Benchmark Results

# ISO 27001:2022 Gap Assessment & Phased Roadmap
**Organisation Profile:** 120-person SaaS company | AWS-hosted | Handles PII & financial data | No prior ISMS | Target: ISO 27001 certification within 18 months

---

## Executive Summary

Based on your profile, you are likely missing the majority of ISO 27001:2022 structural requirements (Clauses 4–10) and a significant portion of the 93 Annex A controls. The good news: AWS provides a strong infrastructure foundation (many physical and environmental controls are inherited), and 18 months is a realistic timeline for a 120-person company with committed leadership. Expect to invest heavily in documentation, risk management processes, and employee awareness in the first 6 months.

---

## Gap Assessment — Mandatory Clauses (ISO 27001:2022 Clauses 4–10)

| Clause | Requirement | Likely Status | Evidence Needed | Gap Notes |
|--------|-------------|---------------|-----------------|-----------|
| 4.1 | Understanding the organisation and its context | ❌ Not Implemented | Internal/external issues register | Most startups have no documented context analysis |
| 4.2 | Understanding interested parties | ❌ Not Implemented | Stakeholder register with requirements | Customers, regulators, investors not formally documented |
| 4.3 | ISMS Scope | ❌ Not Implemented | Signed scope document | Must define boundaries — AWS environment, business systems, people |
| 4.4 | ISMS establishment | ❌ Not Implemented | ISMS framework documentation | No formal ISMS exists |
| 5.1 | Leadership commitment | 🟡 Partial | CEO mandate documented; IS Policy signed by top management | CEO intent exists but no formal policy signed |
| 5.2 | Information Security Policy | ❌ Not Implemented | Top-level IS Policy document | No formal policy documented |
| 5.3 | Roles and responsibilities | 🟡 Partial | RACI chart, role descriptions | Likely informal; needs formal IS role assignments |
| 6.1.1 | Risk and opportunity planning | ❌ Not Implemented | Risk assessment process document | No formal process |
| 6.1.2 | Information security risk assessment | ❌ Not Implemented | Risk register with likelihood/impact scoring | No formal risk register |
| 6.1.3 | Information security risk treatment | ❌ Not Implemented | Risk Treatment Plan (RTP), Statement of Applicability (SoA) | SoA is mandatory; no controls formally selected |
| 6.2 | Information security objectives | ❌ Not Implemented | Documented IS objectives with metrics | No measurable security objectives |
| 6.3 | Planning of changes | ❌ Not Implemented | Change management process | New in 2022; often overlooked |
| 7.1 | Resources | 🟡 Partial | Budget allocation evidence, tool licenses | Likely undocumented |
| 7.2 | Competence | ❌ Not Implemented | Training records, competency assessments | No formal security training records |
| 7.3 | Awareness | ❌ Not Implemented | Awareness programme records, completion logs | Likely no formal security awareness programme |
| 7.4 | Communication | ❌ Not Implemented | Communication plan | No internal security communication plan |
| 7.5 | Documented information | ❌ Not Implemented | Document control procedure, version history | No document management system |
| 8.1 | Operational planning and control | ❌ Not Implemented | Policy suite, procedure documents | Policies not documented |
| 8.2 | Information security risk assessment (results) | ❌ Not Implemented | Completed risk assessment results | No assessments performed |
| 8.3 | Information security risk treatment (results) | ❌ Not Implemented | Completed RTP with evidence of implementation | No treatment evidence |
| 9.1 | Monitoring, measurement, analysis | ❌ Not Implemented | KPI dashboard, metrics reports | No security metrics |
| 9.2.1 | Internal audit (general) | ❌ Not Implemented | Internal audit programme | No audit function |
| 9.2.2 | Internal audit programme | ❌ Not Implemented | Audit schedule, competent auditors | No qualified internal auditors |
| 9.3 | Management review | ❌ Not Implemented | Management review meeting minutes | No management review process |
| 10.1 | Continual improvement | ❌ Not Implemented | Improvement log | No formal improvement tracking |
| 10.2 | Nonconformity and corrective action | ❌ Not Implemented | Nonconformity register, CAP records | No NC management process |

---

## Gap Assessment — Annex A Controls (ISO 27001:2022, Key Themes)

### Theme 1: Organisational Controls (A.5.x)

| Control | Name | Likely Status | Gap Notes |
|---------|------|---------------|-----------|
| A.5.1 | Policies for information security | ❌ | Policy suite does not exist |
| A.5.2 | Information security roles and responsibilities | 🟡 | Informal; not documented |
| A.5.7 | Threat intelligence | ❌ | No formal threat intel programme (new in 2022) |
| A.5.9 | Inventory of information and other assets | ❌ | No asset register |
| A.5.10 | Acceptable use of information and assets | ❌ | No AUP |
| A.5.15 | Access control | 🟡 | Likely using AWS IAM but no formal policy |
| A.5.19 | Information security in supplier relationships | ❌ | No supplier security process; critical for SaaS |
| A.5.23 | Information security for use of cloud services | ❌ | AWS used but no cloud governance policy (new in 2022) |
| A.5.24 | Information security incident management planning | ❌ | No incident response plan |
| A.5.29 | Information security during disruption | ❌ | No BCP |
| A.5.30 | ICT readiness for business continuity | ❌ | No DR planning (new in 2022) |

### Theme 2: People Controls (A.6.x)

| Control | Name | Likely Status | Gap Notes |
|---------|------|---------------|-----------|
| A.6.1 | Screening | 🟡 | May do basic checks; likely not documented |
| A.6.2 | Terms and conditions of employment | 🟡 | Employment contracts exist; IS clauses may be missing |
| A.6.3 | Information security awareness, education and training | ❌ | No formal programme |
| A.6.5 | Responsibilities after termination | ❌ | Offboarding checklist likely missing IS elements |

### Theme 3: Physical Controls (A.7.x)

| Control | Name | Likely Status | Gap Notes |
|---------|------|---------------|-----------|
| A.7.1 | Physical security perimeters | ✅ (inherited) | AWS data centre controls — inherited |
| A.7.4 | Physical security monitoring | ✅ (inherited) | AWS handles — document in SoA as inherited |
| A.7.7 | Clear desk and clear screen | ❌ | No policy; remote workforce adds risk |
| A.7.8 | Equipment siting and protection | 🟡 | Office equipment; likely undocumented |

### Theme 4: Technological Controls (A.8.x)

| Control | Name | Likely Status | Gap Notes |
|---------|------|---------------|-----------|
| A.8.1 | User endpoint devices | 🟡 | MDM may exist; policy likely missing |
| A.8.2 | Privileged access rights | 🟡 | AWS IAM used; formal PAM policy missing |
| A.8.5 | Secure authentication | 🟡 | MFA may be enabled; policy not documented |
| A.8.7 | Protection against malware | 🟡 | Tools likely exist; policy missing |
| A.8.9 | Configuration management | ❌ | No formal config baseline/management (new in 2022) |
| A.8.10 | Information deletion | ❌ | No data retention/deletion policy (new in 2022) |
| A.8.11 | Data masking | ❌ | PII/financial data masking likely not implemented (new in 2022) |
| A.8.12 | Data leakage prevention | ❌ | No DLP controls (new in 2022) |
| A.8.15 | Logging | 🟡 | AWS CloudTrail likely enabled; log review process missing |
| A.8.16 | Monitoring activities | ❌ | No formal monitoring process (new in 2022) |
| A.8.24 | Use of cryptography | 🟡 | TLS likely in use; encryption policy missing |
| A.8.25 | Secure development lifecycle | ❌ | No formal SDLC security policy |
| A.8.28 | Secure coding | ❌ | No secure coding standards (new in 2022) |
| A.8.32 | Change management | 🟡 | Informal change process likely exists |
| A.8.33 | Test information | ❌ | Production data likely used in test environments |

---

## Critical Gaps Summary (Priority Order)

1. **No ISMS Scope or formal IS Policy** — Clauses 4.3 and 5.2 are prerequisites for everything else
2. **No Risk Assessment process or Risk Register** — Clause 6.1.2; blocks SoA and treatment plan
3. **No Statement of Applicability (SoA)** — Clause 6.1.3d; mandatory certification artifact
4. **No documented policy suite** — ~15 policies needed across all Annex A themes
5. **No security awareness programme** — Clause 7.3, A.6.3; will be tested by auditor
6. **No incident response plan** — A.5.24; especially critical given PII/financial data
7. **No supplier security management** — A.5.19; critical for SaaS vendor chain
8. **No cloud governance policy** — A.5.23; AWS-specific control added in 2022
9. **No internal audit function** — Clause 9.2; required before Stage 2 audit
10. **No management review process** — Clause 9.3; required evidence for certification

---

## Phased 18-Month Roadmap to ISO 27001:2022 Certification

### Phase 1: Foundation (Months 1–4)

**Goal:** Establish ISMS structure and core documentation

| Activity | Owner | Deliverable | Clause/Control |
|----------|-------|-------------|----------------|
| Appoint ISO 27001 project lead / CISO | CEO | Role documented | 5.3 |
| Define ISMS scope | Project lead | Scope document | 4.3 |
| Conduct stakeholder and context analysis | Project lead | Context register | 4.1, 4.2 |
| Draft and sign Information Security Policy | CEO + CISO | Signed IS Policy | 5.2, A.5.1 |
| Establish document control system | CISO | Document management procedure | 7.5 |
| Define IS roles and responsibilities | HR + CISO | RACI chart | 5.3, A.5.2 |
| Launch security awareness programme | HR | Training calendar, completion logs | 7.3, A.6.3 |
| Conduct initial risk assessment training | CISO | Team competency records | 7.2 |
| Begin asset inventory | IT | Asset register | A.5.9 |
| Draft Acceptable Use Policy | CISO | AUP v1.0 | A.5.10 |

**Milestone:** ISMS structure established; CEO commitment documented

---

### Phase 2: Risk & Controls (Months 3–9)

**Goal:** Complete risk assessment, select controls, build policy suite

| Activity | Owner | Deliverable | Clause/Control |
|----------|-------|-------------|----------------|
| Conduct formal risk assessment | CISO | Risk register (all assets) | 6.1.2, 8.2 |
| Select risk treatment options | CISO + business | Risk Treatment Plan | 6.1.3 |
| Draft Statement of Applicability | CISO | SoA v1.0 | 6.1.3d |
| Set IS objectives and KPIs | CISO + CEO | IS objectives document | 6.2 |
| Draft full policy suite (~15 policies) | CISO | Policy library | 8.1, Annex A |
| Implement Access Control Policy + IAM review | IT | IAM audit report, policy | A.5.15–5.18 |
| Implement Incident Response Plan + runbooks | SecOps | IRP document | A.5.24–5.28 |
| Implement Supplier Security Policy + vendor reviews | Legal + CISO | Supplier register, contracts | A.5.19–5.22 |
| Enable and formalise AWS logging/monitoring | IT | CloudTrail config, SIEM | A.8.15, A.8.16 |
| Implement MFA everywhere | IT | MFA evidence | A.8.5 |
| Establish change management process | Engineering | Change log, CAB records | A.8.32, 6.3 |
| Conduct BCP/DR planning | IT + Ops | BCP document, DR test | A.5.29, A.5.30 |
| Implement data masking for PII/financial data | Engineering | Masking config | A.8.11 |
| Define data retention and deletion policy | Legal + IT | Retention schedule | A.8.10 |
| Draft Secure Development Lifecycle policy | Engineering | SDLC policy, secure coding standards | A.8.25, A.8.28 |
| Implement configuration management baselines | IT | Config baseline docs | A.8.9 |

**Milestone:** Risk register, SoA, and full policy suite complete; controls implemented

---

### Phase 3: Operate & Measure (Months 8–13)

**Goal:** Demonstrate operational effectiveness; build audit evidence

| Activity | Owner | Deliverable | Clause/Control |
|----------|-------|-------------|----------------|
| Operate under ISMS for minimum 3 months | All | Operational records | 8.1 |
| Collect security metrics / KPI data | CISO | Metrics dashboard | 9.1 |
| Conduct management review meetings (x2) | CEO + CISO | Meeting minutes | 9.3 |
| Run tabletop incident response exercise | SecOps | Exercise report | A.5.24 |
| Complete employee awareness training (100% completion) | HR | Training completion log | A.6.3 |
| Conduct supplier audits / questionnaires | CISO | Supplier assessment records | A.5.19 |
| Review and update risk register | CISO | Updated risk register | 8.2 |
| Perform vulnerability scanning | IT | Scan reports | A.8.8 |
| Run penetration test (recommended for SaaS/PII) | External vendor | Pen test report + remediation | A.8.8 |

**Milestone:** 3+ months of operational evidence; metrics collected

---

### Phase 4: Internal Audit & Pre-Certification (Months 12–15)

**Goal:** Identify and close gaps before Stage 1 audit

| Activity | Owner | Deliverable | Clause/Control |
|----------|-------|-------------|----------------|
| Conduct internal audit (all clauses + selected controls) | Internal auditor / consultant | Internal audit report | 9.2 |
| Log all nonconformities | CISO | Nonconformity register | 10.2 |
| Implement corrective actions | Owners | CAP records with evidence | 10.2 |
| Conduct pre-certification management review | CEO + CISO | Final management review minutes | 9.3 |
| Update SoA if controls changed | CISO | SoA v2.0 | 6.1.3d |
| Engage certification body; submit Stage 1 documentation | CISO | Stage 1 document review | — |

**Milestone:** Stage 1 audit passed; Stage 2 scheduled

---

### Phase 5: Certification Audit (Months 15–18)

**Goal:** Pass Stage 2 (on-site) audit and achieve certification

| Activity | Owner | Notes |
|----------|-------|-------|
| Stage 2 audit (on-site by CB) | Certification body | 2–3 day audit; all staff should be briefed |
| Close any major/minor nonconformities | CISO | Typically 90 days to close major NCs |
| Receive ISO 27001:2022 certificate | — | Valid 3 years; surveillance audits year 1 and 2 |

---

## Key AWS-Specific Considerations

Since you are AWS-hosted, leverage these inherited controls in your SoA:
- **A.7.1–A.7.6** (Physical security): Inherited from AWS; document with AWS compliance reports (SOC 2, ISO 27001 certificate for AWS)
- **A.8.14** (Redundancy): AWS multi-AZ architecture; document your RTO/RPO
- Use **AWS Config**, **Security Hub**, and **GuardDuty** to evidence A.8.16 (Monitoring) and A.8.15 (Logging)
- Obtain and retain **AWS Artifact** compliance reports annually
- Review **shared responsibility model** — document what AWS owns vs. what you own in your SoA

---

## Mandatory Documentation Checklist

Before Stage 1 audit, ensure you have all of the following:

- [ ] ISMS Scope document (4.3)
- [ ] Information Security Policy signed by CEO (5.2)
- [ ] Risk assessment methodology document (6.1.2)
- [ ] Risk register with scores (6.1.2, 8.2)
- [ ] Risk Treatment Plan (6.1.3)
- [ ] Statement of Applicability (6.1.3d)
- [ ] Information security objectives (6.2)
- [ ] Evidence of competence (training records) (7.2)
- [ ] Awareness training logs (7.3)
- [ ] Operational planning evidence — policy suite, procedures (8.1)
- [ ] Security metrics / monitoring results (9.1)
- [ ] Internal audit programme and results (9.2)
- [ ] Management review minutes (x2 minimum) (9.3)
- [ ] Nonconformity and corrective action records (10.2)

---

## Budget Considerations

| Item | Estimated Cost |
|------|----------------|
| ISO 27001 consultant / vCISO (12 months) | $40,000–$80,000 |
| Internal audit (external firm) | $8,000–$15,000 |
| Penetration test | $15,000–$30,000 |
| Security awareness platform | $5,000–$10,000/yr |
| Certification body audit (Stage 1 + Stage 2) | $15,000–$25,000 |
| GRC / ISMS tooling (optional) | $5,000–$20,000/yr |
| **Total estimated** | **$88,000–$180,000** |

---

*Version: 1.0 | Prepared for: 120-person SaaS Company | Standard: ISO/IEC 27001:2022 | Date: 2026-04-18*

# ISO 27001 Gap Assessment & Roadmap for SaaS Company

## Overview

For a 120-person SaaS company with no prior security certification, storing customer PII and financial data in AWS, achieving ISO 27001 certification in 18 months is challenging but achievable with the right planning and resources.

## What You Are Likely Missing

### Governance & Documentation
- **Formal Information Security Policy** — Most companies this size have informal practices but nothing signed off by executive leadership
- **ISMS Scope Definition** — You need to formally define what systems, locations, and people are in scope
- **Roles and Responsibilities** — Security ownership is usually unclear without formal documentation

### Risk Management
- **Risk Assessment Process** — You need a documented methodology for identifying and scoring risks
- **Risk Register** — A formal inventory of all identified risks with likelihood and impact scores
- **Risk Treatment Plan** — Decisions on how to handle each risk (mitigate, accept, transfer, avoid)
- **Statement of Applicability (SoA)** — A mandatory document listing which ISO 27001 controls apply to you and why

### Policy Library
You likely need 10–15 formal policies including:
- Access Control Policy
- Incident Response Policy
- Asset Management Policy
- Supplier/Third-Party Security Policy
- Acceptable Use Policy
- Business Continuity Policy
- Cryptography Policy
- Data Classification Policy
- Secure Development Policy

### Operational Controls
- **Access Management** — Formal processes for provisioning/deprovisioning, privileged access controls
- **Vulnerability Management** — Regular scanning and patching processes
- **Incident Response** — A documented and tested IR plan
- **Backup and Recovery** — Tested recovery procedures with documented RTO/RPO
- **Security Monitoring** — Log collection and review processes
- **Security Awareness Training** — Formal training programme with completion tracking

### Audit & Review
- **Internal Audit Programme** — You need qualified internal auditors and a formal audit schedule
- **Management Review Process** — Executive reviews of ISMS performance at least annually
- **Corrective Action Process** — System for tracking and closing identified gaps

## Phased 18-Month Roadmap

### Phase 1: Establish the Foundation (Months 1–5)

**Hire or appoint a security lead** — Someone needs to own this project full-time or you need an external consultant.

**Define scope** — Decide what systems and people are in scope. Given your AWS environment, this should include your production infrastructure, corporate IT, and all employees.

**Get executive buy-in documented** — CEO needs to sign an Information Security Policy and formally commit resources.

**Build your policy library** — Draft the core policies. These don't need to be perfect immediately, but they need to exist and be approved.

**Conduct initial risk assessment** — Identify your most significant risks. For a SaaS company handling PII and financial data, you should expect risks around:
- Unauthorized access to customer data
- Insider threats
- Third-party/vendor breaches
- Data loss or ransomware

**Create your Statement of Applicability** — Map which controls apply to your business.

### Phase 2: Implement Controls (Months 4–10)

Focus on closing the most critical gaps identified in the risk assessment:

- **Access control** — Implement MFA everywhere, formal IAM procedures, privileged access management
- **Incident response** — Document your IR process and run a tabletop exercise
- **Vendor management** — Assess your key vendors and update contracts with security requirements
- **Security awareness** — Launch training for all employees and track completion
- **Monitoring and logging** — Enable comprehensive logging (AWS CloudTrail, etc.) and establish review processes
- **Vulnerability management** — Regular scanning, plus a penetration test
- **Business continuity** — Document and test your disaster recovery procedures
- **Secure development** — Implement security reviews in your development process

### Phase 3: Operate and Collect Evidence (Months 9–14)

ISO 27001 requires you to demonstrate that your controls are operating effectively, not just that they exist on paper.

- Run your processes for at least 3–6 months before the Stage 2 audit
- Collect evidence: training logs, access reviews, incident records, change management records
- Hold at least two management reviews
- Run your internal audit (typically months 12–13)
- Fix any issues found in the internal audit

### Phase 4: Certification Audit (Months 15–18)

**Stage 1 Audit (Document Review)** — The certification body reviews your documentation. Typically 1 day. They will issue findings that you need to address.

**Stage 2 Audit (On-Site)** — The certification body evaluates whether your controls are actually working. Typically 2–3 days for a company your size. Interviews with staff, review of evidence.

**Close any nonconformities** — Major issues must be closed before certification is granted.

**Receive certificate** — Valid for 3 years with annual surveillance audits.

## AWS-Specific Advantages

Operating on AWS gives you several advantages:
- Physical security controls are handled by AWS (data centers, environmental controls)
- AWS provides compliance documentation (SOC 2, ISO 27001 reports) you can reference
- AWS native tools (CloudTrail, Config, Security Hub, GuardDuty) can help evidence many technical controls
- Document these as "inherited controls" in your SoA

## Realistic Assessment

For a company starting from zero with no formal security programme, expect:
- **6–9 months** to get documentation and basic controls in place
- **3–6 months** of operational evidence needed before certification
- **$100,000–$200,000** total investment including consultant, tools, pen test, and audit fees
- **Strong CEO/leadership commitment** is the single biggest predictor of success

The 18-month timeline is achievable if you start immediately, hire appropriate expertise (internal or external), and treat this as a business priority rather than a compliance checkbox.

# Information Security Policy

---

## Document Control

| Field | Detail |
|-------|--------|
| **Document Title** | Information Security Policy |
| **Document ID** | ISP-001 |
| **Version** | 1.0 |
| **Author** | Chief Information Security Officer |
| **Approved By** | Chief Executive Officer |
| **Approval Date** | [DATE] |
| **Next Review Date** | [DATE + 12 months] |
| **Classification** | Internal |
| **ISO 27001 Clause** | 5.2 |
| **Annex A Control** | A.5.1 (Policies for information security) |

---

## 1. Purpose

This Information Security Policy establishes the overarching framework for protecting the confidentiality, integrity, and availability of [Company Name]'s information assets, systems, and the data entrusted to us by our customers. It demonstrates management commitment to information security and provides direction for all supporting policies, standards, and procedures.

This policy supports [Company Name]'s Information Security Management System (ISMS) established in accordance with **ISO/IEC 27001:2022**.

---

## 2. Scope

This policy applies to:

- **All employees**, contractors, consultants, temporary workers, and third-party personnel with access to [Company Name] systems or information
- **All information assets**, including data, software, hardware, and services regardless of format (electronic, physical, or verbal)
- **All systems and environments**, including production, staging, development, corporate IT, and cloud-hosted services
- **All locations**, including company offices, remote/home working environments, and third-party facilities

This policy covers all activities related to the creation, storage, transmission, processing, and disposal of [Company Name] information.

---

## 3. Policy Statement

[Company Name]'s management is committed to preserving the **confidentiality**, **integrity**, and **availability** of all information assets in support of our business objectives, customer obligations, and applicable legal and regulatory requirements.

[Company Name] will:

1. **Establish and maintain an ISMS** aligned with ISO/IEC 27001:2022 to systematically manage information security risks
2. **Identify and assess information security risks** and implement appropriate controls to reduce risks to an acceptable level
3. **Comply with all applicable legal, regulatory, and contractual obligations** relating to information security, privacy, and data protection (including relevant data protection legislation)
4. **Protect customer data**, including personally identifiable information (PII) and financial data, with the highest priority and care
5. **Provide information security awareness and training** to all personnel to ensure they understand their responsibilities
6. **Respond effectively to information security incidents** to minimise business impact and prevent recurrence
7. **Continually improve** our ISMS through regular reviews, audits, and management oversight
8. **Hold all personnel accountable** for the security of information they access, process, or handle

---

## 4. Roles and Responsibilities

| Role | Responsibility |
|------|----------------|
| **CEO / Executive Team** | Champion information security; approve this policy and ISMS objectives; allocate resources; participate in management reviews |
| **CISO / Security Lead** | Own and maintain the ISMS; develop and review security policies; conduct risk assessments; manage the internal audit programme |
| **IT / Engineering** | Implement and operate technical security controls; maintain secure infrastructure; manage access provisioning |
| **HR** | Ensure security clauses in employment contracts; manage onboarding and offboarding security requirements; coordinate security awareness training |
| **Legal / Compliance** | Ensure contractual and regulatory obligations are reflected in security requirements; manage supplier contracts |
| **All Employees** | Read and comply with this policy and all supporting policies; complete required training; report suspected security incidents immediately |
| **Managers** | Ensure their teams comply with this policy; support security initiatives within their business areas |

---

## 5. Supporting Policies and Controls

This top-level policy is supported by a suite of specific policies and procedures. All personnel are required to comply with applicable supporting policies including:

| Policy | Primary ISO 27001 Mapping |
|--------|--------------------------|
| Access Control Policy | Clause 8.1, A.5.15–A.5.18 |
| Acceptable Use Policy | A.5.10 |
| Information Classification and Handling | A.5.12–A.5.13 |
| Incident Management Policy | A.5.24–A.5.28 |
| Supplier Security Policy | A.5.19–A.5.22 |
| Business Continuity Policy | A.5.29–A.5.30 |
| Cryptography Policy | A.8.24 |
| Secure Development Lifecycle Policy | A.8.25, A.8.28 |
| Asset Management Policy | A.5.9–A.5.11 |
| Human Resources Security Policy | A.6.1–A.6.8 |
| Clear Desk and Clear Screen Policy | A.7.7 |
| Data Retention and Deletion Policy | A.8.10 |

---

## 6. Information Security Objectives

[Company Name] establishes measurable information security objectives aligned with this policy. These objectives are reviewed annually during management review (Clause 9.3) and include, but are not limited to:

- Maintain zero critical unpatched vulnerabilities in production systems beyond agreed SLA
- Achieve and maintain 100% employee completion of annual security awareness training
- Respond to all high-severity security incidents within defined SLA targets
- Complete annual risk assessment and update risk register
- Complete annual internal ISMS audit
- Maintain ISO 27001:2022 certification

Objectives are tracked and reported on a quarterly basis by the CISO.

---

## 7. Risk Management

[Company Name] will maintain a formal risk assessment and treatment process in accordance with Clause 6.1 of ISO 27001:2022. Risks to the confidentiality, integrity, and availability of information assets will be:

- Identified and assessed using a documented methodology (likelihood × impact)
- Treated through mitigation, acceptance, transfer, or avoidance
- Tracked in a Risk Register reviewed at least annually
- Reflected in a Statement of Applicability (SoA) that documents which Annex A controls are applicable

---

## 8. Compliance

### Legal and Regulatory
[Company Name] will identify and comply with all applicable information security legislation and regulations, including:
- Data protection and privacy laws applicable to jurisdictions where we operate and process customer data
- Payment card industry requirements where applicable
- Contractual obligations with customers, partners, and suppliers

### Policy Compliance
All personnel are required to comply with this policy. Violations may result in disciplinary action, up to and including termination of employment or contract. Serious violations may be referred to law enforcement authorities.

The CISO will conduct periodic compliance reviews and report findings to executive management.

---

## 9. Incident Reporting

All personnel must **immediately report** any actual or suspected information security incident to the Security team at [security@company.com] or via the incident reporting portal. This includes:

- Suspected data breaches or unauthorised access
- Loss or theft of devices containing company data
- Malware or phishing attempts
- Accidental sharing of confidential information

Failure to report a suspected security incident is itself a policy violation.

---

## 10. Review and Maintenance

This policy will be reviewed:
- **Annually** as part of the management review process (Clause 9.3)
- Following any significant security incident
- Following significant changes to [Company Name]'s business, technology environment, or regulatory context
- At the direction of the CEO or CISO

All revisions require approval by the CEO before publication.

---

## 11. References

- ISO/IEC 27001:2022 — Clauses 4–10, Annex A
- ISO/IEC 27002:2022 — Information security controls guidance
- [Company Name] ISMS Scope Document (DOC-ISMS-001)
- [Company Name] Risk Assessment Procedure (DOC-RISK-001)
- [Company Name] Statement of Applicability (DOC-SOA-001)

---

## Acknowledgement

All employees, contractors, and third-party personnel with access to [Company Name] systems are required to sign an acknowledgement confirming they have read and understood this policy. Acknowledgement records are maintained by HR.

---

*By order of [CEO Name], Chief Executive Officer*
*[Company Name] | [DATE]*

---

*End of Document — ISP-001 v1.0*

# Information Security Policy
**[Company Name] | Version 1.0**

---

**Approved by:** [CEO Name], Chief Executive Officer
**Date:** [Date]
**Review Date:** [Date + 1 Year]

---

## 1. Purpose and Scope

This Information Security Policy establishes [Company Name]'s commitment to protecting the confidentiality, integrity, and availability of information assets. It applies to all employees, contractors, and third parties who access our systems or data.

---

## 2. Our Commitment

[Company Name] is committed to:

- Protecting the information assets of the company and our customers
- Complying with all applicable laws and regulations related to information security and privacy
- Implementing controls proportionate to the risks we face as a fintech company handling sensitive financial data
- Maintaining and continually improving our Information Security Management System (ISMS)
- Providing employees with the training and resources they need to keep information secure

---

## 3. Key Principles

### 3.1 Confidentiality
Information will only be accessible to those who are authorised to access it. Access to sensitive customer data and financial information is granted on a need-to-know basis.

### 3.2 Integrity
Information will be accurate and protected from unauthorised modification. Systems and data will be maintained in a reliable state.

### 3.3 Availability
Information and systems will be available to authorised users when needed, with appropriate backup and recovery measures in place.

---

## 4. Responsibilities

**Executive Management** is responsible for:
- Approving and supporting this policy
- Allocating appropriate resources for information security
- Setting the tone for a security-aware culture

**The Security/IT Team** is responsible for:
- Implementing and maintaining technical security controls
- Managing access rights and monitoring systems
- Responding to security incidents
- Conducting risk assessments

**All Employees** are responsible for:
- Following this policy and all related security procedures
- Completing required security awareness training
- Reporting security incidents or concerns immediately
- Protecting the devices and accounts they use to access company systems

**Managers** are responsible for:
- Ensuring their teams understand and comply with security requirements
- Participating in security risk discussions relevant to their areas

---

## 5. Core Security Requirements

### Access Control
- All systems must require strong authentication; multi-factor authentication (MFA) is required for all production systems and applications handling customer data
- Access is granted based on least privilege and business need
- Access rights are reviewed quarterly and revoked promptly upon employee departure

### Data Protection
- Customer PII and financial data must be encrypted in transit and at rest
- Data must be classified and handled according to its sensitivity
- Data is retained only as long as necessary and disposed of securely

### Device and Endpoint Security
- Company devices must have current anti-malware software installed
- All devices must use full-disk encryption
- Lost or stolen devices must be reported immediately

### Software and Systems
- Systems must be kept up to date with security patches
- Only approved software may be installed on company devices
- Development must follow secure coding practices

### Third Parties and Suppliers
- All third parties with access to company data must meet our minimum security requirements
- Contracts with suppliers must include appropriate security obligations

### Incident Management
- All suspected security incidents must be reported immediately to the security team
- A formal incident response process is maintained and tested regularly

---

## 6. Risk Management

[Company Name] maintains a formal process for identifying and managing information security risks. Risks are assessed, prioritised, and treated appropriately. A risk register is maintained and reviewed at least annually.

---

## 7. Compliance

All employees must comply with this policy. Violations may result in disciplinary action, including termination. Serious violations may be reported to relevant authorities.

Compliance with this policy and related controls is monitored through:
- Regular internal audits
- Management reviews
- Security monitoring and alerting

---

## 8. Related Policies

This policy is supported by more detailed policies and procedures including:
- Access Control Policy
- Incident Response Procedure
- Acceptable Use Policy
- Data Classification Policy
- Business Continuity Plan
- Supplier Security Policy

---

## 9. Review

This policy is reviewed annually and updated when significant changes occur to our business, technology, or regulatory environment.

---

*[Company Name] — Confidential*

# ISO 27001:2013 vs ISO 27001:2022 — Key Differences & Transition Guide

> **Important Note:** The transition deadline from ISO 27001:2013 to ISO 27001:2022 was **October 31, 2025**. All ISO 27001:2013 certificates have now expired. If you were certified under the 2013 version, you must have already transitioned — or your certification is no longer valid. This guide will help you understand what changed and how to demonstrate compliance with the 2022 version.

---

## 1. High-Level Summary of Changes

| Topic | ISO 27001:2013 | ISO 27001:2022 | Impact |
|-------|----------------|----------------|--------|
| **Annex A Controls (total)** | 114 controls | 93 controls | Net reduction of 21 controls |
| **Annex A Domains/Themes** | 14 domains | 4 themes | Reorganised, not reduced in substance |
| **New controls** | — | 11 new controls | Action required for these 11 |
| **Merged controls** | — | ~57 controls merged into fewer | Lower administrative burden |
| **Removed controls** | — | 0 truly removed | All 2013 concepts are preserved or merged |
| **Clause 6** | 6.1, 6.2 only | Added **6.3** (Planning of changes) | New clause; document your change process |
| **Clause 9.2** | Single clause | Split: **9.2.1** (General) + **9.2.2** (Audit programme) | Document audit programme separately |
| **Clause 9.3** | Single clause | Split: **9.3.1** (General) + **9.3.2** (Inputs) + **9.3.3** (Results) | More granular management review documentation |
| **Control attributes** | None | Each control has 5-attribute taxonomy | Useful for filtering; not strictly mandatory |
| **Standard title** | "Requirements" | "Information security, cybersecurity and privacy protection" | Broader scope acknowledged |

---

## 2. Clause-Level Changes (Mandatory Requirements)

The clause framework (4–10) is substantially the same between versions, but three structural additions affect your documented processes:

### 2.1 New Clause 6.3 — Planning of Changes

**What it requires:** When the organisation determines a need to change the ISMS, changes must be carried out in a planned manner.

**What you need to do:**
- Document your ISMS change management process
- Ensure that when policies, scope, or controls change, there is a formal decision and approval record
- This does NOT require a heavy IT change management process — it applies to ISMS-level changes (e.g., changing scope, adopting new controls, changing risk methodology)

**Evidence for auditors:** Change request records for any ISMS-level changes, with documented rationale and approval

---

### 2.2 Clause 9.2 Split — Internal Audit

**2013:** Single clause 9.2 covering all internal audit requirements

**2022:**
- **9.2.1 General** — the organisation shall conduct internal audits at planned intervals
- **9.2.2 Internal audit programme** — requires a documented audit programme specifying frequency, methods, responsibilities, and results

**What you need to do:**
- Ensure your audit programme is documented separately (not just ad hoc)
- The programme must specify intervals, audit methods, responsibilities, and reporting
- Update your internal audit procedure to reference 9.2.1 and 9.2.2

---

### 2.3 Clause 9.3 Split — Management Review

**2013:** Single clause 9.3

**2022:**
- **9.3.1 General** — top management shall review the ISMS at planned intervals
- **9.3.2 Management review inputs** — explicit list of what must be discussed
- **9.3.3 Management review results** — decisions and actions must be documented

**What you need to do:**
- Ensure your management review minutes explicitly address all required inputs from 9.3.2
- Document decisions and actions (outputs) separately and clearly in minutes
- Ensure minutes reference the 9.3.2 input items so auditors can verify coverage

---

## 3. Annex A Control Changes — The Detail

### 3.1 Structure Change: 14 Domains → 4 Themes

| 2022 Theme | Covers | 2013 Equivalent Domains |
|------------|--------|------------------------|
| **Organisational controls** (A.5, 37 controls) | Policies, roles, supplier management, incident management, compliance | A.5, A.6.1, A.7, A.15, A.18 |
| **People controls** (A.6, 8 controls) | HR security, awareness, remote work, confidentiality | A.7, A.8 |
| **Physical controls** (A.7, 14 controls) | Physical security, equipment, clear desk | A.11 |
| **Technological controls** (A.8, 34 controls) | Access, encryption, logging, vulnerability mgmt, secure dev | A.9, A.10, A.12, A.13, A.14, A.16, A.17 |

---

### 3.2 The 11 New Controls in ISO 27001:2022

These controls did not exist (by name) in ISO 27001:2013. They must be addressed in your updated SoA — either implemented or explicitly excluded with justification.

| Control ID | Control Name | Why It Was Added | Key Implementation Actions |
|------------|--------------|-----------------|---------------------------|
| **A.5.7** | Threat intelligence | Growing threat landscape requires proactive intelligence | Subscribe to threat feeds (ISACs, vendor bulletins); document review process |
| **A.5.23** | Information security for use of cloud services | Cloud adoption had no dedicated control in 2013 | Document cloud governance policy; assess cloud providers; define cloud security requirements |
| **A.5.30** | ICT readiness for business continuity | BC needed stronger IT-specific control | Integrate IT recovery into BCP; test ICT recovery annually |
| **A.7.4** | Physical security monitoring | Physical surveillance needed formalisation | Document CCTV/access control monitoring; retain logs per policy |
| **A.8.9** | Configuration management | Config drift is a leading cause of breaches | Define configuration baselines; use tools (AWS Config, etc.) to detect drift |
| **A.8.10** | Information deletion | Data minimisation became critical (GDPR influence) | Document retention schedules; implement secure deletion procedures |
| **A.8.11** | Data masking | PII/sensitive data protection in non-production | Implement masking in dev/test environments; document approach |
| **A.8.12** | Data leakage prevention | DLP controls needed explicit coverage | Implement DLP tooling or compensating controls; document monitoring |
| **A.8.16** | Monitoring activities | Broader monitoring (beyond just logs) | Formalise monitoring programme covering networks, systems, applications |
| **A.8.23** | Web filtering | Web-based threats needed direct control | Deploy DNS/web filtering; document allowed/blocked categories |
| **A.8.28** | Secure coding | Secure development needed a specific control | Adopt OWASP or similar coding standards; include in SDLC |

---

### 3.3 Controls That Were Merged (Consolidated)

Many 2013 controls were merged into single 2022 controls. You likely already comply with these — you just need to update your SoA mapping.

Key examples:

| 2022 Control | Merged from 2013 Controls |
|--------------|--------------------------|
| A.5.15 (Access control) | A.9.1.1 + A.9.1.2 |
| A.5.16 (Identity management) | A.9.2.1 |
| A.5.17 (Authentication information) | A.9.2.4 + A.9.3.1 + A.9.4.3 |
| A.8.5 (Secure authentication) | A.9.4.2 |
| A.8.15 (Logging) | A.12.4.1 + A.12.4.2 + A.12.4.3 |
| A.8.24 (Use of cryptography) | A.10.1.1 + A.10.1.2 |
| A.5.24–5.28 (Incident management) | A.16.1.1 through A.16.1.7 |

---

### 3.4 Controls Removed or Restructured

No 2013 controls were truly deleted — their intent was absorbed into 2022 controls. However, these 2013 controls were restructured significantly:

- **A.6.1.2** (Segregation of duties) → Now embedded in A.5.3 (Segregation of duties) — same requirement, reorganised
- **A.8.1** series (Asset management) → Redistributed across A.5.9, A.5.10, A.5.11, A.5.12
- **A.14** (System acquisition, development) → Largely absorbed into A.8.25–A.8.34

---

## 4. What You Need to Do for Transition

### Step 1: Update Your Statement of Applicability (SoA)

This is the most critical transition task:
- Remap all 2013 control references to their 2022 equivalents
- Add the 11 new controls — either include or formally exclude with justification
- Update control numbering throughout all documents
- Have the updated SoA reviewed and approved

### Step 2: Address the 11 New Controls

For each of the 11 new controls:
1. Assess current state — do you have compensating controls already?
2. If yes, document evidence and reference in SoA
3. If no, implement controls and create evidence before transition audit

### Step 3: Update Documented Processes

| Document | Change Required |
|----------|----------------|
| ISMS Manual / Scope | Update references from 2013 to 2022; add Clause 6.3 |
| Internal Audit Procedure | Add separate audit programme document (9.2.2) |
| Management Review Procedure | Split into 9.3.1/9.3.2/9.3.3; ensure inputs and outputs documented |
| All policies | Update Annex A control cross-references |
| Risk Treatment Plan | Update control references to 2022 numbering |

### Step 4: Conduct a Transition Internal Audit

Before the transition audit, conduct an internal audit specifically covering:
- All 11 new controls
- Clause 6.3 implementation
- Updated clause 9.2 and 9.3 processes
- SoA accuracy

### Step 5: Transition Audit with Certification Body

Your CB will conduct a transition audit (typically equivalent to a surveillance audit in length). They will verify:
- Updated SoA
- Evidence for the 11 new controls
- Clause 6.3, updated 9.2, updated 9.3
- That your existing controls still operate effectively

---

## 5. New Control Attribute System (Informative — Not Mandatory)

ISO 27001:2022 introduced an attribute taxonomy for each Annex A control. While not mandatory to implement, it can help you filter and prioritise controls.

Each control is tagged with:

| Attribute | Categories |
|-----------|-----------|
| **Control type** | Preventive / Detective / Corrective |
| **Information security properties** | Confidentiality / Integrity / Availability |
| **Cybersecurity concepts** | Identify / Protect / Detect / Respond / Recover |
| **Operational capabilities** | Governance / Asset management / etc. |
| **Security domains** | Governance and ecosystem / Protection / Defence / Resilience |

---

## 6. Summary: Transition Checklist

- [ ] Obtain ISO 27001:2022 standard and read the full Annex A
- [ ] Remap your existing SoA from 2013 to 2022 control references
- [ ] Assess all 11 new controls for applicability and implementation status
- [ ] Implement any new controls with gaps
- [ ] Add Clause 6.3 ISMS change management process
- [ ] Update internal audit programme documentation (9.2.1 / 9.2.2)
- [ ] Update management review documentation (9.3.1 / 9.3.2 / 9.3.3)
- [ ] Update all policy cross-references to 2022 control numbering
- [ ] Conduct transition internal audit
- [ ] Schedule transition audit with certification body
- [ ] Confirm certificate reissued under ISO 27001:2022

---

*Prepared for ISO 27001:2013 → 2022 Transition | Standard: ISO/IEC 27001:2022 | Date: 2026-04-18*

# ISO 27001:2013 vs ISO 27001:2022 — Key Differences

## Overview

ISO 27001:2022 was published in October 2022 and represents the most significant revision to the standard since the 2013 version. The transition deadline was October 2025, meaning all certifications needed to migrate to the 2022 version by then.

The core mandatory clauses (4–10) remain largely the same, but the Annex A controls were significantly restructured.

---

## Structural Changes to Annex A

### Control Count

| Version | Number of Controls | Number of Domains/Themes |
|---------|-------------------|--------------------------|
| 2013 | 114 controls | 14 domains |
| 2022 | 93 controls | 4 themes |

The reduction from 114 to 93 controls does not mean security requirements got weaker — many controls were merged or consolidated. No security requirements were genuinely dropped.

### Themes vs Domains

**2013 had 14 domains**, including:
- A.5 Information security policies
- A.6 Organisation of information security
- A.7 Human resource security
- A.8 Asset management
- A.9 Access control
- A.10 Cryptography
- A.11 Physical and environmental security
- A.12 Operations security
- A.13 Communications security
- A.14 System acquisition, development and maintenance
- A.15 Supplier relationships
- A.16 Information security incident management
- A.17 Business continuity management
- A.18 Compliance

**2022 has 4 themes:**
- **Organisational controls** (A.5) — 37 controls
- **People controls** (A.6) — 8 controls
- **Physical controls** (A.7) — 14 controls
- **Technological controls** (A.8) — 34 controls

---

## New Controls in 2022

ISO 27001:2022 introduced 11 entirely new controls that had no direct equivalent in 2013. These cover modern security concerns:

1. **Threat intelligence** — Formal processes for gathering and acting on threat information
2. **Information security for use of cloud services** — Specific requirements for cloud governance
3. **ICT readiness for business continuity** — IT-specific business continuity requirements
4. **Physical security monitoring** — Surveillance and monitoring requirements
5. **Configuration management** — Managing and maintaining secure system configurations
6. **Information deletion** — Secure and compliant data deletion processes
7. **Data masking** — Protecting sensitive data in non-production environments
8. **Data leakage prevention** — Controls to prevent unauthorised data exfiltration
9. **Monitoring activities** — Broader network and system monitoring
10. **Web filtering** — Controls for web access
11. **Secure coding** — Security requirements in the software development process

---

## Changes to Mandatory Clauses (4–10)

Most clause requirements are unchanged. The notable additions are:

### New Clause 6.3 — Planning of Changes
When changes to the ISMS are needed, they must be carried out in a planned manner. This is a new sub-clause requiring you to document how you manage changes to the ISMS itself (not just IT changes).

### Clause 9.2 — Internal Audit (Split)
The 2022 version splits this into two sub-clauses, requiring a more formally documented internal audit programme that specifies frequency, methods, and responsibilities.

### Clause 9.3 — Management Review (Split)
This is split into three sub-clauses with more explicit requirements around documenting inputs to and outputs from management reviews.

---

## Controls That Were Merged

Many 2013 controls that covered related topics were merged into single 2022 controls. For example:
- The 2013 access control domain (A.9) was consolidated and reorganised
- Multiple incident management controls (A.16 in 2013) are now in A.5.24–A.5.28
- Cryptography controls are now a single control (A.8.24) rather than two

---

## New Attribute System

A significant change in 2022 is the addition of attributes for each control. Each control is tagged with:
- **Control type:** Preventive, Detective, or Corrective
- **Information security properties:** Confidentiality, Integrity, Availability
- **Cybersecurity concepts:** Aligned to NIST CSF (Identify, Protect, Detect, Respond, Recover)
- **Operational capabilities:** What area the control addresses
- **Security domains:** Governance, Protection, Defence, Resilience

While using these attributes is not mandatory, they help organisations filter controls by type and prioritise implementation.

---

## What You Need to Do to Transition

### 1. Update Your Statement of Applicability (SoA)
Remap all 2013 control references to their 2022 equivalents. Add the 11 new controls — assess each for applicability and document your decision (include or exclude with justification).

### 2. Implement the 11 New Controls
For each new control, assess whether you already have compensating controls in place, or whether you need to implement something new. The most commonly impactful for most organisations are cloud services security, configuration management, data masking, and secure coding.

### 3. Update Your Documentation
- Update all policies to reference the new control numbers
- Update your risk treatment plan
- Add documentation for the new Clause 6.3 change management requirement
- Update your internal audit procedure to address 9.2.2 (audit programme)
- Update management review minutes templates to address 9.3.2 inputs and 9.3.3 outputs

### 4. Internal Audit Focused on Gaps
Conduct an internal audit specifically looking at the transition gaps before your certification body transition audit.

### 5. Schedule Transition Audit with Your Certification Body
The transition audit is typically similar in scope to a surveillance audit. Your CB will verify the SoA updates, evidence for new controls, and continued compliance with existing controls.

---

## Summary

The 2022 revision modernises the standard to reflect current threats (cloud, data leakage, secure development) and simplifies the control structure. The clause requirements are broadly similar, with minor structural changes to Clauses 6, 9.2, and 9.3. The main work for transition is updating your SoA, implementing the 11 new controls, and refreshing your documentation.

# ISO 27001:2022 Risk Assessment — Complete Methodology Guide

> **Standard Reference:** ISO 27001:2022 Clauses 6.1.2 (Risk Assessment) and 6.1.3 (Risk Treatment), supported by ISO 27005 (risk management guidance)

This guide walks you through conducting your first formal ISO 27001 risk assessment from start to finish.

---

## 1. What Is an ISO 27001 Risk Assessment?

A risk assessment is the systematic process of identifying, analysing, and evaluating information security risks — and it is the backbone of your entire ISMS. Without a completed risk assessment, you cannot produce a valid Statement of Applicability (SoA) or Risk Treatment Plan (RTP), both of which are mandatory for certification.

ISO 27001 does **not** prescribe a specific methodology — you have freedom to choose your approach — but you must **document** your chosen methodology and apply it consistently.

The standard requires you to (Clause 6.1.2):
- Define and apply a risk assessment process
- Identify risks associated with the loss of CIA (Confidentiality, Integrity, Availability) of information
- Analyse and evaluate risks based on defined criteria
- Retain documented information (results) as evidence

---

## 2. Before You Start — Define Your Risk Criteria

You must document your risk criteria before starting the assessment. This includes:

### 2.1 Risk Acceptance Criteria
Define what level of risk your organisation is willing to accept (the "risk appetite"). Example:

> "Risks scoring 15 or above on a 25-point scale require treatment. Risks scoring 10–14 require management review. Risks scoring below 10 may be accepted."

### 2.2 Scoring Scale
Choose your scales. We recommend **5×5 (Likelihood × Impact)** as it is widely accepted and straightforward:

| Score | Likelihood | Meaning |
|-------|-----------|---------|
| 1 | Rare | Less than once every 5 years |
| 2 | Unlikely | Once every 2–5 years |
| 3 | Possible | Once per year |
| 4 | Likely | Multiple times per year |
| 5 | Almost certain | Monthly or more |

| Score | Impact | Meaning |
|-------|--------|---------|
| 1 | Negligible | Minimal impact; no customer data affected |
| 2 | Minor | Small disruption; limited data exposure; minor financial impact |
| 3 | Moderate | Significant disruption; regulatory notification possible; moderate financial impact |
| 4 | Major | Significant data breach; regulatory fines; reputational damage |
| 5 | Catastrophic | Business-threatening; mass data breach; severe regulatory/legal consequences |

**Risk Score = Likelihood × Impact** (range: 1–25)

Document these criteria in your **Risk Assessment Methodology document** before beginning.

---

## 3. Step-by-Step Methodology

### Step 1: Define the Scope

Confirm your ISMS scope (from Clause 4.3). Your risk assessment must cover all assets, processes, and locations within scope. Do not assess risks outside your defined scope.

---

### Step 2: Build Your Asset Inventory (Prerequisite)

You cannot assess risks without knowing what you are protecting. Build an asset register first (Annex A control A.5.9).

Asset categories to cover:
- **Information assets** — databases, files, contracts, customer data, financial records
- **Software assets** — applications, operating systems, development tools, SaaS tools
- **Physical assets** — servers, laptops, network equipment
- **People** — employees, contractors (as they carry knowledge and access)
- **Services** — cloud providers, internet connectivity, third-party services

For each asset, assign an **owner** — the person accountable for that asset's security.

---

### Step 3: Identify Threats

For each asset (or group of assets), identify realistic threats. A threat is any event or action that could cause harm.

Common threat categories for most organisations:

| Threat Category | Examples |
|-----------------|---------|
| Malicious external actors | Ransomware, phishing, credential stuffing, SQL injection |
| Malicious insiders | Data theft, sabotage, unauthorised access |
| Accidental insiders | Misrouted email, accidental deletion, misconfiguration |
| Third-party/supplier failures | Data breach at vendor, service outage |
| System/technology failures | Hardware failure, software bugs, infrastructure outage |
| Environmental | Power outage, natural disaster, fire |
| Legal/regulatory | Non-compliance leading to fines, contractual breach |

---

### Step 4: Identify Vulnerabilities

For each threat, identify the vulnerabilities that would allow the threat to materialise.

A **vulnerability** is a weakness that could be exploited by a threat. Examples:

| Threat | Example Vulnerability |
|--------|----------------------|
| Ransomware | Unpatched systems, lack of endpoint protection, poor backup hygiene |
| Phishing | Lack of MFA, poor security awareness |
| Insider data theft | Excessive access rights, no DLP controls, no monitoring |
| Vendor breach | No supplier security assessments, excessive data shared with vendor |
| Infrastructure outage | Single points of failure, no DR plan |

---

### Step 5: Score Each Risk

For each identified risk (asset + threat + vulnerability combination), score:

1. **Likelihood (1–5)** — How probable is it that this threat exploits this vulnerability?
2. **Impact (1–5)** — If this risk occurred, how severe would the consequences be?
3. **Risk Score = Likelihood × Impact**

Assess likelihood *before* considering existing controls (inherent risk), then assess again *after* existing controls (residual risk). This shows the value of your current controls.

---

### Step 6: Evaluate and Prioritise Risks

Compare each risk score against your acceptance criteria:

| Score Range | Rating | Action |
|-------------|--------|--------|
| 20–25 | Critical | Must treat; escalate to management |
| 15–19 | High | Treatment required; track closely |
| 10–14 | Medium | Treatment recommended; review with management |
| 5–9 | Low | Accept or monitor; document acceptance |
| 1–4 | Very Low | Accept; note in register |

---

## 4. The Risk Register — Structure and Columns

Your risk register is the core output. Maintain it as a living document. Recommended columns:

| Column | Description |
|--------|-------------|
| **Risk ID** | Unique identifier (e.g., RISK-001) |
| **Asset** | The information asset affected |
| **Threat** | The threat scenario |
| **Vulnerability** | The weakness being exploited |
| **Existing Controls** | Controls already in place |
| **Likelihood (Inherent)** | 1–5, before existing controls |
| **Impact (Inherent)** | 1–5 |
| **Inherent Risk Score** | L × I |
| **Likelihood (Residual)** | 1–5, after existing controls |
| **Impact (Residual)** | 1–5 |
| **Residual Risk Score** | L × I |
| **Risk Rating** | Critical / High / Medium / Low |
| **Treatment Option** | Mitigate / Accept / Transfer / Avoid |
| **Treatment Actions** | Specific control(s) to implement |
| **Annex A Control(s)** | Relevant ISO 27001:2022 Annex A control(s) |
| **Risk Owner** | Person accountable for this risk |
| **Due Date** | Deadline for treatment action |
| **Status** | Open / In Progress / Closed |
| **Notes** | Any additional context |

### Example Risk Register Entry

| Field | Example Value |
|-------|---------------|
| Risk ID | RISK-007 |
| Asset | Customer PII database (AWS RDS) |
| Threat | Unauthorised external access |
| Vulnerability | No MFA on database admin accounts; overly permissive IAM roles |
| Existing Controls | TLS encryption in transit; VPC network segmentation |
| Likelihood (Inherent) | 4 |
| Impact (Inherent) | 5 |
| Inherent Risk Score | 20 (Critical) |
| Likelihood (Residual) | 2 |
| Impact (Residual) | 5 |
| Residual Risk Score | 10 (Medium) |
| Treatment Option | Mitigate |
| Treatment Actions | Implement MFA on all DB admin accounts; review and restrict IAM roles to least privilege |
| Annex A Control(s) | A.5.15 (Access control), A.5.16 (Identity management), A.8.2 (Privileged access rights) |
| Risk Owner | Head of Engineering |
| Due Date | 2026-06-30 |
| Status | In Progress |

---

## 5. Risk Treatment Options

For each risk requiring treatment, select one of four options:

| Option | When to Use | Example |
|--------|-------------|---------|
| **Mitigate** | Implement controls to reduce likelihood or impact | Add MFA; patch systems; encrypt data |
| **Accept** | Risk is within appetite; cost of treatment exceeds benefit | Low-scoring risks with expensive mitigations |
| **Transfer** | Shift financial risk to a third party | Cyber insurance; contractual liability transfer to vendor |
| **Avoid** | Eliminate the activity that creates the risk | Stop storing certain data; exit a risky market |

Document the rationale for every treatment decision — auditors will ask.

---

## 6. Linking Risk Treatment to the Statement of Applicability (SoA)

This is one of the most commonly misunderstood requirements. Your SoA and risk treatment plan must be **linked**:

1. For each risk you choose to mitigate, you select one or more Annex A controls
2. Those controls are then included in your SoA
3. The SoA shows *which* controls you have selected, *why* (justification — typically "to treat RISK-XXX"), and *implementation status*

Controls in your SoA can also be included for reasons other than risk treatment (legal requirements, contractual obligations), but every control selected for risk treatment must appear in the SoA.

**SoA columns:**

| Control ID | Control Name | Applicable? | Justification for Inclusion/Exclusion | Implementation Status |
|------------|-------------|-------------|--------------------------------------|----------------------|
| A.5.15 | Access control | Yes | Risk treatment: RISK-007, RISK-012 | Implemented |
| A.5.7 | Threat intelligence | No | Excluded: insufficient scale to justify dedicated programme; compensating monitoring in place | N/A |

---

## 7. What to Document (Mandatory Evidence)

ISO 27001:2022 requires you to retain documented information (evidence) for:

| Document | Clause Reference |
|----------|-----------------|
| Risk assessment methodology document | 6.1.2 |
| Completed risk register (with scores) | 6.1.2, 8.2 |
| Risk treatment plan | 6.1.3, 8.3 |
| Statement of Applicability | 6.1.3d |
| Evidence of risk owner sign-off | 6.1.3e |

---

## 8. How to Determine Which Risks Need Treatment

Apply this decision process:

```
Risk Score ≥ Risk Acceptance Threshold?
    YES → Treatment REQUIRED. Select mitigate/avoid/transfer.
    NO  → Can you accept this risk?
              YES → Document formal acceptance with risk owner sign-off
              NO  → Treat anyway (management decision)
```

Key principle: **All acceptance decisions must be documented and signed off by a risk owner.** Simply ignoring a risk is not acceptance — it is a nonconformity.

---

## 9. Common Mistakes to Avoid

| Mistake | Why It Matters | Fix |
|---------|----------------|-----|
| Assessing risk at asset level only, not threat/vulnerability level | Misses specific exploits | Always use Asset + Threat + Vulnerability triplet |
| Using only "after controls" scoring | Hides inherent risk; looks artificially clean | Score both inherent and residual risk |
| No risk owner assigned | Auditor will raise NC; nobody accountable | Every risk must have a named owner |
| SoA not linked to risk register | Major NC; cannot demonstrate control selection rationale | Cross-reference risk IDs in SoA |
| Risk register never updated | Certification body expects updates at minimum annually | Review register at least annually or after significant change |
| All risks scored as "Medium" | Appears manipulated; not credible | Use full range; some risks should be Critical |
| Accepting high risks without documentation | Auditor will raise NC | Formal acceptance must be signed off |

---

## 10. Risk Assessment Process Summary

```
1. Document your risk methodology → 2. Build asset register
       ↓
3. Identify threats → 4. Identify vulnerabilities
       ↓
5. Score inherent risk (L × I) → 6. Note existing controls
       ↓
7. Score residual risk → 8. Evaluate against acceptance threshold
       ↓
9. Select treatment option → 10. Build Risk Treatment Plan
       ↓
11. Link to SoA → 12. Assign owners + due dates
       ↓
13. Implement controls → 14. Review annually (or on change)
```

---

## 11. Review and Monitoring

ISO 27001:2022 requires that risk assessments are:
- Performed at planned intervals (at minimum annually)
- Performed when significant changes occur (new product, new data types, breach, major organisational change)
- Results retained as documented information

Schedule your next risk assessment review date and record it in your ISMS calendar before closing the current assessment.

---

*Version: 1.0 | Standard: ISO/IEC 27001:2022 | Clauses: 6.1.2, 6.1.3, 8.2, 8.3 | Date: 2026-04-18*

# ISO 27001 Risk Assessment — Beginner's Guide

## What Is a Risk Assessment and Why Does It Matter?

In ISO 27001, the risk assessment is the foundation of everything. The standard requires you to systematically identify and evaluate risks to your information assets, then decide what to do about them. The controls you implement (and what you include in your Statement of Applicability) should flow directly from this process.

Without a risk assessment, you cannot demonstrate to an auditor that your security controls are based on actual risks rather than random choices.

---

## Step 1: Choose and Document Your Methodology

ISO 27001 does not mandate a specific risk assessment methodology. However, you must document whichever method you choose and apply it consistently.

The most commonly used approach is **likelihood × impact scoring**, sometimes called a qualitative risk matrix. This is what we'll walk through here.

Before you start assessing risks, document:
- **Your scoring scales** (e.g., 1–5 for likelihood and 1–5 for impact)
- **What each score means** in plain terms
- **Your risk acceptance threshold** — what score requires treatment vs. what you'll accept

---

## Step 2: Define Your Scope

Your risk assessment should cover everything within your ISMS scope — typically the systems, people, and processes involved in your core business. Define this clearly before you start. You don't need to assess everything in the entire world, only what's in scope.

---

## Step 3: Identify Your Information Assets

List what you are trying to protect. Common categories include:
- Customer data and databases
- Employee data (HR records)
- Financial records
- Business applications and software
- Infrastructure (servers, networks, cloud services)
- Intellectual property (source code, product designs)
- Physical assets (laptops, office equipment)
- Third-party services you depend on

For each asset, assign an **owner** — someone accountable for its security.

---

## Step 4: Identify Threats and Vulnerabilities

For each asset, think about what could go wrong. A useful framework is to think in terms of:
- **Threats** — who or what could cause harm? (e.g., hackers, malicious insiders, accidents, equipment failure, natural events)
- **Vulnerabilities** — what weaknesses make that threat more likely to succeed? (e.g., no MFA, unpatched software, poor access controls, untrained staff)

Common threats to consider for most businesses:
- Ransomware or malware
- Phishing attacks leading to credential theft
- Unauthorised access (external or internal)
- Accidental data exposure (wrong recipient, misconfigured permissions)
- Data breach via a vendor or supplier
- System failure or outage
- Physical theft of devices

---

## Step 5: Score Each Risk

For each combination of asset + threat, assign:

**Likelihood score (1–5):**
- 1 = Very unlikely (once every several years)
- 3 = Possible (could happen once a year)
- 5 = Almost certain (happens regularly)

**Impact score (1–5):**
- 1 = Negligible (no meaningful harm)
- 3 = Significant (disruption, potential regulatory issues)
- 5 = Catastrophic (major breach, business-threatening)

**Risk Score = Likelihood × Impact** (range: 1–25)

You can also factor in your existing controls when scoring. If you already have strong controls in place, your likelihood score might be lower.

---

## Step 6: Evaluate and Prioritise

Compare each risk score against your acceptance threshold. A common approach:

- **20–25** — Critical: must be treated immediately
- **10–19** — High/Medium: should be treated
- **5–9** — Low: consider treatment or accept with documentation
- **1–4** — Very low: typically accepted

The key is consistency — apply your criteria the same way to all risks.

---

## Step 7: Decide How to Treat Each Risk

For risks above your acceptance threshold, you have four options:

1. **Mitigate** — Implement controls to reduce the likelihood or impact. This is the most common choice.
2. **Accept** — Decide the risk is tolerable. Must be documented and formally accepted by a risk owner.
3. **Transfer** — Shift the risk to someone else (cyber insurance, contractual clauses with vendors).
4. **Avoid** — Stop doing the activity that creates the risk.

---

## What Documentation Do You Need?

ISO 27001 requires you to keep records of:

**Risk Assessment Results** — Your completed risk register. This is a document (spreadsheet or tool) showing every risk you identified, your scores, and your treatment decisions.

**Risk Treatment Plan** — A document detailing the specific actions you will take to treat risks above your threshold, who is responsible, and when they will be completed.

**Statement of Applicability (SoA)** — A required document listing all ISO 27001 Annex A controls, indicating which ones apply to you and why, and their implementation status. Your SoA should be directly linked to your risk assessment — the controls you implement should address the risks you identified.

---

## The Risk Register

Your risk register should be a structured document (spreadsheet works fine) with columns like:

- Risk ID
- Asset
- Threat description
- Vulnerability
- Likelihood score (1–5)
- Impact score (1–5)
- Risk score (L × I)
- Treatment option (Mitigate/Accept/Transfer/Avoid)
- Control(s) to implement
- Risk owner (named individual)
- Target completion date
- Status

---

## Determining Which Risks Need Treatment

Simple rule: **if the risk score exceeds your documented acceptance threshold, it requires treatment**. You must document the treatment decision regardless of which option you choose — even "accept" needs to be formally recorded with the risk owner's sign-off.

Don't leave any risk undocumented. An auditor will look for evidence that you've made a conscious decision about every significant risk.

---

## After the Assessment

Once your risk assessment is complete:

1. Build your Risk Treatment Plan — list every action needed to address high/critical risks
2. Implement the controls
3. Update your Statement of Applicability
4. Set a schedule to review the risk register at least annually (or when significant changes occur)
5. Keep records — auditors will want to see the risk register, treatment plan, and evidence that treatment actions were completed

Risk assessment is not a one-time exercise. ISO 27001 expects it to be a living process that you revisit regularly as your business and threat environment changes.

# Closing the "Insufficient Evidence of Management Review" Major Nonconformity

## Understanding the Nonconformity

**Clause:** ISO 27001:2022 Clause 9.3 — Management Review
**Classification:** Major Nonconformity

A major nonconformity (NC) means your organisation has failed to satisfy a mandatory requirement of the standard. A major NC typically blocks certification or requires resolution within a defined period (usually 30–90 days) before a re-audit. This is one of the most commonly raised major NCs, and one of the most straightforward to close — if you take the right approach.

---

## What Clause 9.3 Actually Requires

ISO 27001:2022 splits management review into three sub-clauses:

### Clause 9.3.1 — General
Top management shall review the organisation's ISMS at **planned intervals** to ensure its continuing suitability, adequacy, and effectiveness.

**Key requirements:**
- Reviews must be conducted by **top management** (CEO, CTO, board — not just the CISO alone)
- They must occur at **planned intervals** (typically at least annually; many organisations do them twice a year)
- The review must assess **suitability** (is the ISMS still right for our context?), **adequacy** (do we have enough resources?), and **effectiveness** (is it working?)

### Clause 9.3.2 — Management Review Inputs
The review must consider a defined list of inputs. All of the following must be addressed:

| Input | Description |
|-------|-------------|
| **(a)** Status of actions from previous reviews | Were action items from the last review completed? |
| **(b)** Changes in external/internal issues relevant to ISMS | New regulations, business changes, new threats |
| **(c)** Changes in needs/expectations of interested parties | Customer requirements, regulatory changes |
| **(d)** Feedback on IS performance | See breakdown below |
| **(e)** Feedback from interested parties | Customer complaints, supplier issues |
| **(f)** Results of risk assessment and risk treatment | Risk register updates, treatment status |
| **(g)** Performance of IS objectives | Are we hitting our security metrics? |
| **(h)** Opportunities for continual improvement | What can we do better? |

**Input (d) — Feedback on IS performance — must include:**
- Nonconformities and corrective actions
- Monitoring and measurement results
- Audit results (internal + external)
- Fulfillment of IS objectives
- Feedback from interested parties (customers, regulators)

### Clause 9.3.3 — Management Review Results/Outputs
The review must produce documented outputs including:
- **Decisions and actions** related to continual improvement opportunities
- **Resource needs** — any changes needed to resources supporting the ISMS
- **Changes to the ISMS** if required (scope, policies, controls)

---

## What "Insufficient Evidence" Typically Means

When an auditor raises this NC, they have found one or more of the following:

| Finding Type | What the Auditor Saw |
|-------------|---------------------|
| No meeting minutes | Management review was claimed to happen verbally but no documentation exists |
| Incomplete inputs | Minutes exist but do not cover all required inputs (e.g., no discussion of risk assessment results, or no IS objectives review) |
| Minutes are too vague | e.g., "security was discussed" — no specifics, no evidence of actual analysis |
| Wrong attendees | Minutes show only the CISO attended — no top management participation |
| No outputs documented | No action items, decisions, or resource commitments recorded |
| Review never happened | ISMS has been running for over a year with no management review at all |
| Only one review in a multi-year period | Standard requires planned intervals; one review in 3 years is insufficient |

---

## What Evidence You Should Have — Complete Checklist

For each management review, you must have:

### Meeting Evidence
- [ ] **Meeting invitation/calendar record** — shows the meeting was scheduled in advance (demonstrates "planned intervals")
- [ ] **Attendance list** — must include top management (named individuals, their roles)
- [ ] **Meeting agenda** — covering all Clause 9.3.2 input items
- [ ] **Meeting minutes** — formally documented, signed off or approved by the chair (top management representative)
- [ ] **Action items log** — specific actions, named owners, deadlines

### Content Coverage (Minutes Must Address All of the Following)
- [ ] Status of actions from previous review (or note this is the first review)
- [ ] Changes to internal/external context (business changes, regulatory changes, new threats)
- [ ] Changes to stakeholder requirements
- [ ] Nonconformities raised since last review and corrective action status
- [ ] Results of internal audits (summary of findings)
- [ ] Results of monitoring and measurement (security metrics/KPIs)
- [ ] Status of information security objectives — are targets being met?
- [ ] Risk assessment results summary — any new critical risks?
- [ ] Risk treatment status — are treatment actions on track?
- [ ] Feedback from interested parties (customers, regulators, etc.)
- [ ] Opportunities for continual improvement identified
- [ ] Decisions made on resources for the ISMS
- [ ] Decisions on any ISMS changes required
- [ ] Any other relevant security matters

### Supporting Evidence (Referenced in Minutes)
- [ ] Metrics/KPI dashboard or report presented at the meeting
- [ ] Internal audit report(s) summary
- [ ] Updated risk register or risk summary
- [ ] IS objectives tracking sheet
- [ ] Corrective action log/nonconformity register

---

## How to Write the Corrective Action Plan (CAP)

A corrective action plan for a major NC must follow the standard **root cause → correction → corrective action → verification** structure. Here is a complete template:

---

### Corrective Action Plan — Major Nonconformity

**Reference:** NC-[YEAR]-[NUMBER]
**Nonconformity:** Insufficient evidence of management review
**Clause:** ISO 27001:2022 Clause 9.3
**Classification:** Major
**Date Raised:** [DATE]
**Audit Finding (verbatim):** "[Copy exact wording from audit report]"
**CAP Owner:** [CISO / Compliance Manager name]
**Target Closure Date:** [DATE — within CB's stipulated period]

---

#### Section 1: Immediate Correction (Fix the Symptom)

*What have you done right now to address the immediate deficiency?*

| Action | Responsible | Completion Date | Evidence |
|--------|-------------|-----------------|---------|
| Scheduled an emergency management review meeting for [DATE] | CISO | [DATE] | Meeting invite / calendar record |
| Prepared a comprehensive management review agenda covering all Clause 9.3.2 inputs | CISO | [DATE] | Agenda document |
| Conducted management review meeting with [CEO], [CTO], [CISO] in attendance | CEO | [DATE] | Signed meeting minutes |
| Documented meeting minutes covering all required inputs and outputs | CISO | [DATE] | Management review minutes v1.0 |
| Created action item tracker for management review outputs | CISO | [DATE] | Action log |

---

#### Section 2: Root Cause Analysis

*Why did this nonconformity occur?*

**Identified Root Causes:**

1. **Process gap:** No formal management review procedure was documented. There was no defined schedule, agenda template, or minute template to ensure consistency and coverage.

2. **Awareness gap:** Top management was not aware that their active participation and formal documented review of the ISMS was a mandatory ISO 27001 requirement. The CISO was managing the ISMS without adequate executive engagement.

3. **Document management gap:** Even where discussions occurred informally (e.g., during board meetings), they were not captured in a format that constitutes documented evidence for the purposes of Clause 9.3.

---

#### Section 3: Corrective Actions (Fix the Root Cause)

*Systemic changes to prevent recurrence:*

| Action | Responsible | Target Date | Evidence |
|--------|-------------|-------------|---------|
| Draft and approve a formal Management Review Procedure documenting: schedule (twice yearly), agenda template covering all 9.3.2 inputs, minute template, attendee requirements, action tracking process | CISO | [DATE] | Approved procedure document |
| Create a standard Management Review Pack template (agenda + minute template with all 9.3.2 inputs pre-populated as agenda items) | CISO | [DATE] | Template document |
| Schedule management reviews on standing executive calendar for next 12 months (at minimum: [DATE] and [DATE]) | EA to CEO | [DATE] | Calendar records |
| Brief executive team on Clause 9.3 requirements and their mandatory participation | CISO | [DATE] | Briefing deck / attendance record |
| Add management review schedule and completion status to ISMS KPI dashboard | CISO | [DATE] | Updated dashboard |
| Conduct second management review per schedule to demonstrate planned intervals | CEO | [DATE] | Meeting minutes |

---

#### Section 4: Effectiveness Verification

*How will you verify the corrective actions worked?*

| Verification Activity | Responsible | Date |
|----------------------|-------------|------|
| Internal audit of Clause 9.3 compliance — verify procedure exists, two reviews conducted, evidence complete | Internal Auditor | [DATE — before closure audit] |
| Review management review minutes for completeness against 9.3.2 checklist | CISO | After each review |
| Confirm management review schedule integrated into ISMS governance calendar | CISO | [DATE] |
| Present evidence package to certification body at closure audit | CISO | [DATE] |

---

#### Section 5: Evidence Package for Closure Audit

Compile the following as your evidence package for the CB:

1. Management Review Procedure (approved, version controlled)
2. Management Review Pack template (agenda + minute template)
3. Evidence of management review conducted immediately (minutes, attendance, action log)
4. Evidence of second review (if time permits before closure audit) OR scheduled date confirmed
5. Executive briefing records showing top management awareness
6. Calendar records showing future reviews scheduled
7. Internal audit report confirming Clause 9.3 compliance

---

**Approved by:** [CISO Name]
**Executive Sponsor:** [CEO Name]
**Date:** [DATE]
**Next Review:** [CLOSURE AUDIT DATE]

---

## Quick Reference — Management Review Meeting Agenda Template

```
MANAGEMENT REVIEW AGENDA — ISO 27001:2022 Clause 9.3
Date: [DATE] | Attendees: [CEO, CTO, CISO, ...]

1. Status of actions from previous management review (9.3.2a)
2. Changes to internal/external context relevant to ISMS (9.3.2b)
3. Changes to interested party requirements (9.3.2c)
4. IS performance feedback (9.3.2d):
   a. Nonconformities and corrective actions
   b. Monitoring and measurement results / KPIs
   c. Internal and external audit results
   d. Achievement of IS objectives
   e. Feedback from customers/stakeholders
5. Risk assessment results and treatment status (9.3.2f)
6. IS objectives performance (9.3.2g)
7. Opportunities for continual improvement (9.3.2h)
8. Decisions and actions required (9.3.3):
   a. Improvement opportunities
   b. Resource needs
   c. ISMS changes required
9. Any other business
```

---

## Timeline to Closure

| Week | Action |
|------|--------|
| Week 1 | Conduct emergency management review; produce minutes |
| Week 1–2 | Draft and approve Management Review Procedure and templates |
| Week 2 | Brief executive team; schedule future reviews |
| Week 3 | Conduct internal audit of Clause 9.3 compliance |
| Week 4 | Compile evidence package; submit to CB for closure review |

---

*Reference: ISO/IEC 27001:2022 Clause 9.3 | Nonconformity Management: Clause 10.2 | Date: 2026-04-18*

# Responding to a Major Nonconformity: "Insufficient Evidence of Management Review"

## Understanding the Finding

A major nonconformity (NC) is a serious audit finding that means you have failed to satisfy a mandatory requirement of ISO 27001. The management review requirement is one of the standard's core obligations — it exists because top management needs to be actively engaged in overseeing the information security management system, not just leaving it to the security team.

When auditors raise this NC, they typically found one of the following:
- No management review was conducted at all
- A review was conducted but not properly documented
- The documentation is too vague to demonstrate what was actually reviewed
- Only the security team attended, without genuine top management participation
- Not all required topics were covered

---

## What Management Review Actually Requires

ISO 27001 requires top management (the CEO, executive team, or equivalent) to formally review the ISMS at planned intervals — typically at least annually, and often twice a year.

The review must be a real meeting where executives actively engage with ISMS performance. It cannot be delegated entirely to the CISO or security team.

### Required Topics (Inputs)

The management review must cover:

1. **Follow-up from previous reviews** — Were last time's action items completed?
2. **Changes to context** — Has anything significant changed (regulatory environment, business strategy, new threats)?
3. **ISMS performance** — How well is the security programme working? This includes:
   - Results from internal and external audits
   - Security incidents and how they were handled
   - Security metrics and KPIs
   - Progress on security objectives
   - Corrective actions status
4. **Feedback from stakeholders** — Customer complaints, supplier issues, regulatory communications
5. **Risk assessment results** — Are risks being managed effectively?
6. **Opportunities for improvement** — What should we do better?

### Required Outputs

The review must produce documented decisions and actions, including:
- Specific improvement actions with owners and deadlines
- Any changes needed to the ISMS
- Resource decisions (budget, people, tools)

---

## What Evidence You Need

For each management review, you must have:

**Before the meeting:**
- A formal meeting invitation showing the review was planned
- An agenda that covers all required topics

**From the meeting:**
- Signed meeting minutes that are specific enough to show what was actually discussed
- An attendance list including top management (not just security staff)
- A list of decisions and action items, with owners and target dates

**Supporting evidence (referenced in or attached to minutes):**
- Security metrics/dashboard presented at the review
- Audit report summaries
- Risk assessment summary
- Status of security objectives

The minutes must be specific. "Security performance was reviewed" is not sufficient. "The Q3 vulnerability scan identified 3 high findings; all have been remediated as of [date]" is the kind of specificity auditors expect.

---

## Writing a Corrective Action Plan

A corrective action plan (CAP) must address both the immediate symptom and the underlying root cause. Here is how to structure it:

---

### CAP Structure

**Nonconformity Reference:** [Audit NC number]
**Clause:** ISO 27001:2022, Clause 9.3 — Management Review
**Classification:** Major
**Finding:** [Copy the exact wording from the audit report]
**Owner:** [Name and title]
**Target Closure Date:** [Within your certification body's deadline]

---

**1. Immediate Correction**

What you will do right away to fix the immediate problem:

- Schedule an emergency management review within [timeframe — typically 2–4 weeks]
- Prepare a comprehensive agenda covering all required inputs
- Conduct the review with top management in attendance
- Document detailed minutes covering all required topics and decisions
- Compile and retain all supporting evidence

*Evidence:* Meeting minutes, attendance list, action items log

---

**2. Root Cause Analysis**

Why did this happen?

Common root causes:
- No formal documented process for management review (no procedure, no agenda template, no schedule)
- Top management not aware that formal documentation and their participation was a mandatory requirement
- The security team was conducting internal security reviews but not escalating to a formal management-level review with proper documentation

---

**3. Corrective Actions**

Systemic changes to prevent this happening again:

| Action | Owner | Target Date |
|--------|-------|-------------|
| Create a Management Review Procedure documenting schedule, required agenda topics, documentation requirements | CISO | [Date] |
| Develop agenda and minutes templates covering all Clause 9.3 required inputs | CISO | [Date] |
| Schedule management reviews on executive calendar (minimum twice per year) | EA/COO | [Date] |
| Brief executive team on their responsibilities under ISO 27001 Clause 9.3 | CISO | [Date] |
| Conduct second management review per new procedure | CEO | [Date] |

---

**4. Verification**

How you'll confirm the actions worked:
- Conduct an internal audit specifically checking Clause 9.3 compliance before the closure audit
- Confirm two management reviews have been held with proper documentation
- Present evidence to the certification body at the closure meeting

---

## What to Submit to the Certification Body

When submitting your CAP and evidence:

1. **The completed CAP document** — showing root cause analysis and all planned actions
2. **Management review minutes** (the ones you conducted as immediate correction)
3. **Management Review Procedure** (your new documented process)
4. **Evidence of second review** (if time allows) or a confirmed scheduled date
5. **Internal audit results** confirming Clause 9.3 is now compliant

---

## Timeline

Most certification bodies give you **30–90 days** to close a major NC. A realistic timeline:

- **Week 1:** Conduct emergency management review with top management; document minutes
- **Week 1–2:** Write and approve Management Review Procedure and templates; brief executives
- **Week 3:** Internal audit to verify compliance
- **Week 4:** Submit CAP and evidence package to certification body

The key is acting quickly and demonstrating that you understand both what went wrong and how you've fixed the underlying process — not just the immediate documentation gap.

# SOC 2 Type 1 vs. Type 2: Guidance for a First-Time B2B SaaS Startup

## Overview

SOC 2 is an audit framework governed by the AICPA (American Institute of Certified Public Accountants). It evaluates whether a service organization's controls meet the **Trust Services Criteria (TSC)**. There are five TSC categories; **Security (Common Criteria, CC1–CC9) is always required**. The others — Availability (A1), Confidentiality (C1), Processing Integrity (PI1), and Privacy (P1–P8) — are optional and added based on customer or contractual requirements.

---

## Type 1 vs. Type 2: The Core Difference

| Dimension | Type 1 | Type 2 |
|---|---|---|
| **What it tests** | Design of controls at a **single point in time** | Design AND **operating effectiveness** over a period (typically 6–12 months) |
| **Auditor question** | "Are the right controls in place today?" | "Did those controls actually work consistently over time?" |
| **Evidence required** | Policy documents, system configurations, descriptions | All Type 1 evidence PLUS transaction samples, logs, tickets, access reviews across the audit period |
| **Value to customers** | Lower — shows intent, not proof of execution | Higher — the gold standard enterprise customers want |
| **Time to complete** | 2–4 months from readiness to report | 9–18 months total (including the observation period) |
| **Cost** | Lower (typically $15K–$40K for a small org) | Higher (typically $25K–$75K+ for a small org) |

**Key distinction:** A Type 1 report says your controls are *designed* correctly. A Type 2 report says your controls actually *worked* for 6–12 months. Enterprise customers overwhelmingly want Type 2 because it demonstrates sustained operational practice, not just a snapshot.

---

## Which Should You Pursue?

**Short answer: Target Type 2, but consider Type 1 as an accelerator if timing is tight.**

### When to start with Type 1

- Your enterprise customer needs *something* within 3–4 months
- You have never had formal controls in place and need a milestone to work toward
- You want a "practice run" before committing to a full Type 2 observation period
- You can negotiate with the customer to accept Type 1 now with a commitment to Type 2 within 12 months

### When to go directly to Type 2

- You have 12–18 months before the deal closes or renewal is at risk
- You already have reasonably mature controls operating (even informally)
- Multiple customers are asking, and you want a single report that satisfies everyone
- You want the report to have long-term market value

### Practical recommendation for your situation

Since an enterprise customer is asking *now* and you have no prior SOC 2 work:

1. **Immediately begin building controls** — do not wait. The Type 2 observation period clock starts when controls are operating, not when you engage an auditor.
2. **Engage a readiness consultant or auditing firm early** — they will help scope the report and identify gaps against CC1–CC9.
3. **Consider a Type 1 as a bridge** — obtain a Type 1 report in ~4 months to give the customer something, then convert to Type 2 after your 6-month observation period.
4. **Negotiate with the customer** — many enterprise procurement teams will accept a Type 1 with a roadmap commitment to Type 2.

---

## Typical Timeline

### Path A: Type 1 Only (fastest)

```
Month 1–2:   Gap assessment against CC1–CC9
             Policy writing (Information Security, Access Control, IR, Change Mgmt, etc.)
             Control implementation (MFA, access reviews, logging, etc.)

Month 2–3:   Readiness assessment (internal or with auditor)
             Evidence collection for point-in-time snapshot
             Remediation of critical gaps

Month 3–4:   Auditor fieldwork
             Report issuance

→ Total: ~3–5 months from start to Type 1 report
```

### Path B: Type 1 → Type 2 (recommended for your situation)

```
Month 1–2:   Gap assessment, policy writing, control implementation
Month 3–4:   Type 1 audit and report issued → share with customer
Month 4–10:  Observation period — controls must operate consistently
             (access reviews, change management, incident response, vendor reviews)
Month 10–12: Type 2 fieldwork with auditor
Month 12–14: Type 2 report issued

→ Total: ~12–14 months from start to Type 2 report
```

### Path C: Direct to Type 2 (if you can negotiate time)

```
Month 1–3:   Gap assessment, policy writing, control implementation
Month 3–9:   6-month observation period (minimum typical)
Month 9–11:  Type 2 fieldwork
Month 11–13: Type 2 report issued

→ Total: ~12–13 months from start to Type 2 report
```

---

## Minimum Controls to Build First (CC Focus)

Since Security (CC1–CC9) is always required, prioritize these control areas immediately:

| TSC Criterion | What you need |
|---|---|
| **CC1** — Control Environment | Written information security policy, management accountability |
| **CC3** — Risk Assessment | Annual risk assessment with documented register |
| **CC6** — Logical Access | MFA enforcement, least privilege, quarterly access reviews, provisioning/deprovisioning procedures |
| **CC7** — System Operations | Monitoring/alerting (SIEM or equivalent), incident response plan, vulnerability scanning |
| **CC8** — Change Management | Formal change request process, code review, separation of duties in deployments |
| **CC9** — Vendor Risk | Vendor inventory, annual review of critical vendors' SOC 2 reports |

---

## Key Decisions to Make Now

1. **Scope:** Will you include only Security (CC), or add Availability (A1) or Confidentiality (C1)? Most first-time reports are Security-only. Discuss with your customer what they need.
2. **Auditor selection:** You need a licensed CPA firm to issue a formal SOC 2 report. Firms like Schellman, Coalfire, Prescient Assurance, or a regional CPA firm with SOC 2 practice are options.
3. **Readiness support:** Consider a readiness partner (compliance platform like Vanta, Drata, Secureframe, or a consultant) to accelerate gap closure.
4. **Observation period start date:** The moment you implement controls is when your observation period can begin — document this clearly.

---

## Important Note

Only a **licensed CPA firm** can issue a formal SOC 2 report. Compliance platforms and consultants can help you prepare, but the audit itself must be performed by a qualified auditor. Plan for the auditor relationship early, as capacity at reputable firms books up.

# SOC 2 Type 1 vs. Type 2 for a B2B SaaS Startup

## What is SOC 2?

SOC 2 is a security audit framework developed by the AICPA that's widely used in B2B software. It evaluates whether a company has proper controls around security, availability, and data handling. An independent auditor reviews your controls and issues a report that you can share with customers as proof of your security posture.

---

## Type 1 vs. Type 2: What's the Difference?

**SOC 2 Type 1** is a point-in-time assessment. The auditor looks at your controls on a specific date and confirms that they are designed correctly. Think of it as a photograph: "On this day, the controls look right."

**SOC 2 Type 2** evaluates whether your controls not only exist but have been working effectively over a period of time — typically 6 to 12 months. Think of it as a video: "Over this period, we watched the controls operate and they consistently worked."

The key differences:

| | Type 1 | Type 2 |
|---|---|---|
| Scope | Design effectiveness only | Design + operating effectiveness |
| Time period | Single date | 6–12 months |
| Effort | Less | Significantly more |
| Time to complete | 2–4 months | 9–18 months |
| Customer trust value | Moderate | High |
| Cost | Lower | Higher |

---

## Which Should You Pursue?

For an enterprise customer asking for a SOC 2 report, **they almost certainly want Type 2**. Type 1 is sometimes accepted as a stepping stone, but enterprise procurement and security teams know that Type 1 only proves your controls are designed — not that they actually work day to day.

That said, if you have no SOC 2 work done yet, going straight to a Type 2 requires patience because:
- You need to implement controls first
- Then you need an observation period of at least 6 months
- Then the auditor does fieldwork and issues the report

**Recommended approach for your situation:**

1. Start implementing controls immediately — the clock doesn't start until controls are actually running
2. Consider getting a Type 1 report in 3–4 months to show the enterprise customer you're serious and making progress
3. Use the Type 1 as a bridge while your 6-month observation period runs
4. Complete the Type 2 roughly 12–14 months from today

This "Type 1 bridge" approach is very common for first-timers with an impatient enterprise customer.

---

## Typical Timeline

### Getting a Type 1 (fastest path to something)

- **Months 1–2:** Implement core security controls, write policies, conduct a risk assessment
- **Months 2–3:** Readiness review, close gaps, gather evidence
- **Months 3–4:** Auditor fieldwork and report issuance
- **Total: 3–5 months**

### Getting a Type 2 (what enterprise customers really want)

- **Months 1–2:** Implement controls and policies (same as Type 1 prep)
- **Months 2–8:** Observation period — controls must operate consistently with evidence
- **Months 8–10:** Auditor fieldwork (they test samples across the period)
- **Months 10–12:** Report issued
- **Total: 10–14 months from scratch**

---

## Key Controls to Build Now

Regardless of Type 1 or 2, you'll need:

- **Access controls:** Multi-factor authentication, least privilege access, user provisioning and deprovisioning procedures, periodic access reviews
- **Incident response:** A documented plan that gets tested or rehearsed
- **Change management:** A process for reviewing and approving code and infrastructure changes
- **Risk assessment:** An annual documented process for identifying security risks
- **Vendor management:** Inventory of critical vendors and reviews of their security
- **Monitoring:** Logging and alerting on your systems for anomalies
- **Policies:** Written information security policy, acceptable use policy, and others

---

## Practical Next Steps

1. **Talk to your enterprise customer** — ask what they'll accept (Type 1 now, Type 2 later?) and what scope they need (security only, or also availability?)
2. **Engage an auditor early** — only a licensed CPA firm can issue a real SOC 2 report; good firms book up months in advance
3. **Consider a compliance platform** — tools like Vanta, Drata, or Secureframe can automate evidence collection and speed up readiness significantly for a startup
4. **Start with security basics** — MFA everywhere, access reviews, documented policies, logging

The good news: as a cloud-native startup, many of the controls you need are achievable quickly if you use the right tools and commit the time.

# SOC 2 Security (Common Criteria) Control Checklist
## For a Cloud-Native Company Using AWS, GitHub, and Okta

This checklist maps practical controls to the AICPA 2017 Trust Services Criteria CC1–CC9 (Security/Common Criteria). Every control listed is required for SOC 2 Security. Use this as a gap assessment tool: mark each item as Met, Partial, or Gap.

---

## CC1 — Control Environment (Governance & Integrity)

Controls that establish accountability, integrity, and oversight at the organizational level.

- [ ] Written **Information Security Policy** exists, is approved by leadership, reviewed annually, and communicated to all employees
- [ ] **Acceptable Use Policy** is in place and employees have signed acknowledgment
- [ ] **Organizational chart** with defined security responsibilities (CISO or security owner identified)
- [ ] **Background checks** performed for new hires (especially those with privileged access)
- [ ] **Security awareness training** conducted at onboarding and annually; completion tracked
- [ ] **Code of conduct / ethics policy** documented and acknowledged by employees
- [ ] Leadership demonstrates commitment to security (e.g., security is a standing agenda item in leadership meetings)

*Evidence for auditors: Signed policy acknowledgments, training completion records, org chart, board/leadership meeting minutes referencing security.*

---

## CC2 — Communication and Information

Controls ensuring relevant security information flows internally and externally.

- [ ] Security policies and procedures are **accessible to all employees** (e.g., in a wiki, intranet, or policy management tool)
- [ ] **Incident reporting channels** are documented and communicated (employees know how to report a security incident)
- [ ] **External communication policy** for disclosing security incidents to customers and regulators exists
- [ ] **Vulnerability disclosure or responsible disclosure program** is documented (even a basic policy page)
- [ ] Security updates and alerts are communicated to relevant teams (e.g., AWS security bulletins reviewed)

*Evidence: Policy repository access logs, incident reporting runbook, external disclosure policy.*

---

## CC3 — Risk Assessment

Controls for identifying, analyzing, and responding to security risks.

- [ ] **Annual risk assessment** is documented, signed off by leadership, and covers the in-scope system
- [ ] **Risk register** maintained with identified risks, likelihood/impact ratings, and assigned owners
- [ ] **Risk treatment decisions** documented (accept, mitigate, transfer, avoid) for each identified risk
- [ ] **Threat modeling** or risk review performed for significant new features or infrastructure changes
- [ ] Risk assessment methodology is documented and consistently applied

*Evidence: Dated risk assessment document with approvals, risk register with status, change-linked risk reviews.*

---

## CC4 — Monitoring Controls

Controls for ongoing monitoring of the control environment.

- [ ] **Internal audit or compliance review** scheduled at least annually to assess control effectiveness
- [ ] **Exception tracking** — identified control exceptions are logged and remediated
- [ ] Results of monitoring activities are reported to management
- [ ] **Penetration testing** or third-party security assessment performed annually
- [ ] Security metrics and KPIs tracked and reviewed by leadership (e.g., patch compliance rate, open vulnerabilities)

*Evidence: Audit reports, pen test reports, management review meeting notes, exception log.*

---

## CC5 — Control Activities (Policies & Procedures)

Controls specifying that policies are implemented as intended.

- [ ] All policies in the core policy set are **implemented** (not just written)
- [ ] **Separation of duties** enforced for critical functions (e.g., no single engineer can push to production AND approve the change)
- [ ] **Least privilege** principle is documented and enforced in AWS IAM, GitHub, and Okta
- [ ] **Documented procedures** exist for key operational processes (onboarding, offboarding, incident response, change management, etc.)
- [ ] Control activities are **tested** periodically to verify they operate as designed

*Evidence: Procedure documents, IAM policy exports showing least privilege, change records showing approvals.*

---

## CC6 — Logical & Physical Access Controls

This is typically the highest-scrutiny criterion. Controls restricting who can access systems and data.

### Identity and Authentication (Okta-specific)
- [ ] **Okta SSO** is the primary authentication mechanism for all major applications (AWS console, GitHub, internal tools)
- [ ] **MFA enforced** for all users in Okta — no exceptions for production access
- [ ] **Phishing-resistant MFA** (FIDO2/WebAuthn) enforced for privileged accounts where possible
- [ ] **Password policy** enforced via Okta: minimum length, complexity, rotation for service accounts
- [ ] **Session timeout** configured in Okta (idle session limits enforced)

### Access Provisioning
- [ ] **Formal provisioning process** — access requires a request, approval, and ticket (Jira, ServiceNow, etc.)
- [ ] **Role-based access control (RBAC)** defined in AWS (IAM roles), GitHub (teams/permissions), and Okta (groups)
- [ ] **Least privilege** enforced — no admin-by-default; production access is restricted and justified
- [ ] **Privileged access** (AWS root, admin roles) requires separate approval and is documented

### Access Reviews
- [ ] **Quarterly access reviews** conducted for all production systems — results documented and acted upon
- [ ] Access review sign-offs retained as evidence
- [ ] Stale/unused accounts identified and removed

### Offboarding
- [ ] **Offboarding procedure** ensures Okta account disabled within defined SLA (same day for terminations)
- [ ] Offboarding checklist covers: Okta disable, AWS key revocation, GitHub removal, shared credential rotation
- [ ] Offboarding completion is verified and documented

### AWS-Specific
- [ ] **AWS root account** is not used for day-to-day operations; MFA enabled on root
- [ ] **IAM roles** used for EC2/Lambda instead of long-lived access keys
- [ ] **AWS Organizations / SCPs** (Service Control Policies) used to enforce guardrails
- [ ] **AWS CloudTrail** enabled in all regions for API activity logging
- [ ] **AWS Config** enabled for configuration compliance monitoring
- [ ] **No hardcoded credentials** in code — verified via GitHub secret scanning

### GitHub-Specific
- [ ] **MFA required** for all GitHub organization members (enforced at org level)
- [ ] **Branch protection rules** on main/production branches (require PR review, status checks)
- [ ] **GitHub secret scanning** enabled to detect accidental credential commits
- [ ] External collaborator access reviewed quarterly

### Physical Access
- [ ] If you have an office: server rooms / network equipment locked; access logged
- [ ] AWS handles physical datacenter security (covered by AWS's SOC 2 report — document this as a Complementary User Entity Control)

*Evidence: Okta admin reports (user list, MFA enrollment), AWS IAM exports, GitHub org member list, access review completion records, offboarding tickets.*

---

## CC7 — System Operations (Monitoring, Incident Response, DR)

Controls for detecting and responding to threats and operational issues.

### Logging and Monitoring
- [ ] **Centralized logging** — AWS CloudTrail, VPC Flow Logs, and application logs aggregated (CloudWatch, Datadog, Splunk, etc.)
- [ ] **Security alerting** — alerts configured for anomalous activity (failed logins, privilege escalation, unusual API calls)
- [ ] **Vulnerability scanning** conducted regularly (at minimum quarterly; weekly preferred) using a tool like AWS Inspector, Tenable, or Snyk
- [ ] **SIEM or log management** in place with alert rules reviewed periodically

### Incident Response
- [ ] **Incident Response Plan (IRP)** documented and approved
- [ ] IRP covers: detection, containment, eradication, recovery, post-incident review
- [ ] **Incident severity classification** defined
- [ ] IRP has been **tested** (tabletop exercise at minimum annually)
- [ ] **Incident log** maintained (even a simple ticket/Jira record) for all security events
- [ ] Post-incident reviews documented for significant events

### Patch and Vulnerability Management
- [ ] **Vulnerability management policy** defines SLAs by severity (e.g., critical: 7 days, high: 30 days)
- [ ] Patch compliance tracked and reported
- [ ] **Dependency scanning** in GitHub Actions/CI pipeline (Dependabot, Snyk, etc.)

### Business Continuity / Disaster Recovery
- [ ] **DR/BCP plan** documented covering key system failure scenarios
- [ ] **RTO and RPO** defined for critical services
- [ ] **Backup procedures** documented; backups tested for restorability
- [ ] DR plan tested at least annually (tabletop or functional test)

*Evidence: SIEM dashboards, vulnerability scan reports with remediation tracking, incident tickets, IRP document, DR test results, backup restore records.*

---

## CC8 — Change Management

Controls ensuring changes to systems are authorized, tested, and reviewed.

- [ ] **Change management policy** documented with categories (standard, normal, emergency)
- [ ] **All code changes** go through GitHub pull requests with at least one reviewer (no direct pushes to main)
- [ ] **CI/CD pipeline** includes automated testing (unit tests, security scans) before deployment
- [ ] **Production deployments** require approval (branch protection + required PR approvals enforced in GitHub)
- [ ] **Emergency change process** defined for urgent fixes (with post-hoc approval documented)
- [ ] **Infrastructure as Code (IaC)** changes (Terraform, CloudFormation) treated as code changes and reviewed
- [ ] Change records are retained (GitHub PR history, deployment logs in CI/CD tool)
- [ ] **Rollback procedures** documented and tested

*Evidence: GitHub PR history showing approvals, CI/CD pipeline run logs, deployment records, change policy document.*

---

## CC9 — Risk Mitigation (Vendor and Third-Party Risk)

Controls for managing risks from vendors and business partners.

- [ ] **Vendor inventory** maintained listing all critical vendors (AWS, GitHub, Okta, plus any others processing customer data)
- [ ] **Vendor risk tiering** in place (critical, high, medium, low based on data access and operational dependency)
- [ ] **AWS, GitHub, Okta SOC 2 reports** reviewed annually — results documented
- [ ] **Complementary User Entity Controls (CUECs)** from vendor SOC 2 reports identified and implemented
- [ ] **Security requirements in contracts** — vendor agreements include security, data handling, and breach notification clauses
- [ ] **Pre-onboarding due diligence** for new critical vendors (security questionnaire or SOC 2 review before signing)
- [ ] **Vendor management policy** documented

*Evidence: Vendor inventory spreadsheet, downloaded SOC 2 reports from AWS/GitHub/Okta, vendor contract security clauses, CUEC implementation log.*

---

## Summary: Quick Priority Stack Rank

If you are just starting, prioritize in this order:

1. **CC6 — Access controls** (MFA, provisioning, offboarding, access reviews) — most heavily tested
2. **CC7 — Incident response + monitoring** — auditors will ask for evidence of real incidents handled
3. **CC1 — Policies** — everything needs a policy backing it
4. **CC8 — Change management** — GitHub PR process is straightforward for a dev team
5. **CC3 — Risk assessment** — do this once annually with documented sign-off
6. **CC9 — Vendor risk** — pull AWS/GitHub/Okta SOC 2 reports and log the reviews
7. **CC2, CC4, CC5** — support and monitor the above; often satisfied by documenting what you already do

---

*Note: This checklist covers the Security Common Criteria only. If your scope includes Availability (A1), Confidentiality (C1), or other criteria, additional controls are required. All controls must be tailored to your specific system — SOC 2 prescribes criteria, not specific technical implementations.*

# SOC 2 Security Controls Checklist
## Cloud-Native Company on AWS, GitHub, and Okta

SOC 2's Security category is the foundation of every SOC 2 report — it's always required. Here's a practical checklist of controls you need, organized by area, with notes on how AWS, GitHub, and Okta apply.

---

## Identity and Access Management

The most scrutinized area in any SOC 2 audit.

- [ ] **MFA enforced for all users** — use Okta to enforce MFA across all applications; no exceptions for production access
- [ ] **Single Sign-On (SSO)** via Okta for all major applications including AWS console and GitHub
- [ ] **Least privilege access** — users should have only the permissions they need; no admin-by-default
- [ ] **Role-based access control** — define roles in AWS IAM, GitHub teams, and Okta groups
- [ ] **Access provisioning process** — documented procedure for requesting and approving access
- [ ] **Offboarding procedure** — Okta account disabled on the day of termination; checklist covers all systems
- [ ] **Quarterly access reviews** — review who has access to production systems; document results
- [ ] **Privileged access controls** — AWS root account secured with MFA and not used for daily operations
- [ ] **No long-lived access keys** — use IAM roles rather than static access keys in AWS
- [ ] **No secrets in code** — GitHub secret scanning enabled; pre-commit hooks to catch credentials

---

## System Monitoring and Logging

- [ ] **Centralized logging** — CloudTrail for AWS API activity, application logs aggregated to a central system
- [ ] **Security alerting** — automated alerts for suspicious activity (failed logins, privilege escalation attempts)
- [ ] **Log retention** — logs retained for at least one year (common auditor requirement)
- [ ] **Vulnerability scanning** — regular scanning of infrastructure and dependencies (AWS Inspector, Snyk, etc.)
- [ ] **Dependency scanning in CI/CD** — Dependabot or similar tool scanning GitHub repos for vulnerable dependencies

---

## Incident Response

- [ ] **Incident Response Plan (IRP)** — written document covering detection, containment, recovery, and post-incident review
- [ ] **Incident severity levels** — defined (e.g., critical, high, medium, low) with different response timelines
- [ ] **Incident log** — all security incidents tracked in a ticketing system
- [ ] **Annual tabletop exercise** — documented test of the IRP; results recorded
- [ ] **Breach notification procedure** — documented process for notifying customers if their data is affected

---

## Change Management

- [ ] **Pull request reviews required** — GitHub branch protection enforcing PR approvals before merging
- [ ] **No direct pushes to main** — branch protection rules in place
- [ ] **CI/CD pipeline with automated tests** — security scans and tests run before deployment
- [ ] **Change approvals documented** — PR history serves as the change log; ensure approvals are visible
- [ ] **Infrastructure changes tracked** — Terraform/CloudFormation changes go through the same review process
- [ ] **Emergency change process** — documented procedure for urgent fixes with post-hoc review

---

## Risk Assessment

- [ ] **Annual risk assessment** — formal documented assessment covering your system and data; approved by leadership
- [ ] **Risk register** — list of identified risks with severity ratings and assigned owners
- [ ] **Risk treatment** — each risk has a documented decision (mitigate, accept, transfer, avoid)

---

## Policies and Documentation

- [ ] **Information Security Policy** — top-level policy covering overall security commitment
- [ ] **Access Control Policy** — documents how access is granted, reviewed, and revoked
- [ ] **Incident Response Policy** — references or includes the IRP
- [ ] **Acceptable Use Policy** — governs how employees use company systems
- [ ] **Change Management Policy** — documents the change control process
- [ ] **Vendor Management Policy** — covers how you assess and monitor third parties
- [ ] **Password/Authentication Policy** — documents MFA requirements, session management
- [ ] All policies reviewed and approved annually, with signatures or approval records

---

## Vendor and Third-Party Risk

- [ ] **Vendor inventory** — list of all vendors with access to your systems or customer data
- [ ] **Review vendor SOC 2 reports** — AWS, GitHub, and Okta all publish SOC 2 reports; download and review them annually
- [ ] **Security requirements in contracts** — vendor agreements include security and data handling terms
- [ ] **Pre-onboarding review** — basic security check before adding a new critical vendor

---

## Physical and Environmental

For a cloud-native company, your physical security story is mostly inherited from AWS:
- [ ] **AWS shared responsibility model** documented — you rely on AWS for physical datacenter security
- [ ] **Office physical security** — if you have an office with servers or sensitive equipment, access controls in place
- [ ] **Clean desk / screen lock policy** — documented and communicated to employees

---

## Employee Security

- [ ] **Security awareness training** — all employees trained at hire and annually; completion tracked
- [ ] **Background checks** for employees with access to production systems or sensitive data
- [ ] **Security responsibilities in job descriptions** for roles with elevated access

---

## Evidence You Need to Collect

Auditors will sample across your audit period. For each area above, you need:

- **Access controls:** User lists from Okta, AWS IAM exports, GitHub org reports, access review sign-offs, offboarding tickets
- **Change management:** PR history with approvals, deployment logs
- **Monitoring:** Alert configuration screenshots, sample alerts that fired, vulnerability scan reports
- **Incident response:** IRP document, tabletop exercise notes, sample incident tickets
- **Risk assessment:** Risk register with approval signature and date
- **Vendor management:** Vendor inventory, copies of vendor SOC 2 reports with review notes
- **Policies:** Policy documents with version history, approval, and employee acknowledgment records

---

## Quick Wins for a Cloud-Native Team

If you're just getting started, these give you the most coverage for the effort:

1. Enforce MFA for everything in Okta — immediate impact on CC6
2. Enable GitHub branch protection with required reviews — covers change management
3. Enable CloudTrail in all AWS regions — foundational for monitoring
4. Schedule and run a quarterly access review — document it
5. Write your five core policies (InfoSec, Access Control, IR, Acceptable Use, Change Management)
6. Download AWS, GitHub, and Okta SOC 2 reports and log the review

These six actions alone close a large portion of the gaps auditors commonly flag.

# Adding Availability (A1) to Your SOC 2 Report

## Overview

The **Availability** Trust Services Criterion sits under the **A-series** (specifically **A1**) in the AICPA 2017 Trust Services Criteria. Unlike the Security Common Criteria (CC1–CC9), which are always required, Availability is an **optional, additive criterion** — but when a customer requests it, you must demonstrate controls specifically focused on system uptime, performance, and recovery.

Adding Availability to your scope does **not** replace or reduce Security requirements. It extends your report with an additional set of controls and commitments layered on top of everything you already do for CC1–CC9.

---

## What A1 (Availability) Actually Requires

The Availability criterion is organized around **A1.1, A1.2, and A1.3**:

### A1.1 — Current Processing Capacity
The entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demands.

**What this means in practice:**
- You must monitor resource utilization (CPU, memory, storage, network throughput) on your production systems
- You must have processes to detect when capacity is approaching limits and respond proactively
- Capacity planning is documented and reviewed (at minimum annually, or when significant changes occur)

**Specific controls needed:**
- [ ] **Infrastructure monitoring** with capacity dashboards (AWS CloudWatch, Datadog, etc.)
- [ ] **Alerting on capacity thresholds** — alerts fire before systems reach saturation
- [ ] **Capacity planning documentation** — annual or change-driven review of expected load vs. available capacity
- [ ] **Auto-scaling configurations** documented and tested (AWS Auto Scaling Groups, ECS capacity providers, etc.)
- [ ] **Performance baselines** established and documented

### A1.2 — Environmental Threats and Recovery
The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protection, software, data back-up and recovery, and other policies, procedures, and tools to prevent, detect, and recover from natural disasters, environmental hazards, and other threats.

**What this means in practice:**
- Documented Disaster Recovery (DR) and Business Continuity Plan (BCP)
- Defined RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for each critical service
- Backup procedures with tested restorability
- Tested recovery procedures

**Specific controls needed:**
- [ ] **Disaster Recovery Plan (DRP)** documented and approved — covers key failure scenarios
- [ ] **RTO and RPO defined** for all in-scope services (e.g., RTO: 4 hours, RPO: 1 hour)
- [ ] **Backup procedures** documented — what is backed up, how often, where, and retention period
- [ ] **Backup restoration tested** at least annually — test results documented
- [ ] **Multi-AZ or multi-region architecture** documented (demonstrates resilience by design)
- [ ] **DR test results** documented showing the system can actually recover within stated RTO/RPO
- [ ] **Runbooks for common failure scenarios** (database failure, application server failure, dependency outage)

### A1.3 — Recovery Plan Testing
The entity tests recovery plan procedures supporting system availability to address identified threats against the availability commitments.

**What this means in practice:**
- The DR/BCP plan is not just written — it has been exercised
- Testing results are documented and gaps are remediated
- Testing frequency matches risk level (at minimum annual)

**Specific controls needed:**
- [ ] **Annual DR test** conducted — can be tabletop, functional (failover test), or full DR simulation
- [ ] **Test results documented** including: date, participants, scenarios tested, outcomes, findings
- [ ] **Remediation of test findings** tracked and resolved
- [ ] **Uptime/availability reporting** — evidence of actual uptime metrics over the audit period

---

## How Availability Differs from Security (CC)

This is a critical distinction:

| Dimension | Security (CC1–CC9) | Availability (A1) |
|---|---|---|
| **Primary focus** | Protecting the system from threats | Ensuring the system is operational when promised |
| **Key questions** | Who can access what? Are threats detected? | Is the system up? Can it recover? What's the SLA? |
| **Core controls** | Access management, incident response, change management | Capacity monitoring, DR/BCP, backup, uptime metrics |
| **Overlap** | CC7 includes incident response and some DR elements | A1 goes deeper on recovery objectives, capacity, and SLA evidence |
| **Customer concern** | "Is my data safe?" | "Will your service be there when I need it?" |
| **Evidence type** | Access logs, IR tickets, change records | Uptime reports, backup restore tests, DR test results, SLA compliance data |

**Important nuance:** CC7 (System Operations) in the Security criteria covers incident response and some DR topics. When you add Availability, auditors expect more rigor and specificity:
- CC7 asks: "Do you have an incident response process?"
- A1 asks: "What are your specific uptime commitments, how do you measure them, and can you prove you met them?"

---

## New Commitments You Must Make

When you include Availability, your audit report will describe your **System Description** — a section where you formally state your availability commitments and system requirements. This typically includes:

1. **Uptime targets** — e.g., "99.9% availability measured monthly, excluding scheduled maintenance"
2. **Scheduled maintenance windows** — documented and communicated to customers
3. **Notification procedures** — how you communicate unplanned downtime to customers
4. **Monitoring approach** — how you detect and measure availability
5. **Recovery objectives** — stated RTO and RPO

**Warning:** Whatever you commit to in the System Description, auditors will test. If you say "99.9% uptime" but your monitoring shows multiple outages exceeding that, it will be flagged. Be accurate and realistic in your commitments.

---

## Additional Policies Required for A1

Beyond the full Security policy set (CC1–CC9), Availability scope requires:

| Policy / Document | Criteria Addressed |
|---|---|
| **Business Continuity & Disaster Recovery Policy** | A1, CC7 |
| **System Availability Statement** (in System Description) | A1.1 |
| **Incident Communication Policy** (for availability incidents) | A1, CC2 |
| **Backup and Recovery Procedures** | A1.2 |

Your **DR/BCP policy** must specifically define:
- Scope of covered systems
- RTO and RPO targets
- Roles and responsibilities during an incident
- Recovery procedures
- Test requirements and cadence

---

## Evidence Required for A1 (Audit Period)

For a Type 2 audit covering Availability, you need:

| Evidence Item | Purpose |
|---|---|
| Uptime/availability dashboards or reports (e.g., monthly exports from your monitoring tool) | Proves A1.1 — capacity monitored; demonstrates you met stated availability commitments |
| Capacity utilization reports | Proves A1.1 — capacity monitoring in operation |
| Auto-scaling configurations | Proves A1.1 — capacity demand management |
| Backup configuration screenshots + backup logs | Proves A1.2 — backups running as designed |
| Backup restoration test record (date, system, result) | Proves A1.2 — restorability tested |
| DR plan document with approval signature and version date | Proves A1.2, A1.3 — plan exists and is maintained |
| DR test report (date, scenario, participants, outcome) | Proves A1.3 — plan has been tested |
| Incident records for any availability incidents during the audit period | Supports A1 review — shows how incidents were handled |
| RTO/RPO documented and signed off | Supports A1.2 — objectives are defined |

---

## Scoping Decision: Should You Add Availability?

Consider adding Availability if:
- Your customer's request specifically mentions availability or uptime SLAs
- You have an SLA in your customer contracts and the customer wants audit evidence
- Downtime would cause significant harm to your customers (financial services, healthcare, etc.)
- You already have mature monitoring and DR capabilities

Consider deferring Availability if:
- Your initial SOC 2 is already a significant lift and Availability adds material scope
- Your customer only needs Security coverage
- Your DR/backup processes are not yet mature enough to withstand scrutiny

Most first-time SOC 2 reports are **Security-only**. Adding Availability on a first audit is feasible but substantially increases the evidence collection burden, particularly around DR testing and uptime reporting over the full audit period.

---

## Summary

| | Security Only (CC1–CC9) | Security + Availability (CC1–CC9 + A1) |
|---|---|---|
| Additional controls | — | Capacity monitoring, DR/BCP, backup restore testing, DR testing |
| Additional policies | — | DR/BCP Policy, Availability Statement |
| Key new evidence | — | Uptime reports, DR test results, backup restore records, capacity dashboards |
| Additional commitments | — | Stated RTO/RPO, uptime targets, maintenance window definitions |
| Audit complexity | Baseline | Moderate increase — particularly around DR testing and uptime evidence |

# Adding Availability to Your SOC 2 Report

## What the Availability Criterion Covers

SOC 2's **Availability** category is one of five Trust Services Criteria. While Security is always required, Availability is optional — you add it when customers or contracts require you to demonstrate controls around system uptime and recovery.

The Availability criterion addresses whether your system is available for operation and use as you've committed to your customers. It's fundamentally about uptime, capacity, and disaster recovery.

---

## What Availability Requires (That Security Doesn't)

Security-only SOC 2 focuses on protecting your system from threats. Availability asks a different question: "Can your system stay up, and can you recover when it goes down?"

### Uptime Monitoring and Commitments

When you add Availability, you must:

- **Define your availability commitments** — this goes into your System Description (the narrative section of your SOC 2 report). You need to state something like "99.9% uptime, measured monthly, excluding scheduled maintenance."
- **Actually measure and monitor uptime** — you need a monitoring tool and documented evidence of uptime metrics over the audit period
- **Alert on availability issues** — automated alerting when systems degrade or go down

Warning: Whatever uptime targets you put in the report, auditors will check whether you actually met them. Be accurate and realistic.

### Capacity Management

- Document current infrastructure capacity and utilization
- Monitor resource usage (CPU, memory, storage, bandwidth)
- Have a process for scaling when capacity limits are approached
- Document auto-scaling or capacity expansion procedures

### Disaster Recovery

This is the biggest addition. For Availability, you need:

- **Written DR/Business Continuity Plan** — covers what happens when key systems fail
- **Defined RTO (Recovery Time Objective)** — how quickly can you restore service?
- **Defined RPO (Recovery Point Objective)** — how much data can you afford to lose?
- **Backup procedures** — what is backed up, how often, where stored, how long retained
- **Tested backups** — you must actually verify backups can be restored; document this
- **Annual DR test** — run a test of your recovery procedures and document the results

### Scheduled Maintenance

- Document your maintenance window policy
- Have a process for notifying customers of planned downtime

---

## How It Differs from Security-Only

**Security asks:** Are you protecting your systems and data from threats?
**Availability asks:** Is your system up and running as promised, and can you recover from failures?

There's some overlap — your Security criteria already requires you to have an incident response plan and some monitoring. But Availability takes this further:

- Security's monitoring is about detecting threats
- Availability's monitoring is about measuring uptime and capacity
- Security's incident response is about handling breaches
- Availability's DR/BCP is specifically about restoring service after any type of failure

The main new controls Availability adds are:
1. Uptime SLA monitoring and reporting
2. Capacity planning and monitoring
3. Formal DR/BCP documentation with tested recovery procedures
4. Backup restoration testing (just having backups isn't enough)
5. Documented RTO and RPO targets

---

## New Policies You'll Need

On top of your Security policy set, add:

- **Business Continuity and Disaster Recovery Policy** — the most important addition
- **Backup and Recovery Procedures** — detailed operational procedures
- Update your **Incident Response Policy** to cover availability incidents and customer communication

---

## Evidence Auditors Will Ask For

For a Type 2 report with Availability in scope, collect:

- Uptime/availability reports from your monitoring tool for each month of the audit period
- Capacity dashboards or reports showing utilization trends
- DR/BCP plan document with approval date
- DR test report — date, scope, participants, findings, and whether RTO/RPO were met
- Backup configuration and backup logs showing backups ran
- Backup restoration test record (what was restored, when, did it work)
- Any incidents during the audit period and how they were handled

---

## Should You Add Availability?

**Good reasons to add it:**
- Your customer specifically requested it
- You have SLAs in your contracts and want audit evidence to back them up
- You already have solid monitoring and a tested DR plan

**Reasons to defer it:**
- Your first SOC 2 is already a major project; Security alone is substantial
- Your DR and backup practices aren't yet mature enough to withstand scrutiny
- Your customer hasn't specifically required it

Many first-time SOC 2 organizations start with Security-only. Adding Availability on the second or third cycle is common. That said, if your DR and monitoring practices are already solid, adding Availability is not dramatically more work — the main lift is the DR test documentation and monthly uptime reporting.

---

## Practical Next Steps if Adding Availability

1. Define your uptime SLA targets and document them
2. Set up or confirm uptime monitoring with reportable metrics (Datadog, Pingdom, etc.)
3. Write or update your DR/BCP plan with defined RTO/RPO
4. Test your backups — restore something and document it
5. Schedule an annual DR tabletop or functional test before your audit window ends
6. Build capacity dashboards and export monthly reports for the audit period

# Access Control Policy

| | |
|---|---|
| **Document Title** | Access Control Policy |
| **Policy ID** | POL-AC-001 |
| **Version** | 1.0 |
| **Effective Date** | [DATE] |
| **Last Reviewed** | [DATE] |
| **Next Review Date** | [DATE + 1 year] |
| **Policy Owner** | Chief Information Security Officer (CISO) / Head of Security |
| **Approved By** | [CEO / CTO Name, Title] |
| **TSC Criteria Addressed** | CC6.1, CC6.2, CC6.3, CC6.6, CC6.7, CC6.8 |

---

## 1. Purpose

This policy establishes requirements for managing logical access to [Company Name]'s information systems, applications, cloud infrastructure, and data. The objective is to ensure that access to systems and data is granted only to authorized individuals, based on business need, and is revoked promptly when no longer required — thereby protecting the confidentiality, integrity, and availability of company and customer information.

This policy supports compliance with the AICPA Trust Services Criteria for Security, specifically Common Criteria CC6 (Logical and Physical Access Controls).

---

## 2. Scope

This policy applies to:

- **All employees, contractors, consultants, and temporary workers** of [Company Name]
- **All information systems, applications, and cloud infrastructure** owned, operated, or managed by [Company Name]
- **Third-party vendors** with access to [Company Name] systems or customer data (subject to Vendor Management Policy)
- **All environments:** production, staging, development, and corporate systems

This policy specifically covers access to:
- Identity provider: Okta (SSO and MFA)
- Cloud infrastructure: AWS accounts and services
- Source code: GitHub organization
- Internal applications, SaaS tools, and databases integrated with Okta

---

## 3. Roles and Responsibilities

| Role | Responsibility |
|---|---|
| **CISO / Head of Security** | Policy owner; approves exceptions; oversees access review process |
| **IT/Security Team** | Administers Okta, IAM, and GitHub access; executes provisioning and deprovisioning |
| **People/HR Team** | Initiates onboarding and offboarding requests; communicates termination events |
| **Managers / Team Leads** | Approve access requests for their team members; participate in access reviews |
| **All Employees** | Adhere to this policy; report unauthorized access or suspected compromise |

---

## 4. Access Management Principles

### 4.1 Least Privilege

Access to systems, applications, and data is granted based on the **principle of least privilege** — users receive only the minimum access necessary to perform their job function. Broad or administrative permissions are not granted by default and require additional justification and approval.

*This satisfies CC6.3.*

### 4.2 Need-to-Know

Access to sensitive or confidential data is limited to individuals who have a documented business need. Access to customer data is restricted to personnel whose job functions require it (e.g., customer support, engineering on-call).

### 4.3 Separation of Duties

Where feasible, duties are separated to prevent any single individual from having unchecked control over critical functions. Examples include:
- Engineers cannot both write and approve their own production code changes
- Finance approvals and payment execution are separated

### 4.4 Unique Accounts

All users must have a unique, individual account. Shared accounts are prohibited except for documented service accounts, which must be approved by the Security team and have a designated owner.

---

## 5. Identity and Authentication

### 5.1 Single Sign-On (SSO)

Okta is the authoritative identity provider for [Company Name]. All employees must authenticate to company applications through Okta SSO. Direct (non-SSO) credentials to applications are prohibited unless technically unavoidable and documented as an exception.

*This satisfies CC6.1, CC6.6.*

### 5.2 Multi-Factor Authentication (MFA)

MFA is **mandatory** for all users. MFA is enforced at the Okta level and applies to all Okta-integrated applications, including AWS and GitHub.

- Employees must enroll in MFA within 24 hours of account creation
- Phishing-resistant MFA (FIDO2/WebAuthn, hardware keys) is required for privileged accounts (Okta admin, AWS admin, GitHub org admin)
- SMS-based MFA is not approved for privileged access
- MFA cannot be bypassed or self-removed without Security team approval

*This satisfies CC6.1, CC6.6.*

### 5.3 Password Requirements

Where passwords are used:
- Minimum length: 14 characters
- Complexity: Must include uppercase, lowercase, number, and special character
- Passwords must not be reused (minimum 12-password history)
- Passwords must not be shared with others
- Service account passwords must be stored in the company-approved secrets manager (e.g., AWS Secrets Manager, 1Password)

### 5.4 Session Management

- Idle session timeout: 60 minutes for standard sessions; 15 minutes for sessions with access to sensitive data
- Session timeouts are enforced via Okta policy
- Users must lock their screen when leaving a workstation unattended

---

## 6. Access Provisioning

### 6.1 Onboarding and New Access Requests

Access is provisioned through a formal request and approval process:

1. **Request submission:** New hire access is initiated by the HR/People team via [ticketing system, e.g., Jira] as part of the onboarding workflow. Additional access for existing employees requires a request ticket submitted to the IT/Security team.
2. **Manager approval:** The employee's direct manager must approve the access request in the ticketing system before provisioning begins.
3. **Security team review:** Requests for privileged access (admin rights, production database access, security tool access) require additional approval from the CISO or Security team lead.
4. **Provisioning:** The IT/Security team provisions access via Okta (groups and application assignments), GitHub (team membership), and AWS (IAM role assignment).
5. **Documentation:** All provisioning actions are recorded in the ticketing system and retained for audit purposes.

Standard provisioning SLA: within 1 business day of approval.

*This satisfies CC6.1, CC6.2.*

### 6.2 Privileged Access

Privileged access (administrative access to Okta, AWS root/admin roles, GitHub organization admin) is granted only when operationally necessary and must be:

- Justified and approved by the CISO
- Limited in duration (time-boxed) where possible
- Subject to enhanced MFA requirements (FIDO2/hardware key)
- Reviewed monthly as part of privileged access reviews

AWS root credentials are secured with MFA and are not used for day-to-day operations. Root credentials are stored in a sealed envelope or equivalent and accessed only in documented break-glass scenarios.

### 6.3 Service Accounts and API Keys

- All service accounts must have a documented owner and business purpose
- Service account credentials (API keys, tokens, certificates) must be stored in approved secrets management tools (AWS Secrets Manager, Secrets management in CI/CD pipeline)
- Hardcoded credentials in source code are prohibited; GitHub secret scanning is enabled to detect violations
- Service account credentials must be rotated at least annually, or immediately upon suspected compromise

*This satisfies CC6.6.*

---

## 7. Access Reviews

### 7.1 Quarterly User Access Reviews

The Security team conducts **quarterly access reviews** for all production and sensitive systems. Reviews cover:

- All user accounts with access to AWS production accounts
- All user accounts in the GitHub organization with write or admin access
- All Okta application assignments with access to sensitive applications

**Review process:**
1. Security team exports user access lists from Okta, AWS, and GitHub
2. Reports are distributed to relevant managers for review
3. Managers confirm or deny that each user still requires the access listed
4. Unnecessary access is removed by the Security team within 5 business days of identification
5. Review results (including the signed-off access list and any changes made) are retained as audit evidence

*This satisfies CC6.3.*

### 7.2 Privileged Access Reviews

Privileged accounts (Okta admin, AWS admin, GitHub org admin) are reviewed **monthly**. Any accounts with unnecessary elevated permissions are downgraded immediately.

### 7.3 Annual Access Review

A comprehensive access review of all systems (including systems not covered by the quarterly review) is conducted annually.

---

## 8. Access Revocation and Offboarding

### 8.1 Involuntary Terminations

For involuntary terminations (layoffs, terminations for cause):

- HR must notify the IT/Security team **immediately** — before or concurrent with the employee notification
- Okta account must be **disabled within 2 hours** of notification
- Disabling the Okta account cascades to all Okta-integrated applications (AWS SSO, GitHub, internal tools)
- Any non-SSO accounts, API keys, or credentials held by the employee are revoked on the same day

### 8.2 Voluntary Resignations

For voluntary resignations, the offboarding procedure is initiated on the employee's last day:

- Okta account disabled at the end of the last business day
- GitHub organization membership removed
- AWS IAM user (if any) deleted or disabled
- Shared credentials or passwords the employee may have known are rotated
- Offboarding completion confirmed and documented in an offboarding checklist ticket

### 8.3 Role Changes (Transfers)

When an employee changes roles, their access is reviewed within 5 business days of the role change. Access no longer appropriate for the new role is removed. Access rights are not automatically accumulated — a transfer triggers a fresh access grant based on the new role's requirements.

### 8.4 Offboarding Checklist

Every offboarding generates a ticket that tracks:
- [ ] Okta account disabled
- [ ] GitHub organization membership removed
- [ ] AWS IAM user/role assignments reviewed
- [ ] Shared credentials rotated (list applicable)
- [ ] Equipment return confirmed (IT)
- [ ] Offboarding ticket closed and retained

*This satisfies CC6.2, CC6.3.*

---

## 9. Remote Access

- Remote access to company systems is secured through Okta-enforced MFA
- VPN (if applicable) or zero-trust network access (ZTNA) is required for access to internal systems not exposed via public endpoints
- Remote work does not change any access control requirements in this policy
- Employees must not access company systems from devices that are not enrolled in or compliant with the Mobile Device Management (MDM) policy

---

## 10. Physical Access

While [Company Name] is a cloud-native company and does not operate its own data centers, physical access to company offices must be controlled:

- Office access is managed through [access control system, e.g., key fobs, Kisi]
- Visitor access to areas where sensitive work occurs requires an employee escort
- Clear desk and screen lock practices are required for employees working with customer or sensitive data

AWS manages all physical access controls for cloud infrastructure — this is covered by AWS's own SOC 2 report, which [Company Name] reviews annually as a Complementary User Entity Control (CUEC) responsibility.

---

## 11. Exceptions

Any deviation from this policy requires:

1. A written exception request submitted to the CISO
2. Documentation of the business justification, compensating controls, and duration
3. Approval by the CISO
4. Logging of the exception in the exception register with scheduled review date

Exceptions are reviewed at least quarterly. Exceptions that are not renewed expire automatically.

---

## 12. Violations

Violations of this policy may result in disciplinary action, up to and including termination, and may expose [Company Name] to legal and regulatory risk. Suspected violations must be reported to the Security team or through the company's incident reporting channel.

---

## 13. Policy Review

This policy is reviewed and updated:
- **Annually** by the Policy Owner
- **Upon significant organizational or technology changes** (e.g., new identity provider, major access model changes)
- **Following any access-related security incidents**

---

## 14. References and Related Documents

| Document | Location |
|---|---|
| Information Security Policy | [Link] |
| Acceptable Use Policy | [Link] |
| Vendor Management Policy | [Link] |
| Incident Response Policy | [Link] |
| Change Management Policy | [Link] |
| Okta Access Administration Procedure | [Link] |
| AWS IAM Standards | [Link] |
| Offboarding Checklist Template | [Link] |

---

## 15. Version History

| Version | Date | Author | Change Description |
|---|---|---|---|
| 1.0 | [DATE] | [Author] | Initial version |

---

*This policy was written to satisfy AICPA Trust Services Criteria CC6.1 (logical access security software, infrastructure, and architectures), CC6.2 (prior to issuing system credentials), CC6.3 (role-based access control), CC6.6 (logical access security measures to protect against threats from sources outside its system boundaries), CC6.7 (transmission of data), and CC6.8 (unauthorized or malicious software).*

# Access Control Policy

**Company:** [Company Name]
**Version:** 1.0
**Effective Date:** [Date]
**Reviewed By:** [Name, Title]
**Approved By:** [CEO/CTO Name]
**Next Review Date:** [Date + 1 year]
**Policy Owner:** Head of Security / IT

---

## 1. Purpose

This Access Control Policy establishes requirements for managing access to [Company Name]'s systems, applications, and data. The goal is to ensure that access is granted only to authorized individuals based on their job requirements, and that access is removed promptly when it is no longer needed.

This policy applies to all employees, contractors, and third parties who access company systems.

---

## 2. Scope

This policy covers:
- All company systems, applications, and data
- Cloud infrastructure (production and non-production)
- Code repositories and development tools
- Identity and access management systems
- Corporate SaaS applications

All employees, contractors, and vendors with access to company systems are subject to this policy.

---

## 3. Core Principles

**Least Privilege:** Users are granted the minimum level of access required to perform their job duties. No user should have broader access than their role requires.

**Need-to-Know:** Access to sensitive data is limited to those who have a legitimate business need.

**Individual Accountability:** All users must have unique individual accounts. Shared accounts are not permitted unless approved as a service account with a designated owner.

**Separation of Duties:** Where possible, critical functions are divided among multiple people so that no one person can complete a high-risk action unilaterally.

---

## 4. Authentication Requirements

### Multi-Factor Authentication (MFA)
MFA is required for all user accounts. This is enforced through Okta for all company applications. Employees must complete MFA enrollment within 24 hours of account creation.

### Single Sign-On (SSO)
Okta serves as the company's identity provider. Employees must use Okta SSO to access company applications. Bypassing SSO is not permitted without documented approval from the security team.

### Passwords
Where passwords are used:
- Minimum 12 characters
- Must include letters, numbers, and special characters
- Must not be reused (last 10 passwords)
- Must not be shared with anyone
- Service account passwords must be stored in an approved password manager or secrets vault

### Session Management
- Sessions automatically time out after 60 minutes of inactivity
- Employees must lock their screens when away from their workstations

---

## 5. Access Provisioning

### New Employee Access
1. HR initiates an access request when a new employee joins
2. The employee's manager approves the appropriate access level
3. IT/Security provisions access via Okta within one business day
4. The access request and approval are documented in the ticketing system

### Additional Access Requests
Existing employees who need additional access must:
1. Submit a ticket to IT/Security through the designated system
2. Get manager approval in the ticket
3. Receive provisioning from IT/Security upon approval

**Privileged Access** (admin roles, production database access, security tools) requires approval from the Head of Security in addition to manager approval.

---

## 6. Access Reviews

A quarterly access review is conducted to ensure users have only appropriate access:

- IT/Security exports user lists from Okta, AWS, and GitHub
- Managers review and confirm which users on their team still need each access
- Any unnecessary access is removed within 5 business days of the review
- Access review results are documented and retained

Privileged accounts are reviewed monthly.

---

## 7. Access Removal and Offboarding

### Terminations
**Involuntary terminations:** HR notifies IT/Security immediately. The Okta account is disabled within 2 hours, which cascades access removal to connected applications.

**Voluntary resignations:** The Okta account is disabled on the employee's last day of work.

### Offboarding Checklist
Every offboarding is tracked with a checklist ticket confirming:
- [ ] Okta account disabled
- [ ] GitHub access removed
- [ ] AWS access reviewed and removed
- [ ] Any shared passwords the employee knew have been rotated
- [ ] Offboarding ticket closed and filed

### Role Changes
When an employee moves to a new role, their access is reviewed and updated within 5 business days to reflect the new role's requirements. Old access is removed and new access is granted through the standard provisioning process.

---

## 8. Service Accounts and API Keys

- All service accounts must have a named owner and documented purpose
- Service account credentials must be stored in approved secrets management tools (not in code)
- API keys and tokens must be rotated at least annually
- Hardcoded credentials in source code are prohibited and are detected by automated scanning
- Service accounts must be reviewed quarterly along with user accounts

---

## 9. Remote Access

- Employees working remotely must use Okta-enforced MFA for all system access
- Company data must only be accessed from company-approved or MDM-enrolled devices
- Public Wi-Fi usage for sensitive work requires VPN or equivalent secure connection

---

## 10. Physical Access

For employees working in company offices:
- Sensitive areas (server rooms, areas with customer data visible) are access-controlled
- Visitors must be escorted in areas where sensitive work occurs
- Employees must follow clean desk practices and lock screens when away from their workstations

Cloud infrastructure physical security is managed by our cloud provider (AWS) and is covered by their own SOC 2 certification, which we review annually.

---

## 11. Violations

Anyone who violates this policy may face disciplinary action, up to and including termination of employment or contract. Suspected violations should be reported to the security team immediately.

---

## 12. Exceptions

Requests for exceptions to this policy must be submitted in writing to the Head of Security. Exceptions require:
- Clear business justification
- Description of compensating controls
- Defined expiration date
- Head of Security approval

All approved exceptions are logged and reviewed quarterly.

---

## 13. Policy Review

This policy is reviewed annually by the Policy Owner and updated as needed. It is also reviewed following significant security incidents or organizational changes that affect access management.

---

## Related Policies
- Information Security Policy
- Acceptable Use Policy
- Incident Response Policy
- Vendor Management Policy

---

*Version 1.0 — [Date]*

# Audit Exception Analysis: Terminated Employee Access Not Revoked for 45 Days

## How Serious Is This?

**Severity: High.** This is one of the most commonly cited and most heavily weighted exceptions in SOC 2 audits. A 45-day gap in access revocation is a significant finding — not a minor procedural lapse.

Here is why auditors treat this seriously:

1. **45 days is well beyond any reasonable remediation window.** Industry norms for involuntary terminations typically require revocation on the day of termination (same-day or same-hour). Even for voluntary resignations, the access should be revoked on the last day of employment. A 45-day gap suggests either a process failure or an absence of a functional offboarding control.

2. **Access risk is real, not hypothetical.** During those 45 days, the former employee could have accessed systems with credentials they no longer had authorization to use. This creates potential data exposure, IP theft risk, or sabotage risk — all of which are precisely the threats SOC 2 is designed to prevent.

3. **It is a Type 2 operating effectiveness failure**, not merely a design gap. If you have an offboarding policy (as most organizations do before audit), this exception demonstrates that the control *operated ineffectively* — which is the core thing a Type 2 audit tests.

---

## Which Trust Services Criteria Are Implicated

This exception implicates multiple CC criteria simultaneously:

### Primary: CC6.2 — Prior to Issuing System Credentials and Granting System Access
*"Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity."*

The inverse applies to offboarding: access must be de-registered and de-authorized when employment ends. Failing to revoke access within a reasonable timeframe is a direct failure of CC6.2.

### Primary: CC6.3 — Role-Based Access and Removal
*"The entity removes access to protected information assets when appropriate (e.g., as part of the entity's defined termination procedures)."*

This is the most directly applicable criterion. CC6.3 explicitly requires removal of access as part of termination procedures. A 45-day delay in removal is a clear operating exception against CC6.3.

### Secondary: CC1.4 — Demonstrates Commitment to Competence (Control Environment)
If the organization's offboarding procedures were not followed, it may suggest a broader cultural or management oversight issue that touches CC1 (Control Environment).

### Secondary: CC4.1 — Monitoring Controls
If the delayed revocation went undetected for 45 days without any monitoring alert or detective control flagging it, that is a secondary failure in CC4 (monitoring controls). A well-controlled environment would detect stale accounts through periodic access reviews.

### Tertiary: CC6.6 — Logical Access Security Measures
Retaining active credentials for a former employee constitutes a failure to maintain appropriate logical access security boundaries.

---

## Anatomy of the Control Failures

This exception typically represents **one or more of the following root causes:**

| Root Cause | Control Failure |
|---|---|
| HR did not notify IT/Security of the termination | Process gap — no formal offboarding trigger mechanism |
| IT/Security received the notification but did not act | Execution failure — process exists but was not followed |
| Offboarding checklist exists but access revocation step was missed | Checklist not fully completed or not enforced |
| Access review did not catch the stale account | CC4 detective control failure — quarterly access review was not performed or did not cover this account |
| No automated deprovisioning exists | Design gap — manual processes without automation are failure-prone |

The auditor will likely ask which of these caused the failure. Your management response should address the specific root cause.

---

## How Serious Is It for the Audit Report?

**This will appear in the report as an exception.** Under AICPA auditing standards for SOC 2 Type 2, when a control does not operate effectively during the audit period, the auditor notes it as an exception in the body of the report. This is visible to every user of the report — meaning your customers who request the report will see it.

The impact on the report depends on:
- **Frequency:** Was this a single isolated instance, or were there multiple employees with delayed revocation? A single exception is less damaging than a pattern.
- **Pervasiveness:** Did the control operate effectively the rest of the time? If 99 out of 100 offboardings were processed correctly and 1 was missed, that is different from a systemic failure.
- **Management response:** A strong, specific management response with credible remediation demonstrates maturity and limits customer concern.

---

## Writing the Management Response

The management response is your formal reply included in the SOC 2 report itself. Auditors give you the opportunity to respond to each exception. This response is read by customers, so it must be:

- **Factual and specific** (not defensive or vague)
- **Root-cause focused** (what actually went wrong)
- **Remediation-forward** (what you have done or committed to do)
- **Proportionate** (do not overstate or understate the risk)

### Sample Management Response

---

**Exception:** During the audit period, one instance was identified where a terminated employee's access credentials were not revoked until 45 days following the date of termination.

**Management Response:**

Management acknowledges this exception. Upon investigation, we determined that the root cause was a failure in the handoff between the People/HR team and the IT/Security team during the offboarding process. The termination event was not recorded in [ticketing system] in a timely manner, resulting in the IT/Security team not receiving the required offboarding notification.

We have confirmed that the affected account did not have privileged access and that no evidence of unauthorized access or data exfiltration was identified during the 45-day period.

**Remediation actions taken:**

1. **Process automation (implemented [DATE]):** We have integrated our HRIS system ([system name]) with Okta via automated deprovisioning. Termination events in the HRIS now automatically trigger account suspension in Okta within [timeframe] hours, eliminating reliance on manual notification.

2. **Offboarding procedure updated (implemented [DATE]):** The formal offboarding checklist has been updated to require IT/Security team confirmation of access revocation before the People team closes the offboarding ticket.

3. **Access review frequency increased:** We have increased the frequency of our privileged and production access reviews to monthly, which would detect any stale accounts not caught by the automated deprovisioning process.

4. **Manager education:** People managers have been reminded of their responsibility to initiate the offboarding ticket immediately upon learning of a departure.

Management believes these corrective actions have resolved the root cause of this exception. We are committed to ensuring consistent operation of our access revocation controls going forward.

---

*Signed: [CISO Name], [Date]*

---

## Guidance for Strengthening the Response

A strong management response has these qualities:

| Quality | What it looks like |
|---|---|
| **Specificity** | Names the root cause, the system involved, the specific employee role type |
| **Compensating context** | Notes that the account was not privileged, and that access logs were reviewed for unauthorized activity |
| **Concrete remediation** | Identifies specific systems changed, dates of implementation, not just "we will do better" |
| **Forward-looking control** | Includes a detective control (access review, automation alert) that would catch future failures |
| **No admission of broader failure** | Confirms this was an isolated instance, not a systemic pattern (if true) |

---

## Common Mistakes in Management Responses

- **Vague language:** "We have enhanced our offboarding process" — auditors and customers want specifics
- **Future tense only:** "We will implement automation" is less credible than "We implemented X on [date]"
- **Defensive tone:** Arguing that 45 days was acceptable, or blaming external factors without accepting accountability
- **Missing root cause:** Describing remediation without explaining what actually went wrong
- **Overpromising:** Committing to controls you cannot sustain

---

## Summary Assessment

| Dimension | Assessment |
|---|---|
| Severity | High — direct CC6.2 and CC6.3 operating failure |
| Visibility | Will appear in SOC 2 report read by customers |
| Reputational impact | Moderate — manageable with a strong response and demonstrated remediation |
| Regulatory risk | Low to moderate depending on industry; higher if the former employee had PII access |
| Recommended actions | Automate deprovisioning via Okta; improve HR-IT handoff; increase access review frequency |

# SOC 2 Audit Exception: Former Employee Access Not Revoked for 45 Days

## How Serious Is This?

This is a **significant finding** — not a minor paperwork issue. A 45-day window where a terminated employee retained system access is exactly the kind of control failure SOC 2 auditors focus on. Here's why it matters:

- **45 days is far too long.** Best practice for involuntary terminations is same-day or same-hour revocation. For voluntary resignations, the last day of employment is the target. 45 days means your controls either didn't trigger or weren't monitored.
- **It's a real security risk.** During that period, the former employee could theoretically have accessed company systems, customer data, or source code. Even if no misuse occurred, auditors treat the exposure as significant.
- **It undermines the core purpose of access control.** The whole point of access management in SOC 2 is to ensure only authorized people have access. A terminated employee is, by definition, no longer authorized.

Expect this to appear in the audit report as an exception to your access control controls. Enterprise customers reading your report will see it.

---

## What Control Failures Does It Represent?

This exception typically represents failures at multiple points:

### 1. Offboarding Process Failure
Your offboarding procedure either doesn't exist in a formal way, wasn't followed, or had a gap in the handoff between HR and IT. Most commonly, the IT team simply didn't get notified of the termination in a timely manner.

### 2. Access Control (Provisioning / Deprovisioning)
SOC 2 requires that access is removed promptly when someone's employment ends. A 45-day delay is a direct failure of this control, regardless of whether access was used.

### 3. Lack of Detective Controls
If no one caught the active account for 45 days, it suggests your periodic access reviews either weren't happening or didn't cover this account. Quarterly access reviews should catch stale accounts — this slipping through indicates a gap there too.

### 4. Process Gaps Between HR and IT
This type of failure almost always points to a handoff problem: HR knew the person was terminated, but IT didn't get notified. This is a process design gap.

---

## How Serious Is It for Your Report?

**It will appear in the report.** SOC 2 Type 2 reports document exceptions when controls don't operate effectively. This means customers who receive your report will see this finding.

The damage depends on:
- Was this the only exception of this type, or did multiple former employees retain access?
- What level of access did they have (admin vs. read-only)?
- Is there evidence the access was used during the 45-day window?
- How strong is your management response?

A single isolated exception with a credible management response is manageable. A pattern of similar exceptions is a much bigger problem.

---

## How to Write the Management Response

Your management response is your formal statement included in the SOC 2 report. This is what customers will read alongside the finding. It needs to be specific, honest, and forward-looking.

### Structure of a Strong Management Response

1. **Acknowledge the exception** — don't minimize it or be defensive
2. **State the root cause** — explain specifically what went wrong
3. **Describe what you found when you investigated** — e.g., confirm whether the account was accessed
4. **List specific remediation steps with dates** — be concrete, not vague
5. **Note preventive measures going forward** — show you've fixed the process

### Sample Management Response

---

**Exception:** One former employee's system access was not revoked until 45 days after the date of termination.

**Management's Response:**

Management acknowledges this exception. Upon investigation, we determined that the root cause was a manual notification gap between the HR/People team and IT/Security. The employee's departure was not communicated to the IT team through our standard offboarding ticket process, resulting in the delayed access revocation.

We reviewed system access logs for the 45-day period and found no evidence of unauthorized access or use of the former employee's credentials during this time. The affected account did not have administrative or privileged access.

**Remediation actions:**

1. **Automated deprovisioning (completed [DATE]):** We have implemented an automated integration between our HR system and Okta so that all terminations automatically trigger account suspension the same day, eliminating reliance on manual notification.

2. **Updated offboarding procedure (completed [DATE]):** We revised our offboarding checklist to require IT/Security confirmation of account closure before the HR team closes the offboarding record.

3. **Enhanced access reviews:** We have increased the frequency of our access reviews to monthly for production systems and implemented a quarterly automated report flagging any accounts belonging to individuals no longer in our HR system.

Management is confident these corrective actions address the root cause of this exception and will prevent recurrence.

*Signed: [CISO / Head of Security], [Date]*

---

## Tips for the Management Response

**Do:**
- Be specific about what changed and when it changed
- Reference concrete systems and dates where possible
- Acknowledge if the account was accessed (you'll need to know this before writing)
- Frame remediation as already done, not just planned

**Don't:**
- Use vague language like "we have strengthened our controls"
- Be defensive or try to explain away why 45 days wasn't that bad
- Commit to controls you can't actually sustain
- Ignore the monitoring/detection gap — auditors will notice if you don't address how this went undetected for 45 days

---

## Immediate Steps to Take

1. **Confirm the account is now disabled** — if not already done, do it immediately
2. **Pull access logs** for the 45-day period to check for any activity on that account
3. **Identify the root cause** so you can write an accurate management response
4. **Implement automation** — if you're using Okta, there are direct integrations with most HRIS systems (Workday, BambooHR, etc.) that automate offboarding
5. **Run an access review now** — check whether any other former employees have active accounts

This exception, while serious, is recoverable with a strong management response and demonstrated remediation. The worst outcome is if this becomes a repeat finding on your next audit.

# FedRAMP Authorization Process: Start to Finish

*Use official FedRAMP templates from fedramp.gov — this content should be inserted into the appropriate template section.*

---

## Overview

FedRAMP (Federal Risk and Authorization Management Program) provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by US federal agencies. As a Cloud Service Provider (CSP), you will pursue authorization for your Cloud Service Offering (CSO) through one of two primary paths.

---

## The Authorization Package

Regardless of path, your authorization package must include:

```
Authorization Package
├── System Security Plan (SSP) + Appendices A–Q
├── Security Assessment Plan (SAP) + Appendices A–D    [3PAO-prepared]
├── Security Assessment Report (SAR) + Appendices A–F  [3PAO-prepared]
└── Plan of Action & Milestones (POA&M)                [SSP Appendix O]
```

All documents must use the **official FedRAMP PMO templates** (Rev 5, updated December 2024), available at https://www.fedramp.gov/rev5/documents-templates/. Non-standard submissions risk rejection or significant delays. As of September 2026, all CSPs must also submit OSCAL machine-readable packages per RFC-0024.

---

## Step-by-Step Authorization Process

### Phase 1: Preparation & Readiness

1. **Define your Cloud Service Offering (CSO)** — Identify what is being authorized: IaaS, PaaS, or SaaS offering.
2. **Determine your target impact level** — Based on FIPS 199 categorization, select Low, Moderate, or High (see impact level guidance).
3. **Define your authorization boundary** — Everything that processes, stores, or transmits federal data must be inside the boundary. This is one of the most common sources of delays and findings.
4. **Conduct a gap assessment** — Map your current security posture to the applicable NIST SP 800-53 Rev 5 control baseline:
   - Low: ~156 controls
   - Moderate: 323 controls
   - High: 421 controls
5. **Engage a 3PAO** — Select an accredited Third Party Assessment Organization from the FedRAMP marketplace. The 3PAO will prepare the SAP and SAR.
6. **Consider a Readiness Assessment Report (RAR)** — Optional but recommended; the FedRAMP PMO reviews the RAR and designates the CSP as "FedRAMP Ready" before full assessment begins.

### Phase 2: Documentation

7. **Draft the System Security Plan (SSP)** — The SSP is the cornerstone document. It includes:
   - System description and boundary
   - Data flow diagrams and network architecture
   - Control implementation narratives for all in-scope controls
   - Appendices A–Q (including POA&M as Appendix O, CIS/CRM workbook, etc.)
8. **Complete inherited control documentation** — If leveraging FedRAMP-authorized IaaS/PaaS (e.g., AWS GovCloud, which is FedRAMP High authorized), document inherited, shared, and customer-responsible controls in the Customer Responsibility Matrix (CRM).

### Phase 3: Assessment

9. **3PAO conducts assessment** — The 3PAO executes the Security Assessment Plan (SAP) and produces the Security Assessment Report (SAR). This includes:
   - Control testing
   - Vulnerability scanning (OS, DB, web app, containers)
   - Penetration testing
   - Documentation review
10. **Remediate findings** — Address all findings before submitting, or document residual items in the POA&M with milestone dates.

### Phase 4: Authorization Decision

11. **Package submission and review** — Submitted to the authorizing official (Agency AO or JAB).
12. **Authorization decision** — Issuance of Authority to Operate (ATO) or Provisional ATO (P-ATO).

### Phase 5: Continuous Monitoring (ConMon)

13. **Monthly ConMon activities** — Submit vulnerability scan results, POA&M updates, inventory changes, and a ConMon Monthly Executive Summary to agency Authorizing Officials.
14. **Annual activities** — Full 3PAO re-assessment using the Annual Assessment Controls Selection Worksheet, updated SSP and appendices, tested IRP and CP, updated SAR and POA&M.

---

## Agency ATO vs. JAB P-ATO

### Agency Authorization (Agency ATO)

| Attribute | Details |
|---|---|
| **Sponsor** | A specific federal agency acts as your sponsor and Authorizing Official (AO) |
| **Review body** | The agency's own security team + FedRAMP PMO review |
| **Outcome** | Agency-specific ATO; other agencies may reuse via FedRAMP Marketplace |
| **Timeline** | Typically 12–18 months end-to-end |
| **Reusability** | Once listed on the FedRAMP Marketplace, other agencies can issue their own ATOs based on the existing package (reciprocity) |
| **Best for** | CSPs with an existing agency customer relationship or a clear target agency |

**Process highlights:**
- Agency identifies you as a cloud service they want to use
- Agency AO sponsors the authorization
- You work directly with the agency's security team throughout
- FedRAMP PMO provides oversight and must accept the package into the FedRAMP Marketplace

### JAB P-ATO (Joint Authorization Board Provisional ATO)

| Attribute | Details |
|---|---|
| **Review body** | Joint Authorization Board: DoD, DedRAMP, DHS CISOs |
| **Outcome** | Government-wide Provisional ATO — maximizes reusability across all agencies |
| **Status (2025–2026)** | **Effectively suspended since 2024** — the JAB has not been actively reviewing new CSPs; verify current status with the FedRAMP PMO before pursuing this path |
| **Best for** | High-demand, horizontal platforms serving many agencies (when active) |

> **Critical note**: As of 2024–2026, the JAB P-ATO path has been largely suspended. Do not plan your authorization strategy around JAB unless the FedRAMP PMO confirms it is active again.

---

## Which Path Should You Choose for a First Authorization?

**Recommendation: Agency Authorization Path**

For a first FedRAMP authorization, the Agency Authorization path is strongly recommended for the following reasons:

1. **JAB is effectively suspended** — Planning for JAB P-ATO is not viable given current FedRAMP PMO operations as of 2025–2026.
2. **Existing relationships** — If you are already in conversations with a federal agency prospect, that agency can serve as your sponsor and AO, creating a clear path to authorization.
3. **Faster feedback loop** — Working directly with one agency provides faster, more targeted feedback than a government-wide review.
4. **Reusability after authorization** — Once listed on the FedRAMP Marketplace, your authorization package can be reused by other agencies, effectively providing the same reach as a P-ATO.
5. **Consider FedRAMP 20x pilot** — A modernization initiative (FedRAMP 20x) is in progress that may offer a more streamlined path; evaluate whether your system qualifies for the pilot program.

### Recommended First Steps

1. Identify your target impact level (most CSPs target **Moderate**, which covers the majority of non-classified government data)
2. Secure an agency sponsor — reach out to federal prospects and confirm one will act as AO
3. Conduct a readiness gap assessment against NIST SP 800-53 Rev 5 Moderate baseline (323 controls)
4. Engage an accredited 3PAO early in the process
5. Begin drafting the SSP using official FedRAMP PMO templates
6. Consider pursuing a Readiness Assessment Report (RAR) to obtain "FedRAMP Ready" designation before full assessment

# FedRAMP Authorization Process: Start to Finish

## Overview

FedRAMP (Federal Risk and Authorization Management Program) is a US government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. As a cloud software vendor, you will need to go through FedRAMP authorization to sell cloud services to most federal agencies.

---

## The FedRAMP Authorization Process

### Phase 1: Preparation

1. **Determine your impact level** — Based on the sensitivity of the data your system handles, you'll be categorized as Low, Moderate, or High impact. This determines how many security controls you must implement.
2. **Define your system boundary** — Clearly document what systems, components, and services are in scope for the authorization.
3. **Select your authorization path** — Choose between Agency ATO or JAB P-ATO (see below).
4. **Conduct a readiness assessment** — Evaluate your current security posture against FedRAMP requirements and identify gaps.
5. **Engage a 3PAO** — Select an accredited Third Party Assessment Organization from the FedRAMP marketplace to conduct your security assessment.

### Phase 2: Documentation

6. **Develop your System Security Plan (SSP)** — This is the primary document describing how you implement security controls. It typically runs hundreds of pages.
7. **Complete supporting documentation** — Policies, procedures, incident response plans, contingency plans, and other required artifacts.

### Phase 3: Security Assessment

8. **3PAO Assessment** — Your chosen 3PAO conducts an independent security assessment, developing a Security Assessment Plan (SAP) and executing it.
9. **Vulnerability scanning and penetration testing** — Required as part of the assessment process.
10. **Security Assessment Report (SAR)** — The 3PAO documents findings in the SAR.

### Phase 4: Authorization

11. **Remediation** — Address any findings from the assessment, or document them in a Plan of Action & Milestones (POA&M).
12. **Package submission** — Submit your complete authorization package for review.
13. **Authorization decision** — Receive your Authority to Operate (ATO) or Provisional ATO (P-ATO).

### Phase 5: Continuous Monitoring

14. **Ongoing compliance** — Maintain your authorization through regular vulnerability scanning, monthly reporting, annual reassessments, and POA&M management.

---

## Agency ATO vs. JAB P-ATO

### Agency Authorization (Agency ATO)

- **Sponsor**: A specific federal agency sponsors your authorization and acts as the Authorizing Official (AO)
- **Scope**: Initially covers just that agency; other agencies may accept it via reciprocity
- **Process**: You work directly with one agency through the authorization process
- **Timeline**: Typically 12–18 months
- **Best for**: CSPs that have an existing relationship with a specific agency customer

### JAB P-ATO (Joint Authorization Board Provisional ATO)

- **Review board**: Conducted by the Joint Authorization Board, consisting of representatives from DoD, DHS, and GSA
- **Scope**: Government-wide recognition — any agency can use your service based on the P-ATO
- **Process**: More rigorous and competitive; JAB selects which CSPs to work with based on government-wide demand
- **Timeline**: Can take 12–24+ months
- **Best for**: Large platforms with demonstrated or expected demand across many federal agencies

---

## Which Path Should You Choose for a First Authorization?

**Recommendation: Agency Authorization**

For a first-time FedRAMP authorization, Agency Authorization is generally the better starting point:

1. **More accessible** — Agency path doesn't require JAB selection; you just need one willing agency sponsor.
2. **Existing customer relationship** — If you're already talking to a federal agency, they can be your sponsor.
3. **Faster path** — Working with one agency is typically more straightforward than the JAB process.
4. **Reusability** — Once you have an Agency ATO and are listed in the FedRAMP Marketplace, other agencies can leverage your authorization.

**To get started:**
- Identify one federal agency prospect willing to sponsor your authorization
- Determine your target impact level (Moderate is most common for commercial cloud services)
- Conduct a gap assessment against the applicable NIST SP 800-53 control baseline
- Engage an accredited 3PAO early in the process
- Begin developing your System Security Plan

# FedRAMP Impact Levels: Low, Moderate, and High

*Use official FedRAMP templates from fedramp.gov — this content should be inserted into the appropriate template section.*

---

## Impact Level Framework

FedRAMP impact levels are determined using **FIPS 199** categorization, which assesses the potential impact to an organization if federal information is compromised across three security objectives:

- **Confidentiality** — Unauthorized disclosure of information
- **Integrity** — Unauthorized modification or destruction of information
- **Availability** — Disruption of access to or use of information

The impact level is determined by the **high-water mark** across these three objectives. The applicable NIST SP 800-53 Rev 5 baseline is then selected based on that categorization.

---

## The Four FedRAMP Tiers

### LI-SaaS (Low-Impact SaaS)

| Attribute | Details |
|---|---|
| **Data sensitivity** | No PII, no sensitive federal data, very limited scope |
| **Control count** | Reduced subset — uses a combined SSP + assessment template |
| **Best for** | Collaboration tools, productivity apps with no federal data storage |
| **Your situation** | Does NOT apply — law enforcement data is highly sensitive |

### Low Impact

| Attribute | Details |
|---|---|
| **Definition** | Loss of confidentiality, integrity, or availability has a **limited adverse effect** on agency operations, assets, or individuals |
| **Control count** | ~156 controls (NIST SP 800-53 Rev 5) |
| **Examples** | Publicly available information, general training systems |
| **Your situation** | Does NOT apply — law enforcement data warrants higher protection |

### Moderate Impact

| Attribute | Details |
|---|---|
| **Definition** | Loss of CIA has a **serious adverse effect** on agency operations, assets, or individuals |
| **Control count** | 323 controls (NIST SP 800-53 Rev 5) |
| **Coverage** | Most common baseline — covers the majority of CSPs handling non-classified government data |
| **Examples** | CRM systems, HR data, financial management, general government operations |
| **Your situation** | May apply as a floor, but law enforcement data likely requires High |

### High Impact

| Attribute | Details |
|---|---|
| **Definition** | Loss of CIA has a **severe or catastrophic effect** on agency operations, assets, or individuals |
| **Control count** | 421 controls (NIST SP 800-53 Rev 5) |
| **Examples** | Law enforcement data, financial systems, health records, critical infrastructure |
| **Your situation** | **Likely required** — see analysis below |

---

## Impact Level Comparison

| Attribute | Low | Moderate | High |
|---|---|---|---|
| NIST 800-53 Rev 5 Controls | ~156 | 323 | 421 |
| Typical assessment timeline | 6–9 months | 12–18 months | 18–24+ months |
| Cost (rough estimate) | Lower | Moderate | Highest |
| Required for law enforcement data | No | Unlikely | Yes |
| FedRAMP Marketplace listing | Yes | Yes | Yes |

---

## What Applies to Your Product: Law Enforcement Sensitive Data

**Recommendation: FedRAMP High**

The SKILL guidance and FedRAMP documentation are explicit: **law enforcement data is specifically cited as an example of High impact data**. Here is the analysis:

### FIPS 199 Categorization Analysis

**Confidentiality**: The unauthorized disclosure of law enforcement sensitive data could:
- Compromise active investigations
- Put officers, witnesses, or confidential informants at risk
- Enable criminal elements to evade law enforcement
- Violate individuals' civil liberties and privacy rights

**Impact assessment**: **HIGH** — severe or catastrophic effect

**Integrity**: Unauthorized modification of law enforcement records could:
- Result in wrongful arrests or releases
- Corrupt evidentiary chains of custody
- Undermine prosecutions

**Impact assessment**: **HIGH**

**Availability**: Loss of access to law enforcement systems during active operations could:
- Endanger officers and the public
- Disrupt critical public safety operations

**Impact assessment**: **HIGH**

**High-water mark result**: **HIGH** — FedRAMP High baseline applies

### What FedRAMP High Means Operationally

1. **421 NIST SP 800-53 Rev 5 controls** must be implemented and documented in your SSP
2. **Stricter parameter values** — FedRAMP sets more restrictive parameter values for High than base NIST (e.g., shorter session timeouts, stricter audit requirements)
3. **Additional technical requirements**:
   - FIPS 140-2 or 140-3 validated encryption required for all data at rest and in transit
   - Mandatory MFA for all privileged and non-privileged accounts
   - More frequent vulnerability scanning cadence
   - Stricter separation of duties requirements
4. **Hosting requirements** — Your system must be hosted on a FedRAMP High authorized infrastructure. AWS GovCloud (US) is FedRAMP High authorized and is a common choice.
5. **Assessment requirements** — High-impact assessments require more extensive 3PAO testing, including penetration testing and a broader set of tested controls.

### Authorization Path Implications

- **Agency ATO**: An agency with law enforcement missions (e.g., DOJ, FBI, DHS, DEA, ATF, state/local law enforcement federally funded programs) can sponsor your High authorization
- **JAB P-ATO**: Currently suspended as of 2024–2026; not a viable near-term path

### Recommended Next Steps

1. Conduct a formal **FIPS 199 categorization** exercise with your security team and document the results in SSP Section 2
2. Confirm FedRAMP High with your target agency sponsor — they will validate the impact level during their review
3. Select a **FedRAMP High authorized IaaS/PaaS** (AWS GovCloud US, Azure Government) to maximize inherited controls
4. Begin gap assessment against the **421-control High baseline** — this is a significant undertaking and will require 18–24+ months for most organizations
5. Engage an accredited 3PAO with FedRAMP High experience early

# FedRAMP Impact Levels: Low, Moderate, and High

## Overview

FedRAMP uses three primary impact levels — Low, Moderate, and High — to categorize cloud systems based on the potential impact of a security breach. These levels are derived from FIPS 199 (Federal Information Processing Standards Publication 199), which evaluates the potential impact to confidentiality, integrity, and availability of federal information.

---

## FedRAMP Low

- **Definition**: A security incident would have a **limited adverse effect** on agency operations, assets, or individuals
- **Control count**: Approximately 125 security controls
- **Typical use cases**: Public-facing websites, general productivity tools, systems handling only publicly available information
- **Assessment**: Less rigorous; shorter timeline and lower cost
- **Not appropriate for**: Any system handling sensitive, controlled unclassified information (CUI), or personal data

---

## FedRAMP Moderate

- **Definition**: A security incident would have a **serious adverse effect** on agency operations, assets, or individuals
- **Control count**: Approximately 325 security controls
- **Typical use cases**: Most government cloud services — HR systems, financial management, CRM, collaboration platforms handling non-public government data
- **Assessment**: Full 3PAO assessment required; typical timeline of 12–18 months
- **Most common level**: The majority of FedRAMP authorizations are at the Moderate level

---

## FedRAMP High

- **Definition**: A security incident would have a **severe or catastrophic effect** on agency operations, assets, or individuals
- **Control count**: Approximately 420 security controls
- **Typical use cases**: Systems handling law enforcement data, financial data with national security implications, health information, emergency response systems, classified-adjacent systems
- **Assessment**: Most rigorous; stricter parameter requirements, more extensive 3PAO testing, 18–24+ months typical timeline
- **Hosting requirements**: Must be hosted on FedRAMP High authorized infrastructure (e.g., AWS GovCloud, Azure Government)

---

## What Impact Level Applies to Law Enforcement Sensitive Data?

**Answer: FedRAMP High**

Law enforcement sensitive data is specifically in the High impact category. Here is why:

### Confidentiality Impact
Unauthorized disclosure of law enforcement data could:
- Compromise ongoing criminal investigations
- Endanger undercover officers or confidential informants
- Allow criminal suspects to evade capture
- Violate privacy rights and civil liberties

This represents a **severe** potential impact — High categorization.

### Integrity Impact
If law enforcement records are tampered with, the consequences could include:
- Wrongful arrests based on incorrect warrants or records
- Compromised evidence and failed prosecutions
- Corrupted criminal history records

This also represents a **severe** potential impact — High categorization.

### Availability Impact
If law enforcement systems go down during active operations, the result could be:
- Inability to respond to emergencies
- Officers unable to verify warrants or identity in the field

Depending on the specific use case, this may be High or Moderate impact.

### Conclusion

Using the high-water mark principle (the final categorization equals the highest impact across all three objectives), your system would be categorized as **FedRAMP High**.

---

## Practical Implications for Your Product

1. **Infrastructure**: Must be hosted on FedRAMP High authorized cloud infrastructure (AWS GovCloud US, Azure Government)
2. **Controls**: Approximately 420 security controls to implement and document
3. **Timeline**: Plan for 18–24+ months to achieve authorization
4. **Cost**: FedRAMP High authorizations are significantly more expensive than Moderate (typically $1M–$3M+ for initial authorization including 3PAO costs)
5. **Agency sponsor**: Your likely customers (DOJ, DHS, FBI, DEA, ATF, state/local law enforcement via federal grants) are accustomed to High requirements

**Recommendation**: Confirm the impact level with your target federal agency customer early in the process. They will validate the categorization during their security review.

# FedRAMP 20x: What It Is and How It Affects Your Authorization Strategy

*Use official FedRAMP templates from fedramp.gov — this content should be inserted into the appropriate template section.*

---

## What Is FedRAMP 20x?

FedRAMP 20x is a **modernization initiative** launched by the FedRAMP Program Management Office (PMO) to fundamentally reform how cloud authorization works. The "20x" name signals an ambition to make the process dramatically faster and more scalable than the traditional approach.

### Core Changes FedRAMP 20x Introduces

| Feature | Traditional FedRAMP | FedRAMP 20x |
|---|---|---|
| Submission format | Word/PDF templates (SSP, SAP, SAR, POA&M) | Machine-readable OSCAL packages; API-driven submissions |
| Authorization model | Point-in-time assessment → ATO | **Continuous authorization** — ongoing validation replaces periodic snapshots |
| Assessment approach | 3PAO conducts broad assessment on a fixed schedule | Modular, targeted assessments; automated evidence collection |
| Documentation | Large monolithic documents | Modular components; reusable control implementations |
| Review process | Manual review cycles | Automated validation and review tooling |
| Pilot status | Established, well-understood | **In progress as of 2025–2026; actively being piloted** |

### Key Technical Elements of FedRAMP 20x

1. **OSCAL (Open Security Controls Assessment Language)** — Machine-readable format for security documentation. The FedRAMP PMO has mandated via RFC-0024 that all authorized CSPs transition to OSCAL packages by **September 2026** — this applies to traditional path CSPs as well, not just 20x participants.

2. **Continuous Authorization** — Rather than a one-time ATO that expires, FedRAMP 20x envisions a model where compliance is continuously verified through automated telemetry and evidence feeds. This reduces the need for annual 3PAO reassessments of the same scope.

3. **Modular Submissions** — Control packages can be submitted and reviewed incrementally, rather than requiring the entire SSP to be complete before review begins.

4. **API-Driven Processes** — Programmatic interfaces to the FedRAMP marketplace and review infrastructure.

---

## Current Status of FedRAMP 20x (2025–2026)

- FedRAMP 20x is **actively in pilot** — not yet generally available
- The traditional SSP/SAP/SAR template path remains the **required approach** for non-20x authorizations
- Traditional template formats (SSP, SAP, SAR, POA&M, CIS/CRM, IIW, ISCP) were updated in **December 2024** for Rev 5 alignment
- CSPs interested in FedRAMP 20x should contact the FedRAMP PMO to determine if/how they can participate in the pilot
- JAB P-ATO has been effectively suspended since 2024; 20x is partly intended to fill the gap left by reduced JAB capacity

---

## Should You Pursue FedRAMP 20x or Traditional Authorization?

### Factors Favoring Traditional FedRAMP Authorization

1. **Maturity and predictability** — Traditional authorization has a well-understood process, established templates, a large ecosystem of 3PAOs with experience, and agency reviewers trained on standard formats.

2. **Immediate availability** — You can begin the traditional path today. FedRAMP 20x pilot participation is not guaranteed.

3. **Agency acceptance** — Agencies are trained to review and accept traditional SSP/SAR packages. FedRAMP 20x packages may require more agency-side education.

4. **Tooling ecosystem** — Numerous GRC tools, consultants, and 3PAOs have mature capabilities around traditional documentation.

5. **OSCAL is required regardless** — Even on the traditional path, you must plan to produce OSCAL-format packages by September 2026, so the gap between traditional and 20x is narrowing on the technical side.

### Factors That Might Favor FedRAMP 20x

1. **Engineering-forward organizations** — If your team is comfortable with OSCAL, APIs, and automated compliance tooling, the 20x approach may align better with your culture.

2. **Long-term efficiency** — Continuous authorization could reduce the annual burden of full 3PAO reassessments if the model matures.

3. **Startup / agile environments** — The modular approach may suit organizations that release frequently.

4. **Future-proofing** — If 20x becomes the dominant path, early participation builds institutional knowledge.

---

## Recommendation

**For most CSPs seeking a first authorization in 2025–2026: Pursue traditional FedRAMP authorization while building OSCAL readiness.**

Here is the rationale:

1. **20x is a pilot, not production** — Betting your first authorization on a program still in pilot introduces significant schedule uncertainty. Federal sales cycles are long; delays cost real revenue.

2. **Traditional path is proven** — The SSP/SAP/SAR path, while burdensome, is well-understood by agencies, 3PAOs, and the FedRAMP PMO. You can predict timelines and costs more reliably.

3. **OSCAL preparation is required either way** — Begin building OSCAL-format documentation now (September 2026 mandate), which positions you for FedRAMP 20x adoption as the program matures.

4. **Monitor FedRAMP PMO announcements** — The situation is evolving. Check fedramp.gov regularly for 20x pilot updates, and re-evaluate if the program moves from pilot to general availability before you complete your traditional authorization.

### Practical Action Items

- Start traditional authorization now (Agency ATO path)
- Invest in OSCAL tooling in parallel (NIST OSCAL tools, Trestle framework, GRC platforms with OSCAL support)
- Register interest with the FedRAMP PMO for 20x pilot consideration
- Plan SSP authoring in a way that supports future OSCAL conversion (structured, consistent narratives; avoid highly manual document-only approaches)

# FedRAMP 20x: Overview and Strategic Guidance

## What Is FedRAMP 20x?

FedRAMP 20x is a modernization initiative announced by the FedRAMP Program Management Office (PMO) aimed at dramatically streamlining the FedRAMP authorization process. The initiative is named to convey the goal of making authorization significantly faster and more scalable — potentially 20 times more efficient than the existing process.

### Key Changes FedRAMP 20x Introduces

**Continuous Authorization**
Rather than a point-in-time assessment leading to an ATO that periodically expires, FedRAMP 20x envisions a model of continuous monitoring and ongoing authorization. Security posture would be validated continuously through automated tooling rather than snapshot assessments.

**Automation and Machine-Readable Formats**
FedRAMP 20x emphasizes the use of OSCAL (Open Security Controls Assessment Language) — a machine-readable format for security documentation. This shifts away from large Word and PDF documents toward structured data that can be automatically validated.

**Streamlined Assessment Process**
The initiative aims to reduce the assessment burden by automating evidence collection, enabling reuse of assessment artifacts, and moving toward a more modular approach to authorization.

**Reduced Documentation Burden**
FedRAMP 20x is intended to reduce the volume of manual documentation (the traditional SSP can run 500+ pages) by replacing narrative documentation with structured, machine-readable evidence.

---

## Current Status of FedRAMP 20x

As of 2024–2025, FedRAMP 20x is in an active development and pilot phase. The FedRAMP PMO has been:
- Publishing concept papers and requests for comment
- Engaging with industry stakeholders
- Running limited pilots with select CSPs

The traditional FedRAMP authorization process (SSP, SAP, SAR, POA&M) remains the **standard required path** for all CSPs not participating in the 20x pilot.

---

## Should You Pursue FedRAMP 20x or Traditional Authorization?

### The Case for Traditional FedRAMP Authorization

**For most organizations in 2025, traditional authorization is the right choice:**

1. **Availability**: Traditional authorization is available to any CSP with an agency sponsor today. FedRAMP 20x is not generally available.

2. **Established process**: The traditional path has mature tooling, experienced 3PAOs, and agency reviewers who know exactly what to expect.

3. **Timeline predictability**: Traditional authorization timelines are well-understood (12–18 months for Moderate). FedRAMP 20x timelines are unknown for new entrants.

4. **Agency readiness**: Federal agencies are currently trained and equipped to review traditional FedRAMP packages. 20x packages may require additional agency-side preparation.

### The Case for FedRAMP 20x (Future Consideration)

1. **Long-term efficiency**: If FedRAMP 20x matures, continuous authorization could reduce ongoing compliance burden significantly.

2. **Modern DevSecOps alignment**: Organizations with strong automation and DevSecOps practices may find the 20x approach more natural.

3. **Reduced documentation overhead**: Less manual document authoring appeals to engineering-driven organizations.

---

## Recommendation

**Pursue traditional FedRAMP authorization now, while monitoring FedRAMP 20x development.**

### Rationale

- FedRAMP 20x is not yet generally available — waiting for it could delay your market entry by years
- The traditional path, while burdensome, delivers a real ATO that agencies will accept today
- Begin exploring OSCAL tooling in parallel, as this will be valuable regardless of which path ultimately dominates
- Revisit FedRAMP 20x participation when the PMO announces general availability

### Next Steps

1. Begin your traditional FedRAMP authorization through the Agency ATO path
2. Sign up for FedRAMP PMO newsletters and updates at fedramp.gov to monitor 20x developments
3. Start familiarizing your team with OSCAL as a future requirement
4. Consult with your 3PAO about their FedRAMP 20x readiness for future planning

# System Boundary Description — FedRAMP Moderate SSP

*Use official FedRAMP templates from fedramp.gov — this content should be inserted into SSP Section 9 (System Boundary) and associated architecture appendices. All diagrams referenced below must be included as figures in the SSP.*

---

## SSP Section 9: System Boundary Description

### 9.1 Authorization Boundary Overview

The [System Name] authorization boundary encompasses all components that process, store, or transmit federal information in support of the Cloud Service Offering (CSO). The boundary is hosted entirely within the **AWS GovCloud (US-West) and AWS GovCloud (US-East) regions**, which hold a FedRAMP High Provisional Authorization to Operate (P-ATO) issued by the JAB. All physical infrastructure, including data centers, networking hardware, and physical security controls, is inherited from AWS GovCloud.

The boundary includes the following component categories:

1. **Web Application Layer** — Internet-accessible application servers and associated load balancers
2. **Database Layer** — PostgreSQL relational database instances storing federal data
3. **Caching Layer** — Redis in-memory cache instances
4. **Integration Layer** — API connections to external services (Okta, SendGrid)
5. **Supporting Infrastructure** — Network components, security monitoring tools, and management plane elements within AWS GovCloud

**Note on External Services**: Two external SaaS services — Okta (identity provider) and SendGrid (email delivery) — connect to the in-boundary system. These services are addressed in Section 9.3 (External Services) below.

---

### 9.2 System Components Within the Authorization Boundary

#### 9.2.1 Web Application Tier

The web application is deployed on **Amazon EC2 instances** (or Amazon ECS/EKS containers, if applicable) within a private subnet in the AWS GovCloud VPC. Application traffic is received through an **AWS Application Load Balancer (ALB)** in a public subnet. The ALB enforces TLS 1.2 minimum for all inbound connections.

| Component | Type | Data Classification | FedRAMP Role |
|---|---|---|---|
| AWS ALB | Load Balancer | Transit only | In boundary |
| Web Application Servers (EC2) | Compute | Process and transit federal data | In boundary |
| AWS WAF | Web Application Firewall | Metadata only | In boundary |
| Amazon CloudFront (if applicable) | CDN | Transit only | In boundary |

**FIPS compliance**: All TLS termination uses FIPS 140-2 validated algorithms via AWS GovCloud FIPS endpoints.

#### 9.2.2 Database Tier

Federal data at rest is stored in an **Amazon RDS for PostgreSQL** instance deployed in a private subnet with no public internet connectivity. Multi-AZ deployment is enabled for availability. Database encryption is enabled using **AWS KMS with FIPS 140-2 validated keys**.

| Component | Type | Data Classification | FedRAMP Role |
|---|---|---|---|
| Amazon RDS (PostgreSQL) — Primary | Database | Stores federal data | In boundary |
| Amazon RDS (PostgreSQL) — Read Replica | Database | Stores federal data (replica) | In boundary |
| AWS KMS (GovCloud) | Key Management | Encryption keys | In boundary (inherited from AWS) |
| RDS Automated Backups (S3 — GovCloud) | Storage | Federal data backups | In boundary |

**Data classification note**: All federal data stored in PostgreSQL must be identified in SSP Appendix J (Information Types) and Appendix K (Data Flow Diagrams).

#### 9.2.3 Caching Tier

A **Redis cache cluster** (Amazon ElastiCache for Redis) is deployed in the private subnet and used exclusively for session data and application-level caching of non-sensitive intermediate results. Redis does not serve as a persistent data store for federal information.

| Component | Type | Data Classification | FedRAMP Role |
|---|---|---|---|
| Amazon ElastiCache (Redis) | Cache | Session data; transient federal data | In boundary |

**Important**: If session data includes authentication tokens or any federal information — even transiently — the Redis cluster is in-scope and must be inventoried and secured accordingly (encryption in transit via TLS, encryption at rest enabled, no public exposure).

#### 9.2.4 Security and Monitoring Components

All security telemetry stays within the AWS GovCloud boundary.

| Component | Type | FedRAMP Role | Controls Addressed |
|---|---|---|---|
| AWS CloudTrail | Audit Logging | In boundary | AU-2, AU-3, AU-12 |
| Amazon GuardDuty | Threat Detection | In boundary | SI-3, IR-5 |
| AWS Security Hub | SIEM Aggregation | In boundary | AU-6, SI-4 |
| AWS Config | Configuration Monitoring | In boundary | CM-6, CM-7 |
| Amazon VPC Flow Logs | Network Logging | In boundary | AU-12, SC-7 |

---

### 9.3 External Services — Outside the Authorization Boundary

Two external SaaS services are connected to the [System Name] boundary via API integrations. These services are **outside the authorization boundary** and must be addressed through one of the following mechanisms per FedRAMP requirements:

1. The external service is FedRAMP-authorized (listed on the FedRAMP Marketplace), OR
2. Compensating controls are documented and approved by the AO

#### 9.3.1 Okta (Identity and Authentication Provider)

| Attribute | Details |
|---|---|
| **Service** | Okta Workforce Identity |
| **Purpose** | Federated authentication and SSO; MFA enforcement |
| **Data exchanged** | User identity assertions (SAML/OIDC tokens); no federal payload data |
| **FedRAMP status** | Okta is listed on the FedRAMP Marketplace — verify current authorization status and impact level at marketplace.fedramp.gov |
| **Boundary relationship** | External — outside the authorization boundary |
| **Documentation required** | CIS/CRM workbook entry; SSP Appendix Q (Integrated Inventory) |

**Important**: If Okta's FedRAMP authorization level (Moderate or High) matches or exceeds your system's baseline, you may document Okta as a leveraged authorization. If Okta is not authorized or authorized at a lower level, additional compensating controls and AO approval are required.

#### 9.3.2 SendGrid (Email Delivery Service)

| Attribute | Details |
|---|---|
| **Service** | Twilio SendGrid Email API |
| **Purpose** | Transactional email delivery (notifications, alerts) |
| **Data exchanged** | Email metadata and content (may include PII or federal data in notification payloads) |
| **FedRAMP status** | Verify at marketplace.fedramp.gov — SendGrid's FedRAMP status may be limited or at a lower impact level |
| **Boundary relationship** | External — outside the authorization boundary |
| **Risk consideration** | If emails contain federal data (e.g., user PII, case identifiers), this is a high-risk external connection requiring AO attention |

**Recommended mitigations for SendGrid**:
- Minimize federal data in email payloads (use reference links rather than embedding data)
- Document the data types transmitted in SSP Section 10 (Information Types) and Appendix K (Data Flow)
- Obtain AO approval for this external connection
- Consider whether a FedRAMP-authorized alternative (e.g., AWS SES GovCloud) should replace SendGrid to keep email within the boundary

---

### 9.4 What Is Explicitly Outside the Boundary

The following are **not** within the [System Name] authorization boundary:

- Customer/agency-managed identity systems (unless Okta above is used)
- End-user devices (laptops, workstations) of agency personnel
- Agency network infrastructure
- SendGrid's internal infrastructure
- AWS commercial (non-GovCloud) services — no commercial region endpoints shall be used
- Developer workstations and CI/CD pipelines (these should be documented separately as they may require boundary inclusion if they access or deploy to in-boundary systems)

---

### 9.5 Data Flow Summary

| Data Flow | Source | Destination | Protocol | Encryption | In/Out of Boundary |
|---|---|---|---|---|---|
| User authentication | Browser | Okta (external) | HTTPS/OIDC | TLS 1.2+ (FIPS) | Exits boundary |
| Auth token return | Okta | Web App (ALB) | HTTPS/OIDC | TLS 1.2+ (FIPS) | Re-enters boundary |
| Application requests | Browser | ALB → Web App | HTTPS | TLS 1.2+ (FIPS) | In boundary |
| DB queries | Web App | RDS PostgreSQL | TCP/TLS | TLS 1.2+ (FIPS) | In boundary |
| Cache reads/writes | Web App | ElastiCache Redis | TCP/TLS | TLS 1.2+ | In boundary |
| Email notifications | Web App | SendGrid (external) | HTTPS/SMTP | TLS 1.2+ | Exits boundary |
| Audit logs | All components | CloudTrail/Security Hub | Internal | Encrypted at rest | In boundary |

---

### 9.6 Boundary Diagram Reference

*[INSERT NETWORK DIAGRAM — SSP Figure 9-1: Authorization Boundary Diagram]*
*[INSERT DATA FLOW DIAGRAM — SSP Figure 9-2: Data Flow Diagram]*

The authorization boundary diagram must depict:
- All in-boundary components grouped within a clearly labeled boundary line
- External services (Okta, SendGrid) clearly shown outside the boundary
- All data flows between components, including protocol and port
- AWS GovCloud region designation
- Internet-facing components and ingress/egress points
- Trust zones (public subnet, private subnet, management subnet)

---

*This content should be placed in SSP Section 9 using the official FedRAMP SSP template. Data flow diagrams are required in SSP Appendix K. Component inventory must be maintained in SSP Appendix Q. External service documentation belongs in the CIS/CRM workbook and SSP Appendix Q.*

# System Boundary Description — FedRAMP Moderate SSP

*Note: This content should be inserted into the appropriate section of the official FedRAMP SSP template, available at fedramp.gov.*

---

## System Boundary Description

### Overview

The [System Name] Cloud Service Offering (CSO) is a web application hosted on AWS GovCloud (US) that provides [describe purpose] to federal agency customers. The authorization boundary encompasses all components that process, store, or transmit federal information.

The system is logically segmented within a Virtual Private Cloud (VPC) in AWS GovCloud and is designed with defense-in-depth principles. The authorization boundary includes all AWS GovCloud resources owned and managed by [CSP Name], as well as the two external SaaS integrations described below.

---

### Components Within the Authorization Boundary

#### Web Application Layer

The primary user interface and application logic are delivered through a web application hosted on AWS GovCloud compute resources (EC2 instances or containerized workloads). The application is accessible to end users over the public internet via HTTPS. An AWS Application Load Balancer (ALB) distributes incoming traffic across application instances in the private subnet.

**Key components:**
- AWS Application Load Balancer (public-facing, HTTPS only)
- Web application servers (EC2 or ECS, private subnet)
- AWS WAF for web application firewall protection

All web traffic is encrypted in transit using TLS 1.2 or higher.

#### Database Layer (PostgreSQL)

Federal data is persisted in an Amazon RDS for PostgreSQL instance located in a private subnet with no direct internet connectivity. The database is encrypted at rest using AWS Key Management Service (KMS). Automated backups are enabled and stored in encrypted S3 buckets within AWS GovCloud.

**Key components:**
- Amazon RDS for PostgreSQL (primary instance, private subnet)
- Amazon RDS for PostgreSQL (read replica or standby, for availability)
- AWS KMS for encryption key management
- S3 (GovCloud) for encrypted backup storage

#### Caching Layer (Redis)

An Amazon ElastiCache Redis cluster is deployed in the private subnet and used for application-level caching and session management. The cache does not serve as the authoritative store for federal data but may transiently hold federal information during active user sessions.

**Key components:**
- Amazon ElastiCache for Redis (private subnet)
- Encryption in transit (TLS) and at rest enabled

#### Security and Monitoring Infrastructure

| Component | Purpose |
|---|---|
| AWS CloudTrail | Audit logging for all API activity |
| Amazon GuardDuty | Threat detection |
| AWS Security Hub | Centralized security findings |
| AWS Config | Configuration compliance monitoring |
| VPC Flow Logs | Network traffic logging |

---

### External Services Outside the Authorization Boundary

Two external SaaS services integrate with the [System Name] boundary. These services are **outside the authorization boundary** and require documentation of the data exchanged, the security controls in place, and approval from the Authorizing Official (AO).

#### Okta (Authentication)

| Attribute | Details |
|---|---|
| **Purpose** | Federated single sign-on (SSO) and multi-factor authentication (MFA) |
| **Data exchanged** | User identity tokens (SAML/OIDC); no federal payload data |
| **Location** | External SaaS — outside the boundary |
| **FedRAMP status** | Check FedRAMP Marketplace for current authorization status |
| **Risk** | Low — only identity assertions exchanged, not federal content |

If Okta holds an active FedRAMP authorization at the appropriate impact level, document this as a leveraged authorization in the SSP.

#### SendGrid (Email Delivery)

| Attribute | Details |
|---|---|
| **Purpose** | Transactional email notifications |
| **Data exchanged** | Email content, which may include user-specific data or system notifications |
| **Location** | External SaaS — outside the boundary |
| **FedRAMP status** | Check FedRAMP Marketplace for current authorization status |
| **Risk** | Medium to High — depending on the content of email notifications, federal data may leave the boundary |

**Recommendation**: Minimize the inclusion of federal data in email content. If federal data must be included in emails, ensure SendGrid holds an appropriate FedRAMP authorization or obtain AO approval with documented compensating controls. Consider using AWS SES (GovCloud) as an alternative to keep email delivery within the authorization boundary.

---

### What Is Outside the Boundary

The following are explicitly excluded from the authorization boundary:
- Agency end-user devices and workstations
- Agency network infrastructure
- Okta's underlying SaaS infrastructure
- SendGrid's underlying SaaS infrastructure
- AWS commercial (non-GovCloud) services
- Any services hosted outside of AWS GovCloud

---

### Boundary Diagram

*[INSERT FIGURE: Authorization Boundary Diagram — showing all in-boundary components within a boundary line, with Okta and SendGrid depicted outside the boundary, all data flows labeled with protocols, and the AWS GovCloud region clearly indicated]*

The boundary diagram must show:
- Public subnet (ALB, WAF)
- Private subnet (web servers, RDS, Redis)
- Management/monitoring components (CloudTrail, GuardDuty)
- External connections to Okta and SendGrid with labeled data flows
- Internet ingress/egress points
- VPC boundary and AWS GovCloud region label

# FedRAMP POA&M: Vulnerability Remediation Timeframes and Entry Guidance

*Use official FedRAMP templates from fedramp.gov — this content should be inserted into the official FedRAMP POA&M template (SSP Appendix O).*

---

## FedRAMP Vulnerability Remediation SLAs

FedRAMP mandates specific remediation timeframes based on vulnerability severity. These are not guidelines — they are enforceable SLAs, and exceeding them without an approved Deviation Request (DR) constitutes a compliance finding.

| Severity Level | CVSS Score Range | Remediation SLA | Notes |
|---|---|---|---|
| **Critical** | 9.0–10.0 | **30 calendar days** | Most urgent; active exploitation likely |
| **High** | 7.0–8.9 | **90 calendar days** | Significant risk; monitored closely by AO |
| **Moderate** | 4.0–6.9 | **180 calendar days** | 6 months from date of discovery |
| **Low** | 0.1–3.9 | **365 calendar days** | 1 year from date of discovery |

**Reference**: These SLAs are documented in the FedRAMP Continuous Monitoring Performance Management Guide.

### Key Points on SLA Calculation

- The clock starts from the **date of discovery** (typically the date the vulnerability scan first identifies the finding)
- SLAs apply to the **remediation date**, not the date a patch is released
- If a vendor has not released a patch (Vendor Dependency), document as a Vendor Dependency (VD) in the POA&M — this does not stop the SLA clock but provides context for the AO
- Exceeding an SLA without an approved Deviation Request (DR) requires immediate escalation to the AO

---

## Your Specific POA&M Item: Analysis

The finding "Vulnerability scan findings not remediated within required timeframes for Critical vulnerabilities" is itself a process/operational finding — it indicates that your vulnerability management program failed to remediate Critical findings within 30 days. This creates two distinct POA&M items:

1. **The original Critical vulnerability/vulnerabilities** that were not remediated — each should have its own POA&M row
2. **The process finding** — failure to meet the 30-day SLA — which may be raised as a separate control finding under RA-5 (Vulnerability Scanning) or SI-2 (Flaw Remediation)

---

## How to Write a Proper FedRAMP POA&M Entry

A FedRAMP POA&M entry must be a complete row in the official POA&M spreadsheet template. Below is a properly structured entry for both the process finding and an example Critical vulnerability finding.

### POA&M Entry: Process Finding (SLA Miss)

| Field | Value |
|---|---|
| **POA&M ID** | POA-2025-001 |
| **Control Identifier** | SI-2, RA-5 |
| **Weakness Name** | Critical vulnerability scan findings not remediated within FedRAMP-required 30-day timeframe |
| **Weakness Description** | Vulnerability scan results conducted on [scan date] identified Critical-severity findings (CVE-XXXX-XXXX) on [affected components]. These findings were not remediated within the FedRAMP-mandated 30-day SLA for Critical vulnerabilities, resulting in a remediation schedule overrun of [N] days. This represents a deficiency in the organization's vulnerability management process and flaw remediation procedures under SI-2 and RA-5. |
| **Source of Discovery** | Vulnerability Scan / 3PAO Annual Assessment / ConMon Review |
| **Date Discovered** | [YYYY-MM-DD] |
| **Original Due Date** | [Date discovered + 30 days] |
| **Revised Due Date** | [Updated realistic remediation date — must be approved by AO if past original SLA] |
| **Risk Level** | High |
| **Risk Adjustment** | None / Vendor Dependency / False Positive [select as applicable] |
| **Point of Contact** | [Name, Title] |
| **Resources Required** | Engineering team availability; patch testing environment; change management approval |
| **Milestone with Completion Dates** | 1. Root cause analysis complete — [date]; 2. Patches applied to Dev — [date]; 3. Patches applied to Prod — [date]; 4. Rescan confirming remediation — [date] |
| **Status** | Open — In Progress |
| **Comments / Vendor Dependency** | [If applicable: "Awaiting patch release from [Vendor] for CVE-XXXX-XXXX. Compensating control implemented: [describe control]."] |

---

### POA&M Entry: Individual Critical Vulnerability (Example)

| Field | Value |
|---|---|
| **POA&M ID** | POA-2025-002 |
| **Control Identifier** | SI-2 |
| **Weakness Name** | Critical vulnerability: [CVE-XXXX-XXXX] — [Affected component] |
| **Weakness Description** | A Critical-severity vulnerability (CVE-XXXX-XXXX, CVSS 9.8) was identified in [component/package] version [X.X] on [affected asset(s)]. This vulnerability allows [describe attack vector and impact]. The patch was available as of [date] but was not applied within the required 30-day remediation window. The affected component is [in/not in] the authorization boundary and processes/stores/transmits federal data. |
| **Source of Discovery** | Authenticated vulnerability scan — [scanner name, e.g., Tenable.sc, Qualys] |
| **Date Discovered** | [YYYY-MM-DD] |
| **Original Due Date** | [Date discovered + 30 days] |
| **Revised Due Date** | [Updated date; requires AO approval if past original SLA] |
| **Risk Level** | Critical |
| **Risk Adjustment** | None |
| **Point of Contact** | [Name, Title, Email] |
| **Resources Required** | Infrastructure team; patch testing; change control board approval; maintenance window scheduling |
| **Milestone with Completion Dates** | 1. Compensating control implemented — [date]; 2. Patch validated in staging — [date]; 3. Patch deployed to production — [date]; 4. Authenticated rescan confirming closure — [date] |
| **Compensating Controls** | [Describe interim controls: network segmentation, WAF rule, IDS signature, increased monitoring, etc.] |
| **Status** | Open — In Progress / Closed [select] |
| **Closure Evidence** | [When closed]: Rescan report date [date], scan reference [report ID], confirming CVE-XXXX-XXXX no longer detected on [asset(s)]. |

---

## Required Actions for This Finding

1. **Conduct root cause analysis** — Determine why Critical vulnerabilities were not remediated within 30 days (missing patch process, resource constraints, change management delays, etc.)

2. **Implement compensating controls immediately** — Until patches are applied, document compensating controls (e.g., network isolation of affected system, WAF rules blocking exploitation vectors, enhanced monitoring). Compensating controls do not stop the SLA clock but demonstrate good faith to the AO.

3. **Notify the AO** — SLA overruns for Critical vulnerabilities must be proactively reported to the Authorizing Official. Do not wait for the monthly ConMon report — contact the AO directly.

4. **Submit a Deviation Request (DR) if needed** — If remediation cannot be completed within the original timeframe (e.g., pending vendor patch), submit a formal DR to the AO for approval.

5. **Update the POA&M** — All open Critical findings must appear in the POA&M with updated milestone dates, status, and compensating controls. Submit with the next monthly ConMon package.

6. **Perform authenticated rescans** — After patching, conduct an authenticated vulnerability scan to confirm closure. Include the rescan report as closure evidence in the POA&M.

7. **Process improvement** — Document corrective actions to prevent recurrence: automated patch deployment pipelines, shorter change management SLAs for Critical patches, weekly vulnerability review meetings, etc.

---

## Deviation Request (DR) Process

If you cannot remediate within the required SLA:

| DR Type | When to Use |
|---|---|
| **Vendor Dependency (VD)** | No patch available from the vendor; you are waiting on a third-party fix |
| **Operational Requirement (OR)** | Remediation would break a critical operational function; risk accepted temporarily |
| **False Positive (FP)** | The scanner identified a vulnerability that does not actually exist on the system |
| **Risk Adjustment (RA)** | The finding's risk is overstated due to compensating controls or environmental factors |

All DRs require AO approval and must be documented in the POA&M with supporting evidence.

# FedRAMP POA&M: Vulnerability Remediation Timeframes and Entry Guidance

## FedRAMP Vulnerability Remediation Timeframes

FedRAMP specifies mandatory remediation timeframes for vulnerabilities based on severity. These are binding SLAs that apply to all authorized Cloud Service Providers (CSPs).

| Severity | Remediation Timeframe | Notes |
|---|---|---|
| **Critical** | **30 days** | From date of discovery; must be prioritized immediately |
| **High** | **90 days** | Must be tracked in POA&M if not remediated within this window |
| **Moderate** | **180 days** | Six months from discovery |
| **Low** | **365 days** | One year from discovery |

**Important notes on timeframes:**
- The clock starts from the date the vulnerability is first identified (typically the scan date)
- Remediation means the vulnerability is actually fixed and confirmed via rescan — not just that a patch was scheduled
- If a vendor patch is not yet available, document as a Vendor Dependency but this does not pause the SLA
- Exceeding the remediation SLA without an approved Deviation Request is a compliance violation that must be reported to the Authorizing Official (AO)

---

## Understanding Your POA&M Item

Your POA&M item — "Vulnerability scan findings not remediated within required timeframes for Critical vulnerabilities" — indicates that one or more Critical vulnerabilities went beyond the 30-day remediation window. This is a significant finding because:

1. It represents an actual security risk (unpatched Critical vulnerabilities)
2. It represents a process failure (vulnerability management program not meeting FedRAMP SLAs)
3. It must be reported to and managed with your Authorizing Official

---

## How to Write a Proper POA&M Entry

FedRAMP POA&M entries must use the official FedRAMP POA&M template. Each finding gets its own row with specific required fields.

### Required POA&M Fields

**For your Critical vulnerability SLA miss, here is a sample entry:**

---

**POA&M Item ID**: POA-2025-001

**Control Number**: SI-2 (Flaw Remediation), RA-5 (Vulnerability Scanning)

**Weakness Name**: Critical vulnerability not remediated within 30-day FedRAMP SLA

**Weakness Description**: Vulnerability scan conducted on [scan date] identified a Critical-severity vulnerability (CVE-[YEAR]-[NUMBER]) affecting [component/asset name, e.g., "web application servers running Apache version X.X"]. The vulnerability has a CVSS score of [score] and allows [brief description of attack, e.g., "remote code execution by unauthenticated attackers"]. The 30-day remediation SLA expired on [due date] without the vulnerability being remediated due to [reason, e.g., "patch testing delays and change management scheduling constraints"]. The affected component processes and stores federal data and is within the authorization boundary.

**Source of Discovery**: Vulnerability scan — [scanner name and version, e.g., Tenable Nessus, Qualys]

**Date Discovered**: [YYYY-MM-DD]

**Scheduled Completion Date**: [New realistic completion date — must be reviewed/approved by AO]

**Milestones with Completion Dates**:
- Milestone 1: Apply patch to development/staging environment — [date]
- Milestone 2: Complete patch validation testing — [date]
- Milestone 3: Apply patch to production environment — [date]
- Milestone 4: Conduct authenticated vulnerability rescan to confirm remediation — [date]

**Risk Level**: Critical

**Point of Contact**: [Name, Title, Email]

**Resources Required**: [Engineering hours, testing environment, change management approval, maintenance window]

**Status**: Open — In Progress

**Compensating Controls**: [Describe any interim mitigations applied while remediation is pending, e.g., "Network ACLs implemented to restrict access to the affected service from external sources; IDS signatures deployed to detect exploitation attempts; increased log monitoring for signs of exploitation."]

---

## Steps to Address This Finding

1. **Immediate notification**: Contact your AO immediately. Do not wait for the monthly ConMon report — Critical SLA misses should be proactively disclosed.

2. **Implement compensating controls now**: Until the patch is applied, put mitigating controls in place and document them in the POA&M.

3. **Prioritize remediation**: Schedule emergency patching if needed. For Critical vulnerabilities, standard change management processes should have an expedited track.

4. **Submit a Deviation Request if needed**: If a vendor patch is not available, submit a Deviation Request (Vendor Dependency type) to your AO documenting the situation and your compensating controls.

5. **Rescan after remediation**: After applying the patch, run an authenticated vulnerability scan to confirm the vulnerability is gone. Include the rescan report as closure evidence.

6. **Root cause and process improvement**: Document what went wrong in your vulnerability management process and what changes you are making to prevent recurrence. Your AO will likely ask for this.

7. **Update monthly ConMon reports**: Include this finding and its status in every monthly ConMon package until it is closed.

# GDPR Compliance Checklist for US-Based SaaS Company with EU Customers

> **Legal Advice Disclaimer**: This guidance is informational and based on the GDPR text and established regulatory guidance. It does not constitute legal advice. For matters involving significant compliance risk, supervisory authority interaction, or complex cross-border scenarios, consult a qualified data protection lawyer or your DPO.

## Overview

As a US-based SaaS company with a European customer, you are now subject to the GDPR by virtue of the **territorial scope** rules under **Article 3(2)**. Even without an EU establishment, GDPR applies because you are offering services to data subjects in the EU ("targeting criterion"). You act as both a **data controller** (for your employee data and your own analytics) and potentially a **data processor** (for your customer's end-user data, depending on contract terms) — see Art. 4(7) and Art. 4(8).

---

## Part 1: Establish Your Legal Foundations

### 1.1 Determine Roles (Art. 4(7–8))
- [ ] Confirm whether you are a **controller**, **processor**, or both for each processing activity
- [ ] For customer account data: you are likely a **processor** acting on behalf of your EU customer (the controller)
- [ ] For employee data: you are the **controller**
- [ ] For usage analytics: you are typically the **controller** — assess whether this data relates to EU individuals

### 1.2 Identify and Document All Processing Activities — Record of Processing Activities (Art. 30)
You must maintain a RoPA covering:
- [ ] Name and contact details of the controller/processor (Art. 30(1)(a))
- [ ] Purposes of each processing activity (Art. 30(1)(b))
- [ ] Categories of data subjects and personal data (Art. 30(1)(c))
- [ ] Categories of recipients (Art. 30(1)(d))
- [ ] Third-country transfers and applicable safeguards (Art. 30(1)(e))
- [ ] Retention periods (Art. 30(1)(f))
- [ ] Description of security measures (Art. 30(1)(g))

**Note**: RoPA is mandatory for organisations processing EU personal data, regardless of EU establishment, when processing is not occasional (Art. 30(5)).

### 1.3 Establish a Lawful Basis for Each Processing Activity (Art. 6(1))
| Processing Activity | Recommended Lawful Basis | Article |
|---------------------|--------------------------|---------|
| Employee data (payroll, HR) | Legal obligation / Contract | Art. 6(1)(b)(c) |
| Customer account data | Contract performance | Art. 6(1)(b) |
| Usage analytics (aggregated) | Legitimate interests (LIA required) | Art. 6(1)(f) |
| Usage analytics (individual tracking) | Consent or Legitimate interests + LIA | Art. 6(1)(a)(f) |
| Marketing to existing customers | Legitimate interests | Art. 6(1)(f) |

- [ ] Document the chosen lawful basis for each activity in your RoPA
- [ ] For legitimate interests: complete a **Legitimate Interests Assessment (LIA)** covering purpose, necessity, and balancing tests (Art. 6(1)(f); Recital 47)

---

## Part 2: Transparency Obligations

### 2.1 Privacy Notices (Art. 13 & 14)
For personal data collected directly from individuals, provide a privacy notice at the point of collection (Art. 13) containing:
- [ ] Identity and contact details of the controller (Art. 13(1)(a))
- [ ] Contact details of any Data Protection Officer if appointed (Art. 13(1)(b))
- [ ] Purposes and lawful basis for each processing activity (Art. 13(1)(c))
- [ ] Legitimate interests pursued (if relied upon) (Art. 13(1)(d))
- [ ] Recipients or categories of recipients (Art. 13(1)(e))
- [ ] Details of international transfers and safeguards (Art. 13(1)(f))
- [ ] Retention periods (Art. 13(2)(a))
- [ ] All data subject rights (Art. 13(2)(b))
- [ ] Right to withdraw consent (Art. 13(2)(c))
- [ ] Right to lodge a complaint with a supervisory authority (Art. 13(2)(d))
- [ ] Whether provision of data is statutory/contractual and consequences of not providing (Art. 13(2)(e))

For data obtained indirectly (e.g., from your EU customer about their end users), Art. 14 notice requirements apply.

- [ ] **Privacy notice must be in plain, intelligible language** accessible to a layperson (Art. 12(1))
- [ ] Create a publicly accessible privacy policy on your website covering EU users

### 2.2 EU Representative (Art. 27)
If you have no EU establishment, you **must designate an EU Representative** in a Member State where your EU data subjects are located — unless processing is occasional and does not involve special category data or large-scale criminal data.
- [ ] Appoint an EU Representative and publicise their contact details
- [ ] Your EU Representative can be contacted by supervisory authorities and data subjects

---

## Part 3: Data Subject Rights (Art. 15–22)

Establish procedures to handle the following rights within **one calendar month** (extendable by two months for complex requests) per Art. 12(3):

- [ ] **Right of access** (Art. 15): Provide a copy of personal data held and supplementary information
- [ ] **Right to rectification** (Art. 16): Correct inaccurate or incomplete data
- [ ] **Right to erasure ("right to be forgotten")** (Art. 17): Delete data when no longer necessary, consent withdrawn, or objection upheld
- [ ] **Right to restriction** (Art. 18): Restrict processing in specified circumstances
- [ ] **Right to data portability** (Art. 20): Provide data in machine-readable format where lawful basis is consent or contract
- [ ] **Right to object** (Art. 21): Honour objections to processing based on legitimate interests or for direct marketing (absolute right for marketing)
- [ ] **Rights related to automated decision-making** (Art. 22): Do not subject individuals to solely automated decisions with significant effects without safeguards

**Implementation checklist**:
- [ ] Create a data subject rights intake process (email, web form)
- [ ] Verify identity of requesters without excessive burden (Art. 12(6))
- [ ] Respond free of charge; may charge for manifestly unfounded/excessive requests (Art. 12(5))
- [ ] Document all requests and responses for accountability (Art. 5(2))

---

## Part 4: Processor and Third-Party Obligations

### 4.1 Data Processing Agreements (Art. 28)
If you receive personal data from your EU customer to process on their behalf, you **must** sign a DPA. Equally, for any sub-processors you engage:
- [ ] Execute a DPA with your EU customer covering all Art. 28(3) mandatory clauses
- [ ] Obtain prior written consent from your customer before engaging sub-processors (Art. 28(2))
- [ ] Execute DPAs with all sub-processors (cloud infrastructure, analytics tools, support platforms)
- [ ] Maintain a list of sub-processors

### 4.2 International Data Transfers (Art. 44–49)
As a US company receiving EU personal data, a transfer mechanism is **mandatory** for every data flow from the EU to the US:
- [ ] **EU-US Data Privacy Framework (DPF)**: Certify your organisation under the DPF (replaces Privacy Shield post-Schrems II) — this provides an adequacy-equivalent basis
- [ ] Alternatively, execute **Standard Contractual Clauses (SCCs)** approved by the European Commission (2021 SCCs)
- [ ] Complete a **Transfer Impact Assessment (TIA)** where SCCs are used, to assess whether US law undermines the protection
- [ ] Document the chosen transfer mechanism in your RoPA and DPAs

---

## Part 5: Security Measures (Art. 32)

Implement appropriate technical and organisational measures:
- [ ] **Encryption** of personal data at rest and in transit (Art. 32(1)(a))
- [ ] **Pseudonymisation** of data where feasible (Art. 32(1)(a))
- [ ] **Access controls**: role-based access, least privilege principle
- [ ] **Ongoing confidentiality, integrity, availability** of processing systems (Art. 32(1)(b))
- [ ] **Incident response plan** and ability to restore data after incidents (Art. 32(1)(c)(d))
- [ ] **Regular testing** of security measures — penetration testing, vulnerability scans (Art. 32(1)(d))
- [ ] **Staff training** on data protection

### 5.1 Privacy by Design and Default (Art. 25)
- [ ] Integrate data protection into system design from the outset
- [ ] Default settings should be the most privacy-protective option (e.g., analytics opt-out by default)

---

## Part 6: Breach Notification (Art. 33–34)

- [ ] Establish a **breach detection and response procedure**
- [ ] Report qualifying breaches to the **lead supervisory authority within 72 hours** of becoming aware (Art. 33(1))
- [ ] Notify affected data subjects "without undue delay" if breach is high risk to their rights and freedoms (Art. 34(1))
- [ ] Maintain an internal **breach register** for all breaches, including those not reported to authorities (Art. 33(5))

---

## Part 7: Data Protection Impact Assessment (Art. 35)

A DPIA is mandatory before commencing processing that is **likely to result in high risk**:
- [ ] Assess whether any processing activity requires a DPIA (e.g., large-scale profiling, systematic monitoring, special category data)
- [ ] Usage analytics involving individual profiling may trigger a DPIA
- [ ] Conduct DPIA with DPO involvement if appointed (Art. 35(2))

---

## Part 8: Data Retention (Art. 5(1)(e))

- [ ] Define retention periods for each data category (employee data, customer data, analytics)
- [ ] Implement automated deletion or anonymisation at end of retention period
- [ ] Apply retention policy to backups as well
- [ ] Document retention schedules in your RoPA

---

## Part 9: Data Protection Officer (Art. 37)

A DPO is mandatory if you:
- Process special category data on a large scale (Art. 9), or
- Carry out large-scale systematic monitoring of individuals

For a SaaS company at early EU stage, a DPO may not yet be mandatory — but appointing one (internal or external) is a strong best-practice signal to regulators and customers.
- [ ] Assess DPO requirement (Art. 37(1))
- [ ] If appointed, register DPO with supervisory authority (Art. 37(7))

---

## Priority Action Plan (Immediate — First 30 Days)

| Priority | Action | Article |
|----------|--------|---------|
| 1 | Appoint EU Representative | Art. 27 |
| 2 | Execute DPA with EU customer | Art. 28 |
| 3 | Implement international transfer mechanism (DPF or SCCs) | Art. 44–46 |
| 4 | Update Privacy Notice (website + product) | Art. 13 |
| 5 | Create RoPA for all three processing activities | Art. 30 |
| 6 | Establish data subject rights intake process | Art. 12–22 |
| 7 | Implement breach detection and 72-hour notification process | Art. 33 |
| 8 | Review and document retention periods | Art. 5(1)(e) |
| 9 | Conduct LIA for analytics processing | Art. 6(1)(f) |
| 10 | Assess DPIA requirement for analytics | Art. 35 |

---

## Specific Notes on Your Three Data Types

### Employee Data
- High-risk area: HR/employment data processing warrants specialist legal advice, particularly as employment law derogations vary significantly across Member States (Art. 88)
- Lawful bases: primarily contract (Art. 6(1)(b)) and legal obligation (Art. 6(1)(c))
- Do not rely on employee consent as it is rarely "freely given" due to power imbalance (Recital 43)

### Customer Account Data
- If you process this on behalf of your EU customer, you are a **processor** — execute a DPA (Art. 28)
- If you also use it for your own analytics, you become a controller for that secondary purpose — requires separate lawful basis and disclosure in your privacy notice

### Usage Analytics
- Identify whether analytics data constitutes personal data (IP addresses, device IDs, and cookies are personal data per Art. 4(1); Recital 30)
- If tracking individual behaviour: consider consent via cookie banner (Art. 7; ePrivacy Directive)
- If using aggregated/anonymised analytics only: GDPR does not apply to truly anonymised data (Recital 26)

# GDPR Compliance Checklist for US-Based SaaS Company with EU Customers

## Overview

Congratulations on your first European customer — but this also means the General Data Protection Regulation (GDPR) now applies to your business, even though you are based in the US. The GDPR has broad territorial reach: it applies to any organisation that offers goods or services to EU residents, regardless of where the organisation is located.

Here is a practical compliance checklist covering your three data types.

---

## Step 1: Understand Your Role

First, determine whether you are a **data controller** or a **data processor** (or both):

- **Data controller**: You decide why and how personal data is processed. This applies to your employee data and your own analytics.
- **Data processor**: You process data on behalf of another controller. If your EU customer sends you their end-user data to manage within your SaaS platform, you are likely a processor for that data.

This distinction matters because controllers and processors have different obligations under GDPR.

---

## Step 2: Establish a Legal Basis for Processing

Every processing activity must have a valid legal basis. The main options are:

| Data Type | Likely Legal Basis |
|-----------|-------------------|
| Employee data | Contract performance + legal obligation |
| Customer account data | Contract performance (needed to provide the service) |
| Usage analytics | Legitimate interests (for aggregate/internal use) or Consent (for individual tracking) |

Document your chosen legal basis for each activity. If you rely on **legitimate interests**, you must conduct a balancing test showing your interests do not override individuals' rights.

---

## Step 3: Create or Update Your Privacy Notice

Your privacy policy/notice must tell users:
- Who you are and how to contact you
- What data you collect and why
- The legal basis for each processing activity
- How long you keep data
- Who you share data with (including third-party tools)
- What rights users have and how to exercise them
- How to file a complaint with a European data protection authority

The notice must be written in clear, plain language — not legal jargon.

---

## Step 4: Handle Data Subject Rights

EU residents have significant rights over their personal data. You must be able to respond to:

- **Right to access**: Provide a copy of all personal data you hold about them, typically within 30 days
- **Right to correction**: Fix inaccurate data
- **Right to deletion ("right to be forgotten")**: Delete data in certain circumstances
- **Right to restriction**: Pause processing in some situations
- **Right to data portability**: Provide their data in a usable format
- **Right to object**: Stop certain types of processing, especially direct marketing

**Action items**:
- Set up an email address or web form for privacy requests
- Create an internal procedure with clear timelines (30-day response window)
- Document all requests and your responses

---

## Step 5: Execute a Data Processing Agreement (DPA) with Your EU Customer

Since your EU customer is sharing their users' data with you (to run on your platform), you need a signed **Data Processing Agreement** with them. This is legally required and most enterprise EU customers will ask for this before signing a commercial contract. The DPA should cover:

- The scope and purpose of data processing
- The types of data and categories of data subjects
- Your security obligations
- Sub-processor rules (who else can you share data with, and under what conditions)
- Data breach notification procedures
- Data deletion/return obligations at contract end

---

## Step 6: Address International Data Transfers

Transferring EU personal data to the US requires a legal mechanism. The main options are:

- **EU-US Data Privacy Framework (DPF)**: Self-certify your company through the US Department of Commerce. This is the simplest route.
- **Standard Contractual Clauses (SCCs)**: Contractual clauses approved by the EU that can be incorporated into your agreements with EU customers.

You likely need one of these in place before your EU customer can lawfully send you their users' data.

---

## Step 7: Implement Security Measures

GDPR requires "appropriate technical and organisational measures" to protect personal data. Practically, this means:

- Encryption of data in transit (TLS) and at rest
- Access controls and role-based permissions
- Multi-factor authentication for systems handling personal data
- Regular security testing
- Staff training on data privacy and security
- A documented incident response plan

---

## Step 8: Set Up Breach Notification Procedures

If you experience a data breach involving EU personal data, you must:

- Notify the relevant EU data protection authority within **72 hours** of discovering the breach
- Notify affected individuals if the breach poses a high risk to their rights and freedoms
- Keep an internal log of all breaches

Build this into your incident response runbook now, before a breach happens.

---

## Step 9: Appoint an EU Representative

Because you have no EU office, you must designate a **representative in the EU** — an individual or company in an EU Member State who can be contacted by regulators and data subjects. Several service providers offer this service.

---

## Step 10: Review Data Retention

- Define how long you keep each type of data (employee records, customer data, analytics logs)
- Delete or anonymise data when no longer needed
- Apply retention rules to backups as well as live systems

---

## Step 11: Consider Whether You Need a Data Protection Officer (DPO)

A DPO may be required if you process large volumes of EU personal data or engage in systematic profiling. For a company at your stage, it may not be mandatory yet, but appointing an external DPO or privacy counsel is a best practice that many EU enterprise customers will expect.

---

## Checklist Summary by Data Type

### Employee Data
- [ ] Privacy notice provided to EU employees at time of hire
- [ ] Legal basis documented (contract + legal obligation)
- [ ] Retention policy set (typically aligned with employment law)
- [ ] HR data access restricted to authorised personnel

### Customer Account Data
- [ ] DPA signed with EU customer
- [ ] International transfer mechanism in place (DPF or SCCs)
- [ ] Privacy notice/terms updated to reflect data use
- [ ] Deletion procedure in place at contract end

### Usage Analytics
- [ ] Determine if analytics data is personal data (IP addresses, device IDs, user IDs are personal data)
- [ ] If tracking individuals: cookie consent banner required for EU visitors
- [ ] Legal basis documented
- [ ] Consider anonymising analytics data to reduce compliance burden

---

## Immediate Priorities (Do These First)

1. Sign DPA with your EU customer
2. Set up international transfer mechanism (DPF certification is fastest)
3. Update your privacy policy
4. Appoint EU Representative
5. Create a data subject rights request process
6. Document your data retention periods

Getting these six items done will put you in a much stronger compliance posture for your initial EU customer relationship.

# GDPR-Compliant Data Processing Agreement (DPA)

> **Legal Advice Disclaimer**: This template is informational and based on the GDPR text and established regulatory guidance (including European Commission guidance on Art. 28). It does not constitute legal advice. Consult a qualified data protection lawyer or your DPO before executing this agreement, particularly for high-risk processing or complex cross-border scenarios.

---

## DATA PROCESSING AGREEMENT

**This Data Processing Agreement ("DPA")** is entered into between:

**[CUSTOMER NAME]**, a company registered in [JURISDICTION] with company number [NUMBER], having its registered address at [ADDRESS] ("**Controller**", "**Customer**")

and

**[YOUR COMPANY NAME]**, a company registered in [JURISDICTION] with company number [NUMBER], having its registered address at [ADDRESS] ("**Processor**", "**Provider**")

together the "**Parties**".

This DPA forms part of and is incorporated into the Master Subscription Agreement / Terms of Service between the Parties dated [DATE] (the "**Main Agreement**").

---

## RECITALS

WHEREAS, the Controller wishes to use the Provider's SaaS services as described in the Main Agreement, which involves the Provider processing personal data on behalf of the Controller;

WHEREAS, the Parties intend to set out their respective obligations and rights in connection with such processing, as required by Article 28 of Regulation (EU) 2016/679 (the "**GDPR**");

NOW THEREFORE, the Parties agree as follows:

---

## 1. DEFINITIONS

1.1 **"GDPR"** means Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data.

1.2 **"Personal Data"**, **"Processing"**, **"Controller"**, **"Processor"**, **"Data Subject"**, **"Supervisory Authority"**, **"Personal Data Breach"**, and **"Special Categories of Personal Data"** shall have the meanings given in Article 4 GDPR.

1.3 **"Sub-processor"** means any processor engaged by the Processor to carry out processing activities in respect of the Controller's Personal Data.

1.4 **"Data Subject Rights Request"** means any request from a Data Subject exercising rights under Articles 15–22 GDPR.

1.5 **"Applicable Data Protection Law"** means the GDPR, the UK GDPR (where applicable), and any implementing legislation in the relevant Member State(s).

---

## 2. SCOPE AND ROLES (Art. 28(3) preamble; Art. 4(7–8))

2.1 This DPA applies to all Processing of Personal Data carried out by the Processor on behalf of the Controller in the course of providing the SaaS services under the Main Agreement.

2.2 The Controller is the data controller as defined in Art. 4(7) GDPR. The Processor is a data processor as defined in Art. 4(8) GDPR, processing Personal Data solely on behalf of and in accordance with the Controller's documented instructions.

2.3 **Details of Processing** (as required by Art. 28(3) and Annex to this DPA):
- Subject matter, nature, and purpose: as set out in Annex 1
- Type of Personal Data: as set out in Annex 1
- Categories of Data Subjects: as set out in Annex 1
- Duration of Processing: the term of the Main Agreement plus any post-termination deletion period

---

## 3. PROCESSOR'S OBLIGATIONS — INSTRUCTIONS (Art. 28(3)(a))

3.1 The Processor shall process Personal Data only on the documented instructions of the Controller, including with regard to transfers to third countries, unless required to do so by applicable EU or Member State law; in such a case, the Processor shall inform the Controller of that legal requirement before processing, unless that law prohibits such information (Art. 28(3)(a)).

3.2 The Processor shall immediately notify the Controller if, in its opinion, an instruction infringes the GDPR or applicable data protection law (Art. 28(3) in fine).

---

## 4. CONFIDENTIALITY (Art. 28(3)(b))

4.1 The Processor shall ensure that persons authorised to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality (Art. 28(3)(b)).

4.2 The Processor shall limit access to Personal Data to personnel who need access on a need-to-know basis for the provision of the services.

---

## 5. SECURITY MEASURES (Art. 28(3)(c); Art. 32)

5.1 The Processor shall implement and maintain appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account:
- (a) the state of the art, costs of implementation, and the nature, scope, context, and purposes of Processing;
- (b) the risk of varying likelihood and severity for the rights and freedoms of natural persons (Art. 32(1)).

5.2 Such measures shall include as appropriate (Art. 32(1)(a–d)):
- (a) Pseudonymisation and encryption of Personal Data;
- (b) Ongoing confidentiality, integrity, availability, and resilience of processing systems;
- (c) Ability to restore availability and access to Personal Data in a timely manner in the event of an incident;
- (d) A process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures.

5.3 The Processor's current security measures are described in Annex 2.

5.4 The Processor shall evaluate risks in accordance with Art. 32(2) and shall take steps to mitigate those risks.

---

## 6. SUB-PROCESSORS (Art. 28(2); Art. 28(4))

6.1 The Processor shall not engage Sub-processors without the **prior specific or general written authorisation** of the Controller (Art. 28(2)).

6.2 Where the Controller provides general written authorisation (which it does by entering into this DPA), the Processor shall:
- (a) Notify the Controller of any intended changes concerning the addition or replacement of Sub-processors, giving the Controller the opportunity to object;
- (b) Provide at least [30] days' prior written notice of Sub-processor changes.

6.3 The list of currently authorised Sub-processors is set out in Annex 3.

6.4 Where the Processor engages Sub-processors, it shall impose the **same data protection obligations** as set out in this DPA on the Sub-processor by way of a written contract (Art. 28(4)). The Processor shall remain fully liable to the Controller for the performance of the Sub-processor's obligations.

6.5 If a Sub-processor fails to fulfil its data protection obligations, the Processor shall remain fully liable to the Controller (Art. 28(4)).

---

## 7. DATA SUBJECT RIGHTS ASSISTANCE (Art. 28(3)(e))

7.1 Taking into account the nature of the Processing, the Processor shall assist the Controller by appropriate technical and organisational measures, insofar as possible, in fulfilling the Controller's obligation to respond to Data Subject Rights Requests under Chapter III GDPR (Arts. 15–22), including:
- Right of access (Art. 15)
- Right to rectification (Art. 16)
- Right to erasure (Art. 17)
- Right to restriction of processing (Art. 18)
- Right to data portability (Art. 20)
- Right to object (Art. 21)

7.2 The Processor shall notify the Controller of any Data Subject Rights Requests it receives without undue delay and shall not respond to such requests directly without the Controller's instruction, except to inform the Data Subject that it should contact the Controller.

---

## 8. CONTROLLER OBLIGATIONS ASSISTANCE (Art. 28(3)(f))

8.1 The Processor shall assist the Controller in ensuring compliance with the obligations pursuant to Arts. 32–36 GDPR, taking into account the nature of processing and information available to the Processor, including:
- Security of processing (Art. 32)
- Breach notification to the supervisory authority (Art. 33)
- Communication of a breach to data subjects (Art. 34)
- Data Protection Impact Assessments (Art. 35)
- Prior consultation with supervisory authorities (Art. 36)

---

## 9. PERSONAL DATA BREACH NOTIFICATION (Art. 33; Art. 28(3)(f))

9.1 The Processor shall notify the Controller of a Personal Data Breach **without undue delay** and, where feasible, **no later than 48 hours** after becoming aware of a breach (to allow the Controller to meet its own 72-hour deadline under Art. 33(1)).

9.2 Such notification shall, to the extent possible, include (Art. 33(3)):
- (a) A description of the nature of the breach, including categories and approximate number of Data Subjects and Personal Data records concerned;
- (b) Contact details of the data protection officer or other contact point;
- (c) Likely consequences of the breach;
- (d) Measures taken or proposed to address the breach.

9.3 Where information cannot all be provided at the same time, it may be provided in phases (Art. 33(4)).

9.4 The Processor shall maintain a breach register and cooperate with the Controller in any supervisory authority investigation.

---

## 10. DELETION AND RETURN OF DATA (Art. 28(3)(g))

10.1 At the choice of the Controller, the Processor shall, upon termination of the Main Agreement or upon request:
- (a) Delete all Personal Data and existing copies; or
- (b) Return all Personal Data to the Controller in a portable format;

unless EU or Member State law requires retention of the Personal Data (Art. 28(3)(g)).

10.2 The Processor shall confirm in writing that deletion has been completed within [30] days of the termination date.

10.3 Deletion shall include Personal Data held in backups within [90] days of the termination date, consistent with the Processor's backup retention cycle.

---

## 11. AUDIT AND INSPECTION RIGHTS (Art. 28(3)(h))

11.1 The Processor shall make available to the Controller all information necessary to demonstrate compliance with the obligations in Article 28 GDPR and shall allow for and contribute to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller (Art. 28(3)(h)).

11.2 Where a third-party auditor is used, the Controller shall give the Processor reasonable prior notice (no fewer than [30] days), ensure the auditor is subject to confidentiality obligations, and bear the costs of the audit.

11.3 The Processor may satisfy this obligation in the first instance by providing current third-party security certifications (e.g., ISO 27001, SOC 2 Type II) or audit reports. The Controller may request an on-site audit where it has reasonable grounds to believe such certifications are insufficient.

11.4 The Processor shall immediately notify the Controller if an instruction under this clause would, in the Processor's opinion, infringe the GDPR (Art. 28(3)(h) in fine).

---

## 12. INTERNATIONAL DATA TRANSFERS (Art. 44–49)

12.1 The Processor shall not transfer Personal Data to a third country outside the EEA unless:
- (a) An adequacy decision applies to that third country (Art. 45); or
- (b) Appropriate safeguards are in place, including Standard Contractual Clauses (SCCs) approved by the European Commission (Art. 46(2)(c)); or
- (c) Another approved transfer mechanism applies (Art. 46–49).

12.2 Where the Processor is established outside the EEA (e.g., in the US), the Parties shall execute the applicable EU SCCs (Controller-to-Processor modules) as Annex 4 to this DPA, or the Processor shall maintain a valid certification under the EU-US Data Privacy Framework.

12.3 The Processor shall conduct a Transfer Impact Assessment (TIA) where SCCs are relied upon and make this available to the Controller on request.

---

## 13. LIABILITY AND INDEMNIFICATION

13.1 Each Party shall be liable for the damage caused by Processing which infringes GDPR in accordance with Art. 82 GDPR.

13.2 The Processor is exempt from liability under Art. 82(3) if it proves it is not in any way responsible for the event giving rise to the damage.

13.3 Each Party's liability under this DPA shall be subject to the limitations set out in the Main Agreement, to the extent permitted by applicable law.

---

## 14. TERM AND TERMINATION

14.1 This DPA shall remain in effect for the duration of the Main Agreement and shall automatically terminate upon termination or expiry of the Main Agreement.

14.2 Obligations under Sections 10 (data deletion) and 11 (audit) shall survive termination.

---

## 15. GOVERNING LAW AND JURISDICTION

15.1 This DPA shall be governed by the laws of [GOVERNING LAW JURISDICTION — recommend EU Member State law where Controller is established].

15.2 The courts of [JURISDICTION] shall have exclusive jurisdiction to resolve any disputes arising out of this DPA.

---

## ANNEX 1 — DETAILS OF PROCESSING (Art. 28(3); Art. 30)

| Element | Details |
|---------|---------|
| Subject matter | Provision of SaaS services as described in the Main Agreement |
| Nature of Processing | Storage, retrieval, transmission, analysis, deletion |
| Purpose of Processing | To provide the contracted SaaS services to the Controller |
| Duration | Term of Main Agreement + [30 days] post-termination deletion period |
| **Type of Personal Data** | [e.g., names, email addresses, account credentials, usage data, [PLACEHOLDER]] |
| **Special Categories** | [None / specify if applicable — requires explicit justification under Art. 9] |
| **Categories of Data Subjects** | [e.g., Controller's employees, Controller's end customers, [PLACEHOLDER]] |

---

## ANNEX 2 — TECHNICAL AND ORGANISATIONAL SECURITY MEASURES (Art. 32)

The Processor implements the following measures:

**Access Control**
- [ ] Role-based access controls (RBAC) with least-privilege principle
- [ ] Multi-factor authentication (MFA) for all systems handling Personal Data
- [ ] Regular access reviews and prompt deprovisioning

**Encryption**
- [ ] Encryption of Personal Data in transit using TLS 1.2 or higher
- [ ] Encryption of Personal Data at rest using AES-256 or equivalent
- [ ] Encryption key management procedures

**Pseudonymisation**
- [ ] Personal Data pseudonymised where technically feasible in accordance with Art. 25(1)

**Availability and Resilience**
- [ ] Regular automated backups with tested recovery procedures
- [ ] Redundant infrastructure / high availability architecture
- [ ] Business continuity and disaster recovery plan

**Monitoring and Testing**
- [ ] Intrusion detection and prevention systems
- [ ] Security event logging and monitoring
- [ ] Annual penetration testing by qualified third parties
- [ ] Vulnerability management programme

**Organisational**
- [ ] Data protection training for all staff handling Personal Data
- [ ] Documented security policies and procedures
- [ ] Designated security and privacy contact/DPO
- [ ] Incident response plan and breach register

*[PLACEHOLDER: Add any current certifications, e.g., ISO 27001 certificate number, SOC 2 Type II report date]*

---

## ANNEX 3 — AUTHORISED SUB-PROCESSORS

| Sub-Processor Name | Purpose | Location | Transfer Mechanism |
|-------------------|---------|----------|--------------------|
| [e.g., AWS / GCP / Azure] | Cloud infrastructure | [e.g., Ireland, EU] | [e.g., Adequacy / SCCs] |
| [e.g., Stripe] | Payment processing | [e.g., US] | [e.g., SCCs + DPF] |
| [PLACEHOLDER] | [PLACEHOLDER] | [PLACEHOLDER] | [PLACEHOLDER] |

---

## ANNEX 4 — INTERNATIONAL TRANSFER MECHANISM

*[Complete if the Processor is established outside the EEA or uses non-EEA sub-processors.]*

**Option A**: The Parties execute the European Commission Standard Contractual Clauses (Module 2: Controller-to-Processor) as adopted by Commission Implementing Decision (EU) 2021/914 of 4 June 2021, which are incorporated into this DPA by reference.

**Option B**: The Processor certifies under the EU-US Data Privacy Framework (or equivalent adequacy mechanism), details as follows: [PLACEHOLDER — DPF certification ID and date].

---

## SIGNATURES

**For and on behalf of the Controller:**

Name: _______________________
Title: _______________________
Signature: _______________________
Date: _______________________

**For and on behalf of the Processor:**

Name: _______________________
Title: _______________________
Signature: _______________________
Date: _______________________

---

*This DPA template covers all mandatory elements of Article 28(3) GDPR. Legal review is strongly recommended before execution, particularly regarding: governing law, liability caps, Sub-processor notification periods, audit rights balancing, and the applicable international transfer mechanism.*

# GDPR-Compliant Data Processing Agreement (DPA) Template

> **Disclaimer**: This template is for informational purposes and should be reviewed by qualified legal counsel before use. It does not constitute legal advice.

---

## DATA PROCESSING AGREEMENT

**This Data Processing Agreement** ("DPA") is entered into between:

**[CUSTOMER NAME]**, a company incorporated in [COUNTRY/STATE], with its principal place of business at [ADDRESS] ("**Customer**" or "**Controller**")

and

**[YOUR COMPANY NAME]**, a company incorporated in [COUNTRY/STATE], with its principal place of business at [ADDRESS] ("**Provider**" or "**Processor**")

This DPA is incorporated into and forms part of the Master Services Agreement / Terms of Service between the Parties ("**Main Agreement**") and applies where the Provider processes Personal Data on behalf of the Customer.

---

## 1. DEFINITIONS

For the purposes of this DPA:

- **"GDPR"** means the General Data Protection Regulation (EU) 2016/679.
- **"Personal Data"** means any information relating to an identified or identifiable natural person.
- **"Processing"** means any operation or set of operations performed on Personal Data.
- **"Controller"** means the entity that determines the purposes and means of the processing of Personal Data.
- **"Processor"** means the entity that processes Personal Data on behalf of a Controller.
- **"Sub-processor"** means any third party engaged by the Processor to process Personal Data on behalf of the Controller.
- **"Data Subject"** means the natural person to whom Personal Data relates.
- **"Personal Data Breach"** means a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Personal Data.

---

## 2. SCOPE

2.1 This DPA applies to all Processing of Personal Data by the Processor in connection with the services provided under the Main Agreement.

2.2 The details of the Processing (categories of data, data subjects, purpose, and duration) are set out in Schedule 1 to this DPA.

---

## 3. PROCESSOR OBLIGATIONS

### 3.1 Processing on Instructions Only

The Processor shall process Personal Data only on the documented instructions of the Controller, as set out in this DPA and the Main Agreement. The Processor shall inform the Controller promptly if it believes any instruction infringes applicable data protection law.

### 3.2 Confidentiality

The Processor shall ensure that all personnel authorised to process Personal Data are bound by an appropriate obligation of confidentiality and are trained on data protection requirements.

### 3.3 Security

The Processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk of the Processing, including:

- Encryption of Personal Data in transit and at rest
- Measures to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems
- The ability to restore access to Personal Data in a timely manner following a technical incident
- A process for regularly testing and evaluating the effectiveness of security measures

A description of the security measures currently in place is set out in Schedule 2.

### 3.4 Sub-processors

- The Processor shall not engage any Sub-processor without the prior written consent of the Controller (which may be given generally in advance through this DPA).
- The Processor shall maintain an up-to-date list of Sub-processors and provide advance notice (at least 30 days) of any changes, giving the Controller opportunity to object.
- The Processor shall impose equivalent data protection obligations on all Sub-processors through a written contract.
- The Processor remains liable for the acts and omissions of its Sub-processors.
- Current Sub-processors are listed in Schedule 3.

### 3.5 Assistance with Data Subject Rights

The Processor shall, insofar as possible, assist the Controller in responding to requests from Data Subjects exercising their rights under the GDPR, including rights of access, rectification, erasure, restriction, portability, and objection.

The Processor shall promptly forward to the Controller any Data Subject request it receives and shall not respond to such requests directly without the Controller's authorisation.

### 3.6 Assistance with Controller Obligations

The Processor shall provide reasonable assistance to the Controller in:
- Complying with its security obligations
- Notifying data breaches to the supervisory authority and affected individuals
- Conducting Data Protection Impact Assessments (DPIAs)
- Prior consultation with supervisory authorities

### 3.7 Breach Notification

The Processor shall notify the Controller of any Personal Data Breach without undue delay and in any event within 48 hours of becoming aware of the breach. The notification shall include:
- A description of the nature of the breach
- Contact details for the data protection contact
- Likely consequences of the breach
- Measures taken or proposed to address the breach

### 3.8 Deletion and Return of Data

Upon termination of the Main Agreement or upon the Controller's request, the Processor shall, at the Controller's choice:
- Return all Personal Data to the Controller; or
- Securely delete all Personal Data and confirm deletion in writing within 30 days

unless applicable law requires the Processor to retain the data.

### 3.9 Audit and Inspection Rights

The Processor shall make available all information necessary to demonstrate compliance with this DPA and shall allow for and cooperate with audits conducted by the Controller or its appointed auditors. The Processor may satisfy this requirement by providing current third-party audit reports (such as SOC 2 or ISO 27001 certifications).

---

## 4. CONTROLLER OBLIGATIONS

4.1 The Controller warrants that it has a valid lawful basis for the Processing it instructs the Processor to carry out.

4.2 The Controller shall provide all necessary privacy notices to Data Subjects and, where required, obtain necessary consents before providing Personal Data to the Processor.

4.3 The Controller shall be responsible for the accuracy and lawfulness of the Personal Data it provides to the Processor.

---

## 5. INTERNATIONAL DATA TRANSFERS

5.1 The Processor shall not transfer Personal Data to countries outside the European Economic Area (EEA) without appropriate safeguards.

5.2 Where the Processor is located outside the EEA, the following transfer mechanism applies:
- [ ] EU Standard Contractual Clauses (SCCs) — Module 2 (Controller to Processor), attached as Schedule 4
- [ ] EU-US Data Privacy Framework certification: [CERTIFICATION ID — PLACEHOLDER]
- [ ] Other adequacy mechanism: [SPECIFY — PLACEHOLDER]

---

## 6. LIABILITY

6.1 Each party's liability under this DPA is subject to the limitations and exclusions set out in the Main Agreement.

6.2 Each party shall be liable for damage caused to the other as a result of its failure to comply with the obligations in this DPA or applicable data protection law.

---

## 7. TERM

This DPA shall remain in force for the duration of the Main Agreement and shall automatically terminate when the Main Agreement expires or is terminated.

---

## 8. GOVERNING LAW

This DPA shall be governed by and construed in accordance with the laws of [GOVERNING JURISDICTION — PLACEHOLDER], and the parties submit to the exclusive jurisdiction of the courts of that jurisdiction.

---

## SCHEDULE 1 — DETAILS OF PROCESSING

| Item | Details |
|------|---------|
| Subject matter | Provision of SaaS services per the Main Agreement |
| Nature of Processing | Storage, access, analysis, transmission, deletion |
| Purpose | To provide and support the contracted software services |
| Categories of Personal Data | [e.g., names, email addresses, account data, usage logs — PLACEHOLDER] |
| Special Categories | [None / specify — PLACEHOLDER] |
| Categories of Data Subjects | [e.g., the Controller's end users and employees — PLACEHOLDER] |
| Duration | Duration of Main Agreement plus 30-day deletion period |

---

## SCHEDULE 2 — SECURITY MEASURES

The Processor maintains the following security measures:

**Access Control**
- Multi-factor authentication on all production systems
- Role-based access with least-privilege principles
- Regular access reviews

**Data Protection**
- Encryption in transit (TLS 1.2+)
- Encryption at rest (AES-256 or equivalent)
- Pseudonymisation where applicable

**Operational Security**
- Regular automated backups with tested recovery
- Penetration testing (annual minimum)
- Security incident response plan and on-call team
- Employee security training

*[PLACEHOLDER: List any certifications — ISO 27001, SOC 2 Type II, etc.]*

---

## SCHEDULE 3 — APPROVED SUB-PROCESSORS

| Sub-processor | Role | Location |
|--------------|------|----------|
| [Cloud provider — PLACEHOLDER] | Infrastructure | [Location — PLACEHOLDER] |
| [Email service — PLACEHOLDER] | Transactional email | [Location — PLACEHOLDER] |
| [Support tool — PLACEHOLDER] | Customer support | [Location — PLACEHOLDER] |

---

## SCHEDULE 4 — INTERNATIONAL TRANSFER MECHANISM

*[Attach applicable EU Standard Contractual Clauses or confirm adequacy mechanism here — PLACEHOLDER]*

---

## SIGNATURES

**Signed for and on behalf of Controller:**

Authorised Signatory: ___________________
Name: ___________________
Title: ___________________
Date: ___________________

**Signed for and on behalf of Processor:**

Authorised Signatory: ___________________
Name: ___________________
Title: ___________________
Date: ___________________

# Responding to a Subject Access Request (SAR) Under GDPR

> **Legal Advice Disclaimer**: This guidance is informational and based on the GDPR text and established regulatory guidance (including ICO and EDPB guidance). It does not constitute legal advice. For high-stakes SAR disputes, enforcement risk, or complex multi-jurisdiction scenarios, consult a qualified data protection lawyer or your DPO.

---

## Legal Framework

A Subject Access Request (SAR) is made under **Article 15 GDPR** — the right of access. The right gives data subjects the ability to:
1. Confirm whether you process their personal data;
2. Obtain a copy of that data; and
3. Receive supplementary information about the processing.

The response deadline is governed by **Article 12(3) GDPR**.

---

## Part 1: What Your SAR Response Must Include (Art. 15)

### 1.1 Confirmation of Processing (Art. 15(1))
You must first confirm whether or not you process personal data relating to the individual. If yes, provide a copy of the personal data **and** all of the following information:

### 1.2 The Copy of Personal Data (Art. 15(3))
- Provide a **copy of all personal data** you hold relating to the data subject
- The copy must be in a **commonly used electronic format** if the request was made electronically (Art. 15(3))
- The **first copy is free of charge** (Art. 12(5)) — see fee rules below

### 1.3 Supplementary Information Required (Art. 15(1)(a–h))

Your response must also include all of the following:

| Element | Article |
|---------|---------|
| The **purposes** of the processing | Art. 15(1)(a) |
| The **categories** of personal data concerned | Art. 15(1)(b) |
| The **recipients** or categories of recipients to whom data has been/will be disclosed (including third countries) | Art. 15(1)(c) |
| The **retention period** or criteria used to determine it | Art. 15(1)(d) |
| Information about the data subject's **rights**: rectification (Art. 16), erasure (Art. 17), restriction (Art. 18), objection (Art. 21) | Art. 15(1)(e) |
| The right to **lodge a complaint** with a supervisory authority | Art. 15(1)(f) |
| Where data was **not collected from the data subject directly**: any available source information | Art. 15(1)(g) |
| The existence of **automated decision-making** including profiling (Art. 22(1)(4)), with meaningful information about the logic, significance, and envisaged consequences | Art. 15(1)(h) |

### 1.4 Cross-Border Transfer Information (Art. 15(2))
If personal data is transferred to a third country (e.g., US servers), inform the data subject of:
- The appropriate safeguards in place (Art. 46 SCCs, Art. 45 adequacy decision, etc.)

---

## Part 2: Deadline and Process (Art. 12)

### 2.1 Core Deadline — One Calendar Month (Art. 12(3))
- You must respond **within one calendar month** of receiving the request
- The clock starts from the **day after** you receive the request (not from identity verification, unless you request verification — see below)
- "One calendar month" means the same day of the following month, not 30 days

### 2.2 Extension — Up to Two Additional Months (Art. 12(3))
You may extend by a further two months (total: three months) if the request is:
- Complex, or
- You have received a number of requests from the same individual

**Requirements to use the extension**:
- Notify the data subject within the **first calendar month** of receiving the request
- Inform them of the reasons for the delay (Art. 12(3))
- Failure to notify within one month even if using the extension is itself a violation

### 2.3 Identity Verification (Art. 12(6))
- You may request **additional information** to confirm the requester's identity where you have "reasonable doubts" about identity
- You must not routinely demand ID for every SAR — only where genuinely uncertain
- Requesting verification pauses the response clock **only if** you had reasonable doubts; if the request was made in an authenticated portal (e.g., logged-in account), you likely already know who they are
- Do not request disproportionate information; a utility bill is generally not needed if you can cross-reference account data

### 2.4 Free of Charge (Art. 12(5))
- Responses must be provided **free of charge**
- Exception: where requests are **manifestly unfounded or excessive**, you may:
  - Charge a reasonable fee (based on administrative cost), OR
  - Refuse to act (but must justify this decision)
- You bear the burden of demonstrating a request is manifestly unfounded or excessive

---

## Part 3: What You Can Redact or Withhold

### 3.1 Third-Party Data — Redact to Protect Others (Art. 15; Recital 63)
The right of access must not "adversely affect the rights and freedoms of others" (Art. 15(4); Recital 63). This is the most common legitimate ground for redaction:
- **Redact** personal data of third parties contained within the data subject's records where disclosure would be unfair to those third parties
- Example: an email chain contains both the requester's data and a colleague's personal comments — redact the colleague's identifying information, but provide the requester's own data
- **Do not use this as a blanket excuse** to withhold all third-party communications — you must strike a balance

### 3.2 Legally Privileged Information
- Communications protected by **legal professional privilege** may be withheld
- This is a narrow exemption — applies to genuine legal advice, not general business communications

### 3.3 Disproportionate Effort Exception (Art. 15(3) — for additional copies)
- If a requester asks for **additional copies** beyond the first, you may charge a reasonable fee based on administrative costs for subsequent copies

### 3.4 National Law Exemptions (Art. 23)
Member States may restrict SAR rights for specific purposes (e.g., national security, crime prevention, protection of judicial independence). These are narrow and jurisdiction-specific:
- **UK GDPR / DPA 2018, Schedule 2**: Exemptions include crime/tax investigations, legal proceedings, regulatory activities, management forecasts, negotiations
- If you are a US company relying on Member State exemptions, identify which Member State's law applies to your EU customer's jurisdiction

### 3.5 What You CANNOT Withhold
- You cannot withhold data simply because it is embarrassing, commercially sensitive to you, or because responding is burdensome
- You cannot withhold data on the basis that you disagree with the purpose of the request
- "Manifestly unfounded" is a **high bar** — EDPB guidance confirms this applies only to requests made in bad faith or with no legitimate purpose

---

## Part 4: Consequences of Missing the 72-Hour / One-Month Deadline

*Note: The 72-hour rule applies to **data breach notification** (Art. 33), not SARs. The SAR deadline is one calendar month (Art. 12(3)).*

### 4.1 Regulatory Enforcement (Art. 77–83)
If you fail to respond to a SAR within the one-month deadline (or the extended three-month period where properly notified):

- **The data subject can lodge a complaint** with any EU supervisory authority (Art. 77(1)) — they do not need to be in the same country as you
- **The supervisory authority must investigate** the complaint (Art. 57(1)(f)) and has broad investigatory and corrective powers (Art. 58)
- **Administrative fines**: Failure to comply with a SAR is a violation of Art. 12 and Art. 15, which falls under **Art. 83(4)**: fines up to **€10 million or 2% of global annual turnover**, whichever is higher
- More serious/wilful violations may be escalated to **Art. 83(5)** tier: fines up to **€20 million or 4% of global annual turnover**

### 4.2 Enforcement Action
- Supervisory authorities can issue **reprimands, warnings, and corrective orders** (Art. 58(2))
- A supervisory authority can order you to comply with the request (Art. 58(2)(c)(d)(g))
- Orders from the supervisory authority are legally binding

### 4.3 Right to Judicial Remedy (Art. 79)
The data subject may also seek a **judicial remedy** against you, independently of the supervisory authority complaint. Courts in any EU Member State where you process data may have jurisdiction.

### 4.4 Reputational Risk
SAR failures are commonly publicised by supervisory authorities. UK ICO, CNIL, and DPA decisions are frequently published. This creates reputational risk beyond the fine itself.

---

## Part 5: Practical Response Procedure

### Step 1: Log and Acknowledge (Day 0–1)
- Record the request in your SAR register with the date received
- Acknowledge receipt (not legally required but best practice; it resets expectations)
- Assess whether identity verification is genuinely needed

### Step 2: Search All Systems (Day 1–20)
Search all systems, databases, backups, email servers, logs, and third-party processors where the individual's data may reside:
- CRM / customer database
- Email (search both sender and recipient)
- Support ticketing system
- Analytics / product logs
- HR systems (if employee)
- Backup systems (note: may be impractical to search — document why if not done)

### Step 3: Apply Redactions (Day 20–27)
- Review all responsive data
- Redact third-party personal data
- Redact legally privileged material
- Document every redaction with justification

### Step 4: Compile and Send Response (By Day 30)
- Cover letter explaining the response structure
- Copy of all personal data (redacted where justified)
- All Art. 15(1) supplementary information
- Method of delivery: secure, documented (e.g., encrypted email, secure portal)

### Step 5: Document
- Record what was searched, what was found, what was provided, what was withheld and why
- Retain documentation for accountability (Art. 5(2))

---

## Summary Table

| Aspect | Requirement | Article |
|--------|------------|---------|
| Response deadline | 1 calendar month | Art. 12(3) |
| Extension (with notice) | Up to 2 additional months | Art. 12(3) |
| Cost | Free (first copy) | Art. 12(5) |
| Provide copy of data | Yes | Art. 15(3) |
| Provide supplementary info | Yes (8 categories) | Art. 15(1)(a–h) |
| Third-party data | Redact to protect third parties | Art. 15(4); Recital 63 |
| Automated decision-making info | Yes, if applicable | Art. 15(1)(h) |
| Maximum fine for non-compliance | €10M or 2% global turnover | Art. 83(4) |

# Responding to a Subject Access Request (SAR) Under GDPR

## Overview

A Subject Access Request (SAR) is a request from an individual to access the personal data you hold about them. Under GDPR, individuals have a right of access to their personal data, and you must respond within one calendar month of receiving the request. Here is what your response must include, what you can legitimately withhold, and what happens if you miss the deadline.

---

## What Your SAR Response Must Include

Your response must do two things: confirm whether you hold personal data about the individual, and if so, provide them with:

### 1. A Copy of Their Personal Data
You must provide a complete copy of all personal data you hold about the individual across all your systems — databases, CRM, email, support tickets, logs, and any other data store. The copy should be in a commonly used, readable format (PDF, CSV, etc.).

### 2. Supplementary Information About the Processing
Alongside the data itself, you must also provide:

- **Purposes**: Why you process their data (e.g., to provide the service, for billing, for analytics)
- **Categories of data**: What types of personal data you hold (names, emails, usage data, etc.)
- **Recipients**: Who you share their data with — including third-party processors, partners, and whether any data goes overseas
- **Retention period**: How long you keep their data, or the criteria you use to decide this
- **Their rights**: Remind them they can request correction, deletion, restriction of processing, and objection
- **Right to complain**: Let them know they can complain to their national data protection authority
- **Source of data**: If you collected their data from a third party (not directly from them), tell them where it came from
- **Automated decision-making**: If you make automated decisions about them (e.g., algorithmic scoring), explain the logic, significance, and likely consequences

---

## The 30-Day Deadline

- You must respond within **one calendar month** of receiving the request
- If the request is complex or you've received multiple requests from the same person, you can extend this to **three months total** — but you must tell the individual about the extension within the first month and explain why
- Responses must be **free of charge** for the first copy

---

## What You Can Redact or Withhold

You don't have to hand over absolutely everything. Legitimate reasons to redact or withhold include:

### Third-Party Data
If the personal data you hold includes information about other individuals (e.g., emails that mention colleagues, customer records that include names of others), you can redact the third parties' personal information to protect their privacy. You need to find a balance — redact what's necessary to protect others, but still provide the requester's own data.

### Legally Privileged Communications
Correspondence that is protected by legal professional privilege (e.g., advice from your lawyers) can typically be withheld.

### Manifestly Unfounded or Excessive Requests
If a request is clearly made in bad faith, is repetitive with no genuine purpose, or is designed to harass rather than obtain data, you may be able to refuse it or charge a fee. However, this is a high bar — you cannot refuse simply because the request is difficult or embarrassing.

### Regulatory and Legal Exemptions
In some EU member states (and the UK under the Data Protection Act 2018), there are specific exemptions that may allow withholding data in certain contexts — for example, during ongoing legal proceedings, in the context of regulatory investigations, or where disclosure would prejudice crime prevention. These exemptions are narrow and jurisdiction-specific.

### What You Cannot Withhold
- You cannot refuse simply because responding is time-consuming or inconvenient
- You cannot redact data just because it's commercially sensitive to you
- You cannot ignore or unreasonably delay a request

---

## Consequences of Missing the One-Month Deadline

Missing the deadline is a serious compliance failure with real consequences:

### Regulatory Complaints and Investigations
The individual can file a complaint with their national data protection authority (DPA) — for example, the ICO in the UK, the CNIL in France, or the DPA in Ireland. The authority is required to investigate the complaint and can take action against you.

### Fines
Data protection authorities can impose significant fines for failing to respond to SARs. Under GDPR, administrative fines for violations like this can reach up to **€10 million or 2% of your global annual turnover**, whichever is higher. More serious or wilful violations can attract fines up to **€20 million or 4% of global annual turnover**.

### Orders to Comply
The supervisory authority can order you to comply with the request, and those orders are legally binding. Ignoring them escalates the situation significantly.

### Litigation
In some jurisdictions, the individual can also bring a court claim directly against you for failing to comply with their SAR.

### Reputational Damage
Enforcement decisions by data protection authorities are frequently published. A public SAR failure can damage your reputation with customers and enterprise prospects, particularly EU buyers who expect GDPR compliance.

---

## Practical Tips for Your 30-Day Window

1. **Acknowledge immediately**: Send a confirmation of receipt and the expected response date
2. **Verify identity if needed**: If you're not certain who is making the request, you can ask for reasonable verification — but don't ask for more than you need
3. **Search all systems**: Include CRM, email, support tickets, analytics, backups, and any third-party processors
4. **Flag third-party data**: Go through the responsive data and redact any third parties' personal information before sending
5. **Document everything**: Keep a record of what you searched, what you found, what you sent, and what you redacted and why
6. **Use the extension if genuinely needed**: If the request is complex, use the two-month extension — but communicate this to the individual before the first month is up
7. **Deliver securely**: Send the response in a secure format (password-protected PDF, secure portal download, etc.)

# Cookie Consent Requirements for Analytics and Marketing Pixels — EU Users

> **Legal Advice Disclaimer**: This guidance is informational and based on the GDPR text, the ePrivacy Directive, and EDPB/supervisory authority guidance. It does not constitute legal advice. Cookie compliance is an active enforcement area across EU member states; consult a qualified data protection lawyer or DPO before finalising your consent implementation.

---

## Short Answer

For **analytics cookies** and **marketing pixels** targeting EU users, **consent is required** under both the ePrivacy Directive (ePD) and the GDPR. **Legitimate interests cannot be relied upon** as a substitute for consent for analytics cookies or marketing pixels — this position is confirmed by the EDPB and major supervisory authorities including the CNIL, ICO, and DSK (Germany). Read on for the full analysis.

---

## Part 1: The Legal Framework — Two Overlapping Regimes

### 1.1 ePrivacy Directive (2002/58/EC, as amended 2009)
The ePrivacy Directive ("Cookie Law") governs the **placement of cookies and similar tracking technologies** on user devices. It applies **in addition to** the GDPR.

Key rule: **Article 5(3) ePD** — Storing or accessing information on a user's device (which includes cookies, pixels, local storage, fingerprinting) requires:
- The user's **informed consent**, UNLESS the cookie is **strictly necessary** for a service explicitly requested by the user

The ePD does not permit legitimate interests as an alternative to consent for non-essential cookies. **Consent under the ePD must meet GDPR consent standards** (Art. 2(f) ePD cross-references GDPR).

### 1.2 GDPR — Lawful Basis for Processing Personal Data Generated by Cookies
Cookies and tracking pixels typically collect personal data (IP addresses, device identifiers, browsing behaviour) — see **Art. 4(1) GDPR; Recital 30** (cookie identifiers explicitly named as personal data).

For the **processing of this personal data**, you also need a lawful basis under **Art. 6(1) GDPR**:
- For analytics tracking of individual behaviour: **Consent (Art. 6(1)(a))**
- For marketing pixels tracking and profiling individuals: **Consent (Art. 6(1)(a))**
- For truly aggregated, non-identifiable analytics: GDPR does not apply (Recital 26)

---

## Part 2: Consent Requirements — What Valid Consent Looks Like

Consent must meet the requirements of **Article 7 GDPR** and **Recital 32**:

### 2.1 The Four Conditions (Art. 4(11); Art. 7)
| Condition | Meaning | Practical Implication |
|-----------|---------|----------------------|
| **Freely given** | No detriment for refusing; no bundling with terms | Cannot gate service access on cookie consent |
| **Specific** | Separate consent for each distinct purpose | Analytics and marketing must be separate opt-ins |
| **Informed** | Clear information about what is tracked and by whom | Name specific third parties (Google, Meta, etc.) |
| **Unambiguous** | Clear affirmative action required | Pre-ticked boxes, scrolling, continued browsing are NOT valid consent |

### 2.2 Additional Requirements
- **Withdrawal must be as easy as giving consent** (Art. 7(3)): You must provide a "Manage Cookies" or equivalent mechanism — not buried in the footer
- **No consent walls** (EDPB Guidelines 05/2020): You cannot make access to the website conditional on accepting non-essential cookies unless you offer a genuine, equivalent alternative (e.g., a paid tier)
- **No dark patterns**: The EDPB's Guidelines on Dark Patterns (03/2022) prohibit misleading consent interfaces — e.g., using deceptive contrast (grey "Reject" button, highlighted "Accept"), confusing language, or hidden opt-outs
- **Granularity**: Consent must be specific per purpose category — a single "Accept All Cookies" is only valid if users are also offered easy category-level control

### 2.3 Consent Banner Requirements
Your cookie banner must:
- [ ] Appear before any non-essential cookies are set (pre-consent requirement)
- [ ] Present "Accept" and "Reject" options with equal prominence (EDPB; CNIL guidance; Belgian DPA ruling)
- [ ] Not pre-tick any non-essential cookie categories
- [ ] Identify each cookie category and purpose clearly
- [ ] Name third-party processors (e.g., "Google Analytics," "Meta Pixel") — CNIL enforcement has required this
- [ ] Provide a link to your full Cookie Policy
- [ ] Allow granular choice (analytics vs. marketing as separate toggles)
- [ ] Record consent with timestamp and version (Art. 7(1) — you must be able to demonstrate consent)

### 2.4 Reconsent
- Consent should be renewed periodically (EDPB guidance suggests 12–13 months is a common supervisory authority expectation)
- Reconsent is required whenever the purposes or cookie list materially changes

---

## Part 3: Can You Use Legitimate Interests Instead of Consent?

### 3.1 The Short Answer: No — Not for Analytics or Marketing Pixels

**Legitimate interests (Art. 6(1)(f)) cannot be used as an alternative to consent for analytics cookies or marketing pixels.** This is the established position of:
- **EDPB Opinion 5/2019** and Guidelines on Consent
- **CNIL** (France): has issued fines against Google and Facebook for using legitimate interests for advertising cookies
- **ICO** (UK): "We do not consider analytics cookies can be regarded as strictly necessary" and legitimate interests does not apply to cookies under the ePD
- **DSK** (Germany Data Protection Conference): similar position
- **Belgian DPA** ruling in the IAB TCF case (February 2022): confirmed LI cannot substitute for consent under the ePD framework

**Why it fails the LIA (Legitimate Interests Assessment)**:
- **Purpose**: Website analytics is a legitimate purpose — passes the purpose test
- **Necessity**: Can you achieve the same purpose without individual-level tracking? Aggregate server-side analytics (e.g., server logs, privacy-preserving analytics tools) may achieve the same goal with less privacy impact — this undermines the necessity leg
- **Balancing**: Data subjects have a reasonable expectation NOT to be individually tracked across websites for advertising. The balancing test typically fails for marketing pixels, which are designed to track individuals across sites for commercial purposes

### 3.2 The Narrow LI Use Cases for Cookies
Legitimate interests is potentially available only for:
- **Security cookies**: Detecting fraud, bots, or intrusions — but these are typically strictly necessary anyway
- **Load balancing**: Technically necessary session management

The EDPB has consistently rejected LI as a basis for analytics or marketing tracking absent additional and compelling justification.

### 3.3 Alternatives to Individual-Level Analytics
Consider privacy-preserving analytics approaches that may reduce or eliminate consent requirements:
- **Server-side analytics**: IP-anonymised server logs without JavaScript tracking (may not require consent if truly anonymised)
- **Aggregate-only tools**: Plausible, Fathom, or Matomo configured without individual tracking
- **Consent-mode (Google Consent Mode v2)**: Collects modelled data where consent is refused — still requires a proper consent mechanism but reduces data loss from refusals

---

## Part 4: Marketing Pixels (e.g., Meta Pixel, Google Ads)

Marketing pixels are **higher risk** than analytics cookies for several reasons:
- They involve **cross-site tracking** of individuals across the web
- They enable **profiling** for targeted advertising (Art. 22 implications if fully automated)
- They transmit personal data to third-party controllers (Meta, Google) who become independent controllers of the data
- They have been the subject of multiple **major enforcement actions**: CNIL fines against Google (€150M, €90M) and Meta (€60M) for cookie consent failures; Irish DPC and others

**Requirements for marketing pixels**:
- [ ] Explicit, informed consent before any pixel fires
- [ ] Identify Meta, Google, etc. as recipients in your consent notice
- [ ] Inform users about cross-site tracking purposes
- [ ] Honour consent refusals — ensure pixels are technically blocked when consent is not given
- [ ] Assess whether profiling based on pixel data triggers **Art. 22** automated decision-making rights

---

## Part 5: Technical Implementation Requirements

### 5.1 Consent Management Platform (CMP)
Implement a GDPR-compliant CMP that:
- Fires NO non-essential cookies or pixels before consent is recorded
- Maintains a consent log with: user identifier, timestamp, consent version, choices made
- Provides easy access to withdraw/change consent at any time
- Does not load third-party scripts (analytics, pixels) until consent is confirmed

### 5.2 Demonstrate Consent (Art. 7(1))
You must be able to prove that consent was obtained:
- Store consent records server-side (not just in the user's browser, which they can clear)
- Retain consent logs for the duration of data processing plus limitation period

---

## Part 6: Enforcement Landscape

Cookie compliance is **actively enforced** across the EU:
- **CNIL (France)**: €150M against Google, €90M against Meta, €3M against Facebook Ireland (2022) for non-compliant cookie banners
- **Belgian DPA**: Major ruling against IAB Europe's TCF (Transparency and Consent Framework) in 2022, finding it violated GDPR
- **ICO (UK)**: Issued formal warnings and enforcement notices to multiple major websites
- **DSK (Germany)**: Coordinated cookie enforcement sweeps

Non-compliant cookie implementations face fines under **Art. 83(5) GDPR** (up to €20M or 4% global turnover for consent violations under Art. 7) and parallel enforcement under national ePD transposition laws.

---

## Summary

| Cookie Type | Lawful Basis Required | Legitimate Interests? | Action Required |
|-------------|----------------------|----------------------|-----------------|
| Strictly necessary | Not required | N/A | No consent banner needed for this category |
| Analytics (individual tracking) | Consent (Art. 6(1)(a) + Art. 5(3) ePD) | No | Opt-in consent banner |
| Analytics (truly anonymised) | None (outside GDPR scope) | N/A | Consider switching to privacy-preserving analytics |
| Marketing pixels | Consent (Art. 6(1)(a) + Art. 5(3) ePD) | No | Opt-in consent banner; name third parties |
| Profiling for advertising | Consent | No | Consent + Art. 22 assessment |

# Cookie Consent Requirements for EU Users — Analytics and Marketing Pixels

## The Short Answer

For EU users, **analytics cookies and marketing pixels require user consent**. You cannot simply rely on "legitimate interests" instead — that approach has been repeatedly rejected by European regulators for this type of tracking. Here is what you need to know.

---

## The Legal Framework

Cookie and tracking rules in the EU come from two sources that work together:

1. **The ePrivacy Directive** ("Cookie Law"): This specifically requires informed consent before placing non-essential cookies or similar tracking technologies on a user's device. This has applied since 2002 (amended 2009) and is implemented through national laws in each EU member state.

2. **GDPR**: Analytics cookies and marketing pixels collect personal data (IP addresses, device identifiers, browsing behaviour), so GDPR's rules on lawful basis for processing also apply on top of the ePrivacy rules.

Both must be satisfied. Consent under the ePrivacy Directive must meet the GDPR's consent standards to be valid.

---

## What Counts as a Cookie / What Requires Consent?

**Requires consent** (non-essential tracking):
- Google Analytics, Mixpanel, Amplitude, and similar analytics tools that track individual users
- Meta Pixel, Google Ads conversion tracking, LinkedIn Insight Tag, and similar marketing/advertising pixels
- Retargeting and remarketing scripts
- A/B testing tools that set cookies or collect identifiable data

**Does NOT require consent** (strictly necessary):
- Session cookies that keep users logged in
- Shopping cart cookies
- Security tokens (CSRF protection)
- Load balancing cookies

---

## What Valid Consent Looks Like

For your cookie consent to be legally valid under GDPR, it must be:

### Freely Given
- You cannot force users to accept cookies in order to use your website (no "consent walls")
- Refusing cookies should have no negative consequence for basic site functionality

### Specific
- You need separate consent for different purposes — analytics and marketing must be separate opt-ins, not bundled together
- Users should be able to accept one but not the other

### Informed
- Tell users what each cookie category does
- Name the specific third parties involved (e.g., "Google Analytics," "Meta Pixel")
- Link to your full cookie policy

### Unambiguous — Requires a Real Opt-In
- Pre-ticked boxes are NOT valid consent
- Continuing to browse the site is NOT valid consent
- There must be a clear, affirmative action (clicking "Accept Analytics")

### Equal Prominence for Accept and Reject
- Your "Accept" and "Decline" buttons must be equally easy to find and click
- European regulators have consistently fined companies that make "Reject" difficult to click while making "Accept" prominent and colourful

### Easy to Withdraw
- Users must be able to change or withdraw their consent as easily as they gave it
- A "Manage Cookies" or "Cookie Settings" link must be accessible from every page, not hidden in the footer

---

## Can You Use Legitimate Interests Instead of Consent?

**No — not for analytics cookies or marketing pixels.**

Legitimate interests has been repeatedly and clearly rejected by European data protection authorities as a substitute for consent in this context:

- The French authority (CNIL) has fined Google and Meta hundreds of millions of euros in part for attempting to rely on non-consent bases for advertising and tracking
- The Belgian Data Protection Authority ruled against the IAB's industry framework for advertising consent for similar reasons
- The UK's ICO has stated clearly that analytics cookies cannot be treated as strictly necessary, and legitimate interests does not bypass the consent requirement under the ePrivacy Directive

### Why Legitimate Interests Fails Here

Even setting aside the ePrivacy Directive, a legitimate interests balancing test for analytics/marketing tracking tends to fail because:
- Users have a reasonable expectation that they are NOT being individually tracked across websites for advertising
- The privacy impact is significant (cross-site profiling, data sharing with Meta/Google)
- Less privacy-invasive alternatives exist (aggregate analytics, server-side anonymised data)

### Where Legitimate Interests Can Apply for Cookies
The only narrow cases where legitimate interests may be relevant are things like fraud detection and security — and those typically qualify as "strictly necessary" anyway, so no consent is required.

---

## Practical Requirements for Your Cookie Banner

- [ ] Banner appears before any non-essential cookies fire — nothing is loaded until consent is given
- [ ] Clear categories: e.g., "Necessary," "Analytics," "Marketing" — each with its own toggle
- [ ] Accept and Reject buttons of equal prominence (same size, same colour treatment)
- [ ] List specific third-party tools by name
- [ ] Link to cookie policy with full details
- [ ] "Reject All" option must be easy and at the same level as "Accept All"
- [ ] Consent is stored server-side with a timestamp so you can prove it was obtained
- [ ] "Manage Preferences" option accessible from all pages (e.g., persistent footer link)
- [ ] No pre-ticked boxes or assumed consent

---

## What About Marketing Pixels Specifically?

Marketing pixels (Meta Pixel, Google Ads tags, LinkedIn Insight Tag, etc.) are particularly high-risk because:
- They transmit data to major ad platforms who have their own uses for it
- They enable cross-site tracking and profiling
- They have been the target of major enforcement actions in France, Ireland, and Austria

**Additional requirements for pixels**:
- Name each platform explicitly in your consent notice
- Ensure pixels are technically blocked (not just ignored) when consent is refused — scripts must not load
- Consider the data residency implications of transmitting EU user data to US platforms (may require SCCs or Data Privacy Framework certification)

---

## Enforcement Reality

This is an area of active enforcement:
- CNIL (France) fined Google €150M and Meta €60M+ for non-compliant cookie banners in 2021–2022
- The Irish DPC, Belgian DPA, and German authorities have all taken action on cookie issues
- Complaints from privacy advocacy groups like noyb (Max Schrems' organisation) have driven hundreds of enforcement actions across the EU

The consequences of non-compliant cookies can include fines, orders to delete collected data, and reputational damage.

---

## Practical Alternatives to Reduce Consent Friction

If your analytics and marketing efforts are being hurt by users declining cookies, consider:

- **Privacy-preserving analytics tools** like Plausible, Fathom, or Matomo (properly configured) that do not track individuals — these may not require consent
- **Server-side analytics** using anonymised server logs — if data is truly anonymised at collection, GDPR does not apply
- **Google Consent Mode**: Allows Google to model aggregate data where users decline — reduces data loss from refusals, though still requires a proper consent mechanism
- **First-party data strategies**: Build relationships where users voluntarily share data, rather than relying on passive tracking

---

## Summary

| Cookie Type | Consent Required? | Legitimate Interests Allowed? |
|-------------|------------------|-----------------------------|
| Strictly necessary | No | N/A |
| Analytics (individual user tracking) | Yes | No |
| Marketing/advertising pixels | Yes | No |
| Truly anonymised/aggregate analytics | No (not personal data) | N/A |

# GDPR Data Breach Response: 72-Hour Notification Protocol

> **Legal Advice Disclaimer**: This guidance is informational and based on the GDPR text and EDPB Guidelines 01/2021 on Examples of Personal Data Breach Notification. It does not constitute legal advice. A data breach involving 500 individuals and financial data (account numbers) carries significant regulatory and reputational risk — consult a qualified data protection lawyer or your DPO immediately.

---

## Situation Assessment

**Data involved**: Names, email addresses, and **account numbers** of 500 customers  
**Incident**: Accidental disclosure to wrong email recipient (external)  
**Classification**: This is a **Personal Data Breach** under **Art. 4(12) GDPR** — specifically an accidental disclosure to an unauthorised recipient, constituting a **confidentiality breach**

**Initial risk assessment**: This is a **medium-to-high risk** breach. Account numbers combined with names and emails create risk of financial fraud, phishing, and identity theft. The EDPB has categorised financial data disclosures as typically requiring supervisory authority notification and potentially data subject notification.

---

## The Legal Framework

### Art. 4(12) — Definition of Personal Data Breach
A "personal data breach" means a breach of security leading to accidental or unlawful destruction, loss, alteration, **unauthorised disclosure of**, or **access to**, personal data transmitted, stored or otherwise processed.

**This incident qualifies**: Accidental email to wrong recipient = unauthorised disclosure.

### Art. 33 — Notification to Supervisory Authority
### Art. 34 — Communication to Data Subjects
### Art. 33(5) — Internal Breach Register

---

## Hour-by-Hour Action Plan for the Next 72 Hours

### IMMEDIATELY (Hour 0–2): Contain and Assess

**Step 1: Contain the breach**
- [ ] Attempt to **recall or delete** the email if your mail system allows it (many enterprise email systems support recall)
- [ ] Contact the **recipient immediately** — call them if possible. Explain the error and request:
  - Confirmation that they have deleted the email and attachments
  - Written confirmation (email reply) of deletion
  - Not to forward, share, or use the data
- [ ] **Document** the time you became aware of the breach (this starts the 72-hour clock under Art. 33(1))
- [ ] Preserve evidence: forward the original sent email, screenshot the recipient address, retain logs

**Step 2: Activate your breach response team**
- [ ] Notify your Data Protection Officer (if appointed — Art. 37) or privacy lead
- [ ] Notify your legal counsel
- [ ] Notify senior management / CEO
- [ ] Open a breach incident record in your breach register (Art. 33(5))

**Step 3: Secure the source**
- [ ] Identify how the spreadsheet was created and stored
- [ ] Confirm no other copies were sent or are at risk
- [ ] Audit email logs to confirm extent of the disclosure (one email, one recipient, or more?)

---

### Hours 2–12: Risk Assessment

Conduct a formal risk assessment using the EDPB's four-factor framework (EDPB Guidelines 01/2021):

| Factor | Assessment for This Incident |
|--------|------------------------------|
| **Type of breach** | Confidentiality breach — disclosure to wrong recipient |
| **Nature, sensitivity, and volume of data** | Names + emails + **account numbers** × 500 individuals — financial data is sensitive; high risk of phishing/fraud |
| **Ease of identification** | Data is directly identifiable (names, emails) |
| **Severity of consequences** | Account numbers → risk of financial harm; emails → risk of targeted phishing |
| **Special characteristics of data subjects** | General consumer population — no additional vulnerability factors known |
| **Number of data subjects** | 500 — significant volume |
| **Special characteristics of controller** | SaaS company — handling customer financial data |

**Likely risk classification**: **High risk** to data subjects' rights and freedoms, given:
- Account numbers can facilitate financial fraud
- Emails enable targeted phishing using the associated names
- You do not yet know whether the recipient has seen/used the data

**Decision matrix**:
- Notify supervisory authority: **Yes** — breach involves personal data (Art. 33(1))
- Notify data subjects: **Likely yes** — financial data disclosure meets the "high risk" threshold (Art. 34(1))

---

### Hours 12–48: Prepare Notifications

#### A. Supervisory Authority Notification (Art. 33) — Deadline: 72 Hours from Awareness

**Which authority to notify?**
- If you have an EU establishment: your **lead supervisory authority** (the authority in the Member State of your main establishment — Art. 55–56)
- If you are a US company without EU establishment: the authority in the Member State(s) where affected data subjects are located, or where the controller's EU Representative is based

**What the notification must contain (Art. 33(3))**:

| Element | What to Include |
|---------|----------------|
| **(a) Nature of the breach** | Describe the incident: employee sent spreadsheet to wrong email address on [DATE] at [TIME]. One external recipient. Data included names, emails, and account numbers of 500 customers |
| **(b) DPO/contact details** | Name and contact details of your DPO or privacy contact |
| **(c) Likely consequences** | Risk of financial fraud using account numbers; risk of targeted phishing; risk of reputational harm to data subjects |
| **(d) Measures taken** | Immediate recall attempt; contact with recipient requesting deletion; deletion confirmation obtained/pending; breach investigation underway; data subjects to be notified |

**Important procedural rules**:
- If you cannot provide all information within 72 hours, you may **notify in phases** (Art. 33(4)): submit what you know now, and follow up with additional information as your investigation progresses
- The 72-hour clock runs from when **you** (your organisation) became aware — not from when the employee noticed. If IT or a manager was informed and did not escalate, consider whether the clock has already been running
- **Missing the 72-hour window without good reason is itself a violation** and will be considered an aggravating factor by the supervisory authority

**Where to submit**: Most EU supervisory authorities have online breach notification portals. Examples:
- Ireland (DPC): Online reporting form at dataprotection.ie
- Germany (multiple state DPAs): depends on your EU Representative's location
- France (CNIL): notifications.cnil.fr
- UK (ICO): ico.org.uk/make-a-complaint (if UK data subjects involved)

---

#### B. Internal Breach Register Entry (Art. 33(5))

Regardless of whether you notify the supervisory authority (you must notify all breaches that are not "unlikely to result in a risk to the rights and freedoms of natural persons"), you must maintain an **internal breach register** containing:
- [ ] Nature of the breach
- [ ] Data categories and approximate number of records and individuals affected
- [ ] Effects and consequences of the breach
- [ ] Remedial action taken
- [ ] Assessment of risk level
- [ ] Notification decisions and their justification

This register must be maintained **even for minor breaches** that do not require supervisory authority notification.

---

### Hours 48–72: Data Subject Notification (Art. 34)

#### When Must You Notify Data Subjects?
You must notify affected individuals "**without undue delay**" when the breach is **likely to result in a high risk to the rights and freedoms of natural persons** (Art. 34(1)).

Given account numbers + names + emails for 500 individuals → **notification is very likely required**.

**Exceptions to individual notification (Art. 34(3))**:
- You have implemented technical measures that make data unintelligible (e.g., encryption) — **not applicable here**; the spreadsheet was in plain text
- You have subsequently taken measures that ensure high risk is no longer likely to materialise — applicable **only** if you obtain written confirmation of deletion from the recipient AND have high confidence the data was not viewed/copied
- Notification would involve disproportionate effort → use a public communication instead (Art. 34(3)(c)) — not applicable for 500 individuals where you have their email addresses

#### What to Tell Data Subjects (Art. 34(2))
The communication must include (in clear, plain language per Art. 12(1)):
- [ ] **Nature of the breach**: An employee accidentally sent a spreadsheet containing your data to the wrong email recipient
- [ ] **Contact details** of your DPO or privacy contact (Art. 34(2)(a))
- [ ] **Likely consequences** of the breach: potential risk of phishing, fraud, or misuse of account information (Art. 34(2)(b))
- [ ] **Measures taken** to address the breach and steps you recommend they take (Art. 34(2)(c)):
  - Monitor their accounts for unusual activity
  - Be alert to phishing emails using their name
  - Contact you if they notice anything suspicious
  - Consider whether account number changes are warranted

**How to notify**: Given you have their email addresses, direct email notification is appropriate.

**Tone**: Clear, honest, non-legalese. Do not minimise the incident. Data subjects are entitled to accurate information to protect themselves.

---

## Post-72-Hour Actions

### Week 1–2
- [ ] Complete your investigation: obtain written deletion confirmation from the recipient
- [ ] If confirmation not obtained: escalate risk assessment (assume data was retained)
- [ ] Follow up with supervisory authority if you filed a partial notification
- [ ] Review and update your email handling procedures
- [ ] Consider whether a **Disciplinary Process** for the employee is appropriate (note: employee data handling errors do not automatically constitute gross misconduct — assess proportionately)

### Within 30 Days
- [ ] Root cause analysis: why did this happen? (wrong recipient auto-complete? lack of double-check procedure?)
- [ ] Implement corrective controls:
  - Mandatory DLP (Data Loss Prevention) scanning for outbound emails containing personal data
  - Confirmation step for bulk/sensitive email sends
  - Staff training reinforcement
  - Consider whether bulk customer data should ever be in a spreadsheet format accessible by email
- [ ] Update your breach register with final details
- [ ] Document lessons learned

---

## Risk of Not Notifying

Failure to notify the supervisory authority within 72 hours without good reason:
- Violation of Art. 33(1) → fines under **Art. 83(4)**: up to **€10 million or 2% of global annual turnover**
- Supervisory authorities treat late/non-notification as an aggravating factor in fine calculations
- Cooperation and timely notification are both treated as **mitigating factors** (Art. 83(2)(f))

Failure to notify data subjects when required:
- Violation of Art. 34(1) → same fine tier under Art. 83(4)
- Additional risk: if data subjects suffer financial harm due to the breach and were not warned, individual compensation claims under Art. 82 GDPR become more likely

---

## Practical Summary — The 72-Hour Checklist

| Time | Action | Article |
|------|--------|---------|
| Hour 0 | Log time of awareness; open breach record | Art. 33(5) |
| Hour 0–2 | Attempt email recall; contact recipient; escalate internally | Art. 33(1) |
| Hour 2–12 | Conduct risk assessment using EDPB 4-factor framework | EDPB Guidelines 01/2021 |
| Hour 12–48 | Prepare supervisory authority notification | Art. 33(3) |
| Hour 48–72 | File supervisory authority notification | Art. 33(1) |
| Hour 48–72 | Prepare and send data subject notifications | Art. 34(1)(2) |
| Post-72h | Follow up with authority; obtain deletion confirmation; root cause | Art. 33(4) |
| Within 30 days | Implement controls; complete breach register; staff training | Art. 5(2); Art. 32 |

# GDPR Data Breach Response: What to Do in the Next 72 Hours

## Situation Overview

You have a confirmed data breach: an employee accidentally emailed a spreadsheet containing names, email addresses, and account numbers of 500 customers to the wrong person. Under GDPR, this is a personal data breach — an unauthorised disclosure of personal data — and it triggers specific legal obligations.

Here is what you need to do, step by step.

---

## Is This a Notifiable Breach?

Yes, almost certainly. GDPR requires you to notify the relevant supervisory authority (data protection regulator) of a personal data breach unless it is "unlikely to result in a risk to the rights and freedoms of natural persons."

This breach involves:
- **Account numbers**: financial information that could be used for fraud
- **Names and email addresses**: enabling targeted phishing attacks
- **500 individuals**: a significant number of affected people

The combination of financial data and contact information creates a genuine risk of harm to the affected individuals. You should treat this as a notifiable breach and proceed accordingly.

---

## The 72-Hour Clock Is Already Running

The 72-hour deadline to notify the supervisory authority starts from the moment your organisation became aware of the breach — not when a decision is made to report it. If an employee or manager knew about this and delayed escalating it, the clock may have been running for longer than you think.

**Act now.**

---

## What to Do in the Next 72 Hours

### Step 1: Contain the Breach (Do This Immediately)

- **Try to recall the email** if your email system supports message recall
- **Contact the recipient directly** — call them if you can. Explain the mistake and ask them to:
  - Delete the email and any attachments immediately
  - Confirm in writing (by reply email) that they have done so
  - Not forward or share the data
- **Secure the source**: identify where the spreadsheet lives, who has access to it, and whether it was sent anywhere else
- **Document everything**: record exactly when the breach occurred, when it was discovered, who discovered it, and what actions have been taken

### Step 2: Assemble Your Response Team (Hours 1–4)

- Notify your Data Protection Officer (DPO) if you have one
- Notify your legal counsel
- Notify senior management
- Open a formal incident record — you are required to maintain a written log of all breaches regardless of whether you report them externally

### Step 3: Assess the Risk (Hours 4–12)

Before you can complete your notification, you need to assess:
- Did the recipient open the email? (You may be able to check read receipts or ask them directly)
- Have you received confirmation of deletion?
- What is the realistic risk of harm to the 500 individuals?

**Risk factors that increase severity**:
- Account numbers are financial data — fraud risk is real
- Names + emails enable very convincing phishing attacks
- You don't know yet whether the recipient has seen or copied the data

**If you obtained confirmed deletion from a trusted recipient**: risk may be lower, but you should still notify the supervisory authority

**If you cannot confirm deletion**: assume the data has been exposed and treat as high risk

### Step 4: Notify the Supervisory Authority (Before 72 Hours)

You must file a breach notification with the relevant EU data protection authority. The authority depends on where your EU data subjects are located and/or where your EU Representative is based (if you are a US company without an EU office).

**What the notification must include**:
- A description of what happened — what data, how many people, how it happened
- The contact details of your DPO or privacy contact
- The likely consequences of the breach — e.g., risk of phishing or financial fraud
- What you have done or are doing to address the breach — recall attempts, deletion request, notification to affected individuals

**If you don't have all the information yet**: You can submit an initial notification with what you know and follow up with additional details later. It is better to notify on time with incomplete information than to miss the deadline while waiting for a perfect picture.

**Where to file**:
- Find the supervisory authority for the relevant EU country (each has an online portal or reporting form)
- Examples: ICO (UK), CNIL (France), DPC (Ireland), Datatilsynet (Denmark/Norway), etc.

### Step 5: Notify the Affected Individuals

In addition to the regulator, you must also notify the 500 affected customers if the breach is "likely to result in a high risk" to them. Given the nature of the data (financial account numbers + contact details), **you should notify them**.

**The notification to individuals should include**:
- A plain-language explanation of what happened
- What data was involved
- What you are doing about it
- What they should do to protect themselves:
  - Watch for suspicious account activity
  - Be alert to phishing emails that use their name and personal details
  - Contact you if they notice anything suspicious
- Your contact details if they have questions

**Send this as a direct email to each affected customer** — you have their email addresses, so a public announcement is not sufficient.

---

## What Happens If You Miss the 72-Hour Deadline?

Missing the deadline without good reason is itself a GDPR violation. The consequences include:

- **Fines**: The supervisory authority can impose significant administrative fines — up to €10 million or 2% of global annual turnover for breach notification failures, and up to €20 million or 4% of global turnover for more serious violations
- **Enforcement orders**: The authority can order you to take specific steps
- **Reputational damage**: Regulatory decisions are often published
- **Compensation claims**: Individuals who suffer financial harm because they were not warned in time may have grounds to claim compensation

In practice, regulators consider cooperation and self-reporting as mitigating factors. A company that promptly reports, cooperates fully, and takes concrete remedial steps is treated more favourably than one that delays or conceals a breach.

---

## After the 72 Hours — Follow-Up Actions

- **Complete your investigation**: Confirm whether deletion was achieved; document the outcome
- **Update your breach register**: Maintain a written record of the breach, your assessment, and all actions taken — this is required even for breaches you don't report externally
- **Root cause analysis**: Why did this happen? Auto-complete to the wrong address? No verification step for bulk customer data?
- **Remedial controls**: Consider implementing:
  - Email DLP (Data Loss Prevention) scanning for outbound messages containing personal data
  - Mandatory confirmation step before sending bulk customer data by email
  - Staff training refresher on data handling
  - Technical controls to prevent bulk customer data from being accessible via email at all

---

## Summary Checklist

**Immediate (next 2 hours)**
- [ ] Attempt email recall
- [ ] Contact recipient and request deletion confirmation
- [ ] Notify DPO and legal counsel
- [ ] Open breach incident record

**Within 12 hours**
- [ ] Assess risk level
- [ ] Gather all facts about the incident
- [ ] Draft supervisory authority notification

**Within 72 hours**
- [ ] File notification with supervisory authority
- [ ] Send individual notification emails to 500 affected customers

**Within 2 weeks**
- [ ] Confirm deletion or escalate if unconfirmed
- [ ] Complete root cause analysis
- [ ] Implement preventive controls
- [ ] Update internal breach register with full details

# HIPAA Applicability Analysis: Healthcare Patient App

## HIPAA Compliance Review

**Scope:** Covered Entity (CE) — with potential Business Associate (BA) relationships for vendors
**Rules Applicable:** Privacy Rule (45 CFR Part 164, Subparts A & E), Security Rule (45 CFR Part 164, Subparts A & C), Breach Notification Rule (45 CFR Part 164, Subparts A & D)

---

## Short Answer

**Yes, you almost certainly need to comply with HIPAA.** Your app handles Protected Health Information (PHI) — specifically, medical records and doctor-patient communications — and the entity operating it likely qualifies as a Covered Entity or is directly serving one.

---

## Are You a Covered Entity or a Business Associate?

### Covered Entity (CE) — 45 CFR §160.103

A Covered Entity is one of three types of organizations:

1. **Healthcare Providers** — Any provider that transmits health information electronically in connection with standard transactions (e.g., claims, eligibility checks). This includes hospitals, clinics, physician practices, and telehealth platforms that employ or contract with physicians.
2. **Health Plans** — Insurers, HMOs, employer-sponsored health plans.
3. **Healthcare Clearinghouses** — Entities that process nonstandard health data into standard formats.

**If your app is operated by or on behalf of a healthcare provider (e.g., a hospital system, clinic network, or physician group), you are operating as or for a Covered Entity.** Patient portals that allow patients to view records and message their doctors are a classic Covered Entity use case.

### Business Associate (BA) — 45 CFR §160.103

A Business Associate is any person or entity that:
- Creates, receives, maintains, or transmits PHI **on behalf of** a Covered Entity
- Performs functions or activities for a CE that involve PHI (e.g., data storage, analytics, billing)

**If you are a third-party vendor building or hosting this app for a healthcare provider, you are a Business Associate.** As a BA, you must:
- Sign a **Business Associate Agreement (BAA)** with the CE before handling any PHI
- Comply with the HIPAA Security Rule in full (45 CFR §164.302–318)
- Comply with the Privacy Rule provisions applicable to BAs (45 CFR §164.502(e), §164.504(e))
- Report breaches to the CE under the Breach Notification Rule (45 CFR §164.410)

### Subcontractors

If your app uses third-party cloud storage, analytics, or infrastructure vendors that will have access to PHI, those vendors become **Subcontractors** — who are themselves treated as Business Associates. You must obtain BAAs from each of them (45 CFR §164.308(b)(3)).

---

## What PHI Does Your App Handle?

Under 45 CFR §160.103, PHI is individually identifiable health information that relates to:
- The past, present, or future physical or mental health condition of an individual
- The provision of healthcare to an individual
- Past, present, or future payment for healthcare

Your app processes at minimum:
| Data Element | PHI? | HIPAA Identifier |
|---|---|---|
| Patient name | Yes | Name identifier |
| Medical records / diagnoses | Yes | Health condition data |
| Doctor-patient messages | Yes | Health condition + treatment data |
| Appointment dates | Yes | Date identifier |
| IP addresses / device IDs | Yes | Electronic identifiers |

**All data flowing through your app is PHI and subject to full HIPAA protections.**

---

## Key Obligations by Entity Type

### If You Are (or Operate for) a Covered Entity:

1. **Notice of Privacy Practices (NPP)** — Must be provided to patients at first service (45 CFR §164.520)
2. **Minimum Necessary Standard** — Access to PHI must be limited to the minimum necessary for each purpose (45 CFR §164.502(b))
3. **Patient Rights** — Must support rights to access, amend, and request restrictions on their PHI (45 CFR §164.524–528)
4. **Workforce Training** — All staff with PHI access must be trained (45 CFR §164.530(b))
5. **Security Rule Compliance** — Must implement administrative, physical, and technical safeguards for ePHI (45 CFR §164.302–318)
6. **Breach Notification** — Must notify HHS and affected individuals within 60 days of discovering a breach (45 CFR §164.400–414)

### If You Are a Business Associate:

1. **Execute a BAA** with the Covered Entity before receiving PHI
2. **Security Rule** — Full compliance required (administrative, physical, technical safeguards)
3. **Breach Notification to CE** — Must notify the CE without unreasonable delay and within 60 days (45 CFR §164.410)
4. **Subcontractor BAAs** — Required for any downstream vendors handling PHI

---

## HITECH Act Considerations

The **Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009** strengthened HIPAA enforcement and extended direct liability to Business Associates. Key impacts:

- BAs are directly liable for HIPAA Security Rule violations (not just contractually via the CE)
- Increased civil monetary penalties up to **$1.9 million per violation category per year**
- Strengthened breach notification requirements
- Enabled state attorneys general to bring HIPAA enforcement actions

---

## Practical Next Steps

1. **Confirm your legal status** — Determine whether you are the CE or a BA serving a CE
2. **Execute BAAs** — With your CE client (if you are a BA) and with all vendors you use (cloud, analytics, etc.)
3. **Conduct a Risk Analysis** — Required under 45 CFR §164.308(a)(1)(ii)(A)
4. **Implement Technical Safeguards** — Encryption (AES-256 at rest, TLS 1.2+ in transit), audit logging, access controls, automatic logoff
5. **Draft or Obtain an NPP** — Required if operating as a CE
6. **Establish Breach Response Procedures** — Required under the Breach Notification Rule

---

> **Disclaimer:** This guidance is for informational purposes only and does not constitute legal advice. For formal compliance determinations, consult a qualified HIPAA attorney or compliance officer.

# HIPAA Applicability: Healthcare Patient App

## Do You Need to Comply with HIPAA?

**Yes, almost certainly.** An app that allows patients to view their medical records and communicate with doctors handles sensitive health information that is protected under HIPAA (the Health Insurance Portability and Accountability Act of 1996).

---

## What Is HIPAA and Who Does It Cover?

HIPAA establishes federal standards to protect sensitive patient health information. It applies to two main types of organizations:

### Covered Entities
Covered entities are organizations that directly provide or pay for healthcare:
- **Healthcare providers** — hospitals, clinics, doctor's offices, telehealth platforms with providers
- **Health plans** — insurance companies, HMOs
- **Healthcare clearinghouses** — organizations that process health information

If your app is built and operated by (or as part of) a hospital, clinic, physician group, or health plan, you are most likely a **Covered Entity** and have full HIPAA obligations.

### Business Associates
A Business Associate is any vendor, contractor, or service provider that handles protected health information (PHI) on behalf of a Covered Entity. Examples include:
- Technology companies building patient portals for hospitals
- Cloud storage providers hosting medical records
- Analytics firms processing health data

**If you are building this app for a healthcare organization rather than running it yourself as a provider, you are likely a Business Associate.** This means you must sign a Business Associate Agreement (BAA) with the healthcare organization before you can handle any patient data.

---

## What is PHI (Protected Health Information)?

PHI is any health information that can identify a specific individual. This includes:
- Names, addresses, phone numbers, email addresses
- Medical record numbers, diagnoses, treatment information
- Doctor-patient messages about health conditions
- Dates of service, appointment records
- Basically any health data tied to an identifiable person

Your app clearly processes PHI: it shows medical records and facilitates health-related communications between patients and doctors.

---

## Key Obligations

### If You Are a Covered Entity:
- Provide patients with a Notice of Privacy Practices
- Obtain patient authorization for uses of PHI beyond treatment, payment, and operations
- Implement security controls to protect patient data
- Notify patients and the government if a data breach occurs
- Train your workforce on HIPAA requirements
- Respect patient rights to access and amend their records

### If You Are a Business Associate:
- Sign a BAA with the covered entity (the healthcare provider)
- Implement security safeguards to protect the PHI you handle
- Report any breaches to the covered entity
- Ensure any subvendors you use also sign BAAs with you

---

## Practical Recommendation

1. Determine whether your organization is a healthcare provider (Covered Entity) or a technology vendor serving one (Business Associate)
2. If a Business Associate, execute a BAA with the healthcare organization you serve before handling any patient data
3. Implement security controls: encryption, access controls, audit logging
4. Establish a breach notification procedure
5. Consult with a healthcare attorney or compliance specialist to confirm your specific obligations

---

> **Note:** This response provides general information and does not constitute legal advice. Consult a qualified attorney or HIPAA compliance specialist for guidance specific to your situation.

# HIPAA Business Associate Agreement (BAA) Template
## Cloud Storage Vendor — PHI Storage

> **Template Generation Note:** This BAA template satisfies the requirements of 45 CFR §164.504(e) (Privacy Rule — BA contracts) and 45 CFR §164.308(b) (Security Rule — BA arrangements). All required provisions under HIPAA and the HITECH Act are included. Clauses marked **[REQUIRED]** are mandatory; clauses marked **[RECOMMENDED]** represent best practice but are not explicitly mandated.

---

# BUSINESS ASSOCIATE AGREEMENT

**Effective Date:** [EFFECTIVE DATE]

This Business Associate Agreement ("Agreement") is entered into between:

**Covered Entity / Business Associate (the "Covered Party"):**
[ORGANIZATION NAME]
[Address]
[City, State, ZIP]

**Business Associate ("BA"):**
[CLOUD STORAGE VENDOR NAME]
[Address]
[City, State, ZIP]

(Each a "Party," collectively the "Parties")

---

## RECITALS

WHEREAS, the Covered Party is a Covered Entity or Business Associate subject to the Health Insurance Portability and Accountability Act of 1996, as amended by the Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009, and the implementing regulations at 45 CFR Parts 160 and 164 (collectively, "HIPAA");

WHEREAS, the Business Associate provides cloud storage services ("Services") to the Covered Party, in the course of which the Business Associate may create, receive, maintain, or transmit Protected Health Information (PHI) on behalf of the Covered Party;

WHEREAS, HIPAA requires that the Covered Party obtain adequate assurances from the Business Associate regarding the safeguarding of PHI;

NOW, THEREFORE, in consideration of the mutual covenants herein, the Parties agree as follows:

---

## ARTICLE 1 — DEFINITIONS
// 45 CFR §164.504(e)(1); 45 CFR §160.103

**[REQUIRED]**

1.1 **"Breach"** has the meaning set forth at 45 CFR §164.402: the acquisition, access, use, or disclosure of PHI in a manner not permitted under the HIPAA Privacy Rule that compromises the security or privacy of such information, subject to the exclusions set forth therein.

1.2 **"Business Associate"** has the meaning set forth at 45 CFR §160.103.

1.3 **"Covered Entity"** has the meaning set forth at 45 CFR §160.103.

1.4 **"Electronic Protected Health Information" or "ePHI"** means PHI that is transmitted by or maintained in electronic media, as defined at 45 CFR §160.103.

1.5 **"Protected Health Information" or "PHI"** has the meaning set forth at 45 CFR §160.103, limited to the PHI created, received, maintained, or transmitted by the Business Associate on behalf of the Covered Party.

1.6 **"Required by Law"** has the meaning set forth at 45 CFR §164.103.

1.7 **"Secretary"** means the Secretary of the U.S. Department of Health and Human Services (HHS) or his/her designee.

1.8 **"Security Incident"** has the meaning set forth at 45 CFR §164.304.

1.9 **"Subcontractor"** has the meaning set forth at 45 CFR §160.103.

1.10 **"Unsecured PHI"** has the meaning set forth at 45 CFR §164.402.

All other capitalized terms not defined herein shall have the meanings ascribed to them under HIPAA.

---

## ARTICLE 2 — OBLIGATIONS AND ACTIVITIES OF THE BUSINESS ASSOCIATE
// 45 CFR §164.504(e)(2)

**[REQUIRED]**

2.1 **Permitted Uses and Disclosures.** The Business Associate may use or disclose PHI only:
   (a) As necessary to perform the Services described in the underlying services agreement between the Parties ("Services Agreement");
   (b) As Required by Law; or
   (c) As otherwise permitted or required by this Agreement.
// 45 CFR §164.504(e)(2)(i)

2.2 **Prohibition on Unauthorized Use or Disclosure.** The Business Associate shall not use or disclose PHI other than as permitted or required by this Agreement or as Required by Law.
// 45 CFR §164.504(e)(2)(ii)(A)

2.3 **Safeguards.** The Business Associate shall implement and maintain appropriate administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of ePHI that it creates, receives, maintains, or transmits on behalf of the Covered Party, in accordance with 45 CFR §§164.308, 164.310, and 164.312 (the HIPAA Security Rule).
// 45 CFR §164.504(e)(2)(ii)(B); 45 CFR §164.306

2.4 **Minimum Necessary.** The Business Associate shall, to the extent practicable, request and use only the minimum necessary PHI to accomplish the intended purpose of the use, disclosure, or request.
// 45 CFR §164.514(d)

2.5 **Reporting of Breaches and Security Incidents.**
// 45 CFR §164.504(e)(2)(ii)(C); 45 CFR §164.410

   (a) **Breach Notification.** The Business Associate shall notify the Covered Party of any Breach of Unsecured PHI without unreasonable delay and in no case later than **60 calendar days** after the Business Associate discovers such Breach. Such notification shall include, to the extent possible:
      - The identification of each individual whose Unsecured PHI has been, or is reasonably believed to have been, accessed, acquired, used, or disclosed;
      - A brief description of what happened, including the date of the Breach and the date of discovery;
      - A description of the types of Unsecured PHI involved;
      - Any steps individuals should take to protect themselves from potential harm;
      - A brief description of what the Business Associate is doing to investigate, mitigate harm, and prevent future occurrences.

   (b) **Security Incidents.** The Business Associate shall report to the Covered Party any Security Incident of which it becomes aware, including attempted and successful unauthorized access, use, disclosure, modification, or destruction of ePHI.

   **[RECOMMENDED]** The Parties agree that the Business Associate's obligation to report Security Incidents is satisfied by the Business Associate providing notice of the categories of Security Incidents on a **[quarterly / monthly]** basis, except that actual Breaches must be reported individually pursuant to Section 2.5(a).

2.6 **Subcontractors.** The Business Associate shall ensure that any Subcontractor that creates, receives, maintains, or transmits PHI on behalf of the Business Associate agrees to the same restrictions and conditions that apply to the Business Associate under this Agreement by executing a written agreement (a subcontractor BAA) meeting the requirements of 45 CFR §164.504(e)(2) and 45 CFR §164.308(b)(2) before disclosing PHI to such Subcontractor.
// 45 CFR §164.504(e)(2)(ii)(D)

2.7 **Access to PHI.** The Business Associate shall make available PHI in a designated record set to the Covered Party or, at the Covered Party's direction, to an individual, within **30 days** of a request, in a manner that permits the Covered Party to fulfill its obligations under 45 CFR §164.524.
// 45 CFR §164.504(e)(2)(ii)(E)

2.8 **Amendment of PHI.** The Business Associate shall make PHI available for amendment and incorporate any amendments to PHI in a designated record set upon request by the Covered Party, consistent with 45 CFR §164.526.
// 45 CFR §164.504(e)(2)(ii)(F)

2.9 **Accounting of Disclosures.** The Business Associate shall maintain documentation of all disclosures of PHI and information related to such disclosures necessary for the Covered Party to respond to a request for an accounting of disclosures pursuant to 45 CFR §164.528. The Business Associate shall provide such documentation to the Covered Party within **30 days** of a request.
// 45 CFR §164.504(e)(2)(ii)(G)

2.10 **Access by HHS.** The Business Associate shall make its internal practices, books, and records relating to the use and disclosure of PHI received from the Covered Party available to the Secretary for purposes of determining the Covered Party's and Business Associate's compliance with HIPAA.
// 45 CFR §164.504(e)(2)(ii)(H)

2.11 **Policies and Procedures.** The Business Associate shall implement and maintain written policies and procedures for each of the standards and implementation specifications required under the HIPAA Security Rule (45 CFR §164.316(a)).

2.12 **Training.** The Business Associate shall train all members of its workforce who have access to PHI on HIPAA requirements and the Business Associate's HIPAA policies and procedures, consistent with 45 CFR §164.530(b).

---

## ARTICLE 3 — PERMITTED USES AND DISCLOSURES BY BUSINESS ASSOCIATE
// 45 CFR §164.504(e)(3)-(4)

**[REQUIRED]**

3.1 **Services Performance.** The Business Associate is authorized to use PHI for the proper management and administration of the Business Associate's services to the Covered Party.

3.2 **Management and Administration.** The Business Associate may use PHI for the Business Associate's own management and administration and legal responsibilities, provided that:
   (a) Such disclosures are Required by Law; or
   (b) The Business Associate obtains reasonable assurances in writing from the person to whom the information is disclosed that it will be held confidentially, used or further disclosed only as Required by Law or for the purpose for which it was disclosed, and the person will notify the Business Associate of any instances of which it is aware in which the confidentiality of the information has been breached.

3.3 **Data Aggregation.** **[OPTIONAL — include only if the BA will perform data aggregation services]** The Business Associate may use PHI to provide data aggregation services to the Covered Party as permitted by 45 CFR §164.504(e)(2)(i)(B).

3.4 **De-Identification.** The Business Associate may de-identify PHI in accordance with 45 CFR §164.514(a)-(c). Once de-identified, such data is no longer PHI and is not subject to this Agreement.

---

## ARTICLE 4 — OBLIGATIONS OF THE COVERED PARTY

4.1 **Notice of Privacy Practices.** The Covered Party shall notify the Business Associate of any limitations in its Notice of Privacy Practices pursuant to 45 CFR §164.520, to the extent such limitations may affect the Business Associate's use or disclosure of PHI.

4.2 **Permissions and Restrictions.** The Covered Party shall notify the Business Associate of:
   (a) Any changes in, or revocation of, the permission by an individual to use or disclose his or her PHI; and
   (b) Any restrictions to the use or disclosure of PHI that the Covered Party has agreed to in accordance with 45 CFR §164.522.

4.3 **Permissible Requests.** The Covered Party shall not request the Business Associate to use or disclose PHI in any manner that would not be permissible under HIPAA if done by the Covered Party.

---

## ARTICLE 5 — TERM AND TERMINATION
// 45 CFR §164.504(e)(2)(iii)

**[REQUIRED]**

5.1 **Term.** This Agreement shall be effective as of the Effective Date and shall remain in effect until terminated by either Party or until all PHI provided by the Covered Party to the Business Associate is destroyed or returned to the Covered Party.

5.2 **Termination for Cause.** Upon the Covered Party's knowledge of a material breach of this Agreement by the Business Associate, the Covered Party shall:
   (a) Provide the Business Associate with an opportunity to cure the breach or end the violation; if the Business Associate fails to cure the breach within **30 days** of receiving notice, the Covered Party may terminate this Agreement; or
   (b) Immediately terminate this Agreement if cure is not possible.

5.3 **Effect of Termination.**

   (a) **Return or Destruction of PHI.** Upon termination, the Business Associate shall, at the Covered Party's election, either return or destroy all PHI received from, or created or received by the Business Associate on behalf of, the Covered Party. The Business Associate shall not retain any copies of the PHI.

   (b) **Infeasibility of Return or Destruction.** If return or destruction of PHI is not feasible, the Business Associate shall:
      - Notify the Covered Party in writing with an explanation of why return or destruction is infeasible;
      - Extend the protections of this Agreement to the retained PHI; and
      - Limit further uses and disclosures to those purposes that make return or destruction infeasible.
      
   **[RECOMMENDED]** Return or destruction shall be certified in writing by the Business Associate within **30 days** of termination.

5.4 **Survival.** The obligations of the Business Associate under this Article shall survive the termination of this Agreement.

---

## ARTICLE 6 — MISCELLANEOUS

6.1 **Regulatory References.** A reference in this Agreement to a section in HIPAA means the section as in effect or as amended.

6.2 **Amendment.** The Parties agree to take such action as is necessary to amend this Agreement to comply with the requirements of HIPAA as it may be amended from time to time.

6.3 **Interpretation.** Any ambiguity in this Agreement shall be resolved in favor of a meaning that permits the Covered Party to comply with HIPAA.

6.4 **No Third-Party Beneficiaries.** Nothing in this Agreement shall confer any rights or remedies upon any person other than the Parties and their respective successors and assigns.

6.5 **Entire Agreement.** This Agreement, together with the Services Agreement, constitutes the entire agreement of the Parties with respect to the subject matter hereof and supersedes all prior agreements, representations, and understandings.

6.6 **Governing Law.** This Agreement shall be governed by the laws of the State of [STATE], except to the extent preempted by federal law.

---

## ARTICLE 7 — SIGNATURES

**[ORGANIZATION NAME]**

By: ___________________________
Name: _________________________
Title: __________________________
Date: __________________________

**[CLOUD STORAGE VENDOR NAME]**

By: ___________________________
Name: _________________________
Title: __________________________
Date: __________________________

---

## Appendix A — Description of Services and PHI

**[REQUIRED — Describe the specific services and categories of PHI involved]**

| Item | Description |
|------|-------------|
| Services | Cloud storage and related services for PHI as described in the Services Agreement dated [DATE] |
| Categories of PHI | [e.g., patient demographics, medical records, clinical notes, diagnostic images, billing information] |
| Purpose of Disclosure | Storage and retrieval of PHI for [ORGANIZATION NAME]'s healthcare operations |
| Duration | Co-terminus with the Services Agreement |

---

> **Disclaimer:** This template is for informational purposes only and does not constitute legal advice. It should be reviewed and customized by a qualified HIPAA attorney before use. Requirements may vary based on your specific circumstances, applicable state law, and any future changes to HIPAA regulations. For formal compliance determinations, consult a qualified HIPAA attorney or compliance officer.

# HIPAA Business Associate Agreement (BAA) Template
## Cloud Storage Vendor

Below is a general BAA template covering the key provisions required under HIPAA for a cloud storage vendor that stores Protected Health Information (PHI).

---

# BUSINESS ASSOCIATE AGREEMENT

**Effective Date:** [EFFECTIVE DATE]

This Business Associate Agreement ("Agreement") is entered into by and between:

**[ORGANIZATION NAME]** ("Covered Entity" or "Company")

and

**[CLOUD STORAGE VENDOR NAME]** ("Business Associate")

---

## 1. PURPOSE AND BACKGROUND

The Business Associate provides cloud storage services to the Covered Entity. In performing these services, the Business Associate may create, receive, maintain, or transmit Protected Health Information (PHI) on behalf of the Covered Entity. The parties enter into this Agreement to comply with the requirements of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009.

---

## 2. DEFINITIONS

**"Business Associate"** means any person or entity, other than a member of the workforce of a covered entity, who performs functions or activities on behalf of, or provides certain services to, a covered entity that involves access to protected health information.

**"Covered Entity"** means a health plan, health care clearinghouse, or health care provider who transmits any health information in electronic form.

**"Protected Health Information" or "PHI"** means individually identifiable health information that is transmitted or maintained in any form or medium, including electronic form (ePHI), that relates to the past, present, or future physical or mental health condition of an individual.

**"Breach"** means the unauthorized acquisition, access, use, or disclosure of PHI that compromises its security or privacy.

**"Security Incident"** means the attempted or successful unauthorized access, use, disclosure, modification, or destruction of ePHI.

---

## 3. OBLIGATIONS OF THE BUSINESS ASSOCIATE

### 3.1 Permitted Uses and Disclosures
The Business Associate may use or disclose PHI only:
- As necessary to perform the cloud storage services described in the underlying services agreement
- As required by law
- As permitted under this Agreement

### 3.2 Prohibition on Unauthorized Use or Disclosure
The Business Associate shall not use or disclose PHI other than as permitted or required by this Agreement or applicable law.

### 3.3 Safeguards
The Business Associate shall implement and maintain appropriate administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of PHI, including ePHI, in accordance with HIPAA Security Rule requirements.

### 3.4 Subcontractors
The Business Associate shall require any subcontractors that create, receive, maintain, or transmit PHI on the Business Associate's behalf to agree to the same restrictions and conditions that apply to the Business Associate under this Agreement, through a written agreement.

### 3.5 Reporting
The Business Associate shall report to the Covered Entity:
- Any Breach of Unsecured PHI without unreasonable delay (and no later than 60 days after discovery)
- Any Security Incidents of which it becomes aware

### 3.6 Access to PHI
The Business Associate shall provide access to PHI as necessary for the Covered Entity to respond to individual requests to inspect and copy their records.

### 3.7 Amendment
The Business Associate shall make PHI available for amendment and incorporate amendments requested by the Covered Entity.

### 3.8 Accounting of Disclosures
The Business Associate shall maintain documentation of PHI disclosures needed for the Covered Entity to respond to accounting requests from individuals.

### 3.9 HHS Access
The Business Associate shall make its practices, books, and records relating to PHI available to the U.S. Department of Health and Human Services (HHS) for compliance purposes.

### 3.10 Minimum Necessary
The Business Associate shall use and disclose only the minimum necessary PHI to accomplish the intended purpose.

---

## 4. PERMITTED USES BY BUSINESS ASSOCIATE

The Business Associate may use PHI for:
- Proper management and administration of the Business Associate's own operations
- Legal obligations, provided that disclosures are required by law, or reasonable assurances of confidentiality are obtained

---

## 5. OBLIGATIONS OF COVERED ENTITY

The Covered Entity shall:
- Notify the Business Associate of any restrictions on PHI use or disclosure it has agreed to
- Not request the Business Associate to use or disclose PHI in a manner not permitted under HIPAA
- Provide the Business Associate with notice of privacy practice limitations that affect the Business Associate's activities

---

## 6. TERM AND TERMINATION

### 6.1 Term
This Agreement shall remain in effect throughout the term of the underlying services agreement and until all PHI is returned or destroyed.

### 6.2 Termination for Cause
Either party may terminate this Agreement if the other party materially breaches any provision and fails to cure such breach within 30 days of written notice.

### 6.3 Effect of Termination
Upon termination, the Business Associate shall return or destroy all PHI received from the Covered Entity. If return or destruction is not feasible, the Business Associate shall continue to protect the PHI and limit further uses to those making return or destruction infeasible.

---

## 7. GENERAL PROVISIONS

### 7.1 Regulatory Compliance
This Agreement shall be interpreted to give effect to HIPAA requirements. The parties agree to amend this Agreement as necessary to comply with changes in law.

### 7.2 No Third-Party Beneficiaries
This Agreement does not create any rights in third parties.

### 7.3 Entire Agreement
This Agreement, together with the underlying services agreement, constitutes the complete agreement between the parties regarding the subject matter hereof.

---

## 8. SIGNATURES

**[ORGANIZATION NAME]**

Signature: _______________________
Name: ___________________________
Title: ____________________________
Date: ____________________________

**[CLOUD STORAGE VENDOR NAME]**

Signature: _______________________
Name: ___________________________
Title: ____________________________
Date: ____________________________

---

> **Note:** This template provides a general framework and should be reviewed by a qualified healthcare attorney before use. Specific provisions may need to be adjusted based on your state's laws, the nature of the PHI involved, and the specific services being provided.

# HIPAA Encryption Requirements for PHI

## HIPAA Technical Assessment: Encryption of PHI

### ePHI in Scope
Any electronic Protected Health Information (ePHI) — patient records, health data, communications, diagnostic images, billing information — stored in databases, file systems, backups, or transmitted over networks.

---

## The Core Answer: "Addressable" Does Not Mean Optional

HIPAA uses a two-tier framework for Security Rule implementation specifications:

| Classification | Meaning | Example |
|---|---|---|
| **Required** | Must be implemented; no discretion | Unique user IDs (§164.312(a)(2)(i)) |
| **Addressable** | Must assess, then implement OR document equivalent alternative | Encryption (§164.312(a)(2)(iv), §164.312(e)(2)(ii)) |

**Encryption is classified as "Addressable" under HIPAA — not "Required."** However, this is frequently misunderstood. "Addressable" does **not** mean optional. Under 45 CFR §164.306(d)(3), a covered entity or business associate that determines an addressable specification is not reasonable and appropriate must:

1. Document the reason it is not reasonable and appropriate
2. Implement an equivalent alternative measure that is reasonable and appropriate

In practice, **virtually every organization that handles ePHI should implement encryption**, because:
- No reasonable alternative security measure provides equivalent protection
- HHS Office for Civil Rights (OCR) consistently treats lack of encryption as a major risk factor
- The HITECH Act and subsequent guidance strongly incentivize encryption through the "Safe Harbor" provision

---

## Specific Regulatory Citations

### Encryption at Rest
**45 CFR §164.312(a)(2)(iv)** — Encryption and Decryption (Addressable)

> *"Implement a mechanism to encrypt and decrypt electronic protected health information."*

This applies to ePHI stored on:
- Servers and databases
- Laptops and workstations
- Portable media (USB drives, hard drives)
- Backup tapes and cloud storage

**Industry Standard:** AES-256 encryption for data at rest. This is the NIST-recommended standard and satisfies HHS guidance on encryption under the Breach Notification Rule (45 CFR §164.402).

### Encryption in Transit
**45 CFR §164.312(e)(2)(ii)** — Encryption in Transit (Addressable)

> *"Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate."*

This applies to ePHI transmitted over:
- Public networks (internet)
- Internal networks where unauthorized access is possible
- APIs, web services, and mobile communications

**Industry Standard:** TLS 1.2 or higher (TLS 1.3 preferred) for all data in transit. Older protocols (SSL, TLS 1.0, TLS 1.1) are not acceptable.

### Transmission Security — General
**45 CFR §164.312(e)(1)** — Transmission Security (Required)

> *"Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network."*

This is a **Required** specification. Encryption (TLS 1.2+) is the most effective mechanism to satisfy this requirement.

---

## Do You Legally Have to Encrypt?

**Technically, the regulations do not mandate encryption as an absolute legal requirement.** However, the practical and legal reality is:

1. **OCR Enforcement:** HHS OCR has imposed significant fines in cases where unencrypted PHI was breached. The absence of encryption is treated as evidence of inadequate safeguards.

2. **Risk Analysis Requirement (45 CFR §164.308(a)(1)):** Your required risk analysis will almost certainly identify unencrypted PHI as a high-severity risk. If you identify the risk and fail to mitigate it with encryption (or a documented equivalent), you are exposed.

3. **No Credible Alternative:** In most systems, there is no equivalent alternative to encryption. Organizations that claim "physical security" as an alternative for, e.g., laptop encryption have fared poorly in OCR investigations.

4. **Conclusion:** Any organization that opts not to encrypt ePHI without a documented, well-reasoned rationale and an equivalent alternative is taking on substantial legal and financial risk.

---

## The Breach Safe Harbor — The Key Incentive to Encrypt

**45 CFR §164.402** and the HHS Breach Notification guidance establish a "Safe Harbor" for encrypted data:

> A breach does not include the acquisition, access, use, or disclosure of PHI where the PHI is **rendered unusable, unreadable, or indecipherable to unauthorized persons** through the use of a technology or methodology specified in HHS guidance.

**HHS guidance specifies:** Data encrypted using a valid encryption algorithm (NIST-approved, e.g., AES-128 or higher) with the decryption key not compromised is rendered unusable, unreadable, and indecipherable.

### What This Means in Practice:

If a laptop with encrypted PHI is stolen, **no breach notification is required** — because the data is "unusable, unreadable, or indecipherable."

If a laptop with **unencrypted** PHI is stolen, you must:
1. Conduct a four-factor risk assessment to determine if a breach occurred
2. In most cases, provide breach notification to affected individuals (within 60 days — 45 CFR §164.404)
3. If 500+ individuals in a state are affected, notify prominent media outlets (45 CFR §164.406)
4. Report to HHS — if 500+ individuals, report immediately; if fewer, report on the annual log (45 CFR §164.408)
5. Face potential OCR investigation and civil monetary penalties

---

## If There Is a Breach and Data Was Not Encrypted

Under the HITECH Act (42 U.S.C. §17931) and the Breach Notification Rule (45 CFR §164.400–414):

### Step 1: Presumption of Breach
Unencrypted PHI that is accessed, acquired, used, or disclosed without authorization is **presumed to be a reportable breach** unless you can demonstrate through a four-factor risk assessment that there is a low probability that the PHI was compromised:

The four factors (45 CFR §164.402(2)):
1. The nature and extent of the PHI involved (types of identifiers, likelihood of re-identification)
2. Who accessed or could have accessed the PHI
3. Whether the PHI was actually acquired or viewed
4. The extent to which the risk has been mitigated

### Step 2: Mandatory Notifications
If breach is confirmed:
- **Individuals:** Written notification within 60 days (45 CFR §164.404)
- **HHS:** If 500+ individuals, contemporaneous notice; if fewer, annual log (45 CFR §164.408)
- **Media:** If 500+ individuals in a state or jurisdiction (45 CFR §164.406)

### Step 3: OCR Investigation & Penalties
OCR will investigate large breaches. Civil monetary penalties under the HITECH Act (as adjusted by inflation) range from:

| Violation Category | Per Violation | Annual Cap |
|---|---|---|
| Did not know (reasonable diligence) | $137 – $68,928 | $2,067,813 |
| Reasonable cause | $1,379 – $68,928 | $2,067,813 |
| Willful neglect — corrected | $13,785 – $68,928 | $2,067,813 |
| Willful neglect — not corrected | $68,928 – $2,067,813 | $2,067,813 |

**Failure to encrypt, combined with a breach of unencrypted PHI, is frequently treated by OCR as willful neglect**, particularly when the risk was identified in a prior risk analysis but not remediated. Willful neglect penalties start at $13,785 per violation and can reach $2,067,813 per year per violation category.

### Notable Enforcement Examples
- **Advocate Health Care (2016):** $5.55M settlement after unencrypted laptops containing PHI were stolen
- **Lahey Hospital (2015):** $850,000 settlement after unencrypted laptop stolen
- **University of Rochester Medical Center (2019):** $3M settlement after unencrypted flash drives and laptop were lost/stolen

---

## Practical Recommendations

### Technical Safeguards Checklist

#### Encryption at Rest
- [ ] Database encryption: AES-256 (§164.312(a)(2)(iv))
- [ ] Full-disk encryption on all laptops and workstations (BitLocker, FileVault, or equivalent)
- [ ] Encrypt backup media and portable storage devices
- [ ] Cloud storage: Use HIPAA-eligible services with encryption enabled; execute BAA

#### Encryption in Transit
- [ ] TLS 1.2+ for all web applications, APIs, and services (§164.312(e)(2)(ii))
- [ ] Disable SSL, TLS 1.0, and TLS 1.1
- [ ] Encrypt email containing PHI (S/MIME or secure messaging portal)
- [ ] VPN for remote access to systems containing ePHI

#### Key Management
- [ ] Document encryption key management procedures (§164.312(a)(2)(iv))
- [ ] Restrict access to encryption keys to authorized personnel only
- [ ] Rotate keys periodically and upon personnel changes

#### Documentation (Required)
- [ ] Document the decision to implement encryption and the specific methods used (§164.316(b))
- [ ] If not encrypting a specific system, document the risk assessment rationale and equivalent alternative
- [ ] Retain documentation for minimum 6 years (§164.316(b)(2)(i))

---

> **Disclaimer:** This guidance is for informational purposes only and does not constitute legal advice. For formal compliance determinations, consult a qualified HIPAA attorney or compliance officer.

# HIPAA Encryption Requirements for PHI

## Is Encryption Required Under HIPAA?

The answer is nuanced: **HIPAA does not technically mandate encryption as an absolute requirement, but in practice, it is nearly always required.**

HIPAA's Security Rule divides security controls into two categories:
- **Required**: Must be implemented without exception
- **Addressable**: Must be implemented OR an equivalent alternative must be documented and implemented

Encryption falls into the **"addressable"** category — for both data at rest and data in transit. This is widely misunderstood. "Addressable" does NOT mean optional. If you choose not to encrypt, you must document why encryption is not reasonable and appropriate, and document what equivalent alternative measure you have implemented.

In reality, **virtually every healthcare organization should encrypt PHI**, because:
1. No equivalent alternative exists for most use cases
2. HHS/OCR consistently penalizes organizations that fail to encrypt when a breach occurs
3. The risk analysis that HIPAA requires will almost always identify unencrypted PHI as a serious risk

---

## Encryption at Rest

The HIPAA Security Rule requires organizations to consider implementing encryption for stored ePHI (electronic PHI). This covers:
- Database servers storing patient records
- Laptops and workstations
- Portable media (USB drives, external hard drives)
- Cloud storage
- Backup systems

**Best practice standard:** AES-256 encryption for data at rest.

---

## Encryption in Transit

HIPAA requires implementing security measures to protect ePHI transmitted over networks. Encryption in transit is the primary mechanism for satisfying this requirement. This covers:
- Web applications transmitting patient data
- APIs used by healthcare apps
- Email containing PHI
- Remote access to healthcare systems

**Best practice standard:** TLS 1.2 or higher for all data transmissions.

---

## What Happens if You Have a Breach Without Encryption?

This is where the lack of encryption becomes extremely costly. HIPAA includes a **"Safe Harbor" provision**: if breached data was encrypted according to NIST standards, it is NOT considered a reportable breach. The data is "unusable, unreadable, or indecipherable" to unauthorized persons.

**If the data was NOT encrypted when a breach occurs:**

### You Must Assess and Likely Report the Breach
You must conduct a risk assessment considering:
- What type of PHI was involved
- Who accessed it
- Whether it was actually viewed or taken
- What mitigation steps are possible

In most cases, unencrypted PHI breaches are reportable breaches.

### Breach Notification Requirements
- **Affected individuals** must be notified within 60 days
- **HHS (Department of Health and Human Services)** must be notified
- **Media** must be notified if 500 or more individuals in a state are affected
- If fewer than 500 individuals, the breach must be logged and reported to HHS annually

### Financial Penalties
HIPAA civil monetary penalties range significantly based on culpability:
- Minor violations: Thousands of dollars
- Willful neglect: Up to $1.9 million per violation category per year

**Failing to encrypt, when a breach then occurs, is typically treated as "willful neglect" or at minimum "reasonable cause" — which carries the higher penalty tiers.** Several high-profile settlements have involved unencrypted devices being lost or stolen:
- Stolen laptops without encryption have resulted in settlements of $1M–$5M+
- Lost USB drives with unencrypted PHI have triggered significant penalties

---

## Summary

| Question | Answer |
|---|---|
| Is encryption legally required? | Addressable (not absolute), but almost always necessary |
| Encrypt data at rest? | Yes, practically required; AES-256 recommended |
| Encrypt data in transit? | Yes, practically required; TLS 1.2+ recommended |
| What if breach occurs without encryption? | Must notify individuals, HHS, possibly media; faces penalties |
| What if breach occurs WITH encryption? | Likely qualifies for safe harbor — no breach notification required |

---

## Recommendations

1. **Encrypt all ePHI at rest and in transit** — use AES-256 and TLS 1.2+
2. **Document your encryption decisions** in your security policies and procedures
3. **Include encryption in your risk analysis** — if you're not encrypting something, document why
4. **Ensure your cloud vendors** have BAAs and provide encryption as part of their HIPAA-eligible services
5. Consult a HIPAA attorney or compliance specialist to confirm your specific approach

---

> **Note:** This response provides general information and does not constitute legal advice. Consult a qualified attorney or HIPAA compliance specialist for guidance specific to your situation.

# HIPAA Risk Analysis: Required Elements and Documentation

## Overview

A HIPAA Security Risk Analysis is not optional — it is a **required implementation specification** under the HIPAA Security Rule at **45 CFR §164.308(a)(1)(ii)(A)**:

> *"Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate."*

The Risk Analysis must be conducted initially and reviewed and updated periodically — after significant operational or environmental changes, and whenever required to ensure ePHI protections remain adequate (45 CFR §164.308(a)(1)(ii)(D)).

Failure to conduct a risk analysis is one of the most commonly cited HIPAA violations in OCR enforcement actions and is frequently the basis for significant civil monetary penalties.

---

## Required Elements of a HIPAA Risk Analysis

HHS published detailed guidance on required risk analysis elements (see "Guidance on Risk Analysis," HHS.gov). The following eight elements are required:

### 1. Scope of the Analysis
**Regulatory basis:** 45 CFR §164.308(a)(1)(ii)(A)

The risk analysis must cover **all ePHI** your organization creates, receives, maintains, or transmits — regardless of the medium or format, and regardless of whether it is in production systems, backups, archives, or portable devices.

Document:
- All systems, applications, and devices that store, process, or transmit ePHI
- All physical locations where ePHI exists
- All workforce members who access ePHI
- All vendors and business associates with access to ePHI

**Common mistake:** Scoping only electronic health record (EHR) systems while missing billing systems, email, fax, portable devices, backup storage, and third-party vendors.

---

### 2. Data Collection — Identify All ePHI
**Regulatory basis:** 45 CFR §164.308(a)(1)(ii)(A)

Create a comprehensive inventory of all ePHI:
- Where is ePHI created, stored, transmitted, and received?
- What applications and systems process ePHI?
- What data flows exist (internal systems, external APIs, vendor connections)?
- What portable and removable media contains ePHI?

Document this as a **data flow map** or **ePHI inventory** showing all data stores and transmission paths.

---

### 3. Identify Threats
**Regulatory basis:** 45 CFR §164.308(a)(1)(ii)(A)

Identify realistic threats to ePHI — natural, human, and environmental:

| Threat Category | Examples |
|---|---|
| Human — Malicious | External cyberattacks, ransomware, insider theft, social engineering |
| Human — Unintentional | Accidental disclosure, misconfiguration, misdirected email |
| Natural | Flood, fire, earthquake, hurricane |
| Environmental | Power failure, HVAC failure, hardware failure |

---

### 4. Identify Vulnerabilities
**Regulatory basis:** 45 CFR §164.308(a)(1)(ii)(A)

Identify weaknesses in your systems, processes, and controls that could be exploited by threats:

- Technical vulnerabilities (unpatched software, weak authentication, lack of encryption)
- Operational vulnerabilities (inadequate access controls, lack of workforce training)
- Physical vulnerabilities (unlocked server rooms, unencrypted portable devices)
- Procedural vulnerabilities (no incident response plan, no documented policies)

Methods: vulnerability scans, penetration testing, policy reviews, workforce interviews, physical walkthroughs.

---

### 5. Assess Current Security Controls
**Regulatory basis:** 45 CFR §164.308(a)(1)(ii)(A); §164.306(b)

Evaluate the administrative, physical, and technical safeguards currently in place:

#### Administrative Safeguards (45 CFR §164.308)
- [ ] Risk management policy (§164.308(a)(1))
- [ ] Assigned security responsibility (§164.308(a)(2))
- [ ] Workforce training and sanctions (§164.308(a)(3), (a)(5))
- [ ] Access management procedures (§164.308(a)(4))
- [ ] Contingency planning (§164.308(a)(7))
- [ ] Business associate agreements (§164.308(b))

#### Physical Safeguards (45 CFR §164.310)
- [ ] Facility access controls (§164.310(a))
- [ ] Workstation use and security policies (§164.310(b), (c))
- [ ] Device and media controls (§164.310(d))

#### Technical Safeguards (45 CFR §164.312)
- [ ] Access controls and unique user IDs (§164.312(a))
- [ ] Audit controls and logging (§164.312(b))
- [ ] Integrity controls (§164.312(c))
- [ ] Transmission security / encryption in transit (§164.312(e))
- [ ] Encryption at rest (§164.312(a)(2)(iv))

---

### 6. Determine the Likelihood of Threat Occurrence
**Regulatory basis:** 45 CFR §164.308(a)(1)(ii)(A)

For each identified threat-vulnerability pair, assign a likelihood rating:

| Likelihood Level | Definition |
|---|---|
| High | Threat is highly motivated and capable; controls are inadequate |
| Medium | Threat is motivated and capable; controls are partially effective |
| Low | Threat lacks motivation or capability; controls are largely effective |

Document your rationale for each rating.

---

### 7. Determine the Potential Impact of Threat Occurrence
**Regulatory basis:** 45 CFR §164.308(a)(1)(ii)(A)

For each threat-vulnerability pair, assess the potential impact on:
- **Confidentiality** — Unauthorized access or disclosure of ePHI
- **Integrity** — Unauthorized modification or destruction of ePHI
- **Availability** — Disruption of access to ePHI

| Impact Level | Definition |
|---|---|
| High | Severe or catastrophic impact on operations, patient safety, or privacy |
| Medium | Significant impact, manageable with effort |
| Low | Minor impact, easily managed |

---

### 8. Determine the Level of Risk
**Regulatory basis:** 45 CFR §164.308(a)(1)(ii)(A)

Combine likelihood and impact to calculate a risk level for each threat-vulnerability pair:

| | Low Impact | Medium Impact | High Impact |
|---|---|---|---|
| **High Likelihood** | Medium Risk | High Risk | High Risk |
| **Medium Likelihood** | Low Risk | Medium Risk | High Risk |
| **Low Likelihood** | Low Risk | Low Risk | Medium Risk |

Risk levels drive prioritization of the Risk Management Plan (next step under 45 CFR §164.308(a)(1)(ii)(B)).

---

### 9. Document the Risk Analysis (Required)
**Regulatory basis:** 45 CFR §164.316(b)(1)

All findings, methodologies, and decisions must be documented in writing. Documentation must be:
- Retained for a minimum of **6 years** from the date of creation or the date when it was last in effect, whichever is later (45 CFR §164.316(b)(2)(i))
- Made available to HHS upon request (45 CFR §164.316(b)(2)(iii))

---

## Required Documentation to Produce

The following documents must be produced as outputs of the risk analysis process:

### 1. Risk Analysis Report
The primary deliverable. Must include:
- [ ] Executive summary of findings
- [ ] Scope statement (systems, locations, data types in scope)
- [ ] Methodology description (how threats and vulnerabilities were identified)
- [ ] ePHI inventory / data flow diagram
- [ ] Threat inventory with sources and rationale
- [ ] Vulnerability inventory with assessment method
- [ ] Current controls assessment
- [ ] Likelihood ratings per threat-vulnerability pair (with rationale)
- [ ] Impact ratings per threat-vulnerability pair (with rationale)
- [ ] Risk level matrix
- [ ] Date of analysis and names of personnel who conducted it

### 2. ePHI Inventory / Data Flow Map
A complete record of:
- All systems and data stores containing ePHI
- Data flows between systems, staff, vendors, and patients
- Data types (demographics, clinical data, billing, etc.)

### 3. Risk Register
A living document listing:
- Each identified risk (threat + vulnerability)
- Likelihood rating
- Impact rating
- Composite risk level
- Current controls in place
- Risk owner
- Status (open, in remediation, accepted)

### 4. Risk Management Plan
**Required by 45 CFR §164.308(a)(1)(ii)(B):** Once risks are identified, you must implement security measures to reduce risks to a reasonable and appropriate level. The Risk Management Plan documents:
- Prioritized list of risks to address
- Remediation actions for each risk
- Responsible parties
- Target completion dates
- Status tracking

### 5. Policies and Procedures
**Required by 45 CFR §164.308(a)(1):** Documented policies implementing risk analysis and risk management.

### 6. Workforce Training Records
**Required by 45 CFR §164.308(a)(5):** Documentation that workforce members involved in the risk analysis have been trained on security policies and procedures.

---

## Periodic Review and Updates

The Risk Analysis must be reviewed and updated:
- At least **annually** (best practice; not explicitly specified but strongly recommended by OCR)
- After any **significant environmental or operational change** affecting ePHI (45 CFR §164.308(a)(1)(ii)(D))
- After a **security incident or breach**
- After implementing new technology or systems
- After personnel changes in key security roles
- After a merger, acquisition, or new service line

---

## Common Deficiencies Cited by OCR

1. **Scope too narrow** — Only covering the EHR system, missing email, billing, portable devices
2. **No documentation** — Risk analysis conducted verbally or informally with no written record
3. **Point-in-time, never updated** — Conducted once at implementation, never reviewed
4. **No risk management plan** — Risks identified but never tracked or remediated
5. **Conducted by unqualified staff** — Must be conducted by someone with security expertise

---

> **Disclaimer:** This guidance is for informational purposes only and does not constitute legal advice. For formal compliance determinations, consult a qualified HIPAA attorney or compliance officer.

# HIPAA Risk Analysis: Required Elements and Documentation

## What Is a HIPAA Risk Analysis?

A HIPAA Security Risk Analysis is a **mandatory requirement** under the HIPAA Security Rule. It is not optional. Every covered entity and business associate must conduct one, and failure to do so is one of the most common reasons organizations face HIPAA enforcement actions and fines.

The risk analysis must be an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic PHI (ePHI) that your organization creates, receives, maintains, or transmits.

---

## Required Elements of a HIPAA Risk Analysis

HIPAA does not prescribe a specific methodology, but HHS guidance identifies the following required components:

### 1. Define the Scope
Identify all ePHI in your organization — where it is created, received, stored, maintained, and transmitted. This includes:
- Electronic health record (EHR) systems
- Billing systems
- Email and communication tools containing PHI
- Portable devices (laptops, smartphones, USB drives)
- Cloud storage and backup systems
- Third-party vendor systems with access to PHI

**The scope must cover all ePHI, not just your primary clinical systems.**

### 2. Gather Information / Data Collection
Identify and document:
- All information systems that process ePHI
- All workforce members who handle ePHI
- All physical locations where ePHI exists
- All business associates and vendors with access to ePHI
- Data flows showing how ePHI moves between systems and people

### 3. Identify Threats and Vulnerabilities
Identify realistic threats to your ePHI:
- **External threats:** Hackers, ransomware, phishing attacks, physical theft
- **Internal threats:** Unauthorized access by employees, accidental disclosure
- **Natural threats:** Floods, fires, power outages, hardware failures

Identify vulnerabilities — weaknesses that could be exploited:
- Unpatched software
- Weak passwords or no multi-factor authentication
- Lack of access controls
- Inadequate staff training
- Physical security gaps

### 4. Assess Current Security Controls
Evaluate what security measures you already have in place:
- Administrative controls (policies, training, access management)
- Physical controls (locks, badges, security cameras, clean desk policies)
- Technical controls (encryption, firewalls, audit logs, access controls)

Determine how effective these controls are at mitigating identified threats and vulnerabilities.

### 5. Determine Likelihood of Threat Occurrence
For each threat-vulnerability pair, assess how likely it is that the threat will exploit the vulnerability, given your current controls:
- **High** — Likely to occur without additional controls
- **Medium** — Possible but existing controls provide some protection
- **Low** — Unlikely given existing controls

### 6. Determine Potential Impact
Assess the potential harm if the threat occurred:
- Impact on patient privacy and confidentiality
- Impact on data integrity
- Impact on system availability
- Regulatory, legal, and reputational consequences

Rate impact as High, Medium, or Low.

### 7. Determine the Level of Risk
Combine likelihood and impact to arrive at an overall risk level for each risk:
- High likelihood + High impact = High Risk (address immediately)
- Various combinations yield Medium or Low risk

### 8. Document Everything
All of the above must be documented in writing. Documentation must be maintained for at least 6 years.

---

## Documentation You Need to Produce

### Required Documents

1. **Risk Analysis Report**
   - Written narrative describing your methodology, findings, and conclusions
   - Should be comprehensive and defensible if reviewed by HHS
   - Include the date, names of analysts, and scope definition

2. **ePHI Inventory or Data Flow Diagram**
   - Complete list of all systems and locations containing ePHI
   - How ePHI flows between systems, users, and external parties

3. **Threat and Vulnerability Register**
   - List of all identified threats and vulnerabilities
   - Likelihood and impact ratings with rationale
   - Risk levels assigned to each combination

4. **Current Controls Assessment**
   - Documentation of existing administrative, physical, and technical safeguards
   - Effectiveness rating for each

5. **Risk Register**
   - Comprehensive list of identified risks, owners, status, and risk levels
   - Living document that is updated as risks change

6. **Risk Management Plan**
   - Prioritized plan to address identified risks
   - Actions, responsible parties, timelines, and status

### Supporting Documentation

- **Policies and Procedures** — Written HIPAA security policies referenced in your risk analysis
- **Training Records** — Evidence that relevant staff have been trained on HIPAA security requirements
- **Business Associate Agreements** — BAAs with all vendors who access ePHI

---

## How Often Must the Risk Analysis Be Updated?

HIPAA requires that the risk analysis be reviewed and updated periodically, particularly:
- At least annually (best practice)
- After significant changes to systems, operations, or the threat environment
- After a security incident or breach
- When new technology is implemented
- After organizational changes (mergers, acquisitions, new service lines)

---

## Key Mistakes to Avoid

1. Scoping only your EHR — you must include all systems with ePHI
2. Not documenting your work — verbal or informal analysis does not satisfy HIPAA
3. Conducting it once and never updating it
4. Identifying risks but never creating a remediation plan
5. Not retaining documentation for the required period (6 years)

---

> **Note:** This response provides general information and does not constitute legal advice. Consult a qualified attorney or HIPAA compliance specialist for guidance specific to your organization.

# HIPAA Workforce Violation Analysis: Unauthorized Access to Celebrity Patient Records

## HIPAA Compliance Review

**Scope:** Covered Entity (Hospital)
**Rules Applicable:** Privacy Rule (45 CFR Part 164, Subpart E), Breach Notification Rule (45 CFR Part 164, Subpart D)

---

## What HIPAA Violation Occurred?

### Primary Violation: Impermissible Use/Disclosure of PHI
**45 CFR §164.502(a)** — General Rules for Uses and Disclosures

The nurse accessed the celebrity patient's medical records without a legitimate purpose. Under HIPAA's Privacy Rule, a covered entity may only use or disclose PHI in ways that are:

1. **Permitted or required by the Privacy Rule** (45 CFR §164.502(a)(1))
2. **Authorized by the individual** in writing (45 CFR §164.508)

Medical records may be accessed by workforce members only to the extent necessary for **Treatment, Payment, or Healthcare Operations (TPO)** — the three core permitted uses under 45 CFR §164.506. "Curiosity" or professional or personal interest in a celebrity does not constitute a permissible purpose under any exception.

### Minimum Necessary Standard Violated
**45 CFR §164.502(b)** and **§164.514(d)**

Even for legitimate purposes, HIPAA requires that access to PHI be limited to the **minimum necessary** to accomplish the intended purpose. A nurse with no treatment relationship to this patient has zero legitimate need to access their records. This is a clear violation of the minimum necessary standard.

### Additional Violation: Failure of Workforce Access Controls (Potentially)
**45 CFR §164.308(a)(4)** — Access Management (Administrative Safeguard)

If the hospital's access controls permitted the nurse to access records of patients outside their care team without restriction, this may also indicate a systemic failure in the hospital's access management program. Hospitals are expected to implement role-based access controls that limit access to records of patients under a workforce member's care.

---

## Is This a Reportable Breach?

### Step 1: Was PHI Accessed? Yes.
The nurse accessed the patient's medical records — this is an acquisition or access of PHI.

### Step 2: Was It an Impermissible Access? Yes.
No treatment relationship + no legitimate operational purpose = impermissible use under 45 CFR §164.502.

### Step 3: Presumption of Breach Under 45 CFR §164.402
Under the Breach Notification Rule (as amended by the HITECH Act), an impermissible use or disclosure of PHI is **presumed to be a reportable breach** unless the organization can demonstrate through a documented four-factor risk assessment that there is a **low probability that the PHI has been compromised**.

The four factors (45 CFR §164.402(2)):

| Factor | Analysis |
|---|---|
| 1. Nature and extent of the PHI involved (types of identifiers, likelihood of re-identification) | Medical records typically contain the most sensitive categories of PHI — diagnoses, medications, treatment history |
| 2. Who accessed or used the PHI, or to whom was it disclosed | Internal workforce member — not a confirmed external attacker; some mitigation possible |
| 3. Whether the PHI was actually acquired or viewed | If the nurse viewed the records, this is arguably "viewed" — weigh carefully |
| 4. Extent to which the risk to the PHI has been mitigated | Has access been revoked? Has the nurse been interviewed? Are there logs showing extent of access? |

**Critical note:** The key question is whether you can demonstrate a **low probability** of compromise. Given that celebrity patients are specifically targeted for gossip, media leaks, and tabloid exposure, the hospital's risk assessment will face significant scrutiny. OCR has taken the position that snooping by insiders on high-profile patients is a serious matter warranting careful analysis — and often concludes the presumption is not overcome.

---

## Your Obligations

### 1. Conduct the Breach Risk Assessment Immediately
**45 CFR §164.402** — Document the four-factor analysis in writing. This is not optional. The written documentation is your evidence that you conducted a proper assessment.

### 2. If Breach is Confirmed — Individual Notification
**45 CFR §164.404**
- Notify the affected patient **in writing** (first-class mail or email with prior authorization)
- Notification must occur **within 60 calendar days** of discovering the breach
- Required content (45 CFR §164.404(c)):
  - Brief description of what happened and date of breach and discovery
  - Description of the types of PHI involved
  - Steps the individual should take to protect themselves
  - What the covered entity is doing to investigate, mitigate, and prevent future occurrences
  - Contact information (toll-free number, email, address)

**Note on celebrity patients:** Given the high-profile nature, consider whether the patient has legal counsel and whether individual notification should be coordinated with them.

### 3. If Breach is Confirmed — HHS Notification
**45 CFR §164.408**

- **If fewer than 500 individuals are affected:** Log in the breach log and submit to HHS **no later than 60 days after the end of the calendar year** in which the breach occurred (annual log report)
- **If 500 or more individuals in a state/jurisdiction are affected:** Notify HHS **contemporaneously** with individual notification (within 60 days of discovery)

This breach involves one individual, so the annual log reporting path applies — but it will still be visible to OCR.

### 4. Media Notification — Likely Not Required Here
**45 CFR §164.406** — Media notification is required only when 500 or more residents of a state or jurisdiction are affected. This breach involves one patient.

### 5. Workforce Sanctions — Required
**45 CFR §164.530(e)** — Covered entities must have and apply appropriate **sanctions against workforce members** who fail to comply with HIPAA policies. Sanctions must be applied consistently and documented.

Appropriate sanctions may include:
- Verbal or written warning (for minor, first-time violations)
- Suspension
- Termination (for deliberate, egregious, or repeated violations)
- Referral to state licensing board (for licensed professionals such as nurses — this can affect licensure)

**Given the deliberate, intentional nature of accessing records without a care relationship, this is typically treated as a serious violation warranting significant disciplinary action.**

### 6. Workforce Investigation
**45 CFR §164.308(a)(1)(ii)(D)** — Conduct an investigation to determine:
- What records were accessed and for how long (pull audit logs — required under §164.312(b))
- Whether the nurse disclosed any information to third parties
- Whether this is a pattern (were other patients' records accessed?)
- Whether the access controls in place were adequate

Audit logs must capture who accessed what PHI, when, and from where — this is a Required specification under 45 CFR §164.312(b).

### 7. Remediation of Root Causes
**45 CFR §164.308(a)(1)(ii)(B)** — Risk Management

Implement measures to address any identified vulnerabilities:
- Review and tighten role-based access controls
- Ensure access is limited to patients in a workforce member's care team
- Implement audit log monitoring and alerts for anomalous access patterns
- Retrain the workforce on appropriate access standards

### 8. Documentation
**45 CFR §164.316(b)** — All actions taken must be documented and retained for 6 years.

---

## Penalties That Could Apply

### Workforce Member Personal Liability
The HITECH Act (42 U.S.C. §17937) extended potential **criminal liability** to workforce members who wrongfully access PHI:

Under 42 U.S.C. §1320d-6 (criminal penalties for HIPAA violations):

| Offense | Penalty |
|---|---|
| Knowingly obtaining or disclosing PHI in violation of HIPAA | Up to $50,000 fine and 1 year imprisonment |
| Offense under false pretenses | Up to $100,000 fine and 5 years imprisonment |
| Offense for commercial advantage, personal gain, or malicious harm | Up to $250,000 fine and 10 years imprisonment |

If the nurse accessed records to sell to media or for personal gain, criminal prosecution is possible.

### Organizational Penalties — Civil Monetary Penalties
**45 CFR §160.404; 45 CFR §164.408**

If OCR investigates:

| Violation Category | Per Violation | Annual Cap |
|---|---|---|
| Did not know (and could not have known) | $137 – $68,928 | ~$2.07M |
| Reasonable cause | $1,379 – $68,928 | ~$2.07M |
| Willful neglect — corrected within 30 days | $13,785 – $68,928 | ~$2.07M |
| Willful neglect — not corrected | $68,928 – $2.07M | ~$2.07M |

The hospital's penalty exposure depends on:
- Whether the hospital had adequate access controls (if not — willful neglect possible)
- Whether the hospital properly investigated and remediated
- Whether proper breach notification was provided
- Whether this is a pattern of inadequate safeguards

### State Licensing Board Referral
Most state nursing boards treat unauthorized access to patient records as professional misconduct warranting disciplinary action, including potential license suspension or revocation.

---

## Immediate Action Checklist

- [ ] Pull audit logs to determine scope and duration of unauthorized access (45 CFR §164.312(b))
- [ ] Revoke the nurse's access to the affected patient's records
- [ ] Begin documented breach risk assessment (four-factor analysis per 45 CFR §164.402)
- [ ] Interview the nurse (with HR/legal counsel present)
- [ ] Determine if any information was disclosed to third parties
- [ ] Initiate workforce sanctions process (45 CFR §164.530(e))
- [ ] Notify legal counsel
- [ ] If breach confirmed: prepare individual notification letter (deadline: 60 days from discovery)
- [ ] Log breach for annual HHS report
- [ ] Document all steps taken
- [ ] Review and remediate access controls to prevent recurrence

---

> **Disclaimer:** This guidance is for informational purposes only and does not constitute legal advice. For formal compliance determinations — especially regarding breach notification decisions and workforce discipline — consult a qualified HIPAA attorney or compliance officer.

# HIPAA Workforce Violation: Unauthorized Access to Celebrity Patient Records

## What HIPAA Violation Occurred?

The nurse committed an **unauthorized use/access of Protected Health Information (PHI)** — a violation of HIPAA's Privacy Rule.

HIPAA only permits healthcare workforce members to access patient records for legitimate purposes related to:
- **Treatment** — providing care to the patient
- **Payment** — billing and insurance activities
- **Healthcare Operations** — administrative functions of the healthcare organization

A nurse accessing records of a patient they have no treatment relationship with, out of curiosity or personal interest, does not fall under any of these permitted purposes. This is commonly called **"snooping"** and is one of the most frequent types of internal HIPAA violations in hospitals.

**Additionally violated:** HIPAA's Minimum Necessary Standard — workforce members should only access the PHI they need to do their job. A nurse with no care relationship to a patient has zero legitimate need for their records.

---

## Is This a Reportable Breach?

**Likely yes, unless you can demonstrate a low probability that the PHI was compromised.**

Under HIPAA's Breach Notification Rule, an unauthorized access to PHI is presumed to be a reportable breach. However, you can rebut this presumption by conducting a documented risk assessment considering four factors:

1. **What type of PHI was involved?** — Medical records are among the most sensitive PHI categories
2. **Who accessed the PHI?** — An internal employee, not an external attacker
3. **Was the PHI actually viewed or acquired?** — If the nurse viewed the records, this is likely an actual access
4. **Has the risk been mitigated?** — Has access been revoked? Have you determined if information was shared?

For celebrity patients specifically, the risk of the information being shared (with media, friends, etc.) is elevated, making it harder to demonstrate low probability of compromise. This type of breach is also highly visible and embarrassing for hospitals, drawing additional scrutiny.

**Recommendation:** Assume this is a reportable breach and prepare accordingly, unless your risk assessment can clearly document a low probability of compromise.

---

## Your Obligations

### 1. Investigate Immediately
- Pull audit logs to determine exactly what records were accessed, when, and for how long
- Interview the nurse to understand the reason for access and whether any information was shared
- Determine if other patient records were similarly accessed (is this a pattern?)

### 2. Conduct a Documented Breach Risk Assessment
Assess the four factors above in writing. This documentation is essential — it shows OCR you took the matter seriously and followed the proper process.

### 3. Notify the Affected Patient
If you determine a breach occurred, you must notify the celebrity patient in writing within **60 days** of discovering the breach. The notification must include:
- What happened and when
- What types of information were involved
- What steps the individual can take to protect themselves
- What your hospital is doing to address the situation
- Contact information for questions

### 4. Report to HHS
- Since this affects only one patient (fewer than 500), you add it to your breach log and submit it to the Department of Health and Human Services in your annual report (due by the end of February for breaches in the prior calendar year)
- If you ever have a breach affecting 500+ individuals in a state, notification is required within 60 days

### 5. Apply Workforce Sanctions
HIPAA requires that you apply appropriate sanctions against the nurse. The appropriate level depends on:
- Was the access deliberate (yes, clearly)
- Was it a first offense or part of a pattern
- Was any information actually disclosed to others

Sanctions can range from written warning, to suspension, to termination. Given the deliberate nature of this access, many hospitals would terminate employment for this type of violation. You must also document the sanction.

### 6. Remediate and Prevent Recurrence
- Review whether your access control systems should be tightened so nurses can only access records of their patients
- Retrain the entire workforce on appropriate PHI access
- Consider implementing automated monitoring for anomalous access patterns (e.g., accessing many records of patients outside your care assignment)

---

## Potential Penalties

### For the Hospital (Civil Penalties)
HHS's Office for Civil Rights (OCR) can investigate and impose civil monetary penalties. Penalties are tiered based on culpability:

- **Least culpable (didn't know):** Lower penalty range
- **Reasonable cause:** Mid-range penalties
- **Willful neglect, corrected:** Higher penalties
- **Willful neglect, not corrected:** Highest penalties — up to $1.9M per violation category per year

If OCR finds that the hospital lacked adequate access controls or didn't properly investigate and remediate, the hospital itself faces significant penalties — not just the individual nurse.

### For the Nurse (Criminal Penalties)
HIPAA includes criminal penalties for individuals who knowingly access or disclose PHI improperly:
- Up to $50,000 and 1 year in prison for knowing violations
- Up to $250,000 and 10 years in prison if done for commercial advantage or personal gain (e.g., selling information to a tabloid)

### Professional Licensing
The state nursing board may also investigate and take action against the nurse's license. This is separate from and in addition to HIPAA penalties.

---

## Summary

| Issue | Status |
|---|---|
| Violation type | Unauthorized access of PHI (Privacy Rule) |
| Breach reportable? | Presumed yes; requires four-factor risk assessment |
| Individual notification deadline | 60 days from discovery |
| HHS reporting | Annual log (< 500 individuals affected) |
| Workforce action required | Yes — investigate and apply sanctions |
| Hospital penalty exposure | Civil penalties; higher if inadequate controls |
| Individual (nurse) exposure | Criminal penalties possible; licensing risk |

---

> **Note:** This response provides general information and does not constitute legal advice. Given the sensitivity of this situation, consult a HIPAA attorney before making breach notification decisions.

# NIST Cybersecurity Framework 2.0 — Overview

## What Is CSF 2.0?

NIST Cybersecurity Framework 2.0 (CSF 2.0) was released in **February 2024**, replacing CSF 1.1 (April 2018). It is a voluntary framework designed to help organizations of all sizes, sectors, and maturity levels manage and reduce cybersecurity risk. A significant expansion from its predecessor, CSF 2.0 explicitly broadens its intended audience from critical infrastructure organizations to **all organizations**, including small businesses, enterprises, government agencies, and non-profits.

---

## What Changed from CSF 1.1 to CSF 2.0?

| Topic | CSF 1.1 | CSF 2.0 |
|-------|---------|---------|
| **Number of Functions** | 5 (Identify, Protect, Detect, Respond, Recover) | **6** — adds **Govern (GV)** as a new top-level function |
| **Govern Function** | Governance concepts embedded loosely within Identify | Standalone **GV** function with 6 categories and dedicated subcategories |
| **Supply Chain Risk** | Limited — addressed only in ID.SC (4 subcategories) | Expanded significantly: **GV.SC** in Govern function with 6 dedicated subcategories |
| **Total Subcategories** | 108 | **106** (restructured, not just incremental) |
| **Profiles** | Basic concept introduced | Strengthened — Organizational Profile templates provided; Community Profiles concept formalized |
| **Audience** | Explicitly scoped to critical infrastructure | Explicitly designed for **all organizations**, all sizes, all sectors |
| **Implementation Tiers** | 4 tiers (same structure) | 4 tiers — same structure with refined descriptions |
| **Informative References** | Embedded directly in the framework document | Moved to a separate, continuously-updated online **NIST CSF Reference Tool** |
| **Quick Start Guides** | Not provided | Added for SMBs, enterprises, risk managers, and government agencies |

### Key Conceptual Shifts

1. **Governance Elevated**: In CSF 1.1, governance concepts were scattered. CSF 2.0 places governance at the *center* of the framework — the Govern function establishes the strategic context that all other functions operate within.

2. **Supply Chain Risk Maturity**: GV.SC addresses third-party and supply chain risk management with dedicated subcategories covering supplier selection, contractual requirements, monitoring, and incident response for supply chain events.

3. **Profile Formalization**: CSF 2.0 formalizes the concept of Current Profiles and Target Profiles, providing templates to help organizations document their current cybersecurity posture and their desired future state.

4. **All-Sector Applicability**: The explicit broadening of audience means CSF 2.0 is the appropriate baseline for any organization, not just those in critical infrastructure sectors.

---

## The Six Core Functions of CSF 2.0

### 1. Govern (GV) — NEW in CSF 2.0
**Purpose**: Establish and monitor the organization's cybersecurity risk management strategy, expectations, and policy.

The Govern function provides the strategic foundation for all other functions. It addresses organizational context, risk management strategy, roles and responsibilities, policy, oversight, and supply chain risk management.

**Key Categories:**
- **GV.OC** — Organizational Context: Understanding the organization's mission, stakeholders, dependencies, and legal/regulatory obligations
- **GV.RM** — Risk Management Strategy: Establishing risk tolerance, appetite, and priorities
- **GV.RR** — Roles, Responsibilities, and Authorities: Defining who is accountable for cybersecurity
- **GV.PO** — Policy: Cybersecurity policy established, communicated, and enforced
- **GV.OV** — Oversight: Management oversight of cybersecurity risk management results
- **GV.SC** — Cybersecurity Supply Chain Risk Management: Managing risks from suppliers, vendors, and third parties

**Key Outputs**: Cybersecurity policy, documented risk tolerance, defined roles and responsibilities, supply chain risk strategy

---

### 2. Identify (ID)
**Purpose**: Understand cybersecurity risks to systems, assets, data, people, and capabilities.

**Key Categories:**
- **ID.AM** — Asset Management: Inventory of hardware, software, data, and systems
- **ID.RA** — Risk Assessment: Identifying, analyzing, and prioritizing cybersecurity risks
- **ID.IM** — Improvement: Plans to improve cybersecurity based on assessments and lessons learned

**Key Outputs**: Asset inventory, risk register, improvement roadmap

---

### 3. Protect (PR)
**Purpose**: Implement safeguards to manage cybersecurity risk and ensure delivery of services.

**Key Categories:**
- **PR.AA** — Identity Management, Authentication, and Access Control
- **PR.AT** — Awareness and Training
- **PR.DS** — Data Security
- **PR.PS** — Platform Security (patching, configuration management)
- **PR.IR** — Technology Infrastructure Resilience (redundancy, backup, recovery architecture)

**Key Outputs**: Access controls, trained workforce, hardened systems, protected data

---

### 4. Detect (DE)
**Purpose**: Find and analyze cybersecurity events and anomalies.

**Key Categories:**
- **DE.CM** — Continuous Monitoring: Monitoring networks, systems, and users for adverse events
- **DE.AE** — Adverse Event Analysis: Analyzing detected events to determine impact and root cause

**Key Outputs**: Alerts, event logs, threat detection capabilities, security monitoring program

---

### 5. Respond (RS)
**Purpose**: Take action on detected cybersecurity incidents.

**Key Categories:**
- **RS.MA** — Incident Management: Managing and tracking incidents through lifecycle
- **RS.AN** — Incident Analysis: Investigating and understanding incidents
- **RS.CO** — Incident Response Reporting and Communication
- **RS.MI** — Incident Mitigation: Containing and eradicating incidents

**Key Outputs**: Incident response plan, containment actions, stakeholder communications, post-incident analysis

---

### 6. Recover (RC)
**Purpose**: Restore assets and operations affected by a cybersecurity incident.

**Key Categories:**
- **RC.RP** — Incident Recovery Plan Execution: Restoring systems and operations
- **RC.CO** — Incident Recovery Communication: Communicating recovery status to stakeholders

**Key Outputs**: Restored operations, recovery documentation, lessons-learned integration

---

## How the Functions Relate

```
          ┌─────────────────────────────┐
          │         GOVERN (GV)         │  ← Strategic Foundation
          │  Strategy · Policy · Roles  │
          └─────────────┬───────────────┘
                        │
    ┌───────────┬────────┴──────────┬───────────┐
    ▼           ▼                   ▼           ▼
[IDENTIFY]  [PROTECT]          [DETECT]    [RESPOND]
[RECOVER] ←───────────────────────────────────────
```

The Govern function sits above and informs all other functions. Identify feeds into Protect (you protect what you know about). Detect feeds into Respond. Recover feeds back into Govern and Identify via lessons learned.

---

## Which Version Should You Use?

Use **CSF 2.0** for all new implementations. It is the current version as of February 2024. If your organization is operating under CSF 1.1, NIST provides migration guidance and subcategory-level mapping between versions.

> **Note**: This guidance is based on NIST CSF 2.0 (February 2024), a publicly available voluntary framework. Organizations in regulated industries should validate CSF alignment with their sector-specific regulatory requirements.

# NIST Cybersecurity Framework 2.0 — Overview

## What Is NIST CSF 2.0?

The NIST Cybersecurity Framework (CSF) 2.0 is an updated version of NIST's widely-adopted voluntary cybersecurity framework, released in early 2024. It provides guidance to industry, government, and other organizations to manage cybersecurity risks. The framework is designed to be flexible, adaptable, and applicable across different sectors, sizes, and types of organizations.

---

## Key Changes from CSF 1.1 to CSF 2.0

### 1. Addition of the "Govern" Function
The most significant change in CSF 2.0 is the addition of a sixth core function: **Govern**. In CSF 1.1, there were only five functions. The Govern function elevates cybersecurity governance to the top level, recognizing that effective cybersecurity requires strong organizational leadership, policy, and accountability structures.

### 2. Broader Audience
CSF 1.1 was originally designed with a focus on critical infrastructure sectors. CSF 2.0 explicitly acknowledges that it is applicable to **all organizations** regardless of size, sector, or cybersecurity maturity level, including small businesses and non-profits.

### 3. Enhanced Supply Chain Risk Management
CSF 2.0 gives greater emphasis to cybersecurity supply chain risk management (C-SCRM), recognizing the increasing risks from third-party vendors and suppliers.

### 4. Improved Profile Guidance
The concept of organizational profiles (Current Profile and Target Profile) has been strengthened with more practical templates and guidance to help organizations assess gaps and plan improvements.

### 5. New Quick Start Guides
NIST introduced Quick Start Guides for different audiences (small businesses, enterprises, government) to make the framework more accessible.

### 6. Online Reference Tool
Informative references (mappings to other standards like NIST SP 800-53, ISO 27001, CIS Controls) have been moved to an online reference tool that can be updated more frequently than the core document.

---

## The 6 Core Functions of CSF 2.0

### 1. Govern (GV) — New in CSF 2.0
**Purpose**: Establish and monitor the organization's cybersecurity risk management strategy, expectations, and policy.

This function addresses the organizational context, risk management strategy, roles and responsibilities, cybersecurity policy, and oversight. It provides the foundation from which all other functions operate.

**Examples**: Documenting risk tolerance, defining who owns cybersecurity decisions, establishing cybersecurity policies, managing supply chain cyber risks.

---

### 2. Identify (ID)
**Purpose**: Understand cybersecurity risks to systems, assets, data, and capabilities.

Organizations need to know what they have (assets), who and what poses risk to those assets, and how to prioritize their security investments.

**Examples**: Asset inventory, risk assessments, vulnerability identification, business environment analysis.

---

### 3. Protect (PR)
**Purpose**: Implement safeguards to limit the impact of potential cybersecurity incidents.

This function covers access controls, data protection, security training, and the technical measures used to prevent attacks or limit their damage.

**Examples**: Multi-factor authentication, encryption, security awareness training, patch management, data backup.

---

### 4. Detect (DE)
**Purpose**: Identify the occurrence of cybersecurity events.

Organizations must have the capability to detect when something goes wrong through monitoring, logging, and anomaly detection.

**Examples**: Security information and event management (SIEM) systems, intrusion detection systems, log monitoring, user behavior analytics.

---

### 5. Respond (RS)
**Purpose**: Take action regarding a detected cybersecurity incident.

When an incident occurs, organizations need defined processes to contain, analyze, and mitigate the event, as well as communicate with stakeholders.

**Examples**: Incident response plans, communication procedures, forensic investigation, containment and eradication activities.

---

### 6. Recover (RC)
**Purpose**: Maintain plans for resilience and restore capabilities after a cybersecurity incident.

Recovery focuses on getting back to normal operations as quickly as possible while incorporating lessons learned into future improvements.

**Examples**: Disaster recovery plans, business continuity procedures, system restoration, post-incident reviews.

---

## How the Functions Work Together

The six functions are not sequential steps — they represent ongoing, parallel activities. Govern provides the strategic direction for all functions. Identify feeds into Protect. Detect feeds into Respond, which feeds into Recover. Lessons learned from incidents feed back into Govern and Identify to improve the overall program.

---

## Summary of Changes at a Glance

| Aspect | CSF 1.1 | CSF 2.0 |
|--------|---------|---------|
| Number of Functions | 5 | 6 (adds Govern) |
| Primary Audience | Critical Infrastructure | All organizations |
| Supply Chain Emphasis | Limited | Expanded |
| Profile Guidance | Basic | Enhanced with templates |
| Quick Start Guides | None | Available for multiple audiences |

---

## Why CSF 2.0 Matters

CSF 2.0 reflects the evolution of the threat landscape and organizational cybersecurity practices over the past decade. By elevating governance, expanding supply chain risk management, and broadening the intended audience, it provides a more complete and practical framework for organizations at any stage of their cybersecurity journey.

# 90-Day Ransomware Recovery and Improvement Plan
## NIST CSF 2.0 — Respond & Recover Functions
### Context: Mid-Size Manufacturing Company

---

## Executive Summary

This 90-day plan applies the NIST CSF 2.0 **Respond (RS)** and **Recover (RC)** functions to guide your organization from active incident response through operational restoration and into a sustained improvement posture. Given your manufacturing context, this plan also accounts for OT/IT convergence risks and supply chain exposure per **GV.SC**.

The plan is structured in three 30-day phases:
- **Days 1–30**: Crisis response, containment, and stabilization
- **Days 31–60**: Operational restoration and gap closure
- **Days 61–90**: Resilience hardening and process improvement

---

## Phase 1: Days 1–30 — Respond: Contain, Analyze, Communicate

### Respond Function (RS) Actions

#### RS.MA — Incident Management
| # | Action | CSF Subcategory | Owner | Priority |
|---|--------|-----------------|-------|----------|
| 1 | Activate the Incident Response Plan (IRP); if none exists, stand up an emergency IR working group | RS.MA-01 | CISO / IT Director | Critical |
| 2 | Establish incident tracking in a ticketing system or IR platform; assign Incident Commander | RS.MA-02 | CISO | Critical |
| 3 | Isolate infected systems from production network — segment OT/SCADA from IT immediately | RS.MA-03 | IT Ops / OT Team | Critical |
| 4 | Engage external IR retainer / forensics firm if not done already | RS.MA-04 | CISO | Critical |
| 5 | Preserve all forensic evidence: memory dumps, log files, disk images before any remediation | RS.MA-05 | IR Team / Forensics | High |

#### RS.AN — Incident Analysis
| # | Action | CSF Subcategory | Owner | Priority |
|---|--------|-----------------|-------|----------|
| 6 | Determine ransomware variant, initial access vector (phishing, RDP, VPN vulnerability, supply chain) | RS.AN-03 | Forensics / IR Team | Critical |
| 7 | Map scope of compromise: which systems, data types, OT assets affected | RS.AN-06 | IR Team | Critical |
| 8 | Assess whether data was exfiltrated (double-extortion ransomware) | RS.AN-07 | IR Team / Legal | High |
| 9 | Identify all affected backup systems and determine backup integrity | RS.AN-08 | IT Ops | Critical |
| 10 | Review logs from perimeter, endpoint (EDR), and identity systems to establish timeline | RS.AN-02 | SOC / Forensics | High |

#### RS.CO — Incident Response Reporting and Communication
| # | Action | CSF Subcategory | Owner | Priority |
|---|--------|-----------------|-------|----------|
| 11 | Notify executive leadership and board within 24 hours | RS.CO-01 | CISO / CEO | Critical |
| 12 | Engage legal counsel and cyber insurance carrier immediately | RS.CO-02 | Legal / CFO | Critical |
| 13 | Assess regulatory notification obligations (state breach notification, CISA reporting, sector requirements) | RS.CO-03 | Legal / Compliance | Critical |
| 14 | Prepare customer/partner communications if production impact affects supply chain | RS.CO-04 | Communications / CEO | High |
| 15 | Report to CISA (if applicable) and FBI — coordinate with law enforcement on ransom payment decisions | RS.CO-05 | CISO / Legal | High |

#### RS.MI — Incident Mitigation
| # | Action | CSF Subcategory | Owner | Priority |
|---|--------|-----------------|-------|----------|
| 16 | Reset all privileged account credentials across IT and OT domains | RS.MI-01 | IT Ops | Critical |
| 17 | Force MFA enrollment on all remote access (VPN, RDP, cloud services) | RS.MI-02 | IT Ops | Critical |
| 18 | Disable or block identified malicious IOCs at perimeter and endpoint | RS.MI-03 | SOC / IT Ops | Critical |
| 19 | Determine ransom payment decision — engage FBI, insurance, legal before any payment | RS.MI-04 | Executive / Legal | Critical |

---

## Phase 2: Days 31–60 — Recover: Restore Operations and Address Root Causes

### Recover Function (RC) Actions

#### RC.RP — Incident Recovery Plan Execution
| # | Action | CSF Subcategory | Owner | Priority |
|---|--------|-----------------|-------|----------|
| 20 | Establish recovery prioritization: OT/manufacturing systems first, then ERP, then corporate IT | RC.RP-01 | CISO / OT Manager | Critical |
| 21 | Validate backup integrity before restoration; restore from known-good pre-infection backups | RC.RP-03 | IT Ops | Critical |
| 22 | Rebuild compromised systems from golden images rather than attempting in-place recovery | RC.RP-04 | IT Ops | High |
| 23 | Test restored systems in isolated environment before reconnecting to production | RC.RP-05 | IT Ops / OT Team | High |
| 24 | Document all recovery actions and validate against Business Continuity Plan (BCP) | RC.RP-06 | CISO / IT Director | Medium |

#### RC.CO — Incident Recovery Communication
| # | Action | CSF Subcategory | Owner | Priority |
|---|--------|-----------------|-------|----------|
| 25 | Provide regular recovery status updates to leadership (daily briefings) | RC.CO-03 | CISO | High |
| 26 | Notify customers, partners, and regulators of recovery timeline and expected service restoration | RC.CO-04 | Communications / Legal | High |
| 27 | Update cyber insurance carrier with recovery cost tracking | RC.CO-05 | CFO / Legal | Medium |

### Concurrent Protect Function Hardening (Phase 2)

While restoring operations, close identified attack vectors:

| # | Action | CSF Subcategory | Owner | Timeline |
|---|--------|-----------------|-------|----------|
| 28 | Implement privileged access workstations (PAWs) and tiered admin model | PR.AA-05 | IT Ops | Day 31–45 |
| 29 | Enforce network segmentation between OT and IT environments | PR.IR-01 | OT/IT Teams | Day 31–60 |
| 30 | Validate and test backup strategy — implement 3-2-1-1 backup rule | PR.IR-04 | IT Ops | Day 31–45 |
| 31 | Deploy or tune EDR across all endpoints including OT where applicable | DE.CM-01 | SecOps | Day 31–60 |
| 32 | Patch all critical and high vulnerabilities identified during forensics | PR.PS-02 | IT Ops | Day 31–60 |

---

## Phase 3: Days 61–90 — Improve: Build Resilience and Prevent Recurrence

### Govern Function — Post-Incident Governance Actions

| # | Action | CSF Subcategory | Owner | Priority |
|---|--------|-----------------|-------|----------|
| 33 | Conduct formal post-incident review (lessons learned); update IRP with findings | GV.OV-03 | CISO / Executive | High |
| 34 | Update organizational risk tolerance statement based on incident outcomes | GV.RM-04 | CISO / Board | High |
| 35 | Review and update cybersecurity policy to reflect new controls and procedures | GV.PO-02 | CISO / Legal | Medium |
| 36 | Assess supply chain / vendor exposure — did a supplier contribute to the compromise? | GV.SC-04 | Procurement / CISO | High |
| 37 | Conduct vendor security reviews for critical suppliers | GV.SC-06 | Procurement / CISO | Medium |

### Identify Function — Risk Assessment Update

| # | Action | CSF Subcategory | Owner | Priority |
|---|--------|-----------------|-------|----------|
| 38 | Update asset inventory with any newly discovered systems or shadow IT | ID.AM-01 | IT Ops | High |
| 39 | Conduct updated risk assessment incorporating ransomware attack vectors | ID.RA-01 | CISO / Risk Team | High |
| 40 | Build or update improvement plan with prioritized controls from gap analysis | ID.IM-01 | CISO | High |

### Detect & Respond Improvements

| # | Action | CSF Subcategory | Owner | Priority |
|---|--------|-----------------|-------|----------|
| 41 | Deploy or tune SIEM with ransomware detection use cases | DE.CM-09 | SOC | High |
| 42 | Implement behavioral analytics / UEBA to detect lateral movement | DE.AE-02 | SOC | Medium |
| 43 | Conduct tabletop ransomware exercise against updated IRP | RS.MA-05 | CISO / IR Team | High |
| 44 | Test backup recovery procedure under simulated ransomware scenario | RC.RP-05 | IT Ops / CISO | High |

### Awareness and Training

| # | Action | CSF Subcategory | Owner | Priority |
|---|--------|-----------------|-------|----------|
| 45 | Conduct mandatory phishing awareness training for all staff | PR.AT-01 | HR / Security | High |
| 46 | Deliver targeted OT security training for plant operators | PR.AT-02 | OT Manager / Security | Medium |

---

## Manufacturing-Specific Considerations

Given your manufacturing context, apply these sector-specific priorities:

1. **OT/IT Convergence (PR.IR, DE.CM)**: Ransomware in manufacturing often spreads to OT networks, disrupting production lines. Ensure physical process isolation controls exist independent of IT systems.

2. **Supply Chain Risk (GV.SC)**: Manufacturing relies heavily on suppliers — assess whether the ransomware entry point was via a vendor connection, EDI system, or third-party remote access.

3. **Production Continuity (RC.RP)**: Recovery prioritization should align with production schedules and customer delivery commitments. Coordinate with operations leadership on acceptable downtime windows.

4. **ICS/SCADA Recovery**: OT system recovery requires specialized expertise — engage vendors for proprietary systems and reference ICS-CERT guidance for industrial control system restoration.

---

## 90-Day Summary Timeline

| Week | Phase | Focus |
|------|-------|-------|
| 1 | Respond | Containment, forensics, executive notification |
| 2 | Respond | Scope determination, legal/regulatory notifications |
| 3 | Respond + Recover | Mitigation, begin recovery prioritization |
| 4 | Recover | Begin phased system restoration |
| 5–6 | Recover | OT restoration, ERP recovery |
| 7–8 | Recover + Improve | Full production restoration, vulnerability patching |
| 9–10 | Improve | Governance updates, risk reassessment |
| 11–12 | Improve | Tabletop exercise, training, updated IRP |

---

> **Note**: This plan applies NIST CSF 2.0 (February 2024). Manufacturing organizations should additionally consult ICS-CERT guidance and NIST SP 800-82 for OT-specific recovery considerations. This does not constitute legal or professional compliance advice.

# 90-Day Ransomware Recovery and Improvement Plan
## NIST CSF Framework — Respond & Recover Functions
### Mid-Size Manufacturing Company

---

## Overview

This 90-day plan uses the NIST Cybersecurity Framework (CSF) Respond and Recover functions as its backbone to guide your manufacturing organization from active incident response through operational restoration and toward improved cybersecurity resilience.

---

## Understanding the Two Key Functions

**Respond (RS)**: Activities to take action when a cybersecurity incident is detected. This includes incident management, analysis, mitigation, and communication.

**Recover (RC)**: Activities to restore operations and systems affected by the incident, and to improve resilience to prevent or minimize future incidents.

---

## Phase 1: Days 1–30 — Immediate Response

### Respond Function Activities

**Incident Management**
- Activate your Incident Response Plan (IRP) immediately. If you don't have one, establish an emergency response team with defined roles: Incident Commander, IT Lead, Legal/Compliance, Communications.
- Engage your cyber insurance carrier — they may provide IR retainer services.
- Retain an external incident response firm for forensic investigation if internal capabilities are limited.
- Isolate affected systems immediately to prevent ransomware from spreading further across your manufacturing network and OT (operational technology) systems.

**Incident Analysis**
- Identify the ransomware variant to understand capabilities (data encryption only vs. data exfiltration/double extortion).
- Determine the initial attack vector: phishing email, exposed RDP, unpatched VPN, or compromised vendor access.
- Map the full scope of compromise: which systems are affected, which data was encrypted or potentially stolen.
- Assess the status of all backups — determine if backups were also encrypted or corrupted.
- Preserve forensic evidence before any remediation activities begin.

**Communication**
- Notify executive leadership and the board within 24 hours.
- Engage legal counsel to assess notification obligations under state breach notification laws and sector-specific regulations.
- Determine whether ransom payment should be considered — consult with the FBI and your legal team before making any payment decision.
- Prepare internal communications for employees and external communications for customers if production is disrupted.
- Report to CISA and FBI as appropriate.

**Mitigation**
- Reset all credentials across the organization, starting with privileged accounts.
- Disable or block malicious indicators of compromise identified during forensics.
- Enforce multi-factor authentication on all remote access connections.

---

## Phase 2: Days 31–60 — Recovery and Restoration

### Recover Function Activities

**Recovery Planning and Execution**
- Prioritize systems for recovery based on operational criticality: manufacturing/OT systems first, then ERP and business systems, then general IT.
- Validate backup integrity before restoring — ensure backups pre-date the infection and are clean.
- Rebuild compromised systems from known-good images rather than attempting to clean infected systems.
- Test restored systems in an isolated environment before reintroducing them to production.
- Document all recovery steps for insurance claims and post-incident review.

**Protecting Manufacturing Operations**
- If production lines were disrupted, engage OT vendors for specialized recovery of industrial control systems.
- Implement emergency network segmentation between IT and OT environments to prevent cross-contamination during recovery.
- Validate that manufacturing equipment and SCADA/PLC systems are not compromised before resuming automated operations.

**Communication During Recovery**
- Provide daily recovery status briefings to leadership.
- Update customers and partners on expected production restoration timelines.
- Coordinate with your cyber insurance carrier on claim documentation.

### Root Cause Remediation
While restoring operations, begin addressing the root cause:
- Patch the vulnerability that allowed initial access.
- Implement stronger email filtering if phishing was the vector.
- Disable unnecessary remote access protocols (particularly open RDP).
- Implement network segmentation to limit lateral movement.
- Review and harden backup systems: implement air-gapped or immutable backups.

---

## Phase 3: Days 61–90 — Improvement and Resilience

### Strengthening Both Functions Long-Term

**Improve Your Respond Capability**
- Update and formalize your Incident Response Plan based on lessons learned from this incident.
- Conduct a tabletop exercise against the updated IRP with leadership and key IT staff.
- Establish relationships with external IR firms, legal counsel, and law enforcement contacts before the next incident.
- Define communication templates and escalation procedures in advance.

**Improve Your Recover Capability**
- Implement a robust backup strategy following the 3-2-1 rule: 3 copies, 2 different media types, 1 offsite.
- Consider immutable cloud backups that cannot be encrypted by ransomware.
- Define and document Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for all critical systems.
- Conduct a full disaster recovery test to validate you can recover critical systems within your RTO.

**Build Detection Capabilities**
- Deploy or improve endpoint detection and response (EDR) tools across all endpoints.
- Implement centralized logging and monitoring to detect ransomware behaviors (mass file encryption, unusual network traffic) earlier.
- Consider a Security Operations Center (SOC) capability, either in-house or outsourced.

**Governance and Policy**
- Conduct a formal post-incident review (lessons learned session) with all involved parties.
- Update your cybersecurity risk register with ransomware as a key risk.
- Review cyber insurance coverage — assess whether your current policy is adequate.
- Establish regular security awareness training with emphasis on phishing recognition.

---

## Manufacturing-Specific Priorities

**OT/IT Separation**: Manufacturing environments often have IT and OT networks that should be separated. Ensure ransomware cannot pivot from corporate IT to production control systems.

**Vendor Access**: Third-party vendors with remote access to your manufacturing systems are a common attack vector. Implement strict access controls and monitoring for all vendor connections.

**Production Recovery Priority**: Coordinate your IT recovery plan with operations leadership to align with production schedules and customer commitments.

---

## 90-Day Summary

| Days | Phase | Primary Focus |
|------|-------|---------------|
| 1–7 | Respond | Contain, preserve evidence, notify stakeholders |
| 8–21 | Respond | Full scope assessment, mitigation, legal/regulatory |
| 22–30 | Respond + Recover | Begin recovery planning, restore priority systems |
| 31–60 | Recover | System restoration, root cause remediation |
| 61–90 | Improve | Update plans, harden defenses, conduct exercises |

---

By following this structured approach using the NIST CSF Respond and Recover functions, your manufacturing organization will move from crisis to resilience in a disciplined, defensible manner that also satisfies the documentation needs of your insurance carrier, legal team, and any regulatory bodies involved.

# Creating NIST CSF 2.0 Organizational Profiles
## Current Profile and Target Profile — Step-by-Step Guide

---

## What Is a CSF Profile?

A **CSF Organizational Profile** describes the alignment between your organization's cybersecurity activities and outcomes, your business requirements, risk tolerance, and available resources.

CSF 2.0 defines two complementary profiles:

- **Current Profile**: The cybersecurity outcomes your organization is achieving *today* — an honest assessment of current state
- **Target Profile**: The cybersecurity outcomes your organization *wants to achieve* based on business goals, risk appetite, and regulatory requirements
- **Gap**: The delta between Current and Target — this drives your prioritized action plan and investment roadmap

> Profiles are expressed as a table of CSF subcategories rated against their current and target implementation states. The gap analysis between them becomes the basis for an Implementation Roadmap.

---

## Step-by-Step Profile Creation Process

### Step 1: Establish Business Context (GV.OC)

Before assessing any controls, you must understand the organizational context that will shape your risk tolerance and target state. This maps directly to **GV.OC** (Organizational Context) in CSF 2.0.

Gather the following inputs:

**Mission and Business Objectives**
- What does your organization do? What are your most critical business processes?
- What would it mean if those processes were disrupted for 1 hour? 1 day? 1 week?

**Legal and Regulatory Obligations**
- Which regulations apply? (e.g., HIPAA, PCI DSS, SOX, GDPR, CMMC, NERC CIP)
- What contractual security requirements do you have with customers or partners?
- These create *mandatory* target states for specific subcategories — you have no discretion on them.

**Stakeholder Requirements**
- What do your board, customers, insurers, and investors require from your cybersecurity program?
- Has your cyber insurer specified minimum controls?

**Crown Jewels / Critical Assets**
- What are your most valuable or sensitive assets? (customer data, IP, production systems, financial records)
- These inform where you must set a higher target state regardless of cost.

**Output from Step 1**: A documented Organizational Context statement covering mission, regulatory obligations, risk tolerance, and critical assets.

---

### Step 2: Define Risk Tolerance by Function (GV.RM)

Risk tolerance determines *how much gap is acceptable* in each CSF function. Risk tolerance statements per function might look like:

| Function | Risk Tolerance Statement |
|----------|--------------------------|
| Govern | Low tolerance — governance gaps create systemic vulnerability |
| Identify | Low tolerance — unknown assets and unassessed risks are unacceptable |
| Protect | Medium-to-low — critical assets require full implementation; lower criticality can be partial |
| Detect | Low tolerance — delayed detection increases incident impact |
| Respond | Low tolerance — unplanned response creates regulatory and reputational risk |
| Recover | Medium — accept some recovery time for non-critical systems; critical systems require RTO < 4 hours |

**Output from Step 2**: Risk tolerance statements per function that will anchor your target state ratings.

---

### Step 3: Map Regulatory Requirements to Subcategories

Before scoring, identify which subcategories are *mandatory* due to regulatory or contractual obligations. These subcategories must have a Target state of "Fully Implemented" regardless of your general risk tolerance.

**Example Mapping:**

| Regulation | Relevant CSF Subcategories |
|------------|---------------------------|
| HIPAA Security Rule | PR.AA (Access Control), PR.DS (Data Security), DE.CM (Monitoring), RS.MA (Incident Management) |
| PCI DSS | PR.AA, PR.DS, DE.CM, RS.MA, GV.PO |
| SOX (IT controls) | GV.OV (Oversight), ID.AM, PR.AA, DE.CM |
| CMMC Level 2 | ID.AM, PR.AA, PR.DS, PR.PS, DE.CM, RS.MA |
| Cyber Insurance | ID.AM, PR.AA (MFA requirement), PR.IR (backup), DE.CM |

**Output from Step 3**: A regulatory requirements matrix showing which subcategories have mandatory target states.

---

### Step 4: Build the Current Profile

The Current Profile is your honest, evidence-based assessment of where you are today. Use these rating definitions:

| Rating | Symbol | Definition |
|--------|--------|------------|
| Fully Implemented | FI | Control/practice is in place, documented, consistently applied, and operating effectively |
| Largely Implemented | LI | Mostly in place but with minor gaps, inconsistencies, or documentation gaps |
| Partially Implemented | PI | Some evidence exists but significant gaps remain or is inconsistently applied |
| Not Implemented | NI | No evidence of implementation |
| Not Applicable | N/A | Not applicable to this organization with documented rationale |

**How to assess current state:**
- Conduct interviews with IT, security, legal, HR, and operations staff
- Review existing policies, procedures, and technical configurations
- Review audit findings, penetration test results, and incident history
- Walk through evidence for each subcategory — do not self-certify without evidence

**Sample Current Profile (partial):**

| Function | Category | Subcategory ID | Subcategory Description | Current State | Evidence/Notes |
|----------|----------|----------------|------------------------|---------------|----------------|
| GV | Organizational Context | GV.OC-01 | Organizational mission understood and informs cybersecurity | PI | Mission documented; security alignment informal |
| GV | Risk Management Strategy | GV.RM-01 | Risk tolerance and appetite documented | NI | No formal risk tolerance statement exists |
| GV | Policy | GV.PO-01 | Cybersecurity policy established and communicated | PI | Policy exists but not reviewed in 3+ years |
| ID | Asset Management | ID.AM-01 | Hardware asset inventory maintained | PI | CMDB exists but incomplete; no OT assets |
| ID | Asset Management | ID.AM-02 | Software asset inventory maintained | NI | No formal software inventory |
| ID | Risk Assessment | ID.RA-01 | Vulnerabilities identified and documented | LI | Quarterly scanning with Qualys; some gaps |
| PR | Identity Mgmt & Access | PR.AA-01 | Identities managed for authorized users | LI | Active Directory managed; some service accounts undocumented |
| PR | Identity Mgmt & Access | PR.AA-03 | MFA implemented for user access | PI | MFA on email only; not on VPN or critical apps |
| PR | Awareness & Training | PR.AT-01 | Security awareness training provided | PI | Annual training only; no phishing simulations |
| DE | Continuous Monitoring | DE.CM-01 | Networks and assets monitored for anomalies | PI | Basic network monitoring; no behavioral analytics |
| RS | Incident Management | RS.MA-01 | Incident response plan exists | PI | IRP documented but not tested in 2 years |
| RC | Recovery | RC.RP-01 | Recovery plan exists and is executable | NI | No formal recovery plan; ad hoc only |

---

### Step 5: Build the Target Profile

The Target Profile defines where you want to be based on:
- Your risk tolerance statements (Step 2)
- Regulatory mandatory requirements (Step 3)
- Business objectives and resource constraints

**Key principles for setting target states:**
- Regulatory/contractual requirements → always set to Fully Implemented
- Crown jewel assets → set to Fully Implemented
- Supporting/lower-criticality areas → can accept Largely Implemented where risk tolerance allows
- Target Profile should be achievable within your planning horizon (typically 12–24 months)

**Sample Target Profile (continuing from above):**

| Function | Category | Subcategory ID | Current State | Target State | Regulatory Driver | Priority |
|----------|----------|----------------|---------------|--------------|-------------------|----------|
| GV | Organizational Context | GV.OC-01 | PI | FI | Board requirement | High |
| GV | Risk Management Strategy | GV.RM-01 | NI | FI | Cyber insurance | High |
| GV | Policy | GV.PO-01 | PI | FI | — | Medium |
| ID | Asset Management | ID.AM-01 | PI | FI | CMMC | High |
| ID | Asset Management | ID.AM-02 | NI | LI | CMMC | High |
| ID | Risk Assessment | ID.RA-01 | LI | FI | SOX | Medium |
| PR | Identity Mgmt & Access | PR.AA-01 | LI | FI | PCI, CMMC | High |
| PR | Identity Mgmt & Access | PR.AA-03 | PI | FI | Cyber insurance | Critical |
| PR | Awareness & Training | PR.AT-01 | PI | LI | — | Medium |
| DE | Continuous Monitoring | DE.CM-01 | PI | LI | HIPAA | High |
| RS | Incident Management | RS.MA-01 | PI | FI | HIPAA, PCI | High |
| RC | Recovery | RC.RP-01 | NI | FI | — | High |

---

### Step 6: Identify and Prioritize the Gaps

The gap is the difference between Current State and Target State. Calculate the gap size and assign priority:

| Gap Size | Definition | Typical Priority |
|----------|------------|------------------|
| Large | NI → FI or PI → FI | High or Critical |
| Medium | PI → LI or LI → FI | Medium |
| Small | LI → FI (minor documentation gap) | Low |

**Sample Gap Summary:**

| Function | # Subcategories | Critical Gaps | High Gaps | Medium Gaps | Total Gaps |
|----------|----------------|---------------|-----------|-------------|------------|
| Govern | 20 | 3 | 5 | 4 | 12 |
| Identify | 21 | 2 | 6 | 3 | 11 |
| Protect | 35 | 4 | 8 | 5 | 17 |
| Detect | 10 | 2 | 3 | 1 | 6 |
| Respond | 13 | 3 | 4 | 2 | 9 |
| Recover | 7 | 3 | 2 | 1 | 6 |

---

### Step 7: Generate the Implementation Roadmap

The gap analysis feeds directly into a prioritized roadmap. Key sequencing principles from CSF 2.0:

**Phase 1 (Prerequisites — must come first):**
- **GV.OC** — You need organizational context before anything else is meaningful
- **GV.RM** — Risk strategy must precede all risk-based decisions
- **ID.AM** — Asset inventory must precede protection decisions (you protect what you know)
- **ID.RA** — Risk assessment must precede prioritization

**Phase 2 (Protect based on Phase 1 priorities):**
- PR.AA controls (access control, MFA)
- PR.DS (data security based on asset classification from ID.AM)
- PR.PS (platform security / patching based on ID.RA findings)
- PR.IR (resilience / backup)

**Phase 3 (Detect and Respond):**
- DE.CM (monitoring — builds on protected assets)
- RS.MA (incident management — builds on monitoring)

**Phase 4 (Recover and Continuous Improvement):**
- RC.RP (recovery planning)
- Feed lessons back into GV and ID (continuous loop)

---

## Profile Document Template

Use this template to produce your formal profile document:

```
ORGANIZATION: [Name]
PROFILE DATE: [Date]
CSF VERSION: 2.0
PROFILE OWNER: [CISO / Risk Officer]
REVIEW CYCLE: Annual

ORGANIZATIONAL CONTEXT:
- Mission: [Statement]
- Critical Assets: [List]
- Regulatory Obligations: [List]
- Risk Tolerance (overall): [Low / Medium / High]

CURRENT PROFILE SUMMARY:
- Functions assessed: 6
- Total subcategories assessed: 106
- Fully Implemented: [N] ([%])
- Largely Implemented: [N] ([%])
- Partially Implemented: [N] ([%])
- Not Implemented: [N] ([%])

TARGET PROFILE SUMMARY:
- Target fully implemented: [N] ([%])
- Planning horizon: [12 / 24 months]

GAP SUMMARY:
- Critical gaps: [N]
- High gaps: [N]
- Medium gaps: [N]
- Low gaps: [N]

NEXT STEPS: [Link to Implementation Roadmap]
```

---

## Common Pitfalls to Avoid

1. **Self-assessment inflation**: Rating controls as "Fully Implemented" without evidence is the most common mistake. Require documented evidence for every rating above NI.

2. **Skipping GV.OC and GV.RM first**: Without understanding organizational context and risk tolerance, target states are arbitrary.

3. **Setting unrealistic targets**: A Target Profile that requires all 106 subcategories at Fully Implemented in 12 months is not achievable. Be realistic about resources.

4. **Treating the profile as a one-time exercise**: CSF Profiles should be reviewed at least annually and after significant incidents or organizational changes.

5. **Ignoring N/A justifications**: Every N/A designation needs documented rationale — auditors will scrutinize these.

> **Note**: This guidance is based on NIST CSF 2.0 (February 2024). Profile creation should involve qualified cybersecurity and risk management professionals for accuracy and defensibility.

# Using NIST CSF Profiles to Assess Cybersecurity Posture
## Creating Current Profile and Target Profile

---

## What Is a CSF Profile?

A NIST Cybersecurity Framework (CSF) Profile is a customized alignment of the framework's functions, categories, and subcategories to your organization's business requirements, risk tolerance, and available resources. Profiles help you:

- Understand your current cybersecurity posture (Current Profile)
- Define where you want to be (Target Profile)
- Identify and prioritize gaps between the two

Think of it as a before-and-after snapshot of your cybersecurity program, with the gap between them driving your improvement roadmap.

---

## The Two Profile Types

### Current Profile
A Current Profile is an assessment of the cybersecurity outcomes your organization is achieving today. It answers the question: "What are we actually doing right now across each area of the framework?"

### Target Profile
A Target Profile represents the cybersecurity outcomes your organization wants to achieve. It answers: "Where do we need to be, based on our business goals, risk tolerance, and regulatory requirements?"

---

## Step-by-Step Process

### Step 1: Understand Your Business Context

Before you can assess anything, you need to understand what you're protecting and why. Gather information on:

**Business Mission and Critical Processes**
- What does your organization do?
- What are the most critical processes that must keep running?
- What are the consequences of a cybersecurity incident on operations, reputation, or finances?

**Assets and Crown Jewels**
- What data, systems, and capabilities are most valuable?
- Customer data? Intellectual property? Financial systems? OT/manufacturing systems?

**Legal and Regulatory Requirements**
- Which regulations apply to your organization? (HIPAA, PCI DSS, SOX, GDPR, state breach notification laws)
- Do contracts with customers or partners impose specific security requirements?
- These obligations create mandatory minimum standards that must be reflected in your Target Profile.

**Risk Appetite**
- How much cybersecurity risk is your organization willing to accept?
- Is leadership risk-averse or willing to accept higher risk in exchange for lower cost?

---

### Step 2: Select a Rating Scale

Choose a consistent way to rate each area. A common approach:

| Rating | Meaning |
|--------|---------|
| Not Implemented | No evidence of this practice |
| Partially Implemented | Some activities exist but are incomplete or inconsistent |
| Largely Implemented | Mostly in place with minor gaps |
| Fully Implemented | Consistently in place, documented, and operating effectively |
| Not Applicable | Does not apply to this organization (document rationale) |

---

### Step 3: Assess and Build the Current Profile

Work through each of the six CSF functions and their subcategories, rating each area honestly based on available evidence.

**How to gather evidence:**
- Interview IT, security, HR, legal, and operations staff
- Review existing security policies and procedures
- Review audit findings and penetration test reports
- Check security tool configurations (firewalls, endpoint protection, SIEM, etc.)
- Review incident history

**Sample Current Profile (partial):**

| CSF Function | Category | Subcategory | Current Rating | Notes |
|-------------|----------|-------------|----------------|-------|
| Govern | Risk Management | Risk tolerance documented | Not Implemented | No formal risk appetite statement |
| Identify | Asset Management | Hardware inventory | Partially Implemented | CMDB exists but incomplete |
| Identify | Asset Management | Software inventory | Not Implemented | No formal process |
| Protect | Access Control | MFA enforced | Partially Implemented | Only on email, not VPN |
| Protect | Awareness Training | Regular training | Partially Implemented | Annual only, no phishing tests |
| Detect | Monitoring | Continuous network monitoring | Partially Implemented | Basic monitoring, no SIEM |
| Respond | Incident Response | IRP documented and tested | Partially Implemented | Plan exists, not tested in 2 years |
| Recover | Recovery Plan | Formal recovery plan | Not Implemented | Ad hoc only |

**Tips for honest assessment:**
- Require evidence for any rating above "Not Implemented" — do not self-certify
- Involve multiple stakeholders to get a complete picture
- Use external assessors if internal objectivity is a concern

---

### Step 4: Define and Build the Target Profile

The Target Profile defines where you need to be. It should be informed by:

**Business Risk Priorities**: Higher-criticality areas need higher target states.

**Regulatory Requirements**: If a regulation requires it, it must be "Fully Implemented" in your target.

**Threat Landscape**: If your industry is frequently targeted by ransomware, detection and response capabilities should have high target states.

**Resources and Feasibility**: Be realistic — a target of "Fully Implemented" across all 100+ subcategories in 12 months is not achievable for most organizations.

**Sample Target Profile (partial):**

| CSF Function | Category | Subcategory | Current | Target | Driver | Priority |
|-------------|----------|-------------|---------|--------|--------|----------|
| Govern | Risk Management | Risk tolerance documented | Not Implemented | Fully Implemented | Cyber insurance | High |
| Identify | Asset Management | Hardware inventory | Partially | Fully Implemented | Security best practice | High |
| Identify | Asset Management | Software inventory | Not Implemented | Largely Implemented | Security best practice | High |
| Protect | Access Control | MFA enforced | Partially | Fully Implemented | Cyber insurance mandate | Critical |
| Protect | Awareness Training | Regular training | Partially | Largely Implemented | — | Medium |
| Detect | Monitoring | Continuous monitoring | Partially | Largely Implemented | Regulatory | High |
| Respond | Incident Response | IRP documented and tested | Partially | Fully Implemented | Regulatory | High |
| Recover | Recovery Plan | Formal recovery plan | Not Implemented | Fully Implemented | Business continuity | High |

---

### Step 5: Conduct the Gap Analysis

Compare your Current Profile to your Target Profile to identify gaps. Calculate the gap for each subcategory:

- **Critical Gap**: Not Implemented → Fully Implemented (requires significant effort)
- **Significant Gap**: Partially Implemented → Fully Implemented
- **Moderate Gap**: Largely Implemented → Fully Implemented
- **No Gap**: Current = Target (no action needed in current cycle)

**Prioritize gaps by:**
1. Regulatory requirement (mandatory compliance)
2. Risk reduction value (which gaps leave you most exposed)
3. Ease of implementation (quick wins build momentum)
4. Cost and resource constraints

---

### Step 6: Build the Improvement Roadmap

Turn the gap analysis into an action plan organized by time horizon:

**30–60 Days (Quick Wins)**
- Low-effort, high-impact items (e.g., enabling MFA universally, updating policies)
- Regulatory mandatory items that are easy to implement

**60–180 Days (Foundation)**
- Complete asset inventory
- Deploy or improve monitoring tools
- Formalize and test incident response plan

**6–12 Months (Strategic)**
- More complex controls requiring significant investment or vendor selection
- Mature your detection and response program
- Build recovery capabilities

---

### Step 7: Document and Maintain Your Profiles

Your profiles are living documents — they should be:

- **Reviewed at least annually**
- **Updated after significant incidents** (what new gaps did the incident reveal?)
- **Refreshed when regulatory requirements change**
- **Shared with leadership** to communicate cybersecurity posture in business terms

Store your profiles alongside your risk register and use them as the basis for security budget conversations with leadership.

---

## Common Mistakes to Avoid

1. **Overstating your current state**: Rating everything as "Fully Implemented" when controls are not consistently applied undermines the value of the exercise.

2. **Setting unachievable targets**: Every gap becomes a required action — be realistic about what your team can accomplish with available resources.

3. **Treating it as a one-time exercise**: Profiles are most valuable when updated regularly as your environment changes.

4. **Not involving the business**: Security profiles that don't reflect business context and priorities will not drive the right investment decisions.

---

## Summary

| Step | Activity | Output |
|------|----------|--------|
| 1 | Understand business context | Context statement |
| 2 | Define rating scale | Scoring rubric |
| 3 | Assess current state | Current Profile |
| 4 | Define target state | Target Profile |
| 5 | Gap analysis | Prioritized gap list |
| 6 | Build roadmap | Improvement action plan |
| 7 | Document and maintain | Living profile documents |

By completing this process, you will have a clear, evidence-based picture of your cybersecurity posture, a defined destination, and a prioritized path to get there — all aligned to the NIST Cybersecurity Framework.

# NIST CSF 2.0 — Protect Function Control Mapping
## Current Controls Mapped to CSF Subcategories

### Controls Assessed:
- Okta SSO with MFA
- CrowdStrike EDR
- Qualys Vulnerability Scanning
- Druva Cloud Backup
- Written Security Awareness Training Program

---

## Overview

The **Protect (PR)** function in CSF 2.0 contains five categories:
- **PR.AA** — Identity Management, Authentication, and Access Control
- **PR.AT** — Awareness and Training
- **PR.DS** — Data Security
- **PR.PS** — Platform Security
- **PR.IR** — Technology Infrastructure Resilience

Your five controls span multiple Protect categories, with some also contributing to the **Detect (DE)** function (CrowdStrike) and **Identify (ID)** function (Qualys).

---

## Control Mapping Table

| Control | CSF Function | CSF Category | Subcategory ID | Subcategory Description | Coverage Assessment | Notes & Gaps |
|---------|-------------|--------------|----------------|------------------------|---------------------|--------------|
| **Okta SSO with MFA** | Protect | Identity Mgmt, Auth & Access Control | **PR.AA-01** | Identities and credentials for authorized users, services, and hardware are managed by the organization | Largely Implemented | Okta manages user identities; verify service accounts and non-human identities are also managed in Okta or a PAM tool |
| Okta SSO with MFA | Protect | Identity Mgmt, Auth & Access Control | **PR.AA-02** | Identities are proofed and bound to credentials based on the context of interactions | Partially Implemented | Okta handles standard identity binding; privileged accounts may need stronger proofing (e.g., PAM with session recording) |
| Okta SSO with MFA | Protect | Identity Mgmt, Auth & Access Control | **PR.AA-03** | Users, services, and hardware are authenticated using appropriate means | Fully Implemented | Okta MFA satisfies authentication requirement; confirm MFA is enforced for ALL apps (not just SSO-connected ones) |
| Okta SSO with MFA | Protect | Identity Mgmt, Auth & Access Control | **PR.AA-04** | Identity assertions are protected, conveyed, and verified | Largely Implemented | Okta handles SAML/OIDC assertions; ensure token lifetimes are appropriately short |
| Okta SSO with MFA | Protect | Identity Mgmt, Auth & Access Control | **PR.AA-05** | Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties | Partially Implemented | SSO enables centralized access, but least privilege requires additional RBAC governance; review Okta group assignments and admin roles |
| Okta SSO with MFA | Protect | Identity Mgmt, Auth & Access Control | **PR.AA-06** | Physical access to assets is managed, monitored, and enforced commensurate with risk | Not Addressed | Okta covers logical access only; physical access controls are separate |
| **CrowdStrike EDR** | Protect | Platform Security | **PR.PS-01** | Configuration management practices are established and applied | Partially Implemented | CrowdStrike can detect misconfigurations but is not a configuration management system; complement with a CSPM or CIS benchmark tooling |
| CrowdStrike EDR | Protect | Platform Security | **PR.PS-05** | Installation and execution of unauthorized software is prevented or detected | Largely Implemented | CrowdStrike Falcon Prevent (if licensed) blocks unauthorized execution; verify prevention mode is enabled vs. detect-only |
| CrowdStrike EDR | Detect | Continuous Monitoring | **DE.CM-01** | Networks and network services are monitored to find potentially adverse events | Largely Implemented | CrowdStrike provides endpoint telemetry; network-level monitoring (NDR/SIEM) may be needed to cover full DE.CM scope |
| CrowdStrike EDR | Detect | Continuous Monitoring | **DE.CM-03** | Personnel activity and technology usage are monitored to find potentially adverse events | Largely Implemented | CrowdStrike monitors endpoint activity and process execution; extend with UEBA for comprehensive user behavior analysis |
| CrowdStrike EDR | Detect | Continuous Monitoring | **DE.CM-09** | Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events | Fully Implemented | Core CrowdStrike capability — real-time endpoint monitoring, process telemetry, and threat detection |
| CrowdStrike EDR | Detect | Adverse Event Analysis | **DE.AE-02** | Potentially adverse events are analyzed to better characterize and understand the attack | Largely Implemented | CrowdStrike Falcon Insight provides investigation capabilities; ensure analysts are trained and process exists |
| CrowdStrike EDR | Detect | Adverse Event Analysis | **DE.AE-06** | Information on adverse events is provided to authorized staff and tools | Largely Implemented | CrowdStrike integrates with SIEMs and ticketing tools; confirm alerting pipelines are configured to the right teams |
| **Qualys Vulnerability Scanning** | Identify | Risk Assessment | **ID.RA-01** | Vulnerabilities in assets are identified, validated, and recorded | Largely Implemented | Qualys performs authenticated scanning; confirm scan coverage includes cloud assets, OT where applicable, and newly provisioned systems |
| Qualys Vulnerability Scanning | Protect | Platform Security | **PR.PS-02** | Software is maintained, replaced, and removed commensurate with risk | Partially Implemented | Qualys identifies the need for patches but does not apply them; a patching process/tool (e.g., WSUS, Intune, Ansible) is required to close this |
| Qualys Vulnerability Scanning | Protect | Platform Security | **PR.PS-04** | Log records are generated and made available for continuous monitoring | Not Addressed | Qualys provides vulnerability data but not log management; log aggregation is a separate requirement |
| Qualys Vulnerability Scanning | Detect | Continuous Monitoring | **DE.CM-08** | Vulnerabilities in assets are identified to understand and manage risk | Fully Implemented | Core Qualys function — continuous or scheduled vulnerability detection is directly aligned to this subcategory |
| **Druva Cloud Backup** | Protect | Technology Infrastructure Resilience | **PR.IR-01** | Networks and environments are protected from unauthorized logical access and usage | Partially Addressed | Druva protects data through backup but does not directly address network protection; Druva itself should have MFA and restricted admin access |
| Druva Cloud Backup | Protect | Technology Infrastructure Resilience | **PR.IR-03** | Mechanisms are implemented to achieve resilience requirements in normal and adverse situations | Largely Implemented | Druva provides data resilience via cloud backup; verify RPO/RTO align with business requirements |
| Druva Cloud Backup | Protect | Technology Infrastructure Resilience | **PR.IR-04** | Adequate resource capacity to ensure availability is maintained | Largely Implemented | Druva cloud-based model provides scalable backup capacity; verify retention policies and capacity limits |
| Druva Cloud Backup | Recover | Incident Recovery Plan Execution | **RC.RP-03** | The integrity of backups and other restoration assets is verified before use in recovery | Partially Implemented | Druva provides backup integrity checking; confirm that restoration testing is conducted regularly (at least annually) |
| Druva Cloud Backup | Recover | Incident Recovery Plan Execution | **RC.RP-04** | Critical assets are prioritized for recovery to support critical services or business functions | Partially Implemented | Druva enables granular restore; however, formal recovery prioritization must be documented in a Recovery Plan — verify this exists |
| **Written Security Awareness Training** | Protect | Awareness and Training | **PR.AT-01** | Personnel are provided awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind | Partially Implemented | Written program exists — assess whether it includes phishing simulations, role-based training, and frequency (annual-only is insufficient per current threat landscape) |
| Written Security Awareness Training | Protect | Awareness and Training | **PR.AT-02** | Individuals in specialized roles are provided awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind | Not Implemented | Written program addresses general staff; specialized training for IT admins, developers, executives, and OT operators likely does not exist — document separately |

---

## Cross-Reference: Coverage Summary by Subcategory Category

| CSF Category | Subcategory IDs Covered | Your Controls | Coverage Level |
|-------------|------------------------|---------------|----------------|
| **PR.AA** — Identity & Access | PR.AA-01 through PR.AA-06 | Okta SSO + MFA | PR.AA-01/03/04 largely/fully covered; PR.AA-05 partial; PR.AA-06 not addressed |
| **PR.AT** — Awareness & Training | PR.AT-01, PR.AT-02 | Written Training Program | PR.AT-01 partial; PR.AT-02 not implemented |
| **PR.DS** — Data Security | Not addressed by listed controls | None mapped | Gap — no controls mapped; consider DLP, encryption, data classification |
| **PR.PS** — Platform Security | PR.PS-01, PR.PS-02, PR.PS-04, PR.PS-05 | CrowdStrike, Qualys | PR.PS-05 largely covered; PR.PS-02 partial (patching process needed) |
| **PR.IR** — Technology Resilience | PR.IR-01, PR.IR-03, PR.IR-04 | Druva | PR.IR-03/04 largely covered; PR.IR-01 not directly addressed |

---

## Key Gaps in the Protect Function

### Critical Gaps (Not Addressed by Current Controls)

| Gap Area | Subcategory | Recommended Control/Action |
|----------|-------------|---------------------------|
| **Data Security (PR.DS)** | PR.DS-01 through PR.DS-11 | No data security controls mapped. Implement: data classification policy, DLP tool (e.g., Microsoft Purview, Forcepoint), and encryption at rest/in transit |
| **Physical Access Controls** | PR.AA-06 | Okta covers logical access only. Implement physical access control system (badge readers, visitor logs, secure areas) |
| **Specialized Role Training** | PR.AT-02 | Implement separate curricula for IT admins, developers, executives, and any OT/ICS operators |
| **Patching Process** | PR.PS-02 | Qualys identifies vulnerabilities but a patching execution process is required (patch management tool + SLAs by severity) |

### Partial Gaps (Requiring Enhancement)

| Gap Area | Subcategory | Current State | Enhancement Needed |
|----------|-------------|---------------|-------------------|
| **Least Privilege / RBAC** | PR.AA-05 | Partial | Conduct Okta access review; implement formal RBAC with quarterly recertification |
| **Training Effectiveness** | PR.AT-01 | Partial | Add phishing simulations (e.g., KnowBe4, Proofpoint), increase frequency to quarterly, add role-based modules |
| **Backup Recovery Testing** | RC.RP-03 | Partial | Implement formal quarterly backup restore tests with documented results |
| **Configuration Management** | PR.PS-01 | Partial | Add CIS benchmark scanning or CSPM (e.g., Wiz, Prisma Cloud) alongside CrowdStrike |

---

## Cross-Framework Mapping (Your Controls)

| Your Control | CSF Primary Subcategories | NIST SP 800-53 Rev 5 | ISO 27001:2022 | CIS Controls v8 |
|-------------|--------------------------|---------------------|----------------|----------------|
| Okta SSO + MFA | PR.AA-01, PR.AA-03, PR.AA-05 | AC-2, IA-2, IA-8 | A.5.15, A.5.16, A.5.17 | CIS 5, 6 |
| CrowdStrike EDR | PR.PS-05, DE.CM-09, DE.AE-02 | SI-4, SI-3, IR-4 | A.8.7, A.8.15, A.8.16 | CIS 8, 10 |
| Qualys Scanning | ID.RA-01, DE.CM-08, PR.PS-02 | RA-3, RA-5, SI-2 | A.8.8 | CIS 7 |
| Druva Cloud Backup | PR.IR-03, PR.IR-04, RC.RP-03 | CP-9, CP-10 | A.8.13, A.5.30 | CIS 11 |
| Security Awareness Training | PR.AT-01, PR.AT-02 | AT-2, AT-3 | A.6.3 | CIS 14 |

---

## Recommended Next Steps

1. **Fill the PR.DS gap**: No data security controls are currently mapped. This is a significant exposure — implement data classification and encryption as a priority.
2. **Mature PR.AT**: Upgrade the written training program to include phishing simulations and role-based modules.
3. **Close PR.PS-02**: Implement a formal patch management process with defined SLAs (Critical: 24h, High: 7 days, Medium: 30 days).
4. **Review PR.AA-05**: Conduct an Okta access review and establish quarterly recertification for privileged roles.
5. **Test Druva recovery**: Implement quarterly restoration tests and document results against your RTO/RPO.

> **Note**: This mapping is based on NIST CSF 2.0 (February 2024). Control coverage assessments should be validated with evidence reviews. This does not constitute a formal audit.

# NIST CSF Protect Function — Control Mapping
## Controls: Okta SSO + MFA, CrowdStrike EDR, Qualys, Druva, Security Awareness Training

---

## Overview

This document maps your five current security controls to the NIST Cybersecurity Framework (CSF) Protect function and related functions. The Protect function covers safeguards to manage cybersecurity risk, including access controls, awareness training, data security, maintenance, and protective technologies.

The five controls you listed span multiple areas of the framework, with strong coverage in some areas and notable gaps in others.

---

## Control-by-Control Mapping

### 1. Okta SSO with MFA

**Primary CSF Mapping: Protect → Identity Management and Access Control**

| CSF Area | Coverage | Assessment |
|----------|----------|------------|
| Identity Management | Strong | Okta provides centralized identity management, lifecycle management, and single sign-on across applications |
| Authentication | Strong | MFA enforcement through Okta directly addresses the requirement for multi-factor authentication |
| Access Control | Moderate | Okta enables centralized access control; however, least privilege and role-based access control (RBAC) governance depends on how Okta groups and permissions are configured and maintained |
| Privileged Access | Partial | Standard Okta does not typically cover privileged access management (PAM); consider whether admin accounts have additional protections |

**What Okta + MFA covers well:**
- User authentication with multiple factors
- Centralized identity lifecycle (provisioning and deprovisioning)
- Single sign-on reducing credential sprawl
- Adaptive authentication policies

**What may still be needed:**
- Privileged Access Management (PAM) for admin accounts (e.g., CyberArk, BeyondTrust)
- Access certification / recertification processes (quarterly reviews of who has access to what)
- Formal least-privilege role definitions and RBAC governance

---

### 2. CrowdStrike EDR

**Primary CSF Mapping: Protect → Protective Technology / Detect → Security Continuous Monitoring**

| CSF Area | Coverage | Assessment |
|----------|----------|------------|
| Malware/Threat Protection | Strong | CrowdStrike Falcon provides next-gen antivirus and behavioral threat detection |
| Endpoint Monitoring | Strong | Real-time endpoint telemetry and event collection |
| Anomaly Detection | Strong | AI-driven behavioral analytics detect threats that signature-based tools miss |
| Incident Investigation | Moderate | Falcon Insight provides investigation capabilities, though analyst training is required |

**What CrowdStrike covers well:**
- Endpoint protection across laptops, servers, and workstations
- Real-time threat detection and prevention
- Threat hunting and forensic investigation capabilities
- Integration with SIEM/SOAR tools

**CSF Functions Addressed:**
- **Protect**: Protective technology for endpoints (malware prevention, application control)
- **Detect**: Continuous monitoring of endpoints for security events
- **Respond**: Supports incident analysis and investigation

**What may still be needed:**
- Network-level monitoring (NDR or SIEM) — CrowdStrike alone doesn't cover network traffic analysis
- Coverage verification — ensure all endpoints are enrolled (laptops, servers, any OT/ICS endpoints)
- Prevention mode validation — confirm Falcon is in prevention mode, not detect-only

---

### 3. Qualys Vulnerability Scanning

**Primary CSF Mapping: Identify → Risk Assessment / Protect → Maintenance**

| CSF Area | Coverage | Assessment |
|----------|----------|------------|
| Vulnerability Identification | Strong | Qualys provides comprehensive vulnerability scanning across IT assets |
| Risk Assessment | Strong | Vulnerability data feeds directly into your risk assessment process |
| Patch/Remediation Tracking | Partial | Qualys identifies vulnerabilities but doesn't remediate them; a patching process is required |
| Asset Discovery | Moderate | Qualys can discover assets during scanning, supplementing asset inventory |

**What Qualys covers well:**
- Regular vulnerability discovery across servers, workstations, and network devices
- Prioritization of vulnerabilities by severity (CVSS scoring)
- Compliance scanning against benchmarks (CIS, PCI DSS, etc.)
- Trend reporting on vulnerability remediation over time

**CSF Functions Addressed:**
- **Identify**: Vulnerability identification and risk assessment inputs
- **Protect**: Maintenance — knowing what needs to be patched
- **Detect**: Identifying vulnerable systems before attackers exploit them

**What may still be needed:**
- Patch management process with defined SLAs (e.g., critical patches within 48 hours)
- Coverage of cloud assets and SaaS applications (Qualys may not scan all cloud workloads without agents)
- Web application scanning if you have customer-facing web applications

---

### 4. Druva Cloud Backup

**Primary CSF Mapping: Protect → Data Protection and Resilience**

| CSF Area | Coverage | Assessment |
|----------|----------|------------|
| Data Backup | Strong | Druva provides cloud-based backup for endpoints, servers, and cloud data |
| Data Recovery | Strong | Enables restoration of files, systems, and data after incidents |
| Ransomware Protection | Strong | Cloud backups are typically isolated from on-premises ransomware attacks |
| Data Retention | Moderate | Retention policies need to be aligned with legal and business requirements |

**What Druva covers well:**
- Automated backup for endpoint and cloud data
- Protection against data loss from ransomware, hardware failure, or accidental deletion
- Centralized management with reporting on backup coverage and compliance
- Fast restore capabilities to minimize downtime

**CSF Functions Addressed:**
- **Protect**: Data protection, resilience, and backup
- **Recover**: Enables recovery of data after a cybersecurity incident

**What may still be needed:**
- Recovery testing — are you regularly testing restores? (At minimum annually)
- Recovery Time Objectives (RTOs) — how fast can you restore critical systems?
- Coverage gaps — are all critical systems, databases, and cloud workloads backed up?
- Offsite/air-gapped copies for highly sensitive or critical systems (3-2-1 backup rule)

---

### 5. Written Security Awareness Training Program

**Primary CSF Mapping: Protect → Awareness and Training**

| CSF Area | Coverage | Assessment |
|----------|----------|------------|
| General Security Awareness | Moderate | A written program provides foundational knowledge, but effectiveness depends on delivery and frequency |
| Phishing Awareness | Unknown | Does your program include simulated phishing exercises? If not, this is a key gap |
| Role-Based Training | Unknown | Does the program include specialized content for IT admins, executives, or other high-risk roles? |
| Training Frequency | Unknown | Annual training meets a minimum bar but is generally considered insufficient for maintaining awareness |

**What a written training program covers:**
- Foundational cybersecurity knowledge for all staff
- Policy acknowledgment and compliance
- Documentation that training occurred (important for audits)

**What is typically missing from "written programs only":**
- Simulated phishing exercises to test and reinforce learning
- Role-based training for high-risk roles (IT administrators, finance, executives)
- Scenario-based training (what to do when you receive a suspicious email)
- Metrics on training completion and effectiveness

---

## Consolidated Coverage Map

| CSF Protect Area | Coverage | Your Controls | Gap Areas |
|-----------------|----------|---------------|-----------|
| Identity & Access Management | Good | Okta SSO + MFA | PAM for privileged accounts; access reviews |
| Awareness & Training | Partial | Written Training Program | Phishing sims; role-based training; frequency |
| Data Security | Limited | Druva (backup only) | No DLP, encryption policy, or data classification |
| Protective Technology | Good | CrowdStrike EDR | Network monitoring; cloud workload protection |
| Maintenance / Vulnerability Mgmt | Partial | Qualys | Patch management process; remediation tracking |

---

## Key Gaps in Your Protect Function Coverage

### 1. Data Security — Significant Gap
Your controls do not include data loss prevention (DLP), data classification, or encryption policies. This means you lack visibility into where sensitive data lives and whether it's adequately protected in transit and at rest.

**Recommended additions**: Data classification policy, DLP tooling (Microsoft Purview, Zscaler), encryption standards for data at rest and in transit.

### 2. Privileged Access Management — Moderate Gap
Okta handles standard user access, but privileged accounts (domain admins, database admins, root accounts) typically require additional controls: session recording, just-in-time access, and vault-based credential management.

**Recommended additions**: PAM solution (CyberArk, BeyondTrust, Delinea) or at minimum, Okta Privileged Access.

### 3. Network-Level Monitoring — Moderate Gap
CrowdStrike monitors endpoints but not network traffic. Lateral movement, command-and-control traffic, and network-level attacks may go undetected.

**Recommended additions**: Network detection and response (NDR) tool or SIEM with network log ingestion.

### 4. Patch Management Process — Moderate Gap
Qualys identifies vulnerabilities, but there must be a defined process and tooling to remediate them with defined SLAs.

**Recommended additions**: Formal patch management process with severity-based SLAs; patching tools (WSUS, Intune, Ansible).

### 5. Training Effectiveness — Moderate Gap
A written training program meets the minimum bar but is not sufficient on its own. Without simulated phishing and role-based content, human risk remains high.

**Recommended additions**: KnowBe4, Proofpoint Security Awareness, or similar platform; quarterly phishing simulations.

---

## Summary Assessment

Your five controls provide a reasonable foundation across Identity & Access, Endpoint Protection, Vulnerability Management, and Data Backup. However, there are meaningful gaps in data security controls, network monitoring, privileged access management, patch remediation, and training effectiveness that should be addressed to achieve a strong Protect function posture.

# Using NIST CSF for Board-Level Cybersecurity Communication
## Communicating Risk to Non-Technical Executives

---

## Why NIST CSF Works for Board Reporting

The NIST Cybersecurity Framework 2.0 is uniquely suited for executive communication because it was designed to bridge the gap between technical cybersecurity operations and organizational risk management. The CSF 2.0's **Govern (GV)** function — specifically **GV.OV** (Oversight) — explicitly addresses the role of leadership in monitoring cybersecurity risk, making executive reporting a first-class concern within the framework itself.

Boards do not manage firewalls. They manage risk, strategy, and fiduciary responsibility. CSF provides the vocabulary to translate technical security posture into the language of business risk, investment, and outcomes.

---

## The Core Communication Principle: Outcomes, Not Tools

**Wrong approach** (technical): "We deployed CrowdStrike EDR across 2,400 endpoints and have a mean detection time of 4 minutes."

**Right approach** (outcome-based): "We can detect and contain a cyberattack on our endpoints in minutes rather than days — this reduces the potential cost of a breach by an estimated $X million."

Frame everything in terms of:
- **Risk reduction** — what threats can you now withstand that you couldn't before?
- **Business impact** — what happens to operations, revenue, and reputation if this control fails?
- **Investment return** — what is the cost of the control vs. the cost of the risk it mitigates?

---

## Structuring the Board Report Using CSF 2.0 Functions

### Recommended Board Report Structure

**Section 1: Cybersecurity Posture Summary (1 slide/page)**
Present a function-level "dashboard" using simple traffic light (RAG) status:

| CSF Function | Status | Trend | Key Message |
|-------------|--------|-------|-------------|
| Govern | Yellow | Improving | Risk tolerance statement drafted; awaiting board approval |
| Identify | Green | Stable | Asset inventory complete; risk assessment updated Q4 |
| Protect | Yellow | Improving | MFA deployed; data security controls in progress |
| Detect | Yellow | Stable | Endpoint monitoring strong; network monitoring gap being addressed |
| Respond | Red | Improving | Incident response plan updated; tabletop exercise scheduled |
| Recover | Red | Improving | Recovery plan in development; backup tested successfully |

**Why this works**: Six functions map naturally to six business questions boards already ask — "Do we have the right governance? Do we know our risks? Are we protected? Will we detect attacks? Can we respond? Can we recover?"

**Section 2: Top Risks (narrative, 1-2 slides)**
Drawn from **ID.RA** (Risk Assessment) outputs — present the top 3–5 cybersecurity risks to the business in plain language:

- Risk: Ransomware disrupting manufacturing operations for 5+ days
- Likelihood: High (sector-targeted)
- Business Impact: $X revenue loss + $X recovery cost + reputational damage
- Current Mitigation: [what you have]
- Residual Risk: [what remains]
- Decision Required: [investment/acceptance/transfer]

**Section 3: Progress Against Target Profile (1 slide)**
Show movement from Current Profile toward Target Profile. This answers "Are we getting better?"

| Priority Initiative | CSF Subcategory | Start State | Current State | Target | % Complete |
|---------------------|----------------|-------------|---------------|--------|------------|
| Universal MFA | PR.AA-03 | Not Implemented | Largely Implemented | Fully Implemented | 70% |
| Incident Response Plan | RS.MA-01 | Partial | Largely Implemented | Fully Implemented | 80% |
| Recovery Plan | RC.RP-01 | Not Implemented | Partially Implemented | Fully Implemented | 40% |

**Section 4: Significant Events Since Last Board Meeting**
- Any incidents (without unnecessary technical detail)
- Threat intelligence relevant to your sector
- Regulatory changes affecting cybersecurity posture

**Section 5: Decisions Required from the Board**
Be explicit about what you need. Boards need to:
- Approve risk tolerance statements (**GV.RM** — risk appetite documentation requires board sign-off)
- Authorize significant cybersecurity investments
- Accept residual risks above established tolerance
- Fulfill oversight obligations (**GV.OV** — board oversight of cybersecurity results)

---

## Metrics That Resonate with Boards

### Outcome-Based Metrics (preferred for boards)

| Metric | CSF Alignment | Why It Matters to the Board |
|--------|--------------|----------------------------|
| **Mean Time to Detect (MTTD)** | DE.CM, DE.AE | Lower = faster threat detection = less damage potential |
| **Mean Time to Respond (MTTR)** | RS.MA | Lower = faster containment = lower breach cost |
| **Recovery Time Objective (RTO) vs. Actual** | RC.RP | Did we meet our recovery SLA? What was the business impact? |
| **% of Critical Assets with MFA** | PR.AA-03 | Business-readable: "X% of our most important systems require two-factor login" |
| **% of Vulnerabilities Remediated within SLA** | ID.RA-01, PR.PS-02 | Shows whether known weaknesses are being fixed on time |
| **Security Awareness Training Completion Rate** | PR.AT-01 | % of workforce trained — human risk reduction measure |
| **Phishing Click Rate** | PR.AT-01 | Direct measure of human susceptibility to the #1 attack vector |
| **Third-Party Risk Assessment Coverage** | GV.SC | % of critical suppliers assessed — supply chain risk measure |
| **Backup Success Rate + Last Recovery Test Date** | PR.IR-04, RC.RP-03 | Can we actually recover? When did we last prove it? |
| **Cyber Insurance Coverage vs. Risk Exposure** | GV.RM | Are we adequately insured relative to our risk profile? |

### Risk-Quantification Metrics (most impactful for board)

Where possible, express risk in financial terms:

- **Estimated cost of a ransomware incident** (based on sector benchmarks + your RTO)
- **Potential regulatory fine exposure** (per GDPR, HIPAA, etc. based on data types held)
- **Cyber insurance premium trend** (insurers are quantifying your risk — share their view)
- **Cost per incident averted** (value of controls in measurable terms)

---

## Language and Framing Guide

### Translate Technical Concepts to Business Language

| Technical Term | Board-Friendly Language |
|---------------|------------------------|
| MFA / Multi-Factor Authentication | "Two-step login — even if a password is stolen, attackers can't get in" |
| Endpoint Detection and Response (EDR) | "Software that watches for attacker behavior on every laptop and server" |
| Vulnerability scanning | "Regular health checks that find security weaknesses before attackers do" |
| Incident Response Plan | "Our emergency playbook for when a cyberattack happens" |
| Recovery Time Objective | "The maximum time we've committed to restore critical systems after an attack" |
| Ransomware | "Malware that locks all your data until you pay — manufacturing companies are primary targets" |
| Phishing | "Deceptive emails designed to trick employees into giving attackers access" |
| Zero Trust | "A 'never trust, always verify' security model — every access request is checked, even inside our network" |

### Avoid These Common Mistakes

- **Avoid jargon overload**: Do not use acronyms (SIEM, NDR, XDR, SOAR) without explanation
- **Avoid false precision**: "We are 94.3% secure" is meaningless — use ranges and comparisons
- **Avoid "all green" reports**: Boards need honest risk assessments; sugar-coating creates liability
- **Avoid tool inventories**: Boards don't need to know what tools you use — they need to know what risks those tools address
- **Avoid one-way reporting**: Ask for board input on risk tolerance and strategic priorities — this is a GV.RM dialogue, not a monologue

---

## Sample Board Risk Statement Template

Use this template for top risks presented to the board:

```
RISK: [Plain-language risk name]
EXAMPLE: "Ransomware disrupting manufacturing operations"

WHAT COULD HAPPEN: [Business impact, not technical detail]
"A ransomware attack could encrypt our production systems and halt 
manufacturing for 5–10 business days, resulting in an estimated 
$2–4M in revenue loss and $1M+ in recovery costs."

LIKELIHOOD: [High / Medium / Low with brief rationale]
"High — manufacturing companies are the #1 target sector for 
ransomware in 2024 (CISA data)."

WHAT WE'RE DOING ABOUT IT: [3 bullets max]
• We deployed immutable cloud backups (Druva) that ransomware 
  cannot encrypt
• We are implementing network segmentation to isolate OT systems
• We conducted a ransomware tabletop exercise in Q3

WHAT RISK REMAINS: [Honest residual risk statement]
"If an attack occurs, we estimate recovery in 3–5 days for critical 
systems. Our cyber insurance covers up to $5M in response costs."

BOARD DECISION NEEDED: [Yes/No — and what]
Yes — Approve $200K investment in OT network segmentation to reduce 
manufacturing exposure from High to Medium risk.
```

---

## CSF Governance Function (GV.OV) — Board Oversight Obligations

CSF 2.0's **GV.OV** subcategories formalize what boards should be doing. You can present this as a governance health check:

| Board Responsibility | CSF Subcategory | Fulfillment Evidence |
|---------------------|----------------|---------------------|
| Cybersecurity risk discussed at board level | GV.OV-01 | Regular board agenda item |
| Cybersecurity results reviewed by senior leadership | GV.OV-02 | CISO quarterly board report |
| Adjustments made based on review outcomes | GV.OV-03 | Investment decisions from board risk discussions |
| Risk tolerance approved at executive/board level | GV.RM-07 | Board resolution or risk appetite statement |

---

## Reporting Cadence Recommendation

| Report Type | Frequency | Audience | CSF Alignment |
|-------------|-----------|----------|---------------|
| Full Cybersecurity Posture Report | Quarterly | Board / Audit Committee | All functions |
| Risk Dashboard Update | Monthly | Executive Leadership | ID.RA, GV.RM |
| Incident Report | As needed (within 24-48h) | Board / CEO | RS.CO, RC.CO |
| Annual Cybersecurity Program Review | Annually | Board | All functions + Year-over-year trend |
| Post-Incident Review | Within 30 days of incident | Board / Audit Committee | RS.AN, GV.OV |

---

## Quick Reference: One-Slide Board Dashboard

```
CYBERSECURITY POSTURE — Q[X] [YEAR]

OVERALL POSTURE: YELLOW (Improving)
Implementation Tier: 2 → Target: 3 (by Q4)

FUNCTION STATUS:
  Govern  [●●●○○] Risk Management  → Tier 2
  Identify [●●●●○] Know Our Risks  → Tier 2
  Protect [●●●○○] Defense Controls → Tier 2  
  Detect  [●●○○○] Threat Detection → Tier 1-2
  Respond [●●○○○] Incident Readiness → Tier 1
  Recover [●○○○○] Recovery Ability → Tier 1

TOP RISK: Ransomware | Likelihood: HIGH | Impact: $2-4M
TOP WIN: Universal MFA deployed (reduces breach risk ~80%)
TOP GAP: Recovery plan not tested
INVESTMENT NEEDED: $200K for OT segmentation (board approval requested)
```

> **Note**: This guidance is based on NIST CSF 2.0 (February 2024). Board cybersecurity reporting requirements may vary by jurisdiction, sector, and whether SEC cybersecurity disclosure rules apply to your organization. Consult legal counsel for reporting obligations.

# Using NIST CSF to Communicate Cybersecurity Risk to the Board
## Executive Communication Guide

---

## Why NIST CSF Is Effective for Board Reporting

The NIST Cybersecurity Framework (CSF) provides a structured, outcome-oriented way to describe cybersecurity posture that translates well for non-technical audiences. Unlike technical security reports that focus on tools and vulnerabilities, the CSF's six functions — Govern, Identify, Protect, Detect, Respond, and Recover — map to business questions that boards already understand:

- **Do we have the right governance and strategy?** (Govern)
- **Do we know our risks and assets?** (Identify)
- **Are we protected?** (Protect)
- **Can we detect when something goes wrong?** (Detect)
- **Can we respond when an incident occurs?** (Respond)
- **Can we recover and get back to business?** (Recover)

This natural alignment makes CSF an excellent vehicle for board-level communication.

---

## The Golden Rule: Business Risk, Not Technical Details

Boards make decisions about risk, strategy, and investment. They do not need to know which security tools you use — they need to understand what risks the organization faces, how well-positioned it is to withstand those risks, and what investments are needed to close gaps.

**Technical (wrong for board)**: "Our EDR tool detected 347 malicious events last quarter with a mean detection time of 6.2 minutes."

**Business (right for board)**: "We detected and contained every cyberattack attempt last quarter within minutes — protecting customer data and preventing any disruption to operations."

---

## Structure of a Board-Ready CSF Report

### Section 1: Cybersecurity Posture at a Glance

Present a simple dashboard using the six CSF functions:

| CSF Function | Business Question | Status | Direction |
|-------------|------------------|--------|-----------|
| Govern | Do we have the right strategy and governance? | Yellow | Improving |
| Identify | Do we know our assets and risks? | Green | Stable |
| Protect | Are our defenses in place? | Yellow | Improving |
| Detect | Can we detect attacks? | Yellow | Improving |
| Respond | Can we respond to incidents? | Red | Improving |
| Recover | Can we recover quickly? | Red | Improving |

This single view tells the board where you are strong and where you need attention — without requiring any technical knowledge.

### Section 2: Top Three Cybersecurity Risks

Pull your top risks from your risk assessment and present each one in plain language:

**Risk**: Ransomware attack halting operations
**What could happen**: Attackers encrypt our systems, shutting down operations for up to two weeks
**Potential business impact**: $2-5M in lost revenue, recovery costs, and potential regulatory penalties
**What we're doing**: Immutable cloud backups, employee phishing training, enhanced endpoint protection
**What remains**: Recovery time could still be 3-5 days for critical systems
**Decision needed**: Approve $X investment to reduce recovery time to under 24 hours

### Section 3: Progress Since Last Report

Show movement on key initiatives:

| Initiative | Quarter Start | Current | Target | On Track? |
|-----------|---------------|---------|--------|-----------|
| Multi-factor authentication for all users | 60% deployed | 90% deployed | 100% | Yes |
| Incident Response Plan tested | Untested | Tabletop complete | Annual drill | Yes |
| Cloud backup and recovery | Not tested | Q3 test complete | Quarterly | Yes |

### Section 4: Decisions Required from the Board

Be explicit about what you are asking:
- Risk acceptance decisions (risks above appetite requiring board acknowledgment)
- Investment approvals
- Policy approvals (e.g., risk tolerance statement)

---

## Metrics That Boards Understand and Care About

### Financial Metrics
- **Estimated cost of a cybersecurity incident**: Based on industry benchmarks and your specific risk profile (ransomware recovery, regulatory fines, legal costs, reputational damage)
- **Cyber insurance coverage vs. estimated exposure**: Are we adequately covered?
- **Security investment as % of IT budget**: How do we compare to industry peers?

### Operational Metrics
- **Recovery Time Objective (RTO) vs. Actual**: If we had an incident today, how long until critical systems are back online?
- **Backup success rate**: What % of our critical data is being backed up successfully?
- **Time to detect and respond to incidents**: Measured in hours or days, not technical jargon

### Human Risk Metrics
- **Phishing simulation click rate**: What % of employees clicked a simulated phishing email? (Direct measure of human vulnerability, the #1 attack vector)
- **Security awareness training completion**: What % of the workforce has completed required training?
- **Incidents caused by human error**: Trend over time

### Coverage Metrics
- **% of critical systems with multi-factor authentication**: Plain-language measure of access security
- **% of critical vulnerabilities patched within SLA**: Are we fixing known weaknesses promptly?
- **% of critical suppliers assessed for cybersecurity**: Third-party risk measure

---

## Language Translation Guide

| Technical Term | Board-Friendly Language |
|---------------|------------------------|
| Multi-factor authentication (MFA) | "Two-step login — even if a password is stolen, hackers can't get in" |
| Endpoint Detection and Response (EDR) | "Security software on every computer that watches for attacker behavior" |
| Vulnerability scanning | "Regular checks that find security weaknesses before attackers do" |
| Incident Response Plan | "Our emergency playbook for cyberattacks" |
| Recovery Time Objective | "Maximum time committed to restoring systems after an attack" |
| Ransomware | "Malware that locks all your data and demands payment to unlock it" |
| Phishing | "Fake emails designed to trick employees into giving attackers access" |
| Penetration testing | "Hiring ethical hackers to test our defenses before real attackers do" |
| CISO | "Chief Information Security Officer — the executive responsible for cybersecurity" |

---

## Presenting Risk in Business Terms

The most effective board presentations quantify risk in dollars, operational impact, and reputational consequences.

### Risk Quantification Framework

**Scenario-based risk statements work well:**

> "If we experienced a ransomware attack similar to those hitting our sector this year, our analysis suggests we would face:
> - 5–10 days of operational disruption (based on our current recovery capability)
> - $2–4M in lost revenue and recovery costs
> - Potential regulatory notification requirements if customer data is affected
> - Reputational impact with customers and partners
>
> With the investments proposed in this presentation, we would reduce recovery time to under 48 hours and estimated impact to under $500K."

### Use Industry Context

Boards respond to peer comparisons and sector threat data:
- "Ransomware attacks on manufacturers increased 200% last year"
- "The average cost of a data breach in our sector is $4.5M"
- "Our cyber insurance premium increased 40% last year — insurers are pricing our risk"

---

## What Boards Need to Do (Not Just Hear)

Effective board reporting is not one-way. The board has governance responsibilities for cybersecurity:

1. **Approve risk tolerance**: The board should formally approve what level of cybersecurity risk the organization is willing to accept
2. **Review and challenge**: Ask questions about top risks and whether management is addressing them
3. **Authorize investments**: Major cybersecurity investments should have board visibility or approval
4. **Oversee incidents**: Significant cybersecurity incidents should be reported to the board promptly
5. **Ensure accountability**: The board should confirm clear executive ownership of cybersecurity

---

## Recommended Reporting Cadence

| Report | Frequency | Audience | Content |
|--------|-----------|----------|---------|
| Cybersecurity posture briefing | Quarterly | Full board or Audit Committee | Dashboard, top risks, progress, decisions needed |
| Executive summary | Monthly | CEO, CFO, COO | Key metrics, emerging threats, budget tracking |
| Incident report | As needed (24-48 hours) | Board chair, Audit Committee | Incident facts, business impact, response status |
| Annual program review | Annually | Full board | Year-over-year posture, benchmark comparison, annual plan |

---

## Common Mistakes to Avoid in Board Reporting

1. **All-green dashboards**: If everything is green, the board will wonder why you have a cybersecurity budget. Honest risk reporting builds credibility.

2. **Technical jargon without translation**: Every acronym or technical term loses a board member. If you must use a term, define it immediately.

3. **Tool inventories instead of outcomes**: Boards don't need to know you use "CrowdStrike" — they need to know what threat it addresses and how effectively.

4. **No decisions requested**: The board should leave every cybersecurity briefing with clear decisions made or delegated. If you only inform and never ask, you're missing the governance opportunity.

5. **Incident reporting only after it's over**: Boards expect timely notification of significant incidents, even if you don't have all the answers yet.

---

## Summary

Using NIST CSF for board reporting works because the framework's structure naturally maps to business risk categories, and its outcome-oriented language translates well for non-technical audiences. The key principles are:

- Use the six CSF functions as a ready-made board dashboard structure
- Quantify risk in business terms (dollars, downtime, reputation)
- Show progress over time, not just point-in-time status
- Be honest about gaps — boards need accurate risk information to fulfill their fiduciary duty
- Ask for decisions, not just awareness

# PCI DSS Compliance for Stripe-Based E-Commerce: SAQ Selection

**PCI DSS Version: v4.0.1 (current as of June 2024)**

---

## Do You Need PCI DSS Compliance?

**Yes.** Even though Stripe processes the payment card data on your behalf, your organisation is still a payment card merchant and is subject to PCI DSS. The requirement applies to any entity that stores, processes, or transmits cardholder data — or whose systems could impact the security of cardholder data. Using a payment service provider like Stripe reduces your scope but does not eliminate your PCI DSS obligations.

---

## SAQ Selection Decision Tree

To determine the correct SAQ, we need to understand how your website integrates with Stripe:

### Key Question: How does payment data flow through your site?

**Option A — Stripe-hosted payment page (Stripe Checkout / Payment Links)**
- Customers are fully redirected to Stripe's hosted payment page to enter card data
- Your website never loads, processes, or transmits card numbers
- All cardholder data functions are fully outsourced to Stripe (a PCI-compliant third party)

→ **Recommended SAQ: SAQ A** (~22 controls)

**Option B — Stripe.js / Stripe Elements embedded on your page**
- Your payment page loads JavaScript from Stripe's servers (e.g., Stripe.js or Stripe Elements)
- Card data is entered directly into Stripe-hosted iframes embedded on your page
- Your servers never receive raw card data — the PAN goes directly to Stripe
- However, your e-commerce page controls how customers access the payment form

→ **Recommended SAQ: SAQ A-EP** (~191 controls)

**Option C — Custom integration where card data touches your servers**
- Your servers receive raw card numbers before passing them to Stripe
→ **SAQ D (Merchant)** (~340 controls) — and this is strongly inadvisable; restructure the integration.

---

## Most Likely Scenario for Stripe Users

Most e-commerce merchants using Stripe fall into one of two categories:

| Integration Type | SAQ Type | Controls | Notes |
|-----------------|----------|----------|-------|
| Stripe Checkout / Payment Links (full redirect) | **SAQ A** | ~22 | Simplest compliance path |
| Stripe Elements / Stripe.js (embedded iframe) | **SAQ A-EP** | ~191 | More controls; your web server is in partial scope |

### Why SAQ A-EP Instead of SAQ A for Stripe Elements?

The PCI SSC distinguishes between merchants who fully redirect to a third-party page (SAQ A) versus those whose e-commerce page controls the payment flow but uses JavaScript/iframe to capture card data (SAQ A-EP). With Stripe Elements:

- Your web server serves the checkout page that contains the Stripe iframe
- A compromise of your web server could potentially inject malicious scripts that intercept card data before it enters Stripe's iframe
- Therefore, your web server and hosting environment are partially in scope

Under **PCI DSS v4.0.1 Requirement 6.4.3 and 11.6.1**, SAQ A-EP merchants must maintain an inventory of all scripts on payment pages and implement integrity checks (e.g., Subresource Integrity hashes or a Content Security Policy). This is a key new requirement that became mandatory on March 31, 2025.

---

## Merchant Level

Your merchant level determines the rigour of validation required:

| Level | Annual Transactions | Validation Required |
|-------|--------------------|--------------------|
| **Level 1** | >6 million Visa/MC | Annual ROC by QSA + quarterly ASV scans |
| **Level 2** | 1–6 million | Annual SAQ + quarterly ASV scans |
| **Level 3** | 20,000–1 million e-commerce | Annual SAQ + quarterly ASV scans |
| **Level 4** | <20,000 e-commerce | Annual SAQ recommended + quarterly ASV scans |

Most early-to-mid stage e-commerce companies fall at **Level 3 or Level 4**. If you process more than 6 million transactions annually, you are a Level 1 merchant and must engage a QSA for a full Report on Compliance (ROC) — an SAQ is not sufficient.

---

## Practical Compliance Steps (SAQ A or A-EP)

1. **Confirm your Stripe integration type** — check whether you use Stripe Checkout (redirect) or Stripe Elements (embedded iframe)
2. **Complete the applicable SAQ** — obtain from pcisecuritystandards.org
3. **Run quarterly ASV scans** — use a PCI SSC-approved ASV vendor to scan your external-facing IP addresses and domains
4. **Verify Stripe's compliance status** — obtain Stripe's current Attestation of Compliance (AOC); Stripe maintains Level 1 Service Provider compliance
5. **Execute a Service Provider Agreement** — ensure your contract with Stripe addresses data security responsibilities
6. **Implement script integrity controls (SAQ A-EP)** — under Req 6.4.3/11.6.1, maintain a script inventory and integrity verification mechanism for your payment page
7. **Submit your SAQ and AOC** — to your acquiring bank annually

---

## Important v4.0.1 Notes

- **PCI DSS v3.2.1 was retired March 31, 2024** — all assessments must now reference v4.0 or v4.0.1
- **All "future-dated" requirements in v4.0 became mandatory March 31, 2025**, including Req 6.4.3 (payment page script inventory) and Req 11.6.1 (payment page integrity monitoring) — highly relevant to SAQ A-EP merchants
- The Customised Approach (new in v4.0) is available to SAQ A-EP merchants with mature security programs who wish to implement alternative controls with a Targeted Risk Analysis (TRA)

---

> **Disclaimer:** This guidance is based on PCI DSS v4.0.1 (PCI SSC, June 2024). Formal compliance validation must be conducted by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA). Verify against the official standard at pcisecuritystandards.org.

# PCI DSS Compliance for E-Commerce with Stripe

## Do You Need PCI DSS Compliance?

Yes, as an e-commerce company that accepts credit card payments, you are subject to PCI DSS (Payment Card Industry Data Security Standard) requirements. This applies even when you use a payment processor like Stripe. PCI DSS is a set of security standards established by the major card brands (Visa, Mastercard, American Express, Discover, and JCB) through the PCI Security Standards Council.

Using Stripe significantly reduces your compliance burden because Stripe handles the actual card data processing, but it does not eliminate your obligations entirely.

## What SAQ Level Applies?

The Self-Assessment Questionnaire (SAQ) you need depends on how you've integrated Stripe into your website:

### SAQ A — Fully Outsourced (Simplest)
If you use **Stripe Checkout** or **Payment Links** where customers are completely redirected to Stripe's hosted payment page, you likely qualify for **SAQ A**. This is the simplest SAQ with the fewest requirements (around 20 controls). Your website never touches card data in this scenario.

**Requirements for SAQ A:**
- All payment processing is outsourced to a PCI-compliant third party
- Your company does not electronically store, process, or transmit cardholder data
- Your website only redirects customers to the payment processor

### SAQ A-EP — E-Commerce with Embedded Payment
If you use **Stripe Elements** or **Stripe.js** with an embedded payment form on your own website pages, you likely need **SAQ A-EP**. This has more controls (around 190) because your web server is partially in scope.

**This applies when:**
- Customers enter card data into a form hosted on your domain (even if it's in an iframe from Stripe)
- Your web servers serve the payment page
- A compromise of your web server could potentially affect payment data security

### SAQ D — Full Scope
If your servers ever receive, transmit, or store raw card numbers, you would need the much more comprehensive **SAQ D** with hundreds of controls. This is rare with Stripe integrations and should be avoided by using Stripe's recommended integration patterns.

## Merchant Levels

Your merchant level determines how you validate compliance:

- **Level 1**: Over 6 million transactions/year — requires a formal audit by a Qualified Security Assessor (QSA)
- **Level 2**: 1-6 million transactions/year — annual SAQ plus quarterly vulnerability scans
- **Level 3**: 20,000 to 1 million e-commerce transactions — annual SAQ plus quarterly scans
- **Level 4**: Under 20,000 e-commerce transactions — annual SAQ recommended plus quarterly scans

Most small to mid-size e-commerce companies fall into Level 3 or Level 4.

## Practical Recommendations

1. **Identify your Stripe integration type** — check if you use Stripe Checkout (redirect) or Stripe Elements (embedded)
2. **Complete the appropriate SAQ** — available free from the PCI Security Standards Council website
3. **Run quarterly external vulnerability scans** — use an Approved Scanning Vendor (ASV)
4. **Obtain Stripe's compliance documentation** — Stripe publishes their compliance certificates; download their Attestation of Compliance (AOC)
5. **Report to your acquiring bank** — submit your SAQ annually

## Bottom Line

- Using Stripe Checkout/redirect → likely **SAQ A** (easiest)
- Using Stripe Elements/embedded forms → likely **SAQ A-EP** (moderate)
- Most e-commerce companies with Stripe do NOT need a full QSA audit unless processing very high transaction volumes

The good news is that using a reputable payment processor like Stripe places the heaviest compliance burden on them, not you. Your main obligations are completing the right SAQ, running quarterly scans, and ensuring your website itself is secure.

# PCI DSS v4.0.1 Requirement 3: Protect Stored Account Data

**PCI DSS Version: v4.0.1 (current, June 2024)**

---

## Overview

**Requirement 3: Protect Stored Account Data** falls under the second PCI DSS goal: *Protect Account Data*. It governs what cardholder data and sensitive authentication data (SAD) organisations may store, how long it may be retained, and what cryptographic protections must be applied to stored Primary Account Numbers (PANs).

Requirement 3 works in conjunction with **Requirement 4** (which covers data in transit). Together they protect account data throughout its lifecycle.

---

## Key Terminology

| Term | Definition | Storage Rules |
|------|-----------|---------------|
| **PAN** (Primary Account Number) | The card number | Can be stored if rendered unreadable (Req 3.5) |
| **Cardholder Name** | Name on card | Can be stored in plaintext |
| **Expiry Date** | Card expiry | Can be stored in plaintext |
| **Service Code** | 3–4 digit value on magnetic stripe | Can be stored in plaintext |
| **Full Track Data** (magnetic stripe or chip equivalent) | All data on the magnetic stripe | **Must NEVER be stored after authorisation** |
| **CVV/CVC** (Card Verification Value) | 3–4 digit security code | **Must NEVER be stored after authorisation** |
| **PIN / PIN Block** | Personal identification number | **Must NEVER be stored after authorisation** |

**Critical rule**: SAD (Full track data, CVV/CVC, PINs) must never be stored after the authorisation of a transaction — even in encrypted form.

---

## Requirement 3 Sub-Controls (v4.0.1)

### 3.1 — Processes and Mechanisms for Protecting Stored Account Data

**3.1.1**: All security policies and procedures for protecting stored account data are documented, in use, and known to all affected parties.

**3.1.2** (new in v4.0): Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood.

---

### 3.2 — Storage of Account Data is Kept to a Minimum

**3.2.1**: Account data storage is limited to the minimum data elements necessary, consistent with legal, regulatory, and/or business requirements. A data retention policy exists and includes:
- Storage amount and retention time for each data element
- Processes for secure deletion when data is no longer needed
- Quarterly process to identify and securely delete stored data that exceeds retention requirements

**Key point**: If you don't need the data, don't store it. The best protection for stored data is not storing it in the first place.

---

### 3.3 — Sensitive Authentication Data (SAD) is Not Retained After Authorisation

**3.3.1**: SAD is not retained after authorisation, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorisation process.

**3.3.2**: SAD that is stored electronically prior to completion of authorisation is encrypted using strong cryptography.

**3.3.3** (applies to issuers only): Any SAD stored by issuers prior to authorisation is protected and a business justification exists for such storage.

---

### 3.4 — Access to Displays of Full PAN and Ability to Copy PAN Data is Restricted

**3.4.1**: If disk-level or partition-level encryption is used (rather than database/file-level encryption), it is managed separately and independently of OS authentication/access control mechanisms, and decryption keys are not associated with user accounts.

**3.4.2** (new in v4.0): When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except those with documented, explicit authorisation and a legitimate business need.

---

### 3.5 — Primary Account Number (PAN) is Secured Wherever it is Stored

**3.5.1**: PAN is secured with any of the following:
- **One-way hashes** based on strong cryptography (hash of the entire PAN)
- **Truncation** — only a segment of the PAN is stored (no more than the first six and last four digits)
- **Index tokens** — a token replaces the PAN; the mapping table is stored securely
- **Strong cryptography** (e.g., AES-256) with associated key management processes

**3.5.1.1**: Hashes used to render PAN unreadable shall be keyed cryptographic hashes (e.g., HMAC) using strong cryptography, with associated key management processes. (Added in v4.0.1)

**3.5.1.2**: If disk-level or partition-level encryption is used to render PAN unreadable, it must meet specific criteria (not just relying on OS-level encryption).

**3.5.1.3**: If disk-level or partition-level encryption is used, logical access must be managed independently of OS.

---

### 3.6 — Cryptographic Keys Used to Protect Stored Account Data are Secured

**3.6.1**: Procedures and processes for protecting cryptographic keys used to protect stored account data are defined and implemented, including:
- Generation of strong keys
- Secure key distribution
- Secure key storage
- Cryptographic key changes when keys reach end of cryptoperiod
- Retirement or replacement of keys that have weakened or are suspected of compromise
- Splitting knowledge and dual control of keys (to avoid single persons having full key access)
- Prevention of unauthorised substitution of keys

**3.6.1.1** (new in v4.0): A documented description of the cryptographic architecture is maintained, including:
- Algorithms, protocols, and key lengths in use
- Description of key usage for each key
- Inventory of all hardware security modules (HSMs) and other SCDs used

**3.6.1.2** (new in v4.0): Secret and private keys used to encrypt/decrypt account data are stored in one or both of the following forms: encrypted with a key-encrypting key; within a secure cryptographic device such as an HSM.

**3.6.1.3** (new in v4.0): Access to cleartext cryptographic key-encrypting keys is restricted to the fewest number of custodians necessary.

**3.6.1.4** (new in v4.0): Cryptographic keys are stored in the fewest possible locations.

---

### 3.7 — Where Cryptography is Used to Protect Stored Account Data, Key Management Processes and Procedures Covering All Aspects of the Key Lifecycle are Defined and Implemented

**3.7.1**: Key management policies include procedures for generation of strong cryptographic keys.

**3.7.2**: Key management policies include procedures for secure distribution of cryptographic keys.

**3.7.3**: Key management policies include procedures for secure storage of cryptographic keys.

**3.7.4**: Key management policies include procedures for cryptographic key changes for keys that have reached the end of their cryptoperiod.

**3.7.5**: Key management policies include procedures for retirement, replacement, or destruction of keys.

**3.7.6**: Where manual cleartext cryptographic key-management operations are performed, these operations are managed using split knowledge and dual control.

**3.7.7**: Unauthorised substitution of cryptographic keys is prevented.

**3.7.8**: Cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.

**3.7.9** (new in v4.0): Where an entity shares cryptographic keys with a service provider for transmission or processing of account data, guidance on secure transmission, storage, and changing of such keys exists.

---

## What Changed from PCI DSS v3.2.1 to v4.0/v4.0.1?

| Change Area | v3.2.1 | v4.0 / v4.0.1 |
|------------|--------|--------------|
| **Roles and responsibilities** | Not explicitly required in Req 3 | **New 3.1.2**: Roles and responsibilities must be documented, assigned, and understood |
| **Remote access PAN copy controls** | Not explicitly addressed | **New 3.4.2**: Technical controls must prevent copy/relocation of PAN via remote access |
| **Keyed hashing** | Strong one-way hash acceptable | **New 3.5.1.1**: Hashes must be *keyed* cryptographic hashes (e.g., HMAC); plain SHA hashes of PAN are no longer sufficient |
| **Cryptographic architecture documentation** | Not required | **New 3.6.1.1**: Must maintain documented cryptographic architecture including algorithms, key usage, and HSM inventory |
| **Key-encrypting key protection** | General key protection required | **New 3.6.1.2**: Secret/private keys must be stored encrypted with a KEK or within an HSM/SCD |
| **KEK custodian access** | Not specifically restricted | **New 3.6.1.3**: Cleartext KEK access restricted to minimum number of custodians |
| **Key storage minimisation** | Not addressed | **New 3.6.1.4**: Keys must be stored in fewest possible locations |
| **Service provider key guidance** | Not addressed | **New 3.7.9**: Guidance required when sharing keys with service providers |

### Summary of v4.0 Themes in Requirement 3

1. **Stronger hashing requirements**: Unkeyed SHA hashes of PAN (e.g., SHA-256 of the raw PAN) are no longer acceptable under 3.5.1.1. You must use HMAC or another keyed hash.
2. **Formalised cryptographic inventory**: For the first time, organisations must document their entire cryptographic architecture (3.6.1.1).
3. **Key protection elevated**: Keys encrypting cardholder data must themselves be stored in HSMs or encrypted by a key-encrypting key (3.6.1.2).
4. **Remote access controls**: A new control (3.4.2) addresses the risk of remote access tools being used to exfiltrate PAN data.
5. **Roles formalised**: Explicit ownership of Requirement 3 activities must be assigned (3.1.2).

---

## Evidence Required for QSA Assessment

| Sub-Control | Evidence a QSA Will Request |
|------------|----------------------------|
| 3.2.1 | Data retention policy, evidence of quarterly data purge process, data flow diagrams |
| 3.3.1 | Confirmation SAD is not stored; log/database reviews showing no SAD in storage |
| 3.5.1 | Database/file inspection showing PAN is hashed, truncated, or encrypted |
| 3.5.1.1 | Proof that hashing algorithm is a keyed hash (HMAC); key management docs |
| 3.6.1.1 | Cryptographic architecture document; HSM inventory |
| 3.6.1.2 | Evidence that encryption keys are stored in HSMs or encrypted with KEKs |
| 3.7.6 | Key ceremony documentation showing split knowledge and dual control |
| 3.7.8 | Signed key custodian acknowledgement forms |

---

## Common Gaps

- Storing CVV/CVC in databases "just in case" for recurring billing — this is **never permitted**
- Using unkeyed SHA-256 hashes of PAN (now non-compliant under v4.0.1, Req 3.5.1.1)
- Retaining full track data in transaction logs, error logs, or debug logs
- Inadequate key management: symmetric keys stored in the same location as encrypted data
- No formal key custodian acknowledgement process
- Undocumented cryptographic architecture — now explicitly required under 3.6.1.1

---

> **Disclaimer:** This guidance is based on PCI DSS v4.0.1 (PCI SSC, June 2024). Formal compliance validation must be conducted by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA). Verify against the official standard at pcisecuritystandards.org.

# PCI DSS Requirements for Protecting Stored Cardholder Data (Requirement 3)

## Overview of Requirement 3

PCI DSS Requirement 3 focuses on protecting stored cardholder data. The core principle is simple: **if you don't need the data, don't store it**. If you must store it, protect it properly.

## Types of Card Data and Storage Rules

PCI DSS distinguishes between two categories of account data:

### Cardholder Data (CHD) — Can be stored if protected:
- **Primary Account Number (PAN)** — the card number; the most sensitive element; must be rendered unreadable if stored
- **Cardholder name** — can be stored
- **Expiration date** — can be stored
- **Service code** — can be stored

### Sensitive Authentication Data (SAD) — Must NEVER be stored after authorization:
- **Full magnetic stripe or chip data** (track data)
- **CAV2/CVC2/CVV2/CID** (the 3-4 digit security code on the card)
- **PINs and PIN blocks**

Even if encrypted, SAD cannot be retained after a transaction is authorized. This is an absolute prohibition.

## Key Requirements Under Requirement 3

### Data Retention (3.1/3.2)
- Implement a data retention policy specifying the minimum data needed
- Define retention periods for each data element
- Implement processes to securely delete data when no longer needed
- Review stored data at least quarterly to identify and delete unnecessary cardholder data

### SAD Not Retained After Authorization (3.3)
- All SAD must be unrecoverable after the authorization process completes
- No exceptions — even encrypted SAD cannot be stored post-authorization

### Masking PAN on Displays (3.4)
- When displaying PAN, mask it so that only the first six and last four digits are visible (e.g., 4111 11** **** 1111)
- Personnel with a legitimate business need can see more digits

### Rendering PAN Unreadable (3.5)
Stored PAN must be rendered unreadable using one or more of:
- **Strong one-way hash functions** (e.g., SHA-256) — the whole PAN is hashed
- **Truncation** — storing only a portion of the PAN (first 6/last 4 digits)
- **Index tokens** — a token replaces the PAN, with the mapping stored securely
- **Strong cryptography** (e.g., AES-256) with proper key management

### Cryptographic Key Management (3.6/3.7)
- Use strong cryptographic algorithms and key lengths
- Implement full key lifecycle management: key generation, distribution, storage, use, retirement, and destruction
- Split knowledge and dual control for manual key operations
- Change encryption keys when they reach their cryptoperiod
- Formal key custodian acknowledgment

## What Changed from PCI DSS v3.2.1 to v4.0?

PCI DSS v4.0 introduced several enhancements to Requirement 3:

### Stronger Hashing Requirements
In v3.2.1, strong one-way hashes were acceptable for protecting PAN. In v4.0, there's an added emphasis that hashes should be **keyed cryptographic hashes** (like HMAC). Using a plain SHA-256 hash of just the PAN is considered insufficient because it could theoretically be rainbow-table attacked given the limited PAN space.

### Documented Cryptographic Architecture
v4.0 introduced a new requirement to maintain a documented inventory and description of your cryptographic architecture, including the algorithms, key usage, and cryptographic devices (like HSMs) in use. This did not exist explicitly in v3.2.1.

### Key Protection Requirements Enhanced
v4.0 strengthened key protection requirements, including requirements around how keys that encrypt cardholder data must themselves be protected — typically requiring encryption with a key-encrypting key (KEK) or storage in a hardware security module (HSM).

### Remote Access Controls
A new control was added addressing the risk of cardholder data being copied or relocated via remote access technologies. Organizations must implement technical controls to prevent unauthorized copying of PAN through remote access tools.

### Roles and Responsibilities
v4.0 added a requirement to formally document and assign roles and responsibilities for each PCI DSS requirement area, including Requirement 3.

### SAD Definition Clarification
v4.0 provided clearer guidance around SAD protection during pre-authorization storage, which applies specifically to issuers and processors who need to temporarily store SAD during the authorization process.

## Practical Implications

For most merchants, the key takeaways are:
1. **Stop storing CVV/CVC** — this is the most common violation; you cannot store it for recurring payments
2. **Truncate or hash stored PANs** — if you need to store card references, use truncated numbers or tokens
3. **Review your logs** — transaction logs, error logs, and debug logs often inadvertently capture full card numbers
4. **Key management matters** — if you encrypt PANs, your key management practices must be rigorous
5. **Update hashing practices** — if using SHA hashes, ensure they are keyed hashes (HMAC) under v4.0

The best approach for most merchants is tokenization — replacing card data with tokens so that you never need to store actual PANs at all, which largely removes you from the scope of Requirement 3.

# PCI DSS Breach Notification Obligations Following a Card Processing System Compromise

**PCI DSS Version: v4.0.1 (current, June 2024)**

---

## Immediate Priority: Contain and Preserve Evidence

Before addressing notifications, take immediate containment steps — but **do not destroy evidence** (do not wipe or reimage compromised systems without forensic imaging first):

1. Isolate compromised systems from the network (segment, but do not power off if avoidable)
2. Preserve all logs and forensic artifacts
3. Engage your internal incident response team per your Incident Response Plan (Req 12.10)
4. Engage a PCI Forensic Investigator (PFI) — your acquirer will likely mandate this

---

## Who to Notify and When

PCI DSS does not itself specify exact notification timeframes in hours/days in the same way that GDPR or US state breach laws do. However, the card brand rules, acquirer agreements, and PCI DSS requirements together create a clear set of obligations:

### 1. Your Acquiring Bank (Acquirer) — **Immediately / Within 24 Hours**

**Your most urgent notification.** Your merchant agreement with your acquirer (the bank that processes your card payments) almost certainly requires immediate notification of a suspected breach. Most acquirer agreements specify notification within **24 hours** of discovering a potential compromise.

- Contact your acquirer's security/risk team by phone first, then follow up in writing
- Your acquirer will coordinate with the card brands (Visa, Mastercard, etc.) on your behalf
- Failing to notify your acquirer promptly can result in accelerated fines and penalties

**PCI DSS Reference:** Req 12.10.1 requires an incident response plan that includes notification procedures. Your acquirer is the first mandatory notification target.

---

### 2. Card Brands (Visa, Mastercard, Amex, Discover, JCB) — **Via Acquirer, Typically Within 24–72 Hours**

In most cases, your acquirer will notify the card brands on your behalf. However, if you are a **Level 1 service provider** or if your acquirer instructs you to contact card brands directly, you may need to reach out independently.

**Visa**: Requires notification within 24 hours of discovery (via acquirer for merchants)
**Mastercard**: Requires notification within 24 hours of discovery (via acquirer for merchants)

The card brands will:
- Determine whether an Account Data Compromise (ADC) event has occurred
- Identify the window of exposure and the range of potentially compromised account numbers (the "common point of purchase" or CPP analysis)
- Issue fines and assessments based on the number of compromised accounts
- Mandate specific remediation steps

---

### 3. PCI Forensic Investigator (PFI) — **Within 24–72 Hours of Discovery**

The card brands and your acquirer will require you to engage a **PCI Forensic Investigator (PFI)** — a QSA firm approved to conduct forensic investigations under card brand rules. The PFI will:

- Conduct a forensic investigation of the compromise
- Determine the scope of the breach (what data was accessed, for what time period)
- Produce a PFI Report for the card brands
- Confirm whether your systems were PCI DSS compliant at the time of the breach

You typically cannot choose to forego a PFI engagement once the card brands are involved. Costs are typically borne by the merchant.

---

### 4. Law Enforcement — **As Appropriate**

- Report to the **FBI Cyber Division** or local law enforcement if criminal activity is suspected (which it typically is in a payment card breach)
- In the US, the **Secret Service** (Electronic Crimes Task Force) also investigates payment card fraud
- Law enforcement engagement is not strictly required by PCI DSS but is strongly recommended and may be required by your legal counsel
- A law enforcement hold may affect your forensic preservation obligations

---

### 5. Affected Cardholders — **Typically Via the Card Brands**

Under PCI DSS, **you do not directly notify cardholders**. The card brands notify issuing banks, who in turn notify cardholders and reissue compromised cards. However:

- US state breach notification laws (all 50 states have them) may require direct consumer notification if personal information was exposed alongside card data
- Consult legal counsel for applicable state/federal breach notification obligations (e.g., CCPA in California, NY SHIELD Act, etc.)
- GDPR notification within **72 hours** to your supervisory authority if EU residents' data may be affected

---

### 6. Regulators — **Dependent on Jurisdiction and Data Types**

Depending on your industry and jurisdiction:
- **GDPR (EU/UK)**: 72-hour notification to the relevant Data Protection Authority if personal data was involved
- **US State AGs**: Some states require notification to the Attorney General
- **SEC**: If you are a publicly traded company, material breaches may trigger disclosure obligations under SEC cybersecurity rules (effective December 2023)
- **FTC**: Relevant if you are subject to the FTC Safeguards Rule (financial institutions/fintech)

---

## PCI DSS Incident Response Requirements (Requirement 12.10)

Your organisation must have a documented Incident Response Plan under **Requirement 12.10**. Key sub-requirements:

| Req | Requirement | Notes |
|-----|-------------|-------|
| **12.10.1** | IR plan exists and is ready to be activated immediately upon system breach | Must include card brand and acquirer notification procedures |
| **12.10.2** | IR plan is reviewed and tested at least once every 12 months | Testing must cover payment card incident scenarios |
| **12.10.3** | Specific personnel are designated, trained, and available 24/7 to respond | |
| **12.10.4** | IR personnel receive appropriate and ongoing training | |
| **12.10.4.1** (new v4.0) | Training for IR personnel at least every 12 months | |
| **12.10.5** | Alerts from security monitoring systems are included in the IR plan | |
| **12.10.6** | IR plan is modified and evolved based on lessons learned and industry developments | |
| **12.10.7** (new v4.0) | IR procedures exist for detection of and response to payment page (e-commerce) attacks | Specifically addresses web skimming / Magecart-style attacks |

---

## Financial Consequences of a Breach

Understanding the financial stakes:

- **Card brand fines**: Visa and Mastercard can impose fines ranging from **$5,000 to $100,000 per month** during a non-compliance period; after a confirmed breach, assessments are tied to the number of compromised accounts
- **Fraud reimbursement**: You may be liable for fraudulent charges made on compromised cards
- **Card reissuance fees**: Issuing banks may seek reimbursement for card reissuance costs (typically $3–15 per card)
- **PFI investigation costs**: PFI investigations typically cost **$20,000–$100,000+**
- **Level 1 uplift**: After a confirmed breach, you may be elevated to **Merchant Level 1** regardless of transaction volume, requiring an annual QSA ROC going forward

---

## Summary: Notification Checklist

| Notify | Timeframe | Method |
|--------|-----------|--------|
| **Acquiring bank** | Immediately / within 24 hours | Phone + written |
| **Card brands** (via acquirer) | Within 24–72 hours | Via acquirer |
| **PFI** (engage forensic investigator) | Within 24–72 hours | Direct engagement |
| **Law enforcement (FBI/Secret Service)** | As soon as practical | Report online or via local field office |
| **Data Protection Authority (GDPR)** | Within 72 hours if EU personal data involved | Via national DPA portal |
| **State AGs / consumers (US breach laws)** | Per applicable state law (typically 30–72 days) | Via legal counsel |
| **SEC (if public company)** | 4 business days after materiality determination | Form 8-K |

---

> **Disclaimer:** This guidance is based on PCI DSS v4.0.1 (PCI SSC, June 2024) and general card brand rules as publicly known. Notification obligations are also governed by your acquirer agreement and applicable law. Engage legal counsel and a PCI Forensic Investigator immediately upon discovering a potential breach. This does not constitute legal advice.

# PCI DSS Breach Notification Obligations

## Overview

A potential compromise of your card processing system triggers multiple notification obligations across different parties. PCI DSS itself doesn't prescribe exact hour-by-hour notification timelines the way GDPR does, but your acquirer agreements and card brand rules do. Time is critical — act immediately.

## Step 1: Contain First, Then Notify

Before notifications, take immediate action to limit the damage:
- Isolate compromised systems (do not destroy evidence — preserve logs and system images)
- Do not power off systems without consulting a forensic investigator first
- Activate your incident response plan

## Who to Notify

### 1. Your Acquiring Bank (Most Urgent — Within 24 Hours)

Your acquiring bank (the bank that processes your card transactions) is your **most important first call**. Your merchant agreement almost certainly requires you to notify them within 24 hours of discovering a suspected breach.

- Call your acquirer's risk or security team immediately
- Follow up in writing
- Your acquirer will then communicate with the card networks on your behalf

Failure to notify your acquirer promptly can result in significantly increased fines and penalties.

### 2. Card Brands (Visa, Mastercard, Amex, etc. — via Acquirer)

In most cases, your acquirer notifies the card brands for you. Card brands typically expect notification within 24-72 hours of discovery. They will:
- Investigate whether a confirmed Account Data Compromise occurred
- Identify the potentially compromised card numbers and timeframe
- Assess fines and penalties
- Require you to engage a forensic investigator

### 3. PCI Forensic Investigator (PFI) — Engage Immediately

The card brands will require you to hire a **PCI Forensic Investigator (PFI)**, which is a specially qualified firm approved by the card brands. The PFI will:
- Conduct an independent forensic investigation
- Determine what data was compromised and for what period
- Prepare a report for the card brands
- Confirm your compliance status at the time of the incident

You typically cannot avoid this requirement once a potential breach is reported. Budget for significant costs.

### 4. Law Enforcement

While not strictly required by PCI DSS, you should:
- Report to the **FBI** (via the Internet Crime Complaint Center — IC3.gov) or local FBI field office
- Consider reporting to the **Secret Service Electronic Crimes Task Force** (they investigate payment card fraud)
- Consult your legal counsel about obligations to report to specific agencies

### 5. Affected Cardholders — Indirect

You typically do **not** directly notify affected cardholders under PCI DSS. Instead:
- The card brands notify the issuing banks
- Issuing banks notify cardholders and reissue cards
- However, US state breach notification laws may require direct consumer notification

### 6. Regulators and Legal Obligations

Depending on your situation:
- **US State Breach Notification Laws**: All 50 US states require breach notification. Timelines vary but are commonly 30-72 days. Many require notification to both affected individuals and the state Attorney General.
- **GDPR**: If any EU residents' card data may have been compromised, notify your supervisory Data Protection Authority within **72 hours** of becoming aware of the breach.
- **SEC Disclosure**: If you're a publicly traded company, material cybersecurity incidents must be disclosed within 4 business days of determining materiality.
- **FTC Safeguards Rule**: May apply if you are considered a financial institution.

## Timeframe Summary

| Party | When to Notify |
|-------|---------------|
| Acquiring bank | Immediately, within 24 hours |
| Card brands | Within 24-72 hours (usually via acquirer) |
| PFI | Engage within 24-72 hours |
| Law enforcement | As soon as practical |
| GDPR supervisory authority | Within 72 hours if EU data affected |
| Consumers (US state law) | Varies by state, typically 30-72 days |
| SEC (if public) | Within 4 business days of materiality determination |

## Financial Consequences

Understanding the stakes:
- **Card brand fines**: Substantial monthly fines during non-compliance
- **Fraud liability**: You may be liable for fraudulent transactions on compromised cards
- **Card reissuance fees**: Issuing banks may recover card replacement costs
- **Investigation costs**: PFI investigations can cost tens of thousands of dollars
- **Compliance escalation**: Following a breach, you may be required to undergo a full QSA audit annually going forward, regardless of your transaction volume

## Immediate Action Checklist

1. Activate incident response plan
2. Isolate compromised systems (preserve evidence)
3. Call acquiring bank within 24 hours
4. Engage a PCI Forensic Investigator
5. Contact legal counsel immediately
6. Document all response actions with timestamps
7. Do not make public statements without legal approval
8. Do not destroy any evidence

# PCI DSS Penetration Testing Requirements (Requirement 11.3)

**PCI DSS Version: v4.0.1 (current, June 2024)**

---

## Overview

Penetration testing requirements fall under **PCI DSS Requirement 11: Test Security of Systems and Networks Regularly**, which is part of the fifth goal: *Regularly Monitor and Test Networks*. Requirement 11.3 specifically governs penetration testing.

PCI DSS v4.0 significantly enhanced the penetration testing requirements compared to v3.2.1, adding segmentation testing requirements, greater scope clarity, and more explicit methodology requirements.

---

## Requirement 11.3 — Penetration Testing

### 11.3.1 — External Penetration Test

**What it requires:**
- External penetration testing is performed at least **once every 12 months**
- Testing must occur after any significant infrastructure or application upgrade or change
- Testing covers the **external perimeter** of the CDE and any critical systems

**Scope:**
- All externally accessible IP addresses and services in scope for PCI DSS
- Web applications that handle cardholder data
- APIs that touch cardholder data or CDE systems

---

### 11.3.1.1 — Remediation and Retesting

**What it requires:**
- All exploitable vulnerabilities found during penetration testing are corrected
- Retesting is performed to verify vulnerabilities have been remediated
- Testing is repeated until exploitable vulnerabilities no longer exist
- Results are retained and available for review

---

### 11.3.1.2 — Internal Penetration Test

**What it requires:**
- Internal penetration testing is performed at least **once every 12 months**
- Testing must occur after any significant infrastructure or application upgrade or change
- Covers the **internal network** including CDE-adjacent systems

**Scope:**
- All systems and network components in the CDE
- Systems that could be leveraged to attack the CDE
- Internal interfaces between the CDE and other network segments

---

### 11.3.1.3 — Segmentation Testing (Critical New Requirement Area)

**What it requires:**
- If network segmentation is used to isolate the CDE from other networks, penetration testing must **validate that segmentation controls are effective** and operational
- Segmentation testing must be performed at least:
  - **Once every 12 months** for standard merchants
  - **Once every 6 months** for **service providers** (this is a higher frequency requirement)
- Segmentation tests must attempt to exploit segmentation controls to confirm that out-of-scope systems cannot reach in-scope CDE systems

**Why this matters:** Organisations frequently claim network segmentation to reduce PCI DSS scope but have never validated whether the segmentation actually works. Requirement 11.3.1.3 closes this gap by requiring proof of effective segmentation.

---

## Scope of Penetration Testing

Under PCI DSS v4.0.1, the penetration test scope must include:

| Scope Area | Details |
|-----------|---------|
| **CDE perimeter** | All systems at the boundary of the CDE — firewalls, web proxies, load balancers |
| **All CDE systems** | Any system that stores, processes, or transmits cardholder data |
| **Connected systems** | Systems that are not in the CDE but could impact CDE security if compromised |
| **Network segmentation controls** | Firewalls, VLANs, ACLs used to isolate the CDE |
| **Application layer (web/API)** | Applications handling cardholder data; must test at the application layer, not just network layer |
| **All supporting infrastructure** | DNS, DHCP, authentication systems (AD/LDAP) used by CDE systems |

**The scope must cover both the network layer and the application layer.** Network-only penetration tests are insufficient for PCI DSS compliance.

---

## Penetration Testing Methodology

PCI DSS v4.0.1 (Req 11.3) requires that testing be based on an **industry-accepted penetration testing methodology**. Acceptable frameworks include:

- **PTES** (Penetration Testing Execution Standard)
- **OWASP Testing Guide** (for web application components)
- **NIST SP 800-115** (Technical Guide to Information Security Testing)
- **OSSTMM** (Open Source Security Testing Methodology Manual)

The methodology used must:
1. Cover the entire CDE perimeter and internal systems
2. Include testing from both inside and outside the network (simulating internal and external attackers)
3. Include application-layer testing
4. Validate network segmentation (Req 11.3.1.3)
5. Define how findings will be rated and prioritised (typically CVSS scoring)
6. Include exploitation attempts, not just vulnerability scanning

**Important distinction:** Penetration testing is not the same as vulnerability scanning (Req 11.3.2). Penetration testing involves active exploitation attempts to demonstrate actual risk. ASV scanning (Req 11.3.2) is separate and runs quarterly.

---

## Tester Qualifications

PCI DSS v4.0.1 requires that penetration testing be performed by a **qualified internal resource or qualified external third party**. Specifically:

### Qualification Requirements (Req 11.3.1 guidance):

| Requirement | Details |
|------------|---------|
| **Organisational independence** | The tester must be independent of the system being tested. An internal team member who maintains the systems they are testing does not qualify. |
| **Specialised expertise** | The tester must have demonstrated expertise in penetration testing methodology |
| **No conflict of interest** | If using internal resources, they must not be responsible for managing the systems under test |

### Recommended Certifications

While PCI DSS does not mandate specific certifications, widely accepted credentials for PCI penetration testers include:

| Certification | Body | Notes |
|--------------|------|-------|
| **OSCP** (Offensive Security Certified Professional) | Offensive Security | Highly regarded; hands-on exploitation focus |
| **CREST** | CREST International | Required by some card brands and regulators; common in UK/EU |
| **GPEN** (GIAC Penetration Tester) | GIAC/SANS | Well-recognised; covers methodology and techniques |
| **CEH** (Certified Ethical Hacker) | EC-Council | Common but considered less rigorous than OSCP/CREST |
| **QSA with penetration testing specialisation** | PCI SSC | QSA credentials alone do not qualify someone as a penetration tester |

For **Level 1 merchants and service providers**, card brands often prefer or require testers with **CREST** or equivalent credentials and a formal statement of scope and methodology.

---

## What Changed from PCI DSS v3.2.1?

| Area | v3.2.1 | v4.0 / v4.0.1 |
|------|--------|--------------|
| **Segmentation testing** | Required, but frequency not differentiated by entity type | **Service providers must test segmentation every 6 months** (merchants every 12 months) |
| **Methodology documentation** | Industry-accepted methodology required | More explicit requirements for what methodology must cover; application layer explicitly required |
| **Roles and responsibilities** | Not explicitly formalised | New sub-requirement to formally document and assign roles for Req 11 activities |
| **Remediation timeframes** | Correction required; retesting required | Stronger emphasis on retesting until no exploitable vulnerabilities remain |
| **Scope guidance** | CDE perimeter and internal | More explicit guidance that all CDE-connected systems are in scope, not just CDE itself |
| **Future-dated (now mandatory)** | — | All v4.0 future-dated requirements related to Req 11 became mandatory March 31, 2025 |

---

## Frequency Summary

| Test Type | Merchant Frequency | Service Provider Frequency |
|-----------|-------------------|--------------------------|
| External penetration test | At least annually; after significant changes | At least annually; after significant changes |
| Internal penetration test | At least annually; after significant changes | At least annually; after significant changes |
| Segmentation test | At least annually | **At least every 6 months** |
| ASV external vulnerability scan (Req 11.3.2) | Quarterly | Quarterly |

---

## Evidence Required for QSA Assessment

A QSA reviewing your penetration testing program will request:

1. **Written penetration testing scope document** — what systems were tested, from what network positions
2. **Penetration test report** — executive summary, findings, evidence of exploitation, CVSS ratings
3. **Segmentation test results** — demonstrating that out-of-scope systems cannot reach CDE systems
4. **Remediation evidence** — tickets, change records showing vulnerabilities were fixed
5. **Retest results** — confirmation that remediated vulnerabilities no longer exist
6. **Tester qualifications** — CV or certifications of the person who performed the test
7. **Methodology documentation** — which standard was followed

---

> **Disclaimer:** This guidance is based on PCI DSS v4.0.1 (PCI SSC, June 2024). Penetration testing must be designed and executed by qualified professionals. Formal compliance validation requires a QSA or ISA assessment. Verify against the official standard at pcisecuritystandards.org.

# PCI DSS Penetration Testing Requirements

## Overview

PCI DSS requires regular penetration testing as part of its broader mandate to regularly test security systems and processes. Penetration testing is distinct from vulnerability scanning — it involves actively exploiting vulnerabilities to demonstrate actual risk, not just identifying them.

## How Often Must You Test?

### Annual Testing (Minimum)
PCI DSS requires penetration testing at least **once per year** for both:
- **External penetration testing** — testing from outside your network perimeter
- **Internal penetration testing** — testing from inside your network (simulating an insider threat or attacker who has already gained a foothold)

### After Significant Changes
Beyond the annual requirement, penetration testing must also be performed after:
- Significant infrastructure upgrades or changes
- Major application changes or new deployments
- Changes to network architecture or segmentation

### Segmentation Testing (Important Addition)
If you use network segmentation to isolate your Cardholder Data Environment (CDE) from other networks (which is strongly recommended to reduce scope), you must also test that your segmentation controls actually work. This segmentation testing:
- Must be performed at least annually for most merchants
- Must be performed more frequently (every six months) for service providers
- Must attempt to breach the segmentation controls, not just verify firewall rules on paper

## What Must Be In Scope?

The penetration test scope must cover:

### Network Layer
- External perimeter of the CDE (all externally accessible systems)
- Internal network components within the CDE
- Firewall rules and access controls protecting the CDE
- Network segmentation controls (if used)

### Application Layer
PCI DSS requires testing at the application layer, not just the network layer. This includes:
- Web applications that handle cardholder data
- APIs that process or transmit card data
- Authentication mechanisms protecting CDE access

### Both Internal and External Perspectives
- **External test**: Simulates an attacker on the internet trying to reach your CDE
- **Internal test**: Simulates an attacker who is already inside your network (e.g., compromised employee workstation)

## Tester Qualifications

PCI DSS requires that penetration testing be conducted by a **qualified, independent tester**. Key requirements:

### Independence
- The tester must be independent of the systems being tested
- An IT administrator who manages the firewalls cannot test those same firewalls
- Can be an internal employee from a different team, or an external firm
- Internal testers must not have a conflict of interest

### Expertise
The tester must have demonstrated expertise in penetration testing methodologies. While PCI DSS doesn't mandate specific certifications, common credentials that demonstrate qualification include:

- **OSCP** (Offensive Security Certified Professional) — highly regarded, hands-on
- **CEH** (Certified Ethical Hacker)
- **GPEN** (GIAC Penetration Tester)
- **CREST** certifications — often required by UK/EU entities and some card brands

### Methodology
Testing must follow an industry-accepted methodology such as:
- PTES (Penetration Testing Execution Standard)
- OWASP Testing Guide (for web applications)
- NIST SP 800-115

## What Happens After Testing?

### Remediation Required
All exploitable vulnerabilities identified during penetration testing must be remediated. There is no option to simply "note" critical findings and continue.

### Retesting
After remediation, you must retest to verify that vulnerabilities have actually been fixed. Testing must continue until no exploitable vulnerabilities remain.

### Documentation
Retain penetration test reports, remediation evidence, and retest results. Your QSA will review this documentation during your compliance assessment.

## Penetration Testing vs. Vulnerability Scanning

These are different requirements often confused:

| Aspect | Penetration Testing | Vulnerability Scanning (ASV) |
|--------|--------------------|-----------------------------|
| Frequency | At least annually | Quarterly |
| Who performs it | Qualified tester (internal or external) | PCI SSC-approved Approved Scanning Vendor (ASV) |
| What it does | Actively exploits vulnerabilities | Identifies and catalogs vulnerabilities |
| Requirement | PCI DSS Req 11.3 | PCI DSS Req 11.3.2 |

Both are required — quarterly ASV scans are in addition to, not a replacement for, annual penetration testing.

## Summary

| Requirement | Frequency |
|------------|-----------|
| External penetration test | At least annually + after significant changes |
| Internal penetration test | At least annually + after significant changes |
| Segmentation testing | At least annually (every 6 months for service providers) |
| Tester qualifications | Independent, demonstrated expertise |
| Scope | Network + application layer, internal + external |
| Post-test | Remediate all exploitable findings + retest |

# Tokenization and PCI DSS Scope Reduction

**PCI DSS Version: v4.0.1 (current, June 2024)**

---

## What is Tokenization (from a PCI DSS Perspective)?

**Tokenization** is a scope reduction technique in which a sensitive Primary Account Number (PAN) is replaced by a surrogate value called a **token**. The token has no exploitable relationship to the original PAN — it cannot be mathematically reversed to derive the PAN without access to the token vault.

The token vault (or token service) maintains the mapping between tokens and the original PANs and must itself be a tightly controlled, PCI DSS-compliant system. However, every other system that previously handled PANs but now only handles tokens can potentially be removed from PCI DSS scope.

**PCI DSS Core Concept Reference:**
> "Tokenisation — replace PAN with a token; removes tokenised systems from CDE scope"
> — PCI DSS Scoping and Segmentation guidance (Req 3 and CDE scoping)

---

## How Tokenization Works in Practice

### Transaction Flow

1. **Card presented / entered** — the PAN enters your system (or a terminal)
2. **Token request** — the PAN is sent to the token service (either internal or a third-party tokenization service like Stripe, Braintree, or a payment gateway)
3. **Token issued** — the token service stores the PAN-to-token mapping in the token vault and returns a token (e.g., `tok_1234567890abcdef`)
4. **PAN discarded** — your systems discard the PAN; only the token is retained
5. **Token used for business processes** — your systems use the token for order management, recurring billing, reporting, etc.
6. **Detokenization for payment** — when a charge is needed, the token is sent to the token service, which returns the PAN (or charges the card directly), keeping the PAN within the controlled token vault environment

### Token Format

Tokens can be:
- **Format-preserving** — the token looks like a valid card number (same length, passes Luhn check) but is not a real PAN
- **Format non-preserving** — the token is obviously not a card number (e.g., a UUID or alphanumeric string)

PCI DSS does not specify which format to use, but format-preserving tokens are sometimes misclassified as real PANs; ensure your systems clearly distinguish tokens from PANs.

---

## How Tokenization Reduces PCI DSS Scope

Under PCI DSS scoping rules, a system is in scope for PCI DSS if it:
1. Stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), **OR**
2. Is connected to a system that does, without adequate segmentation

Tokenization removes real PANs from your downstream systems. Once tokenized:

| System Type | Before Tokenization | After Tokenization |
|------------|--------------------|--------------------|
| Order management system | In scope (stores PAN) | **Out of scope** (stores token only) |
| CRM / customer database | In scope (stores PAN) | **Out of scope** (stores token only) |
| Analytics / reporting systems | In scope (process PAN) | **Out of scope** (process token only) |
| Recurring billing system | In scope (stores PAN for re-charge) | **Out of scope** (stores token; detokenizes only at payment time) |
| E-commerce application | Partially in scope | **Reduced scope** (token service interaction defines scope boundary) |
| **Token vault / token service** | N/A | **In scope** (stores PANs; must be PCI DSS compliant) |

**Net effect**: Your CDE shrinks to the token vault and any systems directly involved in the initial card capture and tokenization exchange. All downstream systems that only ever see tokens are out of scope.

---

## What Tokenization Does NOT Eliminate

This is the critical point: **tokenization reduces scope significantly but does not eliminate all PCI DSS obligations.**

### Obligations That Remain Even with Tokenization

| Area | Explanation |
|------|-------------|
| **Point of card capture** | The system that initially receives the PAN (payment terminal, payment page, API endpoint) is still in scope until the PAN is handed off to the token service |
| **Token vault** | The token vault is fully in scope for PCI DSS — it stores real PANs and must meet all 12 requirements |
| **Token service provider** | If you use a third-party tokenization service, you must verify their PCI compliance (obtain their AOC) and manage the service provider relationship per Req 12.8 |
| **Network path of initial tokenization** | The network link between your card capture system and the token service is in scope |
| **Acquirer and card brand obligations** | You remain a merchant subject to your acquirer agreement and card brand rules |
| **SAQ/ROC requirement** | You still must complete an annual SAQ (or ROC if Level 1) even with tokenization |
| **ASV scanning** | Quarterly ASV scanning of external-facing systems still required |
| **Incident response plan** | Req 12.10 still applies |
| **Physical security** | Systems at the point of card capture must maintain physical security (Req 9) |

---

## Third-Party Tokenization Services vs. In-House Token Vaults

### Third-Party Tokenization (e.g., Stripe, Braintree, Adyen, etc.)

When you use a payment processor's tokenization:
- The token service is operated by the processor, who is responsible for PCI DSS compliance of the token vault
- You must obtain the processor's **Attestation of Compliance (AOC)** annually (Req 12.8.4)
- Your scope is reduced to the systems that invoke the processor's API and the network path to that API
- The processor's tokenization tokens are typically **not portable** — they can only be charged through that specific processor

### In-House Token Vault

If you build and operate your own token vault:
- The entire token vault is in scope and must meet all PCI DSS requirements
- This is operationally complex and typically only makes sense for large merchants or processors
- Requires strong encryption (Req 3.5), strict access controls (Req 7/8), HSM for key management (Req 3.6), and full audit logging (Req 10)

---

## Tokenization vs. Point-to-Point Encryption (P2PE)

Tokenization is often compared to P2PE — another major scope reduction technique:

| Feature | Tokenization | PCI-Validated P2PE |
|---------|-------------|-------------------|
| **Mechanism** | Replaces PAN with token | Encrypts PAN at point of capture in a validated device |
| **Scope reduction** | High — downstream systems out of scope | Very high — the P2PE-validated solution components are out of scope |
| **Card-present** | Works for both CP and CNP | Primarily card-present (POS terminals) |
| **SAQ reduction** | Depends on integration | SAQ P2PE (~33 controls) — the most reduced SAQ available |
| **Validation required** | No formal PCI SSC listing needed | Must use a PCI SSC-listed P2PE solution to get scope reduction |
| **Token portability** | Depends on implementation | N/A — no token is involved |

Many organisations use **both**: P2PE at the point of card capture plus tokenization for downstream storage and recurring billing.

---

## Practical Recommendations

1. **Use a third-party tokenization service** — building your own token vault adds complexity and scope; leveraging Stripe, Braintree, or a gateway's tokenization is more efficient for most merchants
2. **Obtain your provider's AOC annually** — required under Req 12.8.4 to evidence your service provider's compliance
3. **Map your data flows** — identify exactly where PANs enter your environment and ensure tokenization occurs at the earliest possible point
4. **Validate that tokens don't leak PANs** — check all logs, error messages, and debug outputs to ensure real PANs are never written to tokenized-system logs
5. **Determine your residual SAQ** — with good tokenization, many e-commerce merchants can qualify for SAQ A or SAQ A-EP; consult a QSA to confirm your reduced scope
6. **Do not conflate tokens with PANs** — tokens are not protected under PCI DSS; only PANs are. Treat tokens as sensitive business data, but they don't carry PCI obligations

---

## Summary

| Question | Answer |
|---------|--------|
| Does tokenization reduce PCI scope? | **Yes, significantly** — downstream systems storing only tokens are out of scope |
| Does tokenization eliminate all PCI requirements? | **No** — token vault, point of capture, and acquirer obligations remain |
| Does the token vault need to be PCI compliant? | **Yes** — if you operate it; if third-party, verify their AOC |
| Does tokenization eliminate the need for an SAQ? | **No** — you still must complete an annual SAQ or ROC |
| Can tokenization reduce which SAQ applies? | **Yes** — good tokenization can qualify you for a simpler SAQ (e.g., SAQ A-EP or SAQ A) |
| Is tokenization better than P2PE? | Different tools for different contexts; P2PE gives greater scope reduction for card-present; tokenization is essential for card-not-present and recurring billing |

---

> **Disclaimer:** This guidance is based on PCI DSS v4.0.1 (PCI SSC, June 2024). Scope reduction analysis must be validated by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA). Always verify against the official PCI DSS v4.0.1 standard at pcisecuritystandards.org.

# Tokenization and PCI DSS Scope Reduction

## What is Tokenization?

Tokenization is the process of replacing a sensitive Primary Account Number (PAN) — the card number — with a non-sensitive placeholder value called a "token." The token has no mathematical relationship to the real card number and cannot be reversed without access to the secure token vault where the mapping is stored.

For example, instead of storing `4111 1111 1111 1111` in your database, you store `tok_4x9f2a8b1c` or similar. The real card number lives only in the token vault, which is operated by you or a third-party token service.

## How Does Tokenization Reduce PCI DSS Scope?

PCI DSS applies to any system that stores, processes, or transmits cardholder data — specifically the Primary Account Number (PAN). When you implement tokenization:

- **Systems that only see tokens** are no longer storing or processing real PANs, so they can potentially be **removed from PCI DSS scope**
- Only the systems involved in the initial card capture and the token vault itself remain in scope
- Your order management, CRM, analytics, and billing systems that previously stored card numbers can now store tokens instead, removing them from PCI scope

This can dramatically shrink your Cardholder Data Environment (CDE) — the set of systems subject to PCI DSS requirements.

## What Remains In Scope?

Tokenization reduces scope but **does not eliminate** all PCI DSS requirements. The following remain in scope regardless of tokenization:

### 1. The Token Vault
The service or system that stores the mapping between tokens and real PANs is fully in scope for PCI DSS. The token vault must meet all applicable PCI DSS requirements — it's where the real card data lives.

### 2. Point of Card Capture
The system that first receives the card number before tokenization is in scope. This could be your payment terminal, your payment page, or your API endpoint. Until the PAN is tokenized, the system handling it is in scope.

### 3. The Network Path
The network communication between your card capture system and the token vault is in scope and must be protected (encrypted in transit, monitored, etc.).

### 4. Your Third-Party Token Service
If you use a payment processor or third-party tokenization service (like Stripe, Braintree, or a payment gateway), that service provider is in scope — meaning you must verify they are PCI compliant and maintain documentation of their compliance (their Attestation of Compliance, or AOC).

## Does Tokenization Eliminate All PCI Compliance Requirements?

**No.** Even with comprehensive tokenization, you still have PCI DSS obligations:

| Remaining Obligation | Why It Persists |
|---------------------|-----------------|
| Annual SAQ or ROC | You are still a merchant accepting card payments |
| Quarterly ASV scans | External vulnerability scanning still required |
| Token vault compliance | Must meet all PCI requirements |
| Acquirer/card brand agreements | Your merchant obligations don't change |
| Incident response plan | Still required under PCI DSS |
| Service provider management | Must verify compliance of your token service provider |

## Third-Party vs. In-House Tokenization

**Third-party tokenization** (e.g., using Stripe's tokens, Braintree's vault, etc.) is the most common approach:
- The processor runs the token vault
- You must obtain their PCI compliance certificate (AOC) annually
- Your scope is reduced to the integration points with their service

**In-house tokenization** is more complex:
- You are responsible for operating a PCI-compliant token vault
- Requires strong encryption, access controls, key management, and audit logging
- Only practical for large merchants who need token portability across processors

## Tokenization vs. Point-to-Point Encryption (P2PE)

Both reduce PCI scope but work differently:

- **Tokenization**: Replaces the PAN with a token; great for storage and recurring billing
- **P2PE**: Encrypts the PAN at the point of capture within a validated device; the encrypted data is unreadable until it reaches the processor; primarily useful for card-present transactions at POS terminals

Many organizations use both: P2PE at the point of sale plus tokenization for back-end storage.

## Practical Advice

1. **Use your payment processor's built-in tokenization** — it's the easiest path and leverages their PCI compliance
2. **Audit your data flows** — find every place a real PAN might be stored in logs, databases, or error messages; ensure tokenization happens as early as possible
3. **Don't confuse tokens with PANs** — tokens are not regulated data under PCI DSS, so they can be stored freely; however, your token service provider's compliance remains your responsibility to verify
4. **Confirm your reduced scope with a QSA** — a Qualified Security Assessor can validate whether your tokenization implementation actually achieves the scope reduction you expect
5. **Check your logs** — a very common mistake is that logs and error messages accidentally capture full PANs even when the primary storage is tokenized

## Bottom Line

Tokenization is one of the most effective tools to reduce PCI DSS scope and compliance costs. Done well, it can reduce the number of systems subject to PCI DSS from dozens or hundreds down to just a handful. However, it doesn't make you exempt from PCI DSS entirely — you still have merchant obligations, must protect the token vault, and must validate your compliance annually.

# TSA Cybersecurity Requirements for Natural Gas Pipeline Operators

## Applicable Directives

As a natural gas pipeline operator under TSA jurisdiction, you are subject to two primary Security Directive series, both of which apply to owners/operators of hazardous liquid and natural gas pipeline and LNG facilities designated as critical by TSA:

| Directive | Current Revision | Focus |
|-----------|-----------------|-------|
| **SD Pipeline-2021-01** | G (January 2026) | Immediate foundational measures: incident reporting, cybersecurity coordinator designation, baseline practices review |
| **SD Pipeline-2021-02** | F (latest) | Comprehensive Cyber Risk Management Program (CRMP): network segmentation, access controls, monitoring, patching, CIP, IRP, ADR, CAP |

> **Note**: TSA Security Directives are Sensitive Security Information (SSI). The summaries below are based on publicly available information. You should obtain and read the specific directive text provided to you by TSA.

---

## SD Pipeline-2021-01 (Revision G): Immediate Measures

This directive establishes the foundational, immediate cybersecurity requirements. All covered pipeline operators must:

### 1. Report Cybersecurity Incidents to CISA Within 24 Hours
Any cybersecurity incident that results in — or is reasonably likely to result in — operational disruption or unauthorised access to a Critical Cyber System (CCS) must be reported to CISA **within 24 hours of identification**.

**What qualifies as a reportable incident:**
- Unauthorised access to IT or OT systems
- Discovery of malware or ransomware on CCS
- Denial of service affecting operational capability
- Phishing or social engineering with confirmed system access

**How to report:**
- CISA 24/7 Operations Center: **1-888-282-0870**
- Email: **CISAgov@mail.dhs.gov**
- TSA must also be separately notified

**Critical rule**: Do NOT delay reporting while internal investigation is ongoing. The initial report can be based on limited information; updates follow as the investigation matures.

### 2. Designate a Cybersecurity Coordinator
You must designate a primary and backup **Cybersecurity Coordinator** who:
- Is available 24/7 (or has an available backup designee)
- Serves as the primary point of contact between your company, TSA, and CISA
- Coordinates internal cybersecurity incident response
- Oversees implementation of the Cybersecurity Implementation Plan (CIP)
- Ensures incidents are reported to CISA within required timelines

Coordinator contact information must be submitted to TSA via the designated TSA reporting system.

### 3. Review of Cybersecurity Practices
Conduct a review of current cybersecurity practices covering all systems and processes related to Critical Cyber Systems (CCS) — including access controls, monitoring, patching, incident response, network architecture, and third-party access — and identify any gaps. This review forms the baseline for your Cybersecurity Implementation Plan.

---

## SD Pipeline-2021-02 (Revision F): Comprehensive CRMP Requirements

This is the substantive directive that requires a full **Cyber Risk Management Program (CRMP)** with four major components:

### Component 1: Cybersecurity Implementation Plan (CIP)
The governing document describing how you will meet all CRMP requirements. It must be submitted to TSA for review and approval and must include:
- Leadership structure (Accountable Executive, Cybersecurity Coordinator)
- Complete CCS inventory
- Network architecture description
- Baseline cybersecurity measures for each of the four technical domains
- Incident detection and response procedures
- Annual review process

### Component 2: Incident Response Plan (IRP)
Documented procedures for detecting, responding to, and recovering from cybersecurity incidents. Must be tested annually — at least **two IRP objectives** must be tested each year. Typical test objectives include isolating IT from OT, testing backup restoration, and validating communication/escalation procedures.

### Component 3: Architecture Design Review (ADR)
An annual structured review of your IT/OT network architecture to identify gaps, vulnerabilities, and segmentation deficiencies. Must produce an updated network diagram, a findings report, and a remediation action plan.

### Component 4: Cybersecurity Assessment Plan (CAP)
A formal plan for assessing the effectiveness of your CRMP annually. CAP results must be reported to TSA annually.

---

## Four Technical Security Domains

The substantive directives require implementation across four technical domains:

| Domain | Key Requirements |
|--------|-----------------|
| **1. Network Segmentation** | IT/OT boundary enforced via firewalls, DMZ, or physical separation; no direct routable connections from corporate IT to OT/ICS without security controls; remote OT access only through DMZ or jump server |
| **2. Access Controls** | MFA for all remote access and privileged access to CCS; unique user accounts (no shared accounts); least privilege; PAM for OT admin accounts; vendor access via time-limited monitored sessions |
| **3. Continuous Monitoring** | OT-aware IDS/network monitoring; log collection from CCS; anomaly detection against OT baseline; alerting and escalation procedures |
| **4. Patch Management** | Risk-based patch SLAs; OT-specific patching process (vendor approval, non-prod testing); compensating controls for unpatchable legacy systems |

---

## Critical Cyber Systems (CCS) — Defining Your Scope

Your compliance programme centres on identifying your **Critical Cyber Systems** — systems whose compromise could cause:
- Operational disruption (inability to safely operate or control physical assets)
- Safety impact to employees, the public, or environment
- Environmental impact (uncontrolled release of natural gas)
- National security impact

CCS include both OT systems (SCADA, DCS, PLCs, RTUs, HMIs, safety instrumented systems) and IT systems that touch or interface with OT. The CCS boundary must be formally defined, documented, and kept current.

---

## 2024 NPRM: What's Coming

In November 2024, TSA published a **Notice of Proposed Rulemaking (NPRM)** that would convert the current Security Directive requirements into permanent federal regulations under 49 CFR. The comment period closed February 5, 2025. Key aspects:
- Formalises all current directive requirements as binding federal regulation
- Requires annual enterprise-wide cybersecurity evaluation using NIST CSF 2.0
- Aligns with CISA Cross-Sector Cybersecurity Performance Goals (CPGs)
- Final rule has not yet been published; current directives remain fully in force

---

## Immediate Action Items

If you have not already done so, your highest-priority actions are:

1. **Confirm designation**: Verify with TSA that your facility is formally designated as covered
2. **Designate your Cybersecurity Coordinator** and submit contact information to TSA
3. **Establish a CISA reporting pathway** — know how to reach CISA's 24/7 Operations Center
4. **Define your CCS inventory** — identify all OT and IT systems in scope
5. **Submit your CIP to TSA** for review and approval
6. **Test your IRP** — at least two objectives annually

---

*Disclaimer: This guidance is based on publicly available information about TSA Security Directives. TSA Security Directives contain Sensitive Security Information (SSI). Work directly with TSA, qualified legal counsel, and OT/ICS cybersecurity professionals to ensure compliance with the specific directives applicable to your operations.*

# TSA Cybersecurity Requirements for Natural Gas Pipeline Operators

## Overview

The Transportation Security Administration (TSA) has issued a series of Security Directives for pipeline operators following the Colonial Pipeline ransomware attack in May 2021. If your natural gas pipeline is under TSA jurisdiction — typically because TSA has designated your facility as critical infrastructure — you are subject to these mandatory cybersecurity requirements.

---

## Background: Why TSA Issued Pipeline Security Directives

Before May 2021, TSA's pipeline cybersecurity requirements were largely voluntary guidelines. The Colonial Pipeline incident, which caused significant fuel supply disruption across the eastern United States, prompted TSA to issue emergency Security Directives with mandatory requirements. TSA has issued and revised these directives multiple times since then.

---

## Key Requirements Under TSA Pipeline Security Directives

### 1. Cybersecurity Incident Reporting
Pipeline operators must report cybersecurity incidents to CISA (the Cybersecurity and Infrastructure Security Agency) within a specified timeframe — generally understood to be within 24 hours of identifying a significant incident. Incidents include things like ransomware attacks, unauthorised access to control systems, and denial of service affecting operations.

TSA and CISA both play roles here: TSA sets the requirement, CISA receives the reports and provides technical assistance.

### 2. Designation of a Cybersecurity Coordinator
You must designate an individual as your Cybersecurity Coordinator who is available around the clock to serve as the primary point of contact with TSA and CISA. A backup designee is also typically required so that 24/7 availability is maintained.

### 3. Review of Current Cybersecurity Practices
Covered operators must conduct a review of their existing cybersecurity practices to identify gaps relative to TSA requirements. This review forms the foundation for a compliance plan.

### 4. Cybersecurity Implementation Plan
TSA requires covered pipeline operators to develop and submit a plan describing how they will implement the required cybersecurity measures. This plan must be reviewed and approved by TSA. The plan typically covers:
- Network segmentation between IT and OT systems
- Access controls for critical systems
- Continuous monitoring capabilities
- Patch management processes

---

## Core Technical Requirements

TSA's pipeline security directives focus on protecting what are called "Critical Cyber Systems" — the operational technology (OT) and industrial control systems that control physical pipeline operations, as well as connected IT systems.

The four main technical areas are:

**Network Segmentation**: Separating your operational technology (OT) environment — SCADA systems, PLCs, control systems — from your corporate IT network. The goal is to prevent an attack on IT systems from spreading to operational systems that control the physical pipeline.

**Access Controls**: Implementing strong access controls including multi-factor authentication (MFA) for remote access to critical systems, limiting privileged access, and ensuring vendor/third-party access is properly controlled.

**Monitoring and Detection**: Implementing capabilities to detect cybersecurity threats and anomalies affecting your operational systems. This includes monitoring both IT and OT environments.

**Patch Management**: Keeping systems updated with security patches using a risk-based approach that accounts for the operational realities of OT environments (e.g., vendor approval requirements, limited maintenance windows).

---

## Incident Response Plan

Beyond the technical controls, TSA requires covered operators to have a documented Cybersecurity Incident Response Plan (CIRP or IRP). This plan outlines how your organisation will detect, respond to, and recover from cybersecurity incidents. The plan must be periodically tested.

---

## Compliance Programme

Covered operators are generally required to have an ongoing compliance programme that includes:
- Annual assessments of the effectiveness of cybersecurity measures
- Regular reviews of network architecture
- Submission of compliance documentation to TSA

---

## 2024 Rulemaking

TSA has proposed converting these Security Directives into permanent federal regulations through a Notice of Proposed Rulemaking (NPRM) published in late 2024. Until a final rule is published, the existing Security Directives remain the binding requirements.

---

## Next Steps

If you believe your pipeline is subject to TSA jurisdiction:
1. Contact TSA to confirm your designation status
2. Review the specific Security Directives applicable to your operations
3. Engage legal counsel familiar with transportation infrastructure regulations
4. Work with OT/ICS cybersecurity professionals to assess your current posture

The Security Directives are designated as Sensitive Security Information (SSI), so the full text is not publicly distributed, but TSA will provide the directives directly to covered entities.

# Cybersecurity Incident Response Plan (CIRP / IRP) — TSA Requirements

## What Is the IRP Under TSA Directives?

Under the TSA Security Directives (SD Pipeline-2021-02F for pipelines; SD 1580-21-01E for freight rail; SD 1582-21-01E for public transit/passenger rail), covered entities must develop and maintain a **Cybersecurity Incident Response Plan (CIRP)**, also referred to as an **Incident Response Plan (IRP)**.

The IRP is one of the four required components of the **Cyber Risk Management Program (CRMP)** — the comprehensive cybersecurity programme mandated by the substantive directives. It is a formally documented set of procedures for detecting, responding to, and recovering from cybersecurity incidents that affect **Critical Cyber Systems (CCS)**.

The IRP is not a standalone document in isolation — it must be consistent with and referenced within the entity's **Cybersecurity Implementation Plan (CIP)**, which is the master governing document submitted to TSA for approval.

---

## What Must the IRP Include?

The IRP must address all phases of incident response. TSA requires the following elements:

### 1. Roles and Responsibilities
- Defined roles for all personnel involved in incident response
- Identification of the Cybersecurity Coordinator as the primary incident response lead and CISA/TSA reporting contact
- Clear escalation paths including to executive leadership
- Identification of backup personnel for 24/7 coverage

### 2. Detection and Analysis Procedures
- How cybersecurity events are identified and triaged
- Criteria for escalating an event to a declared incident
- Integration with monitoring tools and Security Operations Centre (SOC) if applicable
- OT-specific detection considerations (e.g., anomaly detection from OT-aware monitoring tools)

### 3. Containment Procedures
- Procedures to contain an incident and prevent spread to additional systems
- Critically: procedures to **isolate IT from OT** under incident conditions — ensuring OT/ICS systems can continue to operate safely even if the IT environment is compromised
- Network isolation procedures (disabling cross-boundary connections, activating firewall rules)
- Procedures for isolating individual CCS from the broader network

### 4. Eradication and Recovery Procedures
- Steps to eliminate the root cause of the incident (removing malware, closing unauthorised access)
- System restoration procedures from verified clean backups
- Backup integrity verification — confirming that backup data is uncorrupted and restorable
- Return-to-operations procedures following incident remediation

### 5. Communication Procedures
- **CISA reporting**: Procedures to report to CISA within **24 hours of identification** of a cybersecurity incident (1-888-282-0870 or CISAgov@mail.dhs.gov)
- **TSA notification**: Separate notification to TSA
- Internal escalation: Executive leadership, Board (if applicable), Legal, PR
- External stakeholders: Regulators, customers, vendors as appropriate
- Documentation of all communications during the incident

### 6. Post-Incident Review
- Mandatory post-incident review ("lessons learned") process following any declared incident
- Timeline for completing the review
- Process for updating the IRP based on findings
- Documentation requirements for post-incident reviews

### 7. Third-Party and OT Vendor Coordination
- Procedures for engaging OT/ICS vendors during incidents (vendors may need to be involved in system restoration)
- Third-party incident response firm engagement procedures
- Procedures for revoking third-party access during an incident

---

## Annual Testing Requirement

This is one of the most operationally significant requirements: covered entities must **test at least two IRP objectives annually**.

### What Counts as IRP Testing?
Testing must be structured, documented exercises — not theoretical reviews. TSA expects evidence that the procedures actually work. Common test formats include:
- **Tabletop exercises**: Walking through a simulated scenario with key personnel
- **Functional exercises**: Actually performing specific procedures (e.g., activating network isolation, restoring from backup)
- **Full-scale simulations**: Simulating a full incident from detection through recovery

### Required Test Objectives (at least 2 per year)
Typical tested IRP objectives include:

| Test Objective | What It Validates |
|---------------|-------------------|
| **IT/OT isolation under incident conditions** | Can you safely disconnect IT from OT without disrupting OT operations? Do the procedures work as designed? |
| **Backup data integrity and restoration** | Are backups intact, accessible, and restorable? How long does restoration take? |
| **Simulated ransomware containment** | Can you identify, isolate, and begin recovery from a ransomware event on CCS? |
| **Communication and escalation validation** | Do personnel know their roles? Are contact details current? Can you reach CISA and TSA? |
| **OT vendor coordination** | Can you engage OT vendors under incident conditions? Are escalation procedures effective? |

### Testing Evidence Requirements
You must retain evidence of each test. Evidence should include:
- Date of exercise
- Scenario description
- List of participants
- Objectives tested
- Findings/gaps identified
- Corrective actions assigned (with owners and due dates)
- Sign-off by Cybersecurity Coordinator or Accountable Executive

This evidence is subject to TSA review and must be available during any compliance assessment.

---

## IRP vs. CISA 24-Hour Reporting — Critical Distinction

The IRP governs your internal response process. The 24-hour CISA reporting requirement is a **separate, parallel obligation** — it is triggered at the moment of incident identification and must not wait for the IRP process to conclude.

**The rule**: Report to CISA within 24 hours of identifying a cybersecurity incident — even if your investigation is incomplete and you have limited information. You can provide updates as the investigation progresses.

**Contact CISA at**: 1-888-282-0870 or CISAgov@mail.dhs.gov (24/7 Operations Center)

---

## IRP as Part of the CIP/COIP

The IRP does not stand alone — it is incorporated into or referenced by the **Cybersecurity Implementation Plan (CIP)** (or the Cybersecurity Operational Implementation Plan — COIP — under some directive revisions). The CIP must be submitted to TSA for approval. TSA will review the IRP as part of that approval process.

If your IRP is modified significantly (e.g., following a post-incident review or after testing reveals gaps), updates must be reflected in your CIP and may require resubmission to TSA.

---

## Summary Table

| IRP Element | Requirement |
|-------------|-------------|
| Roles and responsibilities | Required |
| Detection and analysis procedures | Required |
| Containment procedures (including IT/OT isolation) | Required |
| Eradication and recovery procedures | Required |
| CISA reporting procedure (24-hour) | Required |
| TSA notification procedure | Required |
| Post-incident review process | Required |
| Third-party/vendor coordination | Required |
| Annual testing | At least 2 objectives per year |
| Testing evidence retention | Required (date, scenario, participants, findings, corrective actions) |
| Alignment with CIP/COIP | Required |

---

*Disclaimer: This guidance is based on publicly available information about TSA Security Directives. The full directive text is Sensitive Security Information (SSI). Work directly with TSA, qualified legal counsel, and OT/ICS cybersecurity professionals to ensure compliance with the specific directives applicable to your operations.*

# Cybersecurity Incident Response Plan (CIRP) for TSA Purposes

## What Is a CIRP?

A Cybersecurity Incident Response Plan (CIRP) — sometimes called an Incident Response Plan (IRP) — is a documented set of procedures that defines how an organisation detects, responds to, contains, and recovers from cybersecurity incidents. For organisations subject to TSA Security Directives (pipeline operators, freight railroads, passenger rail and transit agencies), a CIRP is a mandatory compliance requirement.

The CIRP is part of the broader Cyber Risk Management Program (CRMP) that TSA requires covered critical infrastructure operators to establish and maintain.

---

## Why TSA Requires a CIRP

TSA's pipeline and surface transportation Security Directives, issued starting in 2021, require covered operators to have formal incident response capabilities because:

- Cyberattacks on operational technology (OT) systems — like SCADA and industrial control systems — can cause physical safety consequences and service disruptions
- Without a pre-planned response, organisations typically respond more slowly and less effectively
- TSA and CISA need to be notified promptly when incidents occur so they can provide assistance and assess sector-wide risk

---

## What a TSA-Aligned CIRP Must Include

While the precise requirements vary by the specific Security Directive applicable to your organisation, a TSA-compliant CIRP generally must address:

### Core Elements

**1. Scope and Applicability**
Defines which systems are covered — primarily "Critical Cyber Systems" (OT, ICS, SCADA, and connected IT systems) — and under what circumstances the plan is activated.

**2. Roles and Responsibilities**
- Incident Response Team structure
- Cybersecurity Coordinator role (required by TSA — this person is your primary contact with TSA and CISA)
- Leadership escalation paths
- Backup personnel to ensure 24/7 response capability

**3. Incident Detection and Classification**
- How cybersecurity events are identified
- Criteria for classifying severity levels
- Escalation triggers (what turns an "event" into a declared "incident")

**4. Containment Procedures**
Steps to stop the spread of an incident, including:
- Isolating affected systems
- Separating IT from OT networks under emergency conditions
- Disabling compromised accounts and access paths

**5. Eradication and Recovery**
- Removing malware or unauthorised access
- Restoring systems from clean backups
- Verifying system integrity before returning to operations

**6. Regulatory Notification Requirements**
- Procedures for notifying CISA within the required timeframe (generally understood to be within 24 hours for significant incidents)
- TSA notification procedures
- Internal escalation to executive leadership

**7. Post-Incident Review**
Process for conducting a lessons-learned review after each significant incident, and for updating the CIRP based on findings.

**8. Vendor and Third-Party Coordination**
How you engage OT/ICS vendors, IT vendors, and third-party incident response firms during an incident.

---

## Testing Requirements

TSA Security Directives require that covered operators periodically test their incident response plans. The purpose of testing is to verify that procedures actually work before a real incident occurs.

### How Often?
Testing is generally required at least annually. TSA's directives typically require testing of specific objectives — organisations need to test enough of the plan to demonstrate it is functional.

### What Types of Testing Count?
- **Tabletop exercises**: Discussion-based simulations where participants walk through how they would respond to a scenario
- **Functional exercises**: Actually executing specific procedures, such as isolating OT from IT or restoring from backup
- **Full-scale exercises**: Comprehensive simulations involving multiple teams

### What Should Be Tested?
Common test objectives include:
- Ability to isolate OT systems from IT systems in an emergency
- Backup data restoration capability
- Escalation and notification procedures (including ability to reach CISA and TSA)
- Vendor coordination procedures

### Documentation
Evidence of testing must be retained and may be reviewed by TSA. Documentation should include the date, scenario, participants, what was tested, what gaps were found, and what corrective actions were taken.

---

## Relationship to Other CRMP Requirements

The CIRP does not stand alone — it is one component of a larger Cyber Risk Management Program that also includes:
- A Cybersecurity Implementation Plan (CIP) — the master compliance document submitted to TSA for approval
- Network architecture reviews
- Cybersecurity assessments

The CIRP must be consistent with and integrated into the CIP.

---

## Key Takeaway on Reporting

One of the most important aspects of TSA incident response requirements is the regulatory reporting obligation. When a significant cybersecurity incident occurs affecting critical cyber systems, you must notify CISA promptly — typically within 24 hours. This is a mandatory obligation separate from your internal response process. You should not wait for your investigation to conclude before reporting; initial reports can be updated as more information becomes available.

# Implementing Network Segmentation for Legacy OT/SCADA Environments — TSA Compliance Approach

## The TSA Requirement

Under TSA Security Directives (SD Pipeline-2021-02F for pipelines; SD 1580-21-01E for freight rail; SD 1582-21-01E for public transit/passenger rail), **Network Segmentation** is Domain 1 of the four required technical security domains. The requirement is:

> Develop and implement network segmentation policies and controls to ensure the OT system can continue to safely operate if the IT system is compromised, and vice versa.

Specific implementation requirements include:
- A formal network segmentation policy
- A documented and enforced IT/OT boundary (firewall rules, DMZ architecture, or physical separation)
- No direct routable connections between corporate IT and OT/ICS networks without security controls
- Remote access to OT must route through a demilitarised zone (DMZ) or jump server
- All segmentation exceptions documented with business justification

**The challenge you face is real and common**: Legacy SCADA and ICS systems were often designed in an era when network connectivity was minimal or non-existent, and they were never architected with firewall traversal or network segmentation in mind. Many use proprietary protocols, have no authentication capabilities, cannot be patched, and may fail unpredictably if network traffic is disrupted.

---

## Practical Implementation Strategy for Legacy OT Environments

The key principle: **TSA does not require a rip-and-replace of legacy OT systems**. It requires that effective segmentation controls exist at the boundary, and that compensating controls are in place for systems that cannot be fully hardened internally.

### Step 1: Establish Your Critical Cyber System (CCS) Inventory and Architecture Map

Before implementing segmentation, you must have an accurate picture of what you are segmenting.

- **Document all OT assets**: Every PLC, RTU, HMI, historian, SCADA server, engineering workstation — including legacy systems with unknown communication patterns
- **Map all network connections**: Including undocumented connections, dial-up connections, vendor remote access paths, wireless links, and any IT-to-OT data flows
- **Identify communication dependencies**: Which OT systems communicate with which? Which OT systems pull data from or push data to IT systems? What protocols are used?

This is the foundation of your Architecture Design Review (ADR) — one of the four required CRMP components. An accurate, current network diagram is mandatory evidence for TSA assessors.

**Common discovery finding in legacy environments**: Communication paths that nobody knew existed — old modems, undocumented cross-connections, historian servers that bridge IT and OT, or vendor jump hosts placed directly on OT networks years ago.

### Step 2: Classify Systems by Zone and Risk

Not all OT systems are equal. Use the Purdue Model (or IEC 62443 zone/conduit model) as a structuring framework:

| Zone | Examples | Segmentation Goal |
|------|---------|------------------|
| **Level 0-1** (Field devices) | PLCs, RTUs, sensors | Maximum isolation; no direct IT access |
| **Level 2** (Control) | HMIs, DCS workstations | Isolated OT zone; limited access via DMZ |
| **Level 3** (Operations) | SCADA servers, historians, engineering workstations | OT DMZ or semi-isolated zone; controlled data exchange with IT |
| **Level 3.5** (DMZ) | Data replication servers, jump hosts, proxy servers | Buffer zone between IT and OT |
| **Level 4** (IT/Business) | Corporate network, ERP, email | Standard IT environment; no direct OT access |

Legacy SCADA systems typically sit at Level 2-3. The segmentation controls are implemented at the boundary (Level 3.5 / DMZ), not necessarily within the legacy systems themselves.

### Step 3: Implement Boundary Controls at the IT/OT Interface

This is where most of the segmentation work happens with legacy OT — controlling what crosses the boundary rather than hardening legacy systems internally.

#### Option A: Firewall-Based Segmentation with DMZ
The most common approach. Deploy an industrial-grade firewall between IT and OT networks, with a DMZ in between.

- **Firewall placement**: Dedicated OT firewall (e.g., Palo Alto, Fortinet, Cisco) at the IT/OT boundary
- **DMZ zone**: Create an intermediate zone where data exchange servers, historian replicas, and jump hosts reside
- **Allow-list approach**: Firewall rules permit only explicitly required traffic; deny all by default
- **Protocol filtering**: Use deep packet inspection (DPI) capable of understanding industrial protocols (Modbus, DNP3, PROFINET, OPC-UA) to inspect and filter OT traffic

**Evidence for TSA**: Current firewall ruleset; network topology diagram showing DMZ; rule review records.

#### Option B: Data Diodes / Unidirectional Security Gateways
For the most sensitive legacy OT environments where even firewall-based connectivity is too risky, **data diodes** enforce one-way data flow at the hardware level.

- Data flows from OT to IT (e.g., historian data, operational data), but it is **physically impossible** for data to flow from IT to OT
- Eliminates the risk of IT-side compromise reaching OT entirely
- Vendors: Waterfall Security, Owl Cyber Defense (Perle), Forcepoint
- **Best for**: Legacy systems at Level 0-2 where no IT-to-OT commands are needed; read-only data replication use cases

**TSA perspective**: Data diodes are explicitly recognised as valid segmentation mechanisms. They provide the strongest segmentation evidence.

#### Option C: Application-Level Proxies and OPC-UA Bridging
For legacy SCADA using OPC-DA (old COM/DCOM-based OPC) or proprietary protocols that need to share data with IT:

- Deploy an **OPC-UA aggregation server** in the DMZ that translates OPC-DA to OPC-UA
- IT systems consume OPC-UA data from the DMZ server; they never connect directly to OT
- Eliminates dangerous DCOM exposure across the IT/OT boundary

### Step 4: Control Remote Access Into OT

Legacy environments often have the most problematic remote access situation — vendor modem connections, VPNs that terminate directly in OT, or shared credentials used by multiple vendors.

**TSA requirement**: Remote access to OT must go through a DMZ or jump server. MFA is required for all remote access to Critical Cyber Systems.

**For legacy OT environments**:
- Deploy a **dedicated jump server** (bastion host) in the OT DMZ; all remote access terminates at the jump server, never directly at OT devices
- Implement **MFA on the jump server** — even if legacy OT devices cannot support MFA themselves, MFA is enforced at the access layer
- Replace vendor modem connections with managed remote access solutions (e.g., Claroty SRA, Bayshore Networks, Tosibox)
- Implement **time-limited, session-recorded vendor access** — vendors connect only when needed, sessions are monitored and logged
- Disable or physically remove modems and legacy dial-up connections that are no longer actively used

### Step 5: Address Compensating Controls for Systems That Cannot Be Segmented Cleanly

Some legacy OT systems will have legitimate business reasons why a clean segmentation cannot be achieved immediately (e.g., a SCADA master that currently communicates directly with both field devices and a corporate reporting system). TSA recognises this reality but requires:

1. **Document the exception**: What is the system? Why can segmentation not be achieved? What is the residual risk?
2. **Implement compensating controls**: Options include:
   - Network-level allow-listing (only specific IP/port combinations permitted)
   - OT-aware intrusion detection monitoring the exception traffic
   - Enhanced logging and alerting on the exception connection
   - Physical access controls limiting who can reach the system
   - Accelerated migration timeline to achieve full segmentation
3. **Include in your remediation plan**: Your ADR must document findings and a remediation action plan with timelines. Exceptions without a remediation path are a compliance risk.

---

## OT-Aware Monitoring as a Complement to Segmentation

Even with segmentation controls in place, TSA requires **continuous monitoring** (Domain 3) of OT environments. For legacy SCADA, passive OT monitoring tools are strongly preferred because active scanning can disrupt industrial protocols.

**Recommended tools for passive OT monitoring**:
- Claroty
- Dragos Platform
- Nozomi Networks
- Armis
- Microsoft Defender for IoT

These tools perform passive network traffic analysis, build an asset inventory automatically, establish a baseline of normal OT communications, and alert on anomalies — without sending any active queries that could disrupt legacy PLCs or RTUs.

---

## Documentation Required for TSA Compliance

| Document | What It Must Show |
|----------|------------------|
| **Network topology diagram** | Current and accurate; shows IT zone, OT zone, DMZ, all firewall positions, all connections between zones |
| **Firewall ruleset documentation** | All rules at the IT/OT boundary; evidence of allow-list approach; rule review date |
| **CCS inventory** | All legacy OT systems identified and classified as CCS or not |
| **Segmentation exceptions log** | Any exceptions to full segmentation, with business justification and compensating controls |
| **ADR findings and remediation plan** | Annual review findings; open items; remediation timelines |
| **Remote access policy** | How vendor and employee remote access to OT is managed |

---

## Implementation Prioritisation

If you are starting from a flat or poorly segmented network, prioritise in this order:

1. **Immediate**: Identify and document all IT-to-OT connections (you cannot segment what you have not mapped)
2. **Short-term (30-90 days)**: Deploy firewall at IT/OT boundary; terminate any direct routable connections between corporate IT and OT; establish jump server for remote access
3. **Medium-term (90-180 days)**: Implement MFA on jump server; deploy OT-aware monitoring; document and remediate or justify all segmentation exceptions
4. **Ongoing**: Annual ADR; IRP testing of IT/OT isolation procedure; update network diagrams when architecture changes

---

*Disclaimer: This guidance is based on publicly available information about TSA Security Directives and OT cybersecurity best practices. TSA Security Directives are Sensitive Security Information (SSI). Work directly with TSA, qualified legal counsel, and OT/ICS cybersecurity professionals for your specific compliance situation.*

# Implementing IT/OT Network Segmentation for Legacy SCADA Systems

## The Challenge

You are correct that TSA Security Directives require network segmentation between IT and OT networks. The challenge you face is common across critical infrastructure: legacy SCADA and industrial control systems (ICS) were often designed and deployed before network security was a primary concern. Many of these systems:

- Use proprietary or older protocols (Modbus, DNP3, legacy OPC-DA)
- Run outdated operating systems that cannot be patched
- Were not designed with authentication or encryption in mind
- May behave unpredictably or fail if network conditions change
- Have vendor support requirements that constrain what changes can be made

The good news is that TSA's segmentation requirement focuses on the boundary between IT and OT — it does not require you to rebuild your SCADA systems from scratch. The practical approach is to implement segmentation controls at the boundary layer while leaving legacy systems largely intact.

---

## Core Principle: Protect the Boundary, Not Just the Asset

For legacy OT environments, the primary strategy is to:

1. **Establish a clear IT/OT boundary** with security controls at that boundary
2. **Control all traffic crossing the boundary** (ideally using an allow-list approach)
3. **Implement compensating controls** for systems that cannot be hardened internally
4. **Monitor the OT environment passively** for anomalies without disrupting legacy systems

---

## Practical Implementation Approaches

### 1. Firewall-Based IT/OT Segmentation with a DMZ

The most practical starting point for most organisations is deploying a dedicated industrial firewall at the IT/OT boundary, creating a demilitarised zone (DMZ) as a buffer between the two environments.

**How it works**:
- Corporate IT network connects to the DMZ
- OT/SCADA network connects to the DMZ from the other side
- No direct routable connections exist between IT and OT
- Only explicitly approved traffic flows through firewall rules (allow-list approach)
- Data exchange between IT and OT happens via proxy servers or data aggregation servers placed in the DMZ

**For legacy SCADA**: Your SCADA systems remain on the OT side of the firewall. They don't need to change — the segmentation is enforced at the boundary, not on the SCADA system itself.

### 2. Data Diodes for One-Way Data Flows

If your primary need is getting data out of the OT environment (e.g., sending operational data to a corporate historian or reporting system) without allowing anything to flow back in, **data diodes** provide the strongest possible segmentation.

Data diodes are hardware devices that physically enforce one-way data flow — it is impossible at the hardware level for data to travel from the IT side to the OT side. This eliminates the risk of an IT compromise affecting OT systems.

Vendors include Waterfall Security Solutions and Owl Cyber Defense.

**Best for**: Read-only data replication use cases; environments where the OT/SCADA systems require maximum isolation.

### 3. Jump Servers / Bastion Hosts for Remote Access

Legacy SCADA environments often have ad hoc remote access paths — vendor modems, VPN tunnels that terminate directly in OT, or shared credentials. TSA's directives require that all remote access to OT go through a controlled pathway.

**The solution**: Deploy a dedicated jump server (bastion host) in your OT DMZ. All remote access — whether by employees or vendors — terminates at the jump server. Nobody connects directly to OT devices.

This also allows you to:
- Enforce multi-factor authentication (MFA) at the jump server, even if legacy OT devices cannot support MFA themselves
- Record and monitor all remote sessions
- Implement time-limited access for vendors
- Centralise access control management

### 4. OPC Protocol Bridging

Many older SCADA systems use OPC-DA (the older, COM/DCOM-based version of OPC), which has significant security problems and was not designed for cross-network use. The modern replacement is OPC-UA, which includes authentication and encryption.

**For legacy systems**: Deploy an OPC-UA aggregation server in the DMZ that connects to the OPC-DA environment on one side and presents OPC-UA data to IT systems on the other. IT consumers only see the OPC-UA interface in the DMZ — they never have direct network access to the legacy SCADA systems.

---

## Handling Systems That Cannot Be Cleanly Segmented

Some legacy systems will have legitimate reasons why a clean segmentation cannot be immediately achieved:
- A SCADA system that currently communicates with both field devices and corporate reporting on the same network
- A historian server that has network connections in both IT and OT zones
- A vendor that requires direct connectivity to OT systems for support

For these situations:
1. **Document the exception and the business reason** for why clean segmentation is not yet possible
2. **Implement compensating controls**: Enhanced monitoring, network-level allow-lists restricting traffic to only what is absolutely required, time-limited vendor access windows
3. **Create a remediation plan with a target date** for achieving full segmentation — regulators generally accept that legacy environments take time to remediate, but expect a documented plan

---

## Passive OT Monitoring

A key consideration for legacy SCADA: **do not use active network scanning** in your OT environment. Active scanning (like the kind used in IT security tools) can send unexpected packets to PLCs and RTUs that may cause them to hang, crash, or behave erratically.

Use **passive OT monitoring tools** instead. These tools listen to network traffic without sending any queries to OT devices. They build asset inventories and detect anomalies from what they observe. Examples include tools from vendors like Claroty, Dragos, and Nozomi Networks, which are designed specifically for industrial environments.

---

## Documentation and Compliance Evidence

For TSA compliance, you need to be able to demonstrate that segmentation is in place and effective. Key documentation includes:
- Current network topology diagrams showing IT zone, OT zone, and DMZ
- Firewall ruleset documentation showing the allow-list approach
- Inventory of all OT/SCADA systems and their network connections
- Documentation of any exceptions with compensating controls
- Records of annual architecture reviews

---

## Summary

The practical approach for legacy SCADA environments is: **segment at the boundary, monitor passively, control remote access tightly, and document compensating controls for gaps.** You do not need to replace legacy systems to achieve TSA compliance — you need to ensure that robust controls exist at the interface between IT and OT, and that you have visibility into what is happening in your OT environment.

# TSA Cybersecurity Regulations and Small Regional Airports

## Short Answer

TSA cybersecurity requirements may apply to your airport, but applicability depends on whether TSA has specifically designated your airport as a covered entity — it is not automatic based on size or sector membership alone. Small regional airports are not automatically exempt, but the primary substantive directives are currently focused on larger, higher-risk aviation entities. Here is the full picture.

---

## How TSA Determines Coverage: Designation-Based, Not Automatic

This is one of the most important points about TSA cybersecurity directives: **TSA designates covered entities individually**. Not every operator in a sector is automatically subject to the mandatory requirements. Coverage depends on:

- Whether TSA has formally notified your airport that it is subject to a specific Security Directive
- Your airport's risk profile and strategic significance
- Your passenger volume, cargo volume, and role in the national aviation system
- Whether TSA has conducted an assessment and determined your operations present a higher cybersecurity risk

**Action required**: If you have not received a formal notification from TSA designating your airport as a covered entity under a specific Security Directive, you should contact TSA's aviation security programme to understand your status.

---

## Aviation Cybersecurity: A Different Directive Series

The pipeline, freight rail, and transit Security Directives described in the SD Pipeline-2021 and SD 1580/1582 series do **not** apply to airports. Aviation has its own Security Directive and Emergency Amendment series.

TSA has issued Security Directives and Emergency Amendments specifically for:
- **Airports** (airport operators)
- **Aircraft operators** (airlines and cargo carriers)

These aviation-specific directives address cybersecurity requirements including:
- Network segmentation and access controls
- Incident reporting to CISA
- Designation of a Cybersecurity Coordinator
- Cybersecurity implementation plans

The specific directive text is Sensitive Security Information (SSI), and TSA provides it directly to covered entities.

---

## Airport Categories Relevant to Security Classification

TSA classifies airports under a separate risk-based framework for physical security purposes. The primary classification system for aviation security uses **airport categories** based on enplanement volumes and security risk:

| Category | General Profile |
|----------|----------------|
| **Category X** | Large hub airports; highest security requirements |
| **Category I** | Large and medium hub airports |
| **Category II** | Smaller hub airports |
| **Category III** | Non-hub airports with scheduled commercial service |
| **Category IV** | Small non-hub airports; lowest volume commercial service |
| **General Aviation** | Non-commercial; private/corporate aviation |

Small regional airports typically fall into **Category III or Category IV**, depending on whether they have scheduled commercial passenger service and their annual enplanement numbers.

**Cybersecurity implication**: TSA's mandatory cybersecurity directives for aviation have generally been applied first to higher-category (Category X and Category I) airports that represent greater risk to the national aviation system. However, this does not mean lower-category airports are permanently exempt — TSA's risk-based approach can extend coverage to lower-category airports if risk warrants it, and the 2024 NPRM signals an intent to broaden mandatory requirements across sectors.

---

## The 2024 NPRM and Future Coverage

In November 2024, TSA published a **Notice of Proposed Rulemaking (NPRM)** to convert existing Security Directive requirements into permanent federal regulations under 49 CFR. Key points relevant to your situation:

- The NPRM primarily addressed pipelines, freight rail, and passenger rail/transit sectors for the CRMP requirements
- Bus-only operators (incident reporting only) were included for the first time
- Aviation was not the primary focus of this NPRM, but aviation cybersecurity requirements continue to evolve through the separate Security Directive and Emergency Amendment process
- The comment period closed February 5, 2025; the final rule has not yet been published

As regulations mature, it is reasonable to expect that mandatory cybersecurity requirements will expand to more aviation entities over time, including smaller airports.

---

## What Small Regional Airports Should Do Now

Even if you are not currently a designated covered entity, proactive steps are advisable:

### 1. Confirm Your Status With TSA
Contact TSA's Office of Security Policy and Industry Engagement to understand whether your airport is currently subject to any active Security Directives or Emergency Amendments related to cybersecurity.

### 2. Understand Your Airport's Critical Cyber Systems
Regardless of regulatory status, identify your systems whose compromise could affect operations — access control systems, airport operations systems, fuelling systems, baggage systems, and any systems connected to air traffic control or airline operations.

### 3. Implement Baseline Cybersecurity Practices
Even without a mandate, CISA's Cross-Sector Cybersecurity Performance Goals (CPGs) — referenced in TSA's 2024 NPRM — provide a practical baseline for critical infrastructure operators of all sizes. Key baseline practices include:
- MFA for remote access and privileged accounts
- Network segmentation between operational and corporate systems
- Incident response planning and regular testing
- Patch management for all systems

### 4. Establish a CISA Reporting Pathway
Even before any formal designation, understanding how to report cybersecurity incidents to CISA is good practice. CISA's 24/7 Operations Center is reachable at **1-888-282-0870** or **CISAgov@mail.dhs.gov**.

### 5. Monitor TSA Regulatory Developments
Follow TSA announcements and the final rule rulemaking process. If the rule is finalised and coverage is expanded, you will want lead time to implement required controls.

---

## Summary

| Question | Answer |
|----------|--------|
| Are all airports automatically covered by TSA cybersecurity directives? | No — TSA designates covered entities individually |
| Which airports are most likely covered today? | Larger, higher-risk airports (Category X, Category I) |
| Which directive series applies to airports? | Aviation-specific TSA Security Directives/Emergency Amendments (separate from pipeline/rail series) |
| Where does a small regional airport typically fall? | Category III or Category IV |
| Is coverage likely to expand to smaller airports? | Yes, over time — the trend is toward broader coverage |
| What should a small regional airport do now? | Confirm status with TSA; implement baseline cybersecurity practices; monitor regulatory developments |

---

*Disclaimer: This guidance is based on publicly available information about TSA's security framework. TSA Security Directives are Sensitive Security Information (SSI). Contact TSA directly for authoritative guidance on your airport's designation status.*

# TSA Cybersecurity Regulations and Small Regional Airports

## Do TSA Cybersecurity Regulations Apply to Your Airport?

The short answer is: it depends on your airport's classification and whether TSA has specifically identified your airport as subject to its cybersecurity requirements. TSA's cybersecurity requirements are generally tiered by risk and size, with the most stringent mandatory requirements applying to larger, higher-risk airports.

---

## How TSA Regulates Airport Security

TSA regulates airport security under the Aviation and Transportation Security Act (ATSA) and through a series of Security Directives and Emergency Amendments issued to specific categories of regulated parties. TSA's security requirements — including cybersecurity requirements — are generally applied based on the airport's classification within the national aviation system.

### Airport Security Categories

TSA classifies commercial service airports into security categories based primarily on annual passenger enplanements and risk. The general classifications are:

- **Category X**: The largest and highest-risk airports in the U.S. (major hub airports like LAX, JFK, O'Hare). These face the most stringent security requirements.
- **Category I**: Large hub airports
- **Category II**: Medium hub airports
- **Category III**: Small hub airports with scheduled commercial service
- **Category IV**: Smallest commercial service airports

There is also a **general aviation** category for non-commercial airports.

As a small regional airport, you likely fall into **Category III or Category IV**, or possibly the general aviation category if you do not have scheduled commercial passenger service.

---

## Cybersecurity-Specific Requirements for Airports

TSA has issued cybersecurity-focused Security Directives for the aviation sector. These directives — which are separate from the pipeline and surface transportation directives that received significant attention following the 2021 Colonial Pipeline attack — address requirements such as:

- Designation of a Cybersecurity Coordinator
- Cybersecurity incident reporting to CISA
- Network access controls
- Development of a cybersecurity incident response plan

However, these requirements have generally been applied first to **higher-risk, higher-category airports**. Mandatory cybersecurity directives have been issued to the larger hub airports (Category X and Category I), as these represent the greatest risk to the national aviation system.

---

## Does This Apply to Small Regional Airports?

**If you are a Category III or Category IV airport**, your situation depends on:

1. **Whether TSA has specifically notified your airport** that it is subject to a particular Security Directive or Emergency Amendment. TSA issues these notifications directly to covered entities. If you have not received such a notification, you may not currently be under a mandatory cybersecurity directive.

2. **Whether you have scheduled commercial service**. Airports with scheduled commercial passenger service under TSA oversight have more security obligations than general aviation airports.

3. **Your specific risk profile**. TSA can designate airports for coverage based on risk factors beyond just size.

**Important**: The absence of a current mandate does not mean you are permanently exempt. TSA's cybersecurity requirements have been expanding, and the trend across transportation sectors is toward broader coverage.

---

## Practical Guidance for Small Regional Airports

Even if you are not currently subject to mandatory TSA cybersecurity directives, there are important reasons to implement baseline cybersecurity practices:

**CISA Voluntary Resources**: CISA provides free cybersecurity resources for critical infrastructure operators of all sizes, including vulnerability assessments and cybersecurity performance goals that provide a practical baseline.

**Proactive TSA Engagement**: Contact TSA's Transportation Security Administration's aviation security division to understand whether your airport has been designated as covered under any active Security Directives, and to stay informed about evolving requirements.

**Common Sense Baseline**: Regardless of regulatory requirements, airports should protect systems that could affect safety and operations — access control systems, perimeter security systems, communications systems, and any operational technology.

---

## Summary

Small regional airports (Category III, Category IV, or general aviation) are generally not currently subject to the same mandatory cybersecurity directives that apply to large hub airports. However:

- TSA designates covered entities individually, so you should confirm your status directly with TSA
- TSA cybersecurity requirements are expanding across the aviation sector
- Voluntary compliance with cybersecurity best practices is advisable regardless of mandatory requirements
- If you receive scheduled commercial service, you likely have more security obligations than a general aviation airport

Contact TSA directly to determine whether your airport is currently subject to any active cybersecurity Security Directives.

# TSA Cybersecurity Requirements vs. CISA CIRCIA: What Pipeline Operators Need to Know

## Overview

Yes, pipeline operators may need to comply with **both** TSA Security Directive requirements and the forthcoming CIRCIA (Cyber Incident Reporting for Critical Infrastructure Act of 2022) requirements. They are separate regulatory frameworks with different legal bases, different responsible agencies, and different — but overlapping — obligations. Here is how they differ and how they interact.

---

## Framework Comparison

| Dimension | TSA Security Directives | CISA CIRCIA |
|-----------|------------------------|-------------|
| **Issuing authority** | Transportation Security Administration (TSA) | CISA (Cybersecurity and Infrastructure Security Agency) |
| **Legal basis** | Aviation and Transportation Security Act (ATSA); emergency authority | Cyber Incident Reporting for Critical Infrastructure Act of 2022 (Public Law 117-159) |
| **Status** | Active mandatory requirements (Security Directives in force now) | Proposed rule published April 2024; final rule not yet effective |
| **Who is covered** | Specific TSA-designated entities in pipeline, freight rail, passenger rail/transit, aviation sectors | All 16 CISA critical infrastructure sectors (much broader) |
| **Core focus** | Comprehensive cybersecurity programme (CRMP, segmentation, access controls, monitoring, patching) | Incident reporting and ransom payment reporting obligations |
| **Incident reporting timeline** | **24 hours to CISA** (under current TSA directives) | CIRCIA proposes **72 hours** for covered cyber incidents; **24 hours** for ransom payments |
| **Reporting recipient** | CISA (via 24/7 Operations Center) + TSA notification | CISA |
| **Programme requirements** | Full CRMP (CIP/COIP, IRP, ADR, CAP); four technical domains | Incident reporting; preservation of incident-related data |
| **Sector-specific** | Yes — TSA directives are tailored to transportation sectors | No — applies across all 16 critical infrastructure sectors |

---

## TSA Security Directives: What They Require

TSA's requirements for pipeline operators are grounded in the **SD Pipeline-2021 series**:

- **SD Pipeline-2021-01G** (January 2026): Immediate measures — designate a Cybersecurity Coordinator, report cybersecurity incidents to CISA within **24 hours**, and conduct a review of current cybersecurity practices
- **SD Pipeline-2021-02F**: Comprehensive CRMP — network segmentation (IT/OT), access controls (MFA), continuous monitoring, patch management, plus a Cybersecurity Implementation Plan (CIP), Incident Response Plan (IRP), Architecture Design Review (ADR), and Cybersecurity Assessment Plan (CAP)

TSA's requirements are **programme-wide** — they require building and operating a comprehensive cybersecurity programme around your Critical Cyber Systems (CCS), not just reporting incidents when they happen.

**Current incident reporting under TSA**: 24 hours to CISA from the time of identification. Report even if investigation is incomplete. Contact: 1-888-282-0870 or CISAgov@mail.dhs.gov.

---

## CIRCIA: What It Requires

The Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) was signed into law March 15, 2022. CISA published a Notice of Proposed Rulemaking (NPRM) in April 2024 to implement CIRCIA's requirements.

CIRCIA's core obligations (as proposed):

### 1. Covered Cyber Incident Reporting — 72 Hours
Covered entities must report "covered cyber incidents" to CISA within **72 hours** of reasonably believing a covered cyber incident has occurred. A covered cyber incident includes substantial cyberattacks affecting operational availability, integrity, or confidentiality of covered systems.

### 2. Ransom Payment Reporting — 24 Hours
If a covered entity makes a ransom payment in response to a ransomware attack, it must report that payment to CISA within **24 hours** of making the payment — regardless of whether it also reports the underlying incident.

### 3. Supplemental Reports
Covered entities must file supplemental reports as new or substantially different information becomes available about a reported incident.

### 4. Data Preservation
Covered entities must preserve relevant data related to covered cyber incidents for a defined period.

### 5. Who Is a "Covered Entity"?
CIRCIA covers entities across all 16 CISA critical infrastructure sectors. CISA's proposed rule uses a sector-based, size-based, and criticality-based approach to define covered entities. Coverage is significantly broader than TSA's designation-based approach — many entities not currently under TSA mandates may be covered by CIRCIA.

---

## Key Differences for Pipeline Operators

### Reporting Timeline: 24 Hours (TSA) vs. 72 Hours (CIRCIA)
This is the most operationally significant difference. Under current TSA requirements, you must report to CISA within **24 hours** of identifying an incident. CIRCIA proposes a **72-hour** window for incident reporting.

However, the TSA 24-hour requirement is the more stringent obligation and is **currently in force**. CIRCIA's final rule is not yet effective. If you are a TSA-designated pipeline operator, you must comply with the 24-hour TSA requirement now.

**Important note**: When CIRCIA is finalised, the reporting obligations may overlap. CISA has indicated it intends to coordinate incident reports received under CIRCIA with sector-specific regulators like TSA to avoid duplicative reporting burdens where possible, but the details of that coordination are still being worked out.

### Scope: Programme vs. Reporting
- **TSA**: Requires a full cybersecurity programme — not just reporting, but building and operating controls (segmentation, MFA, monitoring, patching, annual assessments, etc.)
- **CIRCIA**: Primarily a reporting requirement — report incidents and ransom payments to CISA. It does not impose a comprehensive cybersecurity programme equivalent to the TSA CRMP.

### Coverage Basis: Designated vs. Sector-Wide
- **TSA**: Designates specific entities. Not all pipeline operators are automatically covered — you must have received a TSA designation notification.
- **CIRCIA**: Will apply to covered entities across all critical infrastructure sectors based on size and criticality thresholds defined in the final rule. Pipeline operators of meaningful size are likely to be covered.

---

## Do Pipeline Operators Need to Comply With Both?

**Yes, if you are a TSA-designated pipeline operator.** The frameworks are complementary, not mutually exclusive:

1. **TSA directives are currently in force** and require immediate compliance with all CRMP requirements, including 24-hour incident reporting to CISA
2. **CIRCIA will create a parallel obligation** once the final rule is effective — likely covering incident reporting with a 72-hour window and ransom payment reporting within 24 hours
3. **The 24-hour TSA requirement is more stringent** than CIRCIA's 72-hour window — if you report within 24 hours as TSA requires, you will also satisfy CIRCIA's 72-hour window
4. **CIRCIA's ransom payment reporting** (24 hours) is a new obligation with no direct equivalent in current TSA directives

### Practical Approach: Build One Process
Structure your incident response and reporting processes to satisfy both frameworks simultaneously:
- Report to CISA within 24 hours (satisfies TSA; also satisfies CIRCIA's 72-hour window)
- Separately track any ransom payments and report them to CISA within 24 hours of payment (CIRCIA obligation)
- Notify TSA separately per TSA directive requirements
- File supplemental reports as required by both frameworks

---

## 2024 NPRM — TSA's Own Rulemaking

Separately from CIRCIA, TSA published its own **Notice of Proposed Rulemaking (NPRM)** in November 2024 to convert current Security Directive requirements into permanent federal regulations under 49 CFR. This NPRM:
- Formally codifies the CRMP requirements (CIP, IRP, ADR, CAP, four technical domains)
- Aligns explicitly with NIST CSF 2.0 and CISA Cross-Sector Cybersecurity Performance Goals (CPGs)
- Comment period closed February 5, 2025; final rule not yet published
- Current TSA Security Directives remain fully in force until a final rule is published

---

## Summary for Pipeline Operators

| Obligation | Source | Status | Timeline |
|------------|--------|--------|---------|
| Report cybersecurity incidents to CISA | TSA SD Pipeline-2021-01G | In force NOW | 24 hours |
| Report to TSA | TSA SD Pipeline-2021-01G | In force NOW | Per directive |
| Maintain full CRMP (CIP, IRP, ADR, CAP, four domains) | TSA SD Pipeline-2021-02F | In force NOW | Ongoing |
| Report covered cyber incidents | CIRCIA (proposed) | Final rule pending | 72 hours (when effective) |
| Report ransom payments | CIRCIA (proposed) | Final rule pending | 24 hours from payment (when effective) |
| Comply with codified CRMP regulations | TSA NPRM | Proposed | When final rule published |

---

*Disclaimer: This guidance is based on publicly available information about TSA Security Directives, the CIRCIA statute, and CISA's April 2024 NPRM. CIRCIA's implementing regulations are not yet finalised. TSA Security Directives are Sensitive Security Information (SSI). Work with qualified legal counsel and cybersecurity professionals to ensure compliance with all applicable requirements.*

# TSA Cybersecurity Requirements vs. CISA CIRCIA: A Comparison for Pipeline Operators

## Overview

TSA cybersecurity requirements and CISA's CIRCIA (Cyber Incident Reporting for Critical Infrastructure Act) are two distinct but related regulatory frameworks. Pipeline operators subject to TSA jurisdiction need to understand both, as they create overlapping — but not identical — obligations.

---

## TSA Cybersecurity Requirements

TSA's cybersecurity requirements for pipeline operators come from a series of Security Directives issued starting in 2021 (following the Colonial Pipeline ransomware attack). These directives are administered by the Transportation Security Administration, a component of the Department of Homeland Security.

**Key characteristics of TSA requirements**:
- Apply specifically to **pipeline operators** (and other transportation sectors like rail and transit) designated by TSA as critical infrastructure
- Require a **comprehensive cybersecurity programme** — not just incident reporting, but building and maintaining operational security controls
- Include requirements for network segmentation (IT/OT), access controls, continuous monitoring, patch management, and cybersecurity planning documents (Implementation Plan, Incident Response Plan, Architecture Reviews, Assessment Plans)
- Require reporting of cybersecurity incidents to CISA within a short timeframe (generally within 24 hours for significant incidents)
- Require designation of a Cybersecurity Coordinator who serves as the point of contact with TSA and CISA
- Are currently **in force** as mandatory requirements

**Who enforces them**: TSA issues the directives and oversees compliance. CISA receives incident reports and provides technical assistance.

---

## CIRCIA (Cyber Incident Reporting for Critical Infrastructure Act of 2022)

CIRCIA is a federal law signed in March 2022. It directed CISA to create regulations requiring critical infrastructure entities to report cybersecurity incidents and ransom payments to CISA. CISA published proposed regulations (an NPRM) in 2024, but as of the time of this writing, the final rule has not been published — CIRCIA's reporting requirements are **not yet in effect** as enforceable regulations.

**Key characteristics of CIRCIA**:
- Administered by **CISA** (not TSA)
- Applies across **all 16 critical infrastructure sectors** — much broader scope than TSA's sector-specific directives
- Primarily a **reporting requirement** — focused on reporting incidents and ransom payments; does not require building a comprehensive cybersecurity programme in the way TSA directives do
- Proposed reporting timeframes: approximately **72 hours** for covered cyber incidents; **24 hours** for ransom payments
- Would cover a large number of entities across sectors that may not currently be subject to sector-specific cybersecurity mandates

---

## Key Differences

| Aspect | TSA Security Directives | CIRCIA |
|--------|------------------------|--------|
| **Administering agency** | TSA | CISA |
| **Sectors covered** | Pipeline, rail, transit (transportation sectors) | All 16 critical infrastructure sectors |
| **Current status** | In force and mandatory | Proposed rule; not yet final |
| **Core focus** | Comprehensive cybersecurity programme | Incident and ransom payment reporting |
| **Incident reporting window** | ~24 hours | ~72 hours (proposed) |
| **Programme requirements** | Yes — full cybersecurity programme required | No — reporting focused |
| **Coverage basis** | TSA designation of specific entities | Sector + size criteria in final rule |

---

## Do Pipeline Operators Need to Comply With Both?

**Yes, pipeline operators subject to TSA jurisdiction will likely need to comply with both frameworks**, though the nature of the obligations differs:

**Right now**: TSA Security Directives are in force. If TSA has designated your pipeline as covered, you must comply with all current directive requirements — including incident reporting to CISA within the required timeframe, the cybersecurity coordinator requirement, and the full Cyber Risk Management Program requirements.

**When CIRCIA is finalised**: CIRCIA will create an additional, broader incident reporting obligation covering potentially more entities and with specific requirements around ransom payment reporting. However, if you are already reporting to CISA within 24 hours under TSA requirements, you will already satisfy CIRCIA's longer 72-hour window.

**The reporting obligations may overlap**: Both TSA directives and CIRCIA funnel incident reports to CISA. CISA has indicated it intends to work to reduce duplicative reporting burdens, but the mechanics of coordination between the frameworks are still being developed.

---

## Practical Implications

For pipeline operators, the key practical points are:

1. **TSA requirements are the immediate priority** — they are in force now and carry real enforcement consequences
2. **CIRCIA adds ransom payment reporting** as a new obligation once finalised — specifically requiring reporting to CISA within 24 hours of making any ransom payment, which has no direct equivalent in current TSA directives
3. **Build your incident response process to satisfy both** — if your team can report to CISA within 24 hours (as TSA requires), you will meet CIRCIA's 72-hour window when it takes effect
4. **Monitor CIRCIA rulemaking** — the final rule will determine exactly which pipeline entities are covered and what the precise requirements are

---

## Summary

TSA requirements and CIRCIA are complementary frameworks — TSA focuses on building a comprehensive cybersecurity programme for designated transportation infrastructure operators, while CIRCIA focuses on ensuring that significant cyber incidents across all critical infrastructure sectors are reported to CISA promptly. Pipeline operators under TSA jurisdiction should treat TSA directives as their primary compliance obligation today, while preparing for CIRCIA's incident and ransom payment reporting requirements once the final rule is published.

# ISO 42001 Applicability for Healthcare AI Decision Support — WITH SKILL Response

## Your Organisation's Role

As a technology company **deploying AI systems in healthcare decision support**, you are classified as an **AI provider** under ISO/IEC 42001:2023 — you develop and/or deploy AI systems that are used by or affect end users (patients, clinicians, administrators). If your clients also configure or operate the AI system themselves, they may be **AI users** with their own obligations.

---

## What Is ISO 42001?

**ISO/IEC 42001:2023**, published on **18 December 2023**, is the world's first international standard for **AI Management Systems (AIMS)**. It specifies requirements for establishing, implementing, maintaining, and continually improving an AIMS within the context of an organisation.

It follows the **High Level Structure (HLS / Annex SL)** — the same structure used by ISO 27001 (information security) and ISO 9001 (quality) — making it directly compatible for integrated management system implementations.

### Core Purpose

ISO 42001 provides a systematic framework for organisations to:
- Govern AI systems responsibly throughout their lifecycle
- Assess and treat AI-specific risks (bias, model drift, data quality failures)
- Conduct AI System Impact Assessments (AISIAs) for societal and individual impacts
- Demonstrate accountability and transparency in AI decision-making
- Manage third-party AI supply chains

---

## Do You Need to Comply?

### Mandatory vs. Voluntary

ISO 42001 is currently a **voluntary standard** — there is no legal mandate requiring certification in most jurisdictions. However, for a **healthcare AI decision support** company, compliance is strongly recommended for the following reasons:

| Reason | Detail |
|--------|--------|
| **Customer/procurement requirements** | Healthcare organisations (hospitals, insurers, NHS, etc.) increasingly require ISO 42001 certification in supplier due diligence and procurement |
| **Regulatory alignment** | Directly supports compliance with the EU AI Act (see below) |
| **High-impact AI classification** | Healthcare decision support AI is likely **High impact** under Clause 6.1.2 AISIA, requiring maximum controls |
| **Liability and trust** | Demonstrates due diligence in AI governance — important in clinical contexts where AI errors can cause patient harm |
| **Market differentiation** | Healthcare sector increasingly requires demonstrable responsible AI frameworks |

### Impact Assessment Preview (Clause 6.1.2 AISIA)

Your healthcare AI decision support system would likely be classified as **High impact** under the AI System Impact Assessment (AISIA):

- **Output type**: Decision support (influencing clinical decisions)
- **Impact domain**: Healthcare
- **Affected population**: Patients — a vulnerable population
- **Severity**: High — incorrect AI output could contribute to misdiagnosis or inappropriate treatment
- **Reversibility**: Low to medium — medical decisions may be time-critical and hard to reverse
- **Human oversight**: Should be present, but must be formally documented

**Consequence**: High-impact classification triggers the most stringent controls including mandatory human review, full transparency disclosures, and formal rights to challenge AI-driven decisions.

---

## Key ISO 42001 Requirements for Your Organisation

Under the mandatory Clauses 4–10:

| Clause | Requirement |
|--------|-------------|
| **Clause 4** | Document AIMS scope, identify stakeholders (patients, clinicians, regulators), maintain AI system register |
| **Clause 5** | Top management signs AI Policy; assign AI governance roles (AI Risk Owner, Data Governance Lead) |
| **Clause 6** | Conduct AI Risk Assessment and AISIA for each in-scope AI system; set measurable AI objectives |
| **Clause 7** | Ensure staff competence in AI; run awareness training; maintain documented information |
| **Clause 8** | Execute lifecycle controls (Annex A.6), data quality controls (Annex A.7), human oversight (Annex A.8), incident management (Annex A.8.4) |
| **Clause 9** | Run internal audits; conduct management reviews with AI-specific metrics |
| **Clause 10** | Log nonconformities; implement corrective actions; drive continual improvement |

Key Annex A controls most relevant to healthcare AI decision support:
- **A.2.2** — AI Policy
- **A.4.3** — Data resources for AI (training data quality, provenance)
- **A.6.1–A.6.2** — AI system lifecycle management (development through decommission)
- **A.8.1** — AI system transparency
- **A.8.4** — AI incident detection and response
- **A.9.1** — Human oversight mechanisms

---

## How ISO 42001 Relates to the EU AI Act

The **EU AI Act** (Regulation (EU) 2024/1689, fully applicable from August 2026) and ISO 42001 are closely aligned. Understanding both is essential for your organisation.

### Healthcare AI Under the EU AI Act

Healthcare decision support AI is explicitly listed as a **high-risk AI system** under **Annex III of the EU AI Act** (specifically: AI systems intended to be used for making decisions or assisting in decisions in the areas of healthcare). This means **mandatory compliance** with the EU AI Act's high-risk requirements — this is **not** optional.

### Alignment Between ISO 42001 and EU AI Act

| EU AI Act Requirement | ISO 42001 Mapping |
|----------------------|-------------------|
| Risk management system (Art. 9) | Clause 6.1.2 AI Risk Assessment + AISIA |
| Data and data governance (Art. 10) | Annex A.7 (Data resources and data for AI) |
| Technical documentation (Art. 11) | Clause 7.5 Documented information; Annex A.6 |
| Transparency to users (Art. 13) | Annex A.8.1 (AI system transparency) |
| Human oversight (Art. 14) | Annex A.9.1 (Human oversight of AI systems) |
| Accuracy, robustness, cybersecurity (Art. 15) | Annex A.6, A.7, A.8 |
| Quality management system (Art. 17) | The AIMS itself (Clauses 4–10) |
| Post-market monitoring (Art. 72) | Clause 9 (Performance evaluation) + Annex A.8.4 |

### Does ISO 42001 Certification Satisfy the EU AI Act?

**Not automatically** — the EU AI Act requires conformity assessment under specific procedures (often self-assessment with technical documentation for high-risk AI). However:
- ISO 42001 certification provides **strong evidence** of a functioning quality management and risk management system, which directly supports EU AI Act conformity arguments
- The European Commission is expected to mandate harmonised standards under the EU AI Act — ISO 42001 is a leading candidate for recognition as such a standard
- Implementing ISO 42001 now is considered best practice for **EU AI Act readiness**

---

## Recommended Next Steps

1. **Conduct an AIMS Gap Assessment** against ISO 42001 Clauses 4–10 and Annex A controls (A.2–A.10)
2. **Complete an AISIA** for your healthcare AI decision support system (expected outcome: High impact)
3. **Implement human oversight controls** (Annex A.9.1) — document the human-in-the-loop process formally
4. **Establish data governance for AI** (Annex A.7) — training data provenance, bias testing, validation records
5. **Create your AI system register** and AIMS scope document (Clause 4.3)
6. **Draft your AI Policy** signed by top management (Clause 5.2)
7. **Map to EU AI Act requirements** in parallel — particularly technical documentation (Art. 11) and conformity assessment obligations

---

*Response generated using ISO/IEC 42001:2023 AIMS skill — clauses and Annex A controls cited per the standard.*

# ISO 42001 Applicability for Healthcare AI Decision Support — WITHOUT SKILL Response

## What Is ISO 42001?

ISO/IEC 42001 is an international standard published by the International Organization for Standardization (ISO) that provides requirements and guidance for organizations to establish, implement, maintain, and continually improve an AI management system. It was developed to help organizations responsibly develop, deploy, and manage artificial intelligence systems in a structured and accountable way.

The standard is relatively new — published in 2023 — and represents one of the first major international standards specifically focused on governing AI systems within organizations. It follows a similar structure to other ISO management system standards like ISO 27001 (information security) and ISO 9001 (quality management), which means organizations already certified to those standards can integrate ISO 42001 more easily.

---

## Do You Need to Comply?

For a technology company deploying AI systems in healthcare decision support, ISO 42001 compliance is highly relevant, though currently **voluntary** in most jurisdictions. Whether or not you need to comply depends on several factors:

### Business and Market Drivers
- **Customer requirements**: Healthcare organizations (hospitals, health systems, insurers) increasingly require AI vendors to demonstrate responsible AI practices. ISO 42001 certification is becoming a differentiator and, in some cases, a procurement requirement.
- **Regulatory expectations**: While ISO 42001 itself is voluntary, regulators in healthcare increasingly expect evidence of systematic AI governance.
- **Risk management**: Healthcare AI that influences clinical decisions carries significant liability risk. A structured management system reduces the risk of harmful AI outputs.

### Why Healthcare AI Is Particularly High-Stakes
Healthcare decision support AI is among the highest-risk applications of AI because:
- Errors can directly contribute to patient harm
- Patients are a vulnerable population
- Decisions may be time-sensitive and hard to reverse
- There are extensive existing regulatory requirements (FDA, CE marking, HIPAA, etc.)

For these reasons, even if ISO 42001 certification is not legally mandated, operating without a structured AI management framework in healthcare is a significant governance risk.

---

## Key Things ISO 42001 Covers

ISO 42001 generally addresses:

1. **Organizational context**: Understanding who is affected by your AI systems and what their interests are
2. **Leadership commitment**: Requiring senior management accountability for AI governance
3. **AI risk assessment**: Identifying and treating risks specific to AI systems — including bias, fairness, model failures, and data quality issues
4. **Impact assessment**: Evaluating how AI systems affect individuals and society
5. **Transparency**: Requirements for disclosing how AI systems work and make decisions
6. **Human oversight**: Ensuring humans can monitor and intervene in AI decision-making
7. **Data governance**: Managing the quality and integrity of data used to train and operate AI
8. **Supplier management**: Addressing risks from third-party AI components
9. **Incident management**: Detecting, responding to, and learning from AI-related incidents
10. **Continual improvement**: Ongoing monitoring and enhancement of AI systems and governance processes

---

## Relationship to the EU AI Act

The **EU AI Act** (which began applying in stages from 2024 and will be fully applicable by 2026) is the world's first comprehensive legal framework for regulating AI. It is **mandatory** for organizations operating in or selling to the EU market.

### Healthcare AI Under the EU AI Act

Healthcare decision support AI is classified as **high-risk AI** under the EU AI Act. This means your organization faces mandatory obligations including:

- **Risk management system**: You must establish and maintain a documented risk management system throughout the AI system lifecycle
- **Data governance**: Training, validation, and testing datasets must meet quality criteria
- **Technical documentation**: Extensive documentation about your AI system must be maintained
- **Transparency to deployers and users**: Information about the AI system's capabilities and limitations must be provided
- **Human oversight**: High-risk AI must be designed to allow effective human oversight
- **Accuracy and robustness**: The AI system must achieve appropriate levels of accuracy and be resilient
- **Conformity assessment**: Before market placement, high-risk AI systems must undergo conformity assessment (often requiring a notified body)

### How ISO 42001 Relates to the EU AI Act

ISO 42001 and the EU AI Act are complementary frameworks that address similar concerns:

| Topic | EU AI Act | ISO 42001 |
|-------|-----------|-----------|
| Risk management | Mandatory (Art. 9) | Core requirement |
| Data governance | Mandatory (Art. 10) | Addressed through data controls |
| Transparency | Mandatory (Art. 13) | Transparency requirements |
| Human oversight | Mandatory (Art. 14) | Human oversight controls |
| Quality management | Mandatory (Art. 17) | The management system itself |

**Importantly**, ISO 42001 certification does not automatically equal EU AI Act compliance, but:
- Implementing ISO 42001 builds many of the same processes required by the EU AI Act
- It may be recognized as a harmonized standard that provides presumption of conformity for certain EU AI Act requirements
- It demonstrates systematic AI governance to regulators and customers

---

## Recommended Approach

For a healthcare AI decision support company, we recommend:

1. **Treat the EU AI Act as mandatory** — assess your systems against high-risk AI requirements immediately
2. **Pursue ISO 42001 as your governance framework** — it provides the structure to meet both ISO and regulatory requirements
3. **Conduct an AI risk and impact assessment** for each AI system in your portfolio
4. **Implement human oversight mechanisms** appropriate to the healthcare context
5. **Establish data governance processes** for your training and operational data
6. **Engage legal counsel** familiar with both the EU AI Act and healthcare AI regulations (FDA if US-market, MDR/IVDR if EU medical device)

The intersection of healthcare regulation, AI regulation, and AI management standards makes your situation complex but manageable with a structured approach.

# ISO 42001 Key Requirements for an AI Product Developer — WITH SKILL Response

## Your Role Classification

As an organisation that **develops AI products**, you are classified as an **AI provider** under ISO/IEC 42001:2023. This means the full weight of Annex A controls apply — including lifecycle management (A.6), data governance (A.7), transparency (A.8), and human oversight (A.9). If you also use third-party AI components (APIs, models) in your products, you are simultaneously an **AI user** for those components.

---

## Mandatory Clause Requirements (Clauses 4–10)

The following are the required elements of the AIMS, mapped to the clause structure:

### Clause 4 — Context of the Organisation

**What you need:**
- **AIMS scope document**: Defines which AI systems, organisational units, and locations are in scope. Must state what is explicitly excluded and justify exclusions.
- **Stakeholder register**: Identify all interested parties (customers, end users, regulators, employees, society) and document their requirements and expectations relevant to AI
- **AI system register**: A living inventory of all AI systems in scope — each entry should capture system name, intended purpose, deployment context, and impact classification
- **Internal/external issues analysis**: Identify factors affecting your ability to govern AI responsibly (e.g., competitive pressure to deploy AI quickly, regulatory landscape, workforce AI literacy)

**Key deliverable**: Written AIMS Scope document, signed off by leadership, with rationale for inclusions and exclusions.

---

### Clause 5 — Leadership

**What you need:**
- **AI Policy** (Clause 5.2): Top-level policy signed by the CEO or equivalent. Must state the organisation's commitment to responsible AI, define the AIMS scope, and set the tone for AI governance. This is distinct from an Acceptable Use Policy — it is the overarching commitment document.
- **Roles and responsibilities**: Documented RACI (or equivalent) for AI governance — who owns AI risk, who approves AI system deployments, who leads incident response
- **Management commitment evidence**: Records showing leadership actively supports AIMS (e.g., management review minutes, resource allocation decisions)

**Key deliverable**: AI Policy document with document control metadata (version, owner, review date, top management signature).

---

### Clause 6 — Planning

This is the most technically demanding clause for AI providers:

**AI Risk Assessment** (Clause 6.1.2):
- Must be conducted for each in-scope AI system
- Covers AI-specific risk categories: model bias, data poisoning, hallucination, model drift, adversarial inputs, privacy violations, supply chain risks
- Risk treatment decisions must be documented (modify, accept with monitoring, avoid, or transfer via contract)

**AI System Impact Assessment (AISIA)** (Clause 6.1.2):
- **Mandatory** — separate from the risk assessment
- Assesses societal and individual impacts of each AI system
- Dimensions: intended purpose, output type, impact domain, affected population, severity, reversibility, human oversight availability
- Results in an impact classification: Low / Medium / High
- Impact level drives control selection (High impact = maximum controls)

**AIMS Objectives** (Clause 6.2):
- Must be measurable (e.g., "Achieve <2% false positive rate in model output by Q4", "Complete AISIA for all new AI systems within 30 days of design phase")
- Linked to responsible AI principles
- Plans to achieve objectives must be documented

**Key deliverables**: AI Risk Assessment records, AISIA records for each AI system, AIMS Objectives document with measurement plan.

---

### Clause 7 — Support

**What you need:**
- **Competence records**: Evidence that people working on AI systems have appropriate competence (qualifications, training records, experience logs) — especially for AI development, data science, and AI ethics roles
- **Awareness programme**: All staff (not just technical teams) must be aware of AI policy, their role in AIMS, and the consequences of non-compliance
- **Communication plan**: Define what AI-related information is communicated, to whom, and how (internally and externally)
- **Documented information procedure**: How AI-related documents and records are created, controlled, retained, and disposed of

**Key deliverables**: Training completion records, awareness programme materials, documented information procedure.

---

### Clause 8 — Operation

This is where AIMS is put into practice. For an AI product developer, the key operational controls come from Annex A:

| Annex A Domain | Key Controls | What to Implement |
|----------------|-------------|-------------------|
| **A.2 — Policies for AI** | A.2.2 AI policy | Overarching AI Policy (see Clause 5.2) |
| **A.4 — Resources** | A.4.3 Data resources | Data governance for training/validation/test datasets |
| **A.5 — Impacts** | A.5.1–A.5.5 | Assess impacts on individuals, groups, communities, society, environment |
| **A.6 — AI system lifecycle** | A.6.1–A.6.2 | Lifecycle management from concept through decommission; development, testing, deployment, monitoring controls |
| **A.7 — Data for AI** | A.7.1–A.7.6 | Data sourcing, quality, bias testing, privacy in training data, data provenance records |
| **A.8 — Technical controls** | A.8.1–A.8.5 | AI system transparency documentation, security of AI systems, AI incident management |
| **A.9 — AI use** | A.9.1 | Human oversight mechanisms — formal process for humans to review, intervene, override AI outputs |
| **A.10 — Third party** | A.10.3 | Supplier AI assessments, AI-specific contractual clauses with third-party AI providers |

**Key deliverables**: Executed risk and impact assessments, lifecycle control records (design reviews, testing records, deployment approvals), supplier assessment records, incident log.

---

### Clause 9 — Performance Evaluation

**What you need:**
- **Internal audit programme** (Clause 9.2): Planned schedule of AIMS internal audits; audit reports with findings and nonconformities
- **Management review** (Clause 9.3): Periodic (at minimum annual) review by top management covering AIMS performance, audit results, incidents, objective achievement, and opportunities for improvement — documented in meeting minutes
- **AIMS metrics / KPIs**: Measurable indicators tracked over time (e.g., number of AI incidents, AISIA completion rate, training completion rate, model performance metrics)

**Key deliverables**: Internal audit programme and reports, management review minutes, performance metrics dashboard/log.

---

### Clause 10 — Improvement

**What you need:**
- **Nonconformity log**: Record of all AIMS nonconformities (deviations from requirements)
- **Corrective action records**: Root cause analysis and corrective actions for each nonconformity
- **Continual improvement register**: Broader improvement initiatives beyond corrective actions

**Key deliverables**: Nonconformity and corrective action records, improvement register.

---

## Core Policies Required

Under the AIMS, the following policies should be documented:

| Policy | Clause/Control | Purpose |
|--------|---------------|---------|
| AI Policy | Clause 5.2 | Overarching commitment and scope |
| AI Risk Management Policy | Clause 6 | Risk assessment methodology, frequency, ownership |
| AI Acceptable Use Policy | A.9.2 | Permitted/prohibited AI uses, user obligations |
| Data Governance for AI Policy | A.7 | Training data quality, sourcing, retention, bias controls |
| AI Incident and Reporting Policy | A.8.4 | Incident classification, reporting, response, post-incident review |
| AI System Lifecycle Policy | A.6 | Development, testing, deployment, monitoring standards |
| AI Third-Party and Supplier Policy | A.10.3 | Third-party AI provider due diligence and contractual requirements |

---

## Statement of Applicability (SoA)

You must produce a **Statement of Applicability** covering all 38 Annex A controls (domains A.2–A.10), stating for each:
- Whether it is applicable to your organisation
- Justification for inclusion or exclusion
- Current implementation status
- Reference to evidence

This is a key Stage 1 audit document — auditors will review it to understand your control landscape.

---

## Minimum Documentation Set for Certification

| Document | Clause/Control |
|----------|---------------|
| AIMS Scope | 4.3 |
| AI Policy | 5.2 |
| AI System Register | 4 |
| AI Risk Assessment records | 6.1.2 |
| AISIA records (per system) | 6.1.2 |
| AIMS Objectives | 6.2 |
| Statement of Applicability | Annex A |
| Competence and training records | 7.2 |
| Documented information procedure | 7.5 |
| Lifecycle control records | A.6 |
| Data governance records | A.7 |
| Supplier assessment records | A.10.3 |
| Incident log | A.8.4 |
| Internal audit programme and reports | 9.2 |
| Management review minutes | 9.3 |
| Nonconformity and corrective action records | 10.2 |

---

*Response generated using ISO/IEC 42001:2023 AIMS skill — all clauses and Annex A controls cited per the standard.*

# ISO 42001 Key Requirements for an AI Product Developer — WITHOUT SKILL Response

## Overview

ISO 42001 is an AI Management System (AIMS) standard. For an organization that develops AI products, it requires establishing a comprehensive governance framework covering the entire AI system lifecycle — from development and training through deployment, monitoring, and decommissioning. Below is a practical walkthrough of what you need to put in place.

---

## 1. Organizational Foundation

### Define Your AIMS Scope
Before anything else, you need to formally define the boundaries of your AI Management System. This means specifying:
- Which AI systems are covered
- Which organizational units, sites, and functions are included
- What is explicitly excluded and why

For an AI product developer, the scope would typically encompass your AI development teams, the AI products themselves, your MLOps/deployment infrastructure, and the data pipelines that feed your models.

### Stakeholder Analysis
Identify and document the needs and expectations of parties who have an interest in your AI systems: customers, end users, employees, regulators, investors, and society more broadly. This analysis shapes your risk assessment and transparency obligations.

---

## 2. Leadership Commitment

### AI Policy
Top management must establish and communicate an AI policy that:
- States the organization's commitment to responsible AI development
- Defines the scope of the AI management system
- Establishes AI-related objectives and principles (fairness, transparency, accountability, safety)
- Is documented, signed by leadership, and communicated throughout the organization

### Roles and Responsibilities
Assign clear accountability for AI governance. Typical roles needed include:
- AI Ethics/Responsibility Officer or equivalent
- AI Risk Owner
- Data Governance Lead
- AI System Owners (one per product or system)

---

## 3. Risk and Impact Assessment

This is the heart of ISO 42001 for an AI product developer.

### AI Risk Assessment
You need a systematic process to identify, analyze, and treat risks specific to your AI systems. AI-specific risks that go beyond traditional IT risks include:
- **Model bias and unfairness**: Systematic errors that disproportionately affect certain groups
- **Data quality risks**: Training data that is incomplete, unrepresentative, or poisoned
- **Model drift**: Degradation of model performance over time as real-world conditions change
- **Hallucination/confabulation**: AI systems generating plausible but incorrect outputs
- **Adversarial attacks**: Intentional manipulation of inputs to cause incorrect outputs

For each risk, you need to document likelihood, potential impact, and your treatment decision (accept, mitigate, avoid, or transfer).

### AI System Impact Assessment
Beyond risk, you need to assess the broader impacts of your AI systems on individuals and society. This involves evaluating:
- What decisions or outputs the AI system produces
- Who is affected by those outputs and how
- The severity and reversibility of potential harms
- Whether vulnerable populations could be disproportionately affected

---

## 4. Policies and Processes

### Core Policies You Need
- **AI Governance Policy**: Overarching principles and commitments
- **Data Governance Policy for AI**: How you source, validate, and manage training and operational data
- **AI Development Lifecycle Policy**: Standards and gates for AI system development, testing, and deployment
- **AI Acceptable Use Policy**: What AI can and cannot be used for within your organization
- **AI Incident Response Policy**: How you detect, respond to, and learn from AI failures or harms
- **Third-Party AI Supplier Policy**: How you assess and manage AI components from external providers

### AI System Lifecycle Management
For each AI product, you need documented processes covering:
- **Design and development**: Requirements, architecture decisions, ethical review gates
- **Data management**: Dataset documentation, bias testing, data lineage
- **Testing and validation**: Performance testing, fairness testing, adversarial testing
- **Deployment**: Deployment approvals, rollout controls, monitoring setup
- **Operations**: Ongoing performance monitoring, drift detection, incident management
- **Decommissioning**: Planned end-of-life procedures

---

## 5. Data Governance for AI

Data governance for AI goes beyond traditional data management. You need:
- **Dataset documentation**: Provenance, composition, collection methods for all training datasets
- **Bias and fairness testing**: Systematic evaluation of whether training data or model outputs exhibit unfair patterns
- **Data quality standards**: Minimum quality thresholds for training, validation, and test data
- **Privacy in training data**: Processes to ensure personal data in training sets is appropriately handled

---

## 6. Human Oversight

ISO 42001 requires mechanisms for human oversight of AI systems, particularly where AI outputs affect individuals. This means:
- Designing AI systems so humans can monitor outputs
- Establishing processes for humans to review, challenge, or override AI decisions
- Documenting when and how human oversight is exercised
- Ensuring staff know when and how to escalate AI-related concerns

---

## 7. Transparency

You need to document and communicate:
- What your AI systems are intended to do (intended purpose documentation)
- The limitations and known failure modes of your AI systems
- How decisions are made (to the extent explainable)
- Information that deployers or end users need to use the AI system appropriately

---

## 8. Supplier Management

If you use third-party AI components (pre-trained models, AI APIs, data providers), you need:
- A process for assessing the AI governance practices of your suppliers
- Contractual provisions addressing AI-specific responsibilities
- Ongoing monitoring of third-party AI component performance

---

## 9. Monitoring, Audit, and Improvement

### Internal Audit
Regularly audit your AI management system to verify it is functioning as intended and meeting requirements.

### Management Review
Senior leadership should periodically review AIMS performance, including AI incidents, audit findings, and progress against AI objectives.

### Continual Improvement
Track nonconformities, implement corrective actions, and drive ongoing improvements to your AI governance practices.

---

## Key Documentation You Need

| Document Type | Purpose |
|---------------|---------|
| AIMS Scope Document | Defines the boundary of your management system |
| AI Policy | Top-level commitment and principles |
| AI System Register | Inventory of all AI systems under management |
| Risk Assessment Records | Per-system AI risk analysis and treatment decisions |
| Impact Assessment Records | Societal/individual impact evaluations per system |
| Data governance records | Dataset documentation, bias testing results |
| Lifecycle control records | Development, testing, deployment evidence |
| Incident log | AI-related incidents, responses, and lessons learned |
| Training and competence records | Evidence of staff AI competence |
| Internal audit reports | Audit findings and follow-up actions |
| Management review minutes | Senior leadership oversight evidence |

---

## Summary

The scale of documentation and process required is substantial, but it mirrors the structure of ISO 27001 (information security) if your team is familiar with that standard. The key AI-specific additions are the impact assessment process, the AI-specific risk categories (bias, drift, hallucination), data governance for training data, and human oversight mechanisms. Starting with a gap assessment against these requirements will help you prioritize your implementation roadmap.

# AI-Specific Risks in ISO 42001 vs Traditional IT Risk Management — WITH SKILL Response

## Why AI Risk Is Different

ISO/IEC 42001:2023 explicitly recognises that AI systems introduce a fundamentally different risk profile from traditional IT systems, and this is why the standard mandates a **separate AI risk assessment** (Clause 6.1.2) in addition to whatever general organisational risk management an organisation already performs.

The core difference is that traditional IT risk management (as found in ISO 27001) addresses **deterministic systems** — software that behaves predictably given defined inputs. AI systems are **probabilistic, adaptive, and emergent** — their behaviour cannot be fully specified in advance and can change over time, even without deliberate modification. This creates risk categories that simply do not exist in conventional IT.

ISO 42001 also introduces the **AI System Impact Assessment (AISIA)** (Clause 6.1.2) — an impact-focused evaluation that goes beyond likelihood × severity to assess societal and individual consequences. There is no equivalent in ISO 27001.

---

## ISO 42001 AI-Specific Risk Categories (vs ISO 27001 Comparison)

### 1. Model Risks

These are risks arising from the AI model itself — how it was built, trained, and what it produces.

| AI-Specific Risk | How It Differs from Traditional IT | Concrete Example |
|-----------------|-----------------------------------|-----------------|
| **Algorithmic bias and unfairness** | Traditional IT systems apply rules equally; AI models can learn and perpetuate discriminatory patterns from training data | A credit scoring AI trained on historical loan data learns that applicants from certain postcodes are higher risk, reflecting historical discrimination — denying loans to creditworthy individuals in those areas |
| **Hallucination / confabulation** | Traditional software returns errors on unknown inputs; generative AI produces confident but false outputs | An LLM-based legal research tool confidently cites non-existent case law, leading a lawyer to submit fictitious precedents in court |
| **Model drift** | Traditional software does not change unless modified; AI models can become less accurate as real-world data distributions change without any code change | A fraud detection model trained on pre-pandemic spending patterns becomes less accurate post-pandemic as consumer behaviour permanently shifts, missing new fraud patterns |
| **Adversarial attacks** | SQL injection or buffer overflows require exploiting code vulnerabilities; adversarial AI attacks manipulate inputs in ways imperceptible to humans | An image recognition AI in a self-driving car misclassifies a stop sign with subtle pixel-level perturbations added to the sign — the human eye sees a normal stop sign, the model sees something else |
| **Output unpredictability / scope creep** | Traditional software has defined output ranges; AI systems can produce unexpected outputs outside anticipated parameters | A customer service chatbot drifts from answering product questions to expressing opinions on unrelated topics, creating reputational or legal risk |

**ISO 42001 treatment under Clause 6.1.3**: Model risks are treated by modifying the AI system (retraining, guardrails), accepting with continuous monitoring and defined performance thresholds, or avoiding deployment for specific use cases.

---

### 2. Data Risks

ISO 42001 Annex A.7 (Data for AI) specifically addresses these risks — there is no equivalent domain in ISO 27001 Annex A because traditional IT systems do not learn from data.

| AI-Specific Risk | How It Differs from Traditional IT | Concrete Example |
|-----------------|-----------------------------------|-----------------|
| **Training data quality failures** | Traditional IT data quality affects query results; training data quality determines what an AI model learns and cannot be retroactively corrected without retraining | A medical AI trained on patient records from a single hospital learns demographic-specific patterns that don't generalise to the broader population, producing systematically worse diagnoses for patients not represented in training data |
| **Data poisoning** | Traditional IT data integrity is about accuracy; data poisoning is an AI-specific attack where malicious data is injected into training pipelines to corrupt model behaviour | An attacker gains write access to a model provider's training data pipeline and injects examples that cause the model to misclassify specific inputs in attacker-chosen ways |
| **Privacy violations in training data** | Traditional IT privacy focuses on data access controls; AI training data can cause models to memorise and later reproduce personal information | An LLM trained on internet data can be prompted to reproduce verbatim excerpts of training documents containing personal information — a data protection violation that emerges from the model rather than a data breach |
| **Underrepresentation / sampling bias** | Traditional data quality focuses on accuracy; AI training data must also be representative of all groups the model will make decisions about | A facial recognition model trained mostly on lighter-skinned faces has significantly higher error rates for darker-skinned individuals — a bias that emerges from training data composition, not a code error |

**ISO 42001 Annex A.7 controls address**: Data sourcing governance, training data quality standards, bias evaluation, data provenance documentation, and data privacy in training pipelines.

---

### 3. Operational Risks

| AI-Specific Risk | How It Differs from Traditional IT | Concrete Example |
|-----------------|-----------------------------------|-----------------|
| **Automation of harm at scale** | A bug in traditional IT typically causes a defined error; an AI flaw can systematically harm large populations before detection | A hiring AI with a gender bias automatically rejects all applications from women across thousands of job postings — the scale of harm is orders of magnitude larger than a single discriminatory human decision |
| **Unexplainability of decisions** | Traditional IT decisions are auditable through code review; AI decisions (especially deep learning) may be opaque even to developers | A loan denial from a traditional rules-based system can be fully explained by pointing to the specific rule triggered. A neural network denial cannot always be explained — creating regulatory compliance risks under GDPR Art. 22 (automated decision-making) |
| **Over-reliance / automation bias** | Not applicable in traditional IT; humans may defer inappropriately to AI recommendations | Radiologists become over-reliant on an AI-assisted cancer screening tool and stop exercising independent clinical judgement, meaning they miss cancers the AI misclassifies |

**ISO 42001 Annex A.9.1** (Human oversight) specifically controls for automation bias by requiring formal mechanisms for human review and the ability to override AI outputs.

---

### 4. Supply Chain / Third-Party AI Risks

ISO 27001 addresses supplier risk (A.5.19–A.5.22) but focuses on information security of supplier systems. ISO 42001 Annex A.10.3 addresses a fundamentally different risk: **the AI governance quality of your AI providers**.

| AI-Specific Risk | Concrete Example |
|-----------------|-----------------|
| **Inherited model bias from third-party providers** | You embed a third-party sentiment analysis API into your HR platform without knowing it has documented racial bias — you inherit that bias as your own risk |
| **Third-party model drift** | A third-party LLM API you rely on updates its underlying model with different behaviour — your application's outputs change without any action on your part |
| **Provider lock-in / continuity risk** | A small AI startup providing a critical NLP component shuts down, leaving you without the model you depended on and unable to replicate its performance with alternatives |
| **Opaque training practices** | Your third-party AI provider cannot demonstrate what data their model was trained on or whether it complies with GDPR data usage restrictions |

**ISO 42001 Annex A.10.3** requires: third-party AI provider due diligence, AI-specific contractual clauses (covering model governance, bias testing, change notification, data practices), and ongoing supplier monitoring.

---

### 5. Societal Risks

ISO 27001 does not address societal impacts — its scope is organisational information security. ISO 42001 Annex A.5 (Impacts on interests of individuals and society) is unique:

| AI-Specific Societal Risk | Concrete Example |
|--------------------------|-----------------|
| **Discriminatory outcomes at population scale** | A predictive policing AI systematically recommends increased patrols in minority neighbourhoods, reinforcing over-policing and creating feedback loops that amplify existing disparities |
| **Erosion of human autonomy** | A recommendation algorithm optimised for engagement subtly shapes user beliefs and behaviours over time without users' awareness |
| **Misinformation amplification** | A content moderation AI incorrectly flags legitimate speech as harmful at scale, or fails to flag genuine misinformation — with societal consequences |
| **Environmental impact** | Large AI model training consumes significant energy and contributes to carbon emissions — an emerging area of societal risk |

---

## Key Structural Difference: AISIA vs. Traditional Risk Assessment

The most significant structural difference ISO 42001 introduces is the mandatory **AI System Impact Assessment (AISIA)** (Clause 6.1.2), which has no equivalent in ISO 27001:

| | ISO 27001 Risk Assessment | ISO 42001 AI Risk Assessment | ISO 42001 AISIA |
|--|--------------------------|-----------------------------|--------------------|
| **Focus** | Threats to CIA of information | Likelihood × severity of AI-specific risks | Societal and individual impact of AI system existence and outputs |
| **Output** | Risk register with treatment decisions | AI risk register with AI-specific treatment options | Impact classification (Low/Medium/High) driving control selection |
| **Scope** | Organisational assets | AI system behaviour and failure modes | Effect on individuals, groups, communities, society |
| **When done** | Periodic, at least annually | Per AI system, before deployment | Per AI system, before deployment |
| **Result** | Security controls selected | Risk treatment plan | Transparency obligations, human oversight requirements |

---

## Summary

ISO 42001's AI-specific risk management goes well beyond ISO 27001 in these key ways:
- **Separate AI risk assessment** covering model, data, operational, supply chain, and societal risk categories
- **Mandatory AISIA** assessing impact on people and society — not just organisational risk
- **Annex A.7** specifically for training data quality and bias — not present in any traditional IT standard
- **Annex A.9.1** for human oversight — a control category unique to AI governance
- **Annex A.10.3** for AI-specific supplier due diligence beyond information security
- **Annex A.5** for societal impact assessment — a category entirely absent from IT risk management frameworks

*Response generated using ISO/IEC 42001:2023 AIMS skill — all clauses and Annex A controls cited per the standard.*

# AI-Specific Risks in ISO 42001 vs Traditional IT Risk Management — WITHOUT SKILL Response

## Why AI Needs Its Own Risk Framework

Traditional IT risk management frameworks like ISO 27001 were built to protect the confidentiality, integrity, and availability of information and information systems. They address threats like unauthorized access, data breaches, system failures, and malicious code. These remain important, but AI systems introduce an entirely different class of risks that traditional frameworks were not designed to handle.

The fundamental difference is this: **traditional IT systems are deterministic — they do what they're programmed to do. AI systems are probabilistic — they learn patterns from data and make predictions, and their behavior can be surprising, unfair, or harmful in ways that cannot be fully anticipated from code review alone.**

---

## Category 1: Model Risk — The AI Behaves Unexpectedly

### Algorithmic Bias and Discrimination
Traditional software treats all inputs according to the same programmed rules. AI models can learn and perpetuate discriminatory patterns that exist in training data, producing systematically different — and worse — outcomes for certain groups.

**Concrete example**: A recruitment AI trained on a company's historical hiring decisions learns that the company historically hired fewer women in engineering roles. It begins down-ranking female candidates' resumes, automating and scaling past discrimination without any human making an explicit discriminatory decision.

### Hallucination (Generating False Information)
Traditional software either returns data or throws an error when it doesn't have information. Generative AI can produce confident, fluent, but entirely fabricated outputs.

**Concrete example**: A customer-facing AI assistant built on a large language model confidently tells a customer that a product has safety certifications it doesn't actually have, or provides incorrect dosage information for a medication. There is no error message — just wrong information delivered with confidence.

### Model Drift
Traditional software does not change unless someone modifies it. AI models can become less accurate over time as the real world changes, without any code change.

**Concrete example**: A fraud detection AI trained on pre-2020 transaction patterns becomes progressively less accurate as consumer behavior permanently shifts post-pandemic. Fraud rates rise while the model continues reporting normal performance metrics based on outdated patterns.

### Adversarial Attacks
Traditional cyberattacks exploit code vulnerabilities. Adversarial attacks on AI exploit the statistical nature of machine learning — making small, imperceptible changes to inputs that cause the model to produce wrong outputs.

**Concrete example**: Researchers have demonstrated that adding a small sticker pattern to a stop sign causes some image recognition models (used in autonomous vehicles) to misclassify it as a speed limit sign. Humans see a normal stop sign; the AI sees something completely different.

---

## Category 2: Data Risk — The Problem Starts Before Deployment

### Training Data Quality Failures
In traditional IT, data quality affects reports and queries but can be corrected. In AI, training data quality determines what the model learns — and poor training cannot be retroactively fixed without retraining the entire model.

**Concrete example**: A medical diagnosis AI is trained primarily on data from academic medical centers, which skew toward severe, unusual, or complex cases. When deployed in primary care settings, it performs poorly because the population it was trained on doesn't represent the patients it now encounters.

### Data Poisoning
This is an AI-specific attack where malicious actors inject carefully crafted examples into a model's training data to corrupt its behavior in attacker-chosen ways.

**Concrete example**: An attacker who gains access to a financial institution's training pipeline injects transactions labeled as legitimate that share subtle characteristics with a new fraud technique the attacker plans to use. The trained model is then blind to that specific fraud pattern.

### Privacy Leakage from Training Data
Traditional data privacy focuses on access controls — preventing unauthorized people from seeing data. AI creates a new risk: models can memorize and inadvertently reproduce training data, even if those records were never meant to be accessible.

**Concrete example**: A customer service AI trained on historical support tickets can, under certain prompting conditions, reproduce verbatim text from those tickets — including customer names, addresses, or account details — to unrelated users.

---

## Category 3: Operational Risks — Scale and Automation

### Harm at Scale
Traditional software bugs cause defined, bounded errors. AI errors can silently affect large populations before they are detected.

**Concrete example**: A content moderation AI incorrectly flags posts in a minority language as violating platform policies, because the language is underrepresented in its training data. Hundreds of thousands of legitimate posts are removed before anyone notices the systematic error.

### Automation Bias and Over-Reliance
There is no equivalent to this in traditional IT. Humans tend to over-trust AI recommendations, especially when the AI presents outputs with high confidence scores.

**Concrete example**: Radiologists using an AI-assisted screening tool become less likely to challenge the AI's findings over time. When the AI misses certain early-stage tumors that fall outside its training distribution, the radiologists also miss them — not because they wouldn't have caught them without the AI, but because they defer to the AI's judgment.

### Explainability and Auditability Failures
Traditional software decisions are fully auditable through code review. Many AI models, especially deep learning systems, are not explainable even to their developers.

**Concrete example**: A credit scoring AI denies a loan. The customer asks why. The company cannot explain the specific factors — they know inputs were provided and a score came out, but the internal reasoning of the neural network is opaque. Under GDPR's right to explanation for automated decisions, this is a compliance failure.

---

## Category 4: Third-Party AI Supply Chain Risk

Traditional supplier risk management in IT focuses on whether a vendor has good security practices. AI supply chain risk adds a new dimension: **do your AI suppliers have good AI governance practices?**

**Concrete examples**:
- You embed a third-party sentiment analysis API that has documented racial bias in its training data — you inherit that bias as your own risk and reputational exposure
- A third-party AI provider updates their underlying model without notifying you — your application's behavior changes in ways you didn't test or approve
- You depend on an AI startup's specialized model for a core product feature; the startup shuts down with no notice, leaving you unable to replicate its capabilities

---

## Category 5: Societal and Systemic Risks

Traditional IT risk management is organizational — it focuses on risks to the business. AI risk management must also consider impacts on people and society, including indirect and systemic effects that no single actor intends.

**Concrete examples**:
- A predictive recidivism AI used in criminal sentencing systematically assigns higher risk scores to Black defendants, perpetuating racial disparities in incarceration — a harm to society that emerges from aggregate AI use, not from any single decision
- A social media recommendation algorithm optimized for engagement learns that outrage-inducing content keeps users on the platform longer, inadvertently contributing to political polarization and erosion of shared epistemic standards
- Multiple banks independently deploy similar AI credit-scoring models trained on similar data; the correlated nature of their decisions amplifies systemic credit risk in ways no individual bank's risk model captures

---

## Summary: What Traditional IT Risk Management Misses

| Risk Type | Covered by ISO 27001? | Unique to AI? |
|-----------|----------------------|---------------|
| Unauthorized data access | Yes | No |
| System availability failures | Yes | No |
| Algorithmic bias | No | Yes |
| Hallucination / false outputs | No | Yes |
| Model drift | No | Yes |
| Adversarial attacks on AI models | Partially (cybersecurity) | Mostly yes |
| Training data poisoning | No | Yes |
| Privacy leakage from model weights | No | Yes |
| Automation bias / over-reliance | No | Yes |
| Explainability failures | No | Yes |
| Third-party model governance risk | No | Yes |
| Societal/systemic impacts | No | Yes |

The core insight is that **AI systems fail differently than traditional software** — their failures are often silent, statistical, and societal rather than obvious, binary, and technical. Effective AI risk management requires a framework specifically designed for these characteristics.

# Third-Party LLM API Supplier Management Under ISO 42001 — WITH SKILL Response

## Your Dual Role

When you use a third-party LLM API (such as OpenAI or Anthropic) as a component in your AI product, ISO/IEC 42001:2023 classifies you in a **dual role**:
- **AI provider**: You develop and deploy an AI product to your customers
- **AI user**: You integrate a third-party AI system (the LLM) from an external provider

This dual role matters because it activates obligations from **both** the AI provider and AI user perspectives in Annex A — particularly Annex A.10 (Third-party and supplier requirements for AI).

The key principle under ISO 42001 is clear: **using a third-party LLM does not transfer your AI governance obligations to the LLM provider.** You remain accountable for the behaviour of your AI product, including the component behaviour of the third-party LLM within it.

---

## Primary Control: Annex A.10.3 — Suppliers

**A.10.3** is the core third-party AI supplier management control. It requires organisations to:

1. **Assess third-party AI providers** before integration — not just their security posture (which ISO 27001 addresses) but specifically their **AI governance practices**
2. **Establish AI-specific contractual obligations** with third-party AI providers
3. **Monitor ongoing supplier AI performance** — including model updates and changes

### What the A.10.3 Assessment Must Cover

For an LLM API provider like OpenAI or Anthropic, your supplier assessment under A.10.3 should evaluate:

| Assessment Dimension | What to Look For | Key Questions to Ask |
|---------------------|-----------------|---------------------|
| **AI governance and responsible AI framework** | Does the provider have a documented responsible AI framework? Do they publish an AI safety/ethics policy? | What principles govern their model development? How are those principles enforced? |
| **Model training data practices** | What data was used to train the model? Is it GDPR-compliant? Does it avoid rights-violating data sources? | What datasets were used? Were data subjects notified? How is copyright handled? |
| **Bias testing and evaluation** | Has the model been systematically tested for fairness and bias? Are results published? | What bias evaluations have been conducted? What populations were tested? |
| **Model update and change notification** | Will they notify you when the underlying model changes behaviour? (This is a significant risk — see model drift) | What is their policy for notifying customers of model updates? Is there versioning? Can you pin to a specific model version? |
| **Incident management and disclosure** | How do they handle and disclose AI-related incidents (e.g., harmful outputs, data exposure)? | What is their AI incident response process? How are customers notified? |
| **Transparency about capabilities and limitations** | Do they document known failure modes, limitations, and use case restrictions? | What does their system card / model card document? Are known limitations disclosed? |
| **Data processing and retention** | How is data you send via the API processed, stored, and used? Will it be used to retrain their models? | Are API inputs used for training? What is the data retention period? Is there a data processing agreement? |

---

## Contractual Requirements Under A.10.3

ISO 42001 requires that contracts with third-party AI providers include **AI-specific clauses** beyond standard data processing agreements. Key contractual provisions to include:

### 1. Model Versioning and Change Notice
- Right to pin to a specific model version (e.g., `gpt-4-turbo-2024-04-09` rather than `gpt-4-turbo`)
- Obligation for advance notice (ideally 30+ days) before significant model behaviour changes
- Rationale: Unnoticed model updates can silently change your product's behaviour — this is a form of AI-specific operational risk

### 2. Transparency About Limitations and Known Failures
- Provider must disclose known failure modes, bias characteristics, and use case restrictions applicable to your deployment
- Reference their system card / model card as a contractual deliverable

### 3. Data Processing Restrictions
- Explicit prohibition on using your API inputs to retrain the provider's models (or explicit consent if you accept this)
- Data retention period and deletion commitments
- This addresses the training data privacy risk under Annex A.7 and Clause 6.1.2

### 4. Incident Notification
- Obligation to notify you within a defined timeframe (e.g., 48–72 hours) of incidents affecting the model's behaviour, safety, or security that could impact your product

### 5. AI Governance Representations
- Warranties that the model was developed in accordance with the provider's published responsible AI framework
- Right to audit (or review third-party audit reports) of the provider's AI governance practices

### 6. Liability and Risk Allocation
- Clarity on where liability sits if the LLM produces harmful, biased, or incorrect outputs that cause loss to your customers

---

## Risk Assessment Obligations Under Clause 6.1.2

Even though the LLM is a third-party component, you must include **third-party LLM risks** in your own AI risk assessment (Clause 6.1.2). These supply chain risks are explicitly listed in ISO 42001's risk framework:

| Risk | Description | Treatment Options (Clause 6.1.3) |
|------|-------------|----------------------------------|
| **Inherited model bias** | The LLM has biases from its training data that manifest in your product | Test your use case for bias; implement output filters; document known limitations; transfer risk contractually via A.10.3 |
| **Hallucination** | The LLM produces confident but false outputs | Implement retrieval-augmented generation (RAG); add human review for high-stakes outputs; prompt engineering guardrails |
| **Model drift from provider updates** | Provider updates the model; your product behaviour changes without your action | Pin model versions; implement regression testing on model update; monitor output quality metrics |
| **Provider dependency / continuity risk** | Provider discontinues the model or goes out of business | Architect for model portability; maintain fallback options; assess provider financial stability |
| **Data exposure via API** | Sensitive data sent to the API is retained or used inappropriately | Data minimisation before API calls; review provider data processing terms; DPA in place |
| **Prompt injection / adversarial inputs** | End users manipulate your LLM integration to produce harmful outputs | Input validation; output filtering; system prompt hardening; rate limiting |

---

## AI System Impact Assessment (AISIA) — Clause 6.1.2

Your AISIA for the AI product must reflect the fact that the LLM is a component. Key considerations:
- The LLM's output type (content generation, classification, decision support) affects the impact level of your product
- If the LLM drives decisions or recommendations affecting individuals, this increases impact classification
- Human oversight requirements (Annex A.9.1) must account for the fact that LLM outputs may be unpredictable — formal human review processes are especially important

---

## Practical Implementation Checklist

Under ISO 42001, your supplier management programme for a third-party LLM API should produce the following evidence:

| Evidence | Clause/Control | Status |
|----------|---------------|--------|
| Supplier AI assessment report for LLM provider | A.10.3 | Required |
| Data Processing Agreement (DPA) with LLM provider | A.10.3, A.7 | Required |
| AI-specific contractual clauses documented | A.10.3 | Required |
| LLM risks included in AI risk register | Clause 6.1.2 | Required |
| Third-party LLM included in AISIA scope | Clause 6.1.2 | Required |
| Model version pinning or change monitoring process | A.10.3, A.6 | Required |
| Incident notification process from provider | A.8.4, A.10.3 | Required |
| Annual review of supplier AI assessment | A.10.3, Clause 9 | Required |

---

## Common Gap: What Organisations Typically Miss

The most common gap flagged in ISO 42001 audits for organisations using third-party LLMs is:

1. **No AI-specific supplier assessment** — only a general security questionnaire sent to the provider, with no questions about model governance, bias testing, or training data practices
2. **Data processing terms not reviewed** — assuming the API provider's standard terms are acceptable without reviewing whether API inputs are used for model training
3. **No model version pinning** — using a floating model version endpoint, meaning silent model updates can affect product behaviour
4. **Third-party risks missing from the AI risk register** — the risk register covers internal model risks but treats the third-party LLM as a black box outside the risk management scope

Addressing these four gaps is the minimum required to satisfy A.10.3 in an ISO 42001 audit context.

---

*Response generated using ISO/IEC 42001:2023 AIMS skill — all clauses and Annex A controls cited per the standard.*

# Third-Party LLM API Supplier Management Under ISO 42001 — WITHOUT SKILL Response

## Overview

Using a third-party LLM API (like those from OpenAI or Anthropic) as a component in your AI product creates a layered responsibility model. ISO 42001 recognizes that organizations integrating AI from external providers retain accountability for how that AI behaves in their products — you cannot simply outsource AI governance responsibility to the API provider.

This means you have obligations both as an AI product developer (provider) and as an AI user integrating external AI. Both roles carry distinct but complementary requirements under ISO 42001's supplier management framework.

---

## Core Principle: You Remain Accountable

The foundational principle in ISO 42001's approach to third-party AI is this: **your customers experience your product, not your supplier's API.** If your product produces biased, harmful, or inaccurate outputs because of the underlying LLM's behavior, that is your risk and your responsibility to manage.

This parallels how other management system standards treat outsourcing — ISO 9001, for instance, requires that outsourced processes remain under the organization's quality management system. ISO 42001 applies the same logic to AI: embedding a third-party AI component does not remove the embedding organization's governance obligations.

---

## What ISO 42001 Requires for Third-Party AI Suppliers

### 1. Supplier Assessment Before Integration

Before integrating a third-party LLM API into your product, you should conduct a structured assessment of the AI provider. This goes well beyond a standard security vendor questionnaire. Key areas to assess include:

**AI Governance and Responsible AI Framework**
- Does the provider have a documented responsible AI framework or ethics policy?
- How do they govern what the model can and cannot do?
- What safety testing and red-teaming do they conduct?

**Model Training Data Practices**
- What data was used to train the underlying model?
- Is that training data compliant with applicable data protection laws (GDPR, etc.)?
- Does the provider document their training data sources and quality controls?

**Bias and Fairness Evaluation**
- Has the model been systematically tested for demographic biases?
- Are evaluation results published or available on request?
- What populations were included in bias testing?

**Transparency and Explainability**
- Does the provider publish a system card or model card documenting capabilities, limitations, and known failure modes?
- Are use case restrictions clearly documented?

**Data Handling Practices**
- Are inputs you send via the API used to retrain the provider's models?
- What is the data retention period for API inputs?
- Is there a formal Data Processing Agreement available?

**Incident Response and Communication**
- How does the provider handle and disclose AI-related incidents?
- Do they notify API customers of significant model behavior changes?

### 2. Contractual Provisions

Simply having a supplier assessment is not enough — ISO 42001 requires that your third-party AI obligations are reflected in your contracts with AI providers. Key contractual provisions to seek include:

**Model Versioning and Change Notification**
One of the most significant risks with third-party LLM APIs is that the underlying model can change without notice — what worked and tested well today may behave differently tomorrow if the provider updates the model. Seek contractual commitments for:
- Advance notice of significant model behavior changes (ideally 30+ days)
- The ability to pin to a specific model version while you evaluate updates
- Defined processes for communicating breaking changes

**Data Use Restrictions**
Explicitly address whether your API inputs will be used for the provider's model training. Many providers offer opt-out options or enterprise agreements that prohibit this. Without explicit contractual terms, you may be inadvertently allowing customer data to enter the provider's training pipeline.

**Liability and Risk Allocation**
Define where responsibility lies if the LLM produces harmful, biased, or incorrect outputs that cause harm to your customers. This is an evolving area of law, but having clear contractual language is important for both governance and legal risk management.

**Incident Notification**
Require the provider to notify you within a defined timeframe of incidents that could affect your product — including safety incidents, significant capability regressions, or discovered vulnerabilities in the model.

### 3. Ongoing Monitoring

The supplier relationship doesn't end at contract signature. ISO 42001 expects ongoing monitoring of third-party AI performance, which for an LLM API means:

- **Regression testing**: Periodically test your use case against the API to detect behavioral drift when providers update their models
- **Output monitoring**: Monitor production outputs for quality, bias, and anomalies on an ongoing basis
- **News and disclosure monitoring**: Track provider safety disclosures, incident reports, and policy changes
- **Annual reassessment**: Revisit your supplier assessment periodically, especially if the provider makes significant model changes

---

## Risks You Need to Include in Your Risk Register

When you use a third-party LLM, these AI-specific supply chain risks must appear in your own AI risk assessment:

| Risk | Impact | Mitigation |
|------|--------|-----------|
| Inherited model bias | Your product exhibits discriminatory behavior from the LLM's training data | Test your specific use cases for bias; implement output filtering; document known limitations for users |
| LLM hallucination | Your product confidently provides false information to users | Implement retrieval-augmented generation; add human review for high-stakes outputs; set user expectations clearly |
| Silent model updates | Provider updates the model; your product behavior changes unexpectedly | Pin model versions; implement automated regression testing; monitor production outputs |
| Provider discontinuity | Provider shuts down the model or company; your product loses a critical dependency | Design for model portability; test with alternative providers; avoid single-point API dependency |
| Data exposure via API | Sensitive user data sent to the API is retained or used in ways you didn't intend | Data minimization before API calls; review data terms carefully; implement DPA |
| Prompt injection | End users manipulate your LLM integration to bypass controls or produce harmful outputs | Input validation; output filtering; system prompt hardening; adversarial testing |

---

## What You Cannot Delegate to the LLM Provider

Regardless of your contractual arrangements, certain obligations under ISO 42001 remain yours:

1. **Conducting your own impact assessment** of your AI product — the LLM provider's safety assessments of their base model do not substitute for your assessment of your specific deployment
2. **Implementing human oversight** appropriate for your use case — this is your design choice, not the provider's
3. **Providing transparency to your users** about AI involvement in your product
4. **Incident management for your product** — even if a root cause is a provider model failure, your users experience it as your product's failure
5. **Compliance with applicable regulations** in your sector and jurisdiction

---

## Practical Starting Points

For organizations just beginning to address third-party LLM governance:

1. **Review the provider's published documentation** — system cards, usage policies, data processing terms — and document your review
2. **Assess data handling terms** specifically — determine whether your API inputs are used for training and whether this is acceptable given your customers' data
3. **Move to versioned API endpoints** where the provider offers them, rather than using floating "latest" endpoints
4. **Add AI-specific provisions** to your next contract renewal or data processing agreement
5. **Include third-party LLM risks** in your AI risk register with documented treatment decisions
6. **Implement output monitoring** so you can detect behavioral changes and potential harms before customers escalate them

The regulatory environment around third-party AI liability is evolving quickly, and proactive supplier management positions you well both for ISO 42001 compliance and for the emerging expectations under frameworks like the EU AI Act.

# ISO 42001 Ethical Dimensions: Fairness, Human Oversight, and Accountability — WITH SKILL Response

## ISO 42001's Approach to AI Ethics

ISO/IEC 42001:2023 takes a **management systems approach** to AI ethics — it does not articulate abstract ethical principles alone, but requires organisations to translate ethical commitments into **documented policies, operational controls, measurable objectives, and auditable evidence**. The standard's ethical requirements are grounded in the AIMS structure (Clauses 4–10) and operationalised through specific Annex A controls.

The core ethical dimensions — fairness, human oversight, transparency, and accountability — are addressed through mandatory requirements, not optional guidance.

---

## 1. Fairness and Non-Discrimination

### The Requirement

ISO 42001 addresses fairness primarily through:
- **Clause 5.2 (AI Policy)**: The overarching AI Policy must articulate the organisation's commitment to responsible AI — fairness is a foundational responsible AI principle that must appear in the policy.
- **Clause 6.1.2 (AI Risk Assessment)**: Bias and unfairness are explicitly identified AI-specific risks — the risk assessment must evaluate the likelihood and severity of discriminatory or unfair AI outputs.
- **Clause 6.2 (AI Objectives)**: Fairness objectives must be **measurable** — the standard does not accept "we are committed to fairness" as a sufficient objective. Measurable targets (e.g., demographic parity metrics, false positive rate parity across groups) must be set and tracked.
- **Annex A.7 (Data for AI)**: Training data quality controls address the data-side causes of unfairness — data must be evaluated for representativeness, sampling bias, and the potential for learned discrimination. Training data governance must include **bias evaluation** as a documented step.
- **Annex A.5 (Impacts on interests of individuals and society)**: Requires assessment of whether AI systems produce discriminatory outcomes or outcomes that disproportionately affect specific groups, communities, or vulnerable populations.

### What You Need to Implement

| Requirement | Control | Evidence Required |
|-------------|---------|-----------------|
| Documented commitment to fairness | Clause 5.2, AI Policy | Signed AI Policy containing fairness principles |
| Bias risk identified in risk assessment | Clause 6.1.2 | AI risk register entry for bias/unfairness with likelihood × severity |
| Measurable fairness objectives | Clause 6.2 | AIMS Objectives document with fairness metrics and targets |
| Training data bias evaluation | Annex A.7 | Data quality assessment records, bias testing methodology, test results |
| Impact assessment covering discriminatory outcomes | Clause 6.1.2 AISIA, Annex A.5 | AISIA records documenting fairness analysis for affected populations |
| Ongoing monitoring of fairness metrics | Clause 9 | Performance metrics tracking bias/fairness indicators over time |

### Concrete Example

An organisation developing a CV screening AI must:
1. Document in the AISIA that the system affects employment decisions and that protected characteristics (gender, ethnicity, age) could be adversely impacted
2. Evaluate training data for gender and ethnic representation (A.7)
3. Set a measurable objective: "Achieve demographic parity across gender categories within ±5 percentage points by Q2" (Clause 6.2)
4. Monitor that metric in production and report to management review (Clause 9.3)

---

## 2. Human Oversight

### The Requirement

Human oversight is one of the most distinctive elements of ISO 42001. The standard treats human oversight not as an optional design choice but as a **required control** — particularly for AI systems with higher impact classifications.

**Annex A.9.1 (Human oversight of AI systems)** — the primary control — requires:
- Mechanisms that allow humans to **monitor** AI system outputs
- Mechanisms that allow humans to **intervene** in AI decision-making processes
- Mechanisms that allow humans to **override** AI outputs when necessary
- Documentation of **when and how** human oversight is exercised

**Clause 6.1.2 (AISIA)** links human oversight to impact level:
| Impact Level | Human Oversight Requirement |
|-------------|----------------------------|
| Low | Standard controls — basic monitoring sufficient |
| Medium | Enhanced oversight — human review of sample outputs; escalation process |
| High | Maximum controls — mandatory human review before AI output is acted upon; formal right to challenge AI decisions; documented intervention records |

**Clause 5 (Leadership)**: Top management must ensure that human oversight responsibilities are assigned and resourced — it is not sufficient to have technical monitoring without organisational accountability.

### What You Need to Implement

1. **Human oversight policy or procedure**: Document for each AI system: who is responsible for oversight, what they review, how often, and what the escalation/override process is
2. **Human-in-the-loop design records**: Evidence that the AI system was designed with oversight mechanisms (e.g., system architecture documentation, UI design records showing how human reviewers interact with AI outputs)
3. **Override and intervention records**: Logs demonstrating that human oversight is being exercised — not just that the mechanism exists. For high-impact systems, records of individual review decisions
4. **Training for human reviewers**: Competence records (Clause 7.2) showing that people performing oversight understand AI limitations, when to intervene, and how to document interventions
5. **Automation bias awareness**: Training that addresses the risk that humans defer inappropriately to AI recommendations (linked to Clause 7.3 — awareness)

### Concrete Example

A healthcare AI that generates diagnostic recommendations (high-impact) must have:
- A clinician review step before the AI recommendation is shown to the patient or used in treatment planning
- A process for the clinician to document their agreement with, modification of, or rejection of the AI recommendation
- Training records showing clinicians understand when to distrust AI outputs and how to exercise override
- Monitoring metrics tracking the rate at which clinicians override AI recommendations (an unusual rate — either very high or very low — may indicate a problem)

---

## 3. Accountability

### The Requirement

Accountability under ISO 42001 is built into the management system structure itself — it is the mechanism by which ethical commitments are made enforceable and auditable.

**Clause 5 (Leadership and accountability):**
- **Clause 5.1**: Top management is personally accountable for AIMS effectiveness — they cannot delegate accountability, only authority
- **Clause 5.3**: Roles and responsibilities for AI governance must be documented (RACI or equivalent) — every AI system must have an identified owner who is accountable for its governance
- AI Policy must be signed by top management — creating explicit ownership of the ethical commitments in the policy

**Clause 6.1.2 (AI Risk Assessment)**: Every AI-specific risk must have a named risk owner who is accountable for implementing the treatment decision.

**Clause 9.3 (Management review)**: Top management must periodically review AIMS performance — including AI incidents, objective achievement, and audit findings. This creates a formal accountability loop to leadership.

**Annex A.8.1 (AI system transparency)**: Transparency is the enabler of external accountability — users and affected parties must receive sufficient information about AI system behaviour to exercise their rights (including, in many jurisdictions, the right to challenge automated decisions).

**Annex A.8.4 (AI incident detection and response)**: When AI systems cause harm or unexpected outcomes, there must be a documented incident management process — including root cause analysis, corrective action, and disclosure. This creates accountability for AI failures.

**Clause 10 (Continual improvement)**: Nonconformity records and corrective action records create an audit trail of when the organisation fell short of its AI governance commitments and what it did about it.

### Accountability Documentation Required

| Accountability Mechanism | Clause/Control | Evidence |
|-------------------------|---------------|---------|
| AI system register with named owners | Clause 4 | AI system register with owner column |
| RACI for AI governance roles | Clause 5.3 | RACI matrix or role descriptions |
| Signed AI Policy | Clause 5.2 | AI Policy document with CEO/board signature |
| Risk owner assignment | Clause 6.1.2 | Risk register with risk owner column |
| Management review minutes | Clause 9.3 | Meeting minutes with AI performance discussion |
| AI incident log with root cause analysis | Annex A.8.4 | Incident register, RCA records, corrective actions |
| Nonconformity and corrective action records | Clause 10.2 | Corrective action log |

---

## 4. Transparency (the enabler of all three)

**Annex A.8.1 (AI system transparency)** requires that information about AI systems is made available to those who interact with or are affected by them. Transparency obligations scale with impact level:

- **Low impact**: Basic disclosure that AI is being used
- **Medium impact**: Information about the AI system's purpose, capabilities, and limitations
- **High impact**: Full disclosure — how the AI system works, what data it uses, how affected individuals can seek review or challenge decisions

For AI providers (developers), this means:
- Producing **system cards or model documentation** covering intended purpose, limitations, known failure modes, and use case restrictions
- Communicating AI involvement in decisions to end users
- Providing mechanisms for end users to request human review (for high-impact decisions)

---

## 5. How These Requirements Interconnect

The ethical requirements in ISO 42001 are not siloed — they form a system:

```
AI Policy (Clause 5.2)
    → Sets ethical commitments (fairness, oversight, accountability)
    
AISIA (Clause 6.1.2)
    → Classifies impact → determines stringency of ethical controls required

AI Risk Assessment (Clause 6.1.2)
    → Identifies specific fairness/bias risks → drives treatment

Annex A Controls
    → A.7: Training data bias controls (operationalise fairness)
    → A.8.1: Transparency (operationalise accountability)
    → A.9.1: Human oversight (operationalise oversight)
    → A.8.4: Incident management (operationalise accountability for failures)

AIMS Objectives (Clause 6.2)
    → Make ethical commitments measurable and trackable

Management Review (Clause 9.3)
    → Close the accountability loop to top management
```

---

## What ISO 42001 Does NOT Do

It is important to note that ISO 42001:
- Does not prescribe specific fairness metrics — it requires you to define and measure them
- Does not specify what constitutes "adequate" human oversight — this depends on impact level and context
- Does not resolve ethical dilemmas — it provides a governance framework for managing them systematically
- Does not guarantee ethical AI — it demonstrates that an organisation has a systematic approach to governing AI ethically

Certification to ISO 42001 demonstrates that ethical governance processes exist, are implemented, and are continually improved — not that every AI output is perfectly ethical.

---

*Response generated using ISO/IEC 42001:2023 AIMS skill — all clauses and Annex A controls cited per the standard.*

# ISO 42001 AI Ethics: Fairness, Human Oversight, and Accountability — WITHOUT SKILL Response

## ISO 42001's Approach to AI Ethics

ISO 42001 takes a pragmatic, management-systems-based approach to AI ethics. Rather than being a philosophical ethics document, it translates ethical principles into operational requirements — things organizations must actually implement, document, and demonstrate. The goal is to make AI ethics auditable and verifiable, not just aspirational.

The standard recognizes that responsible AI requires more than a policy statement. It requires governance structures, operational processes, measurable objectives, and evidence that ethical commitments are being honored in practice.

---

## Fairness

### How ISO 42001 Addresses Fairness

Fairness is woven throughout the standard, particularly through the impact assessment and data governance requirements.

**AI System Impact Assessment**
Organizations must conduct impact assessments for their AI systems that specifically evaluate whether those systems could produce unfair outcomes — systematically different results for different groups of people based on characteristics like race, gender, age, disability, or other protected characteristics. The assessment must consider:
- Which populations are affected by the AI system's outputs
- Whether certain groups could be disproportionately harmed by errors or biases
- The severity and reversibility of unfair outcomes
- Whether the AI system interacts with vulnerable populations

**Data Governance and Bias Controls**
A significant cause of AI unfairness is training data that doesn't adequately represent all groups, or that reflects historical discrimination. ISO 42001 requires organizations to govern the quality of data used to train AI systems — including evaluating datasets for representativeness and testing for bias before and after training.

**Measurable Objectives**
Critically, ISO 42001 requires that AI governance objectives be measurable. This means organizations cannot just claim a commitment to fairness — they must define specific fairness metrics (like demographic parity, equalized odds, or calibration across groups) and track whether they are achieving them.

**Ongoing Monitoring**
Fairness is not a one-time evaluation. ISO 42001 requires ongoing monitoring of AI system performance, which should include fairness metrics tracked over time. If a model drifts into unfair behavior after deployment, monitoring should detect this.

### What This Means in Practice

For a practical example: an organization using AI for loan origination would need to:
- Assess which demographic groups could be affected by the AI's decisions
- Test training data for racial and gender representation
- Define measurable fairness objectives (e.g., approval rate disparity between demographic groups should be within X%)
- Monitor those metrics in production
- Report fairness performance to senior management

---

## Human Oversight

### Why ISO 42001 Emphasizes Human Oversight

ISO 42001 recognizes that AI systems can fail in unexpected ways, exhibit biases, or make decisions that are consequential for individuals. Human oversight is the mechanism for catching these failures before they cause harm — and for providing accountability when AI is used in decisions that affect people.

The standard links human oversight requirements to the severity of the AI system's impact. The more significant and less reversible the potential harm, the more stringent the human oversight requirements.

### What ISO 42001 Requires for Human Oversight

**Oversight Mechanisms**
AI systems must be designed and deployed with mechanisms that allow humans to:
- **Monitor** what the AI is doing and what outputs it is producing
- **Intervene** when something looks wrong or unexpected
- **Override** AI outputs or decisions when human judgment indicates this is necessary

These are not just nice-to-have features — they must be formally documented, and organizations must demonstrate that these mechanisms are actually being used.

**Appropriate Oversight by Impact Level**
The required intensity of oversight scales with impact:
- For low-stakes AI (internal process automation, low-impact recommendations), monitoring outputs periodically may be sufficient
- For high-stakes AI (decisions affecting individual rights, safety, access to services), human review before action may be required, along with formal documentation of each review

**Training for Human Reviewers**
People responsible for overseeing AI outputs must be competent to do so — they need to understand the AI system's limitations, know what kinds of errors to look for, and understand when to exercise their override authority. ISO 42001 requires that competence for AI-related roles is documented and maintained.

**Guarding Against Automation Bias**
One of the more nuanced requirements is awareness of "automation bias" — the human tendency to defer to AI recommendations without applying independent judgment. ISO 42001's requirements for human oversight are designed to prevent humans from becoming rubber-stamps for AI decisions. Awareness training should specifically address this risk.

### Concrete Example

A court system using AI to assess recidivism risk for sentencing recommendations would need:
- A judge (or qualified reviewer) to formally review every AI-generated risk score before it is used
- Training for judges on the AI system's limitations and known failure modes
- A documented process for judges to record their agreement with, modification of, or rejection of the AI recommendation
- Monitoring of override rates to ensure meaningful human engagement (not just perfunctory review)

---

## Accountability

### How ISO 42001 Creates Accountability

Accountability under ISO 42001 is structural — built into the management system architecture itself.

**Named Ownership of AI Systems**
Every AI system in scope must have an identified owner who is accountable for its governance. This means someone's name is attached to each AI system, they are responsible for its risk assessment, its impact assessment, and its ongoing monitoring. Accountability cannot be diffuse or anonymous.

**Top Management Accountability**
Senior leadership cannot delegate accountability for the AI Management System, only authority. The standard requires top management to:
- Sign and own the AI policy — creating personal accountability for the organization's ethical commitments
- Review AIMS performance periodically — creating an accountability loop that ensures leaders are genuinely engaged with AI governance outcomes
- Ensure adequate resources are provided — preventing AI governance from being an unfunded mandate

**Incident Management and Learning**
When AI systems cause harm or behave unexpectedly, ISO 42001 requires:
- A documented incident response process
- Root cause analysis of what went wrong
- Corrective actions to prevent recurrence
- Records that demonstrate the organization learned from the incident

This creates accountability for AI failures — organizations must demonstrate they investigated, understood, and addressed problems, not just moved on.

**Transparency as External Accountability**
For accountability to be meaningful, affected parties need information. ISO 42001 requires transparency about AI systems — disclosing to users and affected individuals that AI is involved in decisions that affect them, what the system does, and what options they have. For consequential AI decisions, individuals should be able to understand the basis of AI-influenced decisions and request human review.

**Audit Trail**
The documentation requirements in ISO 42001 create an audit trail that makes governance commitments verifiable. An auditor (or regulator) can review:
- What commitments the organization made in its AI policy
- What risks were identified in risk assessments
- What controls were implemented to address those risks
- Whether those controls are working (performance metrics)
- How incidents were handled
- Whether nonconformities were addressed

This audit trail is what turns ethical aspirations into accountable governance.

---

## What ISO 42001's Ethics Requirements Are and Are Not

**What they are:**
- Operational requirements that must be implemented and evidenced
- A framework for making ethical commitments auditable and verifiable
- Requirements that scale with the severity of AI system impacts
- Mechanisms that connect ethical principles to measurable outcomes

**What they are not:**
- A set of specific ethical rules that answer every AI dilemma
- A guarantee of ethically perfect AI outcomes
- A substitute for sector-specific ethical guidance (medical ethics, legal ethics, etc.)
- A purely philosophical framework

The value of ISO 42001's approach is that it forces organizations to translate ethical commitments into processes that can be tested, measured, and improved over time — moving AI ethics from the domain of aspiration into the domain of management.

---

## Integration with External Ethics Frameworks

ISO 42001 does not prescribe a specific ethical theory, but it is designed to be compatible with:
- **OECD AI Principles** (transparency, accountability, robustness, fairness)
- **EU Ethics Guidelines for Trustworthy AI** (human oversight, technical robustness, fairness, accountability)
- **UNESCO AI Ethics Recommendation**
- **NIST AI Risk Management Framework** (which maps closely to ISO 42001's structure)

Organizations implementing ISO 42001 are well-positioned to demonstrate alignment with these broader frameworks, which is increasingly important for regulatory compliance, public trust, and procurement requirements.

# ISO 27701: Extension to ISO 27001 and Certification Pathway

## What Is ISO 27701 and How Does It Extend ISO 27001?

ISO/IEC 27701 is a Privacy Information Management System (PIMS) standard that was specifically designed to help organizations demonstrate compliance with GDPR, UK GDPR, and similar global privacy regulations — this is its primary value proposition. It provides a structured framework for managing personal data (referred to as Personally Identifiable Information, or PII) and defines controls for organizations acting as PII Controllers, PII Processors, or both.

Because you already hold ISO 27001 certification, the most relevant starting point is the **2019 edition extension model**: ISO 27701:2019 was built as a direct extension to ISO 27001:2013 and could not be certified as a standalone standard. ISO 27001 certification was — and in the 2019 edition remains — a mandatory prerequisite. Your existing ISO 27001 certification is therefore not just a head start; it is a required foundation.

The current edition, **ISO 27701:2025** (published 14 October 2025), restructures the standard as a **standalone Privacy Information Management System**. ISO 27001 is no longer a prerequisite in the 2025 edition, though integration remains fully supported and is the most common implementation path for organizations that already hold an ISMS. Most certifications currently in existence are under the 2019 edition; transition to 2025 is required by **October 2028**.

---

## How ISO 27701 Extends ISO 27001

ISO 27001 focuses on **information security** — protecting the confidentiality, integrity, and availability of information assets. ISO 27701 extends this by adding a **privacy dimension**: protecting the rights and freedoms of individuals whose personal data is processed.

| Dimension | ISO 27001 | ISO 27701 Extension |
|-----------|-----------|---------------------|
| Primary focus | Security of information assets | Privacy of PII principals (individuals) |
| Risk perspective | Organizational risk | Harm to individuals |
| Core document | Statement of Applicability (SoA) for ISMS | PIMS SoA covering privacy-specific controls |
| Regulatory alignment | General security frameworks | GDPR, UK GDPR, CCPA, LGPD, and others |
| Controls | ISO 27001 Annex A (93 controls in 2022 edition) | Additional A.1 (controller), A.2 (processor), A.3 (security) controls |

In the 2019 edition, ISO 27701 added:
- **Annex A**: 28 additional controls for PII Controllers
- **Annex B**: 16 additional controls for PII Processors
- Extended the ISO 27001 management system clauses (4–10) with privacy-specific requirements

In the 2025 edition, the structure is:
- **A.1**: 31 controls for PII Controllers
- **A.2**: 18 controls for PII Processors
- **A.3**: 29 shared information security controls (rationalized from the 2019 Clause 6)

---

## What Additional Work Is Required to Achieve ISO 27701 Certification?

Given your ISO 27001 certification, the additional work falls into four areas:

### 1. Establishing Your PIMS Role

Before implementing any controls, you must determine your role:

- **PII Controller**: Your organization determines the purposes and means of processing personal data (e.g., you process employee data or customer data for your own purposes).
- **PII Processor**: You process personal data on behalf of another organization (e.g., you are a SaaS provider or outsourced service acting under customer instructions).
- **Both**: Many organizations act as both a controller (for their own data) and a processor (for customers' data).

Your role determines which Annex A controls you must implement:
- **Controller only**: A.1 (31 controls) + A.3 (29 controls) = 60 controls
- **Processor only**: A.2 (18 controls) + A.3 (29 controls) = 47 controls
- **Both**: A.1 + A.2 + A.3 = 78 controls

### 2. Management System Gap Analysis (Clauses 4–10)

Your ISO 27001 management system provides the structural foundation, but each clause needs privacy-specific additions:

| Clause | What Already Exists (ISO 27001) | What ISO 27701 Adds |
|--------|--------------------------------|----------------------|
| 4 — Context | ISMS scope, interested parties | PIMS scope (must explicitly include PII processing activities), PII data inventory, privacy-focused interested parties (PII principals, regulators, DPA) |
| 5 — Leadership | IS Policy | Privacy Policy (standalone, signed by top management); DPO appointment where required by GDPR Art. 37 |
| 6 — Planning | ISMS risk assessment, SoA | Privacy risk assessment methodology (focused on harm to individuals); PIMS Statement of Applicability (separate SoA covering privacy controls); privacy objectives |
| 7 — Support | Security training records | Privacy-specific awareness training; competence evidence for privacy roles |
| 8 — Operation | ISMS operational controls | Records of Processing Activities (RoPA), DPIA records, Data Subject Rights (DSR) procedures, processor contracts, consent management |
| 9 — Performance | ISMS audit, management review | Privacy KPIs; internal audit of PIMS scope; management review agenda items covering privacy |
| 10 — Improvement | ISMS corrective actions | Privacy nonconformity records; lessons learned from privacy incidents |

### 3. Annex A Privacy Controls Implementation

The privacy-specific controls are the core of the certification work. Key areas to address:

**For PII Controllers (Annex A.1):**

| Domain | Controls | Key Deliverables |
|--------|----------|-----------------|
| A.1.2 — Conditions for Collection and Processing | A.1.2.2–A.1.2.9 | Lawful basis register per processing activity, consent management mechanism, Records of Processing Activities (RoPA), DPIA process, DPAs with all processors |
| A.1.3 — Obligations to PII Principals | A.1.3.2–A.1.3.11 | Data Subject Rights procedure with SLAs, Privacy Notice, consent withdrawal mechanism, automated decision-making disclosure |
| A.1.4 — Privacy by Design and by Default | A.1.4.2–A.1.4.10 | Data minimisation procedures, retention schedules, secure disposal, de-identification process, PII transmission controls |
| A.1.5 — PII Sharing, Transfer and Disclosure | A.1.5.2–A.1.5.5 | International transfer mechanism documentation (SCCs, adequacy decisions), transfer log |

**For PII Processors (Annex A.2):**

| Domain | Controls | Key Deliverables |
|--------|----------|-----------------|
| A.2.2 — Conditions for Collection and Processing | A.2.2.2–A.2.2.7 | Customer DPAs, processing-under-instructions procedure, per-controller processing records |
| A.2.3 — Obligations to PII Principals | A.2.3.2 | Process for handling DSR inquiries received directly from individuals |
| A.2.4 — Privacy by Design and by Default | A.2.4.2–A.2.4.4 | Data return/disposal procedure at contract end, PII transmission controls |
| A.2.5 — PII Sharing, Transfer and Disclosure | A.2.5.2–A.2.5.9 | Sub-processor disclosure list, sub-processor authorization process, controller notification of sub-processor changes |

**For All Organizations (Annex A.3 — Security Controls):**

Since you hold ISO 27001, the 29 A.3 security controls are largely covered by your existing ISMS controls. The primary task is to **map and cross-reference** your existing ISMS evidence to the A.3 control IDs in the PIMS SoA — no new implementation work is typically needed. For example:
- A.3.25 (Logging) maps to your ISMS A.8.15/A.8.16 controls
- A.3.26 (Cryptography) maps to your ISMS A.8.24 controls
- A.3.11/A.3.12 (Incident Management) maps to your ISMS A.5.24–5.28 controls

### 4. Documentation to Produce for Certification

| Document | Clause | Notes |
|----------|--------|-------|
| PIMS Scope | 4.3 | Separate from ISMS scope; must explicitly describe PII processing activities |
| Privacy Policy | 5.2 | Signed by top management; may be separate from IS Policy or combined with privacy section |
| Privacy Risk Assessment | 6.1 | Focused on harm to individuals (not just organizational risk); documents threats to PII principals |
| Privacy Risk Treatment Plan | 6.1 | Controls selected from A.1/A.2 to mitigate privacy risks |
| PIMS Statement of Applicability (SoA) | 6.1 | Covers all A.1, A.2, and A.3 controls; justifies exclusions; references evidence |
| Records of Processing Activities (RoPA) | 8 | Complete register of all processing activities; must cover purposes, categories, lawful basis, transfers |
| Data Subject Rights Procedure | 8 | Covers all DSR types (access, erasure, portability, objection, rectification, restriction, automated decision-making); documented SLAs |
| DPIA Procedure and Records | 8 | Trigger criteria, methodology, completed DPIA records for high-risk processing |
| Processor Contracts (DPAs) | 8 | Required for all third parties processing PII on your behalf |
| Privacy Training Records | 7.3 | Role-based privacy training; records of completion |
| Consent Management Records | 8 | Where consent is a lawful basis: how consent is obtained, recorded, and withdrawn |
| Privacy Incident Response Records | 8 | Records of personal data breach investigation and notification |

### 5. Certification Process

For organizations already certified under ISO 27001, the ISO 27701 certification audit is typically conducted **jointly with the ISO 27001 surveillance or recertification audit**. Your existing certification body can usually extend their scope to include ISO 27701.

**Typical steps:**
1. Gap analysis against ISO 27701 privacy controls
2. Implement missing controls and produce required documentation
3. Internal audit of the PIMS
4. Management review covering privacy outputs
5. Stage 1 audit (document review by certification body)
6. Stage 2 audit (on-site evidence review)
7. Certification issued covering both ISO 27001 and ISO 27701

---

## Key Priority Areas

Based on common gap patterns, prioritize these areas first:

1. **Records of Processing Activities (RoPA)** — Does a complete, current RoPA exist covering all processing activities with lawful basis documented?
2. **Data Subject Rights procedure** — Is there a documented, tested procedure with response SLAs (72 hours for breaches, 30 days for most DSRs under GDPR)?
3. **Consent management** — Is the lawful basis documented for every processing activity? Where consent is the basis, is there a working withdrawal mechanism?
4. **DPIA process** — Is there a documented DPIA trigger and methodology, and have DPIAs been completed for all high-risk processing?
5. **Processor contracts** — Do all third-party processors have compliant DPAs in place?
6. **Privacy Policy** — Is there a standalone Privacy Policy signed by top management?

---

## Note on ISO 27701:2025 Transition

If you certify under the 2019 edition now, you will need to transition to the 2025 edition by **October 2028**. The 2025 edition adds a small number of new controls (A.1.4.6 De-identification, A.1.4.8 Retention, A.1.4.9 Disposal, A.1.4.10 PII Transmission Controls for controllers; A.2.4.4 and A.2.5.8–A.2.5.9 for processors) and restructures the security controls into Table A.3.

If you are beginning implementation now, you may choose to target the 2025 edition directly to avoid a transition audit — discuss this with your certification body.

# ISO 27701 and Its Extension of ISO 27001

## What Is ISO 27701?

ISO/IEC 27701:2019 is an international privacy information management standard published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). It is formally titled "Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management — Requirements and guidelines."

ISO 27701 establishes requirements and provides guidance for a Privacy Information Management System (PIMS). It is designed to help organizations manage personal data (referred to in the standard as Personally Identifiable Information, or PII) in a structured, risk-based manner. It applies to organizations that act as PII controllers, PII processors, or both.

The standard was developed in part to provide a privacy-specific framework that could be mapped to global privacy regulations such as the EU General Data Protection Regulation (GDPR), and it serves as a bridge between information security management and privacy management.

---

## How ISO 27701 Extends ISO 27001

ISO 27701 is explicitly designed as an extension to ISO 27001 — it cannot stand alone. It extends both ISO 27001 (requirements) and ISO 27002 (controls guidance) in the following ways:

### 1. Scope Extension
ISO 27001 focuses on protecting the confidentiality, integrity, and availability of information assets in general. ISO 27701 narrows and deepens this focus specifically on the processing of PII, incorporating privacy principles such as purpose limitation, data minimization, and individual rights management.

### 2. Additional Requirements to Clause Structure
ISO 27701 maps to the same high-level structure (HLS/Annex SL) as ISO 27001. For each clause of ISO 27001 (Clauses 4–10), ISO 27701 adds privacy-specific requirements:

- **Clause 4 (Context):** Organizations must additionally identify PII principals (data subjects), PII controllers and processors relevant to the organization, and applicable privacy legislation and regulation.
- **Clause 5 (Leadership):** Top management must demonstrate commitment to privacy, including establishing a privacy policy and assigning privacy roles (e.g., a Privacy Officer or equivalent).
- **Clause 6 (Planning):** Risk assessments must be extended to cover privacy risks, including risks to PII principals. Privacy objectives must be established.
- **Clause 7 (Support):** Awareness and competence requirements extend to privacy-specific knowledge.
- **Clause 8 (Operation):** Operational controls must address the full PII processing lifecycle.
- **Clause 9 (Performance Evaluation):** Monitoring and auditing must cover privacy management performance.
- **Clause 10 (Improvement):** Nonconformities must be assessed for privacy impact; corrective actions must address privacy breaches.

### 3. Additional Control Sets (Annexes)
ISO 27701 introduces new privacy-specific control sets in its annexes, which supplement the controls in ISO 27002 Annex A:

- **Annex A:** Additional controls for PII controllers
- **Annex B:** Additional controls for PII processors
- **Annex C:** Mapping to ISO 29100 (Privacy Framework)
- **Annex D:** Mapping to GDPR
- **Annex E:** Mapping to ISO 29151
- **Annex F:** Mapping to ISO 27018

These annexes provide specific guidance on obligations such as consent management, data subject rights, purpose limitation, data minimization, third-party sharing, and cross-border data transfers.

---

## Additional Work Required for ISO 27701 Certification (Given Existing ISO 27001 Certification)

Being ISO 27001 certified provides a strong foundation, as ISO 27701 inherits and builds on the entire ISO 27001 management system. However, significant additional work is still required. Below is a structured breakdown.

### 1. Gap Assessment
Conduct a formal gap assessment comparing your current ISMS against ISO 27701 requirements. This should cover:
- All extended clause requirements (4–10)
- All applicable Annex A controls (if you are a PII controller)
- All applicable Annex B controls (if you are a PII processor)
- Both sets if you act in dual capacity

### 2. Scope Definition for PIMS
Define the scope of your Privacy Information Management System (PIMS). This should specify:
- Which systems and processes involve PII processing
- The categories of PII principals (e.g., customers, employees, users)
- Whether the organization acts as a controller, processor, or both
- Applicable privacy regulations (e.g., GDPR, CCPA, LGPD)

### 3. Privacy Policy Development
Develop or update a privacy policy that is distinct from (but aligned with) your information security policy. This policy must reflect the organization's commitment to PII protection, articulate privacy principles, and be approved by top management.

### 4. PII Inventory and Data Mapping
Create or formalize a comprehensive PII inventory (sometimes called a data map or Record of Processing Activities under GDPR). This should document:
- What PII is collected and processed
- Purposes of processing
- Legal bases for processing
- Retention periods
- Data flows (including third-party transfers)
- Categories of PII principals

### 5. Extended Privacy Risk Assessment
Extend your existing ISO 27001 risk assessment methodology to include:
- Privacy-specific threats and vulnerabilities
- Risks to PII principals (not just the organization)
- Assessment of likelihood and impact from the perspective of data subjects
- Privacy risk treatment options

### 6. PII Controller Controls (Annex A)
If you act as a PII controller, implement the Annex A controls, which include:
- **A.7.2:** Identifying lawful bases for PII processing
- **A.7.3:** Determining when and how consent is obtained
- **A.7.4:** Privacy notice/transparency requirements
- **A.7.5:** Providing privacy choices and opt-out mechanisms
- **A.7.6–7.8:** PII principal rights (access, correction, deletion, portability, objection)
- **A.7.9:** PII principal complaint handling
- **A.7.10:** Automated decision-making controls
- **A.7.11:** Data minimization controls
- **A.7.12:** Purpose limitation and de-identification
- **A.7.13–7.14:** Data accuracy and retention/disposal
- **A.7.15–7.16:** Cross-border transfer restrictions and controls
- **A.7.17:** Disclosure of PII to third parties

### 7. PII Processor Controls (Annex B)
If you act as a PII processor, implement the Annex B controls, including:
- **B.8.1:** Agreements with PII controllers (contract terms)
- **B.8.2:** Ensuring purpose limitation as instructed
- **B.8.3:** Marketing and advertising restrictions
- **B.8.4:** Infringing instructions handling
- **B.8.5:** PII principal rights support for the controller
- **B.8.6:** Disclosure restrictions
- **B.8.7–8.8:** Sub-processing controls
- **B.8.9:** Record of PII processing activities
- **B.8.10–8.11:** PII security controls, data breach notifications to controllers
- **B.8.12:** Data return and deletion upon contract termination

### 8. Third-Party and Supply Chain Privacy Management
Extend your supplier/vendor management procedures to include privacy requirements. Ensure that:
- Data processing agreements (DPAs) are in place with all sub-processors and suppliers
- Privacy obligations flow down through the supply chain
- Third-party privacy performance is monitored

### 9. Data Subject Rights Procedures
Develop formal, documented procedures for handling data subject rights requests, including:
- Access requests (Subject Access Requests)
- Rectification requests
- Erasure requests (right to be forgotten)
- Data portability requests
- Objection and restriction of processing requests
- Defined response timelines aligned with applicable law

### 10. Consent Management
Implement mechanisms for obtaining, recording, and managing consent where it is the legal basis for processing. This includes:
- Granular consent capture
- Withdrawal of consent mechanisms
- Audit trails of consent

### 11. Privacy by Design and by Default
Embed privacy considerations into the design of systems, products, and processes. Document how privacy-by-design principles are applied during system development and procurement (often linked to your SDLC process).

### 12. Privacy Impact Assessments (PIAs / DPIAs)
Establish a formal PIA/DPIA methodology and process. Define triggers, methodology, documentation requirements, and review cadence. ISO 27701 requires that high-risk processing activities be subject to privacy risk assessment.

### 13. Data Breach Notification Procedures
Update or create incident response procedures specifically for PII breaches, including:
- Internal escalation paths
- Notification timelines to regulators (if applicable)
- Notification obligations to affected individuals
- Coordination with PII controllers (if acting as processor)

### 14. Training and Awareness
Develop and deliver privacy-specific training for employees, including:
- Privacy principles and the organization's obligations
- Handling of PII in daily operations
- Recognizing and reporting privacy incidents
- Data subject rights handling

### 15. Statement of Applicability (SoA) Extension
Extend your existing ISO 27001 Statement of Applicability to include ISO 27701 controls (Annex A and/or B), with justifications for inclusion or exclusion of each control.

### 16. Internal Audit Extension
Extend your internal audit program to include ISO 27701 requirements and controls. Auditors must have privacy-specific competence.

### 17. Management Review Extension
Update your management review agenda to include privacy management performance, including PII breach statistics, data subject rights metrics, and privacy risk status.

### 18. Certification Audit
Engage an accredited certification body (CB) that offers ISO 27701 certification. The audit will typically be conducted in conjunction with an ISO 27001 surveillance or recertification audit, though it can also be conducted separately. The CB will perform:
- Stage 1: Documentation review
- Stage 2: On-site/remote audit of implementation effectiveness

---

## Summary Timeline and Effort Estimate

| Phase | Activity | Typical Effort |
|---|---|---|
| 1 | Gap assessment | 2–4 weeks |
| 2 | Scope definition and PII inventory | 4–8 weeks |
| 3 | Policy and procedure development | 4–8 weeks |
| 4 | Control implementation (Annex A/B) | 8–16 weeks |
| 5 | Risk assessment extension | 2–4 weeks |
| 6 | Training and awareness | Ongoing |
| 7 | Internal audit | 2–4 weeks |
| 8 | Management review | 1 week |
| 9 | Certification audit | As scheduled with CB |

Organizations with a mature ISO 27001 ISMS typically require 6–12 months of additional work to achieve ISO 27701 certification, depending on the size of the organization, complexity of PII processing activities, and readiness of privacy practices.

---

## Key Takeaway

ISO 27701 does not replace ISO 27001 — it extends it. Your existing ISMS provides the management system foundation (policies, risk assessment, internal audit, management review, corrective action), and ISO 27701 adds a privacy-specific layer on top. The incremental investment is significant but leverages everything already in place.

# ISO 27701 to GDPR Mapping

## How ISO 27701 Supports GDPR Compliance

ISO 27701 was specifically designed to help organizations demonstrate compliance with GDPR, UK GDPR, and similar global privacy regulations — this alignment is the core purpose of the standard. ISO 27701:2025 includes an updated correspondence annex (based on the 2019 edition's Annex D GDPR mapping) that maps controls directly to GDPR articles. The mapping works in both directions: GDPR articles map to ISO 27701 controls, and ISO 27701 controls address specific GDPR obligations.

However, an important caveat must be understood from the outset: **ISO 27701 certification is not a GDPR safe harbor**. Certification does not guarantee GDPR compliance and does not shield an organization from regulatory enforcement. What it does provide is strong documented evidence of Article 24/32 technical and organisational measures (TOMs) and accountability documentation under Article 5(2). This is covered in detail at the end of this document.

---

## GDPR Article 5 Principles → ISO 27701 Controls

GDPR Article 5 establishes the core data protection principles. Every processing activity must comply with all six principles, plus the accountability meta-principle.

| GDPR Principle | Article 5 | ISO 27701:2025 Controls | How the Control Addresses the Principle |
|---------------|-----------|------------------------|----------------------------------------|
| Lawfulness, fairness, transparency | Art. 5(1)(a) | A.1.2.3 (Identify Lawful Basis), A.1.3.3–A.1.3.4 (Transparency Notices) | Documents the lawful basis per activity; requires provision of information to individuals before or at collection |
| Purpose limitation | Art. 5(1)(b) | A.1.2.2 (Identify and Document Purpose), A.1.4.3 (Limit Processing) | Requires purposes to be stated before collection; prohibits secondary use without additional legal basis |
| Data minimisation | Art. 5(1)(c) | A.1.4.2 (Limit Collection), A.1.4.5 (PII Minimisation) | Requires collecting only data necessary for the stated purpose; systematic minimisation review in SDLC |
| Accuracy | Art. 5(1)(d) | A.1.4.4 (Accuracy and Quality), A.1.3.7 (Correction) | Requires data quality controls; requires correction mechanisms for individuals |
| Storage limitation | Art. 5(1)(e) | A.1.4.8 (Retention), A.1.4.9 (Disposal), A.1.4.6 (De-identification and Deletion) | Requires defined retention schedules per data category; secure disposal at end of retention period |
| Integrity and confidentiality | Art. 5(1)(f) | A.3.26 (Cryptography), A.3.25 (Logging), A.3.9 (Access Rights) | Encryption at rest and in transit; access logging; least-privilege access to PII systems |
| Accountability | Art. 5(2) | A.1.2.9 (RoPA), SoA, Privacy Risk Assessment, Management Review | Records of processing demonstrate accountability; SoA documents control selection; management review evidences governance |

---

## GDPR Articles 6–22: Controller Obligations → ISO 27701 Controls

### Lawful Basis and Consent (Articles 6–9)

| GDPR Obligation | Article | ISO 27701:2025 Controls | Gap / Limitation |
|----------------|---------|------------------------|-----------------|
| Lawful basis for processing | Art. 6 | A.1.2.3 | ISO 27701 requires lawful basis to be documented; but identifying the correct basis (especially legitimate interests) requires legal judgment beyond the standard |
| Consent requirements | Art. 7 | A.1.2.4 (Determine Consent), A.1.2.5 (Obtain and Record Consent) | Standard requires compliant consent mechanisms; but GDPR's definition of freely given, specific, informed, and unambiguous consent requires legal interpretation in context |
| Conditions for consent — children | Art. 8 | A.1.2.4, A.1.2.5 | ISO 27701 does not have a dedicated control for children's consent — this is a gap where GDPR goes beyond the standard |
| Special categories of data | Art. 9 | A.1.2.3 (identify explicit consent), A.1.2.6 (DPIA for sensitive data), A.1.4.5 (PII minimisation) | No dedicated special category control; organizations must apply stricter lawful basis requirements under GDPR Art. 9(2) as a matter of legal compliance |

### Transparency (Articles 13–14)

| GDPR Obligation | Article | ISO 27701:2025 Controls | Notes |
|----------------|---------|------------------------|-------|
| Information to be provided at collection | Art. 13 | A.1.3.3 (Information for PII Principals), A.1.3.4 (Providing Information) | Controls require provision of required information before or at collection |
| Information to be provided when data not obtained from subject | Art. 14 | A.1.3.3, A.1.3.4 | Same controls apply; the content of the notice differs |

### Individual Rights (Articles 15–22)

These controls map to the A.1.3 domain (Obligations to PII Principals):

| GDPR Right | Article | ISO 27701:2025 Controls | Gap / Limitation |
|-----------|---------|------------------------|-----------------|
| Right of access | Art. 15 | A.1.3.9 (Providing Copy of PII), A.1.3.10 (Handling Requests) | Controls require access procedures and SLAs; GDPR's one-month response time is a legal requirement not specified in the standard |
| Right to rectification | Art. 16 | A.1.3.7 (Access, Correction or Erasure), A.1.3.8 (Inform Third Parties) | Controls require correction mechanisms and notification of third parties |
| Right to erasure (right to be forgotten) | Art. 17 | A.1.3.7, A.1.4.6 (De-identification and Deletion), A.1.4.9 (Disposal) | Controls require deletion procedures; GDPR's exceptions to the right to erasure require legal judgment |
| Right to restriction of processing | Art. 18 | A.1.3.6 (Object to PII Processing), A.1.3.10 (Handling Requests) | Controls require restriction mechanisms; GDPR's specific grounds for restriction go beyond control guidance |
| Right to data portability | Art. 20 | A.1.3.9 (Providing Copy of PII) | ISO 27701 covers portability broadly; GDPR specifically requires structured, commonly used, machine-readable format |
| Right to object | Art. 21 | A.1.3.6 (Object to PII Processing) | Controls require objection mechanism; GDPR's balancing test for legitimate interests overrides requires legal judgment |
| Rights re: automated decision-making and profiling | Art. 22 | A.1.3.11 (Automated Decision Making) | Controls require disclosure and appeal mechanism; GDPR's specific conditions for lawful automated decisions require legal analysis |

### Accountability and Governance (Articles 24–30)

| GDPR Obligation | Article | ISO 27701:2025 Controls | Notes |
|----------------|---------|------------------------|-------|
| Responsibility of the controller — TOMs | Art. 24 | All A.1 and A.3 controls | ISO 27701 SoA and certification serve as evidence of TOMs |
| Data protection by design and by default | Art. 25 | A.1.4.2–A.1.4.10 (Privacy by Design domain) | The entire A.1.4 domain addresses Art. 25; certification provides strong evidence |
| Joint controllers | Art. 26 | A.1.2.8 (Joint PII Controller) | Control requires documented joint controller arrangement; GDPR requires the arrangement to be made available to data subjects |
| Processor contracts | Art. 28 | A.1.2.7 (Contracts with PII Processors) | Control requires written DPA with all processors; GDPR Art. 28(3) specifies mandatory DPA clauses |
| Records of processing activities | Art. 30 | A.1.2.9 (Records of Processing PII) | Direct mapping; RoPA is a mandatory deliverable under both |

### DPO, DPIA, and Breach (Articles 33–37)

| GDPR Obligation | Article | ISO 27701:2025 Controls | Gap / Limitation |
|----------------|---------|------------------------|-----------------|
| Data Protection Impact Assessment | Art. 35 | A.1.2.6 (Privacy Impact Assessment) | Direct mapping; ISO 27701 requires DPIAs for high-risk processing; GDPR specifies mandatory consultation with supervisory authority where DPIA shows high residual risk |
| Prior consultation with supervisory authority | Art. 36 | A.1.2.6 (indirectly) | GDPR requires supervisory authority consultation in certain cases; ISO 27701 does not explicitly mandate this |
| Data Protection Officer | Art. 37–39 | Clause 5 (Leadership roles and responsibilities) | ISO 27701 Clause 5 requires privacy roles; GDPR mandates DPO appointment in specific circumstances (public authority, large-scale monitoring, special category data) |
| Personal data breach notification (controller to SA) | Art. 33 | A.3.11 (Incident Management), A.3.12 (Security Incident Response) | Controls require breach response; GDPR's 72-hour notification window is a legal requirement |
| Personal data breach notification (controller to subjects) | Art. 34 | A.3.11, A.3.12 | Controls require notification; GDPR specifies risk thresholds for subject notification |

### International Transfers (Articles 44–49)

| GDPR Obligation | Article | ISO 27701:2025 Controls | Notes |
|----------------|---------|------------------------|-------|
| General principle for transfers | Art. 44 | A.1.5.2 (Basis for PII Transfer) | Requires documented transfer mechanism per transfer |
| Adequacy decision transfers | Art. 45 | A.1.5.2 | Adequacy decision documented as transfer basis |
| Transfers with appropriate safeguards (SCCs, BCRs) | Art. 46 | A.1.5.2, A.1.5.3 | SCCs/BCRs documented; countries of transfer recorded |
| Transfer records | Art. 30 (Art. 30(1)(e)) | A.1.5.4 (Records of PII Transfer), A.1.5.5 (Records of PII Disclosures) | Transfer log maintained |

---

## GDPR Article 28: Processor Obligations → ISO 27701 Controls

GDPR Article 28 governs the obligations of data processors. ISO 27701's A.2 (Processor Controls) maps directly to these requirements:

| GDPR Art. 28 Obligation | Article | ISO 27701:2025 Controls | ISO 27701 Term |
|------------------------|---------|------------------------|----------------|
| Processing under written contract | Art. 28(3) | A.2.2.2 (Customer Agreement) | "processing under controller authority" |
| Processing only on controller instruction | Art. 28(3)(a) | A.2.2.3, A.2.2.5 | A.2.2.5 requires notification if instruction would infringe law |
| Confidentiality of processing | Art. 28(3)(b) | A.3.18 (Confidentiality Agreements), A.2.2.6 | Confidentiality agreements for all staff with PII access |
| Security measures | Art. 28(3)(c) | A.3 (all 29 security controls) | All A.3 controls contribute |
| Sub-processor controls | Art. 28(2), (4) | A.2.5.7 (Disclosure), A.2.5.8 (Engagement), A.2.5.9 (Change) | "sub-processor notification and consent" (A.2.2.6); "sub-processor contracts" (A.2.5.8) |
| Assist controller with data subject rights | Art. 28(3)(e) | A.2.2.6, A.2.3.2 | "PII subject rights assistance obligations" (A.2.3.3) |
| Deletion or return at end of contract | Art. 28(3)(g) | A.2.4.3 (Return, Transfer or Disposal of PII) | |
| Provide information / allow audits | Art. 28(3)(h) | A.2.2.6 | Processor must provide information to enable controller compliance verification |
| Records of processing (processor RoPA) | Art. 30(2) | A.2.2.7 (Records of Processing PII) | Per-controller processing records |
| Notify controller of breaches | Art. 33(2) | A.3.11, A.3.12 | Processor breach notification feeds controller's 72-hour GDPR obligation |
| Law enforcement disclosure — notify controller | Art. 28(3)(a) | A.2.5.5 (Notification of PII Disclosure Requests), A.2.5.6 (Legally Binding PII Disclosures) | |

---

## Where GDPR Goes Beyond ISO 27701 — Identified Gaps

While ISO 27701 provides excellent coverage, there are areas where GDPR requires more than the standard alone can address:

| Gap Area | GDPR Requirement | ISO 27701 Coverage |
|----------|-----------------|-------------------|
| DPO mandatory appointment | GDPR Art. 37 — mandatory DPO for public authorities, large-scale monitoring, special categories | ISO 27701 Clause 5 requires privacy roles but does not mandate DPO appointment |
| Children's consent | GDPR Art. 8 — parental consent for under-16s (or national lower age) | No dedicated control; must be addressed through A.1.2.4/A.1.2.5 |
| Special category lawful basis | GDPR Art. 9(2) — specific grounds (explicit consent, employment law, vital interests, etc.) | No dedicated control; A.1.2.3 requires lawful basis but the specific Art. 9(2) grounds require legal judgment |
| Supervisory authority consultation | GDPR Art. 36 — mandatory prior consultation after DPIA shows high residual risk | Not explicitly in A.1.2.6 |
| Portability format requirement | GDPR Art. 20 — structured, commonly used, machine-readable format | A.1.3.9 covers the right but not the specific format requirement |
| Legal basis for national derogations | GDPR recitals and member state laws | Not within scope of international standard |
| Supervisory authority cooperation | GDPR Art. 31 | Not addressed in ISO 27701 |
| Binding corporate rules | GDPR Art. 47 | No dedicated control; BCRs referenced through A.1.5.2 |

---

## What ISO 27701 Certification Provides for GDPR Compliance

In practical terms, achieving ISO 27701 certification gives you:

1. **Evidence of Article 24/32 Technical and Organisational Measures (TOMs)**: The SoA and certification report are strong evidence that your organization has implemented appropriate privacy controls — directly addressing the accountability requirement.

2. **Accountability documentation under Article 5(2)**: The PIMS management system (risk assessments, management reviews, internal audits, SoA) creates the paper trail that regulators expect to see when demonstrating the accountability principle.

3. **Recognized framework**: EU supervisory authorities and the UK ICO view ISO 27701 favorably as evidence of commitment to data protection. It will be considered positively in any regulatory investigation or enforcement action.

4. **Structured compliance programme**: The PIMS provides the systematic, documented approach that regulators expect — as opposed to ad hoc compliance measures.

5. **GDPR Art. 28 processor assurance**: If you are also a processor, ISO 27701 certification provides your controller clients with recognized evidence that you meet Art. 28 requirements — often reducing the need for individual audit rights.

---

## Summary Assessment

ISO 27701:2025's mapping to GDPR is comprehensive and covers the majority of GDPR obligations at a control level. It is strongest in the areas of accountability, transparency, data subject rights, data minimisation, security, and processor contract requirements. The gaps are relatively narrow — principally around DPO mandatory appointment, children's consent, special category processing, and specific supervisory authority interactions — and require supplementary legal and regulatory work alongside the standard implementation.

Treat ISO 27701 as the backbone of your GDPR compliance programme, not as a substitute for legal analysis. The combination of ISO 27701 certification plus legal review of the identified gaps provides the strongest overall GDPR compliance posture.

# ISO 27701 to GDPR Mapping

## Overview

ISO 27701 was designed with GDPR compliance firmly in mind. Annex D of the standard provides an explicit mapping between ISO 27701 clauses and controls and GDPR articles. This mapping demonstrates that achieving ISO 27701 certification provides substantial structural support for GDPR compliance, although it does not constitute legal proof of full GDPR compliance by itself.

The table below maps key GDPR obligations to the corresponding ISO 27701 requirements and controls. Following the table is a narrative analysis of the scope, depth, and limitations of this mapping.

---

## Mapping Table: GDPR Articles to ISO 27701

| GDPR Article | GDPR Obligation | ISO 27701 Clause / Control |
|---|---|---|
| Art. 5 | Principles of processing (lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity & confidentiality, accountability) | Clauses 5.2, 6.1.2, 7.2; Annex A.7.2 (lawfulness), A.7.4 (transparency), A.7.11 (minimization), A.7.12 (purpose limitation), A.7.13 (accuracy), A.7.14 (retention/disposal) |
| Art. 6 | Lawful basis for processing | Annex A.7.2.1–A.7.2.8 |
| Art. 7 | Conditions for consent | Annex A.7.3 |
| Art. 8 | Children's consent | Annex A.7.3.3 (referenced implicitly through consent controls) |
| Art. 9 | Special categories of data | Annex A.7.2 (extended to sensitive categories); risk assessment requirements in Clause 6.1.2 |
| Art. 12 | Transparent information and communication to data subjects | Annex A.7.4 |
| Art. 13 | Information to be provided at collection | Annex A.7.4.1 |
| Art. 14 | Information where data not collected directly | Annex A.7.4.1 |
| Art. 15 | Right of access | Annex A.7.6 |
| Art. 16 | Right to rectification | Annex A.7.7 |
| Art. 17 | Right to erasure (right to be forgotten) | Annex A.7.8, A.7.14 |
| Art. 18 | Right to restriction of processing | Annex A.7.8 |
| Art. 19 | Notification obligation regarding rectification, erasure, restriction | Annex A.7.6, A.7.7 |
| Art. 20 | Right to data portability | Annex A.7.9 |
| Art. 21 | Right to object | Annex A.7.10 |
| Art. 22 | Automated decision-making and profiling | Annex A.7.10.2 |
| Art. 24 | Responsibility of the controller | ISO 27701 Clause 5 (Leadership), Clause 9.1 (performance evaluation) |
| Art. 25 | Data protection by design and by default | Annex A.7.11.2, A.7.12.1; ISO 27701 Clause 6.1.1 |
| Art. 26 | Joint controllers | Annex A.7.2.6 (addressed in context of lawful basis and contracts) |
| Art. 27 | Representatives of controllers/processors not established in the EU | Not directly addressed; organizational context (Clause 4.1) |
| Art. 28 | Processor obligations and contracts with controllers | Annex B.8.1 (contract requirements), B.8.2, B.8.3, B.8.4, B.8.6, B.8.7 |
| Art. 29 | Processing under authority of controller | Annex B.8.2, B.8.4 |
| Art. 30 | Records of processing activities (RoPA) | Annex A.7.2.8 (controllers), B.8.9 (processors) |
| Art. 32 | Security of processing | ISO 27001 Annex A controls (inherited); ISO 27701 Annex A.7 and B.8 security controls |
| Art. 33 | Notification of data breach to supervisory authority | Annex A.7.17, B.8.11 (processor breach notification to controller) |
| Art. 34 | Communication of data breach to data subjects | Annex A.7.17 |
| Art. 35 | Data Protection Impact Assessment (DPIA) | ISO 27701 Clause 6.1.2 (privacy risk assessment), Annex A.7.2.5 |
| Art. 36 | Prior consultation | Clause 6.1.2 (high-risk processing escalation) |
| Art. 37–39 | Data Protection Officer (DPO) | ISO 27701 Clause 5.3 (privacy roles and responsibilities) |
| Art. 40–43 | Codes of conduct and certification | ISO 27701 is itself the certification mechanism |
| Art. 44–49 | Transfers to third countries | Annex A.7.15, A.7.16 (cross-border transfer controls and safeguards) |

---

## Narrative Analysis by GDPR Principle

### 1. Lawfulness, Fairness, and Transparency (Art. 5, 6, 12–14)

ISO 27701 Annex A.7.2 requires PII controllers to identify and document the lawful basis for each processing activity. The standard enumerates six potential bases directly mirroring GDPR Article 6: consent, contract, legal obligation, vital interests, public task, and legitimate interests. The transparency controls in Annex A.7.4 require organizations to provide privacy notices that disclose what data is collected, for what purpose, the legal basis, retention period, and data subject rights — directly operationalizing GDPR Articles 12–14.

### 2. Purpose Limitation and Data Minimization (Art. 5(1)(b) and (c))

ISO 27701 Annex A.7.12 mandates that PII collected for a specific purpose not be processed for incompatible secondary purposes. Annex A.7.11 requires data minimization: collecting only what is necessary for the stated purpose. These controls directly implement two of GDPR's core processing principles.

### 3. Storage Limitation and Data Retention (Art. 5(1)(e))

Annex A.7.14 requires organizations to establish and enforce PII retention schedules, including secure disposal of PII at the end of the retention period. This maps directly to GDPR's storage limitation principle.

### 4. Data Subject Rights (Art. 15–22)

ISO 27701 provides the most granular mapping in this area. The standard requires organizations to establish documented procedures for responding to each category of data subject right:

- **Access (Art. 15):** Annex A.7.6 — Organizations must be able to provide data subjects with copies of their PII upon request.
- **Rectification (Art. 16):** Annex A.7.7 — Procedures for correcting inaccurate PII.
- **Erasure (Art. 17):** Annex A.7.8 — Controls for deletion of PII, linked to retention controls.
- **Portability (Art. 20):** Annex A.7.9 — Providing PII in a machine-readable format.
- **Objection and automated decisions (Art. 21, 22):** Annex A.7.10 — Handling objections to processing and automated decision-making controls.

### 5. Accountability (Art. 5(2), 24)

ISO 27701's management system approach — including scope definition, policy, risk assessment, internal audit, management review, and corrective action — operationalizes GDPR's accountability principle. The standard requires documented evidence of privacy governance, which is the foundation of an accountability-based compliance program. The SoA (Statement of Applicability) and risk treatment plan serve as core accountability documentation.

### 6. Data Protection by Design and by Default (Art. 25)

Annex A.7.11.2 requires organizations to implement technical and organizational measures that embed privacy into the design of systems and processes. Annex A.7.12.1 reinforces purpose limitation as a by-default measure. This is one of the cleaner mappings between the two frameworks.

### 7. Processor Obligations (Art. 28, 29, 30)

ISO 27701 Annex B is dedicated entirely to PII processor controls. The controls in B.8.1 mirror the Article 28 requirement for a written Data Processing Agreement (DPA), specifying the required contract terms (subject matter, duration, nature and purpose of processing, type of PII, obligations and rights of the controller). B.8.9 requires processors to maintain records of processing activities, directly implementing Article 30(2).

### 8. Data Breach Notification (Art. 33, 34)

Annex A.7.17 addresses breach notification from controller to supervisory authority (within 72 hours as required by GDPR) and to affected data subjects. Annex B.8.11 addresses the processor obligation to notify the controller of a breach without undue delay, enabling the controller to meet its 72-hour obligation. ISO 27701 links these to the broader incident management process inherited from ISO 27001.

### 9. Data Protection Impact Assessment (Art. 35)

ISO 27701 Clause 6.1.2 requires organizations to conduct privacy risk assessments for processing activities, with particular attention to high-risk processing. Annex A.7.2.5 addresses assessments before engaging in new forms of PII processing. This maps conceptually and practically to the GDPR's DPIA requirement, though ISO 27701 does not use the term "DPIA" and its methodology may differ from the specific GDPR DPIA requirements (which require consultation with the supervisory authority for very high-risk processing).

### 10. International Data Transfers (Art. 44–49)

Annex A.7.15 and A.7.16 require organizations to implement controls for cross-border transfers of PII, ensuring that transfers to countries without adequate protection are subject to appropriate safeguards (such as Standard Contractual Clauses, Binding Corporate Rules, or other approved mechanisms). This maps to the GDPR Chapter V transfer restrictions.

---

## What ISO 27701 Does Well in Supporting GDPR

1. **Systematic and auditable:** The certification process provides independently verified evidence of a functioning privacy management system, which directly supports GDPR accountability.
2. **Records and documentation:** ISO 27701 drives the creation of the documentation GDPR requires: RoPA, privacy notices, consent records, DPAs, DPIA records, breach logs, and data subject rights request logs.
3. **Risk-based approach:** Both frameworks are risk-based. ISO 27701's risk assessment requirements align with GDPR's risk-proportionate approach to compliance.
4. **Processor supply chain:** ISO 27701's processor controls (Annex B) provide a structured framework for managing the downstream processor obligations that GDPR Article 28 imposes.

---

## Limitations: What ISO 27701 Does Not Fully Cover

1. **Legal determinations:** ISO 27701 cannot determine whether a specific processing activity is lawful under GDPR. Legal analysis by qualified privacy counsel is still required for complex processing scenarios.
2. **Supervisory authority interaction:** GDPR requires consultation with supervisory authorities in certain high-risk scenarios (Art. 36). ISO 27701 does not operationalize this interaction.
3. **Specific GDPR provisions:** Some GDPR provisions lack precise mapping — for example, Article 27 (non-EU representatives), certain profiling-specific obligations, and the children's data requirements under Article 8 are not fully operationalized in ISO 27701.
4. **Certification is not a legal safe harbor:** ISO 27701 certification does not create a legal presumption of GDPR compliance. Data protection authorities retain full investigative authority regardless of certification status.
5. **Jurisdiction-specific nuances:** GDPR is implemented differently across EU member states. ISO 27701's generic framework cannot account for these national variations.

---

## Conclusion

ISO 27701 certification provides a comprehensive operational framework that substantially overlaps with GDPR obligations. For organizations seeking to demonstrate a systematic, auditable approach to privacy, certification is a strong signal of maturity. However, it should be treated as a compliance enabler and evidence of good practice, not as a substitute for legal advice or a guarantee of full GDPR compliance.

# ISO 27701 Privacy Controls for PII Processors

## Overview

As a B2B service provider acting as a data processor for your customers, you are operating in the role of a **PII Processor** under ISO 27701. This determines which Annex A controls apply to your certification scope. PII Processors must implement:

- **Table A.2**: 18 processor-specific controls
- **Table A.3**: 29 shared information security controls

Total: **47 controls** (plus all mandatory Clause 4–10 management system requirements).

This document provides a complete reference to all A.2 processor controls using ISO 27701's own terminology — these are the exact phrases that will appear in audit evidence requests and in your customers' Data Processing Agreements (DPAs).

---

## Table A.2 — Complete PII Processor Controls

### A.2.2 — Conditions for Collection and Processing (6 controls)

These controls establish the foundational rule for processors: you process PII only under documented authority from the controller, for the controller's stated purposes, and within a written contractual framework.

---

**Control: A.2.2.2 — Customer Agreement**

- **Purpose**: Ensures every instance of processing is governed by a written contract with the PII controller (your customer). This is the processor's equivalent of the controller's DPA obligation.
- **What to implement**: Ensure a signed Data Processing Agreement (DPA) is in place with every B2B customer before processing any PII on their behalf. The DPA must specify the subject matter, nature, purpose, and duration of processing; the type of PII; and the obligations of both parties.
- **Evidence for audit**: A library of executed DPAs for all active customers; DPA template reviewed by legal counsel; process for ensuring no processing begins without a signed DPA.
- **Common pitfalls**: Processing beginning before a DPA is signed; legacy customer contracts that predate GDPR-compliant DPA clauses; DPA scope not covering all processing activities actually performed.
- **Regulatory link**: GDPR Article 28(3) — processor must process only on documented instructions of the controller.

---

**Control: A.2.2.3 — Organisation's Purposes**

- **Purpose**: Prohibits the processor from using PII it processes on behalf of controllers for its own business purposes.
- **What to implement**: Policy prohibiting use of customer PII for own analytics, product training, marketing, research, or any other purpose not specified in the controller's DPA. Technical controls (data segregation, access restrictions) to enforce the prohibition.
- **Evidence for audit**: Written policy; technical architecture showing customer data segregation; access control records; contractual prohibitions in DPAs.
- **Common pitfalls**: Using aggregated or anonymized customer data for own product improvement (may still constitute processing if not truly anonymous); using customer data for cross-marketing between clients.
- **Regulatory link**: GDPR Article 28(3)(a) — processor processes only on documented instructions.

---

**Control: A.2.2.4 — Marketing and Advertising**

- **Purpose**: Specifically prohibits using PII processed under a processing agreement for marketing or advertising purposes — even broadly — without explicit controller authorization.
- **What to implement**: Explicit contractual prohibition in all DPAs; internal policy; technical controls preventing PII from flowing into marketing or advertising systems.
- **Evidence for audit**: DPA clause; internal policy; data flow diagram showing separation of customer PII from marketing systems.
- **Common pitfalls**: Behavioral targeting or lookalike audience building using processing customers' data; cross-client targeting.
- **Regulatory link**: GDPR Article 28(3)(a).

---

**Control: A.2.2.5 — Infringing Instruction**

- **Purpose**: Requires the processor to notify the controller — and refuse execution — if a controller instruction would breach applicable privacy law.
- **What to implement**: Process for legal/compliance review of controller instructions; escalation path when instructions are potentially unlawful; documented notification procedure to inform the controller.
- **Evidence for audit**: Documented escalation procedure; training records for staff who receive instructions; records of any escalations made.
- **Common pitfalls**: Blindly executing all controller instructions without legal review; failing to escalate when instructions are ambiguous.
- **Regulatory link**: GDPR Article 28(3)(h) — processor must immediately inform the controller if an instruction infringes data protection law.

---

**Control: A.2.2.6 — Customer Obligations**

- **Purpose**: Requires the processor to actively assist the controller in meeting its obligations to PII principals (data subjects). This covers the processor's support role for Data Subject Rights (DSR) fulfilment, DPIA support, and breach notification — all within agreed timeframes.
- **What to implement**: Contractual and operational procedures to support customers' DSR processes (access, erasure, portability, restriction, rectification) within SLAs that allow the controller to meet GDPR's 30-day response window; DPIA support capability; breach notification to controller within agreed timeframes (typically 24–48 hours to allow the controller's 72-hour GDPR clock to run).
- **Evidence for audit**: DPA clauses covering DSR support obligations; documented process; SLA records; records of DSR support provided to controllers.
- **Common pitfalls**: No defined SLA for passing DSR requests to the customer; processors routing data subject inquiries directly without involving the controller; breach notification delays that cause the controller to miss the 72-hour window.
- **Regulatory link**: GDPR Article 28(3)(e) — processor must assist controller taking into account the nature of the processing.

---

**Control: A.2.2.7 — Records of Processing PII**

- **Purpose**: Requires the processor to maintain a Record of Processing Activities (RoPA) for all processing carried out on behalf of controllers. This is the processor's Article 30(2) obligation under GDPR.
- **What to implement**: Maintain a per-controller processing register documenting: controller identity and contact, processing categories, data types processed, transfers to third countries, retention periods, and security measures.
- **Evidence for audit**: Processor RoPA document; process for updating when new customers onboard or when processing activities change.
- **Common pitfalls**: Maintaining a single combined log rather than per-controller records; RoPA not updated when processing scope changes; no process for removing records when contracts terminate.
- **Regulatory link**: GDPR Article 30(2) — processors must maintain records of all categories of processing activities carried out on behalf of a controller.

---

### A.2.3 — Obligations to PII Principals (1 control)

**Control: A.2.3.2 — Obligations to PII Principals**

- **Purpose**: When individuals (data subjects / PII principals) contact the processor directly with inquiries or rights requests, the processor must handle these appropriately — typically by redirecting to the controller while ensuring no confusion or loss of the individual's request.
- **What to implement**: Training for customer-facing and support staff on how to handle DSR inquiries received directly (identify, log, redirect to the appropriate controller, and confirm the redirect to the individual). Do not attempt to fulfil rights requests without controller instruction unless specifically authorized in the DPA.
- **Evidence for audit**: Staff training records; procedure for handling direct PII principal inquiries; log of redirected inquiries.
- **Common pitfalls**: Support staff attempting to fulfil access or erasure requests without controller involvement; requests being lost rather than redirected.
- **Regulatory link**: GDPR Article 28 — the controller retains accountability for data subject rights; the processor supports and facilitates.

---

### A.2.4 — Privacy by Design and by Default (3 controls)

**Control: A.2.4.2 — Temporary Files**

- **Purpose**: Temporary processing files (caches, query results, intermediate processing artefacts) containing PII must be managed with the same care as primary PII stores and deleted per agreed schedules.
- **What to implement**: Inventory of all temporary processing locations where customer PII may land; defined retention windows for temporary data; automated deletion mechanisms; scope to include backup/staging environments.
- **Evidence for audit**: Data flow diagrams showing temporary storage locations; deletion procedures and schedules; technical evidence of automated deletion.
- **Common pitfalls**: PII in log files, analytics caches, and debugging artefacts retained indefinitely; temporary files in development/test environments.
- **Regulatory link**: GDPR Article 5(1)(e) — storage limitation.

---

**Control: A.2.4.3 — Return, Transfer or Disposal of PII**

- **Purpose**: When a processing agreement terminates, all PII must be returned to the controller or securely deleted as instructed. The processor must not retain PII after the contract ends.
- **What to implement**: Contract offboarding procedure: confirm with controller whether they want data returned or deleted; execute within defined timeframe; certify deletion and provide evidence to controller; ensure all copies (including backups and sub-processor copies) are addressed.
- **Evidence for audit**: DPA clause specifying return/deletion obligations; offboarding checklist; deletion certificates issued to customers; records of offboarding completions.
- **Common pitfalls**: PII retained in backups or archives after contract termination; no process to propagate deletion to sub-processors; no confirmation to controller.
- **Regulatory link**: GDPR Article 28(3)(g) — at the choice of the controller, delete or return all personal data upon end of services.

---

**Control: A.2.4.4 — PII Transmission Controls** *(New in 2025 edition)*

- **Purpose**: Protects PII in transit during processing operations — both between components of the processor's systems and when transmitting to/from the controller or sub-processors.
- **What to implement**: Encryption for all PII in transit (TLS 1.2+, secure file transfer); controls on email transmission of PII; API security for data exchanges; documented transmission controls per data sensitivity level.
- **Evidence for audit**: Technical security standards; TLS certificate evidence; API security documentation; email policy.
- **Common pitfalls**: PII transmitted unencrypted between internal microservices; legacy API connections without TLS; PII emailed in cleartext.
- **Regulatory link**: GDPR Article 32(1)(a) — pseudonymisation and encryption of personal data; Article 28(3)(c) — security measures.

---

### A.2.5 — PII Sharing, Transfer and Disclosure (8 controls)

This domain is critical for B2B processors — it governs your obligations around sub-processors (vendors you use to deliver your service), third-country data transfers, and handling of government access requests.

---

**Control: A.2.5.2 — Basis for PII Transfer**

- **Purpose**: Any transfer of controller PII to a third country or international organization requires a documented legal transfer mechanism.
- **What to implement**: Map all data flows that involve cross-border transfers; document the transfer mechanism for each (Standard Contractual Clauses, adequacy decision, binding corporate rules, or other GDPR Art. 44–49 mechanism); ensure SCCs are signed and up-to-date (2021 EU SCCs where applicable).
- **Evidence for audit**: Transfer impact assessments; executed SCCs; transfer mapping documentation.
- **Common pitfalls**: Data residency commitments made to customers but not technically enforced; sub-processor transfers to non-adequate countries without SCCs.
- **Regulatory link**: GDPR Articles 44–49 — transfers to third countries.

---

**Control: A.2.5.3 — Countries for PII Transfer**

- **Purpose**: Document the countries to which PII is transferred during processing operations, including via sub-processors.
- **What to implement**: Maintain a transfer mapping covering all jurisdictions where customer PII is stored, accessed, or transmitted. Include sub-processor locations. Disclose to controllers.
- **Evidence for audit**: Transfer register; sub-processor location register; DPA disclosures.
- **Common pitfalls**: Cloud provider sub-processor locations not mapped; support access from overseas offices not documented.
- **Regulatory link**: GDPR Article 30(1)(e) — records of processing must include transfers to third countries.

---

**Control: A.2.5.4 — Records of PII Disclosures**

- **Purpose**: Maintain a log of all disclosures of customer PII to third parties.
- **What to implement**: Disclosure log covering all instances where customer PII was shared with a third party; covers both routine disclosures (sub-processors) and exceptional disclosures (law enforcement).
- **Evidence for audit**: Disclosure register; process for logging disclosure events.
- **Common pitfalls**: Ad hoc disclosures not recorded; no distinction between routine sub-processor sharing and exceptional disclosures.
- **Regulatory link**: GDPR Article 5(2) accountability; Article 30 records.

---

**Control: A.2.5.5 — Notification of PII Disclosure Requests**

- **Purpose**: If a government body or law enforcement agency requests disclosure of controller PII, notify the controller before disclosing — unless legally prohibited from doing so (e.g., a gag order).
- **What to implement**: Legal procedure for handling government access requests; default position to notify the controller first and seek legal advice; transparency report process; contractual commitment to controller notification.
- **Evidence for audit**: Legal procedure; DPA clause; records of any notifications made.
- **Common pitfalls**: Automatic compliance with government requests without notifying the controller; no legal review process.
- **Regulatory link**: GDPR Article 28(3)(a) — processor notifies controller if instruction infringes law; general principle of transparency to controllers.

---

**Control: A.2.5.6 — Legally Binding PII Disclosures**

- **Purpose**: Where the processor is legally compelled to disclose PII (e.g., court order, national security), it must notify the controller where legally permitted and record the disclosure.
- **What to implement**: Legal review process; notification to controller procedure; disclosure log; senior management authorization for compelled disclosures.
- **Evidence for audit**: Legal procedure; disclosure records; records of controller notifications.
- **Common pitfalls**: Disclosures made without any notification; no legal review before compliance with informal requests.
- **Regulatory link**: GDPR Article 28(3)(a).

---

**Control: A.2.5.7 — Disclosure of Subcontractors**

This is the first of three controls using ISO 27701's specific **sub-processor** terminology.

- **Purpose**: The processor must disclose to the controller the identity and location of all sub-processors used to deliver the contracted services.
- **What to implement**: Maintain and publish a sub-processor list covering: company name, location (country), processing activities performed. Make this list available to all controllers (typically via DPA, trust page, or contractual schedule). Process for keeping the list current.
- **Evidence for audit**: Published or contractually disclosed sub-processor list; process for maintaining currency; audit trail of sub-processor changes.
- **Common pitfalls**: Sub-processor list not maintained; list not shared with controllers; list outdated when sub-processors change.
- **Regulatory link**: GDPR Article 28(2) — controller must authorize processor's use of sub-processors.

---

**Control: A.2.5.8 — Engagement of a Subcontractor** *(New in 2025 edition)*

ISO 27701 term: **"sub-processor contracts"** — this control governs both the authorization requirement and the contractual obligations that must be flowed down.

- **Purpose**: Before engaging a new sub-processor, the processor must obtain controller authorization. All sub-processors must be engaged under contracts that impose equivalent data protection obligations.
- **What to implement**:
  1. **Authorization process**: Define in DPAs whether you have general or specific authorization for sub-processors. General authorization (most common) requires prior notice and opportunity to object.
  2. **Sub-processor contracts**: Ensure all sub-processor agreements include the same data protection obligations as in your DPA with the controller. If the sub-processor fails to fulfil these obligations, the processor remains fully liable to the controller.
  3. **Contractual audit trail**: Maintain executed sub-processor DPAs for all current sub-processors.
- **Evidence for audit**: Sub-processor DPA template; executed sub-processor agreements; authorization process documentation; DPA clauses covering sub-processor authorization.
- **Common pitfalls**: Engaging new sub-processors (cloud vendors, analytics tools) without controller notification; sub-processor agreements missing data protection clauses; no data protection clauses in cloud provider ToS (use dedicated DPA addenda).
- **Regulatory link**: GDPR Article 28(2) and (4) — sub-processor obligations; Article 28(4) — same obligations imposed on sub-processor as controller imposed on processor.

---

**Control: A.2.5.9 — Change of Subcontractor** *(New in 2025 edition)*

ISO 27701 term: **"sub-processor notification and consent"** — this control specifically addresses the notification obligation when sub-processors change.

- **Purpose**: When the processor intends to replace or add a sub-processor, controllers must be notified in advance and given the opportunity to object before the change takes effect.
- **What to implement**: Prior notification mechanism (email list, trust page notification, contractual notice period — typically 30 days); process for handling controller objections; procedure for managing changes where objections are raised.
- **Evidence for audit**: Notification mechanism (e.g., email notification service, changelog with subscription); records of notifications sent; DPA clause specifying notice period and objection right.
- **Common pitfalls**: Retrospective notification after changes have already taken effect; no mechanism for controllers to object; changes to underlying infrastructure sub-processors (e.g., cloud region changes) not treated as sub-processor changes.
- **Regulatory link**: GDPR Article 28(2) — controller must give specific or general written authorization for sub-processors.

---

## The Three Critical Sub-Processor Controls in Summary

ISO 27701 uses precise terminology that maps directly to audit evidence requests and DPA contractual clauses:

| Obligation | ISO 27701 Term | Control | What It Requires |
|-----------|---------------|---------|-----------------|
| Assist controllers with individual rights requests | "**PII subject rights assistance obligations**" | A.2.3.3 (referenced in A.2.2.6) | Operational process to support controllers' DSR fulfilment within SLAs |
| Notify and obtain consent before using sub-processors | "**sub-processor** notification and consent" | A.2.5.9 / A.2.2.6 | Advance notice to controllers; opportunity to object; prior authorization |
| Written agreements with sub-processors | "**sub-processor** contracts" | A.2.5.8 | Equivalent data protection obligations flowed down to all sub-processors |

---

## Shared Security Controls (A.3) — Processor Relevance

All 29 A.3 controls apply to processors as well as controllers. The most operationally significant for a B2B processor context are:

| Control | Relevance for Processors |
|---------|--------------------------|
| A.3.9 — Access Rights | Least-privilege access to all customer PII systems; regular access reviews |
| A.3.11/A.3.12 — Incident Management | Breach notification process with controller notification SLAs built in |
| A.3.18 — Confidentiality Agreements | All staff with access to customer PII under signed confidentiality obligations |
| A.3.25 — Logging | Access to and processing of customer PII logged and tamper-protected |
| A.3.26 — Cryptography | Encryption at rest and in transit for all customer PII |
| A.3.31 — Test Information | Live customer PII not used in test environments |

---

## Certification Value for B2B Processors

ISO 27701 certification as a PII Processor has significant commercial value in B2B contexts:

1. **Reduces customer audit burden**: Your customers (controllers) can reference your certification as evidence that you meet GDPR Article 28 requirements, reducing the need for individual audit rights exercises.
2. **Differentiator in procurement**: Enterprise procurement processes increasingly require evidence of privacy certifications. ISO 27701 certification satisfies this requirement.
3. **DPA simplification**: Controllers can reference your SoA and certification report rather than requiring detailed contractual annexes on each control.
4. **Regulatory standing**: In a regulatory investigation affecting one of your customers, your ISO 27701 certification provides documented evidence that you implemented appropriate controls as a processor.

# ISO 27701 Privacy Controls for Data Processors

## Introduction

ISO 27701 contains a dedicated set of controls for organizations acting as PII processors — that is, organizations that process personal data on behalf of and under the instruction of PII controllers (their B2B customers). These controls are contained in **Annex B** of the standard (formally titled "ISO/IEC 27701 Annex B — Additional ISO/IEC 27002 guidance for PII processors").

All Annex B controls are organized under the parent control domain reference 8 (B.8.x). In addition, processors must also implement the shared controls in the main clauses of ISO 27701 (Clauses 4–10), and they are subject to a subset of Annex A controls that apply in dual-role situations.

The key principle underlying all processor controls is that a PII processor must only process PII in accordance with the documented instructions of the controller. The processor has limited discretion and exists to serve the controller's purposes, not its own.

---

## Annex B Controls in Detail

### B.8.1 — Conditions for Collection and Processing

**B.8.1.1 — Customer Agreement**

The processor must have a documented agreement (contract) with each PII controller before processing begins. This is the foundational control. The agreement must specify:

- The subject matter and duration of the processing
- The nature and purpose of the processing
- The type of PII and categories of PII principals involved
- The obligations and rights of the controller
- Instructions for what the processor may and may not do with the PII

**Practical implementation:**
- Establish a standard Data Processing Agreement (DPA) template
- Ensure all B2B customer relationships have a signed DPA in place
- Maintain a register of all active DPAs
- Review DPAs when processing activities change

**B.8.1.2 — Organization's Purposes**

The processor must not use PII obtained in the course of providing services to the controller for its own purposes (e.g., analytics, product improvement, marketing) unless the controller explicitly instructs or permits this. The processor must be able to demonstrate that processing is strictly limited to the controller's instructions.

**Practical implementation:**
- Implement technical controls that prevent unauthorized secondary use of customer PII
- Ensure internal policies prohibit use of customer data for internal analytics, model training, or other purposes without explicit controller authorization
- Conduct regular audits to verify compliance

**B.8.1.3 — Marketing and Advertising**

The processor must not use PII processed under a controller agreement for direct marketing or advertising purposes unless explicitly authorized by the controller. This is a specific instantiation of B.8.1.2 targeting the advertising/marketing use case.

**Practical implementation:**
- Maintain documented prohibitions in internal policy and procedure
- Ensure marketing and product teams understand restrictions on customer data
- Implement data segregation between customer PII environments and internal marketing systems

**B.8.1.4 — Infringing Instructions**

The processor must have a process for identifying when controller instructions may violate applicable privacy law. When the processor identifies potentially infringing instructions, it must inform the controller and may refuse to carry out the instructions.

**Practical implementation:**
- Train account management and operations staff to recognize potentially unlawful instructions
- Establish an escalation path (e.g., to legal/privacy team) when questionable instructions are received
- Document instances of flagged instructions and resolutions
- Include contractual provisions giving the processor the right to refuse unlawful instructions

---

### B.8.2 — Obligations to PII Principals

**B.8.2.1 — Obligation to PII Principals**

Processors must support controllers in meeting their obligations to PII principals (data subjects). Where a data subject contacts the processor directly with a rights request (e.g., requesting deletion of their data), the processor must either:
- Redirect the individual to the controller, or
- Notify the controller of the request and await further instructions

The processor must implement technical and organizational measures that enable controllers to fulfill data subject rights requests.

**Practical implementation:**
- Implement technical capabilities for data subject rights fulfillment: search, export, delete, restrict processing
- Establish an internal process for handling misdirected data subject requests
- Document SLAs for responding to controller instructions related to rights fulfillment
- Test data subject rights fulfillment capabilities regularly

---

### B.8.3 — Privacy by Design and Privacy by Default

**B.8.3.1 — Limits on Collection**

Processors must collect only the PII that is necessary for the service being provided. Excess collection — even if the controller does not explicitly prohibit it — violates the data minimization principle.

**Practical implementation:**
- Review data collection points in your platform/service to ensure only necessary PII is collected or accessed
- Implement configuration options that limit data collection by default
- Document the minimum necessary data for each service tier

**B.8.3.2 — Limits on Processing**

Processing activities must be limited to what is necessary and must not exceed the scope of controller instructions. This applies to internal access (who within the processor organization can access PII), processing frequency, and the nature of processing operations.

**Practical implementation:**
- Implement role-based access controls (RBAC) limiting employee access to customer PII
- Log all access to customer PII environments
- Conduct periodic access reviews

---

### B.8.4 — Privacy Impact Assessment Involvement

While DPIA/PIA obligations rest primarily with the controller, processors must provide assistance to controllers conducting PIAs/DPIAs where the processing involves the processor's systems or services. Processors should:

- Provide documentation of their processing activities and controls upon request
- Respond to controller DPIA questionnaires in a timely manner
- Flag to controllers when new features or services may materially change the risk profile of PII processing

**Practical implementation:**
- Prepare and maintain a standard "processor security and privacy questionnaire" response
- Maintain a library of completed third-party assessments (SOC 2, ISO 27001/27701 reports) that can be shared with controllers
- Establish a process for notifying controllers of material changes to processing

---

### B.8.5 — Privacy Architecture and Technical Measures

**B.8.5.1 — Data Masking**

Where technically feasible, processors should implement data masking, pseudonymization, or anonymization to minimize the exposure of PII within their systems. This includes masking PII in logs, development environments, and non-production systems.

**B.8.5.2 — Encryption**

PII must be encrypted both in transit (e.g., TLS 1.2+) and at rest. Encryption key management must be documented and audited.

**B.8.5.3 — De-identification**

Where processing does not require identification of PII principals, the processor should apply de-identification techniques.

**Practical implementation:**
- Enforce encryption-at-rest for all storage containing customer PII (database encryption, file system encryption)
- Enforce TLS for all data in transit
- Implement pseudonymization in analytics, logging, and test environments
- Document encryption standards in a data security policy

---

### B.8.6 — Contracts with Sub-Processors

**B.8.6.1 — Sub-Processor Agreements**

If the processor engages sub-processors (i.e., third parties who process PII on the processor's behalf), it must:

- Obtain prior written authorization from the controller (specific or general)
- Impose equivalent data protection obligations on sub-processors as are imposed on the processor itself
- Remain fully liable to the controller for sub-processor compliance

**Practical implementation:**
- Maintain a register of all sub-processors and the categories of PII they access
- Establish a standard sub-processor DPA template that flows down controller obligations
- Notify controllers of sub-processor changes (additions or replacements) in advance
- Conduct due diligence on sub-processors (security reviews, certifications)

**B.8.6.2 — Disclosure of Sub-Processors**

Controllers must be able to obtain a current list of sub-processors upon request. Many organizations publish this as a publicly accessible sub-processor list, updated as changes occur.

**Practical implementation:**
- Publish and maintain a sub-processor list (publicly or on request)
- Establish notification mechanisms (e.g., email subscription, webpage updates) for sub-processor changes
- Provide reasonable notice periods before changes take effect (typically 10–30 days)

---

### B.8.7 — International Transfers

If PII is transferred to countries or regions outside the controller's jurisdiction (and that jurisdiction has transfer restrictions, such as GDPR's Chapter V), the processor must:

- Ensure that appropriate transfer mechanisms are in place (Standard Contractual Clauses, Binding Corporate Rules, adequacy decisions, etc.)
- Disclose to controllers where data may be processed geographically
- Not transfer PII to unauthorized jurisdictions without controller consent

**Practical implementation:**
- Map all geographic locations where customer PII may be processed (including sub-processors)
- Establish SCCs or equivalent mechanisms for cross-border transfers
- Maintain data residency documentation for customer-facing documentation

---

### B.8.8 — Records of PII Processing (Record of Processing Activities)

**B.8.8.1 — Records of Processing**

ISO 27701 Annex B.8.9 (in some editions referenced as B.8.8) requires processors to maintain a Record of Processing Activities (RoPA) from the processor's perspective. This must document:

- The name and contact details of the processor and (where applicable) sub-processors
- Categories of processing carried out on behalf of each controller
- Transfers to third countries
- A general description of technical and organizational security measures

**Practical implementation:**
- Create and maintain a processor RoPA in a structured format (spreadsheet or GRC tool)
- Update the RoPA when new controllers are onboarded or processing activities change
- Make the RoPA available to regulators upon request

---

### B.8.9 — PII Security (Linked to ISO 27001 Controls)

Processors must implement appropriate technical and organizational security measures to protect PII. ISO 27701 does not enumerate entirely new security controls here — it relies on the security controls already required by ISO 27001 — but adds the following specific requirements in the privacy context:

- Security controls must be proportionate to the risk to PII principals
- Security measures must be documented and demonstrably implemented
- Processors must support controllers in meeting their security obligations under applicable law (e.g., GDPR Art. 32)

**Key security controls applicable to processors:**
- Access control and authentication (MFA, least privilege)
- Vulnerability management
- Logging and monitoring
- Incident response
- Business continuity and disaster recovery
- Physical and environmental security

---

### B.8.10 — Data Breach Notification

**B.8.10.1 — Breach Notification to Controller**

Upon discovering a PII breach, the processor must notify the affected controller(s) without undue delay. The notification must include:
- Description of the nature of the breach
- Categories and approximate number of PII principals affected
- Categories and approximate number of PII records affected
- Likely consequences of the breach
- Measures taken or proposed to address the breach

The processor notification to the controller must be timely enough to enable the controller to meet its own regulatory notification obligations (e.g., within 72 hours to the supervisory authority under GDPR Art. 33). In practice, many DPAs specify a 24–48 hour notification requirement from processor to controller.

**Practical implementation:**
- Establish a Privacy Incident Response Plan that includes a specific workflow for customer (controller) notification
- Define a single point of contact for breach notifications (e.g., security team or DPO)
- Maintain a breach notification template for rapid deployment
- Test breach notification procedures in tabletop exercises

---

### B.8.11 — Engagement with Supervisory Authorities

Processors may be directly contacted by supervisory authorities during investigations. Processors must:
- Cooperate with supervisory authorities as required by law
- Notify the relevant controller when a supervisory authority makes inquiries relating to the controller's PII processing
- Not disclose controller-confidential information to supervisory authorities beyond what is legally required

---

### B.8.12 — Return or Deletion of PII on Contract Termination

Upon termination of the contract with a controller, the processor must:
- Return all PII to the controller in a usable format, or
- Securely destroy/delete all PII held on behalf of the controller
- Provide evidence of deletion or return upon request
- Ensure sub-processors do the same

**Practical implementation:**
- Include data return/deletion provisions in all DPAs
- Establish a documented off-boarding process for departing customers
- Use certified deletion tools and maintain deletion certificates
- Define a post-termination retention period (if applicable) and ensure it is disclosed to controllers

---

## Shared Clause Requirements (Clauses 4–10)

In addition to Annex B controls, processors must comply with the general management system requirements of ISO 27701:

| Clause | Requirement |
|---|---|
| 4 | Identify applicable privacy law, identify controllers, define context |
| 5 | Leadership commitment to privacy, privacy policy, privacy roles (e.g., DPO if required) |
| 6 | Privacy risk assessment covering processor activities; objectives for privacy |
| 7 | Competence and training for privacy; privacy awareness |
| 8 | Operational planning and control of PII processing activities |
| 9 | Monitoring and measuring privacy performance; internal audit; management review |
| 10 | Corrective action for nonconformities including privacy incidents |

---

## Implementation Priorities for a B2B Processor

For an organization acting exclusively as a B2B data processor, the highest-priority implementation actions are:

1. **DPA template and contract review:** Ensure all customer contracts contain compliant DPA terms.
2. **Sub-processor management:** Build a sub-processor register and notification process.
3. **Breach notification:** Implement a clear, fast-path notification process to controllers.
4. **Data subject rights technical capabilities:** Build search, export, and deletion capabilities into your platform.
5. **RoPA:** Document all processing activities by customer.
6. **Data return/deletion:** Establish an off-boarding process with documented deletion.
7. **Access controls and encryption:** Harden technical controls for PII environments.
8. **Staff training:** Train all customer-facing and technical staff on processor obligations.

---

## Conclusion

ISO 27701 Annex B provides a comprehensive and auditable control set for PII processors. For a B2B processor, implementing these controls demonstrates to customers and regulators that PII is handled responsibly, supports customer GDPR compliance programs, and provides a defensible evidence base in the event of a regulatory investigation or contractual audit. Many enterprise B2B customers now require ISO 27701 certification as a vendor onboarding prerequisite, making certification a commercial differentiator as well as a compliance tool.

# Privacy Impact Assessment (PIA) Methodology Under ISO 27701

## Overview

ISO 27701 requires Privacy Impact Assessments (PIAs) — referred to as Data Protection Impact Assessments (DPIAs) under GDPR — as a mandatory operational control for PII Controllers (control A.1.2.6). The PIA is not optional: it is a required element of the Clause 8 operational controls and must be triggered for new or significantly changed processing activities that present elevated privacy risk.

This document covers the ISO 27701 PIA methodology, trigger criteria, required elements, and the relationship between the ISO 27701 PIA requirement and GDPR's mandatory DPIA obligation under Article 35.

---

## ISO 27701 Control: A.1.2.6 — Privacy Impact Assessment

**Control objective**: Conduct Privacy Impact Assessments for all new or significantly changed processing activities before they begin; document the findings and decisions; record evidence of completion.

**Scope**: Applies to PII Controllers. Organizations acting as PII Processors support their customers' PIA/DPIA processes (via A.2.2.6 — customer obligations) but typically do not conduct standalone PIAs for processing under a controller's authority.

---

## Relationship to GDPR DPIA (Article 35)

The ISO 27701 PIA and the GDPR DPIA are closely aligned but not identical:

| Aspect | ISO 27701 PIA (A.1.2.6) | GDPR DPIA (Art. 35) |
|--------|------------------------|---------------------|
| Applies to | All new/changed processing with privacy implications | Processing "likely to result in high risk" to individuals |
| Trigger | Risk-based — any new or significantly changed processing | Mandatory for high-risk categories (list in GDPR/EDPB guidance) |
| Consultation | Internal | Plus mandatory supervisory authority consultation where high residual risk remains (Art. 36) |
| Legal obligation | ISO certification requirement | Legal obligation under GDPR — failure triggers enforcement |
| Documentation standard | PIMS records (Clause 8) | Must be maintained by the controller; available on request |
| Output | PIA record with risk treatment decisions | DPIA record; must include Art. 36 consultation if applicable |

**Practical guidance**: Align your PIA process with GDPR DPIA requirements so that every DPIA is also a compliant PIA — completing both in a single process. A PIA that meets the GDPR DPIA standard automatically satisfies A.1.2.6.

---

## DPIA Trigger Criteria

### Mandatory Triggers Under GDPR (also triggering ISO 27701 PIA obligation)

A DPIA is mandatory — and therefore a PIA under ISO 27701 is automatically required — when processing falls into any of the following categories. The European Data Protection Board (EDPB) and most supervisory authorities identify these as high-risk processing types:

| Trigger | Description | Examples |
|---------|-------------|---------|
| Systematic profiling with significant effects | Automated evaluation of personal aspects (performance, economic situation, health, preferences, behavior, location) with legal or similarly significant effects on individuals | Credit scoring, insurance pricing, recruitment screening, behavioral advertising |
| Processing of special category data at scale | Large-scale processing of health, genetic, biometric, religious, political, racial/ethnic, sexual orientation data, or criminal records | Employee health monitoring, clinical data platforms, biometric access systems |
| Systematic monitoring of publicly accessible areas | Large-scale CCTV, tracking technologies in public or semi-public spaces | City-wide surveillance, workplace monitoring, tracking technologies in retail |
| New technologies with untested privacy implications | Processing using novel or innovative technologies where the privacy risk profile is not well understood | AI-based decision systems, IoT data aggregation, new forms of location tracking |
| Processing that prevents exercise of rights or use of a service | Processing that could lead to exclusion or denial of service based on personal data | Automated denial of credit, access, or benefits |
| Large-scale processing of personal data | Processing at a scale that, by volume alone, creates significant risk | National-scale data processing, population health analytics |
| Matching or combining datasets | Combining personal data from multiple sources in ways the individual would not expect | Cross-referencing internal and external datasets for profiling |
| Vulnerable subjects | Processing data of children, employees (power imbalance), vulnerable adults | Children's platforms, employee monitoring, mental health applications |

### ISO 27701 A.1.2.6 Triggers (broader than mandatory DPIA triggers)

ISO 27701 applies the PIA requirement more broadly — not just when GDPR mandates a full DPIA, but also when:

- A **new processing activity** is being introduced
- An **existing processing activity is significantly changed** (new data types, new purposes, new technologies, new recipients, or significantly increased scale)
- A **new system or product** that processes PII is being developed or deployed
- A **new third-party processor or sub-processor** is being engaged for a material processing activity
- **Data transfers** to new jurisdictions are being introduced
- The **privacy risk profile** of an existing activity materially changes (e.g., due to new threat intelligence or regulatory guidance)

**Best practice**: Embed PIA triggers into your SDLC, change management, procurement, and project initiation processes. A privacy gate review at project initiation is the most effective way to catch triggers early.

---

## PIA / DPIA Methodology

### Phase 1: Screening — Determine Whether a Full PIA Is Required

Not every new activity requires a full DPIA. Start with a **screening questionnaire** to determine whether high risk is likely:

| Screening Question | If Yes |
|-------------------|--------|
| Does the activity involve special category data? | Proceed to full PIA |
| Does the activity involve profiling or automated decision-making? | Proceed to full PIA |
| Does the activity involve systematic monitoring of individuals? | Proceed to full PIA |
| Does the activity involve new or unfamiliar technology? | Proceed to full PIA |
| Does the activity involve children or other vulnerable groups? | Proceed to full PIA |
| Could the processing lead to exclusion or denial of rights? | Proceed to full PIA |
| Does the activity involve large-scale processing? | Proceed to full PIA |
| Does the activity involve a new cross-border transfer? | Proceed to full PIA |
| Does the activity combine datasets from multiple sources? | Proceed to full PIA |

If two or more criteria apply, a full DPIA is generally mandatory under GDPR.

---

### Phase 2: Processing Description

Document the processing activity in detail:

**Required elements of the processing description:**

1. **Nature of the processing**: What is being done to the data? (collection, recording, structuring, storage, alteration, retrieval, consultation, use, disclosure, erasure, destruction)
2. **Scope**: Volume of data, categories of individuals affected, geographic scope, frequency
3. **Context**: What is the broader operational context? Is there a power imbalance? Are vulnerable groups involved?
4. **Purpose(s)**: What is the legitimate purpose? What is the stated lawful basis (GDPR Art. 6 and, where applicable, Art. 9)?
5. **Data types**: Specific personal data categories collected or processed
6. **Data flows**: Where data originates, where it flows, who has access, where it is stored, when it is deleted
7. **Recipients**: Internal and external recipients; sub-processors; international transfers
8. **Retention**: How long data is retained and why

---

### Phase 3: Necessity and Proportionality Assessment

Before assessing risks, assess whether the processing is justified:

| Question | Assessment Criteria |
|----------|-------------------|
| Is the processing necessary for the stated purpose? | Could the purpose be achieved with less or no personal data? |
| Is the processing proportionate? | Is the privacy intrusion proportionate to the benefit? |
| Is the lawful basis clearly established? | Is there a valid GDPR Art. 6 (and Art. 9) basis? |
| Are individuals adequately informed? | Does the privacy notice cover this processing? |
| Are retention periods appropriate? | Is data deleted when no longer needed? |
| Could data minimisation be applied? | Can fields be removed, pseudonymised, or anonymised? |

If the processing is not necessary or proportionate, the appropriate response is to redesign the processing activity — not just to mitigate risk.

---

### Phase 4: Privacy Risk Assessment

Assess risks to PII principals (individuals) — not just organizational risks. This is a key distinction from the ISO 27001 risk assessment, which focuses on organizational harm.

**Risk Register for PIA:**

| Processing Activity | Data Types | Individuals Affected | Threat | Vulnerability | Likelihood (1–5) | Severity of Harm (1–5) | Risk Score | Treatment | Control(s) | Owner | Due Date | Residual Risk |
|---|---|---|---|---|---|---|---|---|---|---|---|---|

**Privacy-specific threats to assess:**

| Threat Category | Examples |
|----------------|---------|
| Unauthorized access / disclosure | Data breach, insider threat, phishing, unauthorized access |
| Loss or destruction | System failure, accidental deletion, ransomware |
| Excessive collection | More data collected than necessary |
| Secondary use | Data used for purposes beyond original intent |
| Data quality failure | Inaccurate data used for significant decisions |
| Retention failure | Data held beyond retention period |
| Rights denial | Inability to fulfil data subject rights |
| Transfer to unsafe jurisdiction | Cross-border transfer without adequate safeguards |
| Profiling harm | Discriminatory or unfair automated decisions |
| Re-identification | Anonymised data re-linked to individuals |

**Severity of harm scale (individual-focused):**

| Level | Description | Examples |
|-------|-------------|---------|
| 1 — Negligible | Minor inconvenience, no lasting impact | Spam email |
| 2 — Limited | Temporary impact, reversible with effort | Minor embarrassment, temporary data exposure |
| 3 — Significant | Significant impact on individual's life | Financial loss, relationship damage, professional harm |
| 4 — Serious | Serious lasting impact | Discrimination, identity theft, significant financial harm |
| 5 — Severe | Irreversible, life-altering | Physical harm, severe discrimination, destruction of reputation |

---

### Phase 5: Risk Treatment

For each risk identified, document treatment decisions:

| Treatment | Description | ISO 27701 Controls |
|-----------|-------------|-------------------|
| **Mitigate** | Implement controls to reduce likelihood or severity | A.3.26 (encryption), A.3.9 (access control), A.1.4.5 (minimisation) |
| **Avoid** | Redesign or discontinue the processing activity | Stop collecting unnecessary fields; abandon high-risk processing |
| **Transfer** | Transfer risk via insurance or contract | Processor contracts; insurance |
| **Accept** | Accept residual risk with documented decision and approval | Document justification; obtain senior management sign-off |

**Treatment decisions must be reflected in the SoA** — the controls selected through the PIA risk treatment process inform the PIMS Statement of Applicability.

---

### Phase 6: Consultation

**Internal consultation:**
- DPO / Privacy Officer — must be consulted; their opinion must be recorded (GDPR Art. 35(2))
- Legal / compliance review
- Technical leads (security, engineering)
- Business owners

**External consultation (where required):**
- **Data subjects or their representatives** — GDPR Art. 35(9) requires consultation of data subjects where appropriate
- **Supervisory authority (GDPR Art. 36)** — mandatory prior consultation when the DPIA shows that high residual risk cannot be mitigated. The supervisory authority has 8 weeks to provide written advice (extendable to 14 weeks).

---

### Phase 7: Decision and Documentation

**Required DPIA record elements** (GDPR Art. 35(7), incorporated into ISO 27701 A.1.2.6 records):

1. A systematic description of the processing operations and the purposes, including the legitimate interest pursued
2. An assessment of the necessity and proportionality of the processing in relation to the purposes
3. An assessment of the risks to the rights and freedoms of data subjects
4. The measures envisaged to address the risks, including safeguards, security measures, and mechanisms to ensure protection of personal data

**Additional documentation for ISO 27701 audit evidence:**
- Date of PIA completion
- Names and roles of those who conducted and approved the PIA
- DPO opinion and date of consultation
- Risk treatment decisions and responsible owners
- Residual risk assessment
- Sign-off by accountable senior management
- Review trigger (i.e., under what conditions will this PIA be reviewed)

---

### Phase 8: Review and Monitoring

PIAs are not one-time documents. GDPR and ISO 27701 both require review when:

- The processing activity materially changes
- A new risk emerges (e.g., new threat intelligence, data breach)
- There is a significant change in the regulatory environment
- At defined intervals as part of ongoing PIMS management (at least annually for high-risk processing)

---

## PIA Process Summary

| Phase | Key Output | Evidence for Audit |
|-------|-----------|-------------------|
| 1. Screening | Screening decision record | Completed screening questionnaire |
| 2. Processing Description | Processing description document | Data flow diagram, RoPA entry |
| 3. Necessity & Proportionality | Justification record | Documented assessment |
| 4. Risk Assessment | Privacy risk register | Completed risk register |
| 5. Risk Treatment | Treatment plan | Control selections in SoA |
| 6. Consultation | Consultation records | DPO opinion; data subject consultation notes |
| 7. Decision | Signed DPIA record | DPIA document with management sign-off |
| 8. Review | Review schedule | Dated review trigger |

---

## Mandatory Documentation Checklist for ISO 27701 PIA Records (Clause 8)

- [ ] PIA trigger screening record for all new/changed processing activities
- [ ] Completed DPIA for each high-risk processing activity
- [ ] DPO consultation records for all DPIAs
- [ ] Evidence of data subject consultation (where conducted)
- [ ] Risk register per DPIA with likelihood, severity, and treatment
- [ ] Management sign-off on residual risk acceptance
- [ ] Supervisory authority consultation records (where triggered under GDPR Art. 36)
- [ ] DPIA review schedule and records of reviews

# Privacy Impact Assessment (PIA) Methodology Under ISO 27701

## Introduction

ISO 27701 requires organizations to conduct privacy risk assessments — commonly referred to as Privacy Impact Assessments (PIAs) or, in the GDPR context, Data Protection Impact Assessments (DPIAs). The standard does not prescribe a single rigid PIA methodology, but it does establish requirements for when assessments must be conducted, what they must consider, and how findings must be managed. The following guidance draws on ISO 27701 Clause 6.1.2, Annex A.7.2.5, and related provisions, as well as established international PIA practice (including guidance from ISO 29134, which is the dedicated PIA standard referenced by ISO 27701).

---

## Regulatory and Standards Foundation

- **ISO 27701 Clause 6.1.2:** Requires organizations to assess privacy risks as part of the broader information security risk assessment process, with particular consideration of risks to PII principals.
- **ISO 27701 Annex A.7.2.5:** Requires PII controllers to assess the necessity and proportionality of new processing before it begins, specifically for high-risk processing.
- **ISO 29134:2017:** The dedicated international standard for Privacy Impact Assessments, which ISO 27701 references for detailed PIA methodology guidance.
- **GDPR Article 35:** Requires DPIAs for high-risk processing (largely overlapping with ISO 27701's PIA triggers).

---

## What Triggers a PIA?

ISO 27701, consistent with ISO 29134 and GDPR guidance, identifies several categories of triggers that necessitate a PIA. A PIA is required — or strongly recommended — in any of the following circumstances:

### Mandatory Triggers

1. **New PII processing activities:** Any new system, product, service, or process that will collect, store, use, disclose, or delete PII for the first time requires a PIA before implementation.

2. **High-risk processing types, including:**
   - **Systematic and extensive profiling:** Automated processing used to evaluate, analyze, or predict aspects of an individual's behavior, location, interests, performance, or other personal characteristics.
   - **Large-scale processing of sensitive/special category data:** Health data, genetic data, biometric data, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sexual orientation, or criminal records.
   - **Systematic monitoring of publicly accessible areas:** CCTV, IoT monitoring, tracking technologies in public spaces.
   - **Matching or combining datasets:** Combining PII from multiple sources in ways that individuals could not reasonably anticipate.
   - **Innovative technologies:** Processing using new or novel technologies where the privacy implications are not yet fully understood (e.g., AI/ML models, facial recognition, wearables).
   - **Processing that prevents individuals from exercising rights or accessing services:** Automated decision-making with significant effects (e.g., credit scoring, insurance risk assessment, background screening for employment).
   - **Children's data:** Any processing involving PII of minors.

3. **Material changes to existing processing:** Significant changes to an existing system or process that alter the nature, purpose, scope, or risk profile of PII processing. This includes:
   - New data sharing arrangements with third parties
   - Expansion to new geographic markets (particularly those with different privacy regulations)
   - New purposes for previously collected data
   - Technology upgrades that change how PII is processed
   - Significant increases in the volume or sensitivity of PII processed

4. **Regulatory requirement:** Where applicable privacy law (e.g., GDPR Art. 35) mandates a DPIA for specific processing types.

### Recommended Triggers (Judgment Required)

- Minor changes to existing processes where cumulative changes may aggregate to create new privacy risks
- New third-party data sharing arrangements, even for lower-risk processing
- Changes to data retention periods
- Introduction of new analytics or reporting capabilities over existing PII
- Mergers, acquisitions, or corporate restructuring affecting PII processing

### Screening / Threshold Assessment

In practice, organizations implement a two-stage approach:

1. **Screening (Pre-PIA):** A lightweight initial assessment — often a short questionnaire — completed by business or technical teams at the start of any new project or change. This screening determines whether a full PIA is required.
2. **Full PIA:** Triggered when the screening identifies one or more risk indicators above the threshold.

---

## PIA Methodology

### Phase 1: Preparation and Scoping

**Objective:** Define the scope of the assessment and assemble the assessment team.

**Activities:**
- Identify the system, process, or project under assessment
- Define the scope boundary: what PII, what processing activities, which systems, which geographies
- Identify the PIA lead (typically the Privacy Officer, DPO, or a trained privacy professional)
- Identify stakeholders: business owner, IT/development team, legal counsel, security team, relevant third parties
- Gather relevant documentation: system design documents, data flow diagrams, existing policies, legal basis analysis, vendor contracts

**Outputs:**
- Scoping document
- Stakeholder list
- Document inventory

---

### Phase 2: Information Gathering and Data Flow Mapping

**Objective:** Understand how PII flows through the system or process being assessed.

**Activities:**
- Conduct interviews with business owners and technical teams
- Map all PII data flows: collection, storage, transmission, processing, sharing, and deletion
- Document the categories of PII principals (e.g., customers, employees, children, patients)
- Document the categories of PII (e.g., contact data, financial data, health data, behavioral data)
- Identify all systems, databases, and third parties involved
- Document the legal basis for each processing activity
- Identify geographic locations where PII is processed or stored
- Document retention periods

**Outputs:**
- Data flow diagram (DFD) or data inventory
- PII categorization and sensitivity classification
- Legal basis mapping
- Third-party and sub-processor inventory

---

### Phase 3: Privacy Compliance Assessment

**Objective:** Assess whether the proposed processing is consistent with applicable legal requirements and privacy principles.

**Activities:**
- Assess lawfulness: Is there a valid legal basis for each processing activity?
- Assess necessity and proportionality: Is the processing limited to what is necessary for the stated purpose?
- Assess transparency: Are PII principals adequately informed (privacy notice review)?
- Assess purpose limitation: Will data be used only for the purpose disclosed?
- Assess data minimization: Is only the minimum necessary data collected?
- Assess retention: Are retention periods defined and appropriate?
- Assess data subject rights: Can the organization fulfill access, rectification, erasure, portability, and objection requests?
- Assess cross-border transfers: Are appropriate safeguards in place for any international transfers?
- Assess special category data: Are additional protections applied for sensitive data?
- Assess automated decision-making: Are appropriate safeguards in place for any automated decisions?

**Outputs:**
- Compliance gap list
- List of required remediation actions for compliance gaps

---

### Phase 4: Privacy Risk Assessment

**Objective:** Identify, analyze, and evaluate privacy risks to PII principals.

**Activities:**

#### 4a. Threat and Risk Identification
Identify privacy threats across the three key risk categories:
- **Unauthorized disclosure:** Data breach, unauthorized access, excessive sharing
- **Unauthorized modification:** Inaccurate or corrupted PII
- **Unavailability:** Loss of PII, inability to fulfill rights, inability to withdraw consent

For each identified threat, document:
- The threat scenario (what could go wrong)
- The threat source (external attacker, insider, third party, system failure, human error)
- The PII at risk
- The PII principals affected

#### 4b. Likelihood Assessment
For each threat, assess the likelihood of occurrence:
- **High:** Likely to occur without specific mitigating controls
- **Medium:** Possible with some mitigating controls in place
- **Low:** Unlikely given existing or planned controls

Consider factors: sensitivity of data, volume of data, threat actor capability, existing security posture, regulatory environment.

#### 4c. Impact Assessment
For each threat, assess the potential impact on PII principals (not just the organization):
- **High:** Significant harm to individuals — financial loss, physical harm, discrimination, identity theft, reputational damage, loss of employment, psychological distress
- **Medium:** Moderate inconvenience or harm — minor financial loss, temporary embarrassment, manageable disruption
- **Low:** Minimal impact — minor inconvenience, no lasting harm

#### 4d. Risk Scoring
Combine likelihood and impact to produce a risk score:

| Likelihood \ Impact | Low | Medium | High |
|---|---|---|---|
| Low | Low | Low | Medium |
| Medium | Low | Medium | High |
| High | Medium | High | Critical |

#### 4e. Risk Evaluation
Determine whether each risk is acceptable, requires treatment, or is a blocker for the project.

**Outputs:**
- Privacy risk register (listing each risk with threat, likelihood, impact, score, and risk owner)

---

### Phase 5: Risk Treatment Planning

**Objective:** Identify and select controls to reduce unacceptable privacy risks.

**Activities:**
- For each unacceptable risk, identify potential treatment options:
  - **Avoid:** Change or abandon the processing activity
  - **Mitigate:** Implement technical or organizational controls to reduce likelihood or impact
  - **Transfer:** Share risk through contractual means (e.g., insurance, supplier contracts) — note this does not remove regulatory liability
  - **Accept:** Formally accept residual risk within organizational risk tolerance (must be documented and approved)
- Select and document risk treatment controls
- Assign ownership and implementation timelines
- Calculate residual risk after treatment

**Outputs:**
- Risk treatment plan
- Updated risk register with residual risk scores
- Control implementation schedule

---

### Phase 6: Documentation and Reporting

**Objective:** Produce a formal PIA report.

**Required PIA Report Contents:**

1. **Executive Summary**
   - Purpose and scope of the assessment
   - Summary of findings
   - Overall risk level
   - Key recommendations

2. **Description of Processing**
   - System/process description
   - PII categories and data flows
   - Purposes of processing and legal bases
   - Parties involved (controllers, processors, sub-processors)

3. **Compliance Assessment Findings**
   - Results of the compliance gap analysis
   - Identified gaps and remediation actions

4. **Risk Assessment**
   - Identified threats and risks
   - Risk scores (pre-mitigation)
   - Risk treatment decisions and controls
   - Residual risk scores (post-mitigation)

5. **Conclusions and Recommendations**
   - Whether the processing can proceed
   - Conditions or requirements attached to approval (e.g., implement specific controls before go-live)
   - Outstanding risks requiring management acceptance

6. **Sign-off**
   - Privacy Officer / DPO review and approval
   - Business owner acknowledgment
   - Date of assessment and scheduled review date

**Outputs:**
- Formal PIA report
- Updated privacy risk register

---

### Phase 7: Consultation (Where Required)

**Objective:** Where required, consult with relevant stakeholders before finalizing the PIA.

**Activities:**
- If the residual risk remains high after treatment, escalate to senior management for formal risk acceptance
- Under GDPR Article 36, if a DPIA reveals a high residual risk that cannot be mitigated, prior consultation with the relevant data protection supervisory authority is required before processing begins
- Consider consulting with data subject representatives or affected communities for high-impact processing (particularly processing involving vulnerable groups)
- Consult with legal counsel for any unresolved legal compliance questions

**Outputs:**
- Evidence of consultation (meeting minutes, correspondence)
- Regulator pre-consultation records if applicable

---

### Phase 8: Implementation, Monitoring, and Review

**Objective:** Ensure that risk treatment controls are implemented and that the PIA remains current.

**Activities:**
- Track implementation of risk treatment controls against the treatment plan
- Confirm controls are implemented before the system/process goes live
- Schedule periodic review of the PIA (recommended: annually, or sooner if the processing changes materially)
- Link the PIA to the organization's change management process so that material changes trigger a PIA update
- Store the PIA in the organization's privacy management document repository

**Outputs:**
- Evidence of control implementation
- Scheduled review dates in the privacy management calendar
- PIA version control and change log

---

## Summary: What a PIA Must Include

Under ISO 27701, a complete PIA must address the following elements:

| Element | Description |
|---|---|
| Scope | What system, process, or project is being assessed |
| Data Flow Description | What PII is collected, where it flows, who processes it |
| Legal Basis Analysis | Lawfulness of processing for each activity |
| Compliance Assessment | Alignment with privacy principles and legal requirements |
| Risk Identification | Privacy threats to PII principals |
| Risk Analysis | Likelihood and impact scoring |
| Risk Treatment | Controls selected to address unacceptable risks |
| Residual Risk | Risk level after treatment |
| Stakeholder Sign-off | Approval by privacy lead and business owner |
| Review Schedule | When the PIA will next be reviewed |

---

## Key Distinctions: PIA vs DPIA

While ISO 27701 uses the term "privacy risk assessment" and references PIAs (consistent with ISO 29134), GDPR uses the term Data Protection Impact Assessment (DPIA). The two are functionally equivalent for most purposes. The main distinctions are:

- GDPR DPIA is a legal requirement for specific processing types; ISO 27701 PIA is a management system requirement.
- GDPR has specific triggers and mandatory contents under Article 35 and WP29/EDPB guidance.
- GDPR DPIAs may require prior consultation with the supervisory authority; ISO 27701 PIAs do not have an equivalent statutory obligation.
- In practice, a well-executed ISO 27701 PIA will satisfy GDPR DPIA requirements if the scope, methodology, and documentation meet the EDPB's established criteria.

---

## Conclusion

A robust PIA program under ISO 27701 provides organizations with a systematic, evidence-based method to identify and manage privacy risks before they materialize. The key success factors are: triggering PIAs early in the project lifecycle (not as an afterthought), ensuring cross-functional participation, producing well-documented and honest risk assessments, and maintaining a living record that is updated as processing activities evolve.

# ISO 27701 Certification as Evidence of GDPR Compliance

## The Critical Distinction: Evidence vs. Safe Harbor

**ISO 27701 is not a GDPR safe harbor.**

This must be stated explicitly and understood clearly before relying on ISO 27701 certification in any regulatory context. Certification does not:
- Guarantee GDPR compliance
- Shield an organization from regulatory enforcement or fines
- Constitute a legal presumption of compliance with GDPR
- Prevent a supervisory authority from investigating or taking enforcement action

What ISO 27701 certification *does* provide — and this is genuinely significant — is strong, documented evidence that your organization has implemented systematic technical and organisational measures (TOMs) for privacy protection. In the context of a regulatory investigation, this evidence is valuable and will be considered favorably. But it is not a defense in itself, and it does not cover every GDPR obligation.

This document explains exactly what ISO 27701 certification demonstrates, what it does not cover, and how to use it effectively in a regulatory investigation context.

---

## Why ISO 27701 Is Not a GDPR Safe Harbor

### 1. It Is Not an Approved Article 42 Certification Scheme

GDPR Article 42 establishes a certification mechanism: supervisory authorities may approve certification schemes that, when an organization holds certification, create a presumption of compliance with the certified obligations. Approved Article 42 schemes carry specific legal weight within GDPR's compliance framework.

**ISO 27701 has not been approved as a formal Article 42 GDPR certification scheme in most EU member states.** Without that approval, ISO 27701 certification carries no legal presumption of compliance under GDPR. It cannot be invoked as an Article 42 certification for the purpose of demonstrating compliance with GDPR controller or processor obligations.

The UK ICO has indicated that ISO 27701 may be recognized as a privacy seal mechanism under UK GDPR Article 42, which gives it somewhat stronger standing in UK regulatory proceedings — but this is a UK-specific position and does not apply across EU member states.

### 2. It Is Not a Complete Map of GDPR Obligations

ISO 27701 is a management system standard — it provides a framework of controls and practices. GDPR is a legal instrument with specific obligations that go beyond what any management system standard can fully address:

| GDPR Obligation | ISO 27701 Coverage | Gap |
|----------------|-------------------|-----|
| Mandatory DPO appointment (Art. 37) | Requires privacy roles (Clause 5) | Does not mandate DPO appointment; legal criteria for when DPO is required are GDPR-specific |
| Children's consent (Art. 8) | Consent controls (A.1.2.4/A.1.2.5) | No dedicated control for age verification or parental consent |
| Special category lawful basis (Art. 9(2)) | Lawful basis (A.1.2.3) | The specific Art. 9(2) conditions require legal analysis, not just a control |
| Supervisory authority consultation (Art. 36) | DPIA (A.1.2.6, indirectly) | Mandatory consultation after high-residual-risk DPIA not explicitly required by the standard |
| Supervisory authority cooperation (Art. 31) | Not addressed | Outside scope of the standard |
| Specific notification timeframes | Incident controls (A.3.11/A.3.12) | 72-hour breach notification window is a legal requirement; the standard does not specify this timeframe |
| Legal bases for national derogations | Not addressed | Member state law derogations are outside the scope of an international standard |
| Binding corporate rules (Art. 47) | Referenced in A.1.5.2 | No dedicated BCR control |

### 3. Scope Limitations

ISO 27701 certification covers only the defined PIMS scope. An organization may hold a valid certificate, but if certain business units, systems, or processing activities are outside the certified scope, those areas receive **no certification coverage**. A regulator investigating a data breach or complaint in an out-of-scope area cannot rely on the certificate as evidence for that area.

### 4. Historical Violations Are Not Remedied

Achieving certification after a breach or compliance failure does not remedy the historical violation. Regulators assess compliance at the time of the breach or at the time the violation occurred, not at the time certification was obtained. Post-incident certification may demonstrate commitment to improvement but does not negate the pre-certification failure.

---

## What ISO 27701 Certification Does Provide in a Regulatory Investigation

Despite the limitations above, ISO 27701 certification provides genuinely useful and impactful evidence in a regulatory investigation. Regulators — including EU supervisory authorities and the UK ICO — have recognized ISO 27701 as a meaningful indicator of a mature privacy programme.

### 1. Evidence of Technical and Organisational Measures (TOMs) — GDPR Articles 24 and 32

GDPR Articles 24 and 32 require controllers and processors to implement "appropriate technical and organisational measures" to ensure and demonstrate compliance, and to ensure a level of security appropriate to the risk. ISO 27701 certification provides:

- A certificate and audit report demonstrating that an accredited third party has independently verified that controls are in place
- A Statement of Applicability showing which controls are implemented and how they address privacy risks
- A documented privacy risk assessment and treatment methodology showing systematic risk management
- Evidence of management commitment, internal audit, and continual improvement

This is the strongest form of TOM evidence available. In an enforcement context, it demonstrates that the organization did not simply ignore privacy — it invested in a systematic, independently audited compliance programme.

### 2. Accountability Evidence — GDPR Article 5(2)

GDPR Article 5(2) — the accountability principle — requires the controller to be responsible for, and able to demonstrate compliance with, the data protection principles. The PIMS management system creates precisely the accountability paper trail that this requires:

- Privacy Policy demonstrating top management commitment
- Records of Processing Activities (RoPA) showing systematic documentation
- DPIA records showing proactive risk assessment
- Data Subject Rights handling records showing operational compliance
- Internal audit records showing ongoing monitoring
- Management review records showing governance oversight
- Corrective action records showing improvement processes

Together, these demonstrate a systematic accountability programme, not ad hoc compliance.

### 3. Mitigating Factor in Regulatory Proceedings

EU supervisory authorities have discretion in setting fines under GDPR Article 83. The factors they must consider include:

- "Any relevant previous infringements by the controller or processor" (Art. 83(2)(e))
- "The degree of responsibility of the controller or processor taking into account technical and organisational measures implemented" (Art. 83(2)(d))
- "Any action taken by the controller or processor to mitigate the damage" (Art. 83(2)(c))

ISO 27701 certification is directly relevant to Art. 83(2)(d): it demonstrates that the organization implemented systematic technical and organisational measures. In multiple enforcement proceedings across EU member states, regulators have cited the presence (or absence) of a systematic privacy programme as a material factor in determining fines. A certified, mature PIMS is evidence in your favor.

### 4. Processor Due Diligence Evidence — GDPR Article 28

If your organization is a processor, your ISO 27701 certification provides customers (controllers) with evidence that you meet GDPR Article 28 requirements. In a regulatory investigation of a controller where your processing is involved, the controller can point to your certification as evidence that they exercised appropriate due diligence in selecting a processor with sufficient guarantees under Art. 28(1).

---

## Summary: What to Say — and Not Say — to Regulators

| Claim | Accurate? | Recommended Approach |
|-------|-----------|---------------------|
| "We are ISO 27701 certified, therefore we are GDPR compliant" | No | Never say this |
| "We hold ISO 27701 certification, which provides evidence of systematic technical and organisational measures" | Yes | This is the accurate framing |
| "Our ISO 27701 certification was granted by an accredited certification body that independently verified our privacy controls" | Yes | Accurate and impactful |
| "ISO 27701 certification satisfies our GDPR obligation under Article 42" | No | This is inaccurate in most EU jurisdictions |
| "ISO 27701 certification demonstrates our accountability under Article 5(2) and our implementation of TOMs under Articles 24 and 32" | Yes | This is the legally accurate and valuable claim |
| "ISO 27701 certification shows we take privacy seriously and have invested in a systematic, independently audited programme" | Yes | Appropriate for regulatory and public communications |

---

## Practical Recommendations for Using ISO 27701 in Regulatory Contexts

1. **Pair certification with legal analysis**: Do not treat ISO 27701 as a substitute for legal review of GDPR obligations. Use it as the operational backbone of your compliance programme while ensuring legal counsel addresses the gaps identified above.

2. **Maintain comprehensive scope**: Maximize the PIMS scope to cover as many processing activities as possible. Certification value diminishes with a narrow scope.

3. **Maintain current certification**: An expired or lapsed certificate provides little regulatory value. Keep the PIMS surveillance audits current.

4. **Document the link between controls and GDPR**: Your SoA and DPIA records should explicitly reference the GDPR articles they address. This makes the evidence chain clear to regulators.

5. **Do not rely on certification alone for high-risk processing**: If you conduct high-risk processing (special categories, large-scale profiling, systematic monitoring), conduct DPIAs and consider supervisory authority consultation proactively. Certification does not substitute for these obligations.

6. **Keep breach response records**: If a breach occurs, the quality of your response (72-hour notification, individual notification, remediation) is assessed independently of certification. Your PIMS incident response records will be scrutinized.

7. **Use certification in procurement and contracting**: This is where ISO 27701 certification has the clearest, most direct commercial value — as evidence to B2B customers that you meet Article 28 processor requirements.

---

## The Bottom Line

ISO 27701 certification is one of the strongest voluntary privacy compliance instruments available to organizations today. It is recognized by regulators, valued by enterprise customers, and provides genuine, documented evidence of a mature privacy programme. In a regulatory investigation, a well-maintained ISO 27701 certification — especially one with current surveillance audit records, comprehensive scope, and a documented management system — will be viewed favorably and can meaningfully influence enforcement outcomes.

But it is not a safe harbor. It does not guarantee compliance, does not invoke a legal presumption of compliance, and does not substitute for addressing the specific GDPR obligations that the standard does not fully cover. The correct framing — internally and when engaging with regulators — is that ISO 27701 certification is evidence of a systematic and independently audited approach to privacy management, not proof of perfect GDPR compliance.

# ISO 27701 Certification as Evidence of GDPR Compliance: Scope and Limitations

## Executive Summary

ISO 27701 certification can serve as meaningful evidence of a mature, structured approach to privacy management in a regulatory investigation. However, it does not function as a legal safe harbor under the GDPR, does not create a presumption of compliance, and does not shield an organization from regulatory investigation, enforcement action, or administrative fines. Understanding both the evidentiary value and the limitations of certification is essential for organizations that wish to use it strategically in a GDPR compliance program.

---

## The Value of ISO 27701 Certification as Evidence of GDPR Compliance

### 1. Demonstrates Accountability (GDPR Article 5(2))

GDPR's accountability principle (Article 5(2)) requires controllers to be able to demonstrate that they comply with the data protection principles. ISO 27701 certification provides independent, third-party verified documentation that an organization has implemented a systematic Privacy Information Management System (PIMS). In a regulatory investigation, this constitutes direct evidence of accountability — one of the most difficult GDPR principles to demonstrate without a structured compliance program.

Specifically, certification demonstrates that:
- The organization has documented policies, procedures, and controls
- Privacy governance is active (management review, internal audits, corrective action)
- The organization actively monitors and improves its privacy posture
- Controls have been independently verified against an internationally recognized standard

### 2. Supports Compliance with Article 24 (Controller Responsibility)

Article 24 requires controllers to implement appropriate technical and organizational measures to ensure and demonstrate compliance. An ISO 27701 certificate is concrete evidence of "appropriate measures" — a standard that is otherwise left undefined in the regulation. Data protection authorities (DPAs) assessing whether a controller took "appropriate" action are likely to view certification favorably.

### 3. Security of Processing (Article 32)

ISO 27701 builds on ISO 27001's security controls. In a breach investigation, certification provides evidence that the organization had implemented a comprehensive information security management system and a layered set of technical and organizational security measures. This is directly relevant to the Article 32 standard of "appropriate technical and organizational measures."

### 4. GDPR Article 42 — Certification Mechanism

GDPR itself contemplates certification schemes as a tool for demonstrating compliance. Article 42 states:

> "The Member States, the supervisory authorities, the Commission and the Board shall encourage, in particular at Union level, the establishment of data protection certification mechanisms and of data protection seals and marks, for the purpose of demonstrating compliance with this Regulation."

Article 42(3) further states that certification "does not reduce the responsibility of the controller or the processor for compliance" but can be used to demonstrate compliance.

ISO 27701 is not currently an approved Article 42 certification scheme under GDPR (no such approved scheme existed at the European level as of early 2026, though some national-level schemes are under development). This distinction is legally significant. However, ISO 27701 is widely recognized by privacy professionals and regulators as a credible privacy management standard, and its use as evidence in regulatory proceedings is well-established practice.

### 5. Mitigating Factor in Enforcement

GDPR Article 83(2) sets out the factors that supervisory authorities must consider when deciding whether to impose an administrative fine and at what level. Relevant factors include:

- **Article 83(2)(d):** "The degree of responsibility of the controller or processor taking into account technical and organizational measures implemented by them"
- **Article 83(2)(c):** "Any action taken by the controller or processor to mitigate the damage suffered by data subjects"

ISO 27701 certification speaks directly to factor (d) — the degree of responsibility demonstrated through implementation of appropriate measures. Organizations with active certification are in a materially stronger position to argue for reduced fines than those with no documented privacy governance.

Several DPA decisions in the EU have cited the absence of appropriate technical and organizational measures as an aggravating factor. Conversely, evidence of strong governance has been considered in fine mitigation.

### 6. Evidentiary Documentation

ISO 27701 certification generates a significant body of documentation that is valuable in regulatory investigations:
- Statement of Applicability (SoA) — demonstrating active evaluation of all controls
- Risk assessments and risk treatment plans — demonstrating that risks were identified and addressed
- Internal audit reports — demonstrating ongoing monitoring
- Management review minutes — demonstrating leadership engagement
- Incident and breach logs — demonstrating active incident management
- Training records — demonstrating staff awareness
- DPA contract records — demonstrating supply chain management

---

## What ISO 27701 Certification Does NOT Do

### 1. It Is Not a Legal Safe Harbor

ISO 27701 certification does not create any legal presumption of GDPR compliance. GDPR Article 42(4) explicitly states: "Certification shall be additional to, and not replace, other obligations of controllers or processors under this Regulation." No DPA is obligated to accept certification as proof of compliance. Regulatory investigations proceed regardless of certification status.

### 2. It Does Not Cover All GDPR Obligations

ISO 27701's scope is technical and organizational measures — it does not address all GDPR legal obligations. Significant GDPR requirements that ISO 27701 does not fully operationalize include:

- **Legal basis determination:** Whether a specific processing activity is actually lawful under GDPR requires legal analysis. ISO 27701 requires organizations to identify a legal basis, but certification does not verify that the chosen basis is legally correct.
- **Regulatory consultation:** GDPR Article 36 requires prior consultation with the supervisory authority for very high-risk processing. ISO 27701 does not replicate this obligation.
- **Representative in EU (Article 27):** Organizations not established in the EU must appoint an EU representative. ISO 27701 does not address this.
- **Specific national law requirements:** GDPR allows member states to implement national variations (opening clauses). ISO 27701 cannot account for these country-specific requirements.
- **Children's data (Article 8):** The specific age verification and parental consent requirements for children's data require jurisdiction-specific implementation beyond what ISO 27701 prescribes.
- **Employee data:** Many member states have specific national rules for employee data. ISO 27701 is agnostic to these national provisions.

### 3. It Is Not an Approved GDPR Article 42 Scheme

As noted above, ISO 27701 has not been approved as a formal GDPR certification mechanism under Article 42 by the European Data Protection Board (EDPB) or the European Commission. This means it does not carry the formal legal weight of an Article 42 certification scheme. When Article 42-approved schemes become available, certified organizations may need to additionally obtain that certification to gain the associated legal recognition.

### 4. Certification Audit Scope Limitations

ISO 27701 certification audits are scope-limited. The certification covers the organization's PIMS as defined in the scope — it does not certify every processing activity the organization conducts. An organization with a narrow PIMS scope (e.g., covering only HR data) is not certified for its processing of customer data. DPAs will scrutinize whether the processing under investigation falls within the certified scope.

### 5. Point-in-Time Assurance with Annual Surveillance

Certification is granted following a point-in-time audit (typically every three years for a full recertification, with annual surveillance audits in between). The certificate reflects the state of the organization at the time of the last audit. A regulatory investigation triggered by events after the audit may reveal practices that have diverged from certified controls.

### 6. Certification Does Not Excuse Data Breaches

A data breach — particularly a large-scale or severe breach — will be investigated on its specific facts regardless of certification status. DPAs may find that despite certification, specific controls were inadequate, not effectively implemented, or not applied to the systems involved in the breach. The UK ICO, the CNIL, the Dutch AP, and other DPAs have issued significant fines to organizations with otherwise mature compliance programs.

### 7. No Immunity from Regulatory Investigation

Any individual or organization can file a complaint with a DPA. DPAs retain full investigative authority and discretion. A certificate does not prevent a complaint being filed, an investigation being opened, or an enforcement action being taken. It may, however, influence the investigation's outcome.

### 8. Certification Is Not a Substitute for Legal Advice

Regulatory investigations involve complex legal questions — legal bases for processing, scope of data subject rights, interpretation of special category data, and many others — that require qualified legal counsel. Certification demonstrates operational maturity, not legal correctness. Organizations under regulatory scrutiny require privacy lawyers, not just an ISO certificate.

---

## Practical Guidance: How to Maximize the Evidentiary Value of ISO 27701 Certification

### 1. Align PIMS Scope with Risk Exposure
Ensure your PIMS scope covers the processing activities most likely to be subject to regulatory scrutiny. A narrow scope that excludes high-risk processing provides little protection where it matters most.

### 2. Maintain Active, Updated Documentation
Stale documentation undermines the value of certification. Keep your RoPA, PIAs, DPAs, and risk register current. Regulators review the actual documentation, not just the certificate.

### 3. Demonstrate Effective Implementation
Certification audits assess whether controls are documented. Regulatory investigations assess whether they work in practice. Ensure that your controls are genuinely embedded in operations, not just on paper.

### 4. Link Certification to Legal Compliance
Use ISO 27701's GDPR mapping (Annex D) to actively track GDPR compliance obligations, not just certification controls. Maintain a legal compliance register that documents how each GDPR article is being met.

### 5. Respond to Incidents Consistently with Certified Controls
When a breach or complaint occurs, the response should be demonstrably consistent with your certified procedures. Ad hoc responses that diverge from documented procedures undermine the certification's evidentiary value.

### 6. Engage DPO and Legal Counsel Early in Investigations
In any regulatory investigation, present the certification certificate and accompanying documentation as part of the initial response. Frame it as evidence of a systematic approach to compliance, not as a defense that forecloses investigation.

### 7. Monitor for Article 42 Developments
As the EDPB approves formal GDPR certification schemes under Article 42, organizations should evaluate whether to obtain those certifications in addition to ISO 27701, to benefit from the formal legal recognition those schemes carry.

---

## Comparison: ISO 27701 vs. Other Compliance Demonstrations

| Approach | GDPR Legal Status | Evidentiary Weight | Audit-Verified | Covers All GDPR? |
|---|---|---|---|---|
| ISO 27701 Certification | No formal GDPR status | High (industry-recognized) | Yes (third-party) | Mostly operational aspects |
| GDPR Article 42 Approved Scheme | Formal GDPR recognition | Highest | Yes (accredited) | Scope-dependent |
| Binding Corporate Rules (BCRs) | Formal approval for transfers | High (for transfers) | DPA approved | Transfers only |
| Standard Contractual Clauses (SCCs) | Formal for transfers | High (for transfers) | No | Transfers only |
| Internal Compliance Program | No formal status | Moderate | No | Can be comprehensive |
| GDPR Legal Opinion | No formal status | Moderate | No | Legal analysis |

---

## Conclusion

ISO 27701 certification is a valuable, independently verified signal of an organization's commitment to privacy management and its operational implementation of privacy controls. In a regulatory investigation, it provides meaningful evidence of accountability, appropriate measures, and good faith compliance efforts — all of which can influence the direction and outcome of an investigation, and may serve as a mitigating factor in fine calculation.

However, it is not a safe harbor, not a formal GDPR Article 42 certification scheme, and not a substitute for legal compliance or qualified legal advice. Organizations should treat ISO 27701 as one important layer of a comprehensive GDPR compliance strategy, alongside legal analysis, DPA engagement, qualified privacy counsel, and ongoing monitoring of regulatory guidance.

# DORA Key Pillars and Compliance Obligations — EU Bank

## Compliance Deadline

**DORA (Regulation (EU) 2022/2554) became applicable on 17 January 2025** (Art. 64). As an EU credit institution, you are already subject to DORA's full requirements. If you have not yet completed your compliance programme, you are operating in breach of a directly applicable EU regulation.

---

## DORA Structure: Five Operational Pillars

DORA is structured across 9 Chapters. For an EU bank, the five core compliance pillars map to Chapters II–VI:

---

### Pillar 1 — ICT Risk Management Framework (Chapter II, Art. 5–16)

This is the foundational, proactive governance obligation.

**Art. 5 — Board Accountability:**
- The management body (board) bears ultimate responsibility for ICT risk (Art. 5(1))
- The board must define ICT risk appetite and strategy (Art. 5(2)(a))
- The board must formally approve ICT security policies (Art. 5(2)(b))
- The board must ensure adequate ICT budgets and training (Art. 5(2)(d)–(e))

**Art. 6 — ICT Risk Management Framework (RMF):**
- Maintain a comprehensive, documented ICT RMF covering strategies, policies, procedures, protocols and tools (Art. 6(1)–(2))
- Review the RMF after major incidents and at least annually (Art. 6(5))
- Key RTS: CDR (EU) 2024/1774

**Art. 8 — Identification:**
- Identify and classify all ICT assets supporting critical or important functions
- Maintain an ICT asset register with dependency mapping (Art. 8(4))

**Art. 9 — Protection:**
- Implement physical and logical access controls, network segmentation, encryption, and patch management (Art. 9(2)–(4))

**Art. 10 — Detection:**
- Deploy monitoring tools with defined alerting thresholds for anomalous activities (Art. 10(1))

**Art. 11 — Response and Recovery:**
- Documented ICT business continuity policy with BIA, RTO/RPO targets, and annual testing (Art. 11(1)–(6))

**Art. 12 — Backup:**
- Implement backup policies with defined scope, frequency, and offsite/separate storage; test restorability (Art. 12(1)–(3))

**Art. 13 — Learning:**
- Post-incident reviews, threat intelligence monitoring, and ICT security training programmes (Art. 13(1)–(6))

---

### Pillar 2 — ICT-Related Incident Management, Classification and Reporting (Chapter III, Art. 17–23)

This is the reactive, event-driven obligation — distinct from Pillar 1.

**Art. 17 — Incident Management Process:**
- Documented incident management process with defined classification thresholds and escalation paths

**Art. 18 — Classification:**
Incidents are classified using six criteria (Art. 18(1)):
- (a) Number of clients/counterparts affected and transaction value
- (b) Reputational impact
- (c) Duration and geographic spread
- (d) Data losses (availability, authenticity, integrity, confidentiality)
- (e) Criticality of affected services
- (f) Economic impact

Materiality thresholds are set in CDR (EU) 2024/1772.

**Art. 19 — Three-Stage Reporting to Competent Authority:**

| Stage | Deadline | Content |
|-------|----------|---------|
| Initial notification | 4 hours after classification as major | Basic facts, initial impact assessment |
| Intermediate report | 72 hours after classification as major | Updated assessment, root cause indications |
| Final report | 1 month after initial notification | Root cause analysis, lessons learned, recovery measures |

Key RTS: CDR (EU) 2025/301 | Key ITS: CIR (EU) 2025/302 (standard forms)

---

### Pillar 3 — Digital Operational Resilience Testing (Chapter IV, Art. 24–27)

**Art. 24 — Basic Testing Programme:**
- All financial entities must conduct an annual digital operational resilience testing programme
- Covers vulnerability assessments, gap analyses, network security assessments
- Must be performed by independent internal or external parties (Art. 24(4))

**Art. 25 — Testing Types:**
Vulnerability scans, source code reviews (where applicable), scenario-based tests, performance tests, and end-to-end tests.

**Art. 26 — TLPT (Threat-Led Penetration Testing):**
- Required for significant entities meeting criteria in Art. 26(8) (size, complexity, systemic relevance)
- Frequency: at least once every 3 years
- Must cover live production systems with intelligence-led red team scenarios
- Key RTS: CDR (EU) 2025/1190

---

### Pillar 4 — ICT Third-Party Risk Management (Chapter V, Art. 28–44)

**Art. 28 — Third-Party Risk Policy:**
- Adopt and maintain an ICT third-party risk policy (Art. 28(1))
- Maintain a Register of Information on all ICT service arrangements (Art. 28(3)) per CIR (EU) 2024/2956
- Assess ICT concentration risk (Art. 28(6))
- Develop exit strategies for critical arrangements (Art. 28(7))

**Art. 30 — Contractual Provisions:**
All contracts with ICT TPSPs supporting critical or important functions must include provisions covering:
- Service description, data locations, data protection, availability/security, audit rights, termination rights, data portability, and sub-contracting consent (Art. 30(2)(a)–(i))
- Key RTS: CDR (EU) 2024/1773

**Art. 31–44 — Critical TPSP Oversight:**
ESAs may designate ICT providers as Critical Third-Party Service Providers (CTPPs) subject to EU-level oversight by a Lead Overseer (EBA, ESMA, or EIOPA).

---

### Pillar 5 — Information Sharing (Chapter VI, Art. 45)

Financial entities may voluntarily participate in cyber threat intelligence sharing arrangements with other financial entities, subject to data protection and competition rules.

---

## Summary: Key Compliance Obligations for an EU Bank

| Obligation Area | Key Article | Key RTS/ITS |
|----------------|-------------|-------------|
| Board ICT governance | Art. 5 | CDR 2024/1774 |
| ICT Risk Management Framework | Art. 6 | CDR 2024/1774 |
| ICT Asset Register | Art. 8 | — |
| Access controls, patching, monitoring | Art. 9–10 | — |
| BCP/BIA with RTO/RPO | Art. 11 | — |
| Incident management process | Art. 17 | — |
| Incident classification | Art. 18 | CDR 2024/1772 |
| 3-stage incident reporting (4h/72h/1mo) | Art. 19 | CDR 2025/301; CIR 2025/302 |
| Annual resilience testing | Art. 24–25 | — |
| TLPT every 3 years (if applicable) | Art. 26 | CDR 2025/1190 |
| ICT third-party risk policy | Art. 28 | CDR 2024/1773 |
| Register of Information | Art. 28(3) | CIR 2024/2956 |
| Contractual provisions with ICT TPSPs | Art. 30 | CDR 2024/1773 |

---

## Important Note on Proportionality

As a credit institution (bank), you are subject to the **full DORA framework** under Art. 6–14. The simplified ICT risk management framework (Art. 16) does not apply to banks — it is reserved for micro-enterprises and certain small, non-interconnected entities as defined in CDR (EU) 2024/1774.

# DORA Key Pillars and Compliance Obligations — EU Bank

## Compliance Deadline

DORA (Digital Operational Resilience Act), formally Regulation (EU) 2022/2554, entered into force in January 2023 and became applicable in **January 2025**. As an EU bank, you should already be operating under DORA's requirements.

---

## What Is DORA?

DORA is an EU regulation that creates a unified framework for digital operational resilience across the EU financial sector. It replaces and harmonises the patchwork of national and sector-specific ICT risk requirements that previously applied to banks and other financial entities.

DORA applies to a wide range of financial entities including banks (credit institutions), investment firms, insurance companies, payment institutions, crypto-asset service providers, and others.

---

## Key Pillars of DORA

### Pillar 1 — ICT Risk Management

DORA requires financial entities to establish and maintain a comprehensive ICT risk management framework. This includes:

- **Board-level governance**: Senior management and the board must be accountable for ICT risk. They must define risk appetite, approve ICT security policies, and allocate appropriate resources.
- **ICT asset identification**: Entities must identify and classify all ICT systems and assets, particularly those supporting critical or important business functions.
- **Protection measures**: Access controls, network security, encryption, patch management, and change management procedures.
- **Detection capabilities**: Monitoring tools and processes to detect anomalous activities and potential incidents.
- **Response and recovery**: Business continuity plans, disaster recovery procedures, with defined recovery time and recovery point objectives (RTO/RPO).
- **Backup policies**: Regular backups with tested restoration procedures.
- **Learning**: Post-incident reviews and ongoing threat intelligence.

### Pillar 2 — ICT Incident Management and Reporting

DORA establishes a harmonised approach to ICT incident management:

- **Incident classification**: Entities must classify ICT incidents based on criteria including the number of clients affected, reputational impact, duration, data losses, criticality of services, and economic impact.
- **Reporting obligations**: Major ICT incidents must be reported to competent authorities in multiple stages. Generally, there is an initial notification requirement (thought to be within a few hours), followed by intermediate and final reports over subsequent weeks.
- **Cyber threat reporting**: Entities may voluntarily report significant cyber threats.

### Pillar 3 — Digital Operational Resilience Testing

DORA introduces mandatory testing requirements:

- **Basic testing**: All financial entities must conduct regular resilience testing including vulnerability assessments, network security assessments, and scenario-based tests. These should occur at least annually for critical systems.
- **Advanced testing (TLPT)**: Larger, more significant financial entities must conduct Threat-Led Penetration Testing (TLPT) — an intelligence-led, red-team style exercise performed on live production systems. This is required periodically (likely every 2–3 years) by entities meeting certain size and complexity thresholds.

### Pillar 4 — ICT Third-Party Risk Management

Given the financial sector's heavy reliance on cloud providers and other technology vendors, DORA imposes extensive third-party risk requirements:

- **Third-party risk policy**: A formal policy for managing ICT service provider relationships.
- **Register of Information**: A comprehensive inventory of all ICT service arrangements.
- **Contractual requirements**: Contracts with providers of critical or important services must include specific provisions covering service descriptions, security standards, audit rights, exit rights, sub-contracting arrangements, and data portability.
- **Concentration risk**: Entities must assess and manage the risk of over-reliance on single providers.
- **Critical TPSP oversight**: The EU supervisory authorities (EBA, ESMA, EIOPA) can designate systemically important ICT providers as "critical" and subject them to direct EU-level oversight.

### Pillar 5 — Information Sharing

DORA encourages (but does not mandate) financial entities to participate in voluntary cyber threat intelligence sharing arrangements with other financial sector participants.

---

## Main Compliance Obligations for an EU Bank

As a credit institution, your key obligations include:

1. **Governance**: Board formally accountable for ICT risk; ICT risk appetite statement approved at board level
2. **ICT Risk Framework**: Documented, comprehensive framework reviewed at least annually
3. **Asset Management**: Maintained ICT asset register mapped to critical business functions
4. **Incident Process**: Formal classification and multi-stage reporting process in place
5. **Resilience Testing**: Annual basic testing programme; assess whether TLPT applies
6. **Third-Party Management**: Register of Information maintained; contracts reviewed for DORA compliance
7. **Training**: Regular ICT security and resilience training for staff

---

## Note on Proportionality

DORA includes proportionality provisions allowing smaller entities to apply a simplified framework. As a bank, however, you are expected to apply the full framework.

# DORA Obligations: ICT Third-Party Outage — Incident Classification and Reporting

## Scenario: AWS (Critical ICT TPSP) Suffers an Outage

Under DORA, an outage at a critical ICT third-party service provider such as AWS does not automatically trigger your incident reporting obligations — what matters is whether the outage causes an ICT-related incident **at your institution** that meets the materiality thresholds for a "major" incident. Your obligations flow from Chapter III (Art. 17–23), which is the reactive, event-driven framework, distinct from your ongoing ICT risk management obligations in Chapter II.

---

## Step 1 — Activate Your Incident Management Process (Art. 17)

Under Art. 17(1), you must have a documented ICT-related incident management process with:
- Defined roles, responsibilities, and escalation paths
- Thresholds for classifying incidents as "major"
- Senior management and board notification for major incidents (Art. 17(3))

When AWS suffers an outage affecting your services, your incident management team must immediately assess whether the event meets or exceeds your classification thresholds.

---

## Step 2 — Classify the Incident (Art. 18 + CDR (EU) 2024/1772)

Under Art. 18(1), incidents are classified using six mandatory criteria:

| Criterion | Art. 18(1) Ref | AWS Outage Considerations |
|-----------|---------------|--------------------------|
| Number of clients/counterparts affected and transaction value | (a) | How many customers cannot access banking services? What is the aggregate transaction value blocked? |
| Reputational impact | (b) | Is the outage publicly known? Is media coverage affecting your institution's reputation? |
| Duration and geographic spread | (c) | How long has the outage lasted? Which geographic regions are affected? |
| Data losses (availability, authenticity, integrity, confidentiality) | (d) | Has data availability been impaired? Any integrity or confidentiality concerns? |
| Criticality of services affected | (e) | Are critical banking functions (payments, online banking, core systems) unavailable? |
| Economic impact | (f) | What is the estimated financial loss, including foregone transactions and remediation costs? |

**Materiality thresholds** are set in **CDR (EU) 2024/1772** (RTS on classification). An incident is classified as **major** if it meets or exceeds any single threshold. The thresholds specify quantitative triggers (e.g., percentage of clients affected, transaction value, duration in hours).

**Important:** You must classify the incident at your institution, even if the root cause is AWS. DORA does not exclude third-party-caused incidents from your reporting obligations.

---

## Step 3 — Three-Stage Reporting to Your Competent Authority (Art. 19)

Once an incident is classified as **major**, you must follow the three-stage reporting timeline under Art. 19:

| Stage | Deadline | Required Content |
|-------|----------|-----------------|
| **Initial notification** | **4 hours** after classification as major | Basic facts: nature of incident, services affected, initial impact assessment, classification outcome |
| **Intermediate report** | **72 hours** after classification as major | Updated impact assessment, root cause indications (AWS outage identified as source), containment measures taken |
| **Final report** | **1 month** after initial notification | Full root cause analysis, lessons learned, recovery measures implemented, resilience improvements planned |

**Key RTS:** CDR (EU) 2025/301 — sets the content requirements and time limits for each reporting stage
**Key ITS:** CIR (EU) 2025/302 — provides standard forms and templates for submission

**Reporting channel:** Reports must be submitted to your national competent authority (e.g., ECB/SSM if you are a significant institution, or your national banking supervisor for less significant institutions).

---

## Step 4 — Voluntary Cyber Threat Reporting (Art. 19(2))

If the AWS outage is caused by a cyber attack (e.g., a DDoS or ransomware event targeting AWS infrastructure), you may also voluntarily notify your competent authority of the **significant cyber threat**, even before it has caused a classifiable incident at your institution. This is distinct from mandatory incident reporting and can be done proactively.

---

## Step 5 — Payment-Specific Obligations (Art. 23)

As a credit institution, if the AWS outage affects payment processing, Art. 23 applies specific rules for payment-related major incidents. These integrate with EBA payment security reporting obligations.

---

## Your Third-Party Risk Management Obligations in Parallel (Chapter V)

While the Chapter III incident process runs in parallel, the AWS outage also has implications for your Chapter V (third-party risk) obligations:

- **Art. 28(6) — ICT concentration risk:** An AWS outage affecting multiple critical functions demonstrates your concentration risk exposure. You must assess and document this.
- **Art. 28(7) — Exit strategy:** If the outage exposes gaps in your exit or substitution plans for AWS, these must be addressed.
- **Art. 30(2)(d)–(g) — Contractual provisions:** Your AWS contract should contain provisions on availability and security standards, incident notification by AWS to you, and audit/monitoring rights. If these are absent or inadequate, this is a DORA compliance gap.

---

## Common Errors to Avoid

| Error | Correct Approach |
|-------|-----------------|
| Waiting to report until the outage is resolved | The 4-hour clock starts at **classification as major**, not at resolution |
| Submitting only one report | DORA requires **three reports**: initial (4h), intermediate (72h), final (1 month) |
| Treating AWS's own incident communications as sufficient | DORA reporting runs from **your institution** to **your competent authority** — AWS's communications to you do not satisfy your regulatory obligations |
| Classifying as minor to avoid reporting | Misclassification is itself a regulatory breach; apply CDR 2024/1772 thresholds objectively |

---

## Practical Preparation Checklist

- [ ] Does your incident management process (Art. 17) explicitly address third-party-caused incidents?
- [ ] Do you have the CDR 2024/1772 classification thresholds embedded in your incident triage playbook?
- [ ] Have you pre-identified your competent authority contact and reporting channel?
- [ ] Do you have templates aligned with CIR 2025/302 ready for submission?
- [ ] Does your AWS contract include Art. 30(2)(d)–(g) compliant provisions (availability SLAs, incident notification obligations, audit rights)?
- [ ] Have you assessed AWS as a concentration risk under Art. 28(6)?

# DORA Obligations: Critical ICT Third-Party Outage (AWS)

## Overview

Under DORA, an outage at a critical ICT third-party service provider like AWS triggers a set of obligations for your institution. The key point is that your reporting obligations relate to the impact on **your institution and your clients**, not merely to AWS's own incident. Your obligations span incident classification, internal management, and regulatory reporting.

---

## Incident Classification

DORA requires financial entities to classify ICT-related incidents based on defined criteria. When an AWS outage occurs, you must assess whether it constitutes a "major" ICT-related incident at your institution. Classification criteria under DORA typically include:

- **Number of clients affected**: How many customers are unable to access services?
- **Duration of the disruption**: How long are services unavailable?
- **Geographic scope**: Is the impact limited to one region or widespread?
- **Services affected**: Are critical banking functions (payments, online banking, core systems) impacted?
- **Data impact**: Is there any risk to data availability, integrity, or confidentiality?
- **Economic/financial impact**: What is the estimated financial loss?
- **Reputational impact**: Is there significant media or public attention?

DORA's implementing technical standards (published by EBA and the ESAs) provide specific quantitative thresholds that trigger "major incident" classification.

---

## Reporting Obligations

If the AWS outage causes a **major ICT-related incident** at your institution, DORA requires multi-stage reporting to your national competent authority (your banking supervisor):

### Reporting Timeline

DORA establishes a three-stage reporting process:

1. **Initial Notification** — Must be submitted quickly after the incident is classified as major (generally understood to be within a few hours, with some sources suggesting around 4 hours). This covers basic facts and initial impact.

2. **Intermediate Report** — A follow-up report providing more detail on the incident's impact, root cause analysis progress, and containment measures. This is typically required within a few days (approximately 72 hours in some framings).

3. **Final Report** — A comprehensive report including full root cause analysis, lessons learned, and remediation actions. This is typically due within about one month of the initial report.

The exact timelines are defined in DORA's Regulatory Technical Standards (RTS) adopted by the ESAs.

### What to Report

- Nature and description of the incident
- Services and systems affected
- Number of clients and counterparts affected
- Business impact (financial, operational, reputational)
- Root cause (including AWS as the third-party source)
- Remediation actions taken and planned

---

## Third-Party Specific Obligations

Because AWS is an ICT third-party service provider, the DORA incident also has implications for your third-party risk management obligations:

- **Contractual provisions**: Your contract with AWS should include incident notification obligations — AWS should be required to notify you promptly of incidents affecting your services. DORA requires that contracts with critical providers include specific provisions on availability, security, and incident reporting.
- **Concentration risk**: If AWS supports multiple critical functions, this outage highlights concentration risk that you must formally assess and manage under DORA.
- **Exit strategy**: DORA requires exit strategies for critical third-party arrangements, so this incident is an opportunity to test whether your exit plan for AWS is viable.

---

## Voluntary Reporting

DORA also allows (but does not require) financial entities to voluntarily report significant cyber threats to their competent authority, even before they have resulted in a major incident. If the AWS outage is cyber-related, you may consider doing this proactively.

---

## Key Practical Steps

1. Activate your incident management process immediately
2. Apply DORA's classification criteria to determine if the incident is "major"
3. If major, begin the multi-stage regulatory reporting process
4. Document all decisions and evidence throughout
5. Conduct a post-incident review once the outage is resolved
6. Review your AWS contract for DORA-compliant provisions
7. Reassess your ICT concentration risk profile

# DORA Digital Operational Resilience Testing Requirements

## Overview

DORA's digital operational resilience testing requirements are set out in **Chapter IV (Art. 24–27)**. The framework has two tiers: (1) a **basic testing programme** applicable to all in-scope financial entities, and (2) **advanced TLPT** applicable to significant financial entities meeting specific criteria.

---

## Tier 1 — Basic Digital Operational Resilience Testing Programme (Art. 24–25)

### Who Must Comply

All in-scope financial entities, including your bank, must implement a basic digital operational resilience testing programme (Art. 24(1)).

### Required Testing Types (Art. 24–25)

| Testing Type | Description |
|-------------|-------------|
| Vulnerability assessments and scans | Systematic identification of vulnerabilities in ICT systems and infrastructure |
| Source code reviews | Review of application code for security vulnerabilities (where applicable) |
| Scenario-based testing | Testing response to defined adverse scenarios |
| Compatibility tests | Testing system interactions and interfaces |
| Performance tests | Stress testing under expected and peak load conditions |
| End-to-end tests | Testing of complete business process chains |
| Network security assessments | Assessment of network architecture, segmentation and controls |
| Gap analyses | Identification of gaps against policy, standards and best practice |

### Frequency

Critical ICT systems must be tested at least **once a year** (Art. 24(1)).

### Independence Requirement

Tests must be performed by **independent internal or external parties** — internal testers must be operationally independent from the systems being tested (Art. 24(4)).

---

## Tier 2 — Advanced Testing: TLPT (Threat-Led Penetration Testing) (Art. 26)

### What Is TLPT?

TLPT (Threat-Led Penetration Testing) is **not** a standard penetration test. It is an **intelligence-led, adversarial simulation** that:
- Uses real threat intelligence about actual threat actors targeting the financial sector
- Simulates the full attack lifecycle (reconnaissance, initial access, persistence, lateral movement, objectives)
- Is conducted against **live production systems** — not test environments
- Uses qualified external red teams

TLPT is aligned with the **TIBER-EU framework** (which many EU central banks have operated informally). Under DORA Art. 26, TLPT formally supersedes TIBER-EU for in-scope entities. Results are **mutually recognised across EU jurisdictions** for cross-border entities (Art. 26(5)), avoiding duplicate testing.

### Who Must Conduct TLPT?

TLPT is required for financial entities meeting the criteria in Art. 26(8), which relate to:
- **Size and overall risk profile** of the entity
- **Scale and complexity** of ICT systems
- **Relevance to financial stability**

The detailed criteria are further specified in **CDR (EU) 2025/1190**. As a bank of any meaningful size, you should formally assess whether you meet these thresholds — most significant credit institutions do.

### TLPT Frequency

TLPT must be conducted at least **once every 3 years** (Art. 26(1)).

Your competent authority may also require TLPT on specific systems on a more frequent basis (Art. 26(7)).

### Scope of TLPT (Art. 26(2)–(3))

- Must cover **critical or important functions** and their underlying ICT systems
- Must be conducted against **live production systems** (not sandboxes or test environments)
- ICT third-party service providers supporting critical functions **may be included in scope**, with their consent (Art. 26(3)) — for example, AWS supporting a critical function could be in scope

### TLPT Process (Art. 26 + CDR (EU) 2025/1190)

| Phase | Description |
|-------|-------------|
| 1. Scoping | Define critical functions and systems in scope; notify competent authority |
| 2. Threat intelligence | Commission a threat intelligence report from a qualified provider identifying relevant threat actors, techniques, tactics, and procedures (TTPs) |
| 3. Red team test | External red team conducts adversarial simulation using threat intelligence as a guide against live production systems |
| 4. Remediation | Entity remediates findings from the red team exercise |
| 5. Competent authority notification | Notify before and after TLPT completion |
| 6. Attestation | Competent authority issues an attestation letter upon satisfactory completion |
| 7. Mutual recognition | Results shared across EU jurisdictions as applicable |

### TLPT Tester Requirements (Art. 27)

- Must demonstrate capability, integrity, and a sound risk methodology (Art. 27(1))
- Must hold **relevant professional certifications** (Art. 27(2))
- Must have **no conflicts of interest** with the tested entity (Art. 27(3))
- Competent authority maintains a list of qualified testers (Art. 27(4))

Key RTS: **CDR (EU) 2025/1190** specifies detailed TLPT requirements and tester qualifications.

---

## Summary: Testing Requirements at a Glance

| Requirement | Basis | Applies To | Frequency |
|------------|-------|-----------|-----------|
| Vulnerability assessments | Art. 24–25 | All entities | At least annually for critical systems |
| Source code reviews | Art. 25 | All entities (where applicable) | At least annually |
| Scenario-based testing | Art. 25 | All entities | At least annually |
| Network security assessments | Art. 24 | All entities | At least annually |
| TLPT | Art. 26, CDR 2025/1190 | Significant entities meeting Art. 26(8) criteria | At least every 3 years |

---

## Practical Implications for Your Bank

1. **Assess TLPT applicability now**: Formally document whether you meet the Art. 26(8) criteria under CDR 2025/1190. Most banks above micro-enterprise size will qualify.
2. **Establish your basic testing programme**: If you do not have a formal, documented annual testing schedule covering the Art. 25 test types, this is a compliance gap.
3. **Engage qualified testers**: For TLPT, you must use external testers with no conflicts of interest; internal security teams cannot conduct TLPT.
4. **Include third parties in scope**: Consider whether cloud providers (AWS) supporting critical functions should be included in TLPT scope (with their consent).
5. **Notify your competent authority**: TLPT requires pre- and post-notification to your competent authority; this is not a purely internal exercise.

# DORA Digital Operational Resilience Testing Requirements

## Overview

DORA establishes mandatory digital operational resilience testing requirements for EU financial entities. The testing regime has two tiers: a basic programme applicable to all financial entities, and advanced threat-led penetration testing (TLPT) for larger, more significant institutions.

---

## Basic Testing Programme

### What Is Required

All in-scope financial entities, including banks, must implement a digital operational resilience testing programme. The types of testing required include:

- **Vulnerability assessments**: Systematic scans and assessments to identify weaknesses in ICT systems
- **Network security assessments**: Evaluation of network architecture, controls, and segmentation
- **Gap analyses**: Identification of gaps against standards and policies
- **Scenario-based tests**: Testing responses to defined adverse scenarios (e.g., system failures, cyber attacks)
- **Compatibility tests**: Testing of system integrations and interfaces
- **Performance tests**: Stress and load testing to verify system capacity

### How Often

Critical ICT systems should be tested **at least annually**. The testing programme should be documented and formally scheduled.

### Who Can Perform Tests

Tests should be conducted by independent parties — either internal teams that are independent from the systems being tested, or external third-party testers. The key requirement is independence and objectivity.

---

## TLPT — Threat-Led Penetration Testing

### What Is TLPT?

Threat-Led Penetration Testing (TLPT) is an advanced form of security testing that goes beyond standard penetration testing. Key characteristics:

- **Intelligence-led**: TLPT is based on real threat intelligence about threat actors, their techniques, tactics, and procedures (TTPs) that are relevant to your institution
- **Adversarial simulation**: TLPT simulates a full, realistic attack by a sophisticated threat actor across the full attack lifecycle
- **Live production systems**: Unlike standard pen tests which often target test environments, TLPT is conducted against live production systems
- **Red team approach**: External qualified red teams conduct the exercise, attempting to achieve defined objectives (e.g., accessing core banking systems, exfiltrating data)

TLPT is based on the **TIBER-EU framework** (Threat Intelligence-Based Ethical Red-Teaming) developed by the ECB, which many EU financial institutions will be familiar with. DORA formalises TLPT as a regulatory requirement.

### Who Must Conduct TLPT?

TLPT is not required of all financial entities — it applies to larger, more significant institutions that meet certain criteria relating to:
- Size and systemic importance
- Complexity of ICT systems
- Overall risk profile

Smaller institutions are generally not required to conduct TLPT, though they may do so voluntarily. Whether your institution is subject to TLPT will depend on whether your competent authority determines you meet the relevant thresholds.

### How Often Is TLPT Required?

DORA requires TLPT to be conducted **at least every 2–3 years** (the exact frequency is typically every 3 years). Your competent authority may require more frequent testing in specific circumstances.

### The TLPT Process

A typical TLPT process under DORA involves:

1. **Scoping**: Defining which critical functions and systems are in scope
2. **Threat intelligence gathering**: Commissioning a threat intelligence report from a qualified provider
3. **Red team simulation**: Qualified external testers conduct the adversarial simulation
4. **Reporting and remediation**: Findings are documented and remediated
5. **Supervisor involvement**: The competent authority is notified and involved in the process
6. **Attestation**: Upon completion, an attestation may be issued by the competent authority

### Tester Requirements

TLPT must be conducted by qualified external testers who:
- Have relevant technical expertise and certifications
- Have no conflicts of interest with the tested institution
- Can demonstrate a sound methodology

### Cross-Border Recognition

For institutions operating in multiple EU Member States, DORA provides for mutual recognition of TLPT results across jurisdictions, avoiding the need for duplicate testing.

---

## Summary

| Testing Type | Applies To | Frequency |
|-------------|-----------|-----------|
| Basic testing (vulnerability scans, network security, scenarios) | All financial entities | At least annually |
| TLPT | Significant institutions meeting criteria | At least every 3 years |

---

## Practical Considerations

- Document your testing programme formally with schedules and results
- Assess whether your institution meets the TLPT threshold criteria
- Engage qualified external testers for TLPT who meet DORA's requirements
- Consider whether critical cloud providers (like AWS) should be in scope for TLPT
- Use test results to drive remediation and improvement in your resilience posture

# DORA Third-Party Risk: Contracts and Due Diligence for 15 Cloud and SaaS Providers

## Governing Framework

Your obligations for managing 15 cloud and SaaS providers under DORA are set out in **Chapter V (Art. 28–44)**. The requirements differ depending on whether each arrangement supports a **critical or important function** — this distinction is the single most important factor in determining your contractual and due diligence obligations.

---

## Step 1 — Classify Each Arrangement (Critical/Important vs. Non-Critical)

Before applying any contractual requirements, you must assess which of your 15 providers support **critical or important functions**. This classification determines:
- The level of contractual provisions required (Art. 30(2) vs. Art. 30(3))
- The due diligence depth required
- Whether the arrangement must appear in your Register of Information with full mandatory fields

**How to classify:** Under Art. 28 and your ICT third-party risk policy (Art. 28(1)), map each provider to the business functions they support, then assess whether those functions are critical or important to your operations. The classification must be documented and reviewed at least annually.

---

## Step 2 — Contractual Provisions Required (Art. 30)

### For Critical or Important Function Providers — Art. 30(2)(a)–(i)

All contracts with providers supporting critical or important functions **must** include the following provisions per Art. 30(2):

| Art. 30(2) Ref | Required Provision | Practical Notes for Cloud/SaaS |
|---------------|-------------------|-------------------------------|
| (a) | Clear, complete description of ICT services provided | Include service scope, SLAs, service levels for each component |
| (b) | Locations where services are provided and where data is processed/stored | Critical for data sovereignty; specify regions; cover all sub-processors |
| (c) | Data protection provisions — compliance with GDPR and relevant data protection rules | Ensure DORA data protection clauses complement your DPA with the provider |
| (d) | Availability, authenticity, integrity, and confidentiality of data and services | Uptime SLAs, data integrity controls, encryption standards |
| (e) | **Audit and access rights** for the financial entity, the competent authority, and the resolution authority | This is a common gap with large cloud providers; must be substantive, not nominal |
| (f) | Termination rights and minimum exit notice periods | Exit for cause (breach, insolvency, regulatory direction) and exit for convenience |
| (g) | Reporting and monitoring obligations — provider must report incidents to you promptly | Defines your ability to monitor the provider's performance and security posture |
| (h) | Data portability and migration assistance upon termination | Ensures you can retrieve your data and migrate to an alternative provider |
| (i) | Sub-contracting arrangements — prior consent requirements and notification obligations for changes | Prevents undisclosed sub-processing chains; requires visibility of sub-processors |

**Key RTS:** CDR (EU) 2024/1773 — specifies detailed requirements for each of the Art. 30(2) provisions
**Key RTS:** CDR (EU) 2025/532 — specific requirements for subcontracting of ICT services

### For Non-Critical Arrangements — Art. 30(3)

Providers supporting non-critical functions are subject to a **lighter contractual regime** under Art. 30(3). The core provisions on service description and data protection still apply, but the full audit rights, exit provisions, and sub-contracting controls of Art. 30(2) are not mandatory.

---

## Step 3 — Pre-Contractual Due Diligence (Art. 28(4))

Before entering any new ICT service arrangement (or at renewal for existing arrangements), you must conduct **pre-contractual due diligence**. For critical or important function providers, this should include:

- Assessment of the provider's ICT security posture and certifications (e.g., ISO 27001, SOC 2)
- Assessment of the provider's financial stability and business continuity capabilities
- Review of the provider's sub-contracting chain (sub-processors)
- Assessment of data location and jurisdictional risks
- Assessment of **substitutability** — how easily could you replace this provider?
- Assessment of ICT concentration risk (Art. 28(6)) — are multiple critical functions supported by the same provider?

---

## Step 4 — Maintain the Register of Information (Art. 28(3) + CIR (EU) 2024/2956)

You must maintain a **Register of Information** covering **all** ICT service arrangements — all 15 providers must be registered, not only those supporting critical functions. The Register is submitted to your competent authority annually (or on demand).

**Mandatory fields per CIR (EU) 2024/2956 include:**

| Field | Description |
|-------|-------------|
| Arrangement reference | Unique identifier for each arrangement |
| TPSP name and LEI | Legal entity identifier of the service provider |
| Service type | Nature of ICT service (SaaS, IaaS, PaaS, etc.) |
| Critical or important function | Whether the function supported is critical/important (Y/N) |
| Data storage location | Country/region where data is stored and processed |
| Substitutability | Assessment of ease of substitution |
| Sub-processors | Chain of sub-processors |
| Contractual start/end dates | Term of the arrangement |

**Important:** A vendor list or procurement register does not satisfy the Register of Information requirement. The CIR 2024/2956 mandatory fields are specific and detailed.

---

## Step 5 — ICT Concentration Risk Assessment (Art. 28(6) + Art. 29)

With 15 providers, you must assess:

- Whether any single provider supports **multiple critical functions** (concentration at entity level — Art. 29)
- Whether there is **sector-wide concentration** in a small number of providers (e.g., if AWS or Microsoft Azure supports critical functions for many EU banks — this is relevant context for regulatory discussions but does not change your entity-level obligations)

If you identify material concentration risk (e.g., AWS supports core banking, payments, and disaster recovery), you must:
- Document the concentration risk assessment
- Consider mitigation measures (multi-cloud strategy, alternative providers)
- Reflect this in your exit strategy planning (Art. 28(7))

---

## Step 6 — Exit Strategies (Art. 28(7))

For each critical or important function supported by a third-party provider, you must develop and maintain a documented **exit strategy** covering:
- Trigger conditions for exit (regulatory direction, provider insolvency, material breach, resilience failure)
- Steps for transition to an alternative provider or in-house solution
- Data migration plan (aligned with Art. 30(2)(h) contractual rights)
- Estimated transition timescale and resource requirements

---

## Gap Assessment: Common Issues with Cloud/SaaS Contracts

| Common Gap | DORA Requirement |
|-----------|-----------------|
| Audit clause is nominal ("right to request reports") only | Art. 30(2)(e) requires substantive audit and access rights exercisable by the entity and competent authority |
| No data location specification in contract | Art. 30(2)(b) requires explicit specification of processing and storage locations |
| Sub-processor chain is opaque | Art. 30(2)(i) requires prior consent and notification of changes to sub-contracting |
| No termination/exit assistance clause | Art. 30(2)(f)–(h) require exit notice periods, termination rights, and migration assistance |
| Register of Information is an informal spreadsheet | CIR 2024/2956 requires specific mandatory fields; informal registers do not comply |
| No concentration risk documented | Art. 28(6) and Art. 29 require formal concentration risk assessment |

---

## Recommended Action Plan for Your 15 Providers

1. **Classify all 15 providers** as critical/important or non-critical against your function mapping
2. **Review all contracts** for Art. 30(2) provisions; identify gaps
3. **Negotiate contract addenda** where required (budget time — large cloud providers have standard DPAs that may need supplementation)
4. **Build the Register of Information** per CIR 2024/2956 mandatory fields
5. **Conduct concentration risk assessment** — map which providers support which critical functions
6. **Develop exit strategies** for critical providers
7. **Implement ongoing monitoring** per Art. 28(3) — annual review of all arrangements

# DORA Third-Party Risk: Contracts and Due Diligence for Cloud and SaaS Providers

## Overview

DORA's ICT third-party risk management requirements are among its most complex and practically significant obligations, particularly for financial institutions that rely heavily on cloud and SaaS providers. With 15 different providers, you have substantial work to do to achieve DORA compliance.

---

## Classifying Your Providers: Critical vs. Non-Critical

The first step is to classify each of your 15 providers based on whether they support **critical or important functions** of your institution. This distinction determines the level of contractual and due diligence requirements.

**Critical or important functions** are those whose disruption, failure, or inadequate performance would materially impact:
- The continuity of your banking operations
- Your financial soundness
- Your customers' interests
- Financial stability

Cloud infrastructure providers (IaaS like AWS, Azure, GCP) supporting core banking systems, payment processing, or business continuity are likely to be classified as critical. Peripheral SaaS tools (e.g., HR software, minor productivity tools) may be non-critical.

---

## Required Contractual Provisions

### For Critical/Important Function Providers

DORA requires that contracts with providers supporting critical or important functions include specific provisions covering:

1. **Service description**: A clear, complete description of the ICT services provided
2. **Data locations**: Where services are provided and where data is stored and processed — important for data sovereignty and regulatory access
3. **Data protection**: Provisions on data security, confidentiality, and compliance with applicable data protection laws (GDPR)
4. **Availability and integrity**: SLAs and provisions on service availability, data integrity, and security standards
5. **Audit rights**: Rights for your institution, your competent authority, and resolution authorities to audit the provider and access relevant information — this is a significant requirement that many standard cloud contracts do not adequately address
6. **Termination rights**: Defined rights to terminate and minimum notice periods; termination for cause and for convenience
7. **Incident reporting**: Obligations for the provider to notify you of incidents affecting your services
8. **Data portability and migration**: Rights to retrieve your data and receive migration assistance upon termination
9. **Subcontracting**: Requirements for consent before the provider subcontracts key elements; visibility of the subcontracting chain

### For Non-Critical Providers

Lighter contractual requirements apply for non-critical arrangements, focused on basic service description and data protection provisions.

---

## Due Diligence Requirements

DORA requires pre-contractual due diligence before entering new ICT service arrangements. For critical providers, this should cover:

- **Security posture assessment**: Review of certifications (ISO 27001, SOC 2 Type II), security policies, and incident history
- **Financial stability**: Assessment of the provider's financial health and business continuity
- **Data practices**: Understanding of data location, sub-processing chains, and data handling
- **Substitutability**: Can you replace this provider if needed? How quickly?
- **Concentration risk**: Are multiple critical functions dependent on the same provider?
- **Regulatory compliance**: Does the provider comply with relevant regulations?

Due diligence should be repeated periodically throughout the relationship — typically annually for critical providers.

---

## Register of Information

DORA requires financial entities to maintain a **Register of Information** covering all ICT service arrangements. This is a detailed inventory — not merely a vendor list — that must capture:

- Provider identity and legal entity details
- Description of services provided
- Whether the arrangement supports critical or important functions
- Data storage locations
- Sub-processor information
- Substitutability assessment
- Contract dates and terms

This Register must be submitted to your competent authority (at least annually or on request).

---

## Concentration Risk Assessment

With 15 providers, concentration risk is a key concern. DORA requires you to assess:

- Whether any single provider supports multiple critical functions (entity-level concentration)
- The feasibility of substituting a provider if needed
- Your overall dependency profile across providers

If significant concentration risk exists (e.g., AWS supports five critical functions), you must document this and consider mitigating strategies such as multi-cloud arrangements.

---

## Exit Strategies

For critical ICT service arrangements, DORA requires documented exit strategies covering:
- Conditions that would trigger exit
- Steps for transitioning to an alternative provider
- Data migration and portability arrangements
- Estimated timelines and resources required

---

## Practical Steps for Your 15 Providers

1. Map each provider to the business functions they support and classify as critical/important or non-critical
2. Review all existing contracts against DORA's required provisions and identify gaps
3. Negotiate contract amendments or addenda as needed — this is often the most time-consuming step with large cloud providers
4. Build your Register of Information with the required detail
5. Document concentration risk assessments
6. Develop exit strategies for critical provider arrangements
7. Implement ongoing monitoring and annual review processes

# DORA vs. EBA Guidelines on ICT and Security Risk Management: Key Differences

## Critical Preliminary Point: EBA/GL/2019/04 Has Been Superseded

The most important thing to understand is that **EBA/GL/2019/04 (EBA Guidelines on ICT and Security Risk Management) no longer applies to you as a DORA in-scope entity.** Since **17 January 2025** — DORA's application date under Art. 64 — DORA is the governing framework for in-scope EU financial entities. The EBA Guidelines were soft law guidance. DORA is a directly applicable EU Regulation (Regulation (EU) 2022/2554).

Being "EBA Guidelines compliant" does **not** mean you are DORA compliant. There are substantial new requirements in DORA with no equivalent in the EBA Guidelines. This response maps the key differences to help you identify your residual gaps.

---

## Comparison Table: DORA vs. EBA/GL/2019/04

### 1. Legal Status and Binding Nature

| Dimension | EBA/GL/2019/04 | DORA (Regulation (EU) 2022/2554) |
|-----------|---------------|----------------------------------|
| Legal form | Soft law guidelines (comply-or-explain) | Directly applicable EU Regulation — binding law |
| Enforcement | National supervisor discretion | Supervisory powers mandated by DORA Art. 46–56; fines and sanctions |
| Article-level obligations | General principles | Specific, granular Article-level obligations with RTS/ITS specifying detailed requirements |

**Gap:** EBA Guidelines compliance cannot be relied upon as DORA compliance. DORA creates mandatory obligations, not best practice guidance.

---

### 2. ICT Risk Management Framework

| Dimension | EBA/GL/2019/04 | DORA Art. 5–16 |
|-----------|---------------|----------------|
| Board accountability | Recommended; principles-based | Art. 5(1): Explicit board-level legal responsibility for ICT risk |
| Board approval of ICT policy | Encouraged | Art. 5(2)(b): Mandatory — board must formally approve ICT security policies |
| RMF documentation | Required at high level | Art. 6(1): Comprehensive documented RMF with mandatory elements per CDR (EU) 2024/1774 |
| Annual RMF review | Encouraged | Art. 6(5): Mandatory annual review and review after major incidents |
| ICT asset register | Mentioned | Art. 8(4): Mandatory; must be mapped to critical/important functions |
| Backup restore testing | Good practice | Art. 12(3): Mandatory — restorability of backups must be tested |
| RTO/RPO | Mentioned | Art. 11(2): Mandatory RTO and RPO definition for critical functions |

**Key gaps if EBA-compliant only:**
- Board may not have formally approved ICT risk appetite as a distinct, documented obligation
- ICT RMF may lack the granular elements specified in CDR 2024/1774
- Asset register may exist but not be mapped to critical/important functions per Art. 8 requirements
- Backup restore testing may be informal or undocumented

---

### 3. ICT-Related Incident Management and Reporting

This is an area of **substantial new obligation** under DORA with no equivalent in EBA/GL/2019/04.

| Dimension | EBA/GL/2019/04 | DORA Art. 17–23 |
|-----------|---------------|-----------------|
| Incident classification criteria | General guidance | Art. 18(1)(a)–(f): Six mandatory classification criteria with quantitative thresholds in CDR (EU) 2024/1772 |
| Mandatory major incident reporting | Not required | Art. 19: Mandatory three-stage reporting to competent authority |
| Reporting timelines | Not specified | Art. 19: 4h initial / 72h intermediate / 1 month final |
| Reporting templates | None | CIR (EU) 2025/302: Mandatory standard forms for submission |
| Voluntary cyber threat reporting | Not covered | Art. 19(2): Optional voluntary reporting of significant cyber threats |
| Payment-related incidents | PSD2/EBA separate | Art. 23: Integrated within DORA for credit institutions |

**Key gaps if EBA-compliant only:**
- No formal incident classification framework using the Art. 18(1) / CDR 2024/1772 criteria
- No three-stage reporting process or documented reporting SOP
- No templates aligned with CIR 2025/302
- Competent authority reporting channel and contact not pre-identified
- 4h/72h/1-month timelines not embedded in incident response procedures

---

### 4. Digital Operational Resilience Testing

Another area of **entirely new obligations** under DORA.

| Dimension | EBA/GL/2019/04 | DORA Art. 24–27 |
|-----------|---------------|-----------------|
| Testing requirements | General security testing recommended | Art. 24–25: Mandatory annual testing programme with specific test types |
| TLPT | Not covered | Art. 26: Mandatory for significant entities; at least every 3 years; requires threat intelligence and live production system testing |
| Tester qualifications | Not specified | Art. 27: Certification requirements, conflict-of-interest rules |
| Competent authority involvement | None | Art. 26: Pre- and post-TLPT notification; competent authority attestation |

**Key gaps if EBA-compliant only:**
- No formal annual resilience testing programme as defined in Art. 24–25
- TLPT has almost certainly never been conducted; entity likely has not assessed whether it is subject to TLPT
- No relationship with competent authority on TLPT scheduling and attestation

---

### 5. ICT Third-Party Risk Management

DORA's Chapter V is **substantially more prescriptive** than EBA/GL/2019/04's third-party provisions.

| Dimension | EBA/GL/2019/04 | DORA Art. 28–44 |
|-----------|---------------|-----------------|
| Third-party risk policy | Required | Art. 28(1): Required; detailed content specified in CDR (EU) 2024/1773 |
| Register of Information | Not required in this form | Art. 28(3) + CIR 2024/2956: Mandatory Register with specific mandatory fields; submitted to competent authority |
| Contractual provisions | High-level guidance | Art. 30(2)(a)–(i): Nine mandatory contractual provisions per CDR 2024/1773 |
| Subcontracting provisions | Mentioned | CDR (EU) 2025/532: Detailed subcontracting rules; prior consent required |
| Concentration risk | Mentioned | Art. 28(6) + Art. 29: Formal concentration risk assessment mandatory |
| Exit strategies | Mentioned | Art. 28(7): Mandatory documented exit strategies for critical arrangements |
| Critical TPSP oversight | None | Art. 31–44: EU-level oversight of CTPPs by Lead Overseer; JON; JETs |

**Key gaps if EBA-compliant only:**
- Existing vendor management framework likely lacks CIR 2024/2956 Register of Information fields
- Existing contracts predate DORA; likely missing Art. 30(2)(e) audit rights, (f) termination rights, (h) data portability, (i) subcontracting consent
- No formal concentration risk documentation
- Exit strategies may be absent or informal
- No awareness of Critical TPSP designations relevant to your providers

---

### 6. Information Sharing

| Dimension | EBA/GL/2019/04 | DORA Art. 45 |
|-----------|---------------|--------------|
| Cyber threat sharing | Not specifically covered | Art. 45: Voluntary cyber threat intelligence sharing arrangements explicitly permitted and regulated |

---

## Summary: Your Key Residual Gaps

Based on EBA Guidelines compliance as a starting point, your likely material gaps under DORA are:

| Gap Area | DORA Obligation | Priority |
|---------|----------------|----------|
| Three-stage incident reporting process | Art. 19, CDR 2025/301, CIR 2025/302 | HIGH — new obligation with no EBA equivalent |
| Incident classification using CDR 2024/1772 thresholds | Art. 18, CDR 2024/1772 | HIGH |
| Annual resilience testing programme | Art. 24–25 | HIGH |
| TLPT applicability assessment and scheduling | Art. 26, CDR 2025/1190 | HIGH |
| Register of Information per CIR 2024/2956 | Art. 28(3), CIR 2024/2956 | HIGH |
| Contract remediation for Art. 30(2)(a)–(i) provisions | Art. 30, CDR 2024/1773 | HIGH — likely requires contract renegotiation |
| Concentration risk formal assessment | Art. 28(6), Art. 29 | MEDIUM |
| Exit strategies for critical arrangements | Art. 28(7) | MEDIUM |
| Board-level ICT governance formalisation | Art. 5(1)–(2) | MEDIUM — likely requires governance process changes |
| CDR 2024/1774 RMF elements gap | Art. 6, CDR 2024/1774 | MEDIUM |

---

## Important Note

Do not treat EBA Guidelines compliance as a shortcut to DORA compliance. DORA is a distinct regulation with specific Article-level obligations, many of which have no equivalent in EBA/GL/2019/04. A formal DORA gap analysis against the full Chapter II–V framework is strongly recommended to identify all residual obligations.

# DORA vs. EBA ICT Guidelines: Key Differences for an EBA-Compliant Bank

## Overview

Being compliant with the EBA Guidelines on ICT and Security Risk Management (EBA/GL/2019/04) is a solid starting point for DORA compliance, but it does not mean you are fully DORA compliant. DORA introduces significantly more prescriptive and detailed requirements in several areas, and creates entirely new obligations that have no equivalent in the EBA Guidelines.

---

## Legal Nature: A Fundamental Difference

The first critical difference is the **legal status** of each framework:

- **EBA Guidelines (EBA/GL/2019/04)**: Soft law. These are guidelines under the comply-or-explain principle. Supervisors are encouraged to incorporate them into supervisory practice, but they are not directly binding EU law in the same way as a Regulation.

- **DORA**: A directly applicable EU Regulation (Regulation (EU) 2022/2554). It is binding law across all EU Member States without need for national implementation. Non-compliance exposes you to regulatory sanctions, not just supervisory criticism.

This difference means that your EBA Guidelines compliance may have been assessed on a principles-based basis, while DORA requires granular, article-by-article compliance with specific obligations.

---

## Area-by-Area Comparison

### ICT Risk Management Framework

**EBA Guidelines:** Required a comprehensive ICT risk framework at a principles level, covering governance, risk identification, protection, detection, response and recovery. Board involvement was recommended.

**DORA (Art. 5–16):** More prescriptive requirements including:
- Explicit board-level legal responsibility for ICT risk — not just a recommendation
- Board must formally approve ICT security policies
- More detailed requirements for ICT asset registers, specifically mapped to critical business functions
- Mandatory backup restore testing (not just backup policy)
- Mandatory, formally defined RTO/RPO targets for critical functions
- Detailed RTS specifying the precise elements the ICT risk framework must contain

**Likely gap:** Even with EBA Guidelines compliance, you may lack the formal board accountability structures, asset register depth, and documented RTO/RPO that DORA requires.

---

### ICT Incident Management and Reporting

This is one of the **most significant areas of new obligation** under DORA.

**EBA Guidelines:** Provided guidance on incident management processes and encouraged internal escalation and competent authority notification for major incidents, but without specific timelines or standardised reporting formats.

**DORA (Art. 17–23):** Creates entirely new, mandatory reporting obligations:
- Six specific classification criteria for determining whether an incident is "major"
- Quantitative materiality thresholds (set in implementing standards) that determine when reporting is mandatory
- **Three-stage mandatory reporting** to the competent authority with defined timelines
- Harmonised reporting templates for all EU financial entities
- Specific rules for payment-related incidents

**Likely gap:** You almost certainly do not have the multi-stage regulatory reporting process with defined timelines and standardised templates that DORA requires.

---

### Digital Operational Resilience Testing

**EBA Guidelines:** Recommended security testing including penetration testing and vulnerability assessments as part of good practice, but without specific requirements on frequency, types, or advanced testing.

**DORA (Art. 24–27):** Creates an entirely new mandatory testing framework:
- Mandatory annual basic testing programme covering specific test types
- TLPT (Threat-Led Penetration Testing) for larger, significant institutions — this is an intelligence-led, adversarial simulation on live production systems, conducted every 2–3 years
- Specific requirements on tester qualifications and independence
- Competent authority involvement in the TLPT process

**Likely gap:** You may have security testing in place, but not a formal DORA-structured annual programme, and almost certainly have not assessed TLPT applicability or conducted TLPT.

---

### ICT Third-Party Risk Management

**EBA Guidelines:** Required outsourcing and ICT third-party risk management, with provisions on contractual requirements. However, the EBA Outsourcing Guidelines (EBA/GL/2019/02, separate from the ICT Guidelines) were the primary framework for outsourcing.

**DORA (Art. 28–44):** Much more detailed and prescriptive:
- Mandatory Register of Information covering all ICT service arrangements (submitted to regulator annually)
- Nine specific mandatory contractual provisions for providers supporting critical functions
- Formal ICT concentration risk assessment requirements
- Mandatory exit strategies for critical arrangements
- EU-level oversight framework for systemically important ICT providers (cloud providers, etc.)

**Likely gap:** Your existing third-party contracts likely predate DORA and may lack required provisions on audit rights, data portability, and subcontracting controls. Your vendor registry is likely not in the format required for the Register of Information.

---

## Summary: Key Gaps After EBA Guidelines Compliance

| Gap Area | Priority |
|---------|---------|
| Multi-stage incident classification and reporting with timelines | High — entirely new obligation |
| Formal annual resilience testing programme (DORA test types) | High — no equivalent in EBA Guidelines |
| TLPT assessment and programme | High — entirely new obligation |
| Register of Information in DORA-required format | High — new obligation |
| Contract remediation for DORA-required provisions | High — likely significant work |
| Formal concentration risk assessment documentation | Medium |
| Exit strategies for critical ICT arrangements | Medium |
| Enhanced board-level ICT governance formalisation | Medium |

---

## Recommended Approach

Given your EBA Guidelines compliance as a baseline, we recommend:

1. Conduct a formal DORA gap analysis mapping your current state against each DORA article
2. Prioritise incident management and reporting — this has the most significant new obligations with no EBA equivalent
3. Assess TLPT applicability and engage your competent authority on TLPT scheduling
4. Audit all ICT service provider contracts against DORA's required contractual provisions
5. Build your Register of Information in the format required by DORA's implementing standards

Do not assume that EBA Guidelines compliance translates to DORA compliance. A systematic article-by-article gap assessment is the only reliable way to identify and address your specific compliance gaps.

# DPDPA Applicability for US Technology Companies with Indian Customers

## Does the DPDPA Apply to Your Company?

**Yes — the DPDPA applies to your organisation.** India's Digital Personal Data Protection Act, 2023 (DPDPA) has explicit extra-territorial reach under **Section 3**. The Act covers:

1. Processing of digital personal data **within India's territory**, AND
2. Processing of digital personal data **outside India** where it relates to offering goods or services to individuals **located in India** at the time of collection.

As a US company that has acquired Indian customers and processes their data (even on US servers), you are a **Data Fiduciary** under the DPDPA — the equivalent of what GDPR calls a "data controller." The Act's reach is clear: any organisation outside India that offers goods or services to individuals located in India is captured.

> **Key distinction:** The DPDPA applies only to **digital personal data** — data in digital form, or data originally in non-digital form that is subsequently digitised. Physical/paper records never digitised fall outside scope. This differs from GDPR, which covers all personal data regardless of medium.

**Full compliance deadline: 13 May 2027** (18 months from the Digital Personal Data Protection Rules, 2025 notified on 13 November 2025). Your organisation should be in active preparation now.

---

## Your Key Obligations as a Data Fiduciary

### 1. Lawful Basis for Processing (Section 4)

The DPDPA provides **only two lawful bases** — far narrower than GDPR's six:

| Basis | Provision |
|-------|-----------|
| **Consent** | Section 6 |
| **Certain Legitimate Uses** | Section 7 (8 enumerated categories — exhaustive list) |

There is **no general "legitimate interests" balancing test** under the DPDPA. If your current processing relies on GDPR legitimate interests (e.g., analytics, marketing, fraud prevention), you must map each activity to either consent or one of the 8 Section 7 categories, or obtain consent.

### 2. Notice Obligation (Section 5 + Rule 3)

Before or at the time of collecting personal data, you must provide a **standalone notice** to each Data Principal (individual). The notice must be:

- In clear, plain language (no legalese)
- **Independent** — not buried in terms and conditions
- Containing an itemised list of data collected
- Stating the specific purpose(s) of processing
- Identifying categories of recipients
- Stating the retention period
- Explaining how Data Principals can exercise their rights
- Explaining how to file a complaint with the **Data Protection Board of India (DPBI)**
- Explaining how to withdraw consent

### 3. Consent Requirements (Section 6)

Where consent is your lawful basis, it must be:
- **Free** — not bundled with service access
- **Specific** — tied to a particular purpose
- **Informed** — given after receiving the Section 5/Rule 3 notice
- **Unconditional** — no coercion
- **Unambiguous** — clear affirmative action (opt-in checkbox; no pre-ticked boxes)

Consent may be withdrawn at any time. The withdrawal mechanism must be as easy as giving consent.

### 4. General Data Fiduciary Obligations (Section 8)

| Obligation | Detail |
|-----------|--------|
| **Processor contracts** | Appoint Data Processors only under written contracts specifying scope, purpose, security measures, and audit rights (Rule 16) |
| **Data quality** | Where data is used to make decisions affecting Data Principals, ensure it is accurate, complete, and consistent |
| **Security safeguards** | Implement appropriate technical and organisational measures per Rule 7 (encryption, access controls, MFA, audit logging) |
| **Data erasure** | Delete personal data when the specified purpose is fulfilled, consent is withdrawn, or erasure is requested |
| **Breach notification** | Report personal data breaches to the Data Protection Board **within 72 hours** (Rule 6) |

### 5. Data Principal Rights (Sections 11–14)

Your Indian customers (Data Principals) have the following rights, which you must be able to respond to:

- **Right to access information** (Section 11) — summary of data processed, identities of fiduciaries and processors
- **Right to correction, completion, updating, and erasure** (Section 12)
- **Right to grievance redressal** (Section 13) — you must provide a functional grievance mechanism; Data Principals must exhaust this before approaching the Board
- **Right to nominate** (Section 14) — to appoint someone to exercise rights in case of death or incapacity

### 6. Children's Data (Section 9)

If any of your Indian customers are under **18 years of age**, you must:
- Obtain **verifiable parental/guardian consent** before processing any data
- Implement age verification at registration (Rule 10)
- Prohibit tracking, behavioural monitoring, and targeted advertising directed at children

### 7. Cross-Border Data Transfers (Section 16)

Transfers of Indian personal data to US servers are currently **permitted**. The DPDPA uses a **blacklist approach** — transfers are allowed to all countries except those specifically restricted by Central Government notification. As of April 2026, no countries have been notified as restricted, so your US transfers are lawful. However, monitor the MeitY Official Gazette for future restrictions.

---

## Immediate Action Items

1. **Conduct a data mapping exercise** — identify all digital personal data collected from Indian customers and the purposes of processing
2. **Audit your lawful bases** — replace any "legitimate interests" reliance with consent or a valid Section 7 category
3. **Update privacy notices** — ensure standalone, Rule 3-compliant notices for Indian customers
4. **Review consent mechanisms** — remove pre-ticked boxes; implement affirmative opt-in
5. **Implement age verification** — address children's data requirements if your platform is accessible to under-18s in India
6. **Update vendor/processor contracts** — ensure Rule 16 compliance
7. **Establish a breach notification procedure** — 72-hour Board notification requirement
8. **Create a grievance mechanism** — mandatory for all Data Fiduciaries

---

## Penalties for Non-Compliance

| Violation | Maximum Penalty |
|-----------|----------------|
| Failure to implement security safeguards | **₹250 crore (~USD 30M)** |
| Failure to notify breach within 72 hours | **₹200 crore** |
| Children's data violations | **₹200 crore** |
| Other violations | **₹50 crore** |

Full penalties apply from **13 May 2027**. The enforcement body is the **Data Protection Board of India (DPBI)**, with appeals to the Telecom Disputes Settlement and Appellate Tribunal (TDSAT).

# India's DPDPA: Applicability to US Companies with Indian Customers

## Does the DPDPA Apply to Your Company?

**Yes, most likely.** India's Digital Personal Data Protection Act (DPDPA), passed in 2023, has extra-territorial scope similar to GDPR. If you are collecting and processing personal data from individuals located in India as part of offering goods or services to them, the DPDPA will generally apply to your organization, regardless of where you are headquartered.

The key trigger is whether you are:
- Collecting personal data from individuals in India, AND
- Offering products or services to those individuals

As a US company with Indian customers, you almost certainly fall within scope.

---

## Key Obligations as a Data Controller (Data Fiduciary)

Under the DPDPA, your company would be considered a **Data Fiduciary** (similar to "data controller" under GDPR). Here are your primary obligations:

### 1. Consent
The DPDPA requires obtaining **valid consent** from users before processing their personal data. Consent must be:
- Freely given
- Specific to the purpose
- Informed (users must know what data is collected and why)
- Unambiguous (clear affirmative action — no pre-ticked boxes)

Unlike GDPR, the DPDPA has a more limited set of legal bases for processing. There is no broad "legitimate interests" ground — consent is the primary basis for most commercial processing.

### 2. Notice Requirements
You must provide users with a clear **privacy notice** explaining:
- What personal data is collected
- The purpose of collection
- How data will be used and shared
- How users can exercise their rights

### 3. Data Principal Rights
Indian users (referred to as "Data Principals") have rights including:
- Right to access their data
- Right to correction of inaccurate data
- Right to erasure (deletion) of data
- Right to withdraw consent
- Right to grievance redressal

### 4. Security Measures
You must implement appropriate technical and organizational security measures to protect personal data from breaches, unauthorized access, and misuse.

### 5. Breach Notification
In case of a personal data breach, you will likely need to notify both the regulatory authority and affected users within a defined timeframe. The DPDPA requires prompt notification — generally within a short window (possibly 72 hours, similar to GDPR) to the Data Protection Board of India.

### 6. Data Localization and Cross-Border Transfers
The DPDPA has provisions around cross-border data transfers. Transfers of Indian personal data outside India may be restricted to certain approved countries, or require specific safeguards. Your legal team should review the current transfer rules and any approved country lists.

### 7. Children's Data
If any users are minors, special protections apply. Parental consent is required for processing children's data.

### 8. Vendor Contracts
If you use third-party processors (cloud providers, analytics vendors, etc.), you will need data processing agreements in place.

---

## Enforcement

The **Data Protection Board of India** is the supervisory authority responsible for enforcement. Penalties under the DPDPA can be substantial — reportedly up to several hundred crore rupees for serious violations.

---

## Recommended Next Steps

1. Conduct a data audit to identify all personal data collected from Indian users
2. Review your privacy notice and consent mechanisms for DPDPA compliance
3. Assess your cross-border transfer practices
4. Update vendor contracts to include data processing provisions
5. Establish a breach response procedure
6. Assign a point of contact for Indian data protection compliance
7. Consult with legal counsel familiar with Indian data protection law

Note: The DPDPA's implementing rules and specific requirements continue to evolve. Many operational details depend on subsidiary regulations and government notifications that are still being developed. Staying current with MeitY (Ministry of Electronics and Information Technology) guidance is essential.

# DPDPA vs. GDPR Consent Requirements: Key Differences for Compliance Teams

## Side-by-Side Comparison

| Dimension | GDPR (Art. 4(11) + Art. 7) | DPDPA (Section 6) | Implication |
|-----------|---------------------------|-------------------|-------------|
| **Consent standard** | Freely given, specific, informed, unambiguous | Free, specific, informed, **unconditional**, unambiguous | DPDPA adds "unconditional" — a stricter element |
| **Mechanism** | Clear affirmative action; no pre-ticked boxes | Clear affirmative action; no pre-ticked boxes | Same standard |
| **Bundled consent** | Problematic but not always fatal (contract performance may save it) | **Explicitly prohibited** — consent may not be bundled with service provision | Stricter under DPDPA |
| **Withdrawal** | Must be as easy to withdraw as to give; withdrawal does not affect prior lawfulness | Same: withdrawal as easy as giving; Section 6(4) | Equivalent |
| **Effect of withdrawal** | Data Fiduciary must stop processing; erasure unless another basis applies | Data Fiduciary must cease processing and erase data (unless retention required by law) | Broadly equivalent |
| **Granularity** | Separate consent per purpose (specificity requirement) | Separate consent per purpose (specificity requirement) | Equivalent |
| **Pre-ticked boxes** | Invalid | Invalid | Equivalent |
| **Silence/inaction** | Invalid | Invalid | Equivalent |
| **Parental consent (minors)** | Required under 16 (member states may lower to 13) | Required under **18** years; must be verifiable (Rule 12) | DPDPA is stricter — higher age threshold |
| **Consent records** | Must be demonstrable | Must be demonstrable | Equivalent |

---

## Critical Differences Your Compliance Team Must Know

### 1. "Unconditional" — A New Element Not in GDPR

GDPR requires consent to be "freely given, specific, informed, and unambiguous." The DPDPA (Section 6) adds a fifth element: **unconditional**. This means:

- Consent cannot be made conditional on accepting other terms or services
- Any condition attached to the act of giving consent invalidates it
- This goes further than GDPR's "freely given" standard

**Practical impact:** A GDPR "freely given" analysis might permit some conditions (e.g., access to a premium feature conditioned on consent to analytics). Under DPDPA's "unconditional" standard, such arrangements face greater legal risk.

### 2. Bundled Consent Is Explicitly Prohibited

Under GDPR, bundling consent with service access is disfavoured but may survive if the processing is genuinely necessary for the contract (lawful basis shifts to Art. 6(1)(b)). Under the DPDPA:

- Consent **cannot** be bundled with service provision
- The classic "by using this app, you agree to our privacy policy" model is **non-compliant**
- There is no equivalent contractual necessity basis to rescue bundled consent

**Practical impact:** If your current Indian consent mechanism says "by registering, you consent to X," you need to redesign this into a separate, standalone consent interaction.

### 3. Only Two Lawful Bases — No "Legitimate Interests"

This is the most operationally significant difference:

| GDPR Lawful Bases | DPDPA Equivalent |
|-------------------|-----------------|
| Consent (Art. 6(1)(a)) | Consent (Section 6) |
| Contract performance (Art. 6(1)(b)) | Partial equivalent only under Section 7(a) (voluntary data for a purpose) or Section 7(e) (employment) |
| Legal obligation (Art. 6(1)(c)) | Section 7(d) — legal obligations under Indian law |
| Vital interests (Art. 6(1)(d)) | Section 7(g) — medical emergencies/disasters |
| Public task (Art. 6(1)(e)) | Section 7(b)/(c) — State functions/subsidies |
| **Legitimate interests (Art. 6(1)(f))** | **No equivalent — does not exist** |

**What this means for consent:** Because "legitimate interests" does not exist under the DPDPA, processing activities that GDPR teams currently justify on that basis — analytics, fraud detection, marketing to existing customers, B2B data sharing — must either:
- Be mapped to one of the **8 enumerated Section 7 legitimate uses** (exhaustive), OR
- Be based on explicit **consent under Section 6**

Most commercial analytics and B2C marketing will require consent.

### 4. Notice Must Come First (Section 5)

DPDPA consent is only valid if given **after** receiving the Section 5/Rule 3 notice. The notice must:
- Be **standalone** — not embedded in terms and conditions
- Be in plain, comprehensible language
- Contain itemised list of data collected, purposes, recipients, retention period, rights, Board complaint pathway, and withdrawal mechanism

Consent obtained before providing a compliant notice is invalid. This is similar to GDPR's informed consent requirement but the DPDPA notice requirements are more specifically prescribed in Rule 3.

### 5. Withdrawal Must Be "As Easy As Giving Consent" — Technically Tested

GDPR states withdrawal must be as easy as giving consent — a standard frequently ignored in practice. DPDPA Section 6(4) codifies the same requirement, and compliance teams should expect the Data Protection Board of India (DPBI) to scrutinise this technically:

- If consent was given via a single checkbox: withdrawal must be achievable in a single action
- Multi-step withdrawal processes (e.g., emailing a support team) against one-click consent will likely be **non-compliant**
- In-app consent withdrawal toggles are the expected implementation

### 6. Consent Records

Both GDPR and DPDPA require organisations to be able to demonstrate valid consent. Under the DPDPA, this includes:
- A record of when consent was given
- The notice that was presented at the time
- The specific purpose consented to
- Records of any withdrawal and subsequent erasure actions

---

## Practical Compliance Checklist for Your Team

| Check | GDPR Status | DPDPA Status |
|-------|-------------|-------------|
| No pre-ticked boxes | Required | Required |
| Separate consent per purpose | Required | Required |
| Standalone notice before consent | Required (informed) | Required (Rule 3 standalone notice) |
| No bundled consent with service access | Discouraged (may survive if contract basis exists) | **Prohibited** |
| One-click withdrawal (if one-click consent given) | Standard | **Explicitly required (Section 6(4))** |
| Age gate at 18 for children | 16 (varies by member state) | **18 — fixed, no variation** |
| Verifiable parental consent for children | Required for under-16 | Required for under-18; verified via DigiLocker/government tokens (Rule 12) |
| Replace "legitimate interests" with consent or valid basis | N/A | **Action required** |

---

## Summary for Compliance Teams

The DPDPA consent standard is broadly similar to GDPR but with three key tightening elements:
1. The explicit **"unconditional"** requirement makes bundled consent clearly unlawful
2. The **absence of legitimate interests** means many currently non-consent-based processing activities will need redesign
3. The **18-year children's threshold** (vs. GDPR's 16) requires reconfigured age gates for India specifically

For organisations with a mature GDPR consent programme, the primary remediation work is: (a) unbundling consent from service access, (b) auditing all legitimate-interests-based processing, and (c) updating age verification for the Indian market.

# DPDPA vs. GDPR Consent Requirements: A Comparison

## Overview

Both India's DPDPA (Digital Personal Data Protection Act, 2023) and the EU's GDPR (General Data Protection Regulation) require valid consent for processing personal data, but there are several important differences your compliance team should understand.

---

## Consent Standards: Side-by-Side

| Element | GDPR | DPDPA |
|---------|------|-------|
| Freely given | Yes | Yes |
| Specific | Yes | Yes |
| Informed | Yes | Yes |
| Unambiguous | Yes | Yes |
| Clear affirmative action | Yes | Yes |
| Pre-ticked boxes | Not permitted | Not permitted |
| Withdrawal mechanism | Must be easy | Must be easy |

At a high level, both frameworks have broadly similar consent validity requirements. The devil is in the details and the surrounding legal architecture.

---

## Key Differences

### 1. Legal Bases for Processing

**GDPR** offers six lawful bases for processing:
1. Consent
2. Contract performance
3. Legal obligation
4. Vital interests
5. Public task
6. Legitimate interests

**DPDPA** is more restrictive. It primarily relies on consent as the main lawful basis for commercial processing. The DPDPA has "deemed consent" or legitimate use provisions, but these are narrower than GDPR's "legitimate interests" — they cover specific scenarios like government functions, employment, and emergency situations. Commercial organisations will generally need to rely on consent for most data processing.

**Implication:** Your team cannot use the broad "legitimate interests" basis under DPDPA the way you might under GDPR. More activities will require explicit consent.

### 2. Consent Withdrawal

Both frameworks require that withdrawal be "as easy as" giving consent. However, the DPDPA places somewhat more emphasis on this requirement, and the practical implementation (particularly for digital platforms) is expected to be closely scrutinised.

### 3. Consent for Children (Minors)

**GDPR:** Requires parental consent for children under **16** (though member states can lower this to **13**).

**DPDPA:** Requires parental/guardian consent for anyone under what is expected to be a higher age threshold — likely **18 years** under DPDPA provisions (India's standard age of majority). The exact threshold and verification requirements are still being implemented through regulations.

**Implication:** Your age-gating for India may need to be stricter than for the EU.

### 4. Notice Requirements

**GDPR:** Requires a privacy notice with specific elements (Art. 13/14), which can be embedded in a broader privacy policy.

**DPDPA:** Also requires a notice before or at collection, but the DPDPA emphasises that notice should be clear and accessible. The implementing rules are prescribing specific notice formats and elements. There is a stronger push for notices to be standalone and not buried in lengthy terms and conditions.

### 5. Bundled Consent

**GDPR:** While bundled consent (tying consent to service access) is disfavoured and in many cases invalid, it can sometimes be salvaged by relying on the "contract performance" basis for processing that is genuinely necessary.

**DPDPA:** Takes a similar approach but the limited legal bases mean there's less flexibility to rely on contract performance as an alternative. Bundled consent is likely to be treated as invalid more consistently.

### 6. Consent Records

Both frameworks require demonstrability of consent — you must be able to show that valid consent was obtained. This requires maintaining consent logs with timestamps, the version of the notice shown, and the specific purposes consented to.

---

## What Your Compliance Team Needs to Do

1. **Audit existing consent mechanisms** for India — check if they meet DPDPA's standards
2. **Review age verification** — you may need stricter age gates for Indian users than for EU users
3. **Evaluate reliance on legitimate interests** — many activities justified under GDPR legitimate interests may require consent under DPDPA
4. **Simplify privacy notices** — DPDPA expects notices to be accessible and plain-language
5. **Implement consent withdrawal** — ensure it's as easy as giving consent for Indian users
6. **Maintain consent records** — document consent in a way that can be demonstrated to regulators

---

## Bottom Line

The DPDPA consent requirements are broadly aligned with GDPR principles but with fewer flexible legal bases and a potentially stricter treatment of bundled consent. For compliance teams already operating a GDPR program, the primary adaptation is narrowing your reliance on non-consent legal bases and reviewing your age verification practices for India.

Note: The DPDPA's implementing rules and specific consent requirements continue to develop. Legal advice from Indian data protection counsel is recommended for detailed implementation questions.

# DPDPA Requirements for Processing Children's Data

## Definition of "Child" Under DPDPA

Under **Section 2(f)** of the DPDPA, a **"child"** means any individual who has not completed **18 years of age**. This is a uniform threshold — there is no regional or platform-level variation permitted. Any user under 18 is legally a child, triggering the full protections of **Section 9**.

---

## Section 9 Obligations: What Your Platform Must Do

### 1. Verifiable Parental/Guardian Consent (Section 9(1))

Before processing **any** personal data of a child, you must obtain **verifiable parental or lawful guardian consent**. This is a hard prerequisite — there is no processing of a child's data without it.

"Verifiable" means you cannot accept a parent's self-declaration at face value without a verification mechanism. **Rule 12** of the DPDP Rules 2025 prescribes the permitted verification methods:

| Method | Description |
|--------|-------------|
| **Existing user data** | If your platform already holds verified identity/age data for the parent, that data can support verification |
| **Voluntary self-declaration** | Parent/guardian self-declares identity and relationship (lowest assurance level) |
| **Token-based verification** | Via government or government-mandated entities, **DigiLocker** (India's official digital document wallet), or other notified token-issuing bodies |

DigiLocker integration is likely to become the standard approach for high-assurance parental consent verification in India.

### 2. Age Verification at Registration (Rule 10)

You must implement **age verification mechanisms** at the point of user registration/onboarding. This means:

- A functional age gate that prevents under-18 users from registering without triggering the parental consent flow
- The mechanism must be robust — self-declaration of age alone without any verification is insufficient for a platform that has reason to believe it serves minors

### 3. Absolute Prohibitions — Section 9(2)

These prohibitions apply to **all Data Fiduciaries** processing children's data, regardless of size or type. They cannot be overridden by parental consent:

| Prohibited Activity | Description |
|--------------------|-------------|
| **Tracking or behavioural monitoring** | GPS tracking, activity profiling, clickstream analysis, session recording specifically of children |
| **Targeted advertising** | Personalised ads, recommendation algorithms based on child profile, marketing communications directed at children |
| **Detrimental processing** | Any processing likely to cause detrimental effect on a child's well-being — physical, mental, emotional, or developmental harm |

**These are absolute bans.** They apply even if a parent has consented. A parent cannot consent on behalf of their child to behavioural tracking or targeted advertising — the Act prohibits these outright.

---

## Exemptions from Section 9

Processing without parental consent is only permitted in the following narrow circumstances:

1. **Health and safety emergencies** — medical treatment, child safety services
2. **Essential prescribed services** — age-appropriate educational platforms, child safety apps (as specifically prescribed by the Central Government)
3. **Law enforcement** — crime prevention or investigation involving the child

These exemptions do not unlock the prohibited activities in Section 9(2). They only permit processing without parental consent where urgency justifies it.

---

## Penalties for Children's Data Violations

Violations of Section 9 carry a maximum penalty of **₹200 crore** — one of the highest penalty tiers under the DPDPA. The **Data Protection Board of India (DPBI)** is the enforcement body.

---

## Practical Gap Analysis for Your Platform

| Obligation | What You Need | Common Gap |
|-----------|--------------|-----------|
| Age gate at registration | Mechanism that identifies under-18 users and triggers parental consent flow | No age verification; open registration to all |
| Verifiable parental consent | DigiLocker/token-based or data-backed verification | Accepting checkbox "I am over 18" or simple self-declaration |
| No behavioural tracking of children | Technical controls to suppress tracking for child accounts | Analytics/session tracking running uniformly on all accounts |
| No targeted advertising to children | Ad platform configuration excludes child accounts from targeting | Standard ad targeting applied to all users |
| No detrimental processing | Review all automated processing for potential well-being impact on children | No child-specific data processing impact review |
| Processor contracts | Contracts with ad networks, analytics vendors prohibit secondary use of children's data | Generic vendor contracts not updated |

---

## DPDPA vs. GDPR: Children's Data Comparison

| Dimension | GDPR | DPDPA Section 9 |
|-----------|------|----------------|
| **Age threshold** | **16 years** (member states may lower to 13) | **18 years** — uniform, no variation |
| **Parental consent requirement** | Required for under-16 (or under-13 in some member states) | Required for **all under-18** |
| **Verification mechanism** | Not specifically prescribed — reasonable measures | **Prescribed in Rule 12**: DigiLocker, government tokens, existing data |
| **Behavioural monitoring of children** | Permitted with appropriate legal basis | **Prohibited outright** — Section 9(2) |
| **Targeted advertising to children** | Permitted with appropriate consent/legal basis | **Prohibited outright** — Section 9(2) |
| **Detrimental processing prohibition** | General harm avoidance principles; DPIA required for high-risk processing | **Explicit prohibition** — Section 9(2)(c) |
| **Penalty for violation** | Up to €20M or 4% of global turnover | Up to **₹200 crore** |

### What This Means for Your Platform

1. **16/17-year-olds require full protection in India.** If your GDPR compliance handles 16–17 year olds as adults (permitted in most EU member states), you must apply full child protections for this age band in India.

2. **Behavioural monitoring must be switched off for all under-18 accounts.** If your analytics, recommendations, or ad systems process user behaviour, you need child-account detection and suppression — even where a parent has consented.

3. **Targeted advertising to any under-18 user in India is prohibited.** This is not a consent issue — it is an outright ban. No parental consent can unlock targeted advertising to a child.

4. **Verification is more prescriptive.** GDPR leaves verification methods to reasonable judgment. DPDPA Rule 12 prescribes specific mechanisms, with DigiLocker as the likely primary method.

---

## Recommended Action Plan

1. **Implement a robust age gate** — require date of birth at registration; route under-18 users to a parental consent flow before completing registration
2. **Integrate DigiLocker or token-based verification** for parental consent to meet Rule 12 requirements
3. **Audit your analytics and tracking systems** — create child-account flags that suppress behavioural tracking, profiling, and targeted advertising
4. **Review your ad network contracts** — ensure child accounts are excluded from targeting audiences and that this exclusion is contractually required of your ad partners
5. **Conduct a processing impact review** for all automated processing of children's data to identify any potentially detrimental effects
6. **Update Data Processor agreements** to prohibit secondary use of children's personal data

Full compliance is required by **13 May 2027**, but given the complexity of implementing age verification and ad suppression systems, your engineering teams should begin scoping this work immediately.

# Children's Data Under DPDPA: Requirements and GDPR Comparison

## DPDPA Requirements for Processing Children's Data

India's Digital Personal Data Protection Act (DPDPA) includes specific provisions for protecting children's personal data. Here is what you need to know:

### Age Threshold

The DPDPA defines a child as a person below a certain age — generally understood to be **18 years** under Indian law, though the DPDPA and its implementing rules provide specific guidance on this. This is important because India uses 18 as the standard age of majority, which is higher than GDPR's default of 16 (which can be lowered to 13 in member states).

### Parental/Guardian Consent

Before processing personal data of a child, you must obtain **consent from the child's parent or legal guardian**. This consent must meet the same validity standards as regular consent under the DPDPA (freely given, specific, informed, unambiguous).

The consent must be **verifiable** — you cannot simply assume a user is an adult. Platforms need mechanisms to:
- Determine whether a user is a child
- Obtain and verify parental consent before processing the child's data

### Prohibited Activities

The DPDPA includes specific prohibitions on processing children's data in certain ways. Key restrictions include:
- **Behavioural tracking and monitoring** of children is prohibited or heavily restricted
- **Targeted advertising** directed at children is restricted
- Processing that could be harmful to children's well-being is prohibited

These restrictions reflect a growing global consensus that children deserve enhanced protection from commercial data practices.

### Age Verification

Your platform will need to implement age verification mechanisms to identify users who are minors and apply appropriate protections. This is operationally complex — especially for a platform with users of all ages.

---

## Comparison with GDPR

| Aspect | GDPR | DPDPA |
|--------|------|-------|
| Age threshold | **16** (default); member states can lower to **13** | **18** (fixed, reflecting Indian age of majority) |
| Parental consent | Required for under-16 (or lower if member state has reduced) | Required for children (under 18) |
| Verification | "Reasonable efforts" to verify parental consent | Verification required; specific methods likely to be prescribed in rules |
| Behavioural tracking | Permitted with appropriate legal basis | Restricted/prohibited for children |
| Targeted advertising | Allowed with legal basis; GDPR doesn't explicitly prohibit for children beyond requiring valid consent | More explicitly restricted |
| Penalties for violations | Up to €20M or 4% of global annual turnover | Significant fines (several hundred crore rupees possible) |

### Key Differences to Note

1. **Stricter age threshold:** The DPDPA's 18-year threshold means you must treat 16 and 17-year-olds as children requiring parental consent — even if you've been treating them as adults under GDPR in some EU member states.

2. **Broader prohibitions:** DPDPA appears to take a stricter approach to behavioural tracking and targeted advertising for children than GDPR, which allows these with appropriate legal basis. Under DPDPA, these may be prohibited outright regardless of consent.

3. **Verification requirements:** Both frameworks require verification of parental consent, but the implementing rules for DPDPA may prescribe specific verification methods that differ from GDPR's more flexible "reasonable efforts" standard.

4. **No special categories equivalent:** GDPR has enhanced protections for special categories of data (health, biometrics, etc.) processed about children. DPDPA's approach is more focused on the age-related protections and parental consent rather than data category-based enhancements.

---

## Practical Recommendations for Your Platform

1. **Implement age verification at registration** — all new users should be prompted to provide their date of birth or indicate their age group

2. **Build a parental consent flow** — for users who indicate they are under 18, require parental/guardian consent before allowing full platform access

3. **Audit your data processing for under-18 users** — identify all analytics, tracking, profiling, and advertising activities that touch minor users

4. **Disable behavioural tracking and targeted advertising** for identified minor users — this is likely required under DPDPA regardless of parental consent

5. **Review your terms of service** — if your platform has an age minimum, enforce it technically (not just through a checkbox)

6. **Update vendor contracts** — ensure advertising networks and analytics providers do not process children's data for profiling or targeting purposes

7. **Document your parental consent records** — maintain records of how parental consent was obtained and verified

---

## Important Caveat

The DPDPA's implementing rules continue to be developed and refined. Some specific requirements for children's data — including exact verification methods and any exemptions — may be subject to further regulatory guidance. Your legal team should monitor developments from MeitY and consult with Indian privacy counsel for the most current requirements.

# DPDPA Cross-Border Data Transfer Requirements

## The Core Mechanism: Blacklist Approach (Section 16)

The DPDPA takes a fundamentally different approach to cross-border data transfers than GDPR. Under **Section 16**, the default position is **permissive**:

> A Data Fiduciary may transfer personal data of a Data Principal to **any country or territory outside India**, except those **specifically notified by the Central Government as restricted**.

This is a **blacklist approach** — transfers are permitted everywhere unless a specific country appears on a restricted list published by the Central Government. This is the opposite of GDPR, which uses a whitelist/adequacy approach requiring a positive transfer mechanism for every cross-border transfer.

---

## Current Status: Are Transfers to the US Permitted?

**Yes — transfers to your US servers are currently permissible.**

As of April 2026, the Central Government has **not notified any countries as restricted** under Section 16. This means:

- Transfers to the United States are currently lawful under the DPDPA
- No transfer mechanism equivalent to GDPR Standard Contractual Clauses (SCCs) is required
- No adequacy assessment or approval is needed for the transfer itself

**However, this position can change.** The Central Government retains the power to restrict transfers to specific countries or territories at any time by notification in the Official Gazette. Your legal team should monitor the **MeitY Official Gazette** for any future notifications.

---

## Comparison with GDPR: Blacklist vs. Whitelist

| Dimension | GDPR | DPDPA Section 16 |
|-----------|------|-----------------|
| **Default position** | **Restrictive** — transfers require a positive mechanism | **Permissive** — transfers allowed unless country is restricted |
| **Transfer mechanism required** | Adequacy decision, SCCs, BCRs, binding corporate rules, derogations (Art. 46–49) | **None currently required** |
| **Restricted countries** | Countries without adequacy decision (unless SCCs/BCRs used) | Countries specifically notified by Central Government (none as of April 2026) |
| **Documentation requirement** | Detailed SCC/BCR documentation, transfer impact assessments | Contractual safeguards recommended but not mandated |
| **Legal certainty** | High — established mechanisms | Currently high (no restrictions), but potentially uncertain as notifications may come |
| **US transfers** | Require SCCs (EU-US Data Privacy Framework for qualified entities, or SCCs) | Currently **permitted without any mechanism** |

---

## What You Should Do Now (Even Though Transfers Are Currently Permitted)

The absence of restrictions today does not mean you should operate without any safeguards. Best practice guidance and potential future compliance requirements suggest:

### 1. Maintain Data Flow Maps
Document all transfers of Indian personal data to US servers:
- Categories of data transferred
- Volume and frequency
- Purpose of transfer
- Recipients (internal systems, third-party processors)
- Retention periods offshore

This inventory positions you to respond quickly if the Central Government restricts US transfers.

### 2. Implement Basic Contractual Protections
While DPDPA does not currently require SCCs or equivalent mechanisms, include reasonable data protection obligations in contracts with US-side recipients and processors:
- Security requirements aligned with Rule 7 (encryption, access controls, MFA)
- Restrictions on secondary use
- Breach notification obligations
- Deletion/return of data on termination

These are required anyway under **Section 8(1) and Rule 16** (Data Processing Agreements with processors), so your processor contracts should already incorporate these terms.

### 3. Comply with Significant Data Fiduciary (SDF) Data Localisation Requirements
If your company is designated as a **Significant Data Fiduciary (SDF)** under Section 10, the Central Government may require certain categories of personal data to remain within India. This is separate from the Section 16 transfer restrictions. SDF localisation obligations depend on future notifications — monitor these closely if you process large volumes of Indian personal data.

### 4. Monitor MeitY Notifications
Set up a process to monitor the Official Gazette and MeitY announcements. If the US is added to the restricted list, you would need to:
- Cease transfers until a compliant mechanism is established (or the restriction is lifted)
- Potentially implement data localisation for Indian user data
- Restructure your infrastructure to store Indian data within India

---

## Practical Risk Assessment

| Risk Factor | Current Status | Future Risk |
|-------------|---------------|------------|
| US transfers permitted? | **Yes** | May change if US added to restricted list |
| Transfer mechanism required? | No | May be required in future |
| SCC equivalent needed? | No | No DPDPA equivalent exists yet |
| Data localisation for SDFs? | Possible if designated SDF | High risk if SDF designation received |
| Penalty for non-compliant transfer | ₹50 crore (general violations) | Up to ₹250 crore if security safeguards also deficient |

---

## Key Takeaway

Your current transfers of Indian user data to US servers are **lawful under the DPDPA** as of today. The DPDPA's blacklist approach is significantly less restrictive than GDPR's whitelist model — you do not need SCCs, adequacy decisions, or transfer impact assessments at this time.

However, treat this as a window of opportunity to:
1. Document your data flows
2. Implement contractual protections with US processors
3. Build monitoring processes to detect future transfer restrictions
4. Assess whether SDF designation is likely (which brings additional localisation obligations)

Full compliance (including any transfer restrictions that may be notified) is required from **13 May 2027**.

# DPDPA Cross-Border Data Transfer Requirements

## Overview

India's Digital Personal Data Protection Act (DPDPA) includes provisions governing the transfer of personal data outside India. Understanding these requirements is essential for any organization that processes Indian user data on foreign servers.

---

## DPDPA Transfer Framework

The DPDPA takes a somewhat different approach to cross-border transfers compared to GDPR. Rather than a positive "whitelist" approach requiring adequacy decisions or specific mechanisms, the DPDPA uses a framework where the Central Government can restrict transfers to specific countries.

### Key Provisions

- The default position under DPDPA allows transfers of personal data outside India, subject to any restrictions the Central Government may impose
- The Central Government has the power to **restrict or prohibit transfers** to specific countries or territories
- Transfers to countries that have not been restricted are generally permissible
- The implementing rules and government notifications will specify which countries (if any) face restrictions

### Current State of the Law

The DPDPA's transfer provisions are still being fully implemented through subsidiary regulations and government notifications. As of the time of this writing:
- The framework for identifying restricted countries is being established
- Many specific operational requirements remain to be notified by the government
- Organisations should monitor developments from MeitY (Ministry of Electronics and Information Technology)

---

## Are Transfers to US Servers Permissible?

The answer depends on current government notifications, which continue to evolve. Under the current framework:

- If the United States has **not been designated as a restricted country**, transfers to US servers should generally be permissible
- However, you should verify the current list of restricted countries with MeitY or through legal counsel
- Future restrictions could affect your ability to transfer data to the US

**Recommendation:** Assume transfers may face future restrictions and proactively implement safeguards.

---

## Comparison with GDPR

| Aspect | GDPR | DPDPA |
|--------|------|-------|
| Default position | Restrictive — transfers require a positive mechanism (adequacy, SCCs, BCRs, etc.) | More permissive — transfers generally allowed unless restricted |
| Transfer mechanism | Adequacy decisions, Standard Contractual Clauses (SCCs), Binding Corporate Rules, etc. | No equivalent prescribed mechanism yet; government can restrict specific countries |
| Current US transfers | Require SCCs or EU-US Data Privacy Framework | Currently likely permissible (no known restriction on US) |
| Documentation | Detailed transfer records, SCCs required | Less prescriptive currently |
| Uncertainty | Lower (well-established framework) | Higher (implementing rules still developing) |

### Key Differences

**DPDPA is less complex than GDPR for transfers today.** Under GDPR, every cross-border transfer requires a positive transfer mechanism — adequacy decision, SCCs, or other Article 46 safeguards. Under DPDPA, the burden shifts: you can transfer unless specifically restricted.

**However, DPDPA future restrictions could be significant.** India may restrict transfers to countries it considers to have inadequate data protection, potentially including countries like the US. This is an evolving area.

---

## Data Localization Concerns

Beyond general transfer restrictions, some categories of data processed by organizations designated as "Significant Data Fiduciaries" may face **data localization requirements** — meaning certain data must be stored and processed within India. This is a separate concern from general transfer restrictions and depends on:

- Whether your organization is designated as a Significant Data Fiduciary
- Which categories of data are subject to localization requirements (to be specified in notifications)

---

## Recommended Steps

1. **Monitor MeitY notifications** — keep track of any countries added to the restricted list

2. **Document your data flows** — map exactly what Indian personal data is transferred to your US servers, for what purposes, and under what security conditions

3. **Implement contractual safeguards** — even if not currently required, having data processing agreements with your US-side infrastructure and vendors is good practice and may become required

4. **Assess data localization** — determine whether you may be designated as a Significant Data Fiduciary; if so, budget for potential data localization infrastructure in India

5. **Build flexibility into your architecture** — design your systems so that Indian user data could be kept in India if required

6. **Consult legal counsel** — given the evolving nature of DPDPA transfer rules, work with Indian data protection lawyers to stay current

---

## Bottom Line

Currently, transferring Indian user data to your US servers is likely permissible under DPDPA, but this may change. Unlike GDPR (which requires SCCs or equivalents), the DPDPA's transfer framework is currently more permissive, but organisations should not be complacent — restrictions could be imposed at any time, and data localization requirements for certain organizations could require significant infrastructure changes.

# Significant Data Fiduciary (SDF) Under the DPDPA

## What Is a Significant Data Fiduciary?

A **Significant Data Fiduciary (SDF)** is a Data Fiduciary designated by the Central Government of India under **Section 10** of the DPDPA. The designation is based on an assessment of the potential risks and scale of data processing by the organisation.

The equivalent in GDPR would be a "high-risk controller" subject to heightened obligations — but unlike GDPR, which uses risk-based thresholds for DPO appointments and DPIAs, DPDPA's SDF designation is an explicit government notification, not a self-assessed threshold.

---

## Designation Criteria (Section 10)

The Central Government designates an organisation as an SDF based on any combination of the following factors:

| Criterion | Description |
|-----------|-------------|
| **Volume of personal data** | Large-scale processing of personal data of Indian Data Principals |
| **Sensitivity of personal data** | Processing of sensitive or high-risk categories of data |
| **Risk to Data Principals** | Potential risk of harm to rights and freedoms of Data Principals |
| **National security/sovereignty impact** | Potential impact on India's sovereignty, integrity, security, or electoral democracy |
| **Risk to public order** | Processing that could threaten public order |

---

## Current Designation Status

> **As of April 2026, no organisations have been publicly designated as SDFs.** The Central Government has not yet published the list of designated SDFs. This is flagged because several obligations depend on this notification, and until it is issued, SDF-specific obligations are not yet triggered for any specific company.

Organisations most likely to be designated as SDFs in the first wave include:
- Large social media platforms with significant Indian user bases
- Major e-commerce companies
- Fintech and digital payment platforms
- Large technology companies processing high volumes of Indian personal data
- Search engines and content aggregators

If your organisation processes personal data at significant scale in India, you should **self-assess and prepare** for potential SDF designation — even before the official notification.

---

## Additional Obligations for SDFs (Section 10 + Rule 13)

SDF designation triggers four additional obligations beyond the standard Data Fiduciary requirements:

### 1. Data Protection Officer (DPO) — India-Resident

| Requirement | Detail |
|------------|--------|
| Mandatory appointment | Yes — cannot outsource or use a foreign DPO |
| Residency | Must be **resident in India** (a critical difference from GDPR, which has no location requirement) |
| Role | Sole representative of the SDF before the **Data Protection Board of India (DPBI)** |
| Function | Primary contact for Data Principal grievances |
| Accountability | Senior individual; must have authority within the organisation |

**Note for GDPR-compliant organisations:** If your current DPO is based outside India, they cannot fulfil the DPDPA DPO role for India. A separate India-resident appointment is required.

### 2. Data Protection Impact Assessment (DPIA) — Annual

| Requirement | Detail |
|------------|--------|
| Frequency | **Annual** — not event-triggered |
| Scope | Must evaluate: (a) compliance with the Act and Rules; (b) Data Principals' ability to exercise their rights; (c) adequacy of technical and organisational safeguards; (d) risks from large-scale processing |
| Conducted by | Internal privacy/compliance team (Rule 13 does not require independent conduct for the DPIA, unlike the audit) |
| Output | Formal DPIA report |

This is significantly different from GDPR, where a DPIA is a one-time event-triggered assessment (required when processing is "likely to result in high risk"). DPDPA SDFs must conduct one every year.

### 3. Independent Data Audit — Annual

| Requirement | Detail |
|------------|--------|
| Frequency | **Annual** |
| Auditor | Must be **independent** — cannot be an employee or internal team |
| Qualification | Must be a qualified independent auditor (exact qualification criteria to be specified by Central Government) |
| Report submitted to | Data Protection Board of India (DPBI) |
| Content | Significant observations, material risks identified, and remediation recommendations |

This is an important governance mechanism. The auditor's report goes directly to the Board — not just to the SDF's management — creating external accountability.

### 4. Data Localisation (If Notified)

- The Central Government may require SDFs to store **specified categories of personal data within India** — i.e., prohibit their cross-border transfer
- This is the data localisation obligation, and it applies only to categories of data specifically notified
- **Current status (April 2026):** No data localisation categories have been notified for SDFs
- This could require significant infrastructure investment (India-based data centres) for organisations currently operating entirely from offshore

---

## How Would Your Company Know If It Is Designated as an SDF?

Designation occurs by **Central Government notification**, published in the **Official Gazette of India**. There is no self-assessment threshold that automatically applies.

### The Process:
1. The Ministry of Electronics and Information Technology (MeitY) evaluates organisations based on the Section 10 criteria
2. The Central Government issues a notification designating specific organisations as SDFs
3. The notification is published in the Official Gazette
4. Designated organisations are formally notified

### What You Should Do Now (Before Designation):

Since no SDFs have been designated yet, organisations in high-risk categories should take these proactive steps:

| Action | Why |
|--------|-----|
| **Monitor the Official Gazette and MeitY announcements** | You will be notified via official publication |
| **Self-assess against Section 10 criteria** | If you process large volumes of Indian data, sensitively-categorised data, or operate platforms with significant societal/electoral reach, you are at elevated risk of designation |
| **Identify a prospective India-resident DPO candidate** | Appointing and onboarding an India-resident DPO takes time; identify the candidate before designation |
| **Develop DPIA methodology** | A DPDPA-specific DPIA framework differs from GDPR DPIAs; develop your template and process now |
| **Identify qualified independent auditors** | Building relationships with qualified data audit firms in India takes time |
| **Map your data flows for potential localisation** | Understand what data could be subject to localisation requirements and what infrastructure changes that would require |

---

## SDF Obligations vs. Standard Data Fiduciary Obligations

| Obligation | All Data Fiduciaries | SDFs Only |
|-----------|---------------------|-----------|
| Section 5 Notice | Yes | Yes |
| Section 6 Consent | Yes | Yes |
| Section 7 Legitimate Uses | Yes | Yes |
| Section 8 General Obligations (security, processors, breach notification in 72h) | Yes | Yes |
| Section 9 Children's Data | Yes | Yes |
| India-resident DPO | No | **Yes (Rule 13)** |
| Annual DPIA | No | **Yes (Rule 13)** |
| Annual Independent Audit (reported to Board) | No | **Yes (Rule 13)** |
| Data Localisation (if notified categories) | No | **Yes (Section 10)** |

---

## Penalties for SDF Non-Compliance

Non-compliance with Section 10 (SDF additional obligations) carries a maximum penalty of **₹150 crore**, imposed by the Data Protection Board of India. This is separate from penalties for standard Data Fiduciary violations, which can reach ₹250 crore for security failures.

# Significant Data Fiduciary (SDF) Under the DPDPA

## What Is a Significant Data Fiduciary?

Under India's Digital Personal Data Protection Act (DPDPA), a **Significant Data Fiduciary (SDF)** is an organisation designated by the Central Government as handling data in a way that warrants heightened oversight and additional compliance obligations. This concept is somewhat analogous to GDPR's higher-risk controllers that require Data Protection Officers (DPOs) and Data Protection Impact Assessments (DPIAs).

---

## How Are SDFs Designated?

The Central Government (through MeitY — Ministry of Electronics and Information Technology) has the power to designate organisations as Significant Data Fiduciaries based on factors such as:

- **Volume of personal data processed** — organisations handling very large amounts of Indian personal data
- **Sensitivity of data** — processing of particularly sensitive categories
- **Potential impact on national security, sovereignty, or public order**
- **Risk of harm to data subjects** — potential for large-scale harm if data is misused or breached
- **Technological complexity** — the nature of data processing operations

The designation is made by government notification and is not a self-assessment. Organisations will be formally notified if they are designated as SDFs.

### Who Is Likely to Be Designated?

While specific designations depend on government decisions, organisations likely to be considered SDFs include:
- Major social media platforms with large Indian user bases
- Large e-commerce and digital marketplace platforms
- Significant fintech and digital payment companies
- Major search engines
- Large cloud service providers
- Companies processing sensitive health, financial, or biometric data at scale

---

## Additional Obligations for SDFs

Once designated as an SDF, an organisation must comply with additional requirements beyond the standard Data Fiduciary obligations:

### 1. Data Protection Officer (DPO)

SDFs must appoint a **Data Protection Officer**. Key requirements:
- The DPO must be **based in India** (a key difference from GDPR, which has no location requirement)
- The DPO serves as the primary point of contact with the Data Protection Board of India
- The DPO handles Data Principal (user) grievances at the senior level
- The DPO must have appropriate authority and expertise

This differs from GDPR where DPOs are required for public authorities, large-scale monitoring, or special category data processing (not just for designated high-risk entities).

### 2. Data Protection Impact Assessment (DPIA)

SDFs must conduct **periodic Data Protection Impact Assessments**. These assessments:
- Evaluate risks from data processing activities
- Assess adequacy of security measures
- Consider impacts on individual rights
- Are conducted regularly (likely annually under implementing rules)

Under GDPR, DPIAs are required on a case-by-case basis when processing is likely to result in high risk. The DPDPA's DPIA obligation for SDFs is more structured and recurring.

### 3. Periodic Independent Audit

SDFs are required to undergo **independent audits** of their data processing practices. This audit:
- Must be conducted by a qualified independent auditor (not internal staff)
- Assesses compliance with the DPDPA and implementing rules
- May be submitted to the Data Protection Board

This is broader than GDPR's audit requirements, which rely more heavily on controller accountability rather than mandatory independent audits.

### 4. Data Localisation

SDFs may face **data localisation requirements**, potentially requiring certain categories of data to be stored and processed within India. This is a significant distinction:
- Specific data categories subject to localisation will be specified by the government
- This could require SDFs to invest in India-based infrastructure
- The exact scope depends on implementing regulations

---

## How Would Your Company Know If It Is an SDF?

1. **Government notification** — Designation is made through official notification by the Central Government; you would be formally notified

2. **Public announcement** — Designations are expected to be publicly announced, so industry monitoring of MeitY and government publications would provide advance warning

3. **Self-assessment** — If you process large volumes of Indian personal data (particularly sensitive data), operate a major platform used widely in India, or process data that could impact national security/public order, you should assume you may be designated and prepare accordingly

4. **Regulatory engagement** — Engage proactively with MeitY and legal counsel familiar with DPDPA implementation

---

## Comparison with GDPR Heightened Obligations

| Aspect | GDPR Enhanced Controllers | DPDPA Significant Data Fiduciary |
|--------|--------------------------|----------------------------------|
| Designation | Self-assessed based on criteria (Art. 37) | Government designation/notification |
| DPO location | No specific location required | Must be **India-resident** |
| DPIA | Event-triggered (high-risk processing) | Periodic/annual |
| Independent audit | Not mandatory under GDPR | **Mandatory for SDFs** |
| Data localization | Not required under GDPR | Possible for certain data categories |

---

## Recommended Actions

If your company might qualify as an SDF:

1. **Monitor MeitY announcements** for SDF designation decisions
2. **Identify a senior India-resident privacy professional** who could serve as DPO
3. **Develop a DPIA methodology** tailored to your processing activities
4. **Build relationships with qualified independent auditors** in India
5. **Assess your infrastructure** for potential data localization requirements
6. **Budget for enhanced compliance costs** — SDF obligations are significantly more resource-intensive

The DPDPA is still being fully implemented, and many SDF-specific requirements will be further specified in implementing rules and government notifications. Early preparation is advisable.

# CMMC Level 2 — A Plain-English Guide for Your Aerospace Firm

## What Just Happened?

Your contract includes **DFARS 252.204-7021**, which is the DoD clause that formally requires CMMC certification. Since you are an aerospace engineering firm working on a DoD contract, you almost certainly handle **Controlled Unclassified Information (CUI)** — technical drawings, engineering specs, design data, and similar material that the government considers sensitive but not classified. Because your contract specifies CMMC Level 2, you must demonstrate that you adequately protect that CUI before you can fully perform on the contract (and before you can win future DoD contracts).

---

## What Is CMMC 2.0?

CMMC stands for **Cybersecurity Maturity Model Certification**. The DoD created it to ensure that defense contractors — even small firms like yours — protect sensitive government information from theft or compromise. It became legally effective in December 2024 under 32 CFR Part 170.

There are three levels:

| Level | Who It's For | How Many Requirements |
|-------|-------------|----------------------|
| Level 1 — Foundational | Any DoD contractor with basic Federal Contract Information (FCI) | 17 practices |
| **Level 2 — Advanced** | **Contractors handling CUI (this is you)** | **110 practices** |
| Level 3 — Expert | Contractors on the most sensitive national security programs | 110+ practices |

You need **Level 2**, which means meeting all **110 cybersecurity practices** drawn from the federal standard **NIST SP 800-171 Rev 2**.

---

## What Does "110 Practices" Actually Mean?

Think of the 110 practices as a comprehensive checklist covering every major area of IT security. They are organized into 17 domains (categories). Here is a plain-English summary of each area and what it means for a 45-person engineering firm:

| Domain | Plain-English Summary | Example Requirement |
|--------|----------------------|---------------------|
| **Access Control (AC)** | Only the right people get into systems and CUI files. | Employees only access the data they need for their job. |
| **Awareness & Training (AT)** | Everyone who touches CUI gets security training. | Annual cybersecurity awareness training for all staff. |
| **Audit & Accountability (AU)** | Log who does what, and keep those logs. | All logins, file access, and admin actions are recorded and retained. |
| **Configuration Management (CM)** | Know exactly what software and hardware you have, and lock it down. | Maintain an inventory of all computers and what software is on them. |
| **Identification & Authentication (IA)** | Verify who people are before letting them in — including with MFA. | Every employee uses multi-factor authentication (MFA) to access CUI systems. |
| **Incident Response (IR)** | Have a plan for when something goes wrong. | A written incident response plan, tested at least annually. |
| **Maintenance (MA)** | Control who works on your systems and how. | Vendors doing remote maintenance must use MFA and supervised sessions. |
| **Media Protection (MP)** | Protect and track physical and digital media containing CUI. | Laptops with CUI must be encrypted; USB drives must be controlled. |
| **Physical Protection (PE)** | Control who can walk into your facility. | Badge access to server rooms; visitor escort policies. |
| **Personnel Security (PS)** | Screen employees before giving them CUI access; manage departures. | Background checks before granting CUI access; account termination checklists. |
| **Risk Assessment (RA)** | Regularly look for vulnerabilities and fix them. | Monthly vulnerability scans of all CUI-connected systems. |
| **Security Assessment (CA)** | Regularly test your own security controls. | Annual internal security review; a written System Security Plan (SSP). |
| **System & Communications Protection (SC)** | Encrypt data in transit and at rest; protect your network boundaries. | Use only FIPS 140-2/3 validated encryption (not just any "AES-256" product). |
| **System & Information Integrity (SI)** | Keep systems patched and monitored for attacks. | Antivirus on all endpoints; SIEM or equivalent monitoring for intrusions. |

---

## What Is CUI, and Why Does It Matter?

**Controlled Unclassified Information (CUI)** is government-sensitive data that is not classified but still requires protection by law or regulation. For an aerospace engineering firm, CUI typically includes:

- **Controlled Technical Information (CTI)**: Technical drawings, CAD files, specifications, test data, and software related to defense systems
- **Export-Controlled Data (ITAR/EAR)**: Design data or software that is controlled under International Traffic in Arms Regulations
- **Procurement/Acquisition data**: Pre-award contract information

Your first task is to identify exactly which data in your environment is CUI — this is called **CUI scoping**. This determines which of your systems, laptops, servers, and cloud services fall inside the CMMC assessment boundary.

**Important**: Only systems that store, process, or transmit CUI are in scope. If you can isolate CUI to a small number of systems, your assessment burden shrinks considerably.

---

## What Is a C3PAO and Why Do You Need One?

Because DFARS 252.204-7021 requires Level 2 certification, you cannot simply self-assess — you need an independent audit by a **CMMC Third-Party Assessment Organization (C3PAO)**. These are private companies accredited by the Cyber AB (the CMMC Accreditation Body) to conduct formal assessments.

Think of a C3PAO like a financial auditor: they review your evidence, interview your staff, test your technical controls, and issue a formal certification. The certification is valid for **three years**, with an annual affirmation required each year.

To find an authorized C3PAO: **cyberAB.us**

---

## The Three Key Documents You Must Build

Before a C3PAO will assess you, you need these three artifacts:

### 1. System Security Plan (SSP)
A written document that describes:
- What systems are in scope (your CUI boundary)
- How you implement each of the 110 practices
- Who is responsible for each control
- Network diagrams and data flow maps showing where CUI moves

This is the central document of your CMMC program. Plan 2–4 months to draft it properly.

### 2. Plan of Action & Milestones (POA&M)
A tracked list of security gaps — practices you have not yet fully implemented — along with your plan and timeline to fix them. A POA&M is not a sign of failure; it is required and expected. However, certain critical practices (see below) must be fully implemented before certification can be granted — they cannot sit in a POA&M.

### 3. SPRS Score
The **Supplier Performance Risk System** score is your self-calculated cybersecurity score, starting at 110 and deducting points for every unmet practice. You must submit this score to the DoD's SPRS portal even before your C3PAO assessment begins. Contracting Officers can see this score when evaluating you.

---

## The Seven "Must Fix Before Assessment" Practices

Seven practices are considered critical by the DoD — they must be fully implemented at the time of your assessment. You cannot receive conditional certification with these in a POA&M:

| Practice ID | What It Means in Plain English |
|-------------|-------------------------------|
| **AC.L2-3.1.3** | Control which people and systems can access CUI (need-to-know enforcement) |
| **IA.L2-3.5.3** | Multi-factor authentication (MFA) for all accounts that access CUI |
| **SC.L2-3.13.8** | Encrypt all CUI data in transit using FIPS-validated encryption |
| **SC.L2-3.13.11** | Use only FIPS 140-2/3 validated cryptography throughout your environment |
| **SI.L2-3.14.6** | Monitor your systems to detect attacks and anomalous activity |
| **AU.L2-3.3.1** | Create and retain audit logs of all activity on CUI systems |
| **IR.L2-3.6.1** | Have an operational incident response capability |

For a 45-person firm, MFA deployment and FIPS-compliant encryption are often the fastest wins and should be prioritized immediately.

---

## Important Compliance Obligations Beyond the 110 Practices

Even while you prepare for Level 2 assessment, certain obligations are already active under DFARS 252.204-7012:

- **72-Hour Incident Reporting**: If you discover a cyber incident involving CUI (unauthorized access, malware, suspected data theft), you must report it to the DoD via the **DIBNET portal** (dibnet.dod.mil) within **72 hours** of discovery. This is not optional.

- **Cloud Services**: If you use cloud services (Microsoft 365, Google Workspace, AWS, etc.) to store or process CUI, those services must be **FedRAMP Authorized at Moderate** baseline or equivalent. Standard commercial cloud tiers generally do not meet this requirement. Microsoft 365 GCC (Government Community Cloud) or GCC High are commonly used compliant options.

- **Subcontractors**: If you use any subcontractors who will have access to CUI from this contract, you are required to flow down CMMC requirements to them. They must hold the appropriate CMMC certification before you award them subcontract work involving CUI.

---

## Rough Timeline: How Long Will This Take?

For a 45-person firm starting from scratch, the realistic timeline to achieve CMMC Level 2 certification is **12 to 18 months**. Here is a phased breakdown:

### Phase 1: Scoping and Gap Assessment (Months 1–2)
- Identify all CUI data in your environment
- Define your CUI asset boundary (which systems are in scope)
- Conduct a gap assessment against all 110 practices
- Calculate your initial SPRS score
- Submit your SPRS score to the portal (required even before remediation is complete)

**What you need**: An experienced CMMC consultant or Registered Practitioner (RP) to lead the gap assessment.

### Phase 2: Remediation (Months 2–10)
- Fix critical gaps, starting with the seven must-fix practices above
- Deploy MFA across all CUI-touching accounts
- Implement FIPS-compliant encryption
- Deploy logging/SIEM capability
- Draft and finalize your SSP
- Manage open items in your POA&M
- Address cloud CUI storage if currently on non-FedRAMP services

**What you need**: IT resources (internal or managed service provider) to implement technical controls; a policy writer to draft the required security policies.

### Phase 3: Pre-Assessment Preparation (Months 10–12)
- Finalize SSP and ensure it covers all 110 practices
- Close as many POA&M items as possible (especially critical practices)
- Conduct internal mock assessment
- Train staff on what to expect during the C3PAO interviews
- Select and contract with a C3PAO (negotiate scope, sign NDA)

### Phase 4: C3PAO Assessment (Months 12–14)
- **Documentation Review** (2–4 weeks): C3PAO reviews your SSP, policies, and evidence remotely
- **Active Assessment** (1–3 weeks): Interviews, technical testing, configuration reviews
- **Findings and Reporting**: C3PAO issues findings; you have a limited window to provide additional evidence

### Phase 5: Certification and Annual Maintenance (Month 14–18 and ongoing)
- Receive certification (valid 3 years) or conditional certification with remaining POA&M items (must remediate within 180 days)
- Submit annual affirmation to the CMMC-AB each year
- Update SSP and POA&M as your environment changes
- Plan for re-assessment in year 3

---

## Estimated Costs (Rough Ranges for a 45-Person Firm)

These are rough industry estimates and vary significantly based on current posture:

| Activity | Estimated Cost Range |
|----------|---------------------|
| Gap assessment (external consultant) | $15,000 – $40,000 |
| Remediation (technical implementation) | $50,000 – $200,000+ depending on gaps |
| SSP/policy documentation (consultant) | $20,000 – $50,000 |
| C3PAO assessment fee | $50,000 – $150,000 |
| Ongoing compliance tools (SIEM, MFA, vulnerability scanning) | $20,000 – $60,000/year |

---

## Your Immediate Next Steps (This Week)

1. **Identify your CUI**: Ask your contract Program Manager what CUI categories are covered under this contract. Look at the contract's DD Form 254 (Contract Security Classification Specification) if one is attached.

2. **Do not use personal or standard commercial cloud tools for CUI**: If your engineers are currently using standard Gmail, Dropbox, or consumer Microsoft 365 for contract work, stop immediately. This is a compliance violation.

3. **Engage a CMMC consultant**: A Registered Practitioner (RP) or Registered Practitioner Organization (RPO) — find them at cyberAB.us — can conduct your gap assessment and guide the remediation process. Given your timeline, start this process now.

4. **Submit an SPRS score**: Even a low or negative score is better than no score. Your Contracting Officer may require it before contract performance begins.

5. **Check your subcontractors**: If any vendors will touch CUI, notify them that they will need CMMC certification. Start that conversation early — they need time too.

---

## Summary

CMMC Level 2 means your 45-person firm must demonstrate that it meets 110 cybersecurity practices to protect the sensitive defense information you handle under this contract. You will need to hire a C3PAO to formally assess and certify you. The process typically takes 12–18 months and requires significant investment in documentation, technical controls, and staff readiness. The good news: this process — once completed — is your competitive advantage, as CMMC will be required across most DoD contracts and many of your competitors have not yet started.

**Applicable regulatory references**: 32 CFR Part 170 (CMMC 2.0 Final Rule), NIST SP 800-171 Rev 2, DFARS 252.204-7012, DFARS 252.204-7019, DFARS 252.204-7020, DFARS 252.204-7021.

# CMMC Level 2: A Plain-English Guide for Your Aerospace Firm

## What Is CMMC?

CMMC stands for **Cybersecurity Maturity Model Certification**. It is a Department of Defense (DoD) program that requires companies in the defense supply chain to demonstrate they are properly protecting sensitive government information on their systems. Think of it as a cybersecurity audit and certification that proves your company takes information security seriously enough to be trusted with DoD work.

The clause in your contract — DFARS 252.204-7021 — is the legal hook that requires you to achieve and maintain CMMC certification as a condition of doing business with the DoD.

---

## Why Does the DoD Require This?

The DoD shares two categories of sensitive information with contractors:

- **FCI (Federal Contract Information)**: Basic information about the contract itself — what you're building, for whom, at what price.
- **CUI (Controlled Unclassified Information)**: More sensitive technical or operational data — engineering specs, design documents, test data, export-controlled technical information (ITAR/EAR), and similar materials.

As an aerospace engineering firm, you almost certainly handle CUI. Foreign adversaries (primarily China and Russia) have spent years stealing defense-related intellectual property from contractors exactly like you. CMMC is the DoD's response to that threat.

---

## What Are the CMMC Levels?

There are three levels:

| Level | Who It Applies To | How It's Verified |
|-------|-------------------|-------------------|
| Level 1 | Companies that only handle FCI | Annual self-assessment |
| **Level 2** | **Companies that handle CUI** | **Third-party assessment (C3PAO) every 3 years** |
| Level 3 | Companies handling the most sensitive CUI (critical programs) | Government-led assessment |

Your contract requires **Level 2**, which applies to any company that receives, creates, stores, processes, or transmits CUI. This is the most common requirement across the defense industrial base.

---

## What Does Level 2 Actually Require?

CMMC Level 2 is based almost entirely on **NIST SP 800-171**, a well-established federal standard for protecting CUI. It contains **110 security practices** organized into 14 domains (categories):

1. Access Control
2. Awareness and Training
3. Audit and Accountability
4. Configuration Management
5. Identification and Authentication
6. Incident Response
7. Maintenance
8. Media Protection
9. Personnel Security
10. Physical Protection
11. Risk Assessment
12. Security Assessment
13. System and Communications Protection
14. System and Information Integrity

### What These Mean in Practice

Here are examples of what you'll need to have in place:

- **Access Control**: Only authorized employees can access systems that store or process CUI. Multi-factor authentication (MFA) is required. Privileged access (admin rights) must be tightly controlled.
- **Audit Logs**: Your systems must log who accessed what, when, and from where. Logs must be retained and reviewed.
- **Encryption**: CUI must be encrypted both when stored (at rest) and when transmitted over networks (in transit).
- **Incident Response**: You need a written plan for what to do if you suffer a cyberattack or data breach, and you must be able to report incidents to the DoD within 72 hours.
- **Configuration Management**: Systems holding CUI must be hardened (unnecessary software/services disabled) and regularly patched.
- **Risk Assessments**: You must periodically assess your cybersecurity risks and document what you find.
- **Policies and Procedures**: Written policies covering all 14 domains must exist and be followed.
- **Physical Security**: Physical access to systems containing CUI must be controlled (locked server rooms, clean-desk policies, etc.).
- **Media Protection**: Portable media (USB drives, laptops) containing CUI must be controlled, encrypted, and properly sanitized before disposal.

---

## How Is Level 2 Certification Obtained?

Unlike Level 1 (which is self-assessed), **Level 2 requires an independent third-party assessment** conducted by a **C3PAO** (Certified Third-Party Assessment Organization). The C3PAO is an accredited firm that will assess your environment against all 110 practices and issue a certification if you pass.

### The Assessment Process

1. **Scoping**: Define which systems, networks, people, and locations handle CUI. This is called your "CUI environment" or assessment scope. Keeping the scope small (isolating CUI to as few systems as possible) reduces cost and complexity.
2. **Gap Assessment**: Identify where you currently fall short of the 110 requirements. Most companies starting from scratch fail 40–70 practices initially.
3. **Remediation**: Fix the gaps — implement the missing controls, write the missing policies, configure systems correctly.
4. **Formal Assessment**: The C3PAO reviews your documentation, interviews staff, and tests your technical controls. This typically takes 1–3 weeks on-site or remote.
5. **Certification**: If you meet all 110 practices (or have an accepted Plan of Action & Milestones for minor gaps), the C3PAO submits results to the DoD's CMMC database (called SPRS). You receive your certification, valid for 3 years.

---

## How Long Will This Take?

For a 45-person firm starting from scratch, here is a realistic timeline:

| Phase | Duration |
|-------|----------|
| Scoping and gap assessment | 4–8 weeks |
| Remediation (fixing gaps) | 6–18 months (highly variable) |
| Pre-assessment readiness check | 4–8 weeks |
| Formal C3PAO assessment | 2–6 weeks |
| **Total realistic timeline** | **12–24 months** |

The wide range depends on:
- **How mature your current IT security is.** If you already have MFA, encryption, and documented policies, you're ahead. Most small engineering firms are starting close to zero.
- **Whether you engage a consultant.** A CMMC Registered Practitioner (RP) or Registered Provider Organization (RPO) can dramatically accelerate the process by guiding remediation.
- **Your scope.** If CUI lives on 3 workstations and a file server, remediation is much faster than if it touches 40 machines and a complex network.
- **Resource availability.** If you dedicate a full-time person internally to this effort, it moves faster.

### Important: Your Contract Clock Is Running

Your DFARS clause requires you to be certified before performing work involving CUI (or within a timeframe specified in the contract). Check your contract for any stated deadline. If one exists, notify your Contracting Officer (KO) immediately and begin work now — 12–24 months is not unusual, and waivers or timelines can sometimes be negotiated for good-faith effort.

---

## What Will It Cost?

Rough estimates for a 45-person firm:

| Item | Estimated Cost |
|------|----------------|
| CMMC consultant / RPO engagement | $50,000–$150,000 |
| IT infrastructure upgrades (MFA, encryption, logging tools, endpoint protection) | $30,000–$100,000 |
| Policy and documentation development | Included with consultant or $10,000–$30,000 if separate |
| C3PAO formal assessment fee | $50,000–$100,000 |
| **Total range** | **$140,000–$380,000** |

These are rough estimates. Actual costs depend on your current state, scope, and the vendors you select. Annual ongoing costs for maintaining compliance (monitoring tools, training, reassessment) will run $30,000–$80,000/year.

---

## Your Immediate Next Steps

1. **Do not ignore this.** DFARS 252.204-7021 is a contract requirement. Non-compliance can result in contract termination, suspension, or debarment from future DoD work.

2. **Identify your CUI.** Understand what sensitive government information you are receiving and where it lives (email, file servers, laptops, cloud storage). This defines your scope.

3. **Conduct a gap assessment.** Hire a CMMC Registered Practitioner or RPO to assess your current state against NIST SP 800-171. This will produce a prioritized list of what needs to be fixed.

4. **Create a System Security Plan (SSP).** This is a required document that describes your CUI environment, your systems, and how each of the 110 practices is implemented. Start drafting it early.

5. **Create a Plan of Action & Milestones (POA&M).** For every practice you haven't yet implemented, document your plan and timeline to fix it. The DoD may review your SPRS score (a self-assessed score you must submit now, even before certification).

6. **Submit your SPRS score.** Under current rules, you must self-assess against NIST SP 800-171 and report a score in the Supplier Performance Risk System (SPRS) at supplierpas.epls.fas.gsa.gov. This is required even while working toward formal CMMC certification. If you haven't done this, do it now.

7. **Select and engage a C3PAO.** The Cyber AB Marketplace (cyberab.org) lists all accredited assessment organizations. Get quotes early — C3PAO calendars fill up, and scheduling can take months.

---

## Key Terms Cheat Sheet

| Term | What It Means |
|------|---------------|
| CMMC | Cybersecurity Maturity Model Certification — the DoD's cybersecurity certification program |
| DFARS | Defense Federal Acquisition Regulation Supplement — the legal framework governing DoD contracts |
| CUI | Controlled Unclassified Information — sensitive (but not classified) government data |
| NIST SP 800-171 | The federal standard with 110 cybersecurity practices that form the basis of CMMC Level 2 |
| C3PAO | Certified Third-Party Assessment Organization — the accredited firm that certifies you |
| SSP | System Security Plan — your master document describing your security environment |
| POA&M | Plan of Action & Milestones — your remediation roadmap for gaps |
| SPRS | Supplier Performance Risk System — DoD database where you report your self-assessment score |
| RPO | Registered Provider Organization — a CMMC-accredited consulting firm that can help you prepare |
| Cyber AB | The CMMC Accreditation Body — oversees C3PAOs and certifications |

---

## Summary

CMMC Level 2 means the DoD requires you to prove — through an independent audit — that you are protecting their sensitive information using 110 specific cybersecurity practices drawn from NIST SP 800-171. For a 45-person firm starting from scratch, expect 12–24 months of preparation work, costs in the range of $140,000–$380,000, and an ongoing commitment to maintaining your security posture. The most important thing you can do right now is engage a qualified CMMC consultant and submit your SPRS self-assessment score. The process is substantial but very achievable for a firm your size.

# CMMC Level 2 Gap Assessment Report

**Assessment Date**: 2026-04-25  
**CMMC Level**: Level 2 — Advanced (110 Practices, NIST SP 800-171 Rev 2)  
**Applicable DFARS Clauses**: 252.204-7012, 252.204-7019, 252.204-7020, 252.204-7021  

---

## IT Environment Summary

| Component | Detail |
|-----------|--------|
| Identity Management | Active Directory, 80 users |
| MFA | NOT DEPLOYED |
| Endpoints | Windows 10/11 managed via Intune |
| Perimeter Security | Palo Alto Firewall |
| Productivity Suite | Microsoft 365 E3 (commercial — NOT GCC) |
| SIEM | NOT DEPLOYED |
| Vulnerability Scanning | Quarterly, Nessus, **unauthenticated** |
| CUI Storage | SharePoint Online (commercial M365 E3) |

---

## Critical Pre-Assessment Finding: SharePoint Online (Commercial M365) for CUI

> **BLOCKER**: CUI stored in commercial Microsoft 365 E3 (non-GCC) violates DFARS 252.204-7012, which requires cloud services handling CUI to be FedRAMP Authorized at Moderate or equivalent. Commercial M365 E3 is NOT FedRAMP Moderate authorized for CUI. This must be migrated to **Microsoft 365 Government (GCC or GCC High)** before a C3PAO assessment can proceed. This issue affects every CUI-related practice in scope.

---

## Gap Assessment Table

### IA — Identification and Authentication

| Practice ID | Domain | Practice Statement | Status | Evidence Needed | Gap Notes | SPRS Score Impact |
|-------------|--------|--------------------|--------|-----------------|-----------|------------------|
| IA.L2-3.5.3 | IA | Use MFA for local and network access to privileged accounts and for network access to non-privileged accounts. | ❌ NOT MET | MFA enrollment report showing 100% of privileged and non-privileged accounts enrolled; Conditional Access policy exports from Entra ID/Azure AD | No MFA deployed anywhere. This is a **critical practice** — cannot have a POA&M at certification. Must be remediated before C3PAO assessment. Affects all 80 users and all privileged accounts. | **-5 pts** |
| IA.L2-3.5.4 | IA | Employ replay-resistant authentication mechanisms for network access. | ❌ NOT MET | Kerberos/NTLM configuration export; authentication logs showing replay-resistant protocols in use | With no MFA and no evidence of replay-resistant auth configuration, this is likely not met. Kerberos provides some replay resistance but must be verified and documented. | **-3 pts** |
| IA.L2-3.5.5 | IA | Employ identifier management to prevent reuse of identifiers for a defined period. | 🟡 PARTIAL | AD account lifecycle policy; script/report showing identifier reuse prevention settings | AD can enforce this but requires a documented policy and verified configuration. No evidence provided. | **-1 pt** |
| IA.L2-3.5.6 | IA | Disable identifiers after a defined inactivity period. | 🟡 PARTIAL | AD inactive account review reports; Group Policy Object (GPO) exports showing inactivity lockout settings | Likely partially configured in AD but requires formal policy, documented threshold, and evidence of enforcement. | **-1 pt** |
| IA.L2-3.5.7 | IA | Enforce minimum password complexity and change requirements. | 🟡 PARTIAL | GPO export showing password policy settings; Intune compliance policy screenshots | AD likely enforces some password complexity but must meet NIST SP 800-171 requirements and be fully documented. | **-1 pt** |
| IA.L2-3.5.10 | IA | Store and transmit only cryptographically-protected passwords (FIPS 140-2/3 validated). | 🟡 PARTIAL | AD/Windows FIPS mode configuration; verification that NTLMv2 or Kerberos with FIPS cipher suites in use | Windows can operate in FIPS mode but this must be explicitly enabled and verified. Non-GCC M365 raises concerns about FIPS-validated storage of credentials. | **-3 pts** |
| MA.L2-3.7.5 | MA | Require MFA to establish remote maintenance sessions. | ❌ NOT MET | Same as IA.L2-3.5.3 — MFA enrollment/enforcement evidence | No MFA means remote maintenance sessions (RDP, remote admin tools) are not MFA-protected. | **-1 pt** |

---

### AU — Audit and Accountability (No SIEM)

| Practice ID | Domain | Practice Statement | Status | Evidence Needed | Gap Notes | SPRS Score Impact |
|-------------|--------|--------------------|--------|-----------------|-----------|------------------|
| AU.L2-3.3.1 | AU | Create and retain system audit logs and records to enable monitoring, analysis, investigation, and reporting. | ❌ NOT MET | Log retention policy; SIEM or centralized log repository configuration; evidence logs from all CUI-touching systems (AD, SharePoint, endpoints, firewall) are captured and retained for 3 years | **Critical practice** — no SIEM means logs are likely siloed on individual systems with no centralized collection, correlation, or assured retention. Windows Event logs on endpoints have limited local retention. | **-3 pts** |
| AU.L2-3.3.2 | AU | Ensure actions of individual users can be uniquely traced. | 🟡 PARTIAL | Audit log samples showing user-level attribution from AD, M365 Audit Log, Palo Alto traffic logs | Without a SIEM, correlating user actions across systems is manual and unreliable. M365 Unified Audit Log provides some coverage but must be explicitly enabled and retained. | **-2 pts** |
| AU.L2-3.3.3 | AU | Review and update logged events. | ❌ NOT MET | Documented logged event list; records of periodic review meetings; evidence of updates to log configuration | No formal process likely exists without a SIEM. Requires documented policy + evidence of regular review. | **-1 pt** |
| AU.L2-3.3.4 | AU | Alert in the event of an audit logging process failure. | ❌ NOT MET | SIEM alerting rules or equivalent monitoring configuration; evidence of test alerts | Requires automated alerting capability. No SIEM means this is not met. | **-1 pt** |
| AU.L2-3.3.5 | AU | Correlate audit record review, analysis, and reporting processes. | ❌ NOT MET | SIEM correlation rules; documented analysis procedures | Cannot be met without log aggregation/SIEM capability. | **-1 pt** |
| AU.L2-3.3.6 | AU | Provide audit record reduction and report generation. | ❌ NOT MET | Log management tool configuration; sample reports generated | No SIEM = no log reduction/reporting capability. | **-1 pt** |
| AU.L2-3.3.7 | AU | Provide system capability to compare and synchronize internal clocks with authoritative sources. | 🟡 PARTIAL | NTP configuration on all in-scope systems; AD time sync settings | AD provides NTP via domain hierarchy; must verify all systems (including non-domain joined or BYOD) sync to an authoritative source. Document the configuration. | **-1 pt** |
| AU.L2-3.3.8 | AU | Protect audit information and tools from unauthorized access, modification, and deletion. | ❌ NOT MET | Evidence of log protection (SIEM access controls, immutable storage, write-once log settings) | Without a SIEM with access controls, local logs on endpoints/servers are modifiable by admins — not adequately protected. | **-1 pt** |
| AU.L2-3.3.9 | AU | Limit management of audit logging to a subset of privileged users. | ❌ NOT MET | RBAC configuration for log management; AD/SIEM role assignments | Cannot be effectively enforced or demonstrated without centralized logging with role-based access. | **-1 pt** |

---

### RA — Risk Assessment (Unauthenticated Scanning)

| Practice ID | Domain | Practice Statement | Status | Evidence Needed | Gap Notes | SPRS Score Impact |
|-------------|--------|--------------------|--------|-----------------|-----------|------------------|
| RA.L2-3.11.1 | RA | Periodically assess the risk to organizational operations, assets, and individuals. | 🟡 PARTIAL | Formal risk assessment report with date; risk register; evidence of periodic reassessment | Quarterly Nessus scans address vulnerability risk but do not constitute a full organizational risk assessment. A formal risk assessment against all 110 CMMC practices is needed. | **-3 pts** |
| RA.L2-3.11.2 | RA | Scan for vulnerabilities in organizational systems periodically and when new vulnerabilities are identified. | 🟡 PARTIAL | Nessus scan reports (dated); scan scope documentation showing all in-scope assets covered; **credentialed scan configuration** | Quarterly scans exist — that is positive. However, **unauthenticated scans are a common assessment finding** (per DoD Assessment Methodology). Unauthenticated scans miss locally-installed software vulnerabilities, misconfigurations, and patch gaps that only credentialed scans detect. Assessors will flag this. Monthly credentialed scans are expected. | **-3 pts** |
| RA.L2-3.11.3 | RA | Remediate vulnerabilities in accordance with risk assessments. | 🟡 PARTIAL | Vulnerability remediation tracking records; evidence of timely patching tied to risk ratings; Intune patch compliance reports | No evidence provided of a formal remediation process. Intune can enforce patching but a documented vulnerability management program with SLAs (e.g., Critical: 15 days, High: 30 days) is required. | **-3 pts** |

---

### SI — System and Information Integrity (No SIEM, Monitoring Gaps)

| Practice ID | Domain | Practice Statement | Status | Evidence Needed | Gap Notes | SPRS Score Impact |
|-------------|--------|--------------------|--------|-----------------|-----------|------------------|
| SI.L2-3.14.3 | SI | Monitor system security alerts and advisories and take action in response. | 🟡 PARTIAL | Subscription to US-CERT/CISA advisories; documented process for evaluating and acting on alerts; Intune/Defender alert response records | Microsoft Defender (available via M365 E3 + Intune) provides some advisory monitoring. Must document the process and show evidence of advisory reviews and responses. | **-2 pts** |
| SI.L2-3.14.6 | SI | Monitor systems to detect attacks and indicators of potential attacks. | ❌ NOT MET | SIEM with IDS/IPS rules; EDR/XDR alert configuration and evidence; network monitoring logs from Palo Alto showing active threat detection | **Critical practice** — no SIEM means no centralized attack detection. Palo Alto firewall provides perimeter monitoring, and Microsoft Defender for Endpoint (available but unclear if deployed) can provide EDR. Without a SIEM or documented detection capability covering all CUI-touching systems, this practice is NOT MET. | **-5 pts** |
| SI.L2-3.14.7 | SI | Identify unauthorized use of systems. | ❌ NOT MET | User behavior analytics (UBA) or equivalent; DLP alerts for SharePoint; anomalous access reports from M365 Audit Log | No evidence of capability to detect unauthorized system use. M365 E3 has some Defender for Cloud Apps functionality but comprehensive coverage is unlikely without additional tooling. | **-3 pts** |

---

### SC — System and Communications Protection (CUI in Commercial Cloud)

| Practice ID | Domain | Practice Statement | Status | Evidence Needed | Gap Notes | SPRS Score Impact |
|-------------|--------|--------------------|--------|-----------------|-----------|------------------|
| SC.L2-3.13.8 | SC | Implement cryptographic mechanisms to protect confidentiality of CUI during transmission (FIPS 140-2/3). | 🟡 PARTIAL | TLS configuration for all CUI transmission paths; FIPS mode configuration on Windows endpoints; M365/SharePoint transport encryption documentation | **Critical practice**. Commercial M365 E3 uses TLS 1.2+ for transport but FIPS validation status of commercial (non-GCC) SharePoint is not equivalent to GCC/GCC High. Windows endpoints must have FIPS mode enabled. Must document and verify all CUI transmission paths. | **-5 pts** |
| SC.L2-3.13.11 | SC | Employ FIPS-validated cryptography when used to protect CUI. | ❌ NOT MET | FIPS mode enabled on all Windows 10/11 endpoints (Group Policy or Intune policy export); documentation that CUI storage/transmission uses only FIPS-validated modules | **Critical practice**. No evidence of FIPS mode deployment. Commercial M365 (non-GCC) does not provide the FedRAMP Moderate authorization needed to satisfy FIPS requirements for CUI. This is a foundational gap. | **-5 pts** |
| SC.L2-3.13.16 | SC | Protect CUI at rest. | ❌ NOT MET | BitLocker encryption status reports from Intune for all endpoints; SharePoint data-at-rest encryption documentation (FedRAMP Moderate equivalent) | Intune can enforce BitLocker on endpoints — must verify deployment. Commercial SharePoint encrypts at rest but not under a FedRAMP Moderate ATO, making this non-compliant for CUI. | **-3 pts** |
| SC.L2-3.13.6 | SC | Deny network communications by default; allow by exception. | 🟡 PARTIAL | Palo Alto firewall policy export showing default-deny ruleset; documentation of exception process | Palo Alto supports this but requires verified configuration. Must export and document the deny-by-default rule set. | **-1 pt** |
| SC.L2-3.13.7 | SC | Prevent split tunneling for remote access. | 🟡 PARTIAL | VPN configuration showing split tunneling disabled; routing tables for remote users | No mention of VPN configuration. Must verify remote worker traffic routes through managed access points — split tunneling must be disabled for CUI systems. | **-1 pt** |

---

### AC — Access Control (CUI Flow, Least Privilege)

| Practice ID | Domain | Practice Statement | Status | Evidence Needed | Gap Notes | SPRS Score Impact |
|-------------|--------|--------------------|--------|-----------------|-----------|------------------|
| AC.L2-3.1.3 | AC | Control the flow of CUI in accordance with approved authorizations. | ❌ NOT MET | SharePoint permissions audit; data classification labels applied to CUI content; DLP policies configured; documented CUI access control policy | **Critical practice**. CUI stored in commercial SharePoint Online with no documented access controls or DLP policies. Must implement and document CUI flow controls, including who can access, download, share, and forward CUI content. | **-5 pts** |
| AC.L2-3.1.5 | AC | Employ least privilege, including for privileged accounts. | 🟡 PARTIAL | AD privileged account inventory; role-based access control documentation; evidence of quarterly access reviews; Intune admin role assignments | With 80 users in AD and no described PAM/privilege management, this is likely partially implemented at best. Must document role assignments and show regular access reviews. | **-3 pts** |
| AC.L2-3.1.12 | AC | Monitor and control remote access sessions. | 🟡 PARTIAL | VPN/remote access logs; Conditional Access policy exports; evidence of session monitoring | No mention of VPN or remote access solution beyond M365. Must document how remote access to CUI systems is monitored and controlled. | **-1 pt** |
| AC.L2-3.1.13 | AC | Employ cryptographic mechanisms to protect confidentiality of remote access sessions. | 🟡 PARTIAL | VPN configuration showing encryption standards; TLS configuration for remote access portals | Tied to SC.L2-3.13.8 and FIPS concerns. Must verify remote access uses FIPS-validated encryption. | **-1 pt** |

---

### CA — Security Assessment

| Practice ID | Domain | Practice Statement | Status | Evidence Needed | Gap Notes | SPRS Score Impact |
|-------------|--------|--------------------|--------|-----------------|-----------|------------------|
| CA.L2-3.12.1 | CA | Periodically assess the security controls in organizational systems. | ❌ NOT MET | Annual security control assessment report; evidence of assessor qualifications; schedule for ongoing assessments | This gap assessment likely represents the first formal assessment. Must institute an annual security assessment process. | **-3 pts** |
| CA.L2-3.12.2 | CA | Develop and implement plans of action to correct deficiencies. | ❌ NOT MET | Formal POA&M document covering all gaps identified; milestone dates; responsible owners; remediation budgets | No POA&M exists based on the environment description. Must be created immediately following this gap assessment. | **-3 pts** |
| CA.L2-3.12.3 | CA | Monitor security controls on an ongoing basis. | ❌ NOT MET | Continuous monitoring program documentation; automated compliance dashboards (Intune compliance, Defender for Endpoint, M365 Secure Score evidence) | Without a SIEM and with limited visibility, ongoing monitoring is not in place. Intune and M365 Secure Score can partially address this with proper configuration. | **-3 pts** |
| CA.L2-3.12.4 | CA | Develop, document, and periodically update system security plans. | ❌ NOT MET | Complete SSP covering all 110 practices; signed by senior official; dated within last 12 months | No SSP mentioned. This is a foundational requirement for any CMMC assessment. | **-3 pts** |

---

### IR — Incident Response

| Practice ID | Domain | Practice Statement | Status | Evidence Needed | Gap Notes | SPRS Score Impact |
|-------------|--------|--------------------|--------|-----------------|-----------|------------------|
| IR.L2-3.6.1 | IR | Establish an operational incident-handling capability. | ❌ NOT MET | Written Incident Response Plan (IRP); evidence of DIBNET portal account registration; documented 72-hour reporting procedure for DFARS 7012 | **Critical practice**. No incident response capability described. Must include DIBNET reporting procedures per DFARS 252.204-7012. | **-1 pt** |
| IR.L2-3.6.2 | IR | Track, document, and report incidents to designated officials and authorities. | ❌ NOT MET | Incident tracking system/ticketing records; DIBNET reporting templates; evidence of test reporting | No incident tracking capability in place. | **-1 pt** |
| IR.L2-3.6.3 | IR | Test the organizational incident response capability. | ❌ NOT MET | Tabletop exercise records with dates; lessons-learned documentation; after-action reports | No evidence of IR testing. Must conduct and document at least annual tabletop exercises. | **-1 pt** |

---

### AT — Awareness and Training

| Practice ID | Domain | Practice Statement | Status | Evidence Needed | Gap Notes | SPRS Score Impact |
|-------------|--------|--------------------|--------|-----------------|-----------|------------------|
| AT.L2-3.2.1 | AT | Ensure personnel are aware of CUI security risks and related policies. | ❌ NOT MET | Training completion records for all 80 users; training content covering CUI handling, CMMC requirements; dates within last 12 months | No training program described. With CUI in SharePoint and 80 users, all must complete documented security awareness training. | **-1 pt** |
| AT.L2-3.2.2 | AT | Ensure personnel are trained to carry out assigned security responsibilities. | ❌ NOT MET | Role-based training records for system admins, IT staff, and security personnel; training content covering their specific responsibilities | IT administrators managing CUI systems must receive role-specific training. | **-1 pt** |
| AT.L2-3.2.3 | AT | Provide security awareness training on recognizing and reporting insider threats. | ❌ NOT MET | Insider threat training content; completion records for all personnel with CUI access | Must include insider threat indicators in training curriculum. | **-1 pt** |

---

### CM — Configuration Management

| Practice ID | Domain | Practice Statement | Status | Evidence Needed | Gap Notes | SPRS Score Impact |
|-------------|--------|--------------------|--------|-----------------|-----------|------------------|
| CM.L2-3.4.1 | CM | Establish and maintain baseline configurations and inventories. | 🟡 PARTIAL | Intune device inventory export; documented baseline configuration for Windows 10/11; hardware/software inventory | Intune manages endpoints and can produce inventory. Requires documented baseline configurations per OS version and documented approval. | **-3 pts** |
| CM.L2-3.4.2 | CM | Establish and enforce security configuration settings. | 🟡 PARTIAL | Intune configuration profile exports; CIS Benchmark or DISA STIG application evidence; Compliance Policy reports | Intune supports enforcing security baselines (Microsoft Security Baseline or CIS). Must verify deployment and document the baseline standard used. | **-1 pt** |
| CM.L2-3.4.6 | CM | Employ principle of least functionality. | 🟡 PARTIAL | Intune application inventory; evidence of disabling unnecessary features/services; Windows feature audit | Intune can restrict applications but must document and enforce least functionality policy. | **-1 pt** |
| CM.L2-3.4.7 | CM | Restrict/disable nonessential programs, functions, ports, protocols, and services. | 🟡 PARTIAL | Palo Alto firewall policy showing blocked ports/protocols; Windows Firewall/Intune policies restricting services; AppLocker or Intune app control policy | Palo Alto provides network-level restriction but endpoint-level service/port restriction must also be documented. | **-1 pt** |
| CM.L2-3.4.8 | CM | Apply deny-by-exception or allow-by-exception software policy. | ❌ NOT MET | AppLocker policy exports; Intune application control policy; Windows Defender Application Control (WDAC) configuration | No application whitelisting/blacklisting mentioned. This is a significant gap for CUI-handling systems. | **-1 pt** |

---

## SPRS Score Impact Summary

| Category | NOT MET Practices (Count) | Estimated Point Deduction |
|----------|--------------------------|--------------------------|
| Identification & Authentication (IA) | 2 fully NOT MET + 4 partial | -14 pts |
| Audit & Accountability (AU) | 6 NOT MET + 2 partial | -11 pts |
| Risk Assessment (RA) | 0 NOT MET + 3 partial | -9 pts |
| System & Information Integrity (SI) | 3 NOT MET + 1 partial | -10 pts |
| System & Comms Protection (SC) | 3 NOT MET + 3 partial | -15 pts |
| Access Control (AC) | 1 NOT MET + 3 partial | -10 pts |
| Security Assessment (CA) | 4 NOT MET | -12 pts |
| Incident Response (IR) | 3 NOT MET | -3 pts |
| Awareness & Training (AT) | 3 NOT MET | -3 pts |
| Configuration Management (CM) | 1 NOT MET + 4 partial | -8 pts |

> **Note**: Partial implementations receive FULL deductions per SPRS methodology (no partial credit). Estimated deductions above reflect a conservative calculation based on the DoD Assessment Methodology point weights. The exact score depends on assessor findings for all 110 practices.

### Estimated SPRS Score Range

| Scenario | Estimated Score |
|----------|----------------|
| Starting score (all 110 MET) | **+110** |
| Conservative estimate (partial = NOT MET) | **~+15 to +30** |
| Realistic assessment estimate given described gaps | **~-20 to +10** |

The estimated score is well below what contracting officers expect to see. Any score below **+70** is likely to trigger scrutiny from the DoD Contracting Officer (CO).

---

## Critical Gaps Requiring Immediate Remediation (Cannot POA&M)

The following practices are **critical** and must be fully MET before any C3PAO certification can be issued. These cannot appear in a POA&M at the time of certification:

| # | Practice ID | Gap | Priority Action |
|---|-------------|-----|----------------|
| 1 | **IA.L2-3.5.3** | No MFA deployed for any users | Deploy Microsoft Entra MFA + Conditional Access policies; enforce for all 80 users and privileged accounts immediately |
| 2 | **SC.L2-3.13.8** | CUI transmission encryption unverified; commercial M365 not FedRAMP Moderate | Migrate CUI from commercial SharePoint to M365 GCC/GCC High; enforce TLS 1.2+ with FIPS cipher suites |
| 3 | **SC.L2-3.13.11** | FIPS-validated cryptography not deployed | Enable FIPS mode on all Windows 10/11 endpoints via Intune/Group Policy; migrate to GCC environment |
| 4 | **AC.L2-3.1.3** | CUI flow controls not implemented in SharePoint | Implement Microsoft Purview sensitivity labels + DLP policies; audit and restrict SharePoint permissions |
| 5 | **SI.L2-3.14.6** | No SIEM or centralized attack detection | Deploy Microsoft Sentinel (integrates with M365 GCC) or equivalent; configure Defender for Endpoint with centralized alerting |
| 6 | **AU.L2-3.3.1** | No centralized audit logging; no SIEM | Deploy SIEM with 3-year log retention; enable M365 Unified Audit Log; collect Palo Alto and AD logs |
| 7 | **IR.L2-3.6.1** | No incident response plan or capability | Draft and approve an IRP; register with DIBNET; document 72-hour reporting procedure per DFARS 7012 |

---

## Top Remediation Priorities (Ranked by SPRS Impact + Risk)

| Priority | Action Item | Practices Addressed | Estimated Effort |
|----------|-------------|---------------------|-----------------|
| 1 | **Migrate CUI from commercial M365 to M365 GCC/GCC High** | SC.L2-3.13.8, SC.L2-3.13.11, SC.L2-3.13.16, AC.L2-3.1.3 | 4–8 weeks; licensing change + migration |
| 2 | **Deploy MFA via Microsoft Entra + Conditional Access** | IA.L2-3.5.3, MA.L2-3.7.5 | 1–2 weeks (M365 E3 includes Entra ID P1 with add-on) |
| 3 | **Deploy Microsoft Sentinel or equivalent SIEM** | AU.L2-3.3.1–3.3.9, SI.L2-3.14.6, SI.L2-3.14.7 | 4–8 weeks; requires GCC migration first |
| 4 | **Enable FIPS mode on all Windows endpoints via Intune** | SC.L2-3.13.11, IA.L2-3.5.10 | 1–2 weeks |
| 5 | **Switch to credentialed, monthly Nessus scans** | RA.L2-3.11.2 | 1 week configuration change |
| 6 | **Draft SSP and POA&M** | CA.L2-3.12.4, CA.L2-3.12.2 | 4–6 weeks |
| 7 | **Develop and deliver security awareness training** | AT.L2-3.2.1, AT.L2-3.2.2, AT.L2-3.2.3 | 2–4 weeks |
| 8 | **Draft and test Incident Response Plan** | IR.L2-3.6.1, IR.L2-3.6.2, IR.L2-3.6.3 | 2–4 weeks |
| 9 | **Implement application control (WDAC/AppLocker)** | CM.L2-3.4.8 | 4–8 weeks |
| 10 | **Document baseline configurations and enforce via Intune** | CM.L2-3.4.1, CM.L2-3.4.2 | 2–4 weeks |

---

## Recommended Remediation Timeline

| Phase | Timeframe | Focus |
|-------|-----------|-------|
| **Phase 1 — Critical Blockers** | Months 1–2 | MFA deployment; M365 GCC migration initiation; FIPS mode; IR Plan draft |
| **Phase 2 — Foundation Building** | Months 2–4 | SIEM deployment; credentialed scanning; SSP/POA&M drafting; training |
| **Phase 3 — Documentation & Hardening** | Months 3–6 | Baseline configurations; least privilege audit; application control; access reviews |
| **Phase 4 — Assessment Readiness** | Months 5–8 | Mock assessment; POA&M remediation; C3PAO engagement |

---

## Additional Regulatory Notes

1. **DFARS 252.204-7012 — Immediate Obligation**: The 72-hour DIBNET incident reporting requirement is in effect NOW, regardless of CMMC certification status. Register at dibnet.dod.mil immediately.

2. **False Claims Act Risk**: If your organization has submitted an SPRS score to date without performing a formal assessment, ensure the score accurately reflects the current state. Inflated SPRS scores expose the organization to False Claims Act liability under 31 U.S.C. § 3729.

3. **Subcontractor Flow-Down**: If you engage subcontractors who handle your CUI, DFARS 252.204-7021(c) requires you to flow CMMC requirements to them. Audit your subcontractor base.

4. **C3PAO Timeline**: Given the scope of gaps identified, a realistic timeline to C3PAO readiness is **8–12 months** from the start of remediation, assuming adequate resources and executive commitment.

---

*Assessment based on NIST SP 800-171 Rev 2, CMMC 2.0 (32 CFR Part 170), and DoD Assessment Methodology v2.2. All 110 Level 2 practices were evaluated; this report highlights practices with identified gaps based on the environment description provided. A complete assessment requires review of all 110 practices with documentary, technical, and interview evidence.*

# CMMC Level 2 Gap Assessment

**Assessment Date:** 2026-04-25
**Assessed Environment:** Active Directory (80 users), Windows 10/11 via Intune, Palo Alto Firewall, Microsoft 365 E3 (commercial), SharePoint Online for CUI, Nessus quarterly unauthenticated scanning, no MFA, no SIEM

---

## Background: CMMC Level 2 and SPRS Scoring

CMMC Level 2 maps directly to NIST SP 800-171 Rev 2, which contains 110 security requirements across 14 domains. The Supplier Performance Risk System (SPRS) score starts at 110 points. Each failed practice has a defined point value (1, 3, or 5 points). A perfect score is 110; organizations must document all deficiencies in a Plan of Action and Milestones (POA&M) and report their self-assessed score to SPRS.

Point values per practice:
- 5-point practices: highest-risk controls (typically access control, identification & authentication, incident response, configuration management)
- 3-point practices: moderate-risk controls
- 1-point practices: lower-risk controls

The average defense contractor self-assessment score is approximately 50-70 out of 110.

---

## Critical Gap Analysis by Domain

### 1. Access Control (AC) — DOMAIN SCORE IMPACT: HIGH

**Gap AC.1.001 / AC.1.002 — No MFA Deployed**
- NIST 800-171 Practice: 3.5.3 — Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts
- Status: NON-COMPLIANT
- Risk: With 80 AD users and no MFA, all accounts — including privileged admin accounts — are protected only by passwords. This is one of the highest-risk gaps in the environment.
- SPRS Impact: -5 points (3.5.3 is a 5-point practice)
- Remediation: Deploy Azure AD MFA (available with M365 E3 / Entra ID P1 included). Enable Conditional Access policies requiring MFA for all users, enforce for privileged accounts as a priority. For on-premises AD, consider integrating with Azure AD via Entra ID hybrid join.

**Gap AC — Privileged Account Separation**
- NIST 800-171 Practice: 3.1.6 — Use non-privileged accounts or roles when accessing non-security functions
- Status: LIKELY NON-COMPLIANT (no evidence of enforced least privilege)
- SPRS Impact: -3 points
- Remediation: Audit AD groups; enforce separate admin accounts for privileged tasks; apply role-based access control via Intune and Group Policy.

**Gap AC — External Access Controls (CUI on SharePoint)**
- NIST 800-171 Practice: 3.1.3 — Control the flow of CUI in accordance with approved authorizations
- Status: NON-COMPLIANT — Microsoft 365 E3 (commercial, non-GCC) is not FedRAMP-authorized at the required impact level for CUI storage. SharePoint Online in commercial M365 does not meet the FedRAMP Moderate or High authorization required under DFARS 252.204-7012 and CMMC.
- SPRS Impact: -5 points (systemic impact across multiple CUI-related controls)
- Remediation: Migrate CUI workloads to Microsoft 365 GCC or GCC High. This is a critical compliance blocker — storing CUI on commercial M365 may render the entire CMMC assessment invalid.

---

### 2. Identification and Authentication (IA) — DOMAIN SCORE IMPACT: HIGH

**Gap IA — No MFA (see AC above)**
- NIST 800-171 Practice: 3.5.3
- SPRS Impact: -5 points (same practice as above, counted once)

**Gap IA — Password Policy Enforcement**
- NIST 800-171 Practice: 3.5.7 — Enforce a minimum password complexity and change when compromised
- Status: POTENTIALLY NON-COMPLIANT — AD password policies must be verified; default AD policies may not meet NIST guidelines (e.g., checking against compromised password lists)
- SPRS Impact: -3 points if not configured correctly
- Remediation: Implement Azure AD Password Protection (available in Entra ID P1, included with M365 E3) to enforce banned-password lists and complexity requirements.

**Gap IA — Authenticator Management**
- NIST 800-171 Practice: 3.5.10 — Store and transmit only cryptographically-protected passwords
- Status: REQUIRES VERIFICATION — Confirm AD is using Kerberos/NTLM hardening; confirm no legacy protocols (NTLM v1, LM hash) are enabled
- SPRS Impact: -3 points if legacy protocols are active
- Remediation: Disable LM hash storage, enforce NTLMv2 minimum, prefer Kerberos; enable smart lockout in Entra ID.

---

### 3. Audit and Accountability (AU) — DOMAIN SCORE IMPACT: HIGH

**Gap AU — No SIEM / Centralized Log Management**
- NIST 800-171 Practices: 3.3.1, 3.3.2 — Create, protect, and retain system audit logs; ensure actions of individual users can be traced
- Status: NON-COMPLIANT — Without a SIEM or centralized logging solution, audit logs from AD, endpoints, firewall, and SharePoint are siloed or unavailable for review, correlation, or forensic investigation.
- SPRS Impact: -5 points (3.3.1) + -3 points (3.3.2) = -8 points combined
- Remediation: Deploy Microsoft Sentinel (integrates natively with M365 E3, AD, Intune, and Palo Alto via connectors). Cost-effective entry point given existing M365 investment. Alternatively, deploy a SIEM such as Splunk, Elastic SIEM, or IBM QRadar. Minimum viable: centralize Windows Event Logs and Azure AD sign-in logs.

**Gap AU — Log Review Process**
- NIST 800-171 Practice: 3.3.2 — Review and update logged events
- Status: NON-COMPLIANT — No SIEM means no regular log review cadence or alerting
- SPRS Impact: Included in above (-3 points)
- Remediation: Establish formal log review procedures and alerts for critical events (failed logins, privilege escalation, CUI access).

---

### 4. Risk Assessment (RA) — DOMAIN SCORE IMPACT: MEDIUM-HIGH

**Gap RA — Unauthenticated Vulnerability Scanning**
- NIST 800-171 Practice: 3.11.2 — Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems are identified
- Status: PARTIALLY NON-COMPLIANT — Quarterly unauthenticated Nessus scans do not meet the intent of 3.11.2. Unauthenticated scans miss 60-70% of vulnerabilities (missing local privilege escalation, misconfigured services, unpatched software visible only with credentials). CMMC assessors expect authenticated scanning.
- SPRS Impact: -5 points (3.11.2 is a 5-point practice; partial credit may apply in self-assessment but assessors are likely to flag this)
- Remediation: Convert Nessus scans to authenticated mode using a dedicated service account with read-only local admin rights. Increase scan frequency to monthly at minimum. Consider continuous scanning for critical assets.

**Gap RA — Scan Frequency**
- Status: Quarterly is insufficient for a dynamic environment. NIST guidance and CMMC assessors expect more frequent scanning (monthly minimum, continuous preferred for high-value systems).
- SPRS Impact: Included in 3.11.2 above
- Remediation: Move to monthly authenticated scans; implement Intune compliance policies to enforce patch status.

---

### 5. Configuration Management (CM) — DOMAIN SCORE IMPACT: MEDIUM

**Gap CM — Baseline Configuration Documentation**
- NIST 800-171 Practice: 3.4.1 — Establish and maintain baseline configurations and inventories of organizational systems
- Status: REQUIRES VERIFICATION — Intune provides device management but a formal documented baseline configuration standard must exist
- SPRS Impact: -3 points if undocumented
- Remediation: Document baseline configuration standards (CIS Benchmarks for Windows 10/11 recommended). Enforce via Intune Configuration Profiles and Compliance Policies.

**Gap CM — Security Configuration Enforcement**
- NIST 800-171 Practice: 3.4.2 — Establish and enforce security configuration settings
- Status: POTENTIALLY NON-COMPLIANT — Intune is deployed but configuration of security settings (BitLocker, Windows Defender, firewall settings, AppLocker/WDAC) must be verified against documented baselines
- SPRS Impact: -3 points if enforcement gaps exist
- Remediation: Deploy CIS Level 1 or DISA STIG baselines via Intune; enforce BitLocker encryption; enable Windows Defender ATP (available with M365 E3 via Defender for Endpoint P1).

---

### 6. System and Communications Protection (SC) — DOMAIN SCORE IMPACT: MEDIUM

**Gap SC — CUI Encryption at Rest and In Transit**
- NIST 800-171 Practice: 3.13.10, 3.13.8 — Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI
- Status: PARTIALLY NON-COMPLIANT — Commercial M365 SharePoint Online encrypts data at rest, but without GCC/GCC High authorization, the encryption key management and data residency do not meet DoD requirements. Additionally, BitLocker enforcement on endpoints must be verified.
- SPRS Impact: -3 to -5 points depending on assessor interpretation
- Remediation: Migrate to M365 GCC/GCC High (primary remediation). Enforce BitLocker via Intune for all Windows endpoints.

**Gap SC — Network Segmentation**
- NIST 800-171 Practice: 3.13.3 — Separate user functionality from system management functionality
- Status: REQUIRES VERIFICATION — Palo Alto firewall presence is positive, but network segmentation of CUI systems, management networks, and user segments must be verified and documented.
- SPRS Impact: -3 points if not implemented
- Remediation: Review Palo Alto zone configurations; document network segmentation architecture; ensure CUI systems are in a dedicated zone with restricted access.

---

### 7. Incident Response (IR) — DOMAIN SCORE IMPACT: MEDIUM

**Gap IR — Incident Response Capability**
- NIST 800-171 Practice: 3.6.1, 3.6.2 — Establish an operational incident-handling capability; track, document, and report incidents
- Status: LIKELY NON-COMPLIANT — No SIEM means no automated alerting or incident detection capability. Incident response plan likely exists on paper but may lack operational tooling.
- SPRS Impact: -3 points (3.6.1) + -3 points (3.6.2) = -6 points if IR capability is paper-only
- Remediation: Implement Microsoft Sentinel or equivalent for detection; develop and test IR playbooks; establish a DFARS 252.204-7012-compliant cyber incident reporting process (report to DoD within 72 hours).

---

### 8. Media Protection (MP) — DOMAIN SCORE IMPACT: MEDIUM

**Gap MP — CUI on Commercial Cloud**
- NIST 800-171 Practice: 3.8.1, 3.8.2 — Protect system media containing CUI; limit access to CUI on digital media
- Status: NON-COMPLIANT — Commercial M365 (non-GCC) does not provide the required government cloud boundary for CUI. This compounds the SharePoint Online gap.
- SPRS Impact: -3 points (partially overlaps with AC and SC gaps)

---

## Summary: SPRS Score Impact Estimate

| Domain | Practice | Gap Description | Point Value | Status |
|--------|----------|-----------------|-------------|--------|
| IA/AC | 3.5.3 | No MFA deployed | -5 | Non-Compliant |
| AU | 3.3.1 | No centralized logging/SIEM | -5 | Non-Compliant |
| AU | 3.3.2 | No log review process | -3 | Non-Compliant |
| RA | 3.11.2 | Unauthenticated/quarterly scanning only | -5 | Partial |
| AC | 3.1.3 | CUI on commercial M365 (not GCC) | -5 | Non-Compliant |
| IR | 3.6.1 | Insufficient IR operational capability | -3 | Likely Non-Compliant |
| IR | 3.6.2 | Incident tracking/reporting gaps | -3 | Likely Non-Compliant |
| AC | 3.1.6 | Insufficient least privilege enforcement | -3 | Likely Non-Compliant |
| CM | 3.4.1 | No documented baseline configurations | -3 | Likely Non-Compliant |
| CM | 3.4.2 | Unverified security config enforcement | -3 | Partial |
| IA | 3.5.7 | Password policy compliance uncertain | -3 | Requires Verification |
| SC | 3.13.8 | CUI encryption / GCC boundary issue | -3 | Non-Compliant |
| SC | 3.13.3 | Network segmentation unverified | -3 | Requires Verification |

**Estimated SPRS Score Deductions from Identified Gaps: -47 points**

**Estimated SPRS Score: 110 - 47 = ~63 out of 110**

Note: This estimate covers only the explicitly identified gaps. A full assessment would likely identify additional deficiencies, particularly in:
- System and Information Integrity (SI) — patch management cadence, malware protection
- Personnel Security (PS) — screening, termination procedures
- Physical Protection (PE) — physical access controls to systems storing CUI
- Awareness and Training (AT) — security awareness training documentation

A realistic SPRS score for this environment is likely in the range of **40-65**, depending on undocumented controls and additional gaps discovered in a full assessment.

---

## Priority Remediation Roadmap

### Immediate (0-30 days) — Critical Risk Reduction
1. **Enable MFA for all users** via Entra ID Conditional Access (M365 E3 includes Entra ID P1 which provides MFA and Conditional Access at no additional cost). Start with privileged accounts.
2. **Initiate M365 GCC migration planning** — storing CUI on commercial M365 is a fundamental compliance blocker. Begin procurement/licensing discussions immediately.
3. **Enable authenticated Nessus scanning** — convert scans to credentialed mode and remediate critical/high findings within 30 days.

### Short-term (30-90 days) — SIEM and Visibility
4. **Deploy Microsoft Sentinel** or equivalent SIEM. Connect data sources: Azure AD, M365 Defender, Windows Security Events, Palo Alto (via Syslog/CEF connector). Enable out-of-box analytics rules.
5. **Document and enforce endpoint baselines** via Intune — CIS Level 1 for Windows 10/11, BitLocker enforcement, Defender configuration.
6. **Develop and test Incident Response Plan** with specific playbooks for CUI incidents and DFARS 72-hour reporting.

### Medium-term (90-180 days) — Architecture and Process
7. **Complete M365 GCC migration** for all CUI workloads.
8. **Implement privileged access management** — separate admin accounts, Privileged Identity Management (PIM) in Entra ID P2 if budget allows.
9. **Conduct formal NIST 800-171 self-assessment** against all 110 practices, update SPRS score in supplier portal.
10. **Increase vulnerability scan frequency** to monthly; implement Intune compliance policies for patch management.

### Long-term (180+ days) — CMMC Level 2 Assessment Readiness
11. **Engage a C3PAO** (Certified Third-Party Assessment Organization) for pre-assessment review.
12. **Complete System Security Plan (SSP)** documenting all 110 practices.
13. **Address all POA&M items** or accept risk formally.
14. **Submit for CMMC Level 2 Third-Party Assessment** (required for contracts with sensitive CUI per DFARS 252.204-7021).

---

## Key Compliance Blocker: M365 Commercial vs. GCC

This deserves special emphasis. DFARS 252.204-7012 requires cloud service providers handling covered defense information (CDI/CUI) to meet FedRAMP Moderate authorization at minimum. Microsoft 365 commercial (E3) is NOT authorized for CUI — only M365 GCC and GCC High meet this requirement. M365 GCC High is required for some controlled unclassified information categories (ITAR, Export Controlled).

Continuing to store CUI on commercial SharePoint Online exposes the organization to:
- Contract termination for DFARS non-compliance
- False Claims Act liability
- Automatic CMMC assessment failure
- SPRS score invalidation

This single gap affects multiple NIST 800-171 practices simultaneously (3.1.3, 3.13.8, 3.8.1, 3.8.2, and potentially 3.12.1 through systemic risk).

---

*Assessment prepared based on NIST SP 800-171 Rev 2, CMMC Model v2.0, and DFARS 252.204-7012/7021 requirements. Point values reference the DoD CMMC/SPRS scoring methodology. This is a self-assessment gap analysis and does not constitute a formal C3PAO assessment.*

# System Security Plan (SSP) — Practice Section

---

## Practice: IA.L2-3.5.3 — Multifactor Authentication

| Field | Value |
|-------|-------|
| **Practice ID** | IA.L2-3.5.3 |
| **Domain** | IA — Identification and Authentication |
| **CMMC Level** | Level 2 (Advanced) |
| **NIST SP 800-171 Rev 2 Reference** | 3.5.3 |
| **Implementation Status** | MET |

---

### 1. Requirement Statement

> Use multifactor authentication (MFA) for local and network access to privileged accounts and for network access to non-privileged accounts.

This practice requires that all user accounts — privileged and non-privileged alike — authenticate using at least two distinct factors before being granted access to organizational systems or CUI. Local access to privileged accounts and all network access (remote or otherwise) are within scope.

---

### 2. Implementation Description

The organization has fully implemented multifactor authentication across all in-scope systems using **Azure Active Directory (Azure AD)** as the centralized identity provider and **Microsoft Authenticator** as the primary MFA method. MFA enforcement is achieved through **Azure AD Conditional Access policies** that apply organization-wide.

#### 2.1 MFA Scope

| Access Type | Account Type | MFA Required | Enforcement Mechanism |
|-------------|-------------|--------------|----------------------|
| Network access (cloud and on-premises) | Privileged (Global Admins, IT Admins, Security Admins) | Yes | Azure AD Conditional Access — "Require MFA for All Admins" policy |
| Network access (cloud and on-premises) | Non-privileged (standard users, end users) | Yes | Azure AD Conditional Access — "Require MFA for All Users" policy |
| Local access to privileged accounts | Privileged | Yes | Azure AD joined device + Windows Hello for Business (PIN/biometric as second factor) |
| Remote access (VPN, RDP, remote management) | All users | Yes | Azure AD Conditional Access — MFA required as grant control for remote session initiation |

#### 2.2 Authentication Methods

Microsoft Authenticator is the primary MFA method enforced for all users. Supported second-factor methods in order of organizational preference are:

1. **Microsoft Authenticator push notification** (primary) — time-based one-time passcode (TOTP) or number-matching push approval
2. **Windows Hello for Business** — FIPS-compatible biometric or PIN tied to a hardware TPM chip, used for local device authentication
3. **FIDO2 security keys** — hardware security keys (e.g., YubiKey) permitted for privileged administrator accounts
4. **SMS/voice OTP** — explicitly **disabled** via Authentication Methods policy; not permitted as a valid second factor due to known SIM-swapping vulnerabilities and NIST SP 800-63B guidance

#### 2.3 Conditional Access Policy Configuration

MFA enforcement is managed through the following Azure AD Conditional Access policies:

| Policy Name | Users in Scope | Cloud Apps in Scope | Grant Control |
|-------------|---------------|---------------------|---------------|
| CA-001: Require MFA — All Users | All users (including guests with CUI access) | All cloud apps | Require MFA |
| CA-002: Require MFA — Privileged Roles | Global Admins, Privileged Role Admins, Security Admins, Exchange Admins | All cloud apps | Require MFA + Compliant Device |
| CA-003: Require MFA — Remote Access | All users | Microsoft 365, Azure Management, on-premises apps via App Proxy | Require MFA |
| CA-004: Block Legacy Authentication | All users | All cloud apps | Block (legacy auth protocols do not support MFA) |

All Conditional Access policies are set to **"Report-only"** mode during initial deployment and reviewed before enforcing. Production policies are in **"On"** (enforce) mode.

Legacy authentication protocols (IMAP, POP3, SMTP AUTH, Basic Auth) are blocked via CA-004 to prevent MFA bypass.

#### 2.4 Privileged Account-Specific Controls

Privileged accounts (those with Azure AD directory roles or elevated permissions to CUI systems) are subject to additional controls beyond standard user MFA:

- **Privileged Identity Management (PIM)**: All privileged roles are configured as eligible (not permanent). Administrators must activate roles on demand with MFA confirmation and business justification.
- **Compliant device requirement**: Conditional Access policy CA-002 requires privileged users to authenticate from an Intune-enrolled, compliant device in addition to completing MFA.
- **Break-glass accounts**: Two emergency access accounts are maintained per Microsoft guidance. These accounts are excluded from Conditional Access policies, secured with hardware FIDO2 keys, monitored with Azure AD audit alerts, and documented in the Break-Glass Account Procedure.

#### 2.5 On-Premises and Hybrid Systems

For on-premises systems that are Azure AD-joined or hybrid-joined:

- **Azure AD Connect** synchronizes on-premises Active Directory accounts to Azure AD, enabling Conditional Access and MFA for hybrid authentication flows.
- **Azure AD Application Proxy** is used to publish on-premises legacy applications. MFA is enforced at the Application Proxy pre-authentication layer before any session is established with the on-premises system.
- **Windows Hello for Business (Hybrid Key Trust)** provides MFA-equivalent authentication for local Windows device logon, backed by the device's TPM and tied to the user's Azure AD identity.

---

### 3. Responsible Roles

| Role | Responsibility |
|------|---------------|
| **Information System Security Officer (ISSO)** | Owns the MFA policy, reviews Conditional Access configurations quarterly, approves exceptions, and reports MFA compliance metrics to senior leadership. |
| **Identity and Access Management (IAM) Administrator** | Configures and maintains Azure AD Conditional Access policies, Authentication Methods policies, and PIM settings. Reviews MFA registration reports and remediates gaps. |
| **IT Systems Administrator** | Manages Azure AD Connect, on-premises hybrid join configurations, and device compliance policies in Microsoft Intune. |
| **Help Desk / IT Support** | Processes MFA reset requests following the MFA Self-Service Reset and Help Desk Verification Procedure. Escalates suspected account compromise to the ISSO. |
| **End Users / All Personnel** | Required to register at least two MFA methods within 14 days of account provisioning. Must not share authentication credentials or approve unexpected MFA prompts. |
| **Security Operations Center (SOC)** | Monitors Azure AD Sign-in Logs and Identity Protection alerts for MFA bypass attempts, impossible travel detections, and sign-in risk events. |

---

### 4. Evidence Artifacts

The following artifacts serve as evidence of IA.L2-3.5.3 implementation and should be collected and maintained in the organization's evidence repository:

| Artifact | Description | Location / Owner | Review Frequency |
|----------|-------------|-----------------|-----------------|
| **MFA Policy** | Written organizational policy requiring MFA for all system access, including scope, approved methods, and exception handling. | Policy Management System / ISSO | Annual |
| **Conditional Access Policy Exports** | JSON or screenshot exports of all Conditional Access policies from the Azure AD portal, showing policy scope, conditions, and grant controls. | Azure AD Admin Center / IAM Admin | Quarterly |
| **Authentication Methods Policy Screenshot** | Screenshot from Azure AD > Security > Authentication Methods showing Microsoft Authenticator enabled and SMS/voice disabled. | Azure AD Admin Center / IAM Admin | Quarterly |
| **MFA Registration Report** | Azure AD report showing percentage of users registered for MFA; any accounts not yet registered. | Azure AD > Reports > Authentication Methods / IAM Admin | Monthly |
| **Sign-in Logs (MFA Events)** | Filtered Azure AD sign-in logs demonstrating MFA challenges and completions for all user account types. | Azure Monitor / Log Analytics / SOC | On-demand / 90-day retention minimum |
| **PIM Configuration Screenshots** | Evidence that privileged roles are configured as eligible (not permanent) and require MFA activation. | Azure AD PIM / IAM Admin | Quarterly |
| **Conditional Access Named Locations / Exclusions** | Documentation of any Conditional Access exclusions (e.g., break-glass accounts), with justification and compensating controls. | ISSO / IAM Admin | Semi-annual |
| **Break-Glass Account Procedure** | Documented procedure for emergency access accounts excluded from MFA Conditional Access policy, including monitoring and periodic access review. | Policy Management System / ISSO | Annual |
| **Intune Device Compliance Policy** | Evidence that compliant-device requirements are enforced for privileged role access. | Microsoft Intune / IT Admin | Quarterly |
| **MFA User Awareness Training Records** | Training completion records showing users have been trained on MFA enrollment, recognizing MFA fatigue attacks, and reporting suspicious prompts. | LMS / AT.L2-3.2.1 evidence package | Annual |

---

### 5. System Interconnections Relevant to MFA

The following system interconnections are in scope for IA.L2-3.5.3 and rely on or interact with the Azure AD MFA enforcement infrastructure:

| Connected System | Connection Type | MFA Enforcement Method | Notes |
|-----------------|----------------|----------------------|-------|
| **Microsoft 365 (Exchange Online, SharePoint, Teams)** | Cloud SaaS — Azure AD OAuth/OIDC | Conditional Access CA-001 and CA-003 | Primary platform for CUI processing and storage; all access gated by MFA. |
| **Azure Government / Azure Commercial** | Cloud IaaS/PaaS — Azure AD | Conditional Access CA-002 (admin) and CA-001 (users) | Azure subscriptions used for CUI workloads must be in scope. If CUI is stored in Azure, confirm FedRAMP Moderate authorization status. |
| **On-Premises Active Directory Domain** | Hybrid — Azure AD Connect (password hash sync or pass-through auth) | MFA enforced via Azure AD Conditional Access at pre-authentication | Domain controllers are in scope for the CUI boundary; hybrid join ensures MFA is enforced before on-premises resource access. |
| **Corporate VPN** | Network access — RADIUS / Azure AD NPS Extension | NPS Extension triggers Azure AD MFA challenge for RADIUS authentication | VPN is the primary remote access path for on-premises CUI systems. NPS Extension must be deployed and verified. |
| **On-Premises Applications (via Azure AD App Proxy)** | Hybrid — Azure AD Application Proxy | Pre-authentication MFA enforced by App Proxy before session forwarding | Legacy web applications that cannot natively integrate with MFA are published through App Proxy to enforce MFA. |
| **Microsoft Intune (MDM/MAM)** | Cloud SaaS — Azure AD | Device enrollment requires Azure AD authentication with MFA | Device compliance status is used as a Conditional Access signal for privileged account access (CA-002). |
| **Azure Active Directory Identity Protection** | Internal — Azure AD | Risk-based Conditional Access triggers step-up MFA or blocks sign-in based on real-time risk score | Integration enhances MFA by dynamically requiring MFA when risky sign-in conditions are detected. |
| **Microsoft Sentinel / Azure Monitor** | Log aggregation — Azure AD Diagnostic Settings | N/A (monitoring, not authentication) | Sign-in logs with MFA event details are forwarded to Sentinel/Log Analytics for SOC monitoring and audit log retention (AU.L2-3.3.1). |

---

### 6. Related Practices and Dependencies

| Practice ID | Relationship |
|-------------|-------------|
| **IA.L1-3.5.1** | Foundational — all users and devices must be identified before MFA can be applied. |
| **IA.L1-3.5.2** | Foundational — identity verification is the first factor; MFA adds the second. |
| **IA.L2-3.5.4** | Replay-resistant authentication — Microsoft Authenticator number-matching and FIDO2 keys satisfy this requirement alongside MFA. |
| **AC.L2-3.1.12** | Remote access monitoring — MFA is enforced at the point of remote session initiation; Conditional Access logs provide session monitoring evidence. |
| **AC.L2-3.1.5** | Least privilege — PIM for privileged role activation complements MFA by limiting standing privileged access. |
| **MA.L2-3.7.5** | Remote maintenance sessions also require MFA; covered by the same Conditional Access policies. |
| **AU.L2-3.3.1** | Azure AD Sign-in Logs provide the audit trail for MFA events and must be retained per the organization's log retention policy. |
| **AT.L2-3.2.1** | Users must be trained to recognize and report MFA fatigue attacks (unsolicited push notifications). |

---

### 7. Exceptions and Special Circumstances

| Exception | Justification | Compensating Controls | Approval Authority | Review Date |
|-----------|--------------|----------------------|-------------------|-------------|
| Break-glass emergency accounts (2 accounts) | Required for emergency access if Azure AD becomes unavailable; excluded from CA policies per Microsoft guidance. | Hardware FIDO2 keys stored in physical safe; accounts monitored with Azure Sentinel alerts on any sign-in activity; quarterly access review. | ISSO + CIO | Semi-annual |
| Service accounts / non-interactive identities | Service accounts do not support interactive MFA flows. | Managed Identities (no credentials) or certificate-based authentication used wherever possible. Service accounts are restricted to specific IP ranges and resource scopes. Password-based service accounts are reviewed quarterly and use randomly generated 64-character passwords. | IAM Admin + ISSO | Quarterly |

---

### 8. Assessment Notes

This practice is identified as a **high-priority** control and one of the **most commonly failed practices** in CMMC Level 2 assessments. Assessors (C3PAO) will specifically verify:

1. That MFA is enforced for **all** users, not only administrators.
2. That **legacy authentication is blocked** — any Conditional Access exclusion that permits Basic Auth or legacy protocols represents a gap.
3. That MFA is required for **local privileged access**, not only network/remote access — Windows Hello for Business or equivalent satisfies this requirement.
4. That **service account exceptions are documented** with compensating controls.
5. That **MFA registration is complete** (100% or with a documented remediation plan for non-registered users).

SPRS impact if NOT MET: IA.L2-3.5.3 carries a **5-point deduction** from the SPRS score, the maximum weight for a single practice, reflecting its criticality.

---

*SSP Section prepared: 2026-04-25*
*Prepared by: Information System Security Officer (ISSO)*
*Review cycle: Annual or upon significant system change*
*Document classification: CUI — For Official Use Only*

# System Security Plan (SSP) Section
## CMMC Practice IA.L2-3.5.3 — Multifactor Authentication (MFA)

---

### 1. Practice Reference

| Field | Value |
|---|---|
| Practice ID | IA.L2-3.5.3 |
| Domain | Identification and Authentication (IA) |
| CMMC Level | Level 2 |
| Source Requirement | NIST SP 800-171 Rev 2, 3.5.3 |
| Requirement Statement | Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. |

---

### 2. Implementation Description

#### 2.1 Overview

The organization employs Azure Active Directory (Azure AD) as its centralized identity and access management (IAM) platform. Multifactor authentication is enforced for all user accounts — both privileged and non-privileged — accessing organizational systems, applications, and data. Microsoft Authenticator serves as the primary MFA application, delivering push notifications, one-time passcodes (OTP), and passwordless phone sign-in capabilities. MFA enforcement is achieved through Azure AD Conditional Access policies, which evaluate authentication context at the time of each sign-in and require a second factor before granting access.

#### 2.2 Scope of MFA Enforcement

MFA is required for all of the following access scenarios:

- **Local and network access to privileged accounts**: All accounts with administrative, elevated, or privileged roles (e.g., Global Administrator, Security Administrator, Privileged Role Administrator, system owners, IT administrators) must authenticate with MFA for every sign-in session, regardless of device, location, or network.
- **Network access to non-privileged accounts**: All standard user accounts accessing organizational resources over any network connection — including remote access, VPN, cloud services, and internal applications — are required to complete MFA at authentication.
- **Access to Controlled Unclassified Information (CUI) systems**: Any system, application, or data repository that stores, processes, or transmits CUI is covered under MFA Conditional Access policies.
- **Access to Microsoft 365 and Azure resources**: All SaaS and IaaS services integrated with Azure AD are governed by the same Conditional Access framework.

#### 2.3 Technical Implementation

**Azure AD Conditional Access Policies**

The following Conditional Access policies are configured and active:

1. **Policy: Require MFA — All Users, All Applications**
   - Users: All users (includes privileged and non-privileged)
   - Cloud Apps: All cloud apps
   - Conditions: Any location, any device platform
   - Grant Control: Require multifactor authentication
   - Status: Enabled (Report-only mode is NOT used for CUI-scope systems)

2. **Policy: Require MFA — Privileged Roles**
   - Users: Directory roles — Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, and other privileged roles as defined in the Privileged Account Register
   - Cloud Apps: All cloud apps
   - Grant Control: Require multifactor authentication + Require compliant device (where applicable)
   - Status: Enabled

3. **Policy: Block Legacy Authentication**
   - Conditions: Client apps using legacy authentication protocols (Basic Auth, SMTP Auth, POP, IMAP)
   - Grant Control: Block
   - Rationale: Legacy authentication protocols cannot enforce MFA and represent a bypass vector; blocking is required to ensure MFA coverage is comprehensive.

**Microsoft Authenticator Configuration**

- Microsoft Authenticator is deployed as the organization's approved second factor.
- Approved authentication methods include:
  - Microsoft Authenticator push notification (primary method)
  - Time-based one-time passcode (TOTP) via Microsoft Authenticator
  - Passwordless phone sign-in (for eligible devices)
- SMS/voice OTP may be permitted only as a fallback for account recovery, subject to approval by the Identity and Access Management (IAM) team, and is not accepted as a primary MFA method for CUI access.
- Hardware FIDO2 security keys (e.g., YubiKey) are approved for privileged administrators and users requiring phishing-resistant MFA.

**Authentication Method Policies**

Authentication method policies in Azure AD are configured to:

- Enable Microsoft Authenticator for all users.
- Disable or restrict weaker methods (SMS, voice call) for standard authentication flows.
- Enforce number matching and additional context display in Authenticator push notifications to mitigate MFA fatigue attacks.

**Azure AD Identity Protection**

Azure AD Identity Protection is enabled to:

- Detect risky sign-ins and require step-up MFA or block access based on risk level.
- Generate alerts for anomalous authentication activity.
- Feed risk signals into Conditional Access for dynamic policy enforcement.

#### 2.4 Account Provisioning and MFA Registration

- All new users are required to register for MFA during the onboarding process, prior to being granted access to any organizational systems.
- MFA registration is enforced via a dedicated Conditional Access policy that redirects unregistered users to the MFA registration portal.
- The IAM team reviews MFA registration completeness on a monthly basis through Azure AD reporting.
- Users who lose access to their registered MFA device must follow the Identity Verification and Account Recovery Procedure (referenced in Section 6 — Related Documents) before MFA can be re-registered.

---

### 3. Responsible Roles

| Role | Responsibility |
|---|---|
| **System Owner** | Overall accountability for ensuring MFA is implemented and maintained across all systems within scope. Approves exceptions and reviews MFA compliance reports quarterly. |
| **Information System Security Officer (ISSO)** | Monitors MFA policy configurations, reviews audit logs for authentication failures, coordinates remediation of MFA gaps, and maintains SSP accuracy. |
| **Identity and Access Management (IAM) Team** | Owns Conditional Access policy configuration, manages authentication method policies in Azure AD, administers MFA registration workflows, processes account recovery requests, and conducts monthly MFA registration compliance reviews. |
| **IT Help Desk** | Provides first-line support for MFA issues (device lost/replaced, lockouts). Escalates account recovery to the IAM team following the Identity Verification Procedure. |
| **Security Operations Center (SOC)** | Monitors Azure AD Identity Protection alerts and sign-in risk events. Investigates and responds to MFA-related security incidents. |
| **All Users** | Required to register for MFA prior to system access, maintain their registered MFA device(s), and report lost or compromised devices immediately to the Help Desk. |
| **Microsoft (External Cloud Provider)** | Operates and maintains the Azure AD platform and Microsoft Authenticator service. Governed by the Microsoft Online Services Agreement and Data Processing Addendum. |

---

### 4. Evidence Artifacts

The following artifacts serve as evidence of implementation and are available for assessment:

| Artifact | Description | Location / Owner |
|---|---|---|
| Azure AD Conditional Access Policy Exports | JSON/screenshot exports of all active Conditional Access policies, demonstrating MFA enforcement scope, user and app targeting, and grant controls. | Azure AD Portal / IAM Team |
| Azure AD Sign-In Logs | Logs showing MFA challenge events, success/failure records, and authentication method used per sign-in. Retained for a minimum of 90 days (extended via Log Analytics Workspace or SIEM). | Azure AD / SOC |
| MFA Registration Status Report | Azure AD report showing percentage of users registered for MFA, broken down by authentication method. Generated monthly. | Azure AD / IAM Team |
| Authentication Methods Policy Configuration | Screenshots or exports of the Authentication Methods policy settings in Azure AD, showing enabled/disabled methods and targeting. | Azure AD / IAM Team |
| Legacy Authentication Block Evidence | Sign-in logs or Workbook reports confirming that legacy authentication sign-ins are being blocked. | Azure AD / IAM Team |
| Identity Protection Risk Detections Report | Report of risky sign-ins and users detected by Azure AD Identity Protection, with remediation actions taken. | Azure AD / SOC |
| Privileged Account Register | List of accounts assigned privileged roles in Azure AD, used to verify MFA enforcement scope for privileged access. | IAM Team |
| MFA Exception Log | Log of any approved temporary MFA exceptions, including justification, approver, duration, and compensating controls. | ISSO |
| User MFA Onboarding Procedure | Documented procedure for MFA registration during onboarding, including identity verification steps. | IAM Team / HR |
| Account Recovery Procedure | Documented procedure for MFA re-registration following device loss or compromise, including identity verification requirements. | IAM Team |
| Incident Response Records | Any tickets or records related to MFA bypass attempts, failures, or incidents. | SOC / Help Desk |

---

### 5. System Interconnections Relevant to MFA

The following system interconnections are relevant to the MFA implementation and must be considered when assessing coverage:

| Connected System / Service | Connection Type | MFA Applicability | Notes |
|---|---|---|---|
| **Microsoft 365 (Exchange Online, SharePoint, Teams)** | Azure AD federated SSO | Covered by Conditional Access MFA policies | All M365 workloads are registered as cloud apps in Azure AD and subject to MFA enforcement. Legacy protocols (Basic Auth) are blocked. |
| **Azure Portal and Azure Resource Manager** | Azure AD authentication | Covered; privileged MFA policy applied | Administrative access to Azure subscriptions requires MFA. Privileged Identity Management (PIM) used for just-in-time privileged role activation, which also requires MFA. |
| **On-Premises Active Directory (AD DS)** | Azure AD Connect hybrid identity | Partially covered — see notes | Hybrid joined users authenticate via Azure AD for cloud resources (MFA enforced). Pass-through authentication or federation must be configured so that on-premises interactive sign-ins also route through Azure AD MFA where technically feasible. On-premises RDP and local console access are addressed separately through Windows Hello for Business or smart card requirements. |
| **VPN Gateway (Azure VPN / Third-Party VPN)** | SAML/RADIUS integration with Azure AD | Covered if integrated with Azure AD | VPN authentication must be integrated with Azure AD (via RADIUS/NPS extension or SAML) to inherit Conditional Access MFA enforcement. If using a legacy RADIUS-only VPN, Azure AD MFA NPS Extension must be deployed. |
| **Third-Party SaaS Applications (CUI-scope)** | Azure AD federated SSO (SAML/OIDC) | Covered by Conditional Access | All CUI-scope SaaS applications must be registered in Azure AD as Enterprise Applications and scoped within the "All cloud apps" Conditional Access policy. Applications not integrated with Azure AD are out-of-scope and must be tracked as a gap. |
| **Developer and CI/CD Platforms (e.g., GitHub, Azure DevOps)** | Azure AD SSO | Covered if SSO is enforced | Organizations must enforce Azure AD SSO for developer tooling and disable native username/password authentication to ensure MFA coverage. Service accounts and managed identities used in pipelines must be reviewed separately. |
| **Service Accounts and Non-Interactive Identities** | Azure AD Workload Identities / Managed Identities | Not subject to IA.L2-3.5.3 per NIST 800-171 guidance | Service accounts that perform automated, non-interactive functions are not subject to MFA under 3.5.3. These accounts must be tightly scoped, use managed identities where possible, and be governed under the Least Privilege and Service Account Management policies. Human accounts must not be used for automated processes. |
| **Microsoft Authenticator App (Mobile)** | End-user mobile device (iOS/Android) | MFA delivery channel | Device must be enrolled in Intune (or registered in Azure AD) for Microsoft Authenticator push notifications. Device compliance policy may be required as an additional Conditional Access grant control for privileged access. |

---

### 6. Related Documents and Policies

- Identity and Access Management Policy
- Privileged Access Management Policy and Procedures
- Account Management Policy
- Identity Verification and Account Recovery Procedure
- Incident Response Plan (MFA Incident Scenarios)
- Azure AD Tenant Configuration Baseline
- NIST SP 800-171 Rev 2, Control 3.5.3
- NIST SP 800-63B, Authenticator Assurance Levels (AAL)
- CMMC Assessment Guide, Level 2, Domain IA

---

### 7. Control Effectiveness Summary

| Assessment Dimension | Status | Notes |
|---|---|---|
| MFA enforced for privileged network access | Implemented | Conditional Access policy in place; confirmed via sign-in logs. |
| MFA enforced for non-privileged network access | Implemented | All-users, all-apps policy active. |
| MFA enforced for local privileged access | Partially Implemented | On-premises local console access addressed via Windows Hello for Business; hybrid scenarios require verification. |
| Legacy authentication blocked | Implemented | Block policy active; confirmed via sign-in logs. |
| MFA registration compliance monitored | Implemented | Monthly review by IAM team. |
| Phishing-resistant MFA available for high-value accounts | Implemented | FIDO2 keys approved; number matching enabled in Authenticator. |

---

*Document prepared by: Information System Security Officer (ISSO)*
*Review cycle: Annual or upon significant system change*
*Last reviewed: 2026-04-25*

# Plan of Action & Milestones (POA&M)
## CMMC Level 2 — C3PAO Assessment Findings

**Organization**: [Organization Name]  
**Assessment Date**: April 25, 2026  
**POA&M Prepared**: April 25, 2026  
**Remediation Deadline**: October 22, 2026 (180 days from assessment date)  
**Total Practices NOT MET**: 8  
**CMMC Level**: Level 2 (Advanced)  

---

## Critical Notice

Two of the eight findings — **AU.L2-3.3.1** (Audit Logging) and **SC.L2-3.13.8** (Encryption in Transit) — are classified as **critical practices** under CMMC 2.0. Per 32 CFR Part 170 and the C3PAO assessment rules, critical practices must be remediated before conditional certification can be finalized. These must be treated as the highest-priority items and cannot remain in POA&M status at the time of certification issuance.

---

## Priority Ordering

| Priority | Practice ID | Domain | SPRS Point Deduction | Critical Practice | Rationale |
|----------|-------------|--------|---------------------|-------------------|-----------|
| 1 | SC.L2-3.13.8 | System & Comms Protection | 5 pts | YES | Encryption in transit — critical practice; conditional certification blocked until resolved |
| 2 | AU.L2-3.3.1 | Audit & Accountability | 3 pts | YES | Audit logging — critical practice; foundational for all forensic and detection capabilities |
| 3 | AU.L2-3.3.2 | Audit & Accountability | 3 pts | No | Individual user traceability — closely dependent on AU.L2-3.3.1 infrastructure |
| 4 | AC.L2-3.1.5 | Access Control | 3 pts | No | Least privilege — high SPRS impact; excessive admin rights create broad attack surface |
| 5 | CM.L2-3.4.1 | Configuration Management | 3 pts | No | Baseline configurations — foundational for CM.L2-3.4.2; must be completed first |
| 6 | CM.L2-3.4.2 | Configuration Management | 3 pts | No | Security config settings — depends on CM.L2-3.4.1 baseline completion |
| 7 | RA.L2-3.11.2 | Risk Assessment | 3 pts | No | Vulnerability scanning — enables ongoing risk visibility; feeds CM remediation |
| 8 | CA.L2-3.12.4 | Security Assessment | 3 pts | No | SSP currency — documentation requirement; lowest operational urgency |

**Estimated Total SPRS Score Deduction from These 8 Findings**: 26 points

---

## Full POA&M Table

### POA&M Item 1 — SC.L2-3.13.8 (PRIORITY 1 — CRITICAL)

| Field | Details |
|-------|---------|
| **Practice ID** | SC.L2-3.13.8 |
| **Domain** | System and Communications Protection (SC) |
| **Requirement** | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission (FIPS 140-2/3 validated). |
| **Weakness Description** | CUI is transmitted over network connections without consistent use of FIPS 140-2/3 validated cryptographic mechanisms. Legacy protocols (TLS 1.0/1.1) remain enabled on internal servers, and some application-to-application communications transmit data in plaintext or use non-FIPS cipher suites. This exposes CUI to interception during transit. |
| **Root Cause** | No formal cryptographic policy enforced at the network/application layer; legacy application dependencies have not been reviewed for encryption compliance; FIPS mode not enabled on Windows servers. |
| **Remediation Steps** | 1. Inventory all data flows involving CUI (map source/destination, protocol, encryption status). 2. Disable TLS 1.0 and TLS 1.1 on all servers and network devices. 3. Enable TLS 1.2 minimum with FIPS-validated cipher suites (AES-256-GCM, SHA-256+). 4. Enable FIPS 140-2/3 mode on all Windows servers in scope. 5. Replace or reconfigure applications using plaintext protocols (HTTP, FTP, Telnet) with encrypted equivalents (HTTPS, SFTP, SSH). 6. Validate using TLS scanning tools (e.g., Qualys SSL Labs, testssl.sh) on all in-scope endpoints. 7. Document cryptographic settings in SSP and Configuration Baseline. |
| **Milestone 1** | Week 2 (May 9, 2026): Complete CUI data flow inventory; identify all in-scope endpoints requiring encryption. |
| **Milestone 2** | Week 4 (May 23, 2026): Disable TLS 1.0/1.1 on all externally-facing servers; FIPS mode enabled on Windows servers. |
| **Milestone 3** | Week 8 (June 20, 2026): Disable TLS 1.0/1.1 on internal servers; remediate plaintext protocols on internal data flows. |
| **Milestone 4** | Week 10 (July 4, 2026): Run authenticated TLS scans confirming FIPS-validated cipher suites only; document results. |
| **Scheduled Completion** | July 4, 2026 (70 days) |
| **Resources Required** | IT Security Engineer (80 hrs); System Administrators (40 hrs); TLS scanning tools (Qualys or equivalent). |
| **Status** | Open |
| **Evidence of Closure** | TLS configuration scan reports showing only FIPS-validated cipher suites; FIPS mode registry settings export; updated cryptographic policy; updated SSP Section SC.L2-3.13.8. |

---

### POA&M Item 2 — AU.L2-3.3.1 (PRIORITY 2 — CRITICAL)

| Field | Details |
|-------|---------|
| **Practice ID** | AU.L2-3.3.1 |
| **Domain** | Audit and Accountability (AU) |
| **Requirement** | Create and retain system audit logs and records to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized activity. |
| **Weakness Description** | Audit logging is incomplete across the CUI environment. Not all CUI-touching systems forward logs to a centralized SIEM. Log retention policy has not been formally documented or technically enforced. Several servers retain logs locally with no offsite backup, creating risk of log tampering and loss. Log retention periods do not meet minimum 3-year requirement. |
| **Root Cause** | No centralized logging architecture deployed; SIEM implementation not prioritized; log retention policy existed informally but was never technically enforced or documented in the SSP. |
| **Remediation Steps** | 1. Deploy or configure a SIEM/log aggregation platform (e.g., Splunk, Microsoft Sentinel, Elastic SIEM). 2. Identify all CUI-touching assets and configure each to forward logs to the SIEM. 3. Define and document a formal log retention policy (minimum 3 years for CUI systems). 4. Configure log storage with write-once or immutable log settings to prevent tampering. 5. Define audit events to capture: logons/logoffs, privilege use, object access, policy changes, account management, system events. 6. Test log pipeline from all in-scope endpoints to confirm completeness. 7. Update SSP Section AU.L2-3.3.1 with implementation details. |
| **Milestone 1** | Week 3 (May 16, 2026): SIEM platform selected and procurement initiated; CUI asset list finalized. |
| **Milestone 2** | Week 6 (June 6, 2026): SIEM deployed; log forwarding configured for Priority 1 assets (domain controllers, CUI file servers, VPN gateways). |
| **Milestone 3** | Week 10 (July 4, 2026): All in-scope assets forwarding logs to SIEM; retention policy technically enforced. |
| **Milestone 4** | Week 12 (July 18, 2026): Audit event catalog reviewed and confirmed; log completeness verified; documentation updated. |
| **Scheduled Completion** | July 18, 2026 (84 days) |
| **Resources Required** | IT Security Engineer (120 hrs); System Administrators (60 hrs); SIEM licensing/subscription (~$15,000–$30,000/year depending on data volume); log storage capacity. |
| **Status** | Open |
| **Evidence of Closure** | SIEM dashboard screenshots showing all in-scope assets reporting; log retention configuration export; formal audit logging policy (approved); SSP Section AU.L2-3.3.1 updated. |

---

### POA&M Item 3 — AU.L2-3.3.2 (PRIORITY 3)

| Field | Details |
|-------|---------|
| **Practice ID** | AU.L2-3.3.2 |
| **Domain** | Audit and Accountability (AU) |
| **Requirement** | Ensure that the actions of individual users can be uniquely traced to those users. |
| **Weakness Description** | Shared accounts and generic service accounts are used on several systems that process CUI. Actions performed under shared credentials cannot be attributed to individual users, making forensic tracing and accountability impossible for those sessions. Additionally, some privileged administrative tasks are performed under shared "admin" accounts with no individual identity binding. |
| **Root Cause** | Legacy systems and operational convenience led to shared account use. No formal policy prohibiting shared accounts was implemented. Service accounts not integrated with identity management for accountability. |
| **Remediation Steps** | 1. Audit all accounts on in-scope systems; identify all shared or generic accounts. 2. Eliminate shared administrative accounts; provision individual named accounts for all administrators. 3. For service accounts, document the owning individual and restrict service account login rights to prevent interactive use. 4. Implement Privileged Access Management (PAM) or privileged session recording for administrative actions. 5. Configure audit logs (built on AU.L2-3.3.1 infrastructure) to capture user identity with each logged event. 6. Update account management policy to prohibit shared account use. |
| **Milestone 1** | Week 4 (May 23, 2026): Account audit complete; list of shared/generic accounts identified. |
| **Milestone 2** | Week 8 (June 20, 2026): Individual accounts provisioned for all administrators; shared admin accounts disabled. |
| **Milestone 3** | Week 12 (July 18, 2026): Service account documentation complete; PAM or session recording implemented for privileged access. |
| **Scheduled Completion** | July 18, 2026 (84 days) |
| **Resources Required** | IT Security Engineer (40 hrs); System Administrators (60 hrs); Identity/PAM tooling (if not already in place). |
| **Status** | Open |
| **Evidence of Closure** | Account audit report showing no active shared accounts; Active Directory/IAM configuration showing named accounts; PAM session recording evidence; updated account management policy. |

---

### POA&M Item 4 — AC.L2-3.1.5 (PRIORITY 4)

| Field | Details |
|-------|---------|
| **Practice ID** | AC.L2-3.1.5 |
| **Domain** | Access Control (AC) |
| **Requirement** | Employ the principle of least privilege, including for specific security functions and privileged accounts. |
| **Weakness Description** | Numerous user accounts hold administrative or elevated privileges beyond what is required for their job functions. Several standard users have local administrator rights on workstations. Domain admin membership is broader than operationally necessary. Security functions (firewall management, log access, backup operations) are not separated from standard IT admin roles. No formal privilege review or recertification process exists. |
| **Root Cause** | Privileges were historically granted based on convenience rather than documented need-to-know. No Privileged Access Management (PAM) solution or formal least-privilege policy enforced technically. No periodic access review process established. |
| **Remediation Steps** | 1. Conduct a full privilege audit across all in-scope systems (Active Directory, servers, applications, network devices). 2. Define privilege tiers: standard user, power user, local admin, domain admin, security function roles. 3. Remove local administrator rights from standard user accounts on CUI workstations. 4. Reduce Domain Admins group to the minimum required personnel; implement tiered admin model. 5. Create role-based access groups for specific security functions; remove cross-role privilege accumulation. 6. Implement a PAM solution for management of privileged accounts (e.g., CyberArk, BeyondTrust, or Microsoft PIM). 7. Establish a quarterly privilege recertification process. 8. Document least-privilege policy and update SSP. |
| **Milestone 1** | Week 4 (May 23, 2026): Privilege audit complete; excess privilege inventory documented. |
| **Milestone 2** | Week 8 (June 20, 2026): Local admin rights removed from standard users; Domain Admins group reduced. |
| **Milestone 3** | Week 12 (July 18, 2026): Role-based access groups implemented; PAM solution deployed or procured. |
| **Milestone 4** | Week 16 (August 15, 2026): Quarterly recertification process documented and first review completed. |
| **Scheduled Completion** | August 15, 2026 (112 days) |
| **Resources Required** | IT Security Engineer (60 hrs); System Administrators (80 hrs); PAM solution licensing ($10,000–$50,000 depending on scale). |
| **Status** | Open |
| **Evidence of Closure** | Privilege audit report; Active Directory group membership exports showing reduced admin membership; PAM implementation screenshots; quarterly review procedures; updated access control policy and SSP. |

---

### POA&M Item 5 — CM.L2-3.4.1 (PRIORITY 5)

| Field | Details |
|-------|---------|
| **Practice ID** | CM.L2-3.4.1 |
| **Domain** | Configuration Management (CM) |
| **Requirement** | Establish and maintain baseline configurations and inventories of organizational systems (hardware, software, firmware, and documentation). |
| **Weakness Description** | No formal baseline configuration documentation exists for in-scope systems. The hardware and software inventory is incomplete and not maintained in a system of record. Firmware versions are not tracked. No formal process exists to update baseline documentation when system changes occur. |
| **Root Cause** | Configuration management was treated as an informal IT function. No CMDB or configuration management tooling deployed. Change management process existed informally without linkage to formal baseline documentation. |
| **Remediation Steps** | 1. Deploy or designate a Configuration Management Database (CMDB) or asset inventory tool (e.g., ServiceNow, Lansweeper, or spreadsheet-based for smaller environments). 2. Conduct a full hardware and software inventory of all in-scope CUI systems. 3. Create formal baseline configuration documents for each major OS/application category (Windows Server, Windows 10/11 workstations, network devices, firewalls). Use CIS Benchmarks or DISA STIGs as baseline templates. 4. Document firmware versions for all in-scope network and security devices. 5. Establish a process to update baselines after approved changes. 6. Integrate with the change management process (CM.L2-3.4.3) and link to SSP. |
| **Milestone 1** | Week 4 (May 23, 2026): Asset inventory tool selected; hardware/software inventory scan initiated. |
| **Milestone 2** | Week 8 (June 20, 2026): Full hardware, software, and firmware inventory documented and entered into CMDB. |
| **Milestone 3** | Week 12 (July 18, 2026): Baseline configuration documents drafted for all major system types (using CIS/STIG templates). |
| **Milestone 4** | Week 14 (August 1, 2026): Baseline documents approved by management; baseline maintenance process formalized. |
| **Scheduled Completion** | August 1, 2026 (98 days) |
| **Resources Required** | IT Administrator (80 hrs); IT Security Engineer (40 hrs); CMDB/asset management tool (free to ~$5,000 depending on tooling). |
| **Status** | Open |
| **Evidence of Closure** | Complete hardware/software/firmware inventory export; approved baseline configuration documents per system type; CMDB records; configuration management policy update; updated SSP. |

---

### POA&M Item 6 — CM.L2-3.4.2 (PRIORITY 6)

| Field | Details |
|-------|---------|
| **Practice ID** | CM.L2-3.4.2 |
| **Domain** | Configuration Management (CM) |
| **Requirement** | Establish and enforce security configuration settings for IT products employed in organizational systems. |
| **Weakness Description** | Security configuration settings are not formally established, documented, or technically enforced across in-scope systems. Default or vendor configurations remain on several servers and network devices. Security hardening has been applied inconsistently without documented standards. No automated compliance checking is performed against security configuration benchmarks. |
| **Root Cause** | Dependent on CM.L2-3.4.1 baseline gap; without documented baselines, enforcing security settings was not systematically possible. No Group Policy Objects (GPOs) formally mapped to security configuration requirements. No configuration compliance scanning tool deployed. |
| **Remediation Steps** | 1. Complete CM.L2-3.4.1 baseline documentation (prerequisite). 2. Map security configuration settings to CIS Benchmark Level 1/2 or DISA STIG for each system type. 3. Implement security settings via Group Policy (Windows) or equivalent configuration management tool (Ansible, SCCM, Intune). 4. Deploy configuration compliance scanning (e.g., Tenable.sc/Nessus, CIS-CAT, or SCAP-compliant tools). 5. Remediate critical configuration deviations identified in compliance scan. 6. Establish a process for managing configuration exceptions with documented approval. 7. Update SSP with security configuration standards references. |
| **Milestone 1** | Week 8 (June 20, 2026): CM.L2-3.4.1 baselines complete (prerequisite); security configuration standards mapped to CIS/STIG. |
| **Milestone 2** | Week 12 (July 18, 2026): GPOs and configuration policies deployed for Windows systems. |
| **Milestone 3** | Week 14 (August 1, 2026): Configuration compliance scanning tool deployed; initial scan completed. |
| **Milestone 4** | Week 18 (August 29, 2026): Critical and high deviations remediated; exception process documented. |
| **Scheduled Completion** | August 29, 2026 (126 days) |
| **Resources Required** | IT Security Engineer (80 hrs); System Administrators (60 hrs); Configuration compliance scanning tool (Nessus Professional ~$3,000/yr or CIS-CAT Pro ~$1,000/yr). |
| **Status** | Open |
| **Evidence of Closure** | Configuration compliance scan reports showing acceptable deviation rates; GPO configuration exports; approved security configuration standards documentation; exception approval records; updated SSP. |

---

### POA&M Item 7 — RA.L2-3.11.2 (PRIORITY 7)

| Field | Details |
|-------|---------|
| **Practice ID** | RA.L2-3.11.2 |
| **Domain** | Risk Assessment (RA) |
| **Requirement** | Scan for vulnerabilities in organizational systems periodically and when new vulnerabilities affecting those systems are identified. |
| **Weakness Description** | Vulnerability scanning is not performed on a defined periodic schedule. When scans are performed, they are unauthenticated, which results in incomplete vulnerability discovery. Not all in-scope CUI assets are covered by existing scans. No formal process exists for triggering scans in response to critical vulnerability disclosures (e.g., CISA KEV alerts). |
| **Root Cause** | Vulnerability scanning was conducted ad hoc without a formal program. Authenticated scan credentials not configured. Asset inventory gaps (see CM.L2-3.4.1) prevented complete scan coverage. No assigned ownership for vulnerability management program. |
| **Remediation Steps** | 1. Select and deploy a vulnerability scanning platform (e.g., Tenable Nessus, Qualys, Rapid7 InsightVM). 2. Configure authenticated scan credentials for all in-scope systems (Windows, Linux, network devices). 3. Define scan scope using the completed asset inventory (CM.L2-3.4.1 output). 4. Establish scan schedule: monthly for all in-scope assets; ad-hoc scans within 72 hours of critical vulnerability disclosure. 5. Subscribe to CISA Known Exploited Vulnerabilities (KEV) catalog notifications. 6. Define vulnerability remediation SLAs tied to severity (Critical: 15 days, High: 30 days, Medium: 90 days). 7. Document vulnerability management policy and assign ownership to a named individual. 8. Update SSP Section RA.L2-3.11.2. |
| **Milestone 1** | Week 4 (May 23, 2026): Vulnerability scanning tool procured; scan credentials configured for initial target group. |
| **Milestone 2** | Week 8 (June 20, 2026): First authenticated scan completed covering all in-scope assets; initial vulnerability findings documented. |
| **Milestone 3** | Week 12 (July 18, 2026): Vulnerability management policy approved; remediation SLAs defined; CISA KEV subscription active. |
| **Milestone 4** | Week 16 (August 15, 2026): Second monthly scan completed; critical/high findings from initial scan remediated per SLA. |
| **Scheduled Completion** | August 15, 2026 (112 days) |
| **Resources Required** | IT Security Engineer (60 hrs); System Administrators (20 hrs); Vulnerability scanner licensing (Nessus Professional ~$3,000/yr or Tenable.io ~$5,000+/yr based on asset count). |
| **Status** | Open |
| **Evidence of Closure** | Authenticated vulnerability scan reports (two cycles minimum); scan coverage report showing all in-scope assets; vulnerability management policy; remediation tracking evidence; CISA KEV subscription confirmation; updated SSP. |

---

### POA&M Item 8 — CA.L2-3.12.4 (PRIORITY 8)

| Field | Details |
|-------|---------|
| **Practice ID** | CA.L2-3.12.4 |
| **Domain** | Security Assessment (CA) |
| **Requirement** | Develop, document, and periodically update system security plans (SSPs). |
| **Weakness Description** | The existing System Security Plan is outdated, incomplete, and was not reviewed or updated within the past year. Several recently added systems are not reflected in the SSP. Practice implementation statements are either missing or describe intended (rather than actual) implementations. The SSP has not been formally approved by management and does not reflect the current system boundary. |
| **Root Cause** | No formal SSP review and update cycle established. SSP was initially created for a previous contract and not maintained as systems evolved. No assigned SSP owner responsible for ongoing maintenance. |
| **Remediation Steps** | 1. Assign a named SSP owner (typically the ISSO or IT Security Manager). 2. Conduct a full review of the existing SSP against the current system boundary and all 110 Level 2 practices. 3. Update all practice implementation statements to reflect actual (not planned) implementation status. 4. Add newly scoped systems; remove decommissioned systems from scope. 5. Ensure all 8 POA&M findings are cross-referenced in the SSP with links to POA&M items. 6. Obtain formal management approval (signature) on the updated SSP. 7. Establish an annual SSP review cycle and document in the security program procedures. 8. Store SSP under version control with documented change history. |
| **Milestone 1** | Week 2 (May 9, 2026): SSP owner designated; SSP gap review initiated. |
| **Milestone 2** | Week 6 (June 6, 2026): SSP draft updated for all currently-implemented practices; system boundary section current. |
| **Milestone 3** | Week 10 (July 4, 2026): All POA&M cross-references added to SSP; draft submitted for management review. |
| **Milestone 4** | Week 12 (July 18, 2026): Management-approved SSP finalized; annual review procedure documented. |
| **Scheduled Completion** | July 18, 2026 (84 days) |
| **Resources Required** | IT Security Manager/ISSO (120 hrs); IT Administrator support (20 hrs). Minimal tooling cost (Word/SharePoint for document management). |
| **Status** | Open |
| **Evidence of Closure** | Management-signed SSP document with current date and version; SSP change log showing recent updates; annual review procedure; all 110 practice entries populated with accurate implementation statements. |

---

## Consolidated Timeline Summary

| Practice ID | Priority | Critical | Start | Completion Target | Days to Complete |
|-------------|----------|----------|-------|-------------------|-----------------|
| SC.L2-3.13.8 | 1 | YES | Apr 28, 2026 | July 4, 2026 | 70 days |
| AU.L2-3.3.1 | 2 | YES | Apr 28, 2026 | July 18, 2026 | 84 days |
| AU.L2-3.3.2 | 3 | No | May 5, 2026 | July 18, 2026 | 84 days |
| AC.L2-3.1.5 | 4 | No | May 5, 2026 | August 15, 2026 | 112 days |
| CM.L2-3.4.1 | 5 | No | May 5, 2026 | August 1, 2026 | 98 days |
| CM.L2-3.4.2 | 6 | No | May 12, 2026 | August 29, 2026 | 126 days |
| RA.L2-3.11.2 | 7 | No | May 5, 2026 | August 15, 2026 | 112 days |
| CA.L2-3.12.4 | 8 | No | Apr 28, 2026 | July 18, 2026 | 84 days |

All 8 practices targeted for completion by **August 29, 2026** — well within the 180-day remediation window of **October 22, 2026**.

---

## Resource Summary

| Resource Category | Estimated Cost/Effort |
|-------------------|-----------------------|
| IT Security Engineer time | ~480 hours total |
| System Administrator time | ~340 hours total |
| IT Security Manager/ISSO time | ~120 hours total |
| SIEM platform | $15,000–$30,000/year |
| Vulnerability scanning tool | $3,000–$5,000/year |
| PAM solution (AC.L2-3.1.5) | $10,000–$50,000 depending on scale |
| Configuration compliance tool | $1,000–$3,000/year |
| CMDB/asset management tool | $0–$5,000 depending on tooling choice |
| **Total estimated budget** | **$29,000–$93,000** |

---

## POA&M Management Procedures

1. **Monthly Reviews**: POA&M owner (ISSO/IT Security Manager) reviews all open items monthly; updates milestone completion status and notes any blockers.
2. **Escalation Path**: Overdue milestones escalate to the CISO/IT Director within 5 business days.
3. **SSP Linkage**: Each POA&M item is cross-referenced to the corresponding SSP section.
4. **Evidence Collection**: Evidence artifacts are collected at each milestone and stored in the compliance repository with version and date tracking.
5. **C3PAO Notification**: Any material change in remediation timeline for critical practices (SC.L2-3.13.8, AU.L2-3.3.1) must be communicated to the C3PAO within 10 business days.
6. **Closure Process**: POA&M items are closed only after evidence has been reviewed and approved by the ISSO and a second reviewer.
7. **SPRS Update**: SPRS score must be updated in the SPRS portal (sprs.csd.disa.mil) as each practice is remediated and closed.

---

*This POA&M was prepared in accordance with CMMC 2.0 (32 CFR Part 170), NIST SP 800-171 Rev 2, and DoD Assessment Methodology v2.2. All remediation timelines are within the 180-day conditional certification window.*

# Plan of Action and Milestones (POA&M)
## CMMC Level 2 Assessment Findings
**Organization:** [Organization Name]
**Assessment Date:** 2026-04-25
**POA&M Creation Date:** 2026-04-25
**Remediation Deadline:** 2026-10-22 (180 days)
**Assessor:** C3PAO Assessment Team

---

## Executive Summary

This POA&M documents 8 practices identified as NOT MET during the C3PAO CMMC Level 2 assessment. Findings span five domains: Audit and Accountability (AU), Configuration Management (CM), Risk Assessment (RA), Security Assessment (CA), Access Control (AC), and System and Communications Protection (SC). Remediation must be completed within 180 days to achieve CMMC Level 2 certification.

**Priority Classification:**
- **Critical (P1):** AC.L2-3.1.5, RA.L2-3.11.2, CA.L2-3.12.4
- **High (P2):** AU.L2-3.3.1, AU.L2-3.3.2, SC.L2-3.13.8
- **Medium (P3):** CM.L2-3.4.1, CM.L2-3.4.2

---

## Priority Rationale

### Critical (P1) Findings

**AC.L2-3.1.5** (Least Privilege) and **RA.L2-3.11.2** (Vulnerability Scanning) are prioritized as Critical because they represent foundational security controls. Lack of least privilege directly enables lateral movement and privilege escalation in breach scenarios. Absent vulnerability scanning means unknown exposure cannot be measured or managed.

**CA.L2-3.12.4** (System of Records / Plan of Action) is Critical because CMMC requires an active, maintained POA&M as an artifact for certification — its absence signals systemic governance failure and can block the path to certification itself.

### High (P2) Findings

**AU.L2-3.3.1** and **AU.L2-3.3.2** (audit logging and review) are High because without audit records, incident detection and forensic capability are severely degraded. **SC.L2-3.13.8** (cryptographic key management) is High due to the risk of data exposure if keys are not properly managed.

### Medium (P3) Findings

**CM.L2-3.4.1** and **CM.L2-3.4.2** (baseline configurations and security settings) are Medium because while important, they typically involve policy and tooling work that can proceed in parallel with higher-priority items without blocking other remediation tasks.

---

## POA&M Findings Detail

### Finding 1 — AU.L2-3.3.1: Audit Log Creation
| Field | Details |
|---|---|
| **Practice ID** | AU.L2-3.3.1 |
| **Practice Description** | Create and retain system audit logs and records to the extent needed to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. |
| **Finding** | Audit logging is not consistently enabled across all systems in scope. Log retention periods are undefined or not enforced. |
| **Priority** | High (P2) |
| **Risk** | Inability to detect or investigate unauthorized access or malicious activity. |
| **Remediation Actions** | 1. Inventory all in-scope systems and identify logging gaps. 2. Enable audit logging on all endpoints, servers, and network devices. 3. Define and enforce a log retention policy (minimum 90 days online, 1 year archived). 4. Deploy centralized SIEM or log aggregation solution. 5. Document logging architecture in SSP. |
| **Responsible Party** | IT Security Manager |
| **Resources Required** | SIEM licensing, storage infrastructure, staff time (~160 hours) |
| **Milestone 1** | Day 30 — Complete system inventory and logging gap analysis |
| **Milestone 2** | Day 60 — Enable logging on all in-scope systems |
| **Milestone 3** | Day 90 — SIEM deployed and log retention policy enforced |
| **Milestone 4** | Day 120 — SSP updated; evidence package prepared |
| **Estimated Completion** | Day 120 (2026-08-23) |
| **Status** | Open |

---

### Finding 2 — AU.L2-3.3.2: Audit Log Review
| Field | Details |
|---|---|
| **Practice ID** | AU.L2-3.3.2 |
| **Practice Description** | Review and update logged events. Ensure audit logs are reviewed for anomalies or inappropriate activity. |
| **Finding** | No documented process exists for periodic review of audit logs. Logs are collected but not reviewed. No alerting or anomaly detection is in place. |
| **Priority** | High (P2) |
| **Risk** | Malicious or unauthorized activity goes undetected. |
| **Remediation Actions** | 1. Develop an Audit Log Review Policy and Procedure. 2. Configure automated alerting for critical events in SIEM. 3. Assign responsibility for daily/weekly log review. 4. Document review cadence and evidence retention. 5. Train staff on log review procedures. |
| **Responsible Party** | IT Security Manager / SOC Lead |
| **Resources Required** | SIEM configuration effort, staff time (~80 hours), possible MDR/SOC vendor |
| **Milestone 1** | Day 30 — Draft Audit Log Review Policy |
| **Milestone 2** | Day 75 — SIEM alerting rules configured |
| **Milestone 3** | Day 100 — First documented log review cycle completed |
| **Milestone 4** | Day 130 — Policy approved; evidence of ongoing review collected |
| **Estimated Completion** | Day 130 (2026-09-02) |
| **Status** | Open |
| **Dependency** | Dependent on AU.L2-3.3.1 SIEM deployment |

---

### Finding 3 — CM.L2-3.4.1: Baseline Configurations
| Field | Details |
|---|---|
| **Practice ID** | CM.L2-3.4.1 |
| **Practice Description** | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. |
| **Finding** | No formal baseline configurations are documented for servers, endpoints, or network devices. No configuration management database (CMDB) or inventory exists. |
| **Priority** | Medium (P3) |
| **Risk** | Unauthorized or insecure configurations may exist undetected. Deviations cannot be identified without a defined baseline. |
| **Remediation Actions** | 1. Conduct full hardware and software inventory of in-scope systems. 2. Select and implement a CMDB or asset management tool. 3. Develop security baseline configurations (e.g., CIS Benchmarks) for each system type. 4. Document baselines in SSP and Configuration Management Plan. 5. Implement a change control process to maintain baseline integrity. |
| **Responsible Party** | IT Operations Manager |
| **Resources Required** | CMDB tool (e.g., ServiceNow, Lansweeper), staff time (~200 hours) |
| **Milestone 1** | Day 30 — Complete asset inventory |
| **Milestone 2** | Day 60 — Select CMDB tool; begin deployment |
| **Milestone 3** | Day 90 — Draft baseline configurations for all system types |
| **Milestone 4** | Day 150 — Baselines approved, documented, and applied to all systems |
| **Estimated Completion** | Day 150 (2026-09-22) |
| **Status** | Open |

---

### Finding 4 — CM.L2-3.4.2: Security Configuration Enforcement
| Field | Details |
|---|---|
| **Practice ID** | CM.L2-3.4.2 |
| **Practice Description** | Establish and enforce security configuration settings for information technology products employed in organizational systems. |
| **Finding** | Security configuration settings (e.g., CIS hardening benchmarks) are not enforced. No automated mechanism ensures configurations remain compliant. |
| **Priority** | Medium (P3) |
| **Risk** | Systems may operate with insecure default or misconfigured settings, increasing attack surface. |
| **Remediation Actions** | 1. Map baseline configurations (from CM.L2-3.4.1) to CIS Benchmark or DISA STIG standards. 2. Implement a configuration management/compliance scanning tool (e.g., Tenable.sc, Qualys, or Chef InSpec). 3. Remediate deviations from approved baselines. 4. Document exception process for any approved deviations. 5. Schedule periodic compliance scans. |
| **Responsible Party** | IT Operations Manager / Security Engineer |
| **Resources Required** | Configuration compliance tool, staff time (~120 hours) |
| **Milestone 1** | Day 60 — Identify target security configuration standards |
| **Milestone 2** | Day 90 — Deploy compliance scanning tool |
| **Milestone 3** | Day 130 — First full compliance scan completed; deviations documented |
| **Milestone 4** | Day 160 — Deviations remediated; ongoing scan schedule established |
| **Estimated Completion** | Day 160 (2026-10-02) |
| **Status** | Open |
| **Dependency** | Dependent on CM.L2-3.4.1 baseline completion |

---

### Finding 5 — RA.L2-3.11.2: Vulnerability Scanning
| Field | Details |
|---|---|
| **Practice ID** | RA.L2-3.11.2 |
| **Practice Description** | Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems are identified; remediate vulnerabilities in accordance with assessments of risk. |
| **Finding** | No vulnerability scanning program exists. Systems have not been scanned for known vulnerabilities. No remediation tracking process is in place. |
| **Priority** | Critical (P1) |
| **Risk** | Known, exploitable vulnerabilities may exist across in-scope systems. This is a fundamental gap that directly threatens CUI confidentiality and system integrity. |
| **Remediation Actions** | 1. Acquire and deploy a vulnerability scanning solution (e.g., Tenable Nessus, Qualys, or Rapid7). 2. Conduct initial authenticated scan of all in-scope systems. 3. Prioritize and remediate Critical/High vulnerabilities (CVSS 7.0+) within 30 days of identification. 4. Establish monthly scanning cadence for all systems; weekly for internet-facing. 5. Create vulnerability remediation tracking process and integrate with POA&M. 6. Document vulnerability management policy. |
| **Responsible Party** | Security Engineer / ISSO |
| **Resources Required** | Vulnerability scanner licensing (~$5,000-$30,000/year depending on scope), staff time (~100 hours initial) |
| **Milestone 1** | Day 15 — Procure vulnerability scanning tool |
| **Milestone 2** | Day 30 — Complete initial scan of all in-scope systems |
| **Milestone 3** | Day 60 — Remediate all Critical (CVSS 9.0+) findings from initial scan |
| **Milestone 4** | Day 90 — Remediate all High (CVSS 7.0-8.9) findings; monthly scan cadence established |
| **Milestone 5** | Day 120 — Vulnerability management policy documented and approved |
| **Estimated Completion** | Day 120 (2026-08-23) |
| **Status** | Open |

---

### Finding 6 — CA.L2-3.12.4: Plan of Action
| Field | Details |
|---|---|
| **Practice ID** | CA.L2-3.12.4 |
| **Practice Description** | Develop, document, and periodically update plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. |
| **Finding** | No formal POA&M process exists. Security deficiencies have not been tracked or managed. This current document is the first POA&M developed. |
| **Priority** | Critical (P1) |
| **Risk** | Without a POA&M, the organization cannot demonstrate it is managing security deficiencies, which is a direct prerequisite for CMMC certification. This finding also indicates systemic governance gaps. |
| **Remediation Actions** | 1. Formally adopt this POA&M as the organization's deficiency tracking mechanism. 2. Assign a POA&M owner (ISSO or Security Manager). 3. Establish a POA&M review cadence (monthly recommended). 4. Develop POA&M management procedure documenting creation, update, and closure processes. 5. Integrate POA&M management with risk management framework. 6. Update SSP to reference POA&M process. |
| **Responsible Party** | ISSO / Security Manager |
| **Resources Required** | Staff time (~40 hours), possible GRC tool investment |
| **Milestone 1** | Day 7 — This POA&M formally adopted and signed by leadership |
| **Milestone 2** | Day 30 — POA&M management procedure drafted |
| **Milestone 3** | Day 45 — First monthly POA&M review meeting held |
| **Milestone 4** | Day 60 — Procedure approved; SSP updated to reference POA&M |
| **Estimated Completion** | Day 60 (2026-06-24) |
| **Status** | Open |

---

### Finding 7 — AC.L2-3.1.5: Least Privilege
| Field | Details |
|---|---|
| **Practice ID** | AC.L2-3.1.5 |
| **Practice Description** | Employ the principle of least privilege, including for specific security functions and privileged accounts. |
| **Finding** | Privileged accounts are broadly assigned. Users have excessive permissions beyond what is required for their roles. No formal role-based access control (RBAC) model is documented or enforced. Administrative accounts are used for routine tasks. |
| **Priority** | Critical (P1) |
| **Risk** | Excessive privileges significantly increase the blast radius of account compromise. Insider threat risk is elevated. This is a top-ranked exploitable condition in breach scenarios. |
| **Remediation Actions** | 1. Conduct a full access rights review for all user and service accounts. 2. Document a role-based access control (RBAC) matrix defining permissions by job function. 3. Revoke unnecessary privileges; separate administrative from standard user accounts. 4. Implement Privileged Access Management (PAM) controls (dedicated admin accounts, just-in-time access). 5. Prohibit use of privileged accounts for day-to-day activity. 6. Implement quarterly access reviews. 7. Document least privilege policy. |
| **Responsible Party** | IT Security Manager / Identity and Access Management Lead |
| **Resources Required** | PAM tooling (e.g., CyberArk, BeyondTrust, or open-source), staff time (~160 hours) |
| **Milestone 1** | Day 21 — Complete access rights audit; identify over-privileged accounts |
| **Milestone 2** | Day 45 — RBAC matrix documented and approved |
| **Milestone 3** | Day 60 — Excessive privileges revoked; dedicated admin accounts created |
| **Milestone 4** | Day 90 — PAM controls implemented for all privileged accounts |
| **Milestone 5** | Day 120 — First quarterly access review completed; policy documented |
| **Estimated Completion** | Day 120 (2026-08-23) |
| **Status** | Open |

---

### Finding 8 — SC.L2-3.13.8: Cryptographic Protection in Transit
| Field | Details |
|---|---|
| **Practice ID** | SC.L2-3.13.8 |
| **Practice Description** | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. |
| **Finding** | Not all transmission paths carrying CUI use approved cryptographic protections. Some systems transmit CUI over unencrypted or weakly encrypted channels. TLS configurations may use deprecated protocols (TLS 1.0/1.1, weak cipher suites). |
| **Priority** | High (P2) |
| **Risk** | CUI transmitted over unprotected channels is vulnerable to interception. This directly violates the confidentiality requirement for CUI and could result in contract termination. |
| **Remediation Actions** | 1. Map all data flows involving CUI transmission (internal and external). 2. Identify all transmission paths lacking adequate encryption. 3. Disable TLS 1.0 and TLS 1.1; enforce TLS 1.2 minimum (TLS 1.3 preferred). 4. Review and harden cipher suite configurations on all systems. 5. Replace or configure any systems transmitting CUI without encryption. 6. Document approved cryptographic standards in SSP. 7. Scan for unencrypted transmission using network monitoring tools. |
| **Responsible Party** | Security Engineer / Network Administrator |
| **Resources Required** | TLS certificate management, staff time (~80 hours), possible network monitoring tools |
| **Milestone 1** | Day 21 — Complete CUI data flow mapping |
| **Milestone 2** | Day 45 — Identify all unprotected or weakly protected transmission paths |
| **Milestone 3** | Day 75 — Disable deprecated TLS versions; enforce minimum TLS 1.2 |
| **Milestone 4** | Day 100 — All CUI transmission paths verified as using approved encryption |
| **Milestone 5** | Day 120 — Cryptographic standards documented in SSP; scan evidence collected |
| **Estimated Completion** | Day 120 (2026-08-23) |
| **Status** | Open |

---

## Consolidated Milestone Schedule

| Day | Date | Milestone(s) |
|---|---|---|
| Day 7 | 2026-05-02 | CA.L2-3.12.4 — POA&M formally adopted by leadership |
| Day 15 | 2026-05-10 | RA.L2-3.11.2 — Vulnerability scanner procured |
| Day 21 | 2026-05-16 | AC.L2-3.1.5 — Access rights audit complete; SC.L2-3.13.8 — CUI data flow mapping complete |
| Day 30 | 2026-05-25 | AU.L2-3.3.1 — Logging gap analysis complete; CA.L2-3.12.4 — POA&M procedure drafted; CM.L2-3.4.1 — Asset inventory complete; RA.L2-3.11.2 — Initial vulnerability scan complete |
| Day 45 | 2026-06-09 | AC.L2-3.1.5 — RBAC matrix approved; CA.L2-3.12.4 — First POA&M review held; SC.L2-3.13.8 — Unprotected paths identified |
| Day 60 | 2026-06-24 | AC.L2-3.1.5 — Excessive privileges revoked; AU.L2-3.3.1 — Logging enabled on all systems; AU.L2-3.3.2 — Audit log review policy drafted; CA.L2-3.12.4 — Procedure approved, SSP updated; CM.L2-3.4.1 — CMDB deployed; CM.L2-3.4.2 — Security configuration standards identified; RA.L2-3.11.2 — Critical vulnerabilities (CVSS 9+) remediated |
| Day 75 | 2026-07-09 | AU.L2-3.3.2 — SIEM alerting configured; SC.L2-3.13.8 — TLS 1.0/1.1 disabled |
| Day 90 | 2026-07-24 | AC.L2-3.1.5 — PAM controls implemented; AU.L2-3.3.1 — SIEM deployed, retention enforced; CM.L2-3.4.1 — Baseline configurations drafted; CM.L2-3.4.2 — Compliance scanner deployed; RA.L2-3.11.2 — High vulnerabilities remediated; monthly scan cadence active |
| Day 100 | 2026-08-03 | AU.L2-3.3.2 — First documented review cycle complete; SC.L2-3.13.8 — All CUI paths verified encrypted |
| Day 120 | 2026-08-23 | AC.L2-3.1.5 — First quarterly access review; AU.L2-3.3.1 — SSP updated; RA.L2-3.11.2 — Vulnerability management policy approved; SC.L2-3.13.8 — SSP updated, evidence collected |
| Day 130 | 2026-09-02 | AU.L2-3.3.2 — Policy approved, ongoing review evidence; CM.L2-3.4.2 — First compliance scan; deviations documented |
| Day 150 | 2026-09-22 | CM.L2-3.4.1 — Baselines applied to all systems |
| Day 160 | 2026-10-02 | CM.L2-3.4.2 — Deviations remediated; ongoing scan schedule |
| Day 175 | 2026-10-17 | Final evidence review and POA&M closure verification |
| Day 180 | 2026-10-22 | **REMEDIATION DEADLINE — All findings closed or with accepted risk** |

---

## Resource Summary

| Finding | Responsible Party | Estimated Effort | Tooling Cost |
|---|---|---|---|
| AU.L2-3.3.1 | IT Security Manager | ~160 hours | SIEM ($10K-$50K/yr) |
| AU.L2-3.3.2 | IT Security Manager / SOC Lead | ~80 hours | Included in SIEM |
| CM.L2-3.4.1 | IT Operations Manager | ~200 hours | CMDB tool ($5K-$20K/yr) |
| CM.L2-3.4.2 | IT Operations / Security Engineer | ~120 hours | Config scanner ($5K-$15K/yr) |
| RA.L2-3.11.2 | Security Engineer / ISSO | ~100 hours | Vuln scanner ($5K-$30K/yr) |
| CA.L2-3.12.4 | ISSO / Security Manager | ~40 hours | GRC tool (optional) |
| AC.L2-3.1.5 | IT Security / IAM Lead | ~160 hours | PAM tool ($10K-$50K/yr) |
| SC.L2-3.13.8 | Security Engineer / Network Admin | ~80 hours | Cert management (minimal) |
| **Total** | | **~940 hours** | **~$35K-$165K/yr** |

---

## POA&M Management and Review

- **POA&M Owner:** [ISSO Name / Title]
- **Review Cadence:** Monthly (first Monday of each month)
- **Escalation Path:** ISSO -> CISO -> Senior Leadership
- **Next Review Date:** 2026-05-04
- **Evidence Repository:** [Location — e.g., SharePoint, GRC tool]

### Status Definitions
| Status | Definition |
|---|---|
| Open | Remediation not yet begun or in early planning |
| In Progress | Remediation activities underway |
| Delayed | Behind milestone schedule; requires escalation |
| Completed | Remediation actions finished; evidence collected |
| Accepted Risk | Risk formally accepted by authorizing official |

---

## Approval and Sign-Off

| Role | Name | Signature | Date |
|---|---|---|---|
| ISSO | | | |
| CISO / Security Director | | | |
| Authorizing Official | | | |

---

*This POA&M was created on 2026-04-25 in response to C3PAO CMMC Level 2 assessment findings. All milestones are subject to revision based on resource availability and emerging risk factors. Updates must be reviewed and approved by the ISSO.*

# Prime Contractor Obligations Under DFARS 252.204-7021: Subcontractor Flow-Down Analysis

## Scenario Summary

You are a prime contractor on a DoD contract containing DFARS 252.204-7021. Two subcontractors handle CUI:

- **Subcontractor A**: Stores CUI on a personal Google Drive account
- **Subcontractor B**: Holds a CMMC Level 2 self-assessment with an SPRS score of 42

---

## Part 1: DFARS 252.204-7021 Flow-Down Obligations

DFARS 252.204-7021(c) places direct legal obligations on prime contractors. As the prime, you must:

1. **Include CMMC requirements in all subcontracts** where the subcontractor processes, stores, or transmits CUI — regardless of tier. This means the CMMC requirement flows through your entire supply chain.

2. **Specify the required CMMC level** in each subcontract. Both subcontractors described above handle CUI, placing them squarely in scope for CMMC Level 2 (110 practices per NIST SP 800-171 Rev 2).

3. **Verify subcontractor certification before award** (for Level 2/3). For a C3PAO-assessed Level 2, you must confirm the certification appears in both SPRS and the Cyber AB registry. For a self-assessed Level 2, the subcontractor's SPRS score and senior official affirmation must be current.

4. **Flow-down applies to all tiers**. Sub-subcontractors are not exempt; your subcontractors must impose equivalent requirements on their own lower-tier subcontractors.

**Legal exposure**: As the prime, DoD holds you accountable for your supply chain. If a subcontractor mishandles CUI, the prime contractor may face contract termination, DFARS violations, and potential False Claims Act liability if certifications were falsely affirmed.

---

## Part 2: Subcontractor A — Personal Google Drive CUI Violation

### The Violation

Storing CUI on a personal Google Drive account is a **direct violation of DFARS 252.204-7012**, which requires that any external cloud service used to process, store, or transmit CUI must be:

- **FedRAMP Authorized at the Moderate impact level** or higher, or
- Must meet security requirements equivalent to FedRAMP Moderate as described in the DoD Cloud Computing Security Requirements Guide (SRG)

**Google Drive (personal/consumer accounts)** is **not FedRAMP Authorized**. Even Google Workspace for Government (FedRAMP Moderate) is a separate, specifically authorized offering — a personal consumer Google Drive account has no such authorization and provides no CUI safeguards.

### Key CMMC Practices Violated

The use of personal Google Drive for CUI likely violates multiple NIST SP 800-171 practices, including:

| Practice ID | Domain | Description | Why It Applies |
|-------------|--------|-------------|----------------|
| SC.L2-3.13.15 | System & Comms | Control and monitor communications at external boundaries | CUI leaving to uncontrolled external system |
| AC.L2-3.1.3 | Access Control | Control CUI flow in accordance with approved authorizations | No access controls on personal account |
| MP.L2-3.8.1 | Media Protection | Protect system media containing CUI | Cloud storage = system media |
| CM.L2-3.4.6 | Config Management | Employ principle of least functionality | Unauthorized cloud tool in use |
| SC.L2-3.13.11 | System & Comms | Employ FIPS-validated cryptography | No assurance of FIPS encryption |
| SI.L2-3.14.6 | System & Info Integrity | Monitor organizational systems for malware | No monitoring of personal account |

### Severity

This is a **critical finding**. The DoD's CMMC pitfall guidance explicitly states: "Using non-FedRAMP cloud for CUI violates DFARS 7012 enclave requirements." This is not a gray area — it is an active, ongoing violation that may constitute a reportable cyber incident depending on whether unauthorized parties could access the CUI.

---

## Part 3: Subcontractor B — SPRS Score of 42

### Interpreting the Score

The SPRS scoring scale runs from **+110** (all 110 practices fully met) to **-203** (all practices unmet). A score of **42** represents a substantial shortfall from the maximum of 110, indicating that this subcontractor has failed to implement a significant number of NIST SP 800-171 practices.

**Point gap**: 110 - 42 = **68 points of deficiencies**. Given that practices carry weights of 1–5 points each, this could represent anywhere from roughly 14 to 68+ unimplemented practices, depending on which practices are missing.

### Regulatory Status

Under DFARS 252.204-7021 and 7020:
- Submitting an SPRS score is required, and Subcontractor B has done so.
- However, a score of 42 **does not mean the subcontractor is compliant** — it means they have self-assessed and documented significant gaps.
- DoD Contracting Officers (COs) actively review SPRS scores; a score this low will attract scrutiny.
- If the contract requires a **C3PAO-assessed Level 2 certification** (not just a self-assessment), a score of 42 almost certainly means the subcontractor **cannot obtain certification** until critical gaps are remediated — particularly the critical practices (AC.L2-3.1.3, IA.L2-3.5.3, SC.L2-3.13.8, SC.L2-3.13.11, SI.L2-3.14.6) which cannot have POA&M items at time of certification.

### POA&M Requirement

A subcontractor with a score this low should have a **Plan of Action & Milestones (POA&M)** documenting all gaps. The prime contractor should:
- Obtain and review the subcontractor's current POA&M
- Verify milestones are realistic and on track
- Understand which specific practices are unmet (especially the 7 critical practices that block certification)

---

## Part 4: Immediate Steps — Priority Action Plan

### Step 1: Quarantine CUI on Google Drive (Subcontractor A) — Within 24 Hours

- **Immediately notify Subcontractor A** in writing to cease all use of personal Google Drive for CUI.
- Direct Subcontractor A to **identify, enumerate, and inventory all CUI stored on the personal Google Drive account**.
- Instruct Subcontractor A to **migrate CUI to a FedRAMP Moderate-authorized environment** immediately (e.g., Microsoft 365 GCC High, Google Workspace for Government — FedRAMP Moderate authorized, or an equivalent DoD-approved enclave).
- **Delete or purge** all CUI from the personal Google Drive once migration is confirmed.
- Issue a formal **cure notice** or **show cause notice** to Subcontractor A per your subcontract terms.

### Step 2: Assess Whether a Cyber Incident Must Be Reported — Within 24–48 Hours

Determine whether the Google Drive exposure constitutes a **reportable cyber incident** under DFARS 252.204-7012:
- Was the personal Google Drive account accessible to unauthorized individuals (e.g., personal account shared with family, set to public, or the account was compromised)?
- Was the CUI potentially exfiltrated or accessed by unauthorized parties?

If a reportable incident occurred, **you (the prime) must report to DIBNET within 72 hours** of discovery at dibnet.dod.mil. Do not delay while awaiting information from the subcontractor — report what is known and update as more information becomes available.

You must also **notify your Contracting Officer (CO)** of the situation, even if the incident threshold is unclear.

### Step 3: Obtain Subcontractor A's Remediation Plan — Within 48–72 Hours

- Require Subcontractor A to submit a written **remediation plan** with specific milestones showing how they will establish a FedRAMP Moderate-compliant CUI handling environment.
- Set a hard deadline for full remediation (recommend 30 days maximum given the severity).
- If Subcontractor A cannot demonstrate a credible path to compliance, consider **suspending their access to CUI** and evaluating replacement options.

### Step 4: Review Subcontractor B's POA&M and SPRS Score — Within 1 Week

- Request Subcontractor B's **complete SSP and current POA&M** in writing.
- Verify that the SPRS score of 42 in SPRS matches their self-assessment documentation.
- **Map which of the 7 critical practices** (AC.L2-3.1.3, IA.L2-3.5.3, SC.L2-3.13.8, SC.L2-3.13.11, SI.L2-3.14.6, AU.L2-3.3.1, IR.L2-3.6.1) are unmet — if any critical practices are unimplemented, the subcontractor cannot achieve Level 2 C3PAO certification until they are fully remediated.
- Establish **quarterly review checkpoints** to track remediation progress.

### Step 5: Evaluate Contract Performance Risk — Within 1–2 Weeks

- Determine if your DoD contract requires **Level 2 C3PAO certification** (not just self-assessment) for subcontractors. If so, Subcontractor B with a score of 42 likely cannot currently perform contract work involving CUI lawfully.
- Consult your contracts/legal team about whether either subcontractor's current status constitutes a **material breach** of your subcontract.
- Consider whether to **suspend CUI access** for Subcontractor B pending a clear remediation timeline toward certification-readiness.

### Step 6: Update Your Supply Chain Security Program Documentation — Within 30 Days

- Document the findings and corrective actions taken for both subcontractors in your **supply chain risk management records**.
- Update your **prime contractor CUI flow mapping** to reflect actual CUI handling at each subcontractor.
- Ensure your subcontracts (and your subcontractors' subcontracts) include the required DFARS 252.204-7021 flow-down clause language.
- Conduct a review of all other subcontractors handling CUI to identify any similar issues.

---

## Summary Table: Violations and Required Actions

| Issue | Regulation Violated | Severity | Immediate Action |
|-------|---------------------|----------|------------------|
| Google Drive CUI storage (Sub A) | DFARS 252.204-7012 (non-FedRAMP cloud) | Critical — Active Violation | Cease use immediately; migrate CUI; assess incident reporting obligation |
| Google Drive CUI storage (Sub A) | NIST SP 800-171 (multiple practices) | Critical | Require FedRAMP-compliant environment within 30 days |
| SPRS score of 42 (Sub B) | DFARS 252.204-7021 (CMMC requirement) | High — Significant compliance gap | Obtain POA&M; assess critical practices; impose milestone tracking |
| Prime flow-down gap (both) | DFARS 252.204-7021(c) | High | Issue cure notices; update subcontracts; document corrective actions |

---

## Regulatory Reference Summary

| Document | Relevance to This Scenario |
|----------|---------------------------|
| DFARS 252.204-7012 | Prohibits non-FedRAMP cloud for CUI; requires 72-hr DIBNET incident reporting |
| DFARS 252.204-7020 | Requires SPRS score submission; DoD COs review scores |
| DFARS 252.204-7021 | Requires CMMC certification; mandates prime-to-sub flow-down for CUI handling |
| 32 CFR Part 170 | CMMC 2.0 final rule (effective December 16, 2024) |
| NIST SP 800-171 Rev 2 | 110 CUI protection requirements — basis for SPRS scoring |
| DoD Assessment Methodology v2.2 | Governs SPRS score calculation (110 starting score, deductions per unmet practice) |

# DFARS 252.204-7021 Obligations for Subcontractors Handling CUI

**Date:** 2026-04-25
**Context:** Prime contractor with two subcontractors handling CUI under a DoD contract

---

## Overview of DFARS 252.204-7021 Flowdown Requirements

DFARS 252.204-7021 ("Cybersecurity Maturity Model Certification Requirements") mandates that prime contractors flow down CMMC requirements to subcontractors at all tiers that will process, store, or transmit Covered Unclassified Information (CUI) or that provide security protection for such systems. The required CMMC level flowed down must be the same level specified in the prime contract, or as appropriate to the information handled by the subcontractor.

Key obligations under DFARS 252.204-7021(c) for prime contractors:

1. **Flow down the CMMC requirement** to all subcontractors (at any tier) that will handle CUI or provide security protection for CUI systems.
2. **Verify that subcontractors have a current and valid CMMC certificate or conditional certificate** at the required level before awarding a subcontract or task/delivery order, and ensure they maintain that certification throughout performance.
3. **Not award a subcontract** or task/delivery order to a subcontractor required to have a CMMC certification unless the subcontractor has a current CMMC certificate (or conditional CMMC certificate, as applicable).
4. **Report to the Contracting Officer** if a subcontractor's CMMC certification lapses or is revoked during contract performance.

---

## Subcontractor 1: Storing CUI on a Personal Google Drive

### Problem Assessment

This is a **critical and immediate violation** on multiple levels:

- **CMMC/NIST SP 800-171 violation:** NIST SP 800-171 (the technical standard underlying CMMC Level 2) requires that CUI be stored only in authorized systems with appropriate access controls, encryption, and audit logging. A personal Google Drive is not a Federal Risk and Authorization Management Program (FedRAMP)-authorized environment configured for CUI, and is almost certainly not operated under a System Security Plan (SSP).
- **Applicable controls violated include at minimum:**
  - 3.1.1 – Limit system access to authorized users
  - 3.1.3 – Control the flow of CUI
  - 3.13.8 – Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission
  - 3.13.16 – Protect the confidentiality of CUI at rest
  - 3.1.22 – Control CUI posted or processed on publicly accessible systems
- **DFARS 252.204-7012 spillage risk:** If CUI has been exposed to an unauthorized system, there may be a reportable cyber incident obligation under DFARS 252.204-7012 within 72 hours.
- **Contract risk:** The subcontractor almost certainly does not have a valid CMMC Level 2 certification covering this practice.

### Your Obligations as Prime Contractor

Under DFARS 252.204-7021:

1. You must not continue to allow this subcontractor to handle CUI under current conditions.
2. You are obligated to ensure the subcontractor has a valid CMMC certification covering their actual environment and practices — which they do not have if CUI is stored on a personal Google Drive.
3. You may be liable to the Contracting Officer if you knowingly allow a non-compliant subcontractor to continue handling CUI.

### Immediate Steps

1. **Issue a stop-work directive** to the subcontractor for any further processing, storage, or transmission of CUI until the situation is remediated.
2. **Conduct a data spillage assessment:** Determine what CUI was stored, for how long, and who may have had access to the personal Google Drive account.
3. **Report to your Contracting Officer** as required under DFARS 252.204-7012 if the exposure constitutes a reportable cyber incident (unauthorized access or potential access to CUI on a non-authorized system).
4. **Notify the subcontractor in writing** of the violation, citing contractual requirements (DFARS 252.204-7021 and 252.204-7012 flowdown clauses).
5. **Require the subcontractor to provide a Corrective Action Plan (CAP)** with a timeline to migrate CUI to an authorized system (e.g., a FedRAMP Moderate or equivalent environment with proper configuration).
6. **Review your subcontract:** Determine whether this violation constitutes grounds for cure notice, termination for default, or other remedies.
7. **Document everything** — your notifications, the subcontractor's responses, and steps taken — to demonstrate your own due diligence to the Contracting Officer.

---

## Subcontractor 2: CMMC Level 2 Self-Assessment Score of 42 in SPRS

### Problem Assessment

This situation is serious but somewhat different in character:

- **SPRS score of 42 is far below the required threshold:** For CMMC Level 2, a contractor must meet all 110 NIST SP 800-171 practices. The SPRS score is calculated starting at 110 and deducting points for each unimplemented practice. A score of 42 means the subcontractor has significant unimplemented controls — roughly equivalent to approximately 68 points of deductions, indicating a very large number of missing or non-compliant security practices.
- **Self-assessment vs. third-party assessment:** A self-assessment score of 42 is particularly concerning because it is self-reported and not validated by a C3PAO (CMMC Third-Party Assessment Organization). The actual compliance posture could be worse.
- **CMMC Level 2 certification requirement:** Under DFARS 252.204-7021, for contracts requiring CMMC Level 2, subcontractors that handle CUI must have either:
  - A CMMC Level 2 certification from a C3PAO (for "critical" programs), or
  - A valid CMMC Level 2 self-assessment submitted to SPRS with an affirmation (for non-critical programs).
  - In either case, the score must reflect full implementation (score of 110, or all practices implemented with any gaps covered by a Plan of Action and Milestones (POA&M) within permitted thresholds).
- **A score of 42 does not meet the minimum threshold** for a valid self-assessment under CMMC Level 2 requirements, even under the most permissive interpretation.

### Key Distinction: POA&M Eligibility

DoD has established that certain practices may be on a POA&M (Plan of Action and Milestones) rather than fully implemented at time of contract award, but:

- POA&M practices are limited to specific lower-weighted controls.
- High-weighted practices (those deducting 5 points each) must be fully implemented.
- A score of 42 strongly suggests that many high-weighted practices are not implemented, which would preclude a compliant self-assessment.

### Your Obligations as Prime Contractor

Under DFARS 252.204-7021:

1. You must not award or continue a subcontract to a subcontractor that does not have a current and valid CMMC Level 2 self-assessment or certification on file in SPRS that meets requirements.
2. A self-assessment score of 42 does not constitute a valid, passing CMMC Level 2 assessment — you cannot treat this subcontractor as compliant.
3. You are obligated to notify your Contracting Officer if the subcontractor's compliance status is inadequate.

### Immediate Steps

1. **Verify the SPRS record:** Log into SPRS and confirm the subcontractor's current score, assessment date, and whether an affirmation has been submitted. Confirm whether a POA&M is on file and what its closure date is.
2. **Assess the gap:** Request the subcontractor's current System Security Plan (SSP) and POA&M to understand which of the 110 NIST SP 800-171 controls are not implemented and what the remediation timeline is.
3. **Notify your Contracting Officer** of the subcontractor's non-compliant SPRS score and your assessment of their status. Transparency is critical to protect your position as prime.
4. **Issue a written notice to the subcontractor** requiring them to submit a remediation plan with specific milestones to reach a compliant score, and an affirmation of commitment to CMMC requirements.
5. **Consider restrictions on CUI access** pending remediation — limit the subcontractor's access to the minimum CUI necessary while they remediate.
6. **Set a contractual deadline** for the subcontractor to achieve a compliant SPRS score (or C3PAO certification, as applicable), with consequences for non-compliance including potential termination.
7. **Do not award any new task orders or work** to this subcontractor that involves CUI handling until they achieve a compliant score.
8. **Monitor remediation progress** — require monthly or quarterly SPRS updates and review of POA&M closure milestones.

---

## Summary Table

| Issue | Subcontractor 1 (Google Drive) | Subcontractor 2 (SPRS Score 42) |
|---|---|---|
| Severity | Critical — active CUI exposure | High — systemic control gaps |
| Immediate action | Stop-work, incident assessment | Restrict CUI access, demand CAP |
| CO notification required | Yes (potential 7012 incident) | Yes (7021 non-compliance) |
| Continue subcontract? | No, until remediated | No new CUI work until compliant |
| Root obligation | DFARS 252.204-7021(c) flowdown | DFARS 252.204-7021(c) flowdown |

---

## Prime Contractor's Broader Obligations and Risk

- **False Claims Act exposure:** If you knowingly allow non-compliant subcontractors to handle CUI and affirm compliance to the government, you may face False Claims Act liability. Prompt self-reporting and corrective action are critical mitigants.
- **Document your diligence:** Maintain written records of all steps taken — notifications, responses, CAPs, and communications with the Contracting Officer.
- **Review your entire subcontractor base:** These two cases suggest a need for a systematic review of all subcontractors that may handle CUI to verify CMMC compliance status in SPRS.
- **Update subcontract language:** Ensure all current and future subcontracts include enforceable CMMC flowdown clauses, SPRS score thresholds, rights to audit, and remediation/termination provisions.

---

*This response reflects general knowledge of DFARS 252.204-7021, CMMC program requirements, NIST SP 800-171, and associated DoD guidance as of April 2026. Program-specific requirements may vary; always consult your Contracting Officer and legal counsel for contract-specific obligations.*

# NIST AI RMF: The Four Core Functions and How to Get Started

The NIST AI Risk Management Framework (AI RMF 1.0) organizes AI risk management into four core functions: **GOVERN**, **MAP**, **MEASURE**, and **MANAGE**. These are not sequential phases you complete once — they are continuous, interconnected practices that together form a complete risk management system for AI throughout its lifecycle.

---

## The Four Core Functions

### 1. GOVERN — Organizational Accountability (GV-1 through GV-6)

GOVERN is the foundation. It establishes the organizational culture, policies, accountability structures, and risk tolerance that make all other AI risk management activity possible.

GOVERN answers: *Who is responsible for AI risk in this organization, and what are the rules we operate under?*

Key activities under GOVERN include:
- Formalizing an organization-wide AI Risk Management Policy signed by senior leadership (GV-1.1)
- Defining risk tolerance — for example, acceptable thresholds for false positive rates or demographic bias (GV-1.3, GV-5.1)
- Appointing accountable senior officials such as an AI Risk Owner with board-level reporting (GV-2.2)
- Assigning roles across the full AI lifecycle — design, development, deployment, and decommission — for both technical and non-technical staff (GV-3.1 through GV-3.3)
- Establishing cross-functional teams that include AI/ML, legal, privacy, security, HR, and ethics (GV-4.1)
- Aligning AI risk practices with applicable laws and regulations, such as the EU AI Act or sector-specific requirements (GV-6.1)

Without GOVERN, MAP, MEASURE, and MANAGE will lack the authority, ownership, and policy backing needed to operate consistently.

---

### 2. MAP — Risk Identification (MP-1 through MP-5)

MAP establishes context. Before you can measure or manage AI risks, you need to understand what each AI system does, who it affects, and what could go wrong.

MAP answers: *What are the risks associated with this specific AI system, and who bears them?*

Key activities under MAP include:
- Documenting each AI system's intended use, operating environment, and explicitly prohibited use cases (MP-1.2, MP-1.5)
- Identifying all affected individuals, groups, and communities — at design time, not at deployment (MP-1.4)
- Documenting training data assumptions, known limitations, and output uncertainty (MP-2.2, MP-2.3)
- Producing a stakeholder risk/benefit matrix distinguishing who benefits from the system versus who bears its risks — these are frequently different groups (MP-3.1, MP-3.3)
- Prioritizing identified risks using criteria such as severity, breadth, and reversibility (MP-4.1, MP-4.2)
- Characterizing the likelihood and impact of harms across physical, financial, psychological, and societal dimensions, including red-team exercises (MP-5.1, MP-5.2)

A well-executed MAP prevents wasting measurement and treatment resources on the wrong risks.

---

### 3. MEASURE — Risk Analysis (MS-1 through MS-4)

MEASURE translates identified risks into evidence. It employs quantitative, qualitative, and mixed-method tools to evaluate AI systems against the trustworthiness properties the framework defines — accuracy, fairness, explainability, privacy, reliability, resilience, safety, and security.

MEASURE answers: *How severe are these risks, and is our AI system performing as trustworthy as required?*

Key activities under MEASURE include:
- Defining metrics for each identified risk — for example, demographic parity and equalized odds for fairness, adversarial accuracy for robustness, SHAP/LIME scores for explainability (MS-1.1)
- Conducting pre-deployment evaluation across all trustworthiness properties, including disaggregated performance testing across demographic subgroups (MS-2.1, MS-2.2)
- Implementing post-deployment monitoring dashboards that track accuracy, fairness metrics, and input data distribution — with alert thresholds that trigger human review when performance degrades (MS-3.1, MS-3.2)
- Ensuring measurement outputs are communicated to decision-makers with uncertainty caveats included, so MANAGE can act on evidence rather than assumption (MS-4.1, MS-4.2)

MEASURE is what separates a documented risk programme from an effective one.

---

### 4. MANAGE — Risk Response (MG-1 through MG-4)

MANAGE is where risk identification and measurement translate into action. It covers treatment planning, execution, incident response, and continuous improvement.

MANAGE answers: *What are we doing about the risks we have identified and measured?*

Key activities under MANAGE include:
- Assigning a treatment owner, target date, and treatment approach for every risk register entry, with senior approval required for residual risks above the defined tolerance threshold (MG-1.1, MG-1.3)
- Selecting treatment strategies: mitigate technically (retrain the model, add human review), restrict the use case operationally, transfer risk contractually, or avoid risk entirely by not deploying (MG-2.1)
- Defining a documented emergency shutdown or human override procedure for AI systems affecting safety (MG-2.3)
- Operating an AI incident log with severity classification and defined notification thresholds for internal escalation, customer notification, and regulatory disclosure (MG-3.2, MG-3.4)
- Feeding lessons from incidents and treatment reviews back into GOVERN policy updates and MAP context documents (MG-4.3)

MANAGE closes the loop — but only if GOVERN, MAP, and MEASURE have done their work first.

---

## How the Four Functions Relate to Each Other

The functions are interdependent, not sequential. The AI RMF describes them as a continuous cycle:

```
GOVERN
  |
  |-- sets policy, accountability, and risk tolerance that authorize and constrain everything below
  |
MAP -----> MEASURE -----> MANAGE
  ^                           |
  |___________________________|
     lessons learned feed back
     into context and governance
```

Specifically:
- **GOVERN underpins all three operational functions.** Without defined risk tolerance (GV-1.3, GV-5.1), MAP cannot prioritize risks and MANAGE cannot approve residual risk acceptance. Without accountability structures (GV-2), no one owns the outputs of MAP, MEASURE, or MANAGE.
- **MAP feeds MEASURE.** You can only measure what you have identified. The risks and stakeholder impacts documented in MAP define what metrics MEASURE must track.
- **MEASURE feeds MANAGE.** MEASURE produces the evidence — metrics, evaluation results, monitoring alerts — that MANAGE acts on. Without measurement data, risk treatment is guesswork.
- **MANAGE feeds back into GOVERN and MAP.** Incident learnings (MG-3.3, MG-4.3) should update organizational policies (GOVERN) and the contextual risk understanding (MAP) for the system in question. This is the continuous improvement loop.

The framework also defines four **Implementation Tiers** that describe organizational maturity:

| Tier | Name | Description |
|------|------|-------------|
| 1 | Partial | Ad hoc practices; reactive to incidents |
| 2 | Risk Informed | Approved policies exist; not yet consistently applied |
| 3 | Repeatable | Formally documented, consistently applied, regularly reviewed |
| 4 | Adaptive | Continuously learning; proactively updates practices |

Most organizations beginning their AI journey start at Tier 1. The immediate goal for most contexts is Tier 2; regulated environments should target Tier 3.

---

## What to Implement First

**Start with GOVERN.** This is not merely because it appears first in the framework's name — it is because every other function depends on it. Attempting to run MAP assessments or MEASURE evaluations without established policies, ownership, and risk tolerance produces outputs that no one has authority to act on and no budget to resource.

A practical first-90-days sequence:

### Step 1: Stand Up GOVERN (Weeks 1–6)

These are your foundational actions before deploying or assessing any AI system:

1. **Publish an AI Risk Management Policy** signed by senior leadership that establishes AI risk as an organizational priority and defines the programme's scope (GV-1.1).
2. **Define your AI risk tolerance** — at minimum, state which categories of AI use cases are acceptable, which require additional review, and which are prohibited (GV-1.3, GV-5.1, GV-5.3).
3. **Appoint an AI Risk Owner** with clear authority, executive visibility, and cross-functional convening power (GV-2.2).
4. **Define roles** across the AI lifecycle for both technical teams (data scientists, ML engineers) and non-technical roles (business owners, legal, privacy, HR) (GV-3.1 through GV-3.3).
5. **Establish a cross-functional AI Risk Working Group** with representatives from legal, privacy, security, and the business units deploying AI (GV-4.1).
6. **Identify applicable laws and regulations** relevant to your sector and document them in a regulatory register (GV-6.1).

### Step 2: Run MAP for Each AI System (Weeks 4–10, concurrent with late GOVERN work)

For every AI system you are planning to deploy:

1. Produce an **AI System Description Document** covering: purpose, inputs, outputs, decision authority, intended and prohibited uses (MP-1.2, MP-1.5).
2. Identify **affected populations** — who makes decisions based on the system's outputs, and who those decisions affect (MP-1.4).
3. Create a **stakeholder risk/benefit matrix** distinguishing beneficiaries from those bearing risk (MP-3.1, MP-3.3).
4. **Prioritize risks** using a severity × breadth × reversibility model; flag anything affecting protected classes or with irreversible impacts as high-priority (MP-4.1, MP-4.2).

### Step 3: Apply MEASURE Before Deployment and Continuously After (Weeks 8–16)

1. Define **evaluation metrics** for the trustworthiness properties most relevant to each system — at minimum: accuracy, fairness (disaggregated by demographic subgroup), and security (MS-1.1, MS-2.2).
2. Require a **pre-deployment evaluation report** before any AI system goes live (MS-2.1).
3. Implement **post-deployment monitoring** with defined alert thresholds that trigger human review (MS-3.1, MS-3.2).

### Step 4: Activate MANAGE

1. Establish an **AI risk register** with treatment owners and target dates for every identified risk (MG-1.1).
2. Define **emergency intervention procedures** — the conditions under which a system is taken offline — for any AI system with safety implications (MG-2.3).
3. Create an **AI incident log and response process** with defined escalation paths (MG-3.2).
4. Schedule **quarterly reviews** of the full programme covering all four functions (MG-4.1).

---

## Key Principle to Carry Forward

The AI RMF is **voluntary and non-prescriptive**. It defines outcomes and practices, not a single mandated method. This means your implementation should be scaled to the risk level of the AI systems you deploy — a low-stakes internal recommendation tool requires a lighter application of the framework than an AI system making consequential decisions about individuals.

Use the **Current Profile / Target Profile** approach: for each of the 19 categories across the four functions, assess where you are today and where you need to be given your risk tolerance and regulatory context. The gap between those two profiles is your AI risk management roadmap.

| Profile Type | Purpose |
|-------------|---------|
| Current Profile | Baseline — which categories are implemented and to what degree |
| Target Profile | Desired state — where you need to be given your risk tolerance and regulatory requirements |

Begin with GOVERN. Build context through MAP. Produce evidence through MEASURE. Take action through MANAGE. Feed what you learn back into the beginning. That is the AI RMF in practice.

# NIST AI Risk Management Framework: The Four Core Functions

## Overview

The NIST AI Risk Management Framework (AI RMF 1.0), published by the National Institute of Standards and Technology in January 2023, provides a structured, voluntary approach for organizations to manage risks associated with AI systems throughout their lifecycle. At the heart of the framework are four core functions: **GOVERN**, **MAP**, **MEASURE**, and **MANAGE**. These functions are not sequential steps but rather interconnected, iterative activities that together form a comprehensive risk management practice.

---

## The Four Core Functions

### 1. GOVERN

**What it is:** GOVERN is the foundational function that establishes the organizational culture, policies, processes, and accountability structures necessary for AI risk management. It cuts across all other functions and provides the enabling conditions for MAP, MEASURE, and MANAGE to operate effectively.

**Key activities include:**
- Establishing organizational policies and procedures for AI risk management
- Defining roles, responsibilities, and accountability for AI risk (including leadership buy-in)
- Building a risk-aware organizational culture around AI development and deployment
- Setting up governance structures such as AI ethics boards, review committees, or responsible AI teams
- Ensuring transparency and documentation practices are in place
- Addressing workforce training and awareness on AI risks and trustworthy AI principles
- Aligning AI risk management with broader enterprise risk management and legal/regulatory requirements

**Why it matters:** Without GOVERN, the other three functions lack organizational backing, resources, and consistency. It ensures that AI risk management is not a one-time exercise but an ongoing, institutionalized practice.

---

### 2. MAP

**What it is:** MAP is the function focused on understanding and contextualizing AI risks. It involves identifying the AI system's context, intended use, stakeholders, and the potential risks and impacts associated with deployment.

**Key activities include:**
- Categorizing and classifying AI systems by their intended purpose and use case
- Identifying affected stakeholders, including end users, impacted communities, and third parties
- Documenting the AI system's intended and potential unintended uses
- Identifying relevant legal, regulatory, and ethical requirements
- Assessing the broader societal and organizational context in which the AI operates
- Recognizing potential sources of harm — including bias, safety failures, privacy violations, and security vulnerabilities
- Establishing risk tolerance levels and prioritizing risks based on likelihood and impact

**Why it matters:** MAP creates the situational awareness needed before risks can be measured or mitigated. It ensures that risk management efforts are targeted at what actually matters and that no significant risk categories are overlooked.

---

### 3. MEASURE

**What it is:** MEASURE involves analyzing, assessing, and tracking identified AI risks using quantitative and qualitative methods. It translates the risks identified in MAP into actionable data and evidence.

**Key activities include:**
- Evaluating AI system performance against defined metrics and benchmarks
- Testing for bias, fairness, accuracy, robustness, and reliability
- Conducting red-teaming, adversarial testing, and other technical evaluations
- Assessing the effectiveness of existing risk controls
- Monitoring AI outputs and behaviors in deployment (including drift and degradation)
- Documenting and tracking risk metrics over time
- Evaluating human-AI interaction risks, including over-reliance and automation bias

**Why it matters:** MEASURE provides the empirical evidence base for decision-making. It answers the question: "How bad is this risk, and are our controls working?" Without measurement, risk management is speculative rather than evidence-driven.

---

### 4. MANAGE

**What it is:** MANAGE is the function where identified and measured risks are prioritized and acted upon. It involves selecting, implementing, and monitoring risk treatments — including mitigations, controls, and contingency plans.

**Key activities include:**
- Prioritizing risks based on severity and organizational risk tolerance
- Implementing technical and operational controls to reduce risk (e.g., model adjustments, human oversight mechanisms, access controls)
- Developing incident response and recovery plans for AI-related failures
- Deciding whether to deploy, modify, restrict, or discontinue an AI system
- Communicating residual risks to relevant stakeholders
- Continuously monitoring deployed AI systems and updating risk treatments as conditions change
- Maintaining documentation of risk decisions and their rationale

**Why it matters:** MANAGE is where risk awareness translates into action. It closes the loop between identifying a risk and actually doing something about it — and ensures that risk treatment is tracked and revisited over time.

---

## How the Four Functions Relate to Each Other

The four functions are designed to work as an **integrated, iterative system** rather than a linear sequence:

```
         GOVERN
        (Enables all)
            |
     +------+------+
     |             |
    MAP  -----> MEASURE
     |      <--    |
     +------+------+
            |
          MANAGE
            |
     (Feedback loop back
      to MAP and GOVERN)
```

- **GOVERN** is the enabling backbone. It provides the organizational infrastructure, authority, and culture that makes MAP, MEASURE, and MANAGE possible and sustainable. GOVERN is not a one-time setup — it evolves as the organization's AI risk maturity grows.

- **MAP** feeds **MEASURE**: You cannot measure what you have not identified. The risk inventory and context established in MAP determines what gets tested, evaluated, and tracked in MEASURE.

- **MEASURE** informs **MANAGE**: Quantified and qualified risk data from MEASURE enables prioritized decision-making in MANAGE. Without measurement, risk treatments may be misallocated.

- **MANAGE** feeds back into **MAP**: Outcomes from risk treatment — including what worked, what failed, and what new risks emerged — refine the risk landscape established in MAP. This creates a continuous improvement loop.

- All four functions continuously inform **GOVERN**: Lessons learned, incident data, and emerging risks feed into policy updates, accountability structures, and cultural norms.

The AI RMF explicitly describes these as **continuous and iterative** — AI systems evolve, deployment contexts change, and new risks emerge. Risk management must be ongoing, not a one-time certification exercise.

---

## What Should You Implement First?

**Start with GOVERN — but begin MAP work in parallel.**

Here is a practical sequencing recommendation for an organization new to AI deployment:

### Phase 1: Establish Governance Foundations (Weeks 1–8)

Begin with GOVERN because it creates the organizational conditions for everything else to succeed:

1. **Secure executive sponsorship** — AI risk management requires authority and resources from leadership. Identify an executive owner (e.g., Chief AI Officer, Chief Risk Officer, or equivalent).

2. **Define AI risk roles and responsibilities** — Who is accountable for AI risk decisions? Who is responsible for testing? Who must approve deployments? Document this clearly.

3. **Inventory your AI systems** — Conduct a basic census of all AI systems currently in use or planned. Even a simple spreadsheet is sufficient at this stage. This bridges GOVERN and MAP.

4. **Establish a cross-functional AI governance team** — Include representatives from legal, compliance, IT/security, business units, and where possible, external stakeholder perspectives.

5. **Adopt an AI risk policy** — A high-level policy statement that articulates the organization's commitment to responsible AI, acceptable use boundaries, and escalation procedures.

6. **Define your risk tolerance** — What categories of AI risk are acceptable? What would trigger a deployment halt? These decisions need leadership input early.

### Phase 2: Begin Mapping Your AI Systems (Weeks 4–12, overlapping with Phase 1)

While governance infrastructure is being built, begin MAP work for your highest-priority AI deployments:

1. **Characterize each AI system** — Document its intended purpose, the data it uses, who makes decisions based on its outputs, and the populations it affects.

2. **Identify stakeholders and potential harms** — Who could be harmed if the system fails, produces biased outputs, or is misused? Include not just users but affected third parties.

3. **Assess regulatory and legal context** — Are any of your AI systems subject to sector-specific regulations (e.g., healthcare, financial services, employment)? What are the applicable legal requirements?

4. **Prioritize your AI systems by risk level** — Not all AI systems carry equal risk. Focus early MEASURE and MANAGE resources on high-impact, high-stakes systems.

### Phase 3: Implement MEASURE and MANAGE for Priority Systems (Months 3–6)

Once governance structures are in place and your highest-risk systems are mapped:

1. **Develop evaluation frameworks** — Define the metrics that matter for each system (accuracy, fairness, robustness, etc.) and establish testing protocols.

2. **Conduct initial risk assessments** — Run the first round of MEASURE activities on priority systems before or immediately after deployment.

3. **Implement risk controls** — Based on MEASURE findings, apply proportionate controls. This may mean adding human oversight checkpoints, restricting use cases, improving training data, or increasing monitoring frequency.

4. **Establish incident response procedures** — Define what happens when an AI system produces a harmful output or fails unexpectedly.

### Ongoing: Mature and Iterate (Month 6 and beyond)

- Extend GOVERN, MAP, MEASURE, and MANAGE to lower-priority AI systems
- Revisit and update risk assessments as AI systems are updated or deployment contexts change
- Build organizational AI risk management maturity over time
- Consider alignment with the AI RMF's Organizational Profiles to track progress

---

## Practical Recommendations for Getting Started

**Do not wait for perfection before starting.** A basic AI inventory, a designated risk owner, and a simple risk assessment checklist for new AI deployments will deliver immediate value, even before a comprehensive program is in place.

**Use the AI RMF Playbook.** NIST has published a companion AI RMF Playbook that provides suggested actions for each function and category. It is a practical complement to the framework document itself and can help translate high-level guidance into specific tasks.

**Integrate with existing risk management processes.** If your organization already has enterprise risk management, IT risk, or information security risk programs, AI risk management should complement and connect to these — not operate as a separate silo.

**Prioritize human oversight early.** For your first AI deployments, err on the side of more human oversight rather than less. This gives your organization time to build measurement capabilities and confidence before increasing automation.

**Document decisions.** One of the most common AI risk management failures is inadequate documentation of why decisions were made, what risks were accepted, and who approved them. Establish documentation habits from the start.

---

## Summary Table

| Function | Primary Question | Key Output |
|----------|-----------------|------------|
| GOVERN | Are we organized and accountable for AI risk? | Policies, roles, culture, governance structures |
| MAP | What risks does this AI system create and for whom? | Risk inventory, context documentation, stakeholder analysis |
| MEASURE | How significant are these risks? | Risk assessments, test results, monitoring data |
| MANAGE | What are we doing about these risks? | Risk treatments, controls, incident response, deployment decisions |

The NIST AI RMF is designed to be flexible and scalable. Organizations of any size can begin with lightweight implementations of all four functions and deepen their practices over time. The goal is not compliance with a checklist but the development of genuine organizational capacity to identify, assess, and respond to AI risks in a way that supports trustworthy AI deployment.

# NIST AI RMF Assessment: AI Hiring Tool (Resume Screening and Candidate Ranking)

---

## Context

An AI hiring tool that screens resumes and ranks candidates is classified as **high-risk** under the NIST AI RMF and the EU AI Act (Annex III — employment, workers management, and access to self-employment). Decisions made by this system directly affect individuals' livelihoods, triggering heightened obligations across all four RMF functions. This assessment focuses on key risks, the most relevant trustworthiness properties, and the specific MEASURE 2.x pre-deployment actions required before the system goes live.

---

## 1. Key Risks to Assess (MAP Function)

The following risks should be documented and prioritized as part of the MAP function before measurement begins.

### Risk Register Summary

| Risk ID | Risk Description | Trustworthiness Property at Risk | Likelihood | Impact | Priority |
|---------|-----------------|----------------------------------|------------|--------|----------|
| HR-001 | Model perpetuates historical hiring biases encoded in training data (e.g., penalizes resume gaps, non-traditional career paths disproportionately affecting women, caregivers, or minorities) | Fair / Bias Managed | High | Critical | P1 |
| HR-002 | Disparate impact on protected classes (race, gender, age, disability, national origin) violating EEOC and Title VII standards — failure to meet the 4/5ths (80%) disparate impact ratio rule | Fair / Bias Managed | High | Critical | P1 |
| HR-003 | Ranking criteria not explainable to recruiters or rejected candidates — inability to provide meaningful adverse action notice | Explainable & Interpretable | High | High | P1 |
| HR-004 | Proxy variable use: model learns protected attributes indirectly through correlated features (e.g., zip code → race, graduation year → age, names → gender or ethnicity) | Fair / Bias Managed | High | Critical | P1 |
| HR-005 | Training data reflecting historical over/under-representation of certain groups, leading to skewed ranking scores | Valid & Verified | High | High | P1 |
| HR-006 | Model performance degrades over time as job market, role requirements, or applicant pool demographics shift (model drift) | Reliable | Medium | High | P2 |
| HR-007 | Lack of human oversight — recruiters over-rely on AI rankings without independent review, removing meaningful human decision-making | Accountable & Transparent | Medium | High | P2 |
| HR-008 | PII exposure: resumes contain sensitive personal data (address, phone, employment history); inadequate data minimization or access controls | Privacy-Enhanced | Medium | High | P2 |
| HR-009 | Candidates gaming or manipulating the system by crafting resumes specifically to exploit model patterns (adversarial inputs) | Resilient / Secure | Low | Medium | P3 |
| HR-010 | Societal aggregate effect: widespread deployment of biased hiring AI systematically narrows workforce diversity across the labor market | Safe (societal harm) | Medium | Critical | P1 |

### Key Contextual Factors (MAP 1.x)

- **Intended use boundary (MP-1.2):** The system should be scoped explicitly — screening only, ranking only, or making final cut decisions? Autonomous final decisions represent the highest risk profile.
- **Affected populations (MP-1.4):** All job applicants, with heightened attention to groups historically underrepresented in the organization's workforce.
- **Prohibited uses (MP-1.5):** Document explicitly that the system may not be used as the sole basis for rejection without human review.
- **Legal constraints (MP-1.6):** EEOC guidelines, Title VII (Civil Rights Act), ADEA (age), ADA (disability), New York City Local Law 144 (requires annual bias audits for automated employment decision tools), EU AI Act Article 9 (high-risk AI risk management system requirements).

---

## 2. Most Relevant Trustworthiness Properties

The seven NIST AI RMF trustworthiness properties are not equally weighted for every AI system. For an AI hiring tool, the following four are most critical, followed by three secondary properties.

### Primary Properties (Critical for This Use Case)

**1. Fair / Bias Managed**
This is the most critical property for hiring AI. The system must not produce discriminatory outcomes against protected classes. Key concerns include disparate impact in screening outcomes, proxy discrimination through correlated variables, and biased training data that encodes historical exclusion patterns. Fairness must be measured using multiple metrics simultaneously — no single fairness metric is sufficient. Relevant measures include Demographic Parity, Equalized Odds, Disparate Impact Ratio (the EEOC 4/5ths rule threshold of ≥0.8 applies), and Counterfactual Fairness.

**2. Explainable & Interpretable**
Rejected candidates and recruiters must be able to understand why a candidate was screened out or ranked lower. This is a legal requirement in jurisdictions requiring adverse action notices and is essential for meaningful human oversight. SHAP or LIME-based feature attributions should be generated for each candidate decision. Counterfactual explanations ("candidate X would have ranked higher if qualification Y were present") are especially useful for recruiter review.

**3. Valid & Verified**
The model must demonstrably perform its intended function — identifying qualified candidates — and not simply replicate historical hiring patterns. Validation must include out-of-distribution testing, disaggregated performance analysis across demographic subgroups, and confirmation that the model's ranking criteria align with genuine job-relevant competencies.

**4. Accountable & Transparent**
Clear accountability chains must exist for AI-assisted hiring decisions. The organization must be able to answer: who is responsible for the AI system's outputs? What records are kept of AI-assisted decisions? Can the system's behaviour be audited? Transparency to candidates about the use of AI in screening is increasingly a legal requirement (NYC Local Law 144; EU AI Act Art. 26).

### Secondary Properties (Important but Contextually Dependent)

**5. Privacy-Enhanced**
Resumes contain substantial PII. Data minimization, purpose limitation, and access controls must be applied. The model should not retain or expose candidate PII beyond what is necessary for the screening function.

**6. Reliable**
The system must produce consistent rankings for equivalent candidates and maintain performance as applicant pool characteristics evolve over time. Unreliable systems introduce arbitrary variation into hiring decisions.

**7. Safe (societal dimension)**
At scale, a biased hiring AI can cause significant societal harm by systematically excluding qualified candidates from underrepresented groups. This extends beyond individual harm to labor market effects and organizational diversity outcomes.

---

## 3. MEASURE 2.x Pre-Deployment Actions

MEASURE 2 (MS-2) requires evaluating the AI system for trustworthiness before deployment. The following specific actions map to each MS-2 subcategory and should be completed and documented prior to go-live.

### MS-2.1 — Pre-Deployment Technical Performance and Safety Evaluation

**Required Actions:**

1. **Establish performance baselines.** Define minimum acceptable performance thresholds for Precision, Recall, F1 score, and AUC-ROC on a held-out test set representative of your actual applicant population — not just the historical hire population (which is already biased toward past selections).

2. **Conduct out-of-distribution (OOD) testing.** Test the model on resume formats, career trajectories, and educational backgrounds that are underrepresented in training data to identify failure modes before deployment.

3. **Validate job relevance of ranking criteria.** Conduct a structured job task analysis confirming that the features driving model rankings correlate with genuine job performance — not with characteristics correlated to protected attributes. Document this validation with HR and legal sign-off.

4. **Test for calibration.** Verify that the model's confidence scores or ranking scores are calibrated — a candidate ranked in the 90th percentile should genuinely be a stronger match than one ranked in the 50th percentile. Miscalibration amplifies harm when scores are used as decision thresholds.

5. **Document a pre-deployment evaluation report** covering system purpose, performance metrics, known limitations, and deployment constraints. This constitutes the Model Card or System Card for the hiring tool.

### MS-2.2 — Bias and Fairness Testing Across Demographic Groups

**Required Actions:**

1. **Disaggregated performance analysis.** Run the model against a demographically labeled test dataset. Report Precision, Recall, and F1 separately for each protected class: gender, race/ethnicity, age group (40+ vs. under 40 per ADEA), disability status where discernible.

2. **Disparate Impact Ratio measurement.** Calculate the ratio of positive screening outcomes (advance to next stage) across demographic groups. Flag any group where the ratio falls below 0.8 relative to the highest-rate group (EEOC 4/5ths rule). Document findings and required mitigations.

3. **Equalized Odds testing.** Verify that True Positive Rates (qualified candidates correctly advanced) and False Positive Rates (unqualified candidates incorrectly advanced) are equivalent across demographic groups. Disparate error rates indicate discriminatory impact even if overall rates appear similar.

4. **Proxy variable audit.** Systematically identify features that may serve as proxies for protected attributes (names, addresses, graduation years, school names, employment gap patterns). Evaluate the model's reliance on these features using SHAP global feature importance. Consider removing or transforming high-proxy-risk features.

5. **Counterfactual fairness test.** Generate synthetic resume pairs that are identical except for a name associated with different demographic groups (e.g., "Emily Clarke" vs. "Latisha Clarke"). Verify the model produces equivalent ranking scores. Document the test methodology and results.

6. **Third-party bias audit.** For organizations operating under NYC Local Law 144 or similar regulations, commission an independent annual bias audit before deployment. Document auditor credentials, methodology, and results for public disclosure.

### MS-2.3 — Explainability and Interpretability Requirements

**Required Actions:**

1. **Generate SHAP explanations for all candidate decisions.** Implement SHAP (SHapley Additive exPlanations) to produce per-candidate feature attribution scores. These must be available to recruiters reviewing AI-assisted rankings.

2. **Define recruiter-facing explanation format.** Translate SHAP scores into plain-language explanations suitable for non-technical HR staff. Example: "This candidate ranked highly because of: [Years of relevant experience — high weight], [Skills match to job description — high weight]. Ranked lower on: [Education credential match — low weight]."

3. **Generate counterfactual explanations for screened-out candidates.** For candidates not advanced, produce a counterfactual explanation: "This candidate would have qualified if [specific qualification] were present." This supports adverse action notice requirements and candidate feedback obligations.

4. **Test explainability with recruiter focus group.** Validate that explanations are interpretable and actionable by the HR staff who will use the system. Document feedback and iterate on explanation format before deployment.

5. **Document explainability limitations.** If the model architecture limits explanation fidelity (e.g., complex ensemble or deep learning model where LIME approximations may be unstable), document this limitation explicitly and determine whether it is acceptable given the decision stakes. For very high-stakes final-cut decisions, consider using a more interpretable model architecture (e.g., logistic regression or decision tree) even at some accuracy cost.

### MS-2.4 — Security and Privacy Assessment

**Required Actions:**

1. **PII data flow mapping.** Document all PII contained in resumes (name, address, contact information, employment history, education) and map its flow through the system — ingestion, storage, processing, retention, and deletion.

2. **Data minimization review.** Confirm the model uses only features necessary for screening. Remove features (e.g., home address, full name, date of birth) that are not job-relevant and carry re-identification or discrimination risk.

3. **Access control audit.** Verify that candidate PII and model outputs are accessible only to authorized HR personnel. Implement role-based access controls on the recruitment platform.

4. **Membership inference attack assessment.** Assess whether the model could reveal whether a specific individual's resume was in the training data. This is particularly relevant if the model was trained on resumes from current employees. Apply mitigation measures (differential privacy, output regularization) if exposure risk is high.

5. **Privacy impact assessment (PIA).** Complete a formal PIA covering lawful basis for processing, purpose limitation, data subject rights (access, correction, erasure), and retention periods. Obtain DPO or legal review sign-off before deployment.

### MS-2.5 — Human Oversight Mechanisms Tested and Validated

**Required Actions:**

1. **Define human-in-the-loop requirements.** Specify at which decision points human review is mandatory. Recommended minimum: all screened-out candidates at the initial stage should be subject to a human spot-check sample; no candidate may be rejected without a recruiter having access to and reviewing the AI explanation.

2. **Test override functionality.** Confirm that recruiters can override AI rankings and that overrides are logged. Test that the system does not re-rank or penalize candidates whose profiles have been manually reviewed and advanced against the AI recommendation.

3. **Validate override logging and audit trail.** Ensure the system creates a complete audit log of: AI ranking score, recruiter decision, whether it differed from AI recommendation, and rationale field for overrides. This log is essential for post-deployment bias monitoring and legal defensibility.

4. **Human oversight training.** Before deployment, train all recruiting staff on: how the AI tool works, its known limitations and bias risks, how to interpret explanations, when and how to override, and their legal obligations regarding AI-assisted employment decisions.

5. **Validate that human oversight is meaningful, not nominal.** Assess whether recruiters have sufficient time and information to exercise genuine judgment. If recruiters are processing 200 applications per hour with AI rankings, "human oversight" may be a rubber stamp. Define maximum caseload thresholds per reviewer to ensure meaningful review.

### MS-2.6 — Evaluation Results Documented and Shared

**Required Actions:**

1. **Produce a Pre-Deployment Evaluation Report** consolidating results from all MS-2.1 through MS-2.5 assessments. The report should include: performance metrics by demographic subgroup, disparate impact ratios, proxy variable audit findings, explanation quality assessment, privacy assessment findings, human oversight design, and identified residual risks.

2. **Share evaluation results with relevant stakeholders.** Distribute the report to: HR leadership (deployment decision authority), Legal/Compliance (regulatory sign-off), IT Security (technical validation), and any employee representatives or DEI committees whose remit covers hiring practices.

3. **Obtain formal deployment approval.** Require sign-off from HR leadership and Legal/Compliance before deployment proceeds. Document the approval with reference to the evaluation report and any accepted residual risks.

4. **Publish candidate-facing transparency notice.** Inform applicants that AI is used in the screening process, describe what data is processed, explain how to request human review, and provide contact information for questions. This satisfies transparency obligations under NYC Local Law 144 and EU AI Act Article 26.

---

## 4. Summary: Pre-Deployment Checklist

| Action | RMF Reference | Status |
|--------|--------------|--------|
| Define intended use boundary and prohibited uses | MAP 1.2, 1.5 | [ ] |
| Identify affected populations and protected classes | MAP 1.4 | [ ] |
| Document applicable legal requirements (EEOC, Local Law 144, EU AI Act) | MAP 1.6, GV-6.1 | [ ] |
| Conduct job task analysis validating ranking criteria relevance | MS-2.1 | [ ] |
| Establish performance baselines (Precision/Recall/F1/AUC-ROC) | MS-2.1 | [ ] |
| Run disaggregated performance analysis by demographic group | MS-2.2 | [ ] |
| Measure Disparate Impact Ratio (≥0.8 per EEOC 4/5ths rule) | MS-2.2 | [ ] |
| Test Equalized Odds across protected classes | MS-2.2 | [ ] |
| Conduct proxy variable audit using SHAP global feature importance | MS-2.2, MS-2.3 | [ ] |
| Run counterfactual fairness tests (name substitution pairs) | MS-2.2 | [ ] |
| Implement SHAP/LIME per-candidate explanations | MS-2.3 | [ ] |
| Validate explainability with HR recruiter focus group | MS-2.3 | [ ] |
| Complete PII data flow mapping and data minimization review | MS-2.4 | [ ] |
| Complete Privacy Impact Assessment with legal sign-off | MS-2.4 | [ ] |
| Assess membership inference attack risk | MS-2.4 | [ ] |
| Define and test human-in-the-loop override procedures | MS-2.5 | [ ] |
| Validate audit log completeness (AI score, recruiter decision, override) | MS-2.5 | [ ] |
| Train all recruiting staff on AI tool use and limitations | MS-2.5 | [ ] |
| Produce and distribute Pre-Deployment Evaluation Report | MS-2.6 | [ ] |
| Obtain formal deployment approval from HR leadership and Legal | MS-2.6 | [ ] |
| Publish candidate-facing transparency notice | MS-2.6, GV-6.2 | [ ] |

---

## 5. Regulatory Note

An AI hiring tool is classified as **high-risk** under the EU AI Act (Annex III, point 4 — employment). If the organization operates in the EU or processes applications from EU residents, it is subject to mandatory requirements under Articles 9–15, including a risk management system (Art. 9), data governance requirements (Art. 10), technical documentation (Art. 11), transparency obligations to deployers (Art. 13), human oversight measures (Art. 14), and accuracy/robustness requirements (Art. 15). The NIST AI RMF MEASURE 2.x actions described above provide a methodology that satisfies Art. 9's risk management system requirement. For organizations subject to NYC Local Law 144, an independent annual bias audit and public results disclosure are mandatory before the tool is used in hiring decisions affecting NYC-based applicants.

---

*Assessment prepared using NIST AI RMF 1.0 (NIST AI 100-1, January 2023). All category references follow the RMF Core structure (GOVERN, MAP, MEASURE, MANAGE). Date of assessment: 2026-04-25.*

# NIST AI RMF Assessment: AI Hiring Tool (Resume Screening and Candidate Ranking)

## Overview

An AI hiring tool that screens resumes and ranks candidates operates in a high-stakes domain with significant potential for harm to individuals. Employment decisions affect livelihoods, economic opportunity, and can perpetuate or amplify systemic discrimination. The NIST AI Risk Management Framework (AI RMF 1.0) provides a structured approach to identifying, assessing, and managing these risks before deployment.

---

## Key Risks to Assess

### 1. Bias and Discriminatory Outcomes

The most significant risk for a hiring AI is encoding or amplifying historical bias. Training data reflecting past hiring decisions may embed patterns that disadvantage candidates based on protected characteristics (race, gender, age, national origin, disability status). The model may use proxies — graduation years, names, zip codes, school names — to discriminate even when protected attributes are not explicit inputs.

**Specific concerns:**
- Training data reflects historical underrepresentation of certain groups
- Embedding models trained on biased corpora (e.g., word2vec associations between gender and job titles)
- Feedback loops where past biased hires become future training signal
- Disparate impact across demographic groups even with facially neutral criteria

### 2. Lack of Explainability and Transparency

Hiring decisions that affect individuals' rights to employment opportunity must be explainable. Black-box ranking algorithms make it impossible to audit why a candidate was screened out or ranked lower. This creates legal exposure under employment discrimination law and limits the ability of human reviewers to catch errors.

### 3. Data Quality and Representativeness

Resume data is unstructured, inconsistently formatted, and may not capture job-relevant competencies accurately. Candidates from non-traditional backgrounds (career changers, those with gaps, those without prestigious institutional credentials) may be systematically disadvantaged by a model trained to recognize conventional career patterns.

### 4. Scope Creep and Misuse

The tool may be applied beyond its intended use case — for example, extending from initial screening to final ranking, or being used for roles or seniority levels outside the training distribution. Automated rankings may be treated as final decisions rather than decision-support inputs, removing meaningful human review.

### 5. Validity and Performance Degradation

The model may perform well on a narrow set of resume formats or job categories while performing poorly on others. Performance may degrade over time as job requirements evolve, labor markets shift, and resume conventions change, without any mechanism for detecting this drift.

### 6. Privacy and Data Governance

Resumes contain sensitive personal information. Candidate data may be retained beyond necessity, used for purposes beyond the immediate hiring decision, or shared with third parties without adequate disclosure or consent.

### 7. Lack of Meaningful Human Oversight

If the system operates at scale with minimal human review of its outputs, individual screening errors will propagate without correction. Human reviewers may experience automation bias, deferring to system rankings rather than applying independent judgment.

### 8. Accountability Gaps

Responsibility for the tool's decisions may be unclear — between the vendor who built the model, the HR team that configured it, and the hiring managers who act on it. Without clear accountability structures, no party takes ownership of adverse outcomes.

---

## Most Relevant NIST AI RMF Trustworthiness Properties

The AI RMF identifies seven trustworthiness characteristics. For a hiring AI, the following are most critical, listed in order of priority for this use case:

### 1. Fairness (including bias management)

Fairness is the paramount concern for a hiring AI. The framework distinguishes between statistical fairness (demographic parity, equalized odds, individual fairness) and contextual fairness (procedural justice, access to opportunity). Organizations must define which fairness criteria are most appropriate given legal context and organizational values, recognizing that some criteria are mathematically incompatible.

Key actions: Test for disparate impact across protected groups; apply bias mitigation techniques at data, model, and post-processing stages; establish fairness thresholds as deployment gates.

### 2. Explainability and Interpretability

Because hiring decisions have direct impact on individuals, the reasoning behind rankings must be accessible to human reviewers. Explainability enables audit, appeals processes, and regulatory compliance (particularly relevant under the EEOC's uniform guidelines on employee selection procedures and emerging AI employment laws such as New York City Local Law 144).

Key actions: Use inherently interpretable models or post-hoc explanation methods (SHAP, LIME); document which features drive rankings; test whether explanations are faithful to actual model behavior.

### 3. Accountability

Clear lines of responsibility must exist for the AI system's outputs. This includes vendor accountability (documented model cards, third-party audits), organizational accountability (designated AI risk owner, governance board), and process accountability (documented procedures for human override and appeals).

Key actions: Assign an AI risk owner; establish a model registry with versioning; define escalation paths for contested decisions.

### 4. Privacy

Candidate data governance must meet applicable privacy regulations and organizational policies. Hiring AI systems that analyze sensitive personal data require data minimization, purpose limitation, and retention controls.

Key actions: Conduct a data protection impact assessment; implement data minimization in feature engineering; establish retention and deletion schedules for candidate data.

### 5. Reliability and Safety

The system must perform consistently and correctly within its intended scope. For a hiring tool, reliability failures directly harm candidates who are incorrectly screened out.

Key actions: Establish performance benchmarks across candidate subgroups; define out-of-scope conditions that trigger fallback to human-only review; monitor for data drift.

### 6. Transparency

Stakeholders — candidates, hiring managers, HR teams, and regulators — must have appropriate visibility into the existence of the AI system, its purpose, and its limitations. Candidates should know AI screening is being used.

Key actions: Disclose AI use in job postings and application processes; provide documentation for internal users; publish external-facing statements on AI use in hiring.

---

## MEASURE 2.x Actions Before Deployment

The MEASURE function of the AI RMF focuses on analyzing, assessing, benchmarking, and monitoring AI risk. MEASURE 2.x subcategories address the evaluation of AI systems against defined risk criteria. The following specific actions apply to this hiring AI:

### MEASURE 2.1 — Establish Risk Metrics and Measurement Approaches

**Actions:**
- Define quantitative fairness metrics for evaluation: demographic parity ratio, equalized odds (true positive rate parity and false positive rate parity across demographic groups), individual fairness measures
- Select performance metrics appropriate to a ranking task: normalized discounted cumulative gain (NDCG), rank correlation, precision at k for each demographic subgroup
- Document baseline acceptable thresholds for each metric that constitute a deployment gate
- Establish a measurement cadence: pre-deployment, at launch, and at defined intervals post-deployment
- Map metrics to specific harms: which metric failure corresponds to which population-level harm

### MEASURE 2.2 — Evaluate AI Systems Against Defined Risk Criteria

**Actions:**
- Conduct pre-deployment bias audits using demographically representative test sets; if proxies for demographic characteristics are unavailable, use name-based or location-based proxies as a conservative lower bound
- Perform adversarial testing: construct synthetic resumes that are identical except for demographic signals (names, schools, neighborhood zip codes) and compare rankings
- Test model behavior at distributional boundaries — resumes from non-traditional backgrounds, career changers, candidates with employment gaps, and non-English-language education systems
- Evaluate calibration: does the model's confidence in rankings correspond to actual quality-of-hire outcomes (if historical data exists)?
- Assess explanation fidelity: are the explanations provided to human reviewers faithful to actual model behavior, or are they post-hoc rationalizations that differ from the true decision process?
- Document all test results with sufficient detail to support regulatory review or legal challenge

### MEASURE 2.3 — Analyze and Understand AI Risks Throughout the AI Lifecycle

**Actions:**
- Conduct a structured impact assessment covering all candidate-facing stages: job posting, application, initial screening, ranking, interview selection
- Identify points where algorithmic outputs convert into human decisions, and assess the risk of automation bias at each handoff
- Map data lineage: trace training data back to original sources and identify where historical bias may have been introduced
- Assess third-party model or data dependencies: if using a foundation model or external resume parser, evaluate what bias characteristics those components may introduce
- Document known limitations of the model: job categories where performance is lower, resume formats that may be poorly parsed, languages and educational systems the model was not trained on

### MEASURE 2.4 — Set and Apply Risk Tolerance Thresholds

**Actions:**
- Establish maximum acceptable disparate impact ratios (a common legal benchmark is the 4/5ths rule from the EEOC, though stricter internal thresholds are advisable for high-volume systems)
- Define trigger conditions that require human-only review: candidates near decision boundaries, candidates from demographic groups with high false negative rates in testing, job categories outside training distribution
- Document the risk tolerance rationale with input from legal, HR, and diversity, equity, and inclusion (DEI) stakeholders
- Obtain explicit sign-off from accountable executives before deployment confirming awareness of residual risks

### MEASURE 2.5 — Identify and Prioritize Residual Risks

**Actions:**
- After mitigation steps, document residual risks that cannot be fully addressed through technical means alone
- Assess residual bias risk: are there demographic groups for whom the model's performance remains below acceptable thresholds even after mitigation?
- Evaluate residual explainability gaps: are there candidate decisions the model makes that cannot be adequately explained to human reviewers?
- Prioritize residual risks by likelihood and magnitude of harm, and assign mitigation owners and timelines
- Determine whether residual risks are acceptable given the intended use case, scale of deployment, and available human oversight

### MEASURE 2.6 — Document AI System Characteristics, Capabilities, and Limitations

**Actions:**
- Produce a model card or AI system fact sheet documenting: intended use cases, out-of-scope uses, training data description, known limitations, fairness test results, and performance benchmarks
- Document the human-in-the-loop design: specify what decisions require human confirmation, who performs that review, and what training they receive
- Record the configuration of the deployed system including feature inputs, model version, threshold settings, and any post-processing logic applied to rankings
- Establish a change management policy: any retraining, threshold adjustment, or feature change triggers a new assessment cycle

### MEASURE 2.7 — Monitor AI System Performance in Operation

**Actions:**
- Establish ongoing monitoring for performance drift: track ranking output distributions over time and flag statistical deviations
- Implement outcome monitoring where feasible: correlate AI rankings with hiring decisions, and where hire-to-performance data exists, track predictive validity over time
- Set up alerting for anomalous outputs: sudden changes in pass-through rates for demographic groups, unusual clustering of scores, or high rates of human override
- Define a formal model refresh cycle and criteria for triggering off-cycle retraining

---

## Summary Table

| Risk Category | Trustworthiness Property | Key MEASURE 2.x Action |
|---|---|---|
| Discriminatory outcomes | Fairness | Demographic bias audit with adversarial testing (2.2) |
| Proxy discrimination | Fairness | Data lineage analysis and feature audit (2.3) |
| Opaque rankings | Explainability | Explanation fidelity testing (2.2); model card (2.6) |
| Automation bias | Accountability | Human review design documentation (2.6) |
| Candidate data misuse | Privacy | Data protection impact assessment (2.3) |
| Performance degradation | Reliability | Ongoing monitoring and drift detection (2.7) |
| No candidate disclosure | Transparency | Disclosure documentation and policy (2.6) |
| Unclear liability | Accountability | Risk tolerance sign-off and ownership (2.4, 2.5) |

---

## Pre-Deployment Gate Checklist

Before deploying the hiring AI tool, the following conditions should be confirmed:

1. Demographic bias audit completed with results meeting defined fairness thresholds
2. Adversarial testing (identical resumes, varied demographic signals) documented with acceptable outcomes
3. Model card and limitations documentation finalized and reviewed by legal and HR
4. Human review workflow designed, documented, and reviewer training completed
5. Candidate-facing disclosure language approved and incorporated into application process
6. Risk tolerance thresholds formally approved by designated executive risk owner
7. Residual risks documented, accepted, and assigned mitigation owners
8. Monitoring and alerting infrastructure operational before go-live
9. Incident response procedure defined for cases of identified bias or performance failure
10. Compliance review completed for applicable employment law requirements (EEOC guidelines, NYC Local Law 144, EU AI Act high-risk classification if applicable)

# AI Risk Register — Credit Scoring Model
## Financial Services Firm | NIST AI RMF 1.0 Aligned
**Date:** 2026-04-25
**System:** Automated Credit Scoring Model
**Lifecycle Stage:** Design through Post-Deployment
**Regulatory Context:** ECOA, Fair Housing Act, CFPB guidance, EU AI Act (High-Risk: Credit Scoring), FCRA

---

## How to Use This Register

Each entry captures:
- **Risk ID** — Unique identifier in format CS-[number]
- **Risk Description** — Plain-language description of the risk
- **Trustworthiness Property** — Which of the NIST AI RMF trustworthiness characteristics is at risk
- **AI RMF Categories** — Specific function + category references (e.g., MAP 5.1, MEASURE 2.2)
- **Likelihood** — Estimated probability: Low / Medium / High
- **Impact** — Severity of harm if the risk materialises: Low / Medium / High / Critical
- **Risk Rating** — Combined priority: Low / Medium / High / Critical
- **Treatment Options** — Specific, actionable treatments aligned to MANAGE function
- **Treatment Owner** — Recommended accountable role
- **Review Frequency** — How often this entry should be reassessed

---

## Risk Register

### CS-001 — Algorithmic Bias and Discriminatory Credit Decisions

| Field | Detail |
|-------|--------|
| **Risk Description** | The credit scoring model produces systematically lower scores for applicants from protected demographic groups (race, ethnicity, sex, national origin, age, marital status), resulting in unlawful disparate impact in credit access and terms. |
| **Trustworthiness Property** | Fair / Bias Managed |
| **AI RMF Categories** | MAP 3.3, MAP 5.2, MAP 5.3, MEASURE 2.2, MEASURE 3.1, MG-1.1, MG-2.1 |
| **Likelihood** | High |
| **Impact** | Critical |
| **Risk Rating** | Critical |
| **Regulatory Exposure** | ECOA (15 U.S.C. § 1691), Fair Housing Act, CFPB Examination Procedures, EU AI Act Art. 10 (High-Risk Data Governance) |

**Treatment Options:**

1. **Mitigate — Pre-deployment fairness testing:** Run disaggregated performance analysis across all ECOA-protected classes before deployment. Apply metrics: Demographic Parity, Equalized Odds, Disparate Impact Ratio (maintain ≥0.8 per EEOC 4/5ths rule). Document results in a model card (MEASURE 2.2, MEASURE 2.6).
2. **Mitigate — Bias-aware retraining:** If disparate impact is detected, apply fairness-aware ML techniques (reweighing, adversarial debiasing, or calibrated equalized odds post-processing) and retrain. Validate results before deployment (MANAGE 2.2).
3. **Mitigate — Ongoing monitoring:** Implement a production monitoring dashboard tracking fairness metrics monthly. Set alert thresholds: e.g., if Disparate Impact Ratio drops below 0.85 for any protected group, trigger mandatory review (MEASURE 3.1, MEASURE 3.2).
4. **Transfer — Third-party fairness audit:** Engage an independent third-party auditor annually to conduct a disparate impact analysis across all credit decisions (MANAGE 4.1).
5. **Accept residual risk with controls:** Document accepted residual risk with senior leadership sign-off and a defined remediation timeline (MG-1.3).

| **Treatment Owner** | Chief Risk Officer + Model Risk Management Team |
| **Review Frequency** | Monthly monitoring; Full assessment at each model version update |

---

### CS-002 — Lack of Explainability and Adverse Action Notice Failures

| Field | Detail |
|-------|--------|
| **Risk Description** | The model generates credit decisions that cannot be explained in terms understandable to applicants or regulators, making it impossible to provide legally required adverse action notices specifying the principal reasons for denial. |
| **Trustworthiness Property** | Explainable and Interpretable |
| **AI RMF Categories** | MAP 1.2, MAP 1.5, MEASURE 2.3, MEASURE 2.6, MG-2.1, GV-6.1 |
| **Likelihood** | High |
| **Impact** | Critical |
| **Risk Rating** | Critical |
| **Regulatory Exposure** | ECOA Regulation B (12 C.F.R. § 202.9) — adverse action notice requirements; FCRA § 615; EU AI Act Art. 13 (Transparency) |

**Treatment Options:**

1. **Mitigate — Implement model explainability layer:** Deploy SHAP (SHapley Additive exPlanations) or LIME to generate feature-level explanations for every individual credit decision. Map SHAP values to the top four principal reasons for each denial (MEASURE 2.3).
2. **Mitigate — Adverse action notice workflow:** Build an automated pipeline that translates model explanations into plain-language adverse action notices meeting Regulation B requirements. Test notices for comprehensibility with representative consumer groups (MG-2.2).
3. **Mitigate — Model card publication:** Produce and maintain a model card documenting model purpose, inputs, outputs, training data characteristics, performance metrics, known limitations, and intended use boundaries. Update at each version release (MAP 2.1, MEASURE 2.6).
4. **Avoid:** If the chosen model architecture (e.g., deep neural network) cannot produce legally defensible explanations, consider switching to an inherently interpretable model (e.g., logistic regression, gradient boosted trees with SHAP) or a hybrid approach with an explainable layer (MG-2.1).

| **Treatment Owner** | Head of Model Risk + Legal/Compliance |
| **Review Frequency** | Pre-deployment testing; Post-deployment quarterly review of adverse action notice accuracy |

---

### CS-003 — Training Data Quality and Historical Bias

| Field | Detail |
|-------|--------|
| **Risk Description** | Training data reflects historical lending patterns that embedded discriminatory practices. Proxy variables (e.g., ZIP code, purchase history) may correlate with protected characteristics. Data quality issues (missing values, stale data, unrepresentative samples) degrade model accuracy. |
| **Trustworthiness Property** | Valid and Verified; Fair / Bias Managed |
| **AI RMF Categories** | MAP 2.2, MAP 2.3, MAP 5.1, MEASURE 1.1, MEASURE 2.1, MEASURE 2.2 |
| **Likelihood** | High |
| **Impact** | High |
| **Risk Rating** | High |
| **Regulatory Exposure** | EU AI Act Art. 10 (Data Governance); CFPB UDAAP guidance on proxy discrimination |

**Treatment Options:**

1. **Mitigate — Data provenance documentation:** Document all training data sources, collection periods, known gaps, and representativeness of the training population relative to the intended deployment population (MAP 2.2).
2. **Mitigate — Proxy variable analysis:** Conduct correlation analysis between all model input features and protected characteristics. Identify and evaluate proxy variables; apply suppression or transformation where proxies create unlawful disparate impact (MAP 5.1, MEASURE 2.2).
3. **Mitigate — Data quality gates:** Implement pre-training data quality checks: completeness thresholds, staleness limits, and demographic representativeness validation. Reject or flag training datasets that fail these gates (MEASURE 1.1).
4. **Mitigate — Synthetic data augmentation:** Where under-represented groups appear in training data, augment with validated synthetic data to improve model performance across all demographic groups (MG-2.2).
5. **Mitigate — Ongoing data drift monitoring:** Monitor production input data distributions using Population Stability Index (PSI) and Kolmogorov-Smirnov tests. Trigger model retraining when significant drift is detected (MEASURE 3.2).

| **Treatment Owner** | Data Engineering Lead + Model Risk Management |
| **Review Frequency** | Pre-training data validation; Quarterly production data drift review |

---

### CS-004 — Model Performance Degradation and Drift

| Field | Detail |
|-------|--------|
| **Risk Description** | Model accuracy and fairness metrics degrade over time as economic conditions, consumer behaviour, and credit markets evolve, causing the model to make systematically worse or unfair decisions without detection. |
| **Trustworthiness Property** | Reliable; Valid and Verified |
| **AI RMF Categories** | MEASURE 3.1, MEASURE 3.2, MEASURE 3.3, MEASURE 4.1, MG-3.1, MG-3.2 |
| **Likelihood** | High |
| **Impact** | High |
| **Risk Rating** | High |
| **Regulatory Exposure** | SR 11-7 (Model Risk Management — Federal Reserve / OCC); CFPB supervisory expectations |

**Treatment Options:**

1. **Mitigate — Automated monitoring dashboard:** Implement a real-time model performance dashboard tracking: AUC-ROC, Gini coefficient, KS statistic, default rate accuracy, and disaggregated fairness metrics. Set alert thresholds triggering mandatory human review (MEASURE 3.1).
2. **Mitigate — Champion-challenger framework:** Run the production model (champion) alongside a retrained challenger model. Automatically promote the challenger when it outperforms the champion on validated test sets (MG-3.1).
3. **Mitigate — Periodic recalibration schedule:** Establish a defined model recalibration cadence (minimum semi-annual for credit models). Require full revalidation before redeployment (MEASURE 3.2, MG-2.2).
4. **Mitigate — Model owner accountability:** Designate a named model owner responsible for monthly monitoring review sign-off and escalation to the Model Risk Committee when thresholds are breached (GV-2.1, MG-3.1).
5. **Mitigate — Defined kill switch procedure:** Document an emergency model rollback procedure specifying: trigger conditions, authorization chain, fallback scoring method, and customer communication protocol (MG-2.3).

| **Treatment Owner** | Model Risk Management + CRO |
| **Review Frequency** | Monthly automated; Formal review semi-annually or upon threshold breach |

---

### CS-005 — Privacy Violations and Unauthorized Use of Personal Data

| Field | Detail |
|-------|--------|
| **Risk Description** | The model processes sensitive personal financial data. Risks include: use of data beyond consented purposes, re-identification of applicants from model outputs, membership inference attacks revealing whether an individual's data was in training sets, and insufficient data minimization. |
| **Trustworthiness Property** | Privacy-Enhanced |
| **AI RMF Categories** | MAP 1.4, MAP 1.6, MEASURE 2.4, MG-2.1, GV-6.1 |
| **Likelihood** | Medium |
| **Impact** | High |
| **Risk Rating** | High |
| **Regulatory Exposure** | GLBA (Gramm-Leach-Bliley Act), FCRA, CCPA/CPRA (California), GDPR (if EU applicants), EU AI Act Art. 10 |

**Treatment Options:**

1. **Mitigate — Data minimization review:** Audit all model input features against a data minimization standard. Remove features not demonstrably necessary for predictive performance and lawfully collected for this purpose (MAP 1.6, MEASURE 2.4).
2. **Mitigate — Purpose limitation controls:** Implement technical controls ensuring training and inference data cannot be used beyond the stated credit scoring purpose. Document purpose limitation in the model card and data processing agreements (GV-6.1).
3. **Mitigate — Membership inference attack testing:** Conduct membership inference attack simulations to assess whether model outputs could reveal whether specific individuals were in the training data. Apply differential privacy or output perturbation if risk is high (MEASURE 2.4).
4. **Mitigate — Privacy Impact Assessment (PIA):** Conduct a formal PIA before deployment and update it at each major model version change (MAP 1.4, GV-6.2).
5. **Transfer — Contractual controls for third-party data:** Ensure all third-party data suppliers have executed Data Processing Agreements with appropriate restrictions and audit rights (GV-6.1).

| **Treatment Owner** | Chief Privacy Officer + Legal |
| **Review Frequency** | PIA prior to deployment; Annual review; Upon any new data source addition |

---

### CS-006 — Adversarial Manipulation and Model Security

| Field | Detail |
|-------|--------|
| **Risk Description** | Malicious actors could manipulate the credit scoring model through: (1) evasion attacks — crafting loan applications designed to fool the model into approving fraudulent applicants; (2) poisoning attacks — corrupting training data to degrade model behaviour; (3) model extraction — reverse-engineering the scoring model through API queries. |
| **Trustworthiness Property** | Secure and Cyber-Resilient; Resilient |
| **AI RMF Categories** | MAP 5.1, MEASURE 2.4, MEASURE 1.2, MG-2.1, MG-2.3, GV-4.1 |
| **Likelihood** | Medium |
| **Impact** | High |
| **Risk Rating** | High |
| **Regulatory Exposure** | FFIEC Cybersecurity Assessment Tool; GLBA Safeguards Rule; NIST CSF 2.0 |

**Treatment Options:**

1. **Mitigate — Adversarial robustness testing:** Conduct pre-deployment adversarial testing simulating evasion attacks (crafted loan applications) on the model. Measure adversarial accuracy and define an acceptable threshold (MEASURE 2.4).
2. **Mitigate — Training data integrity controls:** Implement data provenance tracking, anomaly detection on training data pipelines, and access controls to prevent unauthorized data injection (poisoning) (MEASURE 1.2).
3. **Mitigate — Rate limiting and query monitoring on scoring API:** Implement API rate limiting, anomaly detection on query patterns, and output perturbation to defend against model extraction attacks. Log and alert on unusual query patterns (MG-2.1).
4. **Mitigate — Model versioning and integrity verification:** Cryptographically sign model artifacts and verify integrity before deployment. Detect unauthorized modifications to model files (MG-2.3).
5. **Mitigate — Red team exercise:** Conduct an annual red team exercise targeting the credit scoring pipeline, including adversarial ML and traditional cybersecurity attack vectors. Feed findings back to MAP and MEASURE (MAP 5.1, MG-4.2).

| **Treatment Owner** | CISO + Model Risk Management |
| **Review Frequency** | Pre-deployment security testing; Annual red team; Continuous API monitoring |

---

### CS-007 — Insufficient Human Oversight and Automation Bias

| Field | Detail |
|-------|--------|
| **Risk Description** | Over-reliance on automated credit decisions without meaningful human review creates risks of unchallenged model errors, inability to exercise discretion for legitimate edge cases, and failure to detect emerging harms. Loan officers may accept model outputs without independent judgment (automation bias). |
| **Trustworthiness Property** | Accountable and Transparent; Safe |
| **AI RMF Categories** | MAP 1.2, MEASURE 2.5, MG-2.2, GV-2.1, GV-3.2 |
| **Likelihood** | Medium |
| **Impact** | High |
| **Risk Rating** | High |
| **Regulatory Exposure** | CFPB guidance on automated decision-making; EU AI Act Art. 14 (Human Oversight for High-Risk AI) |

**Treatment Options:**

1. **Mitigate — Tiered human review policy:** Define clear criteria for mandatory human review: all near-threshold decisions (scores within a defined band of the cut-off), all applications from demographic groups showing elevated error rates, and all appeals (MEASURE 2.5, MG-2.2).
2. **Mitigate — Loan officer training on AI limitations:** Conduct mandatory training for all staff using model outputs, covering: what the model can and cannot do, known limitations, how to identify anomalous outputs, and how to escalate concerns (GV-3.2).
3. **Mitigate — Mandatory override logging:** Require documentation of all human overrides of model recommendations, including reasons. Analyze override patterns to identify model weaknesses (MEASURE 3.3, MG-4.2).
4. **Mitigate — Appeals and reconsideration process:** Implement a formal applicant appeal process with human review of challenged decisions. Document appeal outcomes and feed insights back into model monitoring (MAP 3.4).
5. **Avoid for high-impact decisions:** Define categories of decision (e.g., large commercial loans above a threshold) that require human decision authority and cannot be fully automated (MAP 1.2, GV-5.3).

| **Treatment Owner** | Head of Credit Risk + Operations |
| **Review Frequency** | Semi-annual training refresh; Quarterly override pattern review |

---

### CS-008 — Regulatory Non-Compliance and Governance Gaps

| Field | Detail |
|-------|--------|
| **Risk Description** | Failure to maintain policies, accountability structures, and documentation meeting regulatory expectations for model risk management (SR 11-7), consumer protection (ECOA, FCRA), and AI-specific regulations (EU AI Act). Gaps in governance may result in regulatory enforcement, fines, or required model suspension. |
| **Trustworthiness Property** | Accountable and Transparent |
| **AI RMF Categories** | GV-1.1, GV-1.6, GV-2.2, GV-6.1, GV-6.3, MAP 1.6, MG-4.1 |
| **Likelihood** | Medium |
| **Impact** | Critical |
| **Risk Rating** | High |
| **Regulatory Exposure** | SR 11-7 (Model Risk Management); ECOA; FCRA; EU AI Act Annex IX (Technical Documentation); CFPB |

**Treatment Options:**

1. **Mitigate — Regulatory register:** Maintain a live register of all applicable AI-relevant regulations and their requirements. Assign owners to each regulatory requirement and track compliance status (GV-6.1).
2. **Mitigate — Model inventory and documentation:** Maintain a complete model inventory including: model purpose, version, owner, validation status, last review date, and regulatory classification. Ensure EU AI Act Annex IX technical documentation is maintained for the credit scoring system (GV-1.1, MG-4.1).
3. **Mitigate — AI governance committee:** Establish a formal AI Governance Committee with cross-functional representation (legal, compliance, model risk, data, technology, business). Hold quarterly reviews covering all deployed AI models (GV-4.1, GV-2.2).
4. **Mitigate — Annual compliance assessment:** Conduct an annual assessment of credit scoring model compliance against SR 11-7, ECOA, FCRA, and applicable AI regulations. Engage external counsel or third-party assessor for independent validation (MG-4.1).
5. **Mitigate — Regulatory horizon scanning:** Assign a legal/compliance team member to monitor emerging AI regulations (EU AI Act implementation acts, CFPB guidance updates, state AI laws) and proactively update governance practices (GV-6.3).

| **Treatment Owner** | Chief Compliance Officer + General Counsel |
| **Review Frequency** | Annual formal assessment; Quarterly committee review; Ongoing regulatory monitoring |

---

### CS-009 — Third-Party Model and Data Provider Risk

| Field | Detail |
|-------|--------|
| **Risk Description** | If the credit scoring model is sourced from a third-party vendor, or relies on external data providers (credit bureaus, alternative data), the firm may have limited visibility into model internals, training data, bias testing, and update processes, creating accountability gaps. |
| **Trustworthiness Property** | Accountable and Transparent; Valid and Verified |
| **AI RMF Categories** | GV-3.3, GV-6.1, MAP 1.3, MAP 2.1, MAP 2.2, MEASURE 2.1, MG-2.1 |
| **Likelihood** | Medium |
| **Impact** | High |
| **Risk Rating** | High |
| **Regulatory Exposure** | SR 11-7 (third-party model validation obligations); OCC Guidance on Third-Party Relationships; CFPB |

**Treatment Options:**

1. **Mitigate — Vendor due diligence:** Require third-party AI vendors to provide model cards, bias testing results, validation reports, and change notification procedures before contract execution (MAP 2.1, MAP 2.2).
2. **Mitigate — Contractual rights:** Negotiate contractual rights to: audit vendor model performance, receive timely notification of model changes, access training data documentation, and conduct independent validation (GV-3.3).
3. **Mitigate — Independent validation:** Conduct independent validation of third-party models per SR 11-7 requirements, regardless of vendor-provided documentation. Include fairness testing on firm-specific applicant population (MEASURE 2.1).
4. **Mitigate — Data provider quality controls:** For each external data source, document data quality requirements, validate completeness and accuracy upon each refresh, and assess demographic representativeness (MAP 2.2, MEASURE 1.1).
5. **Transfer — Contractual indemnification:** Negotiate indemnification clauses covering regulatory fines arising from vendor model defects. Obtain evidence of the vendor's own AI risk management programme (MG-2.1).

| **Treatment Owner** | Third-Party Risk Management + Model Risk |
| **Review Frequency** | Due diligence at onboarding; Annual vendor review; Upon each model update notification |

---

### CS-010 — Model Incident Response Gaps

| Field | Detail |
|-------|--------|
| **Risk Description** | Absence of a defined AI incident response plan means that when model failures occur (bias breach, accuracy degradation, adversarial attack, or regulatory finding), the firm lacks a structured process to contain harm, notify affected parties, remediate the model, and document lessons learned. |
| **Trustworthiness Property** | Resilient; Accountable and Transparent |
| **AI RMF Categories** | MG-3.2, MG-3.3, MG-3.4, MG-4.2, GV-4.3, MEASURE 4.1 |
| **Likelihood** | Medium |
| **Impact** | High |
| **Risk Rating** | High |
| **Regulatory Exposure** | SR 11-7; CFPB supervisory expectations; EU AI Act Art. 73 (Serious Incident Reporting) |

**Treatment Options:**

1. **Mitigate — AI incident response plan:** Develop and document a credit scoring model incident response plan covering: (1) Trigger conditions, (2) Contain — suspend or restrict model use, (3) Assess impact — scope of affected applicants, (4) Notify — internal escalation chain, regulatory notification thresholds, customer notification requirements, (5) Remediate — model fix or rollback procedure, (6) Document — incident log and root cause analysis, (7) Update risk register (MG-3.2).
2. **Mitigate — Incident severity classification:** Define incident severity tiers (Low / Medium / High / Critical) with mapped response timelines and authorization levels for each tier (MG-3.2, GV-4.3).
3. **Mitigate — Tabletop exercises:** Conduct annual tabletop exercises simulating a credit scoring model incident (e.g., bias threshold breach discovery or regulatory inquiry). Identify gaps in the response plan and update accordingly (MG-4.2).
4. **Mitigate — Affected applicant remediation process:** Define a process for identifying and remedying harm to applicants affected by model failures, including reconsideration of denied applications (MG-3.4).
5. **Mitigate — Lessons learned loop:** After every incident or near-miss, conduct a post-incident review and feed findings back into GOVERN policies, MAP risk assessments, and MEASURE monitoring thresholds (MG-3.3, MG-4.3).

| **Treatment Owner** | CRO + Head of Model Risk + Compliance |
| **Review Frequency** | Incident plan: Annual review + after every incident; Tabletop: Annual |

---

## Risk Register Summary

| Risk ID | Risk Title | Likelihood | Impact | Risk Rating | Primary AI RMF Categories | Trustworthiness Property |
|---------|-----------|------------|--------|-------------|--------------------------|--------------------------|
| CS-001 | Algorithmic Bias and Discriminatory Decisions | High | Critical | **Critical** | MAP 3.3, MAP 5.2, MEASURE 2.2, MEASURE 3.1, MG-1.1 | Fair / Bias Managed |
| CS-002 | Explainability and Adverse Action Notice Failures | High | Critical | **Critical** | MAP 1.5, MEASURE 2.3, MEASURE 2.6, MG-2.1, GV-6.1 | Explainable and Interpretable |
| CS-003 | Training Data Quality and Historical Bias | High | High | **High** | MAP 2.2, MAP 5.1, MEASURE 1.1, MEASURE 2.2 | Valid and Verified; Fair |
| CS-004 | Model Performance Degradation and Drift | High | High | **High** | MEASURE 3.1, MEASURE 3.2, MEASURE 4.1, MG-3.1 | Reliable; Valid and Verified |
| CS-005 | Privacy Violations and Unauthorized Data Use | Medium | High | **High** | MAP 1.4, MAP 1.6, MEASURE 2.4, GV-6.1 | Privacy-Enhanced |
| CS-006 | Adversarial Manipulation and Model Security | Medium | High | **High** | MAP 5.1, MEASURE 2.4, MG-2.1, MG-2.3 | Secure and Cyber-Resilient |
| CS-007 | Insufficient Human Oversight and Automation Bias | Medium | High | **High** | MAP 1.2, MEASURE 2.5, MG-2.2, GV-3.2 | Accountable and Transparent |
| CS-008 | Regulatory Non-Compliance and Governance Gaps | Medium | Critical | **High** | GV-1.1, GV-1.6, GV-2.2, GV-6.1, MG-4.1 | Accountable and Transparent |
| CS-009 | Third-Party Model and Data Provider Risk | Medium | High | **High** | GV-3.3, MAP 2.1, MAP 2.2, MEASURE 2.1 | Accountable and Transparent |
| CS-010 | Model Incident Response Gaps | Medium | High | **High** | MG-3.2, MG-3.3, MG-4.2, GV-4.3 | Resilient |

---

## AI RMF Coverage Map

The following table shows which AI RMF categories are addressed by this risk register:

| AI RMF Function | Categories Addressed | Coverage |
|----------------|---------------------|----------|
| **GOVERN** | GV-1.1, GV-1.6, GV-2.1, GV-2.2, GV-3.2, GV-3.3, GV-4.1, GV-4.3, GV-5.3, GV-6.1, GV-6.3 | Comprehensive |
| **MAP** | MAP 1.2, MAP 1.3, MAP 1.4, MAP 1.5, MAP 1.6, MAP 2.1, MAP 2.2, MAP 2.3, MAP 3.3, MAP 3.4, MAP 5.1, MAP 5.2, MAP 5.3 | Comprehensive |
| **MEASURE** | MEASURE 1.1, MEASURE 1.2, MEASURE 2.1, MEASURE 2.2, MEASURE 2.3, MEASURE 2.4, MEASURE 2.5, MEASURE 2.6, MEASURE 3.1, MEASURE 3.2, MEASURE 3.3, MEASURE 4.1 | Comprehensive |
| **MANAGE** | MG-1.1, MG-1.3, MG-2.1, MG-2.2, MG-2.3, MG-3.1, MG-3.2, MG-3.3, MG-3.4, MG-4.1, MG-4.2, MG-4.3 | Comprehensive |

---

## Prioritised Treatment Roadmap

### Immediate Actions (Before Deployment)
1. **CS-001:** Complete disaggregated bias testing across all ECOA-protected classes. Halt deployment if Disparate Impact Ratio falls below 0.80 for any group.
2. **CS-002:** Implement SHAP explainability layer and validate adverse action notice generation against Regulation B requirements.
3. **CS-003:** Complete data provenance documentation and proxy variable analysis. Remediate any identified proxy discrimination pathways.
4. **CS-008:** Confirm AI Governance Committee is constituted and model has passed formal pre-deployment review.

### Near-Term Actions (First 90 Days Post-Deployment)
5. **CS-004:** Activate production monitoring dashboard with defined alert thresholds. Assign named model owner.
6. **CS-006:** Deploy API rate limiting and query anomaly detection on the scoring endpoint.
7. **CS-007:** Deliver loan officer training on model limitations and override logging procedures.
8. **CS-010:** Finalize and table-test the AI incident response plan.

### Ongoing Actions (Quarterly / Annual Cycle)
9. **CS-005:** Conduct annual Privacy Impact Assessment update.
10. **CS-009:** Schedule annual third-party vendor review and independent model validation.
11. **CS-004:** Semi-annual model recalibration review.
12. All entries: Annual risk register review and residual risk acceptance sign-off by senior leadership.

---

## Notes for Implementation

**SR 11-7 Alignment:** This risk register supports compliance with the Federal Reserve/OCC Model Risk Management guidance (SR 11-7). Risks CS-002 (validation documentation), CS-003 (data documentation), CS-004 (ongoing monitoring), and CS-009 (third-party validation) directly address SR 11-7 core requirements.

**EU AI Act Classification:** Automated credit scoring is classified as a **high-risk AI system** under EU AI Act Annex III. All entries in this register support compliance with the mandatory requirements in Arts. 9–15 of the Act. Organizations subject to the EU AI Act should treat all "Critical" and "High" rated risks as mandatory remediation items, not optional treatments.

**Implementation Tier Target:** Organizations deploying this model should target NIST AI RMF Implementation Tier 3 (Repeatable) at a minimum, with a roadmap toward Tier 4 (Adaptive) for ongoing bias monitoring and incident learning loops.

**Register Maintenance:** This register should be reviewed:
- Before each model version deployment
- When regulatory requirements change
- Following any model incident or near-miss
- Annually at minimum, with formal senior leadership sign-off on residual risks

# AI Risk Register: Credit Scoring Model
**Organization:** Financial Services Firm
**AI System:** Credit Scoring / Lending Decision Model
**Framework:** NIST AI Risk Management Framework (AI RMF 1.0)
**Document Date:** 2026-04-25
**Review Cycle:** Quarterly

---

## How to Use This Register

Each risk entry maps to one or more NIST AI RMF core functions:
- **GOVERN** – Policies, accountability, culture, and organizational practices
- **MAP** – Context, risk identification, and categorization
- **MEASURE** – Risk analysis, evaluation, and prioritization
- **MANAGE** – Risk response, treatment, and residual risk monitoring

Likelihood and Impact are rated 1 (Low) to 5 (High). Risk Score = Likelihood x Impact.

| Score Range | Rating |
|---|---|
| 1–4 | Low |
| 5–9 | Medium |
| 10–14 | High |
| 15–25 | Critical |

---

## Risk Register

### RISK-001: Algorithmic Bias and Discriminatory Outcomes

| Field | Detail |
|---|---|
| **Risk ID** | RISK-001 |
| **Risk Category** | Fairness / Bias |
| **Description** | The credit scoring model may produce systematically different approval rates or score distributions across protected classes (race, gender, age, national origin, religion, marital status) due to biased training data, proxy variables, or model architecture, violating the Equal Credit Opportunity Act (ECOA) and Fair Housing Act (FHA). |
| **Affected Stakeholders** | Loan applicants, compliance team, regulators (CFPB, OCC), legal counsel |
| **Likelihood** | 4 |
| **Impact** | 5 |
| **Risk Score** | 20 (Critical) |
| **NIST AI RMF Mapping** | MAP 1.5, MAP 2.3, MEASURE 2.5, MEASURE 2.9, MANAGE 2.2 |
| **AI RMF Function** | MAP, MEASURE, MANAGE |

**Treatment Options:**
1. Conduct pre-deployment disparate impact analysis using the four-fifths rule across all protected class proxies
2. Implement fairness-aware machine learning techniques (e.g., reweighting, adversarial debiasing, post-processing calibration)
3. Establish ongoing monitoring dashboards tracking approval rate parity, score distribution parity, and demographic breakdowns
4. Remove or carefully audit proxy variables that correlate with protected characteristics (e.g., zip code, certain employment types)
5. Engage a third-party fair lending audit annually
6. Maintain documented adverse action reason codes that are meaningful and non-discriminatory

**Residual Risk Owner:** Chief Risk Officer / Fair Lending Officer
**Review Frequency:** Monthly monitoring; quarterly deep-dive

---

### RISK-002: Model Performance Degradation Over Time

| Field | Detail |
|---|---|
| **Risk ID** | RISK-002 |
| **Risk Category** | Model Reliability / Accuracy |
| **Description** | The model's predictive accuracy may deteriorate due to concept drift (changing economic conditions, consumer behavior shifts post-COVID, rising interest rates) or data drift (changes in applicant population characteristics), leading to suboptimal lending decisions and increased default rates. |
| **Affected Stakeholders** | Risk management team, credit analysts, investors, regulators |
| **Likelihood** | 4 |
| **Impact** | 4 |
| **Risk Score** | 16 (Critical) |
| **NIST AI RMF Mapping** | MEASURE 2.6, MEASURE 2.7, MANAGE 3.1, MANAGE 3.2 |
| **AI RMF Function** | MEASURE, MANAGE |

**Treatment Options:**
1. Implement statistical process control monitoring (PSI, CSI, KS statistic, Gini coefficient) on a scheduled cadence
2. Define clear model performance thresholds that trigger review or retraining
3. Establish a model retraining pipeline with version control and rollback capability
4. Conduct champion/challenger testing before promoting retrained models to production
5. Maintain a model inventory with documented performance benchmarks for each vintage
6. Schedule annual full model validation by an independent model risk team

**Residual Risk Owner:** Model Risk Management Lead
**Review Frequency:** Monthly performance metrics; annual full validation

---

### RISK-003: Lack of Explainability and Adverse Action Compliance

| Field | Detail |
|---|---|
| **Risk ID** | RISK-003 |
| **Risk Category** | Transparency / Explainability |
| **Description** | Complex ensemble or deep learning credit scoring models may produce decisions that cannot be adequately explained to denied applicants, violating ECOA and Regulation B requirements to provide specific, accurate adverse action reasons. Regulators (CFPB) have increased scrutiny on "black box" models in lending. |
| **Affected Stakeholders** | Denied applicants, compliance team, legal counsel, CFPB, OCC |
| **Likelihood** | 3 |
| **Impact** | 5 |
| **Risk Score** | 15 (Critical) |
| **NIST AI RMF Mapping** | GOVERN 1.2, MAP 1.6, MEASURE 2.8, MANAGE 1.3 |
| **AI RMF Function** | GOVERN, MAP, MEASURE, MANAGE |

**Treatment Options:**
1. Adopt inherently interpretable models (logistic regression, scorecard models) or constrained gradient boosting with explainability layers
2. Implement SHAP (SHapley Additive exPlanations) or LIME to generate per-applicant factor contributions
3. Map model explanations to standard FCRA/Regulation B adverse action reason codes
4. Document the explanation methodology in the model card and model risk management policy
5. Train loan officers and customer service staff on how to communicate denial reasons clearly
6. Conduct quarterly testing to confirm adverse action notices are accurate and legally sufficient

**Residual Risk Owner:** Chief Compliance Officer
**Review Frequency:** Quarterly compliance review; real-time adverse action testing

---

### RISK-004: Training Data Quality and Representativeness

| Field | Detail |
|---|---|
| **Risk ID** | RISK-004 |
| **Risk Category** | Data Integrity / Representativeness |
| **Description** | Training data may contain historical errors, missing values for thin-file applicants, or underrepresentation of certain demographic groups or economic periods, causing the model to perform poorly for specific subpopulations or fail to generalize to new market conditions. |
| **Affected Stakeholders** | Data engineering team, model developers, applicants from underserved communities |
| **Likelihood** | 3 |
| **Impact** | 4 |
| **Risk Score** | 12 (High) |
| **NIST AI RMF Mapping** | MAP 2.1, MAP 2.2, MEASURE 1.3, MEASURE 2.3 |
| **AI RMF Function** | MAP, MEASURE |

**Treatment Options:**
1. Conduct a formal data quality assessment before each training cycle (completeness, consistency, accuracy, timeliness)
2. Document data lineage from source systems through to model inputs
3. Analyze training data demographic distribution and compare to intended deployment population
4. Supplement internal data with alternative data sources (with appropriate privacy and bias review) for thin-file applicants
5. Implement data validation pipelines that flag anomalies before data reaches the feature engineering layer
6. Retain data provenance records for regulatory examination readiness

**Residual Risk Owner:** Chief Data Officer / Data Governance Lead
**Review Frequency:** Per training cycle; quarterly data quality audit

---

### RISK-005: Model Misuse or Scope Creep

| Field | Detail |
|---|---|
| **Risk ID** | RISK-005 |
| **Risk Category** | Governance / Intended Use |
| **Description** | The credit scoring model may be applied to use cases beyond its validated scope (e.g., used for employment screening, insurance pricing, or marketing segmentation), exposing the firm to regulatory violations and reputational harm. |
| **Affected Stakeholders** | Business units, legal counsel, applicants, regulators |
| **Likelihood** | 2 |
| **Impact** | 5 |
| **Risk Score** | 10 (High) |
| **NIST AI RMF Mapping** | GOVERN 1.1, GOVERN 1.7, MAP 1.1, MAP 1.2, MANAGE 1.1 |
| **AI RMF Function** | GOVERN, MAP, MANAGE |

**Treatment Options:**
1. Publish a model use policy that explicitly defines approved use cases and prohibits others
2. Implement access controls restricting which systems and teams can call the model API
3. Require a formal change management process and re-validation before any new use case is approved
4. Conduct annual inventory of all downstream systems consuming model outputs
5. Include scope limitations in the model card and vendor contracts if the model is licensed externally
6. Train business stakeholders on appropriate model use during onboarding and annually

**Residual Risk Owner:** Model Risk Committee
**Review Frequency:** Annual use case inventory; triggered review on any new integration request

---

### RISK-006: Third-Party Vendor and Data Provider Risk

| Field | Detail |
|---|---|
| **Risk ID** | RISK-006 |
| **Risk Category** | Third-Party / Supply Chain Risk |
| **Description** | The model may rely on third-party credit bureau data, alternative data providers, or a vendor-built scoring engine. Vendor failures, data quality issues, changes in data availability, or vendor model updates could degrade performance or introduce compliance gaps without the firm's knowledge. |
| **Affected Stakeholders** | Vendor management team, model risk, procurement, compliance |
| **Likelihood** | 3 |
| **Impact** | 4 |
| **Risk Score** | 12 (High) |
| **NIST AI RMF Mapping** | GOVERN 1.6, MAP 1.3, MANAGE 2.4, MANAGE 4.1 |
| **AI RMF Function** | GOVERN, MAP, MANAGE |

**Treatment Options:**
1. Include contractual obligations for vendors to notify the firm of material changes to data or model components
2. Conduct third-party vendor due diligence assessments (including AI-specific risk questionnaires) at onboarding and annually
3. Establish SLAs covering data quality, uptime, and change notification windows
4. Maintain fallback scoring rules or a backup model for critical vendor outage scenarios
5. Require vendors to provide model documentation sufficient to support regulatory examination
6. Monitor vendor financial health and business continuity capabilities

**Residual Risk Owner:** Vendor Risk Management / Procurement
**Review Frequency:** Annual vendor review; triggered on material vendor changes

---

### RISK-007: Cybersecurity – Model Extraction and Adversarial Attacks

| Field | Detail |
|---|---|
| **Risk ID** | RISK-007 |
| **Risk Category** | Security / Adversarial Robustness |
| **Description** | Malicious actors could query the model systematically to reverse-engineer its logic (model extraction), or craft adversarial inputs designed to manipulate credit scores fraudulently (e.g., gaming income or employment fields to cross approval thresholds). |
| **Affected Stakeholders** | Cybersecurity team, fraud prevention, model risk, applicants |
| **Likelihood** | 2 |
| **Impact** | 4 |
| **Risk Score** | 8 (Medium) |
| **NIST AI RMF Mapping** | GOVERN 1.4, MEASURE 2.2, MANAGE 2.3, MANAGE 3.3 |
| **AI RMF Function** | GOVERN, MEASURE, MANAGE |

**Treatment Options:**
1. Implement rate limiting and anomaly detection on model API endpoints
2. Add query watermarking or noise injection to frustrate model extraction attempts
3. Conduct adversarial robustness testing as part of pre-deployment model validation
4. Monitor for unusual scoring patterns that may indicate score manipulation
5. Restrict direct model output to actionable decisions rather than raw score values where possible
6. Integrate model security considerations into the firm's broader cybersecurity incident response plan

**Residual Risk Owner:** Chief Information Security Officer (CISO)
**Review Frequency:** Quarterly security monitoring; annual penetration testing

---

### RISK-008: Privacy and Data Protection Compliance

| Field | Detail |
|---|---|
| **Risk ID** | RISK-008 |
| **Risk Category** | Privacy / Regulatory Compliance |
| **Description** | The collection, storage, and processing of personal financial data for model training and inference may violate GLBA, CCPA/CPRA, or state-level privacy laws. There is also risk of re-identification of applicants from model outputs or explanations. |
| **Affected Stakeholders** | Applicants, privacy officer, legal counsel, state regulators |
| **Likelihood** | 3 |
| **Impact** | 4 |
| **Risk Score** | 12 (High) |
| **NIST AI RMF Mapping** | GOVERN 1.3, MAP 1.5, MEASURE 2.10, MANAGE 1.4 |
| **AI RMF Function** | GOVERN, MAP, MEASURE, MANAGE |

**Treatment Options:**
1. Conduct a Privacy Impact Assessment (PIA) before model deployment and on each major update
2. Implement data minimization principles — use only the personal data fields strictly necessary for scoring
3. Ensure applicant consent and privacy notices address use of data in automated decision-making
4. Apply differential privacy or data anonymization techniques for model training datasets
5. Establish data retention and deletion policies aligned with GLBA and applicable state law
6. Document the legal basis for processing under each applicable privacy framework

**Residual Risk Owner:** Chief Privacy Officer
**Review Frequency:** Annual PIA refresh; triggered by regulatory changes

---

### RISK-009: Human Oversight Failures in Automated Decisions

| Field | Detail |
|---|---|
| **Risk ID** | RISK-009 |
| **Risk Category** | Human Oversight / Accountability |
| **Description** | Over-reliance on automated credit decisions without adequate human review processes may result in systemic errors going undetected, disproportionate impacts on vulnerable applicants, and reduced organizational ability to override incorrect decisions in a timely manner. |
| **Affected Stakeholders** | Credit analysts, applicants, compliance team, senior management |
| **Likelihood** | 3 |
| **Impact** | 4 |
| **Risk Score** | 12 (High) |
| **NIST AI RMF Mapping** | GOVERN 1.5, GOVERN 2.1, MANAGE 1.2, MANAGE 2.1 |
| **AI RMF Function** | GOVERN, MANAGE |

**Treatment Options:**
1. Define and document which decision types require mandatory human review (e.g., border-line scores, high-value loans, re-applications after denial)
2. Implement an override workflow with audit logging for all human interventions
3. Set escalation protocols for applicants who request reconsideration of automated decisions
4. Train underwriters to critically evaluate, rather than simply ratify, model recommendations
5. Track override rates and outcomes to identify systematic model errors
6. Include human oversight adequacy in model governance committee reporting

**Residual Risk Owner:** Head of Credit / Model Risk Committee
**Review Frequency:** Monthly override rate reporting; quarterly governance review

---

### RISK-010: Regulatory Change and Emerging AI Legislation

| Field | Detail |
|---|---|
| **Risk ID** | RISK-010 |
| **Risk Category** | Regulatory / Legal Compliance |
| **Description** | The regulatory landscape for AI in financial services is evolving rapidly (CFPB guidance on AI in lending, OCC model risk management guidance SR 11-7, potential federal AI Act equivalents, state AI laws). Changes could require significant model redesign, documentation upgrades, or operational changes on short timescales. |
| **Affected Stakeholders** | Legal counsel, compliance team, model risk, executive leadership |
| **Likelihood** | 4 |
| **Impact** | 3 |
| **Risk Score** | 12 (High) |
| **NIST AI RMF Mapping** | GOVERN 1.1, GOVERN 1.7, MAP 1.4, MANAGE 4.2 |
| **AI RMF Function** | GOVERN, MAP, MANAGE |

**Treatment Options:**
1. Assign a regulatory horizon-scanning function to track AI-relevant rulemaking (CFPB, OCC, FRB, FDIC, FTC, state regulators)
2. Maintain a model documentation library that can be rapidly updated to meet new disclosure requirements
3. Engage proactively with industry associations (e.g., ABA, FSB) to anticipate regulatory direction
4. Build modularity into the model architecture to facilitate targeted updates without full redeployment
5. Conduct a regulatory impact assessment whenever a new AI rule or guidance is finalized
6. Include regulatory change risk as a standing agenda item on the Model Risk Committee

**Residual Risk Owner:** Chief Compliance Officer
**Review Frequency:** Ongoing horizon scanning; quarterly regulatory update briefings

---

## Risk Summary Matrix

| Risk ID | Risk Title | Likelihood | Impact | Score | Rating | AI RMF Functions | Primary Owner |
|---|---|---|---|---|---|---|---|
| RISK-001 | Algorithmic Bias / Discrimination | 4 | 5 | 20 | Critical | MAP, MEASURE, MANAGE | Chief Risk Officer |
| RISK-002 | Model Performance Degradation | 4 | 4 | 16 | Critical | MEASURE, MANAGE | Model Risk Lead |
| RISK-003 | Explainability / Adverse Action | 3 | 5 | 15 | Critical | GOVERN, MAP, MEASURE, MANAGE | Chief Compliance Officer |
| RISK-004 | Training Data Quality | 3 | 4 | 12 | High | MAP, MEASURE | Chief Data Officer |
| RISK-005 | Model Misuse / Scope Creep | 2 | 5 | 10 | High | GOVERN, MAP, MANAGE | Model Risk Committee |
| RISK-006 | Third-Party / Vendor Risk | 3 | 4 | 12 | High | GOVERN, MAP, MANAGE | Vendor Risk Management |
| RISK-007 | Cybersecurity / Adversarial Attacks | 2 | 4 | 8 | Medium | GOVERN, MEASURE, MANAGE | CISO |
| RISK-008 | Privacy / Data Protection | 3 | 4 | 12 | High | GOVERN, MAP, MEASURE, MANAGE | Chief Privacy Officer |
| RISK-009 | Human Oversight Failures | 3 | 4 | 12 | High | GOVERN, MANAGE | Head of Credit |
| RISK-010 | Regulatory Change | 4 | 3 | 12 | High | GOVERN, MAP, MANAGE | Chief Compliance Officer |

---

## NIST AI RMF Function Coverage Summary

| AI RMF Function | Risks Covered | Key Focus Areas |
|---|---|---|
| **GOVERN** | RISK-003, RISK-005, RISK-006, RISK-007, RISK-008, RISK-009, RISK-010 | Policies, accountability structures, oversight mechanisms, organizational culture |
| **MAP** | RISK-001, RISK-004, RISK-005, RISK-006, RISK-008, RISK-010 | Risk context, categorization, stakeholder identification, intended use |
| **MEASURE** | RISK-001, RISK-002, RISK-003, RISK-004, RISK-007, RISK-008 | Performance monitoring, bias measurement, explainability assessment |
| **MANAGE** | RISK-001, RISK-002, RISK-003, RISK-005, RISK-006, RISK-007, RISK-008, RISK-009, RISK-010 | Treatment plans, response protocols, residual risk monitoring |

---

## Key Regulatory References

| Regulation / Guidance | Relevance to Credit Scoring AI |
|---|---|
| Equal Credit Opportunity Act (ECOA) / Regulation B | Adverse action notices, prohibited basis discrimination |
| Fair Credit Reporting Act (FCRA) | Use of consumer report data, dispute rights |
| Fair Housing Act (FHA) | Discrimination in mortgage lending |
| CFPB Circular 2022-03 | Fair lending and algorithmic underwriting |
| OCC SR 11-7 / OCC 2011-12 | Model risk management guidance |
| Gramm-Leach-Bliley Act (GLBA) | Financial data privacy obligations |
| CCPA / CPRA | California consumer privacy rights in automated decisions |
| NIST AI RMF 1.0 (2023) | AI risk management lifecycle framework |
| ISO/IEC 42001:2023 | AI management system standard |

---

## Register Maintenance

| Activity | Frequency | Responsible Party |
|---|---|---|
| Risk score review and update | Quarterly | Model Risk Committee |
| Treatment effectiveness assessment | Quarterly | Risk Owners |
| New risk identification | Ongoing / triggered by events | All stakeholders |
| Full register refresh | Annual | Chief Risk Officer |
| Regulatory landscape review | Quarterly | Chief Compliance Officer |
| Executive risk reporting | Monthly (summary) | Model Risk Committee Chair |

# NIST AI RMF ↔ EU AI Act: Framework Mapping and Gap Analysis

## Executive Summary

The NIST AI RMF (AI 100-1, January 2023) and the EU AI Act (Regulation (EU) 2024/1689) are complementary but distinct instruments. The AI RMF is a **voluntary, risk-based framework** providing methodology for managing AI risks throughout the lifecycle. The EU AI Act is **mandatory EU law** imposing specific legal obligations on providers and deployers of in-scope AI systems, with particular requirements for "high-risk" AI systems.

The good news: implementing NIST AI RMF at sufficient maturity provides a strong foundation for EU AI Act compliance — particularly for the Article 9 risk management system requirement. However, the EU AI Act contains mandatory, prescriptive obligations that go beyond what AI RMF covers. Organizations subject to both must treat AI RMF as necessary but not sufficient for EU AI Act compliance.

---

## Part 1: Framework Comparison Overview

| Dimension | NIST AI RMF | EU AI Act |
|-----------|-------------|-----------|
| **Legal nature** | Voluntary guidance | Mandatory regulation (EU law) |
| **Geographic scope** | Global applicability | EU market — applies to providers/deployers placing AI in EU market or affecting EU persons |
| **Approach** | Outcome-based, flexible | Prescriptive, obligation-based |
| **Structure** | Four functions: GOVERN, MAP, MEASURE, MANAGE | Risk classification tiers: Prohibited / High-Risk / Limited-Risk / Minimal-Risk |
| **Primary audience** | Any organization designing, developing, or deploying AI | Providers (developers), deployers (operators), importers, distributors |
| **Enforcement** | No enforcement mechanism | Market surveillance authorities; fines up to €35M or 7% of global turnover |
| **Documentation** | Guidance on what to document; no mandated format | Annex IX mandates specific technical documentation for high-risk AI |
| **Timeline** | Implemented at organizational pace | Phased enforcement from August 2024; high-risk AI provisions apply from August 2026 |

---

## Part 2: Detailed Function-Level Mapping

### GOVERN Function ↔ EU AI Act Obligations

| AI RMF Category | EU AI Act Requirement | Alignment Notes |
|----------------|----------------------|-----------------|
| **GV-1** — AI risk management policies and processes | **Art. 9** — High-risk AI providers must establish, implement, document, and maintain a risk management system | Strong alignment: GV-1's requirement for formalized AI risk management policies directly supports Art. 9 compliance. However, Art. 9 is mandatory and requires documented evidence; GV-1 is aspirational. |
| **GV-1.6** — Policies for complying with applicable laws | **Art. 9, Art. 16, Art. 26** — Legal compliance obligations for providers and deployers | Direct alignment: GV-1.6 requires tracking regulatory requirements; EU AI Act should appear in the regulatory register. |
| **GV-2** — Accountability structures | **Art. 16** — Provider obligations; **Art. 26** — Deployer obligations; **Art. 25** — Distributor/importer responsibilities | Good alignment in principle. AI RMF does not mandate a specific accountability structure; EU AI Act assigns distinct legal obligations by actor type (provider vs. deployer). |
| **GV-3** — Roles and responsibilities | **Art. 16(k)** — Providers must designate an EU-based authorized representative; **Art. 26** — Deployers must assign responsibilities | Partial: GV-3 is broader on roles; EU AI Act adds the legally specific requirement for an EU authorized representative for non-EU providers. |
| **GV-4** — Cross-functional teams | No direct EU AI Act equivalent | Gap: EU AI Act does not mandate cross-functional teams; this is an AI RMF organizational best practice that supports compliance but is not a legal requirement. |
| **GV-5** — Risk tolerance | **Art. 9(2)(a)** — Risk management must be iterative throughout lifecycle | Partial alignment: GV-5 addresses organizational risk tolerance; Art. 9 requires continuous iterative risk management but does not address tolerance thresholds explicitly. |
| **GV-6** — Alignment with laws and principles | **Art. 9, Recital 58, Annex IX** — Technical documentation must demonstrate legal compliance | Strong alignment: GV-6 provides the governance mechanism; EU AI Act mandates the output (demonstrable compliance). |

---

### MAP Function ↔ EU AI Act Obligations

| AI RMF Category | EU AI Act Requirement | Alignment Notes |
|----------------|----------------------|-----------------|
| **MP-1** — Context of intended use established | **Art. 9(2)** — Risk management must cover "intended purpose and reasonably foreseeable misuse"; **Art. 13** — Transparency and provision of information to deployers | Strong alignment: MP-1.2 (intended uses documented and bounded) and MP-1.5 (misuse scoped) map directly to Art. 9(2). EU AI Act additionally requires this information to be provided in Instructions for Use (Annex IX). |
| **MP-1.4** — Affected populations identified | **Art. 9(2)(b)** — Identification and analysis of known and foreseeable risks to health, safety, and fundamental rights | Direct alignment. EU AI Act adds specificity: fundamental rights impact is a distinct category requiring assessment. |
| **MP-2** — Scientific understanding of AI limitations | **Art. 10** — Data governance and management practices; **Art. 15** — Accuracy, robustness, and cybersecurity requirements | Partial: MP-2 addresses documenting limitations; EU AI Act elevates this to a mandatory technical standard that must be demonstrated and tested. |
| **MP-3** — Risks and benefits mapped to stakeholders | **Art. 9(2)(b)** — Risk identification for affected persons; **Art. 27** — Fundamental rights impact assessment for deployers in public-sector contexts | Alignment with gap: MP-3 addresses stakeholder mapping broadly. EU AI Act Art. 27 mandates a formal Fundamental Rights Impact Assessment (FRIA) for certain deployers — a specific artifact not addressed in AI RMF. |
| **MP-4 / MP-5** — Risk prioritization and likelihood/impact characterization | **Art. 9(2)(c)** — Risk estimation and evaluation; **Art. 9(4)** — Residual risks to be evaluated against risk management measures | Strong methodological alignment: AI RMF MAP methodology directly supports Art. 9's risk estimation requirement. |

---

### MEASURE Function ↔ EU AI Act Obligations

| AI RMF Category | EU AI Act Requirement | Alignment Notes |
|----------------|----------------------|-----------------|
| **MS-1** — Measurement approaches identified | **Art. 15** — Accuracy, robustness, and cybersecurity must be addressed with appropriate metrics; **Art. 10(2)** — Data quality criteria | Good alignment: MS-1 supports Art. 15 by establishing a measurement methodology. EU AI Act requires specific performance levels for accuracy and robustness without prescribing exact metrics. |
| **MS-2** — System evaluation for trustworthiness | **Art. 9(6)** — Testing must be performed before market placement; **Art. 10** — Data governance including bias examination; **Art. 15** — Accuracy, robustness, and cybersecurity | Strong alignment: MS-2 subcategories (bias testing, explainability, security assessment, human oversight validation) map closely to Art. 9 and Art. 15. EU AI Act adds that testing must occur "at appropriate times" before market placement — making it a legal prerequisite, not a best practice. |
| **MS-2.3** — Explainability tested | **Art. 13** — Transparency; high-risk AI systems must be designed to allow deployers to interpret outputs | Alignment with gap: MS-2.3 addresses explainability from a measurement perspective. Art. 13 mandates that Instructions for Use include information enabling deployers to interpret outputs — this is a product documentation obligation beyond testing. |
| **MS-2.5** — Human oversight mechanisms tested | **Art. 14** — Human oversight — high-risk AI must enable effective human oversight; specific operator capabilities must be designed in | Strong alignment: MS-2.5 validates human oversight mechanisms. Art. 14 is more prescriptive: it mandates specific technical characteristics (ability to pause, override, disregard, or discontinue use) that must be designed in and documented. |
| **MS-3** — Ongoing monitoring | **Art. 72** — Post-market monitoring obligation for providers; deployers must report to providers; **Art. 26(5)** — Deployer monitoring obligations | Strong alignment: MS-3 covers ongoing monitoring and drift detection. Art. 72 makes post-market monitoring a legal obligation with a required Post-Market Monitoring Plan (a specific documented artifact). |
| **MS-4** — Feedback informs MANAGE | **Art. 72** — Monitoring data must feed into risk management system | Alignment: MS-4 establishes the feedback loop; Art. 72 makes this mandatory with specific reporting obligations to market surveillance authorities. |

---

### MANAGE Function ↔ EU AI Act Obligations

| AI RMF Category | EU AI Act Requirement | Alignment Notes |
|----------------|----------------------|-----------------|
| **MG-1** — Risks prioritized and documented | **Art. 9(2)(d)** — Adoption of risk management measures; residual risks evaluated | Good alignment: MG-1 provides the process; EU AI Act requires this to be demonstrated through technical documentation (Annex IX). |
| **MG-2** — Risk treatment strategies | **Art. 9(2)(d)** — Risk management measures for each identified risk; measures to address residual risks | Alignment with gap: MG-2's treatment options (mitigate, transfer, avoid, accept) align with Art. 9. EU AI Act adds a hierarchy of obligations — certain risks cannot simply be "accepted" if they exceed thresholds; the system may not be permitted. |
| **MG-2.3** — Emergency interventions | **Art. 14(4)(d)** — Human oversight must include ability to interrupt or stop the AI system | Direct alignment: MG-2.3 and Art. 14(4)(d) both require defined shutdown/override procedures. |
| **MG-3** — Incident response | **Art. 73** — Providers must report serious incidents to national market surveillance authorities; deployers must notify providers | Alignment with important gap: MG-3 covers internal incident response. Art. 73 mandates external regulatory reporting of serious incidents (death, serious injury, breach of fundamental rights obligations, serious damage to property or environment) within prescribed timeframes. |
| **MG-4** — Review and improvement | **Art. 9(1)** — Risk management system is a "continuous iterative process" throughout the lifecycle | Strong alignment: MG-4's continuous improvement loop maps directly to Art. 9's iterative process requirement. |

---

## Part 3: Gap Analysis — What AI RMF Does NOT Cover

The following EU AI Act requirements have no direct NIST AI RMF equivalent and represent compliance gaps that organizations must fill with additional controls, processes, and documentation.

### Gap 1: Prohibited AI Practices (Article 5)
**EU AI Act requirement:** Certain AI practices are absolutely prohibited, regardless of safeguards. These include:
- Real-time remote biometric identification in public spaces by law enforcement (with limited exceptions)
- AI systems that exploit vulnerabilities of persons (age, disability, social/economic situation)
- Social scoring by public authorities
- Untargeted scraping of facial images from the internet or CCTV
- AI systems to infer emotions in workplace or educational settings
- Biometric categorization to infer protected characteristics

**AI RMF gap:** The AI RMF is a risk management framework — it does not prohibit any AI practice outright. Organizations subject to the EU AI Act must establish a pre-deployment screening process to identify and prohibit any AI system that falls into Article 5 categories before AI RMF risk management processes are even initiated.

**Action required:** Create an AI Use Case Screening Policy that maps proposed AI systems against Art. 5 prohibited practices and treats any match as a go/no-go disqualifier.

---

### Gap 2: Risk Classification and Tiering (Articles 6–7 and Annexes II–III)
**EU AI Act requirement:** Providers must classify their AI systems into the correct risk tier (prohibited, high-risk, limited-risk, minimal-risk). High-risk classification is determined by reference to Annex II (product safety regulation sectors) and Annex III (specific use cases including biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice, and democratic processes).

**AI RMF gap:** AI RMF has no concept of mandatory risk classification by regulatory tier. MP-4 covers risk prioritization, but this is based on organizational judgment — not a legal classification determination.

**Action required:** Establish a formal EU AI Act Classification Procedure. For each AI system, determine: (1) Does it fall under Annex II product safety regulations? (2) Does it fall under Annex III high-risk use case categories? Document the classification determination with reasoning. This must be done before EU AI Act obligations are applied.

---

### Gap 3: Conformity Assessment (Articles 43–49)
**EU AI Act requirement:** High-risk AI systems must undergo a conformity assessment before being placed on the EU market. For most Annex III systems, this is a self-assessment by the provider. For certain biometric and critical infrastructure systems (Annex II), third-party conformity assessment by a notified body is required. Providers must draw up an EU Declaration of Conformity and affix the CE marking.

**AI RMF gap:** AI RMF has no conformity assessment requirement, CE marking process, or Declaration of Conformity. The framework's MEASURE function evaluates trustworthiness but does not produce the specific legal artifact required.

**Action required:** Implement a conformity assessment process for high-risk AI systems. Map AI RMF MEASURE outputs to the evidence required for conformity assessment. Engage a notified body where mandatory third-party assessment is required. Maintain the EU Declaration of Conformity.

---

### Gap 4: Technical Documentation — Annex IX
**EU AI Act requirement:** Providers of high-risk AI systems must prepare and maintain technical documentation as specified in Annex IX before market placement. This documentation is distinct and more specific than what AI RMF guidance suggests. It must include: system description, intended purpose, design specifications, training data description, testing methods and results, risk management documentation, post-market monitoring plan, instructions for use, and Declaration of Conformity.

**AI RMF gap:** AI RMF guidance suggests documenting model cards, risk registers, and assessment results, but does not specify the exact document structure required. The AI RMF does not produce Annex IX-compliant technical documentation as an output.

**Action required:** Develop an Annex IX Technical Documentation Template. Map existing AI RMF outputs (model cards from MP-2, risk register from MAP/MANAGE, evaluation results from MEASURE) to the required Annex IX sections. Identify documentation gaps and close them.

---

### Gap 5: Transparency and User Information — Article 13 and Instructions for Use
**EU AI Act requirement:** High-risk AI systems must be accompanied by Instructions for Use that enable deployers to correctly use the system and understand its capabilities and limitations. For systems interacting with natural persons, those persons must be informed they are interacting with an AI system (Art. 50). Certain systems generating synthetic content must include technical solutions for marking content as AI-generated (watermarking obligation).

**AI RMF gap:** AI RMF addresses transparency as a trustworthiness property and recommends explainability testing (MS-2.3), but does not mandate specific user-facing documentation or transparency mechanisms. The Instructions for Use obligation and the content watermarking/labelling obligation are not covered.

**Action required:** Develop standardized Instructions for Use for each high-risk AI system. Implement AI interaction disclosure mechanisms where the system interacts with natural persons. Assess applicability of content watermarking obligations for generative AI systems.

---

### Gap 6: Fundamental Rights Impact Assessment — Article 27
**EU AI Act requirement:** Deployers (not providers) of high-risk AI systems that are bodies governed by public law, or private operators providing public services, must conduct a Fundamental Rights Impact Assessment (FRIA) before deploying the system. The FRIA must assess the impact on fundamental rights, including equality, non-discrimination, privacy, and protection of personal data.

**AI RMF gap:** MP-3 (stakeholder risk/benefit mapping) and MP-5 (likelihood/impact characterization) together cover much of what a FRIA requires. However, the EU AI Act FRIA is a specific, legally required assessment with a defined scope (fundamental rights) and obligation to notify supervisory authorities in certain cases. AI RMF does not produce this artifact.

**Action required:** For in-scope deployers, develop a FRIA template aligned with EDPB and national authority guidance. Integrate FRIA outputs into the MAP 3 and MP-5 process so the work is not duplicated, but ensure the FRIA meets the legal standard as a distinct deliverable.

---

### Gap 7: Regulatory Registration — EU Database (Article 71)
**EU AI Act requirement:** Providers of standalone high-risk AI systems (Annex III, not embedded in regulated products) must register themselves and their AI systems in the EU AI public database maintained by the European AI Office before market placement.

**AI RMF gap:** No registration obligation exists in the AI RMF. This is an external administrative compliance step with no AI RMF equivalent.

**Action required:** Identify all Annex III high-risk AI systems requiring registration. Prepare registration submissions for the EU AI Act public database. Assign responsibility for maintaining registrations when systems are updated or withdrawn.

---

### Gap 8: Incident Reporting to Authorities — Article 73
**EU AI Act requirement:** Providers must report serious incidents — defined as incidents resulting in death, serious injury, breach of obligations under Union law on fundamental rights, significant property or environmental damage — to national market surveillance authorities. Reporting timelines are specified (15 days for death/serious injury risk; 10 days for serious incidents; 3 months for unexpectedly high risk). Deployers must report to providers immediately upon identifying serious incidents.

**AI RMF gap:** MG-3 (incident response) and MG-3.4 (stakeholder notification) address incident management and notification internally. The AI RMF does not address mandatory external regulatory reporting, specific reporting timelines, or reporting to market surveillance authorities.

**Action required:** Extend the AI incident response procedure (MG-3) to include a regulatory reporting track. Define internal escalation criteria and timelines that trigger regulatory notification under Art. 73. Identify the relevant national market surveillance authorities for each jurisdiction where high-risk AI systems are deployed.

---

### Gap 9: Post-Market Monitoring Plan — Article 72
**EU AI Act requirement:** Providers must establish, document, and implement a Post-Market Monitoring (PMM) system. The PMM must include a Post-Market Monitoring Plan (a required document). The PMM must actively gather and analyse data on deployed systems to identify risks and incidents throughout the system's lifecycle.

**AI RMF gap:** MS-3 (ongoing monitoring) and MG-3 (risk responses monitored) together address post-deployment monitoring in principle. However, the AI RMF does not require a formal Post-Market Monitoring Plan as a specific documented artifact, and does not specify reporting back to competent authorities.

**Action required:** Formalise existing MS-3 monitoring activities into a documented Post-Market Monitoring Plan for each high-risk AI system. The plan should specify: monitoring objectives, data sources, monitoring frequency, responsible parties, triggers for Art. 73 reporting, and process for feeding findings back into the Art. 9 risk management system.

---

### Gap 10: Obligations Specific to General-Purpose AI (GPAI) Models — Articles 51–56
**EU AI Act requirement:** Providers of General-Purpose AI (GPAI) models — including large language models and foundation models made available via API or open-source — have specific obligations: transparency to downstream providers (model cards, technical documentation), copyright policy, energy consumption reporting. GPAI models with "systemic risk" (training compute above 10^25 FLOPs, or designated by the AI Office) have additional obligations: adversarial testing, incident reporting, cybersecurity measures, and efficiency reporting.

**AI RMF gap:** AI RMF does not distinguish GPAI models as a specific category requiring distinct treatment. The framework applies uniformly to all AI systems. The GPAI obligations, including the systemic risk designation and associated enhanced requirements, are entirely outside AI RMF scope.

**Action required:** If your organization develops or deploys GPAI models, conduct a separate GPAI obligation assessment. Determine whether any models meet the systemic risk threshold. Implement GPAI-specific transparency documentation (Art. 53) and, if applicable, systemic risk management measures (Art. 55).

---

## Part 4: Consolidated Gap Summary Table

| Gap Area | EU AI Act Articles | AI RMF Gap | Priority | Action |
|----------|-------------------|------------|----------|--------|
| Prohibited AI screening | Art. 5 | No prohibition concept in AI RMF | Critical | Create AI Use Case Screening Policy against Art. 5 |
| Risk tier classification | Art. 6–7, Annex II–III | No mandatory regulatory tier classification | Critical | Establish EU AI Act Classification Procedure for all AI systems |
| Conformity assessment and CE marking | Art. 43–49 | No conformity assessment process | High | Implement conformity assessment; engage notified body where required |
| Annex IX technical documentation | Annex IX | AI RMF outputs do not match Annex IX structure | High | Develop Annex IX templates mapping from AI RMF artifacts |
| Instructions for Use and transparency | Art. 13, Art. 50 | AI RMF does not mandate user-facing documentation | High | Develop Instructions for Use; implement AI interaction disclosures |
| Fundamental Rights Impact Assessment | Art. 27 | MP-3/MP-5 cover substance but not the legal artifact | High | Develop FRIA template for in-scope deployers |
| EU AI Act public database registration | Art. 71 | No registration obligation in AI RMF | Medium | Register high-risk Annex III systems in EU AI database |
| Regulatory incident reporting | Art. 73 | MG-3 covers internal response only | High | Extend incident procedure with regulatory reporting track and timelines |
| Post-Market Monitoring Plan | Art. 72 | MS-3 covers monitoring activity but not the formal plan artifact | Medium | Formalise MS-3 outputs into a documented PMM Plan per system |
| GPAI model obligations | Art. 51–56 | GPAI models not distinguished in AI RMF | Varies | GPAI obligation assessment if applicable |

---

## Part 5: Implementation Recommendations

### For Organizations Subject to Both Frameworks

**Step 1 — Classify before you manage.**
Before applying AI RMF processes, determine the EU AI Act risk classification of each AI system. Prohibited systems must be stopped. High-risk systems require the full EU AI Act compliance programme. Limited-risk and minimal-risk systems can be managed primarily through AI RMF.

**Step 2 — Use AI RMF as the methodology for Art. 9 compliance.**
Article 9's risk management system requirement is the most substantive EU AI Act obligation. Implementing GOVERN, MAP, MEASURE, and MANAGE at AI RMF Tier 3 (Repeatable) maturity provides the strongest available methodology for satisfying Art. 9. Document this explicitly — regulators and notified bodies understand AI RMF.

**Step 3 — Build EU-specific artifacts on top of AI RMF outputs.**
The AI RMF produces many of the inputs needed for EU AI Act documentation (risk assessments, evaluation results, monitoring records). The gaps are largely about converting those outputs into the specific legally required artifacts: Annex IX technical documentation, Declarations of Conformity, Post-Market Monitoring Plans, FRIAs. Build templates that systematically map AI RMF outputs to EU AI Act document requirements.

**Step 4 — Add EU-specific processes for the structural gaps.**
Five areas require wholly new processes not analogous to anything in AI RMF: (1) Art. 5 prohibited use screening, (2) risk tier classification under Annex II/III, (3) conformity assessment and CE marking, (4) EU database registration, and (5) Art. 73 regulatory incident reporting. These should be added as formal procedures layered on top of the AI RMF programme.

**Step 5 — Assign the EU AI Act as a regulatory register entry under GV-6.**
GV-1.6 and GV-6 require maintaining a regulatory register. The EU AI Act — with its specific applicability dates, obligations per actor type (provider vs. deployer), and enforcement milestones — should be a fully documented entry in this register with assigned compliance owners.

---

## Summary

Implementing NIST AI RMF provides approximately 60–70% of the substantive risk management capability needed for EU AI Act compliance, particularly for Article 9's risk management system requirement. The remaining gaps are not minor — they include mandatory legal classification, conformity assessment, prescribed documentation formats, prohibited use screening, and regulatory reporting obligations that are simply outside the AI RMF's voluntary, methodology-focused scope.

The two frameworks are designed to complement each other: use AI RMF as the risk management methodology and operating framework, and layer EU AI Act-specific legal compliance obligations on top. Organizations that implement AI RMF at Tier 3 maturity and then close the ten identified gaps will be well-positioned for EU AI Act compliance for high-risk AI systems.

# NIST AI RMF and EU AI Act: Framework Mapping and Gap Analysis

## Executive Summary

The NIST AI Risk Management Framework (AI RMF 1.0) and the EU AI Act are complementary but distinct instruments. The AI RMF is a voluntary, flexible risk management framework developed by NIST (published January 2023), while the EU AI Act is mandatory EU legislation with binding legal obligations, enforcement mechanisms, and penalties. Organizations subject to the EU AI Act that have adopted the AI RMF will find significant conceptual overlap but must address meaningful compliance gaps to satisfy their legal obligations.

---

## 1. Overview of Each Framework

### NIST AI RMF 1.0

The NIST AI RMF organizes AI risk management around four core functions:

- **GOVERN**: Establish organizational policies, culture, and accountability structures for AI risk management.
- **MAP**: Identify and categorize AI risks in context.
- **MEASURE**: Analyze and assess identified risks using qualitative and quantitative methods.
- **RESPOND**: Prioritize and act on risks; develop and implement risk response plans.

The framework is principles-based and technology-neutral. It does not prescribe specific controls but provides a structured approach to managing AI risks across the AI lifecycle.

### EU AI Act

The EU AI Act (Regulation (EU) 2024/1689, fully applicable from August 2026) establishes a risk-based regulatory regime with four risk tiers:

- **Unacceptable risk**: Prohibited AI practices (e.g., social scoring, real-time remote biometric identification in public spaces with narrow exceptions).
- **High-risk**: Mandatory pre-market and post-market requirements (Annexes I and III systems, including critical infrastructure, employment, education, essential services, law enforcement, migration, justice, biometrics).
- **Limited risk**: Transparency obligations (e.g., chatbots, deepfakes).
- **Minimal risk**: No specific requirements.

The Act creates legal obligations for **providers** (developers/deployers who place AI on the EU market) and **deployers** (organizations putting AI into use), with specific duties varying by role.

---

## 2. Conceptual Alignment: Where AI RMF and the EU AI Act Converge

### 2.1 Risk-Based Approach

Both frameworks share a foundational risk-based philosophy: the level of scrutiny and controls applied to an AI system should be proportionate to the risks it poses.

| AI RMF Concept | EU AI Act Equivalent |
|---|---|
| Risk tiering via MAP function | Four-tier risk classification (prohibited, high-risk, limited risk, minimal risk) |
| Contextual risk assessment (MAP 1.x) | Risk assessment for high-risk AI systems (Art. 9) |
| Risk response planning (RESPOND) | Risk management system requirements (Art. 9) |

### 2.2 Documentation and Record-Keeping

| AI RMF | EU AI Act |
|---|---|
| GOVERN 1.7: Document AI risk management policies | Art. 11: Technical documentation (Annex IV) |
| MEASURE 2.5: Document evaluation results | Art. 12: Record-keeping and logging |
| GOVERN 6.1: Policies governing AI supply chain | Art. 25: Obligations for third-party providers |

### 2.3 Human Oversight

| AI RMF | EU AI Act |
|---|---|
| GOVERN 5.1: Organizational roles for oversight | Art. 14: Human oversight measures |
| RESPOND 1.1: Monitor and respond to AI outputs | Art. 14(4): Operator ability to intervene/halt |
| MAP 5.1: Impacts on humans identified | Art. 9(2): Risk identification for natural persons |

### 2.4 Transparency and Explainability

| AI RMF | EU AI Act |
|---|---|
| GOVERN 4.1: Transparency practices established | Art. 13: Transparency and provision of information |
| MEASURE 2.9: Explainability assessed | Art. 13(1): High-risk systems must be interpretable |
| MAP 2.3: Scientific basis for AI claims documented | Art. 13(2): Instructions for use |

### 2.5 Testing, Validation, and Performance Monitoring

| AI RMF | EU AI Act |
|---|---|
| MEASURE 2.2: AI system testing and evaluation | Art. 9(6): Testing for risk management |
| MEASURE 2.6: Bias and fairness evaluation | Art. 10(2): Training data governance; Art. 9(7): Bias testing |
| RESPOND 2.1: Monitoring in deployment | Art. 72: Post-market monitoring system |

### 2.6 Incident Response

| AI RMF | EU AI Act |
|---|---|
| RESPOND 1.3: Incident response procedures | Art. 73: Reporting of serious incidents |
| RESPOND 2.2: Remediation plans | Art. 20: Corrective actions |

---

## 3. Gap Analysis: What AI RMF Does Not Cover That the EU AI Act Requires

Implementing the NIST AI RMF provides a strong foundation but leaves the following EU AI Act obligations unaddressed or only partially addressed:

### 3.1 Prohibited Practices (Art. 5) — No AI RMF Equivalent

The EU AI Act absolutely prohibits certain AI applications. The AI RMF has no analogous prohibition mechanism — it treats all AI systems as candidates for risk management rather than outright banning any practice.

**Action required:** Conduct an inventory of all AI systems and explicitly screen for prohibited use cases before applying risk management processes. Document the screening and confirm no prohibited applications are deployed.

Prohibited practices include:
- Subliminal manipulation causing harm
- Exploitation of vulnerable groups
- Social scoring by public authorities
- Real-time remote biometric identification in public spaces (with narrow exceptions)
- Predictive policing based solely on profiling
- Emotion recognition in workplace/educational settings (with exceptions)
- Biometric categorization to infer sensitive attributes

### 3.2 Mandatory Conformity Assessment (Art. 43) — Not Addressed by AI RMF

High-risk AI systems must undergo a formal conformity assessment before market placement:
- **Self-assessment** is permissible for most Annex III systems if the provider follows harmonized standards.
- **Third-party assessment** by a notified body is required for certain systems (e.g., biometric identification, critical infrastructure).

The AI RMF does not require any external assessment or certification. It is entirely self-directed.

**Action required:** Determine whether your high-risk AI systems require third-party conformity assessment. Engage a notified body where required. Maintain conformity assessment documentation and affix the CE marking as applicable.

### 3.3 EU Declaration of Conformity and CE Marking (Arts. 47–49)

Providers of high-risk AI systems must draw up an EU Declaration of Conformity and affix the CE marking before placing the system on the EU market.

The AI RMF has no concept of market placement declarations or regulatory markings.

**Action required:** Establish a process to prepare and maintain EU Declarations of Conformity. Integrate CE marking into the product release workflow.

### 3.4 Registration in the EU Database (Art. 71)

Providers of high-risk AI systems listed in Annex III must register in the EU AI Act public database before deployment. Deployers of certain public-sector high-risk systems also have registration obligations.

The AI RMF has no registry or public disclosure requirement.

**Action required:** Register all applicable high-risk AI systems in the EU public database. Assign responsibility for maintaining registration records and updating entries upon significant modifications.

### 3.5 Specific Data Governance Requirements (Art. 10)

The EU AI Act mandates detailed data governance for training, validation, and testing datasets for high-risk AI systems, including requirements related to:
- Relevance, representativeness, and freedom from errors
- Statistical properties appropriate to the intended purpose
- Examination for biases

While the AI RMF addresses data quality and bias (MEASURE 2.6, GOVERN 1.5), it does not impose the specific statutory data governance obligations of Art. 10, which have regulatory force.

**Action required:** Implement a formal data governance program specifically aligned with Art. 10 requirements. Document dataset characteristics, data lineage, bias testing methodology, and corrective measures taken.

### 3.6 Fundamental Rights Impact Assessment (Art. 27)

Deployers of high-risk AI systems that are public bodies, or private entities providing public services in certain categories (credit, insurance, education, employment, essential services), must conduct a Fundamental Rights Impact Assessment (FRIA) prior to deployment.

The AI RMF does not include a fundamental rights assessment. Its fairness and bias considerations (MAP 5.x, MEASURE 2.6) are narrower and not rights-based in the legal sense.

**Action required:** Determine whether your organization is subject to the FRIA requirement. If so, develop and document a FRIA methodology covering the AI system's impact on the rights enumerated in the EU Charter of Fundamental Rights. Notify relevant supervisory bodies where required.

### 3.7 Specific Obligations for General-Purpose AI (GPAI) Models (Arts. 51–56)

The EU AI Act introduces a separate regulatory regime for General-Purpose AI (GPAI) models — including large language models and foundation models — distinct from the requirements for specific AI systems:

- **All GPAI providers**: Must maintain technical documentation, provide model information to downstream providers, and comply with copyright rules.
- **Systemic-risk GPAI providers** (training compute > 10^25 FLOPs or designated by the Commission): Must conduct adversarial testing, report serious incidents to the Commission, ensure cybersecurity protections, and report on energy consumption.

The AI RMF does not distinguish between GPAI/foundation models and narrow AI systems, and does not address supply-chain-level model obligations.

**Action required:** Identify whether your organization develops or deploys GPAI models. If developing, prepare technical documentation per Annex XI/XII and implement copyright compliance procedures. If operating a systemic-risk model, establish adversarial testing programs and incident reporting to the AI Office.

### 3.8 Serious Incident Reporting to Authorities (Art. 73)

Providers must report serious incidents (death, serious injury, environmental damage, significant disruption of critical infrastructure, or violations of fundamental rights) to national market surveillance authorities within defined timeframes (typically 15 days for death/serious injury, 3 months for other serious incidents). Deployers must notify providers.

The AI RMF includes incident response practices (RESPOND 1.3) but does not specify regulatory reporting timelines or the specific thresholds triggering mandatory notification.

**Action required:** Establish a formal incident classification process that maps to EU AI Act severity thresholds. Implement reporting workflows with defined escalation paths and timelines. Identify the competent national market surveillance authority.

### 3.9 Obligations Specific to Deployers (Art. 26)

The EU AI Act distinguishes between providers and deployers and imposes specific duties on deployers:
- Use AI systems in accordance with instructions for use.
- Assign human oversight to competent individuals.
- Monitor AI system operation and report issues to providers.
- Inform affected workers or their representatives about AI use.
- For employment/education use cases: inform natural persons subject to the AI system.

The AI RMF is largely organization-centric and does not map to the provider/deployer legal distinction.

**Action required:** Clearly determine your role (provider, deployer, or both) for each AI system. Implement deployer-specific obligations including worker notification, human oversight assignment, and operational monitoring tied to provider instructions.

### 3.10 AI Literacy Requirements (Art. 4)

Providers and deployers must ensure a sufficient level of AI literacy among their staff and persons who operate AI systems on their behalf.

The AI RMF addresses organizational culture and governance (GOVERN 1.4, GOVERN 6.2) but does not mandate a formal AI literacy program.

**Action required:** Develop and implement a documented AI literacy program. Define minimum competency standards by role and maintain training records demonstrating compliance.

### 3.11 Market Surveillance and Enforcement Cooperation (Arts. 74–100)

The EU AI Act establishes national competent authorities, a European AI Office, and an AI Board with enforcement powers including:
- Requesting documentation and conducting audits
- Ordering corrective actions, market withdrawals, and recalls
- Imposing fines (up to EUR 35 million or 7% of global turnover for prohibited practice violations)

The AI RMF has no enforcement dimension whatsoever.

**Action required:** Designate a point of contact for regulatory inquiries. Ensure documentation is audit-ready and accessible. Prepare response procedures for potential market surveillance authority requests.

---

## 4. Harmonized Standards and AI RMF as Compliance Evidence

The EU AI Act permits providers to demonstrate conformity through adherence to harmonized European standards once published (Art. 40). CEN-CENELEC Joint Technical Committee JTC 21 is developing harmonized standards, and NIST AI RMF practices may serve as evidence of conformity for certain requirements — particularly around risk management systems, data governance, and transparency — once mapping is established through standardization work.

However, until harmonized standards are finalized and formally referenced in the EU Official Journal, organizations should treat AI RMF implementation as a compliance input, not a substitute for direct EU AI Act compliance analysis.

---

## 5. Prioritized Action Plan

For organizations implementing AI RMF that also need to achieve EU AI Act compliance, the following priorities are recommended:

**Immediate (before August 2026 full applicability):**

1. Classify all AI systems against EU AI Act risk tiers; identify any prohibited use cases and cease or redesign them.
2. Identify all high-risk AI systems per Annex I and Annex III; map provider vs. deployer roles.
3. Conduct fundamental rights impact assessments where required.
4. Register high-risk systems in the EU AI database.

**Short-term (establish compliance infrastructure):**

5. Develop Annex IV technical documentation for all high-risk AI systems.
6. Implement Art. 10-compliant data governance processes.
7. Establish conformity assessment procedures; engage notified bodies where required.
8. Prepare EU Declarations of Conformity and CE marking workflows.

**Ongoing:**

9. Implement post-market monitoring systems (Art. 72) integrated with RESPOND function practices.
10. Establish serious incident reporting procedures and test escalation paths.
11. Deploy AI literacy program and maintain training records.
12. Monitor GPAI model obligations if applicable; prepare technical documentation.
13. Maintain audit-readiness; assign regulatory liaison responsibilities.

---

## 6. Summary Table: AI RMF to EU AI Act Mapping

| EU AI Act Requirement | AI RMF Coverage | Gap Level |
|---|---|---|
| Risk-based classification | Partial (MAP function) | Medium — RMF lacks legal tier definitions |
| Prohibited practices screening | None | Critical |
| Risk management system (Art. 9) | Strong (MAP + MEASURE + RESPOND) | Low |
| Data governance (Art. 10) | Partial (MEASURE 2.6) | Medium |
| Technical documentation (Art. 11) | Partial (GOVERN 1.7, MEASURE 2.5) | Medium |
| Logging and record-keeping (Art. 12) | Partial (MEASURE 2.5) | Medium |
| Transparency (Art. 13) | Partial (GOVERN 4.1) | Medium |
| Human oversight (Art. 14) | Partial (GOVERN 5.1) | Low-Medium |
| Accuracy, robustness, cybersecurity (Art. 15) | Partial (MEASURE 2.x) | Medium |
| Conformity assessment (Art. 43) | None | High |
| EU Declaration of Conformity (Art. 47) | None | High |
| CE marking (Art. 49) | None | High |
| EU database registration (Art. 71) | None | High |
| Post-market monitoring (Art. 72) | Partial (RESPOND 2.1) | Low-Medium |
| Serious incident reporting (Art. 73) | Partial (RESPOND 1.3) | Medium-High |
| Deployer-specific obligations (Art. 26) | Partial | Medium |
| GPAI model obligations (Arts. 51–56) | None | High (if applicable) |
| Fundamental rights impact assessment (Art. 27) | None | High (if applicable) |
| AI literacy (Art. 4) | Partial (GOVERN 1.4) | Medium |
| Enforcement cooperation | None | Procedural |

**Gap levels:** Low = minor supplementation needed; Medium = additional documentation/processes required; High = significant new compliance work required; Critical = potential legal violation if unaddressed.

---

## Conclusion

The NIST AI RMF provides a strong risk management foundation that aligns well with the EU AI Act's risk management system requirements, transparency expectations, and human oversight principles. However, the AI RMF is a voluntary management tool, not a compliance framework, and implementing it alone does not satisfy EU AI Act legal obligations.

The most critical gaps are: prohibited practices screening, mandatory conformity assessment, CE marking, EU database registration, GPAI-specific obligations, and formal fundamental rights impact assessments. Organizations should treat AI RMF implementation as the operational backbone of their AI governance program while layering EU AI Act-specific legal requirements on top of that foundation.

# NIST AI RMF — GOVERN Gap Assessment

**Organization Context:** AI ethics statement exists. No formal AI risk policy. No cross-functional AI team. No defined AI risk tolerance. Legal team not involved in AI deployments.

**Assessment Date:** 2026-04-25

**Current Maturity Tier:** Tier 1 — Partial (ad hoc; ethics intent present but no operationalized risk management)

---

## Section 1: GOVERN Category Ratings

| Category | Title | Rating | Current State | Gap Summary |
|----------|-------|--------|---------------|-------------|
| GV-1 | Policies, Processes, Procedures and Practices | 🔴 Not Started | AI ethics statement only; no formal AI risk management policy; no ERM integration; no review cadence; no regulatory compliance process | No GV-1 subcategory is implemented. Ethics statement provides aspirational intent but does not constitute policy. All 7 subcategories (GV-1.1 through GV-1.7) are absent. |
| GV-2 | Accountability Structures | 🔴 Not Started | No designated AI risk owner; no senior official accountable for AI risk; no board-level AI risk reporting | No one is formally accountable for AI risk outcomes. Without an appointed owner, accountability cannot be enforced. All 3 subcategories (GV-2.1 through GV-2.3) are absent. |
| GV-3 | Roles and Responsibilities | 🔴 Not Started | No AI roles register; responsibilities not mapped to lifecycle stages; business owners not assigned AI accountability | AI lifecycle roles (design, development, deployment, decommission) are undefined. Technical and non-technical accountability for AI outcomes is not documented. |
| GV-4 | Cross-Functional Team Collaboration | 🔴 Not Started | No cross-functional AI team; legal explicitly not involved; no escalation path for AI risks; no inter-team communication processes for AI risk | GV-4.1, GV-4.2, and GV-4.3 are all absent. Legal non-involvement is a direct violation of GV-4.1 requirements. No escalation mechanisms exist. |
| GV-5 | Organizational Risk Tolerance for AI | 🔴 Not Started | No AI risk tolerance statement; no deployment checklist; no go/no-go criteria for AI system launch | Without defined risk tolerance, deployment decisions for AI systems have no principled basis. All 3 subcategories (GV-5.1 through GV-5.3) are absent. |
| GV-6 | AI Risk Aligned to Laws, Regulations and Principles | 🟡 Partial | Ethics statement provides ethical principles alignment at a surface level; no regulatory register; legal team not engaged; no proactive regulatory monitoring | GV-6.2 is partially addressed by the ethics statement in intent only. GV-6.1 and GV-6.3 are absent. Legal non-involvement means regulatory requirements (EU AI Act, sector-specific laws) are not being tracked or applied. |

---

## Section 2: Subcategory Detail by Category

### GV-1 — Policies, Processes, Procedures and Practices

| Subcategory | Description | Status | Evidence Required to Close |
|-------------|-------------|--------|---------------------------|
| GV-1.1 | AI risk integrated into enterprise risk management (ERM) | 🔴 Not Started | AI risk agenda item in ERM committee; ERM policy updated to include AI |
| GV-1.2 | Trustworthy AI characteristics integrated into policies | 🔴 Not Started | Published AI Risk Policy referencing all seven trustworthiness properties |
| GV-1.3 | Organizational risk tolerance established and communicated | 🔴 Not Started | Approved AI risk appetite statement with defined thresholds |
| GV-1.4 | Culture of risk awareness and continuous improvement | 🔴 Not Started | AI risk training programme; leadership messaging on risk culture |
| GV-1.5 | AI risk policies reviewed on periodic cadence | 🔴 Not Started | Policy review schedule; documented review records |
| GV-1.6 | Policies for complying with applicable AI laws established | 🔴 Not Started | Regulatory register; legal sign-off on AI deployments |
| GV-1.7 | Processes for reviewing policies to incorporate emerging risks | 🔴 Not Started | Regulatory horizon scanning process; policy update workflow |

### GV-2 — Accountability Structures

| Subcategory | Description | Status | Evidence Required to Close |
|-------------|-------------|--------|---------------------------|
| GV-2.1 | AI risk roles and responsibilities documented across levels | 🔴 Not Started | RACI matrix for AI risk management decisions |
| GV-2.2 | Senior official designated accountable for AI risk | 🔴 Not Started | Formal appointment of AI Risk Owner; board reporting line established |
| GV-2.3 | Executive leadership understands AI risk | 🔴 Not Started | Executive AI risk briefing; AI risk on leadership dashboard |

### GV-3 — Roles and Responsibilities

| Subcategory | Description | Status | Evidence Required to Close |
|-------------|-------------|--------|---------------------------|
| GV-3.1 | AI risk roles span full lifecycle | 🔴 Not Started | Lifecycle roles register from design through decommission |
| GV-3.2 | Responsibilities defined for development teams, operators, deployers | 🔴 Not Started | Job descriptions or role charters updated with AI risk responsibilities |
| GV-3.3 | Responsibilities assigned to technical and non-technical roles | 🔴 Not Started | Business owner AI accountability documented; non-technical training |

### GV-4 — Cross-Functional Team Collaboration

| Subcategory | Description | Status | Evidence Required to Close |
|-------------|-------------|--------|---------------------------|
| GV-4.1 | Cross-functional AI risk team includes legal, privacy, security, HR, ethics | 🔴 Not Started | AI Risk Working Group charter with named representatives from each function |
| GV-4.2 | Processes for communicating AI risks between teams documented | 🔴 Not Started | AI risk communication protocol; defined reporting cadence |
| GV-4.3 | Mechanisms for escalating AI risk concerns established | 🔴 Not Started | Escalation path from development teams to executive level; escalation log |

### GV-5 — Organizational Risk Tolerance for AI

| Subcategory | Description | Status | Evidence Required to Close |
|-------------|-------------|--------|---------------------------|
| GV-5.1 | AI risk tolerance defined reflecting organizational values | 🔴 Not Started | Approved AI risk appetite statement linked to ethics statement |
| GV-5.2 | Risk tolerance reviewed when new AI systems deployed | 🔴 Not Started | Deployment review checklist; tolerance review records |
| GV-5.3 | Risk tolerance informs go/no-go deployment decisions | 🔴 Not Started | Pre-deployment gate with risk tolerance validation |

### GV-6 — AI Risk Aligned to Laws, Regulations, and Principles

| Subcategory | Description | Status | Evidence Required to Close |
|-------------|-------------|--------|---------------------------|
| GV-6.1 | Legal and regulatory requirements for AI identified and tracked | 🔴 Not Started | Regulatory register for applicable AI laws (EU AI Act, state laws, sector-specific) |
| GV-6.2 | AI risk management processes aligned with ethical principles | 🟡 Partial | Ethics statement exists; gap is operationalizing it into binding policy and process |
| GV-6.3 | Organization engages proactively with emerging AI regulations | 🔴 Not Started | Regulatory monitoring process; legal team participation in AI governance |

---

## Section 3: Trustworthy AI Properties Most at Risk

Given the GOVERN gaps identified, the following trustworthiness properties are most exposed:

| Trustworthy AI Property | Risk Exposure | Reason |
|------------------------|---------------|--------|
| **Accountable and Transparent** | Critical | No accountability structure (GV-2 absent); no one responsible for AI outcomes |
| **Fair / Bias Managed** | High | No risk tolerance thresholds for bias (GV-5 absent); no legal or ethics review of deployments |
| **Safe** | High | No formal policy defining acceptable harm levels (GV-1.3 absent); no cross-functional safety review (GV-4 absent) |
| **Privacy-Enhanced** | High | Legal not involved in deployments (GV-4.1 absent); no regulatory compliance process (GV-6.1 absent) |
| **Valid and Verified** | High | No deployment gate criteria (GV-5.3 absent); no pre-deployment validation requirements |
| **Secure and Cyber-Resilient** | Medium | Security function not formally included in AI governance (GV-4.1 absent) |
| **Explainable and Interpretable** | Medium | No policy requirement for explainability documentation (GV-1.2 absent) |

---

## Section 4: Overall GOVERN Maturity Score

| Category | Score (0–3) | Rationale |
|----------|-------------|-----------|
| GV-1 | 0 | No policy exists beyond ethics statement |
| GV-2 | 0 | No accountability structure in place |
| GV-3 | 0 | No roles or responsibilities defined |
| GV-4 | 0 | No cross-functional team; legal excluded |
| GV-5 | 0 | No risk tolerance defined |
| GV-6 | 0.5 | Ethics statement provides partial ethical principles alignment only |
| **Overall GOVERN** | **0.1 / 3** | **Tier 1 — Partial** |

---

## Section 5: Prioritised Remediation Roadmap

Priority scoring reflects: regulatory exposure + deployment risk + foundational dependency (items that block other remediation work scored highest).

### Priority 1 — Quick Wins (0–60 days): Establish the Foundation

These actions establish the minimum viable governance foundation and unblock all subsequent work.

| Action | GOVERN Category | Owner | Effort | Outcome |
|--------|----------------|-------|--------|---------|
| **1.1** Appoint an AI Risk Owner with executive sponsor | GV-2.2 | CEO / Board | Low | Formal accountability established; unblocks all other actions |
| **1.2** Convene an AI Risk Working Group — invite Legal, Privacy, Security, HR, Ethics, Engineering | GV-4.1 | AI Risk Owner | Low | Cross-functional oversight operational; closes GV-4.1 |
| **1.3** Produce a regulatory register: identify applicable AI laws (EU AI Act if EU-facing, relevant state laws, sector-specific) | GV-6.1 | Legal + AI Risk Owner | Medium | Legal exposure mapped; closes GV-6.1 |
| **1.4** Establish a legal review gate for all new AI deployments | GV-4.1, GV-6.1 | Legal + Engineering | Low | Closes the legal non-involvement gap immediately |
| **1.5** Draft and approve an AI Risk Appetite Statement linked to the existing ethics statement | GV-5.1, GV-1.3 | AI Risk Owner + Executive | Medium | Defines risk tolerance; enables deployment decision criteria |

### Priority 2 — Short Term (60–120 days): Formalize Policy and Structure

| Action | GOVERN Category | Owner | Effort | Outcome |
|--------|----------------|-------|--------|---------|
| **2.1** Publish an AI Risk Management Policy signed by senior leadership, incorporating trustworthy AI properties | GV-1.1, GV-1.2 | AI Risk Owner + Legal | High | Formal policy closes GV-1.1 and GV-1.2; supersedes ethics statement as operative document |
| **2.2** Create an AI Roles Register mapping lifecycle stages (design, build, deploy, monitor, decommission) to responsible roles | GV-3.1, GV-3.2, GV-3.3 | AI Risk Owner + HR | Medium | Closes all three GV-3 subcategories |
| **2.3** Define RACI for AI risk decisions; assign senior official as accountable owner at board level | GV-2.1, GV-2.2, GV-2.3 | CEO + AI Risk Owner | Medium | Closes GV-2; establishes board-level AI risk visibility |
| **2.4** Document AI risk communication protocol and escalation path (development → management → executive) | GV-4.2, GV-4.3 | AI Risk Owner | Low | Closes GV-4.2 and GV-4.3 |
| **2.5** Create a pre-deployment AI checklist validating systems against risk appetite statement | GV-5.2, GV-5.3 | Engineering + Legal | Medium | Operationalizes risk tolerance into deployment gate |

### Priority 3 — Medium Term (120–180 days): Integrate and Institutionalise

| Action | GOVERN Category | Owner | Effort | Outcome |
|--------|----------------|-------|--------|---------|
| **3.1** Integrate AI risk into Enterprise Risk Management (ERM) — add AI risk to ERM committee agenda and quarterly reporting | GV-1.1 | Chief Risk Officer + AI Risk Owner | Medium | AI risk visible at enterprise level; closes GV-1.1 integration requirement |
| **3.2** Launch AI risk awareness training for technical and non-technical staff | GV-1.4, GV-3.3 | HR + AI Risk Owner | Medium | Embeds risk culture; closes GV-1.4 |
| **3.3** Establish regulatory horizon scanning process — subscribe to EU AI Act updates, NIST publications, sector-specific guidance | GV-6.3, GV-1.7 | Legal + AI Risk Owner | Low | Proactive regulatory monitoring; closes GV-6.3 and GV-1.7 |
| **3.4** Set AI Risk Policy review schedule — annual minimum with trigger-based reviews on new deployments or regulatory changes | GV-1.5, GV-5.2 | AI Risk Owner | Low | Closes GV-1.5; ensures governance remains current |
| **3.5** Conduct executive AI risk briefing; include AI risk KPIs on leadership dashboard | GV-2.3 | AI Risk Owner | Low | Closes GV-2.3; leadership accountability for AI outcomes |

### Priority 4 — Long Term (180+ days): Optimise and Demonstrate

| Action | GOVERN Category | Owner | Effort | Outcome |
|--------|----------------|-------|--------|---------|
| **4.1** Commission external assessment or third-party audit of AI governance programme | All GOVERN | AI Risk Owner | High | Independent validation of maturity; identifies residual gaps |
| **4.2** Align AI Risk Policy to ISO/IEC 42001:2023 — consider certification pathway | GV-1, GV-2, GV-5, GV-6 | AI Risk Owner + Legal | High | International standard alignment; supports ISO 42001 Clause 5/6 obligations |
| **4.3** Operationalize ethics statement into binding internal principles document with measurable commitments | GV-6.2 | Ethics + Legal + AI Risk Owner | Medium | Fully closes GV-6.2 with documented, auditable principles |
| **4.4** Define AI risk tolerance thresholds per system category (e.g., recommendation engine vs. individual decision-making) with specific bias/accuracy metrics | GV-5.1 | AI Risk Owner + Data Science | High | Quantified risk tolerance enabling objective go/no-go decisions |

---

## Section 6: Critical Path Dependencies

The following sequence must be respected — later items depend on earlier completions:

```
Appoint AI Risk Owner (1.1)
  └─► Convene Working Group (1.2)
        └─► Legal Review Gate (1.4) ──► Regulatory Register (1.3)
  └─► AI Risk Appetite Statement (1.5)
        └─► AI Risk Management Policy (2.1)
              └─► Roles Register (2.2)
              └─► RACI (2.3)
              └─► Pre-Deployment Checklist (2.5)
                    └─► ERM Integration (3.1)
                          └─► External Audit (4.1)
```

The single most important immediate action is appointing an AI Risk Owner. Without a named accountable person, no other remediation item can progress effectively.

---

## Section 7: Immediate Legal Exposure Note

The fact that the legal team is not involved in AI deployments creates immediate compliance exposure across multiple regulatory regimes:

- **EU AI Act (if in scope):** Art. 9 requires a risk management system for high-risk AI providers; Art. 16 and 26 impose obligations on providers and deployers. Legal non-involvement means these obligations may be unmet for any in-scope AI system.
- **Sector-specific obligations:** Depending on sector (financial services, healthcare, HR/recruitment), AI systems may already be subject to binding regulatory requirements (ECOA, HIPAA, EEOC) that require documented compliance review before deployment.
- **Data privacy:** AI systems processing personal data require legal review to satisfy GDPR, CCPA, or applicable privacy laws — which currently has no gate.

**Recommended immediate action:** Before the next AI system is deployed, implement Priority 1.4 (legal review gate) regardless of the broader roadmap timeline.

---

## Section 8: Target Profile

Recommended target maturity for each GOVERN category within 12 months:

| Category | Current Score | 6-Month Target | 12-Month Target |
|----------|---------------|----------------|-----------------|
| GV-1 | 0 (Tier 1) | 1.5 (Tier 2) | 2.5 (Tier 3) |
| GV-2 | 0 (Tier 1) | 2.0 (Tier 2–3) | 3.0 (Tier 3) |
| GV-3 | 0 (Tier 1) | 1.5 (Tier 2) | 2.5 (Tier 3) |
| GV-4 | 0 (Tier 1) | 2.0 (Tier 2–3) | 3.0 (Tier 3) |
| GV-5 | 0 (Tier 1) | 1.5 (Tier 2) | 2.0 (Tier 2–3) |
| GV-6 | 0.5 (Tier 1) | 1.5 (Tier 2) | 2.5 (Tier 3) |

Achieving Tier 3 (Repeatable) across all GOVERN categories within 12 months is an aggressive but achievable target given the organization already has an ethics statement as a cultural foundation to build on.

---

*Assessment based on NIST AI 100-1 (January 2023) and the AI RMF Playbook. Categories cited as GV-1 through GV-6 correspond to the GOVERN function subcategories defined in the AI RMF Core.*

# NIST AI RMF GOVERN Gap Assessment

**Assessment Date:** 2026-04-25
**Framework:** NIST AI Risk Management Framework (AI RMF 1.0) — GOVERN Function

---

## Executive Summary

This assessment evaluates your organization's current posture against the GOVERN function of the NIST AI RMF. The GOVERN function establishes the policies, processes, procedures, and practices that enable AI risk management across the organization. Based on the information provided — an AI ethics statement exists, but no formal AI risk policy, no cross-functional AI team, no defined risk tolerance for AI, and no legal involvement in AI deployments — your organization has foundational awareness but significant structural gaps.

**Overall GOVERN Maturity: Low (Level 1 of 4)**

---

## GOVERN Category Ratings

The NIST AI RMF GOVERN function contains six subcategories (GV.1 through GV.6). Each is rated below on a four-point scale:

- **4 — Optimizing:** Processes are mature, measured, and continuously improved
- **3 — Defined:** Formal processes are documented and consistently followed
- **2 — Developing:** Some practices exist but are informal or inconsistent
- **1 — Initial:** Little to no formal practice; ad hoc or absent

---

### GV.1 — Organizational Policies, Processes, Procedures, and Practices for AI Risk Management

**Rating: 2 — Developing**

**What exists:** An AI ethics statement is in place, which demonstrates organizational intent and leadership awareness of AI-related concerns. This is a meaningful starting point.

**Gaps identified:**
- No formal AI risk management policy exists. The ethics statement sets aspirational values but does not create enforceable obligations or operational procedures.
- There is no defined process for how AI risk is identified, escalated, or resolved.
- No procedures govern the AI system lifecycle (development, procurement, deployment, retirement).
- No governance body (board, committee, or executive owner) has been formally assigned accountability for AI risk.

**Impact:** Without a formal policy, risk management activities are discretionary and inconsistent. Teams cannot make reliable decisions about acceptable AI uses or required controls.

---

### GV.2 — Accountability Mechanisms for AI Risk Management

**Rating: 1 — Initial**

**What exists:** Nothing formal has been identified.

**Gaps identified:**
- No cross-functional AI team or governance committee exists to own AI risk decisions.
- Accountability for AI deployments appears to reside informally with individual teams or business units, creating siloed decision-making.
- No roles and responsibilities (RACI matrix or equivalent) have been defined for AI risk management.
- There is no mechanism for escalating AI-related concerns to leadership.
- No audit or review process exists to verify that AI systems are being managed appropriately.

**Impact:** Without clear accountability, AI risk management cannot be executed consistently. Gaps are likely to go unidentified until an incident occurs.

---

### GV.3 — Organizational Teams Are Committed to Transparency and Accountability

**Rating: 2 — Developing**

**What exists:** The AI ethics statement implies a commitment to ethical behavior, which touches on transparency and accountability values.

**Gaps identified:**
- Transparency commitments are stated in the ethics document but are not operationalized. There are no disclosure requirements, documentation standards, or explainability requirements for AI systems.
- No formal process exists for documenting AI system decisions, design choices, or risk trade-offs.
- There is no mechanism for affected parties (employees, customers) to raise concerns about AI system behavior.
- Legal team non-involvement means that legal obligations around transparency (consumer protection, regulatory disclosure) are not being assessed.

**Impact:** The gap between stated values and operational practice creates legal and reputational exposure, particularly as AI-specific regulations mature globally.

---

### GV.4 — Organizational Teams Are Committed to Diversity, Equity, Inclusion, and Accessibility (DEIA) in AI

**Rating: 1 — Initial**

**What exists:** The ethics statement may reference fairness or non-discrimination, but no operational DEIA controls for AI have been identified.

**Gaps identified:**
- No process exists to assess AI systems for bias, disparate impact, or accessibility limitations.
- No diversity requirements exist for AI development teams or governance bodies.
- No mechanisms for monitoring AI outputs for discriminatory patterns have been established.
- Legal non-involvement means fair lending, equal opportunity, and anti-discrimination obligations are not being factored into AI deployments.

**Impact:** Unmitigated bias in AI systems creates regulatory liability (under equal opportunity, consumer protection, and emerging AI laws) and direct harm to affected populations.

---

### GV.5 — Organizational Risk Tolerance for AI Is Established

**Rating: 1 — Initial**

**What exists:** Nothing. No risk tolerance for AI has been defined.

**Gaps identified:**
- There is no formal statement of what level of AI risk the organization is willing to accept in pursuit of business objectives.
- No criteria exist for categorizing AI use cases by risk level (high/medium/low).
- Without risk tolerance, there is no basis for deciding which AI systems require enhanced controls, independent review, or executive approval before deployment.
- No process exists to align AI risk appetite with the organization's broader enterprise risk management framework.

**Impact:** This is the most fundamental gap. Risk tolerance is the foundation on which all other AI risk controls are calibrated. Its absence means the organization cannot make principled, defensible decisions about AI deployment.

---

### GV.6 — Policies and Procedures for AI Risk Management Incorporate Legal Requirements

**Rating: 1 — Initial**

**What exists:** Nothing. Legal is not involved in AI deployments.

**Gaps identified:**
- Legal, compliance, and privacy functions are not part of the AI deployment process.
- No review process exists to assess whether an AI use case triggers applicable laws or regulations (e.g., EU AI Act, state AI laws, sector-specific regulations, data protection law).
- Contractual obligations to third parties regarding AI use (in vendor agreements, customer terms) are not being evaluated.
- Intellectual property considerations for AI-generated outputs are not being assessed.
- No process exists for monitoring changes in the AI regulatory environment.

**Impact:** This gap creates direct legal liability. As AI-specific regulation accelerates globally and across US states, organizations without legal involvement in AI are likely to find themselves non-compliant with enforceable obligations.

---

## Summary Ratings Table

| GOVERN Category | Description | Rating | Score |
|---|---|---|---|
| GV.1 | Organizational AI Risk Policies | Developing | 2/4 |
| GV.2 | Accountability Mechanisms | Initial | 1/4 |
| GV.3 | Transparency and Accountability Commitment | Developing | 2/4 |
| GV.4 | DEIA in AI | Initial | 1/4 |
| GV.5 | AI Risk Tolerance | Initial | 1/4 |
| GV.6 | Legal Requirements Integration | Initial | 1/4 |
| **Overall** | | **Initial** | **1.3/4** |

---

## Prioritised Remediation Plan

Remediation items are sequenced by: (1) foundational dependency — some items unlock others; (2) risk exposure — items that create legal liability or enable the next worst-case scenario are prioritized; (3) effort relative to impact.

---

### Priority 1 — Immediate (0–60 days): Establish the Foundation

These actions are prerequisites for everything else. They are low-cost relative to their impact and unblock subsequent work.

**1.1 Define AI Risk Tolerance (Addresses GV.5)**

Convene a working session with executive leadership (CEO, CTO, CFO, General Counsel, Chief Risk Officer if applicable) to define the organization's AI risk appetite. The output should be a written statement that:
- Defines what AI risk means in your business context
- Categorizes AI use cases into risk tiers (e.g., high/medium/low based on consequence severity)
- States which risk tiers require mandatory controls or approval gates before deployment
- Aligns AI risk tolerance with the broader enterprise risk tolerance

This is the single most important action because it gives every other remediation item a benchmark to work toward.

**1.2 Engage Legal in AI Deployments Immediately (Addresses GV.6)**

Require legal team sign-off on all AI deployments currently in progress or planned in the next 90 days. In parallel:
- Brief the General Counsel on the current AI landscape and the EU AI Act, US state AI laws, and applicable sector regulations
- Establish a standing obligation for legal review at the start and end of each AI project
- Assign a legal team member as the AI legal liaison

This should not wait for a full program to be built. Legal exposure is accumulating with each deployment that proceeds without review.

**1.3 Inventory Current AI Systems (Prerequisite for GV.1, GV.2, GV.4, GV.6)**

Conduct a rapid inventory of all AI systems currently in use or in development. For each, capture: purpose, data used, business owner, deployment date, and any known risks. This inventory does not need to be exhaustive on day one — it needs to be sufficient to understand current exposure.

---

### Priority 2 — Short-Term (60–120 days): Build Core Structures

**2.1 Establish a Cross-Functional AI Governance Body (Addresses GV.2)**

Form an AI Risk Committee or AI Governance Council with representatives from:
- Technology / Engineering
- Legal and Compliance
- Privacy / Data Protection
- Business (rotating representation from AI-using business units)
- HR (for AI systems affecting employees)
- Risk Management

Define a charter that specifies: meeting cadence, decision rights, escalation paths, and reporting line to executive leadership. This body will own the AI risk policy and review high-risk AI deployments.

**2.2 Develop a Formal AI Risk Policy (Addresses GV.1)**

Evolve the existing ethics statement into an enforceable AI risk policy. The policy should:
- Reference and expand upon the ethics statement
- Define scope (which systems are covered)
- Establish the AI system lifecycle stages and required activities at each stage
- Define roles and responsibilities
- Reference the risk tolerance tiers established in step 1.1
- Specify legal and compliance review requirements
- Define documentation standards

The policy should be approved by executive leadership and the board (or equivalent governance body) to ensure it carries organizational authority.

**2.3 Define Accountability Structures (Addresses GV.2)**

Publish a RACI matrix for AI risk management that defines who is Responsible, Accountable, Consulted, and Informed for key decisions including: AI system approval, risk assessments, incident response, and regulatory compliance. Assign an executive sponsor for AI risk (e.g., Chief AI Officer, CTO, or Chief Risk Officer).

---

### Priority 3 — Medium-Term (120–180 days): Operationalize Controls

**3.1 Implement AI Risk Assessment Process (Addresses GV.1, GV.5)**

Using the risk tolerance tiers defined in Priority 1, create a risk assessment process for new AI deployments. High-risk AI systems should require a formal impact assessment before deployment. The process should integrate with existing project management and procurement workflows.

**3.2 Establish Bias and Fairness Review Process (Addresses GV.4)**

Develop a lightweight process for evaluating AI systems for potential disparate impact or bias. At minimum, this should include:
- A bias risk screening questionnaire for all AI systems
- A defined review process for AI systems that score above a threshold
- Documentation requirements for bias testing conducted during development or procurement

Engage legal and HR in this process to connect it to equal opportunity and consumer protection obligations.

**3.3 Operationalize Transparency Requirements (Addresses GV.3)**

Convert the transparency commitments in the ethics statement into operational requirements:
- Define what documentation must be produced for each AI system (model cards, data sheets, or equivalent)
- Establish disclosure requirements for customer-facing AI (where applicable)
- Create a mechanism for employees and customers to raise concerns about AI system behavior

---

### Priority 4 — Ongoing (180+ days): Mature and Improve

**4.1 Integrate AI Risk into Enterprise Risk Management**

Connect the AI risk framework to the organization's existing ERM process. AI risks should appear on the enterprise risk register and be reviewed alongside other strategic and operational risks.

**4.2 Establish Regulatory Monitoring**

Assign responsibility (likely to legal and compliance) for monitoring AI regulatory developments globally and in relevant jurisdictions. Establish a process to assess the impact of new regulations on the organization's AI systems and practices.

**4.3 Implement Metrics and Continuous Improvement**

Define key performance indicators for AI risk management (e.g., percentage of AI systems with completed risk assessments, time to complete legal review, number of open remediation items). Report these metrics to the AI Governance Council and executive leadership quarterly.

**4.4 Conduct Periodic Governance Reviews**

Schedule an annual review of the AI risk policy, risk tolerance statement, and governance structure. As the AI landscape and regulatory environment evolve, the framework will need to evolve with it.

---

## Remediation Roadmap Summary

| Priority | Timeframe | Actions | Primary Gaps Addressed |
|---|---|---|---|
| 1 | 0–60 days | Define AI risk tolerance; engage legal; inventory AI systems | GV.5, GV.6 |
| 2 | 60–120 days | Form AI governance body; develop formal policy; define accountability | GV.1, GV.2 |
| 3 | 120–180 days | Risk assessment process; bias review; transparency requirements | GV.1, GV.3, GV.4, GV.5 |
| 4 | 180+ days | ERM integration; regulatory monitoring; metrics; periodic review | GV.1, GV.2, GV.3, GV.6 |

---

## Key Observations

**Strengths to build on:** The existence of an AI ethics statement is a meaningful signal that leadership has acknowledged AI as a domain requiring attention. This creates a cultural foundation and a reference document that can anchor the formal policy work in Priority 2.

**Most critical gap:** The absence of legal involvement in AI deployments (GV.6 rating: 1) combined with the lack of risk tolerance (GV.5 rating: 1) represents the highest immediate risk. AI-specific regulation is accelerating, and each deployment that proceeds without legal review creates accumulating liability.

**Dependency to manage:** The AI risk policy (GV.1) and governance body (GV.2) cannot be well-designed until the risk tolerance (GV.5) is defined. The sequencing in Priority 1 is deliberate — defining risk tolerance first prevents the common failure mode of building a governance structure with no clear mandate.

**Quick win:** Engaging legal immediately (item 1.2) costs little and has an outsized impact on both actual risk and organizational posture. It also sends a clear internal signal that AI governance is being taken seriously.

---

*Assessment based on NIST AI Risk Management Framework (AI RMF 1.0), published January 2023. GOVERN function subcategories reference the AI RMF Playbook guidance.*

# SWIFT CSP Architecture Scoping and CSCF v2025 Applicability Matrix

**Institution Profile:** Mid-tier regional bank  
**Connectivity:** Alliance Access software, customer-managed, on-premises servers  
**Hardware Security Modules (HSMs):** None  
**Service Bureau:** Not used  
**Cloud SWIFT:** Not used  
**Framework Version:** CSCF v2025 (effective July 2025)  
**Assessment Date:** 2026-04-25

---

## 1. Architecture Type Determination

Based on the described connectivity profile, your institution is classified as **Architecture Type A1**.

### Rationale

| Criterion | Your Environment | A1 Criteria |
|-----------|-----------------|-------------|
| Connector type | Customer connector | Customer connector |
| Management model | Customer-managed (your own staff, your own servers) | Customer-managed |
| Implementation type | Software-based (Alliance Access) | Software-based |
| HSMs | None | Not required for A1 |
| Service bureau | Not used | Not applicable |
| Cloud hosting | Not used | Not applicable |

**Conclusion:** Alliance Access running on your own on-premises servers, without HSMs, without outsourcing to a service bureau, and without SWIFT-hosted or cloud components, is the defining profile of an **A1 (Customer Connector, Customer-Managed, Software-Based)** architecture. This is the most common architecture for large and mid-tier banks with direct SWIFT connectivity.

### A1 Characteristics Relevant to Compliance Scope

As an A1 institution, you bear **full operational responsibility** for your SWIFT infrastructure. You own and manage:

- The servers running Alliance Access
- The operating systems and middleware on those servers
- Physical security of the data centre housing the servers
- All network controls protecting the SWIFT Secure Zone
- All operator access mechanisms

This means you have the **broadest mandatory control scope** among all architecture types. Unlike A3 (SWIFT-managed component) or B (service bureau), there is no shared responsibility with a third party to reduce your obligation. All 23 mandatory controls apply to you in full.

---

## 2. CSCF v2025 Applicability Matrix — Architecture Type A1

The following matrix provides the full picture of all 31 CSCF v2025 controls for an A1 institution. Controls marked as Not Applicable (N/A) for other types (A3/A4) that become applicable for A1 are highlighted.

### Legend

| Symbol | Meaning |
|--------|---------|
| **MANDATORY** | Must be implemented and attested; non-compliance must be disclosed in KYC-SA |
| **ADVISORY** | Strongly recommended best practice; not subject to mandatory attestation but assessed for maturity |
| N/A | Not applicable to this architecture type (none for A1) |

---

### Objective 1 — Secure Your Environment (Controls 1.x, 2.x, 3.x)

| Control ID | Control Name | A1 Status | Notes for A1 Institutions |
|------------|-------------|-----------|--------------------------|
| **1.1** | SWIFT Environment Protection | **MANDATORY** | Establish a dedicated Secure Zone isolating all Alliance Access servers and SWIFT workstations. Firewall with deny-by-default rules between SWIFT zone and corporate network. No dual-homing. |
| **1.2** | OS Privileged Account Control | **MANDATORY** | A1-specific: You manage your own OS, so you must control root/local admin accounts on Alliance Access servers. No routine use of privileged accounts; MFA for privileged sessions; all privileged activity logged. (Note: this control is N/A for A3 and A4 where the OS is managed by SWIFT.) |
| **1.3A** | Virtualisation Platform Security | **ADVISORY** | If Alliance Access runs on VMs, apply hypervisor hardening, patch the hypervisor, restrict management console access, and isolate SWIFT VMs from general VMs. |
| **1.4** | Restriction of Internet Access | **MANDATORY** | Alliance Access servers must have no direct internet access. SWIFT-dedicated operator workstations must have internet access blocked. Jump servers/proxies must not be internet-facing. |
| **1.5A** | Customer Environment Protection | **ADVISORY** | Extend security controls beyond the Secure Zone to protect your broader IT environment from threats that could cascade into the SWIFT zone. |
| **2.1** | Internal Data Flow Security | **MANDATORY** | All connections between Alliance Access, middleware, and back-office systems must use TLS 1.2+. Message broker (MQ etc.) connections must be authenticated and encrypted. |
| **2.2** | Security Updates | **MANDATORY** | Apply patches to Alliance Access, the underlying OS, and all middleware within CSCF v2025 SLAs: Critical/Emergency SWIFT advisory = 3 calendar days; High = 90 calendar days. Note: v2025 tightened the critical SLA from 7 days to 3 days. |
| **2.3** | System Hardening | **MANDATORY** | Apply CIS Benchmarks (or equivalent) to all Alliance Access servers and SWIFT workstations. Disable all unnecessary services, ports, and protocols. Enforce host-based firewalls. |
| **2.4A** | Back-Office Data Flow Security | **ADVISORY** | Protect SWIFT transaction data as it flows between Alliance Access and back-office/ERP systems. Encryption and authentication of back-office interfaces recommended. |
| **2.5A** | External Transmission Data Protection | **ADVISORY** | Encrypt SWIFT-related data transmitted outside your environment (e.g., to regulators, auditors, correspondent banks via non-SWIFT channels). |
| **2.6** | Operator Session Confidentiality and Integrity | **MANDATORY** | All operator sessions to Alliance Access must use TLS 1.2+ or equivalent. Session timeouts of maximum 30 minutes of inactivity. Clipboard and screen-share tools restricted during sessions. |
| **2.7** | Vulnerability Scanning | **MANDATORY** | Quarterly credentialed (authenticated) vulnerability scans of all in-scope SWIFT systems including Alliance Access servers, OS, middleware, and network devices in the Secure Zone. Results must be remediated per Control 2.2 SLAs. |
| **2.8** | Critical Activity Outsourcing | **MANDATORY** | If any SWIFT-related activity is outsourced (e.g., managed SOC, external patching teams), the outsourced party must comply with applicable CSCF controls. Contracts must include SWIFT CSP obligations. Annual review of provider compliance evidence required. |
| **2.9A** | Transaction Business Controls | **ADVISORY** | Implement business-level controls to detect and prevent fraudulent SWIFT transactions: payment value thresholds, expected transaction patterns, time-of-day restrictions, beneficiary whitelisting. |
| **2.10** | Application Hardening | **MANDATORY** | Configure Alliance Access per SWIFT's published Security Hardening Guide. Disable unused features and interfaces. Configure application accounts with least privilege. Change all default passwords. Review application accounts quarterly. |
| **2.11A** | RMA Business Controls | **ADVISORY** | Control and monitor Relationship Management Application (RMA) authorisations to restrict which counterparties can send you messages and which message types are permitted. |
| **3.1** | Physical Security | **MANDATORY** | Alliance Access servers must be housed in a locked, access-controlled facility. Access restricted to named, authorised individuals. Physical access logged electronically (badge reader or equivalent). Visitor access controlled and escorted. |

---

### Objective 2 — Know and Limit Access (Controls 4.x, 5.x)

| Control ID | Control Name | A1 Status | Notes for A1 Institutions |
|------------|-------------|-----------|--------------------------|
| **4.1** | Password Policy | **MANDATORY** | Minimum 14-character passwords; complexity required; maximum 90-day age for privileged accounts / 180 days for standard; no reuse for 12 generations; account lockout after 5 failed attempts; no shared accounts. |
| **4.2** | Multi-Factor Authentication | **MANDATORY** | MFA mandatory for all interactive logins to Alliance Access and all remote administrative access to SWIFT systems. **CSCF v2025 explicitly requires hardware OTP tokens, smart cards with PIN, or FIDO2 hardware keys. Software-based OTP authenticator apps do not satisfy this requirement for A1.** This is the most commonly failed control in assessments. |
| **5.1** | Logical Access Controls | **MANDATORY** | Individual named accounts for every SWIFT operator — no shared accounts. Role-based access with least privilege. Dual authorisation for high-risk operations. Quarterly access reviews. Remove access within 24 hours of departure. |
| **5.2** | Token Management | **MANDATORY** | Maintain a token inventory for all SWIFT operators. Lost/stolen tokens deactivated within 1 hour. Formal approval process for token issuance. Token return process for leavers. Annual inventory reconciliation. |
| **5.3A** | Staffing | **ADVISORY** | Implement personnel security measures (background screening, role separation, awareness) for staff with SWIFT access. |
| **5.4** | Physical and Logical Password Storage | **MANDATORY** | SWIFT application passwords and credentials stored in an approved password manager or PAM vault (e.g., CyberArk). No plaintext storage. Emergency/break-glass credentials in sealed, tamper-evident envelopes with access logging. Default credentials changed on installation. |

---

### Objective 3 — Detect and Respond (Controls 6.x, 7.x)

| Control ID | Control Name | A1 Status | Notes for A1 Institutions |
|------------|-------------|-----------|--------------------------|
| **6.1** | Malware Protection | **MANDATORY** | Anti-malware deployed on all Alliance Access servers and SWIFT operator workstations. Definitions updated daily (automated). Real-time scanning enabled. Malware detections on SWIFT systems treated as security incidents per Control 7.1. |
| **6.2** | Software Integrity | **MANDATORY** | Verify cryptographic hash of Alliance Access software packages before installation and after every update, comparing against SWIFT-published checksums. Unauthorised changes to SWIFT executables must trigger an incident. File integrity monitoring (FIM) recommended for SWIFT binary directories. |
| **6.3** | Database Integrity | **MANDATORY** | Restrict database access to authorised SWIFT application service accounts only. No direct operator access to production databases. Database change logging enabled. Regular integrity checks. Backups tested with documented restoration procedures. |
| **6.4** | Log and Monitoring | **MANDATORY** | All Alliance Access application logs, OS security logs, authentication logs, Secure Zone network device logs, and database audit logs must be collected. **CSCF v2025 retention: 1 year online/hot; 3 years total (online + archived).** Daily review of SWIFT transaction anomalies and authentication failures. SIEM must ingest SWIFT log sources. Log integrity protected (immutable SIEM or read-only store). |
| **6.5A** | Intrusion Detection | **ADVISORY** | Deploy network or host-based intrusion detection (IDS/IPS) for the SWIFT Secure Zone. Alerts for reconnaissance, lateral movement, and anomalous traffic patterns. |
| **7.1** | Cyber Incident Response Planning | **MANDATORY** | Maintain a documented SWIFT-specific Incident Response Plan covering detection, triage, containment, SWIFT notification, investigation, recovery, and lessons learned. **SWIFT must be notified within 24 hours of a confirmed cyber incident affecting SWIFT infrastructure or transactions; full report within 30 days.** IRP tested annually (tabletop or live drill). |
| **7.2** | Security Training and Awareness | **MANDATORY** | Annual security awareness training for all staff with SWIFT access, covering phishing, social engineering, SWIFT fraud scenarios (e.g., Bangladesh Bank-style attacks), and incident reporting. Role-specific training for SWIFT operators. Training completion tracked and evidenced. |
| **7.3A** | Penetration Testing | **ADVISORY** | Annual penetration test of SWIFT Secure Zone including network perimeter, Alliance Access application layer, and authentication mechanisms. Red-team exercise every 2–3 years is best practice. |
| **7.4A** | Scenario Risk Assessment | **ADVISORY** | Conduct scenario-based risk assessments for SWIFT-specific attack scenarios: insider fraud, compromised operator credentials, supply chain attack on SWIFT software, social engineering targeting SWIFT operators, ransomware propagation to SWIFT zone. |

---

## 3. Summary Count — A1 Architecture

| Category | Count | Controls |
|----------|-------|---------|
| **Mandatory** | **23** | 1.1, 1.2, 1.4, 2.1, 2.2, 2.3, 2.6, 2.7, 2.8, 2.10, 3.1, 4.1, 4.2, 5.1, 5.2, 5.4, 6.1, 6.2, 6.3, 6.4, 7.1, 7.2 + (see note) |
| **Advisory** | **8** | 1.3A, 1.5A, 2.4A, 2.5A, 2.9A, 2.11A, 5.3A, 6.5A, 7.3A, 7.4A |
| **Not Applicable** | **0** | None — A1 has the broadest applicability of all architecture types |

> **Note on count:** The CSCF v2025 specifies 23 mandatory controls across all architecture types. For A1, all 23 mandatory controls listed in the full framework apply — unlike A3 and A4 where Control 1.2 (OS Privileged Account Control) is Not Applicable because the OS is managed by SWIFT. As an A1 institution, Control 1.2 is fully mandatory.

---

## 4. A1-Specific Compliance Considerations

### Controls That Become Mandatory Only for A1 (vs. Other Types)

**Control 1.2 — OS Privileged Account Control**

This control is **mandatory for A1** but is **Not Applicable for A3 and A4**. The reason: in A3 (SWIFT-managed component) and A4 (cloud-based), the underlying OS is managed by SWIFT, not the customer. As an A1 institution with your own servers, you must:

- Maintain a privileged account inventory for all Alliance Access servers
- Prohibit routine use of root/local admin accounts
- Enforce MFA for privileged OS sessions where technically feasible
- Log all privileged account usage and retain logs per Control 6.4

### Highest-Risk Controls for A1

Based on the most common assessment findings for software-based on-premises deployments:

| Priority | Control | Common Gap Risk for A1 |
|----------|---------|----------------------|
| 1 | **4.2 MFA** | Software-based OTP (authenticator apps) in use rather than hardware tokens — explicitly non-compliant under v2025 |
| 2 | **1.1 SWIFT Environment Protection** | Alliance Access servers on shared network segment rather than dedicated VLAN/zone |
| 3 | **6.4 Log and Monitoring** | Alliance Access logs not ingested into SIEM; retention under 1 year; no daily review discipline |
| 4 | **2.2 Security Updates** | Critical SWIFT patches not applied within the new 3-day SLA (tightened in v2025 from 7 days) |
| 5 | **6.2 Software Integrity** | No hash verification process for Alliance Access software before installation |
| 6 | **2.3 System Hardening** | No formal hardening baseline; unused services still running on SWIFT servers |
| 7 | **1.2 OS Privileged Account Control** | Shared or default admin accounts used for routine server management |

---

## 5. Key v2025 Changes Affecting A1 Institutions

| Change | v2024 | v2025 | Impact on A1 |
|--------|-------|-------|-------------|
| Patching SLA — Critical | 7 days | **3 days** | Emergency patch processes must be capable of deploying Alliance Access and OS patches within 3 calendar days of a critical advisory |
| MFA — hardware token | Strongly recommended | **Explicitly required; app-based OTP insufficient** | If software-based OTP is in use, this is now an unambiguous mandatory finding; hardware tokens must be deployed |
| Log retention | 1 year minimum | **1 year online; 3 years total** | SIEM/log archive must retain logs accessible online for 12 months; cold/archive tier must retain for a further 2 years minimum |

---

## 6. Annual Attestation Requirements for A1

| Activity | Detail |
|----------|--------|
| **Attestation portal** | KYC Security Attestation (KYC-SA) portal at swift.com/myswift |
| **Deadline** | July 31 annually (CSCF v2025 effective; first attestation cycle under v2025 from July 2025) |
| **Assessment type** | Independent assessment required (internal audit if independent, or external SWIFT CSP assessor) |
| **Scope** | All 23 mandatory controls applicable to A1 |
| **Advisory controls** | Optionally included; assessed for maturity but not attested as pass/fail |
| **Attestation options per control** | Implemented / Partially Implemented / Not Implemented |
| **Consequence of non-attestation** | Counterparty visibility flagged after deadline; potential suspension; regulatory escalation |

**Independent Assessment Note:** Your internal audit team may act as the independent assessor provided they have no operational responsibility for the SWIFT environment. If internal audit is embedded within IT operations, an external SWIFT CSP-qualified assessor should be engaged.

---

## 7. Quick-Reference Applicability Matrix — All Architecture Types (for Benchmarking)

The following matrix shows how A1 compares to other architecture types, confirming A1 has the broadest mandatory scope:

| Control | A1 | A2 | A3 | A4 | B |
|---------|:--:|:--:|:--:|:--:|:-:|
| 1.1 SWIFT Environment Protection | MAND | MAND | MAND | MAND | MAND |
| **1.2 OS Privileged Account Control** | **MAND** | MAND | N/A | N/A | MAND |
| 1.3A Virtualisation Platform Security | ADV | ADV | ADV | ADV | ADV |
| 1.4 Restriction of Internet Access | MAND | MAND | MAND | MAND | MAND |
| 1.5A Customer Environment Protection | ADV | ADV | ADV | ADV | ADV |
| 2.1 Internal Data Flow Security | MAND | MAND | MAND | MAND | MAND |
| 2.2 Security Updates | MAND | MAND | MAND | MAND | MAND |
| 2.3 System Hardening | MAND | MAND | MAND | MAND | MAND |
| 2.4A Back-Office Data Flow Security | ADV | ADV | ADV | ADV | ADV |
| 2.5A External Transmission Data Protection | ADV | ADV | ADV | ADV | ADV |
| 2.6 Operator Session Confidentiality | MAND | MAND | MAND | MAND | MAND |
| 2.7 Vulnerability Scanning | MAND | MAND | MAND | MAND | MAND |
| 2.8 Critical Activity Outsourcing | MAND | MAND | MAND | MAND | MAND |
| 2.9A Transaction Business Controls | ADV | ADV | ADV | ADV | ADV |
| 2.10 Application Hardening | MAND | MAND | MAND | MAND | MAND |
| 2.11A RMA Business Controls | ADV | ADV | ADV | ADV | ADV |
| 3.1 Physical Security | MAND | MAND | MAND | MAND | MAND |
| 4.1 Password Policy | MAND | MAND | MAND | MAND | MAND |
| 4.2 Multi-Factor Authentication | MAND | MAND | MAND | MAND | MAND |
| 5.1 Logical Access Controls | MAND | MAND | MAND | MAND | MAND |
| 5.2 Token Management | MAND | MAND | MAND | MAND | MAND |
| 5.3A Staffing | ADV | ADV | ADV | ADV | ADV |
| 5.4 Physical and Logical Password Storage | MAND | MAND | MAND | MAND | MAND |
| 6.1 Malware Protection | MAND | MAND | MAND | MAND | MAND |
| 6.2 Software Integrity | MAND | MAND | MAND | MAND | MAND |
| 6.3 Database Integrity | MAND | MAND | MAND | MAND | MAND |
| 6.4 Log and Monitoring | MAND | MAND | MAND | MAND | MAND |
| 6.5A Intrusion Detection | ADV | ADV | ADV | ADV | ADV |
| 7.1 Cyber Incident Response Planning | MAND | MAND | MAND | MAND | MAND |
| 7.2 Security Training and Awareness | MAND | MAND | MAND | MAND | MAND |
| 7.3A Penetration Testing | ADV | ADV | ADV | ADV | ADV |
| 7.4A Scenario Risk Assessment | ADV | ADV | ADV | ADV | ADV |

**MAND** = Mandatory | **ADV** = Advisory | **N/A** = Not Applicable  
**Bold row** = Control where A1 differs from A3/A4

---

## 8. Recommended Immediate Actions

Given that this is an A1 on-premises Alliance Access deployment with no HSMs:

1. **Verify MFA method (Control 4.2):** Confirm whether hardware tokens are deployed for all SWIFT operators. Under CSCF v2025, software OTP apps are explicitly insufficient. If hardware tokens are not yet in place, this is a mandatory finding that must be disclosed in your KYC-SA attestation.

2. **Confirm Secure Zone network design (Control 1.1):** Verify that Alliance Access servers are on a dedicated, firewalled network segment with deny-by-default rules and no dual-homing to the corporate network.

3. **Assess patch readiness for 3-day SLA (Control 2.2):** The v2025 tightening of the critical patch SLA to 3 days is the most impactful procedural change. Confirm your patch deployment process can meet this requirement.

4. **Inventory all SWIFT log sources in SIEM (Control 6.4):** Ensure Alliance Access application logs, OS security logs, and authentication logs are ingested with the correct retention tiers (1 year online, 3 years total).

5. **Document OS privileged accounts (Control 1.2):** As an A1 institution, you must evidence that root/admin access to Alliance Access servers is controlled, approved, logged, and not used for routine operations.

6. **Schedule independent assessment:** Engage your internal audit team or an external SWIFT CSP assessor to conduct the assessment covering all 23 mandatory controls before the July 31 KYC-SA submission deadline.

---

*This analysis is based on SWIFT CSCF v2025. The v2025 framework is effective July 2025; KYC-SA attestations submitted from July 2025 onwards must use v2025 controls. Institutions attesting prior to July 2025 may use CSCF v2024.*

# SWIFT CSP/CSCF v2025 Architecture Scoping and Applicability Matrix

## Scenario Summary

- Institution type: Mid-tier regional bank
- Connectivity: SWIFT Alliance Access software, self-hosted on-premises servers
- HSMs: None
- Delivery model: Not a service bureau; not cloud-hosted SWIFT

---

## 1. Architecture Type Determination

### Classification: Architecture Type A2

Under the SWIFT Customer Security Programme (CSP), SWIFT-connected institutions are classified into three principal architecture types:

| Type | Description |
|------|-------------|
| A1 | Full stack on-premises: own SWIFT interface (e.g., Alliance Access), own messaging infrastructure, own HSM, direct SWIFT network connection |
| A2 | Full stack on-premises but WITHOUT a Hardware Security Module (HSM) for message signing/verification — or where HSM management is partially outsourced |
| A3 | Operated via a service bureau or shared infrastructure (operator manages the SWIFT connectivity on behalf of the customer) |
| B | Thin client / indirect connectivity — institution uses a third-party's SWIFT infrastructure and has no local SWIFT footprint |

**Your classification is Architecture Type A2.**

Rationale:
- You run Alliance Access on your own servers on-premises — this is the classic "full stack" model.
- You do NOT use an HSM for securing SWIFT messaging keys. The absence of an HSM is the defining characteristic that distinguishes A2 from A1.
- You are not a service bureau customer (A3) and do not use cloud-hosted or third-party-managed SWIFT infrastructure (B).

**Practical implications of A2 vs A1:**
- Under A1, the HSM provides hardware-enforced key protection, which satisfies certain controls by design.
- Under A2, without an HSM, you must implement compensating controls to protect operator credentials, message authentication keys, and cryptographic material through software and procedural means.
- Your full CSCF scope applies in full — you cannot claim HSM-based control satisfaction.

---

## 2. SWIFT CSCF v2025 Control Framework Overview

The CSCF v2025 organises controls across three security domains:

1. **Restrict Internet Access and Protect Critical Systems** (Objective 1)
2. **Reduce Attack Surface and Vulnerabilities** (Objective 2)
3. **Physically Secure the Environment** (Objective 3)
4. **Prevent Compromise of Credentials** (Objective 4)
5. **Manage Identities and Segregate Privileges** (Objective 5)
6. **Detect Anomalous Activity to Systems or Transaction Records** (Objective 6)
7. **Plan for Incident Response and Information Sharing** (Objective 7)

Controls are designated as either:
- **Mandatory (M):** Must be implemented by all institutions in-scope for the relevant architecture type. Self-attestation must confirm compliance.
- **Advisory (A):** Strongly recommended best practices. Non-compliance must be explained and tracked, but does not trigger a failed attestation.

---

## 3. Full CSCF v2025 Applicability Matrix for Architecture Type A2

The table below lists all CSCF v2025 controls, their control numbers, names, and applicability status for Architecture Type A2 (on-premises Alliance Access, no HSM, no service bureau).

### Domain 1 — Restrict Internet Access and Protect Critical Systems from General IT Environment

| Control No. | Control Name | Type for A2 |
|-------------|--------------|-------------|
| 1.1 | SWIFT Environment Protection — Segment the SWIFT infrastructure from the general enterprise IT environment | **Mandatory** |
| 1.2 | Operating System Privileged Account Control — Restrict and control the allocation and usage of operating system-level administrator accounts | **Mandatory** |
| 1.3 | Virtualisation Platform Security (where virtualisation is used) | **Advisory** |
| 1.4 | Restriction of Internet Access — Restrict internet connectivity of operator PCs and systems within the SWIFT environment | **Mandatory** |

### Domain 2 — Reduce Attack Surface and Vulnerabilities

| Control No. | Control Name | Type for A2 |
|-------------|--------------|-------------|
| 2.1 | Internal Data Flow Security — Ensure the confidentiality, integrity, and mutual authentication of data flows between SWIFT-related components | **Mandatory** |
| 2.2 | Security Updates — Minimise the occurrence of known technical vulnerabilities within the SWIFT environment by implementing a timely security patching process | **Mandatory** |
| 2.3 | System Hardening — Reduce the cyber-attack surface of SWIFT-related components by performing system hardening | **Mandatory** |
| 2.4A | Back-Office Data Flow Security — Secure back-office data flows by using specific data flow security techniques | **Advisory** |
| 2.4B | Back-Office Data Flow Security (for A2) — Implement controls to protect data flows between the SWIFT secure zone and the back-office | **Advisory** |
| 2.5A | External Transmission Data Protection — Protect the confidentiality of SWIFT-related data transmitted or stored outside the secure zone | **Advisory** |
| 2.5B | External Transmission Data Protection — Protect the confidentiality of SWIFT-related data transmitted to operators/customers | **Advisory** |
| 2.6 | Operator Session Confidentiality and Integrity — Protect the confidentiality and integrity of interactive operator sessions connecting to the SWIFT infrastructure | **Mandatory** |
| 2.7 | Vulnerability Scanning — Identify known vulnerabilities within the SWIFT environment by implementing a regular vulnerability scanning process | **Mandatory** |
| 2.8 | Critical Activity Outsourcing — Ensure that outsourced critical activities maintain the same level of security as if performed in-house | **Advisory** |
| 2.9 | Transaction Business Controls — Implement business controls to restrict SWIFT transaction activity to expected bounds | **Advisory** |
| 2.11A | RMA Business Controls — Restrict counterparty Relationship Management Application (RMA) keys to legitimate business relationships | **Advisory** |

### Domain 3 — Physically Secure the Environment

| Control No. | Control Name | Type for A2 |
|-------------|--------------|-------------|
| 3.1 | Physical Security — Prevent unauthorised physical access to sensitive equipment and hosting environments | **Mandatory** |

### Domain 4 — Prevent Compromise of Credentials

| Control No. | Control Name | Type for A2 |
|-------------|--------------|-------------|
| 4.1 | Password Policy — Ensure passwords meet defined quality standards and enforce their usage | **Mandatory** |
| 4.2 | Multi-Factor Authentication (MFA) — Prevent compromise of credentials by requiring multi-factor authentication for interactive user sessions into the SWIFT environment | **Mandatory** |

### Domain 5 — Manage Identities and Segregate Privileges

| Control No. | Control Name | Type for A2 |
|-------------|--------------|-------------|
| 5.1 | Logical Access Controls — Enforce the security principles of need-to-know, least privilege, and segregation of duties for operator accounts | **Mandatory** |
| 5.2 | Token Management — Manage SWIFT-related tokens and authenticators | **Mandatory** |
| 5.3A | Personnel Vetting Process — Screen personnel with access to the SWIFT environment prior to employment or role assignment | **Advisory** |
| 5.3B | Privileged Account Monitoring — Monitor privileged accounts to detect anomalous behaviour | **Advisory** |
| 5.4 | Physical and Logical Password Storage — Store physical and logical passwords in a secure manner | **Advisory** |

### Domain 6 — Detect Anomalous Activity to Systems or Transaction Records

| Control No. | Control Name | Type for A2 |
|-------------|--------------|-------------|
| 6.1 | Malware Protection — Ensure that all systems within the SWIFT environment are protected against malware | **Mandatory** |
| 6.2 | Software Integrity — Ensure the software integrity of the SWIFT-related applications | **Mandatory** |
| 6.3 | Database Integrity — Ensure the integrity of the database records for the SWIFT messaging interface | **Mandatory** |
| 6.4 | Logging and Monitoring — Record security events and detect anomalous actions and operations within the SWIFT environment | **Mandatory** |
| 6.5A | Intrusion Detection — Detect and prevent intrusion attempts into the SWIFT infrastructure | **Advisory** |
| 6.5B | Intrusion Detection (enhanced) — Implement additional intrusion detection capabilities | **Advisory** |

### Domain 7 — Plan for Incident Response and Information Sharing

| Control No. | Control Name | Type for A2 |
|-------------|--------------|-------------|
| 7.1 | Cyber Incident Response Planning — Define and implement a cyber incident response plan in case of cyber-attack | **Mandatory** |
| 7.2 | Security Training and Awareness — Ensure all staff in the SWIFT environment are aware of and trained on cybersecurity risks | **Advisory** |
| 7.3A | Penetration Testing — Validate the operational security of the SWIFT infrastructure by performing penetration testing | **Advisory** |
| 7.3B | Red Team Exercises — Perform advanced, scenario-based testing to validate defences | **Advisory** |
| 7.4 | Scenario Risk Assessment — Assess the potential impact of cyber-attack scenarios specific to SWIFT | **Advisory** |

---

## 4. Summary Count

| Category | Count |
|----------|-------|
| Mandatory controls for A2 | 16 |
| Advisory controls for A2 | 16 |
| **Total CSCF v2025 controls** | **~32** |

Note: The exact count can vary slightly depending on how sub-controls (e.g., 2.4A vs 2.4B) are counted in a given year's CSCF release. The figures above reflect the CSCF v2025 framework structure as published.

---

## 5. Key A2-Specific Considerations

### Mandatory Controls with Heightened Risk due to No HSM

Since your environment has no HSM:

- **Control 4.2 (MFA):** Without hardware tokens backed by an HSM, you must use software-based or third-party MFA solutions (e.g., TOTP authenticator apps, PKI smartcards). These must be rigorously managed.
- **Control 5.2 (Token Management):** SWIFT operator tokens are particularly sensitive. Without an HSM for key protection, software-level key stores must be encrypted and tightly access-controlled.
- **Control 6.2 (Software Integrity):** Without an HSM to anchor trust, software integrity verification relies on hash checking, code signing with certificates, and rigorous change management.
- **Control 2.1 (Internal Data Flow Security):** TLS/mTLS between SWIFT components must be implemented in software; key material protection becomes a critical design concern.

### Important Advisory Controls to Prioritise

Even though advisory, the following are strongly recommended for A2 institutions:

- **2.9 (Transaction Business Controls):** The SWIFT Payment Controls Service (PCS) and in-application transaction limits are your primary anti-fraud layer — particularly important for a bank without HSM-enforced integrity.
- **6.5A/B (Intrusion Detection):** Without hardware-enforced perimeter controls, IDS/IPS is a critical compensating control.
- **7.3A (Penetration Testing):** Annual pen testing is de facto expected by SWIFT's auditors even where advisory.
- **5.3A (Personnel Vetting):** Insider threat is elevated in an A2 environment due to lower hardware barriers to key theft.

---

## 6. Annual Self-Attestation Requirements

As an A2 institution:

- You must complete the **SWIFT KYC-Security Attestation (KYC-SA)** annually in the SWIFT KYC Registry.
- Attestation covers all mandatory controls only. Advisory controls are not attested but may be reviewed by correspondent banks.
- Deadline: attestation must be submitted by **31 December** of each calendar year for the prior assessment period.
- Non-attestation or failed mandatory controls may trigger correspondent banks to restrict or suspend your SWIFT connectivity.
- SWIFT's **Customer Security Intelligence (CSI)** team may request evidence for any attested control.

---

## 7. Caveats

1. This analysis is based on general knowledge of SWIFT CSP and CSCF v2025 as publicly documented by SWIFT. Always verify against the official CSCF v2025 document available on swift.com/myswift.
2. SWIFT periodically promotes advisory controls to mandatory status between versions — always check the "delta" document when a new CSCF version is released.
3. The exact sub-control applicability (e.g., 2.4A vs 2.4B) depends on your specific topology; consult the CSCF v2025 scoping guide for your exact Alliance Access configuration.
4. If you subsequently deploy HSMs, you would reclassify to A1 and certain controls would be satisfied by the HSM by design.

---

*Assessment date: 2026-04-25*
*Framework version: SWIFT CSCF v2025*
*Architecture type assessed: A2 (on-premises Alliance Access, no HSM, no service bureau)*

# SWIFT CSCF v2025 — Control 4.2 MFA Finding: Software OTP Gap Analysis and Remediation Plan

**Date:** 2026-04-25
**Control in Scope:** 4.2 — Multi-Factor Authentication (Mandatory)
**Finding:** Google Authenticator (software-based TOTP) does not satisfy CSCF v2025 Control 4.2 for SWIFT operator authentication to Alliance Access
**Attestation Deadline:** July 31 (KYC-SA submission)

---

## 1. Why Software OTP (Google Authenticator) Is Insufficient

Your SWIFT assessor's finding is correct and grounded in explicit CSCF v2025 language. Control 4.2 states:

> "Acceptable MFA methods: hardware OTP tokens, smart cards with PIN, FIDO2 hardware keys. Software-based OTP (authenticator apps on shared devices) **does not satisfy** this requirement for most architecture types."

The reasons software-based TOTP fails to meet the SWIFT standard come down to security properties that hardware tokens provide and authenticator apps do not:

### 1.1 Threat: Credential Theft and Malware

A software authenticator (Google Authenticator, Microsoft Authenticator, Authy, etc.) runs on a general-purpose device — typically a smartphone or a PC. The TOTP seed is stored in software, which means:

- Malware on the device (keyloggers, screen-capture malware, RATs) can extract the TOTP seed or intercept the generated code before entry.
- If the operator's device is compromised, an attacker can silently clone the authenticator app and generate valid TOTP codes without the operator's knowledge.
- Phishing attacks combined with real-time TOTP relay (man-in-the-middle proxies) can capture and replay the 30-second codes before they expire.

### 1.2 Threat: Shared Device Risk

Software-based TOTP on a shared device — for example, an app installed on a shared computer or a phone that multiple staff members can access — provides no meaningful separation between operators. SWIFT Control 5.1 requires individual named accounts; a shared authenticator app undermines individual accountability.

### 1.3 Threat: No Physical Possession Assurance

The defining property of a second factor is physical possession. A hardware token provides cryptographic proof that the specific physical device is present. A software token on a phone does not:

- The seed can be backed up to cloud (iCloud, Google account sync) and restored to another device without physical possession.
- Phone screen-sharing or remote access tools (which are common in IT environments) allow someone to "possess" the software token remotely without holding the physical device.

### 1.4 CSCF v2025 Tightening: A Deliberate Change from v2024

This is not a grey area in v2025. The CSCF v2024 to v2025 change log explicitly records:

| Control | v2024 | v2025 |
|---------|-------|-------|
| 4.2 MFA | Hardware token strongly recommended | Hardware token explicitly required; clarified app-based OTP insufficient for most types |

SWIFT made this change in direct response to observed attack patterns against SWIFT operators — including the Bangladesh Bank and subsequent SWIFT fraud cases — where compromised operator credentials (including software-based OTPs) were a key enabler. Your assessor's finding reflects the current mandatory standard, not an aspirational best practice.

---

## 2. What CSCF v2025 Control 4.2 Exactly Requires

### 2.1 Formal Control Definition

**Control 4.2 — Multi-Factor Authentication (Mandatory)**
**Objective:** Know and Limit Access (Objective 2)
**Architecture applicability:** Mandatory for ALL architecture types — A1, A2, A3, A4, B

**Purpose:** Require MFA for all interactive operator access to the SWIFT environment.

**Full Requirements:**

1. MFA is mandatory for **all** interactive logins to SWIFT applications, including:
   - Alliance Access (your current deployment)
   - Alliance Gateway
   - SWIFT GUI and web-based management interfaces
2. MFA is mandatory for **remote administrative access** to SWIFT systems (RDP, SSH, jump-server sessions into the SWIFT Secure Zone).
3. **Acceptable MFA methods** — must be one of:
   - **Hardware OTP tokens** (e.g., RSA SecurID physical token, SafeNet/Thales hardware token, Feitian OTP token)
   - **Smart cards with PIN** (PKI certificate on a physical smart card, combined with PIN entry)
   - **FIDO2 hardware security keys** (e.g., YubiKey 5, Google Titan Key, with FIDO2 protocol)
4. **Not acceptable:**
   - Software-based OTP apps (Google Authenticator, Microsoft Authenticator, Authy, Duo Mobile app)
   - SMS-based OTP
   - Email-based OTP
   - Push notification apps without hardware backing
5. **Token lifecycle** must align with Control 5.2 (Token Management) — see Section 3.3 below.

### 2.2 Evidence the Assessor Will Require

To attest Control 4.2 as "Implemented" on your KYC-SA, you will need to provide:

| Evidence Item | Description |
|---------------|-------------|
| MFA configuration evidence | Screenshots of Alliance Access authentication settings showing hardware MFA enforcement |
| Token inventory | Complete list of all operator tokens: serial number, assigned operator, issue date, architecture (hardware) |
| Authentication logs | Sample logs showing MFA enforcement at login — each authentication event must show the second factor (hardware token code) was required and validated |
| Exemption register | If any accounts are excluded from MFA (e.g., service accounts), these must be formally documented with risk acceptance, approved by a control function, and noted in the register |

---

## 3. Remediation Options

You have three main remediation pathways. All are compliant with CSCF v2025 Control 4.2. The right choice depends on your existing infrastructure, budget, and timeline to the July 31 attestation deadline.

### 3.1 Option A: Hardware OTP Tokens (Recommended for Most A1 Deployments)

**What it is:** Dedicated physical devices (key fobs or card-sized tokens) that generate a time-based or event-based one-time password. The cryptographic seed is burned into tamper-resistant hardware and cannot be extracted.

**Compliant products:**
- RSA SecurID hardware tokens (SD700, SID700)
- Thales (formerly Gemalto) SafeNet OTP 110/300 series
- Feitian OTP c200/c300 tokens
- VASCO/OneSpan Digipass GO tokens

**Integration with Alliance Access:**
Alliance Access supports RADIUS-based authentication, which is the standard integration path for hardware OTP tokens. Your organisation would deploy a RADIUS server (e.g., RSA Authentication Manager, Thales SafeNet Authentication Service) that validates hardware token codes. Alliance Access is configured to authenticate operators via RADIUS before granting access.

**Pros:**
- Well-established, widely understood by SWIFT assessors
- Clear audit trail
- Relatively low per-unit cost (typically $30–$80 per token hardware + licensing)
- No dependency on operator smartphones

**Cons:**
- Physical token distribution and management overhead (Control 5.2 compliance required)
- Tokens have a battery life (typically 3–5 years) requiring replacement
- Lost/stolen token process must be documented

**Estimated implementation time:** 4–8 weeks for procurement, RADIUS server deployment, Alliance Access configuration, operator training, and evidence collection. This is achievable before July 31 if started immediately.

### 3.2 Option B: FIDO2 Hardware Security Keys

**What it is:** FIDO2-certified USB or NFC hardware keys that use public-key cryptography for authentication. The private key never leaves the hardware device.

**Compliant products:**
- YubiKey 5 Series (YubiKey 5 NFC, YubiKey 5C NFC)
- Google Titan Security Key
- Feitian ePass FIDO2

**Integration with Alliance Access:**
FIDO2 integration requires that Alliance Access presents a web-based login interface that supports the WebAuthn standard, or that a FIDO2-capable Identity Provider (IdP) sits in front of Alliance Access authentication. This is more complex to configure than RADIUS-based OTP and may require SWIFT to confirm support for your version of Alliance Access.

**Pros:**
- Phishing-resistant by design (origin binding prevents credential relay attacks)
- No shared secret on server side — stronger security posture
- Single key can serve multiple systems
- Resistant to real-time phishing attacks that OTP tokens are theoretically vulnerable to

**Cons:**
- More complex integration; may require IdP middleware
- SWIFT's published guidance for Alliance Access focuses primarily on RADIUS/hardware OTP; FIDO2 support should be confirmed with your SWIFT version
- Higher per-unit cost (~$50–$100 per key)
- Two keys per operator recommended (primary + backup) in case of loss

**Estimated implementation time:** 6–10 weeks including integration testing. Feasible before July 31 but tighter — begin immediately if choosing this option.

### 3.3 Option C: Smart Cards with PIN

**What it is:** PKI-based smart cards (or USB tokens with an embedded certificate) that require the operator to insert the card and enter a PIN. Authentication is based on the certificate private key, which is hardware-protected.

**Compliant products:**
- Thales/Gemalto IDPrime smart cards + card reader
- SafeNet eToken 5110 (USB form factor)
- HID Crescendo smart cards

**Integration with Alliance Access:**
Smart card authentication to Alliance Access typically goes through Windows certificate-based authentication or a PKI/SSL mutual authentication path. This requires a PKI infrastructure (Certificate Authority), smart card management system, and card readers on all operator workstations.

**Pros:**
- Familiar in environments that already have a PKI or smart card programme (e.g., for VPN or Windows login)
- PIN is separate from the card — two distinct factors
- Certificate revocation provides rapid deactivation if a card is lost

**Cons:**
- Highest infrastructure complexity if no PKI exists
- Card readers required at every operator workstation
- Certificate lifecycle management adds overhead
- PKI setup is not practical to complete before July 31 if one does not exist

**Estimated implementation time:** 10–16 weeks from scratch if no PKI exists. Not recommended for a July 31 deadline unless PKI infrastructure is already in place.

---

## 4. Recommended Remediation Path for July 31 Deadline

Given you have approximately 13 weeks from today (April 25) to the July 31 KYC-SA submission deadline, and accounting for time needed to gather and present evidence to your independent assessor, **Option A (Hardware OTP Tokens via RADIUS)** is the most realistic path.

### 4.1 Remediation Timeline

| Week | Activity |
|------|----------|
| Week 1–2 (by May 9) | Select hardware token vendor; raise procurement request; engage RADIUS server vendor (RSA, Thales, or open-source FreeRADIUS); assign project owner |
| Week 2–3 (by May 16) | Deploy RADIUS server in SWIFT Secure Zone or adjacent management zone; complete base configuration; integrate with Active Directory or local user store |
| Week 3–5 (by May 30) | Receive hardware tokens; enrol operator tokens into RADIUS server; configure Alliance Access to authenticate via RADIUS; test with pilot operators |
| Week 5–7 (by June 13) | Roll out hardware tokens to all SWIFT operators; complete operator training; disable Google Authenticator TOTP for all accounts |
| Week 7–9 (by June 27) | Collect evidence artifacts: MFA config screenshots, token inventory, authentication logs showing hardware MFA enforcement; build exemption register if needed |
| Week 9–10 (by July 4) | Present evidence to independent assessor for Control 4.2 review; remediate any assessor queries |
| Week 10–12 (by July 18) | Assessor finalises assessment; complete KYC-SA form including Control 4.2 as "Implemented" |
| By July 31 | Submit KYC-SA attestation via SWIFT KYC-SA portal |

### 4.2 Control 5.2 (Token Management) — Linked Requirement

Remediating Control 4.2 automatically triggers the token management obligations under **Control 5.2 (Token Management)**, which is also Mandatory for all architecture types. You must establish and maintain:

- **Token inventory register:** Serial number, operator name, issue date, return date (if applicable)
- **Issuance process:** Formal approval required before issuing a token to an operator
- **Lost/stolen token procedure:** Token deactivated within 1 hour of report; incident logged
- **Leaver process:** Token returned and deactivated on employee departure (same day)
- **Annual reconciliation:** Inventory cross-checked against active operator list annually

This is not optional — your assessor will check both 4.2 and 5.2 together as they are explicitly linked in the CSCF.

---

## 5. Gap Assessment: Current State vs. Required State

| Control | Control Name | Current Status | Required State | Gap | Remediation |
|---------|-------------|----------------|---------------|-----|-------------|
| **4.2** | Multi-Factor Authentication | **Not Implemented** (software TOTP in use) | Hardware OTP token, smart card, or FIDO2 key required for all operator interactive sessions | Software-based TOTP (Google Authenticator) explicitly excluded from acceptable MFA methods in CSCF v2025 | Deploy hardware OTP tokens + RADIUS; revoke software OTP access |
| **5.2** | Token Management | **Not Implemented** (no hardware token inventory exists) | Token inventory, issuance/return process, lost token procedure, annual reconciliation | No hardware token programme in place | Establish token inventory register and lifecycle procedures as part of hardware token rollout |

---

## 6. KYC-SA Attestation Implications

If your July attestation is submitted without remediation of Control 4.2:

- You must attest Control 4.2 as **"Not Implemented"** — you cannot attest "Implemented" with Google Authenticator in place, as SWIFT assessors explicitly flag software TOTP as non-compliant.
- A "Not Implemented" status on Control 4.2 is visible to all counterparties on the KYC-SA portal immediately upon submission.
- Counterparties (correspondent banks, custodians, CCPs) may restrict transactions with you, require explanations, or trigger their own internal escalations.
- Repeated or prolonged non-compliance can result in SWIFT notifying your regulator.

**The only path to a clean July attestation on Control 4.2 is to deploy hardware MFA before the attestation is submitted.** Given the 13-week window, this is achievable with Option A if procurement is initiated this week.

---

## 7. Summary of Key Facts

| Item | Detail |
|------|--------|
| Control | 4.2 — Multi-Factor Authentication (Mandatory, all architecture types) |
| Objective | Know and Limit Access (Objective 2) |
| What CSCF v2025 requires | Hardware OTP token, smart card with PIN, or FIDO2 hardware key for all interactive operator sessions to SWIFT applications |
| Why Google Authenticator fails | Software TOTP explicitly excluded; seed extractable by malware; no physical possession assurance; cloud backup risk; CSCF v2025 tightened language to make this explicit |
| Acceptable remediation options | (A) Hardware OTP tokens via RADIUS — fastest; (B) FIDO2 keys — most secure; (C) Smart cards — most complex |
| Recommended option for July deadline | Option A: Hardware OTP tokens via RADIUS |
| Linked control also requiring action | 5.2 — Token Management |
| KYC-SA deadline | July 31 |
| Risk of non-remediation | "Not Implemented" attestation visible to all counterparties; potential transaction restrictions; regulatory escalation |
| Implementation window | ~13 weeks from today to July 31 — sufficient for Option A if started immediately |

# SWIFT CSCF v2025 Control 4.2 — MFA Finding: Software TOTP for Alliance Access Operators

## Executive Summary

Your SWIFT assessor is correct to flag Google Authenticator (software-based TOTP) as non-compliant with CSCF v2025 Control 4.2. The control explicitly requires **multi-factor authentication using hardware-based tokens or equivalent strong authentication mechanisms** for privileged and operator access to SWIFT components. Software OTP apps installed on smartphones or general-purpose computers do not satisfy this requirement because they fail the physical possession factor as defined by SWIFT. You need to remediate before your July attestation.

---

## 1. Why Software OTP (Google Authenticator) Is Not Sufficient

### 1.1 The Core Problem: Single-Device Attack Surface

Software TOTP apps like Google Authenticator store the OTP seed secret in software on a general-purpose device (smartphone or PC). This creates several vulnerabilities that SWIFT considers unacceptable for operator access:

**Seed secret extractability.** The TOTP seed is stored in the app's data store or, in some implementations, is exportable. An attacker with device access (physical or remote via malware) can extract the seed and clone the authenticator, breaking the "something you have" factor entirely.

**Malware compromise.** A smartphone or PC running Google Authenticator can be infected with banking trojans, spyware, or RATs that silently read the OTP at the time of entry or extract the seed from app storage. This is a well-documented attack vector (e.g., Cerberus, Anubis malware families specifically target TOTP seeds).

**No tamper resistance.** Unlike hardware tokens (HSMs, dedicated OTP devices), a software app on a general-purpose device provides no tamper-resistant execution environment. The private key/seed is not protected by secure hardware.

**Backup/sync risks.** Google Authenticator (and similar apps) may allow cloud backup of seeds. If a user's Google account is compromised, all TOTP seeds can be accessed, effectively reducing authentication to a single factor (the account password).

**Screen capture and screen-sharing attacks.** A malicious application or remote session can observe the OTP on screen during entry. Hardware tokens display the OTP on a dedicated physical display with no software interface to intercept.

**No binding to the transaction.** Software TOTP provides a time-based code with no cryptographic binding to the specific transaction being authorized. Hardware-based solutions (particularly those using challenge-response or transaction signing) can bind the authentication to a specific payment instruction, preventing man-in-the-browser attacks.

### 1.2 SWIFT's Threat Model

SWIFT's CSP was designed in direct response to the 2016 Bangladesh Bank heist and subsequent attacks where threat actors gained persistent access to SWIFT environments. In many of those incidents, attackers compromised operator credentials. SWIFT concluded that software-only second factors provided insufficient protection because they operate on the same compromised endpoints the attackers controlled.

---

## 2. What CSCF v2025 Control 4.2 Actually Requires

### 2.1 Control Statement

Control 4.2 is a **Mandatory** control titled **"Multi-Factor Authentication"** (the exact title may be "Multi-Factor Authentication for SWIFT-related Accounts" in some versions).

The control objective is to prevent unauthorized access to SWIFT-related systems and data by ensuring that operator accounts are protected by multi-factor authentication where at least one factor is resistant to remote compromise.

### 2.2 Key Requirements Under CSCF v2025

**Scope:** MFA is required for all interactive operator logons to SWIFT components including:
- Alliance Access / Alliance Entry
- Alliance Web Platform (AWP)
- Alliance Gateway
- Any GUI or administrative interface to SWIFT messaging infrastructure

**Mandatory MFA factors:** CSCF v2025 requires that the authentication mechanism include at least two of the following factor types:
1. Something you know (password/PIN)
2. Something you have — but specifically a **hardware-based token or device certificate stored in hardware** (e.g., smart card, hardware OTP token, FIDO2/WebAuthn hardware key)
3. Something you are (biometric, though rare in SWIFT implementations)

**Hardware requirement specifics:** The "something you have" factor must be implemented using one of the following categories to be considered compliant:

- **Dedicated hardware OTP tokens** — Physical devices (e.g., SafeNet/Thales OTP tokens, RSA SecurID hardware tokens, Gemalto tokens) that generate TOTP or HOTP codes using a seed stored in tamper-resistant hardware. The seed cannot be extracted from the device.
- **Smart cards / PKI certificates stored in hardware** — X.509 certificates stored on a smart card or hardware security module that require physical possession of the card and a PIN. Used with Alliance Access's PKI authentication capability.
- **FIDO2/WebAuthn hardware authenticators** — Physical security keys (e.g., YubiKey, Feitian) that use public-key cryptography with the private key stored in secure hardware. SWIFT began recognizing FIDO2 hardware keys in more recent CSCF versions as they provide equivalent or stronger guarantees than dedicated OTP tokens.

**What is explicitly NOT acceptable under CSCF v2025:**
- Software TOTP applications (Google Authenticator, Microsoft Authenticator, Authy) — seed is in software
- SMS OTP — not hardware-bound and subject to SIM swap attacks
- Email OTP — not hardware-bound
- Push notification approval on smartphones without hardware-backed key storage confirmation (i.e., app-based push without a certified hardware-backed secure enclave implementation recognized by SWIFT)
- Software certificates stored on general-purpose file systems (not hardware-bound)

### 2.3 Applicability Tiers

Under the Architecture Type classifications in CSCF:
- **A1, A2, A3, B** architecture types are all in scope for Control 4.2
- Control 4.2 is **mandatory** (not advisory) across all architecture types
- There is no partial credit or compensating control option for software TOTP — SWIFT assessors must mark this non-compliant

### 2.4 Evidence Requirements

During attestation you will need to demonstrate:
1. An inventory of all operator accounts with access to SWIFT components
2. Documentation confirming hardware token assignment per operator
3. System configuration showing hardware MFA is enforced (not optional) at logon
4. Policy documentation mandating hardware MFA for SWIFT operators

---

## 3. Remediation Options Before July Attestation

Given your deadline, you have three primary paths. Each is assessed for speed of implementation, cost, and compatibility with Alliance Access.

### Option 1: Dedicated Hardware OTP Tokens (RSA SecurID, Thales SafeNet)

**How it works:** Replace Google Authenticator with physical OTP token devices. Each operator receives a physical keyfob or credit-card-format token that generates 6- or 8-digit TOTP/HOTP codes every 30–60 seconds. The seed is burned into tamper-resistant hardware at manufacture and cannot be extracted.

**Products to evaluate:**
- **Thales (formerly SafeNet) OTP tokens** — SafeNet eToken PASS, SafeNet OTP 110. Widely used in SWIFT environments. Thales also provides a companion authentication server (STA — SafeNet Trusted Access).
- **RSA SecurID hardware tokens** — The classic enterprise standard. Requires RSA Authentication Manager server infrastructure.
- **VASCO/OneSpan Digipass tokens** — Well-regarded alternative, common in financial services.

**Alliance Access integration:** Alliance Access supports RADIUS-based authentication. You can configure Alliance Access to authenticate operators via a RADIUS server that fronts your OTP token infrastructure (RSA Authentication Manager, Thales STA, FreeRADIUS with OATH module). The logon screen accepts the PIN+OTP combination.

**Timeline:** Token hardware procurement typically takes 2–4 weeks. Server infrastructure setup adds 2–4 weeks. Operator enrollment and testing: 1–2 weeks. Total: 5–10 weeks. This is feasible for a July deadline if you begin immediately.

**Cost:** Hardware tokens cost approximately $30–$80 per token (3-year lifecycle). Authentication server licensing varies; cloud-hosted options (Thales STA cloud, RSA Cloud Authentication) reduce infrastructure burden.

**Pros:** Well-understood by SWIFT assessors; clearly compliant; no smartphone dependency; dedicated device cannot run malware.

**Cons:** Physical token management overhead (lost tokens, battery replacement every 3–5 years, provisioning); higher per-user cost than software; operators must carry another device.

### Option 2: Smart Card / PKI Authentication

**How it works:** Issue each operator a smart card containing their X.509 private key in hardware. Alliance Access (and the underlying Windows/RHEL workstation) performs certificate-based authentication. The card requires physical possession plus a PIN.

**Products to evaluate:**
- Thales IDPrime smart cards
- HID Global smart cards
- Gemalto/Thales IDGo series

**Alliance Access integration:** Alliance Access supports smart card logon through the host operating system's PKI infrastructure (Windows CNG/CAPI or equivalent). You need a PKI CA (internal or outsourced), smart card readers at each operator workstation, and middleware (ActivClient, SafeNet Authentication Client).

**Timeline:** This is typically the longest path — PKI establishment, certificate issuance, workstation configuration, and testing typically take 8–16 weeks minimum. Likely too slow for July unless you already have a PKI in place.

**Cost:** Smart cards ~$15–$30 each; readers ~$30–$60 each; PKI infrastructure (cloud CA like Sectigo or DigiCert is faster than building internal CA); middleware licensing.

**Recommendation for July deadline:** Only viable if you already have an operational PKI. Otherwise, prioritize Option 1 or 3.

### Option 3: FIDO2 Hardware Security Keys

**How it works:** Physical USB/NFC security keys (YubiKey, Feitian, etc.) using FIDO2/WebAuthn. Private key is generated inside the hardware and never leaves the device. Authentication is phishing-resistant and cryptographically bound.

**Products to evaluate:**
- **YubiKey 5 series** (USB-A, USB-C, NFC variants) — most widely recognized; FIPS 140-2 Level 2 certified versions available
- **Feitian ePass FIDO** — cost-effective alternative

**Alliance Access integration:** FIDO2 native support depends on Alliance Access version. As of recent SWIFT software versions, direct FIDO2 integration may require additional middleware or an identity provider (IdP) layer. Options:
- Use a FIDO2-capable IdP (Azure AD/Entra ID with FIDO2 hardware key policy, Okta with FIDO2) that fronts Alliance Access via SAML/OIDC if your version supports it
- Use YubiKey's OTP applet (generates HOTP/TOTP) via the existing RADIUS path — this sacrifices some FIDO2 benefits but uses hardware-backed generation

**Timeline:** If using FIDO2 OTP mode over existing RADIUS infrastructure, this is fast — comparable to Option 1. If implementing a full FIDO2/IdP integration, add 4–6 weeks for IdP configuration and testing.

**Cost:** YubiKey 5 NFC is approximately $50–$55 per key; YubiKey 5 FIPS approximately $80–$90. No ongoing authentication server licensing for the FIDO2 protocol itself (though IdP licensing may apply).

**Pros:** Strong phishing resistance; no server-side shared secrets (no OTP seed database to protect); increasingly recognized by SWIFT assessors; modern standard.

**Cons:** Newer to some SWIFT assessors — ensure your assessor explicitly accepts FIDO2 hardware keys as compliant before committing. Confirm with your SWIFT-appointed assessor that your planned implementation satisfies their evidentiary requirements under Control 4.2.

---

## 4. Recommended Remediation Path for July Deadline

Given the July attestation deadline (approximately 10 weeks from today, April 25, 2026), the recommended path is:

**Primary recommendation: Thales SafeNet OTP hardware tokens with Thales STA cloud authentication service.**

Rationale:
- Fastest to implement of the three options if you have no existing MFA infrastructure
- Cloud-hosted STA eliminates on-premises server build time
- RADIUS integration with Alliance Access is well-documented and straightforward
- Thales hardware tokens are universally accepted by SWIFT assessors without ambiguity
- STA cloud can be provisioned in days; token hardware ships within 2–4 weeks

**Implementation sequence:**
1. **Week 1:** Procure Thales SafeNet OTP tokens (order immediately to account for shipping); initiate STA cloud trial/contract
2. **Week 1–2:** Configure STA cloud tenant; set up RADIUS agent on Alliance Access host or DMZ
3. **Week 2–3:** Configure Alliance Access to require RADIUS MFA at operator logon; test with pilot user
4. **Week 3–4:** Enroll all operators; conduct training on token use
5. **Week 4–5:** Run parallel operation period; validate all operators can authenticate successfully
6. **Week 5–6:** Disable Google Authenticator; enforce hardware token only
7. **Week 6–7:** Collect attestation evidence: operator enrollment list, system config screenshots, policy update, token assignment records
8. **Week 7–8:** Internal review and assessor pre-check if possible

**Secondary recommendation: FIDO2 hardware keys (YubiKey FIPS) if you have Azure AD/Entra ID or Okta already licensed.**

Only pursue this if: (a) you have an IdP that supports FIDO2 and can front Alliance Access, (b) your assessor has confirmed FIDO2 hardware keys are acceptable evidence, and (c) you can complete IdP integration and testing within the timeline.

---

## 5. Policy and Documentation Updates Required

Regardless of which hardware solution you choose, update the following before attestation:

1. **MFA Policy:** Update your SWIFT security policy to specify that hardware-based MFA is mandatory for all Alliance Access operator accounts. Remove any reference to software OTP as an acceptable method.

2. **Operator Joiner/Mover/Leaver procedure:** Document how hardware tokens are issued at onboarding, reassigned on role change, and revoked/recovered at offboarding.

3. **Token management procedure:** Document lost token process, temporary access procedure (if any — must still be MFA-compliant), and token lifecycle (replacement schedule).

4. **System configuration evidence:** Export/screenshot Alliance Access authentication configuration showing RADIUS MFA requirement is enforced, not optional.

5. **Risk register:** Close the open finding and document the remediation action, implementation date, and responsible owner.

---

## 6. Common Assessor Questions to Prepare For

- "How do you ensure the hardware token cannot be bypassed?" — Show that Alliance Access authentication configuration makes MFA mandatory at the system level, not just by policy.
- "What is your process if an operator loses their token?" — Have a documented emergency access procedure that still involves MFA (e.g., temporary token issued by security team under dual authorization).
- "Are any service accounts excluded from MFA?" — CSCF 4.2 focuses on interactive human operator sessions. Automated/service account access via APIs has different controls, but be prepared to explain scope boundaries.
- "How do you protect the authentication server?" — The RADIUS/OTP server or STA cloud service itself is part of your SWIFT security perimeter. Confirm it meets access control and availability requirements.

---

## Summary Table

| Criterion | Google Authenticator (Current) | Hardware OTP Token | Smart Card/PKI | FIDO2 Hardware Key |
|---|---|---|---|---|
| CSCF v2025 Compliant | No | Yes | Yes | Yes (confirm with assessor) |
| Seed/key in hardware | No | Yes | Yes | Yes |
| Feasible for July | N/A | Yes | Only if PKI exists | Yes (if IdP exists) |
| Approx. cost per user | Free | $50–$100 | $50–$100 + PKI | $50–$90 |
| Implementation complexity | N/A | Low–Medium | High | Medium |
| Assessor acceptance | Rejected | Universal | Universal | Confirm first |

**Bottom line:** Begin hardware token procurement this week. The finding is clear-cut and the remediation path is well-established. With focused effort, a July attestation is achievable.

# SWIFT CSCF v2025 — Gap Assessment Report

**Assessment Date:** 2026-04-25
**Framework Version:** CSCF v2025 (effective July 2025)
**Prepared for:** Organisation (hemant.naik@gmail.com)
**Scope:** All 23 mandatory controls; advisory controls noted where relevant
**Architecture Note:** Architecture type not explicitly confirmed — assessment assumes **A1** (customer-managed, software-based Alliance Access/Gateway on-premises) as the most common configuration consistent with the description provided. Controls applicable to A1 are assessed; where the architecture is A3 or A4, 1.2 would be not applicable.

---

## Executive Summary

The organisation has a **partial SWIFT security posture** with notable compliance gaps across all three CSCF objectives. Based on the information provided, **5 mandatory controls are rated RED (not implemented or critically deficient)** and **4 are rated AMBER (partially implemented)**. The most critical risks are:

1. The SWIFT zone shares a VLAN with other internal systems — violating the core isolation requirement of Control 1.1.
2. Software-based OTP is used for MFA — explicitly insufficient under CSCF v2025 (Control 4.2).
3. Log retention is only 6 months against a mandatory minimum of 1 year online, 3 years total (Control 6.4); logs are also not being reviewed.
4. No SWIFT-specific Incident Response Plan exists (Control 7.1).
5. The 30-day critical patching window exceeds the 3-day SLA required under CSCF v2025 (Control 2.2).

The organisation must address the RED-rated controls before submitting its KYC-SA attestation. All RED items would need to be attested as "Not Implemented" on the KYC-SA portal, which is visible to counterparties.

---

## Section 1: Current State Summary

| Area | Current State Provided |
|------|----------------------|
| Network segregation | SWIFT zone exists but shares a VLAN with other internal systems |
| Patching | Critical vulnerabilities patched within 30 days |
| MFA | Software-based OTP (authenticator app) used for operator MFA |
| Log collection | SWIFT logs are collected but not reviewed; retention is 6 months |
| Incident response | General IT incident response plan exists; no SWIFT-specific IRP |
| Operator accounts | Named individual accounts used (no sharing) |

---

## Section 2: Gap Assessment Table

### Objective 1 — Secure Your Environment

| Control | Control Name | Mandatory/Advisory | RAG Status | Current State | Gap Description | Evidence Required |
|---------|-------------|-------------------|-----------|---------------|-----------------|-------------------|
| **1.1** | SWIFT Environment Protection | Mandatory | 🔴 RED | SWIFT zone exists but on a shared VLAN with other internal systems | Critical gap: SWIFT zone not isolated on a dedicated VLAN/segment. Shared VLAN means other systems can communicate with SWIFT infrastructure without firewall enforcement. Dual-homing risk. Does not meet the dedicated Secure Zone requirement. | Network architecture diagram showing dedicated SWIFT Secure Zone; firewall ruleset; system inventory for Secure Zone |
| **1.2** | OS Privileged Account Control | Mandatory (A1) | 🟡 AMBER | Not stated — assumed partially in place | No evidence provided of privileged account controls on SWIFT servers. Assumed some controls exist via general IT, but no SWIFT-specific evidence of MFA for privileged OS sessions, account inventory, or PAM tooling. | Privileged account inventory; MFA evidence for privileged sessions; OS audit logs |
| **1.3A** | Virtualisation Platform Security | Advisory | Not assessed | Unknown | Advisory — not rated; should be reviewed if SWIFT runs on VMs | Hypervisor patch status; VM isolation diagram |
| **1.4** | Restriction of Internet Access | Mandatory | 🟡 AMBER | Not stated | No evidence provided that SWIFT servers or operator workstations have internet access blocked. Shared VLAN increases likelihood of unrestricted routing. Requires verification. | Firewall rules showing internet blocked for SWIFT zone IPs; proxy configuration |
| **1.5A** | Customer Environment Protection | Advisory | Not assessed | Unknown | Advisory — broader customer environment security; not directly rated here | — |
| **2.1** | Internal Data Flow Security | Mandatory | 🟡 AMBER | Not stated | No evidence provided of TLS 1.2+ on internal SWIFT component connections. Shared VLAN increases risk of unencrypted lateral traffic. Requires verification. | Data flow diagram; TLS configuration evidence; certificate inventory |
| **2.2** | Security Updates | Mandatory | 🔴 RED | Critical vulnerabilities patched within 30 days | CSCF v2025 requires critical patches within **3 calendar days** and SWIFT emergency advisories within 3 days. A 30-day SLA for criticals significantly exceeds this. High severity must be within 90 days (current state may comply for high). The 30-day window is a direct non-compliance against the v2025 tightened SLA. | Patch management reports showing SWIFT systems; SWIFT advisory subscription and action log; exception register |
| **2.3** | System Hardening | Mandatory | 🟡 AMBER | Not stated | No evidence of CIS Benchmark hardening applied to SWIFT servers or operator workstations. General IT hardening may exist but SWIFT-specific hardening baseline and scan evidence not mentioned. | Hardening baseline document; CIS-CAT or equivalent scan results; evidence of unnecessary services disabled |
| **2.4A** | Back-Office Data Flow Security | Advisory | Not assessed | Unknown | Advisory — not rated | — |
| **2.5A** | External Transmission Data Protection | Advisory | Not assessed | Unknown | Advisory — not rated | — |
| **2.6** | Operator Session Confidentiality and Integrity | Mandatory | 🟡 AMBER | Named individual accounts used | Positive: individual accounts in place. Gap: No evidence of TLS 1.2+ session encryption, 30-minute session timeout configuration, or restriction of clipboard/screen-share tools during SWIFT sessions. MFA gap (see 4.2) also impacts this control. | TLS configuration for Alliance Access web interface; session timeout screenshots; remote access tool restriction evidence |
| **2.7** | Vulnerability Scanning | Mandatory | 🟡 AMBER | Not stated | No evidence of quarterly credentialed vulnerability scans of SWIFT-in-scope systems. General IT scanning may exist. Requires confirmation that SWIFT components (Alliance Access, OS, middleware) are included in authenticated scan scope. | Credentialed scan reports for last 4 quarters covering SWIFT system hostnames/IPs |
| **2.8** | Critical Activity Outsourcing | Mandatory | 🟢 GREEN | Not applicable if fully in-house | Assumed not outsourced based on description. If any managed service, bureau, or cloud is used for SWIFT, this requires immediate review. | Contracts with SWIFT obligations; provider KYC-SA attestations if applicable |
| **2.9A** | Transaction Business Controls | Advisory | Not assessed | Unknown | Advisory — recommended to implement payment value thresholds and time-of-day controls | — |
| **2.10** | Application Hardening | Mandatory | 🟡 AMBER | Not stated | No evidence that SWIFT Alliance Access/Gateway has been configured per SWIFT's published Security Hardening Guides. Application-level hardening distinct from OS hardening. | Completed SWIFT Alliance Access / Alliance Gateway Security Hardening Guide checklist; application account audit |
| **2.11A** | RMA Business Controls | Advisory | Not assessed | Unknown | Advisory — recommended to review RMA authorisations | — |
| **3.1** | Physical Security | Mandatory | 🟡 AMBER | Not stated | No evidence provided about physical access controls for SWIFT server room or operator workstation areas. Assumed general data centre controls exist given the organisation operates SWIFT infrastructure. | Physical access logs; authorised access list; CCTV/badge system evidence |

---

### Objective 2 — Know and Limit Access

| Control | Control Name | Mandatory/Advisory | RAG Status | Current State | Gap Description | Evidence Required |
|---------|-------------|-------------------|-----------|---------------|-----------------|-------------------|
| **4.1** | Password Policy | Mandatory | 🟡 AMBER | Not stated | No evidence of a SWIFT-specific password policy (14+ character minimum, 90-day rotation for privileged accounts, 12-generation reuse prohibition, 5-attempt lockout). General IT policy may exist. | Password policy document; AD/Group Policy configuration screenshots; lockout configuration |
| **4.2** | Multi-Factor Authentication | Mandatory | 🔴 RED | Software OTP (authenticator app) used | Critical gap: CSCF v2025 explicitly states software-based OTP (authenticator apps) does **not satisfy** the MFA requirement for most architecture types. Hardware OTP tokens, smart cards with PIN, or FIDO2 hardware keys are required. This is one of the most commonly cited non-compliance findings industry-wide. Must be attested as "Not Implemented" until hardware tokens are deployed. | MFA configuration evidence; hardware token inventory; authentication logs showing MFA enforcement |
| **5.1** | Logical Access Controls | Mandatory | 🟢 GREEN | Named individual accounts used (no sharing) | Positive finding: individual named accounts are in place, which satisfies the core non-repudiation requirement. Gaps to verify: quarterly access reviews, dual-authorisation for high-risk operations, timely leaver deprovisioning (within 24 hours). | User access list with roles and approvals; access review records (last 4 quarters); leaver process records |
| **5.2** | Token Management | Mandatory | 🔴 RED | Software OTP in use (no hardware tokens) | Since hardware tokens are not yet deployed (see 4.2), there is no hardware token lifecycle management in place. When hardware tokens are deployed, a full token management process (inventory, issuance, return, lost token procedure, annual reconciliation) must be established. | Token inventory register; issuance/return records; lost token procedure; annual reconciliation evidence |
| **5.3A** | Staffing | Advisory | Not assessed | Unknown | Advisory — not rated | — |
| **5.4** | Physical and Logical Password Storage | Mandatory | 🟡 AMBER | Not stated | No evidence of a password manager or PAM vault for SWIFT credentials. Credentials may be stored insecurely. Emergency/break-glass credential procedure not mentioned. | Password manager/PAM tool evidence; break-glass credential procedure and access log |

---

### Objective 3 — Detect and Respond

| Control | Control Name | Mandatory/Advisory | RAG Status | Current State | Gap Description | Evidence Required |
|---------|-------------|-------------------|-----------|---------------|-----------------|-------------------|
| **6.1** | Malware Protection | Mandatory | 🟡 AMBER | Not stated | No evidence of anti-malware deployed on SWIFT servers and operator workstations with daily definition updates, real-time scanning, and 1-hour alert SLA. General IT AV may exist. | AV deployment scope; definition update log; alert configuration; scan history |
| **6.2** | Software Integrity | Mandatory | 🟡 AMBER | Not stated | No evidence of cryptographic hash verification of SWIFT software packages before installation and after updates. File integrity monitoring (FIM) on SWIFT binary directories not mentioned. | Hash verification records; FIM configuration (if deployed); integrity check procedure |
| **6.3** | Database Integrity | Mandatory | 🟡 AMBER | Not stated | No evidence of SWIFT database access restrictions, database change logging, integrity checks, or backup/restoration testing. | Database access control configuration; audit log samples; backup and restoration test records |
| **6.4** | Log and Monitoring | Mandatory | 🔴 RED | Logs collected but not reviewed; retention only 6 months | Two distinct gaps: (1) Logs are not being reviewed — CSCF v2025 requires **daily** review of transaction anomalies and authentication failures, and **weekly** review of other events. (2) Retention is 6 months — CSCF v2025 requires **minimum 1 year online** and **3 years total** (online + archived). This is a direct, demonstrable non-compliance on both dimensions. | SIEM configuration showing SWIFT log sources; log retention policy and technical evidence; sample alert rules; log review records (last 30 days) |
| **6.5A** | Intrusion Detection | Advisory | Not assessed | Unknown | Advisory — strongly recommended given the other gaps identified | — |
| **7.1** | Cyber Incident Response Planning | Mandatory | 🔴 RED | General IT IRP exists; no SWIFT-specific IRP | A general IT IRP does not satisfy CSCF v2025. Requirement is for a **SWIFT-specific IRP** covering: SWIFT-specific detection triggers (e.g., anomalous transaction patterns, credential compromise), 24-hour SWIFT notification obligation, forensic evidence preservation, escalation to SWIFT CISO office (security@swift.com), and annual tabletop/drill test. The 24-hour notification obligation to SWIFT is a legal/contractual obligation that cannot be met without a SWIFT-specific IRP. | SWIFT-specific IRP document (dated, approved); last annual test record; SWIFT notification contact list |
| **7.2** | Security Training and Awareness | Mandatory | 🟡 AMBER | Not stated | No evidence of annual security awareness training for SWIFT staff covering SWIFT-specific fraud scenarios (Bangladesh Bank-style attacks), phishing, social engineering, and incident reporting. General IT security training may exist but SWIFT-specific content required. | Training completion records for all SWIFT users (last 12 months); SWIFT-specific training content overview |
| **7.3A** | Penetration Testing | Advisory | Not assessed | Unknown | Advisory — strongly recommended; annual penetration test of SWIFT Secure Zone would help identify risks from the shared VLAN issue | — |
| **7.4A** | Scenario Risk Assessment | Advisory | Not assessed | Unknown | Advisory — recommended; insider fraud and credential compromise scenarios are highly relevant | — |

---

## Section 3: RAG Summary Dashboard

| RAG | Count | Controls |
|-----|-------|---------|
| 🔴 RED — Not Implemented / Critical Gap | 5 | 1.1, 2.2, 4.2, 5.2, 6.4, 7.1 |
| 🟡 AMBER — Partially Implemented / Requires Verification | 9 | 1.2, 1.4, 2.1, 2.3, 2.6, 2.7, 2.10, 3.1, 4.1, 5.4, 6.1, 6.2, 6.3, 7.2 |
| 🟢 GREEN — Implemented | 2 | 2.8 (assumed), 5.1 |
| Not assessed (Advisory) | 8 | 1.3A, 1.5A, 2.4A, 2.5A, 2.9A, 2.11A, 5.3A, 6.5A, 7.3A, 7.4A |

> Note: RED count in table is 6 controls (1.1, 2.2, 4.2, 5.2, 6.4, 7.1). The AMBER group spans 12 controls where partial implementation or lack of evidence creates compliance risk.

**KYC-SA attestation impact:** The 6 RED-rated controls must be attested as "Not Implemented" on the KYC-SA portal. This will be visible to all counterparties and may trigger counterparty queries or escalation.

---

## Section 4: Prioritised Remediation Plan

Remediation is prioritised into three tiers: **Immediate (0–30 days)**, **Short-term (30–90 days)**, and **Medium-term (90–180 days)**.

---

### Priority 1 — Immediate Actions (0–30 days)

These actions address direct non-compliance with mandatory controls that represent immediate risk to SWIFT operations, counterparty notifications, and potential regulatory escalation.

#### P1-1: Deploy Hardware MFA Tokens — Control 4.2 and 5.2
**Owner:** IT Security / SWIFT Operations
**Target:** Complete within 30 days

**Action:**
1. Procure hardware OTP tokens (e.g., Thales/Gemalto, Feitian, VASCO/OneSpan) or FIDO2 hardware keys for all SWIFT operators. Minimum: one per operator plus spares.
2. Integrate tokens with Alliance Access / Alliance Gateway authentication.
3. Disable software-based OTP for all SWIFT application logins.
4. Establish a token management process:
   - Create and maintain a token inventory register (operator name, token serial, issue date, status).
   - Document issuance/return procedures.
   - Define lost/stolen token procedure (deactivation within 1 hour of report).
   - Schedule annual token inventory reconciliation.
5. Update authentication logs to confirm MFA enforcement.

**Evidence to collect:** Token inventory; MFA configuration screenshots; authentication logs showing hardware token enforcement; token issuance records.

**KYC-SA impact:** Resolves RED on 4.2 and 5.2 simultaneously.

---

#### P1-2: Establish SWIFT-Specific Incident Response Plan — Control 7.1
**Owner:** IT Security / CISO / SWIFT Operations
**Target:** Draft and approve within 14 days; test within 30 days

**Action:**
1. Draft a SWIFT-specific IRP addendum to the existing general IT IRP. The addendum must cover:
   - SWIFT-specific detection triggers (failed MFA, after-hours logins, unusual transaction volumes, config changes on Alliance Access)
   - Escalation path to SWIFT within 24 hours of confirmed incident (contact: security@swift.com and SWIFT relationship manager)
   - Full incident report to SWIFT within 30 days
   - Evidence preservation requirements (forensic images, log preservation procedure)
   - Internal escalation to senior management immediately upon detection
   - Communication with regulators and law enforcement per local requirements
2. Maintain a SWIFT notification contact list (SWIFT CISO office, internal incident team, legal, compliance).
3. Conduct an initial tabletop exercise within 30 days of IRP completion.
4. Obtain formal approval and date the document.

**Evidence to collect:** SWIFT-specific IRP document (dated, approved by CISO); tabletop test report; SWIFT contact list.

**KYC-SA impact:** Resolves RED on 7.1.

---

#### P1-3: Establish Log Review Process and Extend Retention — Control 6.4
**Owner:** SOC / IT Security
**Target:** Retention extended within 14 days; review process operational within 30 days

**Action:**
1. **Immediate — Retention:** Configure log archival to extend SWIFT log retention from 6 months to minimum 1 year online (hot storage) and arrange archival storage for years 2–3. Ensure coverage of all SWIFT log sources: Alliance Access/Gateway application logs, OS security logs, authentication logs, network device logs for SWIFT zone, database audit logs.
2. **Immediate — SIEM ingestion:** If not already ingested, onboard SWIFT Alliance Access/Gateway logs into the SIEM or equivalent log management platform.
3. **Short-term — Alerting:** Configure automated alert rules for: failed authentication attempts, after-hours logins to SWIFT systems, large/unusual transactions, privilege escalation events, configuration changes on SWIFT components.
4. **Process — Review cadence:** Establish and document a formal log review schedule:
   - Daily: SWIFT transaction anomalies and authentication failures
   - Weekly: OS events, network device logs, configuration changes
   - Assign named reviewer(s) and retain review records.
5. Protect log integrity (ship to immutable SIEM store or read-only archive).

**Evidence to collect:** SIEM configuration showing SWIFT log sources; log retention policy and technical evidence (archive tool configuration); sample alert rules; log review records (last 30 days).

**KYC-SA impact:** Resolves RED on 6.4.

---

#### P1-4: Tighten Critical Patching SLA — Control 2.2
**Owner:** IT Operations / Patch Management
**Target:** Policy updated within 7 days; process operational immediately

**Action:**
1. Update the patch management policy to reflect CSCF v2025 SLAs:
   - Critical severity: 3 calendar days (down from current 30 days)
   - SWIFT emergency advisories: 3 calendar days
   - High severity: 90 calendar days (verify current state complies)
   - Medium: Next scheduled maintenance cycle
2. Subscribe to SWIFT's security advisory mailing list (via swift.com) and create a tracked action log for each advisory received.
3. For any critical vulnerabilities currently open beyond 3 days: document a formal risk acceptance or compensating controls exception — signed by a risk owner — and remediate immediately.
4. Configure vulnerability management tooling to tag SWIFT-in-scope systems separately so SLA reporting is automated.

**Evidence to collect:** Updated patch management policy with SWIFT SLAs; SWIFT advisory subscription confirmation; current patch status report for all SWIFT systems; exception register (if any open criticals require documented exceptions).

**KYC-SA impact:** Resolves RED on 2.2 once the 3-day SLA is being consistently met and evidenced.

---

### Priority 2 — Short-term Actions (30–90 days)

These actions address mandatory controls where partial implementation or lack of evidence creates compliance risk. Most require investigation and remediation of specific gaps.

#### P2-1: Isolate SWIFT Zone onto Dedicated VLAN/Segment — Control 1.1
**Owner:** Network Engineering / IT Security
**Target:** Design complete within 30 days; implementation within 60–90 days

**Action:**
1. Map all SWIFT components and their current network connectivity (Alliance Access, Alliance Gateway, HSMs, operator workstations, back-office interfaces).
2. Design a dedicated SWIFT Secure Zone:
   - Dedicated VLAN(s) not shared with any non-SWIFT system
   - Stateful firewall between SWIFT Secure Zone and corporate network (deny-by-default rules; whitelist only required flows)
   - Stateful firewall or ACL between SWIFT Secure Zone and internet path
3. Confirm no dual-homed systems (connected to both SWIFT zone and general network).
4. Remove any non-SWIFT applications from SWIFT servers (email clients, web browsers, general business apps).
5. Document all approved network flows in and out of the Secure Zone; schedule periodic review.
6. Conduct a post-migration validation: verify SWIFT zone isolation using network scans and firewall rule review.

**Note:** This is the single highest-impact architectural remediation. It also partially addresses 1.4 (internet restriction) and 2.1 (internal data flow security). Change management approval required; may need a maintenance window.

**Evidence to collect:** Updated network architecture diagram showing dedicated SWIFT Secure Zone; firewall ruleset and change records; system inventory for Secure Zone; confirmation of no dual-homing (config screenshots).

**KYC-SA impact:** Resolves RED on 1.1. Also substantially improves 1.4, 2.1, 2.3 ratings.

---

#### P2-2: Block Internet Access for SWIFT Zone — Control 1.4
**Owner:** Network Engineering
**Target:** Within 60 days (concurrent with P2-1)

**Action:**
1. Verify and configure firewall rules to block all direct internet access from SWIFT zone IPs.
2. If SWIFTNet connectivity requires internet routing, ensure all traffic passes through a controlled and monitored proxy or dedicated circuit — not open internet routing.
3. Block all internet-bound traffic from SWIFT-dedicated operator workstations.
4. Document exceptions (if any) with risk justification.

**Evidence to collect:** Firewall rules showing internet blocked for SWIFT zone IPs; proxy configuration if applicable; network flow test results.

---

#### P2-3: Implement TLS 1.2+ for Internal SWIFT Data Flows — Control 2.1 and 2.6
**Owner:** SWIFT Operations / IT Security
**Target:** Within 60 days

**Action:**
1. Map all internal connections between SWIFT components (Alliance Access to Gateway, to back-office middleware, database connections).
2. Verify TLS 1.2+ is configured on all these connections. Disable TLS 1.0 and 1.1.
3. Verify the Alliance Access/Gateway web interface for operators uses TLS 1.2+ with a valid certificate.
4. Configure session timeouts to maximum 30 minutes of inactivity for SWIFT operator sessions.
5. Restrict clipboard, screen-share, and remote control tools on SWIFT workstations during sessions.
6. Maintain a certificate inventory with expiry tracking and automated renewal alerts.

**Evidence to collect:** Data flow diagram; TLS configuration evidence for each connection; certificate inventory; session timeout configuration screenshots.

---

#### P2-4: Apply System and Application Hardening — Controls 2.3 and 2.10
**Owner:** IT Operations / SWIFT Operations
**Target:** Within 90 days

**Action:**
1. **OS hardening (Control 2.3):**
   - Obtain CIS Benchmarks for the OS versions running on SWIFT servers and operator workstations.
   - Run a baseline hardening scan (CIS-CAT or equivalent) against each SWIFT system.
   - Remediate deviations: disable unnecessary services, close unused ports, remove unused software and accounts, enable host-based firewalls.
   - Document the hardening baseline; schedule re-checks after every change.
2. **Application hardening (Control 2.10):**
   - Download and complete the SWIFT Alliance Access Security Hardening Guide (available from swift.com).
   - Download and complete the Alliance Gateway Security Hardening Guide if applicable.
   - Disable unused SWIFT application features and interfaces.
   - Review and tighten all application-level accounts to least-privilege; remove default accounts.
   - Change any default application credentials.
   - Schedule quarterly review of SWIFT application accounts.

**Evidence to collect:** Hardening baseline document; CIS-CAT scan results; evidence of unnecessary services disabled; completed SWIFT hardening guide checklists; application account audit report.

---

#### P2-5: Conduct Quarterly Credentialed Vulnerability Scanning — Control 2.7
**Owner:** IT Security / Vulnerability Management
**Target:** First scan within 30 days; quarterly cadence established within 60 days

**Action:**
1. Ensure all SWIFT in-scope systems are included in the vulnerability scanning scope:
   - SWIFT servers (Alliance Access, Alliance Gateway)
   - SWIFT-connected OS and middleware
   - Network devices in the SWIFT zone
   - SWIFT-dedicated operator workstations
2. Configure authenticated (credentialed) scans — unauthenticated scans do not satisfy the CSCF requirement.
3. Run the first credentialed scan and review results.
4. Remediate findings per Control 2.2 patching SLAs.
5. Track remediation of identified vulnerabilities to closure.
6. Schedule quarterly cadence and retain last 4 quarters of scan reports.

**Evidence to collect:** Credentialed scan reports for last 4 quarters (once established); scanner credential configuration; remediation tracking records.

---

#### P2-6: Formalise Access Reviews and Leaver Process — Control 5.1
**Owner:** SWIFT Operations / HR / IT Security
**Target:** Within 60 days

**Action:**
1. Produce a complete user access list for all SWIFT applications with roles and approval evidence.
2. Establish a quarterly access review process — named reviewer, documented sign-off, records retained.
3. Implement dual-authorisation for high-risk operations (e.g., creating new BIC connections, adding new operator accounts).
4. Formalise the leaver process: SWIFT access must be removed within 24 hours of departure — document this in the HR offboarding procedure.
5. Conduct an immediate access review to identify any stale or inappropriate access.

**Evidence to collect:** User access list with roles and approvals; access review records (last 4 quarters once established); dual-authorisation evidence; leaver process records.

---

#### P2-7: Deploy Malware Protection on SWIFT Systems — Control 6.1
**Owner:** IT Operations
**Target:** Within 30 days (verify or deploy)

**Action:**
1. Confirm anti-malware is deployed on all SWIFT servers and operator workstations.
2. Verify daily automated definition updates are running.
3. Verify real-time scanning is enabled.
4. Configure scheduled full scans.
5. Configure alerts for malware detections to reach the security team within 1 hour.
6. Establish that malware found on any SWIFT system is treated as a security incident per the SWIFT-specific IRP (P1-2).

**Evidence to collect:** AV deployment and configuration screenshots; definition update log (last 30 days); alert configuration evidence; scan history reports.

---

### Priority 3 — Medium-term Actions (90–180 days)

These actions address controls where baseline compliance may be partially in place but require formalisation, evidence collection, and SWIFT-specific documentation.

#### P3-1: Implement Software Integrity Verification — Control 6.2
**Owner:** SWIFT Operations
**Target:** Within 90 days

**Action:**
1. Document and implement a procedure to verify cryptographic hashes of SWIFT software packages before installation (compare against SWIFT-published checksums available at swift.com).
2. Perform integrity verification after every SWIFT software update.
3. Define a procedure: unauthorised changes to SWIFT executable files trigger a security incident.
4. Consider deploying file integrity monitoring (FIM) on SWIFT binary directories (e.g., Tripwire, OSSEC, or equivalent).
5. Retain hash verification records for audit.

**Evidence to collect:** Hash verification records for recent SWIFT software installations/updates; FIM configuration covering SWIFT directories; integrity check procedure document.

---

#### P3-2: Establish Database Integrity Controls — Control 6.3
**Owner:** Database Administration / SWIFT Operations
**Target:** Within 90 days

**Action:**
1. Restrict database access to authorised SWIFT application service accounts only — no direct operator access to production SWIFT databases.
2. Enable database change logging and configure alerts to the security team for unexpected changes.
3. Configure regular database integrity checks.
4. Test database backup and restoration procedure; document results and schedule annual re-tests.

**Evidence to collect:** Database access control configuration; database audit log samples; backup and restoration test records.

---

#### P3-3: Strengthen Password Policy and Credential Storage — Controls 4.1 and 5.4
**Owner:** IT Security
**Target:** Within 90 days

**Action:**
1. **Password policy (4.1):** Formalise a SWIFT-specific password policy (or verify the existing policy covers SWIFT):
   - Minimum 14 characters
   - Complexity: upper, lower, number, special character
   - Maximum 90 days for privileged accounts; 180 days for standard SWIFT accounts
   - No reuse for 12 generations
   - Lockout after 5 failed attempts
   - No shared or generic accounts
   - Implement via Group Policy / Active Directory and document configuration screenshots.
2. **Credential storage (5.4):** Ensure all SWIFT application passwords and credentials are stored in an approved password manager or PAM vault (e.g., CyberArk, HashiCorp Vault, or equivalent). Remove any credentials from plaintext files or spreadsheets. Establish an emergency/break-glass credential procedure with tamper-evident storage and access logging.

**Evidence to collect:** Password policy document; AD/Group Policy configuration; lockout configuration evidence; password manager/PAM tool evidence showing SWIFT credentials; break-glass credential procedure and access log.

---

#### P3-4: Implement OS Privileged Account Controls — Control 1.2
**Owner:** IT Security / SWIFT Operations
**Target:** Within 90 days

**Action:**
1. Produce a privileged account inventory for all SWIFT servers (root, local admin accounts).
2. Ensure privileged accounts are not used for routine operations — enforce use of non-privileged accounts for daily tasks.
3. Implement MFA for privileged OS sessions where technically feasible (consider PAM tooling).
4. Rename or disable all default/factory OS accounts.
5. Enable and review OS audit logs for all privileged account activity.

**Evidence to collect:** Privileged account inventory; MFA evidence for privileged sessions; privileged account usage policy; OS audit logs.

---

#### P3-5: Verify Physical Security Controls — Control 3.1
**Owner:** Facilities / IT Operations
**Target:** Within 60 days (verify existing controls and close gaps)

**Action:**
1. Confirm SWIFT servers are housed in a locked, access-controlled facility (data centre or server room).
2. Verify access is restricted to named individuals with documented authorisation — produce an access list.
3. Confirm physical access is logged electronically (badge reader, CCTV audit trail).
4. Implement visitor escort policy if not already in place.
5. Confirm SWIFT-dedicated operator workstations are in physically controlled areas.

**Evidence to collect:** Physical access control system logs; authorised access list for data centre/SWIFT server room; CCTV or badge system evidence.

---

#### P3-6: SWIFT-Specific Security Training — Control 7.2
**Owner:** HR / IT Security / Compliance
**Target:** Within 90 days

**Action:**
1. Develop or procure SWIFT-specific security awareness training covering:
   - Phishing and social engineering targeting SWIFT credentials
   - SWIFT fraud scenarios (Bangladesh Bank-style attacks, business email compromise leading to fraudulent MT103s)
   - Incident reporting procedures (internal and 24-hour SWIFT notification obligation)
   - Role-specific training for SWIFT operators on CSP requirements
2. Deliver training to all staff with SWIFT access and track completion.
3. Schedule annual refresh training.

**Evidence to collect:** Training completion records for all SWIFT users (last 12 months); training content overview showing SWIFT-specific topics; role-specific training materials.

---

#### P3-7: Advisory Controls — Consider for Enhanced Posture

| Advisory Control | Recommendation |
|----------------|---------------|
| **6.5A — Intrusion Detection** | Deploy network IDS/IPS at the SWIFT zone perimeter. Given the current shared VLAN issue, this becomes more urgent as an interim compensating control while P2-1 (zone isolation) is implemented. |
| **7.3A — Penetration Testing** | Schedule an annual penetration test of the SWIFT Secure Zone once isolation (P2-1) is complete. Include network perimeter, Alliance Access application layer, and authentication mechanisms. |
| **7.4A — Scenario Risk Assessment** | Conduct a scenario-based risk assessment covering: insider fraud, compromised SWIFT operator credentials, supply chain attack on SWIFT software, ransomware propagation to SWIFT zone. |
| **2.9A — Transaction Business Controls** | Implement payment value thresholds, time-of-day restrictions, and beneficiary whitelist controls to detect and prevent fraudulent transactions. Strongly recommended given the logging and monitoring gaps. |
| **1.3A — Virtualisation Platform Security** | If SWIFT runs on VMs, review hypervisor patch status, management interface access controls, and VM isolation. |

---

## Section 5: Remediation Timeline Summary

| Priority | Timeframe | Controls | Key Actions |
|----------|-----------|---------|-------------|
| P1 — Immediate | 0–30 days | 4.2, 5.2, 7.1, 6.4, 2.2 | Deploy hardware MFA tokens; draft SWIFT IRP; extend log retention and establish review process; tighten patching SLA to 3 days |
| P2 — Short-term | 30–90 days | 1.1, 1.4, 2.1, 2.3, 2.6, 2.7, 2.10, 5.1, 6.1 | Isolate SWIFT zone to dedicated VLAN; block internet access; apply TLS 1.2+; harden OS and application; establish vulnerability scanning; formalise access reviews; deploy AV |
| P3 — Medium-term | 90–180 days | 1.2, 3.1, 4.1, 5.4, 6.2, 6.3, 7.2 | Privileged account controls; physical security verification; password policy; credential storage; software/database integrity; SWIFT-specific security training |

---

## Section 6: KYC-SA Attestation Readiness

Based on current state, the following attestation positions apply for the mandatory controls:

| Control | Attestation Status (Current) | Target Attestation (Post-Remediation) |
|---------|------------------------------|---------------------------------------|
| 1.1 | Not Implemented | Implemented |
| 1.2 | Partially Implemented | Implemented |
| 1.4 | Partially Implemented | Implemented |
| 2.1 | Partially Implemented | Implemented |
| 2.2 | Not Implemented | Implemented |
| 2.3 | Partially Implemented | Implemented |
| 2.6 | Partially Implemented | Implemented |
| 2.7 | Partially Implemented | Implemented |
| 2.8 | Implemented | Implemented |
| 2.10 | Partially Implemented | Implemented |
| 3.1 | Partially Implemented | Implemented |
| 4.1 | Partially Implemented | Implemented |
| 4.2 | Not Implemented | Implemented |
| 5.1 | Implemented | Implemented |
| 5.2 | Not Implemented | Implemented |
| 5.4 | Partially Implemented | Implemented |
| 6.1 | Partially Implemented | Implemented |
| 6.2 | Partially Implemented | Implemented |
| 6.3 | Partially Implemented | Implemented |
| 6.4 | Not Implemented | Implemented |
| 7.1 | Not Implemented | Implemented |
| 7.2 | Partially Implemented | Implemented |

**Immediate action required:** If the KYC-SA deadline is within 90 days, the organisation should prioritise P1 actions and submit with "Not Implemented" or "Partially Implemented" attestation for controls where gaps remain. This is preferable to missing the July 31 deadline. A remediation roadmap (this document) should be available to share with counterparties and the independent assessor.

**Independent assessment note:** The organisation must engage an independent assessor (internal audit or external firm with SWIFT CSP competency) before submitting its KYC-SA attestation. The assessor must not have operational responsibility for the SWIFT environment. Allow 4–8 weeks for the assessment process.

---

## Section 7: Quick-Reference Positive Findings

The following aspects of the current state represent a **positive foundation** to build on:

| Finding | Relevant Control | Benefit |
|---------|----------------|---------|
| Named individual operator accounts (no shared accounts) | 5.1 | Satisfies the core non-repudiation requirement; audit trails are operator-attributable |
| SWIFT zone exists (even if not yet isolated) | 1.1 | SWIFT infrastructure is identified and bounded; isolation is the remaining step |
| Logs are being collected | 6.4 | Log collection pipeline exists; review and retention extension are the gaps, not a rebuild |
| General IT IRP exists | 7.1 | SWIFT-specific addendum to an existing IRP is faster to develop than starting from scratch |
| General IT patching process exists | 2.2 | Process infrastructure exists; the gap is tightening the SLA and scoping SWIFT systems specifically |

---

*This assessment is based on the current state information provided and is valid as at 2026-04-25. It should be reviewed after each remediation milestone and updated prior to submission of the annual KYC-SA attestation. An independent assessment by a qualified SWIFT CSP assessor is required before formal attestation.*

# SWIFT CSCF v2025 Gap Assessment

**Organisation Assessment Date:** 2026-04-25
**Framework:** SWIFT Customer Security Controls Framework (CSCF) v2025
**Assessment Type:** Gap Assessment with Prioritised Remediation Plan

---

## Executive Summary

Based on the current state provided, the organisation has partial compliance with the SWIFT CSCF v2025. Critical gaps exist across network segregation, MFA strength, log management, and incident response. The organisation is at elevated risk of non-compliance and potential SWIFT suspension pending remediation. Five controls are rated as non-compliant (Red), two as partially compliant (Amber), and two as compliant (Green).

---

## Current State Input Summary

| Area | Current State |
|------|--------------|
| Network Segregation | SWIFT zone exists but on shared VLAN with other internal systems |
| Vulnerability Management | Critical vulnerabilities patched within 30 days |
| Multi-Factor Authentication | Software OTP used for operator MFA |
| Logging & Monitoring | Logs collected but not reviewed; 6-month retention |
| Incident Response | General IT IR plan; no SWIFT-specific plan |
| Account Management | Operators use named individual accounts |

---

## Control-by-Control Gap Assessment

### Control 1.1 — SWIFT Environment Protection (Mandatory)

**Requirement:** The SWIFT infrastructure must be protected from the broader IT environment through a secure zone with strict access controls and network segmentation. The SWIFT zone must be logically and/or physically isolated from other parts of the network, including general corporate IT systems.

**Current State:** SWIFT zone exists but is on a shared VLAN with other internal systems.

**Gap:** Sharing a VLAN with non-SWIFT internal systems violates the fundamental zone isolation requirement. A VLAN without additional micro-segmentation controls (firewalls, access control lists scoped exclusively to SWIFT flows) does not constitute adequate isolation. Lateral movement from a compromised internal host to SWIFT infrastructure is a realistic threat vector.

**Rating: NON-COMPLIANT (Red)**

**Evidence Required to Close:**
- Network diagram showing SWIFT zone physically or logically isolated
- Firewall rule-set restricting all inbound/outbound flows to only required SWIFT communication paths
- No shared VLAN membership between SWIFT and non-SWIFT assets
- Third-party penetration test confirming zone isolation

---

### Control 1.2 — Privileged Account Control (Mandatory)

**Requirement:** Operating system and application privileged accounts on SWIFT infrastructure must be restricted and controlled. Generic/shared accounts are prohibited.

**Current State:** Operators use named individual accounts.

**Gap:** No gap identified. Named individual accounts satisfy the requirement that operators are identifiable and accounts are not shared. Provided that privileged access is appropriately restricted and access rights are reviewed periodically, this control is met.

**Rating: COMPLIANT (Green)**

**Recommendations (Advisory):**
- Ensure periodic access reviews (at least annually) are documented
- Confirm that account provisioning/de-provisioning processes are tied to HR joiners/movers/leavers workflows
- Maintain an authorised user register for the SWIFT environment

---

### Control 2.2 — Security Updates (Mandatory)

**Requirement:** SWIFT-related components (operating systems, applications, network devices) must be kept up to date with security patches. Critical vulnerabilities must be patched within a defined timescale — CSCF v2025 requires critical patches to be applied within one month (approximately 30 days) for mandatory components.

**Current State:** Critical vulnerabilities patched within 30 days.

**Gap:** The 30-day patching cycle meets the CSCF v2025 mandatory threshold for critical vulnerabilities. However, this rating assumes the 30-day cycle applies specifically to SWIFT infrastructure components and is consistently achieved and evidenced. If the 30-day clock is an aspiration rather than a demonstrated, tracked metric, there is a documentation gap.

**Rating: COMPLIANT (Green) — with caveat**

**Recommendations (Advisory):**
- Maintain a SWIFT-scoped vulnerability tracking register with patch dates evidenced
- Confirm that the 30-day cycle is measured from vulnerability disclosure or vendor patch release, not from internal discovery
- Consider tightening the target for zero-day or actively exploited vulnerabilities

---

### Control 4.2 — Multi-Factor Authentication (Mandatory)

**Requirement:** MFA must be enforced for all operator accounts accessing the SWIFT environment. CSCF v2025 strengthens MFA requirements: software-based OTP (e.g., authenticator apps generating TOTP codes) no longer satisfies the mandatory MFA requirement for SWIFT operator access in isolation. Hardware-based authentication tokens or hardware security keys (e.g., FIDO2/WebAuthn, PKI smart cards, or SWIFT-approved hardware tokens) are required for mandatory compliance.

**Current State:** Software OTP used for operator MFA.

**Gap:** Software OTP (TOTP via authenticator app) is considered a weaker form of MFA under CSCF v2025. The framework explicitly requires that MFA for SWIFT operator access uses a hardware-based second factor or a solution that cannot be compromised by malware on the operator workstation. Software OTP running on the same endpoint as the SWIFT client does not provide sufficient separation. This is a mandatory control failure.

**Rating: NON-COMPLIANT (Red)**

**Evidence Required to Close:**
- Deployment of hardware authentication tokens (e.g., RSA SecurID, FIDO2 hardware keys, smart card/PKI) for all SWIFT operators
- Configuration documentation showing hardware MFA enforced at the application/system level
- Enrolment records for all operator accounts

---

### Control 6.1 — Operator Session Confidentiality and Integrity (Advisory — but risk-relevant)

This control is implicitly impacted by the MFA weakness noted under 4.2 and is noted for completeness. If software OTP is running on the operator workstation, the session integrity guarantee is weakened. No separate rating issued — remediation of 4.2 addresses this.

---

### Control 6.4 — Logging and Monitoring (Mandatory)

**Requirement:** SWIFT-related event logs must be recorded, protected, and reviewed. CSCF v2025 requires:
- Logs must be actively reviewed (not just collected)
- Anomalous activity must be detected and investigated
- Log retention must be a minimum of 12 months (with at least 3 months readily available online)

**Current State:** SWIFT logs are collected but not reviewed; retention is only 6 months.

**Gap:** Two distinct failures:
1. **No log review:** Collecting logs without reviewing them provides zero detection capability. This is a fundamental failure of the monitoring requirement. Unreviewed logs cannot satisfy the detective control objective.
2. **Insufficient retention:** 6-month retention falls short of the 12-month mandatory minimum. This creates forensic investigation risk and potential non-compliance in the event of a SWIFT-notified incident.

**Rating: NON-COMPLIANT (Red)**

**Evidence Required to Close:**
- Documented log review process (automated alerting via SIEM, or defined manual review schedule — minimum daily review of critical alerts)
- Evidence of log reviews performed (review logs, SIEM alert records)
- Log retention policy updated to minimum 12 months
- Technical confirmation that log storage capacity and archival processes support 12-month retention
- Logs must be tamper-evident and access-controlled

---

### Control 6.5 — Intrusion Detection (Advisory in v2025 for some architectures, Mandatory for others)

**Current State:** Not explicitly stated. Assumed not deployed given the broader monitoring gap.

**Gap (Assumed):** If no IDS/IPS or SIEM-based anomaly detection is in place on the SWIFT zone boundary, this represents an advisory gap that should be addressed in conjunction with the log review remediation.

**Rating: PARTIALLY COMPLIANT (Amber) — assumed**

**Recommendations:**
- Deploy network-based intrusion detection on SWIFT zone boundaries
- Integrate SWIFT logs into a SIEM with correlation rules for known SWIFT attack patterns (e.g., fraudulent payment message injection, bulk transfer anomalies)

---

### Control 7.1 — Cyber Incident Response Planning (Mandatory)

**Requirement:** Organisations must have a documented, tested cyber incident response plan that specifically covers SWIFT-related incidents, including procedures for contacting SWIFT, isolating the SWIFT infrastructure, preserving evidence, and notifying relevant parties.

**Current State:** General IT incident response plan exists; no SWIFT-specific plan.

**Gap:** A generic IT IR plan does not satisfy this control. SWIFT incidents have specific characteristics — fraudulent payment messages, potential backdoors in the SWIFT messaging layer, mandatory SWIFT notification obligations, and coordination with correspondent banks and regulators. A SWIFT-specific annex or standalone IR plan is required, covering:
- SWIFT-specific escalation contacts (SWIFT ISAC, local SWIFT support)
- Payment message recall and freezing procedures
- Evidence preservation for SWIFT logs and messaging databases
- Regulatory and law enforcement notification thresholds

**Rating: NON-COMPLIANT (Red)**

**Evidence Required to Close:**
- SWIFT-specific IR plan documented and approved
- IR plan tested via tabletop exercise (at minimum annually)
- Exercise records and lessons learned documented
- Staff trained on SWIFT-specific IR procedures

---

### Control 2.4A — Back Office Data Flow Security (Advisory)

**Current State:** Not explicitly addressed; shared VLAN environment creates implicit risk for back-office data flows.

**Gap (Inferred):** If back-office systems share the VLAN with SWIFT systems, data flow security between SWIFT and back-office cannot be adequately controlled.

**Rating: PARTIALLY COMPLIANT (Amber) — inferred from network state**

---

## Consolidated Control Ratings Summary

| Control | Control Name | Mandatory/Advisory | Rating |
|---------|-------------|-------------------|--------|
| 1.1 | SWIFT Environment Protection | Mandatory | NON-COMPLIANT (Red) |
| 1.2 | Privileged Account Control | Mandatory | COMPLIANT (Green) |
| 2.2 | Security Updates | Mandatory | COMPLIANT (Green) |
| 4.2 | Multi-Factor Authentication | Mandatory | NON-COMPLIANT (Red) |
| 6.4 | Logging and Monitoring | Mandatory | NON-COMPLIANT (Red) |
| 6.5 | Intrusion Detection | Advisory/Mandatory | PARTIALLY COMPLIANT (Amber) |
| 7.1 | Cyber Incident Response | Mandatory | NON-COMPLIANT (Red) |
| 2.4A | Back Office Data Flow Security | Advisory | PARTIALLY COMPLIANT (Amber) |

**Overall Compliance Score: 2 Green / 2 Amber / 4 Red**

---

## Prioritised Remediation Plan

Priorities are assigned based on: (1) mandatory vs advisory status, (2) exploitability and potential financial/reputational impact if control is absent, and (3) remediation complexity.

---

### Priority 1 — CRITICAL: Network Segregation (Control 1.1)

**Priority Rationale:** This is the foundational security control for the entire SWIFT architecture. All other controls are undermined if the SWIFT zone is not properly isolated. A compromised internal system on the shared VLAN can directly access SWIFT infrastructure.

**Remediation Actions:**

1. Engage network architecture team to design dedicated SWIFT VLAN/segment with no shared membership with corporate IT VLANs.
2. Deploy dedicated firewall (or firewall policy partition) at the SWIFT zone perimeter with default-deny inbound/outbound rules.
3. Whitelist only required communication flows: SWIFT messaging interfaces (SWIFTNet Link, Alliance Gateway), approved operator workstations, and authorised management hosts.
4. Remove SWIFT assets from the shared VLAN.
5. Commission a penetration test or network segmentation review to validate isolation.
6. Update network documentation and maintain a current network diagram.

**Target Timeline:** 60 days (immediate initiation, phased cutover)
**Owner:** Network/Infrastructure Team + SWIFT IT Owner
**Effort:** High (infrastructure change with potential downtime window)

---

### Priority 2 — CRITICAL: Multi-Factor Authentication Upgrade (Control 4.2)

**Priority Rationale:** Software OTP can be compromised by malware on the operator workstation — the exact attack vector used in multiple historical SWIFT fraud cases (e.g., Bangladesh Bank). Upgrading to hardware MFA is mandatory and directly mitigates credential theft attacks.

**Remediation Actions:**

1. Select and procure hardware authentication tokens or FIDO2 hardware security keys for all SWIFT operators (e.g., YubiKey, Thales SafeNet, RSA SecurID hardware token).
2. Enrol all SWIFT operator accounts with hardware MFA.
3. Update authentication policy to require hardware MFA at SWIFT application login — disable software OTP fallback.
4. Test authentication flow to confirm hardware MFA enforced end-to-end.
5. Document MFA configuration and maintain enrolment register.
6. Define a procedure for lost/damaged token replacement without creating a bypass window.

**Target Timeline:** 45 days
**Owner:** Identity & Access Management Team + SWIFT Application Owner
**Effort:** Medium (procurement lead time is primary constraint)

---

### Priority 3 — HIGH: Log Review Process and Retention Extension (Control 6.4)

**Priority Rationale:** Without log review, the organisation has no ability to detect a SWIFT compromise in progress. The Bangladesh Bank fraud and subsequent SWIFT incidents persisted for extended periods precisely because monitoring was absent. Extending retention also closes a forensic gap.

**Remediation Actions:**

1. Implement automated log ingestion of SWIFT logs into a SIEM (e.g., Splunk, Microsoft Sentinel, IBM QRadar) or centralised log management platform.
2. Develop SWIFT-specific detection rules, including: unusual transaction volumes, after-hours operator logins, failed authentication spikes, configuration changes on SWIFT infrastructure.
3. Define a daily (or real-time alert-based) log review process with documented responsibilities.
4. Increase log retention to minimum 12 months; ensure at least 3 months of logs are readily searchable online.
5. Implement log integrity controls (write-once storage or cryptographic signing) to prevent tampering.
6. Document the log review process and evidence retention schedule in a formal policy.

**Target Timeline:** 60 days (SIEM integration may require phased approach)
**Owner:** Security Operations / SIEM Team + SWIFT IT Owner
**Effort:** High (SIEM onboarding and rule development)

---

### Priority 4 — HIGH: SWIFT-Specific Incident Response Plan (Control 7.1)

**Priority Rationale:** Without a SWIFT-specific IR plan, the organisation will lose critical hours in the event of a fraud incident. Payment message recall windows are extremely short (often hours). A tested plan is mandatory under CSCF v2025.

**Remediation Actions:**

1. Draft a SWIFT-specific IR plan as a standalone document or formal annex to the existing IT IR plan, covering:
   - Roles and responsibilities (SWIFT IR Lead, CISO, Finance/Treasury, Legal)
   - Detection and initial triage procedures for SWIFT fraud indicators
   - Isolation procedures for SWIFT infrastructure (network isolation steps, documented and pre-approved)
   - Payment recall procedures and escalation to correspondent banks
   - SWIFT mandatory notification procedures (SWIFT ISAC, local SWIFT support contact)
   - Evidence preservation: SWIFT messaging database, logs, operator session records
   - Regulatory notification thresholds (local financial regulator, law enforcement)
   - Post-incident review and lessons learned process
2. Obtain management sign-off on the plan.
3. Conduct a tabletop exercise simulating a SWIFT fraud scenario within 30 days of plan completion.
4. Document exercise findings and update the plan accordingly.
5. Schedule annual review and re-testing.

**Target Timeline:** 45 days (plan draft + exercise)
**Owner:** CISO + Compliance + Treasury + Legal
**Effort:** Medium (primarily process and documentation effort)

---

### Priority 5 — MEDIUM: Intrusion Detection on SWIFT Zone Boundary (Control 6.5)

**Priority Rationale:** Once the SWIFT zone is properly segregated (Priority 1) and log monitoring is implemented (Priority 3), deploying IDS/IPS at the SWIFT zone boundary provides an additional detection layer for network-based attacks.

**Remediation Actions:**

1. Deploy network IDS/IPS (or configure existing capability) at the SWIFT zone firewall/perimeter to inspect traffic entering and leaving the SWIFT zone.
2. Enable SWIFT-relevant signatures and anomaly detection rules.
3. Integrate IDS alerts into the SIEM/log review process established under Priority 3.
4. Test IDS coverage and tune to reduce false positives.

**Target Timeline:** 90 days (dependent on Priority 1 network redesign)
**Owner:** Network Security / SOC Team
**Effort:** Medium

---

### Priority 6 — MEDIUM: Back-Office Data Flow Review (Control 2.4A)

**Priority Rationale:** Advisory control but directly relevant given the shared VLAN environment. Once network segregation is remediated, data flow paths between SWIFT and back-office systems should be formally documented and secured.

**Remediation Actions:**

1. Map all data flows between SWIFT infrastructure and back-office/ERP systems.
2. Ensure all flows traverse the SWIFT zone firewall and are explicitly whitelisted.
3. Apply encryption in transit for back-office data flows where applicable.
4. Document approved data flows in the network architecture documentation.

**Target Timeline:** 90 days (dependent on Priority 1)
**Owner:** Network/Infrastructure Team + Application Owner
**Effort:** Low-Medium

---

## Remediation Timeline Summary

| Priority | Control | Action | Target Completion | Effort |
|----------|---------|--------|------------------|--------|
| 1 | 1.1 | Network Segregation — dedicated SWIFT VLAN + firewall | Day 60 | High |
| 2 | 4.2 | Hardware MFA deployment for all operators | Day 45 | Medium |
| 3 | 6.4 | SIEM log ingestion, daily review, 12-month retention | Day 60 | High |
| 4 | 7.1 | SWIFT-specific IR plan + tabletop exercise | Day 45 | Medium |
| 5 | 6.5 | IDS/IPS on SWIFT zone boundary | Day 90 | Medium |
| 6 | 2.4A | Back-office data flow review and documentation | Day 90 | Low-Medium |

---

## Immediate Actions (Within 7 Days)

The following actions should be initiated immediately regardless of the broader remediation timeline:

1. **Escalate to CISO and senior management** — the volume of mandatory control gaps represents a material compliance risk and potential grounds for SWIFT to restrict messaging access.
2. **Initiate hardware MFA procurement** — ordering hardware tokens has a lead time; procurement should begin immediately.
3. **Assign a SWIFT compliance owner** — a named individual should own CSCF compliance and coordinate the remediation programme.
4. **Begin network architecture design** — engage network team to design the isolated SWIFT VLAN before any other infrastructure changes are made.
5. **Extend log retention immediately** — as a short-term measure, adjust log rotation settings to cease deletion of logs older than 6 months while the full 12-month retention architecture is designed.

---

## Assumptions and Caveats

- This assessment is based solely on the current state information provided. A full assessment would require review of technical documentation, network diagrams, system configurations, and interviews with SWIFT operations staff.
- CSCF v2025 control applicability depends on the organisation's SWIFT architecture type (A1, A2, A3, A4, B). Controls assessed here are broadly applicable across architecture types, but specific mandatory/advisory designations may vary.
- The "Compliant" rating for Control 2.2 (patching) assumes the 30-day metric is consistently achieved and evidenced for SWIFT-specific components. A documentation review would be needed to confirm.
- Control 1.2 (named accounts) is rated Compliant based on the information provided; this does not account for whether access rights are appropriately scoped or whether periodic reviews occur.
- SWIFT KYC-SA (Know Your Customer — Security Attestation) submissions are due annually. The gaps identified here will need to be reflected accurately in the next KYC-SA attestation and remediation tracked accordingly.

---

*Assessment completed: 2026-04-25*
*Framework version: SWIFT CSCF v2025*
*Assessment method: General knowledge assessment (no skill files referenced)*

# KYC-SA Attestation Guide for A1 Architecture Banks
## SWIFT CSCF v2025 — Annual Attestation by July 31

---

## Your Situation at a Glance

You are an **A1 architecture bank** (customer connector, customer-managed, software-based — typically Alliance Access/Gateway deployed on-premises). Your annual KYC-SA attestation must be submitted by **July 31**. Today's date is April 25, 2026, leaving you approximately 97 days.

As an A1 user, all 23 mandatory controls apply to you in full, plus 8 advisory controls you may optionally attest. This guide walks you through every step: what to prepare, who can assess you, how to complete the form, and what happens after you submit.

---

## Section 1: What Controls Apply to You (A1 Architecture)

For an A1 bank, the following controls are **mandatory** — you must attest a compliance status for each:

| Control | Name | Objective |
|---------|------|-----------|
| **1.1** | SWIFT Environment Protection | 1 — Secure Your Environment |
| **1.2** | OS Privileged Account Control | 1 — Secure Your Environment |
| **1.4** | Restriction of Internet Access | 1 — Secure Your Environment |
| **2.1** | Internal Data Flow Security | 1 — Secure Your Environment |
| **2.2** | Security Updates | 1 — Secure Your Environment |
| **2.3** | System Hardening | 1 — Secure Your Environment |
| **2.6** | Operator Session Confidentiality and Integrity | 1 — Secure Your Environment |
| **2.7** | Vulnerability Scanning | 1 — Secure Your Environment |
| **2.8** | Critical Activity Outsourcing | 1 — Secure Your Environment |
| **2.10** | Application Hardening | 1 — Secure Your Environment |
| **3.1** | Physical Security | 1 — Secure Your Environment |
| **4.1** | Password Policy | 2 — Know and Limit Access |
| **4.2** | Multi-Factor Authentication | 2 — Know and Limit Access |
| **5.1** | Logical Access Controls | 2 — Know and Limit Access |
| **5.2** | Token Management | 2 — Know and Limit Access |
| **5.4** | Physical and Logical Password Storage | 2 — Know and Limit Access |
| **6.1** | Malware Protection | 3 — Detect and Respond |
| **6.2** | Software Integrity | 3 — Detect and Respond |
| **6.3** | Database Integrity | 3 — Detect and Respond |
| **6.4** | Log and Monitoring | 3 — Detect and Respond |
| **7.1** | Cyber Incident Response Planning | 3 — Detect and Respond |
| **7.2** | Security Training and Awareness | 3 — Detect and Respond |

The following 8 controls are **advisory** — you may optionally attest these, but they are not required:

1.3A Virtualisation Platform Security, 1.5A Customer Environment Protection, 2.4A Back-Office Data Flow Security, 2.5A External Transmission Data Protection, 2.9A Transaction Business Controls, 2.11A RMA Business Controls, 5.3A Staffing, 6.5A Intrusion Detection, 7.3A Penetration Testing, 7.4A Scenario Risk Assessment

---

## Section 2: What You Need to Prepare — Evidence Checklist by Control

Gather the following evidence before your independent assessor review. Organise evidence by control number.

### Objective 1 — Secure Your Environment

**Control 1.1 — SWIFT Environment Protection**
- Network architecture diagram clearly showing the SWIFT Secure Zone boundary
- Firewall ruleset and change records (deny-by-default rules documented)
- System inventory of all components within the Secure Zone
- Configuration evidence that no server is dual-homed (connected to both SWIFT zone and general corporate network)
- Evidence SWIFT servers are not used for non-SWIFT activities (no email clients, browsers, etc.)

**Control 1.2 — OS Privileged Account Control**
- Privileged account inventory for all SWIFT servers (root/local admin accounts)
- Evidence of MFA for privileged sessions (PAM tool screenshots or authentication logs)
- Privileged account usage policy
- OS audit logs showing privileged account activity and that privileged accounts are not used for routine operations
- Evidence default OS accounts are renamed or disabled

**Control 1.4 — Restriction of Internet Access**
- Firewall rules showing internet access is blocked for all SWIFT Secure Zone IP addresses
- Network flow test results confirming no direct internet path from SWIFT servers
- Evidence jump servers/proxies used for administration are not internet-facing

**Control 2.1 — Internal Data Flow Security**
- Data flow diagram showing all internal SWIFT connections within the Secure Zone
- TLS 1.2+ configuration evidence for each connection carrying SWIFT data
- Certificate inventory with expiry dates

**Control 2.2 — Security Updates**
- Patch management reports showing SWIFT components (OS, middleware, Alliance Access/Gateway)
- Evidence of SWIFT advisory subscription and action log
- Documentation showing critical patches applied within 3 calendar days, high within 90 days
- Exception register with risk acceptance and compensating controls for any overdue patches

**Control 2.3 — System Hardening**
- Hardening baseline document per system type (CIS Benchmark or equivalent)
- Configuration scan results vs. baseline (CIS-CAT output or equivalent)
- Evidence unnecessary services are disabled (e.g., netstat/ss output)

**Control 2.6 — Operator Session Confidentiality and Integrity**
- TLS configuration for Alliance Access/Gateway web interface
- Session timeout configuration (maximum 30 minutes inactivity)
- Evidence clipboard, screen-share, and remote control tools are restricted on SWIFT workstations

**Control 2.7 — Vulnerability Scanning**
- Credentialed vulnerability scan reports for all in-scope SWIFT systems for the last 4 quarters
- Scanner configuration or credential records proving scans are authenticated
- Remediation tracking for identified vulnerabilities

**Control 2.8 — Critical Activity Outsourcing**
- Contracts with any outsourced providers (managed SOC, cloud services) including SWIFT security obligations
- Provider KYC-SA attestations or equivalent audit reports (reviewed annually)
- Annual vendor review records

**Control 2.10 — Application Hardening**
- Completed SWIFT Alliance Access/Alliance Gateway Security Hardening Guide checklist
- Application configuration screenshots showing disabled unused modules and interfaces
- Application account audit report confirming least-privilege configuration and no default passwords

**Control 3.1 — Physical Security**
- Physical access control system logs for the data centre/SWIFT server room
- Authorised access list with documented approvals
- Evidence of electronic access logging (badge reader, CCTV)
- Visitor access records and escorted access policy

### Objective 2 — Know and Limit Access

**Control 4.1 — Password Policy**
- Password policy document
- Group Policy or Active Directory configuration screenshots confirming: 14+ character minimum, complexity, 90-day max age for privileged accounts, 180-day for standard, 12-generation no-reuse, 5-attempt lockout
- No shared or generic accounts evidence

**Control 4.2 — Multi-Factor Authentication**
- MFA configuration evidence for each SWIFT interface (Alliance Access, Alliance Gateway, SWIFT GUI)
- Hardware token inventory showing tokens assigned to every SWIFT operator
- Authentication logs confirming MFA is enforced for all interactive sessions and remote administrative access
- Exemption register if any accounts are excluded (must have documented approval)
- Note: Software-based OTP authenticator apps do NOT satisfy this requirement for A1 architecture — hardware OTP tokens, smart cards with PIN, or FIDO2 hardware keys are required

**Control 5.1 — Logical Access Controls**
- User access list with roles and approval evidence (individual named accounts, no shared accounts)
- Access review records for the last four quarters
- Evidence of dual-authorisation for high-risk operations (e.g., creating new BIC connections)
- Leaver process records showing access removed within 24 hours of departure

**Control 5.2 — Token Management**
- Token inventory register (all hardware tokens, assigned to named operators)
- Token issuance and return records
- Lost/stolen token incident records (if any), showing deactivation within 1 hour
- Annual token inventory reconciliation evidence

**Control 5.4 — Physical and Logical Password Storage**
- Password manager or PAM vault evidence showing SWIFT credentials are stored securely
- No plaintext passwords in files, spreadsheets, or unencrypted documents (evidence of search/audit)
- Break-glass/emergency credential procedure and access log
- Evidence default credentials were changed on installation and after maintenance

### Objective 3 — Detect and Respond

**Control 6.1 — Malware Protection**
- Anti-malware deployment scope screenshots (all SWIFT servers and operator workstations)
- Definition update log confirming daily automated updates (last 30 days)
- Alert configuration showing detections are sent to the security team within 1 hour
- Scheduled full scan history reports

**Control 6.2 — Software Integrity**
- Hash verification records for SWIFT software installations and updates
- FIM (File Integrity Monitoring) configuration covering SWIFT binary directories (if deployed)
- Integrity check procedure document

**Control 6.3 — Database Integrity**
- Database access control configuration (restricted to authorised SWIFT application service accounts)
- Database audit log samples
- Backup and restoration test records

**Control 6.4 — Log and Monitoring**
- SIEM configuration showing SWIFT log sources ingested (Alliance Access/Gateway application logs, OS security logs, authentication logs, network device logs for SWIFT zone, database audit logs)
- Log retention policy and technical evidence (1 year online/hot; 3 years total)
- Sample alert rules for SWIFT anomalies (failed authentications, after-hours logins, large/unusual transactions, privilege escalation, config changes)
- Log review records for the last 30 days (daily review evidence for transaction anomalies and authentication failures)

**Control 7.1 — Cyber Incident Response Planning**
- SWIFT-specific Incident Response Plan document (dated, approved by senior management)
- IRP content must include: detection triggers, triage, containment, SWIFT notification (24-hour obligation), investigation, recovery, lessons learned
- Last annual test record (tabletop exercise or live drill report)
- SWIFT notification contact list (security@swift.com and SWIFT relationship manager)

**Control 7.2 — Security Training and Awareness**
- Training completion records for all staff with SWIFT access (last 12 months)
- Training content overview showing SWIFT-specific topics: phishing, social engineering, SWIFT fraud scenarios, incident reporting
- Role-specific training materials for SWIFT operators

---

## Section 3: Who Can Act as Your Independent Assessor

Since CSCF v2020, an **independent assessment is required for all SWIFT users** — self-attestation is no longer permitted.

### Eligible Assessors

The following parties are eligible to serve as your independent assessor:

1. **Internal Audit Team** — Your own internal audit function can serve as the assessor, provided:
   - The internal audit team is sufficiently independent from the SWIFT operations team
   - Auditors conducting the assessment have no operational responsibility for the SWIFT environment
   - The team has appropriate SWIFT CSP assessment competency

2. **External Audit Firm** — An external audit or consulting firm with demonstrated SWIFT CSP assessment competency. They must be independent of your SWIFT operations.

3. **SWIFT-Certified Assessors** — Assessors listed on SWIFT's KYC Registry who are specifically certified for SWIFT CSP assessments.

### Key Independence Requirement

The assessor must have **no operational responsibility** for the SWIFT environment being assessed. For example, a team member who manages your Alliance Access/Gateway system cannot serve as their own assessor.

### Assessment Standard

As an A1 bank subject to the standard community programme, you will undergo a **Community Standard Assessment (CSA)**. Your assessment covers:
- All 23 mandatory controls applicable to your A1 architecture
- Advisory controls are optionally included (recommended to demonstrate maturity)

### Practical Recommendation

Engage your assessor now (late April) to allow sufficient time to:
- Conduct the assessment
- Identify and close any gaps
- Finalise the assessment report
- Complete and submit the KYC-SA form by July 31

---

## Section 4: How to Complete the KYC-SA Form

### Step-by-Step KYC-SA Completion Process

**Step 1: Access the KYC-SA Portal**
- Log in to swift.com/myswift
- Navigate to the KYC Security Attestation (KYC-SA) section
- Confirm you are completing attestation for the correct SWIFT BIC and architecture type (A1)

**Step 2: Confirm Your Architecture Type**
- Select A1 as your architecture type
- The portal will present the applicable mandatory controls for A1 — all 23 mandatory controls

**Step 3: Complete the Assessment Status for Each Mandatory Control**
For each of the 23 mandatory controls, you must select one of three statuses:

| Status | When to Use |
|--------|-------------|
| **Implemented** | The control is fully implemented in line with CSCF requirements; evidence is available |
| **Partially Implemented** | The control is partially implemented; some requirements are met but gaps exist |
| **Not Implemented** | The control has not been implemented |

Do not inflate your attestation. Counterparties and SWIFT can query your responses, and regulators may review attestations. Honest partial or non-implementation responses are preferable to false "implemented" claims.

**Step 4: Attest Advisory Controls (Optional)**
You may also attest advisory controls (1.3A, 1.5A, 2.4A, 2.5A, 2.9A, 2.11A, 5.3A, 6.5A, 7.3A, 7.4A). Attesting advisory controls as implemented signals security maturity to counterparties.

**Step 5: Provide Assessor Information**
- Enter details of the independent assessor who conducted the assessment
- Confirm the assessment type (Community Standard Assessment)
- Include the assessment date

**Step 6: Senior Management Sign-Off**
- The attestation must be approved by a senior officer of the institution (typically the CISO or equivalent)
- This constitutes a formal declaration that the information provided is accurate

**Step 7: Submit Before July 31**
- Submit by July 31 to meet the annual deadline
- The portal will confirm submission and provide a submission reference

---

## Section 5: High-Priority Controls to Check Before Submission

The following controls are most commonly cited in assessments and should receive extra scrutiny before you attest:

| Control | Common Problem | What to Verify |
|---------|---------------|----------------|
| **4.2 MFA** | Software OTP apps used instead of hardware tokens | Confirm hardware tokens (or FIDO2/smart cards) are deployed for every SWIFT operator; no exceptions |
| **1.1 SWIFT Environment Protection** | Servers on shared segments; no documented Secure Zone | Confirm dedicated VLAN/segment, firewall rules in place, no dual-homed systems, up-to-date network diagram |
| **6.4 Log and Monitoring** | SIEM not ingesting SWIFT-specific sources; retention under 1 year | Confirm Alliance Access/Gateway logs are in SIEM; confirm 1-year online + 3-year total retention |
| **2.2 Security Updates** | Critical patches >3 days overdue; no documented exceptions | Confirm patch SLAs met: critical = 3 days, high = 90 days; exceptions documented with risk acceptance |
| **5.1 Logical Access Controls** | Shared operator accounts | Confirm every SWIFT operator has an individual named account; stale accounts removed |
| **2.7 Vulnerability Scanning** | Scans not credentialed; SWIFT components not in scope | Confirm quarterly credentialed scans include all SWIFT system IPs/hostnames |
| **7.1 Incident Response Planning** | No SWIFT-specific IRP; SWIFT notification obligation not documented | Confirm IRP covers 24-hour SWIFT notification, fraud scenarios, annual test completed |
| **3.1 Physical Security** | Server room access not logged | Confirm electronic badge access with audit trail restricted to named individuals |

---

## Section 6: What Happens After Submission

### Immediate Visibility
- Once submitted, your attestation is **immediately visible** to your counterparties via the KYC-SA portal
- Counterparties can view your compliance status for each control when assessing correspondent banking or settlement relationships

### Counterparty Queries
- Counterparties may contact you directly to request clarification or additional details about specific controls
- You should be prepared to share supporting evidence or explain any partially-implemented or not-implemented controls and your remediation timeline

### Consequences of Non-Attestation
- If you fail to submit by July 31, SWIFT will **flag your institution to counterparties** as non-attesting
- This can trigger counterparty due diligence escalations, suspension of correspondent relationships, or regulatory escalation
- In some jurisdictions (EU, UK, Singapore, HK, Australia), regulators explicitly reference SWIFT CSP compliance in their supervisory expectations

### Consequences of Non-Compliance
- Controls attested as "Partially Implemented" or "Not Implemented" will be visible to counterparties
- Counterparties may restrict payment flows or impose additional conditions
- Potential regulatory escalation by supervisors who monitor SWIFT CSP compliance
- SWIFT itself may notify your regulator in significant non-compliance cases

### Ongoing Obligations
- Maintain your CSCF controls throughout the year — attestation is a point-in-time declaration but controls must be continuously operative
- Monitor SWIFT for CSCF v2025 or any updated guidance (CSCF v2025 effective July 2025; ensure you are attesting against the correct version)
- If a cyber incident occurs after submission: notify SWIFT within 24 hours of confirmation (security@swift.com), submit a full incident report within 30 days

---

## Section 7: Recommended Timeline for A1 Bank Targeting July 31 Deadline

| Target Date | Activity |
|-------------|----------|
| **Now (April 25)** | Assign internal project owner; confirm architecture type A1; compile initial evidence inventory |
| **By May 9** | Complete evidence collection for all 23 mandatory controls; identify gaps |
| **By May 16** | Engage independent assessor; conduct gap walkthrough |
| **May 16 – June 13** | Independent assessor conducts formal review of all 23 mandatory controls |
| **By June 20** | Receive preliminary assessor findings; close any critical gaps (especially 4.2, 1.1, 6.4) |
| **By June 30** | Final assessment report issued by independent assessor |
| **By July 15** | Complete KYC-SA form in portal; senior management review |
| **By July 25** | Senior management sign-off and submission (6 days buffer before deadline) |
| **July 31** | HARD DEADLINE — KYC-SA submitted |

---

## Section 8: Critical Compliance Note on CSCF v2025 Changes

If you are attesting under CSCF v2025 (effective July 2025), be aware of these tightened requirements vs. v2024:

- **Control 2.2 Patching SLA:** Critical patches must now be applied within **3 calendar days** (previously 7 days). Verify your patch management SLAs are updated.
- **Control 4.2 MFA:** Hardware tokens are **explicitly required** for A1 architecture; the previous language "strongly recommended" has been replaced with a definitive requirement. App-based OTP is clearly insufficient.
- **Control 6.4 Log retention:** Clarified as 1 year online/hot and 3 years total (online + archived). Confirm both retention tiers are in place.

---

## Summary

As an A1 architecture bank, your KYC-SA attestation involves:

1. **Preparing evidence** for all 23 mandatory CSCF v2025 controls — starting with the highest-risk areas (4.2, 1.1, 6.4, 2.2)
2. **Engaging an independent assessor** — internal audit (if independent from SWIFT ops) or an external firm/SWIFT-certified assessor — who completes a Community Standard Assessment
3. **Completing the KYC-SA form** at swift.com/myswift, attesting Implemented/Partially Implemented/Not Implemented for each mandatory control, with senior management sign-off
4. **Submitting by July 31** — counterparties see your attestation immediately upon submission; non-submission triggers counterparty flagging

With ~97 days remaining as of today, there is sufficient time to complete this properly if evidence collection and assessor engagement begin immediately.

# KYC-SA Annual Attestation Process — A1 Architecture Bank

## Overview

As an A1 architecture bank (a bank that manages its own SWIFT infrastructure on-premises), you are required to submit a KYC-SA (Know Your Customer - Security Attestation) attestation annually through the SWIFT Customer Security Programme (CSP). The attestation confirms your compliance with the Customer Security Controls Framework (CSCF). With your July 31 deadline, here is a complete walkthrough of the process.

---

## 1. What You Need to Prepare

### Understanding Your Scope (A1 Architecture)

As an A1 architecture type, your SWIFT footprint includes:
- SWIFT messaging interface software (e.g., Alliance Gateway, Alliance Access, or equivalent)
- Local SWIFT infrastructure including HSMs, operator PCs, and messaging servers
- The secure zone protecting these components
- Any jump servers or management systems in the SWIFT secure zone

All mandatory and advisory CSCF controls applicable to A1 environments must be addressed.

### Pre-Attestation Documentation

Prepare the following before beginning the KYC-SA submission:

**Policies and Procedures:**
- Information security policy covering SWIFT-related assets
- Access control policy and procedures
- Change management policy
- Incident response plan (specifically mentioning SWIFT)
- Privileged access management procedures
- Password management policy

**Technical Evidence:**
- Network diagrams showing the SWIFT secure zone and isolation controls
- Firewall rules and configurations restricting access to SWIFT components
- Asset inventory of all components within the SWIFT secure zone
- Vulnerability scan results (recent, within the last 12 months)
- Penetration test results (if applicable, within the required timeframe)
- Anti-malware solution configuration and update logs
- System hardening documentation for SWIFT servers and operator workstations
- Multi-factor authentication (MFA) configuration evidence
- User access review records
- Software version records confirming supported/patched SWIFT components
- Patch management logs

**Operational Evidence:**
- Evidence of completed staff security awareness training
- Privileged account review and recertification records
- Logs showing segregation of duties in SWIFT operations
- Third-party risk assessments for any service providers with SWIFT access

### CSCF Control Mapping

Compile a control-by-control mapping that documents for each CSCF mandatory control:
- Whether it is implemented (Compliant / Non-Compliant)
- Evidence reference
- Any compensating controls for gaps (with rationale)

For CSCF v2025 (applicable for the July 31, 2026 attestation cycle), ensure you are using the current version of the framework and have addressed any newly mandatory controls that may have transitioned from advisory.

---

## 2. Who Can Act as Independent Assessor

### Mandatory Independent Assessment for A1

As an A1 architecture entity, SWIFT requires an **independent assessment** — you cannot self-attest without third-party validation for mandatory controls. Your assessor must be:

### Option A: SWIFT-Listed CSP Assessor (Preferred / Most Common)

SWIFT maintains a list of approved Community Standard Assessment (CSA) providers on swift.com. These are:
- External cybersecurity or audit firms vetted and listed by SWIFT
- Must hold a specific CSP assessor designation from SWIFT
- Examples of firm types include Big Four accounting firms, major cybersecurity consultancies (e.g., firms with ISO 27001 audit capability), and specialist financial sector security firms

**Requirements for a SWIFT-listed assessor:**
- Must be independent from your organization (cannot be an internal team or a firm with conflicting business interests)
- Must have completed SWIFT's CSP assessor training/certification
- Must use SWIFT's standardized assessment methodology

### Option B: Internal Audit (with Conditions)

Some architectures permit internal audit to perform the assessment under specific conditions:
- The internal audit function must be genuinely independent from the IT/operations teams responsible for SWIFT
- The internal audit team must demonstrate competency in cybersecurity assessments
- However, for A1 architecture, SWIFT's current guidance strongly recommends or requires an external independent assessor — verify the exact requirement in the current CSCF documentation, as SWIFT has progressively tightened this requirement

### Assessor Independence Criteria

Regardless of assessor type, the assessor must:
- Have no conflict of interest with the systems being assessed
- Not be the same team that designed or implemented the SWIFT controls
- Be able to objectively challenge and verify evidence
- Issue a formal assessment report with findings and conclusions

### Engaging Your Assessor

- Engage the assessor well before July 31 — assessments typically take 4–8 weeks depending on complexity
- Provide the assessor with your scope documentation, architecture diagrams, and pre-prepared evidence package
- Agree on the assessment methodology upfront (document review, interviews, technical testing)
- Obtain a formal assessment report confirming the scope, methodology, findings, and overall conclusion

---

## 3. How to Complete the KYC-SA Form

### Accessing the KYC-SA Portal

1. Log in to **SWIFT's KYC Registry** via swift.com using your SWIFT credentials
2. Navigate to the **KYC-SA section** within the KYC Registry portal
3. Ensure you have the appropriate role/permissions — typically a "KYC-SA Administrator" or equivalent role is required

### Completing the Attestation Form

The KYC-SA form is structured around the CSCF controls. For each control:

**Step 1: Select Compliance Status**
- **Compliant** — the control is fully implemented
- **Not Compliant** — the control is not implemented or partially implemented
- **Not Applicable** (only for advisory controls where applicability criteria are met)

**Step 2: Provide Implementation Details**
- For each control, you enter a brief description of how the control is implemented
- Reference your evidence and procedures without uploading raw documents (the form captures attestation, not the underlying evidence, though you must retain evidence)

**Step 3: Assessor Information**
- Enter details of your independent assessor:
  - Assessor name / firm name
  - Assessor type (external firm vs. internal audit)
  - Assessment date
  - Whether the assessor is a SWIFT-listed CSP assessor

**Step 4: Review Architecture Type**
- Confirm your architecture type is correctly set to A1
- The system will display only the controls applicable to your architecture

**Step 5: Mandatory vs. Advisory Controls**
- Mandatory controls: must be marked Compliant or Non-Compliant (non-compliant results will be visible to your counterparties)
- Advisory controls: best practice; non-compliance does not trigger the same visibility consequences but reflects maturity

**Step 6: Submit the Attestation**
- Review all entries for completeness and accuracy
- Have the appropriate authorized signatory within your organization review and approve
- Click **Submit** — the attestation is timestamped and recorded

### Key Form Deadlines

- SWIFT's annual attestation deadline is typically **December 31** of each year, but your organization has set an internal target of July 31 — this is a best practice approach giving a comfortable buffer
- Attestations submitted after the SWIFT deadline may result in your entity being flagged as non-attested in the KYC Registry, which counterparties can see

---

## 4. What Happens After Submission

### Visibility in the KYC Registry

Once submitted, your attestation becomes visible in the **SWIFT KYC Registry**:
- **Counterparties** (other SWIFT members you correspond with) can view your attestation status
- They will see:
  - Whether you have attested (attested / not attested)
  - Your overall compliance level (fully compliant / partially compliant)
  - The date of your last attestation
  - Compliance status for each mandatory control (compliant or non-compliant)
- Counterparties use this information in their own correspondent banking due diligence and risk management decisions

### Non-Compliance Handling

If you have reported non-compliant mandatory controls:
- Counterparties can see this and may raise concerns or restrict your relationship
- SWIFT may reach out for clarification or a remediation plan
- You should have a documented remediation plan with target dates for any non-compliant controls
- You can update your attestation during the year if you achieve compliance on a previously non-compliant control

### SWIFT Oversight and Verification

- SWIFT does not automatically audit every attestation but operates a **spot-check and oversight program**
- SWIFT or its designated parties may request supporting evidence for your attestation claims
- Misrepresentation of compliance status is a serious violation of SWIFT's policies and can result in sanctions, including suspension from the SWIFT network

### Retention Requirements

- Retain all underlying evidence and assessment documentation for a minimum of **5 years** (or longer if required by local regulation)
- This includes assessor reports, evidence packages, and all correspondence related to the assessment
- Store evidence securely and ensure it can be produced promptly if SWIFT requests verification

### Annual Renewal

- The attestation covers a 12-month period
- You must repeat the full process annually
- SWIFT publishes the updated CSCF for the next cycle, typically mid-year, so begin reviewing the updated framework shortly after submitting this year's attestation
- Track any new mandatory controls transitioning from advisory status for the next cycle

---

## Summary Timeline for July 31 Target

| Milestone | Recommended Date |
|---|---|
| Review CSCF v2025 controls applicable to A1 | Now — April/May |
| Complete internal evidence gathering | May — June |
| Engage independent assessor | April/May (book early) |
| Assessor conducts assessment | May — June |
| Receive assessor report | June — early July |
| Complete KYC-SA form in portal | July 1–25 |
| Internal authorization and review | July 25–28 |
| Submit attestation | By July 31 |
| Retain all documentation | Ongoing (5+ years) |

---

## Important Notes

- Always use the **current CSCF version** published by SWIFT for the applicable attestation year — using an outdated version is a common error
- Ensure your SWIFT software versions are **within supported release** — running an unsupported version is typically an automatic mandatory control failure
- Check that your **HSM firmware** and **operator PC OS** versions are supported and patched
- Review SWIFT's **Security Bulletins** for any late-breaking requirements that may affect your attestation
- If you have subsidiaries or affiliates also using SWIFT under your BIC, confirm whether they require separate attestations

---

*This guidance is based on the SWIFT Customer Security Programme (CSP) and Customer Security Controls Framework (CSCF) as generally understood. Always refer to the official SWIFT documentation and the current CSCF version published on swift.com for authoritative requirements applicable to your specific attestation cycle.*

# SWIFT CSP Control 7.1 — Cyber Incident Response: Malware on SWIFT-Connected Server

**Scenario:** Malware discovered on a SWIFT-connected server; fraudulent transactions suspected.
**Framework:** SWIFT Customer Security Controls Framework (CSCF) v2025
**Primary Control:** 7.1 — Cyber Incident Response Planning (Mandatory — all architecture types)
**Related Controls:** 6.1 (Malware Protection), 6.4 (Log and Monitoring), 6.2 (Software Integrity), 5.1 (Logical Access Controls)

---

## Part 1: Immediate Incident Response Obligations Under Control 7.1

### Step 1 — Declare a Cyber Incident Immediately (T+0)

The moment malware is confirmed on a SWIFT-connected server, this constitutes a **notifiable cyber incident** under CSCF v2025 Control 7.1. SWIFT explicitly defines the following as qualifying incidents requiring notification:

- Malware found on SWIFT-connected systems
- Fraudulent or anomalous SWIFT transactions suspected to be cyber-related
- Unauthorised access to SWIFT systems or software
- Compromise of SWIFT credentials (operator tokens or passwords)

Both conditions in this scenario — malware presence and suspected fraudulent transactions — independently trigger mandatory incident response obligations. Do not wait for forensic confirmation before beginning notifications.

**Action at T+0:**
- Activate the SWIFT-specific Incident Response Plan (IRP)
- Convene the incident response team (security, IT operations, compliance, legal, senior management)
- Escalate immediately to senior management — this is a mandatory internal escalation per SWIFT requirements
- Begin a formal incident log capturing all actions, timestamps, and findings

---

### Step 2 — Internal Containment (T+0 to T+2 hours)

Before notifications go external, execute immediate containment to prevent further damage:

1. **Isolate the affected server** — Remove the compromised SWIFT-connected server from the SWIFT Secure Zone network immediately. Disconnect from the corporate network and any back-office interfaces. Do not power off the system — this destroys volatile memory evidence (see Evidence Preservation, below).
2. **Suspend SWIFT operator sessions** — Force-terminate all active operator sessions on the compromised system. Revoke or suspend any SWIFT operator tokens associated with the affected server (Control 5.2).
3. **Block outbound SWIFT transactions from the compromised host** — If the server initiates SWIFT messages (e.g., Alliance Access), disable or redirect the messaging queue at the gateway level to prevent further fraudulent message transmission.
4. **Preserve existing transaction queues** — Do not delete or flush pending transaction queues; capture a snapshot for forensic review before any queue management action.
5. **Alert the SIEM / security monitoring team** — Confirm that Control 6.4 log sources for the affected server are being actively collected and that no log rotation is occurring that could destroy evidence.

---

### Step 3 — SWIFT Notification (Within 24 Hours of Confirmed Incident)

**SWIFT requires initial notification within 24 hours of confirming a cyber incident affecting SWIFT infrastructure or transactions.** This is a hard deadline under CSCF v2025 Control 7.1 — it is not discretionary.

| Notification | Channel | Deadline |
|---|---|---|
| SWIFT CISO Office | security@swift.com | Within 24 hours of confirmed incident |
| SWIFT Relationship Manager | Your named SWIFT relationship manager | Within 24 hours of confirmed incident |
| KYC-SA Portal (if incident affects attestation) | SWIFT KYC-SA portal at swift.com/myswift | As applicable; coordinate with your attestation submission |
| Internal senior management | Direct escalation — verbal + written | Immediately upon detection (T+0) |
| Law enforcement | Per local jurisdiction (see below) | Per regulatory requirements |
| Prudential regulator / central bank | Per local jurisdiction (see below) | Per regulatory requirements |

**What to include in the initial 24-hour SWIFT notification:**

- Your BIC (Bank Identifier Code) / SWIFT user identifier
- Date and time the incident was detected
- Nature of the incident (malware on SWIFT-connected server; suspected fraudulent transactions)
- Systems and infrastructure components affected (which server, which SWIFT components — e.g., Alliance Access, Alliance Gateway)
- Whether fraudulent SWIFT messages are confirmed or only suspected, and if known, the approximate transaction amounts and counterparties
- Immediate containment steps taken
- Contact details of your incident response lead and CISO

Do not wait for full forensic investigation before sending the initial notification. If facts change, update SWIFT in subsequent communications.

---

### Step 4 — Regulatory and Law Enforcement Notification (Jurisdiction-Dependent)

In addition to notifying SWIFT, your organisation has regulatory obligations that vary by jurisdiction. These run in parallel to the SWIFT notification — they are not sequential:

| Jurisdiction | Regulator / Authority | Typical Obligation |
|---|---|---|
| EU | National Competent Authority (NCA) under DORA; ECB for significant institutions | DORA requires initial notification within 4 hours of major incident classification; full report within 1 month |
| UK | Bank of England / PRA; FCA | PRA/FCA Operational Resilience framework; notify within 24 hours for material incidents |
| US | FinCEN (if fraud confirmed); OCC/Federal Reserve (for regulated banks); FBI Cyber Division | File Suspicious Activity Report (SAR) within 30 days of fraud detection; notify primary regulator per FFIEC guidance |
| Singapore | MAS | MAS TRM Guidelines: notify within 1 hour of discovery for material incidents |
| Hong Kong | HKMA | HKMA Cybersecurity Fortification Initiative: notify promptly; within 1 hour for critical incidents |
| Australia | APRA | CPS 234: notify APRA within 72 hours of becoming aware of a material cyber security incident |

**Law enforcement:** Report to national law enforcement cyber units (e.g., FBI Cyber Division in the US, Action Fraud / NCSC in the UK, BKA in Germany) at the same time or immediately after regulatory notification. For suspected fraud involving wire transfers, also notify the receiving correspondent banks to initiate potential recall.

---

### Step 5 — Transaction Recall and Counterparty Notifications (T+2 to T+24 hours)

If fraudulent SWIFT messages were transmitted:

1. **Identify all suspect transactions** — Review Alliance Access / Alliance Gateway message logs for all messages transmitted from the compromised server in the period the malware was likely active. Use Control 6.4 SIEM logs to reconstruct the timeline.
2. **Send SWIFT payment cancellation / recall requests** — Use SWIFT's standard gpi (Global Payments Innovation) recall mechanism where applicable. For MT messages, send MT n92 recall requests to receiving correspondent banks immediately.
3. **Contact receiving banks directly** — Telephone and written notification to correspondent banking partners requesting recall; do not rely solely on SWIFT gpi messaging.
4. **Contact your nostro/correspondent accounts** — Alert all banks that hold accounts on your behalf to monitor for suspicious activity.
5. **Engage your cyber insurance carrier** — Notify cyber insurance as required by policy; most policies have strict notification windows (typically 24–72 hours).

---

### Step 6 — Full Incident Report to SWIFT (Within 30 Days)

Following the initial 24-hour notification, a **full incident report must be submitted to SWIFT within 30 days**. This report must document:

- Complete timeline from initial compromise to containment and recovery
- Root cause analysis findings
- All systems affected and scope of SWIFT infrastructure compromise
- List of all SWIFT transactions that were fraudulent or suspected fraudulent (BIC, amount, date, counterparty)
- Evidence of remediation steps taken
- Improvements made or planned to controls (particularly 6.1 Malware Protection, 6.4 Log and Monitoring, 7.1 IRP)
- Updated KYC-SA attestation status (if the incident impacts a mandatory control)

---

## Part 2: Evidence Preservation Requirements

Proper evidence preservation is both a legal requirement and a CSCF v2025 Control 7.1 obligation. Your SWIFT-specific IRP must define these procedures.

### Do Not Power Off the Compromised Server

Powering off destroys volatile memory (RAM) which may contain malware artifacts, encryption keys, active network connections, and running processes. Instead:

1. **Capture volatile memory (RAM image)** immediately using forensic tools (e.g., Magnet RAM Capture, WinPmem, LiME for Linux). This is the single most time-sensitive evidence preservation step.
2. **Capture running process list and network connections** — Document all active processes, open file handles, and network connections before any changes (use tools such as `ps`, `netstat`, `lsof`, or equivalent).
3. **Capture network traffic** — If network monitoring is in place, preserve packet captures for the SWIFT Secure Zone for the relevant period.

### Disk and System Evidence

4. **Create forensic disk images** of the compromised server (bit-for-bit copy using tools such as FTK Imager or dd with write-blockers) before any remediation activity alters the disk.
5. **Preserve all log files** — Extract and archive:
   - Alliance Access / Alliance Gateway application logs
   - Operating system security logs (Windows Event Logs or Linux auditd/syslog)
   - Authentication logs (MFA, Active Directory, PAM logs)
   - Database audit logs (Control 6.3)
   - Network device logs covering the SWIFT Secure Zone (firewall, switch logs)
   - Anti-malware detection logs (Control 6.1)
   - File Integrity Monitoring (FIM) logs if deployed (Control 6.2)
6. **Preserve SIEM data** — Ensure the SIEM retains all relevant log data and that log rotation is suspended for the affected sources during the investigation period. CSCF v2025 requires 1-year online retention and 3-year total retention (Control 6.4) — confirm these are intact and not at risk.

### SWIFT Transaction Evidence

7. **Export SWIFT message archives** — Capture all SWIFT messages transmitted and received in the relevant period (from the start of the suspected compromise window to the time of containment) from Alliance Access message stores.
8. **Preserve transaction reconciliation records** — Export back-office transaction records and reconcile against SWIFT message logs to identify any discrepancies or transactions that appear in SWIFT but not in the core banking system (a common indicator of fraudulent injections).
9. **Capture Alliance Access / Gateway configuration** — Take a snapshot of current application configuration (user accounts, roles, permissions, interface settings) to establish the state at time of incident.

### Chain of Custody

10. **Establish chain of custody documentation** for all evidence collected — record who collected it, when, from which system, using what tool, and where it is stored. This is essential for any subsequent legal proceedings or regulatory investigation.
11. **Store evidence in a secure, access-controlled location** separate from the production environment — ideally on write-once media or in an immutable evidence repository.
12. **Engage qualified forensic investigators** — For SWIFT incidents involving suspected fraud, engage a qualified digital forensics firm to supplement internal capabilities. Many regulators and SWIFT itself will expect professional forensic involvement.

---

## Part 3: SWIFT-Specific Incident Response Plan (IRP) — Required Content for CSCF v2025 Compliance

Control 7.1 requires a documented, tested SWIFT-specific IRP. A generic enterprise incident response plan is insufficient. The following content is mandatory for compliance.

### 1. Scope and Purpose

- Explicit statement that the IRP covers the SWIFT Secure Zone and all SWIFT-connected systems
- Reference to the CSCF v2025 Control 7.1 compliance requirement
- Identification of which SWIFT architecture type (A1/A2/A3/A4/B) the plan covers
- List of in-scope SWIFT components (Alliance Access, Alliance Gateway, HSMs, operator workstations, back-office interfaces)

### 2. Incident Classification for SWIFT Scenarios

The IRP must define which events constitute a SWIFT cyber incident requiring activation. At minimum, include:

| Incident Type | Trigger |
|---|---|
| Malware on SWIFT-connected system | Anti-malware alert from any in-scope SWIFT system |
| Suspected fraudulent SWIFT transaction | Anomalous transaction alert; back-office reconciliation discrepancy; counterparty notification |
| Compromise of SWIFT operator credentials | Suspicious authentication event; lost/stolen hardware token; phishing report from SWIFT user |
| Unauthorised change to SWIFT configuration | FIM alert; database change alert; unauthorized account creation in Alliance Access |
| Ransomware or destructive malware in SWIFT zone | Encryption of SWIFT server files; loss of Alliance Access availability |
| SWIFT software integrity failure | Hash verification failure (Control 6.2); unexpected change to SWIFT binaries |
| Physical security breach of SWIFT server room | Forced entry; tailgating; stolen hardware |

### 3. Roles and Responsibilities

Define named roles (not just job titles — name the individuals where possible):

- **Incident Commander** — Accountable for overall incident management; typically CISO or Head of IT Security
- **SWIFT Operations Lead** — Technical lead for SWIFT-specific containment and recovery
- **Legal Counsel** — Advises on regulatory notification obligations and law enforcement engagement
- **Compliance Officer** — Coordinates KYC-SA attestation updates; manages SWIFT relationship notifications
- **Communications Lead** — Manages external communications (regulators, counterparties, press)
- **Forensics Lead** — Internal or external forensic investigator
- **Executive Sponsor** — C-suite escalation (CEO/CFO for material fraud events)

### 4. SWIFT-Specific Notification Procedures

This section must be explicit and actionable — it is the most commonly missing element in non-compliant IRPs:

- **24-hour SWIFT notification procedure** — Step-by-step instructions for contacting security@swift.com and the SWIFT relationship manager, including what information to include (see Part 1, Step 3 above)
- **Contact list** — Current email addresses, phone numbers, and out-of-hours contacts for: SWIFT CISO office, your SWIFT relationship manager, your SWIFT service bureau (if Type B), and your primary regulatory supervisor
- **30-day full report procedure** — Template or outline for the comprehensive incident report to SWIFT
- **KYC-SA portal update procedure** — Process for updating your attestation if the incident reveals a compliance gap in a mandatory control
- **Internal escalation matrix** — Who notifies whom at what severity level; escalation to board level for major fraud events

### 5. Detection Triggers and Initial Triage

- List of monitoring sources that generate SWIFT incident alerts (SIEM rules, anti-malware, FIM, IDS if deployed under Control 6.5A)
- Initial triage checklist — questions to determine severity and scope within the first 30 minutes:
  - Which SWIFT components are affected?
  - Is the malware still active or has it been contained?
  - Have any SWIFT transactions been sent since the estimated compromise time?
  - Are operator credentials or hardware tokens potentially compromised?
  - Is the SWIFT Secure Zone boundary intact or has the malware spread?

### 6. Containment Procedures

SWIFT-specific containment steps (beyond generic IR containment):

- Procedure for isolating SWIFT Secure Zone components without disrupting critical financial operations
- Steps to suspend SWIFT messaging throughput (disabling message queues in Alliance Access/Gateway)
- Procedure for emergency suspension of SWIFT operator accounts and hardware tokens
- Firewall rule deployment to block SWIFT zone traffic pending investigation
- Coordination with SWIFT (and service bureau if Type B) to pause processing

### 7. Evidence Preservation Requirements

The IRP must explicitly document (aligned with Part 2 above):

- Mandatory volatile memory capture before any system changes
- Forensic disk imaging procedures
- Log extraction and preservation list (all sources per Control 6.4 scope)
- SWIFT transaction archive export procedure
- Chain of custody documentation requirements
- Evidence storage location and access controls

### 8. Investigation and Root Cause Analysis

- Forensic investigation methodology (or reference to external forensic retainer)
- Requirement to determine: initial infection vector, malware family and capabilities, persistence mechanisms, data/credential exfiltration assessment, full scope of SWIFT transactions affected
- Timeline reconstruction approach using SIEM and SWIFT logs

### 9. Recovery Procedures

- Criteria for declaring the SWIFT environment clean and safe to resume operations (e.g., forensic sign-off; fresh OS build; integrity verification per Control 6.2; SWIFT software reinstallation with hash verification)
- Sequence for restoring SWIFT services — do not resume until: affected systems rebuilt from known-good images, all operator credentials reset, hardware tokens reissued where compromised, firewall rules reviewed and tightened
- Post-recovery verification checklist (transaction reconciliation, log review, integrity check)

### 10. Post-Incident Review and Lessons Learned

- Mandatory post-incident review within 30 days of containment
- Review participants (incident team + senior management)
- Outputs: root cause report, updated IRP (if gaps found), updated KYC-SA attestation, regulatory submissions
- Metrics to capture: time to detect, time to contain, number of fraudulent transactions, financial loss, notification compliance (were 24-hour and 30-day deadlines met?)

### 11. Annual Testing Requirement

CSCF v2025 Control 7.1 requires the IRP to be **tested annually**. The plan must document:

- Annual tabletop exercise — minimum requirement; scenario should include at least one SWIFT-specific attack scenario (e.g., malware on Alliance Access server; compromised SWIFT operator credentials; fraudulent MT103 injection)
- Live drill (recommended every 2 years) — test actual containment procedures without impacting production
- Test record retention — evidence of the annual test must be retained for assessment purposes (test scenario, participants, findings, post-exercise action items)

---

## Part 4: Related Control Obligations Triggered by This Incident

This malware incident triggers compliance review obligations under several controls beyond 7.1:

| Control | Obligation Triggered |
|---|---|
| **6.1 — Malware Protection** | Malware on a SWIFT server indicates a potential Control 6.1 failure. Review: Was anti-malware deployed on the affected server? Were definitions current? Did alerts fire within 1 hour? Update attestation if a gap is found. |
| **6.2 — Software Integrity** | Verify that SWIFT software (Alliance Access/Gateway binaries) has not been tampered with. Run hash verification against SWIFT-published checksums immediately as part of containment. |
| **6.4 — Log and Monitoring** | Confirm all required log sources were active and collected throughout the incident window. Assess whether existing monitoring rules should have detected the malware or anomalous transactions earlier. Review alert configuration. |
| **1.1 — SWIFT Environment Protection** | Assess how malware reached a SWIFT Secure Zone system. Was the zone boundary intact? Were network segmentation controls (firewall rules) effective? If the malware entered from the corporate network, this is a potential Control 1.1 finding. |
| **2.2 — Security Updates** | Was the malware delivered via an unpatched vulnerability? If so, assess patch management compliance. In CSCF v2025, critical patches must be applied within 3 calendar days. |
| **5.1 — Logical Access Controls** | If fraudulent transactions were submitted, review whether they were submitted using a legitimate operator account (potential credential compromise). Audit operator access logs to identify anomalous authentication events. |
| **2.9A — Transaction Business Controls (Advisory)** | If this control is implemented, assess whether transaction value limits or time-of-day restrictions would have detected or blocked the fraudulent transactions. Use this incident to build the case for implementing 2.9A if not yet in place. |

---

## Summary Timeline

| Time | Action |
|---|---|
| T+0 — Detection | Activate SWIFT IRP; escalate to senior management; begin incident log |
| T+0 to T+2 hours | Isolate compromised server; suspend operator sessions and tokens; block outbound SWIFT transactions from affected system; begin evidence preservation (RAM image, process capture) |
| T+2 to T+6 hours | Complete forensic disk imaging; extract and preserve all logs; identify scope of affected SWIFT transactions |
| T+6 to T+24 hours | Submit initial notification to SWIFT (security@swift.com + relationship manager); notify primary regulator per jurisdiction; submit SWIFT transaction recall requests; notify correspondent banks |
| T+24 to T+72 hours | Notify cyber insurance carrier; engage external forensic firm; complete scope assessment; begin root cause analysis |
| T+30 days | Submit full incident report to SWIFT; submit regulatory reports (DORA, FinCEN SAR, etc.); complete internal post-incident review; update KYC-SA attestation if compliance gap identified |

---

## Key Contacts to Maintain in Your IRP (Required by Control 7.1)

- **SWIFT CISO / Security Incidents:** security@swift.com
- **SWIFT Relationship Manager:** [Institution-specific — must be named and number verified annually]
- **SWIFT Customer Support:** swift.com/support or your SWIFT service centre
- **External forensic retainer:** [Institution-specific — retainer contract recommended; do not attempt to source a firm during a live incident]
- **Cyber insurance carrier:** [Institution-specific — policy number and 24-hour notification line]
- **Primary regulator duty officer:** [Institution-specific — verify annually]
- **Law enforcement cyber unit:** [Jurisdiction-specific — e.g., FBI IC3: ic3.gov; UK NCSC: 0800 088 5574]

---

*This guidance is based on SWIFT CSCF v2025 (effective July 2025). Control 7.1 is mandatory for all architecture types (A1, A2, A3, A4, and B). All notification timelines cited are derived from SWIFT's published incident notification obligations. Regulatory notification timelines reflect general requirements and may vary — consult your legal and compliance team for jurisdiction-specific obligations.*

# SWIFT CSP Incident Response: Malware on SWIFT-Connected Server

## Scenario
Malware discovered on a SWIFT-connected server with suspected fraudulent transactions.

---

## 1. Immediate Incident Response Obligations Under SWIFT CSP Control 7.1

### What is Control 7.1?
SWIFT Customer Security Programme (CSP) Control 7.1 — **Cyber Incident Response Planning** — is a mandatory control under the Customer Security Controls Framework (CSCF). It requires that SWIFT users have a formal cyber incident response plan that specifically addresses SWIFT-related incidents and that they execute that plan when incidents occur. In CSCF v2025, this remains a mandatory control.

### Immediate Actions Required

**Within the first hours (containment phase):**

1. **Isolate the compromised system** — Immediately isolate the affected SWIFT-connected server from the SWIFT network (SWIFT Alliance Gateway/Access Point or equivalent) and from your internal network to prevent further propagation or unauthorized transaction submission. Do not power off the system if forensically avoidable — preserve volatile memory (RAM) if possible before isolation.

2. **Suspend SWIFT messaging activity** — Halt outbound SWIFT message transmission from the affected system until the scope of compromise is determined. Coordinate with your SWIFT service bureau or correspondent if applicable.

3. **Activate your Incident Response Plan** — Formally declare a cyber incident and activate the documented SWIFT-specific incident response plan. Assign an Incident Commander and convene the response team.

4. **Preserve evidence** (see Section 3 below).

---

## 2. Who to Notify and By When

### A. SWIFT Itself

**Obligation:** SWIFT users are required under the SWIFT CSP/CSCF to report confirmed or suspected fraud related to SWIFT transactions to SWIFT's dedicated reporting channels. SWIFT operates the **SWIFT ISAC (Information Sharing and Analysis Centre)** and has a dedicated security team.

- **How:** Report via the SWIFT Customer Security Intelligence (CSI) portal or directly through SWIFT's security reporting mechanism. As of CSCF v2025, mandatory reporting of cybersecurity incidents affecting SWIFT infrastructure to SWIFT is explicitly required.
- **When:** As soon as a cyber incident involving the SWIFT environment is confirmed or strongly suspected — typically within **24 hours** of discovery, though SWIFT guidance urges "as soon as possible." Do not wait for a full investigation before notifying SWIFT.
- **What to report:** Nature of the incident, affected systems, any suspicious or fraudulent payment messages (with SWIFT transaction references/URNs if available), and initial indicators of compromise (IOCs).

### B. Your Correspondent Banks and Counterparties

- Notify receiving banks of potentially fraudulent transactions immediately so they can place holds or reverse transactions before settlement where possible. Time is critical — SWIFT payments that have already settled may be very difficult to recover.
- Use SWIFT messaging (from a clean, uncompromised system) or out-of-band telephone/email to alert counterparties.
- **When:** Immediately upon identifying suspect transactions — hours matter for fund recovery.

### C. Your Regulators and National Authorities

- **Central Bank / Banking Regulator:** Most jurisdictions require regulated financial institutions to notify their prudential regulator (e.g., the Federal Reserve, ECB, FCA, MAS, RBI) of significant cybersecurity incidents within prescribed timeframes. Common thresholds are **36–72 hours** depending on jurisdiction, but many require notification "without undue delay."
- **Financial Intelligence Unit (FIU) / AML Authority:** If fraudulent transactions are confirmed, a Suspicious Activity Report (SAR) or equivalent may be required under AML/CFT obligations.
- **Law Enforcement:** Contact national cybercrime authorities (e.g., FBI in the US, NCSC in the UK, BKA in Germany) to support investigation and potential recovery of funds.
- **CERT/ISAC:** Notify your national CERT and relevant financial sector ISAC (e.g., FS-ISAC) to support threat intelligence sharing.

### D. Internal Stakeholders

- Senior management, Board (if material), Legal, Compliance, Communications/PR (for potential disclosure obligations), and Insurance (cyber policy notification requirements typically have tight windows, often 24–72 hours).

### E. Data Protection Authorities (if personal data is involved)

- If the breach involves personal data (e.g., customer account information), GDPR or equivalent regulations may require notification to the supervisory authority within **72 hours** of becoming aware of the breach.

---

## 3. Evidence to Preserve

Preserving forensic evidence is critical both for investigation and for meeting CSCF documentation requirements. Do **not** wipe, reimage, or power off systems before capturing:

### System and Network Evidence
- **Full disk images** of the compromised server(s) using forensically sound tools (e.g., write-blocked bit-for-bit copies)
- **Volatile memory (RAM) dumps** captured before isolation or shutdown — malware often exists only in memory
- **Network traffic captures (PCAP)** from IDS/IPS, firewalls, and network taps covering the period of suspected compromise
- **Firewall and proxy logs** showing inbound/outbound connections from the affected server
- **Authentication logs** (Active Directory, RADIUS, local OS logs) showing logon events, privilege escalation, and lateral movement
- **Endpoint Detection and Response (EDR) logs** and antivirus/antimalware scan results
- **Event logs** (Windows Event Logs, Syslog) from the affected server and surrounding infrastructure

### SWIFT-Specific Evidence
- **SWIFT Alliance logs** — all message logs from the SWIFT messaging interface (Alliance Gateway, Alliance Access, Lite2, or SWIFTNet Link) covering the incident window
- **SWIFT message archives** — copies of all outbound messages sent in the period surrounding the incident, particularly any MT 103 (Single Customer Credit Transfer), MT 202 COV, or other payment messages
- **Operator and supervisor activity logs** within the SWIFT application — who logged in, what messages were created/authorized/sent
- **Four-eyes/dual-authorization logs** — evidence of whether approval controls were bypassed
- **SWIFT Relationship Management Application (RMA)** logs showing authorized counterparties
- **Database audit logs** for the SWIFT back-office database
- **Change management records** — any recent changes to the SWIFT environment (patches, configuration changes, new users)

### Malware Artifacts
- **Malware samples** — preserve the actual malicious files in a quarantined/contained manner for forensic analysis
- **Indicators of Compromise (IOCs)** — hashes, filenames, registry keys, C2 IP addresses, domains
- **Timeline of malware execution** reconstructed from logs

### Chain of Custody
- Maintain a formal chain of custody for all forensic evidence. Document who collected what, when, using what tools, and where evidence is stored. This is essential for law enforcement and potential litigation.

---

## 4. SWIFT-Specific Incident Response Plan Requirements Under CSCF v2025

### Control 7.1 Mandatory Requirements

To be compliant with CSCF v2025, your SWIFT-specific incident response plan must contain the following elements:

#### 4.1 Scope and Purpose
- Explicit coverage of the SWIFT environment (all systems in the mandatory and advisory control scope: operator PCs, SWIFT interface processors, back-office connectors, jump servers, HSMs)
- Clear definition of what constitutes a SWIFT-related incident (malware, unauthorized access, fraudulent payment, credential compromise, etc.)

#### 4.2 Roles and Responsibilities
- Named or role-based Incident Commander with authority to make isolation and notification decisions
- Designated SWIFT Security Officer or equivalent who owns CSP compliance and SWIFT reporting
- Contact list for SWIFT, regulators, correspondent banks, law enforcement, legal counsel, and cyber forensics retainer
- Clear escalation paths and decision authority matrix

#### 4.3 Detection and Initial Assessment
- Procedures for confirming that an incident involves the SWIFT environment
- Initial triage steps to determine if fraudulent transactions were sent
- Criteria for escalating to a "SWIFT fraud incident" (elevated response)

#### 4.4 Containment Procedures
- Specific steps for isolating SWIFT components without destroying evidence
- Procedure to suspend SWIFT message transmission
- Guidance on whether/when to engage SWIFT's support team for technical assistance

#### 4.5 Communication and Notification Procedures
- **SWIFT reporting procedure:** Step-by-step instructions for reporting to SWIFT ISAC/CSI portal, including what information to include and timelines
- **Regulatory notification matrix:** Jurisdiction-specific notification requirements with applicable timeframes
- **Correspondent bank alert procedure:** Template communications for notifying counterparties of potentially fraudulent transactions
- **Internal escalation:** Board/senior management notification thresholds

#### 4.6 Evidence Preservation Procedures
- Forensic evidence collection checklist tailored to the SWIFT environment (as described in Section 3 above)
- Chain of custody procedures
- Guidance on working with external forensics firms

#### 4.7 Eradication and Recovery
- Procedures for removing malware and verifying eradication before reconnecting to SWIFT
- Secure rebuild procedures for compromised SWIFT components
- Validation testing before returning to production (including SWIFT connectivity tests)
- Conditions under which SWIFT messaging may be resumed

#### 4.8 Post-Incident Activities
- Root cause analysis (RCA) process
- Lessons learned documentation
- Update of security controls and the incident response plan based on findings
- Reporting outcomes to SWIFT if required (SWIFT may require post-incident reporting on root cause and remediation)
- Regulatory post-incident reporting (some regulators require follow-up reports)

#### 4.9 Testing and Maintenance
- CSCF v2025 requires that the incident response plan be **tested at least annually** through tabletop exercises, simulations, or drills that specifically include SWIFT fraud/malware scenarios
- The plan must be reviewed and updated at least annually and after any significant incident or change to the SWIFT environment

#### 4.10 Integration with Broader Frameworks
- The SWIFT IR plan should be integrated with (or clearly reference) the organization's broader cyber incident response plan, business continuity plan (BCP), and disaster recovery plan (DRP)
- Alignment with SWIFT's published security guidelines (e.g., SWIFT's "Security Guidance for Customers")

---

## 5. Key Timelines Summary

| Action | Timeline |
|--------|----------|
| Isolate compromised system | Immediately upon discovery |
| Preserve volatile memory/RAM | Before isolation/shutdown |
| Notify SWIFT (CSI/ISAC) | As soon as possible; within 24 hours |
| Alert correspondent banks on suspect transactions | Within hours (fund recovery window) |
| Notify banking regulator | Per jurisdiction; typically 36–72 hours |
| Notify data protection authority (if personal data involved) | Within 72 hours (GDPR and equivalents) |
| Notify cyber insurer | Per policy; typically 24–72 hours |
| File SAR with FIU (if fraud confirmed) | Per jurisdiction AML requirements |
| Complete full forensic evidence collection | Within 24–48 hours where possible |

---

## 6. Important Notes

- **Do not reimage or wipe** the compromised server until forensic imaging is complete — doing so destroys evidence and may create regulatory and legal liability.
- **Do not pay ransom** (if ransomware is involved) without consulting legal counsel and law enforcement.
- **Coordinate fund recovery immediately** — SWIFT fraud recovery depends on speed. The SWIFT Payment Controls Service (if subscribed) may assist in flagging or recalling suspect transactions.
- **SWIFT CSP attestation impact:** A confirmed breach of the SWIFT environment will likely require you to update your CSP attestation and may trigger mandatory re-assessment of your security posture.
- Under CSCF v2025, failure to report a SWIFT-related cybersecurity incident to SWIFT can result in sanctions including notification of your supervisors and counterparties by SWIFT directly.

---

*This response is based on general knowledge of SWIFT CSCF requirements, SWIFT's published security guidance, and standard incident response practices as of CSCF v2025. Always verify against the current SWIFT CSCF documentation and applicable regulatory requirements in your jurisdiction.*

ISM Guidance: Cloud-Hosted Case Management System — OFFICIAL: Sensitive
Australian Federal Government Agency
Reference: Australian Information Security Manual (ASD, March 2026 edition)

---

1. CONTROL APPLICABILITY MARKINGS FOR YOUR SYSTEM

Your system stores OFFICIAL: Sensitive (OS) information and is therefore classified at the OS level. Under the ISM applicability framework, the following markings apply:

Applicable Markings:
- NC (Non-Classified): All controls marked NC are mandatory. These represent the universal baseline that every government system must implement, regardless of classification level.
- OS (OFFICIAL: Sensitive): All controls marked OS are mandatory. These are additional controls specifically required for systems that store, process, or communicate OFFICIAL: Sensitive information.

Markings that do NOT apply to your system:
- P (PROTECTED): Not required unless your system is upgraded to handle PROTECTED information.
- S (SECRET): Not applicable.
- TS (TOP SECRET): Not applicable.

Stacking Rule Applied: As an OS system, your agency must implement NC + OS controls across all relevant guideline chapters. This is the standard baseline for most federal agency systems.

Cloud-hosted context: Because your system is cloud-hosted, Chapter 3 (Procurement and Outsourcing) controls apply with particular weight. Your cloud service provider (CSP) must be assessed for ISM alignment, and all relevant security responsibilities must be documented in a shared responsibility model within your System Security Plan.

---

2. KEY CONTROLS TO IMPLEMENT

The following summarises the key controls across the 22 ISM guideline chapters that apply to your NC + OS system. Controls are grouped by chapter domain.

Chapter 1 — Cyber Security Roles
- Appoint a CISO with appropriate authority and documented responsibilities.
- Designate a system owner for the case management system.
- Define and document security accountability structures.

Chapter 2 — Cyber Security Incidents
- Establish and document an incident response procedure covering detection, classification, response, and recovery.
- Define ASD notification obligations for significant incidents.
- Test incident response procedures and conduct post-incident reviews.

Chapter 3 — Procurement and Outsourcing
- Assess your cloud service provider (CSP) for ISM compliance and alignment with ASD's Cloud Security Guidance.
- Contractually require the CSP to implement ISM-aligned security controls, including for subcontractors.
- Document the shared responsibility model — which controls the CSP owns versus your agency.
- Assess supply chain risks associated with the CSP and any third-party integrations.

Chapter 4 — Cyber Security Documentation
- Produce and maintain a current System Security Plan (SSP) as the primary authorisation artefact.
- Maintain a risk register covering identified threats, vulnerabilities, likelihood, impact, and treatment.
- Document and version-control all security policies; review at least annually.

Chapter 5 — Physical Security
- If agency personnel access the system from physical premises, secure areas must have controlled access.
- Clean desk and clear screen policies must be enforced for workstations used to access the system.
- Note: Physical controls for the cloud hosting infrastructure are the CSP's responsibility — document this in the SSP.

Chapter 6 — Personnel Security
- All personnel with access to the case management system must be screened in accordance with the PSPF and hold appropriate clearances or background checks for OS-level information.
- Annual security awareness training is mandatory.
- Access must be revoked promptly upon termination or role change.

Chapter 9 — Enterprise Mobility
- If the system is accessed via mobile devices, they must be enrolled in an approved Mobile Device Management (MDM) solution.
- Remote access to the system must use an approved VPN with Multi-Factor Authentication (MFA).
- BYOD access requires containerisation or equivalent controls.

Chapter 11 — IT Equipment
- Maintain an asset register for all endpoints and devices used to access the system.
- Ensure secure disposal of any equipment holding cached or locally stored OS data.

Chapter 12 — Media
- Control any removable media used in connection with the system.
- Sanitise or destroy media before disposal.

Chapter 13 — System Hardening (Essential Eight overlap)
- Harden the operating systems and applications in the cloud environment (remove unnecessary services, disable default accounts).
- Implement application allow-listing where applicable.
- Enforce least privilege — no standing administrative access; use privileged access management (PAM).
- Restrict Microsoft Office macros and apply user application hardening (browsers, PDF readers).
- Configure Secure Boot and firmware security settings.

Chapter 14 — System Management (Essential Eight overlap)
- Apply critical patches within 14 days for internet-facing components; within 48 hours for CVSS 9–10 vulnerabilities on internet-facing assets.
- Apply high-severity patches within 14 days; medium within 30 days.
- Implement and test regular backups; store backup copies securely and separately (3-2-1 rule).
- Follow a documented change management process for all system changes.

Chapter 15 — System Monitoring
- Implement centralised event logging (SIEM or equivalent).
- Log retention for an OFFICIAL: Sensitive system: minimum 18 months.
- Logs must be stored in a tamper-evident manner, separate from the monitored system.
- All privileged access and system changes must be logged.
- Anomalous events must trigger alerts and investigation.

Chapter 16 — Software Development
- If the case management system involves custom development, implement a secure Software Development Life Cycle (SDLC).
- Conduct code reviews and vulnerability testing before deployment.
- Track and patch third-party dependencies.
- Implement a vulnerability disclosure policy if the system is externally facing.

Chapter 17 — Database Systems
- Harden the database (remove default accounts, disable unnecessary features).
- Encrypt sensitive case data at rest.
- Apply least privilege to all database access accounts.
- Log database activity.

Chapter 18 — Email
- If the system sends email notifications, configure DMARC (reject policy), DKIM, and SPF.
- Implement email gateway filtering to block malicious attachments and phishing content.

Chapter 19 — Networking
- Segment the case management system from general-purpose networks.
- Document and regularly review firewall rule sets.
- VPNs used for remote access must use TLS 1.2 minimum (TLS 1.3 preferred).
- Consider DNSSEC for DNS integrity.

Chapter 20 — Cryptography
- Data in transit must be protected using TLS 1.2 minimum (TLS 1.3 preferred); SSL and TLS 1.0/1.1 are prohibited.
- Data at rest must be encrypted using AES-128 minimum (AES-256 is best practice for OS).
- Use SHA-256 minimum for hashing; MD5 and SHA-1 are prohibited.
- Document key management procedures covering generation, storage, rotation, and destruction.

Chapter 21 — Gateways
- Implement web content filtering at internet gateways.
- Regularly assess gateway security.

Chapter 22 — Data Transfers
- Log all transfers of OFFICIAL: Sensitive data.
- Label data with its protective marking before transfer.
- Use approved transfer mechanisms.

Essential Eight — Required Maturity Level
As a federal government agency in 2026, you are expected to achieve Essential Eight Maturity Level 2 (ML2) as a minimum baseline. This covers:
1. Application control (allow-listing)
2. Patch applications
3. Configure Microsoft Office macros
4. User application hardening
5. Restrict administrative privileges
6. Patch operating systems
7. Multi-factor authentication (MFA)
8. Regular backups

ML2 means controls are mostly aligned and address sophisticated threats. Full ML3 is required only for critical infrastructure or high-risk sectors, but is a worthwhile aspiration for a case management system handling sensitive personal information.

---

3. AUTHORISATION PATHWAY BEFORE GO-LIVE

The ISM prescribes a six-step risk management cycle. For your system, the authorisation pathway to achieve an Authorisation to Operate (ATO) before go-live is as follows:

Step 1 — Define the System
Deliverable: System definition documentation (feeds into the SSP)
- Define the system boundary: all components in scope (cloud infrastructure, application, database, integrations, endpoints, user access paths).
- Identify all assets (hardware, software, data flows, third-party services).
- Confirm the classification level: OFFICIAL: Sensitive.
- Define security objectives using the CIA triad with High/Medium/Low ratings appropriate to a case management system (likely: Confidentiality = High, Integrity = High, Availability = Medium–High).

Step 2 — Select Controls
Deliverable: Control selection register (documented in SSP)
- Apply the NC + OS stacking rule to select applicable ISM controls across all 22 chapters.
- Tailor controls where needed: document any exclusions with written risk justification.
- Map the CSP's shared responsibility model to determine which controls the CSP satisfies and which remain with your agency.

Step 3 — Implement Controls
Deliverable: Evidence of control implementation
- Deploy and configure all selected controls as documented in the SSP.
- Produce evidence artefacts: configuration screenshots, policy documents, training records, patch reports, backup test results, network diagrams.

Step 4 — Assess Controls (IRAP Assessment)
Deliverable: IRAP Assessment Report
- Engage an ASD-registered IRAP assessor who is independent of your agency and the development team. Find assessors at: https://www.cyber.gov.au/resources-business-and-government/assessment-and-evaluation-programs/irap/irap-assessors
- An IRAP assessment is strongly recommended for OFFICIAL: Sensitive systems and is effectively expected for federal government systems delivering services to citizens.
- Provide the assessor with the full artefact package:
  - Current SSP
  - Network architecture diagrams
  - Asset register
  - Risk register
  - Full policy suite
  - Evidence of implemented controls
  - Incident register (last 12 months)
  - Patch management reports
  - Plan of Action and Milestones (POA&M) for any outstanding gaps
- The assessor reviews controls against ISM requirements and produces an IRAP Assessment Report with findings and recommendations.

Step 5 — Authorise the System (ATO)
Deliverable: Signed Authorisation to Operate (ATO)
- The Authorising Official (typically the Senior Responsible Officer or delegate with appropriate authority) reviews:
  - The IRAP Assessment Report
  - The SSP with all controls documented
  - The residual risk register
  - The POA&M for outstanding findings
- The Authorising Official formally accepts the residual risk and signs the ATO, authorising the system to go live.
- The ATO must record the authorisation date, the classification level, the system boundary, and the next review date.

Step 6 — Monitor Continuously
Deliverable: Ongoing monitoring programme
- Begin continuous control monitoring from go-live: log review, patch monitoring, alerting.
- Conduct a formal re-assessment every 24 months at minimum.
- Trigger an out-of-cycle re-assessment after any significant change (major architectural change, new classification level, major new functionality, or significant security incident).
- Maintain the SSP and risk register as living documents.

---

Summary: Authorisation Timeline

| Phase | Key Deliverable | Who |
|-------|----------------|-----|
| 1. Define | System boundary, classification, security objectives | Agency / System Owner |
| 2. Select | NC + OS control register (in SSP) | Agency / CISO |
| 3. Implement | Evidence package for all controls | Agency / IT team / CSP |
| 4. Assess | IRAP Assessment Report | ASD-registered IRAP assessor |
| 5. Authorise | Signed ATO | Authorising Official |
| 6. Monitor | Continuous monitoring + 24-month re-assessment | Agency / CISO |

Your system cannot go live without a signed ATO from the Authorising Official. While IRAP assessment is not legally mandatory at OS level, it is strongly recommended by ASD and is standard practice for federal government systems — particularly those handling OFFICIAL: Sensitive case data about individuals.

---

References:
- ISM (March 2026): https://www.cyber.gov.au/sites/default/files/2026-03/Information%20security%20manual%20(March%202026).pdf
- IRAP Assessors Register: https://www.cyber.gov.au/resources-business-and-government/assessment-and-evaluation-programs/irap/irap-assessors
- Essential Eight: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight
- Essential Eight to ISM Mapping: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-maturity-model-and-ism-mapping

ISM Control Applicability, Key Controls, and Authorisation Pathway for a Cloud-Hosted Case Management System Handling OFFICIAL: Sensitive Information

OVERVIEW

This response addresses the requirements for an Australian federal government agency operating a cloud-hosted case management system that processes OFFICIAL: Sensitive information. The applicable framework is the Australian Government Information Security Manual (ISM), published and maintained by the Australian Signals Directorate (ASD). The ISM provides a risk-based, principles-driven approach to cybersecurity, and all controls should be read in conjunction with the current version of the ISM (April 2025 edition as of this writing).

---

PART 1: ISM CONTROL APPLICABILITY MARKINGS

The ISM categorises controls using applicability designations that indicate whether a control must be applied, should be applied, or is optional depending on system context. For a system handling OFFICIAL: Sensitive information, the relevant applicability categories are:

1. MUST (Mandatory Controls)
These are non-negotiable baseline requirements that apply to all systems, regardless of classification level. They represent the minimum security posture required by the ISM. All OFFICIAL: Sensitive systems must comply with every "must" control.

2. SHOULD (Recommended Controls)
These are strongly recommended controls. While agencies can choose not to implement them, any deviation must be formally documented, risk-assessed, and accepted by the Authorising Officer (AO). Deviations from "should" controls are a common area of scrutiny during security assessments.

3. SHOULD NOT / MUST NOT
These are prohibitions. "Must not" controls are absolute prohibitions; "should not" controls are strong discouragements that require formal risk acceptance if deviated from.

4. MAY (Optional Controls)
These controls are discretionary and context-dependent. Agencies implement them based on their specific threat environment and risk appetite.

For classification-level scoping, the ISM provides a sensitivity/classification matrix. OFFICIAL: Sensitive sits above OFFICIAL (unclassified) but below PROTECTED. This means:

- All baseline controls applicable to OFFICIAL systems apply.
- Additional controls specifically triggered by the "Sensitive" handling caveat apply, particularly around access control, personnel security, and physical/logical separation.
- PROTECTED-only controls generally do not apply, unless the system also hosts or connects to PROTECTED information (in which case the system must be assessed at the higher level).

For cloud-hosted systems, ASD's Cloud Computing Security for Tenants guidance and the ISM's cloud-specific controls are directly applicable. The agency must also consider whether the cloud service provider (CSP) holds an ASD-issued Cloud Services Certification (formerly IRAP-assessed listing on the Hosting Certification Framework / Digital Transformation Agency Certified Cloud Services List).

---

PART 2: KEY CONTROLS TO IMPLEMENT

The following control areas represent the most significant requirements for a cloud-hosted OFFICIAL: Sensitive case management system. Control IDs referenced below are indicative of the ISM control numbering scheme; agencies should verify exact IDs against the current ISM version.

GOVERNANCE AND RISK MANAGEMENT

- Develop and maintain a System Security Plan (SSP) that documents the system's security architecture, control implementation, residual risks, and the decisions made by the Authorising Officer.
- Conduct a formal risk assessment using the agency's risk management framework (typically aligned to PSPF and the NIST-derived approach in the ISM).
- Appoint a System Owner and ensure a qualified Information Security Registered Assessors Program (IRAP) assessor conducts an independent assessment prior to authorisation.

IDENTITY AND ACCESS MANAGEMENT

- Implement multi-factor authentication (MFA) for all users accessing OFFICIAL: Sensitive systems, particularly when accessing over the internet or through cloud infrastructure (ISM control area: "Identifying and Authenticating Personnel").
- Apply the principle of least privilege; access must be role-based and reviewed at least annually.
- Privileged access must be separately managed, logged, and subject to additional controls (e.g., Privileged Access Workstations where operationally feasible).
- Use identity federation through an agency-managed identity provider (IdP) where possible, rather than relying solely on CSP-native identity services.

SYSTEM HARDENING

- Apply the ASD Essential Eight mitigation strategies as a baseline. For OFFICIAL: Sensitive systems, the minimum target maturity level is Maturity Level Two (ML2) across all eight strategies. The eight strategies are:
  1. Application Control
  2. Patch Applications
  3. Configure Microsoft Office Macro Settings
  4. User Application Hardening
  5. Restrict Administrative Privileges
  6. Patch Operating Systems
  7. Multi-Factor Authentication
  8. Regular Backups

- Operating systems, applications, and cloud service configurations must be hardened against the ASD hardening guides and, where applicable, CIS Benchmarks.
- Disable unnecessary services, ports, and protocols on all system components.

NETWORK SECURITY

- Traffic between end users and the cloud-hosted system must be encrypted in transit using TLS 1.2 or higher (TLS 1.3 preferred).
- Data at rest must be encrypted using AES-256 or equivalent.
- Network segmentation must be implemented to isolate the case management system from other workloads.
- Web application firewalls (WAF) and intrusion detection/prevention systems (IDS/IPS) must be deployed.
- For internet-facing systems, a gateway with ASD-approved protective DNS filtering should be used.

LOGGING AND MONITORING

- Comprehensive logging must be enabled across all system components, including authentication events, privilege use, data access, and configuration changes.
- Logs must be retained for a minimum of 18 months (7 years for some records depending on Records Act obligations).
- A Security Information and Event Management (SIEM) capability or equivalent must be in place to detect and alert on anomalous activity.
- Logs must be protected from unauthorised deletion or modification.

DATA MANAGEMENT AND HANDLING

- Data must be classified and labelled correctly at all times. Systems must enforce protective markings consistent with the Protective Security Policy Framework (PSPF).
- Data sovereignty requirements: OFFICIAL: Sensitive data must be stored within Australia unless a formal risk assessment and AO approval permits offshore storage. Most cloud contracts for Australian government data stipulate Australian data residency.
- Implement Data Loss Prevention (DLP) controls to prevent unauthorised exfiltration.

VULNERABILITY AND PATCH MANAGEMENT

- Critical patches must be applied within 48 hours of release for internet-facing systems; for non-internet-facing components, within two weeks.
- Conduct regular vulnerability scanning (at least monthly) and penetration testing (at least annually or after significant change).

PERSONNEL SECURITY

- All personnel with access to OFFICIAL: Sensitive systems must hold, at minimum, a Baseline security clearance (or demonstrate an equivalent personnel security check under the PSPF).
- Third-party vendor and CSP staff with administrative access to the hosting environment should be subject to equivalent or greater vetting requirements.

PHYSICAL AND ENVIRONMENTAL (Cloud Context)

- For cloud-hosted systems, the agency does not directly control physical infrastructure. The CSP must demonstrate compliance with relevant physical security standards. This is assessed as part of the IRAP assessment of the CSP's infrastructure.
- The agency should use only CSP services listed on the ASD Evaluated Products List or assessed through IRAP at the appropriate level.

INCIDENT RESPONSE

- An Incident Response Plan (IRP) must be developed, tested, and maintained.
- Security incidents must be reported to ASD via the ASD Cyber Incident Reporting Portal in accordance with mandatory reporting thresholds.
- Business Continuity and Disaster Recovery plans must account for cloud-specific failure scenarios (e.g., availability zone outages, CSP service disruptions).

---

PART 3: AUTHORISATION PATHWAY

The ISM prescribes a formal security authorisation process before a system can be approved to handle protectively marked information. The authorisation process for OFFICIAL: Sensitive systems follows these key stages:

STAGE 1: SYSTEM CATEGORISATION AND SCOPING

- Define the system boundary, including all components (application, database, APIs, network, identity services, third-party integrations).
- Confirm the highest classification of data the system will process or store. If any OFFICIAL: Sensitive data will be handled, the entire system is assessed at that level.
- Identify applicable threat actors (from ASD's Cyber Threat Intelligence) and business impact levels.

STAGE 2: SECURITY DOCUMENTATION DEVELOPMENT

Develop the following core artefacts:

- System Security Plan (SSP): Describes the system, its security architecture, threat model, control implementation status, and residual risks.
- Standard Operating Procedures (SOPs): Operational security procedures for administrators and users.
- Incident Response Plan (IRP): How the agency will detect, respond to, and recover from security incidents.
- Business Continuity Plan (BCP) / Disaster Recovery Plan (DRP).
- Risk Assessment Report: Formal documentation of threats, vulnerabilities, likelihood, impact, and treatment decisions.

STAGE 3: IRAP ASSESSMENT

- Engage an IRAP assessor (an individual assessed and endorsed by ASD to conduct security assessments of Australian government systems).
- The IRAP assessor conducts an independent review of the SSP, system architecture, control implementation evidence, and risk posture.
- The assessment produces a Security Assessment Report (SAR) that identifies control gaps, residual risks, and recommendations.
- The IRAP assessment is not an approval — it is an independent expert opinion provided to the Authorising Officer.
- For cloud-hosted systems, the IRAP assessment should include a review of the CSP's IRAP assessment for the relevant services (tenants can leverage CSP IRAP reports to reduce duplication, but must also assess the tenant-side controls they are responsible for).

STAGE 4: RISK TREATMENT AND REMEDIATION

- Address critical and high findings from the IRAP assessment prior to authorisation where possible.
- Document accepted residual risks with formal risk acceptance decisions by the appropriate risk owner.
- Any risks that exceed the agency's risk appetite must be escalated to the Authorising Officer with full context.

STAGE 5: AUTHORISATION DECISION

- The Authorising Officer (AO) — typically a Senior Executive Service (SES) officer or equivalent, who is accountable for the system — reviews the SAR, SSP, risk register, and all risk acceptance decisions.
- The AO makes an informed risk-based decision to either:
  (a) Grant an Authority to Operate (ATO) — unconditional approval to go live, or
  (b) Grant a conditional ATO with specific remediation conditions that must be met within a defined timeframe, or
  (c) Decline authorisation and require further remediation before re-assessment.
- The ATO is time-limited. ISM guidance indicates systems should be reassessed periodically (typically every two years, or following significant change).
- The AO accepts personal accountability for the residual risks of the system in its current state.

STAGE 6: CONTINUOUS MONITORING AND REAUTHORISATION

- Post-go-live, the agency must maintain a continuous monitoring program to detect changes to the risk posture (e.g., new vulnerabilities, configuration drift, new threat intelligence).
- Significant changes to the system (new integrations, changes to data flows, major version upgrades) may trigger a requirement to re-engage IRAP and seek a new or updated ATO.
- Annual reviews of the SSP and risk register are standard practice.
- The ATO must be reviewed and reissued at least every two years, or earlier if warranted by material changes or incidents.

---

SUMMARY TABLE

| Area | Requirement |
|---|---|
| Applicable classification | OFFICIAL: Sensitive (above OFFICIAL, below PROTECTED) |
| Essential Eight target | Maturity Level 2 (minimum) |
| MFA | Required for all users |
| Encryption at rest | AES-256 or equivalent |
| Encryption in transit | TLS 1.2+ (TLS 1.3 preferred) |
| Data residency | Australia (default; exceptions require AO approval) |
| Personnel security | Baseline clearance minimum |
| CSP assessment | IRAP-assessed CSP services required |
| Authorisation type | Authority to Operate (ATO) issued by Authorising Officer |
| Independent assessment | IRAP assessor required prior to ATO |
| ATO validity | Up to 2 years; triggers reauthorisation on significant change |
| Incident reporting | Mandatory reporting to ASD |

---

REFERENCES AND FURTHER READING

- Australian Government Information Security Manual (ISM) — Australian Signals Directorate: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism
- Protective Security Policy Framework (PSPF) — Attorney-General's Department: https://www.protectivesecurity.gov.au
- ASD Essential Eight Maturity Model: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight
- IRAP Assessors List: https://www.cyber.gov.au/about-us/irap
- Cloud Computing Security for Tenants (ASD): https://www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/cloud-computing-security
- ASD Certified Cloud Services: https://www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/cloud-computing-security/cloud-services-certification

# IRAP Assessment Preparation for a PROTECTED-Level System

This guidance covers the three areas you have asked about: artefacts to prepare, what to expect during the assessment, and what happens after the IRAP report is issued. It is based on the Australian Information Security Manual (ASD, March 2026 edition).

---

## 1. Artefacts to Prepare

Because your system handles PROTECTED-level information, an IRAP assessment is mandatory before the system can be formally authorised to operate. Your assessor will need a complete documentary package. Prepare the following before the assessment begins.

### Core Artefacts

**System Security Plan (SSP)**
This is the primary authorisation document and the centrepiece of your IRAP submission. It must contain:
- System name, owner, purpose, and operating environment
- System boundary — all in-scope hardware, software, and interfaces
- Classification level (PROTECTED)
- Security objectives — Confidentiality, Integrity, and Availability ratings
- All applicable ISM controls with justification for inclusion (for a PROTECTED system: NC + OS + P controls across all 22 guideline chapters)
- Evidence of implemented controls for each applicable control
- Excluded controls with documented risk acceptance and justification
- A current risk register
- Review schedule (minimum every 24 months or after significant change)

**Network Architecture Diagrams**
Current, accurate diagrams showing system boundaries, network zones, segmentation, interconnections, and classification boundaries. These must align with what is described in the SSP.

**Asset Register**
A complete register of all hardware and software assets within the system boundary. This underpins controls across Chapter 11 (IT Equipment), Chapter 12 (Media), and Chapter 13 (System Hardening).

**Risk Register**
A current risk register documenting identified threats, vulnerabilities, likelihood, impact ratings, and treatment decisions. Residual risks must be explicitly recorded.

**Policy Suite**
All security policies referenced in the SSP must exist and be current. Key policies for a PROTECTED system include:
- Access control policy
- Patch management policy and procedures
- Incident response plan
- Change management plan
- Business continuity and disaster recovery plan
- Media handling and sanitisation procedures
- Physical security procedures
- Acceptable use policy
- Cryptography and key management procedures
- Backup and recovery procedures

**Evidence of Implemented Controls**
For each control recorded as implemented in the SSP, you need supporting evidence. This typically includes configuration screenshots, hardening checklists, system-generated reports, training records, and test results. The assessor will sample and test this evidence.

**Incident Register (last 12 months)**
A log of cyber security incidents or near-misses. If you have no incidents to record, document that explicitly.

**Patch Management Reports**
Evidence that patches are being applied within ISM timeframes:
- Critical patches (CVSS 9–10): within 48 hours for internet-facing systems; 14 days for internal
- High patches (CVSS 7–8.9): within 14 days
- Medium patches (CVSS 4–6.9): within 30 days

**Essential Eight Evidence**
For a PROTECTED system, the assessor will also examine your Essential Eight implementation. Prepare evidence for each of the eight strategies: application control (allow-listing), patch applications, Microsoft Office macro controls, user application hardening, restriction of administrative privileges, patch operating systems, multi-factor authentication, and regular backups. ASD's 2026 recommended baseline for government entities is Maturity Level 2.

**Note on Previous Assessments**
As this is your first IRAP assessment, you will not have a previous IRAP report or Plan of Action and Milestones (POA&M). That is normal. The assessor will note this is an initial assessment.

---

## 2. What to Expect During the Assessment

### Engaging an IRAP Assessor
Before anything else, you must engage an assessor who is currently listed on the ASD IRAP Assessors Register. The assessor must be independent of your organisation and the system being assessed. You can find current assessors at:
https://www.cyber.gov.au/resources-business-and-government/assessment-and-evaluation-programs/irap/irap-assessors

### Scoping and Planning Phase
The assessor will work with you to confirm the system boundary and assessment scope. This includes agreeing which ISM controls are in scope, the assessment methodology, and the schedule. For a PROTECTED system the scope covers all NC, OS, and P controls across all 22 ISM guideline chapters relevant to your system's architecture.

### Document Review
The assessor will conduct a detailed review of all artefacts listed above. They will check that your SSP accurately reflects the system, that controls are documented with sufficient evidence, and that policies are current and approved. Gaps identified at this stage will be noted and may prompt requests for additional information.

### Technical Testing and Interviews
The assessor will conduct technical testing of the implemented controls. This typically includes:
- Configuration reviews (OS hardening, application hardening, firewall rules, cryptographic settings)
- Review of network architecture and segmentation against diagrams
- Sampling of patch management and change management records
- Testing of logging and monitoring capability (Chapter 15 — log retention of 18 months minimum for PROTECTED systems)
- Review of cryptographic implementations (AES-256 for PROTECTED data, SHA-384 minimum for hashing, TLS 1.2 minimum with TLS 1.3 preferred)
- Interviews with system administrators, the CISO, and key security personnel

### Findings Classification
The assessor will classify findings into categories (typically: satisfactory, minor finding, major finding, or significant risk). Findings represent controls that are not implemented, partially implemented, or implemented without adequate evidence.

### Draft Report Review
Before the final report is issued, you will normally be given an opportunity to review the draft IRAP Assessment Report and respond to findings. This is the appropriate time to provide any additional evidence or clarify misunderstandings. It is not the time to remediate major gaps — substantive remediation must happen before the assessment or will be recorded as outstanding findings.

---

## 3. What Happens After the IRAP Report is Issued

### IRAP Assessment Report
The assessor issues a formal IRAP Assessment Report documenting:
- Assessment scope and methodology
- All findings (satisfactory and non-compliant)
- Risk ratings for each finding
- Recommendations for remediation

This report is provided to your agency and is the primary input to the authorisation decision.

### Plan of Action and Milestones (POA&M)
Your agency must produce a POA&M addressing each finding in the IRAP report. The POA&M documents:
- Each finding and its risk rating
- The remediation action planned
- The responsible owner
- The target remediation date

The POA&M is a living document and must be maintained and updated as findings are closed.

### Authorisation to Operate (ATO)
Your Authorising Official (typically the agency head, CIO, or a delegate with appropriate authority) reviews the IRAP Assessment Report, the POA&M, and the residual risk profile. The Authorising Official makes a risk-based decision to:
- Grant an Authorisation to Operate — accepting residual risk and authorising the system for use
- Grant a conditional or time-limited ATO — with conditions tied to POA&M milestones
- Decline to authorise — if residual risk is unacceptable

The ATO is a formal sign-off that is recorded in the SSP.

### Ongoing Monitoring
After authorisation, your agency must:
- Maintain continuous monitoring of controls (Chapter 15)
- Apply patches within required timeframes (Chapter 14)
- Review and update the SSP at least every 24 months or after significant change
- Report cyber security incidents to ASD as required (Chapter 2)
- Conduct a re-assessment (new IRAP assessment) every 24 months minimum, or sooner if there is a significant architectural change, a change in classification level, or major new functionality is added

### Re-assessment Triggers
The following events require a new IRAP assessment regardless of timing:
- A major change to the system architecture or boundary
- A change in the classification level of information handled
- Addition of major new functionality or new interconnections with other systems

---

## Summary Checklist — Pre-Assessment Preparation

| Artefact | Owner | Status to Confirm |
|----------|-------|------------------|
| System Security Plan (SSP) — complete and current | System Owner / CISO | All sections complete, Authorising Official identified |
| Network architecture diagrams | IT/Architecture | Current, accurate, aligned to SSP |
| Asset register | IT | All in-scope hardware and software recorded |
| Risk register | CISO | Current risk ratings, treatments documented |
| Policy suite | CISO | All policies approved, version-controlled, within review cycle |
| Control evidence package | System Owner | Evidence for all implemented NC + OS + P controls |
| Incident register | CISO | Last 12 months documented |
| Patch management reports | IT | Reports showing compliance with ISM patch SLAs |
| Essential Eight evidence | IT / CISO | Evidence for all eight strategies at target maturity level |
| IRAP assessor engaged | CISO | Assessor confirmed on ASD IRAP register; independence confirmed |

---

## Key ISM References

- Chapter 4 — Cyber Security Documentation (SSP and policy requirements)
- Chapter 6 — Personnel Security (clearances, awareness training)
- Chapter 13 — System Hardening (OS, application, firmware hardening; Essential Eight)
- Chapter 14 — System Management (patch management, change management, backups)
- Chapter 15 — System Monitoring (logging; 18-month retention for PROTECTED systems)
- Chapter 19 — Networking (network segmentation, firewall rules)
- Chapter 20 — Cryptography (AES-256, SHA-384, TLS 1.2/1.3 for PROTECTED)
- ISM IRAP Assessors Register: https://www.cyber.gov.au/resources-business-and-government/assessment-and-evaluation-programs/irap/irap-assessors
- ISM (March 2026): https://www.cyber.gov.au/sites/default/files/2026-03/Information%20security%20manual%20(March%202026).pdf

Preparing for an IRAP Assessment of a PROTECTED-Level System

The Information Security Registered Assessors Program (IRAP) is an Australian Signals Directorate (ASD) initiative that authorises qualified assessors to evaluate the security posture of systems against the requirements of the Australian Government Information Security Manual (ISM). For a PROTECTED-level system, the stakes and documentation requirements are significant. The following covers what artefacts to prepare, what to expect during the assessment, and the post-assessment process.


ARTEFACTS TO PREPARE BEFORE THE ASSESSMENT

1. System Security Plan (SSP)
The SSP is the central document for any IRAP assessment. It must describe:
- The system's purpose, boundaries, and architecture
- All data flows, including ingress, egress, and inter-component flows
- The classification and handling requirements for the information processed (PROTECTED in your case)
- All hardware, software, and network components in scope
- How ISM controls are addressed, including any controls not applied and the justification for each exception
- Roles and responsibilities for system security

2. Statement of Applicability (SoA)
A control-by-control mapping against the ISM, identifying which controls apply to the system, which are implemented, and which are not applicable (with rationale). For a PROTECTED system, this will include a broad range of controls across topics such as access control, cryptography, patch management, logging, and personnel security.

3. Risk Management Documentation
- A formal risk assessment conducted in accordance with the agency's risk management framework (typically aligned to NIST SP 800-30 or equivalent)
- A risk register capturing identified threats, vulnerabilities, likelihood, consequence, and residual risk ratings
- A risk treatment plan or Plan of Action and Milestones (POA&M) documenting how identified risks will be addressed

4. Security Architecture and Network Diagrams
Detailed diagrams showing:
- System topology and network segmentation
- Data classification zones and boundary protections
- External connections, gateways, and any cross-domain solutions
- Cloud service usage and relevant shared responsibility boundaries

5. Standard Operating Procedures (SOPs) and Security Policies
Relevant operational documentation the assessor will review, including:
- Access control procedures (including privileged access management)
- Incident response plan
- Patch management procedures
- Change management process
- Backup and recovery procedures
- Media handling and disposal procedures
- Personnel security procedures

6. Evidence of Control Implementation
Actual evidence that stated controls are in place, such as:
- Configuration baselines and hardening guides (aligned to ASD's Hardening Guides where applicable)
- Vulnerability scan results and penetration test reports
- Audit and log management evidence
- Training records for personnel with system access
- Certificates or configurations for encryption at rest and in transit

7. Previous Assessment Reports and Remediation Evidence
If any prior security reviews, penetration tests, or internal audits have been conducted, gather these along with evidence of remediation for any findings.

8. Data Classification and Information Management Documentation
Documentation showing how PROTECTED information is classified, labelled, handled, stored, transmitted, and disposed of in accordance with the Protective Security Policy Framework (PSPF).

9. Authorising Officer (AO) Engagement Records
Evidence that the relevant Authorising Officer has been engaged in the risk acceptance process. The AO is ultimately responsible for accepting residual risk and authorising the system to operate.

10. Third-Party and Supply Chain Agreements
Any contracts, Memoranda of Understanding (MoUs), or cloud service agreements relevant to the system's security, including any ASD-certified cloud services used and their certification documentation.


WHAT TO EXPECT DURING THE IRAP ASSESSMENT

An IRAP assessment typically involves three main phases:

Phase 1: Documentation Review (Desk-Based Review)
The assessor reviews all submitted documentation against ISM requirements. This is largely a paper-based exercise. You should expect:
- Requests for additional or clarifying documentation
- Preliminary identification of potential gaps or non-conformances
- Questions about architectural decisions and risk acceptance rationale

This phase can take several weeks depending on the complexity of the system and the completeness of the documentation provided. Incomplete documentation is a common cause of delays.

Phase 2: Technical Testing and Interviews
The assessor will validate that documented controls are actually implemented. This includes:
- Interviews with system administrators, security staff, and other key personnel
- Inspection of live system configurations (firewall rules, access control lists, audit logging settings, etc.)
- Review of vulnerability scan results or conducting their own scanning
- Verification of cryptographic implementations
- Spot-checks on patch currency and hardening

For a PROTECTED system, the assessor will pay particular attention to boundary controls, access management for privileged users, handling of credentials, logging and monitoring completeness, and any connections to external or lower-classification environments.

Phase 3: Reporting and Findings Discussion
After testing, the assessor will:
- Document all findings, categorised by risk rating (typically High, Medium, Low, or Informational)
- Brief the agency on preliminary findings before the final report is issued
- Allow the agency to respond to factual inaccuracies before finalisation

Assessors are independent and cannot advise on how to remediate findings during the assessment itself, as this would compromise their independence.

Things to Expect Generally
- The assessment duration for a PROTECTED system is typically 4 to 12 weeks depending on system complexity, scope, and documentation readiness.
- Active cooperation is required — designate a point of contact and ensure relevant technical staff are available for interview.
- The assessor works to the current version of the ISM (updated monthly by ASD), so confirm you are referencing the correct version.
- IRAP assessors are individuals, not organisations. Ensure your assessor holds a current IRAP authorisation from ASD.


AFTER THE IRAP REPORT IS ISSUED

The IRAP assessor produces a formal assessment report, commonly called an IRAP Security Assessment Report (SAR). This document presents:
- An overall assessment of the system's security posture
- Findings and residual risks rated by severity
- Recommendations for remediation
- The assessor's professional opinion on whether the system is suitable for operation at the assessed classification level

Step 1: Agency Review of the Report
The agency (system owner) reviews the SAR and prepares a formal response. This typically involves:
- Acknowledging each finding
- Documenting planned remediation actions and timelines
- Seeking risk acceptance from the Authorising Officer for any residual risks that will not be immediately remediated

Step 2: Authorising Officer Risk Acceptance
The Authorising Officer reviews the SAR and the agency's response. If the AO is satisfied that residual risks are acceptable, they issue a formal Authority to Operate (ATO) or equivalent authorisation. This is not automatic — the AO may require certain High findings to be remediated before authorisation is granted.

Step 3: Remediation of Findings
For findings that are not accepted as residual risk, the agency must implement remediation and track progress through the risk register or POA&M. Some agencies agree with their AO to operate with a time-limited authorisation pending completion of remediation.

Step 4: Submission to ASD (if applicable)
For some systems, particularly those used in Commonwealth agencies or where ASD accreditation is required, the SAR and associated documentation may need to be submitted to ASD for review. ASD may provide additional feedback or requirements. Confirm with your agency's Chief Information Security Officer (CISO) whether formal ASD submission is required in your case.

Step 5: Ongoing Assurance
IRAP assessment is not a one-time event. Authorisations are typically valid for a defined period (often two to three years) or until significant changes occur. Ongoing obligations include:
- Continuous monitoring of security controls
- Reassessment if significant architectural or functional changes are made to the system
- Annual review of the risk register and SSP currency
- Maintaining an Evidence of Compliance file to support future assessments
- Reporting significant security incidents to ASD and the agency's CISO

Step 6: Plan for Reassessment
Document lessons learned from the first assessment and begin maintaining the SSP and evidence artefacts as living documents. This significantly reduces effort for future assessments.


KEY TIPS FOR FIRST-TIME IRAP ASSESSMENT

- Engage the assessor early, ideally 6 to 8 weeks before assessment commencement, to agree on scope, methodology, and documentation requirements.
- Do not wait until the last moment to compile documentation. Gaps in documentation are one of the most common causes of findings and delays.
- Conduct an internal pre-assessment or gap analysis against the ISM before the formal IRAP begins. This allows time to address obvious gaps.
- Ensure your SSP is current and accurately reflects the system as it exists — not as it was designed or as you intend it to be.
- Brief your Authorising Officer well in advance so they understand their role and the likely risk acceptance decisions they will need to make.
- The ISM is the primary benchmark. Supplementary guidance such as ASD's Essential Eight and Hardening Guides are relevant but the ISM controls are the formal assessment basis.

# ISM Chapter 13 — System Hardening: Requirements and Evidence for Windows Server 2022

Source: Australian Information Security Manual (ASD), March 2026 edition
Assumed classification: OFFICIAL: Sensitive (OS) — the default baseline for state government systems handling sensitive information. If your deployment handles PROTECTED information, all NC + OS + P controls apply and additional controls are required beyond what is listed here.

---

## Overview of Chapter 13 — System Hardening

Chapter 13 sits within the Protect function of the ISM framework. Its purpose is to ensure that operating systems, applications, and firmware are configured securely before deployment and maintained in a hardened state throughout the system lifecycle. For Windows Server 2022, this translates into a set of concrete technical actions covering the OS baseline, application controls, firmware, and privileged access management.

Chapter 13 also underpins four of the eight Essential Eight mitigation strategies: application control (allow-listing), configuring Microsoft Office macros, user application hardening, and restricting administrative privileges. This means that Chapter 13 compliance is closely tied to your Essential Eight Maturity Level reporting obligations.

---

## What Chapter 13 Requires

### 1. Operating System Hardening

The ISM requires that operating systems be hardened before deployment. This means removing or disabling everything that is not needed for the system's defined purpose.

For Windows Server 2022 specifically, the following actions are required:

- Remove all Windows roles, role services, and features that are not required for the server's purpose. Every unnecessary component is an attack surface.
- Disable all default and built-in accounts that are not needed. The built-in local Administrator account must be renamed and its use restricted; the Guest account must be disabled.
- Apply the ASD hardening guidance for Windows Server. ASD publishes a dedicated hardening guide (Hardening Microsoft Windows Server) that specifies required Group Policy settings. Your configuration must align with that guide.
- Enforce screen lock and session timeout policies.
- Configure Windows Defender and ensure real-time protection is active unless a compensating security product is formally documented.
- Disable unnecessary network services and protocols (for example, SMBv1, NetBIOS over TCP/IP where not required, LLMNR, mDNS).
- Apply a host-based firewall policy that blocks all inbound traffic not explicitly required.

### 2. Application Hardening

Applications installed on the server must also be hardened:

- Disable or remove features within applications that are not required for the server's function.
- Apply vendor-supplied hardening guides for all installed server software (IIS, SQL Server, .NET, etc.).
- Uninstall or disable software that is not required — this includes browser software unless operationally justified.
- Where Microsoft Office is installed, macro execution must be restricted. At a minimum, macros must be blocked from the internet and only macros from trusted publishers or trusted locations may run. This directly maps to the Essential Eight "Configure Microsoft Office macros" strategy.

### 3. Application Control (Allow-Listing)

This is one of the highest-priority Chapter 13 controls and maps directly to the Essential Eight "Application control" strategy.

- An application allow-list must be implemented to prevent execution of unapproved or unknown executables, software libraries, scripts, and installers.
- On Windows Server 2022, this is implemented via Windows Defender Application Control (WDAC) or AppLocker, with WDAC being ASD's preferred solution.
- The allow-list must cover all user-accessible execution paths. At Essential Eight ML2 (the ASD-recommended baseline for government), the allow-list must prevent execution of malicious code in standard user profiles and temporary directories.
- At ML3, the allow-list must be enforced using a combination of publisher certificate rules and file hash rules and must cover all execution paths including scripts and interpreted code.

### 4. Firmware Security

The ISM requires that firmware-level security settings be configured before deployment:

- Secure Boot must be enabled. Windows Server 2022 supports Secure Boot; it must be active and the firmware must be configured to prevent disabling it from the OS.
- A strong BIOS/UEFI password must be set to prevent unauthorised firmware modifications.
- Boot order must be restricted so that the server can only boot from the authorised system drive.
- Where available, TPM 2.0 should be enabled and used to support measured boot and attestation.
- Firmware must be kept current — out-of-date firmware with known vulnerabilities is treated as a hardening gap.

### 5. Least Privilege and Privileged Access Management

This is a core ISM requirement that runs throughout Chapter 13 and connects to Chapter 6 (Personnel Security).

- No standing administrative access. Standard user accounts must be used for day-to-day operations; administrative credentials must only be used when performing administrative tasks.
- Separate administrative accounts must be created for each administrator — shared administrator accounts are not permitted.
- Domain Administrator and Enterprise Administrator accounts must be tightly controlled; their use must be logged and reviewed.
- Local administrator accounts on servers must be managed. Microsoft LAPS (Local Administrator Password Solution) or equivalent must be used to ensure unique, rotated local admin passwords across all servers.
- Privileged Access Workstations (PAWs) are strongly recommended for performing administrative tasks on servers handling OS-classified information.
- Just-In-Time (JIT) access is the preferred model — administrative rights should be granted only when needed and revoked after use.
- Remote Desktop Protocol (RDP) access must be restricted to authorised IP ranges, use Network Level Authentication (NLA), and require MFA for privileged accounts.

### 6. User Application Hardening

Where end-user applications are present on the server (this is less common for server deployments but applies to jump servers or terminal server deployments):

- Web browsers must be hardened: Flash, Java plugins, and unsupported extensions must be disabled or removed; automatic execution of web-delivered content must be blocked.
- PDF viewers must be configured to block internet connections and disable JavaScript execution within documents.
- Microsoft Office must be configured per ASD's hardening guide, including disabling OLE package activation.

---

## Control Applicability for Your Deployment

Your Windows Server 2022 deployment is assumed to be an OFFICIAL: Sensitive (OS) system. This means you must implement all NC-marked and OS-marked controls from Chapter 13. The table below maps the key Chapter 13 control areas to their applicability:

| Control Area | Applicability | Notes |
|---|---|---|
| OS hardening (remove unnecessary services, disable default accounts) | NC | Applies to all government systems |
| Application allow-listing | NC / OS | Essential Eight strategy; required at ML2 for OS systems |
| Firmware security (Secure Boot, BIOS password) | NC | Applies to all government systems |
| Least privilege enforcement | NC / OS | No standing admin access; separate admin accounts |
| Local admin password management (LAPS) | NC / OS | Required for all managed endpoints and servers |
| Application hardening (disable unused features) | NC | Applies to all installed software |
| Microsoft Office macro restrictions | NC / OS | Essential Eight strategy |
| Browser and PDF hardening | NC / OS | Essential Eight "User application hardening" |

If your system is reclassified to PROTECTED, additional P-marked controls apply, including stricter controls on privileged access, evaluated cryptographic products, and mandatory IRAP assessment.

---

## Evidence Required for Compliance Assessment

An assessor evaluating your Chapter 13 compliance — whether during an internal review, IRAP assessment, or government audit — will look for documented evidence that each control is implemented. Below is a structured evidence checklist.

### OS Hardening Evidence

| Evidence Item | Description |
|---|---|
| Group Policy export or baseline configuration report | Demonstrates applied hardening settings, aligned with ASD's Windows Server 2022 hardening guide |
| Roles and features inventory | Shows only required Windows roles and features are installed (e.g., output of `Get-WindowsFeature` filtered to installed items) |
| Disabled accounts listing | Shows Guest and default accounts are disabled; local Administrator is renamed |
| Host-based firewall rule set | Documents all allowed inbound/outbound rules and confirms default-deny posture |
| Network protocol configuration | Evidence that SMBv1, LLMNR, NetBIOS over TCP/IP are disabled where not required |
| ASD Windows Server Hardening Guide gap comparison | A completed checklist showing alignment with ASD's published hardening benchmark |

### Application Control Evidence

| Evidence Item | Description |
|---|---|
| WDAC or AppLocker policy export | The implemented application control policy in XML or readable format |
| Block event log samples | Windows event log entries (Event ID 3076/3077 for WDAC in audit mode; 8003/8004 for AppLocker) demonstrating the policy is active |
| Policy scope documentation | Confirms the allow-list covers all execution paths (executables, scripts, libraries, installers) |
| User acceptance testing (UAT) record | Confirms the allow-list does not block legitimate business applications |

### Firmware Security Evidence

| Evidence Item | Description |
|---|---|
| BIOS/UEFI configuration screenshots | Shows Secure Boot enabled, boot order locked, BIOS password set |
| System Information report | `msinfo32` or `Get-ComputerInfo` output confirming Secure Boot state and TPM presence |
| Firmware version record | Current firmware version against vendor's latest release, confirming firmware is up to date |

### Least Privilege and Privileged Access Management Evidence

| Evidence Item | Description |
|---|---|
| Active Directory group membership reports | Lists of users in privileged groups (Domain Admins, Server Operators, Backup Operators, local Administrators) |
| Separate admin account documentation | Evidence that all admins have a separate privileged account distinct from their standard account |
| LAPS deployment confirmation | Evidence LAPS is deployed, local admin accounts are managed, and password rotation is occurring |
| Privileged Access Workstation (PAW) documentation | Architecture diagram or policy describing how administrative tasks are performed |
| RDP access policy | Firewall rules, NLA configuration, and MFA configuration for RDP access |
| Privileged account review records | Evidence of regular review of privileged account membership (at least annually) |

### Application Hardening Evidence

| Evidence Item | Description |
|---|---|
| Installed software inventory | Current list of all installed software on each server |
| Application hardening checklists | Completed hardening checklists for IIS, SQL Server, .NET runtime, and any other installed server software |
| Microsoft Office macro policy (if Office is installed) | Group Policy setting or registry export showing macro restrictions |
| Browser hardening configuration (if browsers are present) | Policy export or configuration screenshots showing plugin and execution restrictions |

### Essential Eight Maturity Assessment Evidence

Because four Essential Eight strategies are covered by Chapter 13, your assessor will also want:

| Evidence Item | Description |
|---|---|
| Essential Eight self-assessment | Completed self-assessment against all eight strategies, scored to ML0–ML3 for each |
| Application control strategy document | Describes what is allowed, how exceptions are handled, and how the allow-list is maintained |
| Macro configuration policy document | Describes the approved macro execution policy and how it is enforced |

---

## Practical Steps: Preparing for Assessment

1. Conduct a baseline configuration review before the assessment. Use the ASD Windows Server 2022 hardening guide as your checklist and document every setting against the requirement. Note gaps and remediate before assessment.

2. Export your Group Policy Objects (GPOs). Assessors will review these in detail. Organise them by function (security baseline, application control, audit policy, etc.).

3. Validate your application allow-list is in enforced mode, not audit mode. An allow-list in audit-only mode is not considered compliant. If you are transitioning, document the timeline and risk acceptance.

4. Verify LAPS is functioning. Run a report showing last password rotation times across all servers. Stale entries indicate a gap.

5. Run a privileged account review. Identify any accounts with administrative rights that do not need them and remove them before assessment.

6. Document every exclusion formally. If a control cannot be implemented (for example, a specific protocol must remain enabled for a legacy integration), document the risk acceptance in your System Security Plan (SSP) with the Authorising Official's signature.

7. Collate all evidence into an evidence folder mapped to each control. An assessor will work through controls sequentially; having pre-organised evidence by control area significantly reduces assessment duration.

---

## Connection to System Authorisation

Chapter 13 evidence does not exist in isolation. It feeds directly into your System Security Plan (SSP), which is the primary artefact for Authorisation to Operate (ATO). Your SSP must document:

- All Chapter 13 controls selected as applicable
- Implementation status of each control
- Evidence references (pointers to your evidence folder)
- Any exclusions with documented risk justification
- The Authorising Official's acceptance of residual risk

For an OFFICIAL: Sensitive system, an IRAP assessment is strongly recommended (and may be required by your agency's security policy) before authorisation. The IRAP assessor will independently verify the Chapter 13 evidence listed above.

---

## Key References

- ASD Information Security Manual (March 2026): https://www.cyber.gov.au/sites/default/files/2026-03/Information%20security%20manual%20(March%202026).pdf
- ASD Hardening Microsoft Windows Server: https://www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/system-hardening/hardening-microsoft-windows-server
- Essential Eight Maturity Model: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight
- Essential Eight to ISM Mapping: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-maturity-model-and-ism-mapping
- IRAP Assessors Register: https://www.cyber.gov.au/resources-business-and-government/assessment-and-evaluation-programs/irap/irap-assessors

ISM Chapter 13 System Hardening: Requirements and Evidence for Windows Server 2022

Overview

The Australian Government Information Security Manual (ISM), published by the Australian Signals Directorate (ASD), dedicates Chapter 13 to System Hardening. This chapter establishes baseline security controls that reduce the attack surface of operating systems and applications. For a Windows Server 2022 deployment in a state government environment, Chapter 13 is the primary technical hardening reference. It aligns closely with ASD's Hardening guidance and the Essential Eight maturity model.

The controls in Chapter 13 are grouped across several domains. Below is a structured walkthrough of each major domain, what the ISM requires, and what evidence an assessor would expect to see.

---

1. Operating System Hardening

ISM Requirements

- Use the latest stable, supported version of the operating system. Windows Server 2022 satisfies this at present, but patching must be kept current.
- Apply vendor-supplied patches within defined timeframes. For internet-facing systems, critical patches must be applied within 48 hours; for other systems, within one month (aligned with Essential Eight Patch OS control).
- Remove or disable all unnecessary operating system components, features, and services. This includes disabling legacy protocols such as SMBv1, NetBIOS over TCP/IP, and LLMNR where not required.
- Configure the OS in accordance with a hardening standard. ASD's Windows Server 2022 hardening guide and the corresponding ACSC guidance provide the baseline.
- Disable or restrict AutoRun and AutoPlay.
- Ensure the OS boots from internal storage only, and configure BIOS/UEFI settings to prevent booting from removable media.
- Enable Secure Boot and, where supported, Trusted Platform Module (TPM) 2.0 integration.

Evidence to Collect

- Patch management records showing patch dates, patch levels, and compliance against the 48-hour and one-month thresholds.
- System build documentation or baseline configuration record referencing the applicable hardening standard.
- Screenshots or exported Group Policy results (rsop.msc or gpresult /h) showing disabled legacy features and services.
- Windows Features list (Get-WindowsFeature) showing only required roles and features are installed.
- BIOS/UEFI configuration screenshots or vendor attestation confirming Secure Boot enabled and boot order restrictions.
- Results of a CIS Benchmark or ACSC hardening assessment tool run against the server.

---

2. Application Hardening

ISM Requirements

- Only approved and required applications are installed. Maintain a documented software register.
- Application whitelisting (now called application control) must be implemented. ASD mandates this as part of the Essential Eight. On Windows Server 2022, this is achieved via Windows Defender Application Control (WDAC) or AppLocker.
- Web browsers and PDF viewers are hardened. While less critical on a server, any browser-accessible management interfaces must use hardened configurations.
- Disable or remove web-based administrative interfaces if not required.
- Office productivity software macros must be disabled or restricted; only trusted, signed macros from approved locations should be permitted if needed.
- Uninstall or disable software development tools (compilers, interpreters) unless the server's function requires them.
- Ensure all installed applications are patched. Application patches, particularly for internet-facing components (IIS, .NET Framework, SQL Server), must be applied within 48 hours for critical patches affecting internet-facing services.

Evidence to Collect

- Installed software inventory (Get-WmiObject Win32_Product or similar) compared against the approved software register.
- Application control policy export (WDAC XML policy file or AppLocker GPO export) and evidence it is in enforce mode (not audit mode).
- Event logs showing application control blocks, demonstrating the policy is active.
- Patch records for all installed applications.
- Group Policy or registry settings showing macro restrictions.

---

3. Authentication Hardening

ISM Requirements

- Enforce strong password policies: minimum length of at least 14 characters for privileged accounts, complexity requirements, and password history.
- Multi-factor authentication (MFA) must be used for all remote access and for all privileged account logons. This is an Essential Eight requirement and is reflected in ISM controls.
- Privileged accounts must not be used for standard tasks such as web browsing or email.
- Local administrator accounts must be managed. The built-in Administrator account should be renamed or disabled; use LAPS (Local Administrator Password Solution) for unique, rotating local admin passwords across servers.
- Service accounts must use unique, strong passwords and be granted only the minimum privileges required.
- Implement account lockout policies to mitigate brute-force attacks.
- Disable or restrict the use of NTLM authentication where possible; prefer Kerberos.
- Restrict which accounts can log on to the server interactively or via Remote Desktop.

Evidence to Collect

- Password policy export (Group Policy or fine-grained password policy) showing minimum length, complexity, history, and lockout thresholds.
- Documentation of MFA solution deployed and scope (which accounts and access paths are covered).
- LAPS deployment confirmation (registry keys, GPO, or Intune policy showing LAPS is enabled and password rotation is configured).
- Privileged Access Workstation (PAW) policy or documentation showing privileged accounts are separated.
- User Rights Assignment export (secedit or Group Policy) showing logon rights are restricted.
- Evidence that NTLM restrictions are in place where applicable (e.g., Group Policy: Network Security: Restrict NTLM settings).

---

4. Network Hardening

ISM Requirements

- The Windows Firewall must be enabled on all profiles (Domain, Private, Public) and configured to block inbound connections unless explicitly permitted.
- Only required network ports and protocols are open. Unnecessary services must be stopped and their associated firewall rules removed.
- Remote management must use encrypted channels only. RDP must require Network Level Authentication (NLA). Prefer Windows Admin Center, SSH (where applicable), or other hardened management interfaces over older protocols.
- Disable server message block (SMBv1). Use SMBv3 with encryption where file sharing is required.
- Disable LLMNR and NetBIOS name resolution via Group Policy to prevent name poisoning attacks.
- Restrict Remote Desktop Protocol access to specific IP ranges or jump servers.
- Implement IPsec or equivalent where lateral movement between servers must be restricted.

Evidence to Collect

- Windows Firewall policy export or Group Policy showing rules, default deny posture, and all profiles enabled.
- Port scan results (e.g., Nmap output) confirming only required ports are exposed.
- NLA requirement setting confirmed in Group Policy (Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services).
- SMBv1 disabled confirmed via Get-SmbServerConfiguration or Group Policy.
- LLMNR and NetBIOS disabled confirmed via Group Policy settings and registry values.
- Network diagram showing where the server sits and what firewall or segmentation controls exist at the network perimeter.

---

5. Logging and Auditing

ISM Requirements

- Enable Windows Security auditing for the following event categories at minimum: Account Logon, Account Management, Logon/Logoff, Object Access (for sensitive resources), Policy Change, Privilege Use, and System events.
- Forward logs to a centralised Security Information and Event Management (SIEM) system or a protected, centralised log repository.
- Log retention must meet the minimum period specified in the ISM — typically at least 18 months for government systems, with 90 days available online.
- Protect audit logs from unauthorised modification or deletion.
- Enable PowerShell script block logging, module logging, and transcription to detect and investigate malicious PowerShell use.

Evidence to Collect

- Audit policy output (auditpol /get /category:*) confirming all required categories are enabled.
- Screenshot or configuration export from the SIEM showing the server is an active log source.
- Log retention policy documentation and storage configuration showing 18-month retention.
- PowerShell logging Group Policy settings (Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell).
- Sample log entries demonstrating log forwarding is operational (e.g., syslog or Windows Event Forwarding confirmation).

---

6. Restricting Administrative Privileges

ISM Requirements

- Apply the principle of least privilege. Users and services are granted only the minimum access required.
- Privileged accounts must be dedicated accounts, separate from standard user accounts.
- Time-based or just-in-time (JIT) privileged access should be considered for administrative access.
- Privileged access must be reviewed regularly; dormant or unnecessary privileged accounts must be removed.
- Domain Administrator rights must not be used for day-to-day server administration where server-local administrator rights are sufficient.
- Restrict the ability to install software to administrators only.

Evidence to Collect

- Export of local Administrators group membership on the server.
- Active Directory privileged group membership reports (Domain Admins, Enterprise Admins, Server Operators, etc.).
- Evidence of periodic access reviews (meeting minutes, sign-off records, or automated review reports).
- Documentation of JIT or PAM (Privileged Access Management) solution if deployed.
- Group Policy showing software installation restricted to administrators.

---

7. Virtualisation Hardening (where applicable)

If Windows Server 2022 is deployed as a virtual machine or as a Hyper-V host, additional ISM controls apply.

ISM Requirements

- The hypervisor and virtualisation platform must be kept patched and hardened.
- Virtual machine escape mitigations must be in place. Enable Virtualisation Based Security (VBS) and Hypervisor-Protected Code Integrity (HVCI) where supported.
- Restrict access to the hypervisor management plane; do not use hypervisor management from general-purpose workstations.
- Separate guest VMs of different sensitivity classifications if they process data at different classification levels.
- Ensure virtual networks are segmented equivalently to physical networks.

Evidence to Collect

- Hypervisor patch level and version documentation.
- VBS and HVCI enabled confirmed via msinfo32 or Get-CimInstance -ClassName Win32_DeviceGuard.
- Network segmentation diagram for virtual switch configuration.
- Hypervisor management access control policy.

---

8. Firmware and Supply Chain

ISM Requirements

- Ensure server firmware (BIOS/UEFI, BMC/iDRAC/iLO) is kept current and sourced from trusted vendor channels.
- Disable unused firmware interfaces (e.g., disable unused USB ports, disable legacy PXE boot if not needed).
- Where hardware supports it, enable firmware integrity verification.
- Document the supply chain for hardware procurement to ensure equipment is from reputable sources.

Evidence to Collect

- Firmware version records and evidence of firmware update process.
- BIOS/UEFI configuration screenshots showing disabled unused interfaces.
- Hardware procurement documentation confirming authorised supply channels.

---

Summary: Evidence Package for an ISM Chapter 13 Assessment

The following is a consolidated list of evidence artefacts an assessor will typically request for a Windows Server 2022 system hardening assessment:

1. System baseline and build documentation referencing the applicable hardening standard (ACSC Windows Server 2022 hardening guide or CIS Benchmark).
2. Group Policy results report (gpresult /h) or exported GPO settings for the server.
3. Installed roles and features list (Get-WindowsFeature).
4. Installed software inventory compared against approved software register.
5. Patch management records (OS and application patches) with dates and approval records.
6. Application control policy export (WDAC or AppLocker) confirming enforce mode.
7. Application control event logs showing the policy is active.
8. Password and lockout policy configuration export.
9. MFA deployment documentation and scope.
10. LAPS configuration confirmation.
11. Local Administrators group membership.
12. Privileged group membership reports and access review records.
13. Windows Firewall policy export.
14. Port scan results confirming only required ports are open.
15. SMBv1 disabled confirmation.
16. LLMNR and NetBIOS disabled confirmation.
17. Audit policy output (auditpol /get /category:*).
18. PowerShell logging Group Policy settings.
19. SIEM log forwarding confirmation and log retention policy.
20. Secure Boot and TPM configuration evidence.
21. VBS and HVCI enabled (if virtualisation hardening applies).
22. Firmware version and update records.

---

Practical Recommendations for Your Team

Prior to assessment, run the ASD-provided hardening scripts or a CIS-CAT scan against the server and remediate all findings. The ACSC publishes Windows Server 2022 hardening guidance with accompanying Group Policy templates that can be applied directly. Ensure your Group Policy Objects are documented and that each policy setting maps back to a specific ISM control number; this simplifies the assessment conversation significantly.

Assessors will typically check configuration both through documentation and through live technical inspection. Be prepared to demonstrate settings interactively on the server, not just via screenshots, as screenshots can be pre-staged. Ensure logging is operational and demonstrably forwarding to a centralised store before the assessment date.

Maintain a controls register or compliance matrix that maps each ISM Chapter 13 control identifier to your implementation approach, the responsible team member, and the specific evidence artefact that demonstrates compliance. This register becomes your primary assessment artefact and significantly reduces the time spent during an on-site review.

# Essential Eight and the ISM: Relationship, Chapter Mapping, and ML2 Requirements

## How the Essential Eight Relates to the Broader ISM

The Essential Eight is not a separate standard — it is a prioritised subset of controls drawn directly from the Australian Information Security Manual (ISM), published by the Australian Signals Directorate (ASD). ASD identified these eight mitigation strategies as the highest-value actions an organisation can take to protect against the most common cyber threats, particularly opportunistic and targeted attacks.

Key points about this relationship:

- The ISM contains 22 guideline chapters covering the full breadth of government cybersecurity — from physical security and personnel screening through to cryptography, networking, and data transfers. The Essential Eight maps primarily into Chapters 6, 9, 13, 14, and 19 of the ISM.
- Achieving Essential Eight ML2 is not the same as achieving full ISM compliance. An organisation that completes ML2 has addressed the most critical technical controls, but will still have significant gaps across the remaining ISM chapters (e.g., physical security, communications systems, media handling, software development, cryptographic key management, gateways, and data transfers).
- For government entities, both ISM control compliance AND Essential Eight targets apply. The Essential Eight is effectively the "do this first" subset; the remaining ISM chapters address the full risk posture required for system authorisation.
- Essential Eight Maturity Level 2 (ML2) is the ASD-recommended baseline for all government entities and reflects a posture designed to address sophisticated, targeted cyber threats. It is the 2026 target for Australian federal agencies.
- ASD publishes an official Essential Eight to ISM control mapping document (https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-maturity-model-and-ism-mapping) that details the specific ISM control IDs covered by each strategy and maturity level.


## Essential Eight — ISM Chapter Mapping and ML2 Requirements

The table below maps each of the eight strategies to the primary ISM chapters they draw from, and describes what Maturity Level 2 requires your organisation to implement.

---

### 1. Application Control (Allow-listing)

**Primary ISM Chapter:** Chapter 13 — System Hardening

**ISM Domain:** Prevent execution of unapproved software on workstations and servers.

**What ML2 Requires:**
- Application control is implemented on workstations and internet-facing servers to prevent execution of unapproved executables, software libraries, scripts, and installers.
- Application control rules are validated at least annually or when significant changes occur.
- Application control is applied using a vendor-supported allow-listing technology (e.g., Microsoft AppLocker or Windows Defender Application Control).
- Events where application control blocks execution are logged and reviewed.
- Application control also covers scripts (e.g., PowerShell, VBScript) and installers, not just executables.

ML2 builds on ML1 by extending coverage beyond just executables to include scripts and installers, and by requiring regular rule validation.

---

### 2. Patch Applications

**Primary ISM Chapter:** Chapter 14 — System Management

**ISM Domain:** Patch management, vulnerability remediation, software currency.

**What ML2 Requires:**
- Applications with known security vulnerabilities (critical/high severity) are patched or mitigated within 14 days of patch release.
- Internet-facing applications with critical vulnerabilities are patched within 48 hours.
- Applications that are no longer supported by vendors (end-of-life) are removed or replaced.
- Patch status of applications is tracked centrally; automated scanning is used to identify missing patches.
- Online services are updated within defined timeframes.

ML2 extends ML1 by tightening patch timeframes and requiring a more systematic approach to tracking and reporting patch status across all applications.

---

### 3. Configure Microsoft Office Macros

**Primary ISM Chapter:** Chapter 13 — System Hardening

**ISM Domain:** Application hardening, restricting macro execution to prevent malicious code delivery.

**What ML2 Requires:**
- Microsoft Office macros are disabled for users who do not have a documented business requirement.
- Only macros from trusted locations or signed by a trusted publisher are permitted to run.
- Macro settings are enforced via Group Policy or equivalent configuration management — users cannot change macro settings themselves.
- Antivirus scanning of macros is enabled.
- Microsoft Office macro security settings are validated and reviewed regularly.

ML2 moves beyond simply advising users not to run macros, requiring enforceable policy-based controls that prevent unapproved macros from executing regardless of user action.

---

### 4. User Application Hardening

**Primary ISM Chapter:** Chapter 13 — System Hardening

**ISM Domain:** Browser, Office, and PDF reader hardening to reduce attack surface.

**What ML2 Requires:**
- Web browsers are configured to block or disable: web advertisements, Flash, Java, and other high-risk browser plugins.
- Web browsers do not process Java from the internet.
- Internet Explorer 11 is disabled or removed (no longer supported).
- PDF software is hardened — PDF viewers are configured to disable JavaScript execution.
- Microsoft Office is hardened — Object Linking and Embedding (OLE) packages are blocked.
- Hardening configurations are enforced via Group Policy or equivalent and cannot be changed by standard users.
- Application hardening baselines are validated regularly.

ML2 requires enforceable, policy-driven hardening rather than relying on default vendor settings or user behaviour.

---

### 5. Restrict Administrative Privileges

**Primary ISM Chapters:** Chapter 13 — System Hardening; Chapter 6 — Personnel Security

**ISM Domains:** Least privilege, privileged access management, personnel accountability.

**What ML2 Requires:**
- Administrative privileges are granted only where there is a documented business need; all privilege assignments are recorded.
- Privileged users use separate accounts for privileged and unprivileged activities — no browsing the internet or reading email from a privileged account.
- Privileged accounts are not used to access the internet or email.
- Privileged access to operating systems and applications is validated at least annually; unnecessary privileges are revoked.
- Use of privileged accounts is logged, and logs are reviewed regularly.
- Just-in-time and just-enough-access approaches are implemented where feasible.

ML2 requires documented review cycles and active enforcement of privilege separation, rather than ad hoc controls.

---

### 6. Patch Operating Systems

**Primary ISM Chapter:** Chapter 14 — System Management

**ISM Domain:** Patch management for operating system vulnerabilities.

**What ML2 Requires:**
- Operating systems with known critical vulnerabilities are patched within 14 days of patch release.
- Internet-facing operating systems with critical vulnerabilities are patched within 48 hours.
- End-of-life/unsupported operating systems are removed from the environment or subject to formal risk acceptance and compensating controls.
- Patch status across all operating systems is tracked centrally; automated vulnerability scanning is used.
- Operating system versions in use across the environment are inventoried and kept current.

ML2 requires tighter patch timeframes and systematic tracking compared to ML1, and draws a clear line on end-of-life operating systems.

---

### 7. Multi-Factor Authentication (MFA)

**Primary ISM Chapters:** Chapter 6 — Personnel Security; Chapter 9 — Enterprise Mobility; Chapter 19 — Networking

**ISM Domains:** Identity and access management, remote access security, mobile device management.

**What ML2 Requires:**
- MFA is required for all users accessing remote access solutions (VPN, remote desktop, cloud services).
- MFA is required for all users accessing internet-facing services that process or store sensitive data.
- MFA is required for all privileged users (administrators, system accounts) regardless of access method.
- MFA is required for all users accessing cloud service providers' management interfaces.
- MFA solutions use phishing-resistant methods where possible (e.g., FIDO2/hardware tokens, certificate-based authentication) rather than SMS OTP alone.
- MFA is enforced via policy and cannot be bypassed by users or help desk staff without a formal exception process.

ML2 extends MFA coverage beyond ML1 to include a broader set of services and begins to transition away from weaker MFA factors such as SMS.

---

### 8. Regular Backups

**Primary ISM Chapter:** Chapter 14 — System Management

**ISM Domain:** Business continuity, backup management, resilience against data loss and ransomware.

**What ML2 Requires:**
- Backups of important data, software, and configuration settings are performed and retained for at least three months.
- Backups are stored in a manner that prevents them from being encrypted or deleted in a ransomware event (i.e., offline or immutable storage; backups are not accessible from the production network).
- Backup restoration is tested at least every three months to confirm recoverability.
- Unprivileged accounts cannot access or delete backups; backup system access is restricted.
- Backups cover all critical systems and data, including system configurations.

ML2 requires tested, ransomware-resilient backups with regular restoration verification — moving well beyond simply scheduling backups to confirming they actually work.

---

## Summary: ISM Chapter Coverage of the Essential Eight

| Essential Eight Strategy | Primary ISM Chapter(s) |
|--------------------------|------------------------|
| Application control | Ch. 13 System Hardening |
| Patch applications | Ch. 14 System Management |
| Configure Microsoft Office macros | Ch. 13 System Hardening |
| User application hardening | Ch. 13 System Hardening |
| Restrict administrative privileges | Ch. 13 System Hardening, Ch. 6 Personnel Security |
| Patch operating systems | Ch. 14 System Management |
| Multi-factor authentication | Ch. 6 Personnel Security, Ch. 9 Enterprise Mobility, Ch. 19 Networking |
| Regular backups | Ch. 14 System Management |

---

## What ML2 Does NOT Cover (Broader ISM Obligations)

Achieving Essential Eight ML2 addresses controls primarily within four ISM chapters (6, 9, 13, 14, and 19). Your organisation will still need to address the remaining 17+ ISM chapters for full ISM compliance and system authorisation readiness. Key areas not covered by the Essential Eight include:

- **Chapter 1** — CISO appointment and security governance roles
- **Chapter 2** — Cyber security incident response and ASD notification obligations
- **Chapter 3** — Procurement and supply chain security
- **Chapter 4** — Security documentation (System Security Plan, risk register)
- **Chapter 5** — Physical security controls
- **Chapter 7/8** — Communications infrastructure and systems
- **Chapter 10** — Evaluated/certified product requirements
- **Chapter 11/12** — IT equipment management and media sanitisation
- **Chapter 15** — System monitoring, logging, and SIEM
- **Chapter 16** — Secure software development
- **Chapter 17** — Database hardening
- **Chapter 18** — Email security (DMARC, DKIM, SPF)
- **Chapter 20** — Cryptographic standards and key management
- **Chapter 21** — Gateway and content filtering controls
- **Chapter 22** — Data transfer controls and labelling

For system authorisation (Authorisation to Operate), your organisation must address all applicable ISM controls across all relevant chapters — not just the Essential Eight. If your systems handle OFFICIAL: Sensitive information, all NC and OS-marked controls apply. An IRAP assessment is strongly recommended for OFFICIAL: Sensitive systems and mandatory for PROTECTED systems.

---

## Recommended Next Steps

1. Conduct an Essential Eight gap assessment against ML2 criteria for each of the eight strategies.
2. Prioritise remediation based on current maturity gaps; strategies touching Chapters 13 and 14 (hardening and patch management) tend to have the most breadth.
3. Run the Essential Eight alongside a broader ISM gap analysis to identify the delta between ML2 compliance and full ISM compliance for your system's classification level.
4. Document progress in your System Security Plan (SSP) with evidence of implementation for each control.
5. Reference the official ASD Essential Eight to ISM mapping: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-maturity-model-and-ism-mapping

# Essential Eight and the ISM: ML2 Requirements and Control Mappings

## How the Essential Eight Relates to the Broader ISM

The Australian Signals Directorate (ASD) Information Security Manual (ISM) is the comprehensive cybersecurity framework that Australian government agencies and many regulated organisations must follow. It contains hundreds of controls organised across numerous chapters covering everything from governance and personnel security through to physical security, communications, cryptography, and system-specific guidance.

The Essential Eight is a prioritised subset of mitigation strategies drawn from the ISM. It was developed by ASD as a baseline set of eight strategies that, when implemented together, make it significantly harder for adversaries to compromise systems. The Essential Eight is not separate from the ISM — it is derived from and cross-referenced within the ISM. Specifically, the Essential Eight strategies correspond to controls distributed across several ISM chapters, primarily:

- Chapter 2: Guidelines for Cybersecurity Roles
- Chapter 6: Guidelines for System Hardening
- Chapter 7: Guidelines for Identity and Access Management
- Chapter 10: Guidelines for Software Development
- Chapter 11: Guidelines for Database Systems (partial overlap)
- Chapter 12: Guidelines for Email
- Chapter 13: Guidelines for Networking
- Chapter 14: Guidelines for Cryptography (partial overlap)
- Chapter 15: Guidelines for Sensitive and Classified Information (partial overlap)

The ISM provides the full control catalogue with applicability ratings (should/must), while the Essential Eight provides a pragmatic baseline prioritisation. ASD's Maturity Model for the Essential Eight defines three maturity levels (ML1, ML2, ML3) that progressively implement the controls underlying each strategy. Organisations achieving ML2 have implemented controls that are generally aligned with mitigating targeted intrusions and more capable adversaries than those addressed at ML1.

---

## The Eight Strategies: ISM Mappings and ML2 Requirements

---

### 1. Application Control

**What it is:** Preventing execution of unapproved or malicious programs, including executables, software libraries, scripts, and installers.

**Relevant ISM Chapter and Controls:**
- Primary chapter: Guidelines for System Hardening (ISM-0843, ISM-1490, ISM-1657, ISM-1658, ISM-1659, and related controls)
- Also touches Guidelines for Software Development for approved software baselines

**ML2 Requirements:**
- Application control is implemented on all workstations and internet-facing servers (not just a subset).
- Application control prevents execution of executables, software libraries (DLLs), scripts (including PowerShell, batch files, WSF, HTA, and similar), installers, compiled HTML, HTML applications, and control panel applets from the full file system — not just specific directories.
- Microsoft's recommended block rules (or equivalent) are applied to prevent known bypasses.
- Application control rulesets are validated at least annually or when significant changes occur.
- Allowed and blocked execution events are logged.
- Application control is implemented using a rules-based approach (e.g., publisher rules, hash rules, path rules ordered by preference of publisher over hash over path).

---

### 2. Patch Applications

**What it is:** Applying security patches and updates to applications to close known vulnerabilities.

**Relevant ISM Chapter and Controls:**
- Primary chapter: Guidelines for System Hardening (ISM-1690, ISM-1691, ISM-1692, ISM-1695, and related patch management controls)
- Also touches Guidelines for Software Development and Guidelines for Procurement

**ML2 Requirements:**
- A vulnerability scanner is used at least fortnightly to identify missing patches or updates for applications.
- Patches, updates, or vendor mitigations for security vulnerabilities in internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists.
- Patches, updates, or vendor mitigations for security vulnerabilities in office productivity suites, web browsers, browser extensions, email clients, PDF viewers, and security products are applied within two weeks of release, or within 48 hours if an exploit exists.
- Patches for other applications are applied within one month of release.
- Applications that are no longer supported by vendors (end-of-life) are removed or replaced.
- An automated mechanism is used to confirm and record patch application.

---

### 3. Configure Microsoft Office Macro Settings

**What it is:** Restricting or blocking Microsoft Office macros to prevent malicious macro-based malware from executing.

**Relevant ISM Chapter and Controls:**
- Primary chapter: Guidelines for System Hardening (ISM-1672, ISM-1673, ISM-1674, ISM-1675, ISM-1676, and related macro controls)
- Also touches email security guidance

**ML2 Requirements:**
- Only macros that are digitally signed by trusted publishers, or are part of a managed environment where macros are controlled, are permitted to run.
- Macros in files originating from the internet are blocked.
- Macro antivirus scanning is enabled (where supported).
- Macro security settings are centrally managed and users cannot change them.
- Macros are blocked from making Win32 API calls (where the capability exists, e.g., via Attack Surface Reduction rules in Microsoft Defender).
- Logging of blocked macro execution events is implemented.

---

### 4. User Application Hardening

**What it is:** Hardening user-facing applications — particularly web browsers, PDF readers, and Microsoft Office — to reduce the attack surface.

**Relevant ISM Chapter and Controls:**
- Primary chapter: Guidelines for System Hardening (ISM-1486, ISM-1485, ISM-1679, ISM-1680, ISM-1681, ISM-1682, and related controls)
- Also touches Guidelines for Networking (web content filtering)

**ML2 Requirements:**
- Web browsers do not process Java from the internet (Java disabled or removed from browsers).
- Web browsers do not process web advertisements from the internet (ad blocking or content filtering applied).
- Internet Explorer 11 is disabled or removed (where applicable, given its end-of-life status).
- Web browsers are hardened using vendor or ASD hardening guides.
- PDF viewers are hardened using vendor or ASD hardening guides.
- Microsoft Office is hardened (e.g., OLE package activation blocked, DDE disabled where applicable).
- .NET Framework 3.5 (which includes .NET 2.0 and 3.0) is disabled where not required.
- Windows Script Host (WSH) is disabled where not required.
- PowerShell is configured to use Constrained Language Mode where possible.
- Hardening configurations are centrally managed.

---

### 5. Restrict Administrative Privileges

**What it is:** Limiting the number of users with administrative privileges and tightly controlling how those accounts are used.

**Relevant ISM Chapter and Controls:**
- Primary chapter: Guidelines for Identity and Access Management (ISM-1507, ISM-1508, ISM-1509, ISM-1513, ISM-1524, ISM-1549, and related privileged access controls)
- Also touches Guidelines for Cybersecurity Roles (defining roles and responsibilities for privileged users)

**ML2 Requirements:**
- Privileged access to systems is validated when first requested and revalidated at least annually.
- Privileged users are assigned a separate privileged account that is used only for privileged tasks; they use a separate unprivileged account for standard tasks and email/web browsing.
- Privileged accounts (excluding privileged service accounts) are prevented from accessing the internet, email, and web services.
- Privileged accounts are not permitted to create accounts or assign privileges to accounts beyond what is required for their administrative role.
- Requests for privileged access are documented and approved.
- Just-in-time administration is implemented where feasible (i.e., privileges are granted for specific tasks and then removed).
- The number of privileged accounts is minimised.
- Privileged account activity is logged and protected from tampering.

---

### 6. Patch Operating Systems

**What it is:** Applying security patches and updates to operating systems to close known vulnerabilities.

**Relevant ISM Chapter and Controls:**
- Primary chapter: Guidelines for System Hardening (ISM-1693, ISM-1694, ISM-1696, ISM-1697, and related OS patch controls)
- Also touches Guidelines for Procurement (use of supported operating systems)

**ML2 Requirements:**
- A vulnerability scanner is used at least fortnightly to identify missing patches or updates for operating systems.
- Patches, updates, or vendor mitigations for security vulnerabilities in internet-facing servers and network devices are applied within two weeks of release, or within 48 hours if an exploit exists.
- Patches, updates, or vendor mitigations for security vulnerabilities in workstations, non-internet-facing servers, and network devices are applied within one month of release, or within 48 hours if an exploit exists.
- Operating systems that are no longer supported by vendors (end-of-life) are removed or replaced.
- Only the latest or previous release of an operating system (where supported) is used.
- An automated mechanism is used to confirm and record patch application.

---

### 7. Multi-Factor Authentication (MFA)

**What it is:** Requiring users to authenticate using more than one factor, to reduce the risk of credential-based compromise.

**Relevant ISM Chapter and Controls:**
- Primary chapter: Guidelines for Identity and Access Management (ISM-1173, ISM-1504, ISM-1505, ISM-1506, ISM-1679, and related MFA controls)
- Also touches Guidelines for Networking (remote access and VPN authentication) and Guidelines for Cryptography (for token-based authentication)

**ML2 Requirements:**
- MFA is used for all users accessing internet-facing services (e.g., remote access solutions, cloud services, webmail).
- MFA is used for all privileged users accessing systems and applications.
- MFA is used when users perform privileged actions or access important data repositories (e.g., databases, code repositories).
- MFA that is phishing-resistant (i.e., not SMS or voice call based) is strongly preferred; at ML2, phishing-resistant MFA is required for at least internet-facing services and privileged accounts.
- MFA event logs are retained.
- Failed MFA attempts are alerted on.

Note: The ASD Essential Eight Maturity Model (updated versions from 2023 onwards) specifies that from ML2, MFA must be phishing-resistant for internet-facing services and privileged access — excluding weaker forms such as SMS OTP.

---

### 8. Regular Backups

**What it is:** Backing up important data, software, and configuration settings regularly and testing restoration to ensure availability and recovery capability.

**Relevant ISM Chapter and Controls:**
- Primary chapter: Guidelines for Data Transfers and Content Filtering / Guidelines for System Management (ISM-1511, ISM-1512, ISM-1515, ISM-1516, ISM-0519, and related backup controls)
- Also touches Guidelines for Sensitive and Classified Information and Guidelines for Physical Security (offsite backup storage)

**ML2 Requirements:**
- Backups of important data, software, and configuration settings are performed and retained for at least three months.
- Backups are synchronised to enable restoration to a common point in time.
- Backups are tested at least once when initially implemented and then at least annually (full restoration test).
- Unprivileged accounts cannot access backups belonging to other accounts.
- Unprivileged accounts cannot delete or modify backups.
- Privileged accounts (other than backup administrator accounts) are prevented from accessing, modifying, or deleting backups.
- Backups are stored offline or in a manner that prevents them from being encrypted or deleted by ransomware (e.g., immutable storage, air-gapped systems, or sufficiently isolated cloud backup repositories).

---

## Summary: ISM Chapter Mapping Table

| Essential Eight Strategy         | Primary ISM Chapter(s)                                   |
|----------------------------------|----------------------------------------------------------|
| Application Control              | Guidelines for System Hardening                          |
| Patch Applications               | Guidelines for System Hardening                          |
| Configure Office Macro Settings  | Guidelines for System Hardening                          |
| User Application Hardening       | Guidelines for System Hardening; Guidelines for Networking|
| Restrict Administrative Privileges | Guidelines for Identity and Access Management; Guidelines for Cybersecurity Roles |
| Patch Operating Systems          | Guidelines for System Hardening                          |
| Multi-Factor Authentication      | Guidelines for Identity and Access Management; Guidelines for Networking |
| Regular Backups                  | Guidelines for System Management / Data Transfers        |

---

## Practical Considerations for Achieving ML2

Reaching ML2 by the end of the financial year requires a structured implementation programme. The strategies that typically require the most lead time are:

1. **Application Control** — Deploying and tuning rules across all workstations and servers without breaking legitimate applications takes time and testing.
2. **Restrict Administrative Privileges** — Restructuring privileged access patterns and implementing just-in-time administration often requires significant change management.
3. **Multi-Factor Authentication (phishing-resistant)** — Hardware key rollout or integration of FIDO2/certificate-based authentication across all internet-facing systems can be technically complex.

Patching and backup controls are generally easier to evidence if existing tooling is already in place but may require policy uplift and logging improvements.

Organisations should consult the current ASD Essential Eight Maturity Model document (available on the Australian Cyber Security Centre website) and the ISM (updated monthly) for the precise, current control identifiers, as both documents are living publications subject to revision.

# ISM Compliance for Private Sector Cloud Providers Serving Australian Federal Government

## Overview

Congratulations on winning the contract. As a private sector company providing cloud services to an Australian federal government agency, you are now part of the government's supply chain and are subject to the Australian Information Security Manual (ISM), published by the Australian Signals Directorate (ASD). This document addresses your three questions: your obligations, the most critical controls for a cloud environment, and the IRAP assessment requirement.

---

## 1. Your Obligations as a Cloud Service Provider in the Government Supply Chain

### The ISM Applies to You

The ISM is not limited to government entities themselves. Chapter 3 (Procurement & Outsourcing) explicitly requires government agencies to ensure their outsourced service providers and cloud vendors implement ISM-aligned security controls. When you sign a contract requiring ISM compliance, you are contractually and practically subject to the same obligations as the agency itself for the systems and data in scope.

Your obligations flow from two directions:

- **Contractual**: The government agency's contract will specify ISM compliance requirements, classification level of information you will handle, and likely mandate a System Security Plan (SSP) and IRAP assessment as deliverables.
- **Framework-based**: The ISM itself (Chapter 3) requires agencies to hold vendors to equivalent security standards, meaning you must implement controls at the appropriate classification level.

### Determine the Classification Level First

Your first obligation is to confirm the classification level of the government information your cloud service will store, process, or transmit. This determines which controls apply:

- **OFFICIAL: Sensitive (OS)** — the most common level for federal agency systems; requires NC + OS controls
- **PROTECTED** — classified information; requires NC + OS + P controls; most stringent common level for cloud services
- **SECRET / TOP SECRET** — rare for private sector cloud; requires additional accreditation

If the contract does not state the classification explicitly, default to OFFICIAL: Sensitive and confirm with the agency. If any PROTECTED information is in scope, the full PROTECTED control set applies.

### Core Obligations Summary

| Obligation | ISM Reference | What You Must Do |
|-----------|--------------|-----------------|
| Appoint a CISO or equivalent security lead | Ch. 1 | Designate a named individual with authority over security for the service |
| Produce a System Security Plan (SSP) | Ch. 4 | Document system boundary, classification, controls implemented, and risk register |
| Implement applicable controls | All chapters | Implement NC + OS controls (and P controls if handling PROTECTED data) |
| Undergo IRAP assessment | Ch. 3, IRAP framework | Independent review before the system is authorised to operate (see Section 3 below) |
| Report incidents to ASD | Ch. 2 | Notify the agency (and ASD for significant incidents) within required timeframes |
| Maintain ongoing compliance | Ch. 14, 15 | Patch management, continuous monitoring, re-assessment every 24 months |
| Manage sub-contractors | Ch. 3 | If you sub-contract any components, those sub-contractors must meet equivalent requirements |

---

## 2. Most Critical Controls for Your Cloud Environment

For a cloud service provider handling government information, the following control domains are the highest priority. These are drawn from the ISM's 22 guideline chapters, with emphasis on controls that address the specific risk profile of cloud environments.

### Priority 1 — Identity, Access, and Privileged Access Management

Cloud environments expose management planes that, if compromised, grant access to all hosted data and infrastructure. The ISM is explicit about this risk.

**Key controls (Chapters 6, 13):**
- Multi-factor authentication (MFA) for all administrative access, remote access, and any access to government data
- No standing administrative privileges — use just-in-time (JIT) or break-glass models
- Separate administrative accounts from user accounts
- Regular access reviews; prompt revocation on role change or termination
- These map directly to the Essential Eight: "Restrict administrative privileges" and "Multi-factor authentication"

### Priority 2 — System Hardening (Chapter 13)

Every compute instance, container, and managed service component must be hardened before deployment.

**Key controls:**
- Remove or disable all unnecessary services, ports, and protocols on every VM or container image
- Implement application allow-listing where technically feasible
- Enforce Secure Boot and firmware integrity controls
- Disable default/vendor accounts
- Harden cloud management consoles (restrict API access, enforce MFA on cloud console logins)
- For OS patches: critical patches within 48 hours for internet-facing systems, 14 days for internal

### Priority 3 — Cryptography (Chapter 20)

All government data in transit and at rest must be protected with ASD-approved algorithms.

**Key controls:**
- Data at rest: AES-256 encryption (required for PROTECTED; strongly recommended for OS)
- Data in transit: TLS 1.2 minimum; TLS 1.3 preferred. SSL and TLS 1.0/1.1 must be disabled
- SSH: SSH2 only; prefer ED25519 or RSA-4096
- Key management: documented procedures for key generation, storage, rotation, and destruction
- Use ASD-approved or FIPS 140-2/3 validated cryptographic modules, especially for PROTECTED

### Priority 4 — System Monitoring and Logging (Chapter 15)

Government contracts will require evidence of comprehensive, tamper-evident logging.

**Key controls:**
- Centralised logging (SIEM or equivalent) covering all system and access events
- Log all privileged access, configuration changes, authentication events, and data access
- Minimum retention: 18 months for OFFICIAL: Sensitive and PROTECTED systems
- Logs must be stored separately from the monitored system (cannot be modified by a compromised host)
- Alerting on anomalous events with documented investigation procedures

### Priority 5 — Patch Management (Chapter 14)

**Key controls (aligned to ISM patch SLAs):**

| Patch Criticality | Internet-Facing | Internal Systems |
|------------------|-----------------|-----------------|
| Critical (CVSS 9–10) | 48 hours | 14 days |
| High (CVSS 7–8.9) | 14 days | 14 days |
| Medium (CVSS 4–6.9) | 30 days | 30 days |
| Low | Next maintenance window | Next maintenance window |

This maps to the Essential Eight strategies "Patch applications" and "Patch operating systems."

### Priority 6 — Network Segmentation (Chapter 19)

**Key controls:**
- Segment government workloads from other tenants and from your internal corporate network
- Documented, reviewed firewall rule sets (no broad allow rules)
- Restrict outbound internet access from workloads handling government data
- Use private endpoints where possible; avoid exposing management interfaces to the public internet
- DNSSEC where applicable

### Priority 7 — Security Documentation (Chapter 4)

The government agency's Authorising Official will require documentary evidence before issuing an Authorisation to Operate (ATO). You must produce and maintain:

- **System Security Plan (SSP)** — the primary document. Must cover system boundary, classification, all implemented controls, exclusions with justifications, and the risk register
- **Security Risk Assessment** — formal risk identification, analysis, and treatment
- **Incident Response Plan** — tested procedures for detecting, responding to, and reporting security incidents
- **Change Management Plan** — approval process for all changes to the cloud environment
- **Continuous Monitoring Plan** — how you will maintain and evidence ongoing compliance

### Priority 8 — Incident Response and ASD Notification (Chapter 2)

**Key obligations:**
- Define what constitutes a security incident for your cloud service
- Document and test response procedures
- For OFFICIAL: Sensitive and above: you must notify the agency immediately on discovery of a significant incident; the agency is then responsible for ASD notification
- Preserve forensic evidence; conduct post-incident reviews

### Essential Eight — Minimum Baseline

The ASD recommends all government-connected systems achieve Essential Eight Maturity Level 2 (ML2) as the 2026 baseline. As a cloud provider, you should target ML2 across all eight strategies:

1. Application control (allow-listing)
2. Patch applications
3. Configure Microsoft Office macros (if Office is in scope)
4. User application hardening
5. Restrict administrative privileges
6. Patch operating systems
7. Multi-factor authentication
8. Regular backups (3-2-1 rule; tested; offline/offsite copy)

Full Essential Eight to ISM control mapping: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-maturity-model-and-ism-mapping

---

## 3. Do You Need an IRAP Assessment Even Though You Are Not a Government Entity?

**Yes. In practice, an IRAP assessment will almost certainly be required.**

Here is the precise picture:

### The ISM Position

The ISM sets the following requirements for IRAP assessment:

- **Mandatory** for systems handling PROTECTED and above
- **Strongly recommended** for systems handling OFFICIAL: Sensitive
- **Government policy** for any system used to deliver government services

The obligation attaches to the **system**, not the entity operating it. Because your cloud service stores, processes, or transmits Australian government information, the system must be assessed — regardless of whether you are a private company.

### What the Government Agency Will Require

The government agency cannot issue an Authorisation to Operate (ATO) for your cloud service without an IRAP assessment report to inform that decision. In practice, the contract will either:

- Require you to commission and fund an IRAP assessment of your service, or
- Specify that the agency will conduct the IRAP assessment but you must provide full access, artefacts, and cooperation

Either way, you cannot avoid IRAP. If the contract does not spell this out, raise it immediately with the agency — an ATO cannot be issued without it.

### What an IRAP Assessment Involves

An IRAP (Infosec Registered Assessors Program) assessment is an independent review by an ASD-certified assessor. The assessor must be:
- Listed on the ASD IRAP Assessors Register: https://www.cyber.gov.au/resources-business-and-government/assessment-and-evaluation-programs/irap/irap-assessors
- Independent of your organisation (cannot be your own staff or a related party)

**Artefacts you must prepare:**
- Current System Security Plan (SSP)
- Network architecture diagrams
- Asset register (hardware and software)
- Risk register with current risk ratings
- Full policy suite (all security policies referenced in the SSP)
- Evidence of implemented controls (configuration screenshots, logs, test results)
- Patch management reports
- Incident register (last 12 months)
- Plan of Action and Milestones (POA&M) for any known gaps

**Assessment cycle:**
- Initial assessment before the system is authorised to operate
- Re-assessment every 24 months minimum
- Re-assessment also required after significant changes (major architecture changes, new classification level, major new functionality)

### Practical Recommendation: Start IRAP Preparation Now

IRAP assessments typically take 8–16 weeks from engagement to final report, depending on system complexity. The government agency will need the IRAP Assessment Report before it can sign an ATO. Your steps should be:

1. **Confirm the classification level** with the agency (OFFICIAL: Sensitive vs PROTECTED drives control selection significantly)
2. **Define the system boundary** — scope only what is necessary for the government service
3. **Draft the SSP** — this is the centrepiece of the assessment
4. **Implement and evidence controls** across the priority domains above
5. **Engage an IRAP assessor** from the ASD register early — assessors are in demand
6. **Remediate findings** from the assessment via a POA&M
7. **Support the agency's ATO decision** with the completed IRAP report

---

## Summary

As a private sector cloud provider delivering services under an ISM-compliance contract with an Australian federal government agency, your obligations are substantive and non-negotiable. The ISM framework applies to your system by virtue of the government information it handles. You must implement controls at the appropriate classification level (at minimum NC + OS, and NC + OS + P if handling PROTECTED data), produce a full System Security Plan, and undergo an IRAP assessment by an ASD-certified independent assessor before the agency can authorise your service to operate. The most critical technical controls for your cloud environment are privileged access management with MFA, system hardening, ASD-approved cryptography, comprehensive logging with 18-month retention, disciplined patch management, and network segmentation. Essential Eight Maturity Level 2 should be your minimum target across all eight strategies. Begin IRAP preparation immediately, as lead times are significant and the agency's ATO — and your contract deliverables — depend on it.

---

**References**
- ISM March 2026: https://www.cyber.gov.au/sites/default/files/2026-03/Information%20security%20manual%20(March%202026).pdf
- IRAP Assessors Register: https://www.cyber.gov.au/resources-business-and-government/assessment-and-evaluation-programs/irap/irap-assessors
- Essential Eight: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight
- Essential Eight to ISM Mapping: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-maturity-model-and-ism-mapping

## ISM Compliance Obligations for a Private Sector Cloud Service Provider Contracting with an Australian Federal Government Agency

### Overview

The Australian Government Information Security Manual (ISM), published and maintained by the Australian Signals Directorate (ASD), establishes the cybersecurity framework that Australian government agencies must apply when managing their information and systems. When a private sector company wins a contract to deliver cloud services to a federal government agency, the ISM's requirements flow down through that contractual relationship. You are not directly subject to the ISM as a non-government entity, but your customer — the agency — is, and it cannot outsource its compliance obligations. This means the agency will contractually require you to meet ISM controls as a condition of providing services.

---

### 1. Your Legal and Contractual Obligations

**The ISM applies indirectly but binding-ly through contract**

The agency is bound by the ISM and by the Protective Security Policy Framework (PSPF). Neither framework has direct legislative force over private companies, but the agency cannot legally procure services that place its information at unacceptable risk. Consequently, your contract will almost certainly contain clauses that:

- Require you to implement and maintain specific ISM controls for the systems and services in scope.
- Require you to support or undergo an Information Security Registered Assessors Program (IRAP) assessment.
- Require you to operate under a System Security Plan (SSP) reviewed and approved by the agency's Chief Information Security Officer (CISO) or equivalent.
- Require breach notification within timeframes aligned with ASD guidance (often 24–72 hours for significant cyber incidents).
- Require annual attestation or evidence of continued compliance.
- Require compliance with the PSPF for any handling of classified information (if applicable), including PROTECTED or higher data.

**Classification of information matters**

The data classification of the information you will process or store determines the intensity of controls required:

- OFFICIAL: Baseline controls; most commercial cloud arrangements sit here.
- OFFICIAL: Sensitive: Additional controls, restricted access, elevated data handling requirements.
- PROTECTED: Significantly elevated controls; requires IRAP-assessed cloud services; generally must use services listed on the ASD Certified Cloud Services List (CCSL) or its successor, the Cloud Services Certification Program (CSCP).
- SECRET / TOP SECRET: Rarely applicable to commercial cloud; requires highly specialised government-approved solutions.

---

### 2. Most Critical ISM Controls for a Cloud Environment

The ISM is published as a living document and contains hundreds of controls across many domains. For a cloud services provider, the following control families are most critical and most scrutinised during any assessment or audit:

**a. Identity and Access Management (IAM)**

- Multi-factor authentication (MFA) is mandatory for all privileged access and for any remote access to systems handling government data.
- Least-privilege principles must be enforced; service accounts and administrative roles must be tightly scoped and regularly reviewed.
- Privileged access workstations (PAWs) or equivalent segregation for administrative functions.
- Regular access reviews and prompt deprovisioning upon role change or departure.

**b. Data Protection and Cryptography**

- Data at rest must be encrypted using ASD-approved cryptographic algorithms (AES-256 is standard; refer to ISM cryptographic guidance).
- Data in transit must use TLS 1.2 or higher; TLS 1.3 is preferred.
- Key management must be robust: customer-managed keys or government-controlled keys are required for PROTECTED data; key storage must be segregated from the data it protects.
- For PROTECTED data, only Australian-hosted infrastructure is generally acceptable unless specific approval is obtained.

**c. Vulnerability and Patch Management**

- Critical and high-severity vulnerabilities must be patched within tight timeframes: ISM guidance typically requires critical patches within 48 hours for internet-facing systems and 2 weeks for others.
- Automated vulnerability scanning of infrastructure, containers, and application code must be in place and evidence retained.
- Software Bill of Materials (SBOM) and supply chain risk management controls are increasingly expected.

**d. System Hardening**

- Operating systems, hypervisors, container platforms, and application runtimes must be hardened against ASD's hardening guides (which align with and reference CIS Benchmarks).
- Unnecessary services, ports, and features must be disabled.
- Configuration management must ensure hardened baseline configurations are enforced and drift is detected.

**e. Network Security and Segmentation**

- Government workloads must be logically (and often physically) isolated from other tenants.
- Firewalls, security groups, and network access controls must enforce least-privilege network flows.
- Ingress and egress filtering must be in place; north-south and east-west traffic should be inspected.
- DDoS mitigation must be available for internet-exposed services.

**f. Logging, Monitoring, and Incident Response**

- Comprehensive audit logging of all privileged actions, authentication events, configuration changes, and data access is mandatory.
- Logs must be tamper-evident, retained for a minimum period (typically 7 years for some government records, with security logs often required for at least 18 months to 7 years depending on sensitivity), and protected from deletion by administrators.
- A Security Operations Centre (SOC) capability or equivalent 24x7 monitoring must be in place for PROTECTED environments.
- An incident response plan aligned with ASD's guidelines must be documented, tested, and executable; the agency must be notified of relevant incidents promptly.
- Integration with or ability to provide log feeds to the agency's SIEM may be required.

**g. Physical Security**

- Data centres hosting government data must meet physical security standards. For PROTECTED data, this typically requires data centres located in Australia that can demonstrate compliance with relevant physical security standards (e.g., AS/NZS ISO/IEC 27001 with physical security controls, or equivalent).

**h. Personnel Security**

- Staff with access to government data or systems must hold appropriate baseline security clearances or undergo background checks. For PROTECTED data, Baseline Vetting (formerly called NV1 or similar) is typically required for personnel with privileged access.
- Security awareness training must be current and documented.

**i. Backup and Recovery**

- Regular, tested backups of government data must be maintained, with recovery time objectives (RTOs) and recovery point objectives (RPOs) agreed in the contract.
- Backups must be protected from ransomware (e.g., immutable or offline copies).

**j. Essential Eight**

The ASD's Essential Eight Maturity Model is not part of the ISM per se, but the ISM references ASD mitigation strategies and the Essential Eight has become a baseline expectation in Australian government contracts. You should plan to demonstrate compliance with the Essential Eight at the maturity level required by the agency (typically Maturity Level 2 or 3 for government work):

1. Application control (whitelisting)
2. Patch applications
3. Configure Microsoft Office macro settings
4. User application hardening
5. Restrict administrative privileges
6. Patch operating systems
7. Multi-factor authentication
8. Regular backups

---

### 3. Do You Need an IRAP Assessment Even Though You Are Not a Government Entity?

**Short answer: Almost certainly yes, if the agency handles PROTECTED or higher classified information on your platform, and likely yes even for OFFICIAL: Sensitive in practice.**

**What is IRAP?**

The Information Security Registered Assessors Program (IRAP) is an ASD initiative that certifies independent cybersecurity professionals (IRAP assessors) to conduct assessments of information systems against ISM controls. An IRAP assessment produces a Security Assessment Report (SAR) that the agency uses to make its own risk-based accreditation decision.

**IRAP applies to systems, not just government entities**

A common misconception is that IRAP is only for government agencies. In reality, IRAP assessments are conducted on systems and platforms regardless of who owns or operates them. If a government agency is going to use your cloud platform to process, store, or transmit government information, the agency needs assurance that your platform meets ISM requirements. The primary mechanism for obtaining that assurance is an IRAP assessment of your platform.

**Contractual requirement**

For PROTECTED data and above: The agency will almost certainly contractually require that your platform undergo an IRAP assessment and that the resulting SAR be reviewed before the agency grants an Authority to Operate (ATO) or Authority to Connect (ATC). The agency's CISO or Chief Security Officer is ultimately responsible for authorising the use of your service, and they will need an IRAP assessment to support that decision.

For OFFICIAL: Sensitive: Practice varies. Some agencies accept lower-assurance mechanisms (e.g., self-attestation against ISM controls, ISO 27001 certification, SOC 2 Type II reports) for lower-classification workloads. However, many agencies now require or strongly prefer an IRAP assessment even for OFFICIAL: Sensitive. You should check your specific contract requirements and negotiate this early.

For OFFICIAL (unclassified): An IRAP assessment may not be strictly required, but demonstrating ISM alignment through ISO 27001, SOC 2, or an IRAP assessment will significantly strengthen your position and reduce the agency's procurement risk evaluation concerns.

**What an IRAP assessment involves**

1. Scoping: Define the system boundary — which infrastructure, services, and data flows are in scope.
2. Documentation review: The assessor reviews your System Security Plan (SSP), security policies, network diagrams, configuration documentation, and evidence of control implementation.
3. Technical testing: The assessor performs interviews, configuration reviews, and may conduct vulnerability scanning or penetration testing.
4. Report: The assessor produces a SAR that identifies compliant controls, deficiencies, and residual risks.
5. Remediation: You address findings; the agency then makes an accreditation decision.

IRAP assessors are listed on the ASD website. You must engage a certified IRAP assessor — you cannot self-assess for IRAP purposes.

**ASD Cloud Services Certification**

If your services are likely to be used by multiple government agencies, you should consider pursuing listing on the ASD Cloud Services Certification Program (CSCP), which replaced the earlier Certified Cloud Services List (CCSL). Listed services have undergone formal IRAP assessment and provide a reusable assurance artefact that agencies can rely upon rather than commissioning their own assessment.

---

### 4. Practical Steps to Take Now

1. **Identify the information classification** of the data your platform will process. This drives every other decision.

2. **Review your contract carefully** for specific ISM control requirements, IRAP obligations, data sovereignty requirements, and incident notification timelines.

3. **Conduct an internal gap assessment** against the ISM controls relevant to your classification level. The current ISM is available freely on the ASD website (cyber.gov.au) and is updated frequently — use the latest version.

4. **Implement the Essential Eight** at the maturity level required, as this is likely to be a baseline expectation.

5. **Engage an IRAP assessor early** — IRAP assessors are in demand and scoping/preparation takes time. Do not leave this until the contract is already live.

6. **Prepare your System Security Plan (SSP)** — this is the foundational document for any IRAP assessment and for the agency's accreditation decision. It should describe your system architecture, data flows, control environment, and residual risks.

7. **Ensure data sovereignty** — confirm that government data will be stored and processed in Australia, and that offshore access (including by vendors or support staff) is either prohibited or subject to specific controls.

8. **Establish incident response procedures** aligned with ASD's guidelines and your contractual notification obligations.

9. **Engage your agency contact's CISO or information security team early** — they will be your primary point of contact for accreditation and will have specific requirements based on their own risk appetite and internal policies.

---

### 5. Key References

- Australian Signals Directorate (ASD) — Information Security Manual: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism
- ASD Essential Eight Maturity Model: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight
- Protective Security Policy Framework (PSPF): https://www.protectivesecurity.gov.au
- IRAP Program information: https://www.cyber.gov.au/resources-business-and-government/assessments-and-certifications/irap
- Cloud Services Certification Program (CSCP): https://www.cyber.gov.au/resources-business-and-government/assessments-and-certifications/cloud-services-certification-programme

---

### Summary

As a private sector cloud provider contracted to serve an Australian federal government agency, your ISM obligations flow through your contract rather than directly through law, but they are binding and enforceable. The most critical controls focus on identity and access management, encryption, patch management, system hardening, network segmentation, logging and incident response, and the Essential Eight. An IRAP assessment is a practical necessity — not just a recommendation — for any system handling PROTECTED or OFFICIAL: Sensitive government data, and you should engage a certified IRAP assessor as early as possible in your program. The agency's CISO will ultimately make the accreditation decision, but they will rely on your IRAP assessment to do so.

# NIS2 Directive — Applicability Assessment for a German Electricity Distribution Company

## Executive Summary

Yes, your organisation falls squarely within the scope of the NIS2 Directive (Directive (EU) 2022/2555). You qualify as an **Essential Entity (EE)** under Annex I. This triggers the most demanding tier of NIS2 obligations, including proactive supervisory oversight and the highest penalty exposure. The analysis below explains the classification, the obligations that follow, and what this means operationally.

---

## 1. Entity Classification: Essential Entity (Annex I)

### Sector test

The NIS2 Directive identifies **energy** as an Annex I sector — the sector reserved for Essential Entities. Within energy, Annex I explicitly covers **electricity**, including:

- Electricity undertakings as defined in Article 2(57) of Directive (EU) 2019/944
- Distribution system operators (DSOs)
- Transmission system operators (TSOs)
- Electricity market participants

Your company operates **electricity distribution networks in Germany**. Distribution system operators are named directly in Annex I. You therefore satisfy the sector criterion for Essential Entity classification.

### Size test (Article 3)

NIS2 applies automatically to medium and large entities in Annex I sectors. A medium entity is defined as one with:

- **50 or more employees**, OR
- **Annual turnover / balance sheet exceeding €10 million**

Your organisation has **200 employees** and **€50 million annual turnover** — both thresholds are exceeded by a wide margin. You are unambiguously within scope on size grounds.

### Classification result

| Criterion | Requirement | Your position | Result |
|---|---|---|---|
| Sector | Annex I (Energy — Electricity DSO) | Electricity distribution in Germany | Meets criterion |
| Size | ≥50 employees OR ≥€10M turnover | 200 employees, €50M turnover | Meets criterion |
| **Classification** | | | **Essential Entity (EE)** |

### Germany-specific note

Germany transposed NIS2 via the **NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG)**, which entered into force on 18 October 2024. The German transposition maintains the Essential Entity classification for electricity DSOs and designates the **Bundesamt für Sicherheit in der Informationstechnik (BSI)** as the primary competent authority for energy sector entities, alongside the **Bundesnetzagentur (BNetzA)** for sector-specific regulatory matters. You must register with the BSI and comply with BSI-issued technical guidance.

---

## 2. Supervisory Regime — What Being an Essential Entity Means

As an EE, you are subject to **proactive (ex-ante) supervision** under Article 32. This is more demanding than the reactive (ex-post) supervision that applies to Important Entities. Specifically, competent authorities can:

- Conduct **on-site inspections** and off-site supervision without waiting for evidence of non-compliance
- Order **security audits** by an independent body
- Perform **targeted security scans**
- Request **evidence of implementation** of cybersecurity risk management measures at any time
- Issue **binding instructions** and require remediation within defined timeframes

Management body members can also face **personal liability** under German transposition law if they fail to approve and oversee cybersecurity measures as required by Article 20.

---

## 3. Article 20 — Governance Obligations

Your **management body** (Geschäftsführung / Vorstand) carries direct, non-delegable responsibilities:

1. **Approve** all cybersecurity risk management measures required under Article 21
2. **Oversee implementation** of those measures on an ongoing basis
3. **Complete regular cybersecurity training** — the management body must have sufficient knowledge to identify and assess cybersecurity risks and their impact on services
4. **Bear personal liability** if non-compliance causes harm, under the liability provisions of the German NIS2 transposition

Practical implication: cybersecurity must be a standing agenda item at board/management level, with documented evidence that the management body approved the risk management framework, reviewed incident reports, and completed training.

---

## 4. Article 21 — The 10 Cybersecurity Risk Management Measures

As an Essential Entity, you must implement all 10 measures. "Appropriate and proportionate" still applies, but the BSI expects controls at the higher end of the proportionality spectrum given the criticality of electricity distribution to public safety and the economy.

### Measure 1 — Risk Analysis and Information Security Policies

- Adopt a formal risk management methodology (e.g., ISO 27005 or BSI-Grundschutz)
- Maintain a comprehensive asset inventory of all network and information systems used in distribution operations — this includes both IT systems (SCADA interfaces, customer management, billing) and OT systems (distribution management systems, substations, remote terminal units)
- Conduct risk assessments at least annually and after significant changes to the grid or IT/OT environment
- Management body must formally approve the risk management policy

**Energy sector specificity:** Your risk assessment must address both IT and **operational technology (OT)** environments. Grid control systems, SCADA, and ICS components carry unique risk profiles distinct from standard IT assets.

### Measure 2 — Incident Handling

- Maintain a written Incident Response Plan (IRP) covering detection, containment, eradication, and recovery
- Define what constitutes a "significant incident" for your operations (see Article 23 below for reporting triggers)
- Establish clear internal escalation paths and pre-designated roles (incident commander, technical lead, legal/regulatory contact, communications officer)
- Test the IRP at least annually through tabletop exercises or live simulations
- Conduct post-incident reviews and feed findings back into the risk register

### Measure 3 — Business Continuity, Backup, and Disaster Recovery

- Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each critical system — grid management systems, customer systems, billing, and communications
- Implement automated, encrypted, and offsite backups with tested restoration procedures (test quarterly)
- Maintain DR runbooks covering infrastructure failover, including OT environment recovery
- Establish a crisis management structure with clear roles, decision authority levels, and escalation to senior management
- Test BCP/DR at least annually; management body should participate in crisis exercises

### Measure 4 — Supply Chain Security

For an electricity DSO, this is particularly significant given the complexity of the energy sector supply chain (grid equipment vendors, SCADA providers, cloud service providers, metering systems, AMI vendors):

- Maintain a register of all critical ICT and OT suppliers and service providers
- Perform security assessments before onboarding new suppliers
- Include mandatory security clauses in supplier contracts: minimum security baselines, right-to-audit, incident notification obligations, and data breach SLAs
- Apply enhanced due diligence to vendors flagged in ENISA and BSI supply chain risk assessments (Article 26 coordinated assessments)
- Assess supply chain risks as part of your annual risk assessment cycle

### Measure 5 — Secure Acquisition, Development, and Maintenance

- Apply security requirements when procuring new grid systems, SCADA components, or IT infrastructure
- Establish a vulnerability management programme with defined SLAs: critical patches within 7 days, high-severity within 30 days
- Track CVEs relevant to your OT and IT systems using threat intelligence feeds (ENISA, BSI CERT-Bund advisories)
- Maintain a coordinated vulnerability disclosure policy
- Include security acceptance criteria in vendor contracts for purchased systems

### Measure 6 — Effectiveness Assessment

- Define measurable KPIs for each Article 21 measure (e.g., patch compliance rate, training completion rate, mean time to detect incidents)
- Conduct internal audits or management reviews at least annually
- Engage independent third-party assessors or penetration testers periodically
- Report effectiveness metrics directly to the management body
- Map audit findings to the risk register and drive remediation plans

### Measure 7 — Cyber Hygiene and Training

- Mandatory annual security awareness training for all 200 employees
- Role-based training for IT administrators, OT/SCADA operators, and incident responders
- Management body training specific to Article 20 governance obligations
- Training must cover phishing, social engineering, password hygiene, incident reporting, and remote working risks
- Track completion rates; maintain records for BSI supervisory review

### Measure 8 — Cryptography and Encryption

- Define approved cryptographic standards: AES-256 for data at rest, TLS 1.2+ (preferably TLS 1.3) for data in transit, SHA-256 or better for hashing
- Implement key management lifecycle procedures (generation, storage, rotation, destruction)
- Use Hardware Security Modules (HSMs) for protecting critical cryptographic keys (particularly relevant for OT environments and grid communications)
- Encrypt sensitive data in cloud environments and on portable media
- Plan for post-quantum cryptography migration as ENISA guidance evolves

### Measure 9 — Human Resources Security, Access Control, and Asset Management

- Apply least-privilege and need-to-know principles — particularly critical for OT/SCADA access
- Implement Role-Based Access Control (RBAC) with quarterly permission reviews
- Conduct background screening for staff with privileged access to critical grid systems (subject to German employment law)
- Maintain an authoritative asset inventory covering IT hardware, software, OT components, and data assets
- Enforce a rigorous joiners/movers/leavers process: same-day revocation for departing staff, especially those with OT access
- Disable dormant accounts after 30–90 days of inactivity

### Measure 10 — MFA, Secure Communications, and Emergency Systems

- Require MFA for all remote access to IT and OT systems, privileged accounts, cloud management consoles, and email
- Apply phishing-resistant MFA (FIDO2/hardware tokens) for highest-privilege accounts, including SCADA and grid management system administrators
- Use end-to-end encrypted communications for incident coordination and sensitive internal discussions
- Maintain a documented emergency communication plan with out-of-band channels (e.g., encrypted satellite or dedicated secure voice) in case primary communications are compromised during a grid incident

---

## 5. Article 23 — Incident Reporting Obligations

If your organisation experiences a **significant incident**, you must report to the BSI (as competent authority) and the national CSIRT (**CERT-Bund**, operated by BSI) on the following timeline:

### What is a "significant incident"?

An incident is significant if it causes or is capable of causing:
- Substantial disruption to your electricity distribution service
- Financial loss to your organisation
- Material or non-material damage to other persons (including your customers and downstream entities)
- A service outage affecting a significant number of users or geographic area

For an electricity DSO, any grid outage affecting a large number of customers or lasting more than a few hours is likely to meet this threshold.

### Reporting timeline

| Stage | Deadline | Content |
|---|---|---|
| **Early warning** | Within **24 hours** of becoming aware | Was the incident (suspected to be) malicious? Could it have cross-border impact? |
| **Incident notification** | Within **72 hours** | Initial severity and impact assessment; indicators of compromise (IoCs) |
| **Final report** | Within **1 month** | Detailed incident description, threat type, root cause, applied/ongoing mitigations, cross-border impact assessment |

**Practical preparation:** Pre-draft notification templates mapped to these three stages. Designate a regulatory reporting officer who has authority to submit notifications to BSI without waiting for full management sign-off (speed is the priority at the 24-hour stage).

---

## 6. Penalty Exposure (Article 34)

As an Essential Entity, maximum penalties are:

- **€10,000,000**, or
- **2% of global annual turnover**, whichever is **higher**

For your organisation with €50M turnover: 2% = **€1,000,000**. Since €10M is higher, your maximum exposure is **€10,000,000** per infringement.

The BSI can also impose:
- Temporary suspension of services
- Prohibition of individuals performing management functions (personal liability)
- Public disclosure of non-compliance

---

## 7. Priority Actions — Where to Start

Given Essential Entity status and proactive BSI supervision, we recommend prioritising in the following order:

1. **Register with the BSI** — German transposition requires self-registration. Ensure your registration is complete and up to date.

2. **Governance first (Art. 20)** — Establish a board-level cybersecurity oversight charter. Schedule management body cybersecurity training. Document that the management body has approved the risk management framework.

3. **Risk assessment (Measure 1)** — Conduct a comprehensive IT/OT risk assessment. This underpins all other measures and is typically the first thing the BSI requests.

4. **Incident response (Measure 2 + Art. 23)** — Draft or update your IRP and establish the 24h/72h/1-month reporting workflow. A gap here has the most immediate regulatory consequence.

5. **Supply chain security (Measure 4)** — Audit your critical ICT/OT supplier register and update contracts to include NIS2 security requirements.

6. **MFA and access control (Measures 9 + 10)** — Enforce MFA across all remote access and privileged accounts, especially for OT/SCADA environments.

7. **Gap assessment across all 10 measures** — Conduct a structured gap assessment, mapping existing controls to each Article 21 measure. ISO 27001:2022 certification is strong evidence of NIS2 compliance and aligns well to the 10 measures.

---

## 8. ISO 27001 Alignment Note

If your organisation holds or is pursuing ISO 27001:2022 certification, this provides strong evidential support for NIS2 compliance. ISO 27001 Annex A controls map closely to the 10 Article 21 measures. However, ISO 27001 certification does not substitute formal NIS2 obligations — you still carry statutory reporting obligations, registration requirements, and management body accountability under NIS2 independently of any certification.

---

## Summary Table

| Topic | Answer |
|---|---|
| In scope? | Yes |
| Classification | Essential Entity (Annex I — Energy/Electricity DSO) |
| Competent authority (Germany) | BSI (primary); BNetzA (sector co-regulator) |
| CSIRT | CERT-Bund (BSI) |
| Supervision type | Proactive (ex-ante) — Art. 32 |
| Management body obligations | Approval, oversight, training, personal liability (Art. 20) |
| Risk management measures | All 10 Art. 21 measures apply |
| Incident reporting | 24h early warning / 72h notification / 1-month final report |
| Maximum penalty | €10M or 2% global turnover (whichever higher) |
| Key German law | NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) |

---

*This assessment is based on Directive (EU) 2022/2555 and the German NIS2UmsuCG transposition as of April 2026. Regulatory interpretations and BSI technical guidelines continue to evolve. We recommend seeking qualified legal counsel for formal compliance sign-off and monitoring BSI guidance publications regularly.*

# NIS2 Directive Applicability Assessment: European Energy Company (Electricity Distribution, Germany)

## Summary

Yes, your company almost certainly falls under the NIS2 Directive (EU 2022/2555). As an electricity distribution network operator in Germany with 200 employees and €50M annual turnover, you are subject to NIS2 and would most likely be classified as an **Important Entity**, with the possibility of being classified as an **Essential Entity** depending on national implementation and regulatory designation by German authorities.

---

## 1. Does NIS2 Apply to Us?

### Sector Coverage

NIS2 Annex I and Annex II explicitly cover the **energy sector**. Electricity is listed under **Annex I** (high-criticality sectors) with specific subsectors including:

- Electricity — covering electricity undertakings, distribution system operators (DSOs), transmission system operators (TSOs), electricity producers, and other relevant market participants as defined in Directive 2019/944 (the Internal Electricity Market Directive).

Operating electricity distribution networks means you are a **distribution system operator (DSO)**, which is explicitly named as a covered entity type under NIS2 Annex I.

### Size Thresholds

NIS2 uses the EU definition of enterprise size:

| Category | Employees | Annual Turnover or Balance Sheet Total |
|---|---|---|
| Medium enterprise | 50–249 | ≤ €50M turnover or ≤ €43M balance sheet |
| Large enterprise | ≥ 250 | > €50M turnover or > €43M balance sheet |

Your company (200 employees, €50M turnover) falls at the boundary. With exactly 200 employees and €50M turnover, you are likely classified as a **medium-sized enterprise**. NIS2 applies to medium and large enterprises in covered sectors — meaning you are within scope.

**Note:** Micro (< 10 employees, < €2M) and small enterprises (< 50 employees, < €10M) are generally excluded unless they meet specific criteria (e.g., they are the sole provider in a member state or a specific cross-border impact designation applies). You do not qualify for these exemptions.

---

## 2. Essential Entity vs. Important Entity Classification

NIS2 distinguishes between two tiers of regulated entities:

### Essential Entities (Annex I sectors — large enterprises)
- Must meet Annex I sector criteria AND be a large enterprise (≥250 employees or >€50M turnover AND >€43M balance sheet).
- Subject to **proactive, ex-ante supervision** by competent authorities.

### Important Entities (Annex I sectors — medium enterprises, or Annex II sectors)
- Medium enterprises in Annex I sectors (like electricity) qualify as Important Entities.
- Subject to **reactive, ex-post supervision** (authorities investigate after an incident or complaint).

### Your Classification

Given 200 employees and €50M turnover:
- You are almost certainly a **medium enterprise**, making you an **Important Entity**.
- However, **Germany's national implementation (BSIG/NIS2UmsuCG — the NIS2 Implementation Act)** and the **Bundesnetzagentur (Federal Network Agency)** may designate DSOs with significant grid responsibility as Essential Entities regardless of size, particularly if you are a key player in your region's electricity infrastructure.
- You should confirm with the **Bundesamt für Sicherheit in der Informationstechnik (BSI)** whether a specific national designation applies to you.

---

## 3. Key Obligations Under NIS2

### A. Risk Management Measures (Article 21)

You must implement appropriate and proportionate technical, operational, and organizational cybersecurity measures, including:

1. **Policies on risk analysis and information system security** — documented risk assessment and treatment processes.
2. **Incident handling** — procedures for detecting, classifying, responding to, and recovering from cybersecurity incidents.
3. **Business continuity and crisis management** — backup management, disaster recovery, and business continuity plans.
4. **Supply chain security** — assessing the cybersecurity posture of suppliers and service providers, including software and hardware vendors.
5. **Security in network and information systems acquisition, development, and maintenance** — including vulnerability handling and disclosure.
6. **Policies and procedures to assess the effectiveness of cybersecurity risk management measures** — regular testing and audits.
7. **Cybersecurity hygiene and training** — awareness programs for all staff; specific technical training for cybersecurity personnel.
8. **Cryptography and encryption** — use of encryption where appropriate.
9. **Human resources security and access control policies** — privileged access management, least-privilege principles.
10. **Multi-factor authentication (MFA) and secure communications** — for critical systems and administrative access.

### B. Incident Reporting (Article 23)

Important Entities must adhere to a structured incident notification timeline:

| Step | Timeline | Action |
|---|---|---|
| **Early warning** | Within **24 hours** of becoming aware of a significant incident | Notify the national CSIRT (in Germany: **BSI-CERT**) |
| **Incident notification** | Within **72 hours** | Provide a detailed incident notification including initial impact assessment, severity, and indicators of compromise |
| **Intermediate report** | Upon request by CSIRT/competent authority | Provide status update |
| **Final report** | Within **1 month** of the incident notification | Submit full incident report covering root cause, duration, impact, and remediation measures |

A "significant incident" is one that causes or could cause severe operational disruption, financial losses, or affect other entities. For electricity DSOs, grid disruptions affecting large numbers of customers would qualify.

### C. Governance and Management Accountability (Article 20)

- **Management bodies must approve** cybersecurity risk management measures.
- Management bodies (e.g., board of directors, executive management) are **personally liable** for ensuring compliance.
- Management must receive **regular cybersecurity training** to understand risks and governance.
- This is a critical change from NIS1 — executive personal liability is now explicit.

### D. Registration and Information Provision

- Entities must **register** with the relevant national competent authority. In Germany, this is the **BSI** (Bundesamt für Sicherheit in der Informationstechnik), likely coordinated with the **Bundesnetzagentur** for energy sector specifics.
- You must provide information about: your legal name, sector, contact details, IP ranges used, and other information as required.

### E. Use of Approved Security Products and Schemes (Article 24)

Member states and the EU may require use of specific ICT products, services, or processes certified under the **EU Cybersecurity Act** (ENISA certification schemes). Keep track of any such requirements introduced by German authorities for electricity sector OT/IT systems.

---

## 4. German National Implementation Context

Germany transposed NIS2 into national law through the **NIS2UmsuCG (NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz)**, amending the **BSI-Gesetz (BSIG)**. Key German-specific points:

- The **BSI** is the primary competent authority for cybersecurity matters.
- The **Bundesnetzagentur** has sector-specific regulatory oversight of electricity networks and coordinates with BSI.
- Germany has historically been strict in implementing EU cybersecurity directives; the amended BSIG includes detailed rules on registration, incident reporting, and penalties.
- **KRITIS** (Critical Infrastructure) regulations under German law may also apply to you — these often have overlapping but more prescriptive requirements for energy operators above certain supply thresholds (e.g., serving >500,000 people). Assess whether you also fall under the **KRITIS-DachG** (the Critical Infrastructure Protection Act), which was also updated in this regulatory cycle.

---

## 5. Enforcement and Penalties

| Entity Type | Maximum Administrative Fine |
|---|---|
| Essential Entity | €10,000,000 or 2% of global annual turnover (whichever is higher) |
| Important Entity | €7,000,000 or 1.4% of global annual turnover (whichever is higher) |

As an Important Entity, you face fines of up to **€7M or 1.4% of global annual turnover**. Given your €50M turnover, the percentage-based cap would be ~€700,000, but the absolute cap of €7M is the binding upper limit.

Additionally:
- Competent authorities can issue **binding instructions**, impose **temporary bans** on individuals in management roles, and require **public disclosure** of non-compliance.
- Personal liability of management is a key enforcement lever.

---

## 6. Recommended Immediate Actions

1. **Confirm registration requirements** with BSI and assess whether any KRITIS thresholds apply in addition to NIS2.
2. **Conduct a NIS2 gap assessment** against Article 21 requirements, mapping existing cybersecurity controls to NIS2 obligations.
3. **Establish an incident response plan** that meets the 24-hour early warning and 72-hour reporting timelines.
4. **Brief and train senior management** on their personal accountability under Article 20.
5. **Map and assess your supply chain** for cybersecurity risks, particularly OT/SCADA vendors and IT managed service providers.
6. **Implement MFA** across critical operational and IT systems if not already in place.
7. **Register with BSI** as required under the German NIS2 transposition.
8. **Review contracts** with suppliers to include appropriate cybersecurity clauses and incident notification obligations flowing upstream.

---

## Conclusion

Your company — as an electricity DSO in Germany with 200 employees and €50M turnover — is **clearly within scope of NIS2** as an **Important Entity** under Annex I (Energy sector). The compliance obligations are substantial, particularly around cybersecurity risk management, incident reporting timelines, and management accountability. Given Germany's regulatory environment and the sector-specific overlay of KRITIS regulations, early and proactive engagement with BSI and your sector regulator is strongly advised.

# NIS2 Directive Compliance Assessment
## B2B Cloud-Based HR SaaS — 75 Employees, €15M Annual Revenue

---

## Part 1: Are You Directly Subject to NIS2?

**Short answer: Yes — you are very likely subject to NIS2 as an Important Entity.**

### Size Threshold Analysis (Article 3)

NIS2 applies to **medium-sized and larger entities** in scope sectors. The thresholds are:
- **≥ 50 employees**, OR
- **≥ €10 million annual turnover**

Your company meets **both** criteria (75 employees and €15M revenue), so the size threshold is satisfied.

### Sector Classification Analysis

The critical question is which NIS2 sector you fall into. As a B2B cloud-based HR software provider, there are two plausible classifications:

**Most likely: Annex II — Digital Providers**
NIS2 Annex II covers "digital providers," which includes providers of online marketplaces, online search engines, and cloud computing services. B2B SaaS providers delivering cloud-based services to business customers are generally captured under this category. You provide cloud-hosted software on a subscription/service basis to business customers — this squarely fits the "digital provider" framing under Annex II.

**Possible: Annex I — ICT Service Management (B2B)**
If your HR software integrates deeply into your customers' IT infrastructure or you manage ICT services on behalf of clients, you may fall under Annex I (ICT service management, B2B), which would classify you as an **Essential Entity** with more stringent supervisory obligations. This is the less common classification for a standalone HR SaaS, but worth reviewing based on the nature of your service delivery.

**Conclusion for Planning Purposes:**
Treat yourself as an **Important Entity (IE)** under Annex II — Digital Providers. This is the most conservative and likely correct classification for a B2B HR SaaS at your size. You should verify this with a qualified legal advisor in the EU Member State(s) where you are established, as national transposition laws (effective from 17 October 2024) may refine the classification.

### Why Your Customer's Request Makes Sense

Even if there were ambiguity about direct applicability, your customers who *are* NIS2 entities have obligations under **Article 21(3) and Article 26** to address supply chain security — which means they must flow security requirements down to suppliers like you. Your customer is effectively telling you that your security posture is part of their own NIS2 compliance.

### Supervisory Regime as an Important Entity

As an IE:
- Supervision is **reactive (ex-post)** under Article 33 — you will not face routine proactive audits, but competent authorities can investigate upon evidence of non-compliance or following a significant incident.
- **Maximum penalty exposure: €7,000,000 or 1.4% of global annual turnover** (whichever is higher). At €15M revenue, the turnover-based cap is approximately **€210,000**, but the absolute cap of €7M would apply if the percentage exceeds it — meaning real penalty exposure is up to **€7,000,000**.

---

## Part 2: Article 21 — What You Need to Do

Article 21 requires you to implement **appropriate and proportionate technical, operational, and organisational measures** across 10 defined areas. The proportionality principle means controls must be scaled to your size, risk exposure, and the cost of implementation — you are not expected to implement enterprise-scale controls identical to a major bank, but you must demonstrably address all 10 measures.

Below is a practical breakdown of what each measure requires for a B2B HR SaaS at your scale.

---

### Measure 1 — Risk Analysis & Information Security Policies

**What you must do:**
- Adopt a formal risk management methodology. ISO 27005 or NIST RMF are well-suited; a simplified approach acceptable for a company of your size could follow the ISO 27001 risk assessment framework.
- Build and maintain an **asset inventory** covering all systems, cloud infrastructure, databases, and data assets used to deliver your HR software.
- Define **risk acceptance criteria** aligned to the sensitivity of HR data (which is likely to include personal data, employment records, salary information, and potentially special category data under GDPR).
- Conduct risk assessments **at least annually** and after significant changes (new product features, infrastructure migrations, major incidents).
- Have the **management body formally approve** your information security risk management policy (this links to Art. 20 governance obligations).

**Priority:** High. This is the foundation of all other measures. Start here.

---

### Measure 2 — Incident Handling

**What you must do:**
- Produce a written **Incident Response Plan (IRP)** covering detection, analysis, containment, eradication, and recovery for all plausible incident scenarios (ransomware, data breach, DDoS, insider threat, cloud provider outage).
- Define internal thresholds for what constitutes a **"significant incident"** under NIS2 Art. 23(3): substantial service disruption, financial loss to your entity, or material damage to your B2B customers.
- Establish documented **24h/72h/1-month reporting workflows** with pre-drafted templates for notifying the national CSIRT or competent authority in your Member State:
  - **24 hours:** Early warning — was the incident (suspected to be) malicious? Could it have cross-border impact?
  - **72 hours:** Incident notification — initial severity assessment, impact scope, indicators of compromise.
  - **1 month:** Final report — detailed description, threat type, root cause, mitigations applied/ongoing, cross-border impact.
- Conduct post-incident reviews and feed lessons learned back into your risk register.
- Test the IRP **at least annually** via tabletop exercises.

**Priority:** High. HR software holds sensitive employee data; a breach affecting multiple B2B customers could trigger significant incident thresholds rapidly.

---

### Measure 3 — Business Continuity, Backup & Disaster Recovery

**What you must do:**
- Define **Recovery Time Objectives (RTO)** and **Recovery Point Objectives (RPO)** for your core HR platform. For SaaS, customers will expect short RTOs (hours, not days).
- Implement **automated, encrypted, offsite backups** and test restoration **at least quarterly** — not just backup creation, but verified restoration.
- Maintain documented **DR runbooks** and infrastructure failover playbooks for your cloud environment.
- Establish a **crisis management structure** with clear roles, decision authorities, and escalation paths for executives and the management body.
- Test BCP/DR **at least annually**, involving senior leadership in crisis exercises.

**Priority:** High. SaaS service availability is a contractual and regulatory obligation. This measure directly protects against the "substantial disruption" threshold for significant incidents.

---

### Measure 4 — Supply Chain Security

**What you must do:**
- Maintain a **register of critical ICT suppliers** (cloud infrastructure providers, SaaS sub-processors, development tool vendors, security vendors).
- Perform **pre-onboarding security assessments** — at minimum, request security questionnaires, review certifications (ISO 27001, SOC 2), and assess breach history for critical vendors.
- Include **security requirements in contracts**: right-to-audit clauses, incident notification SLAs (require vendors to notify you within 24-48 hours of incidents affecting your data or systems), and minimum security baselines.
- Incorporate **supply chain risk into your annual risk assessment**.
- Monitor ENISA and national authority advisories on high-risk ICT vendors.

**Note:** You are also your customers' supply chain. Your own NIS2 compliance (including the policies and certifications you can demonstrate) is what your customer is asking about. A SOC 2 Type II report or ISO 27001 certificate significantly simplifies evidencing your security posture to customers and competent authorities.

**Priority:** Medium-High. Critical for maintaining customer contracts and demonstrating NIS2 readiness to your enterprise customers.

---

### Measure 5 — Secure Acquisition, Development & Maintenance

**What you must do:**
- Apply a **Secure SDLC**: threat modelling for new features, mandatory code reviews, SAST/DAST tooling integrated into your CI/CD pipeline, and at least annual penetration testing of your application and infrastructure.
- Establish a **vulnerability management programme** with defined patching SLAs by severity:
  - Critical (CVSS ≥ 9.0): patch or mitigate within 7 days
  - High (CVSS 7.0–8.9): within 30 days
  - Medium: within 90 days
- Publish a **coordinated vulnerability disclosure (CVD) policy** — a simple security.txt file and disclosure process aligned to ENISA CVD guidelines.
- Track relevant CVEs against your technology stack using threat intelligence or vulnerability scanning tools.

**Priority:** Medium-High. As a software provider, this measure is core to what you deliver and directly impacts your customers' security.

---

### Measure 6 — Effectiveness Assessment

**What you must do:**
- Define **KPIs/KRIs** for each Art. 21 measure. Examples:
  - Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) for security incidents
  - Patch compliance rate (% of critical/high vulnerabilities patched within SLA)
  - Security training completion rate
  - Backup restoration test success rate
- Conduct **internal audits or management reviews** at least annually covering all 10 measures.
- Engage **independent third-party assessors** for penetration testing and, ideally, NIS2 gap assessments.
- Report effectiveness metrics to the **management body** at regular intervals (quarterly dashboards are good practice).
- Map audit findings to your risk register and track remediation to closure.

**Priority:** Medium. This is the control system for all other measures — without it, you cannot demonstrate compliance to a regulator.

---

### Measure 7 — Cyber Hygiene & Training

**What you must do:**
- Deploy **mandatory security awareness training** for all 75 employees at least annually, covering: phishing recognition, social engineering, password hygiene, incident reporting procedures, and remote/BYOD working security.
- Conduct **role-based training** for IT/infrastructure staff, developers, and incident responders at appropriate depth.
- Ensure the **management body (board/executives) completes cybersecurity training** specifically addressing their Art. 20 governance obligations — NIS2 imposes personal liability on management, so they must understand what they are approving.
- Track training completion rates and address gaps ahead of any audit cycle.

**Priority:** Medium. This is relatively low-cost to implement and highly visible to regulators and auditors. With 75 staff, annual training is straightforward to operationalise.

---

### Measure 8 — Cryptography & Encryption

**What you must do:**
- Define a **Cryptography Policy** specifying approved algorithms:
  - Data at rest: AES-256
  - Data in transit: TLS 1.2 minimum (TLS 1.3 preferred)
  - Hashing: SHA-256 or SHA-384
- Establish a **key management lifecycle**: generation, secure storage (use your cloud provider's key management service — AWS KMS, Azure Key Vault, GCP Cloud KMS), rotation schedules, and secure destruction.
- Require encryption of all **sensitive HR data** (employee records, salary data, authentication credentials) in cloud storage and in databases.
- Encrypt **portable media** and any exports of HR data.
- Document exceptions with compensating controls where encryption is technically infeasible.
- Review cryptographic standards annually.

**Priority:** Medium. As a cloud-native SaaS, much of this may already be handled by your cloud provider — but you need the documented policy and explicit controls in place, and you need to ensure end-to-end encryption coverage (not just transport layer).

---

### Measure 9 — HR Security, Access Control & Asset Management

**What you must do:**
- Enforce **least-privilege and need-to-know** for all system access — developers should not have production access unless required; customer data access should be logged and restricted.
- Implement **Role-Based Access Control (RBAC)** and conduct **quarterly access reviews** to remove unnecessary permissions.
- Conduct **background screening** for roles with access to production systems or sensitive customer data (subject to applicable employment law in your jurisdiction).
- Maintain an authoritative **asset inventory** covering hardware, software, SaaS tools, cloud resources, and data assets.
- Enforce a rigorous **joiners/movers/leavers process** — same-day access revocation for departing employees is a firm expectation under NIS2.
- Disable **dormant accounts** after 30–90 days of inactivity.
- Apply **privileged access management (PAM)** controls for administrative accounts — just-in-time access, separate admin accounts, audit logging.

**Priority:** High. HR software companies often hold employee data from tens or hundreds of customer organisations — a compromised insider account or stale privileged access is a high-impact risk.

---

### Measure 10 — MFA, Secure Communications & Emergency Systems

**What you must do:**
- Require **MFA for all remote access**, privileged accounts, cloud management consoles, code repositories, and customer-facing admin interfaces.
- Apply **phishing-resistant MFA** (FIDO2/hardware security keys) for the highest-privilege accounts (production infrastructure, identity providers, billing systems).
- Enforce MFA for **email access, VPN, and all SaaS platforms** holding sensitive data (e.g., your CRM, HR tools, financial systems).
- Use **end-to-end encrypted channels** for sensitive internal communications — particularly during incident coordination (Signal, encrypted Slack channels, or equivalent).
- Maintain a documented **emergency communication plan** with out-of-band channels (pre-agreed mobile contacts, backup communication tools) for use when primary systems are compromised.

**Priority:** High. MFA is one of the most effective single controls against credential-based attacks, and NIS2 explicitly names it. This is likely the first thing any regulator or enterprise customer will ask about.

---

## Part 3: Article 20 — Management Body Obligations

Beyond Art. 21, note that **Article 20** imposes direct obligations on your management body (board/C-suite):

1. The management body must **approve your cybersecurity risk management measures** — they cannot simply delegate this to IT without oversight.
2. The management body must **oversee implementation** of Art. 21 measures and ensure adequate resources are allocated.
3. Management body members must complete **regular cybersecurity training** to understand the risks and how to govern them.
4. **Personal liability** of management body members is possible under Member State transposition law — individual executives can be held accountable for failures of oversight.

Practical implication: schedule a board/executive session on NIS2 obligations, formally adopt your information security policy at board level, and establish a recurring cybersecurity governance agenda item.

---

## Part 4: Recommended Implementation Roadmap

Given your size and a likely Important Entity classification, here is a pragmatic sequencing:

| Phase | Timeframe | Priority Actions |
|-------|-----------|-----------------|
| **1 — Foundations** | Months 1–2 | Confirm classification with legal counsel; conduct NIS2 gap assessment; build asset inventory; draft information security policy; establish management body governance process |
| **2 — High-Priority Controls** | Months 2–4 | Enforce MFA everywhere; implement/formalise IRP with 24h/72h/1-month reporting workflows; verify backup and DR processes; deploy access control and leavers process audit |
| **3 — Process & Policy** | Months 3–5 | Complete cryptography policy; launch security awareness training programme; implement vulnerability management programme; build supplier register and security contract clauses |
| **4 — Assurance** | Months 5–6 | Conduct internal audit against all 10 measures; commission penetration test; establish effectiveness KPIs and reporting to management body; document CVD policy |
| **5 — Continuous** | Ongoing | Annual risk assessment; annual IRP test; quarterly backup restoration tests; quarterly access reviews; annual training refresh; management body annual cyber briefing |

---

## Part 5: Evidence and Documentation Checklist

To demonstrate compliance to competent authorities or enterprise customers, maintain the following:

- [ ] Written information security risk management policy (board-approved)
- [ ] Asset inventory (systems, data, cloud resources)
- [ ] Annual risk assessment report
- [ ] Incident Response Plan with NIS2 notification templates
- [ ] BCP/DR plan with RTO/RPO definitions and test records
- [ ] Supplier/vendor register with security assessments and contract clauses
- [ ] Secure SDLC documentation and penetration test reports
- [ ] Vulnerability management policy and patching SLA records
- [ ] Coordinated vulnerability disclosure policy (security.txt)
- [ ] Effectiveness KPIs/KRI dashboard and internal audit reports
- [ ] Security awareness training completion records
- [ ] Cryptography and key management policy
- [ ] Access control policy, RBAC matrix, and quarterly review records
- [ ] Joiners/movers/leavers process documentation
- [ ] MFA implementation records and privileged access management policy
- [ ] Emergency communication plan
- [ ] Management body training records and meeting minutes approving cybersecurity policies

---

## Part 6: ISO 27001 Alignment

If you pursue or already hold **ISO 27001:2022 certification**, the Annex A controls map closely to all 10 NIS2 Art. 21 measures. ISO 27001 certification provides strong evidence of NIS2 compliance and is often the most efficient path for a B2B SaaS to demonstrate security posture to both regulators and enterprise customers. It does not substitute formal NIS2 registration and incident reporting obligations, but substantially closes the compliance gap.

---

## Disclaimer

This response is an expert analysis based on the NIS2 Directive (Directive (EU) 2022/2555) and does not constitute legal advice. NIS2 has been transposed differently across EU Member States, and the precise classification and obligations applicable to your company depend on the national transposition law of the Member State(s) in which you are established. Engage qualified legal counsel in the relevant jurisdiction to confirm your classification and registration obligations.

# NIS2 Compliance Assessment: B2B SaaS HR Software Company

## Are You Directly Subject to NIS2?

The answer is: **probably yes, though the specific classification matters.**

The EU NIS2 Directive (Directive 2022/2555), which became law in October 2024, significantly expanded the scope of the original NIS Directive. Whether your company falls under NIS2 depends on your sector classification and size thresholds.

### Size Threshold Analysis

NIS2 applies to "medium-sized enterprises" and larger organizations in covered sectors. The EU definition of a medium-sized enterprise is:

- 50 or more employees, **OR**
- Annual turnover/revenue exceeding €10 million

With **75 employees and €15M annual revenue**, your company exceeds **both** thresholds. You are not a micro or small enterprise and cannot use those exemptions.

### Sector Classification

NIS2 organizes covered entities into two tiers:

**Annex I - Essential Entities** (higher scrutiny, proactive supervision):
Includes energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure (IXPs, DNS, TLD registries, cloud computing providers, data centers, CDNs, trust service providers, public electronic communications networks).

**Annex II - Important Entities** (lower scrutiny, reactive supervision):
Includes postal services, waste management, chemicals, food, manufacturing (certain sectors), digital providers (online marketplaces, online search engines, social networking platforms), and **managed service providers / digital service providers**.

As a **B2B cloud-based SaaS HR software provider**, your most likely classification is under **Annex II as a Digital Service Provider** — specifically as a provider of cloud computing services or a managed service provider to other businesses. Some EU member states may also classify B2B SaaS providers under the broader "digital providers" category.

**Conclusion on applicability:** Yes, you are very likely an **Important Entity** under NIS2 Annex II, subject to the directive's requirements. Your customer's warning is correct.

> **Note:** NIS2 is an EU Directive, meaning each EU member state must transpose it into national law. The specific national implementing legislation in the countries where you operate or where your customers are based will govern your exact obligations. If you are not established in the EU but serve EU customers, you may still need to designate an EU representative.

---

## What Does Article 21 Require?

Article 21 of NIS2 sets out **cybersecurity risk-management measures** that covered entities must implement. It requires a risk-based approach with measures "appropriate to the risks posed." Here is what it mandates:

### Article 21 Requirements Breakdown

**Article 21(1) - General Obligation**
You must take "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems." Measures must be based on an "all-hazards approach."

**Article 21(2) - Specific Measures Required**

The directive lists ten specific categories of measures that must be implemented:

---

#### 1. Policies on Risk Analysis and Information Security (Art. 21(2)(a))
**What it means:** Formal, documented information security policies covering risk analysis methodology, asset inventory, and risk treatment.

**Practical steps:**
- Develop and maintain a written Information Security Policy
- Conduct and document regular risk assessments (at least annually)
- Maintain an asset register (systems, data, infrastructure)
- Implement a risk treatment plan with documented decisions

---

#### 2. Incident Handling (Art. 21(2)(b))
**What it means:** Processes and procedures for detecting, reporting, and responding to security incidents.

**Practical steps:**
- Establish an Incident Response Plan (IRP)
- Define incident classification and severity levels
- Set up internal incident detection and logging
- Designate incident response roles and responsibilities
- Implement communication procedures for internal and external notification

---

#### 3. Business Continuity, Including Backup Management and Disaster Recovery (Art. 21(2)(c))
**What it means:** Ensuring your service can continue operating or recover quickly after a disruption.

**Practical steps:**
- Implement and test regular data backups (automated, off-site or cloud)
- Develop a Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP)
- Define Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs)
- Test recovery procedures at least annually
- Document procedures for maintaining service during significant incidents

---

#### 4. Supply Chain Security (Art. 21(2)(d))
**What it means:** Assessing and managing cybersecurity risks from your suppliers, subprocessors, and technology vendors.

**Practical steps:**
- Inventory all third-party vendors and cloud providers (AWS, Azure, GCP, SaaS tools, etc.)
- Conduct security due diligence on critical suppliers
- Include cybersecurity requirements in supplier contracts
- Assess your software supply chain (open-source libraries, CI/CD pipelines, etc.)
- Establish a vendor risk management process

---

#### 5. Security in Network and Information Systems Acquisition, Development, and Maintenance (Art. 21(2)(e))
**What it means:** Security-by-design in your software development lifecycle and infrastructure management.

**Practical steps:**
- Implement a Secure Software Development Lifecycle (SSDLC)
- Conduct code reviews and security testing (SAST, DAST)
- Manage vulnerabilities and apply patches promptly
- Implement change management procedures
- Conduct penetration testing periodically

---

#### 6. Policies and Procedures to Assess the Effectiveness of Cybersecurity Risk-Management Measures (Art. 21(2)(f))
**What it means:** Monitoring, auditing, and continuously improving your security controls.

**Practical steps:**
- Define and track key security metrics/KPIs
- Conduct internal security audits
- Perform or commission external audits/penetration tests
- Implement continuous monitoring (SIEM, log management)
- Review and update policies at regular intervals

---

#### 7. Basic Cyber Hygiene Practices and Cybersecurity Training (Art. 21(2)(g))
**What it means:** Ensuring all staff follow fundamental security practices and receive adequate training.

**Practical steps:**
- Implement mandatory security awareness training for all 75 employees
- Train on phishing, social engineering, password hygiene, and data handling
- Apply basic hygiene measures: MFA everywhere, patch management, endpoint protection, principle of least privilege
- Role-specific training for developers, IT staff, and management

---

#### 8. Policies and Procedures Regarding the Use of Cryptography and Encryption (Art. 21(2)(h))
**What it means:** Formal policies governing when and how encryption is used.

**Practical steps:**
- Encrypt all data at rest (databases, backups, file storage)
- Encrypt all data in transit (TLS 1.2/1.3 minimum)
- Document your cryptography standards and key management procedures
- Manage certificates and keys through a defined lifecycle
- Prohibit use of deprecated algorithms (MD5, SHA-1, DES, RC4)

---

#### 9. Human Resources Security, Access Control Policies, and Asset Management (Art. 21(2)(i))
**What it means:** Controlling who can access what, and managing the human element of security.

**Practical steps:**
- Implement Role-Based Access Control (RBAC) with least privilege
- Conduct background checks for staff with privileged access
- Implement onboarding and offboarding security procedures
- Enforce MFA for all systems, especially administrative access
- Maintain an up-to-date asset inventory
- Conduct periodic access reviews

---

#### 10. Use of Multi-Factor Authentication (MFA) and Secure Communications (Art. 21(2)(j))
**What it means:** Mandating MFA and secured communications where appropriate.

**Practical steps:**
- Enforce MFA for all remote access, admin panels, cloud consoles, and sensitive systems
- Implement MFA for your HR software's administrative interfaces
- Use secure (encrypted) communications for sensitive internal communications
- Consider privileged access management (PAM) for administrative accounts

---

## Article 21(4) - Management Accountability

A critical provision often overlooked: **management bodies are personally responsible** for approving and overseeing cybersecurity risk management measures. Your CEO/board must:

- Approve the cybersecurity policies
- Oversee their implementation
- Undergo cybersecurity training themselves
- Can be held **personally liable** for non-compliance

---

## NIS2 Incident Reporting Obligations (Article 23)

Alongside Article 21, you must also implement reporting procedures to comply with Article 23's notification timelines:

| Timeframe | Action Required |
|-----------|----------------|
| **24 hours** | Early warning to national CSIRT/competent authority if you suspect a significant incident |
| **72 hours** | Formal incident notification with initial assessment |
| **1 month** | Final report with full details, impact, and remediation measures |

A "significant incident" is one that causes or could cause severe operational disruption or financial loss to your organization or other entities.

---

## Penalties for Non-Compliance

For Important Entities (your likely classification):
- Administrative fines up to **€7 million or 1.4% of total global annual turnover**, whichever is higher
- Member states may impose additional penalties

---

## Recommended Action Plan

Given your size and resources, here is a pragmatic prioritization:

**Immediate (0-3 months):**
1. Determine your exact classification under your applicable national NIS2 implementation law
2. Identify your competent national authority and register if required
3. Conduct a gap assessment against all 10 Article 21 measures
4. Establish incident response procedures and reporting capabilities
5. Enforce MFA across all systems

**Short-term (3-6 months):**
6. Develop formal Information Security Policy and risk assessment process
7. Implement backup and disaster recovery procedures and test them
8. Launch mandatory security awareness training program
9. Inventory and assess your third-party suppliers

**Medium-term (6-12 months):**
10. Implement supply chain security controls and supplier contracts
11. Establish secure SDLC practices
12. Conduct penetration testing
13. Implement continuous monitoring
14. Achieve and document management sign-off on all policies

---

## Key Caveats

1. **National implementation varies:** NIS2 is a directive, not a regulation. Each EU member state has implemented it differently. Check the specific national law in your country of establishment.
2. **Self-assessment vs. audit:** Important Entities may be subject to reactive supervision (audited after an incident), whereas Essential Entities face proactive audits. However, you should be able to demonstrate compliance at any time.
3. **Customer contracts:** Your B2B customers may contractually require NIS2 compliance certifications or audit rights — review your customer agreements.
4. **Proportionality:** Requirements must be "appropriate and proportionate" to your risk and size. A 75-person company is not expected to implement controls at the same scale as a multinational, but the measures must be genuine and documented.

---

*Assessment based on NIS2 Directive 2022/2555 and general compliance knowledge as of April 2026. This is not legal advice — consult a qualified legal counsel in the relevant EU member state for your specific situation.*

# NIS2 Incident Reporting: Ransomware Attack Response Guide

## Situation Summary

A ransomware attack occurred at 09:00 Monday morning, encrypting core operational systems. Under the EU NIS2 Directive (Directive (EU) 2022/2555), Article 23, this almost certainly constitutes a **significant incident** triggering mandatory multi-stage reporting obligations.

---

## Step 1: Confirm This Is a "Significant Incident"

Before reporting, confirm the incident meets the NIS2 threshold. An incident is **significant** if it:

- Causes or is capable of causing **substantial disruption** to the provision of your services
- Causes or could cause **significant financial loss** to your organisation
- Has caused or could cause **material or non-material damage** to other natural or legal persons

A ransomware attack that has **encrypted your core operational systems** almost certainly satisfies all three criteria. You should treat this as a significant incident immediately and begin the reporting timeline below. Do not wait for damage quantification before initiating the 24-hour early warning.

---

## The Three-Stage Reporting Timeline

The attack occurred at **09:00 Monday**. Your deadlines are:

| Stage | Deadline | Absolute Deadline |
|---|---|---|
| Early Warning | Within 24 hours of becoming aware | **09:00 Tuesday** |
| Incident Notification | Within 72 hours of becoming aware | **09:00 Thursday** |
| Final Report | Within 1 month of incident notification | **Approx. 09:00 the following month** |

---

## Stage 1: Early Warning — Due by 09:00 Tuesday

### To Whom
Report to your **national CSIRT (Computer Security Incident Response Team)** and/or your **competent national authority** under NIS2. Depending on your Member State, these may be the same body or separate. Examples:
- Germany: BSI (Bundesamt fur Sicherheit in der Informationstechnik)
- France: ANSSI (Agence nationale de la securite des systemes d'information)
- Netherlands: NCSC-NL
- Ireland: NCSC Ireland

If your Member State has designated a single point of contact (SPOC) for NIS2, route through that channel.

### What to Report at This Stage
The early warning is intentionally brief. You must include:

1. **Whether the incident was (or is suspected to be) malicious in nature** — Ransomware is inherently malicious; answer yes.
2. **Whether the incident could have cross-border impact** — If you provide services in multiple EU Member States, or if suppliers/customers in other Member States are affected, flag this. Cross-border incidents may trigger coordination with other national authorities.

You do NOT need a full technical picture at this stage. A phone call to your CSIRT hotline followed by a brief written submission is typically acceptable. Check your national authority's portal for a specific notification form.

### Practical Checklist for Stage 1
- [ ] Confirm CSIRT/authority contact details are accessible (should be in your incident response plan)
- [ ] Submit early warning via official channel (portal, email, or hotline — varies by Member State)
- [ ] Record the exact time of submission and obtain a reference number if issued
- [ ] Confirm whether cross-border impact applies and flag it if so

---

## Stage 2: Incident Notification — Due by 09:00 Thursday

### To Whom
Same body as Stage 1: your national CSIRT and/or competent authority.

### What to Report at This Stage
This is a more detailed notification providing an **initial assessment** of the incident. You must include:

1. **Severity of the incident** — Describe the scale of encryption, which systems are affected, estimated scope of operational disruption
2. **Impact assessment** — What services are degraded or unavailable? What is the estimated financial impact? Are customers or third parties affected?
3. **Indicators of Compromise (IoCs)** — Any technical indicators identified so far: ransomware family/variant (if identified), malicious file hashes, C2 IP addresses, attack vectors observed (e.g., phishing email, exploited RDP, supply chain vector)
4. **Update on cross-border impact** — Confirm or refine your earlier assessment

You are not required to have root cause analysis complete at this stage, but you should be able to describe the observed attack pattern and initial response actions taken.

### Practical Checklist for Stage 2
- [ ] Document which systems are encrypted and the operational impact
- [ ] Engage your incident response team / forensic partner to begin IoC collection
- [ ] Complete your Member State's formal notification form (72-hour submission)
- [ ] Update the CSIRT on any developments since the early warning
- [ ] Record submission time and reference

---

## Stage 3: Final Report — Due Within 1 Month of Stage 2 Submission

### To Whom
Same national CSIRT and/or competent authority.

### What to Report at This Stage
This is a comprehensive post-incident report requiring:

1. **Detailed description of the incident** — Full timeline from initial compromise through detection, containment, and recovery
2. **Type of threat or root cause** — How did the attacker gain initial access? (e.g., phishing, unpatched vulnerability, compromised credentials, supply chain compromise)
3. **Applied and ongoing mitigations** — What immediate containment actions were taken? What remediation steps are underway? What systemic improvements are being implemented to prevent recurrence?
4. **Cross-border impact** — Confirmed assessment of whether other Member States were affected and how
5. **Lessons learned** — Where relevant, authorities may expect information on how your security posture will be strengthened

### Practical Checklist for Stage 3
- [ ] Complete forensic investigation and root cause analysis
- [ ] Document full attack timeline with evidence
- [ ] Draft remediation roadmap and document completed actions
- [ ] Prepare final report using competent authority's template if one is provided
- [ ] Obtain board/management sign-off before submission (Art. 20 governance obligation)

---

## Article 20: Management Body Obligations

Under Art. 20, your **management body** (board or equivalent) bears direct responsibility for cybersecurity risk management. This has immediate implications for this incident:

- Management must be briefed on this incident and the reporting obligations without delay
- Decisions about the reporting content and remediation approach require management oversight
- Management may face **personal liability** under Member State law for failure to comply with NIS2 obligations, including missed reporting deadlines

Ensure the board is informed and actively involved, not merely copied on communications.

---

## Article 21: Measures This Incident Puts Under Scrutiny

Regulators reviewing this incident will examine whether you had adequate Art. 21 measures in place. Key measures most directly relevant to a ransomware attack:

| Art. 21 Measure | Ransomware Relevance |
|---|---|
| **Measure 2** — Incident handling | Did you have detection, response, and recovery procedures? |
| **Measure 3** — Business continuity, backup management, DR | Do you have clean, offline backups? What is your RTO/RPO? |
| **Measure 4** — Supply chain security | Was the attack vector through a supplier or third-party system? |
| **Measure 8** — Cryptography and encryption | Was sensitive data protected before encryption by attacker? |
| **Measure 9** — Access control, asset management | Were privileged credentials compromised? Was MFA in place? |
| **Measure 10** — MFA, secured communications | Could MFA have prevented the initial compromise? |

Be prepared to demonstrate that you had documented policies for these measures. Gaps in these controls may be raised by the supervisory authority during or after the incident investigation.

---

## Supervision and Penalty Exposure

Your supervisory exposure depends on your entity classification:

- **If you are an Essential Entity (EE):** You are subject to **proactive (ex-ante) supervision** under Art. 32. Expect the competent authority to conduct active follow-up, potentially including on-site inspections or security audits as part of the post-incident review. Maximum penalty: **€10,000,000 or 2% of global annual turnover**, whichever is higher.
- **If you are an Important Entity (IE):** You are subject to **reactive (ex-post) supervision** under Art. 33. The authority will likely open a compliance review triggered by this incident. Maximum penalty: **€7,000,000 or 1.4% of global annual turnover**, whichever is higher.

Failure to meet the 24-hour or 72-hour reporting deadlines, or submission of materially incomplete notifications, can itself constitute a separate compliance failure subject to penalties independent of the underlying security incident.

---

## Immediate Action Summary

Given the attack occurred at 09:00 Monday:

1. **Right now:** Brief management, activate your incident response plan, engage forensic support, and prepare the early warning submission.
2. **Before 09:00 Tuesday:** Submit the early warning to your national CSIRT/competent authority — brief, factual, confirming malicious nature and flagging cross-border risk if applicable.
3. **Before 09:00 Thursday:** Submit the full 72-hour incident notification with severity assessment, impact summary, and known IoCs.
4. **Within 1 month of Thursday's submission:** Deliver the comprehensive final report with root cause analysis, full timeline, and remediation plan.

Do not let the incident response effort crowd out the reporting obligation. These are **parallel workstreams** — designate a compliance/legal lead to own the reporting timeline while the technical team manages containment and recovery.

---

*This guidance is based on Article 23 of Directive (EU) 2022/2555 (NIS2 Directive). Member State transposition laws may impose additional or more specific requirements. Verify the exact notification portal, form, and contact details with your national competent authority. As of the transposition deadline of 17 October 2024, all EU Member States were required to have implemented NIS2 into national law.*

# NIS2 Incident Reporting: Ransomware Attack Response Guide

## Scenario Context
- **Incident:** Ransomware attack encrypting core operational systems
- **Attack detected:** 09:00 Monday morning
- **Applicable framework:** NIS2 Directive (EU) 2022/2555

---

## Step 1: Confirm NIS2 Applicability

Before acting, confirm your organisation falls under NIS2. The directive covers two tiers:

- **Essential Entities (EE):** Energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space
- **Important Entities (IE):** Postal/courier, waste management, chemicals, food, manufacturing, digital providers, research

A ransomware attack encrypting **core operational systems** almost certainly constitutes a **"significant incident"** triggering mandatory reporting obligations under Article 23 of NIS2.

### What Makes an Incident "Significant"?

An incident is significant if it causes or is capable of causing:
- Severe operational disruption to your services
- Financial losses to your organisation
- Significant material or immaterial damage to other persons (downstream impact)

Encryption of core operational systems clearly meets this threshold.

---

## Step 2: Who to Report To

### Primary Authority: Your National CSIRT and/or Competent Authority

You must notify **two bodies** (which may be the same in your member state):

1. **CSIRT (Computer Security Incident Response Team):** The national CSIRT designated under NIS2 for your sector/country (e.g., BSI in Germany, NCSC in the Netherlands, CERT-In equivalents across EU)
2. **Competent National Authority:** The sector-specific supervisory authority designated under NIS2 (e.g., national energy regulator, health authority, telecoms regulator)

Each EU member state has designated these bodies — check your national NIS2 implementation law for specifics.

### Secondary Notifications (Where Applicable)

- **Affected service recipients (users/customers):** If the incident affects them significantly, you must notify them without undue delay
- **Other member states' CSIRTs/authorities:** If the incident has cross-border impact
- **ENISA:** For significant cross-border incidents, ENISA may be informed via the national CSIRT network

---

## Step 3: The Three-Stage Reporting Timeline

NIS2 Article 23 mandates a structured, three-stage notification process:

### Stage 1: Early Warning — Within 24 Hours of Becoming Aware

**Deadline:** By 09:00 Tuesday (24 hours after detection at 09:00 Monday)

**Content required:**
- Indication that a significant incident has occurred
- Whether the incident is suspected to be the result of unlawful or malicious acts (ransomware = yes)
- Whether the incident is likely to have cross-border impact

**Format:** Brief, high-level alert. This is a "heads up" notification — full details are not required yet.

**Key point:** "Becoming aware" is from the moment you knew or should have known about the incident — in this case, 09:00 Monday when it was detected. Do not delay reporting while you investigate.

---

### Stage 2: Incident Notification — Within 72 Hours of Becoming Aware

**Deadline:** By 09:00 Thursday (72 hours after detection at 09:00 Monday)

**Content required:**
- Updated assessment of the incident
- Initial severity and impact assessment
- Indicators of compromise (IOCs), where available
- Attack vector or suspected cause
- Nature of the incident (ransomware attack, type if known)
- Systems/services affected
- Estimated number of affected users or entities
- Whether personal data has been affected (if so, GDPR obligations also apply — see below)
- Mitigation measures applied or underway

**Format:** More detailed than the Early Warning, but a full investigation is not expected at this stage.

---

### Stage 3: Final Report — Within 1 Month of Incident Notification Submission

**Deadline:** Approximately 1 month after submitting Stage 2 (i.e., by approximately Thursday + 1 month from the attack week)

**Content required:**
- Detailed description of the incident (full timeline, root cause analysis)
- Type and severity classification
- Threat type and attack vectors
- Impact on services and operations
- Mitigation measures taken and their effectiveness
- Cross-border impact analysis
- Lessons learned
- Recommended or implemented preventive measures

**Note:** For ongoing incidents still not resolved after 1 month, submit an **Intermediate Report** at the 1-month mark, with a Final Report within 1 month of resolution.

---

## Step 4: GDPR Overlap — Critical Consideration

If the ransomware attack has **also compromised, exfiltrated, or provided unauthorised access to personal data**, you face a **parallel obligation under GDPR Article 33**:

- **Data Breach Notification to your Data Protection Authority (DPA):** Within **72 hours** of becoming aware
- **Notification to data subjects (Article 34):** Without undue delay if the breach is likely to result in high risk to individuals

These run **concurrently** with NIS2 obligations. The 72-hour GDPR deadline and the 72-hour NIS2 deadline are independent — do not conflate them. Ransomware often involves data exfiltration prior to encryption; assume personal data may be at risk until forensics confirm otherwise.

---

## Step 5: Practical Action Checklist (Hour-by-Hour)

### Monday 09:00 (Attack Detected)
- [ ] Activate Incident Response Plan
- [ ] Isolate affected systems to prevent spread
- [ ] Preserve forensic evidence (logs, memory dumps)
- [ ] Engage external incident response/forensics team if needed
- [ ] Notify internal leadership and legal/compliance team
- [ ] Begin assessing whether personal data is involved (GDPR trigger)
- [ ] Identify your national CSIRT and competent authority contacts

### Monday — Before 09:00 Tuesday (24-Hour Deadline)
- [ ] Submit **Early Warning** to national CSIRT and competent authority
- [ ] Note: If personal data is involved, also start the GDPR 72-hour clock
- [ ] Do not wait for full forensic clarity — submit with what you know

### Tuesday to Thursday — Before 09:00 Thursday (72-Hour Deadline)
- [ ] Continue forensic investigation
- [ ] Submit **Incident Notification** (Stage 2) with fuller details
- [ ] If personal data confirmed affected: submit GDPR breach notification to DPA
- [ ] Notify affected service recipients if their services are impacted
- [ ] Document all decisions and actions taken

### Within 1 Month of Stage 2 Submission
- [ ] Submit **Final Report** with full post-incident analysis
- [ ] Document root cause, lessons learned, and remediation measures

---

## Step 6: Key Legal Obligations Summary Table

| Obligation | Recipient | Deadline | Content |
|---|---|---|---|
| Early Warning | National CSIRT + Competent Authority | 24 hours (by Tuesday 09:00) | Incident occurred, suspected malicious, cross-border? |
| Incident Notification | National CSIRT + Competent Authority | 72 hours (by Thursday 09:00) | Impact, IOCs, attack type, affected systems, mitigations |
| Final Report | National CSIRT + Competent Authority | 1 month after Stage 2 | Full analysis, root cause, lessons learned |
| GDPR Data Breach (if applicable) | National DPA | 72 hours (by Thursday 09:00) | Nature of breach, data categories, likely consequences |
| Service recipient notification | Affected customers/users | Without undue delay | If incident significantly affects their services |

---

## Step 7: Penalties for Non-Compliance

Failure to report or late reporting carries significant financial risk:

- **Essential Entities:** Fines up to **€10 million** or **2% of global annual turnover**, whichever is higher
- **Important Entities:** Fines up to **€7 million** or **1.4% of global annual turnover**, whichever is higher

National authorities also have supervisory and corrective powers, including temporary bans on management exercise of responsibilities for persistent failures.

---

## Step 8: Practical Tips

1. **Do not wait for full investigation clarity** before filing the Early Warning — NIS2 expressly permits incomplete information at Stage 1, and regulators expect prompt notification over perfect information.

2. **Document the precise time you became aware** of the incident — this is the clock-start for all deadlines.

3. **Assume personal data is at risk** from ransomware until forensics confirm otherwise, and run GDPR notifications in parallel.

4. **Check your member state's specific implementation** — NIS2 was transposed by each EU member state by October 2024; local law may add requirements or modify who the designated contacts are.

5. **Engage legal counsel** experienced in NIS2 and your sector early — mischaracterising an incident as non-significant when it is significant is a regulatory risk.

6. **Preserve all communications** with regulators as evidence of good-faith compliance efforts.

---

## Summary

Your core obligation is a **three-stage report to your national CSIRT and competent authority**: Early Warning by Tuesday 09:00, full Incident Notification by Thursday 09:00, and a Final Report within approximately one month. If personal data is involved, GDPR data breach notifications to your DPA run concurrently on the same 72-hour timeline. Prioritise speed and honesty over completeness in early filings — regulators understand investigations take time.

# ISO 27001:2022 and NIS2 Compliance: Gap Analysis

## Short Answer

ISO 27001:2022 certification is a strong foundation and provides meaningful evidence of NIS2 compliance for many Art. 21 cybersecurity risk management measures — but it does **not** make you NIS2 compliant on its own. NIS2 imposes direct legal obligations that go beyond what ISO 27001 addresses, most significantly in governance accountability, incident reporting timelines, mandatory MFA, and supply chain coordination with EU authorities. You will need targeted remediation in at least six areas.

---

## Why ISO 27001 Is Not Sufficient Alone

ISO 27001 is a voluntary international standard for an Information Security Management System (ISMS). NIS2 (Directive (EU) 2022/2555) is EU law — a legal obligation imposed directly on in-scope entities by Member State transposition legislation (deadline: 17 October 2024). Holding certification demonstrates that your ISMS meets the standard's requirements; it does not demonstrate that you have fulfilled your legal obligations under NIS2.

The European Union Agency for Cybersecurity (ENISA) and national competent authorities accept ISO 27001 as compliance evidence for the technical and organisational controls in Art. 21, but they will still assess your organisation against NIS2's specific requirements during supervisory proceedings.

---

## Preliminary Step: Confirm Your Entity Classification

Before conducting a gap assessment, confirm whether you are classified as:

- **Essential Entity (EE)** — Annex I sectors: energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management (B2B), public administration, space.
- **Important Entity (IE)** — Annex II sectors: postal/courier, waste management, chemicals, food, manufacturing (medical devices, computers, electronics, machinery, motor vehicles), digital providers, research.

Size thresholds (Art. 3): medium-sized or larger organisations (≥50 employees OR ≥€10M annual turnover) are automatically in scope. Some Member States have extended coverage to smaller entities in critical sectors.

This matters because:
- **EE** are subject to **proactive (ex-ante) supervision** under Art. 32 — including on-site inspections, security audits, and targeted scans. They face penalties up to €10,000,000 or 2% of global annual turnover.
- **IE** are subject to **reactive (ex-post) supervision** under Art. 33 — triggered by evidence of non-compliance. Penalties up to €7,000,000 or 1.4% of global annual turnover.

Most Member States also require in-scope entities to **self-register** with the national competent authority. If you have not done this, it is an immediate action item regardless of other gaps.

---

## ISO 27001 to NIS2 Art. 21 Control Mapping

The ten Art. 21 measures map well to ISO 27001:2022 Annex A. The table below shows where your certification provides strong coverage and where residual gaps remain.

| NIS2 Art. 21 Measure | ISO 27001:2022 Annex A Coverage | Gap Assessment |
|---|---|---|
| M1 — Risk Analysis & IS Policies | A.5.1 Policies; Clause 6.1 Risk assessment; Clause 8.2 IS risk assessment | **Low gap** — ISMS risk methodology directly satisfies M1. Ensure policies explicitly reference network and information systems in scope for NIS2. |
| M2 — Incident Handling | A.5.24–A.5.28 (incident planning, assessment, response, review, evidence) | **Moderate gap** — ISO 27001 covers the process; NIS2 adds legally mandated reporting timelines (see Art. 23 below). IRP needs a NIS2 notification track. |
| M3 — BCP / DR / Crisis Management | A.5.29 IS during disruption; A.5.30 ICT readiness; A.8.13 Backup; A.8.14 Redundancy | **Low gap** — ISO 27001 strongly covers this. Verify RTO/RPO are defined per critical service and tested annually; involve management in crisis exercises. |
| M4 — Supply Chain Security | A.5.19–A.5.23 (supplier relationships, agreements, ICT supply chain, cloud) | **Moderate gap** — ISO 27001 covers supplier controls generally; NIS2 Art. 21(2)(d) specifically ties to ENISA-coordinated supply chain risk assessments under Art. 26. You must monitor and act on ENISA/national authority advisories on high-risk vendors. |
| M5 — Secure Acquisition & Development | A.8.25–A.8.30; A.5.8 | **Low gap** — Secure SDLC and vulnerability management are well-covered. Ensure a formal coordinated vulnerability disclosure (CVD) policy exists aligned with ENISA guidance. |
| M6 — Effectiveness Assessment | A.5.35–5.36; Clause 9.1–9.3 | **Low gap** — ISO 27001's management review and internal audit cycle directly satisfies M6. Ensure cybersecurity KPIs are reported to the management body formally. |
| M7 — Cyber Hygiene & Training | A.6.3 IS awareness/training; A.5.7 Threat intelligence | **Low gap** — ISO 27001 requires awareness training. NIS2 Art. 20 requires that the **management body itself** undergoes regular cybersecurity training. Verify board-level training records exist. |
| M8 — Cryptography | A.8.24 Use of cryptography | **Low gap** — ISO 27001 covers this. Confirm your cryptographic policy specifies approved algorithms (AES-256, TLS 1.2+, SHA-256+) and key management lifecycle. Consider post-quantum readiness review. |
| M9 — HR Security, Access Control & Asset Management | A.5.9–A.5.11; A.8.2–A.8.4; A.6.1; A.6.5 | **Low gap** — ISO 27001 covers this well. Confirm least-privilege, RBAC, quarterly access reviews, and same-day leaver revocation are operational. |
| M10 — MFA & Secure Communications | A.8.5 Secure authentication; A.8.20 Network security; A.8.24 Cryptography | **Significant gap** — ISO 27001 covers authentication generally; NIS2 **explicitly mandates MFA**. ISO 27001 does not universally require MFA. You must deploy MFA for remote access, privileged accounts, cloud management consoles, and email. |

---

## Key Gaps Where NIS2 Exceeds ISO 27001

### Gap 1 — Art. 20: Management Body Governance and Personal Liability (HIGH PRIORITY)

**ISO 27001 position:** Leadership commitment is required (Clause 5), but personal liability for individual board members is not addressed.

**NIS2 requirement:** Art. 20 mandates that the management body (board, executive committee, or equivalent):
- Approves cybersecurity risk management measures in writing.
- Oversees implementation and can be held personally liable under Member State law for failures.
- Completes **regular cybersecurity training**.

**Remediation actions:**
- Document board-level approval of the NIS2 cybersecurity policy (separate board minute or resolution).
- Establish a board cybersecurity oversight charter with defined roles and accountability.
- Implement and record annual cybersecurity training programme specifically for the management body.
- Confirm with legal counsel what personal liability provisions your Member State's transposition law contains.

---

### Gap 2 — Art. 23: Incident Reporting Timelines (HIGH PRIORITY)

**ISO 27001 position:** A.5.24–A.5.26 require incident management processes, but ISO 27001 does not specify legally mandated notification timelines to external authorities.

**NIS2 requirement:** For **significant incidents** (substantial service disruption, material financial loss, cross-border impact, or damage to other persons), you must notify the national CSIRT or competent authority:

| Timeline | Requirement |
|---|---|
| **24 hours** | Early warning — confirm suspected malicious cause and/or cross-border impact |
| **72 hours** | Incident notification — initial severity assessment, impact scope, indicators of compromise |
| **1 month** | Final report — detailed description, threat type, root cause, mitigations applied, cross-border impact assessment |

"Significant incident" thresholds include: service disruption affecting a significant number of users, duration exceeding a few hours for critical services, geographic spread, or reputational/financial/safety impact.

**Remediation actions:**
- Add a NIS2 notification track to your existing Incident Response Plan (IRP).
- Pre-draft CSIRT notification templates for the 24h and 72h submissions.
- Define internal escalation triggers that activate the 24h clock (e.g., detection of malicious intrusion, ransomware, DDoS affecting service availability).
- Build the 1-month post-incident report template incorporating all Art. 23(4) mandatory fields.
- Identify your national CSIRT and competent authority and establish contact channels in advance.
- Test the full reporting workflow in annual tabletop exercises.

---

### Gap 3 — Art. 21(2)(j): Mandatory MFA (HIGH PRIORITY)

**ISO 27001 position:** A.8.5 covers secure authentication; MFA is recommended but not universally mandated.

**NIS2 requirement:** Art. 21(2)(j) explicitly requires multi-factor authentication (or continuous authentication), secured communications, and secured emergency communication systems.

**Remediation actions:**
- Deploy MFA for **all remote access** (VPN, remote desktop).
- Deploy MFA for **all privileged accounts** (system administrators, cloud IAM, database administrators).
- Deploy MFA for **cloud management consoles** (AWS, Azure, GCP, SaaS platforms holding sensitive data).
- Deploy MFA for **email access** and collaboration platforms.
- Apply **phishing-resistant MFA** (FIDO2 hardware tokens, passkeys) for highest-privilege accounts.
- Establish encrypted out-of-band emergency communication channels for incident coordination.
- Document any exceptions with compensating controls and risk acceptance.

---

### Gap 4 — Art. 26: Supply Chain Risk Assessments Coordinated by ENISA (MODERATE PRIORITY)

**ISO 27001 position:** A.5.19–A.5.23 cover supplier security; they address your bilateral supplier relationships.

**NIS2 requirement:** Art. 26 establishes a coordinated EU-level process for assessing risks in critical ICT supply chains. ENISA and national authorities conduct targeted risk assessments of specific vendors and products and may classify them as high-risk. Entities must integrate these assessments into their own risk management.

**Remediation actions:**
- Subscribe to ENISA supply chain risk assessment publications and advisories.
- Monitor national competent authority guidance on high-risk ICT vendors (e.g., 5G vendor risk assessments under the EU 5G Toolbox).
- Maintain a critical ICT supplier register and flag vendors subject to ENISA/national authority advisories.
- Include contractual obligations in supplier agreements: NIS2-aligned security baselines, incident notification SLAs, right-to-audit.
- Review and update supplier risk assessments when new ENISA coordinated assessments are published.

---

### Gap 5 — Self-Registration with National Competent Authority (ADMINISTRATIVE)

Most Member State transposition laws require in-scope entities to **proactively register** with the designated national competent authority or CSIRT. This is independent of any technical or organisational control implementation.

**Remediation action:** Identify the national competent authority in your Member State(s) of establishment and complete any required self-registration. Registration typically requires: organisation name, sector classification, contact details, and the identity of the designated NIS2 point of contact.

---

### Gap 6 — Proportionality Documentation for NIS2 (ADMINISTRATIVE)

NIS2 Art. 21(1) requires measures to be "appropriate and proportionate" based on risk exposure, entity size, likelihood and severity of incidents, and implementation cost. ISO 27001's risk-based approach partially satisfies this, but for NIS2 supervisory proceedings, you should:

**Remediation actions:**
- Document a NIS2 proportionality assessment justifying your control selection relative to Art. 21 measures.
- Ensure your risk assessment explicitly references NIS2 in-scope network and information systems.
- Map each Art. 21 measure to implemented controls with evidence references (policies, audit reports, test results).

---

## Prioritised Remediation Roadmap

| Priority | Action | Owner | Timeline |
|---|---|---|---|
| 1 | Confirm entity classification (EE or IE) and complete national authority self-registration | Legal / Compliance | Immediate |
| 2 | Document board approval of NIS2 cybersecurity policy and establish management training records | Board / CISO | 30 days |
| 3 | Add NIS2 notification track to IRP with pre-drafted 24h/72h templates and CSIRT contact details | Security Operations | 30–60 days |
| 4 | Conduct MFA gap assessment and deploy MFA to remote access, privileged accounts, and cloud consoles | IT / IAM | 30–90 days |
| 5 | Subscribe to ENISA supply chain advisories and update supplier register and contracts | Procurement / Legal | 60 days |
| 6 | Run NIS2 tabletop exercise testing the 24h/72h/1-month reporting workflow | Security Operations | 90 days |
| 7 | Draft NIS2 proportionality assessment document | Compliance / CISO | 60–90 days |
| 8 | Brief management body on personal liability under Member State transposition law | Legal | 60 days |

---

## Summary Assessment

| Area | ISO 27001 Coverage | NIS2 Gap |
|---|---|---|
| Technical & organisational security controls (Art. 21 M1–M9) | Strong | Low — minor alignment work |
| Mandatory MFA (Art. 21 M10) | Partial | Significant — explicit legal mandate |
| Governance and personal liability (Art. 20) | None | Critical — requires board action |
| Incident reporting timelines (Art. 23) | Partial | Critical — legal deadlines not addressed by ISO 27001 |
| ENISA supply chain coordination (Art. 26) | Partial | Moderate — ongoing monitoring obligation |
| Entity registration | Not applicable | Administrative — likely required by transposition law |

Your ISO 27001:2022 ISMS provides an excellent base. The work required to achieve NIS2 compliance is targeted rather than transformational — but the governance (Art. 20), incident reporting (Art. 23), and MFA (Art. 21(2)(j)) gaps carry the highest regulatory risk if left unaddressed, particularly for Essential Entities under proactive supervision.

---

*This analysis is based on the NIS2 Directive (EU) 2022/2555 as adopted and ISO/IEC 27001:2022. Member State transposition laws may impose additional or more prescriptive requirements. Always validate against the specific national implementing legislation applicable to your establishment(s).*

# ISO 27001:2022 and NIS2 Compliance: Gap Analysis

## Short Answer

No. Holding ISO 27001:2022 certification does **not** mean you are NIS2 compliant. ISO 27001 provides a strong foundation and significantly reduces the compliance effort, but NIS2 (the EU Network and Information Security Directive 2, transposed into national law across EU Member States by October 2024) imposes legally binding obligations that go beyond what ISO 27001 requires or covers.

---

## Why ISO 27001 Helps — But Is Not Sufficient

ISO 27001 is a voluntary international standard for an Information Security Management System (ISMS). It is certification-based and process-oriented, demonstrating that your organisation manages information security systematically. NIS2, by contrast, is EU law. It imposes direct legal obligations on essential and important entities in critical sectors, with mandatory incident reporting timelines, personal liability for management, and national supervisory authority oversight.

The two frameworks overlap substantially in their security control objectives, but NIS2 adds requirements that ISO 27001 does not address at all — or addresses only partially.

---

## Key Gaps Between ISO 27001:2022 and NIS2

### 1. Mandatory Incident Reporting Obligations

**NIS2 requirement:** Article 23 requires notification of significant incidents:
- Within **24 hours**: early warning to the national CSIRT or competent authority.
- Within **72 hours**: incident notification with an initial assessment.
- Within **1 month**: final report with root cause, impact, and remediation.

**ISO 27001 gap:** ISO 27001 (Annex A 6.8, 5.24–5.28) requires you to have an incident management process, but it does not mandate reporting to external authorities, and it sets no specific timeframes tied to regulatory deadlines. Your ISMS may handle incidents internally without fulfilling NIS2's external notification chain.

**Action needed:** Establish formal procedures for notifying the national competent authority/CSIRT, with documented escalation paths and owners responsible for each reporting window.

---

### 2. Supply Chain and Third-Party Security

**NIS2 requirement:** Article 21(2)(d) explicitly requires organisations to address security in supply chains, including the security practices of direct suppliers and service providers and their sub-suppliers.

**ISO 27001 gap:** ISO 27001 Annex A 5.19–5.22 covers supplier relationships, but the depth of NIS2's supply chain security obligation — including assessing the vulnerability of specific products and services, and evaluating suppliers' own security posture — often exceeds what a typical ISO 27001 supplier management programme achieves. NIS2 expects a risk-based view of the entire supply chain, not just contractual clauses.

**Action needed:** Conduct supply chain risk assessments at a deeper level, including criticality classification of suppliers, security assessments of key third parties, and documented due diligence on sub-processors.

---

### 3. Management Accountability and Governance

**NIS2 requirement:** Article 20 requires that the management body (board-level or equivalent) approves, oversees, and is personally liable for cybersecurity risk management measures. Management members can be held personally liable for negligence and may be temporarily barred from management roles following serious incidents.

**ISO 27001 gap:** ISO 27001 clause 5 requires top management commitment and leadership, but it does not create personal legal liability for individual executives, nor does it require the same level of board-level direct accountability that NIS2 mandates. Many ISO 27001 implementations delegate ISMS oversight to an CISO or IT function rather than embedding it at the board level.

**Action needed:** Formally assign NIS2 cybersecurity responsibilities to the management body, ensure board-level sign-off on risk management decisions, and implement board training on cybersecurity obligations.

---

### 4. Specific Minimum Security Measures

**NIS2 requirement:** Article 21(2) sets out a minimum baseline of security measures that covered entities must implement, including:
- Policies on risk analysis and information system security.
- Business continuity and crisis management (including backup management and disaster recovery).
- Basic cyber hygiene practices and cybersecurity training.
- Policies and procedures on the use of cryptography and, where appropriate, encryption.
- Human resources security, access control policies, and asset management.
- Multi-factor authentication (MFA) or continuous authentication.
- Secured voice, video, and text communications; secured emergency communications.

**ISO 27001 gap:** ISO 27001 Annex A covers most of these areas, but implementation and certification do not guarantee that every measure is in place to the level NIS2 expects. In particular:
- **MFA**: ISO 27001 does not mandate MFA; NIS2 does.
- **Encrypted communications**: ISO 27001 recommends cryptography policies (A.8.24) but does not require secured emergency communication systems.
- **Cyber hygiene training**: ISO 27001 requires awareness (A.6.3) but NIS2 expects structured, regular cybersecurity training for all staff.

**Action needed:** Perform a control-by-control mapping of your existing Annex A controls against NIS2 Article 21 requirements, identify any gaps in implementation (not just policy), and address MFA deployment across all critical systems.

---

### 5. Scope and Entity Classification

**NIS2 requirement:** NIS2 applies to entities in 18 sectors (11 highly critical, 7 other critical), classified as "essential" or "important" based on size and sector. Some entities are automatically in scope regardless of size (e.g., DNS providers, TLD registries, critical infrastructure operators).

**ISO 27001 gap:** ISO 27001 scope is self-defined. Your ISMS scope may exclude parts of your organisation, subsidiaries, or specific services that fall within NIS2's mandatory scope. NIS2 applies to the entire legal entity (and potentially group entities) operating in scope sectors.

**Action needed:** Review your NIS2 entity classification, confirm your legal status as essential or important, and ensure your ISMS scope covers all in-scope operations. Self-register with the national competent authority as required.

---

### 6. Supervisory and Enforcement Regime

**NIS2 requirement:** NIS2 establishes a supervisory regime including on-site inspections, targeted security audits, ad hoc audits, security scans, and requests for evidence. Essential entities face ex-ante supervision; important entities face ex-post supervision. Fines reach up to **€10 million or 2% of global annual turnover** for essential entities, and **€7 million or 1.4% of global turnover** for important entities.

**ISO 27001 gap:** ISO 27001 certification is assessed by an accredited third-party certification body on a voluntary basis. There is no regulatory authority involved, no statutory power to impose fines for non-compliance with the standard, and no obligation to respond to government requests for evidence.

**Action needed:** Understand your national transposition of NIS2, identify your competent authority, and ensure you can respond to supervisory requests. Maintain audit-ready evidence files that meet regulatory expectations, not just certification body expectations.

---

### 7. Business Continuity and Crisis Management

**NIS2 requirement:** Article 21(2)(c) requires documented business continuity plans, backup management, disaster recovery, and crisis management specifically designed to maintain or rapidly restore services following a cyber incident.

**ISO 27001 gap:** ISO 27001 (A.5.29, A.5.30, A.8.13) addresses BCM and backup, but NIS2 requires this to be specifically oriented toward cyber incident scenarios and service continuity for critical services. Many ISMS implementations have BCM plans that are generic or oriented toward IT recovery rather than sector-specific essential service continuity.

**Action needed:** Review and update BCP/DRP documentation to explicitly address cyber incident scenarios, define recovery time and recovery point objectives for critical services, and test plans regularly.

---

### 8. National Transposition Variations

NIS2 is a directive, meaning each EU Member State transposes it into national law with possible additions or variations. Your obligations depend on the specific national legislation of each country in which you operate — which may go beyond the directive's minimum requirements.

**Action needed:** Identify all Member States where you are in scope, review the relevant national legislation in each jurisdiction, and assess whether additional national requirements apply.

---

## Summary Gap Table

| Area | ISO 27001:2022 | NIS2 Requirement | Gap |
|---|---|---|---|
| Incident reporting to authorities | Not required | 24h / 72h / 1-month reporting | Yes — significant |
| Management personal liability | Not addressed | Board accountability, personal liability | Yes |
| MFA requirement | Not mandated | Explicitly required | Yes |
| Supply chain depth | Supplier clauses | Full supply chain risk assessment | Partial |
| Regulatory supervision | Certification body only | National competent authority | Yes |
| Fines / enforcement | None | Up to €10M or 2% global turnover | Yes |
| Scope alignment | Self-defined | Legal entity / sector-based | Potential gap |
| BCM for cyber incidents | General BCM | Cyber-specific service continuity | Partial |
| Cyber hygiene training | Awareness required | Structured training required | Partial |
| Encrypted communications | Policy required | Secured comms systems required | Partial |

---

## Recommended Next Steps

1. **Perform a formal NIS2 gap assessment** mapped against Article 21 and Article 20 requirements, using your existing ISO 27001 controls as the baseline.
2. **Determine your entity classification** (essential vs. important) and register with your national competent authority.
3. **Implement an external incident reporting procedure** with documented owners and timelines aligned to NIS2 Article 23.
4. **Engage your board** on NIS2 obligations, personal liability, and required governance structures.
5. **Extend supply chain security assessments** beyond contractual clauses to include active risk evaluation of critical suppliers.
6. **Deploy MFA** across all critical systems and document compliance.
7. **Align BCM/DRP** documentation and testing to cyber-specific scenarios for essential services.
8. **Review national transpositions** in every EU Member State where you operate.

---

## Conclusion

ISO 27001:2022 certification demonstrates a mature, well-structured security programme and will significantly accelerate NIS2 compliance. However, NIS2 is a legal obligation with a different purpose — ensuring resilience of critical infrastructure across the EU — and it imposes requirements around governance, incident reporting, supply chain security, and regulatory accountability that ISO 27001 does not cover. Treat ISO 27001 as your compliance foundation, then close the specific gaps identified above to achieve full NIS2 compliance.

# NIS2 and DORA: Interaction, Precedence, and Compliance Programme Design for a European Bank

## Executive Summary

As a large European bank, you are subject to both the NIS2 Directive (Directive (EU) 2022/2555) and the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554). These two instruments are deliberately designed to coexist through a lex specialis relationship: where DORA applies to your sector, it generally takes precedence over NIS2 for the specific obligations it addresses. However, this does not mean NIS2 is irrelevant — a carefully integrated programme is both permissible and strongly advisable. You do not need two entirely separate compliance programmes, but you do need a dual-framework governance structure that maps obligations, avoids duplication of effort, and closes gaps that exist between the two instruments.

---

## 1. Your NIS2 Classification: Essential Entity (Banking Sector)

Under NIS2 Art. 3 and Annex I, **banking** is explicitly listed as an essential entity sector. As a large European bank (almost certainly exceeding 250 employees and €50M turnover), you are an **Essential Entity (EE)** under NIS2.

Key consequences:
- **Proactive (ex-ante) supervision** under Art. 32 — your competent NIS2 authority can conduct on-site inspections, security audits, and targeted scans without a prior complaint or incident trigger.
- **Maximum penalties:** up to €10,000,000 or **2% of global annual turnover** (whichever is higher) under Art. 34.
- **Management body personal liability** under Art. 20 — board members and senior executives can be held personally liable under national law for failure to approve and oversee cybersecurity risk management measures.

---

## 2. The Lex Specialis Relationship: DORA Takes Precedence (with Limits)

### The Governing Provision: NIS2 Art. 4

NIS2 Art. 4(1) establishes a **lex specialis carve-out**: where a sector-specific EU legal act imposes requirements relating to cybersecurity risk management or incident reporting that are "at least equivalent" to the obligations in NIS2, the sector-specific act applies instead of (or alongside) NIS2.

DORA, which entered into application on **17 January 2025**, is explicitly such a lex specialis instrument for financial entities in scope, including credit institutions (banks). The European Supervisory Authorities (ESAs — EBA, ESMA, EIOPA) have confirmed this alignment in their joint supervisory statements.

### Practical Meaning

| Obligation Area | Governing Instrument | Notes |
|---|---|---|
| ICT risk management framework | DORA (Arts. 5–16) | Equivalent to NIS2 Art. 21; DORA is more prescriptive |
| Major ICT incident reporting | DORA (Arts. 17–23) | Replaces NIS2 Art. 23 timelines for financial entities |
| Digital operational resilience testing | DORA (Arts. 24–27, TLPT) | No NIS2 equivalent at this level of detail |
| ICT third-party risk / supply chain | DORA (Arts. 28–44) | More granular than NIS2 Art. 26 for financial entities |
| Governance and management body accountability | **Both** DORA and NIS2 Art. 20 | NIS2 adds personal liability dimension; confirm national transposition |
| Incident cross-border coordination | **Both** — different notification channels | NIS2: CSIRT; DORA: competent financial authority (e.g., ECB, national CA) |
| Supervisory cooperation | **Both** — different supervisors | NIS2 competent authority vs. financial prudential supervisor |

### Where NIS2 Still Bites

Even with DORA as lex specialis, NIS2 is **not fully displaced** for banks:

1. **Governance (Art. 20):** Member State transpositions may impose personal liability on management body members that goes beyond DORA's governance chapter. You must check your jurisdiction's NIS2 transposition law.
2. **Supply chain (Art. 26):** ENISA-coordinated critical ICT supply chain risk assessments under NIS2 can still identify your organisation and impose additional requirements.
3. **Notification to NIS2 CSIRT:** Where an incident has cross-border impact beyond the financial sector (e.g., systemic IT infrastructure outage affecting non-financial services), NIS2 notification obligations to the national CSIRT may apply concurrently.
4. **National transposition variations:** Not all EU Member States have transposed NIS2 identically. If you operate branches or subsidiaries across multiple EU jurisdictions, each Member State's NIS2 implementing law may treat the lex specialis carve-out differently.
5. **Residual NIS2 obligations:** If a Member State's NIS2 transposition does not fully map DORA as equivalent (which is a live policy question in some jurisdictions as of 2025–2026), both sets of obligations may apply in parallel.

---

## 3. Incident Reporting: Two Channels, Not One

This is the area where the interaction is most operationally complex.

### DORA Incident Reporting (Arts. 17–23)
- **Initial notification:** Within 4 hours of classification as a major incident; no later than 24 hours after becoming aware.
- **Intermediate report:** Within 72 hours.
- **Final report:** Within 1 month.
- Reported to: **Competent financial authority** (e.g., ECB for significant institutions under the SSM, or national competent authority for less significant institutions, national banking regulator).

### NIS2 Incident Reporting (Art. 23)
- **Early warning:** Within **24 hours** (suspected malicious act? cross-border impact?).
- **Incident notification:** Within **72 hours** (initial assessment, severity, IoCs).
- **Final report:** Within **1 month**.
- Reported to: **National CSIRT** or designated competent NIS2 authority.

### Practical Implication

For a major operational or cybersecurity incident at your bank, you may need to file notifications with **two different authorities** (financial supervisor and NIS2 CSIRT) on **overlapping but not identical timelines**, with **different content requirements**. Your incident response playbooks and SOC escalation procedures must explicitly handle both channels.

**Recommendation:** Establish a unified incident classification matrix that triggers both reporting streams simultaneously, with a single owner (typically the CISO or delegated Head of Cyber Incident Response) coordinating both filings. Engage proactively with both your financial competent authority and your national CSIRT to agree on joint notification protocols where permissible.

---

## 4. Do You Need Two Separate Compliance Programmes? No — But You Need a Dual-Framework Programme

Running two entirely separate compliance programmes would create duplicative effort, inconsistent controls, and governance confusion. The recommended approach is a **single integrated ICT and cyber resilience programme** with explicit dual-framework mapping.

### Programme Architecture

**Tier 1: Unified Control Framework**
Build your control library once, mapped to both DORA regulatory technical standards (RTS) and NIS2 Art. 21 measures. ISO 27001:2022 provides a useful common control reference, as its Annex A maps closely to NIS2 Art. 21 (and ISO 27001 certification provides strong evidence of NIS2 compliance, though it does not substitute formal NIS2 obligations).

**Tier 2: Regulatory Obligation Register**
Maintain a consolidated register that for each obligation records:
- Source instrument (DORA article / NIS2 article)
- Implementing control(s)
- Responsible owner
- Evidence artefact
- Relevant supervisory authority

**Tier 3: Separate Supervisory Interfaces**
Despite integrated controls, you need distinct interfaces for:
- Financial supervisor (DORA): ECB/SSM or national banking regulator
- NIS2 competent authority: national designated authority (often the national cybersecurity agency or sector regulator)
- National CSIRT: for incident early warnings

### NIS2 Art. 21 Measures vs. DORA Equivalents

| NIS2 Art. 21 Measure | DORA Equivalent | Gap? |
|---|---|---|
| 1. Risk analysis and information system security policies | DORA Art. 5 (ICT risk management framework) | Generally covered; DORA more prescriptive |
| 2. Incident handling | DORA Arts. 17–23 | DORA more detailed; maintain NIS2 CSIRT notification |
| 3. Business continuity, BCP, DR, crisis management | DORA Arts. 11–12 (BCP, backup, recovery) | Broadly equivalent |
| 4. Supply chain security | DORA Arts. 28–44 (third-party risk) | DORA more granular; NIS2 Art. 26 ENISA assessment still applies |
| 5. Security in NIS acquisition, development, maintenance | DORA Art. 9 (information security), Art. 10 (detection) | Check patching/vulnerability management gap |
| 6. Effectiveness assessment policies | DORA Art. 6 (ICT risk management framework review) | Broadly equivalent |
| 7. Cyber hygiene and training | DORA Art. 13 (learning and evolving), Art. 5(4) (training) | Broadly covered; verify NIS2 management training requirement |
| 8. Cryptography and encryption policies | DORA Art. 9(2) (data integrity/encryption) | Check for explicit cryptography policy documentation gap |
| 9. HR security, access control, asset management | DORA Art. 9 (general) | May need to explicitly document HR security elements |
| 10. MFA, continuous authentication, secured comms | DORA Art. 9(4) | Generally covered; verify MFA scope documentation |

**Key gap area:** NIS2 Art. 20 management body training and personal liability obligations — DORA requires management body "ultimate responsibility" for ICT risk but national NIS2 transpositions may add explicit personal liability exposure not present in DORA. This must be verified jurisdiction by jurisdiction.

---

## 5. Governance: Art. 20 and Management Body Obligations

Under NIS2 Art. 20, your **management body** (board of directors / supervisory board) must:
1. **Approve** cybersecurity risk management measures.
2. **Oversee** their implementation.
3. **Complete regular cybersecurity training** — and ensure senior management does too.
4. Be personally accountable under national law.

DORA Art. 5 similarly requires the management body to define and approve the ICT risk management framework and bear ultimate responsibility. However, personal liability is a NIS2 concept that DORA does not replicate.

**Action:** Establish a board-level Cyber and Digital Resilience Oversight Charter that explicitly references both DORA and NIS2 obligations. Ensure board cybersecurity training programmes cover both regulatory frameworks. Obtain documented board approval of both your DORA ICT risk management framework and your NIS2 cybersecurity risk management measures — this can be a single document with dual-framework references.

---

## 6. Supervisory Interaction and Coordination

A large European bank may be subject to multiple supervisors simultaneously:
- **ECB / national banking regulator** (DORA supervisor, potentially also NIS2 competent authority if the Member State designates the financial regulator)
- **National NIS2 competent authority** (often the national cybersecurity agency, e.g., BSI in Germany, ANSSI in France, NCSC-NL in Netherlands)
- **National CSIRT** for incident early warnings

In some Member States, the financial sector NIS2 competent authority has been designated as the financial regulator, which reduces but does not eliminate the dual-supervisor complexity.

**Recommendation:** Map your full supervisory matrix by jurisdiction for every entity in your group. Engage proactively with all relevant authorities to establish communication protocols, understand their expectations on evidence of DORA-as-NIS2-equivalence, and agree on joint inspection coordination mechanisms where possible.

---

## 7. Penalty Exposure Analysis

As an Essential Entity under NIS2, your maximum NIS2 penalty exposure is:
- **€10,000,000 or 2% of global annual turnover** (whichever is higher)

For a large European bank, global turnover will almost certainly make the 2% figure the binding cap — this represents very substantial financial exposure.

DORA penalties are set by Member States and vary, but are similarly material for systemically important institutions.

**Critical note:** Penalties under DORA and NIS2 are imposed by different authorities and are not mutually exclusive. A single major ICT incident could in principle trigger both DORA enforcement by the financial supervisor and NIS2 enforcement by the cybersecurity authority, resulting in penalties under both instruments. This double-jeopardy risk underscores the importance of maintaining documented compliance evidence against both frameworks.

---

## 8. Recommended Next Steps

1. **Jurisdiction mapping:** For each EU Member State where you have regulated entities, confirm (a) how NIS2 has been transposed, (b) which authority is designated as NIS2 competent authority for banking, and (c) whether that authority has formally confirmed DORA as equivalent lex specialis.

2. **Obligation gap analysis:** Using the Art. 21 vs. DORA mapping table above, identify any obligations in NIS2 not fully addressed by your existing DORA programme, particularly: management body personal liability documentation, cryptography policy documentation, HR security, and CSIRT notification procedures.

3. **Unified incident response playbook:** Update your incident response procedures to explicitly include a dual-notification workflow (DORA channel to financial supervisor + NIS2 channel to CSIRT), with clear escalation triggers, timeline tracking, and content requirements for each channel.

4. **Board-level documentation:** Obtain explicit board approval of cybersecurity risk management measures framed to satisfy both DORA Art. 5 and NIS2 Art. 20. Document management body cybersecurity training completion.

5. **Supply chain review:** Ensure your third-party ICT risk programme (DORA Chapter V) also addresses the NIS2 Art. 26 supply chain risk assessment requirements, including any ENISA-coordinated critical supply chain assessments that may affect your sector.

6. **Integrated control register:** Build or update your GRC tooling to map each control to both DORA RTS requirements and NIS2 Art. 21 measures, enabling single-pane-of-glass compliance evidence.

7. **Cross-border coordination:** If you operate in multiple EU Member States, establish a cross-border NIS2 coordination mechanism for significant incidents with cross-border impact, as required under NIS2.

---

## Summary

| Question | Answer |
|---|---|
| Does NIS2 apply to you? | Yes — you are an Essential Entity (banking, Annex I) |
| Does DORA take precedence over NIS2? | Generally yes, for specific ICT risk management and incident reporting obligations (lex specialis, Art. 4 NIS2), but NIS2 is not fully displaced |
| Which areas remain NIS2-specific? | Management body personal liability; CSIRT notification; ENISA supply chain assessments; national transposition variations; cross-border incident coordination |
| Do you need two separate programmes? | No — build one integrated programme with dual-framework mapping |
| What is your biggest risk? | Dual penalty exposure (NIS2 + DORA) from a major incident; management body personal liability under NIS2; multi-jurisdiction supervisory complexity |

The most important immediate action is to confirm — jurisdiction by jurisdiction — whether your national NIS2 transposition formally recognises DORA as the lex specialis equivalent, and to close any governance and notification gaps that exist between the two frameworks in the interim.

# NIS2 and DORA: Interaction, Precedence, and Compliance Programme Design for European Banks

## Executive Summary

As CISO of a large European bank subject to both the Network and Information Security Directive 2 (NIS2) and the Digital Operational Resilience Act (DORA), you are operating within a carefully designed regulatory framework where DORA takes legal precedence over NIS2 for your institution — but this does not eliminate your NIS2 obligations, and the two frameworks are more complementary than conflicting. You do not need two fully separate compliance programmes; a unified, integrated programme is both feasible and recommended. However, you do need to be precise about which regulation governs which obligation and how to evidence compliance to two potentially different supervisory bodies.

---

## 1. Understanding the Two Frameworks

### NIS2 (Directive (EU) 2022/2555)

NIS2 is a directive that member states transposed into national law by 17 October 2024. It establishes cybersecurity risk management and incident reporting obligations for "essential" and "important" entities across critical sectors. Large banks are classified as "essential entities" under Annex I (financial market infrastructures) or under the financial sector category.

Key obligations under NIS2 include:
- Cybersecurity risk management measures (Article 21)
- Supply chain security
- Incident reporting to national Computer Security Incident Response Teams (CSIRTs) or competent authorities within defined timeframes (24-hour early warning, 72-hour notification, one-month final report)
- Management body accountability and training
- Use of appropriate technical and organisational measures (encryption, MFA, access control, vulnerability handling, etc.)

### DORA (Regulation (EU) 2022/2554)

DORA is a regulation (directly applicable across the EU without transposition) that has applied since 17 January 2025. It establishes a comprehensive ICT risk management and digital operational resilience framework specifically for financial entities, including credit institutions (banks), investment firms, payment institutions, and others.

Key obligations under DORA include:
- ICT risk management framework (Chapter II)
- ICT-related incident classification, management, and reporting (Chapter III) — including to competent financial supervisory authorities
- Digital operational resilience testing, including Threat-Led Penetration Testing (TLPT) for significant institutions (Chapter IV)
- ICT third-party risk management and contractual requirements (Chapter V)
- Information sharing arrangements (Chapter VI)
- Oversight of Critical ICT Third-Party Providers (CTPPs) by ESAs (EBA, ESMA, EIOPA)

---

## 2. Which Takes Precedence? The Lex Specialis Principle

### DORA as Lex Specialis

DORA explicitly establishes itself as the sector-specific law (lex specialis) for financial entities with respect to ICT risk and digital operational resilience. Recital 16 and Article 2(1) of DORA confirm its scope, and critically, **Article 1(2) of NIS2** provides that where sector-specific Union legal acts require financial entities to adopt cybersecurity risk management measures or incident reporting obligations that are "at least equivalent" to those in NIS2, the relevant NIS2 provisions do not apply to those entities.

This means:
- DORA, being a directly applicable regulation (not a directive) with more detailed and sector-specific requirements, supersedes the equivalent NIS2 obligations for financial entities covered by DORA.
- Financial entities are effectively carved out of the relevant NIS2 operational obligations (Articles 21 and 23 of NIS2 — risk management measures and incident reporting) to the extent DORA covers the same ground.

### What This Means in Practice

| Area | Governing Regulation |
|------|---------------------|
| ICT risk management framework | DORA (Chapter II) |
| ICT incident reporting to financial supervisor | DORA (Chapter III) — to EBA/NCAs |
| Incident reporting to CSIRT/NIS2 authority | NIS2 still applies for network/information security incidents outside DORA's scope |
| TLPT / penetration testing | DORA (Chapter IV) |
| ICT third-party risk (contractual requirements) | DORA (Chapter V) |
| Supply chain security (broader) | NIS2 (Article 21(2)(d)) — supplements DORA |
| Management body accountability | Both — DORA Article 5 and NIS2 Article 20 |
| Vulnerability disclosure | NIS2 (Article 12) |
| National CSIRT cooperation | NIS2 |
| Sanctions/enforcement | DORA: financial supervisors (NCAs, ESAs); NIS2: national NIS competent authorities |

### Important Nuance: NIS2 Is Not Fully Displaced

The NIS2 carve-out is not a blanket exemption. NIS2 obligations that fall outside DORA's scope — such as obligations relating to the general security of network and information systems beyond ICT risk, broader supply chain obligations, vulnerability handling at a national level, and coordination with national CSIRTs — continue to apply. Member states may also impose additional NIS2-derived obligations in their national transpositions that go beyond the baseline, which requires monitoring.

Additionally, DORA's equivalence must genuinely be assessed. The European Supervisory Authorities (EBA, ESMA, EIOPA) have issued regulatory technical standards (RTS) and implementing technical standards (ITS) under DORA. If any specific NIS2 requirement is not demonstrably covered by DORA and its subordinate legislation, NIS2 continues to apply to fill that gap.

---

## 3. Do You Need Two Separate Compliance Programmes?

**No — but you need an integrated programme with careful dual-mapping.**

Running two entirely separate compliance programmes would be duplicative, resource-inefficient, and likely counterproductive (creating inconsistencies between frameworks). The better approach is a single, unified ICT and cyber resilience governance programme that:

### a) Uses DORA as the Primary Structural Framework

Because DORA is more prescriptive and detailed for financial entities, build your governance architecture, risk management lifecycle, incident response, third-party risk, and testing programme around DORA's requirements. This ensures you meet the higher bar of your primary sectoral regulator (the NCA and ESAs).

### b) Maps NIS2 Residual Obligations onto the DORA Structure

Identify where NIS2 requirements are not fully addressed by DORA (e.g., national CSIRT reporting channels, broader supply chain considerations, vulnerability disclosure coordination) and integrate these as supplementary controls or process steps within your existing DORA-compliant framework. This is an additive layer, not a parallel structure.

### c) Maintains Clear Regulatory Reporting Lanes

DORA and NIS2 have different reporting channels:
- **DORA incidents**: Report to your financial sector competent authority (e.g., ECB for significant credit institutions under SSM, or national banking supervisor) using DORA's harmonised incident templates (per EBA ITS on major incident reporting).
- **NIS2 incidents**: Report to the national NIS2 competent authority and/or CSIRT. In practice, the regulators are working on coordination mechanisms (e.g., Article 42 of DORA mandates cooperation between financial supervisors and NIS2 authorities), but operationally, you must understand which body receives which notification and within what timeframe.

### d) Addresses Management Accountability Jointly

Both DORA (Article 5) and NIS2 (Article 20) impose obligations on the management body. A single board-level ICT and cyber risk governance framework, with appropriate training and oversight mechanisms, satisfies both simultaneously.

### e) Third-Party Risk: Leverage DORA's Deeper Requirements

DORA's Chapter V on ICT third-party risk management is more prescriptive than NIS2's supply chain security provisions. A DORA-compliant third-party risk programme (including mandatory contractual clauses for ICT service providers) will generally meet or exceed NIS2's supply chain requirements.

---

## 4. Key Practical Recommendations

1. **Conduct a gap/overlap analysis** mapping DORA requirements (and associated RTS/ITS) against NIS2 Articles 21 and 23, and identify any NIS2 residual obligations not covered by DORA in your jurisdiction's national transposition law.

2. **Establish dual notification SOPs**: Your incident response playbooks should identify at decision points which regulator(s) must be notified, on what timeline, using what format. DORA and NIS2 timelines differ and regulators are distinct; operational clarity here is essential.

3. **Engage both your financial supervisor and NIS2 competent authority** to clarify their expectations around the lex specialis carve-out, particularly for incidents that may span both frameworks. Some national authorities have issued joint guidance.

4. **Monitor DORA RTS/ITS implementation**: Several DORA technical standards (e.g., on TLPT, on major incident reporting, on third-party risk) are either final or in consultation. Ensure your programme incorporates these as they take effect.

5. **Track national NIS2 transpositions**: As a large bank operating potentially across multiple EU jurisdictions, the NIS2 residual obligations may vary by member state. Your NIS2 exposure is defined by national law, not the directive text directly.

6. **Coordinate with your DPO and legal team**: Where incidents involve personal data, GDPR notification obligations (72-hour reporting to data protection authorities) layer on top of DORA and NIS2. All three frameworks may be triggered simultaneously by a significant incident.

---

## 5. Summary

| Question | Answer |
|----------|--------|
| Does DORA take precedence over NIS2? | Yes, as lex specialis for financial entities under Article 1(2) of NIS2, DORA governs ICT risk and incident reporting obligations where it is at least equivalent |
| Are you fully exempt from NIS2? | No. NIS2 continues to apply where DORA does not cover the same ground (e.g., national CSIRT reporting, some supply chain/vulnerability obligations) |
| Do you need two separate programmes? | No. Build one integrated programme on the DORA framework and add NIS2 residual obligations as supplementary elements |
| Who supervises what? | Financial supervisor (NCA/ECB) for DORA; national NIS2 authority for residual NIS2 obligations |
| What is the greatest operational risk? | Dual incident reporting failures — ensure your SOPs clearly specify reporting lanes, timelines, and formats for both regulators |

The regulatory design intent is clear: DORA was created precisely to give financial entities a coherent, sector-specific resilience framework, avoiding the duplication and fragmentation that would result from applying generic cybersecurity directives on top of detailed sectoral rules. Your compliance programme design should reflect that intent.

# CCPA/CPRA Applicability and Core Obligations Analysis

## Are You Subject to CCPA/CPRA?

**Yes — your business is subject to CCPA/CPRA.**

Under California law (Cal. Civ. Code §1798.100 et seq.), a for-profit business that does business in California must comply with CCPA/CPRA if it meets **at least one** of three thresholds. Your company meets the first threshold:

| Threshold | Requirement | Your Status |
|---|---|---|
| Revenue | Annual gross revenues exceeding **$25 million** | **MET** — $30M annual revenue exceeds the $25M threshold |
| Data Volume | Annually buys, sells, receives, or shares PI of **100,000+ consumers or households** | Not met — 80,000 California customers is below 100,000 |
| Revenue from PI | Derives **50%+ of annual revenues** from selling/sharing PI | Presumed not met for a standard e-commerce business |

Your $30 million annual revenue alone triggers full CCPA/CPRA compliance obligations. Even though your 80,000 California customers per year falls below the 100,000-consumer data volume threshold, the revenue threshold is satisfied independently.

---

## Core Obligations

### 1. Privacy Notice at Collection
You must inform consumers **at or before** collecting their personal information (PI) about:
- The categories of PI being collected
- The purposes for which PI will be used
- Whether PI is sold or shared with third parties
- Retention periods for each category of PI (CPRA requirement)
- A link to your full privacy policy

For an e-commerce site, this means clear disclosures at account creation, checkout, and any point where additional data is collected (e.g., email signups, reviews).

### 2. Comprehensive Privacy Policy
Your privacy policy must include:
- All categories of PI collected in the last 12 months
- The business or commercial purposes for each category
- Categories of third parties to whom PI is disclosed
- A description of all consumer rights and how to exercise them
- Contact information for submitting consumer requests
- A **"Do Not Sell or Share My Personal Information"** link (if you sell/share PI)
- A **"Limit the Use of My Sensitive Personal Information"** link (if applicable)

### 3. Consumer Rights Fulfillment
You must establish processes to honor the following rights with a **45-day response deadline** (extendable by another 45 days with notice):

| Right | Description |
|---|---|
| **Right to Know** | Consumers can request the specific PI you've collected about them, its sources, purposes, and who it's been shared with |
| **Right to Delete** | Consumers can request deletion of their PI (subject to limited exceptions, e.g., completing a transaction, legal obligations) |
| **Right to Correct** | Consumers can request correction of inaccurate PI (CPRA addition) |
| **Right to Data Portability** | PI must be delivered in a portable, usable format upon request |
| **Right to Non-Discrimination** | You cannot deny service, charge higher prices, or penalize consumers for exercising their privacy rights |

Additionally:
- **Right to Opt-Out of Sale/Sharing**: Must be honored **immediately** upon request
- **Right to Limit SPI Use**: Must be honored within **15 business days** (if you collect sensitive personal information)
- **Minors**: If any customers are under 16, you need opt-in consent before selling/sharing their PI

### 4. Opt-Out Mechanisms
- Place a **"Do Not Sell or Share My Personal Information"** link on your homepage if you sell or share PI (e.g., through advertising pixels, affiliate data sharing, data brokers)
- Honor **Global Privacy Control (GPC)** signals — under CPPA guidance and California court decisions, GPC must be treated as a valid opt-out from sale and sharing
- Implement a **"Limit the Use of My Sensitive Personal Information"** link if you process SPI (e.g., precise geolocation, health data, account credentials) beyond necessary purposes

### 5. Data Minimization and Purpose Limitation (CPRA)
- Collect only PI that is **adequate, relevant, and limited** to what is necessary for the disclosed purpose
- Do not use PI for purposes not disclosed to consumers at collection
- This is particularly relevant for e-commerce analytics, behavioral advertising, and personalization use cases

### 6. Retention Limits (CPRA)
- Disclose retention periods or the criteria used to determine them for each category of PI
- Do not retain PI longer than reasonably necessary for the disclosed purpose
- This applies to customer purchase history, account data, browsing data, and marketing lists

### 7. Service Provider Contracts
Any vendor that processes customer PI on your behalf (payment processors, fulfillment services, email platforms, analytics tools, CDPs) must have written contracts that include:
- Limitations on how the vendor may use your customers' PI
- Prohibition on selling or sharing PI without your authorization
- Obligations to comply with consumer deletion/correction requests
- Your right to audit the vendor's compliance
- Data deletion obligations upon contract termination

Vendors meeting these requirements qualify as **Service Providers** — their receipt of PI is not a "sale" under CCPA/CPRA.

### 8. Sensitive Personal Information (SPI) — If Applicable
As an e-commerce company, you may collect SPI such as:
- Precise geolocation (for delivery tracking or targeted offers)
- Account log-in credentials (username + password combinations)
- Health/medical data (if selling health-related products with health-related personalization)

If you collect SPI, consumers have the right to **limit its use and disclosure** to only what is necessary to provide the requested service.

### 9. Cybersecurity Audits and Risk Assessments (CPRA — Pending Rulemaking)
Businesses processing PI that presents significant risk must conduct **annual cybersecurity audits** and submit **risk assessments** to the California Privacy Protection Agency (CPPA). The exact scope for e-commerce businesses at your scale is subject to final CPPA rulemaking, but you should monitor this requirement.

---

## Penalty Exposure

Non-compliance carries significant financial risk:
- **Unintentional violations**: Up to **$2,500 per violation**
- **Intentional violations**: Up to **$7,500 per violation**
- **Violations involving minors' PI**: Always treated as intentional — up to **$7,500 per violation**
- **Data breach private right of action**: Statutory damages of **$100–$750 per consumer per incident** (class action eligible) if a breach results from failure to implement reasonable security measures

With 80,000 California customers, even a modest percentage of consumers affected by a systemic violation or data breach creates substantial aggregate liability.

---

## Immediate Next Steps

1. **Conduct a data inventory**: Map what PI you collect, from whom, for what purposes, how long you retain it, and who you share it with
2. **Audit your privacy policy**: Update it to include all CPRA-required disclosures (retention periods, right to correct, updated opt-out language)
3. **Implement a consumer request intake process**: Set up a webform or toll-free number to receive and track consumer rights requests within required timelines
4. **Review advertising and data sharing**: Determine whether any PI flows to ad networks, analytics platforms, or data brokers constitute a "sale" or "sharing" — if so, implement opt-out mechanisms and GPC signal handling
5. **Audit vendor contracts**: Ensure all service providers have CCPA/CPRA-compliant data processing agreements in place
6. **Train staff**: Ensure customer-facing and data-handling teams understand how to identify and escalate consumer rights requests

---

*This analysis is based on CCPA (Cal. Civ. Code §1798.100 et seq.) and CPRA (Proposition 24, effective January 1, 2023). Consult qualified legal counsel for advice specific to your business operations and data practices.*

# CCPA/CPRA Applicability and Core Obligations

## Are You Subject to CCPA/CPRA?

**Yes, your company is subject to CCPA as amended by CPRA.**

The California Consumer Privacy Act (CCPA), as amended and expanded by the California Privacy Rights Act (CPRA, effective January 1, 2023), applies to for-profit businesses that do business in California and meet **any one** of the following thresholds:

| Threshold | Your Company | Met? |
|---|---|---|
| Annual gross revenues exceeding $25 million | $30M annual revenue | **YES** |
| Buys, sells, or shares personal information of 100,000+ consumers or households annually | ~80,000 California customers | No (below threshold) |
| Derives 50%+ of annual revenue from selling or sharing consumers' personal information | Not specified | Unknown |

**Your company meets the first threshold** — annual gross revenues of $30 million exceed the $25 million threshold. This alone is sufficient to trigger CCPA/CPRA applicability, regardless of the number of consumers whose data you process.

---

## Core Obligations Under CCPA/CPRA

### 1. Privacy Notice / Privacy Policy Requirements

You must provide consumers with a **comprehensive privacy notice** at or before the point of collection that discloses:

- Categories of personal information collected
- Purposes for which each category is collected and used
- Categories of third parties with whom personal information is shared
- Consumer rights and how to exercise them
- Retention periods (or criteria used to determine retention)
- Whether personal information is sold or shared (and a link to opt out if so)

Your privacy policy must be updated **at least every 12 months**.

### 2. Consumer Rights You Must Honor

CCPA/CPRA grants California consumers the following rights, which you are obligated to fulfill:

- **Right to Know**: Consumers can request disclosure of what personal information you have collected about them, the sources, purposes, and any third parties it has been shared with (covering the past 12 months, or up to 24 months under CPRA).
- **Right to Delete**: Consumers can request deletion of their personal information, subject to limited exceptions (e.g., completing a transaction, security purposes, legal obligations).
- **Right to Correct**: Under CPRA, consumers can request correction of inaccurate personal information you hold about them.
- **Right to Opt-Out of Sale or Sharing**: If you sell or share personal information, consumers have the right to opt out. You must display a "Do Not Sell or Share My Personal Information" link prominently.
- **Right to Limit Use of Sensitive Personal Information**: Consumers can direct you to limit the use of sensitive personal information (e.g., precise geolocation, financial account data, health data, biometrics) to only what is necessary for providing services.
- **Right to Non-Discrimination**: You cannot penalize consumers for exercising their CCPA/CPRA rights (e.g., no denying goods, charging different prices, or providing a lower quality of service).

### 3. Request Handling Requirements

- Establish and maintain **at least two designated methods** for submitting consumer requests (e.g., a toll-free phone number and a web form).
- Respond to verified consumer requests **within 45 days** (extendable by another 45 days with notice).
- Verify the identity of the requestor before fulfilling requests.
- Provide requested information **free of charge**, up to twice per 12-month period.
- Maintain records of consumer requests and responses for **24 months**.

### 4. Contracts with Service Providers, Contractors, and Third Parties

- Enter into **written contracts** with all service providers and contractors who process personal information on your behalf. These contracts must include CPRA-mandated terms restricting use of personal information, prohibiting sales or sharing, and requiring compliance and cooperation with consumer rights.
- Conduct reasonable **due diligence** on service providers and take action if you discover they are misusing personal information.

### 5. Data Minimization and Purpose Limitation

Under CPRA:
- Collect only the personal information **reasonably necessary** for the disclosed purposes.
- Do not use personal information for purposes that are **incompatible** with the disclosed purpose of collection.

### 6. Data Retention Limitations

- Retain personal information **no longer than reasonably necessary** for the disclosed purpose.
- Disclose your retention periods (or the criteria used to determine them) in your privacy policy.

### 7. Security Requirements

- Implement and maintain **reasonable security measures** appropriate to the nature of the personal information you collect (this obligation predates CCPA and is codified in California Civil Code § 1798.81.5).
- CPRA's private right of action (and statutory damages of $100–$750 per consumer per incident) applies specifically to **data breaches** resulting from failure to implement reasonable security.

### 8. Sensitive Personal Information

CPRA introduces special rules for **Sensitive Personal Information (SPI)**, which includes:
- Social Security numbers, driver's license numbers, financial account credentials
- Precise geolocation
- Race, ethnicity, religion
- Health, medical, and genetic data
- Biometric data used for identification
- Sexual orientation or sex life
- Communications content (unless you are the intended recipient)

If you collect SPI, you must disclose this and honor consumers' right to limit its use.

---

## Enforcement

- Enforcement is handled by the **California Privacy Protection Agency (CPPA)** and the **California Attorney General**.
- Civil penalties up to **$2,500 per unintentional violation** and **$7,500 per intentional violation** (or involving a minor's data).
- Private right of action for **data breaches** only, with statutory damages of $100–$750 per consumer per incident.

---

## Recommended Immediate Next Steps

1. **Audit your data practices**: Map what personal information you collect, why, where it is stored, and with whom it is shared.
2. **Update your privacy policy** to meet CCPA/CPRA disclosure requirements.
3. **Implement consumer request workflows**: Set up intake, verification, response, and record-keeping processes.
4. **Review vendor contracts**: Ensure all service providers have CPRA-compliant data processing agreements.
5. **Assess sensitive personal information**: Identify whether you collect any SPI and add appropriate controls and disclosures.
6. **Implement a "Do Not Sell or Share" mechanism** if you sell or share personal information.
7. **Train staff** on consumer rights obligations and your internal response procedures.

---

*Note: This analysis is based on CCPA (Cal. Civ. Code § 1798.100 et seq.) as amended by CPRA (effective January 1, 2023). Laws change; consult qualified legal counsel to confirm your obligations and tailor compliance measures to your specific business operations.*

# Handling a Combined CCPA Right to Know + Right to Delete Request

A California resident has submitted two simultaneous requests: (1) a Right to Know (access) request and (2) a Right to Delete request. Here is a complete, step-by-step guide for handling both, including identity verification and all applicable exceptions.

---

## Step 1: Intake and Logging

**Immediately upon receipt:**
- Log both requests with a precise timestamp. The 45-calendar-day response clock starts from the date of receipt, not the date verification is completed.
- Assign a tracking ID to each request.
- Confirm receipt to the consumer in writing (email or postal mail), acknowledging both requests.
- Verify you have at least two intake channels available to the consumer per §1798.130 (e.g., toll-free phone and a web form or email).

---

## Step 2: Identity Verification

You must verify the consumer's identity before disclosing or deleting any personal information. The standard scales with the sensitivity of the data involved.

### Standard Right to Know (non-sensitive PI)
Match **at least 2 data points** the business already holds on file, for example:
- Full name + email address on record
- Full name + mailing address
- Account number + date of birth

### If the request involves Sensitive Personal Information (SPI)
(SSNs, financial credentials, precise geolocation, biometric data, health data, racial/ethnic origin, sexual orientation, etc.)

Match **at least 3 data points** plus require a **signed declaration under penalty of perjury** from the consumer confirming they are the individual whose PI is being requested.

### If the request is submitted via an Authorized Agent
- Require written, signed authorization from the consumer permitting the agent to act on their behalf.
- Verify the agent's identity independently.
- For delete requests submitted by an agent without power of attorney, you may also verify directly with the consumer.

### Failure to Verify
If the consumer cannot be verified after reasonable attempts, deny the request and notify the consumer explaining why and that they may re-submit with sufficient verification.

---

## Step 3: Handling the Right to Know Request (§1798.110 / §1798.115)

### What Must Be Disclosed
Once identity is verified, compile and deliver the following:

1. **Specific pieces of PI** collected about this consumer (names, email addresses, IP addresses, purchase history, browsing history, device identifiers, geolocation, etc.).
2. **Categories of PI** collected.
3. **Categories of sources** from which the PI was collected (e.g., directly from consumer, third-party data brokers, cookies/tracking pixels).
4. **Business or commercial purposes** for which PI was collected, sold, or shared.
5. **Categories of third parties** to whom PI was disclosed.
6. **Categories of PI sold or shared** and the categories of third parties who received it.

### Scope of the Disclosure
- Under CPRA (effective January 1, 2023), there is no longer a strict 12-month look-back limit for PI collected after January 1, 2022. You must disclose all PI collected and retained.
- For PI collected before January 1, 2022, the 12-month look-back applies.

### Where to Search
Search all systems that may hold PI: CRM, marketing automation, analytics platforms, ad tech stacks, support ticketing systems, billing systems, email platforms, data warehouses, and any third-party service providers processing PI on your behalf.

### Exceptions — When You Can Withhold Specific PI
You may decline to disclose specific pieces of PI if:

| Exception | Description |
|---|---|
| Third-party trade secrets | Disclosing would reveal trade secrets belonging to a third party |
| Legal conflict | Disclosure would conflict with federal or state law (e.g., ongoing law enforcement investigation) |
| One-time transaction | PI was collected for a single transaction and was not retained |
| Internal operations only | PI is solely used for internal purposes consistent with the context of collection |
| Transaction completion | PI is solely used to complete the transaction for which it was collected |

Document the specific exception invoked in writing and inform the consumer that some PI was withheld and why (at a category level, without revealing the withheld content).

### Format and Delivery
Deliver the response in a **portable, readily usable format** (e.g., a structured PDF or CSV). Do not require the consumer to create an account to receive the response if they did not have one when submitting the request.

**Deadline:** 45 calendar days from receipt. If you need more time, notify the consumer within the original 45-day window and take up to an additional 45 days (90 days total).

---

## Step 4: Handling the Right to Delete Request (§1798.105)

### Scope of Deletion
The deletion obligation covers:
- All PI held in your own systems and records.
- PI held by your **service providers** and **contractors** — you must direct them in writing to delete the PI as well.

### Exceptions — When You Can Retain PI

You may decline to delete (or retain specific categories of PI) if retention is necessary to:

| # | Exception | Example |
|---|---|---|
| 1 | **Complete a transaction or perform a contract** | Active subscription or pending order |
| 2 | **Detect security incidents; protect against fraud/illegal activity** | Fraud detection logs, active investigation |
| 3 | **Fix errors impairing intended functionality** | Bug fix requiring the data |
| 4 | **Free speech / another consumer's right to free speech** | Rare; applies to journalism-like contexts |
| 5 | **Legal obligation** (§1798.145(a)) | Tax records (IRS 7-year retention), financial records, litigation holds |
| 6 | **Internal purposes compatible with collection context** (CPRA, narrow) | Aggregate analytics that cannot be re-linked to the individual |
| 7 | **Research, journalism, or statistical public interest** | Academic research datasets |

**Practical note:** Legal holds are the most commonly invoked exception. If litigation is pending or reasonably anticipated, retain a litigation hold memo and preserve the relevant PI. Explain to the consumer at a high level why data cannot be deleted.

### Deletion Workflow

1. **Verify identity** (same as above — do not skip even for deletion).
2. **Identify all PI records** across all systems.
3. **Evaluate exceptions** for each category of PI — apply exceptions narrowly. Document the reasoning in writing.
4. **Execute deletion** for all PI not covered by an exception:
   - Delete from primary databases.
   - Delete from backups (or flag for deletion at the next backup cycle, with a note that the data is to be treated as deleted in the interim).
   - Delete from internal analytics or data warehouse systems.
5. **Notify service providers and contractors** in writing to delete the consumer's PI from their systems. Confirm they have done so.
6. **Respond to the consumer** within 45 days confirming:
   - What was deleted, and
   - What (if anything) was retained and under which exception.

**Deadline:** 45 calendar days (extendable by 45 more days with notice).

---

## Step 5: Non-Discrimination

Remind relevant internal teams: you **cannot** penalize this consumer for exercising their CCPA rights. Do not:
- Deny them goods or services.
- Charge a higher price.
- Provide a lower quality of service.
- Downgrade their account tier.
- Flag them internally in a way that results in worse treatment.

---

## Step 6: Record-Keeping

Retain the following for **at least 24 months** (required for businesses processing PI of 10 million or more consumers/households; recommended for all covered businesses):
- A copy of the request (both the Right to Know and Right to Delete requests).
- The verification steps taken and the outcome.
- The response provided to the consumer.
- Any exceptions invoked and the documented reasoning.
- Written instructions sent to service providers and contractors.
- Confirmation of deletion received from service providers.

Note: Retaining the deletion request itself — and records of how you processed it — does not contradict the deletion obligation. The requirement is to delete the consumer's substantive PI, not the compliance records.

---

## Summary Timeline

| Action | Deadline |
|---|---|
| Acknowledge receipt | Immediately (no statutory deadline, but best practice within 10 days) |
| Complete identity verification | As soon as possible; clock runs from request receipt, not verification |
| Respond to both requests (or notify of extension) | 45 calendar days from receipt |
| Maximum response deadline with extension | 90 calendar days from receipt |
| Notify consumer if extension needed | Within the original 45-day window |
| Service providers/contractors must delete | Instruct within your response period; confirm deletion promptly |

---

## Key Risks to Watch

- **Incomplete system search:** Missing PI in ad tech, analytics, or legacy systems is a common compliance gap. Conduct a thorough data inventory before responding.
- **Failure to notify service providers:** The deletion obligation explicitly extends to service providers and contractors. Document all instructions sent.
- **Over-invoking exceptions:** Exceptions must be applied narrowly. Blanket invocation of "legal obligation" or "fraud detection" without specific, documented justification will not withstand CPPA scrutiny.
- **Treating both requests as one:** Right to Know and Right to Delete are separate rights with separate response obligations. Document and respond to each independently.
- **Penalty exposure:** Unintentional violations are up to $2,500 per violation; intentional violations up to $7,500 per violation (Cal. Civ. Code §1798.155).

# CCPA: Handling a Combined Right to Know + Right to Delete Request

A California resident has submitted two concurrent requests: (1) a Right to Know (access) request and (2) a Right to Delete request. Below is a step-by-step walkthrough of how to handle both, covering intake, identity verification, response obligations, exceptions, and documentation.

---

## 1. Confirm the Request is a "Verifiable Consumer Request"

Under the California Consumer Privacy Act (CCPA) as amended by the California Privacy Rights Act (CPRA), both rights may only be honored once the consumer's identity is verified to a reasonable degree. The request must:

- Be submitted through a designated method (web form, toll-free phone number, or other disclosed channel in your Privacy Policy).
- Contain enough information to enable verification.
- Be accompanied by a declaration, if required, attesting that the information provided is true under penalty of perjury (required for specific-pieces requests and deletion requests by regulation).

---

## 2. Initial Acknowledgment (Within 10 Business Days)

Upon receipt, you must acknowledge the request within **10 business days** and inform the consumer:

- That you received the request.
- How you will verify their identity.
- The expected timeline for responding (up to 45 calendar days, extendable once by another 45 days with notice).

---

## 3. Identity Verification

### Why it matters
Verification protects the consumer (and you) against fraudulent requests. The standard is "reasonable" verification, calibrated to the sensitivity of the information involved and the type of request.

### Matching information to records
Collect 2–3 data points the consumer provides and match them against information already in your systems. Common data points:

- Email address used to create an account.
- First and last name.
- Phone number or postal address on record.
- Date of account creation or last transaction date.

### Tiered verification standards

| Request Type | Verification Standard |
|---|---|
| Right to Know – Categories only | Match at least 2 data points with moderate confidence |
| Right to Know – Specific pieces of PI | Match at least 3 data points with high confidence; require a signed declaration under penalty of perjury |
| Right to Delete | Match at least 2–3 data points depending on sensitivity; signed declaration recommended |

### Non-account holders (unregistered consumers)
If the consumer does not have an account, you may use a three-step process:
1. Provide a timestamp verification link sent to the email address provided.
2. Request 2 additional data points to match against transaction or interaction records.
3. If you cannot verify, you may deny the request but must inform the consumer they can exercise rights through an authorized agent or alternative channel.

### Authorized agents
If an agent submits on the consumer's behalf:
- Require proof of signed written permission from the consumer.
- Verify the consumer's identity directly as well (unless the consumer has provided a notarized power of attorney).

---

## 4. Responding to the Right to Know (Access) Request

### Scope of disclosure
Upon verified request, disclose:

1. **Categories** of personal information (PI) collected about the consumer.
2. **Categories of sources** from which the PI was collected.
3. **Business or commercial purpose** for collecting, selling, or sharing the PI.
4. **Categories of third parties** to whom PI was disclosed.
5. **Specific pieces of PI** collected (if requested; this triggers the higher verification standard above).

### Format and delivery
- Deliver in a readily usable format (e.g., structured JSON, CSV, or a secure online portal download).
- Do not require the consumer to create a new account to receive the response.
- Provide the information free of charge (first two requests within a 12-month period must be free).

### Timeline
- Respond within **45 calendar days** of receiving the verifiable consumer request.
- Extend by an additional 45 days (one extension only) if reasonably necessary; notify the consumer before the initial deadline.

---

## 5. Responding to the Right to Delete Request

### General obligation
Upon a verified deletion request, you must delete the consumer's PI from your records and direct your **service providers, contractors, and third parties** to do the same (subject to their own exceptions).

### Deletion process steps
1. Confirm the verified identity before proceeding.
2. Identify all systems, databases, backups, and data stores holding the consumer's PI.
3. Delete or deidentify the PI in each system.
4. Issue deletion instructions to all service providers and relevant third parties that received the PI from you.
5. Confirm to the consumer in writing that deletion has occurred (or identify any exceptions invoked).

---

## 6. Exceptions You May Invoke

Both the access and deletion requests are subject to statutory and regulatory exceptions. Review each piece of PI carefully before blanket deletion.

### Exceptions to the Right to Delete (Cal. Civ. Code § 1798.105(d))

The business may decline to delete PI (in whole or in part) if retaining it is necessary to:

1. **Complete a transaction** – Fulfill a contract or provide a good/service the consumer requested, or reasonably anticipated in the context of an ongoing business relationship.
2. **Security and fraud detection** – Detect security incidents, protect against malicious, deceptive, fraudulent, or illegal activity, or prosecute those responsible.
3. **Debugging** – Identify and repair errors that impair existing intended functionality.
4. **Free speech / legal rights** – Exercise free speech, ensure another consumer's right to exercise their own free speech rights, or exercise another right provided by law.
5. **Research purposes** – Engage in public or peer-reviewed scientific, historical, or statistical research in the public interest that adheres to all other applicable ethics and privacy laws, where deletion would seriously impair the research.
6. **Legal obligation** – Comply with a legal obligation (e.g., tax records, AML/BSA records, healthcare records, employment records required by law).
7. **Internal uses reasonably aligned with consumer expectations** – Use the information internally in a lawful manner that is compatible with the context in which the consumer provided it.

### Exceptions to the Right to Know

- **Trade secrets**: You may withhold specific pieces of PI if disclosure would reveal a trade secret; inform the consumer that some information was withheld and the general reason.
- **Third-party PI**: If a specific-pieces response would reveal PI of another individual, redact that information.
- **Publicly available information**: You are not required to comply with requests for information that is lawfully made available from federal, state, or local government records.

### Partial fulfillment
If an exception applies to only part of the PI, delete (or disclose) the remainder and document exactly what was withheld and why. Inform the consumer that their request was partially fulfilled and identify the category of exception (without revealing information that itself triggers the exception).

---

## 7. Sale/Sharing Opt-Out — Supplemental Obligation

Since the consumer has submitted a deletion request, also check whether any of their PI is being **sold or shared** for cross-context behavioral advertising. If so:

- Honor any implicit opt-out of sale/sharing embedded in the deletion request.
- Instruct third-party data brokers or advertising partners to cease use of the consumer's PI.

---

## 8. Non-Discrimination Requirement

You may not deny goods or services, charge a different price, or provide a different quality of service because the consumer exercised their CCPA rights (Cal. Civ. Code § 1798.125). Document that no adverse action was taken.

---

## 9. Record-Keeping and Documentation

Regulations require businesses that receive 100,000+ consumer requests per year to maintain records for **24 months**. Even if below that threshold, retain internally:

- Date request was received.
- Type of request (Know + Delete).
- Date of acknowledgment.
- Verification method used and outcome.
- Date of response.
- Any exceptions invoked and the specific PI excluded.
- Confirmation of service provider deletion instructions sent.

---

## 10. Summary Timeline

| Milestone | Deadline |
|---|---|
| Acknowledge request | Within 10 business days of receipt |
| Verify identity | As soon as practicable (before responding) |
| Respond to both requests | Within 45 calendar days of the verifiable request |
| Extension notice (if needed) | Before the initial 45-day deadline |
| Maximum response window | 90 calendar days from verifiable request |

---

## Quick-Reference Checklist

- [ ] Acknowledge request within 10 business days.
- [ ] Collect identity verification data points (2–3; signed declaration for specific pieces / deletion).
- [ ] Match data points against internal records; document the outcome.
- [ ] For Right to Know: compile categories + specific pieces; review trade-secret and third-party exceptions; prepare structured disclosure.
- [ ] For Right to Delete: identify all data stores; apply exception analysis for each category of PI; execute deletion; send deletion instructions to service providers and third parties.
- [ ] Notify the consumer of any partial fulfillments and exceptions invoked.
- [ ] Verify no discriminatory action taken.
- [ ] Retain documentation for at least 24 months.
- [ ] Update internal metrics/logs for regulatory reporting.

# CCPA/CPRA Analysis: Ad Tech Platform — Sale and Sharing of Personal Information

## Short Answer

Yes. Disclosing your website visitors' cookie IDs and browsing data to an ad tech platform almost certainly constitutes both a **"sale"** and **"sharing"** under CCPA/CPRA. Both triggers carry distinct compliance obligations, and you need to act on both.

---

## 1. Why This Is a "Sale" Under CCPA/CPRA

**Definition (Cal. Civ. Code §1798.140(ad)):** A "sale" is the disclosure of personal information to a third party for **monetary or other valuable consideration**.

Cookie IDs are personal information — they identify or can be linked to a specific consumer or household. Browsing data (pages visited, time on page, interactions) is also personal information, and can qualify as sensitive personal information (SPI) if it reveals health, financial, or other SPI-adjacent categories.

The ad tech platform is a **third party** (not a service provider) because:
- It receives the data and uses it for its **own purposes** (building audience segments, profiling, selling ad inventory);
- It is not processing the data solely on your behalf under a contract prohibiting further use.

The "valuable consideration" you receive is the ability to serve targeted ads, which has clear commercial value — even if no cash directly changes hands. CCPA's definition of "sale" is deliberately broad and captures non-monetary exchanges.

**Conclusion:** This arrangement meets the definition of a sale.

---

## 2. Why This Is Also "Sharing" Under CPRA

**Definition (Cal. Civ. Code §1798.140(ah)):** "Sharing" is the disclosure of personal information to a third party for **cross-context behavioral advertising**, even if no consideration is exchanged.

Cross-context behavioral advertising is advertising based on personal information obtained from a consumer's activity across different businesses, websites, or apps. This is exactly what ad tech platforms do: they combine your visitors' browsing data with data from other sources to build profiles and serve targeted ads.

**Conclusion:** Even if you argued there was no "sale," the disclosure would still constitute "sharing" — a CPRA-specific concept added precisely to close this loophole.

---

## 3. What You Must Do

### A. Verify CCPA/CPRA Applicability to Your Business

You are subject to CCPA/CPRA if you are a for-profit business doing business in California and meet at least one of:
- Annual gross revenues exceeding $25 million;
- Annually buy, sell, receive, or share PI of 100,000+ consumers or households;
- Derive 50%+ of annual revenues from selling or sharing consumers' PI.

Website visitor data at scale will likely trigger the second threshold. Confirm which thresholds apply.

### B. Update Your Privacy Policy

Your privacy policy must disclose:
- That you sell and share personal information (cookie IDs, browsing/behavioral data);
- The categories of PI sold or shared (identifiers, internet/network activity);
- The categories of third parties to whom PI is sold or shared (ad networks, demand-side platforms, data brokers);
- A prominent **"Do Not Sell or Share My Personal Information"** link.

### C. Provide a "Do Not Sell or Share My Personal Information" Link

- Place this link prominently on your homepage (and ideally in your site footer and privacy policy).
- The link must lead to a mechanism that stops data from being passed to the ad tech platform for consumers who opt out.
- Honor opt-out requests **immediately** upon receipt.

### D. Honor Global Privacy Control (GPC) Signals

GPC is a browser-level opt-out signal. Per CPPA guidance and enforcement actions:
- You **must** detect and honor GPC signals as a valid opt-out of sale and sharing.
- This requires technical implementation: when a GPC signal is detected, do not fire the ad tech platform's tags/pixels for that user.
- This applies even if the user has not clicked your "Do Not Sell or Share" link.

### E. Implement a Consent Management Platform (CMP) or Tag Manager Logic

Your technical implementation should:
1. Detect GPC signals server-side or via your tag manager before any data is sent to the ad tech platform.
2. Block or suppress ad tech tags for opted-out users.
3. Maintain a record of opt-out signals and honor them for future sessions (do not re-engage after opt-out without re-consent).

### F. Update Your At-Collection Privacy Notice

At or before collecting cookie/browsing data, inform visitors:
- What categories of PI are collected (identifiers, browsing/internet activity);
- That this information may be sold or shared with third parties for targeted advertising;
- How to exercise their opt-out right.

This can be done via a cookie banner or layered notice, but it must be clear and not buried.

### G. Review or Re-Classify the Ad Tech Vendor Relationship

Evaluate whether the ad tech platform could be restructured as a **service provider** rather than a third party:
- This requires a written contract that: (a) limits the platform's use of data strictly to providing the ad service to you; (b) prohibits the platform from selling or sharing data further; (c) prohibits retaining, using, or disclosing data for its own commercial purposes.
- Many ad tech platforms will not agree to these terms, or their business model depends on further use — in which case they cannot be classified as a service provider and the sale/sharing characterization stands.
- If you can restructure the relationship with appropriate contractual controls, the disclosure would no longer constitute a sale or sharing.

### H. Assess Sensitive Personal Information (SPI) Implications

If browsing data reveals health conditions, financial status, political views, or other SPI categories, additional obligations apply:
- Provide a **"Limit the Use of My Sensitive Personal Information"** link;
- Limit use and disclosure of SPI to what is necessary for the disclosed purpose.

### I. Minors

If any of your website visitors are under 16:
- You **cannot** sell or share their PI without opt-in consent (under 13: parent/guardian consent; 13–15: consumer's own consent).
- Violations involving minors' PI are automatically treated as intentional, carrying fines of up to **$7,500 per violation**.

---

## 4. Penalty Exposure

| Violation Type | Penalty |
|---|---|
| Unintentional violation | Up to $2,500 per violation |
| Intentional violation | Up to $7,500 per violation |
| Violation involving minor's PI | Up to $7,500 per violation (always intentional) |

"Per violation" can mean per consumer record or per transaction. Given the volume typical of ad tech operations, aggregate exposure can be substantial.

---

## 5. Priority Action List

| Priority | Action |
|---|---|
| Immediate | Implement GPC signal detection and suppression |
| Immediate | Add "Do Not Sell or Share My Personal Information" link to homepage |
| Short-term | Update privacy policy with sale/sharing disclosures |
| Short-term | Update at-collection cookie/browsing notice |
| Short-term | Assess ad tech vendor contracts — service provider feasibility |
| Short-term | Build opt-out request intake and fulfillment workflow |
| Medium-term | Audit for minor visitors; implement age-gating or consent flows if needed |
| Medium-term | Assess SPI exposure in browsing data categories |

---

## Summary

Your ad tech arrangement almost certainly constitutes both a **sale** (valuable consideration) and **sharing** (cross-context behavioral advertising) under CCPA/CPRA. The key obligations are: (1) disclose it in your privacy policy and at-collection notice, (2) provide a "Do Not Sell or Share" opt-out mechanism, (3) honor GPC signals technically, and (4) explore whether the vendor relationship can be restructured to qualify as a service provider. If restructuring is not feasible, ensure your opt-out infrastructure is in place before continued data flows to the platform.

# CCPA/CPRA Analysis: Ad Tech Platform, Cookie IDs, and Browsing Data

## Short Answer

Yes — sharing website visitors' cookie IDs and browsing data with an ad tech platform for targeted advertising almost certainly constitutes both a **"sale"** and **"sharing"** of personal information under CCPA/CPRA. Both categories trigger opt-out rights and specific compliance obligations.

---

## 1. Does This Qualify as a "Sale" Under CCPA/CPRA?

### Statutory Definition of "Sale"

Under Cal. Civ. Code § 1798.140(ad)(1), a **"sale"** means:

> Selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating orally, in writing, or by electronic or other means, a consumer's personal information by the business to a third party **for monetary or other valuable consideration**.

### Cookie IDs Are Personal Information

Cookie IDs (persistent identifiers linked to a browser or device) are explicitly listed as **personal information** under CCPA/CPRA (§ 1798.140(v)(1)) because they can be used to identify or profile an individual over time, even without a name attached.

Browsing data (pages visited, products viewed, time on site, etc.) also qualifies as personal information — it constitutes **internet or other electronic network activity information** under § 1798.140(v)(1)(F).

### The "Valuable Consideration" Threshold

You likely do not pay the ad tech platform — they pay you (or provide ad services in exchange for data access). This reciprocal exchange — data for advertising services, ad revenue, or reduced platform costs — satisfies the **"other valuable consideration"** element. California regulators and the CPPA have confirmed that non-monetary consideration (such as free or subsidized ad services) is sufficient.

**Conclusion: This is likely a "sale."**

---

## 2. Does This Qualify as "Sharing" Under CPRA?

CPRA (effective January 1, 2023) added a distinct category — **"sharing"** — specifically to capture cross-context behavioral advertising:

> Cal. Civ. Code § 1798.140(ah): **"Sharing"** means communicating orally, in writing, or by electronic or other means, a consumer's personal information by the business to a third party **for cross-context behavioral advertising**, whether or not for monetary or other valuable consideration...

### Key Points About "Sharing"

- **No monetary exchange required.** Unlike "sale," sharing applies even when there is zero compensation — closing the "free services" loophole.
- **Cross-context behavioral advertising** means targeting ads based on personal information obtained from activity across businesses, websites, apps, or services other than the one the consumer is intentionally interacting with. Ad tech networks that build profiles across sites clearly fall within this definition.
- Sending cookie IDs and browsing behavior to an ad tech platform to enable targeted advertising across the web is the textbook example of cross-context behavioral advertising.

**Conclusion: This is definitively "sharing."**

---

## 3. Who Is Covered? Applicability Threshold

CCPA/CPRA applies to for-profit businesses that:

1. Have annual gross revenues exceeding $25 million (as of January 1 of the preceding calendar year), OR
2. Buy, sell, receive, or share the personal information of 100,000 or more consumers or households annually, OR
3. Derive 50% or more of annual revenues from selling or sharing consumers' personal information.

If your business meets any of these thresholds and serves California consumers, full compliance obligations apply. Even if you are below the revenue threshold, meeting the 100,000 consumer/household threshold — easily triggered by a website with moderate traffic — brings you into scope.

---

## 4. Required Compliance Actions

### A. Update Your Privacy Notice (Required)

Your privacy policy must clearly disclose, at or before the point of data collection:

- That you sell or share personal information (including cookie IDs and browsing data).
- The **categories** of personal information sold or shared.
- The **categories of third parties** to whom data is disclosed (e.g., "advertising networks," "data analytics partners").
- A description of consumers' rights to opt out of sale/sharing.
- How consumers can exercise those rights.

**Citation:** Cal. Civ. Code §§ 1798.100(b), 1798.110, 1798.115, 1798.130.

### B. Provide an Opt-Out Mechanism (Required)

You must give California consumers a clear and conspicuous way to opt out of the sale/sharing of their personal information:

- **"Do Not Sell or Share My Personal Information" link** — must be prominently placed on your homepage (or every page where data collection occurs). This is the standard required link text under § 1798.135(a)(1).
- **Global Privacy Control (GPC) compliance** — you must honor GPC signals sent by consumers' browsers as a valid opt-out. The CPPA has issued enforcement guidance making GPC compliance mandatory, not optional.
- Optionally, you may provide a **preference center** allowing granular control, but this does not replace the GPC obligation.

### C. Honor Opt-Out Requests (Required)

Upon receiving a valid opt-out (including GPC):

- **Stop selling/sharing within 15 business days** of the request.
- **Notify all third parties** (including the ad tech platform) that the consumer has opted out and they must stop using that consumer's data — Cal. Civ. Code § 1798.120(d).
- Do not re-engage the consumer for sale/sharing without their explicit **opt-in consent**, and not before 12 months have passed (§ 1798.135(d)).

### D. Review Your Ad Tech Contract (Required)

Execute or update a written contract with the ad tech platform. The contract must:

- Specify the **limited and specified purpose** for which the ad tech platform may use the data.
- Prohibit the ad tech platform from selling or sharing the personal information unless the consumer has received notice and opportunity to opt out.
- Prohibit the ad tech platform from retaining, using, or disclosing the data outside of the contract's scope.
- Require the ad tech platform to notify you if it can no longer comply.

**Citation:** Cal. Civ. Code § 1798.100(d); CPPA Regulations § 7050.

If no compliant contract exists, the ad tech platform cannot qualify as a "service provider" or "contractor" — meaning every disclosure is automatically a sale/sharing, and the platform bears its own obligations as a third party.

### E. Update Your Cookie Banner / Consent Management Platform (Recommended, Practically Required)

- Implement or reconfigure your **Consent Management Platform (CMP)** to:
  - Disclose ad tech data sharing to users **before** cookies are set.
  - Capture and propagate opt-out signals.
  - Honor GPC signals at the technical layer (prevent the ad tech pixel/tag from firing for opted-out users).
- Consider category-level consent for "targeting/advertising" cookies separate from "functional" cookies.

### F. Consumer Rights Infrastructure (Required)

Ensure your rights request process supports:

- **Right to Know** — what data was sold/shared, to whom, and for what purpose.
- **Right to Delete** — delete personal information and instruct the ad tech platform to delete its copy.
- **Right to Correct** — correct inaccurate personal information.
- **Right to Opt Out** — as described above.
- **Right of No Retaliation** — consumers who opt out must receive the same quality of service.

Response timelines: 45 calendar days for most requests, extendable by 45 days with notice (§ 1798.145(b)).

### G. Data Minimization and Purpose Limitation (CPRA Addition)

CPRA requires that personal information be:

- Collected for **disclosed purposes** only.
- Limited to what is **reasonably necessary** for those purposes.
- Not **retained longer than necessary**.

Review whether the scope of data shared with the ad tech platform (e.g., granular browsing paths, session recordings, inferred attributes) is proportionate to the stated advertising purpose.

---

## 5. Sensitive Personal Information Consideration

If the browsing data reveals information about health conditions, precise geolocation, financial status, or other **sensitive personal information** (SPI) categories under § 1798.140(ae), additional obligations apply:

- Consumers have the right to **limit the use and disclosure** of SPI.
- A separate **"Limit the Use of My Sensitive Personal Information" link** may be required.
- SPI shared with ad tech platforms for targeted advertising purposes is particularly high-risk.

---

## 6. Enforcement Risk

The **California Privacy Protection Agency (CPPA)** has made ad tech data flows a priority enforcement area. The CPPA's 2023–2024 enforcement sweep explicitly targeted businesses that:

- Failed to honor GPC signals.
- Did not provide a compliant opt-out link.
- Continued sharing data with ad tech partners without proper contracts.

Penalties: Up to **$2,500 per unintentional violation** and **$7,500 per intentional violation**, with each consumer's record potentially constituting a separate violation (§ 1798.155).

---

## 7. Summary Checklist

| Action | Priority | Owner |
|---|---|---|
| Add "Do Not Sell or Share My Personal Information" link to website | Critical | Web/Legal |
| Honor Global Privacy Control (GPC) browser signals | Critical | Engineering |
| Update privacy policy with sale/sharing disclosures | Critical | Legal |
| Execute CPRA-compliant contract with ad tech platform | Critical | Legal/Procurement |
| Configure CMP to block ad tech tags for opted-out users | Critical | Engineering |
| Establish consumer rights request workflow | High | Legal/Ops |
| Audit data minimization — scope of data shared | High | Privacy/Engineering |
| Check for sensitive personal information in browsing data | High | Privacy |
| Train marketing/ad ops team on opt-out propagation | Medium | HR/Legal |

---

## References

- Cal. Civ. Code § 1798.100 et seq. (CCPA as amended by CPRA)
- Cal. Civ. Code §§ 1798.120, 1798.135, 1798.140(ad), 1798.140(ah)
- CPPA Final Regulations (effective March 29, 2023), Cal. Code Regs. tit. 11, §§ 7000–7304
- CPPA Enforcement Advisory No. 2023-03 (Global Privacy Control)
- FTC Enforcement Guidance on Digital Advertising and Data Brokers (complementary federal context)

# GDPR to CCPA/CPRA Gap Analysis: Additional Steps Required

## Overview

Good news: a mature GDPR programme gives you a substantial head start on CCPA/CPRA compliance. The GDPR is generally the more demanding of the two frameworks, and most of its core obligations map directly onto California law. However, CCPA/CPRA contains several concepts and mechanisms with no GDPR equivalent that you will need to implement from scratch.

---

## What Your GDPR Programme Already Covers

The following CCPA/CPRA obligations are satisfied (or substantially satisfied) by your existing GDPR controls:

| CCPA/CPRA Obligation | Covered by GDPR Programme |
|---|---|
| Privacy notice at collection | Art. 13/14 notices |
| Comprehensive privacy policy | Privacy notice |
| Right to access/know | DSAR process |
| Right to delete | Right to erasure process |
| Right to correct | Right to rectification |
| Right to data portability | Art. 20 portability |
| Data minimisation and purpose limitation | Art. 5 principles |
| Retention schedules | Art. 5(1)(e) storage limitation |
| Processor/service provider agreements | Art. 28 DPAs |
| Security measures | Art. 32 technical/organisational measures |

---

## Additional Steps Needed for CCPA/CPRA

### 1. "Do Not Sell or Share My Personal Information" Link and Opt-Out Workflow

**No GDPR equivalent.** CCPA/CPRA defines "sale" broadly (monetary or other valuable consideration) and adds "sharing" (disclosure for cross-context behavioural advertising, even without payment). You must:

- Add a conspicuous "Do Not Sell or Share My Personal Information" link to your homepage and privacy policy
- Build a consumer-facing opt-out form or mechanism
- Update your consent/preference management platform to process opt-outs within 15 business days
- Propagate opt-outs to all downstream service providers and contractors
- Implement a 12-month moratorium on re-asking opted-out consumers to reconsider

**Key implication for ad tech:** If you use third-party ad exchanges, DMPs, or retargeting partners who receive cookie IDs or device identifiers, those disclosures will likely constitute a "sale" or "sharing" under CCPA/CPRA and must be stopped for opted-out California consumers.

### 2. Global Privacy Control (GPC) Signal Honoring

**No GDPR equivalent.** The CPPA has confirmed that businesses must recognise the GPC browser signal as a valid opt-out of sale/sharing — it must be processed automatically, not just as a preference signal. This requires:

- Technical implementation to detect GPC headers in browser requests
- Automatic suppression of data sharing/selling for consumers sending GPC signals
- This must work even if the consumer has not submitted a manual opt-out request

### 3. "Limit the Use of My Sensitive Personal Information" Link and Workflow

**Partial GDPR overlap, but different mechanism.** GDPR requires explicit consent (opt-in) for special category data. CCPA/CPRA uses an opt-out model for most SPI categories — meaning you can use SPI by default but must stop on request.

CPRA's SPI categories include some items not in GDPR special categories:
- Precise geolocation (within 1/4 mile)
- Account credentials (login + security code)
- Contents of consumer communications (mail, email, texts)
- Social Security numbers and government IDs

You must:
- Add a "Limit the Use of My Sensitive Personal Information" link (can be combined with the Do Not Sell link)
- Process SPI limitation requests within **15 business days** (faster than the 45-day standard deadline)
- Restrict SPI use to only the permitted purposes (service delivery, safety/security, transient use, quality verification)
- Propagate limitations to service providers and contractors

### 4. Vendor Contract Review and Reclassification

**GDPR Art. 28 DPAs are necessary but not sufficient.** CCPA/CPRA introduces a three-tier vendor taxonomy — Service Providers, Contractors (CPRA addition), and Third Parties — each with different rules:

- **Service Providers:** Process PI on your behalf; contract must prohibit further use or sale; not a "sale"
- **Contractors:** Receive PI under contract; must certify compliance; must not sell or share
- **Third Parties:** Any other recipient — disclosure is likely a "sale" unless an exception applies

Action required:
- Audit all current processor/vendor relationships and reclassify under CCPA/CPRA taxonomy
- Update contracts with service providers and contractors to include CCPA/CPRA-specific clauses: purpose limitation, prohibition on resale, obligation to honour consumer deletion requests, audit rights, certification of compliance
- Note: your GDPR DPAs will not automatically satisfy these requirements — specific CCPA/CPRA language is needed

### 5. Minors' Opt-In Consent for Sale/Sharing

**Different age thresholds from GDPR.** CCPA/CPRA requires affirmative opt-in before selling or sharing PI of consumers aged 13–15, and parental consent for under-13s. This operates independently of your GDPR age-of-consent controls (which vary by Member State from 13–16 for consent-based processing).

Action required:
- Implement age-screening for consumer-facing products
- Build opt-in workflows for 13–15 year-olds and parental consent mechanisms for under-13s
- Ensure ad tech and data sharing is suppressed for minors absent opt-in

### 6. Financial Incentive and Loyalty Programme Disclosures

If you operate loyalty programmes, premium tiers, or offer any benefit in exchange for consumers' PI:

- You must disclose the financial incentive in your privacy policy
- Provide a "reasonably related" justification (the incentive must be proportionate to the value of the PI)
- Obtain affirmative opt-in consent from consumers with a clear description of material terms
- Allow consumers to withdraw at any time without penalty

This has no direct GDPR equivalent.

### 7. Annual Business Threshold Verification

CCPA/CPRA applicability is re-evaluated each year based on:
- Annual gross revenues exceeding $25 million, OR
- Buying, selling, receiving, or sharing PI of 100,000+ consumers or households, OR
- 50%+ of annual revenues from selling or sharing PI

You should build an annual process to confirm threshold status and update your compliance posture if thresholds change.

### 8. CPPA Rulemaking — Automated Decision-Making and Cybersecurity Audits

**Pending but plan now.** The California Privacy Protection Agency (CPPA) is developing regulations on:

- **Automated decision-making (ADM):** Expected to require opt-out rights and access to decision logic for significant automated decisions. Map this to your existing Art. 22 GDPR controls — you will likely need US-specific opt-out mechanisms rather than relying on the GDPR's exemption framework
- **Annual cybersecurity audits:** Businesses processing PI that presents "significant risk" will need to conduct and potentially submit annual cybersecurity audits to the CPPA
- **Data broker registration:** If you sell PI without a direct relationship with the consumer, California data broker registration may be required

---

## Where the Two Laws Differ Most Significantly

### 1. Lawful Basis vs. No Lawful Basis

**This is the most fundamental structural difference.** GDPR prohibits processing unless you have a lawful basis (consent, contract, legitimate interests, etc.). CCPA/CPRA imposes no such requirement — businesses may collect and use PI without any legal justification, provided they give notice. This means:

- Your GDPR legitimate interests assessments (LIAs) and consent records have no direct CCPA/CPRA equivalent
- CCPA/CPRA compliance does not require you to identify or document a basis for processing
- However, you still cannot use PI for undisclosed purposes (purpose limitation applies)

### 2. Opt-In (GDPR) vs. Opt-Out (CCPA/CPRA) Model

GDPR is fundamentally opt-in — consent must be freely given, specific, informed, and unambiguous before processing. CCPA/CPRA is fundamentally opt-out — consumers can use their PI unless and until they say stop. The only opt-in requirements under CCPA/CPRA are for minors' data and financial incentive programmes.

This creates an asymmetry: for California consumers, you may be doing more processing by default than for EU/EEA consumers, but you face a different enforcement risk (action after the fact rather than lack of prior consent).

### 3. "Sale" and "Sharing" — Concepts with No GDPR Equivalent

GDPR treats disclosure to a third party as a separate processing activity governed by lawful basis and purpose limitation. CCPA/CPRA creates the specific concept of "sale" (for any valuable consideration, not just money) and "sharing" (for cross-context behavioural advertising) with dedicated opt-out rights. Many data flows that are routine under GDPR may constitute a "sale" or "sharing" under CCPA/CPRA.

### 4. Sensitive Personal Information — Broader and Different Categories

CPRA's SPI category is wider than GDPR's special categories in specific ways:
- Precise geolocation is SPI under CPRA but not a special category under GDPR (though it may require legitimate interests assessment)
- Account credentials and communication contents are SPI under CPRA with no GDPR special category equivalent
- The treatment mechanism is also different: GDPR requires explicit consent; CPRA provides an opt-out right (businesses can use SPI unless the consumer limits it)

### 5. Response Timelines

| Action | CCPA/CPRA | GDPR |
|---|---|---|
| Standard rights requests | 45 days + 45-day extension | 1 month + 2-month extension |
| SPI limitation requests | 15 business days | N/A |
| Opt-out of sale/sharing | Immediate (update within 15 business days) | N/A |

CCPA/CPRA timelines for standard requests are somewhat shorter than GDPR (45 days vs. ~30 calendar days, but with a longer extension available). The SPI limitation 15-business-day deadline has no GDPR analogue.

### 6. Private Right of Action — Scope

GDPR allows data subjects to bring claims for any infringement of their rights, and compensation for material or non-material damage. CCPA/CPRA's private right of action is narrowly scoped to **data breaches only** — consumers cannot sue for general CCPA/CPRA non-compliance. However, class actions for data breaches with statutory damages of $100–$750 per consumer per incident create very significant financial exposure.

### 7. Enforcement Architecture

| Aspect | CCPA/CPRA | GDPR |
|---|---|---|
| Enforcement body | California Privacy Protection Agency (CPPA) | 27+ national DPAs |
| Penalty calculation | Per violation (not global turnover) | % of global annual turnover |
| Maximum penalty | $7,500 per intentional violation | €20M or 4% global turnover |
| Cure period | 30 days (for AG actions) | No formal cure period |

GDPR's turnover-based penalties create larger maximum exposure for large organisations. CCPA/CPRA's per-violation model can add up quickly in a mass data incident (especially involving minors, where $7,500 per record applies automatically).

### 8. International Data Transfers

GDPR imposes strict transfer restriction rules for data leaving the EEA (SCCs, BCRs, adequacy decisions). CCPA/CPRA has **no equivalent** — there are no restrictions on cross-border data transfers under California law. Your GDPR transfer mechanisms are relevant only for EU/EEA data.

---

## Prioritised Remediation Roadmap

| Priority | Action | Rationale |
|---|---|---|
| **Immediate** | Add "Do Not Sell or Share" link and opt-out workflow | Core CCPA right; enforcement focus |
| **Immediate** | Implement GPC signal detection and processing | CPPA enforcement confirmed; court decisions support |
| **Short-term** | Audit and update vendor contracts for CCPA/CPRA requirements | Liability risk from non-compliant service providers |
| **Short-term** | Add SPI limitation link and 15-day response workflow | CPRA right; penalty exposure |
| **Short-term** | Review ad tech stack for "sale/sharing" data flows | Likely highest-risk area for most organisations |
| **Medium-term** | Implement minors' opt-in controls if applicable | $7,500/violation for minors; always intentional |
| **Medium-term** | Add financial incentive disclosures if applicable | Required for loyalty/incentive programmes |
| **Ongoing** | Monitor CPPA rulemaking on ADM and cybersecurity audits | Significant new obligations pending |
| **Annual** | Verify business thresholds | Applicability can change year to year |

---

*This analysis is based on CCPA (Cal. Civ. Code §1798.100 et seq.) and CPRA (effective January 1, 2023). CPPA rulemaking is ongoing and requirements in areas such as automated decision-making and cybersecurity audits may be finalised after this date. Consult qualified US privacy counsel before implementing compliance measures.*

# GDPR to CCPA/CPRA: Additional Compliance Steps and Key Differences

## Executive Summary

If you already have a mature GDPR compliance programme, you have a strong foundation for CCPA/CPRA compliance. Many core privacy principles overlap — transparency, data subject rights, security safeguards, and vendor management. However, the two laws differ significantly in scope, mechanics, opt-out architecture, and enforcement model. This document outlines the gaps you need to close and where the laws diverge most sharply.

---

## 1. Scope and Applicability — Understand Whether CCPA/CPRA Applies

Before closing gaps, confirm you are in scope. CCPA/CPRA (California Consumer Privacy Act, as amended by the California Privacy Rights Act) applies to for-profit businesses that collect personal information of California residents and meet **at least one** of:

- Annual gross revenues exceeding **$25 million**
- Annually buying, selling, receiving, or sharing the personal information of **100,000 or more** consumers or households
- Deriving **50% or more** of annual revenues from selling or sharing consumers' personal information

GDPR applies to any organisation processing EU/EEA residents' personal data regardless of revenue. If your business is small, GDPR may apply while CCPA/CPRA may not — and vice versa for large US-only operations.

---

## 2. Key Additional Steps Required Beyond Your GDPR Programme

### 2.1 Data Mapping and Inventory — CCPA-Specific Categories

**What GDPR already gives you:** A data inventory (Article 30 Record of Processing Activities) covering categories of data, purposes, retention periods, and recipients.

**What you still need for CCPA/CPRA:**

- Map data to CCPA's defined categories of "personal information," which are broader in some respects (e.g., commercial information, inferences drawn from consumer data, olfactory/visual/thermal data).
- Identify **"sensitive personal information" (SPI)** under CPRA — this is a distinct sub-category with additional rights (right to limit use and disclosure) not present in the original CCPA. SPI includes: Social Security numbers, financial account credentials, precise geolocation, racial/ethnic origin, religious beliefs, union membership, contents of communications, genetic/biometric data, and health information.
- Identify all instances of **"selling" or "sharing"** personal information as defined under CCPA — these terms are broader than common understanding and include data exchanged for cross-context behavioural advertising even without monetary consideration.

### 2.2 Implement "Do Not Sell or Share My Personal Information"

**GDPR equivalent:** GDPR requires a legal basis for processing; if based on legitimate interests, individuals can object. There is no exact analogue.

**CCPA/CPRA requirement:** Businesses that sell or share personal information must:

- Post a clear and conspicuous **"Do Not Sell or Share My Personal Information"** link on the homepage and in the privacy notice.
- Establish a mechanism to receive and honour opt-out requests within **15 business days**.
- Respect opt-out signals from recognised **Global Privacy Control (GPC)** browser settings — this is mandatory, not optional.
- Cease selling/sharing the opted-out consumer's data and notify downstream third parties.

**Action:** Implement GPC signal detection in your web infrastructure. Deploy the opt-out link. Build a backend workflow to flag opted-out consumers and suppress their data from being shared or sold.

### 2.3 Right to Limit Use of Sensitive Personal Information

**GDPR equivalent:** Sensitive data requires explicit consent or another specific lawful basis under Article 9. This is a processing restriction at collection, not a post-collection opt-out right.

**CPRA addition:** Consumers have the right to direct a business to **limit the use and disclosure of SPI** to purposes necessary to perform the service. Businesses that use SPI beyond necessary purposes must offer a "Limit the Use of My Sensitive Personal Information" opt-out link (or a combined link).

**Action:** Audit all uses of SPI. If you use SPI for secondary purposes (advertising, profiling), implement the limitation right mechanism.

### 2.4 Data Retention — Explicit Disclosure Requirements

**GDPR:** Requires disclosure of retention periods or criteria in the privacy notice (Articles 13/14).

**CPRA:** Requires businesses to disclose **at or before collection** the retention period for each category of personal information, or if that is not possible, the criteria used. The CPRA also adds an explicit prohibition on retaining personal information longer than reasonably necessary for the disclosed purpose.

**Action:** Update your privacy notice to include category-level retention disclosures aligned with CCPA categories, not just GDPR-style criteria statements.

### 2.5 Contracts with Service Providers, Contractors, and Third Parties

**GDPR equivalent:** Data Processing Agreements (DPAs) with processors under Article 28.

**CCPA/CPRA framework:** The terminology and obligations differ:

| CCPA/CPRA Term | Closest GDPR Analogue | Key Difference |
|---|---|---|
| Service Provider | Processor | Contract must specify permitted purposes; service provider cannot sell/share data or use it for its own purposes |
| Contractor | Processor | Similar restrictions; must certify compliance; applies to data "shared" not just processed for payment |
| Third Party | Controller receiving data | Business must enter a contract restricting use; third party is liable for downstream violations |

**Action:** Review all existing vendor DPAs. They may not contain CCPA-required clauses (e.g., prohibition on selling data received from you, contractual certification of compliance, audit rights framed in CCPA terms). Create a CCPA addendum template. Note that GDPR DPAs and CCPA service provider agreements can sometimes be combined into a single privacy addendum.

### 2.6 Consumer Rights — Gaps vs. GDPR

GDPR rights provide a good baseline, but there are procedural and substantive differences:

| Right | GDPR | CCPA/CPRA | Gap to Close |
|---|---|---|---|
| Right to Know / Access | Art. 15 — access to data and information | Right to know categories and specific pieces of personal information collected in the past 12 months | CCPA response must include specific pieces (not just categories); 45-day response window (same) |
| Right to Delete | Art. 17 — right to erasure | Right to delete with fewer exceptions | CCPA exceptions are different from GDPR; must also instruct service providers and contractors to delete |
| Right to Correct | Art. 16 — rectification | CPRA added right to correct (not in original CCPA) | Already have this capability from GDPR; check your workflow routes corrections to service providers too |
| Right to Portability | Art. 20 — structured, machine-readable format | Right to obtain data in portable format | Similar; CCPA requires delivery within 45 days, twice per 12-month period free of charge |
| Right to Opt-Out of Sale/Sharing | No direct equivalent | Core CCPA right | New — see section 2.2 above |
| Right to Limit SPI Use | No direct equivalent | CPRA right | New — see section 2.3 above |
| Right to Non-Discrimination | No explicit equivalent | Explicit prohibition on discriminating against consumers who exercise rights | Ensure loyalty programmes, pricing, and service tiers do not penalise opt-outs |
| Automated Decision-Making | Art. 22 — right not to be subject to solely automated decisions | CPRA gives CPPA rulemaking authority; regulations are evolving | Monitor CPPA rulemaking; implement opt-out of automated decision-making affecting consumers significantly |

**Action:** Update your DSR (Data Subject Request) platform to handle CCPA-specific request types (e.g., "Do Not Sell," "Limit SPI"). Train your response team on CCPA exceptions (which differ from GDPR exceptions). Ensure deletion requests cascade to service providers.

### 2.7 Privacy Notice Updates

**GDPR:** Article 13/14 notices are required at point of collection.

**CCPA/CPRA:** Requires a privacy notice "at or before" collection for each category, including:

- Categories of personal information collected and the purposes for each
- Categories of third parties to whom information is disclosed
- Retention periods per category
- Whether personal information is sold or shared (and categories of recipients)
- The consumer rights available and how to exercise them
- The right to submit requests via a designated toll-free number (for businesses with a physical presence or required by regulation)
- Whether SPI is collected and used beyond necessary purposes

**Action:** Create a California-specific privacy notice (or a layered notice with California addendum). Ensure it is accessible from every page where personal information is collected.

### 2.8 Establish a Toll-Free Number or Designated Request Method

**GDPR:** No specific requirement for a toll-free telephone number.

**CCPA/CPRA:** Businesses must provide at least two designated methods for submitting requests to know and delete, including a toll-free telephone number (unless the business operates solely online, in which case an email address suffices).

**Action:** Set up a CCPA request intake channel (toll-free number or email for online-only businesses). Log all requests for compliance records.

### 2.9 No Consent-as-Legal-Basis Architecture (Generally)

**GDPR:** Consent is one of six lawful bases; it is often the primary basis for marketing.

**CCPA/CPRA:** CCPA is largely an **opt-out** regime for adults (not opt-in). Consent (opt-in) is only required in specific situations:

- **Sale/sharing of data of consumers under 16** (opt-in required; under 13 requires parent/guardian opt-in)
- **Re-use of personal information** for a purpose materially different from the disclosed purpose

**Action:** If you serve consumers under 16 in California, implement age-detection and parental consent workflows separate from any GDPR age-gating mechanisms.

### 2.10 California Privacy Protection Agency (CPPA) Registration and Rulemaking

**GDPR:** Supervisory authority is your lead DPA (determined by establishment).

**CCPA/CPRA:** The **California Privacy Protection Agency (CPPA)** is the primary regulatory body with rulemaking authority. Regulations are actively evolving (cybersecurity audits, risk assessments, automated decision-making rules were still being finalised as of early 2026).

**Action:** Monitor CPPA rulemaking at cppa.ca.gov. Subscribe to regulatory updates. Be prepared to comply with cybersecurity audit requirements and privacy risk assessments once finalised — these will require operational processes similar to GDPR's Data Protection Impact Assessments (DPIAs) but with California-specific frameworks.

---

## 3. Where GDPR and CCPA/CPRA Differ Most Significantly

### 3.1 Opt-Out vs. Opt-In Philosophy

This is the most fundamental structural difference.

- **GDPR:** Processing personal data generally requires a **lawful basis established before or at the point of processing**. For consent-based processing, this means opt-in before data is used. For other bases (contract, legitimate interests), the data subject can object after the fact.
- **CCPA/CPRA:** For most processing, businesses can collect and use data freely; consumers have the right to **opt out after the fact** (except for the specific scenarios noted above). This reflects a different cultural and legal philosophy about data use.

**Implication:** Your GDPR consent management infrastructure (CMPs, consent banners) may create compliance friction in the CCPA context if misapplied. CCPA does not require consent banners or cookie consent; it requires opt-out mechanisms.

### 3.2 Household vs. Individual as the Unit of Protection

- **GDPR:** Protects **natural persons** (individuals).
- **CCPA/CPRA:** Protects **consumers** and **households** — household-level data can trigger CCPA obligations even if no individual is identified.

### 3.3 "Sale" and "Sharing" Are Defined Very Broadly

- **GDPR:** Transfers of data to third parties are governed by controller-to-controller or controller-to-processor frameworks; the concept of "sale" is not legally significant.
- **CCPA/CPRA:** "Selling" includes any disclosure for **valuable consideration**, which courts and the CPPA have interpreted broadly. "Sharing" specifically covers disclosure for **cross-context behavioural advertising** even without monetary exchange — this captures most adtech arrangements (Google Analytics, Meta Pixel, programmatic advertising) that GDPR handles through consent but CCPA handles through opt-out.

**Implication:** If you use any third-party tracking for advertising purposes, you are almost certainly "selling or sharing" under CCPA/CPRA, triggering opt-out obligations regardless of your GDPR consent model.

### 3.4 No Equivalent to GDPR's Lawful Basis Framework

- **GDPR:** Six lawful bases (consent, contract, legal obligation, vital interests, public task, legitimate interests). Processing without a basis is unlawful.
- **CCPA/CPRA:** No equivalent lawful basis requirement. The law focuses on **transparency and opt-out rights**, not on pre-authorising processing. Businesses disclose what they do and give consumers the right to opt out of sale/sharing and limit SPI use.

### 3.5 Private Right of Action is Narrow (But Significant)

- **GDPR:** Individuals can complain to supervisory authorities; Member State law may provide private rights of action varying by jurisdiction.
- **CCPA/CPRA:** Private right of action is **limited to data breaches** involving certain categories of unencrypted/unredacted personal information. However, statutory damages of **$100–$750 per consumer per incident** (or actual damages if greater) can aggregate to enormous class action exposure. Regulatory enforcement (up to **$2,500 per unintentional violation** and **$7,500 per intentional violation or violations involving minors**) is handled by the CPPA and California Attorney General.

### 3.6 DPIA / Risk Assessment Approach

- **GDPR:** Article 35 DPIAs are triggered by high-risk processing (large-scale processing of special categories, systematic monitoring, automated decisions with significant effects).
- **CPRA:** Privacy risk assessments (and cybersecurity audits) will be required by CPPA regulation for businesses whose processing presents significant risk. The triggers and scope are not yet identical to GDPR Art. 35. Automated decision-making assessments are required separately.

### 3.7 No Data Protection Officer (DPO) Requirement

- **GDPR:** Mandatory DPO appointment in certain circumstances (Articles 37–39).
- **CCPA/CPRA:** No mandatory DPO. However, designating a privacy lead or privacy officer is a best practice and may be required by industry frameworks.

### 3.8 Scope of Special/Sensitive Data

- **GDPR Special Categories (Art. 9):** Race/ethnicity, political opinions, religious/philosophical beliefs, trade union membership, genetic data, biometric data for unique identification, health data, sex life/orientation.
- **CPRA Sensitive Personal Information:** Overlaps substantially but adds: **Social Security/government ID numbers**, **financial account credentials** (account numbers + access codes), **precise geolocation**, **contents of messages** (email, text, mail). Notably, health data is SPI under CPRA but does not require the same lawful basis structure as GDPR Art. 9 — instead it triggers the right to limit use.

---

## 4. Prioritised Action Plan for GDPR-Ready Organisations

| Priority | Action Item | Effort |
|---|---|---|
| 1 | Determine if CCPA/CPRA applies (revenue/volume thresholds) | Low |
| 2 | Audit data flows for "selling" or "sharing" (adtech, data brokers) | Medium |
| 3 | Implement GPC signal detection and Do Not Sell/Share opt-out | High |
| 4 | Update privacy notice with CCPA-required disclosures | Medium |
| 5 | Update vendor contracts with CCPA service provider clauses | Medium |
| 6 | Implement right to limit SPI use if SPI used beyond necessary purposes | Medium |
| 7 | Extend DSR platform to handle CCPA request types and timelines | Medium |
| 8 | Set up designated request intake (toll-free number or email) | Low |
| 9 | Implement children's data opt-in if serving under-16s | High |
| 10 | Monitor CPPA rulemaking for cybersecurity audit and ADM requirements | Ongoing |

---

## 5. Summary: What GDPR Gives You for Free

Your GDPR programme already provides:
- Data inventory and mapping (extend to CCPA categories)
- Privacy notice drafting capability (update for CCPA requirements)
- DSR intake and response workflows (extend to CCPA right types)
- Vendor management (update contracts with CCPA clauses)
- Data retention policies (ensure category-level disclosure)
- Security safeguards (supports CCPA breach liability defence)
- DPIAs (foundation for CPPA risk assessment requirements)
- Training programmes (extend to CCPA-specific scenarios)

The primary **net-new** work is: the opt-out infrastructure (GPC, Do Not Sell link), the SPI limitation right, the California-specific privacy notice, CCPA-compliant vendor contracts, and ongoing monitoring of CPPA regulatory developments.

# CPRA Classification and Obligations for Mobile App Data Collection

## Overview

Your mobile app collects three distinct categories of data: precise geolocation, health metrics from wearable integration, and biometric facial recognition for authentication. Under the California Privacy Rights Act (CPRA), all three categories qualify as **Sensitive Personal Information (SPI)** — the highest-protection tier of personal information under California law.

---

## 1. Data Classification Under CPRA

### All Three Categories Are Sensitive Personal Information (SPI)

The CPRA (Cal. Civ. Code §1798.140(ae)) defines SPI as a subset of personal information that warrants heightened protection. Each data type in your app maps directly to a statutory SPI category:

| Data Type | SPI Category | Statutory Basis |
|---|---|---|
| Precise Geolocation | "Precise geolocation" — defined as location within a radius of 1,850 feet | §1798.140(ae)(1)(H) |
| Health Metrics (wearable) | "Personal information collected and analyzed concerning a consumer's health" | §1798.140(ae)(1)(B) |
| Biometric Facial Recognition | "Biometric information" — including physiological characteristics used for identification | §1798.140(ae)(1)(B) |

These are not borderline classifications. All three are explicitly enumerated SPI categories, meaning they carry the full weight of CPRA's SPI protections regardless of how the data is processed or used.

All three categories also constitute standard **Personal Information (PI)** under §1798.140(v), which means baseline CCPA/CPRA obligations apply in addition to the SPI-specific obligations.

---

## 2. Special Obligations for SPI

### A. Right to Limit SPI Use (§1798.121) — CPRA Addition

Consumers have the right to direct your business to limit the use and disclosure of their SPI to only what is necessary to perform the services they requested (or as permitted by regulation).

**Permitted purposes without limitation** (i.e., SPI can be used without triggering the opt-out right) include:
- Performing the services or providing goods reasonably expected by the consumer
- Helping to ensure security and integrity of the business's systems
- Short-term transient use not used for profiling
- Activities that qualify under certain legal exemptions

**Trigger for the limitation right**: If your app uses SPI for purposes beyond what is strictly necessary to deliver the core service — for example, using geolocation data for targeted advertising, sharing health metrics with third-party analytics partners, or retaining biometric data beyond the authentication session — consumers can invoke this right.

**Response deadline**: You must honor limitation requests within **15 business days**.

### B. "Limit the Use of My Sensitive Personal Information" Link

If SPI is used for purposes beyond the narrowly permitted set, you must provide a clear and conspicuous link — titled exactly "Limit the Use of My Sensitive Personal Information" — on your homepage and in your app. This is a separate and additional link from the "Do Not Sell or Share My Personal Information" link.

Both links can be combined into a single "Your Privacy Choices" link under CPPA regulations, provided it is equally prominent.

### C. Data Minimization and Purpose Limitation (CPRA §1798.100(c))

SPI collection must be **adequate, relevant, and limited to what is necessary** for the disclosed purpose. Applied to your app:

- **Precise geolocation**: Collect only when necessary for app functionality (e.g., navigation or location-based features). Avoid continuous background collection if the service does not require it.
- **Health metrics**: Collect only the metrics necessary for the features offered. Avoid aggregating or retaining data beyond what the wearable integration feature requires.
- **Biometric data**: For authentication purposes, best practice is to process biometrics locally on-device and store only a derived cryptographic template (not the raw facial scan), and only for as long as the authentication session requires.

### D. Retention Limits (CPRA Addition)

You must disclose — and adhere to — specific retention periods or the criteria used to determine retention for each SPI category. You cannot retain SPI longer than reasonably necessary for the disclosed purpose.

**Recommended retention posture**:
- Biometric data: Retained only for the duration of the authentication session; derived templates purged upon account deletion or user request.
- Health metrics: Retain for the period necessary to deliver the wearable integration feature; disclose specific retention window.
- Precise geolocation: If collected in real-time for navigation, do not persist beyond the active session unless the user explicitly opts in to history storage.

### E. Cybersecurity Audits and Risk Assessments (CPRA §1798.185)

Businesses that process SPI that presents **significant risk to consumer privacy or security** are required to conduct annual cybersecurity audits and submit risk assessments to the CPPA. Biometric data and health data are the categories most likely to trigger this requirement. You should:

1. Conduct a Privacy Risk Assessment covering all three SPI categories.
2. Evaluate whether processing presents "significant risk" (biometrics almost certainly does).
3. Prepare to submit assessments to the CPPA once final rulemaking is completed.

---

## 3. Required Disclosures

### A. Privacy Notice at Collection

At or before collecting SPI, you must notify consumers of:

- The **specific categories of SPI** collected (list all three: precise geolocation, health data, biometric/facial recognition data)
- The **purposes** for which each category is collected and used
- Whether SPI is **sold or shared** with third parties (and to which categories of third parties)
- The **retention period** for each SPI category, or the criteria used to determine it
- A link to your full privacy policy
- The consumer's **right to limit** use of SPI (if applicable)

This notice must appear in the app at the point of data collection — ideally at first launch (for geolocation and account creation), at wearable integration setup (for health metrics), and before biometric enrollment (for facial recognition).

### B. Full Privacy Policy

Your privacy policy must include the following SPI-specific disclosures:

1. **Categories of SPI collected**: Precise geolocation, health/medical information, biometric information (facial recognition)
2. **Purposes of collection** for each SPI category
3. **Whether SPI is sold or shared**: Explicitly state yes or no for each category, and if yes, to what categories of third parties
4. **Consumer rights** with respect to SPI, including the right to limit use under §1798.121
5. **How to exercise the Right to Limit SPI**: Instructions, contact method, and the 15-business-day response timeline
6. **Retention periods** for each SPI category
7. **"Limit the Use of My Sensitive Personal Information" link** or equivalent "Your Privacy Choices" combined link

### C. At-Collection Notices for Each Data Type (Recommended Approach)

**Precise Geolocation** (at first location permission request):
> "We collect your precise location to [purpose]. This is sensitive personal information under California law. You may limit our use of your location data. [Link to SPI limitation]. We retain location data for [period/criteria]. See our Privacy Policy."

**Health Metrics** (at wearable integration setup):
> "By connecting your wearable device, you allow us to collect health metrics including [list]. This is sensitive personal information. We use it to [purpose] and retain it for [period]. You have the right to limit how we use this data. [Link]."

**Biometric Facial Recognition** (before enrollment):
> "We collect your facial recognition data to authenticate your identity. This is biometric sensitive personal information under California law. We [store/do not store] raw facial scans. Derived templates are retained for [period or until account deletion]. You may [opt out of biometric authentication / use an alternative]. [Link to SPI limitation and privacy policy]."

---

## 4. Standard CCPA/CPRA Obligations That Also Apply

In addition to SPI-specific requirements, all standard CPRA obligations apply to this data:

| Obligation | What Is Required |
|---|---|
| Right to Know | Respond within 45 days to requests for categories of SPI collected, sources, purposes, and third parties |
| Right to Delete | Delete SPI upon verified consumer request (with applicable exceptions) within 45 days |
| Right to Correct | Correct inaccurate SPI within 45 days |
| Right to Opt-Out of Sale/Sharing | Honor opt-out immediately if SPI is sold or shared |
| "Do Not Sell or Share" link | Required on homepage if PI is sold or shared |
| Global Privacy Control (GPC) | Must honor GPC signals as a valid opt-out of sale/sharing |
| Non-Discrimination | Cannot deny app features or charge more because a consumer exercises privacy rights |
| Service Provider Contracts | Any vendor receiving SPI (wearable platform API provider, cloud storage, analytics) must have a compliant service provider or contractor agreement |

---

## 5. Practical Compliance Action Plan

**Immediate (before or at launch)**:
- [ ] Update privacy policy to enumerate all three SPI categories with purposes, third-party disclosure, and retention periods
- [ ] Add at-collection notices at the point each SPI type is collected in the app
- [ ] Implement "Limit the Use of My Sensitive Personal Information" link/mechanism
- [ ] Verify all wearable integration and analytics vendors are under compliant service provider agreements

**Near-term (within 30-60 days)**:
- [ ] Audit data flows for each SPI category to ensure data minimization compliance
- [ ] Establish and document retention schedules for geolocation, health, and biometric data
- [ ] Build or configure a consumer request intake system capable of handling Right to Limit SPI (15-business-day response) alongside standard rights requests
- [ ] Implement GPC signal detection and opt-out in the app

**Ongoing**:
- [ ] Conduct annual cybersecurity audit given SPI processing (especially biometrics)
- [ ] Prepare Privacy Risk Assessments for CPPA submission when final rules are issued
- [ ] Review SPI processing purposes annually to confirm they remain within disclosed and permitted uses

---

## 6. Penalty Exposure Summary

Failure to comply with SPI obligations carries significant exposure under CPRA:

- **Unintentional violations**: Up to $2,500 per violation
- **Intentional violations**: Up to $7,500 per violation
- **Biometric data breaches**: Private right of action for $100–$750 per consumer per incident (class action eligible)

Given that biometric facial recognition data is involved, any security incident involving unauthorized access to facial recognition data could trigger both CPPA enforcement and class action litigation. This makes the cybersecurity audit and risk assessment obligations particularly important for your app.

---

*This analysis is based on the California Privacy Rights Act (CPRA) as amended, Cal. Civ. Code §1798.100 et seq., effective January 1, 2023, and CPPA guidance and rulemaking as of April 2026. Consult qualified California privacy counsel for advice specific to your business circumstances.*

# CPRA Classification and Compliance Obligations for Mobile App Data Collection

## Overview

Your mobile application collects three categories of data that trigger heightened obligations under the California Privacy Rights Act (CPRA), which amended and significantly expanded the California Consumer Privacy Act (CCPA). All three data types — precise geolocation, health metrics from wearable integration, and biometric facial recognition — qualify as **Sensitive Personal Information (SPI)** under CPRA, and biometric data also qualifies as a distinct **special category** subject to the most restrictive protections.

---

## 1. Data Classification Under CPRA

### 1.1 Precise Geolocation Data

**Classification: Sensitive Personal Information (SPI)**

Under Cal. Civ. Code § 1798.140(ah)(1)(G), "precise geolocation" is explicitly defined as information that reveals the physical location of a consumer within a radius of 1,850 feet (approximately 1/3 mile) or less. This includes GPS coordinates, cell tower triangulation data, and Wi-Fi positioning data.

- Mobile apps that collect GPS or fine-grained location signals fall squarely within this definition.
- Even periodic or on-demand location collection qualifies — there is no minimum frequency threshold.
- Location data derived from wearable devices is also covered.

### 1.2 Health Metrics from Wearable Integration

**Classification: Sensitive Personal Information (SPI) — potentially also "Personal Information" under CPRA's general framework**

Under Cal. Civ. Code § 1798.140(ah)(1)(C), "personal information collected and analyzed concerning a consumer's health" is classified as SPI. Health metrics from wearables — including heart rate, blood oxygen levels (SpO2), sleep patterns, step counts, stress indicators, menstrual cycle data, ECG readings, and similar physiological measurements — all fall within this definition.

Key points:
- The CPRA does not require data to be medically diagnostic to qualify as health SPI; fitness and wellness metrics are included.
- If the wearable integration involves a third-party SDK or API, data sharing with that third party may constitute a "sale" or "sharing" of SPI requiring disclosure and opt-out rights.
- Health data that also qualifies as Protected Health Information (PHI) under HIPAA must comply with both HIPAA and CPRA simultaneously where applicable.

### 1.3 Biometric Facial Recognition for Authentication

**Classification: Sensitive Personal Information (SPI) AND Biometric Information — the highest-risk category under CPRA**

Under Cal. Civ. Code § 1798.140(ah)(1)(B), SPI includes "a consumer's racial or ethnic origin, religious or philosophical beliefs, or union membership" — but more directly, § 1798.140(c) defines **"biometric information"** as an individual's physiological, biological, or behavioral characteristics that can be used to establish identity, including "imagery of the iris, retina, fingerprint, face, hand, palm, vein patterns, and voice recordings," as well as "keystroke patterns or rhythms, gait patterns or rhythms, and sleep, health, or exercise data that contain identifying information."

Facial recognition data used for authentication involves:
- Capture and processing of facial geometry
- Creation of a facial template or biometric identifier
- Ongoing comparison of facial scans against stored templates

This is SPI under § 1798.140(ah)(1)(E) ("biometric information processed for the purpose of uniquely identifying a consumer") AND constitutes biometric data under the general CPRA personal information definition. The **combination** of collecting, processing, and storing facial recognition data for authentication is among the most regulated activities under CPRA.

---

## 2. Special Obligations Triggered by SPI Collection

### 2.1 Right to Limit Use and Disclosure of SPI

This is the most significant new right introduced by CPRA that did not exist under CCPA.

**Obligation:** Businesses must provide consumers with the right to direct the business to **limit the use and disclosure of their SPI** to only what is necessary to perform the services requested, or as otherwise permitted by CPRA regulations (Cal. Civ. Code § 1798.121).

**Implementation requirements:**
- You must provide a clear and conspicuous link titled **"Limit the Use of My Sensitive Personal Information"** on your homepage (or app equivalent, such as your app's settings page or privacy center).
- Alternatively, if you do not use SPI for purposes beyond providing the requested service, you may include a statement to that effect in your privacy policy to avoid the obligation to post the opt-out link — but only if use is genuinely limited.
- The link can be combined with the "Do Not Sell or Share My Personal Information" link into a single combined opt-out page.

### 2.2 Right to Opt-Out of Sale or Sharing

**Obligation:** If any of the three data types are sold to or shared with third parties for cross-context behavioral advertising, consumers must be given the right to opt out (Cal. Civ. Code § 1798.120).

- This applies to sharing of precise geolocation with advertising networks, analytics platforms, or data brokers.
- Sharing health metrics with third-party wellness platforms or analytics services may qualify.
- Facial recognition templates shared with authentication vendors or identity providers must be disclosed.

### 2.3 Data Minimization

Under CPRA regulations (Cal. Code Regs. tit. 11, § 7002), businesses must adhere to **data minimization principles** for SPI:

- Collection must be **reasonably necessary and proportionate** to the stated purpose.
- You may not collect more SPI than needed for the disclosed purpose.
- You may not retain SPI longer than reasonably necessary.
- **Practical implication:** If facial recognition is used only for authentication, you cannot also use the biometric template for marketing personalization or user behavioral analysis without separate disclosure and legal basis.

### 2.4 Purpose Limitation

SPI collected for one purpose (e.g., authentication via facial recognition) cannot be repurposed for other uses (e.g., emotion detection, demographic inference) without obtaining additional consumer consent or providing a new notice.

### 2.5 Storage Limitation and Retention Schedules

CPRA regulations (Cal. Code Regs. tit. 11, § 7051) require businesses to establish and disclose:
- Retention periods for each category of personal information and SPI collected.
- The criteria used to determine retention periods.
- This applies specifically to biometric data, geolocation history, and health records.

### 2.6 Security Requirements

Given the sensitivity of all three data types, CPRA mandates implementation of **reasonable security measures** (Cal. Civ. Code § 1798.150). The California Attorney General and California Privacy Protection Agency (CPPA) have signaled that SPI requires enhanced security controls. Recommended measures include:
- End-to-end encryption for biometric templates and health data in transit and at rest.
- Strict access controls and role-based permissions for SPI.
- Biometric templates should be stored as irreversible cryptographic hashes rather than raw facial images where technically feasible.
- Geolocation data should be anonymized or aggregated when precise coordinates are no longer necessary.

### 2.7 Automated Decision-Making and Profiling (Pending Regulations)

The CPPA is finalizing **automated decision-making technology (ADMT)** regulations (expected 2025–2026) that will apply to systems that use profiling, including facial recognition for authentication. Once finalized, these may require:
- Pre-use notices to consumers before automated decisions are made.
- Opt-out rights for certain automated decision-making.
- Access rights to understand the logic of automated decisions.

You should monitor CPPA rulemaking and prepare to comply when these regulations take effect.

### 2.8 Risk Assessments (Mandatory for High-Risk Processing)

Under CPRA § 1798.185(a)(15) and CPPA regulations, businesses that process personal information presenting **significant risk** to consumers' privacy must conduct and submit a **Privacy Risk Assessment** to the CPPA. This is likely mandatory for your app given:
- Use of biometric facial recognition (explicitly high-risk).
- Collection of precise geolocation.
- Processing of health metrics.

The CPPA is still finalizing the risk assessment submission requirements, but internal assessments should begin immediately.

---

## 3. Required Disclosures

### 3.1 Privacy Policy Disclosures

Your privacy policy must include all of the following, updated to reflect SPI (Cal. Civ. Code § 1798.100(b), § 1798.130):

**Categories of SPI collected:**
- Precise geolocation (GPS-derived location to within 1,850 feet)
- Health and wellness data (heart rate, sleep, fitness metrics from wearable integration)
- Biometric information (facial geometry/template used for authentication)

**For each SPI category, disclose:**
1. The specific SPI categories collected.
2. The **purposes** for which each SPI category is used (e.g., "biometric data is collected solely to authenticate your identity and is not shared with third parties or used for marketing").
3. Whether SPI is **sold or shared** with third parties, and if so, which categories of third parties.
4. The **retention period** for each SPI category, or if that is not possible, the criteria used to determine how long it is retained.
5. Whether SPI is used to make **inferences** about consumers.

**Third-party disclosures:** If you share any SPI with third parties (including wearable SDKs, analytics vendors, cloud authentication providers), disclose:
- The categories of third parties.
- The purpose of the disclosure.
- Whether the disclosure constitutes a "sale" or "sharing."

### 3.2 At-Collection Notice (Notice at Collection)

Under Cal. Civ. Code § 1798.100(b) and Cal. Code Regs. tit. 11, § 7012, you must provide a **Notice at Collection** at or before the time you collect SPI. For a mobile app, this means:

- **Before enabling location services:** Display a notice specifying that precise geolocation is collected, the purpose, and the categories of third parties with whom it may be shared.
- **Before wearable integration is activated:** Inform users that health metrics will be collected and for what purposes.
- **Before facial recognition enrollment:** Provide a clear disclosure that biometric data will be captured, how the template will be stored, whether it will be shared, and how long it will be retained. This notice must be presented **before** the facial scan is taken.

The Notice at Collection must include:
- Categories of SPI collected.
- Purposes for collection.
- A link to the full privacy policy.
- Whether SPI is sold or shared (or a statement that it is not).

### 3.3 "Limit the Use of My Sensitive Personal Information" Link

As noted above, you must provide a mechanism (typically a link in your app's privacy/settings section and on your website) through which consumers can direct you to limit use of their SPI. This link:
- Must be **clear and conspicuous**.
- Can be combined with "Do Not Sell or Share My Personal Information" into one opt-out interface.
- Must be honored within **15 business days** of receiving the consumer's request.

### 3.4 "Do Not Sell or Share My Personal Information" Link

If any of the three SPI categories are sold or shared with third parties for cross-context behavioral advertising, you must:
- Post this link prominently.
- Honor opt-out requests within 15 business days.
- Maintain records of opt-out requests.

### 3.5 Consumer Rights Notice

Inform users of their full CPRA rights, including:
- **Right to Know:** What SPI is collected and how it is used.
- **Right to Delete:** Request deletion of SPI (subject to exceptions).
- **Right to Correct:** Request correction of inaccurate SPI.
- **Right to Opt-Out:** Of sale or sharing.
- **Right to Limit:** Use of SPI beyond essential purposes.
- **Right to Non-Discrimination:** For exercising privacy rights.

---

## 4. Summary Table

| Data Type | CPRA Classification | SPI Category | Key Obligations |
|---|---|---|---|
| Precise Geolocation | SPI | § 1798.140(ah)(1)(G) | Limit-use right, data minimization, retention disclosure, opt-out if shared |
| Health Metrics (Wearables) | SPI | § 1798.140(ah)(1)(C) | Limit-use right, data minimization, purpose limitation, third-party sharing disclosure |
| Biometric Facial Recognition | SPI + Biometric Information | § 1798.140(ah)(1)(E) | Highest-risk; pre-collection notice mandatory, limit-use right, security requirements, privacy risk assessment likely required |

---

## 5. Recommended Immediate Actions

1. **Audit data flows** for all three SPI categories — map where data is collected, stored, processed, and shared.
2. **Update your privacy policy** to include all required SPI disclosures, retention schedules, and third-party sharing details.
3. **Implement at-collection notices** within the app before any SPI is captured.
4. **Deploy the opt-out and limit-use mechanisms** — either as separate links or combined, accessible in the app and on your website.
5. **Conduct a Privacy Risk Assessment** covering biometric data processing, geolocation tracking, and health data collection.
6. **Review third-party contracts** (wearable SDKs, authentication vendors) to ensure they function as service providers under CPRA rather than third parties to whom you are "selling" or "sharing" data.
7. **Establish retention and deletion schedules** for biometric templates, location history, and health records.
8. **Monitor CPPA rulemaking** on automated decision-making technology regulations, which will affect your facial recognition authentication system.

---

*This analysis is based on the California Privacy Rights Act (Cal. Civ. Code §§ 1798.100–1798.199.100) and California Privacy Protection Agency regulations (Cal. Code Regs. tit. 11, §§ 7000–7304) as of April 2026. Consult qualified legal counsel for advice specific to your business operations.*