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.*

# ITAR Jurisdiction Analysis: Ruggedized Military Laptops

## Short Answer

**Very likely yes** — your company is almost certainly subject to ITAR, and **yes**, you are required to register with DDTC. The analysis below walks through exactly how to reach that conclusion and what to do next.

---

## Step 1 — Understand the Regulatory Framework

ITAR is codified at **22 CFR Parts 120–130**, administered by the Directorate of Defense Trade Controls (DDTC) within the U.S. Department of State. The core question is whether your ruggedized laptop qualifies as a **defense article** — defined at **22 CFR § 120.31** as any item designated on the **United States Munitions List (USML)**, found at **22 CFR § 121.1**.

If your product is on the USML, ITAR applies in full: registration, licensing, recordkeeping, and all other obligations under Parts 120–130.

---

## Step 2 — Apply the USML Jurisdiction Test

Jurisdiction is determined by a two-part test. Work through both steps.

### Test 1: USML Enumeration Test (22 CFR § 121.1)

Ask: *Is our product specifically described in any of the 21 USML categories?*

The most relevant USML categories for ruggedized military computers are:

**Category XI — Military Electronics**
This is the primary category to evaluate. Category XI covers military electronic systems including military navigation, targeting systems, electronic warfare (EW), IFF (Identification Friend or Foe) systems, jamming equipment, and radar. A ruggedized laptop *designed for, integrated into, or qualified for* military electronic systems falls squarely within Category XI's scope.

**Category VIII — Aircraft and Associated Equipment**
If your ruggedized laptop is designed for airborne military platforms (e.g., mission computers in military aircraft, helicopter cockpit systems, UAV ground control), it may fall under Category VIII instead, which covers military aircraft, airframes, and associated equipment including avionics.

**Category XII — Fire Control, Range Finder, Optical and Guidance Equipment**
If the laptop is a fire control computer or targeting system component, Category XII may apply.

**Category XV — Spacecraft Systems**
If the system is integrated into satellite ground control or ISR (intelligence, surveillance, reconnaissance) infrastructure, Category XV warrants review.

**Practical guidance**: If your laptop is marketed, qualified, or sold specifically as military hardware (e.g., MIL-SPEC, MIL-STD-810 ruggedization, classified processing capability, TEMPEST-rated), it is very likely enumerated within one of these categories, most probably **Category XI**.

---

### Test 2: The "Specially Designed" Test (22 CFR § 120.41)

If your product is not *explicitly listed* by name in a USML category, the second question is: *Was the item specially designed for a military application that provides a critical military or intelligence advantage?*

Under **22 CFR § 120.41**, an item is **specially designed** if it was developed, configured, or adapted to provide a critical performance parameter enabling the military capability of a USML end-item. Relevant factors include:

- Was the design driven by military requirements (MIL-SPEC, ITAR program requirements)?
- Does the item provide a performance capability that is critical to the military system it is part of (e.g., encrypted comms, battlefield data processing)?
- Was it developed under a U.S. government defense contract?
- Is it marketed exclusively or primarily to military customers?

**Key principle**: If either the enumeration test *or* the specially designed test is met, the item is a defense article subject to ITAR. You do not need both.

---

## Step 3 — Apply the Tests to Your Product

| Factor | Analysis |
|--------|----------|
| "Military use" designation | Strongly suggests USML applicability — commercial items for military use differ from *commercial* items |
| Ruggedization to MIL-STD-810 | Indicates design for military environment; relevant to specially designed analysis |
| Intended integration into military systems | If used with military electronics (radios, C2 systems, targeting), likely falls under Cat XI |
| Classified processing or TEMPEST rating | Directly enumerated under Cat XI or Cat XIII |
| Sold commercially with incidental military use | May fall under EAR — but requires careful analysis |

**Preliminary conclusion**: A ruggedized laptop *purpose-built* for military use is almost certainly a defense article under USML Category XI (Military Electronics) and/or meets the "specially designed" standard under 22 CFR § 120.41. Unless the laptop is a purely commercial product (e.g., a COTS Dell laptop simply purchased by the military), ITAR jurisdiction is the likely result.

---

## Step 4 — DDTC Registration Requirement

**22 CFR § 122.1** requires DDTC registration for any U.S. person who:

1. **Manufactures** defense articles — even if you never export them
2. **Exports or temporarily imports** defense articles or furnishes defense services
3. **Brokers** defense articles or services (separate Part 129 registration)

**This means: if your product is a defense article, registration is mandatory from the moment you manufacture it** — you do not have to wait until you export.

### Registration Process

1. Create an account at the DDTC Registration Portal: `registration.pmddtc.state.gov`
2. Submit **Form DS-2032** (Statement of Registration) electronically
3. Pay the annual registration fee:
   - Small businesses: **$2,750/year**
   - Larger companies: **$2,750–$27,500/year** (tiered by revenue)
4. Renew annually, at least **60 days before expiration**
5. Notify DDTC within **5 days** of any changes to registration details (22 CFR § 122.4)

**Important**: Registration does not authorize exports. Separate export licenses (e.g., DSP-5) or agreements (TAA/MLA) are required before any defense article leaves the U.S. or technical data is shared with foreign nationals.

---

## Step 5 — How to Get a Formal Determination (Commodity Jurisdiction)

If you have any doubt about whether your laptop is on the USML — for example, if it has both military and commercial variants — you should file a **Commodity Jurisdiction (CJ)** request.

A CJ determination (**22 CFR § 120.4**) is the official, binding process by which DDTC rules on whether an item is controlled under ITAR or EAR. It is the only way to get legal certainty.

**CJ Process:**
1. Submit a CJ request via DDTC's online portal (the same D-Trade system)
2. Provide a full item description, technical specifications, intended end-use, and customer information
3. DDTC (in coordination with DoD and Commerce as needed) issues a written determination
4. The determination is binding and can be cited in your compliance records

**When to file a CJ:**
- Your product has both commercial and military variants
- You are unsure which USML category applies
- You want a written record confirming ITAR or EAR jurisdiction before investing in a compliance program
- A customer or contracting officer requires a formal jurisdiction determination

**Key principle**: When in doubt, treat the item as ITAR-controlled until a CJ confirms otherwise. The penalties for incorrect EAR classification of a true ITAR item are severe.

---

## Step 6 — Summary and Recommended Next Steps

| Question | Answer |
|----------|--------|
| Is our product likely a defense article? | **Yes** — ruggedized laptops for military use are likely covered under USML Cat XI or Cat VIII |
| Are we subject to ITAR? | **Yes**, if the product is on the USML |
| Must we register with DDTC? | **Yes** — 22 CFR § 122.1 requires registration for manufacturers of defense articles |
| How do we get a definitive answer? | File a **Commodity Jurisdiction (CJ)** request under 22 CFR § 120.4 |
| What regulations govern this? | **22 CFR Parts 120–122** are the primary operative sections |

### Immediate Action Items

1. **Do not export** any product or share technical data with foreign nationals until jurisdiction is confirmed and compliance measures are in place
2. **Engage ITAR counsel** to review your product specifications against USML Cat XI (and VIII if applicable)
3. **File a CJ request** (22 CFR § 120.4) if there is any ambiguity about jurisdiction
4. **Register with DDTC** (22 CFR § 122.1) via DS-2032 if you determine — or if your counsel advises — that the product is a defense article
5. **Establish a Technology Control Plan (TCP)** to control access by foreign nationals under 22 CFR § 120.50 (deemed export rules)

---

## Applicable CFR References

| Regulation | Topic |
|------------|-------|
| 22 CFR § 120.31 | Definition of "defense article" |
| 22 CFR § 120.32 | Definition of "defense service" |
| 22 CFR § 120.33 | Definition of "technical data" |
| 22 CFR § 120.4 | Commodity Jurisdiction (CJ) process |
| 22 CFR § 120.41 | "Specially designed" standard |
| 22 CFR § 120.50 | Deemed exports (foreign nationals) |
| 22 CFR § 121.1 | United States Munitions List (USML) — all 21 categories |
| 22 CFR Part 122 | DDTC registration requirements |
| 22 CFR § 122.1 | Who must register |
| 22 CFR § 122.4 | Changes to registration |
| 22 CFR § 122.5 | Record retention (5 years) |

---

*This analysis is based on 22 CFR Parts 120–130 as administered by DDTC. It represents general compliance guidance and not legal advice. For a binding determination, file a Commodity Jurisdiction request with DDTC or consult qualified ITAR counsel.*

# ITAR Compliance Analysis: Ruggedized Laptops for Military Use

## Overview

The International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State's Directorate of Defense Trade Controls (DDTC), governs the export and import of defense articles and services listed on the United States Munitions List (USML). If your ruggedized laptops qualify as defense articles under the USML, your company will be subject to ITAR and required to register with DDTC.

This analysis walks through the key questions you need to answer.

---

## Step 1: Understand What ITAR Covers

ITAR (22 C.F.R. Parts 120–130) controls:

- **Defense articles**: Items specifically designed, developed, configured, adapted, or modified for a military application (or listed on the USML)
- **Defense services**: Furnishing assistance, training, or technical data related to defense articles
- **Technical data**: Information required for the design, development, production, manufacture, assembly, operation, repair, testing, or maintenance of defense articles

ITAR applies to U.S. persons and companies, regardless of where they are located, as well as to anyone exporting controlled items from the United States.

---

## Step 2: Determine Whether Your Product Is on the USML

The USML is codified at **22 C.F.R. Part 121**. It has 21 categories (Category I through XXI). The most relevant categories for ruggedized military laptops are:

### Primary Category to Examine: Category XI — Military Electronics

**22 C.F.R. § 121.1, Category XI(a)** covers:

> Electronic equipment not elsewhere enumerated in this list, specifically designed or modified for military applications, including:
> - Systems, equipment, and components for electronic warfare, target acquisition, reconnaissance, and surveillance
> - Computers **specially designed for military use**
> - Command and control systems

Key provision: If your laptop is **"specifically designed, developed, configured, adapted, or modified"** for military use — as opposed to being a commercial off-the-shelf (COTS) product that the military happens to purchase — it may fall under Category XI.

### Other Potentially Relevant Categories

| Category | Description | Relevance |
|----------|-------------|-----------|
| **Category XI** | Military Electronics | Primary category for military-purpose computers |
| **Category XIII(b)** | Auxiliary Military Equipment | May cover ruggedized enclosures or housings designed to military specifications |
| **Category XV** | Spacecraft and Related Articles | If applicable to airborne military platforms |
| **Category XVII** | Classified Articles | If any aspect is classified |

### The "Specially Designed" Standard

The threshold question is whether your laptop is **"specially designed"** for military use. Under 22 C.F.R. § 120.41, an item is "specially designed" if it:

1. **Was developed** as a result of government-funded development specifically for a military application; OR
2. **Has characteristics** that are peculiarly responsible for achieving or exceeding controlled performance levels, thresholds, or characteristics

**Factors that push toward ITAR-controlled:**
- Designed to MIL-SPEC standards (e.g., MIL-STD-810 for environmental testing, MIL-STD-461 for electromagnetic interference)
- Developed under a military contract (e.g., DARPA, DoD, prime contractor subcontract) specifically for military purposes
- Contains features specifically requested by a military customer not available in commercial products
- Designed to operate in classified environments or handle classified data (e.g., Type 1 encryption)
- Incorporates controlled components (e.g., ITAR-controlled processors, radios, encryption modules)

**Factors that push toward EAR/not ITAR-controlled (potential "COTS" argument):**
- Based on a standard commercial design with only physical ruggedization added
- Sold widely in the commercial market without modification
- No government funding for its development
- Ruggedization (shock, vibration, temperature) is the only modification and is achievable with commercial engineering practices
- Has no military-unique features beyond physical durability

### Applying the "Catch-and-Release" Test

The Export Administration Regulations (EAR, 15 C.F.R. Parts 730–774), administered by the Department of Commerce's Bureau of Industry and Security (BIS), govern items that are NOT on the USML. Many ruggedized laptops that are sold commercially (including to the military) fall under the EAR rather than ITAR.

**Key question**: Is the item "specially designed for a military application" per the USML, OR is it a commercial item that the military buys?

If your ruggedized laptop:
- Is derived from a standard commercial laptop design
- Has been ruggedized using commercial engineering standards
- Is sold through normal commercial channels to anyone who wants a durable computer
- Does not incorporate ITAR-controlled subcomponents or technologies

...then it may fall under the EAR (likely ECCN 4A994 or similar) rather than ITAR. This is a crucial distinction because EAR compliance is significantly less burdensome.

---

## Step 3: Check for ITAR-Controlled Subcomponents

Even if the overall laptop system is not ITAR-controlled, individual components may be. Common ITAR-controlled components that might be incorporated into military laptops include:

- **Encryption modules**: If using NSA-approved Type 1 encryption (e.g., for classified data)
- **GPS receivers**: Military GPS (M-Code capable) receivers are controlled under Category XV(f)
- **Radios**: Software-defined radios with military waveforms (e.g., SINCGARS, HAVEQUICK) may be Category XI
- **Night vision interfaces**: Components interfacing with NVG systems
- **Classified software** or firmware

If your product incorporates any ITAR-controlled components, the entire end item may become a defense article requiring ITAR compliance, regardless of the laptop's own classification.

---

## Step 4: Conduct a Formal Jurisdiction/Classification Determination

The formal process for determining whether your product is ITAR-controlled involves:

### Option A: Internal Jurisdiction Review
Conduct an internal review applying the regulatory criteria above. Document:
1. The product's design history and intent
2. Whether it was developed under a military contract
3. Whether it incorporates ITAR-controlled components
4. How it compares to commercially available products
5. The applicable USML category analysis

### Option B: Commodity Jurisdiction (CJ) Request
If you are uncertain after an internal review, you may submit a **Commodity Jurisdiction (CJ) request** to DDTC under 22 C.F.R. § 120.4.

- The CJ process asks DDTC to formally determine whether your item is subject to ITAR or falls under the EAR
- You submit a detailed description of the item, its design, development history, and intended use
- DDTC will coordinate with DoD and Commerce and issue a formal determination
- Processing typically takes 45–90 days (though it can take longer)
- A CJ determination provides legal certainty and protects you from inadvertent violations

**Recommendation**: For military-specific products, a CJ request is strongly advisable if there is any genuine ambiguity.

---

## Step 5: DDTC Registration Requirements

### Who Must Register

Under **22 C.F.R. § 122.1**, any person or company that:
- **Manufactures** defense articles (even if no export is contemplated), OR
- **Exports** defense articles or defense services

...must register with DDTC **before** engaging in those activities.

Registration is required even if:
- You only sell domestically (manufacturing alone triggers the requirement)
- You are a subcontractor (not the prime exporter)
- You never intend to export

### Registration Process

1. **Register at** the DDTC Registration Portal: [https://www.pmddtc.state.gov](https://www.pmddtc.state.gov)
2. **Complete DD Form 2032** (Statement of Registration)
3. **Pay the registration fee**: Fees are tiered based on the number of licenses anticipated:
   - No anticipated licenses: ~$2,250/year
   - With licenses: $2,750–$3,250/year depending on quantity
4. Registration is **renewed annually**

### Consequences of Failure to Register

Operating as an unregistered manufacturer of ITAR-controlled items is a federal violation subject to:
- Civil penalties up to **$1,394,010 per violation** (as adjusted for inflation)
- Criminal penalties up to **$1,000,000 per violation** and/or **20 years imprisonment**
- Debarment from future government contracting

---

## Step 6: Ongoing ITAR Compliance Obligations

If you determine your product is ITAR-controlled and register with DDTC, you will have ongoing obligations:

### Export Licensing
- Any export of defense articles (including to foreign nationals in the U.S. — the "deemed export" rule) requires either a **license** or an applicable **exemption**
- Common exemptions include ITAR § 126.4 (U.S. government shipments), § 126.6 (foreign military sales), and § 123.22/§ 124.2 (various specific cases)

### Technology Control Plan (TCP)
- Implement a TCP to prevent unauthorized access to ITAR-controlled technical data, especially by foreign nationals

### Empowered Official
- Designate a senior officer as an **Empowered Official** (EO) responsible for ITAR compliance, with authority to sign export licenses

### Recordkeeping
- Maintain records of all ITAR-related transactions for **5 years** (22 C.F.R. § 122.5)

### Voluntary Disclosures
- If you discover a past violation, consider filing a **Voluntary Disclosure** with DDTC, which is a significant mitigating factor in enforcement actions

---

## Summary and Recommendations

| Question | Answer |
|----------|--------|
| Are you subject to ITAR? | **Likely yes**, if your laptop was specifically designed for military applications, developed under military contracts, or incorporates ITAR-controlled components. Possibly no if it is a commercial ruggedized product sold to the military without military-unique design features. |
| Must you register with DDTC? | **Yes, if your product is ITAR-controlled** — registration is required for manufacturers of defense articles regardless of whether you export. |
| How do you determine USML coverage? | Analyze against Category XI (Military Electronics); assess "specially designed" status; review subcomponents; consider filing a CJ request if uncertain. |

### Immediate Action Steps

1. **Engage ITAR counsel**: Retain an attorney specializing in U.S. export controls to conduct a formal jurisdiction review before making compliance decisions.
2. **Review your contracts**: Examine your development history — were you funded by DoD or a defense prime contractor to build this specific product for military use?
3. **Audit your components**: Identify every subcomponent and determine whether any are independently ITAR-controlled.
4. **File a CJ Request if uncertain**: DDTC's formal determination eliminates guesswork and provides a legal safe harbor.
5. **Do not export** (including sharing technical data with foreign persons) until jurisdiction is determined.
6. **Register with DDTC** if you conclude the product is ITAR-controlled.

---

## Key Regulatory References

| Source | Description |
|--------|-------------|
| 22 C.F.R. Parts 120–130 | International Traffic in Arms Regulations (ITAR) |
| 22 C.F.R. § 120.41 | Definition of "specially designed" |
| 22 C.F.R. § 120.4 | Commodity Jurisdiction procedure |
| 22 C.F.R. § 121.1, Cat. XI | USML Category XI: Military Electronics |
| 22 C.F.R. § 122.1 | Registration requirement |
| 22 U.S.C. § 2778 | Arms Export Control Act (AECA) statutory authority |

---

*This analysis is for informational purposes only and does not constitute legal advice. ITAR compliance determinations are highly fact-specific and should be made in consultation with qualified export control counsel.*

# ITAR Compliance: Foreign National Visiting for Defense Electronics Project

## Summary

Hosting a German engineer at your facility to collaborate on a defense electronics project involving ITAR-controlled technical data triggers **deemed export** obligations under 22 CFR § 120.50. You must complete several compliance steps **before the engineer arrives** — failure to do so could constitute an unlicensed export of technical data, exposing your organization to civil penalties of up to $1,369,000 per violation and criminal penalties up to $1,000,000 and 20 years imprisonment per violation (22 CFR Part 127; 22 USC § 2778).

---

## 1. Recognize This as a Deemed Export Situation

Under **22 CFR § 120.50**, a "deemed export" occurs when ITAR-controlled technical data is released to a foreign national inside the United States. That release is treated as an export to the foreign national's **country of citizenship** — in this case, Germany.

**Critical point on citizenship vs. visa status**: The deemed export determination is based on the engineer's **nationality (German citizenship)**, not their work visa type, work authorization status, or length of stay. A German national on any visa category — tourist, J-1, H-1B, etc. — is treated as a deemed export to Germany. Do not assume that a US work authorization or long-term visa changes this analysis.

**Persons exempt from deemed export rules** (22 CFR § 120.62) are limited to US persons: US citizens, lawful permanent residents ("green card" holders), and protected persons under 8 USC § 1324b. A visiting German engineer does not fall into any of these categories.

---

## 2. Determine Whether a License or TAA Is Required

Germany is not subject to a comprehensive ITAR arms embargo (22 CFR § 126.1), so the analysis turns on the nature of the technical data and whether any license exemption applies.

**Step 1 — Classify the technical data**: Confirm the specific USML category (22 CFR § 121.1) covering the defense electronics project data (e.g., Category XI – Military Electronics, Category XV – Spacecraft, or another applicable category). The license requirement applies to technical data directly related to defense articles on the USML.

**Step 2 — Assess exemptions**: Review whether any narrow exemption under 22 CFR Parts 123–126 applies. For most defense electronics collaboration involving a foreign national's access to controlled technical data, no general exemption will cover the disclosure.

**Step 3 — Obtain authorization before access is granted**: If no exemption applies, you must obtain one of the following **before** the engineer is permitted to access any ITAR-controlled technical data, areas, systems, or discussions:

- **Technical Assistance Agreement (TAA)** under 22 CFR § 124.1: This is the standard authorization for sharing ITAR-controlled technical data and providing defense services to a foreign person. It must identify all parties, define the precise scope of data and services, include mandatory clauses (retransfer prohibition, US government rights, record-keeping), and be submitted via DDTC's D-Trade portal. **Processing time is typically 30–60 days** — begin this process well in advance of the visit.

- **Individual Export License (DSP-5 or technical data license under 22 CFR Part 125)**: An individual license may be appropriate if the scope of access is narrow and a full TAA is not warranted. Consult your Empowered Official (EO) and legal counsel to determine which instrument is appropriate.

> **Do not allow the engineer access to any ITAR-controlled data, systems, or discussions until the TAA or individual license is in place and approved by DDTC.**

---

## 3. Screen the Visitor Against Restricted Parties Lists

Before the visit is confirmed and again before the engineer arrives, conduct and document screening against:

- **DDTC Debarred Parties List** (22 CFR § 127.7) — persons debarred from ITAR activities
- **OFAC Specially Designated Nationals (SDN) List** — persons subject to US sanctions
- **BIS Denied Persons List, Entity List, and Unverified List** — persons restricted under EAR (relevant for thoroughness)
- **US State Department Watch Lists**

Screening must be documented with the date run, lists checked, search terms used, and result. Retain records for 5 years (22 CFR § 122.5). If any screening returns a potential match, do not proceed until your legal/compliance team has cleared the match.

---

## 4. Technology Control Plan (TCP) — Visitor Procedures

Your TCP (required as a matter of ITAR compliance best practice and often as a condition of TAA/license approval) must include procedures governing foreign visitor access. Before the visit:

**a. Physical access controls**
- Define which areas of your facility the engineer is authorized to access.
- Restrict access to areas where ITAR-controlled hardware, data, or discussions are present to only those covered by the TAA/license scope.
- Assign an escort for any area where the engineer's access is not explicitly authorized.
- Issue visitor badges that visually distinguish the engineer from cleared personnel.

**b. IT and data access controls**
- Segregate ITAR-controlled networks, file shares, and systems from any systems the engineer will use.
- Do not provide login credentials or access to shared drives, repositories, or collaboration platforms that contain ITAR-controlled data unless specifically covered by the authorization and your TCP controls.
- If the engineer will use a laptop or device, ensure it is not connected to systems containing unauthorized ITAR data.

**c. Visitor log and documentation**
- Maintain a visitor log documenting: name, citizenship, purpose of visit, dates, areas accessed, escort name, and TAA/license reference number.
- Brief the engineer on ITAR obligations upon arrival: no photography of controlled items, no retransfer of data to third parties, no disclosure to other foreign nationals not covered by the agreement.

**d. Brief relevant staff**
- Inform all personnel who will interact with the engineer about the scope of authorized access — what they may and may not discuss or share.

---

## 5. Pre-Arrival Checklist Summary

| Action | Regulatory Basis | Timing |
|--------|-----------------|--------|
| Identify USML category for project technical data | 22 CFR § 121.1 | Immediately |
| Confirm engineer's citizenship (not just visa) | 22 CFR § 120.50 | Immediately |
| Determine TAA or individual license requirement | 22 CFR § 124.1; 22 CFR Part 125 | Immediately |
| Apply for and receive TAA/license from DDTC (D-Trade) | 22 CFR § 124.1 | 30–60 days before visit |
| Screen engineer against DDTC Debarred, OFAC SDN, and BIS lists | 22 CFR § 127.7; OFAC regulations | Before confirming visit; again before arrival |
| Update TCP to include visitor procedures and access scope | 22 CFR compliance best practice | Before visit |
| Define and enforce physical access restrictions | TCP; TAA conditions | Before arrival |
| Segregate ITAR-controlled IT systems and data | TCP | Before arrival |
| Brief staff on authorized disclosure scope | TCP; 22 CFR § 124.9 | Before arrival |
| Establish visitor log | 22 CFR § 122.5 | Day of arrival |
| Brief engineer on ITAR obligations | TAA conditions | Day of arrival |

---

## 6. Key Risk Reminders

- **Do not allow the visit to begin before DDTC authorization is received.** Even informal conversations about ITAR-controlled technical data constitute a deemed export and require a license.
- **Oral disclosures count.** A deemed export violation can occur in a meeting room, hallway, or phone call — not only through document transfer.
- **Three weeks is a long engagement.** Ensure the TAA or license scope fully covers all data, services, and discussions planned for the entire visit, including any incidental access.
- **Germany is a close US ally, but ITAR still applies.** The Australia/UK Treaty exemption (22 CFR § 126.7) does not extend to Germany; no blanket NATO-partner exemption exists under ITAR.

---

*This guidance is based on 22 CFR Parts 120–130 (ITAR) as currently in effect. Consult your Empowered Official and export control legal counsel to confirm the appropriate authorization instrument and verify exemption availability for your specific project.*

# ITAR Compliance Requirements: German Engineer Visit for Defense Electronics Project

## Executive Summary

Hosting a foreign national (German citizen) at your facility who will have access to ITAR-controlled technical data triggers the **"deemed export" rule** under the International Traffic in Arms Regulations (ITAR), 22 C.F.R. Parts 120-130. This is one of the most commonly misunderstood and mishandled compliance obligations in defense contracting. Releasing ITAR-controlled technical data to a foreign national — even within the United States — constitutes an export to that person's country of nationality and requires authorization from the U.S. Department of State, Directorate of Defense Trade Controls (DDTC), unless a valid exemption applies.

**Failure to comply can result in criminal penalties up to $1,000,000 per violation and 20 years imprisonment, civil penalties up to $1,394,010 per violation (as adjusted for inflation), and loss of export privileges.**

---

## Step 1: Determine Nationality and Verify Identity

Before anything else, establish the engineer's exact legal status:

- **Confirm citizenship**: A German citizen is a national of Germany. Germany is not on any U.S. embargo or restricted-party list and is a NATO ally, but foreign national status still triggers ITAR deemed export requirements.
- **Check for dual nationality**: If the engineer holds citizenship in any other country (especially a Country Group D:5, embargoed, or specially designated country), this significantly changes the analysis. ITAR applies to the most restrictive nationality.
- **Verify immigration status in the U.S.**: Permanent residents ("green card" holders) are generally treated as U.S. persons under ITAR (22 C.F.R. § 120.62), but verify this carefully. Temporary visa holders are foreign nationals.
- **Screen against restricted party lists**: Run the individual's name through:
  - DDTC Debarred Parties List (22 C.F.R. Part 127)
  - BIS Denied Persons List, Entity List, Unverified List
  - OFAC SDN and Consolidated Sanctions List
  - FBI Terrorist Screening Database (through appropriate channels)

**Do not allow access to any controlled data until screening is complete and documented.**

---

## Step 2: Identify and Classify the ITAR-Controlled Technical Data

Conduct a thorough review of all technical data the German engineer would be exposed to during the 3-week collaboration:

- **Confirm USML categorization**: Identify which category of the U.S. Munitions List (USML) covers the defense electronics project (e.g., Category XI for military electronics, Category XII for fire control, etc.).
- **Define the scope of technical data**: "Technical data" under ITAR (22 C.F.R. § 120.33) includes information required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification of defense articles. This includes specifications, drawings, software source code, manuals, and even verbal discussions.
- **Identify what the engineer will actually access**: Map out exactly which technical data elements are ITAR-controlled versus those that may be publicly available, EAR-controlled, or otherwise uncontrolled. Not all information on the project may be ITAR-controlled.

---

## Step 3: Determine if an Exemption Applies

Before applying for a license, evaluate whether a valid ITAR exemption covers the intended activities. The most relevant exemptions for this scenario include:

### 3a. NATO Exemption (22 C.F.R. § 126.16)
- Germany is a NATO member. This exemption may authorize certain defense services and technical data transfers among NATO member governments and their contractors.
- **Important caveats**: The exemption applies to government-to-government activities or activities in furtherance of a government contract. The engineer must be working on a project under a NATO contract or agreement. Specific conditions and documentation requirements apply.
- This exemption does **not** apply to all defense electronics work — review the regulation carefully.

### 3b. U.S. Government Agencies Exemption (22 C.F.R. § 126.4)
- If the project is conducted under a U.S. government contract that explicitly authorizes the foreign national's participation, verify whether the contracting agency has a relevant agreement (e.g., a Government-to-Government (G2G) agreement with Germany).

### 3c. Technical Data in the Public Domain (22 C.F.R. § 120.33)
- If some of the technical data is already in the public domain (published, ITAR-approved public release), that specific data does not require authorization for sharing.

### 3d. Fundamental Research Exemption (22 C.F.R. § 120.34)
- Likely **does not apply** to a defense electronics project with controlled technical data, as this exemption is typically for basic and applied research at accredited institutions without access restrictions.

**If no exemption clearly applies, you must obtain a license or other authorization before the engineer arrives.**

---

## Step 4: Apply for the Appropriate ITAR Authorization (If No Exemption Applies)

If an exemption does not cover the activities, you must apply to DDTC for one of the following:

### 4a. DSP-5: Permanent Export License for Technical Data
- Used for the export (including deemed export) of unclassified technical data.
- Filing is done through DDTC's Defense Export Control and Compliance System (DECCS).
- **Processing time**: DDTC's average processing time is 35-45 days for routine applications, but can be significantly longer. **Do not wait until the last minute.**
- Include a detailed technical description of the data to be shared, the USML category, end-use statement, and information about the receiving party (the German engineer and their employer).

### 4b. Technical Assistance Agreement (TAA) (22 C.F.R. § 124.1)
- Required if the collaboration involves providing defense services (not just data), or if there is an ongoing relationship involving the transfer of know-how.
- A TAA is a contract that must be approved by DDTC before execution.
- Processing time is similar to or longer than a DSP-5.

### 4c. Manufacturing License Agreement (MLA) (22 C.F.R. § 124.6)
- Required if the German engineer will be involved in manufacturing defense articles.

**Recommendation**: Engage your export control officer or outside export counsel immediately to determine the correct authorization type and begin the application process.

---

## Step 5: Pre-Arrival Internal Compliance Measures

While awaiting or alongside license applications, implement the following:

### 5a. Engage Your Export Control Officer (ECO)
- Your organization should have a designated ECO or compliance point of contact. Loop them in immediately.
- If you do not have an ECO, consult with legal counsel specializing in ITAR/export control.

### 5b. Notify and Involve the Project Contracting Officer (if applicable)
- If this is a government contract, notify your Contracting Officer (CO) and review your contract for any foreign national access restrictions (e.g., DD Form 254, Security Classification Specification).
- The DD Form 254 may explicitly prohibit or restrict foreign national access — this is an absolute bar regardless of ITAR licensing.

### 5c. Obtain Facility Security Officer (FSO) Approval (if applicable)
- If your facility holds a Facility Clearance (FCL) under the National Industrial Security Program Operating Manual (NISPOM), your FSO must be involved. The Defense Counterintelligence and Security Agency (DCSA) must be notified of planned foreign national visits to cleared facilities.
- A **Foreign National Visit (FNV)** request may need to be submitted to DCSA, potentially requiring government approval before the visit.
- For German nationals, there are established processes under the U.S.-Germany bilateral security agreement.

### 5d. Implement an Access Control Plan
- Define and document exactly which areas of your facility the engineer may access.
- Restrict physical and electronic access to only the ITAR-controlled data covered by your authorization.
- Segregate any classified, sensitive, or unauthorized data from areas where the visitor will work.
- Implement need-to-know limitations — the engineer should only access data directly relevant to their specific collaboration role.

### 5e. Prepare Required Documentation
Compile and have ready:
- Copy of the approved ITAR license or exemption citation
- Passport copy and visa information for the engineer
- Results of restricted party screening
- Visitor non-disclosure agreement (NDA) — tailor for ITAR obligations
- End-use certificate or statement of end use
- Visitor log/access records

---

## Step 6: Prepare Required Agreements with the Engineer and Their Employer

### 6a. Non-Disclosure Agreement (NDA)
- Execute a comprehensive NDA that includes ITAR-specific language: prohibiting re-transfer of controlled technical data to third parties or third countries without U.S. government authorization.
- The NDA should reference the specific USML category and the scope of authorized access.

### 6b. Employee/Visitor ITAR Briefing and Certification
- Provide a written ITAR briefing to the engineer before or upon arrival.
- The briefing should cover: what ITAR is, what data they are authorized to access, prohibitions on re-export or retransfer, and consequences of violations.
- Obtain a signed acknowledgment that they understand their obligations.

### 6c. Agreements with the German Employer (if applicable)
- If the engineer's German employer will also receive or use the technical data, a TAA or DSP-5 covering that employer may also be required.
- Ensure the German company is not on any restricted party list.

---

## Step 7: IT and Cybersecurity Controls

ITAR-controlled technical data in electronic form requires specific controls:

- **Network access**: Do not give the visitor access to your general corporate network. Provide access only to systems containing the specific ITAR data covered by your authorization.
- **Email and file transfer**: Monitor and restrict the ability to email or transfer ITAR-controlled files. Use encrypted, access-controlled repositories.
- **BYOD prohibition**: Do not allow the engineer to use personal devices to access ITAR data. Provide a facility-managed device if needed.
- **Physical media**: Control USB drives, external hard drives, and printing of ITAR data. Log all removable media use.
- **Cloud storage**: Do not use unapproved cloud storage for ITAR data — most standard cloud services (e.g., commercial Google Drive, Dropbox) are not authorized for ITAR storage without specific ITAR-compliant configurations.

---

## Step 8: During the Visit — Ongoing Compliance

- **Escort requirements**: Depending on your facility security requirements, the engineer may need to be escorted at all times in controlled areas.
- **Meeting monitoring**: If meetings involve ITAR technical discussions, ensure only authorized personnel (with appropriate clearances or authorization) are present. Document attendees.
- **Visitor log**: Maintain a detailed visitor log recording dates, times, areas accessed, and data accessed.
- **No unapproved discussions**: Ensure your employees know not to share any ITAR-controlled data beyond the scope of the approved authorization, even in casual conversation.

---

## Step 9: Post-Visit Compliance

- **Retrieve all access credentials**: Revoke facility access, badge, and system credentials on the last day.
- **Document retention**: Retain all ITAR-related records (license, visitor logs, NDAs, briefing acknowledgments, access records) for a minimum of **5 years** as required by 22 C.F.R. § 122.5.
- **Report any violations**: If any unauthorized disclosure occurred, report it to DDTC as a Voluntary Disclosure (22 C.F.R. § 127.12) promptly. Voluntary disclosure is a significant mitigating factor in DDTC enforcement actions.

---

## Summary Checklist

| # | Action Item | Responsible Party | Timeline |
|---|-------------|-------------------|----------|
| 1 | Verify nationality, dual citizenship, immigration status | ECO / HR / Legal | Immediately |
| 2 | Run restricted party screening | ECO | Immediately |
| 3 | Classify all ITAR technical data to be shared | Technical Lead / ECO | Immediately |
| 4 | Determine applicable exemption or begin ITAR license application (DSP-5 or TAA) | ECO / Legal | Immediately — allow 45+ days |
| 5 | Review government contract (DD Form 254) for foreign national restrictions | ECO / Contracts / FSO | Immediately |
| 6 | Submit DCSA Foreign National Visit request (if cleared facility) | FSO | Per DCSA requirements — allow weeks |
| 7 | Implement physical and IT access controls | IT / Facilities / Security | Before arrival |
| 8 | Execute NDA with ITAR-specific language | Legal | Before arrival |
| 9 | Conduct and document ITAR briefing with engineer | ECO | Day of arrival or before |
| 10 | Maintain visitor logs and access records | Security / ECO | Throughout visit |
| 11 | Revoke access and retain records | IT / ECO | Day of departure |

---

## Key Regulatory References

- **22 C.F.R. Part 120**: ITAR General Provisions (definitions of "export," "foreign person," "technical data")
- **22 C.F.R. § 120.62**: Definition of U.S. person
- **22 C.F.R. § 120.33**: Definition of technical data
- **22 C.F.R. Part 122**: Registration of manufacturers and exporters
- **22 C.F.R. Part 123**: Licenses for export of defense articles
- **22 C.F.R. Part 124**: Agreements, off-shore procurement, and other defense services
- **22 C.F.R. Part 126**: General license exemptions (including § 126.16 NATO exemption)
- **22 C.F.R. Part 127**: Violations and penalties
- **32 C.F.R. Part 117 (NISPOM)**: National Industrial Security Program (for cleared facilities)
- **DCSA Foreign National Visit/Assignment guidance**

---

## Critical Warnings

1. **Do not allow access to any ITAR-controlled data until authorization is confirmed.** A license application is not authorization — only an approved license is.
2. **Three weeks is a very short lead time for a DDTC license application.** If you have not already started the process, contact DDTC or legal counsel immediately. DDTC does not typically offer expedited processing except in extraordinary circumstances.
3. **The NATO exemption is not automatic** — it has strict conditions. Do not assume it applies without careful legal review.
4. **Verbal discussions of technical data are controlled** — ITAR applies to oral, written, and electronic transfers of technical data. Brief all employees who will interact with the visitor.
5. **Consult legal counsel**: This analysis is informational. Given the complexity of ITAR and the potential consequences of violations, you should obtain advice from a qualified export control attorney before proceeding.

# ITAR Temporary Export License for Night-Vision Rifle Scope — European Trade Show Circuit

## Classification Confirmation: USML Category XII

A night-vision rifle scope is explicitly controlled under **USML Category XII — Fire Control, Range Finder, Optical and Guidance and Control Equipment** (22 CFR § 121.1, Category XII). This category covers military targeting optics, infrared imaging (military), and night-vision devices (NVDs). There is no ambiguity here — no Commodity Jurisdiction (CJ) determination is needed. The item is a defense article subject to the full requirements of the International Traffic in Arms Regulations (ITAR), 22 CFR Parts 120–130.

---

## Required License: DSP-73 (Temporary Export)

Because the night-vision scope is leaving the US **temporarily** for trade show display and is intended to **return** to the United States, the correct license is the **DSP-73 (Temporary Export License)** under **22 CFR § 123.5**.

A DSP-5 (permanent export) is not appropriate because there is no transfer of ownership or permanent sale to the UK distributor. A Warehouse/Distribution Agreement (22 CFR § 124.14) would apply only if you were stocking items abroad for resale — which is not the case here.

---

## Application Process — D-Trade Portal

All DSP-73 applications are submitted electronically through **DDTC's D-Trade portal** (https://dtrade.pmddtc.state.gov). The following information is required:

1. **Applicant information**: Your DDTC registration number (confirm registration is current under 22 CFR § 122.1).
2. **Item description**: Precise description of the night-vision rifle scope, including USML Category XII citation, model number(s), quantity, and unit value.
3. **Serial numbers**: Document all serial numbers for each unit being exported — this is critical for temporary export tracking and return verification.
4. **Purpose statement**: State clearly that the purpose is "trade show display" and the item will be returned to the US.
5. **Duration**: Specify the 6-month trade show circuit as the requested license period. The license expiry date must be set to allow sufficient time for the items to return to the US.
6. **Destinations**: List all countries in the European show circuit (e.g., UK, Germany, France, etc.), as each destination country must be identified.
7. **UK distributor details**: Identify the UK distributor as the foreign consignee/agent handling the items.

**Processing time**: Allow 30–60 days for DDTC review. Submit well in advance of your planned shipment date.

---

## Key License Conditions and Restrictions

### 1. No Transfer to Foreign Ownership
The DSP-73 strictly prohibits the transfer of the items to foreign ownership, possession, or control on a permanent basis. The UK distributor is acting as a custodian/agent — title and ownership must remain with the US exporter throughout the trade show circuit.

### 2. Items Must Return by License Expiry
All exported items **must physically return to the United States** by the license expiry date. Failure to return the items by the expiry date constitutes a potential ITAR violation under 22 CFR § 127. If delays occur, contact DDTC proactively to seek an amendment or extension before the expiry.

### 3. No Operational or Combat Use
DSP-73 licenses prohibit the use of exported items in combat or operational military deployment. Use is limited to display and demonstration purposes at the trade shows.

### 4. No Sale or Re-Transfer
The items may not be sold, loaned, leased, or otherwise transferred to any third party during the trade show circuit without separate DDTC authorisation.

---

## Re-Export Across European Countries — DDTC Approval Required

This is a critical compliance point for your trade show circuit. When the night-vision scope moves from the UK to other European countries (e.g., Germany, France, Netherlands), each movement constitutes a **re-export** under ITAR.

**Re-export of ITAR-controlled defense articles from one foreign country to another requires prior DDTC approval** (22 CFR § 126.14). The DSP-73 authorises the initial export from the US to the UK, but **does not automatically authorise onward movement to other European countries**.

### How to Address This

There are two approaches:

**Option A — List all destination countries on the DSP-73 at application time**: When submitting the DSP-73, provide a complete itinerary of all European countries in the show circuit and request DDTC authorise movement among all listed countries. DDTC may approve this within the scope of the single DSP-73 if the purpose (trade show display) and all destinations are clearly described.

**Option B — Seek individual re-export authorisation per country**: If the itinerary is not finalised at application time, obtain the DSP-73 for the initial UK export, then seek DDTC's written approval (via amendment or separate correspondence) for each subsequent country leg before the items are moved.

Option A is strongly preferred as it reduces administrative burden and risk of gaps in authorisation coverage.

---

## UK Defence Trade Cooperation Treaty Note

The US–UK Defence Trade Cooperation Treaty provides some streamlined licensing pathways, but it is **not a blanket exemption** for USML Category XII items. Verify with your ITAR counsel whether any treaty-based exemption (22 CFR § 126.7) applies to your specific scope model and transaction structure before relying on it. For a multi-country European circuit, a DSP-73 covering all destinations is the most straightforward and legally certain path.

---

## Pre-Export Compliance Checklist

| Step | Action | CFR Reference |
|------|--------|---------------|
| 1 | Confirm DDTC registration is active and covers your product line | 22 CFR § 122.1 |
| 2 | Classify item under USML Cat XII | 22 CFR § 121.1 |
| 3 | Submit DSP-73 via D-Trade portal listing all EU destinations | 22 CFR § 123.5 |
| 4 | Document all serial numbers before export | 22 CFR § 123.5 |
| 5 | Execute written agreement with UK distributor confirming custodial (not ownership) role | 22 CFR § 123.5 |
| 6 | Confirm DDTC approval covers all re-export legs | 22 CFR § 126.14 |
| 7 | Track license expiry and plan return shipment well before that date | 22 CFR § 123.5 |
| 8 | Retain all export records for 5 years | 22 CFR § 122.5 |

---

## Summary

| Item | Answer |
|------|--------|
| License required | DSP-73 (Temporary Export) |
| USML classification | Category XII — Night-Vision / Optical Targeting Equipment |
| Application portal | DDTC D-Trade (dtrade.pmddtc.state.gov) |
| Processing time | 30–60 days |
| Items must return | Yes — by license expiry date |
| Transfer of ownership permitted | No |
| Re-export to other EU countries | Requires DDTC prior approval — list all countries on the initial application |

Engage your ITAR compliance counsel before submitting to ensure the application accurately describes the trade show circuit, all destination countries, and the custodial arrangement with the UK distributor.

# ITAR Export License for Night-Vision Rifle Scope — Trade Show Circuit (UK/Europe)

## Situation Summary

You intend to export a night-vision rifle scope classified under **USML Category XII(b)** (fire control, range finder, optical and guidance and control equipment) to a UK distributor, which will then carry the item through a multi-country European trade show circuit for six months. This export of a defense article requires a license from the U.S. Department of State, Directorate of Defense Trade Controls (DDTC).

---

## The Correct License: DSP-73 (Temporary Export License)

Because the item will be exported **temporarily** — for display purposes and will be returned to the United States — the applicable license is the **DSP-73, Application for Temporary Export of Unclassified Defense Articles**.

### Why DSP-73 and Not DSP-5?

| Factor | DSP-5 (Permanent Export) | DSP-73 (Temporary Export) |
|---|---|---|
| Intended return to U.S. | No | Yes |
| Purpose | Sale/transfer of title | Demonstration, trade shows, testing |
| Duration | Permanent | Up to 4 years (extensions possible) |
| ATA Carnet compatible | No | Yes |
| Your scenario | Does not apply | **Applies** |

A DSP-5 (permanent export license) would be required only if title/ownership transfers permanently to the UK distributor. Since the item is coming back after the trade shows, DSP-73 is the correct instrument.

---

## Step-by-Step Application Process

### Step 1 — Verify USML Classification

Before applying, confirm the exact ECCN/USML category:
- Night-vision rifle scopes with image intensifier tubes typically fall under **USML Category XII(b)** — electro-optical and night-vision equipment.
- If the scope contains a thermal imaging detector (focal plane array), it may additionally implicate **Category XII(d)**.
- Confirm with your company's empowered official or a licensed export counsel that no EAR (Commerce Control List) classification applies instead.

### Step 2 — Register with DDTC (if not already registered)

Your company must be registered as a manufacturer/exporter with DDTC under 22 CFR Part 122.

- **Form:** DS-2032 (Statement of Registration)
- **Fee:** $2,750 per year (as of 2024; confirm current fee)
- **Portal:** D-Trade (https://dtrade.pmddtc.state.gov)
- Registration must be current at the time of application and throughout the license period.

### Step 3 — Gather Required Documentation

Assemble the following before filing in D-Trade:

| Document | Details |
|---|---|
| **Technical Specification Sheet** | Full description of the item: model number, NSN (if any), key specs (magnification, image intensifier generation, reticle type) |
| **Quantity and Value** | Number of units and fair market value for the items being exported |
| **DSP-83** (Non-Transfer and Use Certificate) | Required for USML items; must be signed by the UK end user (your distributor) and countersigned by the UK government if required |
| **End-Use Statement / Letter from UK Distributor** | On distributor letterhead: confirms the item is for trade show display only, will not be re-exported without U.S. approval, and will be returned by a specified date |
| **Itinerary of Trade Shows** | List of specific events, dates, venues, and countries where the item will be displayed |
| **ATA Carnet** (strongly recommended) | Issued by the U.S. Council for International Business; functions as a "merchandise passport" for temporary exports; required by most European customs authorities and simplifies re-importation |
| **Purchase/Consignment Agreement** | Between your company and the UK distributor, confirming the temporary nature |
| **Export Compliance Program documentation** | DDTC may request evidence of your internal compliance program |

### Step 4 — Complete the DSP-73 Application in D-Trade

Log into the **D-Trade portal** at https://dtrade.pmddtc.state.gov and file electronically:

**Key fields to complete:**

- **Applicant:** Your company (registered exporter)
- **Consignee:** UK distributor (name, address, registration details)
- **End User:** Same as consignee, or list each country's trade show host organization
- **Foreign Countries of Temporary Sojourn:** List every European country where the item will travel — e.g., United Kingdom, Germany, France, Netherlands, Italy, etc. Do not omit any country; unlicensed transit is a violation.
- **USML Category/Subcategory:** Category XII, specify subcategory (b) or as applicable
- **Item Description:** Full technical description matching the specification sheet
- **Quantity:** Number of units
- **Value:** Dollar value
- **Requested Duration:** Up to 4 years permitted; for a 6-month circuit, request 12 months to allow buffer for return shipping and customs delays
- **Purpose:** "Trade show display and demonstration — item to be returned to the United States upon conclusion of events"

**Supporting attachments** (uploaded directly in D-Trade):
- Technical data package
- Signed DSP-83
- End-user letter and trade show itinerary
- Any relevant MOU or agreement

### Step 5 — Pay the Filing Fee

DDTC charges a fee per license application. As of 2025, fees vary by transaction type. Confirm the current fee schedule on the DDTC website. Payment is made through D-Trade.

### Step 6 — DDTC Review

- **Standard processing time:** 30–60 business days for Category XII items (which receive enhanced scrutiny as a sensitive category)
- **Expedited processing:** Available in limited circumstances; contact DDTC directly
- DDTC may issue a **Request for Additional Information (RAI)** — respond promptly to avoid delays
- State Department may coordinate with Department of Defense (DTSA) for technical review
- Plan for **at least 90 days** lead time before the first trade show date

### Step 7 — Obtain the ATA Carnet

Simultaneously with or shortly after filing the DSP-73, apply for an **ATA Carnet** through the U.S. Council for International Business (USCIB):

- Website: https://www.atacarnet.com
- The carnet covers customs duties in participating countries and simplifies border crossings
- All European Union countries and the UK are ATA Carnet contracting parties
- The carnet must list each country of sojourn matching the DSP-73
- Carnet validity: typically 1 year; must cover the entire circuit duration

### Step 8 — Shipper's Export Declaration / Electronic Export Information (EEI)

For each physical export shipment:
- File **Electronic Export Information (EEI)** in the Automated Export System (AES) via ACE (https://ace.cbp.dhs.gov)
- Reference the DSP-73 license number and USML Category XII classification
- Use Schedule B code appropriate for the item
- File before the item departs U.S. territory

### Step 9 — Country-Specific Considerations for Europe

Post-Brexit, the UK is no longer part of the EU's common trade regime. This affects the circuit:

| Country/Bloc | Consideration |
|---|---|
| **United Kingdom** | UK has its own export control regime (OGEL/SIEL under the Export Control Order 2008). Your UK distributor must verify they hold the appropriate UK import authorization and any re-export licenses required to move the item into EU countries. |
| **EU Countries (Germany, France, etc.)** | EU Common Position on arms exports; each country may have national import authorization requirements for USML defense articles. Verify with each host country's customs authority. |
| **Germany** | BAFA (Federal Office for Economic Affairs and Export Control) controls imports of defense equipment — your UK distributor may need a German import permit |
| **France** | SBDU/DGA controls — temporary import under ATA Carnet typically accepted for trade shows but confirm with French customs |

The DSP-73 covers the U.S. export side. The UK distributor bears responsibility for compliance with local import/re-export laws in each country visited. Contractually require your distributor to obtain all necessary host-country permits before crossing each border.

---

## Additional ITAR Obligations During the Circuit

### Re-Export Prohibition
The UK distributor **may not re-export** the item to any third country not listed on the DSP-73 without obtaining a separate U.S. re-export authorization (or license amendment). If the show circuit expands to additional countries, you must amend the license before the item travels there.

### No Technology Transfer
Trade show demonstration must be conducted in a manner that prevents unauthorized nationals from accessing technical data. Under ITAR 22 CFR § 120.50 (release of technical data to foreign persons), even showing a foreign national how the scope operates could constitute a "deemed export" of ITAR-controlled technical data if that data is not already in the public domain. Work with your distributor to:
- Restrict hands-on access by nationals of embargoed countries (Iran, North Korea, Russia, China, etc.)
- Avoid providing manuals, schematics, or maintenance data to foreign persons without a separate authorization

### Recordkeeping
Under 22 CFR § 122.5, you must maintain records of the transaction for **5 years** from the date of export, including the DSP-73, ATA Carnet, shipping records, EEI filings, and all correspondence with the distributor.

### Return of the Item
Upon conclusion of the circuit:
- The item must be returned to the United States
- File EEI for the re-importation (CBP entry)
- Retain documentation proving return
- If the item will instead be sold to the UK distributor or another foreign party, you must obtain a separate **DSP-5 permanent export license** before transfer of title occurs

---

## Key ITAR Regulatory References

- **22 CFR Part 123** — Licenses for the Export and Temporary Import of Defense Articles (§ 123.4 covers exemptions; § 123.5 and § 123.10 cover the DSP-73 process)
- **22 CFR Part 121** — United States Munitions List (Category XII)
- **22 CFR Part 122** — Registration of Manufacturers and Exporters
- **22 CFR Part 126** — General policies and provisions (§ 126.18 covers dual/third-country national screening)
- **DDTC Guidelines on Temporary Exports**

---

## Potential Exemptions to Consider (and Why They Likely Don't Apply)

### 22 CFR § 123.4 — License Exemptions for Defense Articles
Certain temporary export exemptions exist (e.g., for items accompanying U.S. government personnel, NATO cooperative programs), but none cleanly cover a commercial trade show circuit through multiple non-NATO-only countries handled by a foreign distributor. **A DSP-73 license is required.**

### 22 CFR § 123.22(b)(2) — Trade Show Exemption
ITAR does contain a limited trade show exemption for items exported by U.S. persons to U.S.-controlled exhibitions. However, because this item will be handled by a **UK distributor** (a foreign person), not a U.S. person, and will travel across multiple countries over 6 months, this exemption does not apply. A DSP-73 is required.

---

## Summary Checklist

- [ ] Confirm USML Category XII classification with empowered official or export counsel
- [ ] Verify DDTC registration is current (DS-2032)
- [ ] Obtain signed DSP-83 from UK distributor
- [ ] Compile trade show itinerary (all countries, dates, venues)
- [ ] Prepare end-user letter from UK distributor
- [ ] File DSP-73 application in D-Trade (allow 90+ days)
- [ ] Apply for ATA Carnet through USCIB
- [ ] Require UK distributor to obtain host-country import permits for each country
- [ ] Brief distributor on ITAR re-export, deemed export, and recordkeeping obligations
- [ ] File EEI in AES before export
- [ ] Upon return: file re-import documentation, retain records for 5 years

---

## Recommended Next Steps

1. **Engage ITAR export counsel immediately** — given the multi-country circuit and Category XII sensitivity, legal counsel specializing in DDTC licensing is strongly advised.
2. **Contact DDTC directly** via their Response Team at 202-663-2700 or DDTCResponseTeam@state.gov for pre-application guidance.
3. **Brief your UK distributor** on their ITAR obligations as a foreign consignee before the license application is filed.
4. **Start the process at least 90–120 days** before the first trade show to allow for DDTC review, potential RAIs, and ATA Carnet issuance.

---

*This response reflects ITAR regulations and DDTC practice as of May 2026. Regulations and fee schedules are subject to change. This is informational guidance and does not constitute legal advice. Consult a licensed export attorney for your specific transaction.*

# ITAR Violation Response: Unauthorized Export of Technical Drawings to Taiwan

## Situation Summary

An engineer emailed ITAR-controlled technical drawings to a supplier in Taiwan without a license six months ago. This constitutes an **unauthorized export of technical data** under ITAR and is a serious violation of 22 CFR Part 125 (export of technical data) and 22 CFR Part 127 (violations and penalties). Immediate, structured action is required.

---

## Immediate Actions — Do These First

### 1. Place a Litigation Hold on All Relevant Records

Before anything else, preserve all evidence. Issue a litigation hold immediately covering:

- The email(s) in question and all email chains related to the incident
- The technical drawings and any attachments sent
- Communications with the Taiwan supplier (before and after the disclosure)
- Any internal communications about the drawings or the supplier relationship
- The engineer's email account, file access logs, and any shared drives

Destroying, modifying, or failing to preserve records after discovery of a potential violation can constitute obstruction and will be treated as an aggravating factor by DDTC.

---

### 2. File a Voluntary Self-Disclosure (VSD) — 22 CFR § 127.12

**Voluntary Self-Disclosure is the single most important step you can take.** DDTC explicitly recognizes VSD as the strongest available mitigating factor. Filing promptly signals good faith and significantly reduces the risk of criminal referral and civil penalties.

#### VSD Process — Three Stages

**Stage 1: Initial Notification (file within ~30 days of discovery)**

Submit a brief written notification to the DDTC Director of Compliance. The initial notification should include:

- Your company name and DDTC registration number
- A general description of the potential violation (technical data sent without a license)
- The destination country (Taiwan)
- An estimate of the number of occurrences
- A request for a **tolling agreement** to preserve the statute of limitations while you complete the internal investigation

The initial notification does not need to be complete or perfectly detailed — accuracy matters more than comprehensiveness at this stage. File it promptly.

**Stage 2: Internal Investigation (typically 30–90 days)**

Conduct a thorough internal investigation to establish:

- What technical data was sent (drawings, specifications, part numbers, USML category)
- Who sent it and who received it (names, roles, nationalities)
- When it was sent (dates, any follow-up transmissions)
- Whether the drawings were accessed, copied, shared further, or used by the Taiwan supplier
- Whether there are any other undisclosed transmissions to this or other foreign parties
- Root cause: was this a training failure, a process gap, or a deliberate act?
- Whether any similar violations exist elsewhere in the organization

Pull all records — emails, shipping documents, license files, TAA files, and engineering access logs.

**Stage 3: Final VSD Report (file within ~60–90 days of initial notification)**

Submit a comprehensive written report to DDTC including:

- A detailed factual narrative of all violations
- The specific CFR sections violated (e.g., 22 CFR § 125.2 for unlicensed export of technical data, 22 CFR § 127.1 for the violation itself)
- Identification of all parties (the engineer, the supplier, recipients in Taiwan)
- A complete timeline of events
- Root cause analysis
- Corrective actions already implemented
- Proposed additional remediation measures

**Stage 4: DDTC Review and Resolution**

DDTC will review the report, may request additional information, and will determine the outcome. For cooperative VSDs with no prior violations: outcomes range from no action or a warning letter to a reduced civil penalty. Most cooperative VSDs resolve within 6–18 months.

---

### 3. Retain Outside Counsel with ITAR/Export Control Expertise

Engage attorneys experienced in DDTC enforcement and export control law before filing the VSD. Counsel can:

- Guide the scope and privilege of the internal investigation
- Draft the VSD in the most favorable light while remaining accurate
- Assess criminal exposure and advise on DOJ referral risk
- Interface with DDTC on your behalf

---

### 4. Identify and Assess the Technical Data Disclosed

Confirm the USML classification of the technical drawings. Technical data is ITAR-controlled under 22 CFR § 120.33 if it is directly related to a defense article on the United States Munitions List (22 CFR § 121.1). Identify:

- The specific USML category (e.g., Category I for firearms, Category VIII for aircraft, Category XI for military electronics, etc.)
- Whether the drawings include manufacturing or production data (higher risk) vs. general performance specifications
- Whether a TAA or DSP-5/DSP-73 license would have been required
- Whether any export exemption under 22 CFR § 125.4 might arguably apply (unlikely if sent to a supplier for production purposes, but assess)

---

### 5. Notify Senior Management and Your Empowered Official

Your designated Empowered Official (22 CFR § 120.67) must be informed immediately. Senior management involvement demonstrates that the company is taking the matter seriously, which DDTC expects.

---

### 6. Implement Immediate Remediation

While the investigation is ongoing, take corrective steps now:

- Notify the Taiwan supplier in writing that the technical data was disclosed in error, that it is ITAR-controlled, and that it must not be used, copied, or disclosed further
- Request written acknowledgment and return or certified destruction of the drawings
- Temporarily restrict the engineer's access to ITAR-controlled data pending investigation outcome
- Review whether any other ITAR-controlled data has been shared with foreign parties without authorization
- Assess whether your Technology Control Plan (TCP) and training program need immediate updates

---

## Penalty Exposure

### Civil Penalties — 22 CFR Part 127

- **Up to $1,369,000 per violation** (adjusted annually under the Federal Civil Penalties Inflation Adjustment Act)
- Each unauthorized export of technical data constitutes a **separate violation**
- If multiple drawings were sent, or sent in multiple emails, DDTC may count each as a separate violation
- DDTC may impose civil penalties via Consent Agreement without requiring criminal prosecution

### Criminal Penalties — 22 USC § 2778(c)

- **Up to $1,000,000 fine per violation**
- **Up to 20 years imprisonment per violation**
- Criminal cases are referred to the Department of Justice National Security Division
- Criminal exposure is most acute if the violation was willful, deliberate, or if the engineer or management knew a license was required and acted anyway

### Debarment — 22 CFR § 127.7

- DDTC may debar the company from all ITAR privileges (registration, licensing, TAAs, MLAs, government contracting)
- Debarment is typically 3 years but can be permanent for egregious violations
- Debarment is published publicly on the DDTC Debarred Parties List

### Other Consequences

- Seizure and forfeiture of articles involved in the violation (22 USC § 2778(e))
- Suspension of export privileges during investigation
- Public disclosure — Consent Agreements are published by DDTC, creating reputational harm
- Potential impact on existing US government contracts if company holds defense contracts

---

## Factors That Will Affect Your Outcome

### Mitigating Factors (work in your favor)

- **Voluntary self-disclosure** — the most important factor; file promptly
- Full cooperation with DDTC's investigation
- No prior ITAR violations
- Effective pre-existing compliance programme
- Prompt remediation steps taken
- Relatively low national security harm (Taiwan is not an embargoed country; assess whether the supplier or technology raises specific national security concerns)
- Low transaction value

### Aggravating Factors (increase exposure)

- Willful or deliberate violation — if the engineer knew a license was required
- Senior management awareness or involvement
- Pattern of violations (more than this one incident)
- Further dissemination of the drawings by the Taiwan supplier
- Obstruction, destruction of records, or failure to cooperate
- Prior ITAR violations or enforcement history

Taiwan is not subject to a comprehensive arms embargo under 22 CFR § 126.1, which is a favorable fact. However, certain USML categories and specific defense technologies may carry heightened national security sensitivity even for Taiwan; assess the specific drawings against DDTC guidance.

---

## Summary Checklist

| Action | Priority | Timing |
|--------|----------|--------|
| Issue litigation hold on all relevant records | CRITICAL | Immediately |
| Retain outside export control counsel | CRITICAL | Within 24–48 hours |
| Notify Empowered Official and senior management | CRITICAL | Immediately |
| Confirm USML classification of technical drawings | HIGH | Within 1 week |
| File initial VSD notification to DDTC | HIGH | Within ~30 days of discovery |
| Notify Taiwan supplier to cease use / return/destroy drawings | HIGH | Within 1 week |
| Conduct internal investigation | HIGH | 30–90 days |
| Restrict engineer's ITAR access pending investigation | MODERATE | Immediately |
| Submit final VSD report to DDTC | HIGH | Within ~60–90 days of initial notification |
| Implement corrective actions (training, TCP update, process controls) | MODERATE | During/after investigation |

---

## Key Regulatory References

- **22 CFR § 127.12** — Voluntary Self-Disclosure
- **22 CFR § 127.1** — Violations
- **22 CFR Part 125** — Licenses for Export of Technical Data
- **22 CFR § 120.33** — Definition of Technical Data
- **22 CFR § 127.7** — Debarment
- **22 USC § 2778** — Criminal and civil penalties
- **22 CFR § 120.67** — Empowered Official
- **22 CFR § 122.5** — Record retention (5 years)

---

*Note: This guidance is based on ITAR regulations as of the date of this response. DDTC enforcement practice evolves; retain qualified export control counsel before filing any disclosure or making representations to DDTC.*

# ITAR Violation Response: Unauthorized Export of Technical Drawings to Taiwan

## Executive Summary

The unauthorized email transmission of ITAR-controlled technical drawings to a supplier in Taiwan constitutes a serious violation of the International Traffic in Arms Regulations (ITAR), 22 C.F.R. Parts 120-130, administered by the U.S. Department of State's Directorate of Defense Trade Controls (DDTC). This is a significant export control violation with potentially severe criminal, civil, and administrative consequences. Immediate and structured action is required.

---

## 1. Understanding What Happened

### Nature of the Violation
- **Unauthorized Export**: Emailing ITAR-controlled technical drawings to a foreign person/entity without a license constitutes an "export" under ITAR (22 C.F.R. § 120.17), even when transmitted electronically.
- **Taiwan is a Foreign Country**: Despite generally friendly U.S.-Taiwan relations, Taiwan is treated as a foreign country under ITAR. A license or other authorization is required to export ITAR-controlled items or technical data to Taiwan.
- **Technical Data is Controlled**: Technical drawings, specifications, and design documents related to defense articles listed on the U.S. Munitions List (USML) are "technical data" under 22 C.F.R. § 120.33 and are controlled under ITAR.
- **The Email Itself is the Violation**: Electronic transmission of controlled technical data is an export. The violation occurred at the moment the email was sent, regardless of whether the recipient actually accessed, used, or disseminated the information.

### The 6-Month Discovery Gap
The fact that this occurred 6 months ago and is only now being discovered is itself a compliance concern. It suggests gaps in:
- Employee training and awareness
- Export control monitoring/screening of outbound communications
- Technical controls on data transmission
- Internal reporting culture

---

## 2. Immediate Steps to Take

### Step 1: Stop the Bleeding — Contain the Violation (Do Immediately)

- **Notify the supplier in Taiwan immediately** to return or destroy the technical drawings and confirm in writing that no copies were retained, shared further, or used.
- **Preserve all evidence**: Do not delete emails, logs, or communications. Issue a litigation hold immediately.
- **Identify the full scope**: Determine exactly which drawings were sent, their USML classification, and whether any additional disclosures occurred (e.g., did the supplier share with others?).
- **Restrict the engineer's export privileges** pending investigation — ensure no further unauthorized transmissions occur.

### Step 2: Engage Legal Counsel Specializing in Export Controls (Within 24-48 Hours)

- Retain an attorney with specific ITAR/export control expertise immediately. Do not attempt to self-navigate this.
- Attorney-client privilege is critical here — communications about the violation should go through counsel.
- Counsel will guide the voluntary disclosure decision (see below) and help frame the narrative to regulators.

### Step 3: Conduct an Internal Investigation

- Interview the engineer to understand intent, circumstances, and whether this was an isolated incident.
- Determine whether anyone else knew about the transmission.
- Review other outbound communications for similar issues.
- Identify which specific USML category the technical drawings fall under (this affects severity).
- Determine whether any licenses, agreements (e.g., TAAs, MLAs), or exemptions existed that may cover or partially cover this activity.

### Step 4: Assess Voluntary Self-Disclosure to DDTC (Critical Decision — Within Days to Weeks)

Under 22 C.F.R. § 127.12, companies can submit a Voluntary Self-Disclosure (VSD) to DDTC. This is one of the most important decisions you will make:

**Benefits of Voluntary Self-Disclosure:**
- DDTC treats VSDs as a significant mitigating factor in penalty determinations.
- Penalties are typically substantially reduced — often by 50% or more.
- Demonstrates good faith and a commitment to compliance.
- Reduces the risk of criminal referral to the Department of Justice.
- Protects against debarment from future defense contracting in many cases.

**Risks of Not Disclosing:**
- If DDTC discovers the violation through other means (supplier audit, counterpart intelligence, whistleblower), the company loses all mitigation credit.
- Non-disclosure can be construed as willful concealment, dramatically increasing penalties and criminal exposure.
- Statutes of limitations for ITAR violations are generally 5 years for criminal charges; regulators have long memories.

**VSD Process:**
1. Submit an initial notification letter to DDTC within a short timeframe (counsel will advise on timing).
2. Follow up with a full disclosure package including a detailed account of the violation, corrective actions taken, and remediation plan.
3. Cooperate fully with any DDTC inquiry.

### Step 5: Apply for a Retroactive or Nunc Pro Tunc License (If Applicable)

- In some cases, you may be able to apply for a license to retroactively authorize the disclosure, or at minimum to regularize the ongoing relationship with the supplier.
- Counsel will advise whether this is feasible based on the specific technical data and USML category.

### Step 6: Implement Immediate Remediation

- Suspend the existing supplier relationship until proper authorizations are in place.
- Review all other international supplier relationships for similar risks.
- Immediately implement or strengthen export control policies, procedures, and technical controls.

---

## 3. Potential Penalties and Exposures

ITAR violations carry some of the most severe penalties in U.S. law. Both the company and the individual engineer face exposure.

### Criminal Penalties (22 U.S.C. § 2778(c); 22 C.F.R. Part 127)

- **Per violation**: Up to **20 years imprisonment** and/or up to **$1,000,000 in fines** per violation.
- Each item exported and each transaction can constitute a separate violation.
- Both the company (organizational criminal liability) and the individual engineer can be prosecuted.
- The Department of Justice (DOJ) handles criminal ITAR prosecutions.
- Intent ("willfulness") is required for criminal liability, but courts interpret this broadly — ignoring obvious red flags can suffice.

### Civil Penalties (22 C.F.R. § 127.10)

- Up to **$1,368,136 per violation** (amount adjusted periodically for inflation under the Federal Civil Penalties Inflation Adjustment Act; this figure reflects recent adjustments).
- DDTC calculates penalties per transaction, per controlled item, and per violation.
- A single email with multiple controlled drawings could be treated as multiple violations.
- Civil penalties do not require proof of criminal intent.

### Administrative/Debarment Penalties (22 C.F.R. § 127.7)

- DDTC can **debar** companies and individuals from participating in defense trade (import and export of defense articles and services) for up to **3 years** per violation.
- Debarment is devastating for defense contractors and can effectively end a business.
- Even partial debarment (restrictions on specific USML categories) is extremely disruptive.

### Export Enforcement Coordination Center (E2C2) and DOJ Criminal Division

- Multiple agencies have jurisdiction over export control violations: DDTC (State), BIS (Commerce, for EAR items), OFAC (Treasury, for sanctions), and DOJ/FBI for criminal enforcement.
- While this scenario involves ITAR (State/DDTC), the DOJ Criminal Division's National Security Division prosecutes ITAR crimes.

### Reputational and Contractual Consequences

- **Loss of facility security clearance** if the company holds one.
- **Suspension or termination of government contracts** — Contracting Officers may suspend or debar you from federal contracting.
- **Negative past performance ratings** affecting future contract awards.
- **Reputational damage** in the defense industrial base and with prime contractors.
- **Insurance implications** — Directors & Officers (D&O) and errors & omissions policies may have export control exclusions.

---

## 4. Mitigating Factors That Affect Penalty Severity

DDTC considers multiple factors when determining penalties:

**Factors That Reduce Penalties:**
- Voluntary self-disclosure (most significant mitigation)
- Isolated, non-systemic violation
- No evidence of intent to harm national security or violate the law
- Immediate corrective action upon discovery
- Robust existing compliance program (even if it failed here)
- Full cooperation with DDTC investigation
- No prior ITAR violations
- Minimal harm — e.g., Taiwan supplier did not further disseminate or use the data
- Quick retrieval/destruction of disclosed materials

**Factors That Increase Penalties:**
- Willfulness or deliberate circumvention of ITAR
- Prior ITAR violations
- Involvement of state actors or foreign intelligence services
- Data transmitted to a sanctioned country or denied party (Taiwan is not sanctioned, which is favorable)
- Systemic compliance failures across the organization
- Failure to cooperate or attempted concealment
- Harm to national security or sensitive programs

---

## 5. Taiwan-Specific Considerations

- Taiwan is **not a sanctioned country** and is not on restricted party lists, which is a mitigating factor.
- However, Taiwan is treated as a foreign country under ITAR, and no ITAR exemption generally covers Taiwan for most technical data transmissions without a license.
- Taiwan is eligible for ITAR licenses, and approvals for Taiwan are common, but approval is not retroactive.
- The geopolitical context (U.S.-Taiwan relations, semiconductor supply chains) will not substitute for a license.
- There is no "friendly country" exemption under ITAR that automatically covers Taiwan.

---

## 6. Medium-Term Remediation Plan

After handling the immediate crisis, implement the following:

### Compliance Program Enhancement
- Conduct a comprehensive ITAR/EAR audit of all technical data and products.
- Classify all technical data under the USML or Commerce Control List (CCL) as appropriate.
- Implement an export control management system (ECMS) to screen all outbound transmissions.
- Establish a Technology Control Plan (TCP) governing access to ITAR-controlled technical data.

### Training and Culture
- Mandatory ITAR training for all employees who handle technical data — not just compliance staff.
- Specific training on electronic transmission risks (email, cloud storage, collaboration tools).
- Clear escalation procedures for employees who are uncertain about export control requirements.
- Anonymous reporting hotline for potential violations.

### Technical Controls
- Data Loss Prevention (DLP) tools to flag or block transmission of ITAR-tagged data to foreign domains.
- Email archiving with export control keyword and metadata screening.
- Access controls limiting who can access ITAR technical data.
- Encryption requirements for any authorized transmissions.

### Process Controls
- Require export control review and sign-off before sharing any technical data with foreign persons or entities.
- Maintain a log of all technical data transmissions to foreign parties.
- Establish a formal license management process for all DDTC licenses and agreements.

---

## 7. Timeline Summary

| Timeframe | Action |
|-----------|--------|
| Immediately (Day 1) | Contain violation, notify supplier to cease use/return data, preserve evidence, brief senior leadership and legal |
| 24-48 hours | Retain export control counsel, issue litigation hold, begin internal investigation |
| 1-2 weeks | Complete initial investigation, assess VSD decision with counsel, begin drafting VSD letter |
| 2-4 weeks | Submit VSD initial notification to DDTC (if proceeding), implement emergency compliance controls |
| 30-90 days | Submit full VSD package to DDTC, complete comprehensive ITAR audit, deploy enhanced controls |
| Ongoing | Enhanced monitoring, training, and compliance program improvements |

---

## 8. Key Regulatory References

- **22 U.S.C. § 2778** — Arms Export Control Act (AECA), the authorizing statute
- **22 C.F.R. Parts 120-130** — International Traffic in Arms Regulations (ITAR)
- **22 C.F.R. § 120.17** — Definition of "Export" (includes electronic transmission)
- **22 C.F.R. § 120.33** — Definition of "Technical Data"
- **22 C.F.R. Part 121** — The United States Munitions List (USML)
- **22 C.F.R. § 127.10** — Civil penalties
- **22 C.F.R. § 127.12** — Voluntary self-disclosure procedures
- **22 C.F.R. § 127.7** — Debarment

---

## Conclusion

This is a serious situation that demands immediate, coordinated action. The single most important step — after containing the violation and retaining export control counsel — is making a well-prepared voluntary self-disclosure to DDTC. Companies that self-disclose promptly, cooperate fully, and implement meaningful remediation routinely achieve substantially reduced penalties compared to those discovered through government investigation. The penalty exposure without mitigation is significant: potentially millions of dollars in civil fines, possible criminal prosecution of the engineer and company officers, and reputational consequences that can affect defense contracting for years.

Do not delay. Do not attempt to quietly ignore this. The path through this situation, while uncomfortable, is to act with speed, transparency with regulators (through counsel), and demonstrated commitment to compliance.

---

*This response is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel with ITAR/export control expertise before taking any action.*

# Technical Assistance Agreement (TAA) for Missile Guidance System Design Data — India

## 1. Regulatory Framework and USML Classification

Sharing missile guidance system design data with a foreign defence manufacturer requires a **Technical Assistance Agreement (TAA)** under **22 CFR § 124.1**. This is the mandatory authorisation instrument for the export of ITAR-controlled technical data and defence services to foreign persons.

### USML Classification

Missile guidance systems fall under **USML Category IV** (22 CFR § 121.1, Category IV): "Launch Vehicles, Guided Missiles, Ballistic Missiles, Rockets, Torpedoes, Bombs and Mines." This category covers all military rockets, missiles, and associated guidance and control systems.

Additionally, components of the guidance system may independently fall under:
- **USML Category XII**: Fire Control, Guidance and Control Equipment (military gyroscopes, targeting systems, guidance computers)
- **USML Category XI**: Military Electronics (navigation and targeting electronics)

All related technical data — blueprints, drawings, specifications, software, test reports — constitutes **ITAR-controlled technical data** under 22 CFR § 120.33 and cannot be exported without a TAA or other DDTC authorisation.

**A TAA is the correct and required instrument** here, not a DSP-5 (which covers hardware) or an MLA (which covers licensed foreign manufacture).

---

## 2. India-Specific Considerations

India is a **Major Defence Partner** of the United States and has benefited from significant defence trade cooperation, including a foundational agreement (GSOMIA/COMCASA/BECA/LEMOA framework). However, this status **does not exempt** US exporters from ITAR licence requirements.

Key points:
- India is **not** a treaty partner under the Australia–UK–US Defence Trade Cooperation Treaties (22 CFR §§ 126.6–126.7), which provide streamlined licensing only for the UK and Australia
- India is **not** covered by the Canada exemption (22 CFR § 126.5)
- A full DDTC-approved TAA is **required** before sharing any ITAR-controlled technical data with the Indian defence manufacturer
- India is not on the 22 CFR § 126.1 comprehensive arms embargo list, so approval is in principle available, subject to DDTC and interagency review

---

## 3. Mandatory TAA Clauses (22 CFR § 124.9)

The following clauses are legally required in every DDTC-approved TAA:

### 3.1 Scope of Agreement
Precise and exhaustive description of the technical data and/or defence services to be shared. For a missile guidance system, this must identify:
- Specific design documents, drawings, specifications, and software
- System and subsystem descriptions (e.g., inertial navigation unit, guidance computer algorithms, seeker data)
- Any permitted defence services (e.g., engineering consultation, training, integration support)

Vague or overly broad scope descriptions will result in DDTC rejection or requests for additional information.

### 3.2 Identification of All Parties
- US licensor (your organisation) with DDTC registration number
- Foreign licensee (the Indian defence manufacturer), full legal name and address
- Any authorised sub-licensees (must be individually named and approved by DDTC)
- No additional parties may access the technical data without a TAA amendment

### 3.3 Retransfer Prohibition
The TAA must expressly prohibit the foreign licensee from further disclosing, transferring, or retransferring the technical data to any third party — including other Indian government agencies, sub-contractors, or subsidiaries — without prior written approval from DDTC. This is a mandatory clause under 22 CFR § 124.9(a).

### 3.4 US Government Rights
The US Government (including DDTC, DoD, and designated agencies) must have the right to:
- Review all records relating to the TAA and technical data transfers
- Audit the foreign licensee's compliance with the agreement
- Terminate the TAA if required by national security or foreign policy considerations

This clause cannot be waived or modified.

### 3.5 Audit Rights
The US licensor must retain the right to audit the foreign licensee's compliance with the TAA, including access to relevant records, facilities, and personnel. This protects the US exporter and satisfies the US Government's oversight requirements.

### 3.6 Record-Keeping — 5-Year Retention
Both the US licensor and the foreign licensee must maintain all records associated with the TAA — including technical data transfer logs, correspondence, end-use records, and any sub-licensing records — for a minimum of **5 years** (22 CFR § 122.5). Records must be available for inspection by DDTC, US Customs, DoD, or any authorised US Government agency.

### 3.7 Term and Renewal
- TAAs are valid for a maximum of **5 years**
- Renewal requires a new DDTC application before expiry
- The agreement must state the effective date and expiry date

### 3.8 Security Classification Handling (if applicable)
If any of the missile guidance design data is classified, the TAA must include provisions for handling classified information in accordance with US Government security requirements, including applicable National Disclosure Policy (NDP-1) authorisation.

### 3.9 Amendment Requirement
The TAA must state that any change to the scope, parties, authorised countries, or technical data requires a formal amendment approved by DDTC before taking effect.

---

## 4. Congressional Notification Requirement

Because missile guidance systems are **Significant Military Equipment (SME)** under ITAR and represent a major defence capability transfer, the following applies:

- Under **22 USC § 2776**, the US Government is required to notify Congress before approving certain defence article and service transfers
- For commercially licensed sales or transfers involving SME to countries such as India, congressional notification thresholds may apply (typically for transfers valued at **$14 million or more** for SME, or where national security significance warrants it)
- DDTC will conduct interagency review (including DoD/DSCA, Department of Commerce, and intelligence community) prior to approval
- The nature of missile guidance systems — a Category IV USML item with direct strategic and proliferation implications — is likely to trigger heightened scrutiny and may require a formal congressional notification period (typically **30 days** for NATO allies/Australia/Japan/NZ/Israel/South Korea, or **15 days** for others) before DDTC may issue final approval

Your organisation should plan for this additional timeline in project scheduling and engage legal counsel and a US export control consultant early in the process.

---

## 5. DDTC Approval Process — Step by Step

### Step 1: Confirm DDTC Registration
Verify that your organisation is currently registered with DDTC under 22 CFR § 122.1. Registration must be active before submitting a TAA application. Registration is via the DDTC portal at registration.pmddtc.state.gov using Form DS-2032.

### Step 2: Draft the TAA
Prepare the TAA document incorporating all mandatory clauses listed in Section 3 above. Legal counsel experienced in ITAR is strongly recommended. The agreement must:
- Be in English
- Clearly identify all technical data and defence services
- Include all required 22 CFR § 124.9 clauses

### Step 3: Submit via D-Trade Portal
Submit the TAA application through DDTC's **D-Trade electronic portal** (dtrade.state.gov). The submission package typically includes:
- The draft TAA agreement (PDF)
- Cover letter explaining the purpose and scope
- Description of the foreign licensee, including ownership information and any government affiliation
- End-use statement from the Indian manufacturer
- Details of the programme or contract the TAA supports
- Any relevant US Government programme documentation (if applicable)

### Step 4: DDTC Review and Interagency Coordination
- Standard processing time: **30–60 days** for most TAAs
- For Category IV items (missiles/guidance systems), expect extended review due to interagency coordination requirements and potential congressional notification
- DDTC may issue a Request for Additional Information (RAI) — respond promptly to avoid further delays
- DDTC conducts review in consultation with DoD (DSCA), Department of Commerce, and the intelligence community

### Step 5: Congressional Notification (if triggered)
If the transfer meets the threshold for congressional notification under 22 USC § 2776, DDTC will notify Congress. A mandatory review period (15 or 30 days) must pass before DDTC issues the TAA approval, unless Congress acts to block it.

### Step 6: TAA Issuance
Once approved, DDTC issues the TAA with assigned agreement number, conditions, and an expiry date. No technical data may be shared until the approved TAA is in hand.

### Step 7: Implementation Controls
After approval:
- Implement a Technology Control Plan (TCP) covering access controls, data segregation, and training
- Maintain transfer logs for all disclosures made under the TAA
- Brief the Indian manufacturer on their obligations under the TAA
- Track the 5-year expiry and initiate renewal proceedings well in advance

---

## 6. Summary Checklist

| Requirement | Regulatory Basis | Status |
|-------------|-----------------|--------|
| DDTC registration active | 22 CFR § 122.1 | Verify before applying |
| TAA identified as correct instrument | 22 CFR § 124.1 | Required for technical data |
| USML Category IV classification confirmed | 22 CFR § 121.1 | Missile guidance = Cat IV |
| Scope clause — precise technical data description | 22 CFR § 124.9 | Mandatory |
| Retransfer prohibition clause | 22 CFR § 124.9(a) | Mandatory |
| US Government rights clause | 22 CFR § 124.9 | Mandatory |
| Audit rights clause | 22 CFR § 124.9 | Mandatory |
| 5-year record retention clause | 22 CFR § 122.5 | Mandatory |
| 5-year term / renewal provision | 22 CFR § 124.1 | Mandatory |
| No India exemption available | 22 CFR §§ 126.5–126.7 | Licence required |
| D-Trade portal submission | DDTC practice | Required |
| 30–60 day approval timeline | DDTC practice | Plan accordingly |
| Congressional notification (SME) | 22 USC § 2776 | Likely for Cat IV/missile |
| Technology Control Plan | 22 CFR § 120.50 | Implement post-approval |

---

## 7. Key Risk Warnings

1. **No transfer before TAA approval**: Sharing any missile guidance design data — including drawings, specifications, emails, or oral briefings — with the Indian manufacturer prior to DDTC TAA approval is an ITAR violation subject to criminal penalties up to $1,000,000 per violation and 20 years imprisonment (22 USC § 2778).

2. **Deemed export risk**: If Indian nationals employed at your US facilities have access to the missile guidance design data, a deemed export licence (TAA or individual licence) is required for those individuals before access is granted (22 CFR § 120.50).

3. **Third-party sub-contractors**: If the Indian manufacturer intends to involve sub-contractors, each must be individually authorised in the TAA or a TAA amendment — unauthorised sub-licensing is a violation.

4. **Amendment discipline**: Any expansion of scope, addition of parties, or change in authorised countries requires a DDTC-approved amendment before the change is implemented.

---

*All regulatory citations refer to the International Traffic in Arms Regulations (ITAR), 22 CFR Parts 120–130, as administered by the Directorate of Defense Trade Controls (DDTC), US Department of State. This guidance reflects the regulatory framework as of the date of this document. Consult qualified US export control legal counsel before proceeding.*

# TAA for Sharing Defense Technical Data with an Indian Manufacturer

## The Right Legal Instrument

A **Technical Assistance Agreement (TAA)** under 22 CFR Part 124 is the correct authorisation instrument when sharing ITAR-controlled technical data (design data, specifications, drawings) with a foreign person. This is distinct from a DSP-5 hardware export licence or a Manufacturing License Agreement (MLA) — a TAA covers the transfer of knowledge and services, not physical hardware.

You cannot share any ITAR-controlled design data with the Indian manufacturer until DDTC approves the TAA.

## Required TAA Clauses

DDTC requires specific provisions in every TAA (22 CFR § 124.9). The key mandatory elements are:

- **Scope**: Precise description of the technical data and/or defense services being provided — reference the specific USML category and enumerate what is and is not authorised
- **Parties**: Full identification of the US licensor, all foreign licensees, and any authorised sub-licensees
- **Retransfer prohibition**: Foreign licensee may not transfer the data to any third party without prior written DDTC approval
- **US government rights**: The US government retains rights to review records, conduct audits, and terminate the agreement
- **Audit rights**: US licensor right to audit the foreign licensee's compliance
- **Record retention**: All records related to the TAA must be retained for 5 years
- **Term**: Typically 5 years; must be renewed before expiry
- **Amendment requirement**: Any change to parties, scope, or authorised countries requires a formal amendment approved by DDTC

## Applying for DDTC Approval

1. Draft the TAA (typically with export control counsel)
2. Submit via the **D-Trade portal** (dtrade.pmddtc.state.gov)
3. Include supporting documentation: technical description, end-use statement, Indian manufacturer's details
4. Standard processing time: **30–60 days**, though complex agreements or sensitive categories take longer

## India-Specific Considerations

India is a designated **Major Defense Partner** of the United States, which facilitates some defence trade, but India is **not** covered by the Defence Trade Cooperation Treaty exemptions that apply to Australia and the UK (22 CFR §§ 126.6–126.7), nor the Canada exemption (22 CFR § 126.5). A full DDTC-approved TAA is required — there is no shortcut or simplified process.

Depending on the value and nature of the transfer, the transaction may require **congressional notification** under 22 USC § 2776, which adds a mandatory 15–30 day review period before DDTC can approve.

## Compliance Obligations During the TAA

Once approved, the US company must:
- Maintain records of all data transferred under the TAA
- Conduct periodic audits of the Indian licensee's compliance
- Seek DDTC approval for any amendments before implementing changes
- Report any suspected violations or diversions to DDTC
- Retain all TAA-related records for 5 years (22 CFR § 122.5)

# LGPD Compliance Analysis: US SaaS Company with Brazilian Customers

**Date:** 2026-05-05  
**Prepared by:** LGPD Compliance Advisor  
**Subject:** Extraterritorial scope of LGPD and applicable legal bases for processing name, email, CPF, and purchase history of Brazilian customers

---

## 1. Does LGPD Apply to Your Company?

**Yes. LGPD applies to your company, even though you are incorporated and based in the United States.**

### Legal Basis for Extraterritorial Application (Art. 3)

LGPD's territorial scope is defined in **Art. 3**, which expressly extends the law beyond Brazil's borders. The law applies to any processing of personal data when **at least one** of the following conditions is met:

| Condition | Art. 3 Reference | Applicability to Your Company |
|-----------|-----------------|-------------------------------|
| Processing occurs in Brazil | Art. 3, I | Possibly (if data is processed on Brazilian infrastructure) |
| **Purpose is to offer or provide goods or services to individuals located in Brazil** | **Art. 3, II** | **Yes — you actively serve Brazilian customers** |
| Personal data was collected in Brazil | Art. 3, III | Yes — your Brazilian customers are in Brazil when they sign up and use your SaaS |

Your company clearly meets **Art. 3, II** (and likely Art. 3, III as well): you are deliberately offering a SaaS product to individuals located in Brazil and collecting their personal data in that context. This is directly analogous to the GDPR "targeting" criterion under Art. 3(2) GDPR, and LGPD was deliberately drafted with similar extraterritorial reach.

### The "Location in Brazil" Standard

LGPD uses the phrase "individuals located in Brazil" (pessoas que se encontrem no território nacional) — meaning physical presence in Brazil at the time of data collection, not citizenship or domicile. Your Brazilian customers are located in Brazil when they use your app, which satisfies this criterion.

### No Exemption Applies (Art. 4)

The Art. 4 exemptions do not apply to your situation. Those exemptions cover:
- Personal or household use only
- Journalistic, artistic, or academic purposes
- National security, public safety, or criminal investigation by public entities
- Data originating exclusively outside Brazil with no communication to Brazilian recipients

A US SaaS company providing commercial services to Brazilian customers falls squarely outside all exemptions.

**Conclusion:** LGPD applies to your company in full. You are a **controller (controlador)** as defined in Art. 5, XIV — you determine the purposes and means of processing your Brazilian customers' personal data.

---

## 2. Data Classification Analysis

Before identifying legal bases, it is essential to classify the data you collect:

| Data Element | LGPD Classification | Notes |
|-------------|---------------------|-------|
| **Name** | Regular personal data (Art. 5, I) | Identifies the individual |
| **Email address** | Regular personal data (Art. 5, I) | Identifies or is linked to the individual |
| **CPF (Cadastro de Pessoas Físicas)** | Regular personal data (Art. 5, I) | Brazil's national taxpayer identification number; highly sensitive in practice due to identity fraud risk — ANPD has flagged CPF exposure as high-risk (see large-scale breach investigations) |
| **Purchase history** | Regular personal data (Art. 5, I) | Financial/transactional data linked to the individual |

**Important note on CPF:** While CPF is classified as regular (not sensitive) personal data under LGPD's Art. 11 definitions, the ANPD has treated CPF data breaches with heightened concern in enforcement actions, given the severe harm that CPF exposure causes to Brazilian individuals (identity theft, credit fraud). Your security and legal basis choices for CPF should reflect this elevated practical risk.

None of the data you collect constitutes **sensitive personal data** under Art. 11 (which covers racial/ethnic origin, religion, political opinion, trade union membership, health or sex life data, genetic data, or biometric data) — provided you do not profile customers in ways that reveal such attributes from their purchase history.

---

## 3. Legal Bases for Each Processing Activity

Under LGPD **Art. 7**, processing of regular personal data requires one of ten enumerated legal bases. Unlike a general balancing test, LGPD requires a specific positive basis for each processing activity. Below is an analysis of the bases most relevant to your SaaS context.

### 3.1 Legal Bases Applicable to Your Processing

#### A. Contract — Art. 7, V (Primary Basis for Core Service Delivery)

**"Processing necessary for the execution of a contract or preliminary procedures related to a contract to which the data subject is a party, at the data subject's request"**

**Applies to:** Collection and use of name, email, CPF (where required for account/billing), and purchase history for the purpose of:
- Creating and managing customer accounts
- Delivering the subscribed SaaS service
- Billing and payment processing
- Order confirmation and transaction records

**Key requirements:**
- Processing must be genuinely necessary for contract performance — not merely convenient
- The data subject must be a party to the contract (your Terms of Service / subscription agreement)
- Applies to pre-contractual steps (e.g., account setup, onboarding) as well as ongoing service delivery

**Practical guidance:** Name and email are clearly necessary for account creation and service delivery. CPF may be necessary where required for invoicing (Brazilian fiscal rules often require CPF on NF-e electronic invoices). Purchase history is directly generated by and necessary to the contractual relationship. This is your strongest and most appropriate primary basis for core service functions.

---

#### B. Consent — Art. 7, I (For Non-Essential Processing)

**"With the consent of the data subject"**

Consent under LGPD must be (Art. 8):
- **Free** — not coerced; cannot be bundled as a condition of service unless necessary
- **Informed** — purpose clearly stated
- **Unambiguous** — affirmative action required; pre-ticked boxes are invalid
- **Specific** — separate consent per distinct purpose; generic consent is invalid
- **Documented** — burden of proof rests on the controller
- **Revocable** — at any time, at no cost, without prejudice to prior lawful processing

**Applies to:** Processing activities that go beyond contract performance, such as:
- Marketing communications and promotional emails
- Sharing data with third-party marketing platforms
- Behavioural analytics beyond service improvement
- Personalised advertising based on purchase history

**Key limitation:** You cannot condition access to your SaaS service on consent for non-essential processing (Art. 8, §3º). Consent for marketing must be separate from and independent of the service agreement.

---

#### C. Legitimate Interest — Art. 7, IX (For Proportionate Business Purposes)

**"When necessary to serve the legitimate interests of the controller or a third party, except where the data subject's fundamental rights and freedoms prevail"**

Unlike GDPR, LGPD's legitimate interest basis is more circumscribed — Art. 10 requires that:
1. The interest be legitimate and specific
2. Processing not prevail over the data subject's fundamental rights
3. Data subjects have a reasonable expectation of the processing
4. A balancing test (Legitimate Interest Assessment / LIA) be documented

**Sensitive data cannot use legitimate interest** (Art. 11 does not include it as a basis).

**May apply to:**
- Internal analytics and product improvement (where proportionate)
- Fraud detection and security monitoring
- IT security and system integrity logging
- Customer support and service quality monitoring
- Internal business reporting aggregating anonymised data

**Required action:** For each activity relying on legitimate interest, conduct and document a balancing test addressing: (a) the specific legitimate interest pursued; (b) necessity of the processing; (c) potential impact on data subjects; (d) whether data subjects would have reasonable expectations; (e) mitigating measures (e.g., pseudonymisation, limited access).

---

#### D. Legal Obligation — Art. 7, II (For Regulatory Compliance)

**"When the processing is necessary for the controller to comply with a legal obligation or regulatory duty"**

**May apply to:**
- Retaining financial records as required by Brazilian law (e.g., Lei 9.613/1998 for anti-money laundering, if applicable)
- Responding to court orders or regulatory demands
- Tax and fiscal record-keeping obligations applicable to your Brazilian customers or Brazilian operations

**Note:** This basis applies where a specific Brazilian (or applicable) legal norm mandates the processing. It cannot be used as a general justification for convenience.

---

#### E. Credit Protection — Art. 7, X (Specific to Credit-Related Processing)

**"For credit protection purposes, including credit analysis"**

If your SaaS business model involves any form of credit analysis (e.g., payment terms, instalment options, assessing creditworthiness of Brazilian customers), this specific basis exists in LGPD and is not present in GDPR. CPF is commonly used in Brazilian credit analysis contexts, and this basis would be relevant where you perform credit checks using CPF.

---

### 3.2 Legal Basis Mapping Table

| Processing Activity | Recommended Primary Basis | Alternative Basis | Notes |
|--------------------|--------------------------|--------------------|-------|
| Account creation (name, email) | Art. 7, V — Contract | Art. 7, I — Consent | Contract is stronger; necessary for service |
| CPF collection for invoicing | Art. 7, V — Contract | Art. 7, II — Legal obligation | Required for Brazilian fiscal compliance |
| CPF collection for identity verification | Art. 7, V — Contract | Art. 7, IX — Legitimate interest | Document balancing test for LI |
| Purchase history — service delivery | Art. 7, V — Contract | — | Core to contractual performance |
| Purchase history — personalisation | Art. 7, I — Consent | Art. 7, IX — LI (with LIA) | Consent preferred for direct personalisation |
| Marketing emails | Art. 7, I — Consent | — | Consent mandatory; must be freely given |
| Fraud detection / security | Art. 7, IX — Legitimate interest | Art. 7, II — Legal obligation | Document LI balancing test |
| Analytics / product improvement | Art. 7, IX — Legitimate interest | Art. 7, I — Consent | Pseudonymise data where possible |
| Sharing with processors (cloud, payments) | Same basis as underlying activity | — | Governed by Art. 39 processor agreements |
| Retention for legal/fiscal purposes | Art. 7, II — Legal obligation | — | Specify applicable Brazilian/US law |

---

## 4. Key Compliance Obligations That Follow

Now that LGPD applies, the following obligations arise for your company as a controller:

### 4.1 Transparency — Privacy Notice (Art. 9)

You must provide Brazilian customers with a privacy notice containing:
- Identity and contact of your company (controller)
- DPO (Encarregado) identity and contact
- Purposes of processing for each data category
- Legal basis for each processing activity
- Whether data will be shared and with whom
- Information about international transfers (data leaving Brazil to US servers)
- Retention periods
- How data subjects may exercise their rights
- Any automated decisions or profiling

### 4.2 DPO Appointment — Art. 41

You must appoint a **Encarregado (DPO)**. Unlike GDPR (which has SME exemptions), LGPD's Art. 41 broadly requires all controllers to appoint a DPO. The DPO's identity and contact must be published (typically on your website's privacy policy). ANPD Resolution No. 2/2022 provides limited exemptions for micro/small enterprises with low-risk processing — your company's profile (CPF, purchase history at scale) is unlikely to qualify.

The DPO may be an employee, a contracted individual, or a service provider (external DPO). They do not need to be Brazilian or located in Brazil, but must be reachable by Brazilian data subjects and ANPD.

### 4.3 Records of Processing Activities — Art. 37

Maintain a **RoPA** documenting each processing activity, including the data elements, legal basis, retention period, third-party recipients, and international transfer mechanism. ANPD Resolution No. 2/2022 makes RoPA mandatory where processing occurs at large scale, involves sensitive data, or involves a public authority — if your Brazilian customer base is material in size, this applies.

### 4.4 International Data Transfers — Arts. 33–36

You are transferring Brazilian customers' personal data to the United States (and potentially to third-party cloud infrastructure in other countries). This constitutes an **international data transfer** under LGPD Art. 5, XV, and requires a compliant transfer mechanism under Art. 33:

| Available Mechanism | Current Status |
|--------------------|----------------|
| **ANPD adequacy decision** | No adequacy decision for the US has been issued by ANPD as of 2026 |
| **Standard contractual clauses** | ANPD has not yet published standard clauses; specific contractual clauses between parties may be used (Art. 33, II) |
| **Binding Corporate Rules (BCRs)** | Available for multinational groups (Art. 33, III) |
| **Specific consent** | Data subject consented specifically to the international transfer — must be informed of destination country and risks (Art. 33, VIII) |
| **ANPD authorisation** | Case-by-case; not scalable (Art. 33, IX) |

**Recommended approach:** Use specific contractual clauses in your Terms of Service or a dedicated data processing agreement that provides LGPD-equivalent protections, and disclose the international transfer in your privacy notice. Alternatively, obtain specific informed consent for the transfer to the US.

### 4.5 Data Subject Rights — Arts. 17–22

Brazilian customers have the following rights, which you must operationally support:

| Right | Article | Timeframe |
|-------|---------|-----------|
| Confirmation of processing | Art. 18, I | Immediately (simplified) |
| Access to their data | Art. 18, II | Within 15 days (full report) |
| Correction of inaccurate/outdated data | Art. 18, III | Without undue delay |
| Anonymisation, blocking, or deletion | Art. 18, IV | Without undue delay |
| Portability | Art. 18, V | ANPD to define format |
| Deletion of consent-based data | Art. 18, VI | Without undue delay |
| Information about data sharing | Art. 18, VII | Without undue delay |
| Information about consequences of not consenting | Art. 18, VIII | Without undue delay |
| Revocation of consent | Art. 18, IX | Without undue delay |
| Review of automated decisions | Art. 20 | Upon request |

You must provide a mechanism for Brazilian customers to submit these requests (e.g., a dedicated privacy request form or email) in accessible language.

### 4.6 Security — Art. 46

Implement technical and administrative security measures proportionate to the risk of your processing. Given that you hold CPF numbers (which carry high fraud risk in Brazil) and purchase history, your measures should include:

- Encryption of CPF data at rest and in transit
- Access controls limiting internal access to CPF data on a need-to-know basis
- Pseudonymisation of CPF where full identification is not required for the processing step
- Logging and monitoring of access to CPF and financial data
- Documented information security policies
- Employee training on data handling

### 4.7 Breach Notification — Art. 48 + ANPD Resolution No. 15/2024

If a security incident occurs that may cause relevant risk or harm to your Brazilian customers (e.g., exposure of CPF or purchase history):
- **Preliminary notification to ANPD: within 3 working days** of becoming aware
- **Full report to ANPD: within 20 working days**
- **Notification to affected data subjects** where there is high risk of harm

Portal: https://www.gov.br/anpd/pt-br/assuntos/incidentes-de-seguranca

---

## 5. Penalty Exposure If Non-Compliant

Under **Art. 52**, ANPD may impose:

| Sanction | Details |
|----------|---------|
| Warning | With remediation period |
| Fine | Up to **2% of Brazilian revenue** (prior fiscal year); capped at **R$50 million per violation** |
| Daily fine | To compel compliance; same cap |
| Public disclosure | Of the violation |
| Data blocking | Temporary suspension of processing |
| Data deletion | Of data related to the violation |
| Processing suspension | Up to 6 months (renewable) |
| Processing prohibition | Total ban on processing activities |

ANPD enforcement priorities specifically include: large-scale data breaches, failure to respond to data subject rights requests, and lack of DPO appointment — all areas directly relevant to a SaaS company with a large Brazilian customer base.

---

## 6. Immediate Action Priorities

Based on your described data processing, here are the highest-priority actions:

| Priority | Action | LGPD Reference |
|----------|--------|----------------|
| 1 — Critical | Appoint and publish a DPO (Encarregado) | Art. 41 |
| 2 — Critical | Draft and publish a LGPD-compliant privacy notice covering all four data types | Art. 9 |
| 3 — Critical | Implement a mechanism for Brazilian data subjects to exercise their rights | Art. 18 |
| 4 — Critical | Establish an international data transfer mechanism for US-hosted data | Arts. 33–36 |
| 5 — High | Map legal basis to each processing activity and document in RoPA | Arts. 7, 37 |
| 6 — High | Implement consent mechanism for non-essential processing (marketing, analytics) | Art. 8 |
| 7 — High | Implement enhanced security for CPF data | Art. 46 |
| 8 — High | Establish breach detection and ANPD notification procedure (3-day requirement) | Art. 48 |
| 9 — Medium | Conduct Data Protection Impact Assessment (RIPD) for CPF processing | Art. 38 |
| 10 — Medium | Review processor agreements with sub-contractors to include LGPD terms | Art. 39 |

---

## 7. LGPD vs. GDPR: Relevance If You Are Already GDPR-Compliant

If your company already complies with GDPR for EU customers, much of your framework will transfer — but note these key differences:

| Topic | LGPD | GDPR |
|-------|------|------|
| Legal bases | 10 bases (includes credit protection — Art. 7, X) | 6 bases |
| DPO requirement | Required for all controllers (limited exemptions) | Only in specific cases (large-scale, systematic, sensitive) |
| Breach notification | 3 working days preliminary; 20 working days full | 72 hours to supervisory authority |
| Fines | Up to 2% of Brazilian revenue; max R$50M per violation | Up to 4% global turnover; max €20M |
| Children | Parental consent required (Art. 14); controller must verify | Parental consent for under-16 (member states may lower to 13) |
| Adequacy for US | No adequacy decision; ANPD has not listed US as adequate | No adequacy for US under Schrems II; EU-US Data Privacy Framework exists |
| Sensitive data | Cannot use legitimate interest for sensitive data (Art. 11) | Cannot use legitimate interest for special categories (Art. 9 GDPR) |

The main gaps GDPR-compliant companies typically face under LGPD are: the DPO publication requirement (name and contact must be publicly listed), the 3-working-day breach preliminary notification (shorter than 72 hours in calendar terms for working days, but operationally similar), and the lack of an established international transfer mechanism for Brazil-to-US flows equivalent to the EU-US DPF.

---

## 8. Summary

**Yes, LGPD applies to your US SaaS company** by virtue of Art. 3, II — you are offering services to individuals located in Brazil and processing their personal data. There is no exemption that shields you.

**The legal bases most applicable to your processing are:**

1. **Art. 7, V — Contract**: Primary basis for collecting name, email, CPF (for billing/invoicing), and generating/retaining purchase history as part of your SaaS service delivery.
2. **Art. 7, I — Consent**: Required for marketing communications, sharing data with third-party marketing tools, and non-essential analytics or personalisation based on purchase history.
3. **Art. 7, IX — Legitimate Interest**: May apply to fraud prevention, security monitoring, and internal product analytics — but requires a documented balancing test (LIA) for each activity.
4. **Art. 7, II — Legal Obligation**: Where Brazilian law mandates retention of specific records (e.g., fiscal, tax).
5. **Art. 7, X — Credit Protection**: If any credit assessment of customers is performed using CPF.

Your most urgent compliance steps are: appointing a DPO, publishing an LGPD-compliant privacy notice, establishing a data subject rights request process, implementing an international data transfer mechanism, and creating a breach notification procedure meeting ANPD's 3-working-day preliminary notification requirement.

---

*References: LGPD — Law No. 13,709/2018 as amended by Law No. 13,853/2019; ANPD Resolution CD/ANPD No. 2/2022 (RoPA/DPO); ANPD Resolution CD/ANPD No. 15/2024 (breach notification); ANPD Resolution CD/ANPD No. 4/2023 (micro/small enterprise simplified rules).*

# LGPD Compliance for US SaaS Companies Serving Brazilian Customers

## Question
"We are a US SaaS company with Brazilian customers. Our app collects name, email, CPF, and purchase history. Do we need to comply with LGPD? Which legal bases apply to our processing?"

---

## 1. Applicability: Does LGPD Apply to Your Company?

**Yes, LGPD applies to your company, even though you are based in the United States.**

Brazil's Lei Geral de Proteção de Dados (LGPD), Law No. 13,709/2018, has explicit extraterritorial reach. Article 3 establishes that the law applies to any data processing operation, regardless of where the controller or processor is headquartered, if **any one** of the following conditions is met:

1. **The processing operation is carried out in Brazil** — even if the company is foreign, if data is collected, stored, or processed on Brazilian territory (e.g., servers, agents, or data flows touching Brazil), LGPD applies.
2. **The processing activity aims to offer goods or services to individuals located in Brazil** — this is your primary trigger. Your SaaS platform targets Brazilian customers and offers them a service, which squarely brings you within LGPD's scope.
3. **The personal data being processed was collected in Brazil** — when Brazilian residents submit their name, email, CPF, or purchase history through your platform while located in Brazil, that data was collected in Brazil.

Your company meets **all three** of these conditions. Your US location is irrelevant for purposes of applicability. This mirrors the territorial logic of the EU's GDPR (Article 3), and Brazilian regulators (ANPD — Autoridade Nacional de Proteção de Dados) are expected to interpret the extraterritorial scope similarly.

### The Data You Collect

| Data Element     | Classification Under LGPD | Notes |
|------------------|---------------------------|-------|
| Name             | Personal data (Art. 5, I) | Identifies a natural person |
| Email address    | Personal data (Art. 5, I) | Identifies or can identify a person |
| CPF (Cadastro de Pessoas Físicas) | Personal data (Art. 5, I) | National taxpayer ID — highly sensitive identifier |
| Purchase history | Personal data (Art. 5, I) | Behavioral/transactional data linked to identifiable individuals |

None of these categories constitute **sensitive personal data** (dados pessoais sensíveis) under Article 5, II (which covers racial/ethnic origin, religion, political opinion, health, biometric, genetic, and sexual orientation data). However, the **CPF is a highly regulated identifier** in Brazil — its collection and use requires particular care, a clear legal basis, and robust security controls, as it is commonly used for identity verification and fraud.

---

## 2. Legal Bases for Processing

LGPD Article 7 enumerates **ten legal bases** for processing personal data of private individuals. Unlike GDPR's six legal bases, LGPD's list is broader. The most relevant bases for your scenario are:

### 2.1 Contract Performance (Art. 7, V)
**"Processing necessary for the performance of a contract or preliminary procedures related to a contract of which the data subject is a party, at the request of the data subject."**

- **Applies to:** Name, email, CPF (for account creation, billing, and identity verification), and purchase history.
- **Rationale:** When a Brazilian customer signs up for your SaaS, a contractual relationship is formed. Processing their name and email to create an account, deliver the service, send invoices, and record purchases is necessary to fulfill that contract. This is likely your **primary legal basis** for core service delivery.
- **Practical scope:** Account registration, authentication, service delivery, billing, and transaction records.

### 2.2 Legitimate Interest of the Controller (Art. 7, IX)
**"Processing based on the legitimate interests of the controller or a third party, except in the case where the data subject's fundamental rights and freedoms prevail."**

- **Applies to:** Purchase history (for fraud prevention, analytics, service improvement), email (for security notifications, product updates).
- **Rationale:** You have a legitimate interest in maintaining service integrity, preventing fraud, improving your product, and communicating relevant updates to customers. However, this basis requires a **three-part balancing test** (similar to GDPR): (a) the interest must be legitimate, (b) the processing must be necessary, and (c) the interest must not be overridden by the data subject's rights.
- **Limitation:** Legitimate interest cannot be used as a catch-all. It must be documented and balanced against data subject rights. ANPD is expected to scrutinize this basis carefully.

### 2.3 Consent (Art. 7, I)
**"Provision of free, informed, and unambiguous consent by the data subject."**

- **Applies to:** Marketing emails, behavioral analytics, sharing data with third-party advertising partners, profiling.
- **Rationale:** For processing that goes beyond direct service delivery — particularly marketing communications, behavioral tracking, or sharing data with partners — consent is the appropriate (and often required) legal basis.
- **LGPD consent requirements (Art. 8):**
  - Must be given for a specific purpose
  - Must be free, informed, unambiguous, and given in written or equivalent form
  - The burden of proof of consent lies with the controller
  - Consent may be revoked at any time (the controller must make revocation as easy as giving consent)
  - Bundled consent (consent buried in terms of service) is not valid
- **Important:** Consent is **not required** for contract performance or legitimate interest processing. Do not over-rely on consent — if another valid basis applies, use it, as over-reliance on consent creates risk when users withdraw it.

### 2.4 Compliance with a Legal Obligation (Art. 7, II)
**"Processing necessary for compliance with a legal obligation or regulatory requirement by the controller."**

- **Applies to:** Retention of transaction records and CPF data for Brazilian tax/accounting regulations, responding to lawful government requests.
- **Rationale:** Brazilian law (and potentially US law on cross-border transactions) may require you to retain certain records. If Brazilian fiscal or consumer protection regulations require you to keep invoices or purchase records with CPF for a defined period, this basis justifies that retention even after the contractual relationship ends.

### 2.5 Regular Exercise of Rights in Judicial, Administrative, or Arbitration Proceedings (Art. 7, VI)
**"Processing necessary for the regular exercise of rights in judicial, administrative, or arbitration proceedings."**

- **Applies to:** Retaining data to defend against chargebacks, legal disputes, or regulatory investigations.
- **Rationale:** If a customer disputes a transaction or files a complaint, you may need to retain their data beyond what the contract alone would justify. This basis covers that scenario.

---

## 3. Key Obligations Under LGPD

### 3.1 Appoint a Data Protection Officer (DPO) — Encarregado
Article 41 requires controllers to appoint a **Data Protection Officer (Encarregado)**. The ANPD has clarified that this requirement applies broadly, including to foreign companies processing Brazilian data. The DPO must:
- Be publicly identified (name and contact information disclosed in your privacy notice)
- Serve as the point of contact between your company, data subjects, and the ANPD
- Can be an individual or a legal entity (e.g., an outsourced DPO service)

### 3.2 Privacy Notice / Privacy Policy
You must provide data subjects with **clear, transparent information** (Art. 9) including:
- Identity and contact details of the controller (and your DPO/Encarregado)
- Purposes of processing for each data category
- Legal basis for each processing activity
- Data retention periods
- Whether data is shared with third parties and with whom
- Whether data is transferred internationally and the safeguards in place
- Data subject rights and how to exercise them

### 3.3 International Data Transfers
Since your company is US-based, **every time you process Brazilian customer data**, you are engaging in an international data transfer. Article 33 of LGPD restricts international transfers. Permissible mechanisms include:
- Transfer to countries that provide an adequate level of protection (as determined by ANPD — no US adequacy decision exists yet)
- Standard contractual clauses approved by ANPD
- Global corporate policies (binding corporate rules equivalent)
- Specific consent of the data subject for the transfer
- Necessity for contract performance (where the transfer is necessary to execute the contract with the data subject)

**Critical action item:** You must implement an international data transfer mechanism. The most practical option for a US SaaS company is likely **standard contractual clauses** (once ANPD finalizes them) or **reliance on contract necessity** for core service data flows.

### 3.4 Data Subject Rights
LGPD grants Brazilian data subjects the following rights (Arts. 17–22), which you must be able to fulfill:

| Right | Description |
|-------|-------------|
| Confirmation | Confirm whether processing of their data exists |
| Access | Receive a copy of their personal data |
| Correction | Correct inaccurate or outdated data |
| Anonymization/Blocking/Deletion | Request anonymization, blocking, or deletion of unnecessary or unlawful data |
| Data portability | Receive their data in a structured, interoperable format |
| Deletion of consent-based data | Delete data processed on the basis of consent, upon revocation |
| Information about sharing | Know which third parties their data has been shared with |
| Opt-out of consent/legitimate interest | Refuse or revoke consent; oppose processing based on legitimate interest |
| Review of automated decisions | Request human review of automated decisions affecting them |

You must have a **mechanism** (e.g., a web form, email process) for Brazilian users to submit these requests and a process to respond within a **reasonable timeframe** (ANPD guidance suggests 15 days as a benchmark, though the law does not specify an exact period).

### 3.5 Data Minimization and Purpose Limitation
Article 6 establishes principles including:
- **Finality (Finalidade):** Data may only be processed for stated, legitimate, specific, and explicit purposes.
- **Necessity (Necessidade):** Only collect data that is strictly necessary for the stated purpose. For example, if CPF is not technically required for your SaaS to function, carefully consider whether its collection is justified.
- **Adequacy (Adequação):** Processing must be compatible with the stated purposes.

### 3.6 Security Measures
Article 46 requires controllers to adopt **technical and administrative security measures** to protect personal data from unauthorized access, destruction, loss, alteration, or leakage. You should:
- Encrypt data at rest and in transit
- Implement access controls and least-privilege principles
- Conduct regular security assessments
- Maintain an incident response plan

### 3.7 Data Breach Notification
Article 48 requires notification of security incidents that may cause **risk or harm** to data subjects. Notification must be made to:
- The **ANPD** — within a reasonable timeframe (ANPD guidelines indicate 2 business days for initial notification of serious incidents)
- **Affected data subjects** — when the incident poses risk to them

The notification must include: nature of the data affected, data subjects involved, security measures in place, risks of the incident, and measures taken to remedy it.

### 3.8 Data Processing Records
While LGPD does not have an explicit equivalent to GDPR's Article 30 Records of Processing Activities (RoPA), the **accountability principle** (Art. 6, X) and ANPD's regulatory guidance effectively require controllers to maintain internal documentation of their processing activities. Maintain records of:
- What data you collect
- Why you collect it (legal basis and purpose)
- How long you retain it
- Who you share it with
- Security measures in place

### 3.9 Privacy by Design and by Default
Article 46, paragraph 2 and the general accountability principle require you to implement data protection from the outset of system design, not as an afterthought.

---

## 4. Recommended Compliance Roadmap

Given your situation as a US SaaS company with Brazilian customers, prioritize the following:

1. **Immediate:** Conduct a data mapping exercise — document all data collected (name, email, CPF, purchase history), where it is stored, how it flows, who has access, and with whom it is shared.

2. **Short-term (1–3 months):**
   - Update your privacy policy to meet LGPD transparency requirements (Art. 9), including identifying your Encarregado/DPO contact.
   - Appoint or designate a Data Protection Officer/Encarregado.
   - Implement a data subject rights request mechanism.
   - Review your consent flows — ensure marketing consent is granular, informed, and revocable.
   - Establish an international data transfer mechanism (evaluate contract necessity basis and monitor ANPD's standard contractual clauses).

3. **Medium-term (3–6 months):**
   - Conduct a legitimate interest assessment (LIA) for processing based on Art. 7, IX.
   - Implement or verify technical security controls (encryption, access controls, logging).
   - Develop a data breach response plan with ANPD notification procedures.
   - Review data retention schedules and implement deletion/anonymization workflows.

4. **Ongoing:**
   - Monitor ANPD regulatory guidance and resolutions (the ANPD continues to publish implementing regulations).
   - Conduct periodic privacy reviews as your product evolves.
   - Train staff on LGPD obligations.

---

## 5. Summary Table

| Topic | Answer |
|-------|--------|
| Does LGPD apply? | **Yes** — extraterritorial application under Art. 3 applies because you offer services to people in Brazil and collect data in Brazil |
| Primary legal basis | **Contract performance** (Art. 7, V) for core service data |
| Secondary legal bases | **Legitimate interest** (Art. 7, IX) for analytics/security; **Consent** (Art. 7, I) for marketing; **Legal obligation** (Art. 7, II) for mandatory retention |
| CPF sensitivity | Not "sensitive data" under LGPD but a highly regulated identifier requiring strong justification and security |
| DPO required? | **Yes** — Encarregado must be appointed and publicly identified |
| International transfers | **Must be addressed** — no US adequacy decision; use contractual mechanisms |
| Key risks of non-compliance | Fines up to 2% of Brazilian-market revenue (capped at R$50 million per violation), public warnings, data processing bans, reputational harm |

---

*This response reflects LGPD as enacted (Law No. 13,709/2018, as amended by Law No. 13,853/2019) and ANPD regulatory guidance as of the knowledge cutoff date. ANPD continues to issue implementing resolutions; consult current ANPD publications and qualified Brazilian legal counsel for jurisdiction-specific advice.*

# Handling a Brazilian User's Data Deletion Request Under LGPD

**Jurisdiction:** Brazil — Lei Geral de Proteção de Dados Pessoais (LGPD), Law No. 13,709/2018, as amended by Law No. 13,853/2019  
**Request type:** Data subject right — deletion of personal data  
**Relevant LGPD articles:** Art. 5, Art. 7, Art. 16, Art. 18 (IV and VI), Art. 19, Art. 37, Art. 39, Art. 41, Art. 47, Art. 52

---

## 1. Overview: The Right to Deletion Under LGPD

LGPD grants every data subject (titular) ownership of their personal data as a fundamental right (Art. 17). Within that framework, Brazilian users hold two distinct deletion rights:

| Right | LGPD Article | Trigger |
|-------|-------------|---------|
| Deletion of unnecessary, excessive, or non-compliant data | Art. 18, IV | Data that does not comply with LGPD; data no longer necessary for the original purpose |
| Deletion of consent-based data | Art. 18, VI | Data subject revokes consent; controller has no other valid legal basis to retain |

A deletion request email from a Brazilian user can invoke either or both of these rights. Your response obligations depend on which legal bases you relied on to originally collect and process the data, and whether any lawful retention exception applies under Art. 16.

---

## 2. Step-by-Step Workflow for Handling the Request

### Step 1 — Acknowledge and Log (Day 1)

Upon receiving the deletion request email:

- **Log the request immediately.** Record the date, channel (email), requestor identity, and request type. LGPD requires controllers to demonstrate accountability (Art. 6, X; Art. 47), and maintaining request logs is essential for that purpose.
- **Send an acknowledgement** within 1 business day confirming receipt and the expected response timeline.
- **Assign to your DPO (Encarregado).** Under Art. 41, your DPO must receive and coordinate data subject communications. The DPO's contact must be published on your website (Art. 41, §1º).

> The response must be provided **free of charge** (Art. 19).

---

### Step 2 — Verify the Identity of the Requestor

Before acting on any deletion request, verify that the person making the request is the actual data subject, or is duly authorised to act on their behalf.

- Request minimum necessary proof: full name, CPF (Brazilian tax ID), email address on file, or another account reference.
- Do **not** demand excessive documentation — the verification must be proportionate to the risk and consistent with the necessity principle (Art. 6, III).
- If the request is made by a third party (e.g., a legal representative), require a valid power of attorney (procuração).

Failure to properly verify identity before deletion creates both a security risk and a regulatory risk.

---

### Step 3 — Map the Data Across All Three Systems

The user has stated their data exists in:

1. **CRM** (Customer Relationship Management system)
2. **Email platform**
3. **Analytics tool**

For each system, your team must:

- Identify every **category of personal data** stored (Art. 5, I — "personal data" is broadly defined as any information relating to an identified or identifiable natural person).
- Identify any **sensitive personal data** (Art. 5, II) — e.g., health data, biometric data, ethnic origin — which carries stricter obligations.
- Identify the **legal basis** under which that data was originally collected and continues to be processed (Art. 7 for regular data; Art. 11 for sensitive data).
- Check whether any **Art. 16 retention exception** applies that overrides the deletion obligation (see Step 4 below).

This system-by-system mapping is also required for your Records of Processing Activities (RoPA) under Art. 37, which should already document these details.

---

### Step 4 — Assess Applicable Legal Bases and Retention Exceptions

This is the most critical legal analysis step. Your deletion obligation — and any lawful refusal — depends entirely on the legal basis for each processing activity.

#### 4a. If Data Was Processed Under Consent (Art. 7, I)

If you collected and processed the user's data based on their **consent** (e.g., newsletter subscriptions via email platform, opt-in analytics tracking), then:

- The user has an unqualified right to **revoke consent at any time** (Art. 18, IX; Art. 8, §5º).
- Upon revocation, you must **delete the personal data** unless a retention exception under Art. 16 applies (Art. 18, VI).
- Consent-based processing cannot continue once consent is withdrawn.

**Practical implication:** Any data in your email platform or analytics tool collected solely on the basis of consent must be deleted unless an Art. 16 exception applies.

#### 4b. If Data Was Processed Under Contract (Art. 7, V)

If you hold data necessary for the **performance of a contract** with the user (e.g., purchase records, account data in the CRM):

- A deletion request does not automatically override this legal basis while the contractual relationship is active or while obligations remain outstanding.
- However, once the contractual relationship ends and no retention exception applies, this data must also be deleted.

#### 4c. If Data Was Processed Under Legitimate Interest (Art. 7, IX)

If you relied on **legitimate interest** (LI) as the legal basis:

- The user's deletion request is a direct challenge to your LI balancing test. You must re-assess whether your interest still outweighs the data subject's fundamental rights (Art. 10).
- If the balancing test now favours the data subject (e.g., there is no compelling business necessity), the data must be deleted.
- **Important:** Legitimate interest cannot be used as a basis for processing **sensitive personal data** (Art. 11; Art. 10). Any sensitive data processed under LI was non-compliant from the outset.

#### 4d. If Data Was Processed Under Legal Obligation (Art. 7, II)

If you are **required by law or regulation** to retain certain data (e.g., tax records, anti-money laundering records, consumer transaction records under the Consumer Defence Code):

- The deletion right does **not** override a mandatory legal retention requirement.
- Art. 16, I explicitly permits retaining data for compliance with a legal or regulatory obligation even after the data subject requests deletion.

#### 4e. Art. 16 — Lawful Retention Exceptions

Art. 16 of LGPD sets out circumstances under which data **may be retained** even after a deletion request:

| Exception | Art. 16 Sub-item | Example |
|-----------|-----------------|---------|
| Compliance with legal or regulatory obligation | Art. 16, I | Tax records, financial records required by law |
| Transfer to third parties (with legal basis) | Art. 16, II | Sharing with a controller who has an independent legal basis |
| Exclusive use by controller; anonymised data | Art. 16, III | Aggregated/anonymised analytics that no longer identify the person |
| Exercise of rights in judicial, administrative, or arbitral proceedings | Art. 16, IV | Retention for active litigation involving the data subject |

Where you rely on an Art. 16 exception, you must:
- Inform the data subject that their deletion request is partially refused and on what basis.
- Limit retained data to the minimum necessary for the permitted purpose (Art. 6, III — necessity principle).
- Document the exemption in your request log.

---

### Step 5 — Execute Deletion Across All Three Platforms

For data that is not subject to an Art. 16 retention exception, you must execute deletion **without undue delay** (Art. 18, §4º). ANPD guidance indicates 15 days as the target timeframe for full responses, but deletion should proceed as quickly as technically feasible.

#### CRM

- Delete the user's contact record, interaction history, notes, tags, and any linked custom fields.
- If your CRM has backup systems, include scheduled deletion from backups within your standard backup retention cycle.
- If the CRM is operated by a third-party vendor, that vendor is acting as a **processor (operador)** under Art. 5, VII. Under Art. 39, processors must act solely per controller instructions. You must instruct the CRM vendor in writing to delete the data. Your contract with the CRM vendor should already include LGPD-compliant data processing terms (Art. 39).

#### Email Platform

- Delete the user's email address, subscription preferences, email interaction history (opens, clicks), and any segmentation or profile data.
- Suppress the email address to prevent future sends (distinguish between deletion and suppression — suppression lists typically retain the email address in a "do-not-contact" list; this may be permissible under Art. 16, I if required for compliance, or under a legitimate interest in not re-contacting someone who has requested deletion).
- As with the CRM, instruct the email platform vendor (processor) to execute deletion per Art. 39.

#### Analytics Tool

- Identify all event data, session data, user profiles, and identifiers linked to this user.
- Delete or anonymise user-level data. **True anonymisation** removes all reasonable means of re-identification (Art. 5, III; Art. 12). Anonymised aggregate data (e.g., total page views) is not personal data under Art. 12 and need not be deleted.
- If the analytics tool uses cookies or device identifiers (advertising IDs, fingerprinting), ensure those are also removed or reset.
- Instruct the analytics vendor to execute deletion per Art. 39, including any data retained in the vendor's own systems.

#### Processor Accountability (Art. 39 and Art. 42)

Controllers remain responsible for the actions of their processors. If a processor fails to delete data when instructed:
- The controller remains liable (Art. 42).
- Processors are jointly liable where they violate LGPD or fail to follow controller instructions (Art. 42, §1º).

Ensure your vendor contracts explicitly require processors to:
- Delete data upon controller instruction.
- Confirm deletion in writing within a defined timeframe.
- Not retain data beyond the agreed period.

---

### Step 6 — Respond to the Data Subject

Under Art. 18 and Art. 19, your response must be:

- **Free of charge** (Art. 19).
- **In clear, accessible language.**
- Provided within **15 days** for a full written response (Art. 19, §3º), or immediately for a simplified response.
- Delivered via a format accessible to the data subject.

Your response letter should include:

1. Confirmation that you have received and processed their deletion request.
2. A summary of the data deleted from each system (CRM, email platform, analytics tool).
3. Any data **not deleted**, identifying the specific Art. 16 exception and the legal basis for retention (e.g., "We have retained your purchase transaction records for 5 years as required by [applicable tax law] — Art. 16, I LGPD").
4. Notice of their right to file a complaint with the ANPD if they are dissatisfied with the handling of their request (Art. 18; Art. 22).
5. Your DPO's contact details (Art. 41, §1º).

---

### Step 7 — Update Records and Suppress Future Processing

After executing the deletion:

- **Update your RoPA** (Art. 37) to reflect that this data subject's data has been deleted and the request has been fulfilled.
- **Implement a suppression list** or equivalent technical control to prevent accidental re-collection (e.g., if the user re-visits your website or a third party attempts to upload their data to your CRM).
- **Revoke any active consents** in your consent management system.
- **Notify any downstream third parties** with whom you have shared the data. Art. 18, VII gives data subjects the right to know with whom their data has been shared, and Art. 18, IV implies that deletion should cascade to shared recipients where those recipients have no independent legal basis.

---

## 3. Timeline Summary

| Action | Responsible Party | Deadline |
|--------|------------------|----------|
| Acknowledge request | DPO / Privacy team | Day 1 |
| Verify identity | Privacy team | Days 1–3 |
| Map data across CRM, email, analytics | Technical / Privacy team | Days 2–5 |
| Assess legal bases and Art. 16 exceptions | Legal / DPO | Days 3–7 |
| Instruct processors to delete | Privacy team | Days 5–10 |
| Execute deletion across all systems | Technical team + processors | Days 5–13 |
| Respond in writing to data subject | DPO | Within 15 days (Art. 19, §3º) |
| Update RoPA and log | Privacy team | Within 15 days |

---

## 4. Potential Grounds for Refusing (or Partially Refusing) the Request

LGPD does not grant an absolute right to erasure in all circumstances. Under Art. 18, §3º and Art. 16, you may lawfully refuse or limit the deletion where:

| Grounds | Legal Basis | Action Required |
|---------|-------------|----------------|
| Legal or regulatory retention requirement | Art. 16, I | Retain minimum necessary data; notify data subject |
| Active litigation involving the data subject | Art. 16, IV | Retain data for duration of proceedings; notify data subject |
| National security or criminal investigation | Art. 18, §3º | Notify data subject of exemption; right to complain to ANPD |
| Data already anonymised | Art. 12 | Confirm anonymisation; no deletion required as data is not personal data |

Any refusal must be **communicated to the data subject** with the specific reason, and they must be informed of their right to file a complaint with the ANPD (Art. 18, §4º).

---

## 5. Enforcement Risk for Non-Compliance

Failure to comply with a valid deletion request is a priority enforcement area for the ANPD. The authority has specifically flagged **failure to respond to data subject rights — especially access and deletion — as a key enforcement priority**.

Under Art. 52, sanctions for non-compliance include:

| Sanction | Details |
|----------|---------|
| Warning | With deadline to remedy |
| Simple fine | Up to 2% of Brazilian revenue (prior FY); maximum R$50 million per violation |
| Daily fine | To compel compliance; same R$50M cap |
| Public disclosure | Publication of the violation |
| Blocking | Temporary blocking of the relevant personal data |
| Deletion | ANPD-ordered deletion of the data |
| Processing suspension | Partial suspension for up to 6 months |
| Processing prohibition | Complete ban on data processing activities |

The ANPD's complaint process allows the data subject to escalate directly to the ANPD (at https://www.gov.br/anpd/pt-br/assuntos/peticoes) if their request is not properly handled. The ANPD first gives the controller the opportunity to resolve the complaint before escalating to a formal investigation (Art. 54).

Aggravating factors under Art. 52, §1º that would increase any fine include: recidivism, lack of internal controls, failure to cooperate with the ANPD investigation, and degree of harm to the data subject.

---

## 6. Key LGPD Compliance Checklist for This Request

- [ ] Request received and logged with date and requestor details
- [ ] Identity of data subject verified proportionately
- [ ] DPO notified and assigned (Art. 41)
- [ ] Data mapped across CRM, email platform, and analytics tool
- [ ] Legal basis for each dataset identified (Art. 7 / Art. 11)
- [ ] Art. 16 retention exceptions assessed and documented
- [ ] Processors (CRM vendor, email platform, analytics vendor) instructed to delete per Art. 39
- [ ] Deletion executed across all systems without undue delay (Art. 18, IV / Art. 18, VI)
- [ ] Any downstream data-sharing recipients notified
- [ ] Data subject notified in writing within 15 days (Art. 19)
- [ ] Grounds for any partial refusal communicated to data subject
- [ ] ANPD complaint rights communicated to data subject
- [ ] RoPA updated to reflect deletion (Art. 37)
- [ ] Suppression controls implemented to prevent re-collection
- [ ] Request and response retained in compliance log

---

## 7. Note on LGPD vs. GDPR

For organisations also subject to GDPR, this situation maps closely to the GDPR "right to erasure" under Art. 17 GDPR. Key differences to note:

| Topic | LGPD | GDPR |
|-------|------|------|
| Deletion right scope | Art. 18, IV and Art. 18, VI | Art. 17 GDPR |
| Retention exceptions | Art. 16 (4 categories) | Art. 17(3) GDPR (6 categories) |
| Response timeframe | 15 days (Art. 19) | 1 month (extendable to 3) — Art. 12(3) GDPR |
| Supervisory authority | ANPD | Relevant EU/EEA DPA |
| Right to complain | Art. 18, §4º; Art. 22 | Art. 77 GDPR |

LGPD's 15-day response window is significantly shorter than GDPR's one-month period. Organisations operating under both regimes should calibrate their DSR processes to the more demanding LGPD timeline.

---

## Summary

A Brazilian user's deletion request triggers obligations under Art. 18, IV and Art. 18, VI of LGPD across all systems holding their personal data — your CRM, email platform, and analytics tool. The process requires: (1) identity verification; (2) data mapping and legal basis analysis for each system; (3) assessment of Art. 16 retention exceptions; (4) issuing deletion instructions to each third-party processor per Art. 39; (5) executing deletion without undue delay; and (6) a written response to the data subject within 15 days confirming what was deleted and explaining any lawful retention.

Non-compliance with a valid deletion request is an ANPD enforcement priority carrying penalties of up to 2% of Brazilian revenue or R$50 million per violation (Art. 52).

---

*This analysis is based on LGPD — Law No. 13,709/2018 as amended by Law No. 13,853/2019 — and ANPD guidance and resolutions current as of May 2026. Legal advice specific to your organisation's circumstances should be obtained from qualified Brazilian data protection counsel.*

# LGPD Data Deletion Request: How to Handle a Brazilian User's Request

## Overview

Brazil's Lei Geral de Proteção de Dados Pessoais (LGPD), Law No. 13,709/2018, grants data subjects a set of enforceable rights over their personal data. When a Brazilian user requests deletion of all their personal data held across your CRM, email platform, and analytics tool, you are legally obligated to respond in a structured and timely manner. This document covers the applicable rights, the step-by-step process, mandatory timelines, and lawful exemptions.

---

## 1. Applicable LGPD Rights

### Right to Deletion (Art. 18, IV and VI)

The LGPD provides two distinct deletion rights:

- **Art. 18, IV — Deletion of unnecessary or excessive data**: The data subject may request deletion of personal data that is unnecessary, excessive, or processed in non-compliance with LGPD.
- **Art. 18, VI — Deletion of data processed with consent**: Where processing is based on the data subject's consent, they may request deletion at any time.

### Related Rights That May Also Be Invoked

- **Art. 18, I — Confirmation of processing**: The user may ask whether you hold their data at all.
- **Art. 18, II — Access**: The user may request a copy of all data held.
- **Art. 18, III — Correction**: The user may request correction of inaccurate or incomplete data.
- **Art. 18, V — Anonymization, blocking, or elimination**: Where data cannot be deleted (e.g., legal obligation), it may be anonymized or blocked instead.
- **Art. 18, VII — Information on third parties**: The user may ask which third parties received their data.
- **Art. 18, IX — Revocation of consent**: If consent was the legal basis, the user may revoke it, which triggers the obligation to stop processing and, where applicable, delete.

---

## 2. Step-by-Step Process

### Step 1: Verify the Identity of the Requester

Before acting on any deletion request, confirm the requester's identity to prevent unauthorized deletion of another person's data. This can be done by:

- Matching the email address to the account on record.
- Sending a verification link or code to the registered email.
- Requesting a government-issued ID if the scope of the request is particularly sensitive or broad.

The verification step must not be used as a delay tactic and should be completed promptly.

### Step 2: Acknowledge Receipt

Send a written acknowledgment to the requester confirming that their request has been received, and provide an expected response date. Under LGPD Art. 18, §5, the controller must respond to requests. Best practice is to acknowledge within 2–3 business days.

### Step 3: Assess the Legal Basis for Processing in Each System

Before deleting, determine the legal basis under which you hold the data in each system:

| System | Likely Legal Basis | Deletion Implication |
|---|---|---|
| CRM | Contract (Art. 7, V), Consent (Art. 7, I), or Legitimate Interest (Art. 7, IX) | Review which data elements are tied to each basis |
| Email Platform | Consent (Art. 7, I) | Consent-based data is deletable upon request; unsubscribes may also trigger obligations |
| Analytics Tool | Legitimate Interest (Art. 7, IX) or Consent (Art. 7, I) | Anonymized or aggregated analytics data may not constitute personal data and may be retained |

### Step 4: Identify Any Applicable Exemptions

Check whether any exemption applies before deleting (see Section 4 below). Document the rationale for retaining any data that falls under an exemption.

### Step 5: Execute Deletion Across All Systems

For data that must be deleted:

- **CRM**: Delete the contact record including all associated fields (name, email, phone, interaction history, deal history) unless a legal hold applies.
- **Email Platform**: Remove the subscriber record, including all campaign interaction data (opens, clicks, bounces). Unsubscribe records may need to be retained separately to prove suppression compliance.
- **Analytics Tool**: Delete or anonymize user-level identifiers (user ID, IP address, device fingerprint). Aggregate statistical data that cannot be attributed to an individual does not constitute personal data under LGPD and may be retained.

Ensure deletion cascades to:
- Backup systems (set a retention window after which backups are purged).
- Any third-party sub-processors who received the data (Art. 18, §7 — the controller must communicate the deletion request to all entities with whom data was shared).

### Step 6: Notify Third Parties

Under LGPD Art. 18, §7, the controller must communicate corrections, deletions, anonymizations, or blockings to third parties to whom data was transmitted — unless such communication is impossible or disproportionately costly. Document any notifications sent to third-party processors (e.g., the CRM vendor, email service provider, analytics vendor).

### Step 7: Respond to the Requester

Provide a written response confirming:
- Which data was deleted, from which systems.
- Which data was retained, citing the specific exemption and its expected retention period.
- The identity of any third parties notified.

### Step 8: Maintain an Internal Record

Log the request and your response in your data subject request register. This supports accountability obligations under LGPD Art. 37, which requires controllers to maintain records of processing activities.

---

## 3. Timelines

LGPD does not specify a single fixed deadline for responding to data subject requests in the same way GDPR specifies 30 days. However, the following applies:

- **ANPD guidance and best practice**: Respond within **15 business days** of receiving the verified request. Some practitioners reference the Brazilian Consumer Protection Code (CDC), which mandates a 5-business-day response for consumer complaints, but the LGPD standard is broader.
- **No undue delay**: Art. 18, §5 states that responses must be provided "immediately" or, where that is not possible, within a reasonable period consistent with the complexity of the request.
- **Practical benchmark**: Many Brazilian DPOs adopt a **15-day target** for straightforward requests and a **30-day maximum** for complex or multi-system requests, with an explanation provided to the requester if the longer period is needed.

---

## 4. Exemptions — When You May Refuse or Defer Deletion

LGPD Art. 16 explicitly permits the retention of personal data even after the end of processing or upon a deletion request under the following circumstances:

### Art. 16, I — Compliance with a Legal or Regulatory Obligation

If you are required by Brazilian law (e.g., tax law, labor law, anti-money laundering regulations) to retain certain records for a defined period, you may retain the minimum data necessary to fulfill that obligation. For example:

- Brazilian tax records (Receita Federal) may require retention of invoicing and customer data for 5 years.
- Labor-related data must be retained for periods specified under the CLT (Consolidação das Leis do Trabalho).

### Art. 16, II — Transfer to a Third Party Under ANPD Rules

Data may be retained for transfer to a third party, provided the transfer is conducted in accordance with LGPD and ANPD regulations.

### Art. 16, III — Sole Use by the Controller, Anonymized

Data may be retained in anonymized form for the controller's exclusive use, where it can no longer be attributed to an identified or identifiable individual. Aggregate analytics data that has been properly anonymized falls into this category.

### Art. 16, IV — Fraud Prevention and Data Subject Security

Data may be retained when necessary for fraud prevention or to protect the safety of the data subject, in accordance with ANPD regulations.

### Art. 18, §3 — Rights of Third Parties or the Public Interest

The right to deletion may be restricted where deletion would harm the rights and freedoms of third parties, or where retention is required in the public interest.

---

## 5. Handling Each System in Practice

### CRM

- Delete all personal identifiers: name, email, phone, address, account history.
- If the customer relationship involves outstanding contractual obligations (e.g., an active warranty, pending dispute), you may retain the minimum data necessary to fulfill or enforce that contract under Art. 7, V (contract performance) until the obligation is discharged.
- After the contractual period ends, delete residual data.

### Email Platform

- Remove the subscriber from all active lists and suppress them from future sends.
- **Unsubscribe/suppression records**: Retain a minimal suppression entry (typically the hashed email address) to prevent re-adding the user to marketing lists in error. This is a narrow, defensible retention under the fraud prevention or legitimate interest basis, but document the rationale explicitly.
- Delete all campaign engagement history linked to the individual.

### Analytics Tool

- Delete or anonymize any user-level identifiers (user ID, client ID, IP address, device ID, session tokens).
- Aggregate metrics (e.g., "1,200 unique visitors in March") that cannot be re-associated with the individual are not personal data under LGPD and may be retained.
- If the tool uses cookies or device fingerprinting, ensure those identifiers are also purged from any persistent stores.

---

## 6. Documentation and Accountability

LGPD's accountability principle (Art. 6, X and Art. 37) requires you to be able to demonstrate compliance. Maintain:

- A log of the deletion request (date received, identity verified, systems searched, data deleted, exemptions claimed, response sent).
- Evidence of third-party notifications.
- Records of any partial refusals with legal justification.

Your Data Protection Officer (Encarregado, Art. 41) should oversee and sign off on the response if one has been appointed.

---

## 7. Summary Checklist

- [ ] Verify the identity of the requester.
- [ ] Acknowledge receipt of the request promptly.
- [ ] Map all personal data held in CRM, email platform, and analytics tool.
- [ ] Identify the legal basis for processing in each system.
- [ ] Assess whether any Art. 16 exemption applies to any data category.
- [ ] Execute deletion in all applicable systems (CRM, email, analytics).
- [ ] Notify all third-party sub-processors and recipients of the deletion.
- [ ] Respond to the requester in writing, confirming deletions and documenting any retained data with justification.
- [ ] Log the full request lifecycle in your data subject request register.
- [ ] Complete the above within 15 business days (30 days maximum for complex cases).

---

## 8. Key LGPD Articles Referenced

| Article | Subject |
|---|---|
| Art. 6, X | Accountability principle |
| Art. 7 | Legal bases for processing |
| Art. 16 | Retention after end of processing |
| Art. 18 | Data subject rights |
| Art. 18, §3 | Limits on the right to deletion |
| Art. 18, §5 | Obligation to respond to requests |
| Art. 18, §7 | Notification to third parties |
| Art. 37 | Records of processing activities |
| Art. 41 | Data Protection Officer (Encarregado) |

---

*This response is based on LGPD (Law No. 13,709/2018) as amended by Law No. 13,853/2019, and reflects ANPD guidance available as of May 2026. For jurisdiction-specific legal advice, consult a qualified Brazilian data protection attorney.*

# LGPD Analysis: Processing Health Insurance Data and Credit Scores for Marketing Personalised Financial Products

**Prepared for:** Fintech Startup, São Paulo, Brazil  
**Date:** 5 May 2026  
**Governing Law:** Lei Geral de Proteção de Dados Pessoais (LGPD) — Law No. 13,709/2018, as amended by Law No. 13,853/2019

---

## Executive Summary

Your proposed use case — processing customers' health insurance data and credit scores to market personalised financial products — triggers the most restrictive provisions of the LGPD. Health data is explicitly classified as **sensitive personal data** under Art. 5, X, and the legal bases available to justify its use for marketing are severely limited. Credit score data, while potentially regular personal data, also carries heightened obligations when used for profiling and automated marketing decisions. This analysis concludes that:

1. **Using health insurance data for marketing is legally precarious under LGPD** and cannot be justified by most standard legal bases — only express, specific consent (Art. 11, I) could potentially support it, subject to strict conditions.
2. **Using credit scores for marketing** may be possible under consent (Art. 7, I) or — with caution — legitimate interest (Art. 7, IX), subject to a documented balancing test.
3. **Multiple overlapping safeguards** are mandatory, including a Data Protection Impact Assessment (RIPD), DPO appointment, and robust consent management infrastructure.

---

## 1. Classification of the Data: Sensitive vs. Regular Personal Data

### 1.1 Health Insurance Data — Sensitive Personal Data (Art. 5, II; Art. 11)

Under Art. 5, II of the LGPD, **sensitive personal data** includes data concerning a person's **health** ("dados sobre a saúde"). Health insurance data falls squarely within this definition because it reveals details about a person's health status, medical history, conditions, treatments, or insured risks.

This classification is not merely definitional — it triggers an entirely separate and stricter legal regime under **Art. 11**, which exhaustively lists the bases on which sensitive data may be processed. The bases available under Art. 7 (regular data) do **not** automatically apply to sensitive data.

### 1.2 Credit Scores — Regular Personal Data (Art. 5, I; Art. 7)

Credit scores are personal data under Art. 5, I, as they relate to an identified or identifiable natural person and reflect their financial behaviour. Unless the credit score is derived from or combined with health data in a way that reveals health information, it is treated as **regular personal data** governed by Art. 7.

However, when credit scores are used for **profiling and automated marketing decisions**, additional obligations arise under **Art. 20** (right to review automated decisions).

---

## 2. Legal Bases for Processing

### 2.1 Health Insurance Data for Marketing (Art. 11 Analysis)

Art. 11 lists the only permissible bases for processing sensitive personal data. We assess each in the context of marketing:

| Art. 11 Basis | Applicable to Marketing? | Assessment |
|---|---|---|
| **Art. 11, I — Express and specific consent** | YES — with strict conditions | The only viable basis; see Section 3 below |
| **Art. 11, II, a — Legal obligation** | NO | Marketing is not required by any Brazilian law |
| **Art. 11, II, b — Public policy by public entities** | NO | Your startup is a private entity |
| **Art. 11, II, c — Research (anonymised)** | NO | Research results must be anonymised; cannot be used to target individuals |
| **Art. 11, II, d — Exercise of rights in proceedings** | NO | Not applicable to marketing |
| **Art. 11, II, e — Protection of life or physical safety** | NO | Marketing does not protect life |
| **Art. 11, II, f — Health care by professionals/entities** | NO | Marketing of financial products is not health care |
| **Art. 11, II, g — Prevention of fraud / security of data subject** | NO | Marketing is not fraud prevention |
| **Art. 11, II, h — Protection of credit** | NARROW | Art. 7, X credit protection basis does not extend to sensitive data; Art. 11 does not replicate this exception for sensitive data |

**Critical observation:** Art. 10 and Art. 11 expressly prohibit the use of **legitimate interest** as a basis for processing sensitive personal data. Unlike regular data, there is no balancing test available to justify health data processing for commercial marketing.

**Conclusion for health data:** The only plausible legal basis is **express and specific consent under Art. 11, I**. Any other approach would constitute unlawful processing.

### 2.2 Credit Score Data for Marketing (Art. 7 Analysis)

Credit scores benefit from more flexible legal bases under Art. 7:

| Art. 7 Basis | Applicable to Marketing? | Assessment |
|---|---|---|
| **Art. 7, I — Consent** | YES | Valid if freely given, specific, informed, and unambiguous (Art. 8) |
| **Art. 7, IX — Legitimate interest** | POSSIBLE | Requires documented balancing test; controller's marketing interest must not outweigh data subject's fundamental rights |
| **Art. 7, X — Credit protection** | NARROW | Permits credit analysis; does not extend broadly to marketing personalisation beyond credit risk assessment |
| **Art. 7, V — Contract** | LIMITED | Only if the marketing is strictly necessary for a pre-existing or contemplated contract with the data subject |

**Recommended basis for credit scores:** Consent (Art. 7, I) is the safest and most defensible basis for using credit scores for personalised marketing. Legitimate interest (Art. 7, IX) may also be available but requires a formal balancing test and carries greater regulatory risk — particularly given ANPD's stated enforcement focus on sensitive and financial data processing (see Section 6).

---

## 3. Consent Requirements in Detail

Since **express and specific consent** (Art. 11, I read with Art. 8) is the only viable basis for using health insurance data in marketing, the requirements for valid consent are critical:

### 3.1 Requirements for Valid Sensitive Data Consent (Art. 8; Art. 11, I)

| Requirement | LGPD Provision | Practical Implication |
|---|---|---|
| **Express** | Art. 11, I | Cannot be implied; must be an affirmative, positive action by the data subject |
| **Specific to purpose** | Art. 8, §4º | Consent for health data use in marketing must be separate from other consents; bundled consent is invalid |
| **Highlighted/differentiated** | Art. 11, I | Must be presented separately and prominently from consents for non-sensitive data processing |
| **Informed** | Art. 8 | Data subject must understand what health data will be used, for what marketing purposes, and by whom |
| **Free** | Art. 8, §3º | Cannot condition access to financial products or services on providing this consent (unless strictly necessary) |
| **Documented** | Art. 8, §2º | Burden of proof on controller to demonstrate valid consent was obtained |
| **Revocable at any time** | Art. 8, §5º | Data subject must be able to withdraw consent freely, at no cost, without prejudice |
| **No pre-ticked boxes** | Art. 8 | Consent must be an affirmative act; passive acceptance is invalid |

### 3.2 Consequence of Consent Withdrawal

Upon revocation of consent (Art. 18, IX), the controller must:
- Cease processing for the marketing purpose without undue delay
- Delete data processed solely on that consent basis (Art. 18, VI), unless another lawful basis applies (e.g., legal obligation, credit protection for the original credit assessment purpose)

---

## 4. Key Safeguards Required

### 4.1 Data Protection Impact Assessment — RIPD (Art. 38)

Processing health data (sensitive) at scale for marketing constitutes **high-risk processing** that will trigger the obligation to conduct a Relatório de Impacto à Proteção de Dados Pessoais (RIPD/DPIA). This is particularly acute because your processing involves:

- Sensitive personal data (health insurance data)
- Profiling and automated marketing decisions (credit scores)
- Large-scale financial customer data

The RIPD must be completed **before** the processing begins and must address:
- Description of the processing activity and legal basis
- Necessity and proportionality assessment (Art. 38; Art. 6, III)
- Identification of risks to data subjects (e.g., discrimination, financial harm, health data exposure)
- Mitigation measures for each identified risk
- DPO opinion on whether to proceed

ANPD may require disclosure of the RIPD upon request (Art. 38, §§1º–2º). Given ANPD's enforcement priorities (Section 6), a well-documented RIPD is a critical defence.

### 4.2 DPO Appointment (Art. 41)

As a fintech processing sensitive data (health) and credit data at scale, you are required to appoint a **Encarregado (DPO)**. The DPO's identity and contact must be **publicly published** (Art. 41, §1º) — typically on your website's privacy policy page and on any forms collecting data.

ANPD Resolution No. 2/2022 provides a limited DPO exemption for micro and small enterprises with low-risk processing, but processing sensitive data for marketing disqualifies you from this exemption.

### 4.3 Records of Processing Activities — RoPA (Art. 37; ANPD Resolution No. 2/2022)

You must maintain a RoPA for the marketing processing activities, documenting at minimum:
- Processing activity name and purpose
- Legal basis (Art. 11, I — express consent for health data; Art. 7 basis for credit data)
- Categories of sensitive and personal data
- Data subject categories (customers)
- Recipients and sharing (marketing technology vendors, analytics platforms)
- International transfers (if data leaves Brazil — e.g., cloud providers)
- Retention periods
- Security measures
- Reference to the RIPD

### 4.4 Non-Discrimination Principle (Art. 6, IX)

The LGPD expressly prohibits processing that enables **unlawful discriminatory** outcomes. Using health insurance data to target or exclude certain customers from financial products (e.g., denying credit or insurance based on health risk proxies) would violate this principle and potentially also Brazilian Consumer Protection Code obligations (Art. 45 LGPD). Your marketing logic and segmentation models must be audited for discriminatory outcomes.

### 4.5 Automated Decision Review Rights (Art. 20)

If credit scores and health data are combined in algorithms that automatically determine which marketing offers are presented to which customers, data subjects have the right to:
- Request review of decisions made solely by automated processing
- Request human review of the automated decision
- Be informed of the criteria and procedures used

You must implement a mechanism to provide meaningful human review and must document the logic of your personalisation algorithms.

### 4.6 Transparency and Privacy Notice (Art. 9)

Your privacy notice must include, specifically for this processing:
- The precise purpose of using health and credit data for marketing
- The legal basis for each data type (Art. 11, I for health; chosen Art. 7 basis for credit)
- The types of financial products marketed
- Whether data will be shared with third-party marketing platforms or data brokers
- Any international transfers of this data
- Retention periods for marketing profiles
- How to exercise rights, including consent withdrawal

### 4.7 Security Measures (Art. 46)

Given the sensitivity of health insurance data, technical and administrative security measures must be proportionate to the risk. Minimum recommended measures include:
- Encryption of health data at rest and in transit
- Strict access controls (need-to-know basis)
- Pseudonymisation where feasible for marketing analytics
- Regular security testing and vulnerability assessments
- Incident detection and response capability (Art. 48; 3 working-day preliminary ANPD notification per ANPD Resolution CD/ANPD No. 15/2024)

### 4.8 Data Minimisation and Purpose Limitation (Art. 6, I and III)

A critical compliance risk in your use case is the **secondary use** of health data originally collected for insurance purposes and now being repurposed for marketing. The LGPD's purpose limitation principle (Art. 6, I) and adequacy principle (Art. 6, II) require that:

- Health data collected for insurance administration purposes is not automatically available for marketing
- Repurposing health data for marketing requires a **new and specific legal basis** — i.e., fresh express consent (Art. 11, I) specifically for the marketing purpose
- The collection must be limited to the minimum necessary for the marketing purpose (Art. 6, III)

If your health data was originally collected under a different legal basis (e.g., contract for health insurance administration), you **cannot** rely on that original basis to now use the data for marketing. A fresh consent must be obtained.

---

## 5. Summary Legal Basis Table

| Data Type | Proposed Use | Permissible Legal Basis | Key Conditions |
|---|---|---|---|
| **Health insurance data** | Personalised marketing | **Art. 11, I — Express specific consent only** | Separate, highlighted, affirmative consent; purpose-specific; revocable; documented |
| **Health insurance data** | Fraud prevention in credit offer | Art. 11, II, g (narrow) | Only if genuinely for fraud/security prevention, not marketing |
| **Credit scores** | Personalised marketing | **Art. 7, I — Consent** (preferred) | Informed, unambiguous, specific, revocable |
| **Credit scores** | Personalised marketing | Art. 7, IX — Legitimate interest (possible) | Formal balancing test required; document that marketing interest does not override data subject rights; higher regulatory risk |
| **Credit scores** | Credit risk assessment | Art. 7, X — Credit protection | Limited to credit assessment; not a basis for general marketing |

---

## 6. Regulatory Risk Assessment

### ANPD Enforcement Priorities

ANPD has explicitly identified **sensitive data processing without legal basis** — particularly health and financial data — as a priority enforcement area. Relevant enforcement precedents include:

- **Health Sector Data Sharing (2022–2023):** ANPD investigated sharing of health data with third parties without express consent and issued compliance orders.
- **Telemarketing Sector (2023):** Multiple companies received warnings and remediation orders for processing personal data for marketing without adequate legal basis.

Given ANPD's joint oversight with:
- **Banco Central do Brasil** (financial data oversight)
- **ANS/ANVISA** (health sector data)
- **SENACON** (consumer protection)

a fintech startup using health insurance data for marketing could face **multi-regulator scrutiny**, not solely ANPD enforcement.

### Penalty Exposure (Art. 52)

| Scenario | Potential Sanctions |
|---|---|
| Using health data for marketing without valid consent | Simple fine up to 2% of Brazilian revenue or R$50,000,000 per violation; possible data blocking or deletion |
| Invalid/bundled consent for sensitive data | Warning + remediation order; escalation to fine on recurrence |
| Failure to conduct RIPD for high-risk processing | Warning; fine; suspension of processing |
| Unlawful discrimination via health data profiling | Fine + potential prohibition of processing |
| Failure to honour consent revocation | Daily fine to compel compliance |

---

## 7. Practical Recommendations

### Immediate Actions (Before Any Processing Begins)

1. **Do not use health insurance data for marketing without first obtaining fresh, express, specific, highlighted consent** from each data subject — separately from any consent for insurance services. Existing data collected for insurance administration cannot be repurposed without new consent.

2. **Conduct a RIPD** covering both the health data marketing processing and the credit score profiling processing before launching any campaign.

3. **Appoint a DPO (Encarregado)** and publish their contact details publicly.

4. **Create a RoPA entry** for each marketing processing activity, documenting legal bases, data categories, recipients, transfers, and security measures.

5. **Implement a consent management platform** capable of:
   - Recording granular, purpose-specific consents
   - Distinguishing sensitive data consents (health) with explicit highlighting
   - Enabling easy consent withdrawal
   - Maintaining timestamped consent audit logs

6. **Review your privacy notice** to add the specific elements required for marketing use of health and credit data (Art. 9).

### Structural Advice

- **Consider anonymisation/aggregation:** If health data can be used to create anonymised cohort-level marketing segments without targeting individuals based on their health status, this may reduce legal risk — but must be genuinely anonymised per Art. 12.

- **Separate the credit scoring use case from the health data use case:** They have different legal bases, different risk profiles, and should be managed separately in your consent infrastructure and RoPA.

- **Implement automated decision review processes** before launching credit-score-based personalisation, to honour Art. 20 rights.

- **Train sales, marketing, and product teams** on the restrictions on using health data for targeting — the prohibition on discriminatory processing (Art. 6, IX) must be embedded in campaign design.

---

## 8. Comparison with GDPR (for Reference)

| Topic | LGPD Position | GDPR Position |
|---|---|---|
| Health data legal bases for marketing | Art. 11, I — express specific consent only (no LI available) | Art. 9(2)(a) GDPR — explicit consent; LI also excluded for special category data |
| Credit data for marketing | Consent (Art. 7, I) or LI (Art. 7, IX) with balancing test | Consent (Art. 6(1)(a)) or LI (Art. 6(1)(f)) with balancing test |
| DPIA requirement | Art. 38 — ANPD may require for high-risk processing | Art. 35 GDPR — mandatory for high-risk processing |
| DPO | Art. 41 — always required for controllers (limited SME exemption per Resolution 2/2022) | Art. 37 GDPR — required only for specific cases (large-scale special category data processing qualifies) |
| Fines | Up to 2% Brazilian revenue; max R$50M per violation | Up to 4% global turnover; max €20M |

Both frameworks align on the fundamental principle that sensitive/special category data may not be used for commercial marketing without explicit, specific consent.

---

## 9. Conclusion

**Using health insurance data for personalised financial product marketing is legally permissible under LGPD only if you obtain express, specific, highlighted, and freely given consent from each data subject under Art. 11, I.** No other legal basis under Art. 11 supports this use case. Given the strict requirements for that consent and the high regulatory risk, you should carefully consider whether the marketing benefit justifies the compliance burden and operational risk.

**Using credit scores for personalised marketing** is more feasible, with consent (Art. 7, I) being the recommended legal basis, and legitimate interest (Art. 7, IX) potentially available subject to a documented balancing test.

Regardless of the legal bases chosen, the following safeguards are mandatory and must be implemented before any such processing begins:
- RIPD / DPIA (Art. 38)
- DPO appointment and publication (Art. 41)
- RoPA for each processing activity (Art. 37; Resolution No. 2/2022)
- Granular, auditable consent management (Art. 8; Art. 11, I)
- Updated and transparent privacy notice (Art. 9)
- Automated decision review mechanism (Art. 20)
- Non-discrimination review of marketing algorithms (Art. 6, IX)
- Proportionate security measures (Art. 46)

Engaging a qualified Brazilian data protection lawyer alongside your internal DPO is strongly recommended before operationalising this use case, given the intersection of financial sector regulation (Banco Central), health sector oversight (ANS/ANVISA), consumer protection (SENACON), and LGPD enforcement by ANPD.

---

*This analysis is based on LGPD (Law No. 13,709/2018 as amended), ANPD Resolutions CD/ANPD No. 2/2022 and CD/ANPD No. 15/2024, and ANPD published enforcement guidance as of May 2026. It does not constitute legal advice and should be reviewed by qualified Brazilian legal counsel.*

# LGPD Compliance Analysis: Using Health Insurance Data and Credit Scores for Marketing Personalised Financial Products

## Executive Summary

Processing health insurance data and credit scores for marketing personalised financial products in Brazil raises significant LGPD compliance challenges. Health data is classified as **sensitive personal data** under LGPD and is subject to strict, narrowly defined legal bases. Credit scores, while not inherently sensitive, carry additional regulatory obligations. This use case — secondary use of both data types for marketing — is **highly restricted** and will require careful legal structuring, robust safeguards, and in some scenarios may not be permissible at all without explicit consent.

---

## 1. Applicable Law and Regulatory Framework

**Lei Geral de Proteção de Dados Pessoais (LGPD)** — Lei nº 13.709/2018, as amended by Lei nº 13.853/2019 — is the primary statute governing personal data processing in Brazil. The **Autoridade Nacional de Proteção de Dados (ANPD)** is the supervisory authority responsible for enforcement, interpretation, and guidance.

For credit data specifically, **Lei nº 12.414/2011** (Positive Credit Register Law) and complementary BACEN (Banco Central do Brasil) regulations also apply to fintech entities operating in the Brazilian financial sector.

---

## 2. Classification of the Data Types

### 2.1 Health Insurance Data — Sensitive Personal Data

Under **LGPD Art. 5, II**, health data is expressly listed as **sensitive personal data** (*dado pessoal sensível*). Health insurance data — which inherently reveals a person's health status, conditions covered, medical history, or insurance risk profile — falls squarely within this category.

Sensitive personal data is subject to **heightened legal requirements** under LGPD Art. 11, which provides a **closed and exhaustive list** of legal bases for processing. These are materially more restrictive than the general legal bases applicable to ordinary personal data.

### 2.2 Credit Scores — Ordinary Personal Data with Sector-Specific Rules

Credit scores are treated as **ordinary personal data** under LGPD (not sensitive), but they are subject to:
- LGPD's general legal bases (Art. 7)
- Lei nº 12.414/2011 requirements regarding permissible uses and access rights
- BACEN regulatory requirements for licensed fintech entities

The secondary use of credit scores for marketing purposes requires a valid LGPD legal basis and must be consistent with the purpose for which the data was originally collected.

---

## 3. Legal Bases Analysis

### 3.1 Legal Bases for Sensitive Data (Health Insurance Data) — LGPD Art. 11

LGPD Art. 11 provides the following exhaustive legal bases for sensitive data processing:

| Legal Basis | Applicability to Marketing Use Case |
|---|---|
| **Explicit consent** (Art. 11, I) | Potentially available, but subject to strict requirements (see below) |
| Compliance with legal or regulatory obligation | Not applicable to marketing |
| Shared processing by public bodies | Not applicable (private fintech) |
| Medical research, health studies (with anonymisation) | Not applicable to marketing |
| Exercise of rights in judicial, administrative, or arbitration proceedings | Not applicable |
| Health protection by health professionals or bodies | Not applicable |
| Fraud prevention and data subject security | Not applicable to marketing |
| Regulatory compliance for financial activities (Art. 11, II, g) | Narrow — generally limited to credit risk assessment, not marketing |

**Practical conclusion for health data:** The only realistically available legal basis for using health insurance data for marketing is **explicit consent (Art. 11, I)**. All other bases do not cover marketing activities.

### 3.2 Requirements for Explicit Consent — LGPD Art. 8 and Art. 11, I

For consent to be valid under LGPD for sensitive data, it must be:
- **Free** (*livre*): not conditioned on the provision of services or products; coerced or bundled consent is invalid
- **Informed** (*informado*): the data subject must be clearly told what data is being processed, for what purpose, and by whom
- **Unambiguous** (*inequívoco*): for ordinary data; for sensitive data, the standard is **explicit** (*destacado*)
- **Specific** (*para finalidades determinadas*): consent must be tied to a specific, clearly articulated purpose — in this case, marketing personalised financial products
- **Granular**: separate consent must be obtained for each distinct processing purpose; bundling consent for health data processing into general terms and conditions is not permitted
- **Revocable at any time** (Art. 8, §5): data subjects must be able to withdraw consent easily and without penalty

**Risk:** If customers originally consented to health data processing for insurance-related purposes (e.g., underwriting, claims), using that data for marketing financial products is a **new, secondary purpose** and requires **fresh, explicit consent** for that specific use. Repurposing previously collected health data without new consent would violate the **purpose limitation principle** (Art. 6, I).

### 3.3 Legal Bases for Credit Score Data — LGPD Art. 7

Credit scores may be processed under a broader set of legal bases, including:

- **Consent** (Art. 7, I)
- **Legitimate interests** (Art. 7, IX) — subject to the balancing test (controller's legitimate interest must not override the data subject's fundamental rights and freedoms)
- **Compliance with legal obligation** (Art. 7, II)
- **Execution of a contract** (Art. 7, V) — only where marketing is genuinely incidental to and necessary for contract performance

**Legitimate interests for marketing:** LGPD's legitimate interests basis (Art. 7, IX) is potentially available for credit score-based marketing but requires a documented **Legitimate Interest Assessment (LIA)** demonstrating that:
1. There is a genuine legitimate interest
2. The processing is necessary for that purpose
3. The data subject's interests, rights, and freedoms do not override the controller's interest

Regulators and privacy authorities across jurisdictions are increasingly skeptical of legitimate interests as a basis for direct marketing using financial data. Given that ANPD guidance is still developing, reliance on this basis carries legal risk without a robust and documented LIA.

---

## 4. Purpose Limitation and Data Minimisation

**LGPD Art. 6, I (purpose):** Personal data must be processed only for legitimate, specific, explicit, and informed purposes. Secondary use for marketing must be either:
- Covered by the original consent/purpose, or
- Supported by a new valid legal basis

**LGPD Art. 6, III (necessity / data minimisation):** Processing must be limited to what is necessary for the stated purpose. For marketing, the controller must demonstrate that using health insurance data specifically is necessary and proportionate — which is a very high bar to clear given the sensitivity of health data.

**Compatibility analysis:** If health data was originally collected to administer a health insurance product, using it to market unrelated financial products (e.g., loans, investment products) would typically fail a purpose compatibility assessment, as these are substantively different purposes not reasonably anticipated by the data subject at the time of collection.

---

## 5. Additional LGPD Principles and Obligations

### 5.1 Transparency (Art. 6, VI)
The fintech must provide clear, accessible privacy notices disclosing:
- What data is being processed
- The specific purpose of marketing personalisation
- The legal basis relied upon
- Data retention periods
- Data subject rights and how to exercise them

### 5.2 Non-Discrimination (Art. 6, IX and Art. 21)
LGPD expressly prohibits processing sensitive data (including health data) in ways that give rise to **unlawful discrimination**. Using health insurance data to target or exclude customers from financial product offers based on inferred health status could constitute discriminatory profiling and violates Art. 6, IX.

### 5.3 Data Subject Rights (Arts. 17–22)
Customers have rights to:
- **Access** their data (Art. 18, I–II)
- **Correct** inaccurate data (Art. 18, III)
- **Delete** data processed on the basis of consent (Art. 18, VI)
- **Opt out of automated decision-making** that produces significant effects (Art. 20)
- **Revoke consent** at any time (Art. 8, §5)

Marketing based on automated profiling using health and credit data must provide a mechanism to contest automated decisions (Art. 20).

### 5.4 Data Protection Officer (DPO) — Art. 41
Entities processing sensitive data at scale are expected to appoint a **Data Protection Officer (Encarregado)**. For a São Paulo fintech processing health and credit data, DPO appointment is effectively mandatory.

### 5.5 Data Protection Impact Assessment (DPIA)
While LGPD does not explicitly mandate DPIAs by name in all cases, **ANPD guidance and Art. 38** contemplate that controllers processing sensitive data or engaging in high-risk processing (such as large-scale profiling for marketing) should conduct **impact assessments** (*relatório de impacto à proteção de dados pessoais — RIPD*). ANPD has indicated in its published resolutions that processing sensitive data for marketing is likely to require a RIPD.

---

## 6. Sector-Specific Considerations for Fintechs

### 6.1 BACEN and CMN Regulations
Fintech entities regulated by the Banco Central do Brasil (e.g., as a Sociedade de Crédito Direto, Instituição de Pagamento, or other licensed entity) are subject to:
- **BACEN Resolution 4.658/2018** (cybersecurity requirements for financial institutions)
- **BACEN Resolution 4.893/2021** (updated cybersecurity policy requirements)
- Complementary BACEN rules on credit data sharing and Open Finance (Open Banking) frameworks

These rules impose additional data governance, security, and audit trail requirements beyond LGPD.

### 6.2 Open Finance / Open Banking
If the fintech participates in Brazil's Open Finance ecosystem (regulated by BACEN), specific consent and data sharing rules apply to financial data, including credit scores. Repurposing Open Finance data for marketing purposes outside the permitted scope of that framework is prohibited.

---

## 7. Recommended Compliance Pathway

If the fintech wishes to proceed with using health insurance data and credit scores for marketing personalised financial products, the following steps are required:

1. **Obtain explicit, specific, granular consent** from each data subject for the specific purpose of using health insurance data and credit scores for marketing. This consent must be:
   - Separate from any consent for the primary insurance/financial product purpose
   - Clearly worded and not buried in general terms
   - Easy to withdraw at any point

2. **Conduct a RIPD (DPIA)** documenting the processing, risks, and mitigations — particularly for the use of sensitive health data in a marketing context.

3. **Perform a Legitimate Interest Assessment** if relying on that basis for credit score processing, and document it formally.

4. **Review purpose limitation** — ensure that any data originally collected for insurance underwriting or credit assessment is not repurposed without fresh consent.

5. **Implement non-discrimination controls** to prevent health data from being used in ways that could discriminate against customers in access to financial products.

6. **Update privacy notices** to clearly disclose the marketing use of health and credit data.

7. **Appoint a DPO** and ensure they are accessible to data subjects.

8. **Establish data subject rights mechanisms** including easy consent withdrawal, data access requests, and opt-out of profiling.

9. **Apply data minimisation and retention controls** — collect and retain only what is strictly necessary for the marketing purpose.

10. **Engage legal counsel** with LGPD and BACEN expertise to review the specific business model and consent mechanisms before launch.

---

## 8. Summary Assessment

| Data Type | Use for Marketing | Primary Legal Basis | Risk Level |
|---|---|---|---|
| Health insurance data | Heavily restricted | Explicit consent only (Art. 11, I) | Very High |
| Credit scores | Possible with controls | Consent or Legitimate Interests (Art. 7) | Medium–High |
| Combined profiling (health + credit) | Requires full RIPD and explicit consent | Explicit consent | Very High |

**Overall Assessment:** Using health insurance data for marketing personalised financial products is **legally possible under LGPD only on the basis of valid, explicit, specific consent**. No other legal basis in Art. 11 supports this use. Absent genuine, freely given, informed, and specific consent, this processing would be **unlawful under LGPD**.

Credit score use for marketing is less restrictive but still requires a valid legal basis, purpose compatibility analysis, and documented LIA if relying on legitimate interests.

The combination of both sensitive and financial data for automated marketing profiling places this processing in a **high-risk category** requiring a RIPD, strong governance, and careful implementation. Enforcement by ANPD, while still developing, has been increasingly active. Administrative sanctions under LGPD Art. 52 include warnings, fines of up to 2% of Brazilian revenue (capped at R$50 million per violation), and public disclosure of the infraction.

---

*This analysis is based on LGPD (Lei nº 13.709/2018), associated ANPD guidance, and applicable Brazilian financial sector regulations. It does not constitute legal advice. The fintech should engage qualified Brazilian legal counsel before implementing any data processing activities described herein.*

# LGPD Breach Notification Obligations — Database Breach Affecting 50,000 Brazilian Customers

**Incident Summary:** Database breach exposing names, email addresses, and encrypted passwords of 50,000 Brazilian customers.
**Date of Response:** 2026-05-05

---

## 1. Immediate Legal Assessment

### Does LGPD Apply?
Yes. The affected individuals are Brazilian customers, meaning LGPD (Law No. 13,709/2018, as amended by Law No. 13,853/2019) applies in full under **Art. 3**. The data controller has obligations under **Art. 48** and ANPD Resolution CD/ANPD No. 15/2024.

### Data Types Affected

| Data Element | Classification | Notes |
|---|---|---|
| Names | Personal data (Art. 5, I) | Directly identifies individuals |
| Email addresses | Personal data (Art. 5, I) | Contact identifier |
| Encrypted passwords | Personal data (Art. 5, I) | Still personal data; encryption is a mitigating factor but does not eliminate the obligation to notify |

**Important note on encrypted passwords:** Although passwords are encrypted, they remain personal data under LGPD. Depending on encryption strength and whether the keys were also compromised, there is risk of credential-stuffing attacks and account takeover. This constitutes "relevant risk or harm" triggering notification obligations.

This breach does **not** appear to involve sensitive personal data (Art. 11) — health, biometric, racial/ethnic, political, or religious data — which would trigger stricter obligations. However, 50,000 affected data subjects constitutes large-scale processing.

---

## 2. LGPD Notification Obligations

### Primary Legal Basis: Art. 48, LGPD + ANPD Resolution CD/ANPD No. 15/2024

**Art. 48 requires** that controllers notify both the ANPD and affected data subjects of security incidents that **may cause relevant risk or harm** to data subjects.

A breach of 50,000 customers' personal data — including contact information and credentials — clearly meets the threshold of "relevant risk or harm." This triggers **two mandatory notifications**:

1. **Preliminary notification to ANPD** — within 3 working days of awareness
2. **Full incident report to ANPD** — within 20 working days of confirmation
3. **Notification to affected data subjects** — where high risk of harm exists (concurrent with or following ANPD notification)

---

## 3. The 72-Hour Action Plan

*Note: LGPD uses "3 working days" not 72 calendar hours (unlike GDPR). However, treating this as approximately 72 hours is the safest approach to ensure compliance.*

### Hour 0–4: Detect and Contain

- [ ] **Activate incident response team** — include legal/DPO, IT security, communications, and executive leadership
- [ ] **Isolate affected systems** — take the compromised database offline or restrict access immediately to prevent further exfiltration
- [ ] **Preserve evidence** — capture logs, access records, and forensic data before any remediation that could destroy evidence
- [ ] **Change all database credentials** — rotate passwords, API keys, and access tokens for all affected systems
- [ ] **Identify the attack vector** — SQL injection, compromised credentials, misconfigured access controls, or third-party breach?
- [ ] **Engage forensic specialists** — internal or external cybersecurity experts to conduct investigation
- [ ] **Notify DPO (Encarregado)** — under Art. 41, the DPO must be involved immediately and will be the point of contact with ANPD

### Hour 4–24: Assess and Scope

- [ ] **Confirm the scope of breach** — verify that exactly 50,000 (or more/fewer) records were exposed; identify which fields were accessed
- [ ] **Assess encryption strength** — determine the hashing/encryption algorithm used for passwords (bcrypt, SHA-1, MD5, etc.); weaker algorithms (MD5, SHA-1) dramatically increase risk
- [ ] **Determine if encryption keys were also compromised** — if so, passwords are effectively exposed in plaintext
- [ ] **Assess whether exfiltration occurred** — was data copied, or only accessed?
- [ ] **Identify timeline of breach** — when did it begin, when was it discovered?
- [ ] **Assess risk to data subjects** — consider: likelihood of password cracking given encryption method; risk of account takeover on other platforms (password reuse); phishing risk using exposed names and emails
- [ ] **Document all findings** — maintain a written incident log for accountability (Art. 6, X — Accountability principle)

### Hour 24–48: Preliminary ANPD Notification (Working Day 1–3)

**You must file a preliminary notification with ANPD within 3 working days** of becoming aware of the incident (ANPD Resolution CD/ANPD No. 15/2024; Art. 48, §1º).

#### ANPD Preliminary Notification — Required Content

The preliminary notification must include all of the following:

| Required Element | Description |
|---|---|
| **Nature of affected data** | Names, email addresses, encrypted passwords |
| **Number of affected data subjects** | 50,000 Brazilian customers (confirmed or estimated) |
| **Technical and security measures adopted** | Encryption in place; containment measures taken (system isolation, credential rotation, forensic investigation commenced) |
| **Risks of the incident** | Potential credential-stuffing attacks, account takeover, phishing using exposed contact data |
| **Measures taken or planned** | Containment actions, password reset enforcement, user notification plan, forensic review |
| **Controller identity and contact** | Full legal name, CNPJ, DPO name and contact details (Art. 41) |
| **Reason for any delay** | If notification is delayed beyond 3 working days, reason must be stated |

**How to file:** Submit via the ANPD's official portal at [https://www.gov.br/anpd/pt-br](https://www.gov.br/anpd/pt-br) or by email to anpd@anpd.gov.br. Check ANPD's current portal for the most up-to-date submission form.

### Hour 48–72: Notify Affected Data Subjects

**Art. 48 requires notification to affected data subjects** where the incident poses high risk of harm. A breach of login credentials (even encrypted) and contact data for 50,000 individuals meets this threshold.

#### Data Subject Notification Must Include:

- Description of the incident in plain language
- Types of data exposed (name, email, encrypted password)
- Measures taken to protect them
- Practical steps data subjects should take (password reset, watch for phishing)
- Contact information for the DPO / support team
- Data subjects' rights under LGPD (Art. 18) and how to exercise them

**Recommended notification channels:** Direct email to each affected customer (you have their email addresses); supplementary notice on your website/app.

**Tone and content guidance:** Be clear, honest, and actionable. Avoid minimising the incident. Customers should be told:
- Their password on your platform has been reset or should be reset immediately
- If they use the same password elsewhere, they should change it on all other platforms
- To be vigilant for phishing emails

---

## 4. Full Incident Report — Within 20 Working Days

Within 20 working days of confirming the incident, submit a **comprehensive report to ANPD** (Art. 48). This must include:

- Complete forensic findings — how the breach occurred, timeline, full scope
- Complete list of data categories and fields affected
- Exact (or refined) count of affected data subjects
- Root cause analysis
- Full description of corrective and preventive measures implemented
- Any third-party processor involvement and their liability assessment (Art. 42)
- Evidence of data subject notifications sent
- Impact assessment on data subjects' rights
- Long-term remediation plan

---

## 5. Parallel Actions — Beyond 72 Hours

### Force a Password Reset
- Immediately invalidate all sessions and force password resets for affected accounts
- Implement multi-factor authentication (MFA) if not already in place

### Assess Third-Party Processors
Under **Art. 39 and Art. 42**, if the database was managed or accessed by a processor (third-party cloud provider, database vendor, etc.), you must:
- Notify them of the incident
- Assess whether they bear joint liability
- Review your Data Processing Agreement (DPA) with them

### Review Legal Bases and Records
- Confirm your legal basis for processing the affected customer data (Art. 7) — most likely **Art. 7, V (contract)** or **Art. 7, I (consent)**
- Ensure your Records of Processing Activities (RoPA — Art. 37) is updated to reflect the incident

### Engage Legal Counsel
- Assess civil liability exposure under **Art. 42–44** — affected data subjects may seek damages
- Consider whether the Consumer Defence Code (CDC) creates additional obligations
- Review cyber insurance policy for coverage and notification requirements

### Conduct a DPIA / RIPD
Under **Art. 38**, conduct or update a Data Protection Impact Assessment (RIPD) for the affected processing activity to document risks and mitigation measures. ANPD may request this during their investigation.

---

## 6. Penalty Exposure

If LGPD obligations are not met, the following sanctions may apply under **Art. 52**:

| Sanction | Applicable Scenario |
|---|---|
| **Warning** | First violation; minor procedural breach |
| **Simple fine** | Up to 2% of Brazilian revenue (prior FY); maximum **R$50 million per violation** |
| **Daily fine** | To compel compliance with ANPD orders |
| **Public disclosure** | Publication of the violation after investigation |
| **Data blocking or deletion** | Affecting the processing activities involved |
| **Suspension or prohibition** | For serious or recurrent violations |

**Key mitigating factors (Art. 52, §1º)** that reduce penalty exposure:
- Promptly notifying ANPD within the 3-working-day window
- Cooperating fully with the ANPD investigation
- Demonstrating good faith and existing security measures (encrypted passwords)
- Promptly notifying and protecting affected data subjects
- Implementing corrective measures before ANPD action

**Key aggravating factors to avoid:**
- Late or incomplete ANPD notification
- Failure to notify data subjects
- Evidence of inadequate security practices (e.g., weak hashing algorithms)
- Prior LGPD violations

**Large-scale breach context:** ANPD has identified large-scale data breaches as an enforcement priority. A 50,000-person breach will attract regulatory attention. Prompt, transparent action is essential.

---

## 7. 72-Hour Checklist Summary

| Priority | Action | Deadline |
|---|---|---|
| **CRITICAL** | Contain the breach — isolate systems, preserve evidence | Hour 0–4 |
| **CRITICAL** | Notify DPO; activate incident response team | Hour 0–4 |
| **CRITICAL** | Change all compromised credentials and access keys | Hour 0–8 |
| **HIGH** | Scope and assess the breach — data types, volume, vector | Hour 4–24 |
| **HIGH** | Force password reset for all 50,000 affected accounts | Hour 4–24 |
| **CRITICAL** | File **preliminary ANPD notification** (3 working days) | Working Day 1–3 |
| **HIGH** | Notify affected data subjects by email | Hour 48–72 |
| **HIGH** | Engage forensic experts for full investigation | Hour 24–48 |
| **MEDIUM** | Notify third-party processors if involved | Hour 24–72 |
| **MEDIUM** | Brief legal counsel; assess civil liability | Hour 24–72 |

---

## 8. Key LGPD References

| Article / Resolution | Topic |
|---|---|
| **Art. 3** | Scope — applies to Brazilian customers' data |
| **Art. 5, I** | Definition of personal data |
| **Art. 6** | Principles — Security, Prevention, Accountability |
| **Art. 41** | DPO (Encarregado) — must be involved immediately |
| **Art. 46** | Security measures obligation |
| **Art. 48** | Incident notification obligation — ANPD and data subjects |
| **Art. 48, §1º** | Content requirements for notification |
| **Art. 52** | Administrative sanctions and penalty methodology |
| **Art. 42–44** | Civil liability for controllers and processors |
| **ANPD Resolution CD/ANPD No. 15/2024** | 3-working-day preliminary notification requirement |

---

## 9. LGPD vs. GDPR — Key Difference on Breach Notification

If your organisation also has GDPR obligations (e.g., EU customers or EU-based operations), note:

| Aspect | LGPD | GDPR |
|---|---|---|
| Supervisory authority notification | **3 working days** (preliminary) | **72 calendar hours** |
| Full report | **20 working days** | No separate full-report deadline (Art. 33 GDPR) |
| Data subject notification | Required where high risk | Required where high risk (Art. 34 GDPR) |

Under GDPR, 72 calendar hours is a hard deadline; under LGPD, 3 working days is slightly more generous but should still be treated with urgency. If you have dual obligations, you should comply with the stricter 72-hour GDPR clock.

---

*This analysis is based on LGPD (Law No. 13,709/2018, as amended), ANPD Resolution CD/ANPD No. 15/2024, and ANPD enforcement guidance current as of May 2026. This document is for compliance planning purposes and does not constitute legal advice. Engage qualified Brazilian data protection counsel for legal representation.*

# LGPD Breach Notification: 50,000 Brazilian Customers Affected

## Incident Summary

- **Scope:** 50,000 Brazilian data subjects
- **Data Exposed:** Names, email addresses, encrypted passwords
- **Applicable Law:** Lei Geral de Proteção de Dados (LGPD) — Law No. 13,709/2018
- **Regulatory Authority:** Autoridade Nacional de Proteção de Dados (ANPD)

---

## LGPD Notification Obligations

### Legal Basis

Article 48 of the LGPD requires that the data controller communicate to the ANPD and to affected data subjects the occurrence of a security incident that may create risk or relevant harm to the data subjects.

### Notification Threshold

Notification is required when the incident **may cause relevant risk or harm** to the data subjects. For 50,000 individuals with exposed names and emails, this threshold is almost certainly met, even with encrypted passwords, because:

- The volume (50,000 records) is significant.
- Names and emails alone can enable phishing, spam, identity fraud, and credential-stuffing attacks.
- Even encrypted passwords represent a risk if encryption is weak or passwords are reused.

### Notification Deadline

The LGPD states notification must occur **within a reasonable timeframe** after the controller becomes aware of the incident. ANPD Resolution CD/ANPD No. 15/2024 (the ANPD's incident reporting regulation) clarified this as:

- **72 hours** for preliminary notification to the ANPD (same standard as GDPR, and explicitly aligned by ANPD guidance).
- A more **complete follow-up report** is expected within **30 days**.

### Who Must Be Notified

1. **ANPD (Autoridade Nacional de Proteção de Dados)** — Mandatory preliminary report within 72 hours.
2. **Affected Data Subjects** — Must be notified when the incident may cause significant harm, within a reasonable timeframe.

### Content of the ANPD Notification

The preliminary notification must include, at minimum:

- Description of the nature of the affected personal data
- Categories and approximate number of affected data subjects
- Contact details of the Data Protection Officer (DPO/Encarregado)
- Description of the likely consequences of the incident
- Measures taken or proposed to mitigate the effects
- Date and time of discovery of the incident
- Whether the notification to data subjects has been or will be made

---

## 72-Hour Action Plan

### Hour 0–6: Containment and Assessment

- [ ] **Activate the Incident Response Plan.** Convene the incident response team immediately.
- [ ] **Isolate the compromised system(s).** Take affected database(s) or services offline or restrict access to prevent further exfiltration.
- [ ] **Preserve evidence.** Capture logs, system snapshots, and access records before remediation alters them — these will be needed for the ANPD report.
- [ ] **Determine the attack vector.** Understand how the breach occurred (SQL injection, compromised credentials, misconfigured storage, etc.).
- [ ] **Confirm scope.** Verify exactly which records were accessed or exfiltrated: confirm the 50,000 figure and the fields involved.
- [ ] **Notify internal leadership.** Inform the CEO, Legal, and the DPO (Encarregado de Dados) immediately.

### Hour 6–24: Legal and Regulatory Engagement

- [ ] **Engage legal counsel** with Brazilian data protection expertise.
- [ ] **Contact the DPO (Encarregado).** The DPO is the designated point of contact with the ANPD and must lead the regulatory response.
- [ ] **Assess harm risk formally.** Determine whether the incident crosses the "relevant risk or harm" threshold (it almost certainly does given the scale).
- [ ] **Begin drafting the ANPD preliminary notification.** Use the ANPD's official incident reporting form (available on the ANPD portal at gov.br/anpd).
- [ ] **Document everything.** Maintain a written incident log with timestamped actions — this is required for the 30-day follow-up report and may be inspected.

### Hour 24–48: ANPD Preliminary Notification

- [ ] **Submit the preliminary notification to the ANPD** via the official ANPD portal. Include:
  - Nature of the breach and data categories exposed
  - Approximate number of affected individuals (50,000)
  - DPO contact information
  - Likely consequences for data subjects
  - Mitigation measures taken so far
- [ ] **Assess encryption strength.** If passwords were encrypted with a strong, salted algorithm (e.g., bcrypt, Argon2), document this as a mitigating factor. Weak or unsalted hashing (MD5, SHA-1) elevates risk and must be disclosed.
- [ ] **Evaluate cyber insurance coverage.** Notify your insurer if you have a cyber liability policy — late notification can void coverage.
- [ ] **Engage a forensics firm** if not already done, to conduct an independent investigation and produce a report for the ANPD.

### Hour 48–72: Data Subject Notification and Remediation

- [ ] **Draft data subject notification.** Notifications must be:
  - Written in clear, plain Portuguese
  - Explain what happened, what data was affected, and potential risks
  - Provide steps data subjects can take to protect themselves (e.g., change passwords on other sites, watch for phishing)
  - Include DPO contact information for inquiries
- [ ] **Choose notification channel.** Email is appropriate given you have email addresses. Consider also a prominent notice on your website and/or app.
- [ ] **Send notifications to all 50,000 affected individuals.**
- [ ] **Force password resets** for all affected accounts, even though passwords were encrypted.
- [ ] **Consider offering credit monitoring or fraud alerts** if feasible — not legally required but demonstrates good faith to the ANPD.
- [ ] **Patch the vulnerability** that allowed the breach before bringing systems back online.

---

## Risk Assessment for This Specific Incident

| Factor | Assessment |
|---|---|
| Data sensitivity | Moderate — names and emails are personal data; no financial or health data reported |
| Encryption of passwords | Mitigating — reduces immediate credential misuse risk |
| Volume | High — 50,000 individuals is significant scale |
| Risk of harm | High — phishing, credential stuffing, identity fraud are likely downstream risks |
| Notification required? | **Yes** — both ANPD and data subjects |

---

## Potential Penalties for Non-Compliance

Under LGPD Article 52, failure to notify the ANPD of a breach can result in:

- **Warnings** with a mandatory corrective action deadline
- **Fines** up to 2% of the company's revenue in Brazil in the prior fiscal year, capped at BRL 50 million per infraction
- **Public disclosure** of the violation
- **Suspension** of data processing activities

Failure to notify affected data subjects can result in similar sanctions and significantly increases reputational damage.

---

## 30-Day Follow-Up Obligations

After the 72-hour window, the ANPD expects a complete incident report within 30 days (per ANPD Resolution CD/ANPD No. 15/2024), covering:

- Root cause analysis
- Full forensics findings
- Complete list of affected data categories and record counts
- All remediation measures implemented
- Evidence that data subjects were notified
- Measures adopted to prevent recurrence

---

## Key Contacts and Resources

- **ANPD Portal:** [https://www.gov.br/anpd](https://www.gov.br/anpd)
- **ANPD Incident Reporting Form:** Available in the "Peticionamento Eletrônico" section of the ANPD portal
- **LGPD Text:** Lei No. 13,709/2018
- **ANPD Incident Resolution:** Resolução CD/ANPD No. 15, de 24 de abril de 2024

---

## Summary Checklist

**Within 72 hours:**
- [ ] Contain the breach
- [ ] Preserve forensic evidence
- [ ] Notify internal leadership and DPO
- [ ] Engage legal counsel
- [ ] Submit preliminary notification to ANPD
- [ ] Notify all 50,000 affected data subjects
- [ ] Force password resets for affected accounts
- [ ] Patch the vulnerability

**Within 30 days:**
- [ ] Submit complete incident report to ANPD
- [ ] Complete forensic investigation
- [ ] Implement and document remediation measures
- [ ] Review and update incident response and data security policies

---

*This analysis is based on LGPD (Lei No. 13,709/2018) and ANPD regulatory guidance as of 2025. Organizations should consult qualified Brazilian data protection counsel for advice specific to their circumstances.*

# LGPD International Data Transfer to the United States: Available Mechanisms and Implementation Guide

**Prepared under:** Lei Geral de Proteção de Dados Pessoais (LGPD) — Law No. 13,709/2018, as amended by Law No. 13,853/2019  
**Regulatory authority:** Autoridade Nacional de Proteção de Dados (ANPD)  
**Scenario:** Transfer of Brazilian customer personal data to parent company servers in the United States (no ANPD adequacy decision)

---

## 1. Legal Framework Overview

International data transfers from Brazil are governed by **Arts. 33–36 LGPD**. The law establishes that personal data may only be transferred internationally if one of the approved mechanisms is in place. An **adequacy decision** — where ANPD formally recognises that the destination country provides a level of protection equivalent to LGPD — is the simplest route, but the United States does not currently benefit from any such decision. As of 2025–2026, ANPD has not published a list of adequate countries.

This means your organisation must rely on one or more of the alternative mechanisms set out in Art. 33. Each is analysed below with practical implementation steps.

**Important:** Art. 36 further provides that ANPD may impose **additional requirements** for sensitive data or large-scale transfers even where a base mechanism is satisfied. This is particularly relevant where your customer data includes health, financial, or biometric information.

---

## 2. Available Transfer Mechanisms (Art. 33 LGPD)

### Mechanism 1 — Standard or Specific Contractual Clauses (Art. 33 combined with Art. 35)

**What it is:** A binding written agreement between your Brazilian entity (the data exporter / controller) and your US parent company (the data importer) that contractually guarantees the same level of protection that LGPD affords to data subjects in Brazil.

**Current ANPD status:** ANPD has not yet published standard contractual clauses (SCCs) equivalent to the EU's SCCs. Organisations must therefore use **specific contractual clauses** — bespoke contract provisions drafted to satisfy Art. 35 requirements.

**Implementation steps:**

1. **Draft the data transfer agreement (DTA).** The agreement must cover at minimum:
   - Identity of the exporting Brazilian controller and the importing US entity
   - Categories of personal data being transferred and the purposes
   - Legal basis for the underlying processing (Art. 7 or Art. 11)
   - Obligations of the importer to process data only for agreed purposes
   - Data subject rights — commitment by the importer to cooperate in fulfilling all Art. 18 rights
   - Security measures the importer will implement (equivalent to Art. 46 standards)
   - Breach notification — importer must notify the Brazilian controller promptly to enable the 3-working-day ANPD preliminary notification (Resolution CD/ANPD No. 15/2024)
   - Audit rights — the Brazilian controller's right to audit the importer or commission third-party audits
   - Sub-processing restrictions — requirement to obtain prior authorisation before engaging sub-processors
   - Governing law and dispute resolution clauses that preserve data subject remedies
   - Provisions for deletion or return of data on contract termination

2. **Conduct a Transfer Impact Assessment (TIA).** Although LGPD does not use this precise term, the accountability principle (Art. 6, X) and ANPD's expectation of documented compliance require you to assess whether the legal environment in the US (surveillance laws, government access rights) undermines the protections guaranteed in the contractual clauses. Document this assessment.

3. **Update your RoPA** (Records of Processing Activities, Art. 37) to record the transfer, its purpose, legal basis, and the contractual mechanism used.

4. **Update privacy notices** (Art. 9) to inform Brazilian data subjects that their data is transferred internationally, to what country, and on what basis.

**Recommended as:** Primary mechanism for intragroup transfers to the US parent.

---

### Mechanism 2 — Binding Corporate Rules (BCRs) (Art. 33 combined with Art. 35, I)

**What it is:** A set of binding internal privacy rules that apply across the entire corporate group (your Brazilian entity and the US parent, and any other group entities). BCRs create a framework where the group collectively commits to LGPD-equivalent protection for all intragroup transfers.

**Current ANPD status:** ANPD has not yet published a formal BCR approval procedure or standard framework. BCR authorisation by ANPD is referenced in Art. 35 but the implementing regulation remains outstanding. Organisations may still develop BCRs in anticipation of ANPD guidance, and some leverage GDPR-approved BCRs as a model.

**Implementation steps:**

1. **Assess group structure.** Map all entities in the group that will be bound — Brazilian operations, US parent, and any other subsidiaries that will handle Brazilian customer data.

2. **Draft the BCR document.** A LGPD BCR should address:
   - Scope (entities bound, categories of data, types of transfers)
   - Data protection obligations binding on each entity
   - Data subject rights mechanisms — how Brazilian data subjects exercise Art. 18 rights against any group entity globally
   - Enforcement mechanism — internal binding effect, liability allocation
   - DPO coordination across the group
   - Breach response and ANPD notification chain
   - Training requirements for group employees
   - Cooperation with ANPD

3. **Seek ANPD authorisation** once ANPD publishes its BCR procedure. Until then, document your BCR alongside contractual clauses (Mechanism 1) to ensure you have an immediately operative mechanism.

4. **Leverage GDPR BCR approval** if your group has GDPR BCRs approved by an EU supervisory authority. These demonstrate a high standard of data protection that ANPD is likely to consider positively, though they do not automatically satisfy LGPD requirements.

**Recommended as:** Medium-term strategic mechanism — begin development now and formalise when ANPD issues BCR guidance. Use alongside contractual clauses in the interim.

---

### Mechanism 3 — Specific Consent of the Data Subject (Art. 33, VIII)

**What it is:** The data subject explicitly consents to the international transfer to the United States, having been specifically informed that the US does not have an ANPD adequacy decision.

**Consent requirements under LGPD (Art. 8):**
- Must be **free** (not coerced; cannot be a condition of service unless strictly necessary)
- Must be **informed** — the data subject must be told: (a) that data will be transferred internationally; (b) to which country (United States); (c) that the US does not have an ANPD adequacy decision; (d) the risks this implies
- Must be **unambiguous** — affirmative opt-in action; pre-ticked boxes are invalid
- Must be **specific** — a general consent to "share your data" is insufficient; the international transfer consent must be separately identified
- Must be **documented** — the controller bears the burden of proving consent was validly obtained
- Must be **revocable** — at no cost, at any time, without prejudice

**Limitations of consent as the sole mechanism:**
- Consent can be withdrawn at any time. If a customer withdraws consent, you must cease transferring that customer's data and potentially repatriate it — operationally complex at scale.
- LGPD prohibits conditioning service on consent (Art. 8, §5º) unless the processing is genuinely necessary for service delivery. Relying solely on consent for a bulk transfer to a parent company server carries regulatory risk.
- ANPD may scrutinise whether consent was freely given where there is a power imbalance (e.g., customer needs the service).

**Implementation steps if using consent:**

1. Design a **specific, layered consent** flow:
   - At or before data collection, include a clearly distinguished disclosure about international transfers
   - Describe: data types transferred, destination country (US), absence of adequacy decision, risks
   - Provide an affirmative opt-in (checkbox, not pre-ticked)

2. **Record consent:** Capture the consent timestamp, IP address, version of the consent form, and exact language presented.

3. **Implement a withdrawal mechanism:** A data subject request portal or email address where data subjects can withdraw transfer consent, with a documented process for actioning withdrawals.

4. **Do not rely solely on consent** for operational transfers of large customer datasets. Pair with contractual clauses (Mechanism 1).

**Recommended as:** Supplementary mechanism only, particularly for transfers that are genuinely optional from the customer's perspective. Not recommended as sole mechanism for bulk customer data transfers.

---

### Mechanism 4 — ANPD Case-by-Case Authorisation (Art. 33, IX)

**What it is:** A specific authorisation granted by ANPD for a particular transfer or category of transfers. ANPD evaluates the transfer and may impose conditions.

**Current ANPD status:** ANPD has not yet published a formal procedure for individual transfer authorisations. This mechanism exists in the law but is not yet practically accessible through a structured ANPD process.

**When it may be relevant:**
- Where no other mechanism clearly applies
- For sensitive data transfers where ANPD may wish to exercise oversight
- As a long-term option if ANPD develops a structured procedure

**Practical guidance:** Do not rely on this mechanism as your primary transfer basis for ongoing operational transfers. It is inherently unpredictable, slow, and ANPD has not yet established the process. Use it only if no other mechanism is available and the transfer is genuinely necessary.

---

### Mechanism 5 — Vital Interests (Art. 33, VII)

**What it is:** Transfers necessary to protect the life or physical safety of the data subject or a third party.

**Applicability:** This is a narrowly defined emergency exception. It does not apply to routine commercial transfers of customer data. It is unlikely to be relevant to your Brazilian operations expansion scenario.

---

### Mechanism 6 — Legal Cooperation and International Treaties (Art. 33, VI)

**What it is:** Transfers between public authorities under international legal cooperation obligations or treaties.

**Applicability:** Applies to transfers between government bodies under treaty frameworks. Not applicable to private sector commercial transfers to a parent company.

---

## 3. Recommended Transfer Strategy for Your Scenario

Given that you are transferring Brazilian **customer personal data** to a US parent company for operational purposes, and the US has no ANPD adequacy decision, the recommended approach is:

| Priority | Mechanism | Rationale |
|----------|-----------|-----------|
| **Primary** | Specific Contractual Clauses (Art. 35) | Immediately operable; no ANPD approval required; directly applicable to intragroup transfers |
| **Medium-term** | Binding Corporate Rules (Art. 35, I) | Provides a comprehensive group-wide framework; begin development now |
| **Supplementary** | Specific Consent (Art. 33, VIII) | For transfers that are genuinely optional and customer-initiated |

---

## 4. Implementation Checklist

### Immediate Actions (within 30 days)

- [ ] **Legal basis audit:** Confirm the legal basis (Art. 7) for the underlying processing of Brazilian customer data — this must be valid independently of the transfer mechanism
- [ ] **Draft Data Transfer Agreement** between Brazilian entity (exporter) and US parent (importer) — engage Brazilian data protection counsel
- [ ] **Conduct Transfer Impact Assessment:** Assess US legal environment (including surveillance laws such as FISA/CLOUD Act) against contractual protections
- [ ] **Update RoPA** (Art. 37): Add international transfer fields — destination country, mechanism, purpose, categories of data
- [ ] **Update privacy notice** (Art. 9): Disclose international transfers to the US, the mechanism relied upon, and the absence of an ANPD adequacy decision
- [ ] **Appoint or confirm DPO (Encarregado)** (Art. 41): Publish DPO identity and contact on your Brazilian website

### Within 60–90 Days

- [ ] **Security standards alignment:** Ensure the US parent's security measures (Art. 46 equivalent) are documented and meet Brazilian standards — consider ISO 27001 certification or SOC 2 reports as evidence
- [ ] **Data minimisation review:** Confirm only the minimum data necessary (Art. 6, III — necessity principle) is being transferred; avoid transferring more data than the US parent requires for the stated purpose
- [ ] **Sub-processor mapping:** Identify all US-side processors and sub-processors that will handle Brazilian customer data; ensure each is covered by the data transfer agreement or equivalent contractual protections
- [ ] **Conduct RIPD (DPIA)** (Art. 38): If the transfer involves large-scale data or sensitive data, complete a Data Protection Impact Assessment before the transfer commences
- [ ] **Breach response integration:** Ensure the US parent's incident response procedure includes a contractual obligation to notify the Brazilian controller within a timeframe that allows the 3-working-day ANPD preliminary notification (Resolution CD/ANPD No. 15/2024)

### Ongoing Compliance

- [ ] **Monitor ANPD regulatory developments:** ANPD is expected to publish standard contractual clauses and BCR guidance; update your mechanisms when available
- [ ] **Annual transfer review:** Reassess the transfer annually — legal environment in the US, volume/categories of data, ongoing necessity
- [ ] **Data subject rights fulfilment:** Ensure your Brazilian entity can fulfil Art. 18 rights requests even when the data is held on US servers — this requires contractual cooperation obligations on the US parent and a practical mechanism for retrieval
- [ ] **Employee training:** Train Brazilian operations staff on LGPD transfer requirements and data subject rights obligations

---

## 5. Sensitive Data Considerations (Art. 11 and Art. 36)

If your customer data includes **sensitive personal data** (health data, biometric data, racial/ethnic origin, financial data classified as sensitive, etc.), additional requirements apply:

- The legal basis for the underlying processing must be one of the Art. 11 bases (not merely Art. 7)
- Art. 36 empowers ANPD to impose **additional requirements** for sensitive data transfers
- Contractual clauses for sensitive data should include heightened protections: encryption in transit and at rest, access controls, purpose limitation, and prohibition on onward transfers without prior consent
- A RIPD (DPIA) under Art. 38 is strongly recommended and may be required by ANPD for high-risk sensitive data transfers

---

## 6. Penalty Exposure for Non-Compliance (Art. 52)

Conducting international transfers without a valid mechanism exposes your organisation to:

| Sanction | Details |
|----------|---------|
| Warning | With compulsory remediation period |
| Simple fine | Up to **2% of revenue in Brazil** (prior financial year, group basis); maximum **R$50 million per violation** |
| Daily fine | Same cap; applied to compel compliance |
| Public disclosure | Publication of violation after ANPD investigation |
| Data blocking | Temporary suspension of all processing related to the violation |
| Data deletion | ANPD may order erasure of improperly transferred data |
| Processing suspension | Partial suspension of operations up to 6 months |
| Processing prohibition | Total ban on data processing activities in Brazil |

The statute of limitations for ANPD enforcement is **5 years** from the date ANPD becomes aware of the violation (Art. 54).

---

## 7. LGPD vs. GDPR: Key Differences Relevant to Transfers

For organisations familiar with GDPR, note the following differences:

| Topic | LGPD (Brazil) | GDPR (EU) |
|-------|--------------|-----------|
| Standard contractual clauses | Not yet published by ANPD — bespoke clauses required | EC has published SCCs; parties must use approved versions |
| Adequacy list | Not yet published; US has no adequacy decision | EC adequacy decisions exist; US has EU-US Data Privacy Framework |
| BCR procedure | ANPD procedure not yet published | Formal BCR approval process with lead SA |
| Transfer impact assessment | Implied by accountability principle | Explicitly required by EDPB guidelines post-Schrems II |
| Supervisory authority | ANPD (federal, single authority) | Lead supervisory authority mechanism (one-stop-shop) |

---

## 8. Summary

Because the United States has no ANPD adequacy decision, your transfer of Brazilian customer data to your US parent company must be grounded in one of the Art. 33 mechanisms. **Specific contractual clauses** (Art. 35) are the immediately available and most practical primary mechanism. You should:

1. Execute a comprehensive Data Transfer Agreement between your Brazilian entity and the US parent before transfers commence.
2. Conduct a Transfer Impact Assessment to document that the contractual protections are effective given the US legal environment.
3. Update all required documentation — RoPA, privacy notices, RIPD.
4. Begin developing Binding Corporate Rules as a medium-term group-wide solution.
5. Monitor ANPD for standard contractual clause publication and BCR guidance.

Transfers made without a valid mechanism risk ANPD enforcement action, fines of up to 2% of Brazilian revenue (capped at R$50 million per violation), and reputational harm in the Brazilian market.

---

*This guidance reflects LGPD (Law No. 13,709/2018 as amended), ANPD resolutions current as of 2025–2026 (including Resolution CD/ANPD No. 15/2024), and should be reviewed against any new ANPD guidance or resolutions issued after the date of preparation. Engage qualified Brazilian data protection counsel before implementing transfer mechanisms.*

# LGPD International Data Transfer: Brazil to United States

## Overview

Brazil's Lei Geral de Proteção de Dados (LGPD — Law No. 13,709/2018) regulates the transfer of personal data to foreign countries under Chapter V (Articles 33–36). Since the United States does not have an adequacy decision from Brazil's data protection authority (ANPD — Autoridade Nacional de Proteção de Dados), transfers to US-based parent company servers require reliance on one of the alternative legal mechanisms described below.

---

## Legal Basis for International Transfers Without an Adequacy Decision

Under Article 33 of the LGPD, international data transfers are permitted only when one of the following conditions is met:

### 1. Standard Contractual Clauses (SCCs) — Article 33, II(a)

The most commonly used mechanism. The ANPD is empowered to publish standard contractual clauses that controllers and processors may adopt to govern cross-border transfers.

**What you need to implement:**
- Execute a data transfer agreement between your Brazilian entity (data exporter) and your US parent company (data importer) incorporating the ANPD-approved standard contractual clauses.
- As of 2025, the ANPD has been developing and refining its own SCC template (distinct from EU SCCs). Monitor ANPD publications for the final approved version.
- The contract must specify: categories of data transferred, purposes of processing, data subject rights guarantees, security measures, and sub-processor obligations.

---

### 2. Specific Contractual Clauses — Article 33, II(b)

Where standard clauses do not exist or do not fit the transfer scenario, controllers may draft specific (bespoke) contractual clauses and submit them to the ANPD for review or approval.

**What you need to implement:**
- Draft a bespoke data transfer agreement tailored to your processing activities.
- Include equivalent protections to those LGPD requires domestically (purpose limitation, data minimization, security safeguards, data subject rights).
- Engage legal counsel familiar with ANPD expectations to reduce the risk of the agreement being challenged.

---

### 3. Global Corporate Policy (Binding Corporate Rules equivalent) — Article 33, III

Multinational corporate groups may adopt a global privacy/data protection policy that is submitted to and approved by the ANPD. This is the LGPD analog to the GDPR's Binding Corporate Rules (BCRs).

**What you need to implement:**
- Develop a comprehensive group-wide data protection policy covering all entities (including the US parent).
- The policy must articulate enforceable rights for data subjects, internal accountability mechanisms, audit rights, and dispute resolution processes.
- Submit the policy to the ANPD for approval.
- This mechanism is resource-intensive but provides long-term flexibility for intra-group transfers across multiple jurisdictions.

---

### 4. Specific Consent of the Data Subject — Article 33, VIII

Transfers may be based on the free, informed, specific, and unambiguous consent of the data subject, provided the data subject is informed that the destination country does not offer an equivalent level of protection.

**What you need to implement:**
- Update your privacy notices to clearly disclose: (a) that data will be transferred to the United States, (b) that the US does not have an ANPD adequacy decision, and (c) the specific purpose of the transfer.
- Obtain affirmative, granular consent (separate from other consents) before the transfer occurs.
- Implement a consent withdrawal mechanism; withdrawal invalidates the transfer basis going forward.
- **Caution:** Consent is not suitable as the primary mechanism for large-scale or operationally essential transfers because it can be withdrawn at any time, creating operational risk.

---

### 5. Legal Cooperation Between Governments — Article 33, IV

Transfers may occur to fulfill legal obligations arising from international cooperation between Brazilian and foreign government bodies. This is narrow in scope and unlikely to apply to commercial intra-group transfers.

---

### 6. Necessity for Life or Physical Safety — Article 33, V

Applies only in emergency scenarios to protect the life or physical safety of the data subject or a third party. Not applicable to routine commercial transfers.

---

### 7. Necessity for Public Policy or Legal Obligations — Articles 33, VI–VII

Covers transfers required to perform a legal obligation, exercise rights in judicial/administrative/arbitral proceedings, or fulfill public policy purposes. Not generally applicable to routine intra-group business transfers.

---

## Recommended Implementation Roadmap

Given that your transfer is for commercial/operational purposes (customer data to a US parent company), the most practical and durable mechanisms are:

| Priority | Mechanism | Rationale |
|----------|-----------|-----------|
| 1st | Standard Contractual Clauses (ANPD model) | Widely accepted, scalable, no ongoing ANPD approval needed once template is published |
| 2nd | Specific Contractual Clauses | Available now; covers gap until ANPD SCCs are finalized |
| 3rd | Global Corporate Policy | Best long-term solution for a corporate group with multiple cross-border flows |

### Step-by-Step Implementation Plan

**Step 1 — Data Mapping and Transfer Assessment**
- Identify all categories of customer personal data being transferred (name, CPF, contact details, purchase history, etc.).
- Map the data flows: which systems send data, which US systems receive it, and for what purpose.
- Classify data by sensitivity (ordinary vs. sensitive personal data under Article 5, II).

**Step 2 — Select and Implement a Transfer Mechanism**
- Execute a Data Transfer Agreement (DTA) between your Brazilian subsidiary and US parent using currently available specific contractual clauses (Article 33, II(b)) while ANPD finalizes its standard clauses.
- The DTA should include: purpose limitation, data subject rights pass-through, security obligations, breach notification timelines, sub-processor restrictions, audit rights, and jurisdiction/governing law clauses.

**Step 3 — Update Privacy Notices**
- Revise your Brazilian-facing privacy policy to disclose: the fact of international transfer, the destination country (United States), the legal basis for transfer, and the safeguards in place.
- This is required under Article 33, paragraph 1.

**Step 4 — Implement Technical and Organizational Measures**
- Encrypt data in transit (TLS 1.2+) and at rest on US servers.
- Apply access controls and least-privilege principles on the US side.
- Document security measures to demonstrate compliance if audited by the ANPD.

**Step 5 — Establish Accountability Mechanisms**
- Appoint a Data Protection Officer (DPO/Encarregado) in Brazil if not already done (Article 41).
- Maintain records of processing activities (Article 37), including the international transfer entries.
- Implement a data subject rights fulfillment process covering Brazilian customers (access, correction, deletion, portability — Articles 18–20).

**Step 6 — Monitor ANPD Regulatory Developments**
- The ANPD continues to publish guidance and finalize SCC templates. When official SCCs are published, transition your agreements to the approved model.
- Subscribe to ANPD official communications (www.gov.br/anpd).

---

## Key Risks and Considerations

| Risk | Mitigation |
|------|-----------|
| ANPD enforcement action for undocumented transfers | Execute contractual clauses before initiating transfers |
| Consent withdrawal disrupting operations | Do not rely on consent as sole transfer mechanism for operational data |
| US sub-processors receiving Brazilian data | Ensure your DTA includes flow-down obligations to US sub-processors |
| Sensitive personal data (health, financial, biometric) | Apply heightened protections; consider whether transfer is strictly necessary |
| ANPD audit request | Maintain complete transfer documentation and records of processing |

---

## Penalties for Non-Compliance

The LGPD (Article 52) provides for administrative sanctions including:
- Warnings
- Fines of up to 2% of a company's revenue in Brazil for the prior fiscal year, capped at BRL 50 million per violation
- Partial or complete suspension of personal data processing activities
- Prohibition on processing personal data

---

## Summary

Since the United States does not have an LGPD adequacy decision from the ANPD, your company must rely on one of the Article 33 alternative mechanisms. For routine intra-group customer data transfers, the most appropriate and scalable path is to:

1. Execute specific contractual clauses (Article 33, II(b)) now as an interim measure.
2. Transition to ANPD-approved standard contractual clauses once published.
3. Consider developing a Global Corporate Policy (Article 33, III) for a permanent group-wide solution.
4. Update privacy notices, implement technical safeguards, and maintain complete transfer documentation.

Engaging a Brazilian privacy law specialist to review your specific data flows and draft compliant agreements is strongly recommended before initiating transfers.

---

*This response reflects LGPD requirements as of the knowledge cutoff date (August 2025). ANPD guidance and regulations continue to evolve; always verify against current ANPD publications.*

# CSRD Scope Analysis — German Manufacturing Company

## Company Profile

| Parameter | Value |
|-----------|-------|
| Jurisdiction | Germany (EU member state) |
| Employees | 800 |
| Annual Turnover | €120M |
| Total Assets | €55M |
| Listing Status | Listed on Frankfurt Stock Exchange (EU regulated market) |

---

## Scope Determination

**Legal basis:** Art. 19a and Art. 29a of Directive (EU) 2022/2464 (CSRD), amending Accounting Directive 2013/34/EU.

### Step 1 — Entity Type

You are an EU-incorporated company (Germany) listed on an EU regulated market (Frankfurt Stock Exchange / Frankfurter Wertpapierbörse). This places you squarely within the CSRD's EU entity rules and triggers consideration under both the "large company" and "listed SME" categories.

### Step 2 — Large Company Size Thresholds

CSRD defines a **large company** as one meeting **at least 2 of the following 3 criteria** (Accounting Directive Art. 3(4), as referenced in CSRD):

| Criterion | Threshold | Your Company | Meets? |
|-----------|-----------|-------------|--------|
| Employees | > 250 | 800 | YES |
| Annual net turnover | > €40M | €120M | YES |
| Total assets (balance sheet) | > €20M | €55M | YES |

**Result: You meet all three criteria — you are unambiguously a large company.**

### Step 3 — PIE Status Check

A Public Interest Entity (PIE) includes companies listed on an EU regulated market. The Frankfurt Stock Exchange is an EU regulated market. You are therefore a **listed PIE**.

However, the first wave of mandatory reporters under CSRD was limited to large PIEs **already subject to NFRD** — i.e., those with **more than 500 employees**. With 800 employees, you exceed the 500-employee threshold.

### Step 4 — NFRD Status Check

The Non-Financial Reporting Directive (NFRD, Directive 2014/95/EU) applied to large PIEs with more than 500 employees. With 800 employees and listing on a regulated market, your company **was subject to NFRD** and therefore falls into the **Wave 1 (large PIEs > 500 employees)** category under CSRD.

---

## Verdict

**YES — you are in scope for CSRD.**

You qualify under the most accelerated reporting timeline as a **large PIE with more than 500 employees** (previously subject to NFRD).

| Category | Your Status |
|----------|------------|
| EU company | Yes — Germany |
| Large company (2-of-3 test) | Yes — meets all three criteria |
| Listed on EU regulated market | Yes — Frankfurt Stock Exchange |
| > 500 employees (PIE threshold) | Yes — 800 employees |
| Previously subject to NFRD | Yes |

---

## First Reporting Year

| Milestone | Date |
|-----------|------|
| **First mandatory reporting financial year** | **FY 2024** |
| **Publication deadline (in management report)** | **2025** (during FY 2025 reporting cycle) |

Your first CSRD-compliant sustainability report must cover **financial year 2024**, to be published as part of your management report in **2025**.

*Note: This means reporting obligations have already commenced. If you have not yet filed your FY 2024 sustainability disclosures, this requires immediate attention.*

---

## Key Immediate Obligations (Art. 19a CSRD / ESRS)

As a Wave 1 reporter, you are required to comply with the **full ESRS framework** from FY 2024:

1. **ESRS 2 — General Disclosures (mandatory):** Governance (GOV-1 to GOV-5), Strategy (SBM-1 to SBM-3), IRO management (IRO-1). No materiality exemption applies to ESRS 2.

2. **Double Materiality Assessment (DMA):** Must be conducted in accordance with ESRS 1 (paras. 45–56) across all environmental (E1–E5), social (S1–S4), and governance (G1) topics, covering own operations and value chain.

3. **Topical ESRS Standards:** Apply to all topics assessed as material through the DMA. For a German manufacturer, ESRS E1 (Climate Change — Scope 1/2/3 emissions, transition plan), ESRS S1 (Own Workforce), and ESRS G1 (Business Conduct) are highly likely to be material.

4. **Third-Party Assurance (Art. 26a):** Limited assurance required from the first reporting year. Your statutory auditor or an accredited independent assurance services provider (IASP) must provide assurance on the sustainability disclosures.

5. **XBRL Digital Tagging:** Sustainability disclosures must be tagged in iXBRL format under ESEF (European Single Electronic Format).

6. **Location:** Disclosures must appear in a **dedicated section of the management report** (Lagebericht under HGB / §289b et seq.), not in a standalone document.

---

## Important Note: CSRD Omnibus Proposal (2025)

The European Commission published a CSRD Omnibus Package in February 2025 proposing potential scope narrowing and datapoint reductions. As of the current date (May 2026), you should verify the current legislative status of any adopted amendments, as these may affect the specific datapoints required. However, **your in-scope status as a large listed PIE with > 500 employees is unlikely to be affected by any proposed simplifications**, which primarily target smaller in-scope companies.

---

## Summary

| Question | Answer |
|----------|--------|
| In scope for CSRD? | **Yes** |
| Legal basis | Art. 19a CSRD (Directive EU 2022/2464); previously Art. 19a Accounting Directive under NFRD |
| Category | Large PIE, > 500 employees, previously NFRD-subject |
| First mandatory reporting FY | **FY 2024** |
| First publication deadline | **2025** |
| Assurance required? | **Yes — limited assurance from first year** |
| DMA required? | **Yes — ESRS 1, paras. 45–56** |

# CSRD Applicability Assessment: German Manufacturing Company

## Company Profile
- **Employees:** 800
- **Turnover:** €120M
- **Total Assets:** €55M
- **Listing:** Frankfurt Stock Exchange (regulated market)

---

## Conclusion: Yes, CSRD Applies

Your company falls under the Corporate Sustainability Reporting Directive (CSRD, EU Directive 2022/2464/EU) and is subject to mandatory sustainability reporting obligations.

---

## Legal Basis and Threshold Analysis

The CSRD establishes a tiered applicability framework based on company size and listing status. Three size criteria are used, of which a company must exceed **at least two** to qualify as a "large" company:

| Criterion | CSRD Threshold | Your Company | Exceeded? |
|-----------|---------------|--------------|-----------|
| Employees | > 250 | 800 | Yes |
| Net turnover | > €40M | €120M | Yes |
| Total assets | > €20M | €55M | Yes |

Your company exceeds **all three** thresholds, qualifying as a **large undertaking** under Article 3 of the EU Accounting Directive (2013/34/EU) as amended by CSRD.

Additionally, your company is **listed on a regulated market** (Frankfurt Stock Exchange), which is relevant to the phased rollout timeline.

---

## Reporting Timeline

The CSRD introduced a phased implementation schedule:

### Phase 1 — Already in scope (financial year 2024, reports due 2025)
Large public-interest entities (PIEs) with more than 500 employees that were already subject to the Non-Financial Reporting Directive (NFRD). This phase does **not** apply to your company, as you have 800 employees but were likely not previously a PIE subject to NFRD (NFRD applied to PIEs with >500 employees, but your company's prior NFRD status would need to be confirmed).

### Phase 2 — **Your company's applicable phase** (financial year 2025, reports due 2026)
Large undertakings not previously subject to NFRD — meaning large companies (meeting at least two of the three size thresholds above) that were **not** already reporting under NFRD. This covers listed large companies like yours with 250–500+ employees not previously in scope.

**Your first CSRD report will cover financial year 2025, to be published in 2026.**

> Note: If your company was already subject to NFRD as a PIE with >500 employees prior to CSRD, you would fall under Phase 1 (reporting on FY 2024). Given that NFRD historically applied to PIEs with >500 employees, your company (with 800 employees and Frankfurt listing) may warrant a careful review of prior NFRD status. If previously subject to NFRD, your first reporting year would be **2024** (report due **2025**). If not previously subject to NFRD, your first reporting year is **2025** (report due **2026**).

---

## Key Reporting Requirements Under CSRD

Once in scope, your company must:

1. **Report in accordance with European Sustainability Reporting Standards (ESRS)** — mandatory sector-agnostic standards (ESRS 1 & 2) and topical standards covering environment, social, and governance matters.

2. **Apply double materiality assessment** — disclosures must cover both financial materiality (sustainability risks affecting the company) and impact materiality (the company's impacts on people and environment).

3. **Include sustainability statement in the management report** — sustainability disclosures must be integrated into (not appended to) the annual report.

4. **Obtain limited assurance** — initially required at a "limited assurance" level, transitioning to "reasonable assurance" in future years.

5. **Ensure machine-readable reporting** — the annual report, including the sustainability statement, must be tagged using the ESEF (European Single Electronic Format) taxonomy.

6. **Value chain disclosure** — you will need to gather data from your upstream and downstream value chain to the extent material.

---

## German Transposition

Germany transposed the CSRD into national law through the **Umsetzungsgesetz zur CSRD** (CSRD Implementation Act), which amended the Handelsgesetzbuch (HGB). German companies must file the Nachhaltigkeitsbericht (sustainability report) as part of the Lagebericht (management report) and submit it to the Bundesanzeiger (Federal Gazette).

---

## Recommended Next Steps

1. **Confirm NFRD status** to determine whether Phase 1 (FY2024) or Phase 2 (FY2025) applies.
2. **Conduct a double materiality assessment** to identify which ESRS topics are material for your manufacturing operations.
3. **Establish data collection processes** for environmental (e.g., emissions, energy, water), social (e.g., workforce, supply chain labor), and governance metrics.
4. **Engage auditors early** to prepare for the limited assurance requirement.
5. **Review ESRS sector-specific standards** relevant to manufacturing once finalized by EFRAG.
6. **Assess value chain data availability**, particularly for Scope 3 emissions and supplier social standards.

---

## Summary

| Question | Answer |
|----------|--------|
| Does CSRD apply? | **Yes** |
| Reason | Large undertaking (exceeds all 3 size thresholds) listed on regulated market |
| First reporting year | **FY2025** (if not previously subject to NFRD) or FY2024 (if previously subject to NFRD) |
| First report due | **2026** (most likely scenario) or 2025 |
| Applicable standards | European Sustainability Reporting Standards (ESRS) |
| Assurance required | Limited assurance initially |

# Double Materiality Under CSRD: Concept, Comparison, and Assessment Process

---

## 1. What Is Double Materiality?

Double materiality is the **foundational principle of CSRD sustainability reporting** (Directive (EU) 2022/2464, Art. 19a). It requires companies to assess and report on sustainability matters from two distinct and equally valid perspectives simultaneously:

**Perspective 1 — Impact Materiality ("Inside-Out")**
Does the company have actual or potential impacts on people or the environment, whether positive or negative? This perspective looks outward from the company into the world — how the company's activities, decisions, and value chain affect ecosystems, communities, workers, and society.

**Perspective 2 — Financial Materiality ("Outside-In")**
Does a sustainability matter generate — or could it generate — risks or opportunities that affect the company's financial position, financial performance, cash flows, access to finance, or cost of capital? This perspective looks inward — how external sustainability developments affect the company's own economic value.

**The critical rule (ESRS 1, para. 47):** A topic is material if it meets **either** the impact materiality threshold **or** the financial materiality threshold. Topics meeting both thresholds are doubly material. The two perspectives are assessed independently — a topic can be impact-material without being financially material, and vice versa, and both require full disclosure under the relevant ESRS standard.

This "OR" logic is what gives double materiality its breadth. A company cannot avoid reporting on a topic simply because it does not create financial risk — if the company causes significant harm to communities or the environment, that impact must be reported regardless of whether it affects the income statement.

---

## 2. How Double Materiality Differs from GRI and TCFD

### Side-by-Side Comparison

| Aspect | CSRD / ESRS | GRI Standards | TCFD |
|--------|-------------|---------------|------|
| **Materiality concept** | Double materiality — both impact AND financial perspectives required | Impact materiality — focused on company's effects on the world | Financial materiality — focused on climate risks/opportunities affecting the company |
| **Primary perspective** | Both inside-out and outside-in | Inside-out (impact on people/environment) | Outside-in (financial risk to company) |
| **Trigger for reporting** | Either perspective suffices (OR logic) | Significant impact on economy, environment, or people | Material financial risk or opportunity from climate |
| **Mandatory or voluntary** | Mandatory EU law | Voluntary global standard | Voluntary (mandatory in some jurisdictions, e.g., UK, NZ) |
| **Scope of sustainability topics** | All ESRS topics (E, S, G) across value chain | Company-determined based on stakeholder engagement | Climate-focused (physical and transition risks) |
| **Assurance required** | Yes — limited assurance from first reporting year (Art. 26a) | Optional | Optional |
| **Stakeholder engagement** | Mandatory input into DMA process | Central — stakeholder identification drives topic selection | Recommended but not prescribed |
| **Interoperability** | ESRS 1 Appendix C maps to GRI; ESRS E1 incorporates TCFD | ESRS references GRI — GRI reporters can identify gaps | TCFD reporters have a strong foundation for ESRS E1 |

### GRI: Impact Materiality Only

GRI's materiality concept (as defined in GRI 1: Foundation 2021) focuses on the company's **significant impacts on the economy, environment, and people** — essentially the inside-out perspective. GRI asks: what does the company do to the world? It does not require a systematic assessment of how sustainability matters financially affect the company. Stakeholder engagement is central to identifying material topics under GRI, but the lens is outward.

If a company uses GRI as its sole reporting framework, it may be capturing impact materiality in reasonable depth, but it will not have systematically assessed financial risks and opportunities from sustainability matters — the outside-in dimension that CSRD requires.

### TCFD: Financial Materiality Only

TCFD (Task Force on Climate-related Financial Disclosures) operates exclusively on **financial materiality** — specifically the outside-in view of climate risk. TCFD asks how physical risks (acute events like floods, chronic effects like sea-level rise) and transition risks (policy, technology, market, reputational) could affect the company's finances. It does not ask whether the company's activities are causing climate harm.

A company reporting under TCFD may have robust climate risk scenario analysis but no assessment of whether its own emissions are causing significant environmental impact — a key impact materiality question under ESRS E1.

### The CSRD Difference

CSRD requires **both** frameworks' logic applied across **all** sustainability topics, not just climate. A company must ask both:
- "What harm or benefit is our business causing to people and the planet?" (impact lens), and
- "What sustainability developments out there could affect our financial health?" (financial lens)

Neither lens can be skipped, and the answer to either is sufficient to trigger full disclosure obligations.

---

## 3. Conducting a Double Materiality Assessment: Step-by-Step Process

The DMA is the mandatory first step in CSRD compliance (ESRS 1, paras. 19–56 and 45–56). It must be completed **before** deciding which ESRS topical standards apply — it cannot be done retrospectively to justify pre-selected topics.

### Step 1: Understand the Business Context (ESRS 1, para. 45)

Before assessing materiality, the company must establish a clear picture of what it is assessing. This involves:

- **Mapping the business model:** What products and services does the company provide? In which markets and geographies does it operate?
- **Mapping the value chain:** Who are the key upstream suppliers (tier 1 and beyond)? What are the downstream channels, customers, and end-users? Where does the company have influence?
- **Identifying sector-specific risks:** Use sector references — SASB standards, GRI sector standards, ESRS sector standards (when published) — to establish a starting universe of relevant sustainability topics.

Output: A business context document and value chain map that scopes what the DMA must cover. Note that CSRD requires companies to consider both their own operations and their upstream and downstream value chain (ESRS 1, para. 46).

---

### Step 2: Identify Actual and Potential Impacts (ESRS 1, paras. 46–48)

Generate a long list of actual and potential impacts across all ESRS topic areas. Sources for identification include:

- Internal: operational reviews, incident and near-miss data, management interviews, procurement data
- External: stakeholder engagement, NGO and civil society reports, industry benchmarks, ESG ratings, peer company disclosures

**Stakeholder engagement is mandatory (ESRS 1, para. 22).** The company must engage meaningfully with affected stakeholders — not just investors. Required engagement includes workers (own workforce and value chain), local communities, customers and consumers, civil society, and regulators. Investor-only consultation is insufficient and would be flagged during assurance.

At this stage, classify each identified impact as:
- Actual (currently occurring) or Potential (could occur in future)
- Positive or Negative
- In own operations or in the value chain
- Short-term, medium-term, or long-term

Output: A long-list impact register covering all ESRS topic areas.

---

### Step 3: Assess the Significance of Impacts (Impact Materiality Scoring)

Rate each identified impact using the ESRS significance formula:

- **Negative actual impacts:** Scale × Scope × Irremediability
- **Negative potential impacts:** Scale × Scope × Irremediability × Likelihood
- **Positive actual impacts:** Scale × Scope
- **Positive potential impacts:** Scale × Scope × Likelihood

Each criterion is scored on a 1–5 scale:

| Score | Scale | Scope | Irremediability | Likelihood |
|-------|-------|-------|----------------|-----------|
| 1 | Minimal | Very local / few individuals | Easily remediable | Very unlikely (<5%) |
| 2 | Low | Local / small group | Mostly remediable | Unlikely (5–25%) |
| 3 | Moderate | Regional / significant group | Partially remediable | Possible (25–50%) |
| 4 | High | National / large group | Mostly irreversible | Likely (50–75%) |
| 5 | Severe | International / systemic | Irreversible | Very likely (>75%) |

The company must then set a materiality threshold — for example, a severity score of ≥27 for actual negative impacts (3×3×3), or ≥50 for potential negative impacts. ESRS does not prescribe a specific numerical threshold, but the threshold chosen must be justified and disclosed in ESRS 2 IRO-1.

Output: Scored and ranked impact register with impact materiality conclusions per topic.

---

### Step 4: Identify Financial Risks and Opportunities (Financial Materiality)

Working topic by topic, assess whether each ESRS sustainability matter generates financial risks or opportunities for the company. Common sources include:

- **Physical risks** — acute (flooding, extreme heat events) and chronic (sea-level rise, shifting precipitation patterns) affecting assets, supply chains, and operations
- **Transition risks** — regulatory changes (carbon pricing, product standards), technology disruption, market shifts in customer preferences, reputational effects
- **Opportunities** — energy efficiency gains, access to green finance, talent attraction through ESG leadership, new sustainable product markets

For each identified risk or opportunity, document: the type, description, time horizon (short <1 year, medium 1–5 years, long >5 years), and potential financial effect (revenue, costs, assets, liabilities, cash flows, access to finance, cost of capital).

Output: Financial risk and opportunity register per ESRS topic.

---

### Step 5: Assess Financial Significance

Rate each identified financial risk or opportunity on two dimensions:

- **Magnitude:** Could range from less than 1% of EBITDA (low) through 1–5% (medium) to more than 5% (high)
- **Likelihood:** The probability that the financial effect materialises

Combine magnitude and likelihood to reach a financial significance score. Again, the company sets its own threshold, which must be disclosed. Topics where financial significance exceeds the threshold are financially material.

Output: Scored financial risk/opportunity register with financial materiality conclusions per topic.

---

### Step 6: Determine Overall Materiality — Topic by Topic

Apply the OR logic: a topic is material if it is impact-material, financially material, or both. Compile the conclusions into a DMA summary table:

| ESRS Standard | Topic | Impact Material? | Financially Material? | Overall Material? | Reporting Required? |
|--------------|-------|-----------------|----------------------|------------------|-------------------|
| E1 | Climate Change | Yes | Yes | Yes | Full ESRS E1 |
| E2 | Pollution | No | No | No | Omit (brief statement) |
| E3 | Water & Marine Resources | Yes | Yes | Yes | Full ESRS E3 |
| E4 | Biodiversity & Ecosystems | No | No | No | Omit (brief statement) |
| S1 | Own Workforce | Yes | No | Yes | Full ESRS S1 |
| G1 | Business Conduct | No | Yes | Yes | Full ESRS G1 |

**Important note on Climate (E1):** ESRS 1 treats climate change as presumptively material for most companies. A company seeking to exclude E1 must provide robust justification and strong evidence — it is not sufficient to simply assert that climate is not relevant to the business model.

For non-material topics, the company must include a brief explanatory statement in the materiality statement — a complete absence of justification is not permitted.

---

### Step 7: Document and Disclose the DMA Process (ESRS 2 IRO-1 and SBM-3)

The DMA process itself must be disclosed, not just its outputs. Two key ESRS 2 disclosures are required:

**ESRS 2 IRO-1 — Process to identify and assess material IROs:**
- The scope of the assessment (own operations and value chain depth)
- The methodology, criteria, and thresholds used
- How stakeholders were identified and engaged
- The timeline and frequency of the DMA
- How DMA results feed into strategy and reporting decisions

**ESRS 2 SBM-3 — Material impacts, risks, and opportunities:**
- The complete list of material topics identified
- How material IROs interact with the business model and strategy
- Current and anticipated financial effects of material IROs

The materiality statement must also list each ESRS topic concluded to be non-material and provide a brief explanation for each exclusion.

---

### Step 8: Validate and Update the DMA Annually

The DMA is not a one-time exercise. It must be reviewed at least annually, and material changes to conclusions must be disclosed. Triggers for a mid-period review include:

- Significant business changes (acquisitions, new markets, new products)
- New or amended regulation affecting sustainability risks
- Emerging risks identified by stakeholders
- Material incidents in own operations or value chain

---

## 4. Common Pitfalls to Avoid

**Scope too narrow:** Limiting the DMA to own operations only. ESRS requires value chain consideration where material — this includes key suppliers and downstream channels.

**Stakeholder engagement limited to investors:** ESRS mandates engagement with affected stakeholders, including workers, communities, and civil society. Investor-only consultation fails this requirement.

**Financial materiality skipped:** Conducting only an impact assessment. Both perspectives must be assessed independently.

**Thresholds undocumented:** Setting arbitrary thresholds without disclosing and justifying them. ESRS 2 IRO-1 requires disclosure of the methodology and thresholds applied.

**DMA done retrospectively:** The DMA must drive reporting decisions — not be completed after the topics to report have already been chosen.

**Over-exclusion without justification:** Excluding topics with only a brief or formulaic explanation. Each exclusion requires substantive reasoning.

**Static DMA:** Treating the DMA as a one-time deliverable. Annual review is mandatory.

---

## Summary

Double materiality under CSRD is a dual-lens framework that requires companies to assess sustainability topics from both an impact perspective (the company's effects on people and the environment) and a financial perspective (sustainability matters' effects on the company). Either lens can independently trigger full reporting obligations under the relevant ESRS standard.

This is fundamentally broader than GRI, which applies only the impact lens, and fundamentally broader than TCFD, which applies only the financial lens for climate. CSRD applies both lenses across all environmental, social, and governance topics, backed by mandatory assurance and legal force as EU law.

A well-conducted DMA follows the eight-step process above: understand context, identify impacts, score impact significance, identify financial risks/opportunities, score financial significance, determine materiality topic by topic, document the process in ESRS 2 disclosures, and update annually. The DMA is the foundation on which all other CSRD reporting decisions rest.

**Key references:** ESRS 1 (paras. 19–56, esp. 45–56); ESRS 2 (IRO-1, SBM-3); Directive (EU) 2022/2464, Art. 19a; Commission Delegated Regulation (EU) 2023/2772.

# Double Materiality Under CSRD

## What Is Double Materiality?

Double materiality is the defining concept at the heart of the Corporate Sustainability Reporting Directive (CSRD) and the European Sustainability Reporting Standards (ESRS) that implement it. It holds that a company must assess materiality from two distinct but related perspectives simultaneously:

1. **Financial materiality (outside-in perspective):** How do sustainability-related risks and opportunities affect the company's financial performance, position, cash flows, and value over time? This looks at how the external world — including climate change, social instability, or resource scarcity — impacts the company.

2. **Impact materiality (inside-out perspective):** How does the company's own activities, value chain, products, and services affect people and the planet? This looks at positive and negative, actual and potential impacts on the environment and society.

A topic is material under CSRD if it clears the threshold on either dimension — it does not need to satisfy both. A company must report on it if it is material from a financial perspective, from an impact perspective, or both. When a topic is material on both axes, it sits at the intersection and represents a "double material" issue — simultaneously important to investors and to affected stakeholders.

This two-dimensional requirement is codified in ESRS 1, which lays out the general requirements for how the assessment must be conducted and documented.

---

## How Double Materiality Differs from GRI and TCFD

### GRI (Global Reporting Initiative)

GRI has long used an impact-first philosophy. Its standards ask companies to identify topics that reflect significant economic, environmental, and social impacts, or that substantively influence the assessments and decisions of stakeholders. The focus is primarily on the inside-out direction — what harm or benefit does the company cause in the world?

GRI 3 (2021) introduced a concept called "impact materiality" that emphasizes actual and potential impacts across the value chain. While GRI also acknowledges that stakeholder concerns can encompass financial interest, it does not formally require companies to assess how sustainability issues translate into financial risk or opportunity for the company itself. In practice, many GRI reporters focus heavily on impact and stakeholder concerns without systematically connecting those impacts to financial materiality.

**Key difference from CSRD:** GRI is primarily single-dimensional (impact-out). CSRD requires both dimensions to be assessed and reported on independently, with explicit thresholds and criteria for each.

### TCFD (Task Force on Climate-related Financial Disclosures)

TCFD operates almost entirely on the financial materiality axis. Its four pillars — Governance, Strategy, Risk Management, and Metrics and Targets — are all oriented toward understanding how climate-related risks and opportunities affect a company's financial condition and strategic prospects. TCFD was designed specifically to give investors decision-useful information about climate risk embedded in financial assets.

TCFD does not require companies to report on the impacts they have on the climate or on affected communities. A company can be fully TCFD-compliant while saying nothing about whether it is accelerating deforestation, harming local water supplies, or contributing to carbon emissions beyond what affects its own bottom line.

**Key difference from CSRD:** TCFD is single-dimensional (financial-in). CSRD requires the same financial perspective but adds a mandatory impact perspective, and it covers all sustainability topics (not only climate).

### Summary Comparison

| Framework | Direction | Scope | Who It Serves |
|-----------|-----------|-------|----------------|
| GRI | Primarily inside-out (impact) | All ESG topics | Broad stakeholders |
| TCFD | Outside-in (financial) | Climate only | Investors/capital markets |
| CSRD/ESRS | Both directions (double) | All ESG topics | Investors + broader society |

---

## How to Conduct a Double Materiality Assessment

The ESRS do not prescribe a single rigid method, but they do set out requirements that define the minimum standard. The following steps reflect both the regulatory requirements and established practice.

### Step 1: Define the Universe of Topics

Begin by reviewing the full list of sustainability matters covered in ESRS — environment (ESRS E1–E5 covering climate, pollution, water, biodiversity, and resource use), social (ESRS S1–S4 covering workforce, supply chain workers, affected communities, and consumers), and governance (ESRS G1 covering business conduct). These are the candidate topics. Also consider whether the company's specific sector or business model raises additional issues not fully captured in the standard list.

### Step 2: Understand the Business and Value Chain

Map the company's activities, upstream supply chain, and downstream use and end-of-life stages. This scoping exercise identifies where the company has direct operations, where it has significant business relationships, and where its products or services have effects. The value chain scope is important because CSRD requires consideration of impacts and risks that extend beyond the company's own legal boundary.

### Step 3: Engage Stakeholders

Stakeholder engagement is not optional under CSRD. The company must gather input from those who are affected by its activities (workers, communities, suppliers, customers) and from those who use sustainability information for financial decisions (investors, lenders, analysts). Engagement methods can include surveys, interviews, focus groups, materiality workshops, and review of public disclosures and analyst reports. The results inform both the impact and financial assessments.

### Step 4: Assess Impact Materiality (Inside-Out)

For each candidate topic, evaluate:

- **Severity of actual negative impacts:** Considering scale (how serious is the harm?), scope (how many people or how much of the environment is affected?), and remediability (can the harm be undone?).
- **Severity of potential negative impacts:** Assessed on the same three dimensions, weighted by the likelihood that the impact will occur.
- **Scale of actual and potential positive impacts:** Positive impacts are also assessed, though negative impacts receive more weight in the severity calculus.

Topics that cross a defined severity threshold (which the company sets and must justify) are material from an impact perspective. The threshold should be consistent across topics and documented.

### Step 5: Assess Financial Materiality (Outside-In)

For each candidate topic, evaluate whether it gives rise to material risks or opportunities for the company over the short, medium, or long term. Relevant considerations include:

- Physical risks (acute events or chronic changes in environmental conditions that affect assets, operations, or supply chains)
- Transition risks (regulatory, market, reputational, or technological changes associated with moving toward a more sustainable economy)
- Dependencies on natural or social capital that could be disrupted
- Opportunities such as access to new markets, green financing, or improved customer loyalty

A topic is financially material if it has or could reasonably be expected to have a material effect on the company's financial position, performance, cash flows, or cost of capital. The definition aligns with what a reasonable investor would consider significant.

### Step 6: Apply Thresholds and Determine Materiality

Combine the results. A topic is material under CSRD if it clears the threshold on either or both dimensions. The company must document:

- Which topics are material, and why
- Which topics were considered but assessed as not material, and why
- The thresholds and criteria used for each dimension
- How stakeholder input was incorporated

The final materiality list determines which ESRS disclosure requirements apply. Some disclosures in ESRS 2 (general disclosures) are mandatory regardless of materiality. For all other topic-specific ESRS, the disclosure requirements are conditional on the company having assessed the topic as material.

### Step 7: Validate and Review

The assessment should be reviewed by senior management and the board, since CSRD places governance responsibility for sustainability reporting at the board level. It should also be reviewed periodically — at least annually — and updated when material changes occur in the business or its context. In many EU member states, the sustainability statement (including the materiality assessment rationale) will be subject to limited assurance from an auditor, with a trajectory toward reasonable assurance.

### Step 8: Document and Disclose

The company must include in its sustainability statement:

- A description of the process used to conduct the double materiality assessment
- The outcome (list of material topics)
- A summary of why certain topics were or were not assessed as material
- The role of stakeholder engagement in shaping the outcome

Transparency in the process is itself a disclosure requirement. A company cannot simply publish a list of material topics without explaining how it arrived at them.

---

## Practical Considerations

**Threshold-setting is the hardest part.** ESRS do not specify a universal quantitative threshold. Companies must exercise judgment and disclose their reasoning. Inconsistent thresholds across topics, or thresholds that are set so high that almost nothing is material, are likely to attract scrutiny from auditors and regulators.

**The value chain requirement adds significant scope.** Many companies find that their most significant impacts — particularly for social topics like labor rights — sit in the supply chain rather than in direct operations. Conducting meaningful due diligence across Tier 1 and beyond requires investment in supplier engagement and data collection.

**Financial and impact materiality can interact.** A topic that starts as impact material (a company harms a local community) can become financially material over time as litigation risk, regulatory action, or reputational damage materializes. The double materiality framework is dynamic, not a one-time exercise.

**CSRD applies to a much larger population than TCFD or GRI.** CSRD is mandatory for large EU companies and EU-listed SMEs (with different timelines), and it extends to non-EU companies with significant EU turnover. For companies already reporting under GRI or TCFD, the double materiality requirement means extending and formalizing an assessment that may previously have been done informally or from only one direction.

# CSRD Disclosure Requirements Based on Your Double Materiality Assessment

## Summary of Your DMA Outcome

| ESRS Topic | Assessment | Required? |
|------------|-----------|-----------|
| ESRS 2 — General Disclosures | Mandatory (all companies) | Yes — always |
| ESRS E1 — Climate Change | **Material** | Yes — full disclosure |
| ESRS E2 — Pollution | Non-material | No (omit with statement) |
| ESRS E3 — Water & Marine Resources | Non-material | No (omit with statement) |
| ESRS E4 — Biodiversity & Ecosystems | Non-material | No (omit with statement) |
| ESRS E5 — Resource Use & Circular Economy | Non-material | No (omit with statement) |
| ESRS S1 — Own Workforce | **Material** | Yes — full disclosure |
| ESRS S2 — Workers in Value Chain | Non-material | No (omit with statement) |
| ESRS S3 — Affected Communities | Non-material | No (omit with statement) |
| ESRS S4 — Consumers & End-Users | Non-material | No (omit with statement) |
| ESRS G1 — Business Conduct | **Material** | Yes — full disclosure |

---

## 1. ESRS 2 — General Disclosures (Mandatory for All In-Scope Companies)

ESRS 2 is **fully mandatory regardless of your DMA outcome**. Even if every topical standard had been found non-material, ESRS 2 would still be required in full (ESRS 2, para. 1; Commission Delegated Regulation (EU) 2023/2772).

### Governance (GOV)

**GOV-1 — Role of governance bodies**
- Composition and sustainability expertise of your board and supervisory bodies
- How the board oversees sustainability strategy, impacts, risks, and opportunities (IROs)
- Sustainability topics on board agendas and reporting lines into governance

**GOV-2 — Information provided to governance bodies**
- Frequency and nature of sustainability reporting to the board/management
- How governance bodies factor sustainability risks and opportunities into decisions

**GOV-3 — Sustainability in incentive schemes**
- Whether and how ESG performance metrics are integrated into executive/management remuneration
- Proportion of remuneration linked to sustainability targets

**GOV-4 — Due diligence statement**
- Whether your due diligence process aligns with international standards (UN Guiding Principles on Business and Human Rights; OECD Guidelines for Multinational Enterprises)
- How human rights and environmental due diligence is embedded in operations

**GOV-5 — Risk management and internal controls**
- Your internal control framework for sustainability reporting
- How you manage risks of material misstatement in sustainability data

### Strategy and Business Model (SBM)

**SBM-1 — Strategy, business model, and value chain**
- Overview of your business model and key value drivers
- How sustainability matters are integrated into strategy
- Description of your full value chain (upstream suppliers, own operations, downstream)
- Significant products/services, markets, and geographies

**SBM-2 — Stakeholder engagement**
- Which stakeholders were engaged and how
- How stakeholder views influenced your strategy and materiality conclusions
- Linkage between stakeholder input and identified material IROs

**SBM-3 — Material IROs and interaction with strategy**
- Output of your DMA: list of material topics (E1, S1, G1) and why they are material
- How material IROs interact with your business model and strategy
- Current and anticipated financial effects of material IROs
- Resilience of strategy under different scenarios

### Impacts, Risks and Opportunities (IRO)

**IRO-1 — DMA process description**
- Your DMA methodology: scope, process, assessment criteria
- How you assessed impact significance (scale, scope, irremediability, likelihood)
- How you identified and assessed financial risks/opportunities
- Stakeholders consulted and how their input shaped conclusions
- Why non-material topics were excluded (materiality statement)

---

## 2. ESRS E1 — Climate Change (Material)

Climate change is material for your company. This is one of the most disclosure-intensive ESRS standards. **Note:** Even for companies that find climate change non-material, Art. 19a(2)(a) of the CSRD legally requires disclosure of a transition plan — so this standard carries special weight.

### E1-1 — Transition plan for climate change mitigation
- Decarbonisation targets for 2030, 2040, and 2050 aligned with the 1.5°C pathway
- Planned actions and enablers (technology, operational changes, procurement)
- Financial resources allocated: capex, opex, and R&D for decarbonisation
- Role of carbon offsets (must be distinguished from actual emission reductions)
- Locked-in GHG assets and stranded asset risk assessment
- EU Taxonomy alignment targets

### E1-2 — Policies related to climate change mitigation and adaptation
- Scope of your climate policies (own operations and/or value chain)
- Climate risk management policies
- Net-zero ambition and decarbonisation pathway

### E1-3 — Actions and resources
- Decarbonisation action plan with timelines
- Resources committed (financial, human, technical)
- Actions addressing key GHG sources in own operations and value chain

### E1-4 — Targets related to climate change
- GHG reduction targets (Scope 1, 2, and 3 separately)
- Alignment with Paris Agreement (1.5°C pathway)
- Energy efficiency and renewable energy targets
- Physical and transition risk mitigation targets

### E1-5 — Energy consumption and mix
- Total energy consumption (MWh)
- Breakdown: fossil fuels / renewables / nuclear
- Energy intensity (per net revenue or other relevant denominator)
- Renewable energy share (%)

### E1-6 — Gross Scope 1, 2, 3 and total GHG emissions
This is typically the most data-intensive disclosure:
- **Scope 1:** Direct GHG emissions (tCO2e) from owned/controlled sources
- **Scope 2:** Indirect GHG emissions — both **location-based** and **market-based** (tCO2e)
- **Scope 3:** All **15 GHG Protocol categories** (tCO2e) — upstream and downstream
- Total GHG emissions (Scope 1 + 2 + 3)
- GHG intensity (tCO2e per € net revenue)
- Methodology disclosure: GHG Protocol alignment, emission factors used, exclusions

*Phase-in relief: Scope 3 data may be phased in during the first reporting year (ESRS 1, paras. 118–134). Confirm current phase-in status.*

### E1-7 — GHG removals and climate project finance
- GHG removals from own operations (forestry, CCUS, etc.)
- Carbon credits purchased (volume, type, standard applied)
- Clear distinction between removals and purchased offsets in any net-zero claims

### E1-8 — Internal carbon pricing
- Whether an internal carbon price is used in investment/operational decisions
- Price per tCO2e and scope of application

### E1-9 — Anticipated financial effects from climate risks and opportunities
- Financial effects of **physical risks** (acute: flooding, storms; chronic: temperature rise, sea-level rise)
- Financial effects of **transition risks** (policy/regulatory, technology, market, reputational)
- Climate-related opportunities and anticipated financial benefits
- Climate scenario analysis (EFRAG recommends at minimum 1.5°C and >2°C scenarios)

---

## 3. ESRS S1 — Own Workforce (Material)

### S1-1 — Policies related to own workforce
- Working conditions policies (health & safety, working hours, wages)
- Equal treatment and non-discrimination policies
- Human rights policies related to workforce

### S1-2 — Processes for engaging with own workers
- How workers and their representatives (trade unions, works councils) are consulted
- Topics covered in engagement and outcomes

### S1-3 — Processes to remediate negative impacts
- Grievance mechanisms available to workers
- How workers can raise concerns (whistleblowing channels, anonymous reporting)

### S1-4 — Actions and effectiveness
- Actions taken on material workforce impacts
- Approaches to managing workforce risks and opportunities
- Assessment of effectiveness of actions taken

### S1-5 — Targets
- Specific measurable targets to address material negative impacts and manage risks

### S1-6 — Employee characteristics (Quantitative)
- Total headcount
- Breakdown by gender
- By country (for material operations)
- By contract type: permanent vs. temporary
- By employment regime: full-time vs. part-time
- Number of non-employee workers (contractors, agency staff)

### S1-7 — Characteristics of non-employees
- Number and profile of non-employee workforce

### S1-8 — Collective bargaining coverage
- % of own employees covered by collective bargaining agreements
- Countries/regions where coverage applies

### S1-9 — Diversity metrics
- % female employees across total workforce and management levels
- % employees by age group (<30, 30–50, >50)

### S1-10 — Adequate wages
- Whether employee remuneration meets or exceeds living wage benchmarks

### S1-11 — Social protection coverage
- Access to social protection (sick pay, parental leave, pension) for employees

### S1-12 — Persons with disabilities
- % or number of employees with disabilities

### S1-13 — Training and skills development
- Average training hours per employee per year
- % employees receiving regular performance and career development reviews
- Transition assistance programmes (e.g., reskilling for technology change)

### S1-14 — Health and safety (Quantitative)
- % employees covered by a health & safety management system (ISO 45001 or equivalent)
- Number of work-related fatalities (employees and non-employees)
- Lost Time Injury Frequency Rate (LTIFR) per 1 million hours worked
- Number of recordable work-related accidents
- Work-related ill health cases

### S1-15 — Work-life balance
- Parental leave uptake rates, broken down by gender

### S1-16 — Compensation metrics (Quantitative)
- CEO pay ratio (CEO total remuneration / median employee total remuneration)
- Gender pay gap (median remuneration women vs. men, expressed as %)

*Phase-in relief: The gender pay gap (S1-16) and some other S1 datapoints have phase-in provisions for first-year reporters. Confirm what phase-in applies to your first reporting year.*

---

## 4. ESRS G1 — Business Conduct (Material)

### G1-1 — Corporate culture and business conduct policies
- Code of conduct / code of ethics
- Anti-corruption and anti-bribery policies
- Lobbying and political engagement policies
- Payment practices policies (prompt payment to suppliers)

### G1-2 — Management of supplier relationships
- Responsible procurement policies
- Fair dealing with suppliers (payment terms, supplier code of conduct)
- Coverage of supply chain due diligence at tier-1 supplier level

### G1-3 — Prevention and detection of corruption and bribery
- Corruption risk assessment methodology
- Anti-corruption training coverage (% of relevant employees trained)
- Processes for detecting and reporting corruption

### G1-4 — Incidents of corruption or bribery (Quantitative)
- Number of confirmed corruption convictions during the reporting period
- Total monetary value of fines for corruption
- Actions taken in response to confirmed incidents

### G1-5 — Political influence and lobbying activities
- Total financial or in-kind contributions to political parties
- Description of significant lobbying activities and positions taken

### G1-6 — Payment practices (Quantitative)
- Average payment period to suppliers (days)
- % of payments made beyond contractual payment terms
- Description of complaints received from suppliers about payment practices

---

## 5. Materiality Statement for Non-Material Topics

For all topics assessed as non-material — ESRS E2 (Pollution), E3 (Water), E4 (Biodiversity), E5 (Circular Economy), S2 (Value Chain Workers), S3 (Communities), and S4 (Consumers) — you are not required to produce the full disclosures under those standards.

However, you **must** include in your ESRS 2 SBM-3 and IRO-1 disclosures:
- A brief explanation that each topic was assessed and found non-material
- The basis for that conclusion (impact materiality and financial materiality assessment)
- How stakeholders were engaged in reaching those conclusions

This materiality statement provides the audit trail for auditors and stakeholders to understand why those standards were omitted.

---

## 6. Format, Assurance, and Digital Tagging Requirements

### Location in annual report
All CSRD disclosures must appear in a **dedicated section of the management report** (Accounting Directive, Art. 19a). They cannot be published as a standalone sustainability report.

### Third-party assurance (Art. 26a CSRD)
- **Limited assurance** is required from your first reporting year
- Assurance must cover: compliance with ESRS, the DMA process, and the sustainability information disclosed
- Provided by your statutory auditor or an independent assurance services provider (IASP)
- **Reasonable assurance** will be phased in at a later date (Commission review by 2028)

### Digital tagging (XBRL/iXBRL)
All sustainability disclosures must be **digitally tagged** in XBRL/iXBRL format using the European Single Electronic Format (ESEF). The Commission's sustainability tagging taxonomy applies.

### Comparative data
Prior-year comparative data is required for all quantitative disclosures (ESRS 1, para. 86). Phase-in provisions may apply in the first reporting year.

---

## 7. Key Data Collection Priorities

Given your material topics, focus your data collection efforts on:

| Data Area | Standard | Typical Challenge |
|-----------|----------|------------------|
| Scope 1 & 2 GHG emissions | E1-6 | Metering gaps, emission factor selection |
| Scope 3 GHG emissions (all 15 categories) | E1-6 | Value chain data availability, spend-based vs. activity-based methods |
| Transition plan narrative | E1-1 | Requires board-level strategy decision, not just data |
| Physical and transition risk assessment | E1-9 | Scenario analysis capability |
| EU Taxonomy alignment (revenue, capex, opex) | E1 / ESRS 2 | Technical screening criteria assessment |
| Gender pay gap | S1-16 | HR system configuration, consistent methodology |
| CEO pay ratio | S1-16 | Median calculation across all employees |
| LTIFR and H&S metrics | S1-14 | Consistent global H&S data collection |
| Collective bargaining coverage | S1-8 | Country-level HR data |
| Anti-corruption incident data | G1-4 | Legal/compliance case tracking |
| Supplier payment data | G1-6 | ERP/finance system reporting |

---

## 8. Omnibus Proposal Caveat

The European Commission proposed simplifications in the **CSRD Omnibus Package** (February 2025), which may reduce the number of mandatory datapoints and narrow reporting scope. The legislative process was ongoing as of the date of this guidance. You should monitor the status of the Omnibus Package before finalising your disclosure framework, as some datapoints listed above may be modified or made voluntary.

---

*Sources: Directive (EU) 2022/2464 (CSRD), Arts. 19a, 26a, 29a, 40a; Commission Delegated Regulation (EU) 2023/2772 (ESRS); ESRS 1 (General Requirements), ESRS 2 (General Disclosures), ESRS E1 (Climate Change), ESRS S1 (Own Workforce), ESRS G1 (Business Conduct); EFRAG Implementation Guidance.*

# CSRD Disclosure Requirements Based on Your Double Materiality Assessment

## Overview

Under the Corporate Sustainability Reporting Directive (CSRD) and the European Sustainability Reporting Standards (ESRS), companies only need to provide detailed disclosures for topics that are material. Your double materiality assessment identified three material topics: Climate Change (ESRS E1), Own Workforce (ESRS S1), and Business Conduct (ESRS G1). Non-material topics do not require full standard-level disclosures, though you must document and explain your materiality conclusions.

The following outlines what you must disclose.

---

## 1. Cross-Cutting / General Disclosures (Always Required)

Regardless of materiality outcomes, ESRS 1 and ESRS 2 apply to all companies in scope of CSRD. These are not subject to materiality — they form the mandatory baseline.

### ESRS 1 (General Requirements)
This standard sets out the architecture, principles, and methodology for sustainability reporting. It does not itself contain disclosure requirements but governs how you apply the other standards.

### ESRS 2 (General Disclosures) — Fully Mandatory
You must disclose all requirements under ESRS 2, which covers:

- **Governance (GOV)**: Governance bodies' oversight of sustainability matters, management roles and responsibilities, integration of sustainability in corporate governance
- **Strategy (SBM)**: Business model and value chain description, sustainability strategy and significant groups of stakeholders, material impacts, risks and opportunities and how they interact with strategy and business model
- **Impact, Risk and Opportunity Management (IRO)**: The process used to identify, assess, prioritise and monitor material IROs — including a full description of your double materiality assessment process
- **Metrics and Targets (MT)**: Disclosure of the sustainability-related targets set and performance against those targets

ESRS 2 also requires you to disclose the **list of material sustainability matters** identified through your assessment, and critically, an **explanation of why topics assessed as non-material were excluded**. This means you must document why Pollution (E2), Water (E3), Biodiversity (E4), Circular Economy (E5), Value Chain Workers (S2), Communities (S3), and Consumers/End-users (S4) were determined non-material.

---

## 2. Material Topic Disclosures

For the three topics that came out as material, you must apply the relevant topical ESRS standards. Each topical standard contains a mix of mandatory disclosures and disclosures subject to materiality.

---

### ESRS E1 — Climate Change

This is one of the most demanding ESRS standards. Key disclosure areas include:

**Governance and Strategy**
- Transition plan for climate change mitigation aligned with Paris Agreement / 1.5°C pathway
- Climate-related physical and transition risks and opportunities
- Resilience of business model and strategy under climate scenarios (scenario analysis)
- Integration of climate into overall strategy and financial planning

**Impact, Risk and Opportunity Management**
- Policies for climate change mitigation and adaptation
- Actions and resources allocated to manage climate-related IROs
- Engagement with value chain on climate matters

**Metrics and Targets**
- **Scope 1, 2, and 3 greenhouse gas (GHG) emissions** — this is a core mandatory metric; Scope 3 can be phased in for some companies
- GHG removal and storage activities
- GHG intensity metrics
- Energy consumption and mix (renewable vs. non-renewable)
- Climate-related targets, including whether aligned with science-based targets
- Potential financial effects of material climate risks

Note: ESRS E1 includes some of the most prescriptive quantitative requirements in the entire framework, particularly around GHG accounting methodology (aligned with GHG Protocol).

---

### ESRS S1 — Own Workforce

This standard covers your employees and non-employee workers (e.g., contractors working under your direction).

**Governance and Strategy**
- Policies related to your own workforce (e.g., fair wages, health and safety, non-discrimination, working conditions)
- How you engage with your own workforce on material topics

**Impact, Risk and Opportunity Management**
- Processes for identifying and managing impacts on your own workforce
- Remediation processes for identified negative impacts
- Channels for workers to raise concerns

**Metrics and Targets**
- **Headcount data**: total workforce broken down by gender, country, employment type (permanent/temporary, full-time/part-time), non-employees
- **Health and safety**: work-related injuries, ill health, and fatalities (rates and absolute numbers)
- **Work-related health and safety management system** coverage
- **Remuneration**: pay gap metrics (gender pay gap), ratio of CEO pay to median employee pay
- Collective bargaining coverage
- Training and skills development metrics
- Diversity metrics (particularly gender across governance and management levels)
- Cases of discrimination, harassment, and outcomes

Several S1 metrics are mandatory even if the underlying sub-topic might have limited materiality; others apply only where the relevant sub-topic (e.g., remuneration adequacy, work-life balance) is material.

---

### ESRS G1 — Business Conduct

This standard covers ethics, anti-corruption, anti-bribery, lobbying, supplier relationships, and payment practices.

**Governance and Strategy**
- Corporate culture and conduct policies (code of conduct, anti-corruption and anti-bribery policies)
- Whistleblower/speak-up mechanisms
- Political engagement and lobbying activities
- Protection of whistleblowers

**Impact, Risk and Opportunity Management**
- Processes for preventing and detecting corruption and bribery
- Management of relationships with suppliers and payment terms

**Metrics and Targets**
- Confirmed incidents of corruption or bribery
- Legal actions related to anti-competitive behaviour
- Payment practices: average payment period to suppliers, proportion of payments made beyond agreed terms (particularly relevant for SME suppliers)
- Fines and settlements for ethical violations

---

## 3. Non-Material Topics — What You Still Need to Do

Even though Pollution (E2), Water (E3), Biodiversity (E4), Circular Economy (E5), Value Chain Workers (S2), Communities (S3), and Consumers/End-users (S4) are non-material, CSRD/ESRS imposes the following obligations:

1. **Document your assessment**: ESRS 2 requires you to describe the process and outcome of your double materiality assessment, including the rationale for exclusions.

2. **Disclose that these topics were assessed and found non-material**: Your sustainability statement should include a clear statement noting which ESRS topics were assessed and why they did not meet the materiality threshold.

3. **Revisit periodically**: Materiality is not static. You should reassess each reporting period. Changes in business model, supply chains, or operating context could make currently non-material topics material in the future.

4. **Sector-specific standards**: If sector-specific ESRS are finalized and applicable to your sector, they may require certain disclosures regardless of your materiality outcome — monitor EFRAG's work on sector standards.

5. **Phased-in requirements**: Some E1 and S1 metrics have transitional provisions allowing phase-in over the first 1–3 years of reporting. Check ESRS Appendix C for the specific list of phase-in reliefs.

---

## 4. Summary Table

| Standard | Applicability | Key Obligation |
|---|---|---|
| ESRS 1 | Always | Governs how you report — no disclosure requirements per se |
| ESRS 2 | Always mandatory | Full general disclosures including governance, strategy, materiality process |
| ESRS E1 | Material — full disclosure required | GHG emissions, transition plan, climate risks, energy use, targets |
| ESRS E2 (Pollution) | Non-material — no topical disclosures | Document why non-material |
| ESRS E3 (Water) | Non-material — no topical disclosures | Document why non-material |
| ESRS E4 (Biodiversity) | Non-material — no topical disclosures | Document why non-material |
| ESRS E5 (Circular Economy) | Non-material — no topical disclosures | Document why non-material |
| ESRS S1 | Material — full disclosure required | Workforce data, H&S, pay gap, diversity, training, remediation |
| ESRS S2 (Value Chain Workers) | Non-material — no topical disclosures | Document why non-material |
| ESRS S3 (Communities) | Non-material — no topical disclosures | Document why non-material |
| ESRS S4 (Consumers) | Non-material — no topical disclosures | Document why non-material |
| ESRS G1 | Material — full disclosure required | Anti-corruption, whistleblowing, payment practices, lobbying |

---

## 5. Practical Considerations

- **Connectivity to financial statements**: ESRS requires disclosures to be connected to your financial reporting where sustainability risks and impacts have financial implications. This is particularly relevant for E1 climate risks.

- **Value chain**: Even though S2–S4 are non-material, ESRS E1 and S1 may still require some consideration of your upstream supply chain (particularly for Scope 3 emissions under E1).

- **Assurance**: CSRD requires limited assurance of the sustainability statement (moving toward reasonable assurance over time). Your disclosures must be audit-ready.

- **Location**: The sustainability statement must be included in the management report (directors' report) as a dedicated section — it cannot be a standalone document.

- **Digital tagging**: Disclosures must be tagged using the European Single Electronic Format (ESEF) with the ESRS XBRL taxonomy once the taxonomy is finalized and applicable to your reporting period.

# GRI + TCFD to CSRD/ESRS Transition: Gap Assessment

## Executive Summary

If you already report under GRI Standards and publish a TCFD report, you have a meaningful head start — but you should expect **moderate-to-significant incremental work** to reach full CSRD/ESRS compliance. The good news: GRI and TCFD together cover a large portion of the climate and social disclosures required by ESRS. The challenge lies in CSRD's mandatory legal structure, its double materiality requirement, extensive governance disclosures, value chain obligations, digital tagging, and third-party assurance — none of which GRI or TCFD mandates.

A realistic estimate for a large company with mature GRI/TCFD reporting: **12–18 months of structured implementation work** before first reporting, assuming you run it in parallel with business-as-usual ESG reporting.

---

## What GRI and TCFD Give You (Your Starting Assets)

**From GRI Standards:**
- A materiality-assessed topic structure that maps broadly to ESRS topical standards (E1–E5, S1–S4, G1)
- Existing data collection processes for many quantitative disclosures (GHG, energy, water, waste, workforce metrics)
- Stakeholder engagement methodology
- Narrative disclosures on policies, targets, and management approaches

**From TCFD:**
- Climate-related governance disclosures (board and management roles) — directly useful for ESRS E1 and ESRS 2 GOV disclosures
- Climate risk scenario analysis (physical and transition risks) — maps to ESRS E1 physical and transition risk disclosures
- Metrics and targets for GHG emissions (Scope 1, 2, and likely Scope 3 at category level)
- Strategy disclosures on climate resilience

**GRI interoperability:** ESRS 1 Appendix C explicitly maps ESRS datapoints to GRI disclosures. GRI reporters can use this mapping to identify existing disclosures that already satisfy ESRS requirements, rather than starting from scratch.

**TCFD interoperability:** ESRS E1 incorporates TCFD recommendations directly. If your TCFD report covers governance, strategy, risk management, and metrics/targets for climate, you have the core architecture for ESRS E1.

---

## Gap Assessment Table

| ESRS Area | Current State (GRI + TCFD) | Gap | Priority | Recommended Action |
|-----------|---------------------------|-----|----------|--------------------|
| **ESRS 2 — Double Materiality Assessment (DMA)** | GRI uses impact materiality; TCFD uses financial materiality | GRI only covers one lens; no formal combined DMA process exists | **Critical** | Conduct a formal DMA integrating both impact and financial materiality per ESRS 1 paras. 45–56; document and disclose the process under SBM-3 |
| **ESRS 2 — Governance (GOV-1 to GOV-5)** | TCFD covers board/management climate roles; GRI covers some governance topics | GOV disclosures are broader than TCFD: must cover ALL sustainability topics, incentive schemes (GOV-3), internal controls for sustainability (GOV-5), and due diligence statement (GOV-4) | **High** | Map existing TCFD governance narrative to GOV-1/GOV-2; build out GOV-3 (incentives), GOV-4 (due diligence linkage), GOV-5 (risk controls) for all ESRS topics |
| **ESRS 2 — Strategy & Business Model (SBM-1, SBM-2, SBM-3)** | GRI partial; TCFD partial for climate | SBM-1 requires value chain description; SBM-2 requires documented stakeholder engagement per topic; SBM-3 requires full IRO disclosure tied to DMA | **High** | Expand strategy disclosures beyond climate; formalize stakeholder engagement documentation; link DMA outputs to SBM-3 |
| **ESRS E1 — Climate Change** | Strong: TCFD covers scenario analysis, governance, strategy, metrics/targets; GRI covers Scope 1/2/3 | Likely gaps: Scope 3 all 15 categories (if not already complete), GHG intensity per net revenue, EU Taxonomy alignment disclosures, transition plan with financial planning (capex/opex for decarbonisation), locked-in assets | **High** | Complete Scope 3 category inventory; prepare EU Taxonomy eligibility and alignment calculation; draft ESRS-compliant transition plan per ESRS E1-1 |
| **ESRS E2 — Pollution** | GRI 305 (emissions) covers some; may have limited pollution disclosures | Likely a significant gap unless you are in a sector with heavy pollution relevance; specific ESRS E2 datapoints (substances of concern, pollution incidents, PRTR-linked disclosures) are more granular than typical GRI | **Medium** | Run DMA to determine materiality; if material, build data collection for air/water/soil pollutants and substances of concern |
| **ESRS E3 — Water & Marine Resources** | GRI 303 covers water withdrawal and consumption | GRI 303 aligns reasonably well; gap is likely in marine-specific disclosures and water stress area disaggregation | **Medium** | Cross-reference GRI 303 data to ESRS E3 datapoints; add water stress area breakdown if not already present |
| **ESRS E4 — Biodiversity & Ecosystems** | GRI 304 (biodiversity) is typically thin in most GRI reports | This is commonly the largest environmental gap for GRI reporters; ESRS E4 requires site-level biodiversity impact assessment, ecosystem services assessment, targets per the Kunming-Montreal framework | **High** | Assess biodiversity materiality in DMA; if material, engage specialist support for site-level assessment and ecosystem services mapping |
| **ESRS E5 — Resource Use & Circular Economy** | GRI 301 (materials), GRI 306 (waste) provide a base | ESRS E5 requires circular economy strategy disclosure and material flow data that goes beyond typical GRI waste disclosures | **Medium** | Map GRI 301/306 disclosures to ESRS E5 datapoints; identify gaps in circular economy strategy narrative |
| **ESRS S1 — Own Workforce** | GRI 400-series covers many workforce topics | Key gaps: gender pay gap disclosure (aligned with EU Pay Transparency Directive), collective bargaining coverage %, health & safety management system coverage, and more granular employee breakdown by country (for large companies) | **High** | Conduct ESRS S1 datapoint mapping against existing GRI 400-series data; build gender pay gap calculation and reporting process |
| **ESRS S2 — Workers in Value Chain** | GRI 408/409 cover some supply chain labour issues | ESRS S2 requires systematic value chain labour rights assessment — typically far more granular than GRI practice; data availability from suppliers is a common pain point | **High** | Map tier-1 supplier coverage; establish value chain data collection programme; use sector averages/proxies where direct data unavailable (disclose methodology) |
| **ESRS S3 — Affected Communities** | GRI 413 covers community impact | Typically a gap in formalised community IRO assessment and documentation tied to DMA | **Medium** | Assess materiality in DMA; if material, formalise community engagement and impact documentation |
| **ESRS S4 — Consumers & End-Users** | GRI 416/417/418 cover product safety and data | ESRS S4 requires consumer-related IRO process; may be covered adequately by GRI if disclosures are current | **Low–Medium** | Cross-reference existing GRI 416–418 disclosures to ESRS S4 datapoints |
| **ESRS G1 — Business Conduct** | GRI 205 (anti-corruption), GRI 206 (anti-competitive behaviour) provide a base | ESRS G1 adds payment practices (average payment days to suppliers), lobbying disclosure, and political contributions — often not in GRI reports | **Medium** | Add payment practices data collection; review lobbying and political contribution disclosures |
| **Reporting Location (Management Report)** | GRI report is typically standalone; TCFD may be in annual report | CSRD requires sustainability information in the management report (Accounting Directive Art. 19a), not as a standalone document | **High** | Work with legal/finance to integrate sustainability section into the annual management report; this requires coordination with auditors |
| **Digital Tagging (XBRL/iXBRL)** | Not applicable under GRI or TCFD | Full new requirement; all sustainability disclosures must be tagged using ESEF taxonomy (Commission sustainability taxonomy pending) | **High** | Engage reporting technology provider or work with finance team already using ESEF for financial statements; allow 3–6 months for taxonomy mapping and tagging setup |
| **Third-Party Assurance** | GRI assurance optional (many companies obtain it); TCFD no assurance requirement | CSRD requires limited assurance from statutory auditor or IASP from first reporting year (Art. 26a); this is a legal obligation, not optional | **Critical** | Engage statutory auditor or IASP now — assurance scope, readiness, and fees need to be agreed well before year-end; if you have GRI assurance, your provider may have a pathway |
| **Value Chain Data Collection** | GRI encourages but does not mandate systematic value chain data | CSRD requires value chain impacts, risks, and opportunities to be assessed where material; data from suppliers and downstream partners is needed | **High** | Run value chain mapping exercise tied to DMA; build supplier data requests into procurement contracts; begin with material topics only |

---

## Top Gaps to Prioritise

### 1. Double Materiality Assessment — Start Immediately
Your GRI materiality process covers only impact materiality. TCFD covers financial materiality for climate only. CSRD requires a combined DMA across all ESRS topics. This is the **foundation of your entire CSRD report** — without it, you cannot determine which topical standards apply or which datapoints to collect. Begin the DMA process at least 12 months before your first reporting year.

### 2. Assurance Readiness — Engage Your Auditor Now
Limited assurance is legally required from day one. Many statutory auditors are developing CSRD assurance methodologies. Engaging early allows you to understand what evidence they will require, which will drive your data governance and documentation approach. If you currently obtain GRI assurance, your existing provider may be well-positioned to extend scope.

### 3. Scope 3 Completeness and Value Chain Data
Most GRI reporters disclose Scope 3 selectively. ESRS E1 requires all 15 Scope 3 categories if climate is material, with clear disclosure of estimation methodology. Value chain social data (ESRS S2) is also a common and significant gap, requiring supplier engagement programmes.

### 4. Biodiversity (ESRS E4)
This is the most frequent "surprise" gap for GRI reporters. Unless you have already aligned with TNFD or published detailed biodiversity disclosures, expect to build this largely from scratch if it is material after your DMA.

### 5. Governance Integration and Incentives (ESRS 2 GOV)
TCFD governance disclosures cover climate. ESRS 2 GOV requires board and management oversight of all material sustainability topics, disclosure of sustainability-linked incentive schemes, and internal controls over sustainability reporting — significantly broader than most existing frameworks require.

### 6. Management Report Integration and XBRL Tagging
These are structural/legal requirements with no equivalent in GRI or TCFD. They require coordination across finance, legal, IT, and sustainability teams and typically take 6–12 months to implement properly.

---

## Realistic Work Estimate

| Phase | Timeline | Key Activities |
|-------|----------|---------------|
| **Scoping & DMA** | Months 1–4 | Confirm CSRD applicability, conduct DMA, identify material ESRS topics |
| **Gap Analysis** | Months 3–5 | Map existing GRI/TCFD disclosures to ESRS datapoints topic by topic |
| **Data Architecture** | Months 4–9 | Build data collection processes for gaps (value chain, pay gap, biodiversity, Scope 3 completeness) |
| **Governance & Policy** | Months 5–8 | Establish board oversight processes, sustainability governance documentation, due diligence statement |
| **Reporting Integration** | Months 7–11 | Draft ESRS disclosures, integrate into management report structure, prepare XBRL tagging |
| **Assurance Preparation** | Months 6–12 | Engage auditor, build evidence trail, conduct pre-assurance readiness review |
| **First CSRD Report Published** | End of Year 1 or 2 (depending on your scope category) | Full ESRS-compliant report with limited assurance |

---

## Key References

- **ESRS 1, Appendix C** — GRI-to-ESRS mapping (use this to identify which existing GRI disclosures satisfy ESRS datapoints)
- **ESRS 2, GOV-1 to GOV-5, SBM-1 to SBM-3, IRO-1** — mandatory for all in-scope companies regardless of DMA
- **ESRS E1** — incorporates TCFD recommendations; TCFD reporters have a strong foundation but gaps exist on EU Taxonomy, transition plan financial detail, and Scope 3 completeness
- **Art. 19a CSRD (Directive 2022/2464)** — management report location requirement
- **Art. 26a CSRD** — assurance obligation
- **Commission Delegated Regulation (EU) 2023/2772** — ESRS standards text

**Note on the Omnibus Proposal (February 2025):** The European Commission has proposed simplifications that may narrow the scope of CSRD and reduce mandatory datapoints, particularly for the second wave of reporters. Monitor the legislative status of this proposal, as it may affect which ESRS topical standards are mandatory versus voluntary for your reporting category. However, the core DMA, ESRS 2 general disclosures, assurance, and management report location requirements are unlikely to be removed.

# Transitioning from GRI Standards and TCFD to CSRD/ESRS: Gap Analysis and Effort Assessment

## Executive Summary

If your organization already reports under GRI Standards and TCFD, you have a meaningful head start on CSRD/ESRS compliance. However, transitioning is not a simple mapping exercise. CSRD/ESRS introduces a more prescriptive, auditable, and legally binding framework with significant new requirements that neither GRI nor TCFD fully address. Expect a moderate-to-substantial effort depending on your organization's size, sector, and current reporting maturity.

---

## What You Already Have: Your Starting Advantages

### From GRI Standards
GRI provides a strong foundation for the social and governance dimensions of ESRS. Key areas of alignment include:

- **Stakeholder engagement processes** — GRI's materiality approach involves stakeholder dialogue, which partially supports ESRS's double materiality requirements.
- **Social disclosures** — GRI 400-series (Labor, Human Rights, Society) maps reasonably well to ESRS S1 (Own Workforce), S2 (Workers in the Value Chain), S3 (Affected Communities), and S4 (Consumers and End-users).
- **Governance disclosures** — GRI 2 (General Disclosures) overlaps with ESRS G1 (Business Conduct) and ESRS 2 governance disclosures.
- **Environmental topic coverage** — GRI 300-series (Energy, Water, Emissions, Waste, Biodiversity) provides baseline data that feeds into ESRS E1–E5.
- **Reporting infrastructure** — Existing data collection systems, internal controls, and reporting workflows can be adapted rather than built from scratch.

### From TCFD
TCFD was the primary precursor to ESRS E1 (Climate Change) and provides strong alignment for:

- **Climate governance** — Board and management oversight of climate risk maps directly to ESRS 2 GOV disclosures.
- **Risk and opportunity identification** — TCFD's risk/opportunity framework aligns with ESRS E1's physical and transition risk disclosures.
- **Scenario analysis** — If you have conducted TCFD scenario analysis, this work is directly reusable for ESRS E1 requirements on climate scenario analysis.
- **Metrics and targets** — Scope 1, 2, and 3 GHG emissions, and climate-related financial metrics, are required in both frameworks.

---

## Key Gaps: Where Significant Work Is Still Required

### 1. Double Materiality Assessment (Critical Gap)
**Effort: High**

This is the single most significant structural gap. ESRS requires a rigorous **double materiality assessment** that evaluates:
- **Impact materiality**: How does your company affect people and the environment (positive and negative, actual and potential, across the value chain)?
- **Financial materiality**: How do sustainability matters affect your company's financial position and performance?

GRI uses a single-axis stakeholder-informed materiality process. TCFD uses financial materiality only. ESRS requires both simultaneously and with documented, auditable methodology. This assessment determines which ESRS topic standards apply to you and must be defensible to auditors. Most organizations undergoing CSRD transition find this to be their most time-consuming workload.

### 2. Value Chain Disclosures (Significant Gap)
**Effort: High**

ESRS extends disclosure requirements far into the upstream and downstream value chain — suppliers, contractors, distribution partners, and end customers. GRI encourages but does not mandate this depth. TCFD is primarily focused on the reporting entity itself. You will likely need:
- Supplier data collection programs or surveys
- Contractual requirements with key suppliers
- Estimation methodologies where direct data is unavailable
- Governance frameworks for value chain oversight

### 3. Biodiversity and Ecosystems — ESRS E4 (Significant Gap)
**Effort: Medium to High**

Unless you have voluntarily adopted TNFD or similar frameworks, biodiversity is likely a major gap. ESRS E4 requires:
- Site-specific assessments of biodiversity-sensitive locations
- Metrics on land use, species impact, and ecosystem degradation
- Alignment with EU Biodiversity Strategy targets

GRI 304 (Biodiversity) exists but is rarely reported with the granularity ESRS E4 demands. TCFD does not address biodiversity.

### 4. Resource Use and Circular Economy — ESRS E5 (Moderate Gap)
**Effort: Medium**

ESRS E5 on resource use and circular economy goes beyond what GRI 301 (Materials) and GRI 306 (Waste) typically cover, requiring:
- Inflows and outflows of resources tracked against circular economy principles
- Products and materials designed for reuse, repair, and recyclability
- Alignment with EU Circular Economy Action Plan targets

### 5. Own Workforce Detail — ESRS S1 (Moderate Gap)
**Effort: Medium**

ESRS S1 is substantially more granular than most GRI reporters achieve in practice. New requirements include:
- Detailed breakdown of workforce by employment type, contract type, gender, age, and region
- Living wage assessments and coverage rates
- More specific health and safety metrics
- Collective bargaining and freedom of association data at a greater level of specificity
- Disclosures on non-employee workers (contractors, agency workers)

### 6. Narrative and Policy Disclosures (Moderate Gap)
**Effort: Medium**

Each ESRS topic standard requires a structured set of disclosures covering:
- **Policies** in place addressing the topic
- **Actions and resources** allocated
- **Targets** set and progress against them
- **Metrics** (both mandatory and entity-specific)

GRI reporters often have partial versions of these, but ESRS requires them to follow a specific, mandatory structure. Retrofitting existing narrative disclosures to this architecture takes significant editorial and governance effort.

### 7. Assurance Readiness (Significant Gap for Most)
**Effort: Medium to High**

CSRD mandates **limited assurance** from the outset, with a trajectory toward **reasonable assurance**. This requires:
- Internal controls over sustainability reporting comparable to financial reporting controls
- Audit trails and data documentation
- Cross-functional governance (sustainability, finance, legal, operations)
- Engagement with external auditors who will scrutinize not just disclosures but data processes

Most GRI and TCFD reporters have not built sustainability data infrastructure to this standard. This is often the area that requires the most investment in systems and process redesign.

### 8. ESRS 2 — General Disclosures (Moderate Gap)
**Effort: Medium**

ESRS 2 is mandatory for all in-scope entities regardless of double materiality outcomes. It requires structured disclosures on:
- Governance bodies and their sustainability roles
- Management of sustainability-related impacts, risks, and opportunities
- Strategy and business model integration
- Stakeholder engagement processes (more detailed than GRI's approach)
- The double materiality assessment methodology itself

While GRI 2 and TCFD governance disclosures cover some of this ground, ESRS 2 has a more prescriptive format that will require dedicated structuring work.

---

## Areas Where Gaps Are Minimal

| Topic | Reason |
|-------|--------|
| Climate governance (ESRS E1 GOV) | Strong TCFD coverage |
| Scope 1 and 2 GHG emissions | Covered by both GRI 305 and TCFD |
| Transition risks and opportunities | TCFD scenario analysis directly applicable |
| Labor practices (partial) | GRI 400-series provides strong base |
| Anti-corruption and business ethics | GRI 205/206 maps well to ESRS G1 |
| Water and effluents | GRI 303 provides reasonable base for ESRS E3 |

---

## Effort Estimation by Phase

| Phase | Description | Estimated Effort |
|-------|-------------|-----------------|
| **Double Materiality Assessment** | Methodology design, stakeholder engagement, topic prioritization | 3–6 months |
| **Gap Analysis and Mapping** | Detailed mapping of existing GRI/TCFD disclosures to ESRS requirements | 1–2 months |
| **Data Architecture** | Systems and process design for new data points (value chain, biodiversity, circular economy) | 6–12 months |
| **Policy and Governance Updates** | Board-level oversight structures, internal policies aligned to ESRS topics | 3–6 months |
| **Narrative Restructuring** | Reformatting existing disclosures to ESRS architecture | 2–4 months |
| **Assurance Preparation** | Internal controls, documentation, pre-assurance readiness review | 3–6 months |
| **First Report Production** | Drafting, review, and finalization | 3–4 months |

**Total indicative timeline: 12–24 months** for a well-resourced organization, depending on scope and starting maturity. Organizations with strong GRI and TCFD programs are typically at the lower end of this range.

---

## Key Recommendations

1. **Start with the double materiality assessment.** Everything else in ESRS is conditioned on its outputs. Invest in a rigorous, documented methodology early.

2. **Do a structured GRI-to-ESRS mapping exercise.** Many GRI disclosures have direct or partial equivalents in ESRS. Identify what you can reuse and what needs enhancement versus what must be built from scratch.

3. **Treat TCFD as your ESRS E1 foundation.** Your climate scenario analysis, risk identification, and metrics work is directly transferable — focus on filling gaps (e.g., physical risk at asset level, Scope 3 completeness, transition plan requirements under ESRS E1).

4. **Prioritize value chain data collection.** This typically has the longest lead time and requires external partner engagement. Start scoping supplier data programs early.

5. **Engage your assurance provider early.** Understanding what your auditors will expect shapes how you build data processes. Early engagement prevents costly rework.

6. **Assess ESRS E4 (Biodiversity) carefully.** If your double materiality assessment flags biodiversity as material, this is likely your largest net-new disclosure workload.

7. **Invest in data infrastructure.** CSRD-grade reporting requires sustainability data to be managed with the same rigor as financial data. This often means upgrading ESG data management systems.

---

## Summary Assessment

| Dimension | Assessment |
|-----------|-----------|
| Overall transition effort | Moderate to Substantial |
| Biggest single gap | Double Materiality Assessment methodology |
| Largest data gap | Value chain and biodiversity data |
| Largest structural gap | Assurance-ready internal controls |
| Biggest advantage from GRI | Social and governance topic coverage |
| Biggest advantage from TCFD | Climate risk, governance, and scenario analysis |
| Estimated timeline | 12–24 months to first compliant report |

Organizations that have invested seriously in GRI and TCFD reporting are meaningfully better positioned than those starting from scratch, but should not underestimate the structural and legal shift that CSRD represents. The combination of mandatory assurance, double materiality, and the sheer scope of ESRS topic standards makes this a significant compliance program, not merely a reporting reformat.

# CSRD Scope Analysis: Non-EU Company with EU Subsidiaries

## Your Situation at a Glance

**Yes, CSRD applies to your group.** As a US-headquartered technology company with €200M in EU net turnover and qualifying EU subsidiaries, you fall within the CSRD's third-country undertaking provisions. Your first mandatory reporting year is **FY 2028**, with the report published in **2029**.

---

## Scope / Threshold Analysis

### Step 1: Non-EU Company Threshold Test (Art. 40a CSRD)

CSRD Art. 40a (transposed from Directive 2013/34/EU as amended) extends the directive's reach to non-EU parent undertakings that generate significant EU revenue and have qualifying EU-based entities.

| Criterion | Threshold | Your Position | Met? |
|-----------|-----------|---------------|------|
| Net turnover generated in the EU | > €150M | €200M combined from German and French subsidiaries | **YES** |
| Qualifying EU subsidiary (large company OR listed) | ≥ 1 large EU subsidiary or branch with >€40M EU turnover | German subsidiary: 600 employees (see Step 2) | **YES** |

**Verdict: Both criteria are satisfied. CSRD applies to your group.**

### Step 2: German Subsidiary — Large Company Test (Art. 3(4) Directive 2013/34/EU)

A company qualifies as "large" under EU law if it exceeds **at least 2 of the following 3 thresholds**:

| Size Criterion | Threshold | German Subsidiary |
|----------------|-----------|-------------------|
| Number of employees | > 250 | **600** — Exceeds |
| Net turnover | > €40M | Not stated, but likely exceeded given total EU revenue of €200M |
| Total assets | > €20M | Not stated |

With 600 employees, the German subsidiary already exceeds one threshold definitively. Given it is part of a group generating €200M in EU revenue, it almost certainly also exceeds the €40M turnover threshold. If so, it qualifies as a **large EU subsidiary**, satisfying the second prong of the Art. 40a test.

**If the German subsidiary's standalone turnover exceeds €40M (highly probable given group revenues), it qualifies as a large company even without being listed.**

The French subsidiary further reinforces the group's EU footprint.

### Step 3: First Reporting Year

| Category | First Reporting Year | Report Published |
|----------|---------------------|-----------------|
| Non-EU companies (Art. 40a) | **FY 2028** | **2029** |

---

## What CSRD Requires from You

### Who Files the Report?

Under Art. 40a, the **EU subsidiaries themselves** (specifically, the large ones — here, the German subsidiary and potentially the French subsidiary) are obligated to publish a CSRD-compliant sustainability report. There is no option for the US parent to file a consolidated ESRS report at parent level as a substitute — the obligation sits at the EU subsidiary level unless an equivalent third-country parent report is accepted (see "Group Reporting" below).

**Practical implication:** Your German subsidiary is the primary obligated entity. If the French subsidiary also qualifies as large, it bears its own obligation.

### Reporting Standard

Non-EU company subsidiaries report under the **ESRS standards** (Commission Delegated Regulation (EU) 2023/2772) — the same standards as EU large companies. There is a sector-agnostic set of ESRS for non-EU undertakings currently being developed by EFRAG (the "ESRS for third-country undertakings"), though EU subsidiaries of non-EU groups will use the standard ESRS unless a specific equivalence decision has been made.

---

## Key Obligations — What You Need to Do

### 1. Double Materiality Assessment (DMA) — The Starting Point

Before any disclosure can be prepared, the German (and French) subsidiary must conduct a **Double Materiality Assessment** (ESRS 1, paras. 45–56). This determines which ESRS topical standards apply.

**Two lenses:**
- **Impact materiality:** Does the subsidiary's technology operations cause actual or potential impacts on people or the environment (e.g., digital waste, energy use in data centres, workforce conditions)?
- **Financial materiality:** Do sustainability factors create risks or opportunities for the subsidiary's financial performance (e.g., physical climate risk to EU offices, regulatory cost from carbon pricing)?

A topic is material if it meets **either** lens. As a technology company, the DMA will likely identify climate (energy, GHG from data centres), workforce (ESRS S1), and business conduct (ESRS G1) as highly probable material topics.

### 2. Mandatory Disclosures — ESRS 2 (All In-Scope Companies)

Regardless of DMA outcomes, **ESRS 2 General Disclosures are mandatory** for all in-scope entities. These cover:

| Disclosure | Content Required |
|------------|-----------------|
| **GOV-1** | Role of board/supervisory bodies in sustainability oversight |
| **GOV-2** | Management's role and sustainability expertise |
| **GOV-3** | Sustainability-linked incentive schemes |
| **GOV-4** | Due diligence statement (alignment with UN Guiding Principles, OECD Guidelines) |
| **GOV-5** | Risk management and internal controls for sustainability |
| **SBM-1** | Business model, strategy, and value chain description |
| **SBM-2** | Interests and views of stakeholders |
| **SBM-3** | Material impacts, risks, and opportunities (output of DMA) |
| **IRO-1** | Process for identifying and assessing material IROs |

### 3. Likely Material Topical Standards for a Technology Company

| ESRS Standard | Topic | Likely Applicability |
|---------------|-------|---------------------|
| **ESRS E1** | Climate Change | High — data centres, office energy consumption, business travel, Scope 3 supply chain emissions |
| **ESRS S1** | Own Workforce | High — 600+ employees in Germany alone; pay gap, collective bargaining, H&S, training |
| **ESRS G1** | Business Conduct | High — anti-corruption, data ethics, supplier practices |
| **ESRS E5** | Resource Use & Circular Economy | Medium — hardware lifecycle, e-waste |
| **ESRS S4** | Consumers & End-Users | Medium — data privacy, product safety obligations |
| **ESRS S2** | Workers in Value Chain | Medium — supply chain labour practices |

Note: The DMA will determine the definitive list.

### 4. Key Datapoints to Prepare (Illustrative for E1 and S1)

**ESRS E1 — Climate (if material):**
- Scope 1 GHG emissions (direct, e.g., fleet, on-site combustion)
- Scope 2 GHG emissions (electricity — both market-based and location-based)
- Scope 3 GHG emissions across all 15 categories (especially Categories 1, 3, 6, 11 for tech companies)
- Energy consumption and renewable energy share
- GHG reduction targets (Paris-aligned, 2030/2050)
- Climate transition plan (Art. 19a(2)(a))
- EU Taxonomy eligible and aligned revenue/capex/opex

**ESRS S1 — Own Workforce (if material):**
- Total headcount by gender, contract type, country
- Gender pay gap (aligned with EU Pay Transparency Directive)
- % employees covered by collective bargaining agreements
- Work-related injury rate (LTIFR) and fatalities
- Training hours per employee
- Employee turnover rate

### 5. Value Chain Reporting

CSRD requires consideration of the **upstream and downstream value chain** where material (ESRS 1). As a technology company, this means:

- **Upstream:** Hardware suppliers, cloud infrastructure partners, component manufacturers
- **Downstream:** Customer use-phase emissions (Scope 3 Category 11), end-of-life product disposal

Where supplier data is unavailable, proxy data and sector averages may be used, but the methodology and limitations must be disclosed.

### 6. Group Reporting — Can the US Parent File on Behalf of Subsidiaries?

Under Art. 19a(9) and related provisions, a subsidiary may be **exempt from its own CSRD filing** if:
- It is included in a **consolidated sustainability report** prepared by a parent undertaking, AND
- That parent's report complies with CSRD or an **equivalent standard** as determined by the European Commission

Currently, **no third-country standard has been formally declared equivalent** by the Commission. This means:
- A US parent reporting under GRI, TCFD, or SEC climate disclosure rules alone **cannot substitute** for CSRD compliance at the EU subsidiary level
- However, if the Commission declares equivalence for a US framework in the future, this option may become available

**Practical path:** The German subsidiary (and French subsidiary if large) must file their own ESRS-compliant reports unless and until equivalence is formally granted.

### 7. Report Format and Assurance Requirements

| Requirement | Details |
|-------------|---------|
| **Location** | Dedicated section of the German subsidiary's management report (Lagesbericht) — not a standalone sustainability document |
| **Digital tagging** | XBRL/iXBRL tagging required (ESEF format) per Art. 19a CSRD |
| **Third-party assurance** | **Limited assurance** required from first reporting year (Art. 26a) — by a statutory auditor (Wirtschaftsprüfer in Germany) or accredited IASP |
| **Reasonable assurance** | Phased in later (Commission review by 2028) |

---

## Timeline and Recommended Action Plan

| Year | Milestone |
|------|-----------|
| **2025–2026** | Conduct subsidiary-level Double Materiality Assessment; confirm French subsidiary size thresholds; establish group CSRD governance structure |
| **2026** | Design data collection processes for material ESRS topics; assess value chain data availability; begin Scope 3 inventory |
| **2026–2027** | Perform gap analysis against ESRS 2 and material topical standards; engage statutory auditors for assurance readiness review; implement XBRL tagging capability |
| **2027** | First dry-run / shadow reporting for FY 2027 (optional but strongly recommended); board training on sustainability governance (ESRS GOV-1/GOV-2) |
| **Early 2028** | Begin formal data collection for FY 2028 (first mandatory reporting year) |
| **2029** | Publish first CSRD-compliant sustainability report for FY 2028 |

---

## Critical Considerations and Risks

### 1. French Subsidiary Threshold Confirmation
The question does not specify the French subsidiary's employee count or standalone turnover. If the French subsidiary also qualifies as a large company (≥2 of: >250 employees, >€40M turnover, >€20M assets), it bears **its own independent CSRD obligation**. Confirm the French subsidiary's size classification immediately.

### 2. German Subsidiary Standalone Turnover
Confirm that the German subsidiary's standalone turnover exceeds €40M. While highly probable given the group's €200M EU revenue, this should be formally verified to ensure the Art. 40a trigger is met.

### 3. CSRD Omnibus Package (2025)
The European Commission proposed a simplification package in February 2025 (the "CSRD Omnibus") that may:
- Narrow the scope of companies subject to CSRD
- Reduce the number of mandatory datapoints
- Potentially raise thresholds

As of the current date (May 2026), monitor the legislative status of the Omnibus Package. The FY 2028 timeline and current ESRS obligations remain the baseline until formal changes are enacted.

### 4. German Codetermination and Works Council
The German subsidiary's 600 employees will trigger German codetermination rules (Mitbestimmungsgesetz). Any CSRD-related data collection on workforce matters (ESRS S1) should be coordinated with the **Betriebsrat (works council)**, as workforce data collection may require consultation or agreement under German labour law.

### 5. Intragroup Data Sharing
The US parent will need to consider **data governance arrangements** for sharing sustainability data between the parent and EU subsidiaries. This intersects with GDPR obligations for any personal data elements (e.g., headcount by gender, pay gap data). Ensure data transfer mechanisms are in place.

---

## Summary Verdict

| Question | Answer |
|----------|--------|
| Does CSRD apply? | **Yes** — Art. 40a applies (€200M EU turnover > €150M threshold + large EU subsidiary) |
| Who must report? | **German subsidiary** (confirmed large); confirm **French subsidiary** |
| First mandatory year? | **FY 2028** (report published 2029) |
| Reporting standard? | **Full ESRS** — ESRS 2 mandatory + topical standards based on DMA |
| Assurance required? | **Yes** — limited assurance from first year (Art. 26a) |
| Can US parent file instead? | **Not currently** — no equivalence determination for US frameworks |
| Immediate next step? | **Conduct Double Materiality Assessment** and confirm French subsidiary thresholds |

---

*Legal basis: Art. 40a CSRD (Directive (EU) 2022/2464); Art. 19a, 29a Accounting Directive 2013/34/EU as amended; ESRS 1 General Requirements (Commission Delegated Regulation (EU) 2023/2772); ESRS 2 General Disclosures.*

# CSRD Applicability for a US-Headquartered Company with EU Subsidiaries

## Summary Answer

Yes, CSRD likely applies to your situation — but the obligations fall on your EU subsidiaries, not directly on the US parent company. Based on the facts provided, your German subsidiary almost certainly qualifies as a large undertaking under CSRD and will be required to publish a sustainability report. There is also a potential obligation at the consolidated (group) level if the EU group as a whole meets the thresholds.

---

## 1. CSRD Background and Scope

The Corporate Sustainability Reporting Directive (CSRD), adopted in December 2022 and effective from January 2023, significantly expands the EU's non-financial reporting requirements. It replaces the Non-Financial Reporting Directive (NFRD) and is implemented into national law by EU member states (Germany and France have both transposed it).

CSRD applies to:
- Large EU companies (including subsidiaries of non-EU groups)
- Non-EU parent companies with significant EU activity (via a separate "third-country undertaking" rule)
- EU-listed SMEs (with a later opt-out period)

---

## 2. Does CSRD Apply to You as a Non-EU Company?

### Direct Obligation on the US Parent (Third-Country Undertaking Rule)

Under Article 40 of CSRD (the "third-country undertaking" provision), a non-EU parent company is directly subject to CSRD reporting if it meets **both** of the following thresholds:

- **Net turnover in the EU exceeds €150 million** for each of the last two consecutive financial years, AND
- The company has either:
  - At least one EU subsidiary that is a large undertaking or a listed SME, OR
  - At least one EU branch generating more than €40 million net turnover

**Your situation:** With €200M in combined EU revenue, you exceed the €150M EU turnover threshold. You also have at least one EU subsidiary (the German subsidiary with 600 employees), which, as shown below, qualifies as a large undertaking.

**Conclusion:** The US parent company is subject to the third-country undertaking rule and must publish a group-level sustainability report covering EU operations. This report must be filed by a designated EU subsidiary (typically the largest one, in your case likely the German subsidiary) and must comply with the European Sustainability Reporting Standards (ESRS) or an equivalent standard recognized by the European Commission.

**Timing for third-country undertakings:** The obligation for non-EU parent companies applies for financial years starting on or after **1 January 2028** (with first reports due in 2029), under the current CSRD timeline. Note that the EU has proposed and in some cases adopted deferrals — you should confirm the current timeline as it may have been adjusted.

---

### Obligation on the German Subsidiary (Large Undertaking Rule)

Independently of the parent company's obligations, each EU subsidiary must be assessed against the CSRD thresholds for large undertakings. A company qualifies as a "large undertaking" under EU Accounting Directive criteria if it exceeds **at least two of the three** following thresholds:

| Criterion | Threshold |
|---|---|
| Balance sheet total | > €25 million |
| Net turnover | > €50 million |
| Average number of employees | > 250 |

**Your German subsidiary:**
- Employees: 600 (exceeds the 250 threshold)
- Revenue: The combined EU revenue is €200M across Germany and France. Even if split, it is highly likely the German subsidiary alone exceeds €50M net turnover given the scale of operations.
- Balance sheet: Not stated, but a technology company with 600 employees and >€50M revenue would typically exceed €25M in balance sheet total.

**Conclusion:** The German subsidiary almost certainly meets two or more thresholds and qualifies as a large undertaking under CSRD. It is therefore independently required to report under CSRD.

**Timing for large undertakings:** For companies that were not previously subject to NFRD (non-public-interest entities), the obligation applies for financial years starting on or after **1 January 2025** (with first reports due in 2026). However, given recent EU "Omnibus" simplification proposals in early 2025, this timeline may have been deferred — confirm the current applicable dates.

**French subsidiary:** Similarly, the French subsidiary should be assessed against the same thresholds independently.

---

## 3. What Do You Need to Do?

### Step 1: Confirm Subsidiary-Level Thresholds

- Obtain the precise revenue, balance sheet, and headcount figures for both the German and French subsidiaries separately.
- Determine whether each subsidiary independently meets at least two of the three large undertaking thresholds.
- If both subsidiaries qualify, each may need its own CSRD-compliant sustainability report (unless a consolidated report at the EU sub-group level is permitted and elected).

### Step 2: Assess the Third-Country Undertaking Obligation

- Confirm that combined EU net turnover has exceeded €150M for each of the past two consecutive financial years.
- Identify which EU subsidiary will be designated to file the group sustainability report on behalf of the US parent.
- Track the third-country undertaking reporting timeline (currently financial years from 1 January 2028).

### Step 3: Determine Reporting Structure

You have two main structural options:

**Option A — Subsidiary-Level Reports Only**
Each qualifying subsidiary reports individually. This is simpler but may result in duplicative effort and does not satisfy the third-country undertaking obligation at the parent level.

**Option B — Consolidated EU Sub-Group Report**
A designated EU subsidiary (e.g., the German subsidiary) publishes a consolidated sustainability report covering all EU subsidiaries. This can satisfy both the large undertaking obligation and (from 2028) the third-country undertaking obligation, provided the report meets the required standards.

### Step 4: Align with European Sustainability Reporting Standards (ESRS)

CSRD reports must follow the ESRS, developed by EFRAG (European Financial Reporting Advisory Group). Key ESRS requirements include:

- **Double materiality assessment:** Identify sustainability topics that are material both from a financial perspective (how ESG issues affect the company) and an impact perspective (how the company affects people and the environment).
- **Mandatory disclosures:** Certain general disclosures (ESRS 2) are mandatory for all reporting entities.
- **Topical standards:** Additional disclosures on climate (ESRS E1), pollution, biodiversity, water, workers, affected communities, business conduct, and governance — required based on materiality assessment outcomes.
- **Value chain disclosures:** You must report on sustainability matters across your upstream and downstream value chain where material.

### Step 5: Third-Party Assurance

CSRD requires **limited assurance** on sustainability reports from an independent auditor, with a pathway to reasonable assurance in future years. Engage your statutory auditor or an accredited third-party assurance provider early.

### Step 6: Integration with Annual Report

CSRD requires the sustainability report to be published as a dedicated section of the management report (annual report) — it cannot be a standalone document separate from the financial reporting package.

### Step 7: XBRL Tagging

Sustainability disclosures must be tagged in XBRL (iXBRL) format using the ESRS taxonomy to enable machine-readable reporting and submission via the European Single Electronic Format (ESEF).

### Step 8: Governance and Data Infrastructure

- Appoint a CSRD project owner at the subsidiary level (and group level for the parent).
- Map data collection responsibilities across business units: HR, operations, procurement, finance, legal.
- Implement a sustainability data management system capable of collecting and auditing ESG metrics.
- Update board-level governance to include oversight of sustainability reporting.

---

## 4. Key Deadlines (as of Knowledge Cutoff — Verify for Updates)

| Entity Type | Reporting for FY | First Report Due |
|---|---|---|
| Large EU undertakings (non-NFRD) | FY 2025 | 2026 |
| Third-country undertakings (non-EU parents) | FY 2028 | 2029 |

**Important caveat:** The European Commission launched an "Omnibus" simplification package in early 2025 that proposed deferring CSRD obligations for certain companies by two years and narrowing scope. As of mid-2025, legislative negotiations were ongoing. You must verify the current applicable timeline with EU legal counsel or by checking the latest Official Journal of the EU.

---

## 5. Practical Recommendations

1. **Engage EU legal counsel** in Germany and France immediately to confirm national transposition specifics and any local regulatory guidance.
2. **Conduct a double materiality assessment** as the foundation for all ESRS disclosures — this is time-consuming and should begin 12–18 months before the first report is due.
3. **Assess whether the ESRS or an equivalent standard** (e.g., GRI, if recognized by the Commission) will be used for the third-country undertaking report.
4. **Coordinate reporting across subsidiaries** to avoid inconsistent disclosures and reduce duplication.
5. **Engage your auditor early** on assurance scope, methodology, and readiness requirements.
6. **Monitor legislative developments** — the Omnibus package may materially change your obligations and timelines.

---

## Conclusion

CSRD applies to your organization in two ways: (1) your German subsidiary is independently required to report as a large EU undertaking, and likely your French subsidiary as well; and (2) the US parent company is subject to the third-country undertaking rule given €200M in EU revenue and the presence of large EU subsidiaries. The immediate compliance priority is preparing the German (and potentially French) subsidiary for their large undertaking reporting obligations. Planning for the parent-level consolidated report should begin now given the complexity of ESRS implementation.

# CIS Controls v8: Implementation Group Scoping for a 75-Person Accounting Firm

---

## 1. Organization Profile

| Attribute | Your Organization |
|-----------|------------------|
| **Size** | 75 employees |
| **Industry** | Accounting / Professional Services |
| **IT Staffing** | 1 part-time IT generalist |
| **Data Sensitivity** | High — client financial and tax data (PII, financial records) |
| **Technology Stack** | Cloud-based accounting software, Microsoft 365 |
| **Prior Security Assessments** | None |
| **Regulatory Exposure** | IRS Safeguards Program (if handling tax data), state CPA board requirements, potentially FTC Safeguards Rule |

---

## 2. Implementation Group Determination

### Recommended IG: **IG2 (with immediate IG1 foundation)**

**Rationale:**

You sit at the upper boundary of IG1 and clearly cross into **IG2** based on the following criteria:

| IG Criterion | Your Situation |
|---|---|
| **Data sensitivity** | You process client financial and tax data — this is highly sensitive data that, if compromised, would materially harm your clients and expose your firm to liability. This is the defining IG2 signal. |
| **IT capability** | One part-time IT person is limited, but you do have *someone responsible for managing and protecting IT* — the IG2 criterion is met. IG1 is specifically for organizations with *no dedicated IT function*. |
| **Operational impact** | A breach or extended outage would significantly impact client service delivery and could trigger regulatory reporting obligations. You can withstand *some* outage, but not prolonged disruption. |
| **Commercial off-the-shelf tools** | Your stack (Microsoft 365, cloud accounting software) is commercially supported — consistent with both IG1 and IG2. |
| **Regulatory oversight** | Tax data handling brings IRS and FTC Safeguards Rule exposure. If you have more than 5,000 customer records, the FTC Safeguards Rule (16 CFR Part 314) mandates a formal written information security program — directly driving IG2 controls. |

**You are not IG3** because you do not employ dedicated security experts, you are not subject to rigorous regulatory audits (e.g., HIPAA, PCI, FEDRAMP), and a breach — while serious — would not cause "significant harm to public welfare."

**Practical guidance:** Since you have never done a formal security assessment, **begin by achieving full IG1 compliance first**, then systematically layer in IG2 safeguards. Trying to implement all 130 IG2 safeguards simultaneously will overwhelm a part-time IT resource.

---

## 3. IG1 Foundation: Where to Start (56 Safeguards Across 18 Controls)

The following is a prioritized starting sequence tailored to your environment. Work through these in order — each builds on the last.

---

### Phase 1: Know What You Have (Weeks 1–4)

**CIS Control 1 — Inventory and Control of Enterprise Assets**
- **Safeguard 1.1:** Create and maintain a detailed inventory of all devices: laptops, desktops, phones, printers, routers. Use a spreadsheet or Microsoft Intune (already available in M365) to track device name, owner, OS version, and location.
- **Safeguard 1.2:** Identify and address any unauthorized devices found on the network.
- **Why first:** You cannot protect what you do not know exists. This is the prerequisite for every other control.

**CIS Control 2 — Inventory and Control of Software Assets**
- **Safeguard 2.1:** Document all software authorized to run on firm devices, including your cloud accounting platform, M365 apps, and any installed applications.
- **Safeguard 2.2:** Confirm all software is currently vendor-supported (no end-of-life OS or applications).
- **Safeguard 2.3:** Remove or disable unauthorized software.

**CIS Control 3 — Data Protection (IG1 Safeguards)**
- **Safeguard 3.1:** Establish a data management process — define what client data you hold, where it lives, and who can access it.
- **Safeguard 3.2:** Maintain a data inventory (e.g., "client tax returns stored in [cloud platform]; client PII in M365 SharePoint").
- **Safeguard 3.3:** Configure access control lists — client data should be accessible only to staff working on that client.
- **Safeguard 3.4/3.5:** Define data retention periods and a secure disposal process for old records (shredding, secure deletion).

---

### Phase 2: Protect Accounts and Access (Weeks 3–6)

**CIS Control 5 — Account Management**
- **Safeguard 5.1:** Inventory all user accounts in Microsoft 365 and your accounting software. Remove former employee accounts immediately.
- **Safeguard 5.2:** Enforce unique, strong passwords. Use Microsoft 365's password policies and ban common passwords.
- **Safeguard 5.3:** Disable or remove accounts for departed employees and inactive accounts (no activity in 90 days).
- **Safeguard 5.4:** Restrict admin privileges — only the IT person (and a designated backup) should have global admin in M365. Partners should not use admin accounts for daily work.

**CIS Control 6 — Access Control Management (IG1 Safeguards)**
- **Safeguard 6.1:** Establish a formal process for granting access (new hire checklist).
- **Safeguard 6.2:** Establish a formal process for revoking access (offboarding checklist — same day as termination).

> **Critical note for your firm:** Multi-factor authentication (MFA) for externally-exposed applications (Safeguard 6.3) is technically an IG2 safeguard, but given that you process client financial data through cloud applications accessible over the internet, **treat this as an immediate priority regardless of IG level**. Enable MFA for all Microsoft 365 accounts and your cloud accounting platform now. This single action prevents the majority of credential-based attacks.

---

### Phase 3: Harden Systems and Prevent Malware (Weeks 5–8)

**CIS Control 4 — Secure Configuration**
- **Safeguard 4.1:** Document baseline security configurations for all devices. Use Microsoft Security Baseline templates (free from Microsoft).
- **Safeguard 4.3:** Configure automatic screen lock after 15 minutes of inactivity on all devices.
- **Safeguard 4.4/4.5:** Enable host-based firewalls on all servers and end-user devices. Windows Defender Firewall is already available.

**CIS Control 10 — Malware Defenses**
- **Safeguard 10.1:** Deploy anti-malware on all endpoints. Microsoft Defender (included in M365 Business Premium) covers this.
- **Safeguard 10.2:** Confirm automatic signature updates are enabled.
- **Safeguard 10.3:** Disable AutoRun/AutoPlay on all Windows devices.
- **Safeguard 10.4:** Configure anti-malware scanning of removable media (USB drives).

---

### Phase 4: Patching and Backups (Weeks 7–10)

**CIS Control 7 — Continuous Vulnerability Management (IG1 Safeguards)**
- **Safeguard 7.1:** Create a vulnerability management process — at minimum, a monthly patching schedule.
- **Safeguard 7.2:** Document a remediation process: critical patches within 14 days, high within 30 days.
- **Safeguard 7.3:** Enable automatic OS patch management for all Windows/Mac devices. Microsoft Intune or Windows Update for Business (included in M365) handles this.
- **Safeguard 7.4:** Enable automatic application patch management. Enable auto-updates for all third-party apps.

**CIS Control 11 — Data Recovery**
- **Safeguard 11.1:** Document your backup and recovery process.
- **Safeguard 11.2:** Implement automated backups of all critical data. Your cloud accounting platform likely has built-in backups — verify this. For M365, enable Microsoft 365 Backup or use a third-party backup (Veeam, Acronis).
- **Safeguard 11.4:** Maintain an isolated backup copy (offline or separate cloud tenant) to protect against ransomware. This is non-negotiable for a firm handling financial data.

---

### Phase 5: Email, Web, and Logging (Weeks 9–12)

**CIS Control 9 — Email and Web Browser Protections**
- **Safeguard 9.1:** Ensure all browsers and email clients are fully supported and up-to-date.
- **Safeguard 9.2:** Enable DNS filtering (Microsoft Defender for Endpoint includes this; Cisco Umbrella or Cloudflare Gateway are low-cost alternatives).
- **Safeguard 9.3:** Configure SPF, DKIM, and DMARC DNS records for your email domain to prevent spoofing. This is free and critical for an accounting firm targeted by business email compromise (BEC) attacks.

**CIS Control 8 — Audit Log Management (IG1 Safeguards)**
- **Safeguard 8.1:** Define a log management process.
- **Safeguard 8.2:** Enable audit logging in Microsoft 365 (Microsoft Purview Audit). Confirm logging is enabled in your cloud accounting platform.

---

### Phase 6: Training and Incident Response (Ongoing)

**CIS Control 14 — Security Awareness and Skills Training**
- **Safeguard 14.1:** Establish a security awareness program. Microsoft 365 includes Attack Simulator for phishing training. KnowBe4 and Proofpoint Security Awareness Training are cost-effective options.
- **Safeguard 14.2:** Train all staff to recognize phishing and social engineering — the #1 attack vector against accounting firms.
- **Safeguard 14.3:** Train on authentication best practices (why MFA matters, how to recognize MFA fatigue attacks).
- **Safeguard 14.4/14.5:** Train on data handling — what client data can be emailed, how to securely share documents.

**CIS Control 17 — Incident Response Management**
- **Safeguard 17.1:** Designate the IT person (and a partner as backup) to manage security incidents.
- **Safeguard 17.2:** Document contact information for reporting — your cyber insurance carrier, the IRS Stakeholder Liaison (for tax data breaches), state attorney general (for breach notification).
- **Safeguard 17.3/17.4:** Write a basic incident response plan. A one-page runbook covering: detect → contain → notify → recover is sufficient at this stage.

---

**CIS Control 15 — Service Provider Management**
- **Safeguard 15.1:** List all your service providers (cloud accounting vendor, M365/Microsoft, payroll processor, any IT contractors).
- **Safeguard 15.2:** Document a service provider management policy.
- **Safeguard 15.3/15.4:** Classify providers by risk level and confirm security requirements are addressed in contracts (look for data processing agreements, SOC 2 reports from your vendors).

---

## 4. IG2 Priorities to Layer In (After IG1 is Established)

Once IG1 is in place — realistically 3–6 months for a part-time IT resource — prioritize these IG2 additions given your risk profile:

| Priority | Safeguard | Reason for This Firm |
|----------|-----------|----------------------|
| **Immediate** | 6.3 — MFA for externally-exposed apps | Cloud apps accessible from internet; BEC is top threat for accountants |
| **Immediate** | 6.4 — MFA for remote network access | Remote work is common; VPN without MFA is insufficient |
| **High** | 3.11 — Encrypt sensitive data at rest | Client tax/financial data must be encrypted on laptops and file shares |
| **High** | 3.6 — Encrypt data on end-user devices | Enable BitLocker (Windows) or FileVault (Mac) on all devices |
| **High** | 11.3 — Protect recovery data | Backups must be isolated from production to survive ransomware |
| **High** | 9.5 — Implement DMARC enforcement | Move DMARC policy from `p=none` to `p=quarantine` or `p=reject` |
| **Medium** | 7.6 — Automated vulnerability scans | Use Microsoft Secure Score or Tenable Nessus Essentials |
| **Medium** | 8.5 — Collect detailed audit logs | Enable Unified Audit Log in M365 with 1-year retention |
| **Medium** | 12.7 — Remote access VPN | Require VPN for access to on-premises resources |
| **Medium** | 15.5 — Assess service providers | Request SOC 2 Type 2 reports annually from cloud accounting vendor |

---

## 5. Quick Win Summary (Do These This Week)

1. **Enable MFA** for all Microsoft 365 accounts — takes 30 minutes, prevents ~99% of credential attacks.
2. **Audit and remove** all inactive and former-employee accounts in M365 and accounting software.
3. **Verify backups** are running and test restoration from at least one backup.
4. **Configure SPF, DKIM, DMARC** for your email domain — free, takes 1–2 hours.
5. **Enable Microsoft Defender** on all endpoints and confirm it is reporting to M365 Defender portal.
6. **Check for end-of-life software** — any Windows 10 machines should be upgraded before October 2025 end-of-support.

---

## 6. Tools Available in Your Existing Stack

You already pay for Microsoft 365 — leverage it fully before purchasing additional tools:

| Capability | M365 Feature | CIS Control |
|-----------|-------------|-------------|
| Device inventory and management | Microsoft Intune | Control 1, 4 |
| Endpoint protection | Microsoft Defender for Endpoint | Control 10 |
| Identity and MFA | Microsoft Entra ID (Azure AD) | Control 5, 6 |
| Email security | Microsoft Defender for Office 365 | Control 9 |
| Audit logging | Microsoft Purview Audit | Control 8 |
| Vulnerability assessment | Microsoft Secure Score | Control 7 |
| Phishing simulation | Microsoft Attack Simulator | Control 14 |
| Data loss prevention | Microsoft Purview DLP | Control 3 (IG2) |

> **Note:** Many of these features require M365 Business Premium or higher. If you are on M365 Business Basic or Standard, upgrading to Business Premium (~$22/user/month) unlocks most of the security capabilities above and is likely your highest-ROI security investment.

---

## 7. Regulatory Context

As an accounting firm, your CIS Controls implementation supports compliance with:

- **IRS Publication 4557 / FTC Safeguards Rule (16 CFR Part 314):** Requires a written information security plan (WISP). IG1 + IG2 implementation provides the technical controls underpinning a compliant WISP.
- **State CPA board requirements:** Many states require reasonable security measures for client data.
- **AICPA SOC 2 (if applicable):** If you seek a SOC 2 report, IG2 implementation maps directly to the Security Trust Services Criteria (CC6–CC9).

---

## Summary

| Question | Answer |
|----------|--------|
| **Target IG** | IG2 (with IG1 as the mandatory foundation) |
| **Where to start** | Enable MFA immediately; then build asset inventory (Controls 1–2) |
| **Biggest risk** | Business email compromise and ransomware targeting client financial data |
| **Timeline** | IG1 complete in 3–6 months; IG2 in 12–18 months at part-time IT capacity |
| **Best leverage** | Maximize Microsoft 365 Business Premium security features before buying new tools |
| **Critical gap to address now** | No MFA on cloud applications is your highest-probability breach vector |

# CIS Controls Implementation Group Recommendation
## 75-Person Accounting Firm Security Assessment

---

## Recommended Implementation Group: IG1

**You should target CIS Controls Implementation Group 1 (IG1).**

### Why IG1 Is the Right Fit

The CIS Controls define three Implementation Groups based on organizational risk profile, resources, and security maturity:

| Factor | Your Organization | IG Match |
|--------|------------------|----------|
| Organization size | 75 employees | IG1 |
| IT staffing | Part-time, single person | IG1 |
| Security program maturity | No formal assessments | IG1 |
| Data sensitivity | Client financial/tax data | IG1–IG2 boundary |
| Technology environment | Cloud-based SaaS + M365 | IG1 |

IG1 is designed for organizations with limited cybersecurity expertise and resources. It covers the 56 "essential cyber hygiene" safeguards that every organization should have regardless of size — the baseline below which no organization should fall. CIS describes IG1 as protecting against the most common, non-targeted attacks.

**Important nuance:** Your processing of sensitive client financial and tax data pushes your *risk* toward IG2 territory, but your *resources and capacity* clearly place you at IG1 right now. Start with IG1 fully implemented before considering IG2 expansion. Regulatory obligations (IRS Publication 4557, FTC Safeguards Rule for tax preparers) reinforce the urgency of getting IG1 right.

---

## Where to Start: Priority IG1 Safeguards

IG1 spans CIS Controls 1–16 (with specific safeguards per control). Given your profile, prioritize in this order:

### Phase 1: Immediate Actions (Month 1–2)

**CIS Control 5 — Account Management**
- Safeguard 5.3: Disable dormant accounts within 30 days
- Safeguard 5.4: Restrict administrator privileges — your IT person and no one else should have admin rights
- Safeguard 5.6: Centralize account management (M365 Active Directory/Entra ID)

*Why first:* Credential compromise is the #1 entry point for accounting firm breaches. Former employees with active accounts and over-privileged users are immediate risks.

**CIS Control 6 — Access Control Management**
- Safeguard 6.3: Require MFA for all users accessing cloud applications
- Safeguard 6.5: Require MFA for all administrative access

*Why first:* MFA alone blocks over 99% of automated credential attacks. Your M365 environment has MFA built in — this is a configuration task, not a purchase.

**CIS Control 4 — Secure Configuration of Enterprise Assets**
- Safeguard 4.1: Establish and maintain a secure configuration process
- Safeguard 4.2: Establish and maintain a secure configuration for network infrastructure
- Apply Microsoft Secure Score baselines for M365

### Phase 2: Core Hygiene (Month 2–4)

**CIS Control 1 — Inventory and Control of Enterprise Assets**
- Safeguard 1.1: Maintain a detailed inventory of all enterprise assets
- Know every device that accesses client data

**CIS Control 2 — Inventory and Control of Software Assets**
- Safeguard 2.1: Maintain an inventory of all authorized software
- Safeguard 2.5: Allowlist authorized software on endpoints

**CIS Control 3 — Data Protection**
- Safeguard 3.3: Configure data access control lists — who can access which client files?
- Safeguard 3.11: Encrypt sensitive data at rest on laptops/workstations
- Safeguard 3.12: Segment data processing and storage based on sensitivity

*Why this matters for you:* Client tax data is a high-value target. Data protection controls directly address your regulatory exposure under the FTC Safeguards Rule.

**CIS Control 11 — Data Recovery**
- Safeguard 11.1: Establish and maintain a data recovery process
- Safeguard 11.2: Perform automated backups — verify your cloud accounting software and M365 backups are actually working
- Safeguard 11.4: Test backup recovery quarterly

### Phase 3: Detection and Response Foundation (Month 4–6)

**CIS Control 8 — Audit Log Management**
- Safeguard 8.2: Collect audit logs from M365, cloud accounting software, and network devices
- Safeguard 8.5: Enable Microsoft Defender audit logging

**CIS Control 9 — Email and Web Browser Protections**
- Safeguard 9.1: Use only fully supported browsers and email clients
- Safeguard 9.2: Use DNS filtering services (Cisco Umbrella, Cloudflare Gateway — both have free/low-cost tiers)
- Safeguard 9.5: Enable anti-phishing controls in M365 (Defender for Office 365)

*Why critical for accounting firms:* Phishing and business email compromise (BEC) targeting accounting firms is rampant, especially during tax season. BEC attacks impersonate partners to redirect client payments.

**CIS Control 14 — Security Awareness and Skills Training**
- Safeguard 14.1: Establish and maintain a security awareness program
- Safeguard 14.2: Train employees to recognize social engineering attacks
- Safeguard 14.6: Train employees on how to identify and report phishing

*Practical approach:* Microsoft 365 Business Premium includes Attack Simulator for phishing training. KnowBe4 and Proofpoint offer SMB-appropriate pricing.

**CIS Control 17 — Incident Response Management**
- Safeguard 17.1: Designate personnel to manage incident handling — even if it's your part-time IT person
- Safeguard 17.2: Establish and maintain contact information for reporting security incidents (IRS, state tax agencies, clients)
- Safeguard 17.3: Create a simple written incident response plan

---

## Practical Considerations for Your Situation

### Leverage What You Already Have
Your Microsoft 365 subscription likely includes significant security tooling at no additional cost:
- **Microsoft Defender Antivirus** — ensure it is active on all endpoints
- **Microsoft Entra ID** (formerly Azure AD) — MFA, conditional access, device compliance
- **Microsoft Defender for Office 365** (Plan 1 included in M365 Business Premium) — anti-phishing, safe links, safe attachments
- **Microsoft Purview** — data loss prevention to prevent client data from leaving via email
- **Microsoft Secure Score** — provides a dashboard showing your current security posture and prioritized recommendations

Check which M365 plan you have. Upgrading from Business Basic/Standard to Business Premium (~$22/user/month) unlocks substantially more security capability and is likely cost-justified given the client data you hold.

### Regulatory Baseline You Must Meet
As an accounting firm handling tax data:
- **IRS Publication 4557** (Safeguarding Taxpayer Data) — mandatory for tax preparers; maps closely to IG1
- **FTC Safeguards Rule** — applies to financial institutions including tax preparers; requires a written information security program, risk assessment, and designated security coordinator
- **State-level data breach notification laws** — know your obligations if client data is compromised

Your IG1 implementation will substantially address these requirements.

### Resource-Constrained Implementation Strategy

Given a part-time IT resource, be realistic:

1. **Use M365 Secure Score as your roadmap** — it prioritizes actions by impact and difficulty
2. **Automate where possible** — Conditional Access policies in Entra ID enforce MFA without manual intervention
3. **Consider a one-time engagement** with an MSSP (Managed Security Service Provider) or CIS-certified assessor to baseline your current state — a 2–3 day assessment will reveal your highest risks
4. **Prioritize prevention over detection** at this stage — MFA, patching, and email filtering prevent incidents that your part-time IT person does not have capacity to investigate

### 90-Day Quick Win Checklist

- [ ] Enable MFA for all M365 users (Entra ID Conditional Access)
- [ ] Remove local administrator rights from standard user accounts
- [ ] Audit and disable inactive accounts
- [ ] Review your M365 Secure Score and address top 10 recommendations
- [ ] Confirm automated backups are running and test restoration
- [ ] Enable Microsoft Defender on all endpoints
- [ ] Enable anti-phishing policies in Defender for Office 365
- [ ] Document a one-page incident response contact list
- [ ] Conduct one phishing awareness training session
- [ ] Create an asset inventory (spreadsheet of all devices and software is sufficient to start)

---

## Summary

| Recommendation | Detail |
|---------------|--------|
| Target IG | **IG1 (all 56 safeguards)** |
| Start here | **CIS Control 5 (Accounts) and Control 6 (MFA)** |
| Highest risk | Credential compromise, phishing/BEC, unencrypted client data on endpoints |
| Quick wins | MFA in M365, admin privilege restriction, M365 Secure Score review |
| Regulatory anchor | IRS Pub 4557, FTC Safeguards Rule |
| Timeline to IG1 completion | 6–12 months with part-time IT resource |

Completing IG1 will put you ahead of the majority of firms your size and will provide a defensible security posture if a breach occurs. Once IG1 is fully implemented and documented, reassess whether your client obligations and growth trajectory warrant moving to IG2.

# CIS Controls v8 IG2 Gap Assessment
## Manufacturing Company — 350 Employees, IT Team of 5

---

## Step 1: Implementation Group Determination

**Profile:**

| Factor | Detail |
|--------|--------|
| Size | 350 employees |
| IT Capability | 5-person dedicated IT team; responsible for managing and protecting IT infrastructure |
| Data Sensitivity | Manufacturing environment — likely contains proprietary process data, supplier/customer records, OT/IT boundary considerations |
| Risk Tolerance | Operational disruptions would impact production and revenue; some outages tolerable but sustained downtime costly |
| Regulatory Exposure | Possible CMMC/DFARS exposure if defense supplier; EHS data; financial records |

**Determination: IG2**

This organization clearly meets IG2 criteria: it has dedicated IT personnel responsible for managing and protecting IT, stores data that could affect operations if compromised, and can withstand some outage. IG3 is not required as there is no evidence of a dedicated security team (separate from IT) or significant regulatory oversight of sensitive data. All IG1 and IG2 safeguards apply.

---

## Step 2: Current State Inventory

**Known Implemented Controls:**
- Antivirus on all endpoints
- Monthly Windows patching
- Basic perimeter firewall
- Annual security awareness training

**Known Gaps:**
- No MFA on VPN
- No vulnerability scanner
- No centralized log management (only Windows Event Viewer per server)

---

## Step 3: Gap Assessment Table

The table below covers all 18 CIS Controls, assessing current state against IG2 requirements. Status uses RAG scoring: **Green** = implemented, **Amber** = partial, **Red** = not implemented.

| CIS Control | Safeguard(s) | IG Level | Current State | Gap | Priority |
|-------------|-------------|----------|---------------|-----|----------|
| **1: Inventory & Control of Enterprise Assets** | 1.1 Maintain enterprise asset inventory | IG1 | Unknown — no evidence of formal inventory | No formal hardware asset inventory confirmed | HIGH |
| | 1.2 Address unauthorized assets | IG1 | Unknown | No process documented to detect/quarantine rogue devices | HIGH |
| | 1.3 Use DHCP logging | IG1 | Unknown | Likely not formally implemented | MEDIUM |
| | 1.4 Use DHCP logging to update inventory | IG1 | Unknown | No evidence of automated inventory updates | MEDIUM |
| | 1.5 Use passive asset discovery tool | IG2 | Not implemented | No asset discovery tooling in place | HIGH |
| **2: Inventory & Control of Software Assets** | 2.1 Establish software inventory | IG1 | Unknown | No formal authorized software list confirmed | HIGH |
| | 2.2 Ensure software is currently supported | IG1 | Partial — Windows patched monthly | Non-Windows and third-party apps not addressed | MEDIUM |
| | 2.3 Address unauthorized software | IG1 | Unknown | No process for detecting/blocking unauthorized software | HIGH |
| | 2.5 Allowlist authorized software | IG2 | Not implemented | No application allowlisting in place | HIGH |
| | 2.6 Allowlist authorized libraries | IG2 | Not implemented | No library allowlisting | MEDIUM |
| | 2.7 Allowlist authorized scripts | IG2 | Not implemented | No script allowlisting | MEDIUM |
| **3: Data Protection** | 3.1 Establish data management process | IG1 | Unknown | No evidence of formal data classification or management policy | HIGH |
| | 3.2 Establish data inventory | IG1 | Unknown | No data inventory confirmed | HIGH |
| | 3.3 Configure data access control lists | IG1 | Unknown | No evidence of formal ACL governance | MEDIUM |
| | 3.6 Encrypt data on end-user devices | IG2 | Unknown | Full-disk encryption status on endpoints unknown | HIGH |
| | 3.11 Encrypt sensitive data at rest | IG2 | Unknown | Encryption at rest for servers/databases not confirmed | HIGH |
| **4: Secure Configuration** | 4.1 Secure configuration process for assets | IG1 | Unknown | No evidence of configuration baselines (e.g., CIS Benchmarks) | HIGH |
| | 4.2 Secure configuration for network infra | IG1 | Partial — basic firewall exists | Firewall rules not confirmed as hardened; no configuration standard | MEDIUM |
| | 4.3 Configure automatic session locking | IG1 | Unknown | Session lock policy not confirmed | LOW |
| | 4.4 Implement firewall on servers | IG1 | Unknown | Host-based firewall status on servers not confirmed | MEDIUM |
| | 4.5 Implement firewall on end-user devices | IG1 | Unknown | Windows Firewall status not confirmed as enforced | MEDIUM |
| | 4.8 Disable unnecessary services | IG2 | Unknown | No service hardening process in place | MEDIUM |
| **5: Account Management** | 5.1 Inventory of accounts | IG1 | Unknown | No formal account inventory confirmed | MEDIUM |
| | 5.2 Use unique passwords | IG1 | Unknown | Password policy not confirmed | MEDIUM |
| | 5.3 Disable dormant accounts | IG1 | Unknown | No dormant account review process confirmed | MEDIUM |
| | 5.4 Restrict admin privileges | IG1 | Unknown | Least-privilege enforcement not confirmed | HIGH |
| | 5.5 Inventory of service accounts | IG2 | Unknown | No service account inventory confirmed | MEDIUM |
| | 5.6 Centralize account management | IG2 | Unknown | Central directory (Active Directory) assumed but not confirmed | MEDIUM |
| **6: Access Control Management** | 6.1 Access granting process | IG1 | Unknown | Formal access provisioning process not documented | MEDIUM |
| | 6.2 Access revoking process | IG1 | Unknown | Offboarding access revocation process not confirmed | MEDIUM |
| | **6.3 Require MFA for external applications** | **IG2** | **Not implemented** | **No MFA on externally exposed services** | **CRITICAL** |
| | **6.4 Require MFA for remote network access (VPN)** | **IG2** | **Not implemented** | **VPN has no MFA — confirmed gap** | **CRITICAL** |
| | 6.5 Require MFA for admin access | IG2 | Unknown | MFA for administrative accounts not confirmed | CRITICAL |
| | 6.8 Define role-based access control | IG2 | Unknown | No formal RBAC model documented | HIGH |
| **7: Continuous Vulnerability Management** | 7.1 Establish vulnerability management process | IG1 | Partial — monthly Windows patching only | No formal vulnerability management policy or process | HIGH |
| | 7.2 Establish remediation process | IG1 | Partial — patches applied monthly | No risk-based remediation SLAs defined | HIGH |
| | 7.3 Automated OS patch management | IG1 | Partial — Windows patched; manual process assumed | Non-Windows OS and third-party app patching not confirmed as automated | MEDIUM |
| | 7.4 Automated application patch management | IG1 | Not implemented | Application-level patching (third-party software) not addressed | HIGH |
| | **7.6 Automated vulnerability scans — internal assets** | **IG2** | **Not implemented** | **No vulnerability scanner — confirmed gap** | **CRITICAL** |
| | **7.7 Remediate detected vulnerabilities** | **IG2** | **Not implemented** | **Cannot remediate what is not scanned** | **CRITICAL** |
| **8: Audit Log Management** | 8.1 Establish audit log management process | IG1 | Not implemented | No formal log management policy | HIGH |
| | 8.2 Collect audit logs | IG1 | Partial — Windows Event Viewer on individual servers | Logs exist but not aggregated, no retention, no alerting | HIGH |
| | **8.3 Ensure adequate audit log storage** | **IG2** | **Not implemented** | **No centralized storage; logs at risk of overwrite** | **HIGH** |
| | **8.5 Collect detailed audit logs** | **IG2** | **Not implemented** | **Event Viewer alone does not meet IG2 detail requirements** | **HIGH** |
| | **8.11 Conduct audit log reviews** | **IG2** | **Not implemented** | **No regular log review process** | **HIGH** |
| | **8.12 Collect service provider logs** | **IG2** | **Not implemented** | **Cloud/SaaS service logs not collected** | **MEDIUM** |
| **9: Email and Web Browser Protections** | 9.1 Use fully supported browsers/email clients | IG1 | Unknown | Browser/email client version management not confirmed | LOW |
| | 9.2 Use DNS filtering | IG1 | Not confirmed | No DNS filtering service confirmed | MEDIUM |
| | 9.3 Maintain anti-spoofing (SPF/DKIM) | IG1 | Unknown | Email authentication records not confirmed | MEDIUM |
| | 9.5 Implement DMARC | IG2 | Unknown | DMARC policy not confirmed | MEDIUM |
| | 9.6 Block unnecessary file types | IG2 | Unknown | Email file type filtering not confirmed | MEDIUM |
| | 9.7 Deploy email server anti-malware | IG2 | Unknown | Centralized email anti-malware not confirmed | MEDIUM |
| **10: Malware Defenses** | 10.1 Deploy anti-malware software | IG1 | Implemented — antivirus on all endpoints | Met | LOW |
| | 10.2 Automatic signature updates | IG1 | Assumed — standard AV behavior | Confirm auto-update is enforced via policy | LOW |
| | 10.3 Disable autorun/autoplay | IG1 | Unknown | Autorun policy not confirmed | LOW |
| | 10.5 Enable anti-exploitation features | IG2 | Unknown | Windows Exploit Guard / DEP / ASLR enforcement not confirmed | MEDIUM |
| | **10.6 Centrally manage anti-malware** | **IG2** | **Unknown** | **Central AV management console/policy enforcement not confirmed** | **HIGH** |
| | 10.7 Use behavior-based anti-malware | IG2 | Unknown | Whether current AV includes EDR/behavioral detection not confirmed | MEDIUM |
| **11: Data Recovery** | 11.1 Establish data recovery process | IG1 | Unknown | No backup/recovery policy confirmed | HIGH |
| | 11.2 Perform automated backups | IG1 | Unknown | Automated backup status not confirmed | HIGH |
| | 11.3 Protect recovery data | IG2 | Unknown | Backup encryption and offsite storage not confirmed | HIGH |
| | 11.4 Establish isolated recovery data | IG1 | Unknown | Immutable/isolated backups not confirmed | HIGH |
| | 11.5 Test data recovery | IG2 | Unknown | Recovery testing not confirmed | HIGH |
| **12: Network Infrastructure Management** | 12.1 Keep network infrastructure up-to-date | IG1 | Unknown | Firewall/switch firmware patching not confirmed | MEDIUM |
| | 12.2 Establish secure network architecture | IG2 | Unknown | Network segmentation (IT/OT, guest, production) not confirmed | HIGH |
| | 12.3 Securely manage network infrastructure | IG2 | Unknown | Out-of-band management and access controls for network devices not confirmed | MEDIUM |
| | 12.4 Maintain architecture diagram | IG2 | Unknown | Formal network diagram not confirmed | MEDIUM |
| | 12.6 Use secure management protocols | IG2 | Unknown | Use of SSH/HTTPS vs Telnet/HTTP for device management not confirmed | MEDIUM |
| | **12.7 Ensure remote devices use VPN** | **IG2** | **Partial — VPN exists but no MFA** | **VPN without MFA is a critical control failure** | **CRITICAL** |
| **13: Network Monitoring and Defense** | **13.1 Centralize security event alerting** | **IG2** | **Not implemented** | **No SIEM or centralized alerting** | **HIGH** |
| | 13.2 Deploy host-based intrusion detection | IG2 | Unknown | HIDS/EDR not confirmed beyond basic AV | HIGH |
| | **13.3 Deploy network intrusion detection (NIDS)** | **IG2** | **Not implemented** | **No network-level detection** | **HIGH** |
| | 13.6 Collect network traffic flow logs | IG2 | Not implemented | No NetFlow or traffic logging | HIGH |
| **14: Security Awareness Training** | 14.1 Establish security awareness program | IG1 | Partial — annual training only | Annual cadence insufficient; no metrics or role-based training | MEDIUM |
| | 14.2 Train on social engineering | IG1 | Partial — included in annual training | Phishing simulation not confirmed | MEDIUM |
| | 14.3 Train on authentication best practices | IG1 | Partial | MFA and password hygiene likely not reinforced given no MFA deployment | MEDIUM |
| | 14.7 Train on insider threats | IG2 | Unknown | Insider threat awareness not confirmed as a training topic | MEDIUM |
| **15: Service Provider Management** | 15.1 Inventory of service providers | IG1 | Unknown | No vendor/service provider inventory confirmed | MEDIUM |
| | 15.2 Service provider management policy | IG1 | Unknown | No vendor management policy confirmed | MEDIUM |
| | 15.5 Assess service providers | IG2 | Not implemented | No third-party security assessments | HIGH |
| | 15.6 Monitor service providers | IG2 | Not implemented | No ongoing vendor monitoring | HIGH |
| **16: Application Software Security** | 16.1 Secure development process | IG2 | Unknown — manufacturing context | Likely not applicable if no in-house dev; confirm and document | LOW |
| | 16.2 Process for software vulnerability reports | IG2 | Unknown | No vulnerability disclosure intake process | MEDIUM |
| | 16.7 Use hardening configuration templates | IG2 | Unknown | CIS Benchmark hardening for deployed applications not confirmed | MEDIUM |
| **17: Incident Response Management** | 17.1 Designate incident response personnel | IG1 | Unknown | No formal IR team or designated roles confirmed | HIGH |
| | 17.3 Enterprise incident reporting process | IG1 | Unknown | No documented incident reporting process | HIGH |
| | 17.4 Establish incident response process | IG1 | Unknown | No IR plan or playbooks confirmed | HIGH |
| | 17.7 Conduct IR exercises | IG2 | Not implemented | No tabletop or IR drills | HIGH |
| | 17.9 Establish incident thresholds | IG2 | Not implemented | No defined thresholds for what constitutes a security incident | MEDIUM |
| **18: Penetration Testing** | 18.1 Establish penetration testing program | IG2 | Not implemented | No pen testing program | MEDIUM |
| | 18.2 Perform periodic external pen tests | IG2 | Not implemented | No external pen tests conducted | HIGH |
| | 18.3 Remediate pen test findings | IG2 | N/A — no tests conducted | Dependent on 18.2 | MEDIUM |

---

## Step 4: Priority Actions — Remediation Roadmap

### CRITICAL (Address Within 30 Days)

These gaps represent the highest probability of a successful breach and should be treated as immediate risks.

---

**Priority 1: Deploy MFA on VPN and All Remote Access**
- **Safeguards:** CIS Control 6, Safeguards 6.3, 6.4, 6.5
- **Why:** VPN without MFA is the single most exploited attack vector for initial access in manufacturing ransomware incidents. Credential stuffing and phishing-obtained passwords provide direct network entry.
- **Action:** Enable MFA on the VPN using an authenticator app (Microsoft Authenticator, Duo, Google Authenticator). Extend MFA to RDP, Microsoft 365/cloud portals, and local admin accounts.
- **Tools:** Duo Security, Microsoft Entra ID MFA, Cisco Duo for network devices.
- **Effort:** Low-Medium (1–3 weeks with existing infrastructure).
- **MITRE ATT&CK Addressed:** T1078 (Valid Accounts), T1110 (Brute Force), T1133 (External Remote Services).

---

**Priority 2: Deploy a Vulnerability Scanner**
- **Safeguards:** CIS Control 7, Safeguards 7.6, 7.7
- **Why:** Monthly Windows patching alone does not identify unpatched third-party software, misconfigurations, or newly discovered CVEs between patch cycles. You cannot remediate what you cannot see.
- **Action:** Deploy an authenticated vulnerability scanner. Scan all internal assets weekly. Establish remediation SLAs: Critical CVEs within 15 days, High within 30 days.
- **Tools:** Tenable Nessus Essentials (free for 16 IPs, affordable for full network), Qualys VMDR, Rapid7 InsightVM.
- **Effort:** Low (days to deploy; ongoing process to build).
- **MITRE ATT&CK Addressed:** T1190 (Exploit Public-Facing Application), T1203 (Exploitation for Client Execution).

---

**Priority 3: Implement Centralized Log Management (SIEM)**
- **Safeguards:** CIS Control 8, Safeguards 8.2, 8.3, 8.5, 8.11; CIS Control 13, Safeguard 13.1
- **Why:** Windows Event Viewer on individual servers provides no ability to detect lateral movement, correlate events across systems, or meet any retention requirements. This is a detection blind spot.
- **Action:** Deploy a SIEM or centralized log aggregation solution. Collect Windows Security Event Logs, firewall logs, VPN logs, and authentication logs at minimum. Set up alerting for failed logins, privilege escalation, and account lockouts.
- **Tools:** Microsoft Sentinel (cloud-native, low-cost for SMB), Wazuh (open-source SIEM + HIDS), Elastic Security (SIEM), Graylog.
- **Effort:** Medium (2–6 weeks for initial deployment; ongoing tuning).
- **MITRE ATT&CK Addressed:** T1078, T1021 (Remote Services), T1059 (Command and Scripting Interpreter).

---

### HIGH (Address Within 60–90 Days)

**Priority 4: Establish Hardware and Software Asset Inventories**
- **Safeguards:** CIS Control 1, Safeguards 1.1, 1.2, 1.5; CIS Control 2, Safeguards 2.1, 2.3, 2.5
- **Why:** You cannot protect assets you don't know you have. Unauthorized devices and software are entry points for attackers.
- **Action:** Deploy a network asset discovery tool (active and passive). Build and maintain an authorized hardware inventory. Create an authorized software list and begin enforcing application allowlisting on critical servers.
- **Tools:** Lansweeper (free tier available), Spiceworks Network Scanner, Microsoft Intune (if using M365), Cisco DNA Center.
- **Effort:** Medium (4–8 weeks to establish baseline inventory).

---

**Priority 5: Formalize Data Protection — Encryption at Rest and on Endpoints**
- **Safeguards:** CIS Control 3, Safeguards 3.6, 3.11
- **Why:** Manufacturing environments store valuable IP. Laptop loss or a ransomware event without encryption means data exposure.
- **Action:** Enable BitLocker (Windows) or FileVault (Mac) on all end-user devices via Group Policy. Enable encryption on file servers and databases storing sensitive data.
- **Tools:** Microsoft BitLocker (built into Windows Pro/Enterprise), Group Policy for enforcement, Intune for mobile devices.
- **Effort:** Low-Medium (can be deployed via GPO in 1–2 weeks).

---

**Priority 6: Establish and Test a Data Recovery and Backup Program**
- **Safeguards:** CIS Control 11, Safeguards 11.1, 11.2, 11.3, 11.4, 11.5
- **Why:** Ransomware recovery without clean, tested backups is catastrophic for manufacturing operations. Backup existence is not enough — recoverability must be tested.
- **Action:** Implement automated daily backups for all critical systems. Store at least one copy offsite or in immutable cloud storage (following 3-2-1 rule). Test recovery quarterly.
- **Tools:** Veeam Backup (SMB-friendly), Azure Backup, AWS Backup, Acronis.
- **Effort:** Medium (4–6 weeks to implement; quarterly for testing).

---

**Priority 7: Deploy Centralized Antivirus Management and Upgrade to EDR**
- **Safeguards:** CIS Control 10, Safeguards 10.6, 10.7
- **Why:** Antivirus on endpoints is a start, but without central management you cannot confirm coverage, push updates, or detect behavioral threats (e.g., fileless malware, ransomware precursors).
- **Action:** Centralize AV management via a management console. Evaluate upgrading to an EDR solution that provides behavioral detection and response capabilities.
- **Tools:** Microsoft Defender for Endpoint (integrates with Intune/M365), CrowdStrike Falcon Go, SentinelOne.
- **Effort:** Low-Medium (1–3 weeks if using existing Microsoft tooling).

---

**Priority 8: Establish an Incident Response Plan**
- **Safeguards:** CIS Control 17, Safeguards 17.1, 17.3, 17.4, 17.7
- **Why:** Without a documented IR plan, a ransomware or breach incident will cause maximum operational disruption and extend recovery time.
- **Action:** Document an Incident Response Plan covering: roles and responsibilities, incident classification criteria, communication chains (internal and external — CISA, FBI, legal counsel, cyber insurer), containment and eradication steps, and recovery procedures. Conduct a tabletop exercise annually.
- **Tools:** CISA's free IR planning resources; NIST SP 800-61r2 as a template.
- **Effort:** Medium (3–4 weeks to draft; tabletop exercise within 90 days).

---

**Priority 9: Implement Network Segmentation and Architecture Documentation**
- **Safeguards:** CIS Control 12, Safeguards 12.2, 12.4; CIS Control 13, Safeguard 13.3
- **Why:** Flat networks allow ransomware and attackers to move laterally without constraint. In manufacturing, OT/IT convergence creates significant risk if not segmented.
- **Action:** Document current network architecture. Implement VLANs to separate: corporate users, servers, OT/manufacturing systems, guest Wi-Fi, and IoT devices. Deploy a network intrusion detection system (NIDS) on the perimeter and key internal segments.
- **Tools:** Managed switches with VLAN support (Cisco, Ubiquiti), pfSense/Fortinet for NIDS, Zeek/Suricata for open-source NIDS.
- **Effort:** Medium-High (6–12 weeks; phased by segment).

---

### MEDIUM (Address Within 6 Months)

**Priority 10: Enhance Patching to Cover Third-Party Applications**
- **Safeguards:** CIS Control 7, Safeguards 7.3, 7.4
- **Action:** Extend patch management to third-party software (Adobe, Java, browsers, Office). Use a patch management tool that covers non-Microsoft software.
- **Tools:** PDQ Deploy + Inventory (SMB-friendly), ManageEngine Patch Manager Plus, Chocolatey (open-source).

**Priority 11: Implement Email Security (SPF, DKIM, DMARC, Anti-Malware)**
- **Safeguards:** CIS Control 9, Safeguards 9.3, 9.5, 9.6, 9.7
- **Action:** Publish and enforce SPF and DKIM records. Implement a DMARC policy (start with p=none for monitoring, progress to p=quarantine/reject). Enable email anti-malware filtering.
- **Tools:** Proofpoint Essentials, Microsoft Defender for Office 365, MXToolbox for record verification.

**Priority 12: Increase Security Training Frequency and Add Phishing Simulations**
- **Safeguards:** CIS Control 14, Safeguards 14.1, 14.2, 14.7
- **Action:** Move from annual to quarterly security awareness training. Add monthly phishing simulation campaigns. Include insider threat awareness and manufacturing-specific scenarios (e.g., USB drops, vendor phishing).
- **Tools:** KnowBe4, Proofpoint Security Awareness Training, Cofense (free tiers available).

**Priority 13: Establish Service Provider (Vendor) Management**
- **Safeguards:** CIS Control 15, Safeguards 15.1, 15.2, 15.5, 15.6
- **Action:** Create an inventory of all third-party service providers with access to systems or data. Establish minimum security requirements in contracts. Conduct annual security assessments of high-risk vendors.

**Priority 14: Establish Secure Configuration Baselines**
- **Safeguards:** CIS Control 4, Safeguards 4.1, 4.2, 4.8
- **Action:** Adopt CIS Benchmarks for Windows Server, Windows 10/11, and network devices. Apply hardened configurations. Disable unnecessary services on all servers. Use Group Policy to enforce configuration standards.
- **Tools:** CIS-CAT Lite (free), Microsoft Security Baseline (free GPO templates).

**Priority 15: Conduct External Penetration Test**
- **Safeguards:** CIS Control 18, Safeguards 18.1, 18.2, 18.3
- **Action:** Engage a qualified third-party penetration testing firm for an annual external pen test. After completing MFA and vulnerability management improvements (Priorities 1–2), an internal pen test will also be valuable.

---

## Step 5: Summary Scorecard

| CIS Control | IG Level Required | Current Maturity | Gap Severity |
|-------------|------------------|-----------------|--------------|
| 1: Asset Inventory | IG2 | Red — Not Implemented | HIGH |
| 2: Software Inventory | IG2 | Red — Not Implemented | HIGH |
| 3: Data Protection | IG2 | Red — Not Implemented | HIGH |
| 4: Secure Configuration | IG2 | Amber — Partial | MEDIUM |
| 5: Account Management | IG2 | Amber — Partial | MEDIUM |
| 6: Access Control / MFA | IG2 | Red — Confirmed Gap | CRITICAL |
| 7: Vulnerability Management | IG2 | Red — No Scanner | CRITICAL |
| 8: Audit Log Management | IG2 | Red — Confirmed Gap | CRITICAL |
| 9: Email/Web Protections | IG2 | Unknown/Partial | MEDIUM |
| 10: Malware Defenses | IG2 | Amber — AV exists, not centralized | MEDIUM |
| 11: Data Recovery | IG2 | Unknown | HIGH |
| 12: Network Infrastructure | IG2 | Amber — Firewall only | HIGH |
| 13: Network Monitoring | IG2 | Red — Not Implemented | HIGH |
| 14: Security Training | IG2 | Amber — Annual only | MEDIUM |
| 15: Service Provider Mgmt | IG2 | Red — Not Implemented | HIGH |
| 16: Application Security | IG2 | Unknown | LOW-MEDIUM |
| 17: Incident Response | IG2 | Red — Not Implemented | HIGH |
| 18: Penetration Testing | IG2 | Red — Not Implemented | MEDIUM |

**Overall IG2 Compliance Estimate: ~15–20% implemented**

---

## Step 6: Quick Win Summary (Ranked by Impact vs. Effort)

| Action | Effort | Impact | Timeframe |
|--------|--------|--------|-----------|
| Enable MFA on VPN and admin accounts | Low | CRITICAL | Week 1–2 |
| Deploy vulnerability scanner (Nessus Essentials) | Low | CRITICAL | Week 1–2 |
| Enable BitLocker on all endpoints via GPO | Low | HIGH | Week 2–3 |
| Deploy SIEM (Wazuh or Microsoft Sentinel) | Medium | CRITICAL | Month 1–2 |
| Establish hardware/software asset inventory | Medium | HIGH | Month 1–2 |
| Centralize AV management / upgrade to EDR | Low-Medium | HIGH | Month 1 |
| Implement and test backup/recovery | Medium | HIGH | Month 2–3 |
| Draft Incident Response Plan + tabletop | Medium | HIGH | Month 2–3 |
| Publish DMARC/SPF/DKIM records | Low | MEDIUM | Week 2–3 |
| Move to quarterly security training + phishing sim | Low | MEDIUM | Month 2 |

---

## Notes on Manufacturing-Specific Risks

1. **OT/IT Convergence:** If manufacturing equipment (PLCs, SCADA, HMI systems) is network-connected, CIS Control 12 (network segmentation) becomes even more critical. OT systems often run legacy OS versions that cannot be patched — isolation is the primary control.

2. **VPN Risk Profile:** Without MFA, the VPN is effectively a single-factor authenticated path into the entire network. Given that manufacturing IP is a high-value target for nation-state actors and ransomware groups, this is the single highest-priority remediation.

3. **Supply Chain Risk:** Manufacturing suppliers and partners with network access (CIS Control 15) are a common attack vector. Vendor access should be reviewed and MFA-enforced for all third-party remote connections.

4. **Ransomware Readiness:** The combination of no MFA, no vulnerability scanner, no centralized logging, and unconfirmed backups creates near-ideal conditions for a successful ransomware attack. Addressing Priorities 1–3 and 6 directly reduces ransomware risk.

---

*Assessment based on CIS Controls v8, published May 2021 by the Center for Internet Security. All safeguard references are to CIS Controls v8 Implementation Group assignments. Next assessment recommended after completing Priority 1–3 actions (approximately 90 days).*

# CIS Controls v8 IG2 Gap Assessment
## Manufacturing Company (350 Employees, IT Team of 5)

**Assessment Date:** 2026-05-06
**Framework:** CIS Controls v8, Implementation Group 2 (IG2)
**Organization Profile:** Manufacturing, ~350 employees, dedicated IT team of 5

---

## Executive Summary

Your organization has established a foundational security baseline (antivirus, monthly patching, basic firewall, annual training) but has significant gaps against CIS Controls v8 IG2 requirements. IG2 is designed for organizations with IT professionals who handle sensitive data and need to defend against more sophisticated threats — a profile that fits a mid-size manufacturer well, particularly given the risk of ransomware targeting operational technology (OT) and supply chain data.

**Overall Posture:** Partial compliance with IG1 (the most basic tier); substantially non-compliant with IG2.

**Critical Risk Areas:** No MFA on VPN, no centralized log management, no vulnerability scanning, and no asset/software inventory program represent the highest-probability attack paths an adversary would exploit today.

---

## CIS Controls v8 IG2 — Control-by-Control Gap Analysis

The table below maps your current practices to each CIS Control and its IG2 safeguards, identifies gaps, and rates residual risk.

**Risk Rating Scale:** Critical | High | Medium | Low

---

### CIS Control 1 — Inventory and Control of Enterprise Assets

**IG2 Safeguards Required:** 1.1 (establish and maintain detailed asset inventory), 1.2 (address unauthorized assets), 1.3 (utilize DHCP logging), 1.4 (use dynamic host configuration), 1.5 (use passive asset discovery)

| Current State | Gap | Risk |
|---|---|---|
| No mention of formal asset inventory process | No centralized hardware asset inventory; unknown if DHCP logs are retained; no passive network discovery tool in place | High |

**Detail:** Without a complete, current inventory of hardware assets, you cannot patch, protect, or monitor what you do not know exists. Rogue or unmanaged devices are a common ransomware entry point in manufacturing environments. IG2 requires not just a list but active processes to detect unauthorized devices.

---

### CIS Control 2 — Inventory and Control of Software Assets

**IG2 Safeguards Required:** 2.1 (establish and maintain software inventory), 2.2 (ensure authorized software is currently supported), 2.3 (address unauthorized software), 2.4 (utilize automated software inventory tools), 2.5 (allowlist authorized software), 2.6 (allowlist authorized libraries), 2.7 (allowlist authorized scripts)

| Current State | Gap | Risk |
|---|---|---|
| Antivirus present (implies some endpoint visibility); no software inventory process described | No formal software inventory; no allowlisting; no process to identify unauthorized or unsupported software | High |

**Detail:** Manufacturing environments frequently accumulate legacy, unpatched, or shadow IT software. Without an inventory, unsupported software (e.g., old HMI clients, legacy ERP components) goes undetected and unpatched.

---

### CIS Control 3 — Data Protection

**IG2 Safeguards Required:** 3.1 (establish data management process), 3.2 (establish data inventory), 3.3 (configure data access control lists), 3.4 (enforce data retention), 3.5 (securely dispose of data), 3.6 (encrypt data on end-user devices), 3.7 (establish and maintain a data classification scheme), 3.8 (document data flows), 3.9 (encrypt data on removable media), 3.10 (encrypt sensitive data in transit), 3.11 (encrypt sensitive data at rest), 3.12 (segment data processing and storage), 3.13 (deploy a data loss prevention solution)

| Current State | Gap | Risk |
|---|---|---|
| No data protection controls described | No data classification, no DLP, encryption posture unknown, no documented data flows | High |

**Detail:** Manufacturing companies hold valuable IP (designs, formulas, production processes) and supply chain data. IG2 requires a structured data protection program. The absence of encryption policy and DLP leaves sensitive data exposed to both internal and external threats.

---

### CIS Control 4 — Secure Configuration of Enterprise Assets and Software

**IG2 Safeguards Required:** 4.1 (establish and maintain a secure configuration process), 4.2 (establish and maintain a secure configuration process for network infrastructure), 4.3 (configure automatic session locking), 4.4 (implement and manage a firewall on servers), 4.5 (implement and manage a firewall on end-user devices), 4.6 (securely manage enterprise assets and software), 4.7 (manage default accounts), 4.8 (uninstall or disable unnecessary services), 4.9 (configure trusted DNS servers), 4.10 (enforce automatic device lockout), 4.11 (enforce remote wipe capability), 4.12 (separate enterprise workspaces on mobile end-user devices)

| Current State | Gap | Risk |
|---|---|---|
| Basic firewall exists; no configuration hardening program described | No documented secure baselines (CIS Benchmarks); no process to manage default accounts, disable unnecessary services, or verify hardened configurations | Medium-High |

**Detail:** A "basic firewall" with no documented ruleset review process does not meet IG2. Secure configuration requires documented baselines applied consistently to all asset types, with a process to detect and remediate drift. Default credentials on networking gear and servers are a top attack vector.

---

### CIS Control 5 — Account Management

**IG2 Safeguards Required:** 5.1 (establish and maintain an inventory of accounts), 5.2 (use unique passwords), 5.3 (disable dormant accounts), 5.4 (restrict administrator privileges to dedicated administrator accounts), 5.5 (establish and maintain an inventory of service accounts), 5.6 (centralize account management)

| Current State | Gap | Risk |
|---|---|---|
| No account management controls described | No formal account inventory, no documented policy for dormant account disablement, admin privilege usage unknown | High |

**Detail:** Privileged account abuse and credential theft are primary ransomware vectors. IG2 requires a formal, maintained account inventory and strict separation of admin from standard user accounts.

---

### CIS Control 6 — Access Control Management

**IG2 Safeguards Required:** 6.1 (establish an access granting process), 6.2 (establish an access revoking process), 6.3 (require MFA for externally-exposed applications), 6.4 (require MFA for remote network access), 6.5 (require MFA for administrative access), 6.6 (establish and maintain an inventory of authentication and authorization systems), 6.7 (centralize access control), 6.8 (define and maintain role-based access control)

| Current State | Gap | Risk |
|---|---|---|
| No MFA on VPN (explicitly stated); MFA status on other systems unknown | **Critical gap:** VPN lacks MFA (Safeguard 6.4). Admin MFA (6.5) status unknown. No formal access provisioning/revocation process described. No RBAC documentation. | **CRITICAL** |

**Detail:** This is your single highest-priority gap. VPN without MFA is the most common ransomware entry point for mid-size organizations. A stolen or phished credential provides direct network access. Safeguard 6.4 is unambiguous: MFA is required for all remote network access. This gap alone is sufficient to invalidate IG2 compliance status.

---

### CIS Control 7 — Continuous Vulnerability Management

**IG2 Safeguards Required:** 7.1 (establish and maintain a vulnerability management process), 7.2 (establish and maintain a remediation process), 7.3 (perform automated operating system patch management), 7.4 (perform automated application patch management), 7.5 (perform automated vulnerability scans of internal enterprise assets), 7.6 (perform automated vulnerability scans of externally-exposed enterprise assets), 7.7 (remediate detected vulnerabilities)

| Current State | Gap | Risk |
|---|---|---|
| Monthly Windows patching exists (partial credit for 7.3); no vulnerability scanner | No vulnerability scanner (gaps 7.5 and 7.6); no application patch management described; no formal remediation process or SLA; no external attack surface scanning | **Critical** |

**Detail:** Monthly OS patching addresses one patch category but leaves application vulnerabilities (browsers, Office, third-party tools, OT software) unaddressed. Without a scanner (e.g., Tenable Nessus, Qualys, Rapid7), you have no visibility into what vulnerabilities exist on your network. IG2 requires both internal and external automated scanning.

---

### CIS Control 8 — Audit Log Management

**IG2 Safeguards Required:** 8.1 (establish and maintain an audit log management process), 8.2 (collect audit logs), 8.3 (ensure adequate audit log storage), 8.4 (standardize time synchronization), 8.5 (collect detailed audit logs), 8.6 (collect DNS query audit logs), 8.7 (collect URL request audit logs), 8.8 (collect command-line audit logs), 8.9 (centralize audit logs), 8.10 (retain audit logs), 8.11 (conduct audit log reviews), 8.12 (collect service provider logs)

| Current State | Gap | Risk |
|---|---|---|
| Windows Event Viewer on individual servers only | No centralized log management; no SIEM; logs are siloed per server and likely overwritten; no log review process; no network device, DNS, or firewall log collection; retention policy unknown | **Critical** |

**Detail:** Decentralized Windows Event Viewer provides no actionable detection capability. You cannot correlate events across systems, you will lose logs when servers are reloaded or when storage fills, and you have no ability to detect lateral movement, privilege escalation, or data exfiltration in progress. IG2 requires centralized collection (Safeguard 8.9) and a defined retention period. This gap also means you likely cannot reconstruct what happened after a security incident.

---

### CIS Control 9 — Email and Web Browser Protections

**IG2 Safeguards Required:** 9.1 (ensure use of only fully supported browsers and email clients), 9.2 (use DNS filtering services), 9.3 (maintain and enforce network-based URL filters), 9.4 (restrict unnecessary or unauthorized browser and email client extensions), 9.5 (implement DMARC), 9.6 (block unnecessary file types), 9.7 (deploy and maintain email server anti-malware protections)

| Current State | Gap | Risk |
|---|---|---|
| No email/web protections described | DNS filtering, DMARC, URL filtering, and email anti-malware status all unknown — assumed absent | High |

**Detail:** Phishing is the primary initial access vector for manufacturing ransomware attacks. DMARC prevents domain spoofing. DNS filtering and URL filtering block malicious sites. These controls are inexpensive and highly effective.

---

### CIS Control 10 — Malware Defenses

**IG2 Safeguards Required:** 10.1 (deploy and maintain anti-malware software), 10.2 (configure automatic anti-malware signature updates), 10.3 (disable autorun and autoplay for removable media), 10.4 (configure automatic anti-malware scanning of removable media), 10.5 (enable anti-exploitation features), 10.6 (centrally manage anti-malware software), 10.7 (use behavior-based anti-malware software)

| Current State | Gap | Risk |
|---|---|---|
| Antivirus on all endpoints (partial credit for 10.1) | Central management of AV console status unknown; behavior-based/EDR capability unknown; autorun configuration unknown; anti-exploitation features (e.g., Windows Defender Exploit Guard) status unknown | Medium |

**Detail:** Traditional signature-based AV alone does not meet IG2. IG2 expects behavior-based detection (EDR-class capabilities), centralized management, and anti-exploitation features enabled. If your AV is legacy signature-only, this is a meaningful gap.

---

### CIS Control 11 — Data Recovery

**IG2 Safeguards Required:** 11.1 (establish and maintain a data recovery process), 11.2 (perform automated backups), 11.3 (protect recovery data), 11.4 (establish and maintain an isolated instance of recovery data), 11.5 (test data recovery)

| Current State | Gap | Risk |
|---|---|---|
| No backup/recovery controls described | Backup posture entirely unknown; no mention of tested, isolated, or immutable backups | High |

**Detail:** For manufacturing, ransomware that encrypts production systems and backups is an existential threat. IG2 requires automated backups, offline or immutable copies, and tested restoration. Untested backups frequently fail at the worst possible moment.

---

### CIS Control 12 — Network Infrastructure Management

**IG2 Safeguards Required:** 12.1 (ensure network infrastructure is up-to-date), 12.2 (establish and maintain a secure network architecture), 12.3 (securely manage network infrastructure), 12.4 (establish and maintain architecture diagram(s)), 12.5 (centralize network authentication, authorization, and auditing), 12.6 (use of secure network management and communication protocols), 12.7 (ensure remote devices utilize a VPN and are connecting to an infrastructure's AAA), 12.8 (establish and maintain dedicated computing resources for all administrative work)

| Current State | Gap | Risk |
|---|---|---|
| Basic firewall exists; no architecture documentation described | No network architecture diagram; no network segmentation described; no out-of-band management; no documented firewall ruleset review process | High |

**Detail:** Manufacturing environments often mix IT and OT/ICS networks. Without documented segmentation, a compromised workstation can directly reach production control systems. IG2 requires a documented, defensible network architecture.

---

### CIS Control 13 — Network Monitoring and Defense

**IG2 Safeguards Required:** 13.1 (centralize security event alerting), 13.2 (deploy a host-based intrusion detection solution), 13.3 (deploy a network intrusion detection solution), 13.4 (perform traffic filtering between network segments), 13.5 (manage access control for remote assets), 13.6 (collect network traffic flow logs), 13.7 (deploy a host-based intrusion prevention solution), 13.8 (deploy a network intrusion prevention solution), 13.9 (deploy port-level access control), 13.10 (perform application layer filtering), 13.11 (tune security event alerting thresholds)

| Current State | Gap | Risk |
|---|---|---|
| No network monitoring described | No IDS/IPS, no SIEM alerting, no network flow logging, no application layer filtering | High |

**Detail:** Without network monitoring, intrusions go undetected. The average dwell time for ransomware actors (time between initial access and detonation) is measured in days to weeks — all of which would be invisible to your current environment.

---

### CIS Control 14 — Security Awareness and Skills Training

**IG2 Safeguards Required:** 14.1 (establish and maintain a security awareness program), 14.2 (train workforce members to recognize social engineering attacks), 14.3 (train workforce members on authentication best practices), 14.4 (train workforce members on data handling best practices), 14.5 (train workforce members on causes of unintentional data exposure), 14.6 (train workforce members on recognizing and reporting security incidents), 14.7 (train workforce members on how to identify and report if their enterprise assets are missing security updates), 14.8 (train workforce members on the dangers of connecting to and transmitting enterprise data over insecure networks), 14.9 (conduct role-specific security awareness and skills training)

| Current State | Gap | Risk |
|---|---|---|
| Annual security training exists (partial credit for 14.1) | Annual frequency is insufficient for IG2; no phishing simulations described; no role-specific training; training content scope unknown | Medium |

**Detail:** Annual training satisfies the minimum IG1 bar but not IG2. IG2 expects more frequent training, phishing simulation exercises, and role-specific content (e.g., additional training for IT staff, finance staff who handle wire transfers, and executives). Phishing simulation is one of the highest-ROI controls available.

---

### CIS Control 15 — Service Provider Management

**IG2 Safeguards Required:** 15.1 (establish and maintain an inventory of service providers), 15.2 (establish and maintain a service provider management policy), 15.3 (classify service providers), 15.4 (ensure service provider contracts include security requirements), 15.5 (assess service providers), 15.6 (monitor service providers), 15.7 (securely decommission service providers)

| Current State | Gap | Risk |
|---|---|---|
| No third-party/vendor management described | No vendor inventory, no security requirements in contracts, no third-party risk assessment process | Medium |

**Detail:** Manufacturing supply chains are a major attack vector (e.g., compromised software updates, vendor remote access). IG2 requires a formal vendor risk program.

---

### CIS Control 16 — Application Software Security

**IG2 Safeguards Required:** 16.1 (establish and maintain a secure application development process), 16.2 (establish and maintain a process to accept and address software vulnerabilities), 16.3 (perform root cause analysis on security vulnerabilities), 16.4 (establish and maintain a process for receiving and addressing security vulnerability reports), 16.5 (use up-to-date and trusted third-party software components), 16.6 (establish and maintain a severity rating system and process for application vulnerabilities), 16.7 (use standard hardening configuration templates for application infrastructure), 16.8 (separate production and non-production systems), 16.9 (train developers in application security concepts and secure coding), 16.10 (apply secure design principles in application architectures), 16.11 (leverage vetted modules or services for application security components), 16.12 (implement code-level security checks), 16.13 (conduct application penetration testing), 16.14 (conduct threat modeling for sensitive applications)

| Current State | Gap | Risk |
|---|---|---|
| No application security program described | Assumed gap across all IG2 safeguards | Medium |

**Detail:** If your organization runs or customizes business applications (ERP, MES, WMS), application security practices are required. If you are purely a consumer of COTS software, the scope is reduced but vendor patch management still applies.

---

### CIS Control 17 — Incident Response Management

**IG2 Safeguards Required:** 17.1 (designate personnel to manage incident handling), 17.2 (establish and maintain contact information for reporting security incidents), 17.3 (establish and maintain an enterprise process for reporting incidents), 17.4 (establish and maintain an incident response process), 17.5 (assign key roles and responsibilities), 17.6 (define mechanisms for communicating during incident response), 17.7 (conduct routine incident response exercises), 17.8 (conduct post-incident reviews), 17.9 (establish and maintain security incident thresholds)

| Current State | Gap | Risk |
|---|---|---|
| No incident response program described | No documented IR plan, no defined roles, no exercises, no external contact relationships (e.g., law enforcement, IR retainer) | High |

**Detail:** Without a tested IR plan, your response to a ransomware event will be improvised, slow, and expensive. IG2 requires a documented plan with defined roles, communication procedures, and regular exercises. Manufacturing downtime costs during a ransomware recovery are typically measured in tens to hundreds of thousands of dollars per day.

---

### CIS Control 18 — Penetration Testing

**IG2 Safeguards Required:** 18.1 (establish and maintain a penetration testing program), 18.2 (perform periodic external penetration tests), 18.3 (remediate penetration test findings), 18.4 (validate security measures), 18.5 (perform periodic internal penetration tests)

| Current State | Gap | Risk |
|---|---|---|
| No penetration testing described | No external or internal pen testing; no validation of security controls | Medium |

**Detail:** Penetration testing provides independent validation that your controls actually work. IG2 requires periodic external and internal tests. For a company of your size, an annual external test plus periodic internal assessments is standard.

---

## Prioritized Gap Summary

### Tier 1 — Critical: Address Within 30 Days

These gaps represent the highest probability of a significant security incident causing business disruption.

| Priority | Control | Gap | Recommended Action |
|---|---|---|---|
| 1 | CIS 6.4 | No MFA on VPN | Deploy MFA immediately. Microsoft Authenticator (if using Azure AD/Entra), Duo Security, or similar. Cost is low; impact is very high. This is your single most exploitable gap. |
| 2 | CIS 8.9 | No centralized log management | Deploy a SIEM or log aggregator (e.g., Wazuh (free/OSS), Microsoft Sentinel, Graylog). At minimum, centralize Windows Event logs, firewall logs, and VPN logs. Configure 90-day online retention. |
| 3 | CIS 7.5/7.6 | No vulnerability scanner | Deploy an authenticated vulnerability scanner (Tenable Nessus Essentials is free for up to 32 IPs; Nessus Professional or Rapid7 InsightVM for full coverage). Run weekly internal scans and monthly external scans. |

---

### Tier 2 — High: Address Within 60–90 Days

| Priority | Control | Gap | Recommended Action |
|---|---|---|---|
| 4 | CIS 11 | Backup posture unknown | Implement or verify: automated daily backups, at least one offline or immutable copy (e.g., Azure Blob with immutability, Veeam with hardened repository), and quarterly tested restoration exercises. |
| 5 | CIS 17 | No incident response plan | Develop a written IR plan covering ransomware, data breach, and OT disruption scenarios. Assign roles. Conduct a tabletop exercise. Establish an IR retainer with a reputable DFIR firm. |
| 6 | CIS 1 & 2 | No asset/software inventory | Deploy a network discovery and asset inventory tool (e.g., Lansweeper, Qualys CSAM, or even a well-maintained spreadsheet fed by DHCP logs as a start). Integrate with patch management. |
| 7 | CIS 10 | AV without EDR capability | Evaluate upgrading to an EDR solution (Microsoft Defender for Endpoint (included in M365 Business Premium), CrowdStrike Falcon Go, SentinelOne). EDR provides behavioral detection that signature AV misses. |
| 8 | CIS 9.5 | DMARC not described | Implement DMARC (with SPF and DKIM) on your email domain. Start in monitoring mode (p=none), progress to p=quarantine, then p=reject. This blocks domain spoofing and phishing that uses your brand. |

---

### Tier 3 — Medium: Address Within 90–180 Days

| Priority | Control | Gap | Recommended Action |
|---|---|---|---|
| 9 | CIS 4 | No secure configuration baselines | Adopt CIS Benchmarks for Windows, your firewall/router, and any server OS. Use Group Policy or Intune to enforce baseline settings. Document and track configuration drift. |
| 10 | CIS 5 | No formal account management | Audit all accounts (disable dormant ones immediately). Enforce a policy: admin accounts separate from daily-use accounts. Document and inventory service accounts. |
| 11 | CIS 12 | No network segmentation documented | Map your network. Identify where OT/ICS systems connect to IT. Implement VLAN segmentation to isolate production systems, guest networks, and corporate systems. Document the architecture. |
| 12 | CIS 14 | Annual training only | Increase training frequency to quarterly. Add phishing simulations (KnowBe4, Proofpoint Security Awareness, or Microsoft Attack Simulator). Add role-specific training for IT, finance, and leadership. |
| 13 | CIS 9.2/9.3 | No DNS/URL filtering | Deploy DNS filtering (Cisco Umbrella, Cloudflare Gateway, or DNSFilter). This is a high-ROI, low-friction control that blocks malware callbacks and phishing sites. |
| 14 | CIS 6.5 | Admin MFA status unknown | Confirm and enforce MFA for all administrative access — servers, network devices, cloud consoles, security tools. |
| 15 | CIS 15 | No vendor risk program | Create a vendor inventory. Add security requirements to new contracts. Request SOC 2 reports or security questionnaires from critical vendors. Control and log all vendor remote access. |

---

### Tier 4 — Longer-Term: Address Within 6–12 Months

| Priority | Control | Gap |
|---|---|---|
| 16 | CIS 13 | Deploy IDS/IPS or NDR capability |
| 17 | CIS 3 | Develop formal data classification and DLP program |
| 18 | CIS 18 | Establish annual external penetration testing program |
| 19 | CIS 16 | Application security practices for any custom/configured applications |
| 20 | CIS 7.4 | Formalize application patch management (browsers, Office, third-party tools) |

---

## Resource Considerations for a 5-Person IT Team

Given your team size, prioritize controls that provide maximum coverage with minimal ongoing operational burden:

- **Free/low-cost tools to deploy first:** Wazuh (SIEM), Nessus Essentials (vulnerability scanner), Duo (MFA — free tier supports up to 10 users, then tiered pricing), DMARC/SPF/DKIM (configuration change only), Windows Defender for Endpoint (included with Microsoft 365 Business Premium if you use it)

- **Highest ROI controls for a small IT team:** MFA everywhere, centralized logging, vulnerability scanning, EDR, and DNS filtering provide the most risk reduction per hour of effort

- **Consider managed services for:** SIEM (managed SOC/MDR), IR retainer (DFIR firm), and annual pen testing — these are appropriate to outsource given team size

- **Quick wins your team can complete in a week:** Enable MFA on VPN (1–2 days), deploy DMARC monitoring mode (2–4 hours), disable dormant accounts (1 day), review and restrict firewall rules (1 day)

---

## Compliance Score Estimate

| CIS Control | IG2 Safeguards | Estimated Current Compliance |
|---|---|---|
| 1 — Asset Inventory | ~5 safeguards | ~10% |
| 2 — Software Inventory | ~7 safeguards | ~10% |
| 3 — Data Protection | ~13 safeguards | ~5% |
| 4 — Secure Configuration | ~12 safeguards | ~25% |
| 5 — Account Management | ~6 safeguards | ~15% |
| 6 — Access Control | ~8 safeguards | ~15% (MFA gap is disqualifying) |
| 7 — Vulnerability Management | ~7 safeguards | ~20% (patching only) |
| 8 — Audit Log Management | ~12 safeguards | ~10% |
| 9 — Email/Web Protections | ~7 safeguards | ~10% |
| 10 — Malware Defenses | ~7 safeguards | ~40% (AV present) |
| 11 — Data Recovery | ~5 safeguards | Unknown/~10% |
| 12 — Network Infrastructure | ~8 safeguards | ~20% |
| 13 — Network Monitoring | ~11 safeguards | ~5% |
| 14 — Security Training | ~9 safeguards | ~30% (annual training) |
| 15 — Service Provider Mgmt | ~7 safeguards | ~5% |
| 16 — Application Security | ~14 safeguards | ~10% |
| 17 — Incident Response | ~9 safeguards | ~5% |
| 18 — Penetration Testing | ~5 safeguards | ~0% |
| **Overall Estimate** | **~161 IG2 safeguards** | **~15–20% compliant** |

---

## Conclusion

Your organization has the basic hygiene controls of an IG1 organization but is substantially below the IG2 bar. The three most urgent and impactful actions are:

1. **Deploy MFA on the VPN** — this single action closes your most likely ransomware entry point
2. **Stand up centralized log management** — you currently have no ability to detect or investigate incidents
3. **Run an authenticated vulnerability scan** — you do not know what vulnerabilities exist on your network

A manufacturing company of your size and profile is actively targeted by ransomware groups. The controls above, implemented in priority order, will significantly reduce your risk exposure and bring you into reasonable alignment with CIS IG2 over a 12-month period.

# CIS Controls v8: Multi-Factor Authentication (MFA) Safeguards

## MFA Safeguards in CIS Controls v8

CIS Controls v8 contains three explicit MFA safeguards, all residing in **CIS Control 6: Access Control Management**. All three are assigned to **Implementation Group 2 (IG2)**, meaning they are required for organizations with dedicated IT staff, sensitive data, and moderate risk tolerance. They are not part of the IG1 (essential hygiene) baseline.

---

## The Three MFA Safeguards

| Safeguard ID | Title | IG Level | Asset Type | Security Function |
|-------------|-------|----------|-----------|------------------|
| **6.3** | Require MFA for Externally-Exposed Applications | IG2 | Users | Protect |
| **6.4** | Require MFA for Remote Network Access | IG2 | Users | Protect |
| **6.5** | Require MFA for Administrative Access | IG2 | Users | Protect |

### CIS Control 6, Safeguard 6.3 — Require MFA for Externally-Exposed Applications

**IG Level:** IG2

**Scope:** All SaaS platforms, web portals, cloud management consoles, webmail, and any application reachable from the public internet.

**What it requires:** Every user authenticating to an externally-exposed application must use a second factor beyond their password. This includes corporate SaaS tools (Microsoft 365, Google Workspace, Salesforce, etc.), customer-facing portals, and any web application accessible without a VPN.

**Implementation note from CIS:** Phishing-resistant MFA (FIDO2/passkeys) is the preferred approach. SMS OTP is considered an acceptable but weaker fallback.

---

### CIS Control 6, Safeguard 6.4 — Require MFA for Remote Network Access

**IG Level:** IG2

**Scope:** VPN connections, Remote Desktop Protocol (RDP) gateways, SSH access to internal systems, and any mechanism that extends network-layer access to remote workers or third parties.

**What it requires:** Remote connectivity into the enterprise network must require MFA at the authentication step — not just at the VPN client but enforced by the authentication server (AAA infrastructure). Safeguard 12.7 reinforces this by requiring that remote devices connect through VPN with AAA.

---

### CIS Control 6, Safeguard 6.5 — Require MFA for Administrative Access

**IG Level:** IG2

**Scope:** All administrative console access — Active Directory, Azure/Entra ID, cloud management planes (AWS Console, Azure Portal, GCP Console), network device management, security tools, and any privileged management interface.

**What it requires:** Administrative accounts must authenticate with MFA for every session. This is the highest-priority MFA safeguard because compromised admin accounts enable lateral movement, ransomware deployment, and full domain takeover. CIS explicitly calls for phishing-resistant MFA (FIDO2/hardware keys) for privileged users.

---

## Implementation Group Context

MFA safeguards first appear at **IG2**. This does not mean IG1 organizations can ignore MFA entirely — Safeguard 5.2 (IG1) notes that passwords of at least 14 characters are required "or MFA required," and Safeguard 5.4 (IG1) restricts admin privileges to dedicated admin accounts, which pairs with MFA at IG2. However, the formal MFA mandate begins at IG2.

| IG | MFA Requirement |
|----|----------------|
| IG1 (56 safeguards) | No explicit MFA mandate; strong passwords (14+ chars) required; admin account separation required |
| IG2 (130 total safeguards) | MFA required for external apps (6.3), remote access (6.4), and admin access (6.5) |
| IG3 (153 total safeguards) | All IG2 MFA requirements apply; phishing-resistant MFA strongly emphasized for privileged access |

---

## SMS OTP vs. Phishing-Resistant MFA in the CIS Controls Context

CIS Controls v8 does not prohibit SMS OTP, but it explicitly recommends phishing-resistant MFA as the preferred approach. The distinction is critical for understanding implementation quality:

### SMS OTP (One-Time Password via Text Message)

**How it works:** A six- or eight-digit code is sent to the user's registered phone number. The user enters this code as the second factor.

**Weaknesses acknowledged by CIS:**
- **SIM swapping:** Attackers socially engineer mobile carriers to transfer a victim's phone number to an attacker-controlled SIM, intercepting all SMS codes.
- **Real-time phishing:** Adversary-in-the-middle (AiTM) proxy attacks (e.g., Evilginx, Modlishka) capture the OTP code in real time and replay it to the legitimate service before it expires.
- **SS7 vulnerabilities:** Telecommunications protocol weaknesses can allow interception of SMS messages at the carrier level.
- **Malware:** Mobile malware can intercept SMS messages on the device before the user reads them.

**CIS position:** SMS OTP satisfies the letter of Safeguards 6.3, 6.4, and 6.5 but is identified as a common implementation pitfall when used for privileged access. The implementation guidance explicitly flags "SMS OTP used for privileged access" as a gap requiring remediation.

---

### Phishing-Resistant MFA (CIS Preferred Approach)

**What it means:** Authentication mechanisms that are cryptographically bound to the specific origin (domain) being accessed, making it impossible for an attacker to use a captured credential against a different site or at a different time.

**CIS-recommended technologies:**

| Technology | Description | Use Case |
|-----------|-------------|----------|
| **FIDO2 / WebAuthn** | Hardware or platform authenticator; cryptographic challenge/response bound to the registered origin | Web applications, cloud consoles |
| **Passkeys** | FIDO2 credential stored on device (biometric-protected); synced across devices via platform (Apple, Google, Microsoft) | Consumer-friendly phishing-resistant MFA |
| **Hardware Security Keys** | Physical devices (YubiKey, Google Titan, Token2); FIDO2/U2F; require physical presence | Privileged users, admin accounts |
| **Smart Card / PIV** | Certificate-based authentication; common in government and regulated industries | Enterprise, federal environments |

**Why phishing-resistant MFA defeats AiTM attacks:** The authentication response is cryptographically signed with the exact origin URL. A phishing site at `microsoft-login.attacker.com` cannot use a credential registered at `login.microsoft.com` — the origin binding check fails. The attacker intercepts nothing reusable.

---

## Recommended MFA Deployment Tiers (Aligned to CIS Safeguards)

| Access Type | Safeguard | Minimum Acceptable | CIS Preferred |
|-------------|----------|-------------------|---------------|
| External SaaS / Web apps | 6.3 | Authenticator app TOTP (e.g., Microsoft Authenticator, Google Authenticator) | FIDO2 / Passkeys |
| Remote network / VPN | 6.4 | TOTP or push notification | FIDO2 hardware key |
| Administrative / Privileged | 6.5 | Authenticator app TOTP | FIDO2 hardware key (YubiKey, Titan) |
| General workforce (IG1 recommendation) | 5.2 (password quality) | Strong password (14+ chars) | Passkeys to eliminate password |

**Note on push notification MFA (e.g., Microsoft Authenticator "Approve/Deny"):** This is more resistant than SMS OTP because it does not involve a code that can be intercepted. However, it is vulnerable to "MFA fatigue" attacks where attackers send repeated push requests hoping the user approves one. Number-matching and additional context features (location, app name) in modern authenticator apps substantially mitigate this risk. Push MFA is acceptable for Safeguard 6.3 and 6.4 but phishing-resistant MFA remains preferred for 6.5 (admin access).

---

## Common Pitfall: MFA Deployment Gaps

The CIS implementation guidance specifically identifies MFA deployment gaps as a top pitfall:

> **Problem:** MFA enabled on some systems but not others; SMS OTP used for privileged access.
> **Solution:** Comprehensive MFA inventory; phishing-resistant MFA for privileged and external access.

A complete MFA deployment covering all three IG2 safeguards requires:
1. Inventory of all externally-exposed applications (for 6.3)
2. Inventory of all remote access methods (for 6.4)
3. Inventory of all administrative accounts and consoles (for 6.5)
4. Enforcement via identity provider policy (Azure AD/Entra ID Conditional Access, Okta Policies, Google Workspace security policies) — not just user awareness

---

## Related Safeguards That Support MFA

| Safeguard | IG | Relevance to MFA |
|----------|-----|-----------------|
| 5.4 — Restrict Administrator Privileges to Dedicated Admin Accounts | IG1 | Ensures admin accounts exist as separate identities to apply MFA to |
| 5.6 — Centralize Account Management | IG2 | Single IdP (Azure AD, Okta) enables consistent MFA policy enforcement |
| 6.6 — Maintain an Inventory of Authentication/Authorization Systems | IG2 | Identifies all systems where MFA must be evaluated and enforced |
| 6.7 — Centralize Access Control | IG2 | SSO with MFA enforcement prevents MFA bypass through direct application access |
| 14.3 — Train Workforce on Authentication Best Practices | IG1 | Trains users to recognize MFA fatigue attacks and phishing attempts targeting MFA |

---

## Summary

- **Three safeguards require MFA in CIS Controls v8:** 6.3, 6.4, and 6.5 — all at IG2.
- **Scope of coverage:** Externally-exposed applications, remote network access, and administrative access respectively.
- **SMS OTP:** Technically satisfies the safeguard requirements but is explicitly flagged as insufficient for privileged access due to SIM swapping and AiTM phishing vulnerabilities.
- **Phishing-resistant MFA (FIDO2/hardware keys/passkeys):** The CIS-preferred implementation, cryptographically bound to the authentication origin and immune to real-time phishing interception. Required for IG3 privileged users; strongly recommended at IG2.
- **IG1 organizations** have no explicit MFA mandate but should implement MFA voluntarily, particularly for any admin accounts or externally-facing systems, as it is the single highest-impact control for preventing account compromise.

# CIS Controls v8 — Multi-Factor Authentication (MFA) Safeguards

## 1. Safeguards That Explicitly Require MFA

CIS Controls v8 addresses MFA primarily within **Control 6: Access Control Management**. The two safeguards that directly mandate MFA are:

---

### Safeguard 6.3 — Require MFA for Externally-Exposed Applications

| Attribute | Detail |
|-----------|--------|
| **Safeguard ID** | 6.3 |
| **Full Title** | Require MFA for Externally-Exposed Applications |
| **Implementation Group** | IG1 (foundational — applies to ALL organizations) |
| **Asset Type** | Users |
| **Security Function** | Protect |

**Description:** Require all externally-exposed enterprise or third-party applications to enforce MFA, where supported. Externally-exposed applications include those reachable from the internet, including web-based services, remote access portals, cloud services, SaaS applications, and any internet-facing systems. Because this is an IG1 control, it is considered a basic cyber hygiene requirement that every organization — regardless of size or resources — should implement.

---

### Safeguard 6.4 — Require MFA for Remote Network Access

| Attribute | Detail |
|-----------|--------|
| **Safeguard ID** | 6.4 |
| **Full Title** | Require MFA for Remote Network Access |
| **Implementation Group** | IG1 (foundational — applies to ALL organizations) |
| **Asset Type** | Users |
| **Security Function** | Protect |

**Description:** Require MFA for all remote network access (e.g., VPN, dial-up, and other forms of network access from outside the enterprise perimeter). This safeguard recognizes that remote access is a high-risk entry point and that credential theft alone should not be sufficient for an attacker to gain network-level access. Like 6.3, this is an IG1 requirement.

---

### Safeguard 6.5 — Require MFA for Administrative Access

| Attribute | Detail |
|-----------|--------|
| **Safeguard ID** | 6.5 |
| **Full Title** | Require MFA for Administrative Access |
| **Implementation Group** | IG2 (applies to organizations with moderate IT resources and risk) |
| **Asset Type** | Users |
| **Security Function** | Protect |

**Description:** Require MFA for all administrative access accounts, where supported, on all enterprise assets, whether managed on-site or through a third-party provider. Administrative accounts have elevated privileges, making them a prime target for attackers. This safeguard extends MFA to privileged users and is an IG2 requirement, meaning it is expected of organizations with dedicated security personnel and a higher risk profile.

---

## 2. Summary Table of MFA Safeguards

| Safeguard ID | Title | Implementation Group | Scope |
|---|---|---|---|
| 6.3 | Require MFA for Externally-Exposed Applications | **IG1** | Internet-facing apps, SaaS, cloud portals |
| 6.4 | Require MFA for Remote Network Access | **IG1** | VPN, remote access, dial-up |
| 6.5 | Require MFA for Administrative Access | **IG2** | Admin/privileged accounts on all assets |

---

## 3. Implementation Group Levels Explained

CIS Controls v8 introduced three Implementation Groups (IGs) to help organizations prioritize controls based on their risk profile and resources:

- **IG1 (Basic Cyber Hygiene):** Applies to all organizations. These are the minimum controls every enterprise should have. Safeguards 6.3 and 6.4 fall here, reflecting that MFA for external apps and remote access is non-negotiable regardless of organization size.
- **IG2 (Foundational):** Applies to organizations with dedicated IT/security staff handling sensitive data or providing critical services. Safeguard 6.5 falls here because privileged account MFA requires more mature identity management capabilities.
- **IG3 (Organizational):** Applies to large enterprises or those in critical infrastructure. IG3 organizations implement all safeguards from IG1 and IG2 plus additional advanced controls.

---

## 4. Types of MFA Recommended by CIS Controls

CIS Controls v8 does not prescribe a single MFA method but distinguishes between methods based on their security strength. CIS guidance (including the companion CIS Benchmarks and the CIS Controls Implementation Guide) recommends **phishing-resistant MFA** wherever feasible, and acknowledges that weaker MFA methods like SMS OTP provide some protection but are insufficient against sophisticated threats.

### MFA Methods Referenced and Recommended

**a) Phishing-Resistant MFA (Strongly Recommended)**

These methods are bound to the specific relying party (website/application) and cannot be intercepted or replayed via phishing:

- **FIDO2/WebAuthn hardware security keys** (e.g., YubiKey, Google Titan Key): Uses public-key cryptography. The private key never leaves the device. Authentication is domain-bound, so a phishing site cannot capture a usable credential.
- **Platform authenticators using FIDO2** (e.g., Windows Hello, Apple Face ID/Touch ID with passkeys): Built into the device, cryptographically bound to the origin. No shared secret to steal.
- **PIV/CAC smart cards**: Certificate-based authentication used widely in government contexts (DoD, federal agencies). Cryptographically strong and phishing-resistant.
- **Passkeys**: A modern implementation of FIDO2 credentials, increasingly adopted by major platforms. Phishing-resistant by design.

**b) Time-Based One-Time Passwords (TOTP) / Authenticator Apps (Acceptable, Not Phishing-Resistant)**

- **Examples:** Google Authenticator, Microsoft Authenticator, Authy
- **Mechanism:** Generates a 6–8 digit code that rotates every 30 seconds using a shared secret (TOTP per RFC 6238).
- **Security level:** Stronger than static passwords and SMS, but **not phishing-resistant** — an attacker can use a real-time phishing proxy to capture the TOTP code during login and replay it immediately.

**c) SMS One-Time Passwords (Weakest MFA — Discouraged)**

- **Mechanism:** A numeric code is sent via SMS to the user's registered phone number.
- **Vulnerabilities:** Subject to SIM swapping, SS7 protocol attacks, and real-time phishing interception. NIST SP 800-63B deprecated SMS OTP as a primary authenticator in 2017. CIS guidance aligns with NIST and advises against relying on SMS OTP where better options exist.
- **Use case:** CIS acknowledges SMS OTP may be used where no better option exists (e.g., legacy systems), but it is the least preferred method.

**d) Push Notifications (Acceptable, but Vulnerable to MFA Fatigue)**

- **Examples:** Microsoft Authenticator push, Duo Security push
- **Mechanism:** App sends a push notification; user approves on their phone.
- **Vulnerability:** Susceptible to **MFA fatigue attacks** (adversary-in-the-middle sends repeated push requests until user accidentally approves). Number matching and additional context are mitigations.

---

## 5. SMS OTP vs. Phishing-Resistant MFA in the CIS Controls Context

### SMS OTP (One-Time Password via Text Message)

**How it works:** When a user logs in, the server generates a short numeric code and transmits it via the public SMS network to the user's mobile phone number. The user then types this code into the authentication prompt.

**Weaknesses in the CIS Controls context:**

1. **SIM Swapping:** An attacker socially engineers a mobile carrier into transferring the victim's phone number to a SIM card the attacker controls. All subsequent SMS messages — including MFA codes — are delivered to the attacker.
2. **SS7 Protocol Attacks:** The Signaling System No. 7 (SS7) protocol, which underpins the global telephone network, has well-documented vulnerabilities that allow interception and redirection of SMS messages by well-resourced attackers.
3. **Real-Time Phishing (Adversary-in-the-Middle / AiTM):** A phishing site proxies the login to the real site in real time. The victim enters their password on the phishing site; the attacker simultaneously submits it to the real site, triggering an SMS OTP to the victim. The victim enters the OTP on the phishing site; the attacker relays it to the real site. The attacker achieves full session access.
4. **Malware:** On a compromised device, malware can read incoming SMS messages and exfiltrate the OTP silently.

**CIS Stance:** SMS OTP satisfies the letter of safeguards 6.3, 6.4, and 6.5 (technically it is "MFA") but CIS explicitly recommends stronger alternatives. Organizations relying solely on SMS OTP should treat it as a transitional measure while migrating to stronger methods.

---

### Phishing-Resistant MFA

**How it works:** Phishing-resistant MFA uses **cryptographic binding between the authenticator and the specific origin (domain)**. The most prominent example is FIDO2/WebAuthn:

1. During registration, the authenticator (hardware key or platform) generates a **unique public/private key pair** for the specific relying party (RP) origin.
2. The private key **never leaves the authenticator**.
3. During authentication, the server sends a **challenge**. The authenticator signs it using the private key. Critically, this signing operation is **origin-bound** — the authenticator checks that the origin (domain) in the request matches the registered origin before signing.
4. If a user is phished to `bank-login-secure.evil.com` instead of `bank.com`, the authenticator **refuses to sign** because the origin does not match.

**Why this defeats phishing:**

- Even if an attacker tricks a user into visiting a phishing site, **there is no code to intercept** — the credential is cryptographic and domain-bound.
- There is no shared secret (like an OTP) that can be captured and replayed.
- Real-time AiTM attacks fail because the cryptographic assertion from the authenticator is tied to the legitimate origin, not the attacker's proxy.

**CIS Controls alignment:**

- CIS Controls v8 guidance documents, the CIS Controls Implementation Guide, and the associated CIS Benchmarks increasingly reference FIDO2 and phishing-resistant MFA as the gold standard.
- For IG3 organizations and those in high-risk sectors (financial services, healthcare, critical infrastructure), phishing-resistant MFA is effectively expected.
- CISA's "Phishing-Resistant MFA" guidance (which CIS aligns with) explicitly recommends FIDO2/WebAuthn or PKI-based methods and deprecates SMS OTP.

---

## 6. Practical Recommendations by Implementation Group

| Implementation Group | Recommended MFA Approach |
|---|---|
| **IG1** | At minimum, deploy TOTP authenticator apps for 6.3 and 6.4. Avoid SMS OTP where possible. |
| **IG2** | Deploy TOTP or push MFA with number matching. Begin piloting FIDO2 keys or passkeys for admin accounts (6.5). |
| **IG3** | Require phishing-resistant MFA (FIDO2/WebAuthn, smart cards) for all privileged and high-risk accounts. Migrate user-facing systems to passkeys/FIDO2. |

---

## 7. Conclusion

CIS Controls v8 mandates MFA through three safeguards: **6.3** (external apps, IG1), **6.4** (remote access, IG1), and **6.5** (administrative access, IG2). The controls are deliberately flexible on MFA method, but CIS guidance clearly favors phishing-resistant methods — particularly FIDO2/WebAuthn — over legacy approaches like SMS OTP.

The critical distinction is that SMS OTP introduces an interceptable shared secret into the authentication flow, making it vulnerable to SIM swapping, SS7 attacks, and real-time phishing proxies. Phishing-resistant MFA eliminates the interceptable factor entirely by using origin-bound cryptographic authentication, ensuring that even a fully compromised phishing site cannot capture usable credentials.

Organizations should treat SMS OTP as a deprecated fallback, implement TOTP authenticator apps as a baseline, and progressively move toward FIDO2/WebAuthn passkeys and hardware security keys as their primary authentication mechanism — especially for privileged accounts and externally-exposed systems.

---

*Reference: CIS Controls v8, Center for Internet Security (2021). Safeguard details from Control 6: Access Control Management.*

# CIS Controls v8 → NIST CSF 2.0 Mapping: Controls 1–8

## Overview

This mapping supports organizations using **CIS Controls v8** as their primary security framework while demonstrating alignment with **NIST CSF 2.0** for government contract requirements. The tables below provide a side-by-side mapping for CIS Controls 1 through 8, including the applicable NIST CSF 2.0 Function, Categories, and a summary of coverage.

---

## CIS Controls 1–8 → NIST CSF 2.0 Mapping Table

| CIS Control | Control Name | NIST CSF 2.0 Function | NIST CSF 2.0 Categories | Notes |
|-------------|-------------|----------------------|------------------------|-------|
| **CIS Control 1** | Inventory and Control of Enterprise Assets | **Identify** | ID.AM-1, ID.AM-2 | Establishes the asset inventory foundation required for CSF asset management. Safeguard 1.1 directly addresses ID.AM-1 (physical device inventory). |
| **CIS Control 2** | Inventory and Control of Software Assets | **Identify** | ID.AM-2, ID.AM-5 | Software inventory maps to ID.AM-2 (software platform/application inventory) and ID.AM-5 (resource prioritization). |
| **CIS Control 3** | Data Protection | **Protect** | PR.DS-1, PR.DS-2, PR.DS-5 | Data classification, access controls, encryption at rest (Safeguard 3.11), and DLP (Safeguard 3.13) align with CSF data security categories. |
| **CIS Control 4** | Secure Configuration of Enterprise Assets and Software | **Protect** | PR.IP-1, PR.IP-3 | Secure baselines (Safeguard 4.1) and configuration management align with PR.IP-1 (baseline configuration) and PR.IP-3 (configuration change control). |
| **CIS Control 5** | Account Management | **Protect** | PR.AC-1, PR.AC-4 | Credential management, dormant account disabling (Safeguard 5.3), and admin privilege restriction (Safeguard 5.4) align with identity management categories. |
| **CIS Control 6** | Access Control Management | **Protect** | PR.AC-3, PR.AC-6, PR.AC-7 | MFA requirements (Safeguards 6.3–6.5), least privilege, and access granting/revoking processes align with remote access, least privilege, and authentication categories. |
| **CIS Control 7** | Continuous Vulnerability Management | **Identify / Protect** | ID.RA-1, PR.IP-12 | Vulnerability scanning and remediation (Safeguards 7.6, 7.7) map to risk assessment (ID.RA-1) and vulnerability management plan (PR.IP-12). Dual-function coverage. |
| **CIS Control 8** | Audit Log Management | **Detect** | DE.AE-3, DE.CM-1, DE.CM-7 | Log collection (Safeguard 8.2), audit log reviews (Safeguard 8.11), and alerting map directly to anomalous event detection and continuous monitoring categories. |

---

## Detailed Control-by-Control Breakdown

### CIS Control 1: Inventory and Control of Enterprise Assets
**NIST CSF 2.0 Function: Identify**

| Safeguard | Description | NIST CSF Category |
|-----------|-------------|-------------------|
| 1.1 | Establish/maintain detailed enterprise asset inventory | ID.AM-1 |
| 1.2 | Address unauthorized assets | ID.AM-1 |
| 1.3 | Utilize DHCP logging to update enterprise asset inventory | ID.AM-1 |
| 1.4 | Use DHCP logging | ID.AM-1 |
| 1.5 (IG2+) | Use a passive asset discovery tool | ID.AM-2 |

**CSF Alignment Notes:** CIS Control 1 is the foundational control for the NIST CSF "Identify" function. Without a complete asset inventory (ID.AM-1), no other CSF function can be effectively implemented. This control is universally required at IG1.

---

### CIS Control 2: Inventory and Control of Software Assets
**NIST CSF 2.0 Function: Identify**

| Safeguard | Description | NIST CSF Category |
|-----------|-------------|-------------------|
| 2.1 | Establish/maintain a software inventory | ID.AM-2 |
| 2.2 | Ensure authorized software is currently supported | ID.AM-5 |
| 2.3 | Address unauthorized software | ID.AM-2 |
| 2.5 (IG2+) | Allowlist authorized software | ID.AM-2 |
| 2.6 (IG2+) | Allowlist authorized libraries | ID.AM-2 |
| 2.7 (IG2+) | Allowlist authorized scripts | ID.AM-2 |

**CSF Alignment Notes:** CIS Control 2 strengthens the Identify function by ensuring software assets are known, authorized, and supported. Unsupported software creates unmanaged risk that cannot be captured in CSF risk assessment (ID.RA) without this inventory.

---

### CIS Control 3: Data Protection
**NIST CSF 2.0 Function: Protect**

| Safeguard | Description | NIST CSF Category |
|-----------|-------------|-------------------|
| 3.1 | Establish/maintain a data management process | PR.DS-1, PR.DS-2 |
| 3.2 | Establish/maintain a data inventory | PR.DS-1 |
| 3.3 | Configure data access control lists | PR.DS-5 |
| 3.4 | Enforce data retention | PR.DS-1 |
| 3.5 | Securely dispose of data | PR.DS-1 |
| 3.6 (IG2+) | Encrypt data on end-user devices | PR.DS-1 |
| 3.11 (IG2+) | Encrypt sensitive data at rest | PR.DS-1 |
| 3.13 (IG3) | Deploy a data loss prevention solution | PR.DS-5 |

**CSF Alignment Notes:** CIS Control 3 maps to the CSF Protect function's data security categories. PR.DS-1 (data at rest protection), PR.DS-2 (data in transit protection), and PR.DS-5 (data leak protections) are all addressed through this control's safeguards.

---

### CIS Control 4: Secure Configuration of Enterprise Assets and Software
**NIST CSF 2.0 Function: Protect**

| Safeguard | Description | NIST CSF Category |
|-----------|-------------|-------------------|
| 4.1 | Establish/maintain a secure configuration process | PR.IP-1 |
| 4.2 | Establish/maintain a secure configuration process for network infrastructure | PR.IP-1 |
| 4.3 | Configure automatic session locking | PR.IP-1 |
| 4.4 | Implement/manage a firewall on servers | PR.IP-1 |
| 4.5 | Implement/manage a firewall on end-user devices | PR.IP-1 |
| 4.8 (IG2+) | Uninstall or disable unnecessary services | PR.IP-3 |

**CSF Alignment Notes:** CIS Control 4 directly supports PR.IP-1 (baseline configuration of information technology/industrial control systems) and PR.IP-3 (configuration change control processes). Use of CIS Benchmarks for configuration baselines is explicitly recommended for both frameworks.

---

### CIS Control 5: Account Management
**NIST CSF 2.0 Function: Protect**

| Safeguard | Description | NIST CSF Category |
|-----------|-------------|-------------------|
| 5.1 | Establish/maintain an inventory of accounts | PR.AC-1 |
| 5.2 | Use unique passwords | PR.AC-1 |
| 5.3 | Disable dormant accounts | PR.AC-1, PR.AC-4 |
| 5.4 | Restrict administrator privileges to dedicated admin accounts | PR.AC-4 |
| 5.5 (IG2+) | Establish/maintain an inventory of service accounts | PR.AC-1 |
| 5.6 (IG2+) | Centralize account management | PR.AC-1 |

**CSF Alignment Notes:** CIS Control 5 maps to CSF PR.AC-1 (identities and credentials are issued, managed, verified, revoked, and audited) and PR.AC-4 (access permissions and authorizations are managed, incorporating least privilege). This is foundational to identity governance.

---

### CIS Control 6: Access Control Management
**NIST CSF 2.0 Function: Protect**

| Safeguard | Description | NIST CSF Category |
|-----------|-------------|-------------------|
| 6.1 | Establish an access granting process | PR.AC-3, PR.AC-6 |
| 6.2 | Establish an access revoking process | PR.AC-3, PR.AC-6 |
| 6.3 (IG2+) | Require MFA for externally-exposed applications | PR.AC-7 |
| 6.4 (IG2+) | Require MFA for remote network access | PR.AC-3, PR.AC-7 |
| 6.5 (IG2+) | Require MFA for admin access | PR.AC-7 |
| 6.8 (IG2+) | Define/maintain role-based access control | PR.AC-4, PR.AC-6 |

**CSF Alignment Notes:** CIS Control 6 addresses three CSF access management categories: PR.AC-3 (remote access management), PR.AC-6 (identities are proofed and bound to credentials), and PR.AC-7 (users, devices, and other assets are authenticated). MFA safeguards directly satisfy the authentication assurance requirements implicit in PR.AC-7.

---

### CIS Control 7: Continuous Vulnerability Management
**NIST CSF 2.0 Functions: Identify AND Protect**

| Safeguard | Description | NIST CSF Category |
|-----------|-------------|-------------------|
| 7.1 | Establish/maintain a vulnerability management process | ID.RA-1, PR.IP-12 |
| 7.2 | Establish/maintain a remediation process | PR.IP-12 |
| 7.3 | Perform automated OS patch management | PR.IP-12 |
| 7.4 | Perform automated application patch management | PR.IP-12 |
| 7.6 (IG2+) | Perform automated vulnerability scans of internal assets | ID.RA-1 |
| 7.7 (IG2+) | Remediate detected vulnerabilities | PR.IP-12 |

**CSF Alignment Notes:** CIS Control 7 spans two NIST CSF functions. The scanning and discovery aspects (Safeguard 7.6) map to the **Identify** function under ID.RA-1 (vulnerabilities in assets are identified and documented). The remediation and patching aspects map to the **Protect** function under PR.IP-12 (a vulnerability management plan is developed and implemented). This dual coverage is important to document for government contract purposes.

---

### CIS Control 8: Audit Log Management
**NIST CSF 2.0 Function: Detect**

| Safeguard | Description | NIST CSF Category |
|-----------|-------------|-------------------|
| 8.1 | Establish/maintain an audit log management process | DE.CM-1, DE.AE-3 |
| 8.2 | Collect audit logs | DE.AE-3, DE.CM-7 |
| 8.3 (IG2+) | Ensure adequate audit log storage | DE.AE-3 |
| 8.5 (IG2+) | Collect detailed audit logs | DE.CM-1, DE.AE-3 |
| 8.11 (IG2+) | Conduct audit log reviews | DE.CM-1, DE.AE-3 |
| 8.12 (IG2+) | Collect service provider logs | DE.CM-7 |

**CSF Alignment Notes:** CIS Control 8 is the primary IG1-eligible control that maps to the **Detect** function. It covers:
- **DE.AE-3:** Event data are collected and correlated from multiple sources and sensors
- **DE.CM-1:** The network is monitored to detect potential cybersecurity events
- **DE.CM-7:** Monitoring for unauthorized personnel, connections, devices, and software is performed

---

## NIST CSF Function Coverage Summary: CIS Controls 1–8

| NIST CSF Function | CIS Controls (1–8) That Map to It |
|-------------------|----------------------------------|
| **Govern** | None directly (Controls 1–8 focus on operational controls) |
| **Identify** | CIS Control 1, CIS Control 2, CIS Control 7 (partial) |
| **Protect** | CIS Control 3, CIS Control 4, CIS Control 5, CIS Control 6, CIS Control 7 (partial) |
| **Detect** | **CIS Control 8** |
| **Respond** | None (CIS Controls 17 covers this — outside scope of Controls 1–8) |
| **Recover** | None (CIS Control 11 covers this — outside scope of Controls 1–8) |

---

## CIS Controls That Cover the NIST CSF "Detect" Function

**Within CIS Controls 1–8, only CIS Control 8 (Audit Log Management) maps to the NIST CSF "Detect" function.**

CIS Control 8 covers the Detect function through three categories:

| NIST CSF Category | Category Description | Covered By |
|-------------------|---------------------|------------|
| **DE.AE-3** | Event data are collected and correlated from multiple sources | Safeguards 8.1, 8.2, 8.3, 8.5, 8.11 |
| **DE.CM-1** | The network is monitored to detect potential cybersecurity events | Safeguards 8.1, 8.5, 8.11 |
| **DE.CM-7** | Monitoring for unauthorized personnel, connections, devices, and software | Safeguards 8.2, 8.12 |

**Important Note for Program Planning:** If robust Detect function coverage is required for the government contract, CIS Controls 1–8 alone provide only foundational detection through audit logging (CIS Control 8). Organizations should also implement:

- **CIS Control 13 (Network Monitoring and Defense)** — Adds DE.CM-1, DE.CM-7, DE.AE-2 coverage through IDS/IPS and SIEM capabilities (IG2+)
- **CIS Control 18 (Penetration Testing)** — Adds DE.CM-8 coverage through active detection testing (IG2+)

These controls beyond the initial 8 significantly strengthen the Detect function and are likely expected for a government contract requiring NIST CSF 2.0 alignment.

---

## Implementation Recommendations for Dual-Framework Compliance

### Prioritization by Implementation Group

For organizations building toward a government contract, the recommended path is:

1. **Start with IG1 Controls 1–8** — Establishes the Identify and Protect functions and foundational Detect capability
2. **Add IG2 safeguards for Controls 7, 8, and 13** — Expands Detect function coverage significantly
3. **Document each CIS safeguard against its NIST CSF category** — Creates the evidence trail needed for CSF compliance demonstration

### Evidence Artifacts for Each Mapping

| CIS Control | NIST CSF Evidence Needed |
|-------------|-------------------------|
| Control 1 | Asset inventory documentation, DHCP logs |
| Control 2 | Software inventory, allowlisting records |
| Control 3 | Data classification policy, encryption certificates, DLP reports |
| Control 4 | Configuration baselines (CIS Benchmarks recommended), change management records |
| Control 5 | Account inventory, access reviews, privileged account documentation |
| Control 6 | Access request/revocation records, MFA enrollment reports, RBAC documentation |
| Control 7 | Vulnerability scan reports, patch management records, remediation tracking |
| Control 8 | Log collection architecture, log retention documentation, audit review records |

---

## References

- Center for Internet Security. *CIS Controls v8.* May 2021.
- National Institute of Standards and Technology. *Cybersecurity Framework 2.0.* February 2024.
- CIS Controls v8 Safeguard assignments per Implementation Group (IG1/IG2/IG3) as published by CIS.
- NIST CSF 2.0 Core Functions: Govern (GV), Identify (ID), Protect (PR), Detect (DE), Respond (RS), Recover (RC).

# CIS Controls v8 (1–8) Mapped to NIST CSF 2.0

## Executive Summary

This document maps CIS Controls 1 through 8 to the NIST Cybersecurity Framework (CSF) 2.0 functions and categories to support dual-framework alignment for government contract purposes. NIST CSF 2.0 introduces six functions: **Govern (GV)**, **Identify (ID)**, **Protect (PR)**, **Detect (DE)**, **Respond (RS)**, and **Recover (RC)**. CIS Controls v8 are operationally focused and map most heavily to the Identify and Protect functions, with select controls also addressing Detect and Govern.

---

## NIST CSF 2.0 Function Overview

| Function | Abbreviation | Purpose |
|---|---|---|
| Govern | GV | Organizational cybersecurity risk strategy, expectations, and policy |
| Identify | ID | Understanding assets, risks, and context |
| Protect | PR | Safeguards to deliver critical services |
| Detect | DE | Identifying cybersecurity events |
| Respond | RS | Actions regarding detected incidents |
| Recover | RC | Restoring capabilities after incidents |

---

## CIS Controls 1–8: Detailed Mapping to NIST CSF 2.0

---

### CIS Control 1: Inventory and Control of Enterprise Assets

**Description:** Actively manage (inventory, track, and correct) all enterprise assets—end-user devices, network devices, IoT, and servers—connected to the infrastructure.

| NIST CSF 2.0 Function | NIST CSF 2.0 Category | Category Description |
|---|---|---|
| **Identify (ID)** | ID.AM-01 | Inventories of hardware assets are maintained |
| **Identify (ID)** | ID.AM-02 | Inventories of software, services, and systems are maintained |
| **Identify (ID)** | ID.AM-05 | Assets are prioritized based on classification, criticality, resources, and impact |
| **Govern (GV)** | GV.OC-04 | Legal, regulatory, and contractual requirements regarding cybersecurity are understood |

**Primary Function:** Identify
**Secondary Function:** Govern

**Rationale:** Asset inventory is foundational to understanding what an organization has and needs to protect. This directly supports the Identify function's asset management (ID.AM) category. The governance overlay applies because asset management policies must be established and maintained.

---

### CIS Control 2: Inventory and Control of Software Assets

**Description:** Actively manage (inventory, track, and correct) all software on the network so that only authorized software is installed and can execute.

| NIST CSF 2.0 Function | NIST CSF 2.0 Category | Category Description |
|---|---|---|
| **Identify (ID)** | ID.AM-02 | Inventories of software, services, and systems are maintained |
| **Protect (PR)** | PR.PS-01 | Configuration management practices are established and applied |
| **Protect (PR)** | PR.PS-02 | Software is maintained, replaced, and removed commensurate with risk |
| **Govern (GV)** | GV.PO-01 | Policy for managing cybersecurity risks is established, communicated, and enforced |

**Primary Function:** Identify
**Secondary Function:** Protect

**Rationale:** Software inventory aligns to ID.AM-02 for asset management. Application whitelisting and allowlisting controls—core to CIS Control 2—also align to Protect (PR.PS) as they prevent unauthorized software execution. The allowlisting policy element maps to Govern.

---

### CIS Control 3: Data Protection

**Description:** Develop processes and technical controls to identify, classify, securely handle, retain, and dispose of data.

| NIST CSF 2.0 Function | NIST CSF 2.0 Category | Category Description |
|---|---|---|
| **Identify (ID)** | ID.AM-07 | Inventories of data and corresponding metadata for designated data are maintained |
| **Protect (PR)** | PR.DS-01 | The confidentiality, integrity, and availability of data-at-rest are protected |
| **Protect (PR)** | PR.DS-02 | The confidentiality, integrity, and availability of data-in-transit are protected |
| **Protect (PR)** | PR.DS-10 | The confidentiality, integrity, and availability of data-in-use are protected |
| **Protect (PR)** | PR.DS-11 | Backups of data are created, protected, maintained, and tested |
| **Govern (GV)** | GV.PO-01 | Policy for managing cybersecurity risks is established, communicated, and enforced |

**Primary Function:** Protect
**Secondary Function:** Identify

**Rationale:** Data protection controls are the quintessential Protect-function activity. Data classification (ID.AM-07) belongs to Identify, while encryption, DLP, and secure disposal map to PR.DS categories. Data retention policies map to Govern.

---

### CIS Control 4: Secure Configuration of Enterprise Assets and Software

**Description:** Establish and maintain the secure configuration of enterprise assets (end-user devices, network devices, servers) and software.

| NIST CSF 2.0 Function | NIST CSF 2.0 Category | Category Description |
|---|---|---|
| **Protect (PR)** | PR.PS-01 | Configuration management practices are established and applied |
| **Protect (PR)** | PR.PS-04 | Logs of events are generated and retained |
| **Identify (ID)** | ID.RA-01 | Vulnerabilities in assets are identified, validated, and recorded |
| **Govern (GV)** | GV.PO-02 | Cybersecurity roles, responsibilities, and authorities are established, communicated, and enforced |

**Primary Function:** Protect
**Secondary Function:** Identify

**Rationale:** Hardening and baseline configuration management are core Protect activities (PR.PS-01). Secure configuration also reduces the attack surface, indirectly supporting risk identification (ID.RA-01). Logging configurations (PR.PS-04) bridge toward Detect but are considered a Protect activity in the context of secure configuration.

---

### CIS Control 5: Account Management

**Description:** Use processes and tools to assign and manage authorization to credentials for user accounts, including administrator accounts, as well as service accounts.

| NIST CSF 2.0 Function | NIST CSF 2.0 Category | Category Description |
|---|---|---|
| **Protect (PR)** | PR.AA-01 | Identities and credentials for authorized users, services, and hardware are managed by the organization |
| **Protect (PR)** | PR.AA-02 | Identities are proofed and bound to credentials based on the context of interactions |
| **Protect (PR)** | PR.AA-05 | Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed |
| **Govern (GV)** | GV.PO-01 | Policy for managing cybersecurity risks is established, communicated, and enforced |

**Primary Function:** Protect
**Secondary Function:** Govern

**Rationale:** Account and identity lifecycle management is a direct implementation of NIST CSF 2.0's PR.AA (Identity Management, Authentication, and Access Control) category. Privileged account management maps specifically to PR.AA-05. Account management policy requirements map to Govern.

---

### CIS Control 6: Access Control Management

**Description:** Use processes and tools to create, assign, manage, and revoke access credentials and privileges for user, administrator, and service accounts.

| NIST CSF 2.0 Function | NIST CSF 2.0 Category | Category Description |
|---|---|---|
| **Protect (PR)** | PR.AA-03 | Users, services, and hardware are authenticated |
| **Protect (PR)** | PR.AA-04 | Identity assertions are protected, conveyed, and verified |
| **Protect (PR)** | PR.AA-05 | Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed |
| **Protect (PR)** | PR.AA-06 | Physical access to assets is managed, monitored, and controlled |
| **Identify (ID)** | ID.AM-03 | Representations of the organization's authorized network communication and internal and external network data flows are maintained |

**Primary Function:** Protect
**Secondary Function:** Identify

**Rationale:** CIS Control 6 focuses on least-privilege access, role-based access control, and MFA—all of which map squarely to PR.AA categories in NIST CSF 2.0. Network segmentation and access path documentation support ID.AM-03 (network flow inventories). Note: CIS Controls 5 and 6 are closely related and together form the full IAM picture mapped to PR.AA.

---

### CIS Control 7: Continuous Vulnerability Management

**Description:** Develop a plan to continuously assess and track vulnerabilities on all enterprise assets within the organization's infrastructure, in order to remediate and minimize the window of opportunity for attackers.

| NIST CSF 2.0 Function | NIST CSF 2.0 Category | Category Description |
|---|---|---|
| **Identify (ID)** | ID.RA-01 | Vulnerabilities in assets are identified, validated, and recorded |
| **Identify (ID)** | ID.RA-07 | Changes and exceptions are managed, assessed for risk impact, informed by prior risk analyses, and recorded |
| **Protect (PR)** | PR.PS-02 | Software is maintained, replaced, and removed commensurate with risk |
| **Govern (GV)** | GV.RM-05 | Risks with shared characteristics are aggregated and managed |
| **Detect (DE)** | DE.CM-09 | Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events |

**Primary Function:** Identify
**Secondary Function:** Protect, Detect

**Rationale:** Vulnerability scanning, patch management, and risk-based remediation prioritization are predominantly Identify-function activities (ID.RA). Patching maps to Protect (PR.PS-02). Continuous scanning that detects newly emerged vulnerabilities in real time has a secondary alignment to Detect (DE.CM-09), since authenticated vulnerability scans can surface active exploitation indicators.

---

### CIS Control 8: Audit Log Management

**Description:** Collect, alert, review, and retain audit logs of events that could help detect, understand, or recover from an attack.

| NIST CSF 2.0 Function | NIST CSF 2.0 Category | Category Description |
|---|---|---|
| **Detect (DE)** | DE.CM-03 | Personnel activity and technology usage are monitored to find potentially adverse events |
| **Detect (DE)** | DE.CM-06 | External service provider activities and services are monitored to find potentially adverse events |
| **Detect (DE)** | DE.CM-09 | Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events |
| **Detect (DE)** | DE.AE-02 | Potentially adverse events are analyzed to better understand associated activities |
| **Detect (DE)** | DE.AE-03 | Information is correlated from multiple sources |
| **Protect (PR)** | PR.PS-04 | Logs of events are generated and retained |
| **Govern (GV)** | GV.PO-01 | Policy for managing cybersecurity risks is established, communicated, and enforced |

**Primary Function:** Detect
**Secondary Function:** Protect

**Rationale:** Audit log management is the most direct mapping to the Detect function among CIS Controls 1–8. Log generation maps to Protect (PR.PS-04—a prerequisite), while log review, alerting, correlation, and analysis map to DE.CM and DE.AE categories. Log retention policies map to Govern. CIS Control 8 is the primary vehicle for demonstrating Detect function coverage within the first eight CIS Controls.

---

## Summary Mapping Table

| CIS Control | Primary CSF Function | Secondary CSF Function(s) | Key CSF Categories |
|---|---|---|---|
| 1 – Enterprise Asset Inventory | Identify (ID) | Govern (GV) | ID.AM-01, ID.AM-02, ID.AM-05 |
| 2 – Software Asset Inventory | Identify (ID) | Protect (PR), Govern (GV) | ID.AM-02, PR.PS-01, PR.PS-02 |
| 3 – Data Protection | Protect (PR) | Identify (ID), Govern (GV) | PR.DS-01, PR.DS-02, PR.DS-10, PR.DS-11, ID.AM-07 |
| 4 – Secure Configuration | Protect (PR) | Identify (ID), Govern (GV) | PR.PS-01, PR.PS-04, ID.RA-01 |
| 5 – Account Management | Protect (PR) | Govern (GV) | PR.AA-01, PR.AA-02, PR.AA-05 |
| 6 – Access Control Management | Protect (PR) | Identify (ID) | PR.AA-03, PR.AA-04, PR.AA-05, PR.AA-06 |
| 7 – Vulnerability Management | Identify (ID) | Protect (PR), Detect (DE) | ID.RA-01, ID.RA-07, PR.PS-02, DE.CM-09 |
| 8 – Audit Log Management | **Detect (DE)** | Protect (PR), Govern (GV) | DE.CM-03, DE.CM-06, DE.CM-09, DE.AE-02, DE.AE-03, PR.PS-04 |

---

## Which CIS Controls Cover the NIST CSF "Detect" Function?

Among CIS Controls 1 through 8, the Detect function is addressed primarily by:

### Primary Coverage: CIS Control 8 – Audit Log Management

CIS Control 8 is the dominant Detect-function control in this set. It maps to multiple DE categories:

- **DE.CM (Continuous Monitoring):** Log collection and review activities directly implement continuous monitoring of systems, users, and external services (DE.CM-03, DE.CM-06, DE.CM-09).
- **DE.AE (Adverse Event Analysis):** Log correlation, alerting, and event analysis activities implement DE.AE-02 (event analysis) and DE.AE-03 (multi-source correlation).

The specific CIS Control 8 safeguards that drive Detect coverage include:
- **8.2** – Collect audit logs from all enterprise assets
- **8.5** – Collect detailed audit logs (authentication, privilege use, data access)
- **8.6** – Collect DNS query audit logs
- **8.7** – Collect URL request audit logs
- **8.9** – Centralize log management (SIEM or equivalent)
- **8.11** – Conduct audit log reviews (alerts on anomalies)

### Secondary Coverage: CIS Control 7 – Continuous Vulnerability Management

CIS Control 7 has a secondary alignment to Detect (specifically **DE.CM-09**) because:
- Authenticated vulnerability scanning tools actively probe systems to identify exposed vulnerabilities and configuration weaknesses in real time.
- When integrated with a continuous monitoring program, vulnerability scan results feed into detection pipelines.
- However, this is a supporting rather than primary alignment—vulnerability management's core function is risk identification (ID.RA), not event detection.

### Gap Analysis: Detect Function Coverage in CIS Controls 1–8

It is important to note that CIS Controls 1–8 provide **limited Detect function coverage**. The bulk of Detect-function capabilities in CIS Controls v8 live in higher-numbered controls:

| CIS Control | Detect Relevance |
|---|---|
| Control 9 | Email and Web Browser Protections — partial DE.CM alignment |
| Control 10 | Malware Defenses — DE.CM-09 (endpoint monitoring) |
| Control 13 | Network Monitoring and Defense — **core DE.CM** coverage |
| Control 17 | Incident Response Management — DE.AE, RS function |

**For government contract alignment:** When demonstrating NIST CSF 2.0 Detect function coverage using only CIS Controls 1–8, organizations should document CIS Control 8 as the primary mechanism and supplement with evidence from CIS Controls 9–13 for complete Detect coverage. A crosswalk document noting that full DE function implementation requires controls beyond the first eight is recommended for assessor transparency.

---

## Recommendations for Government Contract Alignment

1. **Document the mapping formally:** Produce a crosswalk table (similar to this document) that assessors can review, showing each CSF category and the CIS Control safeguard that satisfies it.

2. **Address the Detect gap explicitly:** CIS Controls 1–8 are heavily weighted toward Identify and Protect. For full Detect coverage, include Controls 9, 10, and 13 in your program scope and crosswalk.

3. **Leverage CISA's CIS-to-NIST mappings:** CISA and the Center for Internet Security publish official crosswalk documents. Reference these as authoritative sources in your contract deliverables.

4. **Implement CIS Control 8 as your SIEM/logging strategy:** A centralized logging platform (SIEM) implementing Control 8 safeguards provides the most direct evidence of Detect function compliance for government auditors.

5. **Respond and Recover gap:** CIS Controls 1–8 do not meaningfully address Respond (RS) or Recover (RC) functions. Controls 17 (Incident Response) and 11 (Data Recovery) must be cited for those functions.

---

*Document prepared as part of security program framework alignment initiative. Based on CIS Controls v8 and NIST Cybersecurity Framework 2.0 (February 2024).*

# CIS Control 7: Continuous Vulnerability Management — Detailed Walkthrough

**Source:** CIS Controls v8 (published May 2021, Center for Internet Security)
**Control Reference:** CIS Control 7, Safeguards 7.1–7.7

---

## Overview

CIS Control 7 requires organizations to develop a plan to continuously assess and track vulnerabilities across all enterprise assets within the network — both internally exposed and externally facing — in order to proactively identify and remediate weaknesses before they can be exploited. The control emphasizes *continuous* and *automated* processes, not one-time or infrequent manual efforts.

The control maps to:
- **NIST CSF 2.0:** ID.RA-1 (Risk Assessment), PR.IP-12 (Vulnerability Management)
- **ISO 27001:2022:** A.8.8 (Management of technical vulnerabilities)
- **CMMC 2.0:** RA.L2-3.11.x (Risk Assessment domain)

---

## All 7 Safeguards: Detail, IG Assignment, and Implementation Notes

### Safeguard 7.1 — Establish and Maintain a Vulnerability Management Process
- **Implementation Group:** IG1
- **Asset Type:** Devices / Applications
- **Security Function:** Protect

**What it requires:** A documented, repeatable vulnerability management process that covers scanning frequency, roles and responsibilities, asset scope, tooling, and escalation paths. This policy must be reviewed and updated at least annually.

**Why it matters:** Without a defined process, vulnerability identification and remediation happen inconsistently or reactively. This safeguard creates the governance foundation for all subsequent Control 7 activities.

**How to implement:**
1. Draft a Vulnerability Management Policy that defines: scanning schedule, asset scope (on-prem, cloud, remote), responsible parties, escalation procedures, and remediation SLAs.
2. Assign ownership — typically to a Security or IT Operations team.
3. Review and update the policy annually or after significant infrastructure changes.
4. Integrate with the change management and patch management processes.

---

### Safeguard 7.2 — Establish and Maintain a Remediation Process
- **Implementation Group:** IG1
- **Asset Type:** Devices / Applications
- **Security Function:** Respond

**What it requires:** A documented remediation process that specifies how vulnerabilities are prioritized, assigned, tracked, and verified as resolved. This includes defined SLAs by severity (see SLA table below) and a process for handling exceptions when remediation cannot occur within the SLA window.

**Why it matters:** Identifying vulnerabilities without a clear remediation workflow leads to finding-fatigue and backlog accumulation. This safeguard ensures discovered vulnerabilities are acted upon systematically.

**How to implement:**
1. Define CVSS-based severity tiers and associated remediation deadlines (see SLA table in next section).
2. Establish a ticketing workflow (e.g., in Jira, ServiceNow) to track each finding from discovery through remediation and verification.
3. Define a risk acceptance / exception process for vulnerabilities that cannot be remediated within SLA (requires business risk owner sign-off and compensating controls).
4. Measure and report Mean Time to Patch (MTTP) by severity as a KPI.

---

### Safeguard 7.3 — Perform Automated Operating System Patch Management
- **Implementation Group:** IG1
- **Asset Type:** Devices
- **Security Function:** Protect

**What it requires:** Automate the application of operating system patches and updates across all enterprise endpoints and servers. Manual, ad hoc patching is insufficient for IG1 compliance.

**Why it matters:** Unpatched operating systems are among the most common attack vectors exploited in real-world breaches. Automation ensures patches are applied consistently without relying on individual administrators.

**How to implement:**
1. Enable automatic OS updates for workstations (Windows Update, macOS Software Update) or manage via a patch management platform.
2. For servers and managed endpoints, use tools such as WSUS, SCCM/MECM, Intune, Ansible, or Puppet to centrally deploy patches.
3. Define a patching cadence: critical patches applied within 15 days; routine patches within 30 days.
4. Track patch compliance rates; target 95%+ for critical patches within SLA.

**Recommended Tools:** Microsoft Intune / MECM, Jamf, Ansible, PDQ Deploy, ManageEngine Patch Manager Plus

---

### Safeguard 7.4 — Perform Automated Application Patch Management
- **Implementation Group:** IG1
- **Asset Type:** Applications
- **Security Function:** Protect

**What it requires:** Automate patching of third-party applications (browsers, productivity suites, PDF readers, runtime environments such as Java and .NET, and other installed software) across all enterprise assets.

**Why it matters:** Application vulnerabilities (particularly in browsers, Office applications, and Java runtimes) are a primary initial access vector. OS-only patching leaves a large attack surface unaddressed. This safeguard extends automated patching to the application layer.

**How to implement:**
1. Inventory all applications requiring patching (CIS Control 2 provides the foundation).
2. Use a patch management tool that covers third-party applications in addition to OS patches.
3. Include browser updates (Chrome, Edge, Firefox), Microsoft Office, Adobe Acrobat, Java, .NET, and all other commonly installed applications.
4. Confirm cloud/SaaS applications are kept current by the provider; verify SLA commitments in contracts.

**Recommended Tools:** Qualys Patch Management, Ivanti Patch for Endpoints, NinjaRMM, ManageEngine, Automox

---

### Safeguard 7.5 — Perform Automated Vulnerability Scans of Internal Enterprise Assets
- **Implementation Group:** IG2
- **Asset Type:** Devices
- **Security Function:** Identify

**What it requires:** Deploy an authenticated vulnerability scanner and run automated scans of all internally exposed enterprise assets (workstations, servers, network devices, printers, and other networked systems). CIS guidance recommends **weekly** authenticated scans of internal assets at IG2.

**Why it matters:** Automated OS and application patching (Safeguards 7.3 and 7.4) addresses known patch channels, but vulnerability scanning identifies a broader set of weaknesses including misconfigurations, missing patches that automated tools missed, default credentials, and newly discovered CVEs. Scanning provides ground-truth visibility into the actual security posture of assets.

**How to implement:**
1. Deploy a vulnerability scanner with credentialed scan capabilities (authenticated scans using domain credentials yield significantly more accurate results than unauthenticated scans).
2. Configure scan profiles to cover all asset classes: servers, workstations, network devices, and where possible, IoT/OT.
3. Schedule scans weekly at a minimum (not quarterly — see the IG2 sufficiency analysis below).
4. Feed scan results into a centralized vulnerability management platform for tracking, prioritization, and reporting.
5. Integrate scan coverage with the asset inventory (CIS Control 1) to detect unscanned assets.

**Recommended Tools:** Tenable Nessus / Tenable.io, Qualys VMDR, Rapid7 InsightVM, Microsoft Defender Vulnerability Management, CrowdStrike Spotlight

---

### Safeguard 7.6 — Perform Automated Vulnerability Scans of Externally Exposed Enterprise Assets
- **Implementation Group:** IG2
- **Asset Type:** Devices / Network
- **Security Function:** Identify

**What it requires:** Conduct automated vulnerability scans of all externally exposed assets — public-facing web servers, APIs, remote access infrastructure (VPN gateways, RDP), DNS servers, mail servers, and cloud-hosted services. CIS guidance recommends **monthly** scans of external assets at IG2.

**Why it matters:** Externally exposed assets present the most immediate risk because they are reachable by adversaries globally. A critical vulnerability on an internet-facing server can be discovered and exploited within hours of a CVE being published. Monthly external scanning is the minimum cadence that provides timely awareness of newly discovered exposures.

**How to implement:**
1. Maintain an inventory of all externally accessible IP addresses, domains, and cloud-hosted services (attack surface inventory).
2. Run monthly unauthenticated scans from an external vantage point to simulate attacker perspective.
3. Also run authenticated scans where possible (e.g., against web applications and cloud workloads).
4. Consider adding continuous external attack surface management (EASM) tools to detect newly exposed assets between scheduled scans.
5. Prioritize findings on external assets for faster remediation (treat external Critical/High findings as higher urgency).

**Recommended Tools:** Tenable.io, Qualys External Scanning, Rapid7 InsightVM, Detectify, Censys, Shodan (for exposure monitoring), UpGuard

---

### Safeguard 7.7 — Remediate Detected Vulnerabilities
- **Implementation Group:** IG2
- **Asset Type:** Devices / Applications
- **Security Function:** Respond

**What it requires:** Act on the findings produced by vulnerability scans (Safeguards 7.5 and 7.6). Vulnerabilities must be remediated, mitigated, or formally risk-accepted within the SLA timeframes defined in Safeguard 7.2, based on CVSS severity. This safeguard closes the loop between identification and remediation.

**Why it matters:** Scanning without remediating is meaningless from a security standpoint and can create legal and compliance risk (demonstrating knowledge of a vulnerability without action). This safeguard operationalizes the remediation workflow.

**How to implement:**
1. Integrate scanner output with a ticketing system for automated assignment to system owners.
2. Apply CVSS-based remediation SLAs (see table below).
3. Track open vulnerabilities aging past SLA; escalate to management for risk acceptance decisions.
4. Verify remediation by re-scanning after patches are applied.
5. Report remediation metrics (MTTP by severity, vulnerability backlog trend) to leadership monthly.

---

## Remediation SLAs by CVSS Severity

CIS Control 7 (Safeguard 7.2) requires organizations to define a remediation process with severity-based timeframes. The following SLAs represent the CIS-recommended standards and align with common industry practice and regulatory frameworks (NIST SP 800-40, PCI DSS, and others):

| CVSS Severity | Score Range | Recommended Remediation SLA | Notes |
|---------------|-------------|------------------------------|-------|
| **Critical** | 9.0 – 10.0 | **15 days** | Highest urgency; exploits frequently available within days of CVE publication; consider emergency change procedures |
| **High** | 7.0 – 8.9 | **30 days** | Significant risk; patch within one monthly patch cycle |
| **Medium** | 4.0 – 6.9 | **90 days** | Address within one quarter; compensating controls may be appropriate while patch is scheduled |
| **Low** | 0.1 – 3.9 | **180 days or risk-accepted** | Address opportunistically; document risk acceptance where remediation is deferred |

**Important notes on SLA application:**
- **Externally exposed assets:** Apply accelerated SLAs. A Critical vulnerability on an internet-facing system should be treated as a 7-day SLA, not 15 days, due to heightened exploitability.
- **CVSS vs. EPSS:** CVSS score alone does not reflect actual exploitability. Where possible, supplement CVSS with EPSS (Exploit Prediction Scoring System) scores and CISA KEV (Known Exploited Vulnerabilities) catalog membership to further prioritize. A CVSSv3 Medium vulnerability that is actively exploited in the wild may warrant Critical-level urgency.
- **SLA exceptions:** Document risk acceptance decisions with business owner sign-off, compensating controls, and a defined review date. Do not allow exceptions to accumulate silently.

**IG2 KPI Targets (from CIS guidance):**
- Mean Time to Patch (MTTP) — Critical: ≤ 15 days
- Mean Time to Patch (MTTP) — High: ≤ 30 days

---

## Complete Safeguard Summary Table

| Safeguard | Title | IG | Asset Type | Security Function |
|-----------|-------|----|-----------|------------------|
| 7.1 | Establish and Maintain a Vulnerability Management Process | **IG1** | Devices / Apps | Protect |
| 7.2 | Establish and Maintain a Remediation Process | **IG1** | Devices / Apps | Respond |
| 7.3 | Perform Automated OS Patch Management | **IG1** | Devices | Protect |
| 7.4 | Perform Automated Application Patch Management | **IG1** | Applications | Protect |
| 7.5 | Perform Automated Vulnerability Scans of Internal Assets | **IG2** | Devices | Identify |
| 7.6 | Perform Automated Vulnerability Scans of External Assets | **IG2** | Devices / Network | Identify |
| 7.7 | Remediate Detected Vulnerabilities | **IG2** | Devices / Apps | Respond |

---

## Are Quarterly Vulnerability Scans Sufficient for IG2?

**Direct answer: No. Quarterly vulnerability scans do not meet the IG2 requirements of CIS Control 7.**

Here is the specific gap analysis:

### What IG2 Requires for Scanning Frequency

| Safeguard | Asset Scope | CIS-Required Minimum Frequency |
|-----------|-------------|-------------------------------|
| 7.5 | Internal assets | **Weekly** (authenticated) |
| 7.6 | External assets | **Monthly** |

### Your Current State vs. IG2 Requirements

| Dimension | Your Current State | IG2 Requirement | Gap |
|-----------|-------------------|-----------------|-----|
| Internal scan frequency | Quarterly (every ~13 weeks) | Weekly | **Non-compliant — scanning 12x less frequently than required** |
| External scan frequency | Quarterly (assumed) | Monthly | **Non-compliant — scanning 3x less frequently than required** |
| Authenticated scanning | Unknown | Required for internal scans | Verify if scans use credentials |
| Remediation tracking | Unknown | Required (Safeguard 7.7) | Assess current tracking process |

### Why Quarterly Scanning Is Insufficient

1. **Vulnerability disclosure pace:** The NVD (National Vulnerability Database) publishes thousands of new CVEs every month. A vulnerability published on Day 1 of your quarter could remain undetected in your environment for up to 90 days with quarterly scanning.

2. **SLA compliance is impossible:** Your 15-day SLA for Critical vulnerabilities (Safeguard 7.2 / IG1) cannot be honored if scans only run quarterly — you may not discover a Critical vulnerability until it is 13 weeks old.

3. **IG2 explicitly specifies scan frequency:** The CIS implementation guidance for IG2 is unambiguous: weekly internal scans (Safeguard 7.5) and monthly external scans (Safeguard 7.6). Quarterly scanning represents a significant control gap for any IG2 compliance claim.

4. **Regulatory alignment:** Quarterly scanning also falls short of expectations in PCI DSS (quarterly *minimum* for external, but continuous monitoring recommended), HIPAA risk management requirements, and most cyber insurance baseline controls.

### Recommended Remediation Path

**Phase 1 — Immediate (0–30 days):**
- Increase internal scanning to weekly using an authenticated vulnerability scanner.
- Increase external scanning to monthly at minimum; consider continuous external attack surface management tooling for ongoing visibility.
- Ensure all scan profiles are using authenticated credentials for internal scans (unauthenticated scans miss a significant portion of vulnerabilities).

**Phase 2 — Short-term (30–60 days):**
- Integrate scanner output with a ticketing system for automated assignment and SLA tracking (supports Safeguard 7.7).
- Define and document remediation SLAs formally in a Vulnerability Management Policy (Safeguards 7.1 and 7.2).
- Establish a remediation KPI dashboard tracking MTTP by severity.

**Phase 3 — Ongoing:**
- Report monthly on vulnerability backlog, scan coverage, and MTTP metrics.
- Review the vulnerability management policy annually.
- Consider expanding to continuous scanning or agent-based approaches (e.g., Tenable.io agents, Qualys Cloud Agent, CrowdStrike Spotlight) to achieve near-real-time visibility without the overhead of scheduled network scans.

### Recommended Tooling for IG2 Vulnerability Scanning

| Tool | Strength | Deployment |
|------|---------|-----------|
| Tenable Nessus / Tenable.io | Industry standard; broad CVE coverage | On-prem scanner or cloud |
| Qualys VMDR | Cloud-native; strong asset correlation | Cloud-hosted |
| Rapid7 InsightVM | Strong remediation workflow integration | On-prem or cloud |
| Microsoft Defender Vulnerability Management | Native Windows integration; no separate agent | Microsoft ecosystem |
| CrowdStrike Spotlight | Agent-based; no network scan required | EDR-integrated |

---

## Key Takeaways

1. **CIS Control 7 has 7 safeguards:** Four are IG1 requirements (process, remediation, OS patching, app patching) and three are IG2 requirements (internal scanning, external scanning, remediation closure).

2. **IG1 organizations** must automate patching and define a remediation process, but are not required to run vulnerability scans — that requirement is introduced at IG2.

3. **IG2 organizations** must run weekly authenticated internal scans, monthly external scans, and formally track and remediate all findings within CVSS-based SLAs.

4. **Quarterly scanning fails IG2** by a significant margin: it is 12x below the internal scan frequency requirement and 3x below the external scan frequency requirement.

5. **Remediation SLAs:** Critical = 15 days, High = 30 days, Medium = 90 days, Low = 180 days. Externally exposed assets should use accelerated timelines.

6. **Scanning without remediation tracking is non-compliant:** Safeguard 7.7 requires that scan findings are acted upon, tracked, and verified — not just identified.

---

*References: CIS Controls v8, Center for Internet Security (May 2021). Safeguard details per CIS Controls v8 safeguards-detail reference. Implementation guidance per CIS Controls v8 implementation-guidance reference.*

# CIS Controls v8 — Control 7: Continuous Vulnerability Management

## Overview

CIS Control 7 focuses on continuously acquiring, assessing, and taking action on new information about vulnerabilities to identify, remediate, and minimize the window of opportunity for attackers. The intent is to proactively manage the attack surface by understanding what vulnerabilities exist across the enterprise's assets and systematically reducing exposure before adversaries can exploit them.

---

## All Safeguards Under Control 7

CIS Controls v8 defines seven safeguards (7.1 through 7.7) under Control 7. Each is assigned to an Implementation Group (IG1, IG2, or IG3), which define cumulative tiers of security maturity.

---

### Safeguard 7.1 — Establish and Maintain a Vulnerability Management Process

**Implementation Group: IG1**

Establish and maintain a documented vulnerability management process for enterprise assets. Review and update the process annually, or whenever significant changes occur that could affect this Safeguard.

**Key requirements:**
- A formal, written process must exist
- It must cover the full lifecycle: discovery, prioritization, remediation, verification
- Annual review cadence (at minimum)

**Asset type:** All

---

### Safeguard 7.2 — Establish and Maintain a Remediation Process

**Implementation Group: IG1**

Establish and maintain a risk-based remediation strategy documented in a remediation process, with monthly, or more frequent, reviews.

**Key requirements:**
- Defines how vulnerabilities are triaged and prioritized (typically using CVSS scores or similar)
- Defines ownership and accountability for remediation
- Monthly review cadence (at minimum)

**Asset type:** All

---

### Safeguard 7.3 — Perform Automated Operating System Patch Management

**Implementation Group: IG1**

Perform operating system updates on enterprise assets through automated patch management on a monthly, or more frequent, basis.

**Key requirements:**
- Applies to all enterprise assets (servers, workstations, mobile devices, etc.)
- Automated tooling strongly preferred
- Monthly cadence is the floor — more frequent is better

**Asset type:** Devices (endpoints, servers)

---

### Safeguard 7.4 — Perform Automated Application Patch Management

**Implementation Group: IG1**

Perform application updates on enterprise assets through automated patch management on a monthly, or more frequent, basis.

**Key requirements:**
- Covers third-party and enterprise-developed applications
- Monthly cadence (at minimum)
- Automated patch deployment tooling required

**Asset type:** Applications

---

### Safeguard 7.5 — Perform Automated Vulnerability Scans of Internal Enterprise Assets

**Implementation Group: IG2**

Perform automated vulnerability scans of internal enterprise assets on a quarterly, or more frequent, basis. Conduct both authenticated and unauthenticated scans using a SCAP-compliant vulnerability scanning tool.

**Key requirements:**
- Authenticated scans strongly preferred (they yield far more complete results than unauthenticated)
- SCAP-compliant tooling (e.g., Tenable Nessus, Qualys, Rapid7 InsightVM, OpenVAS)
- Quarterly is the minimum frequency — not the recommended frequency
- Covers all internal assets (servers, workstations, network devices)

**Asset type:** Devices, network infrastructure

---

### Safeguard 7.6 — Perform Automated Vulnerability Scans of Externally-Exposed Enterprise Assets

**Implementation Group: IG2**

Perform automated vulnerability scans of externally exposed enterprise assets using a SCAP-compliant vulnerability scanning tool. Perform scans on a monthly, or more frequent, basis.

**Key requirements:**
- Monthly cadence (more stringent than internal scans)
- Covers internet-facing assets: web applications, APIs, VPN concentrators, mail servers, etc.
- Must use authenticated scans where technically feasible
- External attack surface is higher risk, hence the tighter cadence

**Asset type:** Network infrastructure (external-facing)

---

### Safeguard 7.7 — Remediate Detected Vulnerabilities

**Implementation Group: IG2**

Remediate detected vulnerabilities in software through processes and tooling on a monthly, or more frequent, basis, based on the remediation process.

**Key requirements:**
- Remediation must follow a defined, risk-based process (see Safeguard 7.2)
- Monthly cadence as the baseline for action
- Tracking through a vulnerability management platform or ticketing system
- Verification of remediation (re-scanning, validation)

**Asset type:** All

---

## Safeguard Summary by Implementation Group

| Safeguard | Description | IG |
|-----------|-------------|-----|
| 7.1 | Establish and maintain a vulnerability management process | IG1 |
| 7.2 | Establish and maintain a remediation process | IG1 |
| 7.3 | Perform automated OS patch management | IG1 |
| 7.4 | Perform automated application patch management | IG1 |
| 7.5 | Automated vulnerability scans — internal assets (quarterly+) | IG2 |
| 7.6 | Automated vulnerability scans — external assets (monthly+) | IG2 |
| 7.7 | Remediate detected vulnerabilities (monthly cadence) | IG2 |

**Note:** There are no IG3-exclusive safeguards in Control 7. IG3 organizations implement all seven safeguards above with greater rigor, tooling integration, and often higher scan frequency.

---

## CIS-Recommended Remediation SLAs by CVSS Severity

CIS does not publish a single rigid SLA table within the Controls v8 document itself — the Controls framework delegates SLA specifics to the remediation process defined in Safeguard 7.2. However, CIS and the broader cybersecurity community (including CIS Benchmarks guidance, CISA KEV directives, and common industry practice aligned with CIS guidance) converge on the following widely-cited SLA framework:

| CVSS Score Range | Severity | Recommended Remediation SLA |
|------------------|----------|-----------------------------|
| 9.0 – 10.0 | Critical | 15 days (often cited as 7–15 days for internet-facing assets) |
| 7.0 – 8.9 | High | 30 days |
| 4.0 – 6.9 | Medium | 60–90 days |
| 0.1 – 3.9 | Low | 180 days or next scheduled maintenance cycle |
| 0.0 | Informational | Risk acceptance / no required remediation window |

**Important caveats:**

1. **CISA KEV override:** Any vulnerability listed on CISA's Known Exploited Vulnerabilities (KEV) catalog should be treated as Critical regardless of its CVSS base score, with a 14-day remediation window for federal systems (FCEB agencies under BOD 22-01). Non-federal organizations should adopt a similar posture for KEV-listed vulnerabilities.

2. **Internet-facing assets:** CIS guidance and industry practice consistently compress SLAs for externally exposed assets. A High-severity vulnerability on an internet-facing asset should be remediated in 15 days, not 30.

3. **CVSS v3.x vs. base scores:** CVSS base scores alone are insufficient for prioritization. Organizations should incorporate temporal scores (exploit code maturity, remediation level, report confidence) and environmental scores (asset criticality, exposure) when setting actual SLAs.

4. **Exploit availability:** If a public exploit exists (e.g., via Metasploit, ExploitDB, or CISA KEV), SLAs should be compressed regardless of CVSS score.

---

## Are Quarterly Internal Scans Sufficient for IG2?

**Short answer: Technically yes, but practically insufficient and not recommended.**

### What CIS Says

Safeguard 7.5 states: "quarterly, or more frequent." So quarterly scanning of internal assets technically meets the minimum letter of the IG2 requirement for internal scans.

However, **quarterly scans alone are not sufficient to meet the full spirit of IG2**, for the following reasons:

### Why Quarterly Is Inadequate in Practice

**1. External assets require monthly scans (Safeguard 7.6)**
If your organization has any internet-facing assets — and virtually every IG2 organization does — those assets must be scanned at least monthly. Quarterly scans of external assets would be a direct compliance gap.

**2. The vulnerability landscape changes faster than quarterly**
New critical and high vulnerabilities are disclosed daily. The average time-to-exploit for critical vulnerabilities has dropped to under 15 days in recent years. A vulnerability disclosed on day 1 of a quarter may go undetected for up to 90 days if you only scan quarterly. This window directly contradicts the SLAs for Critical (15 days) and High (30 days) vulnerabilities — you cannot remediate what you have not discovered.

**3. Safeguard 7.7 requires monthly remediation cycles**
Even if scanning is quarterly, Safeguard 7.7 requires you to perform remediation on a monthly basis. If you're only scanning quarterly, you have no new findings to act on for three months at a time, which means your monthly remediation process is running on stale data.

**4. Patch management safeguards (7.3, 7.4) are monthly**
IG1 safeguards 7.3 and 7.4 require monthly automated patching. If you are patching monthly but only scanning quarterly, you have no mechanism to verify that patches were applied successfully or to catch vulnerabilities introduced between scans.

**5. Authenticated vs. unauthenticated scanning**
CIS requires both authenticated and unauthenticated scans. If your quarterly scans are unauthenticated-only, you are likely missing 40–60% of actual vulnerability findings, which is a significant compliance and risk gap.

### Recommended Posture for IG2

| Asset Category | Minimum CIS Cadence | Recommended Best Practice |
|----------------|---------------------|---------------------------|
| Internal assets | Quarterly | Monthly |
| External/internet-facing assets | Monthly | Weekly or continuous |
| Critical systems (servers, DC, databases) | Monthly | Weekly |
| Post-change scanning | As-needed | Within 24–48 hours of any significant change |

### Remediation Gap Analysis

If you run quarterly scans only, your actual exposure timeline looks like this:

- Vulnerability disclosed: Day 1
- Next scan detects it: Up to Day 90
- Remediation begins: Day 90+
- Remediation completed: Day 90 + your remediation cycle

For a Critical vulnerability, the remediation SLA (15 days) would be violated in nearly every scenario. For High vulnerabilities (30-day SLA), the same is true.

---

## Recommendations for IG2 Compliance

1. **Immediately move external asset scans to monthly** — this is a hard IG2 requirement (Safeguard 7.6), not a recommendation.

2. **Move internal scans to monthly** — quarterly is the CIS floor, not the target. Monthly internal scans dramatically reduce your exposure window and align with your monthly patching and remediation cycles.

3. **Implement authenticated scanning** — ensure all scans use credentials to get complete vulnerability coverage. Unauthenticated scans miss local privilege escalation flaws, misconfigurations, and software inventory gaps.

4. **Establish a vulnerability tracking process** — use a vulnerability management platform (Tenable, Qualys, Rapid7, etc.) or at minimum a tracked ticketing workflow that maps findings to remediation owners with due dates tied to the SLA table above.

5. **Subscribe to CISA KEV notifications** — treat KEV-listed vulnerabilities as P0 regardless of CVSS score. Integrate KEV status into your prioritization workflow.

6. **Implement continuous monitoring for critical assets** — for your most sensitive systems, consider agent-based scanning or continuous monitoring tools that provide real-time visibility rather than point-in-time scans.

7. **Close the loop with re-scanning** — after remediation, verify closure with a follow-up scan within 5–7 days. Do not mark vulnerabilities as remediated based solely on a ticket closure without technical verification.

---

## Summary

CIS Control 7 contains seven safeguards spanning IG1 (7.1–7.4) and IG2 (7.5–7.7). The framework requires monthly external scans, quarterly-minimum internal scans, and monthly remediation cycles. Recommended SLAs range from 15 days for Critical vulnerabilities to 180 days for Low. Quarterly internal scans technically satisfy the minimum IG2 bar for internal assets only, but fall short for external assets, cannot support the required remediation SLAs for Critical and High findings, and represent a significant operational risk gap. Organizations serious about IG2 compliance should target monthly internal scans and weekly or continuous external scans as their operational baseline.

EAR COMPLIANCE ANALYSIS
RF Power Amplifier — 6 GHz, 40 W Output, Commercial Wireless Base Station Use
Export Destination: Germany

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STEP 1 — JURISDICTION DETERMINATION (Order of Review, § 732.3)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Before classifying under the EAR, apply the mandatory Order of Review.

1a. USML Check (ITAR, 22 CFR Part 121)
    The item is a commercial RF power amplifier designed for civilian wireless
    base-station infrastructure (3GPP/commercial 5G or 4G). It is NOT specially
    designed for a military application. USML Category XI (Military Electronics)
    covers military radios and electronic warfare equipment; a commercial base-
    station PA that is not "specially designed" for military use does not fall
    there. CONCLUSION: Not on USML — ITAR jurisdiction does NOT apply.

1b. Other Agency Controls
    Not a nuclear item (NRC), pharmaceutical (FDA), or controlled substance
    (DEA). No other agency has exclusive jurisdiction.

1c. Subject to the EAR (§ 734.3)
    If the amplifier is of US origin (manufactured in the US) or physically
    located in the US, it is subject to the EAR. This analysis proceeds on
    that basis.

JURISDICTION RESULT: Item is subject to the EAR. Proceed to CCL classification.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STEP 2 — ECCN CLASSIFICATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The item's key technical parameters:
  • Frequency: 6 GHz
  • Output power: 40 W (continuous or peak — relevant to technical thresholds)
  • Function: RF power amplification
  • End-use: Commercial wireless base station (civilian infrastructure)

CCL Category: Category 3 — Electronics

The primary ECCN to evaluate is 3A001, which controls electronic components
including microwave and millimeter-wave components.

ECCN 3A001 — Analysis:

ECCN 3A001.b covers microwave solid-state amplifiers. Specifically,
3A001.b.4 controls "microwave solid-state amplifiers and microwave assemblies
or modules" with all of the following characteristics:
  (a) Designed for frequencies exceeding 2.7 GHz; AND
  (b) An "instantaneous bandwidth" of more than one octave; OR
      (c) A saturated power output of greater than certain thresholds.

For a 6 GHz amplifier, the frequency criterion (> 2.7 GHz) is clearly met.
The 40 W output power at 6 GHz is significant and likely exceeds the CCL
thresholds specified in 3A001.b.4 (which set out power/frequency combination
thresholds for amplifier assemblies).

Additionally, 3A001.b.2 controls "microwave power amplifiers" designed to
operate at frequencies exceeding 31.8 GHz — this item at 6 GHz falls below
that threshold, so .b.2 does not apply directly.

The most applicable subparagraph for a 6 GHz, 40 W RF power amplifier is
3A001.b.4 (microwave solid-state amplifiers operating above 2.7 GHz with
elevated saturated output power). However, the detailed thresholds in
3A001.b.4 depend on exact instantaneous bandwidth and saturated power levels
that should be confirmed against the current regulatory text.

ECCN CLASSIFICATION: 3A001 (most likely 3A001.b.4)

Reasons for Control under 3A001:
  • NS — National Security (Column 1)
  • AT — Anti-Terrorism (Column 1)

Note: 3A001 does NOT typically carry MT (Missile Technology) controls for
commercial PA components designed for civilian wireless infrastructure, but
you must confirm the item has no missile/guidance application and that it is
not "specially designed" for a missile or unmanned aerial vehicle system.

If upon review of the exact CCL technical parameters the item does NOT meet
the 3A001.b.4 thresholds (e.g., output power or bandwidth falls below the
controlled levels), then the item may instead classify as EAR99 — subject
to EAR but with no license requirement to most destinations absent end-use
or end-user concerns (see Step 5 below). Consider submitting a CCATS request
via SNAP-R (Form BIS-748P-A) to obtain a binding BIS classification if there
is any ambiguity.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STEP 3 — LICENSE REQUIREMENT ANALYSIS (Part 738, Country Chart)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Destination: Germany

Germany's Country Group Status:
  • Country Group A:1 (Wassenaar Arrangement member) — YES
  • Country Group A:5 (allied/partner, license-friendly) — YES
  • Germany is a NATO ally, EU member, and long-standing US partner
  • Germany is NOT in Country Group D or E

Country Chart lookup for ECCN 3A001 — NS Column 1 and AT Column 1:

  NS Column 1 / Germany: The Commerce Country Chart shows NO "X" in the NS
  Column 1 row for Germany. Germany, as an A:1/A:5 country and Wassenaar
  member, does not have an "X" in NS Column 1.

  AT Column 1 / Germany: Germany is not a state sponsor of terrorism and
  does not have an "X" in AT Column 1.

LICENSE REQUIREMENT RESULT: No license is required based on the Country
Chart analysis for a 3A001 item exported to Germany.

The transaction qualifies as "No License Required" (NLR) for this
ECCN/destination combination.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STEP 4 — LICENSE EXCEPTION ANALYSIS (Part 740)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Because the Country Chart analysis above shows no license is required for
Germany (NLR determination), a formal license exception is not needed to
authorize the export. However, note the following for completeness:

If for any reason a license were required, the most relevant exception would
be License Exception STA (Strategic Trade Authorization, § 740.20) —
applicable to exports to Country Group A:5 countries of items controlled for
NS reasons. Germany qualifies as an A:5 country. STA would authorize export
of 3A001 items to Germany subject to the conditions in § 740.20(b)(2),
including obtaining a STA eligibility statement from the consignee.

Other potentially applicable exceptions to note:
  • LVS (Limited Value Shipments, § 740.3): If the value of the shipment is
    below the LVS dollar threshold listed in the 3A001 entry, LVS may apply.
    Check the ECCN's LVS column for the applicable per-shipment value limit.
  • GBS (Group B Shipments, § 740.4): Applicable to NS-only items going to
    Country Group B. Germany is in A:1/A:5 (a more permissive grouping), so
    GBS may apply to NS-only controlled items — but again, NLR already
    applies here.

CONCLUSION FOR LICENSE EXCEPTIONS: Not required; the export qualifies as NLR.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STEP 5 — END-USER AND END-USE CONTROLS (Part 744)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Even with an NLR determination, you MUST conduct the following checks before
every shipment:

5a. Restricted Party Screening
    Screen all parties to the transaction — buyer, consignee, end-user,
    freight forwarder, bank, and any intermediate parties — against:

    (i)   Entity List (Supplement 4 to Part 744): A license is required for
          ALL items subject to EAR for any entity on this list. No exceptions
          available.
    (ii)  Denied Persons List (Part 764): Absolute prohibition. Do not
          proceed.
    (iii) Unverified List (Supplement 6 to Part 744): Cannot use license
          exceptions; must obtain UVL Statement before proceeding.
    (iv)  Military End-User (MEU) List (Supplement 7 to Part 744): License
          required for items in Supplement 2 to Part 744 if the party
          appears on this list.
    (v)   OFAC SDN List: Treasury-administered; full block.

    Use the Consolidated Screening List at trade.gov/consolidated-screening-list
    for a single-search check across BIS, State, and Treasury lists.

    Germany-based entities are generally low-risk, but screening is mandatory
    regardless of destination.

5b. WMD End-Use Prohibitions (§ 744.2–744.6)
    RF power amplifiers at 6 GHz could theoretically support radar or
    directed-energy applications. You must have no knowledge or reason to
    know that the amplifier will be used in:
      • Nuclear weapons development (§ 744.2)
      • Missile systems capable of delivering WMD (§ 744.3)
      • Chemical or biological weapons (§ 744.4)
    The stated end-use (commercial wireless base station) is a well-recognized
    civilian application. Document the end-use clearly.

5c. Red Flag Review (§ 732.6)
    Assess whether any "Red Flags" are present:
      • Is the buyer reluctant to provide end-use details? (Not typical for a
        licensed telecoms operator)
      • Does the order quantity, configuration, or payment method raise
        concerns?
      • Is the shipping route unusual for Germany?
    If red flags are identified, you must resolve them through due diligence
    before proceeding — no export until concerns are cleared.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STEP 6 — EXPORT CLEARANCE AND DOCUMENTATION (Part 758)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

EEI Filing (Electronic Export Information):
  • EEI via AES (Automated Export System) is required for shipments valued
    over $2,500 per Schedule B number, or for any shipment requiring an
    export license (15 CFR § 30.37).
  • For a 40 W RF power amplifier valued above $2,500 (which is highly
    likely), file EEI via AES before export.
  • Enter the ECCN (3A001) and "NLR" as the export license code on the EEI
    filing.

Commercial Invoice and Shipper's Export Declaration:
  • Include ECCN classification and NLR designation on shipping documents.
  • Clearly state the end-use: "Commercial wireless base station — civilian
    telecommunications infrastructure."

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STEP 7 — RECORDKEEPING (Part 762)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Retain all records for 5 years from the date of export:
  • Purchase orders and sales contracts
  • Commercial invoices and packing lists
  • Bills of lading / airway bills
  • AES/EEI filing confirmation
  • Restricted party screening records (date, lists checked, results)
  • End-use documentation from the consignee (recommended best practice)
  • Internal ECCN classification memorandum

Records must be available to BIS on request.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SUMMARY AND FINAL DETERMINATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┌─────────────────────────────────────────────────────────────────────────┐
│ ITEM:        RF Power Amplifier, 6 GHz, 40 W, commercial base station  │
│ ECCN:        3A001 (most likely 3A001.b.4)                              │
│ RFCs:        NS Column 1, AT Column 1                                   │
│ DESTINATION: Germany (Country Group A:1, A:5)                          │
│ COUNTRY CHART RESULT: No "X" in NS Col. 1 or AT Col. 1 for Germany     │
│ LICENSE REQUIRED: NO                                                    │
│ EXPORT AUTHORIZATION: NLR (No License Required)                         │
│ LICENSE EXCEPTION: Not required; STA (§ 740.20) available if needed    │
└─────────────────────────────────────────────────────────────────────────┘

ACTION CHECKLIST BEFORE SHIPPING:

[ ] 1. Confirm ECCN against current 3A001.b technical parameters; submit
       CCATS via SNAP-R if any ambiguity exists (Form BIS-748P-A).

[ ] 2. Screen all transaction parties against the Consolidated Screening List
       (trade.gov/consolidated-screening-list) and record results.

[ ] 3. Confirm end-use in writing: commercial wireless base station, civilian
       operator in Germany. Retain documentation.

[ ] 4. File EEI via AES if shipment value exceeds $2,500. Enter ECCN 3A001
       and license code "NLR."

[ ] 5. Retain all export records for 5 years (Part 762).

[ ] 6. If the buyer resells or reexports the amplifier, advise them that the
       item is EAR-controlled and that reexport to embargoed countries (Cuba,
       Iran, North Korea, Syria — Part 746) or to Russia/Belarus (Part 746.8)
       is prohibited without a BIS license, regardless of where the reexport
       originates.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IMPORTANT CAVEATS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. Self-classification carries legal responsibility. If you are uncertain
   whether the amplifier meets 3A001.b.4 thresholds — particularly regarding
   instantaneous bandwidth, saturated output power at 6 GHz, and gain — submit
   a CCATS request to BIS for an official, binding determination.

2. Dual-use nature: A 6 GHz, 40 W PA can have radar and electronic warfare
   applications. If the device is configurable for or marketed to military
   customers, revisit the USML (Category XI) and consider a Commodity
   Jurisdiction (CJ) request to DDTC.

3. German import controls: Germany applies EU dual-use Regulation (EU) 2021/821
   on the import/domestic transfer side. This analysis covers US export
   requirements only. Verify with your German consignee whether any EU or
   German national import permits are required for their end-use.

4. BIS regulations are updated frequently. Verify classifications and Country
   Chart entries against the current version of the EAR at ecfr.gov or
   bis.doc.gov before each shipment.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
REGULATORY CITATIONS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  • § 732.3         — Order of Review
  • § 734.3         — Items subject to the EAR
  • § 734.13        — Deemed export
  • § 736.2(b)      — Ten General Prohibitions
  • 15 CFR Part 738 — Commerce Country Chart
  • 15 CFR Part 740 — License Exceptions (STA at § 740.20; LVS at § 740.3;
                       GBS at § 740.4)
  • 15 CFR Part 744 — End-user and end-use controls
  • § 744.2–744.6   — WMD end-use prohibitions
  • 15 CFR Part 746 — Embargoes and special controls
  • 15 CFR Part 758 — Export clearance (EEI/AES filing)
  • 15 CFR Part 762 — Recordkeeping (5-year retention)
  • 15 CFR Part 774, Supplement No. 1, ECCN 3A001 — CCL entry for electronics

EAR CLASSIFICATION AND EXPORT LICENCE ANALYSIS
RF Power Amplifier — 6 GHz, 40 W Output, Commercial Wireless Base Station Use

Generated: 2026-05-07
Question: We manufacture an RF power amplifier that operates at 6 GHz with an output power of 40W. It is used in commercial wireless base stations. How do I classify it under the EAR, and does it need an export licence to ship to Germany?

================================================================================
1. OVERVIEW OF THE EAR CLASSIFICATION FRAMEWORK
================================================================================

The Export Administration Regulations (EAR), administered by the Bureau of Industry and Security (BIS) within the U.S. Department of Commerce, control the export of dual-use items (items with both commercial and potential military applications). Classification begins by determining whether the item is described by an Export Control Classification Number (ECCN) on the Commerce Control List (CCL), found at 15 C.F.R. Part 774, Supplement No. 1.

If an item is not described by any ECCN, it is classified as EAR99 — the lowest-control designation. EAR99 items may still require a licence in certain circumstances (e.g., prohibited end-use, prohibited end-user, embargoed destination), but they generally do not require a licence for export to close allies.

================================================================================
2. RELEVANT ECCN ANALYSIS
================================================================================

The item in question — an RF power amplifier operating at 6 GHz with 40 W output power for commercial wireless base stations — must be evaluated against the CCL, particularly Category 3 (Electronics) and relevant subcategories.

2.1 Primary Candidate: ECCN 3A001

ECCN 3A001 covers "Electronic components, as follows (see List of Items Controlled)." The most relevant sub-paragraph for this product is:

  3A001.b — "Radio-frequency (RF) power amplifiers" and related items.

Specifically, 3A001.b.1 and 3A001.b.2 address amplifiers designed or modified for operation above certain frequency and power thresholds. The precise control parameters under 3A001.b have historically included:

  - Frequency: Controls often engage for amplifiers capable of operating at frequencies associated with radar or electronic warfare bands, or above certain GHz thresholds specified in the technical note.
  - Output power: Thresholds vary by subparagraph and frequency band.
  - Designed/modified for: Military radar, electronic countermeasures (ECM), or specific wideband characteristics.

At 6 GHz and 40 W, the amplifier sits in the C-band / lower S-to-C-band range. Commercial wireless base station amplifiers (e.g., for LTE, 5G, or similar cellular infrastructure) operating in this range are generally purpose-built for commercial telecommunications. However, 6 GHz at 40 W approaches or may exceed certain control thresholds specified in 3A001.b depending on the exact regulatory language in force at the time of export.

2.2 Other Potentially Relevant ECCNs

  - 3A002: This covers general-purpose electronic equipment not specifically enumerated in 3A001. Less likely to apply here given that power amplifiers have explicit treatment in 3A001.
  - 5A001: Category 5, Part 1 (Telecommunications) covers telecommunications equipment and systems. RF components used in telecommunications end-use may also be reviewed under 5A001, though dedicated RF amplifier components are more typically captured under 3A001.
  - EAR99: If the amplifier's specifications fall below all ECCN thresholds — for example, if the power level and frequency combination does not meet the specific numeric parameters in 3A001.b — the item may qualify as EAR99.

2.3 Key Classification Considerations

To determine the exact ECCN with certainty, you should:

  a) Review the current text of ECCN 3A001.b in the CCL (15 C.F.R. Part 774, Supp. 1) for the precise frequency and power thresholds applicable at the time of export, as these parameters are periodically revised through the Wassenaar Arrangement and subsequent regulatory updates.

  b) Assess whether the amplifier is "specially designed" for any military, radar, or electronic warfare application — even if your stated use is commercial. The design intent and capability matter, not only the stated end-use.

  c) Consider whether the amplifier has wideband tuning capability, or whether it is narrowband and fixed-frequency for commercial cellular use (which tends to support a lower-control classification).

  d) If uncertain, submit a Commodity Classification Request (CCR) to BIS using BIS Form 748P, Supplement 1, for an authoritative ECCN determination. This is the safest path for borderline items.

Working assumption for this analysis: Given the commercial wireless base station end-use and 40 W at 6 GHz, the most likely classification is ECCN 3A001 (if the item meets control parameters) or EAR99 (if it falls below them). For the remainder of this analysis, both scenarios are addressed.

================================================================================
3. LICENCE REQUIREMENTS FOR EXPORT TO GERMANY
================================================================================

3.1 Germany as a Destination

Germany is a member of:
  - The European Union (EU)
  - NATO
  - The Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies
  - The Nuclear Suppliers Group (NSG)
  - The Australia Group
  - The Missile Technology Control Regime (MTCR)

For EAR purposes, Germany is in Country Group A:1 (Wassenaar Arrangement participants) and Country Group B. It is NOT in any of the more restrictive country groups (D:1 through D:5, or E:1/E:2). Germany is not subject to a U.S. embargo or comprehensive sanctions.

3.2 If the Amplifier is Classified EAR99

No licence is required to export to Germany. EAR99 items may be exported to Germany without a licence, subject only to the general prohibitions (Part 736) — i.e., you must still check denied parties lists and ensure no prohibited end-use or end-user is involved.

3.3 If the Amplifier is Classified ECCN 3A001

The Reasons for Control (RFC) associated with 3A001 typically include:
  - NS (National Security) — Column 1 or Column 2
  - AT (Anti-Terrorism) — Column 1
  - Possibly MT (Missile Technology) depending on sub-paragraph

For Germany and Country Group A:1/B destinations:

  - NS Column 1 controls: A licence exception is generally available. The most relevant is Licence Exception STA (Strategic Trade Authorization) under 15 C.F.R. § 740.20, which authorises export of many NS-controlled items to close allies including Germany without a specific licence, provided all STA conditions are met (e.g., the item is not 600-series/munitions, the consignee provides required STA assurances, etc.).

  - Alternatively, Licence Exception GOV may apply if the end-user is a government entity.

  - AT Column 1: Germany is not a terrorism-supporting state; AT controls do not restrict exports to Germany.

  - A specific licence (from BIS) would generally NOT be required for export to Germany for a commercial-use 3A001 amplifier, assuming STA or another applicable licence exception covers the transaction and no red flags are present.

3.4 Summary of Licence Determination

| Classification | Reason for Control | Germany Licence Needed? | Notes                                      |
|----------------|--------------------|-------------------------|--------------------------------------------|
| EAR99          | None               | No                      | Check denied parties, no other issues      |
| 3A001          | NS1, AT1           | Likely No               | Licence Exception STA typically available  |
| 3A001          | NS1, AT1           | Possibly                | If STA conditions not met; apply for BIS licence |

In practice, for a commercial RF power amplifier destined for wireless base station infrastructure in Germany, a specific export licence is very unlikely to be required. The combination of Germany's country group status, the commercial end-use, and available licence exceptions (particularly STA) means most such shipments proceed without individual BIS licence approval.

================================================================================
4. MANDATORY COMPLIANCE STEPS (REGARDLESS OF LICENCE REQUIREMENT)
================================================================================

Even when no licence is required, U.S. exporters must:

  1. Classify the item accurately and document the classification rationale in your export compliance records.

  2. Screen all parties: Check the consignee, end-user, and any intermediaries against:
     - BIS Denied Persons List (DPL)
     - BIS Entity List
     - BIS Unverified List
     - OFAC Specially Designated Nationals (SDN) List
     - State Department Debarred List (ITAR)
     - EU and UN consolidated sanctions lists (for completeness)

  3. Obtain an End-User Statement or End-Use Certificate if the item is ECCN-controlled and the transaction warrants it (good practice even when not strictly required).

  4. Comply with Electronic Export Information (EEI) filing requirements via AES (Automated Export System) / ACE if the shipment value exceeds $2,500 per Schedule B number or if a licence is required.

  5. Retain export records for five years from the date of export (15 C.F.R. § 762.6).

  6. Ensure your shipping documents (commercial invoice, packing list, shipper's export declaration) accurately describe the item and its ECCN/EAR99 classification.

================================================================================
5. IMPORTANT CAVEATS AND RECOMMENDATIONS
================================================================================

  a) This analysis is based on general knowledge of EAR regulations and is not a substitute for legal advice from a licensed export control attorney or a formal BIS commodity classification ruling.

  b) Export control regulations change. The specific numeric thresholds in ECCN 3A001.b should be verified against the current CCL text at the time of each export.

  c) If your amplifier has any specifications or design features that approach military-grade performance (e.g., broad tuning range, rugged MIL-SPEC construction, high efficiency at wide bandwidths), the classification risk increases and professional legal review is strongly advised.

  d) Germany has its own export controls under the EU Dual-Use Regulation (EU) 2021/821 and national Aussenwirtschaftsgesetz (AWG) / Aussenwirtschaftsverordnung (AWV). Your German customer or distributor may need to comply with EU-side re-export controls, particularly for onward shipment of the amplifier to third countries.

  e) If the amplifier were to be used in any application that could support military radar, electronic intelligence (ELINT), or electronic warfare — even incidentally — the risk profile changes significantly, potentially triggering ITAR jurisdiction (if it meets USML Category XI parameters) or requiring a specific BIS licence even for allied destinations.

================================================================================
6. RECOMMENDED NEXT STEPS
================================================================================

  1. Pull the current CCL text for ECCN 3A001.b and compare your amplifier's exact specifications (frequency range, output power, gain, bandwidth, efficiency) against each control parameter.

  2. If the product clearly falls below all 3A001.b thresholds, document it as EAR99 with a written classification rationale.

  3. If the product meets or is borderline on any 3A001.b parameter, consider filing a Commodity Classification Request (CCR) with BIS for a binding determination.

  4. Screen all parties in the Germany transaction against current denied/restricted party lists.

  5. Determine whether Licence Exception STA (or another exception) applies and document that determination.

  6. File EEI via ACE/AES if required.

  7. Consult an export control attorney or a licensed Export Management Company (EMC) if your product line includes multiple RF components with varying specifications, to establish a scalable classification process.

================================================================================
CONCLUSION
================================================================================

An RF power amplifier operating at 6 GHz with 40 W output power for commercial wireless base stations most likely falls under ECCN 3A001 (electronics — RF power amplifiers) or potentially EAR99 depending on whether its specifications meet the current CCL control thresholds. For export to Germany — a Wassenaar Arrangement member and close U.S. ally — a specific BIS export licence is very unlikely to be required. Licence Exception STA or other applicable exceptions typically authorise such shipments. However, accurate self-classification, denied-party screening, and proper record-keeping are mandatory regardless of whether a licence is needed.

DEEMED EXPORT ANALYSIS — CHINESE NATIONAL EMPLOYEE ACCESS TO 5D002 SOURCE CODE
================================================================================
Prepared under: Export Administration Regulations (EAR), 15 CFR Parts 730–774
Administered by: Bureau of Industry and Security (BIS), U.S. Department of Commerce

SCENARIO
--------
- Company: US software company
- Employee: Chinese national, Chinese/Australian dual citizen, located in the US
- Item at issue: Source code for a product classified under ECCN 5D002
- Question: What deemed export obligations apply? Is a licence required?

--------------------------------------------------------------------------------
1. ECCN CLASSIFICATION — 5D002
--------------------------------------------------------------------------------

ECCN 5D002 covers software specifically designed or modified for the development,
production, or use of commodities or software controlled under ECCN 5A002 or 5B002
(information security equipment), as well as software using "cryptography" as defined
in the CCL. In plain terms, 5D002 captures encryption software — including source
code for encryption products.

Reasons for Control under 5D002:
  - EI  (Encryption Items) — primary control
  - NS  (National Security)
  - AT  (Anti-Terrorism)

This is a controlled software classification, not EAR99. The source code of your
encryption product is almost certainly 5D002 software technology or software itself.
Note that "technology" for the development of 5D002 software (e.g., design
documentation, architecture specs, cryptographic algorithms) would be classified
5E002. For this analysis, we address source code access, which constitutes release
of the 5D002 software itself.

--------------------------------------------------------------------------------
2. DEEMED EXPORT RULE — § 734.13
--------------------------------------------------------------------------------

Under 15 CFR § 734.13, the "release" of controlled technology or software to a
foreign national in the United States is deemed to be an export to that person's
country of nationality. This is the cornerstone of deemed export compliance.

"Release" is defined broadly and includes:
  - Visual inspection of controlled items or materials
  - Oral briefings and demonstrations
  - Electronic transmission (email, file share, repository access)
  - Hands-on access to controlled systems or code

Granting your employee access to the 5D002 source code repository — whether via
GitHub, GitLab, an internal code server, or any other means — constitutes a
"release" of controlled software under § 734.13. This triggers a deemed export
analysis immediately.

--------------------------------------------------------------------------------
3. DUAL NATIONALITY RULE — MOST RESTRICTIVE NATIONALITY APPLIES
--------------------------------------------------------------------------------

This is the critical issue in your scenario. BIS applies the "most restrictive
nationality" rule to individuals holding dual or multiple citizenships:

  "For purposes of the deemed export rule, BIS will look to the most
   restrictive licensing treatment applicable to any nationality held
   by the individual."

Your employee holds both Chinese and Australian citizenship. The analysis is:

  - Australia: Country Group A:5 (allied/partner nation); highly favourable
    licensing treatment; many licence exceptions available
  - China: Country Group D:1 (national security-controlled country); D:5
    (arms embargo); significantly more restrictive licensing treatment

Result: The employee is treated as a CHINESE NATIONAL for all deemed export
licensing purposes, regardless of Australian citizenship.

Australian dual citizenship provides NO relief. The Chinese nationality controls.

This rule is not discretionary. It is BIS policy applied consistently across
enforcement actions. You may not argue that the employee's Australian passport,
Australian residency, or Australian cultural ties change the nationality
determination.

--------------------------------------------------------------------------------
4. LICENCE REQUIREMENT ANALYSIS FOR 5D002 TO CHINA
--------------------------------------------------------------------------------

Step 1 — Country Chart Check (15 CFR Part 738, Supplement No. 1)

For ECCN 5D002, the applicable Reasons for Control are EI, NS, and AT.
Check each against China (D:1 country) on the Commerce Country Chart:

  Control Column         China
  -----------------------------------------------
  NS Column 1            X  (licence required)
  NS Column 2            X  (licence required)
  EI (Encryption Items)  Special — see ENC analysis below
  AT Column 1            X  (licence required)

A licence requirement is triggered under NS controls. The EI control for 5D002
operates slightly differently and is addressed through the ENC licence exception
framework below.

Step 2 — Can a Licence Exception Apply?

Review the key licence exceptions under Part 740:

  TSU (Technology and Software Unrestricted, § 740.13):
  - Covers published software and technology in the public domain
  - Does NOT cover proprietary source code that is not publicly available
  - Your source code is NOT publicly released → TSU does not apply

  ENC (Encryption, § 740.17):
  - The ENC exception is the primary pathway for 5D002 items
  - Allows export/deemed export of certain encryption software to most destinations
    after a one-time review and annual reporting
  - Key eligibility tiers:
      § 740.17(b)(1): Mass-market encryption products — broadest availability,
        including to most Country Group D:1 countries, after one-time BIS/NSA
        review notification
      § 740.17(b)(2)-(3): Non-standard, proprietary encryption items — more
        restricted; generally NOT available to Country Group D:1 nations including
        China for source code

  CRITICAL: ENC § 740.17(b)(1) for mass-market products EXCLUDES source code.
  ENC § 740.17(b)(4) specifically restricts availability for encryption source
  code and non-publicly available encryption software to Country Group D:1
  countries including China.

  For 5D002 source code released as a deemed export to a Chinese national:
  - If the source code is for a product that qualifies as "mass market"
    (widely available, off-the-shelf, with no specialised military/government
    features), review § 740.17(b)(1) carefully — but source code (as opposed
    to object code) may still be excluded
  - For proprietary or non-mass-market encryption source code, ENC is generally
    NOT available for deemed exports to Chinese nationals

  CIV (Civil End-Users, § 740.7):
  - Available for NS-controlled items to D:1 countries for civil end-use
  - Does NOT apply to EI-controlled items (5D002 has EI control)
  - CIV is not available here

  GBS, TSR, LVS: Not applicable to 5D002 technology/software deemed exports
  to D:1 countries.

CONCLUSION ON LICENCE EXCEPTIONS:
For most 5D002 source code deemed export scenarios involving Chinese nationals,
no licence exception will be available. A BIS export licence will be required.

--------------------------------------------------------------------------------
5. IS A LICENCE REQUIRED? — BOTTOM LINE
--------------------------------------------------------------------------------

YES. A deemed export licence is required before your company allows this employee
access to the 5D002 source code, unless a specific exception analysis confirms
eligibility.

The specific pathway is:
  - Apply for a deemed export licence via SNAP-R (snap-r.bis.doc.gov)
  - Use Form BIS-748P (Multipurpose Application Form)
  - Describe the technology (5D002 source code), the nationality of the employee
    (Chinese national), and the intended use (software development within the
    company)
  - BIS/NSA will review; encryption licence applications involve NSA referral
  - Review timeline: up to 90 days; plan accordingly

IMPORTANT: Do NOT grant the employee access to the source code while the licence
application is pending. Doing so would constitute an unlicensed deemed export —
a violation carrying civil penalties up to $374,474 per violation (or 2x the
transaction value) and potential criminal exposure under § 764.2.

--------------------------------------------------------------------------------
6. POSSIBLE EXCEPTION — FUNDAMENTAL RESEARCH (§ 734.8)
--------------------------------------------------------------------------------

If any of the software development work qualifies as "fundamental research" —
basic or applied research at an accredited institution where results are ordinarily
published — the Fundamental Research Exclusion (FRE) under § 734.8 may apply.

However, for a US software company developing a commercial encryption product:
  - The work is not conducted at an accredited institution
  - The source code is proprietary and not intended for public release
  - The FRE almost certainly does NOT apply

Do not rely on this exception without a detailed legal review.

--------------------------------------------------------------------------------
7. PRACTICAL HR AND ACCESS CONTROL STEPS
--------------------------------------------------------------------------------

Immediate Actions (Before Any Source Code Access):

1. HALT SOURCE CODE ACCESS
   Remove or do not grant repository access to the employee until licence analysis
   is complete and a deemed export licence is obtained. This is a bright-line
   compliance requirement.

2. CONDUCT NATIONALITY VERIFICATION
   Obtain documentation confirming citizenship status. Under the most-restrictive
   nationality rule, Chinese nationality controls. Confirm there are no additional
   citizenships via an HR screening questionnaire (ensure questionnaire is
   legally reviewed for employment law compliance in your jurisdiction).

3. CLASSIFY ALL TECHNOLOGIES THE EMPLOYEE WILL ACCESS
   Map the specific source code modules, libraries, algorithms, and documentation
   the employee's role requires. Classify each under the EAR:
   - Encryption source code → 5D002 (primary)
   - Encryption technology (design specs, algorithm documentation) → 5E002
   - Test equipment → 5B002 (if applicable)

4. SCREEN THE EMPLOYEE AGAINST RESTRICTED PARTY LISTS
   Run the employee's name against:
   - BIS Entity List (Supplement 4, Part 744)
   - BIS Denied Persons List
   - BIS Unverified List
   - OFAC SDN List
   Use the Consolidated Screening List at trade.gov/consolidated-screening-list.
   Document the screening result. A match on any list creates a hard stop.

5. APPLY FOR DEEMED EXPORT LICENCE VIA SNAP-R
   File Form BIS-748P at snap-r.bis.doc.gov. Include:
   - Description of the 5D002 source code
   - Employee's name, nationality, job title, and role description
   - End-use statement: internal software development only
   - BIS-748P-A supplement for encryption items
   Engagement of export counsel experienced in encryption licences is strongly
   recommended given the NSA referral requirement.

6. IMPLEMENT ACCESS CONTROLS PENDING LICENCE
   During the period between hiring and licence receipt:
   - Assign the employee to non-controlled tasks (documentation, UI work, testing
     of non-encryption modules, or other EAR99 activities)
   - Use role-based access controls (RBAC) on all code repositories
   - Ensure the employee cannot access controlled source code through indirect
     means (shared drives, Slack/Teams file sharing, screen sharing, pair
     programming on controlled modules)

7. ESTABLISH ONGOING COMPLIANCE CONTROLS
   Once a licence is obtained:
   - Record the licence number, conditions, and expiry date
   - Document the access scope — what code repositories and modules are covered
   - Audit access logs periodically to ensure usage within licence scope
   - Re-apply at least 60 days before licence expiry
   - Update access controls if the employee's role changes

8. TRAINING
   Ensure the employee completes EAR/deemed export training before accessing any
   controlled material. Document completion. Retain training records for 5 years
   (§ 762.6).

9. RECORDKEEPING (§ 762)
   Retain all of the following for 5 years:
   - Deemed export licence application and approval
   - Nationality screening documentation
   - Restricted party screening records (dated)
   - Access control logs
   - Training records

--------------------------------------------------------------------------------
8. BROADER COMPLIANCE PROGRAMME IMPLICATIONS
--------------------------------------------------------------------------------

This scenario highlights gaps that should be addressed in your Export Compliance
Programme (ECP) if they are not already in place:

Element 3 — Written Policies and Procedures:
  Your ECP should include a written procedure for hiring foreign nationals into
  roles that involve access to controlled technology. The procedure should require:
  - Pre-hire deemed export screening for all technical roles
  - Classification review of technologies in the role scope
  - Licence or exception determination before access is granted
  - HR and Legal coordination on questionnaire design (nationality questions must
    comply with employment discrimination law, but may be asked for export
    compliance purposes under § 734.13)

Element 4 — Training:
  HR staff and engineering managers must understand deemed export concepts.
  Engineers should understand that sharing controlled source code with foreign
  national colleagues — even informally, in a code review or via a shared screen —
  can constitute an unlicensed deemed export.

Element 5 — Restricted Party Screening:
  Foreign national employees should be screened against restricted party lists
  at hire and periodically thereafter (recommended: annually, and whenever lists
  are materially updated).

Element 6 — Due Diligence:
  For employees from D:1 countries in sensitive technical roles, enhanced due
  diligence is appropriate. This does not mean discriminatory treatment but does
  mean earlier and more thorough export compliance analysis.

--------------------------------------------------------------------------------
9. SUMMARY TABLE
--------------------------------------------------------------------------------

Issue                          Analysis                        Conclusion
------------------------------ ------------------------------- ------------------
ECCN of source code            5D002 (encryption software)     Controlled item
Deemed export trigger          § 734.13 release of software    YES — triggered
Applicable nationality         Most restrictive = Chinese       China (D:1)
Country group for China        D:1, D:5                        High restriction
NS Country Chart check         NS Column 1 & 2 = X for China  Licence required
EI control / ENC exception     Source code excluded from       ENC likely N/A
                               ENC § 740.17(b)(1) for D:1
Other exceptions available     TSU, CIV, GBS, TSR              None applicable
Licence required?              YES                             Apply via SNAP-R
Access permitted pending app?  NO                              HALT access now
Restricted party screening     Required                        Screen before hire

--------------------------------------------------------------------------------
10. DISCLAIMER
--------------------------------------------------------------------------------

This analysis is provided for general EAR compliance guidance purposes only and
does not constitute legal advice. Export control regulations are complex, subject
to frequent amendment, and highly fact-specific. Engage qualified US export
counsel — particularly counsel with encryption (EI) and deemed export experience —
before making final compliance determinations or filing licence applications.

Key regulatory citations:
  - Deemed exports: 15 CFR § 734.13
  - Dual nationality rule: BIS policy; § 734.13 interpretive guidance
  - 5D002 classification: 15 CFR Part 774, ECCN 5D002
  - ENC licence exception: 15 CFR § 740.17
  - Country Chart: 15 CFR Part 738, Supplement No. 1
  - China country groups: 15 CFR Part 740, Supplement No. 1 (D:1, D:5)
  - SNAP-R licensing: snap-r.bis.doc.gov; Form BIS-748P
  - Recordkeeping: 15 CFR Part 762
  - Enforcement and penalties: 15 CFR §§ 764.2, 764.3, Part 766

================================================================================
END OF ANALYSIS
================================================================================

DEEMED EXPORT COMPLIANCE ANALYSIS
US Software Company — Chinese National Employee Access to 5D002 Encryption Source Code
Date of Analysis: 2026-05-07

==============================================================================
EXECUTIVE SUMMARY
==============================================================================

Granting a Chinese national (even one holding Australian dual citizenship) access
to source code for a product classified under ECCN 5D002 very likely triggers a
deemed export obligation under the Export Administration Regulations (EAR). A
BIS licence or applicable licence exception will almost certainly be required
before access is granted. This is a high-risk scenario that warrants careful
legal review before proceeding.

==============================================================================
1. BACKGROUND: THE DEEMED EXPORT RULE
==============================================================================

Under the EAR (15 CFR Part 734), a "deemed export" occurs when controlled
technology or source code is released to a foreign national inside the United
States. "Release" includes:

  - Visual inspection of technology by foreign nationals
  - Oral exchanges of information
  - Applying technology abroad after release in the US
  - Granting access to systems, source code repositories, or technical data

The deemed export is treated as an export to the foreign national's country of
citizenship/nationality, NOT the country where the release occurs (15 CFR
734.13).

==============================================================================
2. ECCN 5D002 — WHAT IT COVERS
==============================================================================

ECCN 5D002 ("Information Security" — software) falls under Category 5, Part 2
of the Commerce Control List (CCL). It covers software specifically designed or
modified for encryption, cryptanalysis, or key management functions. Source code
for encryption products (particularly those implementing non-standard or strong
encryption algorithms) typically falls under 5D002.c.1.

Control Reasons for 5D002:
  - AT  (Anti-Terrorism)
  - EI  (Encryption Items — the primary control reason)
  - NS  (National Security)

The EI (Encryption Items) controls are the dominant concern here and carry
specific review and licensing requirements under Supplement No. 1 to Part 742
and the encryption review provisions of Part 740.

==============================================================================
3. DUAL NATIONALITY — THE CRITICAL RULE
==============================================================================

BIS policy on dual nationals is unambiguous and unfavourable to the employer
in this scenario:

RULE: For deemed export purposes, BIS uses the MOST RESTRICTIVE nationality.
When a person holds citizenship in two countries, the country that imposes
the most restrictive export controls applies.

  - China is subject to comprehensive EI controls and significant NS controls.
  - Australia is a close ally with favourable treatment under EAR (e.g., Country
    Group A:1 — Wassenaar Arrangement).

Because the employee holds Chinese citizenship, BIS treats the deemed export
as an export TO CHINA regardless of the Australian citizenship. The Australian
citizenship does not dilute, override, or eliminate the China-related controls.

This is explicitly addressed in BIS guidance and has been the subject of
enforcement actions. Employers cannot rely on an employee's secondary
(more favourable) nationality to avoid licence requirements tied to the
primary (more restrictive) nationality.

Key point: The employee's Australian passport does not help here.

==============================================================================
4. CHINA'S CONTROL STATUS UNDER THE EAR
==============================================================================

China is classified in the following Country Groups relevant to this analysis:

  - Country Group D:1 (National Security concerns)
  - Country Group D:5 (US Arms Embargo)
  - NOT in Country Group A:1 (Wassenaar) or A:5/A:6 (Five Eyes / close allies)

For ECCN 5D002 with EI controls, exports/deemed exports to China are subject
to licence requirements or must qualify under a specific licence exception.

China is NOT on the EAR Exclusion list (e.g., not Cuba, Iran, North Korea,
Syria — which are subject to comprehensive embargoes), but it is a controlled
destination for encryption technology under the EI regime.

==============================================================================
5. LICENCE EXCEPTIONS — CAN ANY APPLY?
==============================================================================

Several licence exceptions exist for encryption items. The most commonly used
are:

A. ENC (Encryption — 15 CFR 740.17)

  ENC is the primary licence exception for encryption technology. It has
  multiple tiers:

  ENC Section 740.17(b)(1) — Mass market encryption software:
    - Applies to products that qualify as "mass market" under the EAR
    - Source code for encryption is generally NOT eligible for mass market
      treatment under 740.17(b)(1). The exception is more readily available
      for object code / compiled products, not source code.
    - Source code for 5D002 products typically requires a higher tier review.

  ENC Section 740.17(b)(3) — Government end users (allies):
    - Does not apply here (employee is not a government end user).

  ENC Section 740.17(d) — Unrestricted encryption source code:
    - Covers source code that is publicly available (e.g., posted to the
      internet without access controls). If the source code has already been
      published openly, it may qualify. However, most proprietary company
      source code does NOT qualify here.

  Annual Self-Classification Report: Companies using ENC must file an annual
  encryption registration/self-classification report with BIS and NSA
  (Supplement No. 8 to Part 742). Failure to file is itself a violation.

B. TSR (Technology and Software — Unrestricted, 15 CFR 740.13)

  TSR allows release of technology and source code that is:
    - Released to the public domain (no restriction on further dissemination)
    - Or "educational" in nature (basic scientific information in public domain)

  Proprietary commercial source code is NOT eligible for TSR.

C. TMP (Temporary — 15 CFR 740.9)

  For temporary exports/releases. This would not be applicable to ongoing
  employment access.

D. NLR (No Licence Required)?

  For 5D002 with EI controls and a Chinese national, NLR is not available
  as a blanket matter. The EI controls require affirmative action (either
  a licence or a qualifying licence exception with proper procedures).

CONCLUSION ON EXCEPTIONS: Unless the source code qualifies as publicly
available/open source (in which case ENC 740.17(d) or TSR may apply after
review), a BIS licence will very likely be required for a Chinese national to
access proprietary 5D002 encryption source code.

==============================================================================
6. OPEN SOURCE / PUBLICLY AVAILABLE CARVE-OUT
==============================================================================

If your source code is truly publicly available (e.g., on a public GitHub repo
with no access controls), the EAR's "publicly available" exemption (15 CFR
734.7) may mean the technology is not subject to the EAR at all. In that case,
no deemed export licence would be required.

However, this is a narrow carve-out:
  - The code must be genuinely publicly available without restriction
  - Most commercial encryption source code is proprietary and does NOT qualify
  - Even if parts of the codebase use open-source libraries, the proprietary
    integration, configuration, and custom components remain controlled

Do not assume this applies without a thorough legal review of what is public
vs. proprietary.

==============================================================================
7. WHAT OBLIGATIONS DOES THE COMPANY HAVE?
==============================================================================

Step 1 — Classify the technology
  Confirm the ECCN 5D002 classification is accurate. If any doubt, request
  a commodity classification ruling from BIS (CCATS request).

Step 2 — Do not grant access until compliant
  Access to controlled source code must be withheld until either:
    (a) A BIS licence is obtained; or
    (b) An applicable licence exception is confirmed in writing by counsel; or
    (c) A legal determination is made that the technology is publicly available
        and outside EAR jurisdiction.

Step 3 — Encryption Self-Classification / Annual Report
  If not already filed, ensure your encryption products are registered under
  the annual encryption self-classification report (Supplement No. 8 to Part
  742). This is a standalone compliance obligation separate from the deemed
  export question.

Step 4 — Apply for a BIS Licence if required
  Submit a licence application to BIS via SNAP-R (the online portal).
  For an individual deemed export:
    - Include the employee's biographical information
    - Describe the technology (ECCN, technical parameters)
    - Describe the business need
    - Expect BIS review times of 30–90+ days (encryption items may take longer
      due to NSA referral under EAR Part 742.15)

Step 5 — Implement internal controls
  While the licence application is pending (or as ongoing compliance):
    - Restrict the employee's repository/code access by role or need-to-know
    - Maintain access logs
    - Train the employee and their manager on EAR obligations
    - Document your compliance analysis in writing

Step 6 — Consult export counsel
  Given the complexity (5D002, Chinese national, dual nationality), engage a
  qualified US export control attorney before making any access decisions.

==============================================================================
8. PENALTIES FOR NON-COMPLIANCE
==============================================================================

EAR violations (including deemed export violations) carry serious consequences:

Civil penalties:
  - Up to $364,992 per violation (adjusted annually for inflation) or twice the
    value of the transaction, whichever is greater (as of recent adjustments)

Criminal penalties:
  - Up to $1,000,000 per violation and/or up to 20 years imprisonment
    (for wilful violations — Export Control Reform Act of 2018 / ECRA)

Other consequences:
  - Denial of export privileges (debarment from export activities)
  - Reputational damage
  - Government contract ineligibility

BIS has actively pursued deemed export enforcement cases. This is not a
theoretical risk.

==============================================================================
9. PRACTICAL CONSIDERATIONS — STRUCTURING FOR COMPLIANCE
==============================================================================

While the licence application is pending, consider whether the employee can
perform their role without accessing the controlled source code:
  - Can work be restructured to use compiled binaries only?
  - Can the employee work on non-encryption modules of the codebase?
  - Can access be granted to non-controlled supporting tools only?

If the employee's role genuinely requires source code access and a licence is
needed, plan for the lead time. BIS encryption licence applications involving
China can take several months.

Some companies obtain a blanket/standing deemed export licence for categories
of technology applicable to recurring employee situations, rather than
applying per-employee. Consider this for ongoing hiring needs.

==============================================================================
10. SUMMARY TABLE
==============================================================================

  Question                                  Answer
  ----------------------------------------  ---------------------------------
  Is 5D002 source code controlled?          Yes — EI, NS, AT controls apply
  Does deemed export rule apply?            Yes — release in US to foreign
                                            national = deemed export
  Does Australian citizenship help?         No — BIS uses most restrictive
                                            nationality (China prevails)
  Is China a controlled destination?        Yes — D:1 country group
  Does NLR apply?                           No
  Does ENC exception likely apply?          Only if source code is publicly
                                            available (unlikely for proprietary)
  Is a BIS licence required?                Almost certainly yes for proprietary
                                            source code
  Immediate action required?                Yes — do not grant access until
                                            legal review and licence obtained

==============================================================================
DISCLAIMER
==============================================================================

This analysis is provided for general informational purposes based on the EAR
framework as generally understood. It does not constitute legal advice. Export
control regulations change frequently and the facts of individual situations
significantly affect compliance outcomes. You should consult a qualified US
export control attorney before making any decisions about access, licensing,
or employee assignments involving controlled technology.

==============================================================================
END OF ANALYSIS
==============================================================================

SITUATION ANALYSIS: APPARENT EAR VIOLATION — ENTITY LIST RE-EXPORT OF A 3A001 SEMICONDUCTOR

You have described a serious apparent violation of the Export Administration Regulations (EAR),
15 CFR Parts 730–774, administered by the Bureau of Industry and Security (BIS), U.S. Department
of Commerce. This requires immediate, structured action. Below is a complete legal and compliance
roadmap.

================================================================================
PART 1 — UNDERSTANDING THE APPARENT VIOLATION
================================================================================

1.1 The Core Legal Problem

Your original export of a 3A001-classified semiconductor component to Singapore was, on its
face, a lawful transaction — Singapore is a Country Group A:1/B country and 3A001 items (Category
3, Electronics; Product Group A, Equipment) typically require a license only for specific Reasons
for Control to certain destinations. Singapore is generally a permissive destination.

The problem arises from the re-export. Under 15 CFR § 734.14, a "reexport" is any shipment,
release, or other transfer of an item subject to the EAR from one foreign country to another.
Your Singapore customer's onward transfer of the 3A001 component to a Chinese military research
institute on the Entity List (Supplement No. 4 to Part 744) constitutes an apparent unauthorized
reexport under 15 CFR § 736.2(b)(1) (General Prohibition One — export or reexport without a
required license) and § 736.2(b)(2) (General Prohibition Two — reexport contrary to a license
condition or EAR requirement).

1.2 Why the Entity List Is Central

The Entity List imposes a license requirement for ALL items subject to the EAR — regardless of
their ECCN or whether a license would otherwise be required for the destination country — when
shipped to a listed party (15 CFR § 744.11). For virtually all Entity List entries involving
Chinese military institutions, BIS's licensing policy is "presumption of denial," meaning a
license would almost certainly not have been granted. No license exception is available for
Entity List parties. (§ 740.2(a)(3) bars license exceptions for Supplement 4 parties.)

3A001 semiconductors are controlled for National Security (NS) and Anti-Terrorism (AT) reasons,
among potentially others depending on the specific item parameters. Items with NS controls
destined for a Chinese military end-user are among the most sensitive categories BIS enforces.

1.3 China Country Group Implications

China is in Country Group D:1 (national security concern). The receiving entity — a Chinese
military research institute — implicates § 744.21 (Military End-User controls) and potentially
§ 744.22 (Military Intelligence End-User controls), in addition to the Entity List restrictions
under § 744.11. If the institute is designated on the Entity List, § 744.11 controls are
dispositive; the MEU controls are additional layers of restriction.

1.4 The "Knew or Had Reason to Know" Standard — and Why It May Not Fully Protect You

You state you did not know at the time of original sale. The EAR "reason to know" standard
(§ 772.1) is objective — BIS asks whether a reasonable person in your position, given the
available facts, should have known. BIS will examine:

  - Did you conduct Know Your Customer (KYC) due diligence on the Singapore customer?
  - Did you obtain and verify an End-User Statement (EUS) or end-use certificate?
  - Were there red flags (§ 732.6 / Supplement 3 to Part 732) that were missed or ignored?
    (e.g., customer declining to identify the ultimate end-user, unusual order volume for a
    trading company, shipping to a transshipment hub with a declared end-user in a D:1 country)
  - Did your compliance program require screening of not just the direct customer but declared
    and potential end-users?

If red flags existed and were missed, BIS may find "reason to know" even without actual
knowledge. This distinction is critical to how the enforcement case will unfold.

================================================================================
PART 2 — IMMEDIATE STEPS TO TAKE (THE FIRST 72 HOURS)
================================================================================

Step 1: Convene an Internal Crisis Response Team
  - Immediately involve: General Counsel (or outside export controls counsel), Export Compliance
    Officer (ECO), senior management, and relevant business unit leads.
  - Do NOT discuss the potential violation in informal emails, chat, or with parties outside the
    response team. Attorney-client privilege should be established from the outset.
  - Retain outside EAR counsel with BIS enforcement experience if not already available in-house.

Step 2: Preserve All Records — Litigation Hold
  - Issue a document litigation hold immediately covering: all records related to the original
    Singapore transaction; all communications with the Singapore customer; shipping documents,
    invoices, purchase orders, EEI/AES filings, screening records; and any communications that
    may touch on the Chinese end-user.
  - Under 15 CFR § 762.2, you are required to retain export records for 5 years. Destruction of
    records after learning of a potential violation could itself constitute an additional violation
    and would be treated as an aggravating factor in any enforcement action.

Step 3: Stop Any Related Transactions
  - Immediately place the Singapore customer on hold for all pending orders.
  - Screen the Singapore customer against all restricted party lists (BIS Entity List, Denied
    Persons List, Unverified List, MEU List, OFAC SDN List) — if they do not themselves appear,
    evaluate whether they are a knowing facilitator whose future reliability is now compromised.
  - Identify any other transactions involving the same Singapore customer or any other customer
    that may have involved re-export to Chinese military entities.

Step 4: Conduct a Preliminary Internal Investigation
  - Reconstruct the original transaction: classification basis for 3A001, license determination,
    any license exception claimed, end-user screening conducted, due diligence documentation.
  - Establish what you now know about the Chinese military institute recipient: when you learned
    it, from what source, and what evidence exists.
  - Assess scope: Is this an isolated transaction or is there a pattern? Are there other shipments?

Step 5: File an Initial VSD Notification to Preserve the VSD Date (see Part 3 below)
  - Do not wait until the full investigation is complete. File a brief initial notification to OEE
    as soon as you have confirmed a likely apparent violation. This preserves your VSD date.

================================================================================
PART 3 — THE VOLUNTARY SELF-DISCLOSURE (VSD) PROCESS UNDER § 764.5
================================================================================

3.1 What a VSD Is

A Voluntary Self-Disclosure (VSD) is a self-initiated notification to BIS's Office of Export
Enforcement (OEE) of an apparent violation of the EAR, a license, or an order. It is governed
by 15 CFR § 764.5 and BIS's enforcement guidelines (Supplement No. 1 to Part 766).

Filing a VSD is strongly recommended — and in a matter of this seriousness, failing to disclose
carries substantially greater risk than disclosing. (See Part 4 on the disclosure vs. non-
disclosure calculus.)

3.2 The Two-Step VSD Process

STEP A — INITIAL NOTIFICATION (file immediately upon confirming a likely violation):

  - Written letter or email to: Office of Export Enforcement, Bureau of Industry and Security
  - Content: Company name and contact; general description of the apparent violation (item,
    destination, parties involved, approximate date); a statement that you are filing an initial
    VSD notification and will follow with a full submission.
  - Purpose: This locks in your VSD date. BIS will credit the disclosure from the date of the
    initial notification, not the date of the full submission.

STEP B — FULL VSD SUBMISSION (within 180 days of initial notification):

The full VSD must be a comprehensive written narrative including:

  (a) Company identification: name, address, EIN, CAGE code if applicable
  (b) Detailed facts: chronological narrative of all relevant events from order placement through
      discovery of the apparent violation
  (c) Transaction details for each affected shipment: shipper, consignee, declared end-user,
      actual end-user (the Chinese military institute), item description, ECCN (3A001),
      license exception claimed or license number, date of export, value of shipment
  (d) Legal analysis: which EAR provisions appear to have been violated (e.g., General Prohibition
      One under § 736.2(b)(1), § 744.11 Entity List requirements)
  (e) Root cause analysis: what controls failed, why the re-export was not caught
  (f) Remedial actions already taken: hold on customer, litigation hold, internal investigation
  (g) Proposed corrective actions: enhanced due diligence, updated screening, distributor
      agreement revisions, training enhancements (see Part 5)

3.3 What Happens After Filing

  - OEE will acknowledge receipt and assign a case number.
  - OEE may request additional information, documents, or interviews.
  - OEE may conduct End-Use Checks (post-shipment verifications) independently.
  - Resolution options:
      - No-Action Letter: Violation found minor; no penalty recommended
      - Warning Letter: Violation acknowledged; no monetary penalty; letter placed on record
      - Administrative penalty with VSD reduction: Negotiated settlement
      - Referral to Department of Justice for criminal investigation (reserved for egregious cases)

For a first-time violation with a strong compliance program and full cooperation, the likely
outcome for a non-willful violation is a warning letter or a significantly reduced administrative
penalty. However, given the Entity List party and military end-user dimensions, BIS will treat
this as a sensitive matter and the resolution will not be automatic.

================================================================================
PART 4 — CIVIL PENALTY EXPOSURE: DISCLOSING VS. NOT DISCLOSING
================================================================================

4.1 Penalty Structure Under § 764.3 and Part 766

Civil penalties for EAR violations are assessed per violation — and each shipment can constitute
multiple violations (wrong destination, wrong end-user, failure to obtain license = multiple
counts from a single transaction):

  Maximum civil penalty: Greater of $374,474 per violation (FY2025 inflation-adjusted figure)
                         OR 2 times the value of the transaction

For a single semiconductor shipment of even modest value, penalty exposure without mitigation
could easily reach $500,000–$1,000,000+ per transaction, and if multiple shipments are
involved, liability compounds accordingly.

Given the involvement of an Entity List military end-user in China — among the highest-priority
enforcement targets for BIS — OEE will apply heightened scrutiny and may treat this as an
egregious case if willfulness or recklessness is found.

4.2 The Mitigation Effect of a VSD

Under Supplement No. 1 to Part 766, BIS's penalty mitigation guidelines expressly identify
a VSD as a strong mitigating factor. In practice:

  WITH a VSD + strong ECP + full cooperation + remediation:
    - Non-egregious violations: Often resolved via warning letter or significant penalty reduction
      (50% or more reduction from base penalty)
    - Egregious violations: Penalty reduction of 25–40% from the otherwise-applicable maximum,
      plus reduced risk of Denial of Export Privileges

  WITHOUT a VSD:
    - If BIS discovers the violation independently (e.g., through an end-use check, tip-off,
      or customs data), the deliberate failure to disclose becomes an aggravating factor
    - BIS can assess the full statutory maximum; denial of export privileges becomes more likely
    - If the failure to disclose was deliberate, it may independently constitute a violation
      under § 764.2 (acting with knowledge of a violation)

4.3 Criminal Referral Considerations

Criminal penalties under § 764.2 apply to willful violations:
  - Individuals: Up to 20 years imprisonment + up to $1 million per violation
  - Corporations: Up to $1 million per violation

Criminal referral to DOJ is reserved for cases involving deliberate evasion, proliferation
risk, or knowing facilitation of military programs. Your scenario — unknowing original export
with subsequent discovery — is not the paradigm criminal case. However:

  - If the internal investigation reveals that employees had actual knowledge and concealed it,
    criminal exposure becomes real.
  - Failure to disclose after discovery, if deliberate, significantly raises criminal risk.
  - Cooperating fully with BIS via VSD and demonstrating good faith substantially reduces
    the probability of criminal referral.

4.4 The Disclosure Decision — Bottom Line

Given the facts as described (no knowledge at time of sale, discovered post-shipment), the
risk calculus strongly favors disclosure:

  DISCLOSE (VSD):
    + Strong penalty mitigation
    + Demonstrates good faith; likely outcome is warning letter or reduced civil penalty
    + Reduces criminal referral risk
    + Demonstrates effective compliance culture to regulators
    - Requires full cooperation, candor, and remediation commitment

  DO NOT DISCLOSE:
    - If BIS independently discovers the violation (highly likely for Entity List cases,
      which receive heightened scrutiny including end-use checks), maximum penalties apply
    - Deliberate non-disclosure is itself an aggravating — and potentially independent —
      violation
    - Vastly higher civil and criminal exposure
    - Possible Denial of Export Privileges, which would effectively end your ability to export

The decision to file a VSD should be made with export counsel, but the analysis here almost
universally points toward disclosure.

================================================================================
PART 5 — REMEDIATION STEPS
================================================================================

Following the VSD, BIS expects to see credible, specific corrective actions. These must be
included in the full VSD submission and implemented. Recommended steps:

5.1 Immediate Transaction-Level Remediation
  - Suspend all shipments to the Singapore customer pending investigation.
  - Notify the Singapore customer in writing that they must provide full documentation of all
    downstream transactions involving your products. (Do not tip off that you are filing a VSD,
    but you can require end-use information under your contractual terms.)
  - Assess whether the Singapore customer themselves should be reported to OEE separately as
    a knowing transshipper (§ 764.2(e) prohibits any person from facilitating a prohibited
    transaction).

5.2 Compliance Program Enhancements

  (a) Restricted Party Screening — Enhanced:
      - Implement transactional screening not just of the direct customer but also of declared
        end-users on export documentation.
      - For Singapore and other transshipment-risk jurisdictions (Hong Kong, UAE, Turkey,
        Malaysia): require an end-user certificate identifying the ultimate end-user before
        order acceptance — not just at shipment.
      - Re-screen all existing high-risk distributor relationships against all BIS lists and OFAC.

  (b) Know Your Customer (KYC) — Strengthen:
      - Require End-User Statements (EUS / BIS-711) for all 3A001 and similarly controlled items
        destined for known transshipment hubs.
      - Conduct enhanced due diligence: customer site visits or third-party due diligence reports
        for high-value/high-risk customers.
      - Add contractual representations and warranties in distributor and reseller agreements:
        downstream customers must be screened; re-export to D:1 country end-users requires
        separate authorization; customer must notify you of any re-export requests.

  (c) Red Flag Review:
      - Audit the original transaction file to identify whether red flags existed. If they did,
        implement a formalized red flag checklist for order acceptance (see § 732.6 and Supplement
        3 to Part 732).
      - Require ECO sign-off on any transaction involving a customer in a known transshipment
        jurisdiction when the product is NS-controlled.

  (d) Training:
      - Conduct immediate targeted training for sales, logistics, and customer management teams
        on Entity List obligations, re-export responsibilities, and transshipment red flags.
      - Annual refresher training going forward with documented completion records (5-year
        retention per § 762.6).

  (e) Distributor Agreement Revisions:
      - Update all distributor and reseller agreements to include: export compliance
        representations, re-export restrictions, right to audit, flow-down of EAR obligations to
        sub-distributors, and termination rights for compliance violations.

  (f) Post-Shipment Verification (Internal):
      - For controlled items shipped to transshipment-risk destinations, implement a post-shipment
        follow-up process: contact the customer 30–60 days post-delivery to confirm receipt and
        request confirmation of end-use/end-user as declared.

5.3 Internal Audit
  - Conduct an immediate retroactive audit of all shipments to this Singapore customer for the
    past 5 years (the recordkeeping period under § 762.6). Identify any other transactions that
    may involve similar issues and include them in the VSD.
  - BIS will expect a comprehensive disclosure — a VSD that omits related violations discovered
    in the same investigation will be treated as an incomplete disclosure.

5.4 Leadership and Governance
  - Brief senior leadership and board (if appropriate) on the apparent violation and the VSD
    decision.
  - Assign ownership of the remediation plan to the ECO with executive sponsor accountability.
  - Document all remediation actions with dates and evidence — BIS will review these as part of
    the VSD resolution process.

================================================================================
PART 6 — TIMELINE SUMMARY
================================================================================

  IMMEDIATELY (Day 1–3):
    - Convene crisis response team; retain outside export counsel
    - Issue litigation hold; preserve all records
    - Suspend related transactions
    - Begin preliminary internal investigation

  WITHIN DAYS (Day 3–14):
    - Complete preliminary investigation sufficient to confirm apparent violation
    - File INITIAL VSD NOTIFICATION to OEE (locks in VSD date)
    - Begin full internal investigation and transaction audit

  WITHIN 180 DAYS of Initial Notification:
    - Complete full investigation
    - File FULL VSD SUBMISSION with all required elements
    - Implement initial remediation steps; document and include in VSD

  ONGOING:
    - Cooperate fully with OEE requests for information
    - Continue and document remediation program
    - Await OEE resolution (warning letter, negotiated settlement, or further action)

================================================================================
PART 7 — KEY REGULATORY REFERENCES
================================================================================

  15 CFR § 734.14        — Definition of "reexport"
  15 CFR § 736.2(b)(1)   — General Prohibition One (export/reexport without license)
  15 CFR § 736.2(b)(2)   — General Prohibition Two (violation of license terms/conditions)
  15 CFR § 740.2(a)(3)   — License exceptions unavailable for Entity List parties
  15 CFR § 744.11        — Entity List license requirements
  15 CFR § 744.21        — Military End-User (MEU) controls
  15 CFR § 762.6         — Recordkeeping; 5-year retention requirement
  15 CFR § 764.2         — Violations: prohibitions and criminal penalties
  15 CFR § 764.3         — Civil penalties; maximum per-violation amounts
  15 CFR § 764.5         — Voluntary Self-Disclosure process
  15 CFR Part 766, Supp. 1 — Penalty mitigation and aggravation guidelines
  15 CFR § 772.1         — "Reason to know" definition
  15 CFR § 732.6 / Supp. 3 to Part 732 — Red flag indicators

  ECCN 3A001             — Electronics, Category 3, Equipment (semiconductors, integrated
                           circuits, components) — NS, AT, NP, RS controls typically apply

================================================================================
DISCLAIMER
================================================================================

This analysis is provided for informational and compliance planning purposes under the EAR
framework. It does not constitute legal advice and does not establish an attorney-client
relationship. Given the enforcement sensitivity of this matter — involving an Entity List party,
a Chinese military end-user, and NS-controlled semiconductor components — you should engage
qualified outside export control counsel before taking any external-facing action, including
filing the VSD. The analysis above reflects BIS regulations and enforcement practice as of 2025
and should be verified against current BIS guidance.

EXPORT COMPLIANCE RESPONSE: DISCOVERED EAR VIOLATION — 3A001 RE-EXPORT TO ENTITY LIST PARTY

Situation Summary:
- Your company exported a 3A001-classified semiconductor to a customer in Singapore.
- That Singapore customer re-exported the item to a Chinese military research institute on the BIS Entity List.
- You did not know of the intended re-export at the time of original sale.
- You have now discovered the apparent violation.

This is a serious situation involving potential violations of the Export Administration Regulations (EAR), 15 C.F.R. Parts 730-774, administered by the Bureau of Industry and Security (BIS) within the U.S. Department of Commerce. The key concern is that 3A001 items (semiconductors, electronic components) are controlled for National Security (NS), Anti-Terrorism (AT), and potentially other reasons, and exports/re-exports to Entity List parties generally require a license that is almost certainly subject to a policy of denial for Chinese military end-users.

Below is a step-by-step guide on what to do.

---

STEP 1: STOP AND PRESERVE EVERYTHING IMMEDIATELY

- Issue a litigation/investigation hold on all documents, records, emails, contracts, shipping documents, invoices, bank records, and communications related to this transaction.
- Do not destroy, alter, or delete any records. Obstruction of a federal investigation is a separate and serious crime.
- Suspend any ongoing shipments or dealings with this Singapore customer until the situation is fully assessed.
- Identify and secure records of the original export: EAR99 or ECCN classification records, the license determination, the end-use/end-user statements or certifications obtained from the Singapore buyer, shipper's export declaration (EEI filed in AES), and any due diligence documentation.

---

STEP 2: ASSEMBLE AN INTERNAL RESPONSE TEAM

- Immediately loop in:
  - Legal counsel (ideally experienced export controls counsel)
  - Senior management / C-suite
  - Your export compliance officer (if you have one)
  - Finance (for potential disgorgement considerations)
- Do not conduct informal, uncoordinated inquiries. All fact-gathering should be directed by counsel to preserve attorney-client privilege where possible.

---

STEP 3: CONDUCT AN INTERNAL INVESTIGATION

Under counsel's direction, investigate:

a) The original export:
   - Was the Singapore customer properly vetted at time of sale? Were they screened against the Consolidated Screening List (Entity List, SDN List, Denied Persons List, Debarred List)?
   - Was the ECCN 3A001 classification accurate?
   - What license exception, if any, was used — or was a license obtained?
   - What end-use/end-user statements were collected from the Singapore buyer?
   - Were there any red flags at the time that should have prompted additional diligence (e.g., questions about the end-use, unusual payment arrangements, requests for export control markings to be removed)?

b) The re-export:
   - How did you learn of the re-export? When did it occur?
   - What evidence do you have of the Chinese military research institute as the actual end-user?
   - Is that institute confirmed on the Entity List? (Check the current BIS Entity List at bis.doc.gov)
   - Was there a license requirement for the re-export from Singapore to China? (Almost certainly yes — re-exports of U.S.-origin controlled items from third countries to Entity List parties require BIS authorization.)
   - Did the Singapore customer have any obligation to notify you or seek authorization? (Review your customer agreement and any re-export certifications they signed.)

c) Culpability assessment:
   - Did your company have actual knowledge of the re-export destination?
   - Were there red flags you should have acted on ("reason to know")?
   - Was the Singapore customer acting as a conduit/transshipment hub — and were there indicators of this?
   - Is there any evidence of intentional structuring to evade controls?

The answers to these questions will determine the severity of the violation and shape your disclosure strategy.

---

STEP 4: CONSIDER VOLUNTARY SELF-DISCLOSURE (VSD) TO BIS

This is one of the most important decisions you will make. BIS strongly encourages voluntary self-disclosure and provides significant mitigation credit for companies that self-report violations promptly, cooperate fully, and remediate.

Why disclose:
- BIS provides up to 50% reduction in base penalty for a VSD.
- Failure to disclose — especially if BIS discovers the violation on its own — typically results in far harsher penalties.
- Voluntary disclosure demonstrates good faith and can influence whether BIS pursues criminal vs. civil enforcement (BIS/OEE handles civil; DOJ handles criminal).
- EAR violations can carry civil penalties of up to $364,992 per violation (indexed for inflation) or twice the value of the transaction, whichever is greater, and criminal penalties of up to $1,000,000 per violation and/or 20 years imprisonment.

The VSD Process (15 C.F.R. Part 764, Supplement No. 1):

1. Initial Notification: Submit a letter to the Director, Office of Export Enforcement (OEE), BIS, providing initial notice that you are conducting an internal review of a potential violation and intend to make a full submission. This letter preserves the date of disclosure. Send it promptly — do not wait until the investigation is complete.

   Send to:
   Office of Export Enforcement
   Bureau of Industry and Security
   U.S. Department of Commerce
   14th Street and Pennsylvania Ave., NW
   Washington, D.C. 20230
   (or the appropriate regional OEE field office)

2. Full Submission: Within 180 days of the initial notification (extensions can be requested), submit a comprehensive written disclosure that includes:
   - A narrative description of the violation(s), including dates, parties, items, and ECCNs
   - All relevant supporting documents (shipping records, invoices, correspondence, screening records)
   - An explanation of how the violation occurred
   - A description of your remediation efforts (see Step 5)
   - Your internal compliance improvements

3. Cooperation: Respond promptly to any follow-up requests from OEE. Full cooperation is a mitigating factor.

Note: If there is any possibility of criminal conduct (intentional evasion, conspiracy, willful blindness), you must discuss with counsel whether to also make disclosure to DOJ or coordinate with OEE on referral.

---

STEP 5: CONSIDER WHETHER OFAC IS ALSO IMPLICATED

Chinese military entities may also appear on OFAC's SDN List or other OFAC lists. If the end-user is OFAC-designated (not just BIS Entity Listed), you may have additional disclosure obligations to the Office of Foreign Assets Control (OFAC) under IEEPA/EO authorities separate from the EAR.

Check: Is the Chinese military research institute on the SDN List or any OFAC list? If yes, consult counsel about a separate OFAC voluntary self-disclosure.

---

STEP 6: NOTIFY OTHER POTENTIALLY IMPLICATED AGENCIES

Depending on the nature of the semiconductor and its capabilities, other agencies may have jurisdiction:
- State Department / DDTC: If the item has defense application and could be construed as a defense article, ITAR may be implicated. (3A001 semiconductors are generally EAR-controlled, but review carefully.)
- DOJ / FBI: BIS OEE may refer criminal matters to DOJ. If you believe criminal conduct occurred (by your company or the Singapore customer), counsel should assess proactive engagement.
- U.S. Customs and Border Protection (CBP): May be relevant if the original export documentation was incorrect.

---

STEP 7: ADDRESS THE SINGAPORE CUSTOMER

- Review your contractual agreements with the Singapore customer. Most robust export-controlled sales contracts include re-export restrictions, end-use certifications, and indemnification clauses for export violations by the buyer.
- Consider whether to terminate the relationship or suspend business pending resolution.
- Do not coach or collude with the Singapore customer on what to tell regulators.
- Preserve all communications with the customer; do not contact them in ways that could appear to be witness tampering.

---

STEP 8: REMEDIATE YOUR COMPLIANCE PROGRAM

BIS evaluates the strength of your export compliance program as a mitigating factor. Use this incident to:

1. Audit your screening processes: Were all parties — including end-users and known re-export destinations — screened against the Consolidated Screening List? If not, implement automated screening.

2. Review your ECCN classification procedures: Ensure all products are properly classified. 3A001 items carry significant controls, especially for China (AT-Column 1, NS Column 1 controls apply; China requires specific license for most NS-controlled items).

3. Strengthen end-use/end-user documentation: Implement robust end-user certifications that explicitly require customers to notify you before re-exporting to controlled destinations and prohibit re-export to Entity List parties.

4. Implement red flag training: Train sales, customer service, and logistics staff to recognize red flags — unusual shipping routes, customers unwilling to identify end-users, requests involving controlled countries.

5. Conduct a transaction review: Look back at other sales to this Singapore customer and similar customers. Were there other shipments that may have been re-exported to problematic end-users?

6. Update your compliance policies and procedures: Document the improvements in writing for the VSD submission.

---

STEP 9: DOCUMENT EVERYTHING

Keep detailed records of:
- When you discovered the issue
- Who was notified internally and when
- What investigative steps were taken and when
- What remediation steps were implemented
- All communications with BIS/OEE

This documentation supports your VSD and demonstrates good faith.

---

KEY MITIGATING FACTORS UNDER BIS GUIDELINES (Supplement No. 1 to Part 766)

BIS considers the following mitigating factors in penalty calculations:
- Voluntary self-disclosure (up to 50% reduction)
- No prior violations
- Cooperation with investigation
- Remedial compliance measures taken
- Item did not provide significant military or WMD advantage
- No evidence of intentional evasion
- Transaction was isolated / not part of a pattern

Aggravating factors that increase penalties:
- Willful or intentional conduct
- Prior violations
- Involvement of WMD-related items or end-users
- Obstruction of investigation
- Large commercial benefit from the violation
- Items with significant military application reaching military end-users

---

IMPORTANT CAVEATS

This analysis is general guidance based on publicly available EAR frameworks and BIS enforcement policy. It is NOT legal advice. Given the severity of this situation — Entity List party, Chinese military end-use, controlled semiconductor — you must engage experienced export controls legal counsel immediately. The facts of your specific case will determine the appropriate strategy, and missteps (including delay) can significantly worsen outcomes.

Time is critical. The sooner you move on Step 1 (preservation) and initiate attorney engagement, the better positioned you will be.

---

QUICK REFERENCE: KEY BIS RESOURCES

- BIS Office of Export Enforcement (OEE): www.bis.doc.gov/oee
- EAR Voluntary Self-Disclosure: 15 C.F.R. Part 764, Supplement No. 1
- BIS Penalty Guidelines: 15 C.F.R. Part 766, Supplement No. 1
- Consolidated Screening List: export.gov/csl (or trade.gov)
- Entity List: 15 C.F.R. Part 744, Supplement No. 4
- ECCN 3A001: 15 C.F.R. Part 774, CCL Category 3

---

Response generated: 2026-05-07
Disclaimer: This is general informational guidance only, not legal advice. Consult qualified export controls counsel immediately.

EAR COMPLIANCE ANALYSIS: COMMERCIAL EXPORT OF CYBERSECURITY SOFTWARE WITH AES-256 ENCRYPTION
Destinations: France, India, Brazil
Prepared under: 15 CFR Parts 730–774 (Export Administration Regulations)
Administered by: Bureau of Industry and Security (BIS), U.S. Department of Commerce

================================================================================
EXECUTIVE SUMMARY
================================================================================

Your cybersecurity software incorporating AES-256 encryption is almost certainly
classified as ECCN 5D002 under the Commerce Control List (CCL). A BIS licence is
not required for commercial export to France, India, or Brazil provided you qualify
for the ENC licence exception under § 740.17. However, a one-time BIS notification
(filing via SNAP-R) is a mandatory precondition before first use of the exception.
No ongoing annual licence is needed, but recordkeeping and restricted-party
screening obligations apply to every shipment.

Below is a step-by-step analysis.

================================================================================
STEP 1 — JURISDICTION DETERMINATION (ORDER OF REVIEW)
================================================================================

Before classifying under the EAR, apply the mandatory Order of Review.

1. ITAR / USML (22 CFR Part 121): Commercial encryption software for cybersecurity
   does not appear on the United States Munitions List. It is not an ITAR-controlled
   defence article. Jurisdiction is NOT with DDTC.

2. Other agencies: Encryption software of this type falls outside NRC, FDA, DEA,
   and ATF controls.

3. Subject to EAR (§ 734.3): US-origin software is subject to the EAR regardless
   of where it is located. Your product is subject to EAR.

4. Proceed to CCL classification.

================================================================================
STEP 2 — ECCN CLASSIFICATION: 5D002
================================================================================

Category 5, Part 2 — Information Security.

Your cybersecurity software falls under:

  ECCN 5D002 — "Software" specially designed or modified for the "development",
  "production" or "use" of equipment or "software" controlled by 5A002 or 5B002,
  or software providing capabilities of equipment controlled by 5A002 or 5B002.

AES-256 is a symmetric block cipher with a key length of 256 bits, well above the
56-bit threshold that triggers encryption controls. Commercial cybersecurity
software implementing AES-256 as a primary or integral feature is a paradigmatic
5D002 product.

Reasons for Control (RFCs) for ECCN 5D002:
  - EI  — Encryption Items (primary reason for control)
  - NS  — National Security (Column 2)
  - AT  — Anti-Terrorism (Column 1)

Note: If your software also incorporates features beyond encryption — e.g.,
intrusion detection, firewall components, or vulnerability assessment tools — those
features should be evaluated separately. However, the AES-256 encryption component
alone is sufficient to produce a 5D002 classification.

If you have not already obtained an official ECCN determination, consider submitting
a Commodity Classification Automated Tracking System (CCATS) request via SNAP-R
(snap-r.bis.doc.gov) using Form BIS-748P. This creates a defensible, BIS-endorsed
classification record.

================================================================================
STEP 3 — LICENCE REQUIREMENT ANALYSIS (COUNTRY CHART)
================================================================================

The Commerce Country Chart (Part 738, Supplement No. 1) determines whether a
licence is required by cross-referencing the ECCN's RFCs against each destination.

--- France ---

Country Group membership: A:1 (Wassenaar Arrangement), A:2 (Australia Group),
A:3 (MTCR), A:4 (NSG), A:5 (allied/partner), B. NOT in any D or E group.

Country Chart result for 5D002:
  - NS Column 2: No "X" for France → no licence required on NS grounds
  - EI: France is not on the EI column with an "X" for standard commercial encryption
  - AT Column 1: No "X" for France (Country Group B, not AT-controlled destination)

Preliminary conclusion: France does not generate a licence requirement on the
Country Chart for 5D002 commercial encryption software. However, the ENC exception
framework still applies because 5D002 carries EI controls, and BIS notification
under § 740.17 is the mechanism that authorises export of EI-controlled items.

--- India ---

Country Group membership: B. India is NOT in Country Group A:5 and is not a
member of all four multilateral export control regimes. India is also NOT in D:1,
D:2, D:3, D:4, D:5, E:1, or E:2.

Country Chart result for 5D002:
  - NS Column 2: Check — India does have an "X" for NS2 controls in some CCL entries,
    but for 5D002 (EI-controlled), the ENC exception framework governs.
  - AT Column 1: No "X" for India.
  - EI: India is not a prohibited destination for ENC (not E:1 or E:2).

Preliminary conclusion: India is an eligible ENC destination. The ENC exception
under § 740.17 is available, subject to the conditions described below.

--- Brazil ---

Country Group membership: B. Brazil is not in Country Group A:5 and is not in any
D or E group.

Country Chart result for 5D002:
  - Same analysis as India applies. Brazil is an eligible ENC destination.
  - Brazil is not on the E:1 or E:2 list.

Preliminary conclusion: Brazil is an eligible ENC destination.

================================================================================
STEP 4 — ENC LICENCE EXCEPTION (§ 740.17) — DETAILED ANALYSIS
================================================================================

The ENC licence exception at § 740.17 is the primary — and almost certainly the
correct — authorisation for your commercial exports of AES-256 cybersecurity
software to all three destinations.

--- ENC EXCEPTION STRUCTURE: THREE TIERS ---

TIER 1 — § 740.17(a): Mass-Market Encryption
  Applies to: Encryption commodities and software that qualify as "mass market"
  under the criteria in § 740.17(b)(1) and Note 3 to Category 5, Part 2 of the CCL.

  Mass-market criteria (all must be met):
    1. The software is generally available to the public by being sold from stock
       at retail selling points (physical or online) without restriction.
    2. The encryption functionality cannot be easily changed by the user.
    3. Designed for installation by the user without substantial support from the
       supplier.
    4. AES-256 qualifies as a standard, widely deployed algorithm — not proprietary
       or non-standard encryption.

  If your cybersecurity software is sold commercially off-the-shelf or via
  standard download/subscription with no customised key management or bespoke
  encryption architecture, it almost certainly qualifies as mass market.

TIER 2 — § 740.17(b)(1): Source Code for Mass-Market Products
  If you are exporting the source code of a mass-market encryption product (e.g.,
  to an open-source community, a distribution partner, or for integration), this
  tier applies. One-time BIS notification is still required.

TIER 3 — § 740.17(b)(3): Non-Standard / Proprietary Encryption
  If your encryption implementation is proprietary, non-standard, or cannot meet
  the mass-market criteria above, Tier 3 applies. This requires an annual
  self-classification report rather than a one-time notification.

  ASSESSMENT: For standard AES-256 in commercially sold cybersecurity software,
  Tier 1 (§ 740.17(a)) is the most likely applicable tier. Confirm with your
  product manager that the mass-market criteria above are all satisfied.

--- THE ONE-TIME BIS NOTIFICATION REQUIREMENT ---

CRITICAL REQUIREMENT: You CANNOT use the ENC exception until you have filed the
required notification with BIS. This is not optional.

How to file:
  1. Submit Form BIS-748P-A ("Supplement to Form BIS-748P") via SNAP-R at
     snap-r.bis.doc.gov.
  2. The notification covers the product (or product line) and its encryption
     specifications (algorithm, key length, protocol).
  3. BIS does not "approve" the notification — it is self-effectuating after filing.
     You may begin exporting under ENC once the notification is submitted.
  4. One notification covers all eligible destinations; you do not need separate
     filings per country.

What the notification must include:
  - Product name and description
  - ECCN (5D002)
  - Encryption algorithms and key lengths (AES-256, and any others such as RSA,
    SHA-2, TLS version)
  - Intended markets and customer types
  - Statement that the product meets mass-market criteria (for Tier 1)

After filing: Retain a copy of the SNAP-R submission confirmation in your
compliance records. This filing must be renewed if you materially change the
encryption features of the product.

--- ANNUAL SELF-CLASSIFICATION REPORT (§ 742.15(b)) ---

All exporters relying on ENC (§ 740.17) must submit an annual self-classification
report to BIS and NSA by February 1 of each year. This report covers all products
exported under ENC during the prior calendar year. This is separate from, and in
addition to, the one-time notification.

The annual report is submitted via SNAP-R and must include:
  - Product name and version
  - ECCN
  - Encryption details
  - Approximate number of units/copies exported

================================================================================
STEP 5 — COUNTRY GROUP ANALYSIS FOR FRANCE, INDIA, AND BRAZIL
================================================================================

FRANCE:
  Country Group: A:1, A:2, A:3, A:4, A:5, B
  ENC eligibility: YES — France is a highly favoured destination. As an A:5 country
  and EU member, France poses the lowest ENC compliance burden. The ENC exception
  under § 740.17(a) is fully available.
  Any restrictions: None specific to France for commercial encryption software.
  Reexport: French customers may further reexport under ENC to most Country Group B
  destinations without returning to you for authorisation, subject to their own
  ENC compliance under the EAR (as foreign re-exporters, they are subject to EAR
  reexport controls if the software was of US origin).

INDIA:
  Country Group: B
  ENC eligibility: YES — India is a Country Group B destination. The ENC exception
  is available under § 740.17(a).
  Additional note: India is not a member of the Wassenaar Arrangement (A:1) or
  Country Group A:5, meaning some other licence exceptions (e.g., TSR, GBS) have
  narrower availability for India. However, for ENC specifically, Country Group B
  eligibility is sufficient.
  India-specific considerations:
    - India has its own domestic encryption regulations (IT Act, 2000 and related
      rules). While this does not affect your US EAR obligations, advise Indian
      customers that domestic Indian import/use regulations may apply independently.
    - Screen all Indian customers against the Entity List, Unverified List, and
      Military End-User List before each shipment (see Step 6 below).

BRAZIL:
  Country Group: B
  ENC eligibility: YES — Brazil is a Country Group B destination. The ENC exception
  is available under § 740.17(a).
  Brazil-specific considerations:
    - Brazil is not subject to any US embargo or special controls.
    - Brazil has its own data localisation and cybersecurity regulations (LGPD,
      ANPD rules) which are separate from EAR obligations but relevant to your
      customers' compliance.
    - Screen all Brazilian customers against all restricted party lists.

SUMMARY TABLE:

Destination | Country Group | ENC Available | Restrictions
------------|---------------|---------------|------------------------------------------
France      | A:5, B        | YES (§740.17a)| None for commercial AES-256 software
India       | B             | YES (§740.17a)| Screen entity lists; India not in A:5
Brazil      | B             | YES (§740.17a)| Screen entity lists; Brazil not in A:5

================================================================================
STEP 6 — END-USER AND END-USE CONTROLS (PART 744)
================================================================================

Even with ENC exception eligibility confirmed, you must screen every transaction
and every party before export.

MANDATORY RESTRICTED PARTY SCREENING:
Screen all parties — customer, distributor, end-user, broker, freight forwarder,
bank, and any intermediate consignee — against:

  1. Entity List (Supplement 4, Part 744): Licence required for all EAR items;
     most licence exceptions INCLUDING ENC are unavailable for Entity List parties.
  2. Denied Persons List (Part 764): Absolute prohibition. No exceptions apply.
  3. Unverified List (Supplement 6, Part 744): Cannot use any licence exception.
  4. Military End-User (MEU) List (Supplement 7, Part 744): Enhanced restrictions
     for items in Supplement 2, Part 744.
  5. SDN List (OFAC): Not EAR, but must be screened alongside BIS lists.

Use the Consolidated Screening List at trade.gov/consolidated-screening-list for
a single-search approach across BIS, State, and Treasury lists.

WMD END-USE PROHIBITION (§ 744.2–744.6):
No licence exception — including ENC — applies if you know or have reason to know
your cybersecurity software will be used in nuclear weapons development, missile
programmes, or chemical/biological weapons programmes. This prohibition is absolute.

RED FLAGS (§ 732.6):
Given that you are selling cybersecurity software (a sensitive dual-use item),
apply heightened diligence. Stop and investigate before proceeding if:
  - A customer refuses to identify the end-use or end-users of the software
  - The order is inconsistent with the customer's stated business (e.g., a
    mining company purchasing enterprise cybersecurity software in unusual volumes)
  - Payment arrives from an unexpected third-country account
  - The customer declines standard licence/maintenance support
  - The customer requests delivery to an unusual transhipment point

================================================================================
STEP 7 — DEEMED EXPORT CONSIDERATIONS (§ 734.13)
================================================================================

If your company employs foreign nationals (including remote workers in France,
India, or Brazil) who have access to the source code or controlled technology
underlying your AES-256 implementation, a deemed export analysis is required.

Releasing controlled technology or software source code to a foreign national in
the US is deemed an export to their country of nationality. For 5D002 technology,
if a licence would be required for export of that technology to the foreign
national's home country, a deemed export licence or applicable exception must be
identified.

For France: country group A:5 — deemed export risk is very low; most exceptions
available.
For India and Brazil: Country Group B — ENC exception may cover deemed exports of
5D002 software; confirm with your legal counsel that the deemed export falls within
the ENC exception terms.

================================================================================
STEP 8 — ELECTRONIC EXPORT INFORMATION (EEI) FILING (PART 758)
================================================================================

EEI filing via the Automated Export System (AES) is required when:
  - The value of the shipment exceeds $2,500 per Schedule B number and the
    destination is outside Canada (all three destinations qualify).
  - When filing, cite "ENC" in the licence exception field (not a licence number).

For software delivered electronically (download, SaaS, cloud):
  - If no physical media crosses the border, EEI filing requirements may not apply
    to the electronic transmission itself. However, the EAR still controls the
    export, and your ENC notification and recordkeeping obligations remain in full
    force regardless of delivery method.

================================================================================
STEP 9 — RECORDKEEPING (PART 762)
================================================================================

Retain the following for 5 years from the date of each export (§ 762.6):
  - Purchase orders, invoices, and contracts
  - The ENC licence exception symbol ("ENC") on all shipping and export documents
  - Your SNAP-R BIS-748P-A notification confirmation
  - Annual self-classification reports submitted to BIS and NSA
  - Denied party screening records and date of each screening
  - Any end-user statements or due diligence documentation
  - EEI/AES filing records

================================================================================
STEP 10 — ACTION CHECKLIST
================================================================================

BEFORE FIRST EXPORT:

[ ] 1. Confirm ECCN 5D002 applies (consider CCATS if classification is uncertain).
[ ] 2. Verify your product meets mass-market criteria under § 740.17(b)(1) / Note 3.
[ ] 3. File BIS-748P-A notification via SNAP-R at snap-r.bis.doc.gov.
[ ] 4. Set up a Consolidated Screening List workflow for all transactions.
[ ] 5. Train sales, logistics, and finance staff on red flag recognition (§ 732.6).
[ ] 6. Establish recordkeeping procedures (5-year retention, Part 762).

FOR EVERY SHIPMENT:

[ ] 7. Screen all parties against CSL and OFAC SDN list.
[ ] 8. Confirm no red flags or WMD end-use indicators.
[ ] 9. Cite "ENC" as the licence exception on the export documentation and EEI filing.
[ ] 10. Retain all transaction records.

ANNUALLY (by February 1):

[ ] 11. Submit annual self-classification report for all ENC-exception exports
        during the prior calendar year (§ 742.15(b)).

IF PRODUCT CHANGES:

[ ] 12. If you materially change the encryption algorithm, key length, or product
        architecture, file a new BIS-748P-A notification. A material change that
        causes the product to no longer qualify as mass-market may require
        reclassification under Tier 3 (§ 740.17(b)(3)) or a BIS licence.

================================================================================
IMPORTANT CAVEATS AND LIMITATIONS
================================================================================

1. This analysis is based on the information provided: commercial cybersecurity
   software, AES-256 encryption, exports to France, India, and Brazil. If the
   software includes additional controlled features (e.g., intrusion detection
   with NS or MT controls, or cryptanalysis tools), separate ECCN entries may
   apply alongside or instead of 5D002.

2. Country classification and Country Chart "X" marks are subject to regulatory
   updates. Verify current Country Chart status in Part 738 Supplement No. 1
   before export.

3. This analysis does not address the destination countries' own import controls
   for encryption software. India, Brazil, and France (via EU dual-use regulations)
   may impose independent import licence requirements. Consult local counsel in
   each jurisdiction.

4. The ENC exception does not authorise exports to E:1 countries (Cuba, North
   Korea, Iran, Syria) or E:2 countries (Russia, Belarus) for most encryption
   items. None of your three destinations are E:1 or E:2, so this restriction
   does not apply here but is noted for completeness.

5. This analysis constitutes legal/compliance information and not legal advice.
   Engage qualified export counsel for transaction-specific determinations and
   before submitting BIS notifications or licence applications.

================================================================================
REGULATORY CITATIONS INDEX
================================================================================

§ 734.3       — Items subject to EAR
§ 734.13      — Deemed export rule
§ 736.2(b)    — Ten General Prohibitions
§ 738         — Commerce Country Chart
§ 740.2       — Global restrictions on all licence exceptions
§ 740.17      — ENC licence exception (Encryption Items)
§ 740.17(a)   — Tier 1: Mass-market encryption
§ 740.17(b)(1)— Tier 2: Source code for mass-market products
§ 740.17(b)(3)— Tier 3: Non-standard/proprietary encryption
§ 742.15(b)   — Annual self-classification report requirement
§ 744.2–744.6 — WMD end-use prohibitions
§ 758.1       — EEI/AES filing requirements
§ 762.2       — Recordkeeping — what to retain
§ 762.6       — 5-year retention period
Part 774      — Commerce Control List (ECCN 5D002)
ECCN 5D002    — Information Security software classification

EXPORT COMPLIANCE ANALYSIS: AES-256 CYBERSECURITY SOFTWARE
Destinations: France, India, Brazil
Framework: U.S. Export Administration Regulations (EAR), 15 C.F.R. Parts 730-774
Date of Analysis: 2026-05-07

===========================================================================
OVERVIEW
===========================================================================

Yes, your cybersecurity software incorporating AES-256 encryption is subject
to U.S. export controls under the Export Administration Regulations (EAR),
administered by the Bureau of Industry and Security (BIS) within the
Department of Commerce. However, for commercial sales to France, India, and
Brazil, there is a strong likelihood that you can use a licence exception
rather than obtaining an individual export licence, provided you meet the
applicable conditions.

===========================================================================
STEP 1: CLASSIFICATION UNDER THE COMMERCE CONTROL LIST (CCL)
===========================================================================

Your product almost certainly falls under ECCN 5D002 on the Commerce Control
List (CCL).

ECCN 5D002 covers:
  "Software specially designed or modified for the 'development',
   'production' or 'use' of equipment or 'software' controlled in
   5A002 or 5B002, or software designed to certify software controlled
   in 5D002."

5A002 controls, among other things, systems and equipment that use
cryptography with a symmetric key length exceeding 56 bits -- AES-256
(256-bit symmetric key) clearly exceeds this threshold.

Reasons your product is likely 5D002:
  - AES-256 is a symmetric encryption algorithm with a 256-bit key length
    (well above the 56-bit threshold)
  - The software is cybersecurity software -- it uses encryption as a
    core functional capability, not merely incidentally
  - It is designed for commercial use (not exclusively mass-market in
    the EAR sense at the classification stage)

Could it be classified as EAR99?
  Unlikely for cybersecurity software with strong encryption as a primary
  feature. EAR99 classification requires that no ECCN on the CCL applies.
  Given the cryptographic capabilities, 5D002 is almost certainly the
  correct classification.

Could it be 5D992 instead of 5D002?
  5D992 covers software with encryption features that have been "decontrolled"
  or are for mass-market use. However, the initial classification analysis
  starts at 5D002 for strong encryption. The mass-market decontrol path
  (discussed below) is a licence exception mechanism, not a reclassification
  for most purposes.

===========================================================================
STEP 2: REASONS FOR CONTROL (WHY IS IT CONTROLLED?)
===========================================================================

Under ECCN 5D002, the reasons for control include:
  - AT:  Anti-Terrorism
  - EI:  Encryption Items (the primary reason for encryption controls)
  - NS:  National Security (in some cases)

The EI (Encryption Items) controls are the central concern here. They are
administered specifically through the ENC licence exception framework and
the annual self-classification reporting regime.

===========================================================================
STEP 3: DO YOU NEED A BIS LICENCE?
===========================================================================

The general answer: You need either a licence or a valid licence exception
to export 5D002 software. A licence is not automatically required -- BIS
has established several licence exceptions for encryption items precisely
to facilitate legitimate commercial trade.

For most commercial cybersecurity software exports to France, India, and
Brazil, the ENC licence exception (15 C.F.R. Section 740.17) is the
primary pathway to avoid needing an individual licence.

===========================================================================
STEP 4: THE ENC LICENCE EXCEPTION (15 C.F.R. § 740.17)
===========================================================================

The ENC licence exception authorises the export, re-export, and transfer
of encryption items that would otherwise require a licence under ECCN 5D002
(and related ECCNs such as 5E002). It has two main tiers:

-------------------------------------------
TIER A: ENC -- Section 740.17(b)(1)
"Encryption software...after a one-time review"
Actually called: ENC without review -- Mass Market
-------------------------------------------

This sub-paragraph covers encryption software that qualifies as
"mass market" under the Note to ECCN 5D002. To qualify:

Requirements:
  1. The software must be generally available to the public by being
     sold from stock at retail selling points (or designed for installation
     by the user without further substantial support from the supplier)
  2. The cryptographic functionality cannot be easily changed by the user
  3. It is designed for installation without further substantial supplier
     support

If your software meets the mass-market criteria, you may export it
under ENC to most destinations (including France, India, and Brazil)
WITHOUT a prior BIS review, subject to:

  - Annual self-classification reporting to BIS and NSA (required)
  - Filing an Electronic Export Information (EEI) in AES where required
  - You cannot export to embargoed countries or denied parties

Mass market determination for cybersecurity software:
  This can be fact-specific. Cybersecurity tools sold as off-the-shelf
  products with standard configurations may qualify. Highly customised
  enterprise tools or tools sold with significant professional services
  may not. Legal counsel should evaluate this carefully.

-------------------------------------------
TIER B: ENC -- Section 740.17(b)(2) and (b)(3)
"After a one-time review" (most commercial encryption software)
-------------------------------------------

If your software does not qualify as mass market, the standard ENC
exception under 740.17(b)(2) is available after a one-time BIS/NSA
review. Under this pathway:

  1. Submit a one-time product review request to BIS (via the online
     Simplified Network Application Process Redesign -- SNAP-R system)
  2. BIS and NSA review the submission (typically within 30 days)
  3. Once reviewed (or after 30 days without action), you may export
     the product under the ENC exception to eligible destinations

Eligible destinations for 740.17(b)(2):
  The ENC exception under (b)(2) is available for exports to most
  countries, including France, India, and Brazil, provided the customer
  is not:
    - A government end-user in a country outside the "ENC-favorable"
      category (discussed below), OR
    - A prohibited end-user (denied party, arms embargo, etc.)

-------------------------------------------
TIER C: ENC -- Section 740.17(b)(3)
"Unrestricted" encryption -- no review, no reporting (very limited)
-------------------------------------------

Applies only to encryption software with very short key lengths or
open-source software. Not applicable to AES-256.

===========================================================================
STEP 5: COUNTRY-BY-COUNTRY ANALYSIS
===========================================================================

FRANCE
------
Country Group: B (not D:1, not embargoed, not E:1 or E:2)
Relationship: EU member, NATO ally, strong partner
AT controls apply: No (France is not on the AT list)
Government end-user concern: France is a favorable destination; government
  end-users in France can generally receive encryption items under ENC.

Result: France is among the most permissive destinations for encryption
exports. Both ENC (b)(1) (mass market) and (b)(2) (after review) are
available for commercial and government customers. No individual BIS
licence required in the normal commercial case.

INDIA
-----
Country Group: B (not D:1 as of general EAR structure, though watch for
  specific controls)
Note: India has had multilateral export control sensitivities in the past
  but is generally in Country Group B for EAR purposes, not subject to
  the most restrictive encryption controls.
AT controls apply: No (India is not on the AT list)
Government end-user concern: For exports to non-ENC-favorable government
  end-users, an individual licence may be required. India's government
  end-users may require case-by-case review for some controlled items,
  but for standard commercial cybersecurity software sold to private-sector
  customers, ENC (b)(2) after one-time review should be available.

Result: For commercial/private-sector customers in India, the ENC
exception (b)(2) after one-time BIS review is most likely available.
If selling to Indian government entities, consult legal counsel as
individual licence review may be warranted, particularly for products
with military or intelligence applications.

Also note: India has its own encryption import regulations (enforced
by the Department of Telecommunications). You should verify local
Indian import compliance in addition to U.S. export requirements.

BRAZIL
------
Country Group: B (not embargoed, not AT-designated)
AT controls apply: No
Government end-user concern: Similar to India -- commercial sales to
  private-sector customers in Brazil should qualify under ENC (b)(2).
  Government end-users may require separate analysis.

Result: For commercial cybersecurity software sold to private Brazilian
customers, ENC (b)(2) after one-time BIS review should be available.
Brazil also has its own cryptographic software regulations (administered
by the Brazilian Army's Regulatory Division for Cryptographic Products --
DSIC/GSI); local import compliance should be separately verified.

===========================================================================
STEP 6: ANNUAL SELF-CLASSIFICATION REPORTING REQUIREMENT
===========================================================================

Regardless of which ENC tier applies, exporters using the ENC licence
exception are generally required to submit annual self-classification
reports to BIS and NSA by February 1 each year, covering products
exported in the prior calendar year under ENC. This is a compliance
obligation, not a licence application -- but failure to file can
expose the company to enforcement risk.

The reports are submitted via the BIS Encryption Registration system
and include:
  - Product name and model number
  - ECCN
  - Key length(s) and algorithm(s)
  - Whether the product is mass market or reviewed

===========================================================================
STEP 7: DENIED PARTY SCREENING (MANDATORY FOR ALL EXPORTS)
===========================================================================

Regardless of licence exception, you must screen all customers, end-users,
and intermediaries against U.S. Government restricted-party lists before
each export:

  - BIS Entity List (15 C.F.R. Part 744, Supplement 4)
  - BIS Denied Persons List
  - BIS Unverified List
  - Treasury OFAC Specially Designated Nationals (SDN) List
  - State Department Debarred List (ITAR)
  - Consolidated Screening List (consolidates multiple lists)

A match on any of these lists may prohibit the export entirely, regardless
of the licence exception.

===========================================================================
STEP 8: END-USE AND END-USER CONSIDERATIONS
===========================================================================

Even when a licence exception applies, EAR Part 744 prohibits certain
exports based on prohibited end-uses or end-users, regardless of the
product's ECCN. For cybersecurity software specifically:

  - Do not export to entities known to support weapons of mass destruction
    programs
  - Do not export to entities that will use the software for offensive
    cyber operations against U.S. interests
  - Conduct basic due diligence on the customer's intended use

Red flags that should trigger deeper review:
  - Customer is a military or intelligence organisation in a non-partner country
  - Customer's stated use is inconsistent with the product's capabilities
  - Unusual payment or shipping routing
  - Customer is unwilling to disclose end-use

===========================================================================
STEP 9: PRACTICAL COMPLIANCE STEPS SUMMARY
===========================================================================

1. CLASSIFY: Confirm ECCN 5D002 (or engage a licensed export counsel to
   confirm classification).

2. DETERMINE ENC TIER:
   a. Is your product mass market? If yes, ENC (b)(1) may apply -- no
      prior BIS review needed.
   b. If not mass market, prepare and submit a one-time product review
      to BIS/NSA via SNAP-R under ENC (b)(2). Wait for clearance (or
      30 days) before first export.

3. SCREEN CUSTOMERS: Run all customers through denied-party lists before
   each transaction.

4. ASSESS END-USERS: Confirm customers in France, India, and Brazil are
   private-sector commercial users. Government end-users require separate
   analysis.

5. FILE EEI: Determine whether Electronic Export Information filing in
   the Automated Export System (AES) is required (generally required for
   exports valued over $2,500 or controlled commodities, though there are
   exceptions for software downloads).

6. ANNUAL REPORTING: File annual self-classification report with BIS/NSA
   by February 1 covering prior-year ENC exports.

7. LOCAL LAW: Separately verify encryption import requirements in France
   (ANSSI -- generally permissive for AES-256 in commercial products),
   India (DoT regulations), and Brazil (Army cryptographic regulations).

8. DOCUMENT EVERYTHING: Maintain records of classification decisions,
   ENC exception use, customer screening, and end-use representations
   for at least 5 years (EAR recordkeeping requirement).

===========================================================================
CONCLUSION
===========================================================================

For commercial cybersecurity software incorporating AES-256 encryption:

  - A BIS individual export licence is NOT required for France, India,
    and Brazil in most commercial scenarios.

  - The ENC licence exception (15 C.F.R. § 740.17) is the applicable
    pathway:
      * Mass-market products: ENC (b)(1) -- no prior review required
      * Non-mass-market commercial products: ENC (b)(2) -- one-time
        BIS/NSA product review required before first export

  - France is the most straightforward of the three destinations; India
    and Brazil require attention to government end-user restrictions and
    local import regulations.

  - Annual self-classification reporting to BIS and NSA is mandatory
    regardless of which ENC tier applies.

  - Denied-party screening is mandatory for every transaction.

IMPORTANT DISCLAIMER: This analysis reflects general knowledge of U.S.
export control law as of 2026 and is provided for informational purposes
only. It does not constitute legal advice. Export control regulations are
complex, fact-specific, and subject to change. You should consult a
licensed export control attorney or compliance specialist before making
final compliance determinations or submitting classification or licence
exception filings to BIS.

EXPORT COMPLIANCE PROGRAMME DESIGN FOR A 200-PERSON SEMICONDUCTOR EQUIPMENT COMPANY
=====================================================================================
Prepared under the Export Administration Regulations (EAR), 15 CFR Parts 730–774
Bureau of Industry and Security (BIS), U.S. Department of Commerce

Company profile: 200 employees, semiconductor capital equipment manufacturer, export
destinations: Europe, Japan, South Korea, Taiwan, occasional India.

======================================================================================
PART ONE: THE SEVEN BIS ELEMENTS OF AN EFFECTIVE EXPORT COMPLIANCE PROGRAMME (ECP)
======================================================================================

BIS has identified seven elements of an effective ECP. A documented, fully functioning
ECP is the single largest mitigating factor in an enforcement action — it can reduce
civil penalties substantially and, in borderline cases, result in a Warning Letter rather
than a monetary penalty. For a semiconductor equipment company, the stakes are
particularly high: your core products almost certainly fall under ECCNs 3B001 and/or
3B002, which carry NS, AT, and NP controls and are central to the Foreign Direct Product
Rule (FDPR) regime for advanced chips. Here is how to build each element.

----------------------------------------------------------------------
ELEMENT 1 — MANAGEMENT COMMITMENT
----------------------------------------------------------------------

What BIS expects:
  Senior leadership must visibly and substantively champion export compliance — not
  simply sign a policy and move on. This means resources, authority, and accountability
  flowing from the top.

Specific actions for your company:

  1.1 Export Compliance Policy
      Draft a written, board-approved Export Compliance Policy signed by the CEO or
      President. The policy must state that compliance with EAR (and any applicable ITAR
      obligations) is a condition of doing business, that violations will not be tolerated,
      and that resources will be provided to maintain the programme.

  1.2 Designated Export Control Officer (ECO)
      Appoint an ECO in writing. For a 200-person company with semiconductor equipment
      exports to Japan, South Korea, Taiwan, and India, this should be a dedicated
      position, not a collateral duty. The ECO must have direct access to senior leadership
      and authority to stop shipments. Document the ECO's authority, reporting line, and
      budget.

  1.3 Compliance Reporting Structure
      Implement quarterly compliance reporting to the CEO/Board. Reports should cover:
      screening results, classification updates, licence status, training completion rates,
      and any identified compliance gaps or near-misses.

  1.4 Annual ECP Review Certification
      The ECO should certify annually to the board that the ECP is operating effectively,
      identify any gaps, and propose remediation with timelines and budgets.

  1.5 Resources
      Commit budget for: screening software (see Element 5), ERP integration, legal
      counsel with EAR expertise, and periodic third-party ECP audits. BIS rewards
      companies that invest in compliance infrastructure, not just paper policies.

  Semiconductor-specific note: Given the heightened scrutiny on semiconductor
  manufacturing equipment — particularly in light of the October 2022 and October 2023
  BIS rules on advanced computing — management commitment must include explicit
  attention to China-related transactions and FDPR applicability. Your CEO and board
  should be briefed on what these rules mean operationally.

----------------------------------------------------------------------
ELEMENT 2 — RISK ASSESSMENT
----------------------------------------------------------------------

What BIS expects:
  A systematic identification of all items, transactions, customers, and channels that
  present export control risk, with documented rationale.

Specific actions:

  2.1 Product Classification Audit (Start Here)
      Every product in your portfolio must be classified under the EAR. For semiconductor
      capital equipment, the primary ECCNs are:

        3B001 — Equipment for the manufacture of semiconductor devices or materials:
          - Lithography equipment (photolithography, e-beam, ion beam)
          - Etch equipment (plasma, wet etch)
          - Deposition equipment (CVD, PVD, ALD, MBE)
          - Ion implantation equipment
          - Rapid thermal processing equipment
          Controls include: NS, AT, and in some cases NP or MT
          Note: 3B001.a through 3B001.j have specific technical parameter thresholds
          that determine control.

        3B002 — Equipment for the inspection and testing of semiconductor devices:
          - Wafer probers, testers, parametric test equipment
          - In-process and post-process metrology tools
          Controls: NS, AT

        3D001/3D002/3E001/3E002 — Corresponding software (D) and technology (E) for
          3B equipment. Software and technology ECCNs must be classified separately
          from the equipment itself.

        EAR99 — Lower-end equipment, spare parts, consumables with no CCL entry may
          be EAR99. Do not assume; verify against the CCL.

      Build an ECCN Classification Log with these fields for every product, subassembly,
      component, and software package:
        - Part number and description
        - Technical parameters reviewed (e.g., minimum feature size, throughput)
        - ECCN assigned
        - Reason(s) for Control (NS, AT, NP, etc.)
        - Date of classification
        - Classifier name
        - Next review date (trigger: product modification, new regulatory guidance)

  2.2 Geography Risk Assessment
      Your destination mix presents the following risk profile:

        Europe (EU/UK/EEA): Generally A:1, A:5 countries. Low-risk for most 3B001/3B002
          exports; many licence exceptions available (e.g., STA for A:5 countries). Still
          requires screening and classification.

        Japan: A:1, A:5. Low licence risk for most items. Japan is a Wassenaar Arrangement
          member and a close ally. Japan's own export controls (FEFTA/Foreign Exchange Act)
          mirror EAR in many respects. However, Japan-origin semiconductor equipment is
          subject to FDPR analysis.

        South Korea: A:1, A:5. Similar to Japan. Low licence risk for NS-controlled items.
          KITA alignment with multilateral regimes.

        Taiwan: Country Group B (not A:5). Taiwan is not a Wassenaar member but is
          treated favourably. However, proximity to China and active PRC pressure on
          Taiwan-based chipmakers (TSMC, UMC, etc.) elevates the diversion and re-export
          risk. Taiwan-based fab customers may be producing chips for Chinese end-users.
          Enhanced due diligence required.

        India: Country Group B. India is an occasional destination. India became an
          A:5-equivalent partner (U.S.-India iCET initiative) but for EAR purposes India
          remains Country Group B for most purposes. India has its own import controls
          under SCOMET. For 3B001/3B002 equipment, verify licence exception availability
          on a case-by-case basis.

  2.3 Customer/Channel Risk Assessment
      Segment customers by risk tier:
        Tier 1 (Low): Large, established IDMs and foundries in EU/Japan/Korea with
          documented end-use (Intel, Samsung, TSMC, Infineon, etc.)
        Tier 2 (Medium): Distributors, trading companies, smaller fabs; Taiwan and
          India customers; customers whose end-use is not wholly transparent
        Tier 3 (High): Any customer with connections to China; distributors who
          sub-distribute in D:1 countries; any customer on or near any restricted list

  2.4 Technology Risk Assessment (Deemed Exports)
      For a semiconductor equipment company, your engineers regularly work with
      3E001/3E002-controlled technology. Every foreign national employee or visitor who
      accesses controlled technology is a deemed export risk. Conduct a deemed export
      risk assessment covering: lab access, CAD/design files, process recipes, and
      system software source code.

----------------------------------------------------------------------
ELEMENT 3 — WRITTEN POLICIES AND PROCEDURES
----------------------------------------------------------------------

What BIS expects:
  Procedure-level written guidance for every process that touches controlled items or
  transactions. A high-level policy alone is insufficient.

Procedures your company needs:

  3.1 ECCN Classification Procedure
      - Who classifies (ECO + engineering)
      - How to access the CCL (Part 774)
      - How to complete and maintain the Classification Log
      - Triggers for reclassification (product change, new guidance)
      - Use of CCATS (Commodity Classification Automated Tracking System) for
        official BIS classification when uncertain

  3.2 Restricted Party Screening Procedure (see Element 5 for full detail)
      - Which lists to screen
      - When to screen (order acceptance, pre-shipment, periodic re-screen)
      - How to handle a potential match
      - Escalation path

  3.3 Order Acceptance and Licence Determination Procedure
      - Sales team check: Does the customer, destination, or stated end-use raise flags?
      - ECO check: Is a licence required? Is a licence exception available?
      - Approval workflow before accepting an order that triggers a licence requirement
      - "Hold for compliance" authority (ECO can stop any shipment)

  3.4 Licence Application and Management Procedure
      - How to apply via SNAP-R (snap-r.bis.doc.gov)
      - Documentation required for 3B001/3B002 applications (technical specs,
        end-user statements on BIS-711 form, end-use certificates)
      - Licence condition tracking (re-export authorisations, reporting requirements)
      - Licence expiry calendar and renewal process (apply 60 days before expiry)

  3.5 End-User Statement and Due Diligence Procedure
      - When an End-User Statement (EUS) is required (high-risk transactions,
        Tier 2/Tier 3 customers, any 3B001 to Country Group B)
      - Use of BIS Form BIS-711 (Statement by Ultimate Consignee and Purchaser)
      - KYC due diligence steps for new distributors and resellers
      - Distributor agreement provisions (downstream compliance obligations,
        right to audit, no-reexport-to-D:1 clauses)

  3.6 Deemed Export Procedure
      - Pre-hire screening for foreign national candidates who will access controlled tech
      - Access control for controlled technology (lab, CAD tools, source code repositories)
      - Deemed export licence application process via SNAP-R
      - Most-restrictive nationality rule for dual nationals (§ 734.13)

  3.7 FDPR Assessment Procedure
      - For all foreign-manufactured products incorporating your US technology or
        produced on equipment you manufactured: FDPR analysis checklist
      - Two-prong test (technology/software prong + destination prong)
      - Documentation of FDPR analysis for each product line

  3.8 Recordkeeping Procedure
      - List of record types to retain (see Element 7)
      - Five-year retention from date of export (§ 762.6)
      - Electronic storage, backup, and retrieval requirements
      - Response to BIS inspection requests (generally within 5 business days)

  3.9 Voluntary Self-Disclosure (VSD) Procedure
      - How to recognise a potential violation
      - Immediate escalation to ECO and legal counsel
      - Preliminary Inquiry process
      - Criteria for filing an initial notification to OEE
      - Full VSD submission within 180 days
      - Internal documentation during VSD process

  3.10 Trade Show, Demo, and Visitor Access Procedure
      - Controls on technology disclosed during trade shows or customer site visits
      - Foreign visitor access to controlled equipment or technology in US facilities
      - Temporary export of demo equipment (TMP licence exception, § 740.9)

----------------------------------------------------------------------
ELEMENT 4 — TRAINING AND AWARENESS
----------------------------------------------------------------------

What BIS expects:
  Mandatory, role-appropriate training for all employees who may touch controlled
  transactions, with documented completion and annual refresh.

Training programme structure:

  4.1 Role-Based Training Tracks

      Track A — All Employees (1-hour annual awareness):
        - What is export control and why it matters
        - EAR vs. ITAR (don't assume semiconductor equipment is ITAR-free; verify)
        - What is an ECCN and what is EAR99
        - Restricted parties — what they are and why you must not engage
        - Red flag recognition (15 red flags from Supplement 3 to Part 732)
        - How to report concerns (escalation path to ECO)

      Track B — Sales, Business Development, Customer Success (2-3 hours annual):
        - Deeper dive on licence requirements and exceptions for your destination mix
        - End-user statements and due diligence
        - How to handle a customer who pushes back on compliance requests
        - Red flags in customer inquiries
        - Distributor management requirements

      Track C — Engineering, R&D, Product Management (2-3 hours annual):
        - Deemed exports — what they are and how they arise (visual access, oral briefings,
          electronic transmission, source code access)
        - Most-restrictive nationality rule
        - FDPR — when your technology creates FDPR obligations for foreign manufacturers
        - 3B001/3B002 technical parameter thresholds — when does a design change affect
          the ECCN?
        - Cloud and repository access controls for controlled technology
        - Fundamental research exclusion and its limits

      Track D — ECO, Legal, Finance (deep dive, 4-8 hours, plus continuing education):
        - Complete ECCN classification methodology
        - Licence exception analysis (all 14 exceptions in Part 740)
        - SNAP-R licence application process
        - FDPR comprehensive analysis
        - Enforcement regime (civil and criminal penalties, § 764)
        - VSD process (§ 764.5)
        - Advanced computing rules (October 2022/2023 BIS rules)
        - Entity List additions and update monitoring

      Track E — HR and Recruiting:
        - Deemed export screening in the hiring process
        - Foreign national pre-hire compliance checklist
        - How to handle a candidate who triggers deemed export concern

  4.2 Training Administration
      - Annual mandatory training for all tracks; completion required within 30 days
        of hire for new employees and annually thereafter
      - Track completion records retained for 5 years
      - Signed acknowledgement by each employee
      - Training content updated whenever regulations change materially (BIS
        entity list additions, new FDPR rules, new licence exceptions)

  4.3 Practical Exercises
      - Annual tabletop exercise for the ECO and leadership: a realistic scenario
        (e.g., discovery of shipments to an Entity List party's subsidiary; FDPR
        analysis of a new OEM partnership with a Japanese company; a deemed export
        situation with a newly hired Chinese national engineer)

----------------------------------------------------------------------
ELEMENT 5 — RESTRICTED PARTY SCREENING
----------------------------------------------------------------------

What BIS expects:
  Screening of all parties to every transaction against all applicable government lists,
  on a defined cadence, with documented procedures for handling matches.

5.1 Mandatory Lists to Screen

  You must screen against, at minimum, the following lists:

  BIS Lists (15 CFR Part 744 and Part 764):
    (a) Entity List (Supplement 4 to Part 744)
        - Effect: Licence required for ALL items subject to EAR, destined for or involving
          listed entities; most licence exceptions unavailable
        - Key relevance: Many Chinese semiconductor companies and research institutes
          are on the Entity List. Taiwan-based customers producing for Chinese
          Entity List companies create a prohibited-end-user risk.

    (b) Denied Persons List (Part 764)
        - Effect: Absolute prohibition — you may not export, reexport, or transfer
          any item subject to EAR to or with a denied person; no exceptions
        - Applies to persons acting as agents, freight forwarders, banks, and intermediaries

    (c) Unverified List (Supplement 6 to Part 744)
        - Effect: Cannot use any licence exceptions; must obtain a UVL Statement from
          the party before proceeding with any transaction
        - Signals: Party's bona fides could not be verified by BIS end-use checks

    (d) Military End-User (MEU) List (Supplement 7 to Part 744)
        - Effect: Licence required for items listed in Supplement 2 to Part 744
          (which includes many semiconductor manufacturing items) to listed military
          end-users in China, Russia, and other D:5 countries

  State Department Lists:
    (e) DDTC Debarred List (22 CFR Part 127)
        - While ITAR-specific, debarred persons are prohibited from participating in
          ITAR transactions and frequently overlap with EAR concerns; best practice
          is to screen all parties against this list

  OFAC Lists (Treasury Department):
    (f) Specially Designated Nationals (SDN) List
        - Effect: Full asset block; US persons may not transact with SDNs regardless
          of whether items are subject to EAR. Non-compliance is a Treasury matter,
          not BIS, but the prohibition is absolute.

    (g) OFAC Consolidated Sanctions List
        - Includes SDNs, Foreign Sanctions Evaders, Sectoral Sanctions (SSI list),
          Non-SDN Chinese Military-Industrial Complex (NS-CMIC) companies, and more

  Single-Search Resource:
    The Consolidated Screening List (CSL) at trade.gov/consolidated-screening-list
    combines BIS Entity List, Denied Persons List, Unverified List, and MEU List with
    State's Debarred List and OFAC's SDN and Consolidated Sanctions List into a single
    searchable interface. Use the CSL as your primary search tool, but supplement with
    direct source checks for high-risk transactions, as the CSL may have a brief lag
    behind individual agency publications.

5.2 Who to Screen

  Screen ALL parties to every transaction, not just the buyer. This includes:
    - Buyer / purchaser
    - End-user (if different from buyer)
    - All intermediate consignees
    - Freight forwarder and logistics providers
    - Customs brokers
    - Banks and financial intermediaries involved in payment
    - Brokers or agents
    - Parent companies and subsidiaries of any of the above (ownership/control analysis)

  For semiconductor equipment: Pay particular attention to end-users at the wafer
  fabrication level. Your direct customer may be a trading company; the actual fab
  is the end-user. Screen both.

5.3 When to Screen (Screening Cadence)

  At order inception:
    - Screen all parties when a quote is first requested or an order is received,
      before any commitment is made to the customer

  Before shipment:
    - Re-screen all parties immediately before each shipment; lists are updated
      continuously and a party clean at order acceptance may be listed by shipment date
    - This is especially important for long-cycle semiconductor equipment orders
      (equipment may be ordered 6-12 months before delivery)

  During ongoing relationships:
    - Re-screen existing distributors, agents, and regular customers at minimum
      monthly; for China-adjacent channels, consider weekly re-screening
    - Automate this via ERP integration (SAP GTS, Oracle AGIS, Visual Compliance,
      Descartes Denied Party Screening, or similar)

  When parties change:
    - Any change in ownership, address, banking details, or shipping instructions
      triggers an immediate re-screen — these are classic red flags for diversion

  When new lists are published:
    - BIS publishes Entity List amendments in the Federal Register, often with
      immediate effective dates. Subscribe to BIS update alerts at bis.gov.
      When a new list is published, run all active customers and open orders against it.

5.4 Handling a Potential Match

  When a screening result returns a potential match, follow this process:

  Step 1 — Do Not Ship
    Immediately place a hold on the order or shipment. No item subject to EAR may
    be exported or transferred while a potential match is unresolved.

  Step 2 — Escalate to ECO and Legal Counsel
    The screening analyst escalates to the ECO within 1 business day. ECO engages
    export control counsel for any non-trivial match.

  Step 3 — True Hit vs. False Positive Analysis
    Conduct a structured comparison:
      - Name: exact match, phonetic similarity, known aliases?
      - Address: same country, city, street?
      - Date of birth / incorporation date (for individuals/companies)
      - Ownership and control linkages
      - Nature of business compared to the listed reason for control
    Document the analysis in writing with the date and the analyst's name.

  Step 4 — False Positive Disposition
    If the match is clearly a different entity (e.g., same common name, different
    country, no other overlapping identifiers), document the false positive
    determination and the basis for it. Retain the record for 5 years. Proceed
    with the transaction.

  Step 5 — True Hit Disposition
    If the match is confirmed or cannot be ruled out:
      (a) Refuse the transaction — do not proceed with the sale, shipment, or service
      (b) Do not tip off the customer that they have been identified as a restricted
          party (while EAR has no explicit "tipping off" prohibition as severe as OFAC,
          alerting an SDN to their status creates additional exposure)
      (c) For SDN hits: OFAC may require reporting; consult counsel
      (d) Document the true hit, the decision to refuse, and all communications
      (e) If items have already shipped to a party that is subsequently listed,
          consult counsel immediately regarding potential VSD obligations (§ 764.5)

  Step 6 — Record Retention
    All screening records — positive, negative, and false positive — are retained
    for 5 years from the date of the transaction or screening event. For systematic
    screening, retain dated screenshots or system-generated reports.

5.5 Semiconductor-Equipment-Specific Screening Considerations

  China Channel Risk:
    Even for your legitimate destinations (Japan, Korea, Taiwan), screen for
    connections to Chinese entities. Taiwan-based customers often produce for
    Chinese fabs. A shipment to TSMC's fab in Taiwan is legitimate; a shipment
    to a trading company that re-sells to a Yangtze Memory or CXMT subsidiary
    is a potential violation. Your distributor agreements in Taiwan should require
    downstream screening and no-reexport clauses for any controlled equipment.

  Entity List Alumni:
    Monitor not only current Entity List entries but watch for successor entities,
    renamed subsidiaries, and shell companies. The Entity List entry for Huawei
    includes hundreds of non-designated affiliates; transactions with them still
    require BIS licensing analysis.

  India-Specific:
    India's Department for Promotion of Industry and Internal Trade (DPIIT) SCOMET
    list controls some semiconductor manufacturing equipment. For Indian transactions,
    screen against SCOMET in addition to the US lists, and confirm your Indian
    customer's import authorisation for 3B001/3B002 equipment where required.

----------------------------------------------------------------------
ELEMENT 6 — DUE DILIGENCE (KNOW YOUR CUSTOMER)
----------------------------------------------------------------------

What BIS expects:
  Going beyond list screening to actually know who your customers are, what they
  will do with your equipment, and whether your channel partners are reliable.

  6.1 Customer Onboarding KYC
      For all new customers and distributors:
        - Business registration documents
        - Ownership and control structure (beneficial ownership)
        - Description of end-use and end-facility
        - References from existing suppliers or customers
        - For high-risk Tier 2/3 customers: site visit or third-party due diligence report

  6.2 End-User Statements (EUS)
      For any 3B001/3B002 equipment sold to Country Group B customers, Taiwan customers,
      or any transaction where the end-use is not transparent from your direct sales
      relationship, obtain a signed End-User Statement covering:
        - Identity of the actual end-user and end-facility
        - Specific intended end-use of the equipment
        - Certification that the equipment will not be re-exported without BIS authorisation
        - Certification that the party is not acting as an agent for a third party not
          identified in the transaction

      Use BIS Form BIS-711 (Statement by Ultimate Consignee and Purchaser) as the
      baseline template. For Japanese and Korean customers, a Japanese/Korean language
      version with certified translation is acceptable.

  6.3 Distributor Agreements
      Distributor and reseller agreements must include:
        - Obligation to comply with US export laws (EAR, OFAC)
        - Prohibition on re-export or transfer to restricted parties or destinations
          without BIS authorisation
        - Flow-down of restricted party screening obligations
        - Right of your company to audit the distributor's compliance records
        - Termination right for export control violations
        - Record-retention obligation aligned with Part 762 (5 years)

  6.4 Red Flag Investigation
      BIS publishes 15 red flags in Supplement 3 to Part 732. Any of the following
      require you to pause the transaction, investigate, and document your findings:
        - Customer reluctant to provide end-use information or end-user identity
        - Ordered item is inconsistent with the customer's stated business
          (e.g., a general trading company ordering precision lithography equipment)
        - Payment from an unusual third-country account or unusual payment structure
        - Shipping route is circuitous or through unusual transshipment hubs
          (e.g., routing semiconductor equipment through Singapore or UAE to a
          destination that should receive direct shipments)
        - Customer declines installation, training, warranty, or service
          (unusual for complex capital equipment)
        - Customer uses a freight forwarder as the address of record
        - Customer's ordering volume or frequency is inconsistent with known capacity
        - Requests for unusual technical documentation or modifications

      For each red flag identified, document: the flag, your investigation, and your
      conclusion about whether the transaction is legitimate. Unresolved red flags
      are grounds to refuse a transaction.

  6.5 Post-Sale Monitoring
      For high-value or high-risk equipment:
        - Installation sign-off confirming equipment is at the declared end-facility
        - Periodic check-ins with customers (annual for low-risk, quarterly for Tier 2)
        - BIS may conduct post-shipment verifications (PSVs) at customer sites;
          cooperation is mandatory and confirms your compliance posture

----------------------------------------------------------------------
ELEMENT 7 — RECORDKEEPING AND AUDITS
----------------------------------------------------------------------

What BIS expects:
  Retention of all export-related records for 5 years, with timely retrieval capability,
  and regular internal and external audits of the ECP.

  7.1 Recordkeeping Requirements (§ 762.6)

  Retain for 5 years from the date of export or reexport:

      Transaction Records:
        - Purchase orders and order confirmations
        - Commercial invoices
        - Packing lists
        - Bills of lading, air waybills, ocean bills
        - Electronic Export Information (EEI) filings via AES/ACE
        - Shipping instructions

      Classification Records:
        - ECCN Classification Log entries for each product
        - CCATS determinations (if obtained from BIS)
        - Classification rationale memoranda

      Screening Records:
        - Dated screenshots or system reports of every restricted party screening
          (positive, negative, and false positive)
        - False positive analysis documentation
        - True hit resolution documentation

      Licensing Records:
        - All SNAP-R licence applications (BIS-748P)
        - Issued licences and all conditions
        - Licence exception documentation (basis for each exception claimed)
        - End-user statements and BIS-711 forms
        - Advisory opinions received from BIS

      Due Diligence Records:
        - Customer KYC files
        - Distributor agreements and compliance certifications
        - Red flag investigation files

      Training Records:
        - Training materials, version history
        - Completion records with employee signatures/acknowledgements

      VSD Records (retain permanently, not just 5 years):
        - Initial notifications to OEE
        - Full VSD submissions
        - OEE correspondence
        - Internal investigation findings

  7.2 Record Format and Accessibility
      Records may be maintained in any readable electronic or paper format.
      Electronic storage must be backed up, with access controls preventing
      unauthorised alteration. BIS must be able to retrieve any record within
      a reasonable time (generally 5 business days of an OEE request).

  7.3 Internal Audit Programme
      Annual internal ECP audit covering:
        - Sample of screening records: were all parties screened, at the right cadence?
        - Sample of classification records: are ECCNs current and documented?
        - Sample of shipments: were correct ECCNs and licence authorities used
          on EEI filings?
        - Training completion rates
        - Licence condition compliance
        - Distributor agreement currency
        - Deemed export controls

      Audit findings reported to senior leadership; remediation tracked to closure.

  7.4 Periodic Third-Party Assessment
      For a semiconductor equipment company with 3B001/3B002 products and sales to
      Taiwan and India, conduct a third-party ECP assessment at minimum every 2-3 years.
      Third-party assessors provide defensible evidence of programme quality if BIS
      ever investigates. BIS's own penalty guidelines give substantial credit to
      companies with externally validated ECPs.

=======================================================================
PART TWO: SEMICONDUCTOR-EQUIPMENT-SPECIFIC CONSIDERATIONS
=======================================================================

----------------------------------------------------------------------
A. ECCN CLASSIFICATION: 3B001 AND 3B002 IN DEPTH
----------------------------------------------------------------------

3B001 — Equipment for manufacturing semiconductor devices and materials

This ECCN has approximately 10 sub-entries (3B001.a through 3B001.j), each with
specific technical parameter thresholds. Classification is not at the ECCN level —
you must determine the specific paragraph (e.g., 3B001.a.1 for photolithography
equipment using UV or deep UV light sources). Technical differences such as:
  - Minimum feature size achievable
  - Wavelength of light source
  - Alignment accuracy
  - Film thickness uniformity

...all affect which paragraph applies and, consequently, which reasons for control
apply (NS, AT, NP, MT). Your engineering team must be involved in classification —
this is not a task that can be done purely by legal or compliance staff.

Recommendation: For each product line, obtain a CCATS determination from BIS to
lock in an official classification. CCATS provides certainty and is valuable in
enforcement situations (good faith reliance on BIS classification is a mitigating
factor).

3B002 — Equipment specifically designed for the inspection or testing of semiconductor
devices or materials

Covers parametric test equipment, wafer probers, and certain metrology tools. Similarly
technical, with NS and AT controls in most cases.

Controls and destinations:
  For NS-controlled 3B001/3B002 equipment:
    - Europe (Country Group A:5): Licence exception STA (Strategic Trade Authorization,
      § 740.20) available for most NS items
    - Japan, South Korea (A:5): STA available; favourable
    - Taiwan (Country Group B): NS column 1 and 2 on the Country Chart — check
      for licence requirement; STA not available to Country Group B; may need
      licence or alternative exception (LVS if low value; TMP for demos)
    - India (Country Group B): Same analysis as Taiwan; case-by-case

----------------------------------------------------------------------
B. FOREIGN DIRECT PRODUCT RULE (FDPR) — CRITICAL FOR YOUR COMPANY
----------------------------------------------------------------------

As a semiconductor equipment manufacturer, the FDPR is not just something you must
comply with as an exporter — your products CREATE FDPR obligations for your customers
and foreign buyers of your equipment. This is a dual exposure:

  B.1 Your Outbound FDPR Obligations
      When you export US-origin technology (3E001) to a Japanese equipment manufacturer
      who then uses that technology to build equipment, that foreign-made equipment
      may be subject to EAR under the General FDPR if destined for D:1 or E countries.
      You must assess this in your technology licensing agreements.

  B.2 FDPR Triggered by Your Equipment
      Under the Entity List FDPR (Huawei Rule, 2020) and the Advanced Computing FDPR
      (October 2022/2023), semiconductor wafer fabrication equipment controlled under
      3B001 or 3B002 is specifically designated as triggering equipment. This means:

      If your customer (Japanese or Korean equipment maker, or a Taiwanese foundry) uses
      YOUR 3B001/3B002 equipment to produce chips or equipment, those foreign-made items
      may be subject to EAR when destined for:
        (i) Entity List parties (Entity List FDPR — all destinations)
        (ii) China or Macau for advanced computing applications above the specified
             performance thresholds (Advanced Computing FDPR)

      Practical implication: Your distributor agreements and equipment sale agreements
      with foreign manufacturers must include FDPR representations:
        - Buyer acknowledges that the equipment is subject to EAR
        - Buyer agrees not to use the equipment to produce items for Entity List parties
          or for China/Macau advanced computing applications, unless separately licensed
        - Buyer agrees to flow these restrictions down in their own supply agreements

  B.3 Russia/Belarus FDPR (March 2022)
      Since March 2022, virtually all items produced anywhere in the world using any
      US-origin technology, software, or equipment are subject to EAR for Russia and
      Belarus destinations. This is nearly categorical; the exceptions are narrow.
      You should have zero Russia/Belarus sales, and your distributor agreements must
      explicitly prohibit reexport to Russia and Belarus.

  B.4 FDPR Documentation
      For each product line, document in writing:
        - Does the product incorporate US-origin technology or software controlled for NS?
        - Was the product manufactured on US-origin equipment controlled under 3B001/3B002?
        - Two-prong FDPR analysis (technology/software prong + destination prong)
        - Conclusion: subject to EAR via FDPR or not?

----------------------------------------------------------------------
C. HEIGHTENED CHINA SCRUTINY
----------------------------------------------------------------------

Even though China is not listed as a current export destination for your company, the
China dimension is pervasive given your products, customers, and the current regulatory
environment.

  C.1 October 2022 and October 2023 Advanced Computing Rules
      BIS's October 7, 2022 interim final rule and October 17, 2023 final rule imposed:
        - New licence requirements for advanced chip exports to China/Macau
        - Expanded FDPR covering items produced with US wafer fab equipment above
          performance thresholds destined for China
        - New end-use restrictions under § 744.23 for supercomputer and semiconductor
          manufacturing end-uses in China
        - Restrictions on US persons supporting development/production of advanced
          ICs in China

      Your semiconductor equipment, particularly any 3B001.c-f class tools with
      capability above specified thresholds, may be subject to these rules even for
      sales to non-China customers, if those customers supply Chinese fabs.

  C.2 Taiwan-Based Customer Diversion Risk
      Taiwan is a major diversion risk point. TSMC, UMC, and other Taiwanese foundries
      have production for Chinese customers. While a sale to TSMC itself is generally
      compliant, equipment that ends up used for production above thresholds for Chinese
      advanced chip customers may trigger questions. Your due diligence for Taiwan
      customers should document the production activities of the fab and confirm
      the equipment will not be used for prohibited China-related applications.

  C.3 MEU List and Chinese Military-Civil Fusion
      China's Military-Civil Fusion strategy means that ostensibly civilian Chinese
      entities (universities, research institutes, ostensibly commercial companies)
      may have military connections. The MEU List and the NS-CMIC (Non-SDN Chinese
      Military-Industrial Complex) list are your primary tools here. Screen for these
      even for transactions that appear wholly commercial.

  C.4 No China Sales Policy
      Consider implementing a formal "No Direct Sales to China" policy, pending
      individual transaction review and approval by the ECO and legal counsel.
      This is increasingly standard practice for semiconductor equipment companies
      and provides a defensible compliance posture given current regulatory risk.

----------------------------------------------------------------------
D. DEEMED EXPORTS — SPECIFIC TO SEMICONDUCTOR EQUIPMENT ENGINEERING CULTURE
----------------------------------------------------------------------

A 200-person semiconductor equipment company typically has a significant portion of
its workforce in engineering roles, often including foreign nationals from China,
India, South Korea, and Taiwan. The deemed export implications are substantial.

  D.1 Pre-Hire Screening
      Before extending an offer to any foreign national for a role that will involve
      access to 3E001 (technology for 3B001 equipment) or 3E002 (technology for 3B002
      equipment), conduct a deemed export screening:
        - Identify which technology the employee will access
        - Classify that technology
        - Determine the employee's nationality (most restrictive rule for dual nationals)
        - Determine if a licence would be required to export that technology to the
          employee's home country

      For Chinese nationals accessing NS-controlled 3E001 technology: a deemed export
      licence is very likely required. Apply through SNAP-R before granting access.

  D.2 Access Controls
      Implement role-based access controls for all controlled technology:
        - Physical lab access: badge control, visitor logs
        - CAD and design files: permissions by role and nationality
        - Source code repositories (GitHub/GitLab/Bitbucket): access groups controlled
          by the ECO, not just IT or engineering management
        - Test data and process recipes: treat as controlled technology

  D.3 Foreign Visitors to Your Facilities
      Any foreign national who visits your facility and is shown controlled equipment
      or technology (even in a marketing or sales context) may trigger a deemed export.
      Implement a visitor access policy: screen visitors, log their access, and ensure
      controlled technology is not disclosed without appropriate authorisation.

=======================================================================
PART THREE: PROGRAMME LAUNCH — RECOMMENDED SEQUENCING
=======================================================================

For a company building an ECP from scratch, implement in this order:

Phase 1 (Months 1-3) — Foundations:
  - Appoint ECO; draft and execute management commitment policy
  - Begin ECCN classification of the top 20 product lines (highest revenue/highest risk)
  - Implement restricted party screening tool (at minimum, CSL screening via
    trade.gov or a commercial tool like Visual Compliance or Descartes)
  - Draft and implement the restricted party screening procedure
  - Deliver Track A training to all employees

Phase 2 (Months 4-6) — Structure:
  - Complete ECCN classification of full product portfolio
  - Draft all written procedures (Elements 3.1-3.10)
  - Conduct deemed export assessment of engineering roles
  - Begin KYC review of existing customer and distributor base
  - Deliver Track B and Track C training
  - Implement ERP integration for automated screening

Phase 3 (Months 7-12) — Maturity:
  - FDPR analysis for all product lines and customer agreements
  - Update distributor agreements with EAR compliance clauses
  - Obtain CCATS determinations for key product lines
  - Conduct first internal ECP audit
  - Deliver Track D training to ECO/legal/finance
  - Engage third-party counsel for programme review
  - Commission SNAP-R accounts and practice licence application workflows
  - Implement VSD procedure; run tabletop exercise

=======================================================================
PART FOUR: RECORDKEEPING QUICK REFERENCE
=======================================================================

Document Type                              | Retention Period
-------------------------------------------|--------------------------
Commercial invoices, purchase orders       | 5 years from export date
Bills of lading, air waybills              | 5 years
EEI/AES filings                            | 5 years
Licence applications and approvals         | 5 years from expiry
Licence exception documentation            | 5 years from export
Restricted party screening records         | 5 years
End-user statements (BIS-711)              | 5 years
ECCN classification records                | 5 years from last export
Customer KYC/due diligence files           | 5 years from last transaction
Training records                           | 5 years
VSD submissions and OEE correspondence     | Permanently

=======================================================================
REGULATORY CITATIONS AND RESOURCES
=======================================================================

  15 CFR Part 730         — General Information
  15 CFR Part 734         — Scope of the EAR; definitions of export, reexport, transfer
  15 CFR § 734.13         — Deemed export rule
  15 CFR § 734.4          — De minimis rule
  15 CFR Part 736         — Ten General Prohibitions
  15 CFR § 736.2(b)(3)    — Foreign Direct Product Rule
  15 CFR Part 738         — Commerce Country Chart
  15 CFR Part 740         — License Exceptions (all 14 exceptions)
  15 CFR § 740.20         — STA (Strategic Trade Authorization) exception
  15 CFR Part 742         — Control policy
  15 CFR Part 744         — End-user and end-use controls
  15 CFR § 744.2-744.6    — WMD end-use prohibitions
  15 CFR Part 744, Supp. 4 — Entity List
  15 CFR Part 744, Supp. 6 — Unverified List
  15 CFR Part 744, Supp. 7 — MEU List
  15 CFR Part 746         — Embargoes and special controls
  15 CFR Part 748         — License applications; SNAP-R; BIS-748P; BIS-711
  15 CFR Part 758         — Export clearance (EEI)
  15 CFR Part 762         — Recordkeeping (5-year retention at § 762.6)
  15 CFR Part 764         — Enforcement; Denied Persons List; civil/criminal penalties
  15 CFR § 764.5          — Voluntary Self-Disclosure
  15 CFR Part 766         — Administrative enforcement proceedings
  15 CFR Part 774, Supp. 1 — Commerce Control List; ECCN 3B001, 3B002, 3E001, 3E002
  15 CFR Part 732, Supp. 3 — Red Flag Indicators (15 flags)

  BIS Portal:       bis.gov
  SNAP-R:           snap-r.bis.doc.gov
  CSL:              trade.gov/consolidated-screening-list
  CCATS:            Submit via SNAP-R using Form BIS-748P
  BIS Alerts:       Subscribe at bis.gov/regulations/subscribe-bis-alerts

=======================================================================
DISCLAIMER
=======================================================================

This guidance reflects the EAR as of the date of preparation and is based on
publicly available regulatory text and BIS guidance. Export control regulations
change frequently — particularly for semiconductor equipment given ongoing
national security policy activity. This response is for informational and compliance
planning purposes. Before making final licensing determinations, consult qualified
export control counsel and verify current regulatory text at ecfr.gov and bis.gov.

=======================================================================
END OF RESPONSE
=======================================================================

EXPORT COMPLIANCE PROGRAMME DESIGN FOR A 200-PERSON SEMICONDUCTOR EQUIPMENT COMPANY
Covering the Seven BIS Elements and Restricted Party Screening

=============================================================================

INTRODUCTION

Semiconductor equipment is among the most tightly controlled categories of dual-use technology
in U.S. export regulations. The Export Administration Regulations (EAR), administered by the
Bureau of Industry and Security (BIS) within the U.S. Department of Commerce, impose
significant obligations on exporters of items classified under Export Control Classification
Numbers (ECCNs) in the 3B category (semiconductor manufacturing equipment). Your destinations —
Europe, Japan, South Korea, Taiwan, and India — range from very favorable (close treaty allies)
to requiring heightened diligence (India, depending on end-use and end-user). Building a
credible Export Compliance Programme (ECP) from scratch requires implementing the seven
elements BIS has identified as core to an effective compliance framework.

=============================================================================

PART I: THE SEVEN BIS ELEMENTS OF AN EFFECTIVE EXPORT COMPLIANCE PROGRAMME

BIS has articulated these elements through its enforcement guidelines, penalty mitigation
factors, and guidance documents (including the Export Compliance Guidelines published on the
BIS website). Companies that implement all seven elements in good faith receive meaningful
mitigation credit in enforcement proceedings and, more importantly, are far less likely to
commit violations in the first place.

---------------------------------------------------------------------
ELEMENT 1: MANAGEMENT COMMITMENT
---------------------------------------------------------------------

What it means:
Senior leadership — the CEO, Board, and executive team — must visibly and actively champion
the compliance programme. This is not a delegated-down function; it requires top-down tone
and resources.

Implementation for your company:

a) Designate a senior Export Compliance Officer (ECO) or Export Compliance Manager with
   direct reporting access to the CEO or General Counsel. For a 200-person semiconductor
   equipment company, this should be a dedicated, experienced hire — not a collateral duty
   added to the Legal or Finance function.

b) Obtain and document Board/executive-level approval of the Export Compliance Policy
   Statement. The policy should be signed by the CEO and reviewed annually.

c) Allocate budget: screening tools, legal counsel, training platforms, and dedicated staff
   time are real costs. Management must fund them adequately.

d) Establish an Export Control Committee or steering group that includes representatives from
   Sales, Engineering, Legal, Finance, and Operations. This group should meet at least
   quarterly to review compliance matters, emerging regulatory changes (e.g., Entity List
   additions), and escalations.

e) Include export compliance objectives in executive performance evaluations and incorporate
   compliance metrics in management reporting.

f) Ensure that management is briefed on significant changes to the Entity List and on any
   transactions involving heightened risk (India end-uses, unusual routing, etc.).

Why it matters for semiconductor equipment:
BIS has significantly escalated enforcement in the semiconductor space, particularly regarding
China-adjacent supply chains, advanced node equipment, and multilateral controls under the
Wassenaar Arrangement. Management buy-in is essential for the cultural authority to say "no"
to a lucrative sale that raises compliance concerns.

---------------------------------------------------------------------
ELEMENT 2: RISK ASSESSMENT
---------------------------------------------------------------------

What it means:
A systematic, documented process for identifying, evaluating, and prioritizing export control
risks across the company's products, markets, customers, and transactions.

Implementation for your company:

a) Product Classification Review:
   - Conduct a thorough ECCN classification review for all products in your portfolio.
     Semiconductor equipment will commonly fall under ECCN 3B001 or 3B002 (equipment for
     manufacturing semiconductor devices) or potentially 3B991/3B992 for less sensitive items.
   - Engage outside counsel or a technical expert to classify products if internal expertise
     is limited. Misclassification is a common source of violations.
   - Document the classification rationale in a Classification Register, including the
     technical parameters that drove the classification decision (e.g., overlay accuracy,
     minimum feature size, throughput thresholds).
   - Identify which products qualify as EAR99 (no ECCN, subject to EAR but generally low
     risk) versus controlled ECCNs.

b) Destination/Country Risk Mapping:
   - Map your destination countries against the EAR's Country Groups (A, B, D, E).
   - Europe and Japan: generally Country Group A, with favorable license exception
     availability (e.g., License Exception STA — Strategic Trade Authorization).
   - South Korea and Taiwan: broadly favorable, but verify transaction-by-transaction.
   - India: Country Group B but not A:5 (no validated end-user list at the same level
     as close allies). Certain items require a license for India that would be license-
     exception eligible for Japan. Also review Validated End-User (VEU) program
     opportunities for repeat Indian customers.
   - Assess whether any products are subject to foreign military end-use / end-user
     (FMEU) controls under EAR Part 744.

c) End-Use Risk Assessment:
   - Semiconductor equipment is of particular concern for:
     * Military end-use (EAR 744.21 — the military end-use / end-user rule)
     * WMD end-use (EAR 744.2-.6)
     * Proliferation activities
     * Advanced node chip fabrication that may be restricted under recent semiconductor
       rules (e.g., October 2022 and subsequent BIS rules targeting advanced computing
       and semiconductor manufacturing items — "ITAR-adjacent" EAR controls)
   - Develop an end-use risk scoring matrix that factors in: customer type (IDM, foundry,
     research institution, distributor, defense contractor), product application, and
     country of ultimate destination.

d) Channel Risk:
   - Assess risks from distributors, sales agents, and resellers who may export your
     equipment onward.
   - For your destination mix, this is particularly relevant in India (where equipment
     may be resold or transferred to third parties) and Taiwan (given proximity to China
     and potential for diversion).

e) Document and update your risk assessment at least annually and whenever there is a
   significant change in your product portfolio, customer base, or the regulatory
   environment.

---------------------------------------------------------------------
ELEMENT 3: EXPORT COMPLIANCE POLICIES, PROCEDURES, AND GUIDELINES
---------------------------------------------------------------------

What it means:
Written, accessible, and operationally integrated policies that govern how the company
conducts export-controlled activities, makes classification decisions, screens parties,
processes license applications, and responds to red flags.

Implementation for your company:

a) Core Policy Documents to Draft:
   - Export Compliance Policy (top-level, CEO-signed)
   - Product Classification Procedure (including the ECCN determination workflow)
   - Order Review and Transaction Screening Procedure
   - Restricted Party Screening Procedure (see Part II below for detail)
   - License Determination and Application Procedure
   - Red Flag Identification and Resolution Procedure
   - Technology Control Plan (TCP) for controlled technology
   - Deemed Export Procedure (for foreign nationals working with controlled technology)
   - Recordkeeping Policy (EAR requires five-year retention of export records)
   - Incident Response and Voluntary Self-Disclosure Procedure

b) Make policies searchable and accessible — host on your intranet with version control.
   Procedures should be written at an operational level: who does what, when, using
   which tools, and how decisions are documented.

c) Integration into Business Processes:
   - Embed compliance checkpoints in the order-to-cash process (CRM to ERP).
   - Require compliance sign-off before contract execution for controlled items.
   - Link classification records to the ERP system's product master data.

d) Deemed Export Controls:
   - Semiconductor equipment technology is frequently subject to deemed export controls —
     sharing controlled technical data with a foreign national in the U.S. is treated as
     an export to that person's country of nationality.
   - Implement a deemed export procedure: maintain records of foreign national employees/
     contractors with access to EAR-controlled technical data, assess their nationalities
     against license requirements, and obtain licenses where required.
   - This is especially important given that your engineering team likely includes
     nationals of China, India, Taiwan, and other countries.

---------------------------------------------------------------------
ELEMENT 4: TRAINING AND AWARENESS
---------------------------------------------------------------------

What it means:
A systematic programme to educate employees on their export control responsibilities,
proportionate to their role and the risk level they encounter.

Implementation for your company:

a) Role-Based Training Curriculum:
   - All employees: Annual general awareness training (what are export controls, why
     they matter, what is a red flag, how to escalate).
   - Sales and customer-facing staff: In-depth training on restricted party screening,
     end-use/end-user red flags, license requirements by destination, and embargo awareness.
   - Engineering and R&D: Training on deemed exports, technology control plans, and
     classification of technical data.
   - Shipping/logistics: Training on export documentation (EEI filings, AES), destination
     controls statements, and physical security of shipments.
   - Management and ECO: Advanced training on penalty exposure, recent enforcement actions,
     and emerging regulatory changes.

b) Training Delivery:
   - Use a learning management system (LMS) to track completion and issue certificates.
   - Supplement annual training with targeted briefings after significant regulatory changes
     (BIS issues rules frequently in the semiconductor space).
   - Include export compliance scenarios in onboarding for new hires in Sales, Engineering,
     and Operations.

c) Documentation:
   - Retain training completion records. BIS views documented training as a significant
     mitigating factor in enforcement proceedings.

d) Awareness Culture:
   - Circulate brief "compliance alerts" when significant regulatory changes occur (e.g.,
     new Entity List additions of semiconductor customers, new EAR rules on advanced
     computing).
   - Maintain a confidential reporting channel for employees to raise compliance concerns
     without fear of retaliation.

---------------------------------------------------------------------
ELEMENT 5: SCREENING, AUDITING, AND MONITORING
---------------------------------------------------------------------

What it means:
Systematic and ongoing processes to screen transactions and parties, and to audit the
compliance programme for effectiveness and gaps.

This element has two distinct components: (a) ongoing transaction/party screening, and
(b) periodic compliance auditing. Restricted party screening is covered in depth in
Part II below.

Auditing:

a) Internal Audits:
   - Conduct a comprehensive internal export compliance audit at least annually. The audit
     should cover: classification accuracy, screening process adherence, license condition
     compliance, recordkeeping, training completion, and deemed export compliance.
   - The audit should be conducted by someone independent of the day-to-day compliance
     function — either an internal audit team member trained in EAR, or outside counsel.

b) Audit Scope for Semiconductor Equipment Exporters:
   - Sample shipment records and verify EEI filings in AES (Automated Export System).
   - Verify that ECCN classifications are current and reflect current product specifications
     (engineering changes can affect ECCN).
   - Test that restricted party screening was performed and documented for audited
     shipments.
   - Review license conditions for any licenses held and verify compliance.
   - Check that technology transfers (technical data, software) to foreign nationals
     and overseas subsidiaries/customers were properly screened and authorized.

c) Monitoring:
   - Monitor regulatory changes continuously: subscribe to BIS email alerts, Federal
     Register notices, and law firm client alerts.
   - Monitor the Entity List, SDN List, and other restricted party lists for additions
     relevant to your customer/supplier base.
   - Track BIS enforcement actions for industry-specific lessons learned.

---------------------------------------------------------------------
ELEMENT 6: HANDLING AND REPORTING EXPORT CONTROL PROBLEMS
---------------------------------------------------------------------

What it means:
Clear processes for identifying, escalating, investigating, and (where appropriate)
voluntarily disclosing export control violations or potential violations.

Implementation for your company:

a) Red Flag Escalation:
   - Define what constitutes a "red flag" (unusual payment terms, requests to remove
     technical markings, vague end-use descriptions, routing through unusual third
     countries, customer reluctance to provide end-use certificates).
   - Require employees to escalate red flags to the ECO before proceeding with a
     transaction. Establish a formal hold process.

b) Investigation Protocol:
   - When a potential violation is identified, the ECO (with Legal) should conduct a
     prompt preliminary investigation.
   - Preserve all relevant records immediately.
   - Assess whether a Voluntary Self-Disclosure (VSD) to BIS's Office of Export
     Enforcement (OEE) is appropriate.

c) Voluntary Self-Disclosure:
   - BIS strongly encourages VSDs and provides significant mitigation credit (typically
     50% reduction in civil penalty) for timely, complete, and good-faith disclosures.
   - VSDs should be submitted to OEE with a narrative of facts, root cause analysis,
     and corrective action plan.
   - Engage experienced export control counsel before submitting a VSD.

d) Corrective Action:
   - Every violation or near-miss should result in a documented root cause analysis and
     corrective action plan.
   - Update policies, training, and screening procedures as needed.

e) No Retaliation Policy:
   - Employees who report compliance concerns in good faith must be protected from
     retaliation. Make this explicit in policy and in leadership communications.

---------------------------------------------------------------------
ELEMENT 7: RECORDKEEPING
---------------------------------------------------------------------

What it means:
Systematic maintenance of all export-related records in compliance with EAR requirements,
and in a manner that supports auditing and investigation.

Implementation for your company:

a) Regulatory Requirements:
   - EAR Part 762 requires exporters to maintain records for five years from the date
     of export, reexport, or other regulated transaction.
   - Required records include: export licenses, AES filings, purchase orders, invoices,
     packing lists, shipping documents, end-use certificates, restricted party screening
     records, and export classification determinations.

b) Recordkeeping System:
   - Implement a centralized document management system for export records.
   - Ensure records are indexed and retrievable by transaction, customer, and date.
   - Link records to the ERP system where possible.

c) Technology Control / Data Security:
   - Maintain access controls for technical data stored in engineering systems (PLM, CAD,
     file servers) to prevent unauthorized access by foreign nationals or transfer to
     unauthorized destinations.
   - Log and retain records of technical data access for deemed export compliance.

d) Retention Schedule:
   - Set an automated retention schedule of at least five years, with legal hold
     capability for records under investigation.

=============================================================================

PART II: RESTRICTED PARTY SCREENING PROCESS

Restricted party screening (RPS) is arguably the most operationally critical compliance
control for an active exporter. Transacting with a party on a restricted list is a per se
violation of U.S. law and may result in criminal prosecution, civil penalties, and
debarment — regardless of whether you knew the party was listed.

---------------------------------------------------------------------
WHICH LISTS MUST YOU SCREEN AGAINST?
---------------------------------------------------------------------

For a U.S.-based semiconductor equipment exporter, screening must cover at minimum:

1. OFAC Lists (administered by Treasury's Office of Foreign Assets Control):
   - Specially Designated Nationals and Blocked Persons List (SDN List) — the most
     critical. Transacting with an SDN is generally prohibited regardless of what
     is being sold.
   - Non-SDN Sectoral Sanctions Identifications List (SSI List)
   - Consolidated Sanctions List (covers multiple OFAC programs)
   - Foreign Sanctions Evaders List
   - Sectoral sanctions lists (e.g., for Russia, Cuba, Iran, North Korea, Syria)

2. BIS Lists (administered by Department of Commerce):
   - Entity List (EAR Part 744, Supplement 4) — parties for whom a license is required
     for all items subject to the EAR. This list has grown dramatically in recent years
     with semiconductor-related additions, particularly Chinese entities.
   - Denied Persons List — parties denied export privileges; no U.S. person may
     participate in any export transaction involving them.
   - Unverified List — parties for whom BIS could not verify end-use; heightened due
     diligence required; license exception unavailability.

3. DDTC List (administered by State's Directorate of Defense Trade Controls):
   - Debarred Parties List (ITAR) — while your products may be EAR-controlled rather
     than ITAR, debarred parties are generally high-risk and warrant screening.

4. Additional Government Lists:
   - DHS CAATS / Consolidated Terrorist List
   - FBI Most Wanted
   - Non-SDN Palestinian Legislative Council List
   - Various country-specific sanctions lists

Best practice: Use a commercial restricted party screening (RPS) tool (e.g., Descartes
Visual Compliance, Amber Road/E2open, Thomson Reuters World-Check, Dow Jones Risk &
Compliance, Sayari, or similar) that aggregates all relevant lists into a single search
interface and auto-updates as lists change. Manual screening against individual government
websites is error-prone and not sustainable at transaction volume.

---------------------------------------------------------------------
WHEN TO SCREEN
---------------------------------------------------------------------

Screen at each of the following trigger points:

1. Pre-Opportunity / Quote Stage: Screen the prospective customer (legal entity name,
   doing business as names, and any named intermediaries) before committing engineering
   or commercial resources to a proposal.

2. Order Receipt: Screen at order entry into the ERP or order management system.
   This is the primary transaction-level control.

3. Pre-Shipment: Conduct a final screen immediately before releasing a shipment,
   particularly if there has been a gap of more than 30 days since the last screen.
   Entity List and SDN additions occur on a rolling basis.

4. Contract Execution: Screen before signing distribution agreements, service contracts,
   or technology license agreements.

5. After Significant List Updates: When BIS makes a major Entity List addition (e.g.,
   adding a major chip manufacturer or fab), proactively screen your existing customer
   and pipeline against the update.

6. New Employees / Contractors (Foreign Nationals): Screen under deemed export
   obligations — assess nationality of foreign national employees before granting
   access to controlled technology.

---------------------------------------------------------------------
WHOM TO SCREEN
---------------------------------------------------------------------

Screen all relevant parties in a transaction, not just the direct customer:

- The ordering customer (bill-to party)
- The ship-to / end-use party (may differ from the ordering customer)
- Distributors, sales agents, and resellers acting on your behalf
- Freight forwarders and customs brokers (for completeness)
- Named end-users in end-use certificates
- Ultimate consignees
- Intermediate consignees
- Any third parties introduced mid-transaction

For your destination mix:
- Taiwan: Pay particular attention to whether the customer or end-user has known ties to
  Chinese entities or Chinese-funded fabs, given the EAR's focus on preventing
  semiconductor technology from reaching restricted Chinese end-users.
- India: Screen not just the customer but the stated end-use facility and any Indian
  government or defense-affiliated entities involved.
- South Korea and Japan: Lower routine risk, but screen systematically regardless —
  lists include parties in all countries.
- Europe: Include EU and UK sanctions lists (post-Brexit, UK has its own sanctions
  regime) in addition to OFAC/BIS lists for customers in the UK.

---------------------------------------------------------------------
FUZZY MATCHING AND ALIAS MATCHING
---------------------------------------------------------------------

Restricted party screening is complicated by transliteration, name variations, and
aliases. Your screening tool must:

- Apply fuzzy matching logic (typically 80-85% match threshold is a reasonable starting
  point, adjustable based on your risk tolerance).
- Screen aliases, also-known-as (AKA), formerly-known-as (FKA), and doing-business-as
  (DBA) names.
- Screen addresses and other identifying information where available.
- Flag partial matches for human review rather than auto-clearing them.

Establish a documented match review process:
- Screening tool generates a "hit" or "potential match."
- A trained reviewer conducts manual due diligence: compare address, country, industry,
  and other identifiers against the list entry.
- Document the determination: confirmed match (transaction blocked) or false positive
  (transaction cleared, with written rationale).
- Escalate any confirmed match to the ECO and Legal.

---------------------------------------------------------------------
DOCUMENTATION
---------------------------------------------------------------------

For every screening action, retain:
- Date and time of screen
- Names and entities screened
- Lists screened against (or confirmation that the tool covers all required lists)
- Result (clear, hit, or potential match)
- For potential matches: the reviewer's analysis and determination
- Authorizing signature for cleared transactions involving any potential match

This documentation is essential for audit defense and forms part of your five-year
EAR recordkeeping obligation.

---------------------------------------------------------------------
CUSTOMER DUE DILIGENCE BEYOND LIST SCREENING
---------------------------------------------------------------------

Restricted party screening is necessary but not sufficient. BIS's Red Flag guidance
(EAR Supplement 1 to Part 732, "Know Your Customer" guidance) requires that you also
conduct broader due diligence when red flags are present.

For new customers in your markets, consider also:
- Verifying the customer's business existence and legitimacy (website, trade references,
  business registration).
- Requiring end-use certificates or statements for controlled items, particularly for
  India and any new customer in any market.
- Conducting enhanced due diligence for distributors who will resell your equipment —
  review their customer list if possible, obtain flow-down compliance representations
  in the distribution agreement.
- Implementing a Know Your Customer (KYC) questionnaire for new distributors and
  high-value customers.

---------------------------------------------------------------------
AUTOMATED INTEGRATION
---------------------------------------------------------------------

For a 200-person company with active transaction volume, integrate your RPS tool with
your ERP or CRM system to:
- Automatically trigger a screen when a new customer is added or a new order is entered.
- Block order release until screening is completed and documented.
- Generate screening certificates that attach to the shipment record.

This automation reduces the risk of human omission and creates an auditable trail.

---------------------------------------------------------------------
INDIA-SPECIFIC CONSIDERATIONS FOR YOUR SCREENING PROGRAMME
---------------------------------------------------------------------

India presents additional considerations:

- Indian Space Research Organisation (ISRO) and entities affiliated with it have at
  various times appeared on restricted lists. Verify current status at each transaction.
- India's defense-civil integration means some ostensibly commercial customers may
  have defense connections requiring license review under EAR 744.21.
- For certain controlled semiconductor equipment, India may require a BIS license even
  where a license exception would apply to Japan or South Korea. Verify ECCN-specific
  India license requirements.
- Pursue Validated End-User (VEU) authorization for trusted, repeat Indian customers
  to streamline ongoing transactions.

=============================================================================

PART III: PROGRAMME IMPLEMENTATION ROADMAP (SUGGESTED SEQUENCING)

Given you are building from scratch, a phased approach is recommended:

PHASE 1 (Months 1-3): Foundation
- Hire/designate Export Compliance Officer
- Engage outside export control counsel for initial assessment
- Conduct ECCN classification review of product portfolio
- Implement commercial RPS screening tool immediately
- Draft and execute Export Compliance Policy (CEO-signed)
- Establish screening procedure and begin documenting all screens

PHASE 2 (Months 3-6): Core Programme Build
- Draft all core policy documents (classification, order review, deemed export, etc.)
- Implement role-based training programme; complete all-employee training
- Conduct comprehensive risk assessment; document in writing
- Integrate RPS tool with ERP
- Establish Export Control Committee
- Review and classify deemed export risk for foreign national employees

PHASE 3 (Months 6-12): Full Programme Operationalization
- Complete integration of compliance checkpoints into order-to-cash workflow
- Conduct first internal compliance audit
- Establish recordkeeping system and retention schedule
- Develop incident response and VSD procedure
- Submit VEU applications for qualifying Indian customers (if applicable)
- Benchmark programme against BIS guidance and peer-industry practices

ONGOING:
- Annual risk assessment update
- Annual training refresh
- Annual internal audit
- Continuous regulatory monitoring
- Quarterly Export Control Committee meetings
- Pre-shipment screening on every controlled transaction

=============================================================================

PART IV: KEY REGULATORY REFERENCES

- Export Administration Regulations (EAR): 15 C.F.R. Parts 730-774
- BIS Entity List: EAR Part 744, Supplement No. 4
- BIS Denied Persons List: EAR Part 764, Supplement No. 2
- BIS Unverified List: EAR Part 744, Supplement No. 6
- Red Flag guidance: EAR Supplement 1 to Part 732
- OFAC SDN List: 31 C.F.R. various parts
- EAR Recordkeeping: 15 C.F.R. Part 762
- BIS Penalty Guidelines: 15 C.F.R. Part 766, Supplement No. 1
- Commerce Control List (CCL): EAR Part 774 (ECCN 3B001, 3B002 for semiconductor equipment)

Note: The semiconductor equipment sector is subject to particularly dynamic regulatory
change. As of 2024-2026, BIS has issued multiple significant rules restricting exports
of advanced semiconductor manufacturing equipment, particularly to China, including
restrictions on items that assist in producing advanced logic chips below certain node
sizes. Monitor BIS Federal Register notices closely and engage outside counsel to assess
the impact of each new rule on your product portfolio and customer relationships.

=============================================================================

DISCLAIMER

This document reflects general knowledge of U.S. export control law and BIS compliance
programme design principles as of May 2026. It does not constitute legal advice.
Export control regulations change frequently and can be highly fact-specific. Consult
qualified export control counsel before making licensing determinations or compliance
programme decisions.

=============================================================================

================================================================================
NIST SP 800-53 Rev 5 COMPLIANCE ADVISORY RESPONSE
FIPS 199 Categorization & Baseline Selection — Federal HR System
================================================================================

SYSTEM DESCRIPTION
------------------
System Name:    Federal Human Resources Information System (HRIS)
System Type:    Internal agency application (on-premises data center)
User Population: 5,000 federal employees
Data Types:     Personally Identifiable Information (PII), salary/compensation
                data, performance evaluation records
Hosting:        Internal government data center (not cloud)

================================================================================
STEP 1 — FIPS 199 SYSTEM CATEGORIZATION
================================================================================

Authority: Federal Information Processing Standard (FIPS) Publication 199,
"Standards for Security Categorization of Federal Information and Information
Systems" (February 2004), implemented under FISMA 2014 (44 U.S.C. § 3551).

Methodology: Each information type processed by the system is assessed against
the three security objectives — Confidentiality, Integrity, and Availability —
and assigned a potential impact level of Low, Moderate, or High. The overall
system categorization is determined by the high-water mark across all three
objectives for all information types in scope.

SP 800-60 Reference: NIST SP 800-60 Volume II, "Guide for Mapping Types of
Information and Information Systems to Security Categories," provides the
recommended impact levels for standard government information types. The
following mappings apply to this HR system:

INFORMATION TYPES IN SCOPE
---------------------------
1. Employee PII (names, SSNs, addresses, dates of birth, contact info)
   SP 800-60 Type: C.3.1.1 — General Personnel Records / Privacy Data

2. Salary and Compensation Data (pay grades, salaries, benefits, deductions)
   SP 800-60 Type: C.3.1.2 — Payroll and Benefits Data

3. Performance Review Records (ratings, disciplinary actions, promotion records)
   SP 800-60 Type: C.3.1.1 — General Personnel Records

--------------------------------------------------------------------------------
CIA IMPACT ASSESSMENT — PER INFORMATION TYPE
--------------------------------------------------------------------------------

INFORMATION TYPE 1: Employee PII (5,000 staff records)
-------------------------------------------------------
CONFIDENTIALITY — MODERATE
  Rationale: Unauthorized disclosure of PII for 5,000 federal employees would
  cause serious adverse effects to those individuals (identity theft risk,
  financial harm, reputational damage) and to the agency (regulatory sanctions,
  loss of public trust, notification obligations under the Privacy Act of 1974).
  A breach would not rise to the level of "severe or catastrophic" affecting
  national security or critical operations, but the scale (5,000 records) and
  sensitivity of SSNs and financial data clearly exceeds a "limited" impact.
  Per SP 800-60, PII data is typically assigned Moderate Confidentiality.
  Impact Level: MODERATE

INTEGRITY — MODERATE
  Rationale: Unauthorized modification of employee PII records (e.g., altering
  direct deposit routing numbers, changing addresses, falsifying identity
  fields) would cause serious adverse effects — incorrect payroll disbursements,
  inability to locate employees in emergencies, erroneous background-check
  results. While damaging, such modifications are generally detectable and
  correctable; they do not rise to catastrophic operational failure.
  Impact Level: MODERATE

AVAILABILITY — LOW
  Rationale: Temporary unavailability of general PII records (beyond active
  payroll functions) would have limited adverse effect. Employees can be
  identified through alternative records; short-term outages do not prevent
  mission execution. HR lookups are important but not time-critical at the
  operational level.
  Impact Level: LOW

INFORMATION TYPE 2: Salary and Compensation Data
-------------------------------------------------
CONFIDENTIALITY — MODERATE
  Rationale: Federal salary data for GS-scale employees is partially public
  information under OPM regulations, but specific compensation details
  (locality pay, benefits elections, deductions, garnishments) are protected
  under the Privacy Act. Unauthorized disclosure would cause serious adverse
  effects to individual employees and could expose the agency to Privacy Act
  violations. Scale of 5,000 records elevates impact beyond Low.
  Impact Level: MODERATE

INTEGRITY — MODERATE
  Rationale: Integrity of payroll-linked salary data is critical. Unauthorized
  modification could result in improper payments, violations of the Improper
  Payments Information Act, OPM audit findings, and financial harm to employees.
  Errors in salary records could propagate into payroll processing systems,
  causing systematic overpayments or underpayments. Recovery could be complex
  and time-consuming, constituting a serious adverse effect.
  Impact Level: MODERATE

AVAILABILITY — MODERATE
  Rationale: Salary/compensation data feeds into payroll processing cycles. If
  the HR system is unavailable during a pay period processing window, payroll
  for 5,000 employees cannot be processed on time — a serious adverse effect
  on both employees and agency operations. Payroll deadlines are immovable;
  a missed pay cycle constitutes significant operational and legal harm.
  Impact Level: MODERATE

INFORMATION TYPE 3: Performance Review Records
-----------------------------------------------
CONFIDENTIALITY — MODERATE
  Rationale: Performance evaluations, disciplinary records, and promotion
  decisions are sensitive personnel data protected under the Privacy Act and
  5 U.S.C. § 552a. Disclosure could harm employee reputations, expose the
  agency to grievance proceedings, and undermine trust in the HR process.
  Unauthorized access to these records for 5,000 employees constitutes a
  serious adverse effect.
  Impact Level: MODERATE

INTEGRITY — MODERATE
  Rationale: Tampering with performance ratings or disciplinary records would
  have serious adverse effects — improper promotions, wrongful disciplinary
  actions, civil service merit system violations, and potential litigation
  (whistleblower retaliation, EEO claims). The integrity of the federal merit
  system is foundational to civil service law.
  Impact Level: MODERATE

AVAILABILITY — LOW
  Rationale: Performance reviews are typically accessed infrequently (annual
  review cycles, promotion boards). Temporary unavailability has limited adverse
  effect on day-to-day agency operations. Review cycles can be rescheduled in
  most circumstances.
  Impact Level: LOW

--------------------------------------------------------------------------------
HIGH-WATER MARK DETERMINATION
--------------------------------------------------------------------------------

Per FIPS 199 Section 3, the overall system categorization is the highest impact
level recorded across all three security objectives for all information types
processed by the system.

Security Objective | Highest Impact Level Across All Information Types
-------------------|--------------------------------------------------
CONFIDENTIALITY    | MODERATE (PII, Salary, Performance Records)
INTEGRITY          | MODERATE (PII, Salary, Performance Records)
AVAILABILITY       | MODERATE (Salary/Compensation — payroll dependency)

                        +---------------------------------+
                        |  OVERALL SYSTEM CATEGORIZATION  |
                        |                                 |
                        |  SC = {(C, MODERATE),           |
                        |        (I, MODERATE),           |
                        |        (A, MODERATE)}           |
                        |                                 |
                        |  FIPS 199 CATEGORY: MODERATE    |
                        +---------------------------------+

Formal categorization notation per FIPS 199:
  SC-HR System = {(confidentiality, MODERATE), (integrity, MODERATE),
                  (availability, MODERATE)}

================================================================================
STEP 2 — NIST SP 800-53B BASELINE SELECTION
================================================================================

Authority: NIST SP 800-53B, "Control Baselines for Information Systems and
Organizations" (October 2020).

SELECTED BASELINE: MODERATE

Rationale:
  The FIPS 199 high-water mark of MODERATE maps directly to the SP 800-53B
  Moderate control baseline. This baseline encompasses approximately 323
  controls and control enhancements and is the appropriate starting point for
  all federal information systems categorized at the Moderate impact level.

  The Moderate baseline is also the most common baseline applied to federal
  administrative and mission-support systems, and it aligns with FedRAMP
  Moderate authorization requirements for cloud equivalents of systems of
  this type.

Why NOT Low:
  The Low baseline is insufficient for a system storing PII for 5,000
  employees, salary data with payroll dependencies, and sensitive performance
  records. The Privacy Act, OMB Circular A-130, and the NIST Privacy Framework
  all require controls commensurate with the sensitivity and volume of PII
  processed. Low baseline controls do not provide adequate access controls,
  audit capabilities, or data protection measures for this data sensitivity.

Why NOT High:
  A High categorization would be appropriate if a breach would cause severe or
  catastrophic harm — such as loss of life, national security compromise, or
  widespread critical infrastructure failure. While unauthorized disclosure of
  5,000 employees' PII is serious, it does not meet the FIPS 199 threshold for
  "severe or catastrophic" adverse effects. High baseline controls would impose
  disproportionate burden without proportionate risk reduction for this system.
  If future analysis reveals that the system supports law enforcement,
  intelligence, or national security HR functions, High should be reconsidered.

MODERATE BASELINE — KEY CONTROL FAMILIES APPLICABLE TO THIS SYSTEM
-------------------------------------------------------------------

AC — Access Control (Moderate Baseline)
  AC-2    Account Management: Formal account creation, modification, removal
          and review procedures for all HR system users.
  AC-2(1) Automated System Account Management [M enhancement]
  AC-3    Access Enforcement: Role-based access control (RBAC) enforcing
          least privilege — HR staff see only records within their scope.
  AC-5    Separation of Duties: No single user can both create and approve
          salary changes.
  AC-6    Least Privilege
  AC-6(1) Authorize Access to Security Functions [M enhancement]
  AC-17   Remote Access: Controls for any VPN or remote HR system access.
  Recommended ODV: AC-2(3) — disable inactive accounts after 90 days.

AU — Audit and Accountability (Moderate Baseline)
  AU-2    Event Logging: Log all read/write/delete access to PII and salary
          records, privileged user actions, authentication events.
  AU-3    Content of Audit Records
  AU-9    Protection of Audit Information
  AU-11   Audit Record Retention
  Recommended ODV: AU-11 — retain audit logs for 3 years (aligned with
          Privacy Act records retention schedules).

IA — Identification and Authentication (Moderate Baseline)
  IA-2    Identification and Authentication (Org Users)
  IA-2(1) MFA for Privileged Accounts [M]: Multi-factor authentication
          required for all HR administrators and privileged roles.
  IA-2(2) MFA for Non-Privileged Accounts [M]: MFA recommended for all
          users given PII sensitivity.
  IA-5    Authenticator Management: Password complexity and rotation policies.
  IA-5(1) Password-Based Authentication [M enhancement]

SC — System and Communications Protection (Moderate Baseline)
  SC-8    Transmission Confidentiality and Integrity: Encrypt all data in
          transit (TLS 1.2+ minimum).
  SC-8(1) Cryptographic Protection [M enhancement]
  SC-28   Protection of Information at Rest: Encrypt PII, salary, and
          performance data at rest (AES-256 recommended).
  SC-28(1) Cryptographic Protection [M enhancement]
  SC-7    Boundary Protection: Network segmentation isolating the HR
          system from general-purpose networks.

SI — System and Information Integrity (Moderate Baseline)
  SI-2    Flaw Remediation: Patch critical vulnerabilities within 30 days;
          high within 60 days.
  SI-3    Malware Protection
  SI-7    Software, Firmware, and Information Integrity [M]
  SI-12   Information Management and Retention: Manage PII in accordance
          with Privacy Act records schedules.

CP — Contingency Planning (Moderate Baseline)
  CP-9    Information System Backup: Regular backups of all HR data.
  CP-9(1) Testing for Reliability/Integrity [M]
  CP-10   Information System Recovery and Reconstitution

RA — Risk Assessment (Moderate Baseline)
  RA-3    Risk Assessment: Conduct and document a system-level risk assessment.
  RA-5    Vulnerability Monitoring and Scanning: Regular vulnerability scans
          of the HR system and its hosting infrastructure.
  RA-3(1) Supply Chain Risk Assessment [M enhancement]: Assess risks from
          any third-party HR software components or vendors.

CA — Assessment, Authorization and Monitoring (Moderate Baseline)
  CA-2    Control Assessments: Independent security assessment before ATO.
  CA-7    Continuous Monitoring: Ongoing assessment of control effectiveness.
  CA-9    Internal System Connections: Document and authorize connections to
          payroll or other agency systems.

PS — Personnel Security (Moderate Baseline)
  PS-3    Personnel Screening: Background investigations for all HR system
          users commensurate with data sensitivity.
  PS-4    Personnel Termination: Immediate account deactivation upon departure.
  PS-5    Personnel Transfer: Modify access rights upon internal transfers.

PE — Physical and Environmental Protection (Moderate Baseline)
  PE-2    Physical Access Authorizations
  PE-3    Physical Access Control: Physical access controls for the data
          center hosting the HR system.
  PE-6    Monitoring Physical Access
  Note: As an on-premises data center deployment, PE controls are system-
  specific and cannot be fully inherited from a cloud provider.

================================================================================
STEP 3 — PT FAMILY (PII PROCESSING AND TRANSPARENCY) — MANDATORY OVERLAY
================================================================================

Because this system processes Personally Identifiable Information for 5,000
federal employees, the Privacy controls (PT family) under SP 800-53 Rev 5 are
mandatory regardless of the Moderate impact categorization. OMB Circular A-130,
"Managing Information as a Strategic Resource" (July 2016), requires agencies
to implement privacy controls for all systems processing PII.

The PT family (PT-1 through PT-8) must be applied as a privacy overlay on top
of the Moderate security baseline:

PT-1  — Policy and Procedures: Establish and maintain a PII processing policy
        documenting the legal authority, purpose, and use limitations for
        collecting employee PII.

PT-2  — Authority to Process PII: Document the legal authority authorizing the
        collection and use of employee PII (e.g., 5 U.S.C. Chapter 31 federal
        employment statutes, Privacy Act of 1974).

PT-3  — Purposes of Processing PII: Document and limit PII processing to
        stated HR purposes only. Do not use salary or performance data for
        unapproved secondary purposes.

PT-4  — Consent: Determine whether and how employee consent is required or
        appropriate for specific PII processing activities (note: employment
        relationships may not require separate consent for core HR functions,
        but supplemental uses require analysis).

PT-5  — Privacy Notice: Provide Privacy Act Statements at the point of PII
        collection informing employees of the authority, purpose, routine uses,
        and whether disclosure is mandatory or voluntary.
        Action Required: Publish a System of Records Notice (SORN) in the
        Federal Register for this HR system per Privacy Act requirements.

PT-6  — Privacy Reports: Report on PII processing activities as required by
        OMB reporting requirements.

PT-7  — Specific Categories of PII: Identify whether any special categories
        of PII are processed (e.g., financial account data for direct deposit,
        medical information in benefits records). Apply enhanced protections
        if sensitive PII categories are present.

PT-8  — Computer Matching Requirements: Assess whether any data matching
        with other federal agency records occurs, triggering Computer Matching
        and Privacy Protection Act requirements.

Additional Privacy Requirements:
  - Conduct a Privacy Impact Assessment (PIA) per E-Government Act of 2002
    Section 208 prior to system deployment.
  - Publish or update the System of Records Notice (SORN) per 5 U.S.C. § 552a.
  - Designate a Senior Agency Official for Privacy (SAOP) point of contact.
  - Document data minimization practices — collect only PII necessary for HR
    functions; do not aggregate beyond operational need.

================================================================================
STEP 4 — SP 800-60 REFERENCE DETAIL
================================================================================

NIST SP 800-60 Volume II provides the following specific guidance for the
information types present in this HR system:

Information Type C.3.1.1 — Personnel Records:
  Default Impact Values: Confidentiality = Moderate, Integrity = Moderate,
                         Availability = Low
  Adjustment Factors: The volume of records (5,000) and the inclusion of
  financial data (salary) supports maintaining Moderate ratings without
  downgrade.

Information Type C.3.1.2 — Payroll and Benefits Data:
  Default Impact Values: Confidentiality = Moderate, Integrity = Moderate,
                         Availability = Moderate
  Rationale: Payroll availability is time-sensitive due to pay period cycles;
  Moderate availability is appropriate and consistent with SP 800-60 defaults.

Practitioner Note: SP 800-60 default values may be adjusted up or down based
on specific agency mission context. Adjustments must be documented and approved
by the Authorizing Official (AO). In this case, no adjustments from the SP
800-60 defaults are warranted — the defaults match the mission risk analysis.

================================================================================
STEP 5 — RMF INTEGRATION PATH
================================================================================

This categorization decision feeds directly into the NIST Risk Management
Framework (RMF), SP 800-37 Rev 2:

RMF Step 1 — Prepare:
  Assign ISSO, System Owner, Authorizing Official. Establish privacy roles
  (SAOP, Privacy Officer). Define system boundary to include all components
  storing or processing HR data.

RMF Step 2 — Categorize:
  Document FIPS 199 categorization in the System Categorization document.
  Categorization = {(C, MODERATE), (I, MODERATE), (A, MODERATE)}.
  Overall: MODERATE.

RMF Step 3 — Select:
  Select SP 800-53B Moderate baseline. Apply PT family privacy overlay.
  Identify common controls inherited from the data center/agency infrastructure
  (PE, MA, CP controls may be partially or fully inheritable). Document in SSP.

RMF Step 4 — Implement:
  Implement Moderate baseline controls. Prioritize: AC (access control),
  IA (MFA), SC-8/SC-28 (encryption), AU (audit logging), PT (privacy),
  AC-6 (least privilege).

RMF Step 5 — Assess:
  Independent security assessment using SP 800-53A Rev 5 procedures.
  Include Privacy Impact Assessment review.

RMF Step 6 — Authorize:
  Authorizing Official issues ATO based on residual risk. Complete PIA and
  SORN publication prior to ATO.

RMF Step 7 — Monitor:
  Implement continuous monitoring strategy per CA-7. Conduct annual control
  assessments. Manage POA&M items for any control deficiencies found.

================================================================================
SUMMARY AND RECOMMENDED NEXT STEPS
================================================================================

FIPS 199 Categorization:  MODERATE
SP 800-53B Baseline:       MODERATE (~323 controls/enhancements)
Privacy Overlay:           PT family (PT-1 through PT-8) — MANDATORY
SP 800-60 Types:           C.3.1.1 (Personnel Records), C.3.1.2 (Payroll)

Immediate Action Items:
  1. Complete SP 800-60 information type mapping and document in System
     Categorization document for AO approval.
  2. Initiate Privacy Impact Assessment (PIA) per E-Government Act Section 208.
  3. Publish or update System of Records Notice (SORN) in Federal Register.
  4. Begin SSP development with Moderate baseline control selection and PT
     family overlay.
  5. Identify common controls inheritable from the data center (facility PE
     controls, network infrastructure SC controls).
  6. Implement MFA (IA-2(1), IA-2(2)) and encryption at rest (SC-28(1)) and
     in transit (SC-8(1)) as highest-priority controls given PII sensitivity.
  7. Establish audit logging (AU-2, AU-3, AU-11) prior to system go-live.
  8. Conduct background investigations (PS-3) for all HR system privileged users.

Key References:
  - FIPS 199 (February 2004)
  - FIPS 200 (March 2006)
  - NIST SP 800-53 Rev 5 (September 2020)
  - NIST SP 800-53B (October 2020)
  - NIST SP 800-60 Volumes I and II (August 2008)
  - NIST SP 800-37 Rev 2 (December 2018)
  - Privacy Act of 1974 (5 U.S.C. § 552a)
  - OMB Circular A-130 (July 2016)
  - E-Government Act of 2002, Section 208

================================================================================
END OF RESPONSE
================================================================================

FIPS 199 CATEGORIZATION AND NIST SP 800-53 BASELINE SELECTION
Federal HR System — PII, Salary Data, and Performance Reviews (5,000 Staff)

==============================================================================
OVERVIEW
==============================================================================

This analysis walks through the FIPS 199 security categorization process for
a federal HR system storing employee PII, salary data, and performance reviews,
and then maps that categorization to the appropriate NIST SP 800-53 baseline.

==============================================================================
STEP 1: FIPS 199 SECURITY CATEGORIZATION
==============================================================================

FIPS 199 ("Standards for Security Categorization of Federal Information and
Information Systems") requires agencies to assess the potential impact of a
security breach across three security objectives:

  - Confidentiality: Preserving authorized restrictions on access and disclosure
  - Integrity: Guarding against improper modification or destruction
  - Availability: Ensuring timely and reliable access to information

For each objective, the potential impact is rated LOW, MODERATE, or HIGH.
The overall system categorization is determined by the "high-water mark" —
the highest impact level across all three objectives.

------------------------------------------------------------------------------
Information Types in Scope
------------------------------------------------------------------------------

This HR system contains the following information types (aligned to NIST SP
800-60, Volume II, "Guide for Mapping Types of Information and Information
Systems to Security Categories"):

  1. Personally Identifiable Information (PII) — employee records
     NIST 800-60 Type: C.3.1.1 — General Information (PII)

  2. Salary / Compensation Data — financial HR records
     NIST 800-60 Type: C.3.5.1 — Compensation Management (Pay and Benefits)

  3. Performance Reviews — employee appraisal records
     NIST 800-60 Type: C.3.1.2 — Human Resources Management (Performance)

------------------------------------------------------------------------------
Impact Analysis by Security Objective
------------------------------------------------------------------------------

CONFIDENTIALITY
  - Employee PII (names, SSNs, home addresses, dates of birth, etc.) is
    sensitive personal data protected under the Privacy Act of 1974. Unauthorized
    disclosure could harm 5,000 individuals through identity theft, financial
    harm, or reputational damage.
  - Salary data is sensitive and its exposure could cause significant
    embarrassment, workplace conflict, and individual financial harm.
  - Performance reviews contain evaluative judgments that could harm careers
    or violate privacy expectations if disclosed.
  - Impact Rating: MODERATE to HIGH. A breach affecting 5,000 federal employees
    involving SSNs and financial data would cause serious adverse effects.
    Most agencies categorize this type of system at MODERATE for confidentiality
    as the standard baseline, though agencies with a large workforce or highly
    sensitive positions may elect HIGH.
  - Recommended Rating: MODERATE (with consideration for HIGH if the workforce
    includes sensitive national security positions or the agency's risk
    tolerance requires it)

INTEGRITY
  - Corruption or unauthorized modification of salary data could result in
    improper payments, payroll fraud, or denial of correct compensation —
    causing direct financial harm to employees and the agency.
  - Modification of performance records could impair promotion decisions,
    disciplinary actions, or workforce management functions.
  - PII corruption could cause incorrect benefits enrollment or identity errors.
  - Impact Rating: MODERATE. Integrity failures would cause serious adverse
    effects on agency mission and individual employee welfare, but are unlikely
    to be catastrophic or irreversible in most scenarios.
  - Recommended Rating: MODERATE

AVAILABILITY
  - An HR system supporting 5,000 staff must be available for payroll
    processing cycles, benefits enrollment windows, and onboarding/offboarding
    workflows. Extended outages could disrupt pay, benefits, and HR operations.
  - However, the system does not typically support life-safety or real-time
    mission-critical operations (e.g., emergency response).
  - Impact Rating: MODERATE. Temporary unavailability would cause significant
    disruption but is unlikely to result in catastrophic harm.
  - Recommended Rating: MODERATE

------------------------------------------------------------------------------
Security Categorization Result
------------------------------------------------------------------------------

Applying the high-water mark principle per FIPS 199:

  SC HR_System = {(Confidentiality, MODERATE), (Integrity, MODERATE),
                  (Availability, MODERATE)}

  OVERALL SYSTEM CATEGORIZATION: MODERATE

This is expressed in FIPS 199 notation as:

  SC HR_System = {(confidentiality, MODERATE), (integrity, MODERATE),
                  (availability, MODERATE)} = MODERATE

NOTE: If the agency determines that the confidentiality impact should be HIGH
(e.g., due to inclusion of law enforcement personnel records, SCI-cleared staff
data, or whistleblower information), the overall categorization would become
HIGH, and a different baseline would apply. Agencies should document their
rationale in the System Security Plan (SSP).

==============================================================================
STEP 2: NIST SP 800-53 BASELINE SELECTION
==============================================================================

NIST SP 800-53 Rev. 5 ("Security and Privacy Controls for Information Systems
and Organizations") provides three control baselines tied directly to the FIPS
199 categorization:

  - LOW Baseline:      For systems categorized as LOW overall
  - MODERATE Baseline: For systems categorized as MODERATE overall
  - HIGH Baseline:     For systems categorized as HIGH overall

Based on the MODERATE overall categorization above:

  SELECTED BASELINE: MODERATE

The NIST SP 800-53 Rev. 5 MODERATE baseline includes approximately 323 control
requirements (base controls plus required enhancements) across 20 control
families. Key control families particularly relevant to this HR system include:

  AC  — Access Control
        Enforce least-privilege access; role-based access control for HR
        personnel, managers, and system administrators. Restrict access to PII
        to only authorized users.

  AT  — Awareness and Training
        Security awareness training for all users handling PII and salary data.

  AU  — Audit and Accountability
        Log and review access to PII, salary records, and performance data.
        Audit logs must be protected against tampering.

  CA  — Assessment, Authorization, and Monitoring
        Conduct security assessments; obtain Authority to Operate (ATO) from
        the Authorizing Official (AO); continuous monitoring program.

  CM  — Configuration Management
        Maintain baselines for the HR application, database, and server
        configurations.

  CP  — Contingency Planning
        Backup and recovery procedures for PII and HR data; test recovery
        capabilities; define Recovery Time Objective (RTO) and Recovery Point
        Objective (RPO).

  IA  — Identification and Authentication
        Multi-factor authentication (MFA) for all privileged users and remote
        access; strong password policies; PIV/CAC authentication where required
        by HSPD-12.

  IR  — Incident Response
        Documented incident response plan that specifically addresses PII
        breaches, including OMB Memorandum M-17-12 breach notification
        requirements (report to US-CERT within 1 hour of discovery).

  MP  — Media Protection
        Protect and sanitize removable media; encrypt data at rest on storage
        media containing PII.

  PE  — Physical and Environmental Protection
        Physical access controls to the internal data center; visitor controls;
        environmental safeguards (fire, flood, HVAC).

  PL  — Planning
        System Security Plan (SSP) documenting the security architecture,
        control implementation, and interconnections.

  PS  — Personnel Security
        Screening of individuals with access to PII; rules of behavior; access
        termination procedures for separated employees.

  PT  — PII Processing and Transparency (Privacy Controls — Rev. 5 addition)
        Privacy controls specifically addressing lawful collection, use, and
        retention of PII; Privacy Act System of Records Notice (SORN); Privacy
        Impact Assessment (PIA) required per E-Government Act of 2002.

  RA  — Risk Assessment
        System-level risk assessment; vulnerability scanning; supply chain
        risk management.

  SA  — System and Services Acquisition
        Secure development practices; security requirements in acquisition
        contracts; software assurance.

  SC  — System and Communications Protection
        Encryption of PII and salary data in transit (TLS 1.2+); network
        segmentation; boundary protection.

  SI  — System and Information Integrity
        Malware protection; security alerts; flaw remediation; spam protection.

==============================================================================
STEP 3: ADDITIONAL COMPLIANCE OBLIGATIONS
==============================================================================

Beyond the NIST SP 800-53 MODERATE baseline, this system triggers several
additional federal requirements:

  1. PRIVACY ACT OF 1974
     The system constitutes a "System of Records" under the Privacy Act because
     it retrieves employee information by personal identifier. The agency must:
     - Publish a System of Records Notice (SORN) in the Federal Register
     - Establish a routine uses schedule
     - Respond to Privacy Act requests

  2. PRIVACY IMPACT ASSESSMENT (PIA)
     Required under Section 208 of the E-Government Act of 2002. Must be
     completed before deployment and updated when the system changes
     significantly.

  3. OMB CIRCULAR A-130 (Managing Information as a Strategic Resource)
     Requires senior agency official for privacy (SAOP) involvement, privacy
     continuous monitoring, and privacy risk management.

  4. FISMA (Federal Information Security Modernization Act of 2014)
     Requires an Authority to Operate (ATO) from the Authorizing Official.
     The ATO package must include: SSP, Security Assessment Report (SAR),
     Plan of Action and Milestones (POA&M).

  5. OMB M-17-12 (Preparing for and Responding to a Breach of PII)
     Establishes breach response requirements including US-CERT notification
     within 1 hour and affected-individual notification timelines.

  6. HSPD-12 / PIV
     Federal employees must authenticate using Personal Identity Verification
     (PIV) cards for logical access to federal systems where technically
     feasible.

  7. NIST SP 800-122 (Guide to Protecting the Confidentiality of PII)
     Provides supplemental guidance specific to PII protection, including
     de-identification and minimization techniques.

==============================================================================
STEP 4: RECOMMENDED IMPLEMENTATION APPROACH
==============================================================================

  1. Conduct a formal FIPS 199 categorization workshop with the system owner,
     information owner, and ISSO — document all information types and impact
     ratings in the SSP.

  2. Register the system in the agency's GRC tool (e.g., CSAM, Xacta, or
     similar) under the MODERATE baseline.

  3. Tailor the MODERATE baseline as needed:
     - Apply organization-defined parameters (ODPs) per agency policy
     - Add compensating controls where required
     - Scoping guidance: exclude controls not applicable to the internal
       data center hosting model (e.g., some cloud-specific controls)

  4. Complete the Privacy Impact Assessment and submit the SORN for
     Federal Register publication prior to system go-live.

  5. Conduct security assessment (typically by an independent assessor or
     the agency's A&A team) against the tailored MODERATE baseline.

  6. Obtain ATO from the Authorizing Official before processing live PII.

  7. Establish a continuous monitoring strategy per NIST SP 800-137 aligned
     to the MODERATE categorization.

==============================================================================
SUMMARY
==============================================================================

  FIPS 199 Categorization:  MODERATE
                             {(Confidentiality, MODERATE),
                              (Integrity, MODERATE),
                              (Availability, MODERATE)}

  NIST SP 800-53 Baseline:  MODERATE (~323 controls and enhancements)

  Key Additional Frameworks: Privacy Act SORN, PIA (E-Gov Act), FISMA ATO,
                              OMB M-17-12, HSPD-12/PIV, NIST SP 800-122

  Hosting Consideration:    Internal data center hosting is fully compatible
                             with the MODERATE baseline. The agency retains
                             full control over physical and environmental
                             controls (PE family) and does not need to apply
                             FedRAMP authorization processes applicable to
                             cloud service providers.

==============================================================================

================================================================================
EXPERT NIST SP 800-53 REV 5 RESPONSE
FINDING: AC-2(3) — Other Than Satisfied (OTS)
Federal System Security Plan (SSP) — Inactive Account Remediation and POA&M Guidance
================================================================================
Date: 2026-05-07
Control: AC-2(3) | Baseline: Moderate and High | Family: Access Control (AC)
================================================================================


PART 1: AC-2(3) CONTROL DESCRIPTION AND REGULATORY CONTEXT
------------------------------------------------------------

Control: AC-2(3) — Account Management | Disable Accounts

Control Statement (NIST SP 800-53 Rev 5):
  "Disable accounts within [Assignment: organization-defined time period] when
  the accounts: (a) Have expired; (b) Are no longer associated with a user or
  individual; (c) Are in violation of organizational policy; or (d) Have been
  inactive for [Assignment: organization-defined time period]."

Baseline Assignment:
  - Low:      NOT required
  - Moderate: REQUIRED
  - High:     REQUIRED

Your ODV (Organization-Defined Value): 90 days of inactivity triggers mandatory
account disablement.

Why This Control Matters:
AC-2(3) is a foundational access control requirement because dormant accounts
represent one of the highest-probability attack vectors for credential-based
intrusions. Inactive accounts:
  - Are rarely monitored for anomalous logon attempts
  - May retain stale but valid credentials (unchanged passwords)
  - Provide unauthorized access if credentials are compromised
  - Violate the principle of least privilege (AC-6) by maintaining access for
    users who no longer require it
  - Can be exploited in lateral movement during a breach

The assessor's finding — 120 accounts inactive for over 120 days against your
stated ODV of 90 days — is a clear, objective, and documented OTS finding.
The violation exceeds your ODV by 30+ days and affects a significant population
(120 accounts), which elevates the risk severity.

Related Controls You Must Also Review:
  - AC-2 (base): Account management lifecycle — creation, review, modification,
    removal
  - AC-2(1): Automated system account management (Moderate/High)
  - AC-2(5): Inactivity logout (session-level; separate from AC-2(3))
  - AC-5: Separation of duties — verify disabled account holders had no
    conflicting privilege concentrations
  - IA-4: Identifier management — identifiers for inactive accounts must also
    be managed
  - CA-7: Continuous monitoring — your ConMon process should have caught this
  - CA-5: POA&M — document this finding immediately


================================================================================
PART 2: IMMEDIATE REMEDIATION STEPS
================================================================================

The remediation process has two parallel tracks: immediate operational
remediation (fix the condition now) and process remediation (fix why it
happened and prevent recurrence).

--- TRACK A: IMMEDIATE OPERATIONAL REMEDIATION (Days 1-7) ---

Step 1: Account Inventory and Validation (Day 1-2)
  - Pull a complete report of all 120 flagged accounts from your identity
    management system or Active Directory (or equivalent directory service).
  - For each of the 120 accounts, validate:
      a) Last logon timestamp (confirm inactivity period)
      b) Account type (user, service, privileged, shared, or system account)
      c) Current account status (enabled/disabled)
      d) Associated individual or function (is the account orphaned?)
      e) Group memberships and privilege level
  - Segregate the 120 accounts into sub-categories:
      - Standard user accounts inactive > 90 days
      - Privileged accounts inactive > 90 days (PRIORITY — disable FIRST)
      - Service accounts (do NOT disable without application impact analysis;
        coordinate with application owners)
      - Accounts for separated employees (disable immediately; may require
        coordination with HR and PS-4 controls)

Step 2: Prioritized Disablement (Day 2-5)
  - PRIORITY 1 (Day 2): Disable all privileged/admin accounts in the inactive
    set first. Privileged account compromise has the highest blast radius.
  - PRIORITY 2 (Day 3-4): Disable all standard user accounts confirmed inactive
    for > 90 days.
  - PRIORITY 3 (Day 4-5): For each service account, perform application impact
    analysis. Coordinate with system/application owners before disabling. If
    a service account is genuinely inactive (no application dependency), disable
    it. If active dependency exists, document the exception and escalate.
  - Document every account disabled, including: account name, account type,
    last logon date, disabled-by, disabled-on timestamp, and ticket/work order
    reference.

Step 3: Notification Protocol (Day 1-3, concurrent)
  - Notify account holders' managers (or HR for separated personnel) before
    disabling, where operationally feasible and where the delay does not extend
    the violation window beyond an acceptable period.
  - For accounts of active employees that are simply unused, give a documented
    24-48 hour notice before disablement per your access control policy.
  - For accounts of separated personnel, disable immediately and notify the
    responsible manager.

Step 4: Exception Handling (Day 3-5)
  - Any account that cannot be immediately disabled (e.g., undocumented service
    accounts with unresolved dependencies) must be:
      a) Logged as an outstanding exception in the POA&M milestone tracker
      b) Assigned an owner responsible for resolving the dependency
      c) Given a hard deadline (suggest 30 days maximum for service account
         resolution) with written approval from the ISSO and System Owner
  - Do NOT simply carry exceptions forward without documentation — each one
    must have an owner and a date.

--- TRACK B: ROOT CAUSE AND PROCESS REMEDIATION (Days 7-60) ---

Step 5: Root Cause Analysis (Day 7-14)
  Determine WHY 120 accounts were not disabled within the 90-day ODV. Common
  root causes include:
    a) Automated account review process was not configured, broke, or was
       disabled
    b) Reports were generated but not acted upon (process failure, not technical)
    c) Account review responsibility was unclear (no defined owner)
    d) Service desk or IT operations lacked an enforced workflow to disable
       flagged accounts
    e) The ODV was documented in the SSP but never operationalized in the
       directory service or IAM tool
    f) Exceptions were granted informally without documentation
  Document the root cause in the POA&M milestone record.

Step 6: Automated Controls Implementation (Day 14-45)
  Implement or repair the automated account management capability required by
  AC-2(1) (which is also a Moderate/High baseline requirement and may itself
  be OTS if automation was absent):
    - Configure Active Directory (or your IAM/IDM platform) to automatically
      flag accounts reaching 75 days of inactivity (15-day warning ahead of
      90-day threshold)
    - Configure automatic disablement at 90 days of inactivity
    - Establish automated notifications to account managers at 60 days and
      75 days
    - Test the automated process end-to-end in a non-production environment
      before deploying to production
    - Document the configuration settings as evidence for future assessments

Step 7: Policy and Procedure Update (Day 14-30)
  - Review and update the Access Control Policy (required by AC-1) to explicitly
    state the 90-day ODV and the automated enforcement mechanism
  - Update the Account Management Procedure to define:
      - Roles responsible for account review and disablement
      - Escalation path for accounts that cannot be automatically disabled
      - Quarterly manual review requirement as a backup to automation
      - Service account exception handling process
  - Ensure procedures reference the specific system and directory service
    configuration, not generic language

Step 8: Training and Awareness (Day 30-60)
  - Brief IT operations and help desk staff on the revised account management
    procedures
  - Document training completion records (supports AT-3)

Step 9: Verification and Evidence Collection (Day 45-60)
  - Run a post-remediation account report showing zero accounts inactive > 90
    days
  - Capture screenshots or exported reports from the directory service
    demonstrating the automated disablement configuration
  - Request a spot-check or mini-assessment from your ISSO or an independent
    reviewer to confirm the control is now Satisfied
  - Retain all remediation evidence in your compliance artifact repository


================================================================================
PART 3: POA&M DOCUMENTATION — REQUIRED FIELDS AND GUIDANCE
================================================================================

The POA&M is mandated by CA-5 (Plan of Action and Milestones) and is a required
component of your authorization package. The following provides the complete
field-by-field guidance for documenting this specific finding.

--- POA&M ENTRY: COMPLETED TEMPLATE ---

+---------------------------+---------------------------------------------------+
| FIELD                     | VALUE / GUIDANCE                                  |
+---------------------------+---------------------------------------------------+
| POA&M Item ID             | [Assign sequential ID, e.g., POA&M-2026-042]      |
|                           | Must be unique and traceable to the SAR finding   |
+---------------------------+---------------------------------------------------+
| Weakness / Deficiency     | AC-2(3) — Inactive accounts are not being         |
|                           | disabled within the organization-defined value     |
|                           | (ODV) of 90 days of inactivity. Security          |
|                           | assessment identified 120 user accounts with       |
|                           | last logon dates exceeding 120 days, in violation |
|                           | of the documented ODV and SP 800-53 Rev 5          |
|                           | control AC-2(3).                                  |
+---------------------------+---------------------------------------------------+
| Source of Discovery       | Security Assessment / Third-Party Assessment       |
|                           | (SCA/3PAO) — [Assessment date] — SAR Finding      |
|                           | Reference: [SAR-Finding-ID]                       |
+---------------------------+---------------------------------------------------+
| Control Identifier        | AC-2(3) — Account Management: Disable Accounts    |
|                           | NIST SP 800-53 Rev 5                              |
+---------------------------+---------------------------------------------------+
| Risk Level                | MODERATE                                          |
|                           |                                                   |
|                           | Rationale: Dormant accounts with valid credentials|
|                           | present an attack surface for credential-based    |
|                           | intrusion and lateral movement. The 120 affected  |
|                           | accounts exceed the ODV by 30+ days. Risk is      |
|                           | elevated if any accounts belong to privileged     |
|                           | users; re-evaluate as HIGH if privileged accounts |
|                           | are confirmed in the inactive set.                |
+---------------------------+---------------------------------------------------+
| Scheduled Completion Date | [Insert date: recommend 60 days from SAR          |
|                           | issuance for full remediation, consistent with    |
|                           | Moderate risk timeline guidance]                  |
|                           |                                                   |
|                           | Note: FedRAMP POA&M guidance requires Moderate    |
|                           | findings to be remediated within 180 days;        |
|                           | FISMA/agency policy may impose tighter deadlines. |
|                           | Recommend 60 days given the straightforward       |
|                           | technical remediation path.                       |
+---------------------------+---------------------------------------------------+
| Responsible Parties       | Primary: ISSO (Information System Security        |
|                           | Officer) — [Name / Title]                        |
|                           |                                                   |
|                           | Secondary: System Owner (SO) — [Name / Title]    |
|                           |                                                   |
|                           | Supporting: IT Operations / Identity Management   |
|                           | Team — [Team name or lead name]                  |
|                           |                                                   |
|                           | Approving: Authorizing Official (AO) or AODR     |
|                           | must be informed; AO signature required if risk   |
|                           | acceptance is invoked for any sub-items           |
+---------------------------+---------------------------------------------------+
| Resources Required        | - IT Operations staff time: ~40-80 hours          |
|                           |   (account analysis, disablement, testing)        |
|                           | - IAM/Directory service admin access              |
|                           | - AD or IDM platform configuration capability     |
|                           | - Policy/procedure update: ISSO ~8 hours          |
|                           | - No significant new budget anticipated           |
|                           |   (remediation uses existing tooling)             |
+---------------------------+---------------------------------------------------+
| Status                    | OPEN [at time of entry]                           |
|                           | Update monthly per ConMon requirements            |
+---------------------------+---------------------------------------------------+

--- MILESTONE SCHEDULE (REQUIRED — Document Each Step with Dates) ---

Milestone 1 — Account Inventory and Triage
  Description: Generate complete report of all 120 inactive accounts. Categorize
               by account type (standard, privileged, service). Identify
               separated employees and orphaned accounts.
  Owner: IT Operations Lead / ISSO
  Target Date: [Day 2 from SAR receipt]
  Evidence: Account inventory spreadsheet with last logon dates, account types,
            and owner identification

Milestone 2 — Privileged Account Disablement
  Description: Disable all privileged/admin accounts in the inactive set.
               Verify disablement via directory query.
  Owner: IT Operations Lead
  Target Date: [Day 3 from SAR receipt]
  Evidence: Screenshot/export from AD or IDM showing disabled status; change
            management ticket reference

Milestone 3 — Standard User Account Disablement
  Description: Disable all standard user accounts inactive > 90 days (excluding
               service accounts pending dependency analysis).
  Owner: IT Operations Lead
  Target Date: [Day 5 from SAR receipt]
  Evidence: Account status report; notification records sent to managers

Milestone 4 — Service Account Dependency Analysis
  Description: Complete application impact analysis for all service accounts in
               the inactive set. Disable those with no active dependency.
               Document exceptions for accounts with unresolved dependencies.
  Owner: Application Owners / IT Operations
  Target Date: [Day 10 from SAR receipt]
  Evidence: Dependency analysis document; exception log with owner assignments

Milestone 5 — Root Cause Analysis Completion
  Description: Document the root cause of the control failure (automation gap,
               process failure, responsibility gap, etc.). Present findings to
               ISSO and System Owner.
  Owner: ISSO
  Target Date: [Day 14 from SAR receipt]
  Evidence: Root Cause Analysis memo signed by ISSO and System Owner

Milestone 6 — Automated Account Review/Disablement Configuration
  Description: Implement or repair automated account inactivity monitoring and
               disablement at the 90-day threshold. Configure warning
               notifications at 60 and 75 days. Test in non-production
               environment before production deployment.
  Owner: IT Operations / IAM Team
  Target Date: [Day 45 from SAR receipt]
  Evidence: Configuration documentation; test results; change management record

Milestone 7 — Policy and Procedure Update
  Description: Update Access Control Policy (AC-1) and Account Management
               Procedure to reflect the 90-day ODV, automated controls, roles
               and responsibilities, and exception handling process.
  Owner: ISSO
  Target Date: [Day 30 from SAR receipt]
  Evidence: Revised policy and procedure documents with version numbers and
            approval signatures

Milestone 8 — Post-Remediation Verification
  Description: Run account activity report demonstrating zero accounts inactive
               > 90 days. ISSO conducts internal spot-check. Retain evidence.
  Owner: ISSO
  Target Date: [Day 55 from SAR receipt]
  Evidence: Post-remediation account report (exported); ISSO verification memo

Milestone 9 — POA&M Closure and ISSO/SO Sign-Off
  Description: ISSO and System Owner review all milestone evidence. Complete
               POA&M closure documentation. Notify AO/AODR of remediation
               completion and submit updated POA&M.
  Owner: ISSO and System Owner
  Target Date: [Day 60 from SAR receipt — Scheduled Completion Date]
  Evidence: Signed POA&M closure memo; updated SSP implementation narrative
            for AC-2(3); evidence package submitted to AO


================================================================================
PART 4: ISSO AND SYSTEM OWNER SIGN-OFF REQUIREMENTS
================================================================================

Federal policy and SP 800-37 Rev 2 establish clear accountability requirements
for POA&M management. The following sign-offs are required:

1. ISSO Responsibilities and Sign-Off:
   - The ISSO is the day-to-day security point of accountability for this
     finding. The ISSO must:
       a) Review and validate the initial finding against the SAR
       b) Approve the POA&M entry before it is submitted to the AO
       c) Verify each milestone is completed and evidence is adequate
       d) Sign the POA&M closure memo when all milestones are complete
       e) Update the SSP AC-2(3) implementation narrative to reflect the
          remediated and now-operational control
       f) Certify the accuracy of the POA&M in monthly ConMon reports
   - ISSO signature is required on:
       - Initial POA&M entry (at submission)
       - Each monthly status update if milestones shift
       - Final POA&M closure memo

2. System Owner (SO) Responsibilities and Sign-Off:
   - The System Owner has ultimate accountability for the system's security
     posture and must:
       a) Acknowledge the finding and concur with the remediation plan
       b) Authorize the resource allocation (staff time, tooling changes)
       c) Accept any residual risk during the remediation window
       d) Co-sign the POA&M closure memo
       e) Ensure the updated Account Management Procedure is formally approved
   - SO signature is required on:
       - Initial POA&M entry concurrence
       - Root Cause Analysis memo
       - POA&M closure memo
       - Updated Access Control Policy (AC-1) if revised

3. Authorizing Official (AO) / AODR Notification:
   - The AO must be notified of the OTS finding and the POA&M entry.
   - If any accounts in the 120-account set are privileged accounts, the AO
     should be explicitly briefed given the elevated risk to the authorization
     boundary.
   - AO signature is NOT required for routine Moderate-risk POA&M entries
     UNLESS: (a) risk acceptance is invoked, (b) the finding affects a critical
     or high-impact component, or (c) agency policy requires AO concurrence.
   - If remediation cannot be completed within the scheduled completion date,
     a formal risk acceptance memorandum requiring AO signature must be
     prepared and executed.

4. Risk Acceptance (if needed):
   If any sub-item (e.g., service accounts with unresolved dependencies) cannot
   be remediated within the standard timeline, a Risk Acceptance must be
   documented separately, including:
     - Specific accounts or account types accepted under the risk acceptance
     - Business justification for the delay
     - Compensating controls in place during the acceptance period
     - Expiration date of the risk acceptance
     - ISSO signature, System Owner signature, and AO signature
   Risk acceptance is NOT a permanent closure of the POA&M item — the item
   remains open and must be reviewed at each ConMon cycle.


================================================================================
PART 5: SSP UPDATE REQUIREMENTS
================================================================================

Once remediation is complete, update the SSP implementation narrative for
AC-2(3) from "Partially Implemented" (or "Planned") to "Implemented" with the
following narrative components:

Control: AC-2(3) — Account Management: Disable Accounts
Implementation Status: Implemented

Implementation Description:
  [System Name] disables user accounts that have been inactive for 90 days or
  more, consistent with the organization-defined value (ODV) documented in the
  Access Control Policy [Policy Name, Version X.X, dated YYYY-MM-DD]. Account
  inactivity is monitored automatically through [tool name, e.g., Active
  Directory / identity management platform]. The system is configured to:
    (1) Send automated notification to the account owner's manager at 60 days
        and 75 days of inactivity;
    (2) Automatically disable the account at 90 days of inactivity.
  Service accounts are reviewed quarterly by [role] to verify continued
  business need. Accounts associated with separated personnel are disabled
  within [X] hours of HR notification per the account termination procedure
  [Procedure Name, Version X.X]. Account disablement is logged and retained
  in [audit log system] for [retention period] per AU-11. The ISSO conducts
  a quarterly review of the account activity report to verify compliance with
  the 90-day ODV.

Responsible Roles:
  - ISSO: Quarterly compliance review; POA&M management
  - IT Operations / IAM Team: Automated system configuration; disablement
    execution
  - System Owner: Policy approval; resource authorization

Evidence / Artifacts:
  - Access Control Policy [version and date]
  - Account Management Procedure [version and date]
  - Directory service / IAM configuration screenshot showing 90-day threshold
  - Quarterly account activity report (most recent)
  - ISSO quarterly review memo


================================================================================
PART 6: CONTINUOUS MONITORING (ConMon) — PREVENTING RECURRENCE
================================================================================

To prevent this finding from recurring at the next assessment cycle:

1. Monthly ConMon Check: Include an account inactivity report in your monthly
   ConMon package. Run a query for accounts approaching 75 days and accounts
   at 90+ days. Review results with IT Operations and document actions taken.

2. Automated Alerting: Configure alerts (via SIEM or IAM platform) when any
   account exceeds 85 days of inactivity — providing a 5-day buffer to take
   manual action before the ODV is breached.

3. Quarterly Manual Review: Supplement automation with a quarterly manual
   account review (tie to CA-7 continuous monitoring tasks) that specifically
   covers:
     - Service accounts
     - Shared accounts
     - Privileged accounts
     - Any accounts excluded from automated review

4. Annual Control Assessment: Include AC-2(3) as a prioritized control in your
   annual assessment (or ConMon-based ongoing assessment) to validate that the
   automated process continues to function correctly.

5. POA&M Monthly Updates: Until this POA&M item is formally closed, provide
   milestone progress updates monthly. Include accounts remaining to be
   disabled, milestones completed, and any new exceptions identified.


================================================================================
PART 7: SUMMARY CHECKLIST — ACTIONS AND DELIVERABLES
================================================================================

IMMEDIATE (Days 1-7):
  [ ] Generate complete inventory of 120 inactive accounts
  [ ] Disable privileged accounts first
  [ ] Disable standard user accounts inactive > 90 days
  [ ] Initiate service account dependency analysis
  [ ] Open POA&M entry with all required fields populated
  [ ] Notify ISSO, System Owner, and AO of the finding and remediation plan

SHORT-TERM (Days 7-30):
  [ ] Complete root cause analysis
  [ ] Update Access Control Policy and Account Management Procedure
  [ ] Assign milestone owners and dates in POA&M
  [ ] Resolve service account exceptions or escalate to formal risk acceptance
  [ ] ISSO and System Owner sign initial POA&M entry

MEDIUM-TERM (Days 30-60):
  [ ] Implement/repair automated account disablement at 90-day threshold
  [ ] Test automation in non-production; deploy to production
  [ ] Complete post-remediation verification report
  [ ] Update SSP AC-2(3) narrative to "Implemented"
  [ ] ISSO and System Owner sign POA&M closure memo
  [ ] Submit updated POA&M and SSP to AO/AODR

ONGOING:
  [ ] Monthly account inactivity ConMon report
  [ ] Quarterly manual account review
  [ ] Annual control assessment of AC-2(3)
  [ ] Monthly POA&M status updates until closure


================================================================================
REFERENCES
================================================================================
  - NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems
    and Organizations — AC-2(3) (September 2020)
  - NIST SP 800-53A Rev 5: Assessing Security and Privacy Controls in
    Information Systems and Organizations (January 2022)
  - NIST SP 800-53B: Control Baselines for Information Systems and Organizations
    (October 2020) — Moderate and High baseline, AC-2(3)
  - NIST SP 800-37 Rev 2: Risk Management Framework for Information Systems
    and Organizations (December 2018) — RMF Steps 5, 6, 7; POA&M management
  - OMB Circular A-130: Managing Information as a Strategic Resource (2016) —
    POA&M and ATO requirements
  - CISA Federal Continuous Diagnostics and Mitigation (CDM) Program —
    Account Management/Identity management capabilities
  - FedRAMP POA&M Template and Guidance (if applicable to your authorization)

================================================================================
END OF RESPONSE
================================================================================

NIST SP 800-53 AC-2(3) Remediation Guidance and POA&M Documentation
Finding: AC-2(3) - Account Management | Disable Inactive Accounts
Status: Other Than Satisfied (OTS)
Finding Detail: 120 accounts inactive for 120+ days; ODV (Organization-Defined Value) for disabling is 90 days

================================================================================
SECTION 1: UNDERSTANDING THE CONTROL
================================================================================

AC-2(3) - ACCOUNT MANAGEMENT | DISABLE INACTIVE ACCOUNTS
Control Text: "Disable accounts within [Assignment: organization-defined time period] when accounts: (a) Have expired; (b) Are no longer associated with a user or individual; (c) Are in violation of organizational policy; or (d) Have been inactive for [Assignment: organization-defined time period]."

Your SSP states an ODV of 90 days for the inactivity threshold. The assessor identified 120 accounts that have been inactive for 120+ days — a 30+ day gap beyond your stated threshold. This is a clear, measurable control deficiency and must be remediated and tracked as a formal POA&M item.

================================================================================
SECTION 2: IMMEDIATE REMEDIATION STEPS
================================================================================

PHASE 1: EMERGENCY REMEDIATION (Within 30 days — POA&M Milestone 1)

Step 1 — Pull the Full Inactive Account Inventory
- Generate a report from your Identity and Access Management (IAM) system, Active Directory (AD), LDAP, or applicable user provisioning system.
- Export all accounts with last login date, account type (user, service, privileged, shared), owning system, and associated role/privilege level.
- Cross-reference with HR records and access request logs to identify accounts that may belong to separated personnel, contractors who have completed engagements, or temporary accounts that were never closed.

Step 2 — Triage and Categorize the 120 Accounts
Before bulk-disabling, categorize accounts into:
  a) Confirmed orphan accounts — users who have left the organization; disable immediately.
  b) Service/system accounts — do NOT disable without coordination with system owners; may break automated processes.
  c) Accounts belonging to active users who have not logged in — verify with supervisors/system owners before disabling.
  d) Emergency/break-glass accounts — these may legitimately be inactive; document exceptions with risk acceptance.

Step 3 — Disable Non-Exempt Accounts
- For all confirmed orphan and clearly inactive accounts: disable (not delete) accounts in the authoritative identity store.
- Retain account records for audit trail purposes — do not delete until proper off-boarding procedures confirm no data recovery needs.
- Use a standardized naming convention or flag in the IAM system to mark accounts as "Disabled - AC-2(3) Remediation [DATE]."
- Document each account actioned: username, system, date last active, date disabled, who authorized the action.

Step 4 — Notify System and Data Owners
- For accounts where ownership is unclear, send formal notification to supervisors/system owners requesting confirmation of account necessity within 5 business days.
- Document all responses. Accounts with no response after the deadline should be disabled pending further review.

PHASE 2: PROCESS REMEDIATION (Within 60 days — POA&M Milestone 2)

Step 5 — Implement Automated Controls
- Configure your IAM/AD environment to automatically disable accounts after 90 days of inactivity. This is achievable via:
  * Active Directory: Use "Maximum password age" in conjunction with PowerShell scripts or Group Policy; more precisely, implement scheduled scripts querying lastLogonTimestamp attribute against a 90-day threshold.
  * Cloud IAM (AWS IAM, Azure AD, GCP): Use built-in credential reports and lifecycle policies or third-party PAM tools.
  * SIEM/SOAR integration: Create automated alerts at 75 days (warning), 85 days (pre-disable notification), and 90 days (auto-disable action).
- Ensure service accounts are excluded from automatic disabling via a documented exception process with periodic review.

Step 6 — Update Account Management Procedures
- Revise the Account Management Policy and Standard Operating Procedure (SOP) to explicitly codify the 90-day inactivity ODV.
- Establish the process for:
  * Quarterly (at minimum) review of inactive accounts.
  * Automated notification to account owners at 60 days and 80 days of inactivity.
  * Formal exception process for service accounts, break-glass accounts, and emergency access accounts.
  * Off-boarding integration: HR termination triggers must feed directly into the IAM provisioning/de-provisioning workflow within 24 hours.

Step 7 — Privileged Account Focus
- Apply heightened scrutiny to inactive privileged accounts (system administrators, database administrators, network administrators). These represent the highest risk.
- Consider a shorter inactivity threshold (e.g., 45 days) for privileged accounts if not already documented, and update the SSP ODV accordingly.

PHASE 3: VERIFICATION AND EVIDENCE COLLECTION (Within 90 days — POA&M Milestone 3)

Step 8 — Conduct a Full Account Audit
- Run a follow-up report confirming all 120 identified accounts have been either disabled or formally excepted with documented justification.
- Verify that no new accounts have exceeded the 90-day threshold since remediation began.
- Retain all reports as evidence artifacts.

Step 9 — Update the SSP
- Ensure the System Security Plan accurately reflects the implemented automated controls, the 90-day ODV, and the exception management process.
- If your ODV has changed, update it in the SSP and obtain re-approval from the Authorizing Official (AO) or their designated representative.

================================================================================
SECTION 3: POA&M DOCUMENTATION REQUIREMENTS
================================================================================

Under NIST SP 800-53A and OMB Memorandum M-02-01 (as updated), findings assessed as "Other Than Satisfied" must be tracked in a formal Plan of Action and Milestones (POA&M). Below is the required documentation structure.

POA&M ENTRY — REQUIRED FIELDS AND RECOMMENDED CONTENT:

1. POA&M ID
   Assign a unique identifier per your organization's POA&M numbering scheme (e.g., POA&M-2026-AC-2(3)-001).

2. Control Identifier
   AC-2(3) — Account Management | Disable Inactive Accounts

3. Weakness / Vulnerability Description
   "The organization's information system does not automatically disable or enforce disabling of inactive user accounts within the organization-defined value (ODV) of 90 days. A security assessment identified 120 user accounts with no recorded logon activity for a period exceeding 120 days (30+ days beyond the stated ODV). The failure to enforce this control creates risk of unauthorized access through dormant credentials that may be compromised, forgotten, or associated with personnel no longer authorized to access the system."

4. Point of Contact (POC)
   Name and title of the system owner or ISSO responsible for remediation.

5. Resources Required
   - IAM administrator time (estimated: X hours for initial account audit and disablement)
   - Potential licensing for PAM/IAM tooling if automated enforcement is not available natively
   - System owner coordination time for service account review
   - Estimated cost: [populate per your resource model]

6. Scheduled Completion Date
   Provide a realistic date — typically 90 to 180 days for full remediation of process-level findings. Immediate disablement of the 120 accounts should be a near-term milestone (within 30 days).

7. Milestones with Completion Dates
   Milestone 1 (30 days): Complete triage and disable all 120 identified inactive accounts. Generate and retain evidence report. Deliverable: Account Disable Evidence Report.
   Milestone 2 (60 days): Implement automated inactivity enforcement controls. Update Account Management SOP and Policy. Deliverable: Updated SOP; screenshot/config export of automated rule.
   Milestone 3 (90 days): Conduct follow-up account audit confirming zero accounts exceed 90-day threshold. Update SSP AC-2(3) control implementation narrative. Deliverable: Clean account audit report; updated SSP section.
   Milestone 4 (180 days): Conduct first quarterly review under the new process to verify sustained compliance. Deliverable: Quarterly account review report.

8. Changes to Milestones
   Leave blank initially. Update with explanations if milestones are missed or adjusted, including new completion dates and justification.

9. Status
   Initial status: "Open — In Progress"
   Update as: "Open — Ongoing," then "Closed" only when all milestones are complete and the authorizing official concurs.

10. Identified Risk
    Risk Level: HIGH
    Rationale: Dormant accounts with valid credentials represent a significant attack surface. Compromised inactive accounts are commonly exploited in lateral movement and privilege escalation attacks. The 120 identified accounts exceed the ODV by 30+ days, indicating a systemic process failure, not an isolated incident.

11. Risk Acceptance / Mitigation Strategy
    "The organization will mitigate this risk through immediate disablement of identified inactive accounts (short-term) and implementation of automated enforcement controls aligned to the 90-day ODV (long-term). No risk acceptance is requested at this time. Compensating controls in place during remediation include [e.g., privileged account session monitoring via SIEM, network segmentation limiting lateral movement, multi-factor authentication on remote access channels]."

12. Supporting Evidence / Artifacts (attach or reference)
    - Inactive account report (pre-remediation) dated [date]
    - Account disable confirmation report dated [date]
    - Updated Account Management SOP version [X.X] dated [date]
    - Automated control configuration screenshot/export dated [date]
    - Follow-up clean account audit report dated [date]
    - Updated SSP AC-2(3) section, version [X.X] dated [date]

================================================================================
SECTION 4: SSP UPDATE REQUIREMENTS
================================================================================

Your SSP implementation statement for AC-2(3) must be updated to accurately reflect:

1. The ODV: Explicitly state "90 days" as the inactivity threshold triggering account disablement.

2. Implementation description: Describe the automated mechanism (e.g., "Active Directory scheduled task queries lastLogonTimestamp attribute nightly; accounts exceeding 90 days of inactivity are automatically disabled. System owners receive automated notification at 75 days.").

3. Exception process: Describe how service accounts, emergency accounts, and other non-standard accounts are handled with appropriate compensating controls and periodic review.

4. Roles and responsibilities: Identify who owns the account review process (typically the ISSO, system administrator, or IAM team) and the frequency of manual oversight review (quarterly recommended).

================================================================================
SECTION 5: ONGOING COMPLIANCE — PREVENTING RECURRENCE
================================================================================

To prevent this finding from recurring at the next assessment:

1. Establish a formal quarterly account review as a standing governance process. Document minutes and sign-off from the system owner.

2. Integrate HR off-boarding with IAM provisioning. Account disablement should be triggered by HR separation events within 24 hours, independent of the 90-day inactivity timer.

3. Define and document service account exceptions explicitly in the SSP. Each exception should have a named owner, a documented business justification, and a periodic review date.

4. Include AC-2(3) compliance metrics in your continuous monitoring program (ConMon). Monthly or quarterly reports on inactive account counts should be reviewed by the ISSO and reported to the AO as part of ongoing authorization reporting.

5. Conduct tabletop or process walkthrough of account management procedures annually to ensure staff are trained on the SOP and automated controls are functioning as intended.

================================================================================
SECTION 6: COMMON PITFALLS TO AVOID
================================================================================

- Do not close the POA&M item until automated controls are operational AND a clean follow-up audit report has been generated. Premature closure will result in a repeat finding.
- Do not disable service accounts without system owner sign-off. Inadvertent disablement of service accounts can cause system outages.
- Do not conflate "disabled" with "deleted." Disabled accounts preserve audit trail integrity; deletion may violate records retention requirements.
- Ensure the 90-day threshold is measured from last logon, not last password change or account creation date — these are different attributes in most directory services.
- Document everything. The assessor will want to see not just that the 120 accounts were disabled, but that a sustainable process now exists to prevent recurrence.

================================================================================

This guidance is based on NIST SP 800-53 Rev. 5 (AC-2(3)), NIST SP 800-53A Rev. 5 assessment procedures, OMB Circular A-130, and federal POA&M management best practices.

NIST SP 800-53 Rev 5 — Multi-Factor Authentication Requirements for Federal Systems
Executive Order 14028 / OMB M-22-09 Phishing-Resistant MFA Guidance
==============================================================================

OVERVIEW
--------
Implementing multi-factor authentication (MFA) for a federal system involves several
controls within the IA (Identification and Authentication) family of NIST SP 800-53
Rev 5. The specific controls required depend on the system's FIPS 199 impact level
(Low, Moderate, or High) and the user population (privileged vs. non-privileged,
network vs. local access). Overlaid on the baseline requirements, Executive Order 14028
and OMB Memorandum M-22-09 impose additional mandates for phishing-resistant MFA that
go beyond the standard SP 800-53 baseline language.

This response addresses:
  1. The specific IA-2 control enhancements that mandate MFA
  2. Baseline assignments for each enhancement (L/M/H per SP 800-53B)
  3. EO 14028 and OMB M-22-09 phishing-resistant MFA requirements
  4. The PIV/FIDO2 vs. SMS/TOTP distinction
  5. SP 800-63B Authenticator Assurance Level (AAL) alignment
  6. Implementation guidance and SSP narrative considerations


PART 1 — SP 800-53 Rev 5 IA-2 CONTROLS THAT REQUIRE MFA
=========================================================

The base control IA-2 (Identification and Authentication — Organizational Users)
requires that the system uniquely identify and authenticate organizational users. MFA
is mandated through specific enhancements to IA-2. The relevant enhancements are:


1. IA-2(1) — Multi-Factor Authentication to Privileged Accounts
   -------------------------------------------------------------
   Baseline Assignment: LOW | MODERATE | HIGH (all three baselines)

   Control Statement:
   Implement multi-factor authentication for access to privileged accounts.

   Scope: All privileged (administrative) accounts, regardless of access method
   (network, local, or console). "Privileged" means accounts with elevated permissions
   such as system administrators, database administrators, and security administrators.

   Key Implementation Points:
   - Both factors must be from different categories: something you know, something you
     have, or something you are.
   - This enhancement applies to ALL privileged account access — not just network access.
   - Required at the LOW baseline, making it mandatory for every federal information
     system regardless of categorization.
   - Post-EO 14028, the acceptable authenticator types are further constrained (see
     Part 3 below).

   SP 800-53B Baseline: Required at Low, Moderate, and High.


2. IA-2(2) — Multi-Factor Authentication to Non-Privileged Accounts
   -----------------------------------------------------------------
   Baseline Assignment: LOW | MODERATE | HIGH (all three baselines)

   Control Statement:
   Implement multi-factor authentication for access to non-privileged accounts.

   Scope: All non-privileged (standard user) accounts. In the Rev 5 version of this
   enhancement, the requirement applies broadly — the historical limitation to "network
   access" from Rev 4 has been revised so that Rev 5 focuses on the account type
   rather than the access vector.

   Key Implementation Points:
   - MFA applies to the full population of organizational users, not just administrators.
   - Systems must ensure that all users authenticate with at least two factors prior to
     gaining access.
   - Required at the LOW baseline in SP 800-53 Rev 5, representing a significant
     strengthening from Rev 4 where IA-2(2) was only required at Moderate and above.

   SP 800-53B Baseline: Required at Low, Moderate, and High.


3. IA-2(6) — Access to Accounts — Separate Device
   ------------------------------------------------
   Baseline Assignment: HIGH only

   Control Statement:
   Implement multi-factor authentication for [Selection: local; network] access to
   [Selection: privileged accounts; non-privileged accounts] such that:
     (a) One of the factors is provided by a device separate from the system gaining
         access; and
     (b) The device meets [Assignment: organization-defined strength of mechanism
         requirements].

   Scope: High-impact systems only. This enhancement goes beyond IA-2(1) and IA-2(2)
   by requiring that at least one authentication factor be provided by a physically
   separate device — typically a hardware token, smart card, or mobile authenticator
   app on a separate device.

   Key Implementation Points:
   - The "separate device" requirement prevents an attacker who has compromised the
     workstation from also controlling the second factor.
   - PIV/CAC cards (smart cards) inherently satisfy this requirement because the
     cryptographic operations occur on the card itself, separate from the workstation.
   - FIDO2 hardware security keys (e.g., YubiKey) also satisfy this requirement.
   - Organization-defined strength of mechanism requirements should reference NIST SP
     800-63B Authenticator Assurance Level 3 (AAL3) for High-impact systems.

   SP 800-53B Baseline: Required at High only. Organizations with Moderate systems
   should consider this enhancement based on risk; it is also a strong candidate for
   supplemental control selection when threat modeling indicates insider threat or
   advanced persistent threat (APT) actors.


4. IA-2(8) — Access to Accounts — Replay Resistant
   -------------------------------------------------
   Baseline Assignment: MODERATE | HIGH

   Control Statement:
   Implement replay-resistant authentication mechanisms for access to [Selection:
   privileged accounts; non-privileged accounts].

   Scope: Moderate and High impact systems. This enhancement requires that the
   authentication mechanism cannot be successfully replayed by an adversary who
   captures the authentication exchange.

   Key Implementation Points:
   - Replay resistance is satisfied by authenticators that use nonces, timestamps, or
     cryptographic challenge-response protocols — meaning each authentication exchange
     produces a unique, time-limited credential.
   - PIV/CAC cards and FIDO2 keys inherently provide replay resistance through
     asymmetric cryptography.
   - One-time password (OTP) tokens (hardware TOTP) provide partial replay resistance
     because the OTP is time-limited, but they are susceptible to real-time phishing
     (attacker intercepts and immediately replays the OTP). See Part 3.
   - Kerberos with pre-authentication, TLS mutual authentication, and SAML assertions
     with short validity windows also satisfy replay resistance in specific deployment
     contexts.
   - SMS-based OTP does NOT provide meaningful replay resistance — it is vulnerable
     to SIM-swapping and SS7 protocol attacks, and it is not considered replay-
     resistant in the context of this control.

   SP 800-53B Baseline: Required at Moderate and High. Not included in Low baseline
   but may be selected as a supplemental control based on risk.


5. IA-2(12) — Acceptance of PIV Credentials
   ------------------------------------------
   Baseline Assignment: LOW | MODERATE | HIGH (all three baselines)

   Control Statement:
   Accept and electronically verify Personal Identity Verification (PIV) credentials
   from other federal agencies.

   Scope: All federal information systems. This control flows from Homeland Security
   Presidential Directive 12 (HSPD-12), which mandates government-wide use of PIV
   credentials (FIPS 201 compliant), and OMB M-11-11, which required all federal
   agencies to accept PIV credentials from employees of other agencies.

   Key Implementation Points:
   - The system must be technically capable of validating PIV credentials — this
     requires integrating with a PIV-capable identity provider or implementing a
     Certificate Validation Authority (CVA).
   - PIV validation involves checking:
       (a) Certificate path validation against the Federal PKI (FPKI) trust anchor
       (b) Certificate revocation (OCSP or CRL checks against the issuing CA)
       (c) Cardholder Unique Identifier (CHUID) validation or Card Authentication
           Certificate (CAC) validation
   - For cloud-hosted or SaaS systems, PIV acceptance is typically implemented through
     an agency identity provider (IdP) that federates PIV authentication (e.g., using
     SAML 2.0 or OIDC) rather than requiring direct PIV card integration at the
     application layer.
   - IA-2(12) is a universally required control: it appears in the Low, Moderate, and
     High baselines and cannot be scoped out for federal systems.

   SP 800-53B Baseline: Required at Low, Moderate, and High.


SUMMARY TABLE — MFA-Related IA-2 Enhancements and Baseline Assignments
-----------------------------------------------------------------------

Control     | Description                          | Low | Moderate | High
------------|--------------------------------------|-----|----------|-----
IA-2        | Identification & Authentication      |  Y  |    Y     |  Y
IA-2(1)     | MFA — Privileged Accounts            |  Y  |    Y     |  Y
IA-2(2)     | MFA — Non-Privileged Accounts        |  Y  |    Y     |  Y
IA-2(6)     | MFA — Separate Device                |  N  |    N     |  Y
IA-2(8)     | Replay-Resistant Authentication      |  N  |    Y     |  Y
IA-2(12)    | Acceptance of PIV Credentials        |  Y  |    Y     |  Y

Note: "Y" = included in SP 800-53B baseline; "N" = not in baseline (may be added
through risk-based supplementation or overlay requirements).

Additional Supporting Controls (not MFA mandates but directly relevant):
  - IA-5(2) [M/H] — PKI-Based Authentication: requirements for PKI authenticators,
    certificate validation, key storage (must be hardware-protected for AAL3).
  - IA-11 [M/H] — Re-authentication: requires re-authentication after defined periods
    of inactivity or when roles/privileges change.
  - IA-12 [M/H] — Identity Proofing: requires in-person or supervised remote identity
    proofing at IAL2 or IAL3 (per SP 800-63A) before issuing authenticators.


PART 2 — RELATED AUTHENTICATOR MANAGEMENT CONTROL: IA-5
========================================================

While IA-2 establishes the MFA requirement, IA-5 (Authenticator Management) governs
how authenticators are issued, protected, revoked, and maintained. Key enhancements:

IA-5(2) — PKI-Based Authentication [Moderate/High]
   Requires:
   (a) Validation of certificates through construction and verification of a
       certification path to an accepted trust anchor including checking certificate
       status information.
   (b) Enforcement of authorized access to the private key.
   (c) Mapping of the authenticated identity to the account of the individual or group.
   (d) Implementation of a local cache of revocation data to support path discovery
       and validation for systems unable to access revocation information via the network.

This control is directly satisfied by PIV/CAC deployment. The private key must reside
in a hardware-protected cryptographic module (the PIV card itself, satisfying FIPS
140-3 Level 2 or higher requirements).

IA-5(1) — Password-Based Authentication [Low/Moderate/High]
   For systems that still use passwords as one factor, SP 800-63B Section 5 guidance
   applies:
   - Minimum 8 characters for memorized secrets (federal agencies typically set 15+)
   - No mandatory composition rules (per SP 800-63B — complexity requirements are
     counterproductive to security)
   - Check passwords against known compromised password lists
   - No mandatory periodic rotation unless compromise is suspected
   - Support paste functionality in password fields


PART 3 — EXECUTIVE ORDER 14028 AND OMB M-22-09 PHISHING-RESISTANT MFA REQUIREMENTS
====================================================================================

Executive Order 14028, "Improving the Nation's Cybersecurity" (May 12, 2021), Section 3,
mandates that federal agencies adopt a Zero Trust Architecture (ZTA) and modernize their
cybersecurity practices, including MFA. The implementing guidance is OMB Memorandum
M-22-09, "Moving the U.S. Government Toward Zero Trust Cybersecurity Principles"
(January 26, 2022).


Key EO 14028 Directives for MFA:
---------------------------------
Section 3(b)(i): Within 180 days, agencies must employ multi-factor authentication
where the authentication is resistant to phishing attacks.

The EO explicitly distinguishes between "multi-factor authentication" (the general
capability) and "phishing-resistant multi-factor authentication" (the specific security
property required for federal systems).


OMB M-22-09 Phishing-Resistant MFA Mandate:
--------------------------------------------
M-22-09 establishes the following specific requirements:

1. ALL federal staff, contractors, and partners must use phishing-resistant MFA.

2. Phishing-resistant MFA is defined as authentication that uses cryptographic
   techniques that prevent the authenticator output from being used to authenticate
   to a different party (i.e., the authenticator is bound to the specific service
   and cannot be replayed to a fraudulent site).

3. Deadline: Agencies must meet the MFA requirements within the fiscal year
   2024 milestones defined in the memorandum.

4. Approved phishing-resistant MFA methods (per M-22-09):
   APPROVED:
   - PIV/CAC smart cards (FIPS 201 / HSPD-12)
   - FIDO2 / WebAuthn hardware security keys (e.g., YubiKey, Google Titan Key)
   - Platform authenticators using FIDO2 (e.g., Windows Hello for Business with
     hardware TPM, Apple Face ID/Touch ID tied to Passkeys)

   NOT ACCEPTABLE as phishing-resistant MFA (even though they are "MFA"):
   - SMS-based one-time passwords (OTP) — vulnerable to SIM swapping, SS7 attacks,
     and real-time adversary-in-the-middle (AiTM) phishing
   - Voice call OTP — same vulnerabilities as SMS
   - Email-based OTP — susceptible to account compromise and AiTM phishing
   - TOTP/HOTP authenticator apps (e.g., Google Authenticator, Microsoft Authenticator
     in OTP mode) — the 6-digit code can be intercepted and replayed by AiTM tools
     (e.g., Evilginx2, Modlishka) in real time; NOT phishing-resistant
   - Push notifications without number matching — susceptible to MFA fatigue attacks

5. Internal-facing systems: Even internal/intranet systems must use phishing-resistant
   MFA for agency staff. M-22-09 does not permit exceptions for internal applications.

6. External-facing systems: Agencies must offer phishing-resistant MFA as an option
   to members of the public where technically feasible.


CISA Guidance — Implementing Phishing-Resistant MFA (2022):
------------------------------------------------------------
CISA has issued accompanying guidance reinforcing the M-22-09 requirements:
- Tier 1 (Preferred): Hardware PIV/CAC or FIDO2 hardware security keys
- Tier 2 (Acceptable for limited use cases): FIDO2 platform authenticators with
  biometric binding on government-managed devices
- NOT Acceptable: Any OTP-based method (SMS, TOTP, email) for systems subject to
  M-22-09

Key Distinction — Why TOTP Fails the Phishing-Resistant Test:
TOTP codes (the 6-digit codes from apps like Google Authenticator) are:
  - Not bound to the relying party (RP) — the same code could be submitted to a
    fraudulent site
  - Interceptable by real-time AiTM phishing proxies — the attacker captures the
    TOTP and immediately forwards it to the legitimate service
  - Not providing replay resistance in the M-22-09 / EO 14028 sense

PIV and FIDO2 are phishing-resistant because:
  - The cryptographic signature is bound to the specific origin/relying party
    (the domain or service). A signature generated for agency.gov cannot be used
    to authenticate to evil-agency.gov
  - The private key never leaves the hardware device
  - Authentication is a challenge-response protocol — there is no replayable
    shared secret


PART 4 — SP 800-63B AUTHENTICATOR ASSURANCE LEVELS (AAL) ALIGNMENT
====================================================================

NIST SP 800-63B (Digital Identity Guidelines — Authentication and Lifecycle Management,
Rev 3, June 2017; Rev 4 Draft under development) defines three Authenticator Assurance
Levels. Federal systems must map to the appropriate AAL based on impact level and risk:

AAL1 (Single Factor):
  - Not sufficient for any federal system covered by IA-2(1) or IA-2(2)
  - Suitable only for low-risk, public-facing informational applications without
    personal data

AAL2 (Multi-Factor, not necessarily phishing-resistant):
  - Requires two or more authentication factors
  - Approved authenticators include: OTP hardware/software tokens, PIV, FIDO2,
    look-up secrets, memorized secret + OTP
  - Satisfies SP 800-53 IA-2(1) and IA-2(2) at baseline level
  - Does NOT satisfy M-22-09 phishing-resistant MFA requirement if using TOTP/OTP
  - Appropriate for: Moderate impact systems not handling particularly sensitive data

AAL3 (Hardware-based, Phishing-Resistant, Verifier Impersonation Resistant):
  - Requires a hardware cryptographic authenticator
  - Requires verifier impersonation resistance (the authenticator is bound to the
    specific RP)
  - Approved authenticators: PIV/CAC, FIDO2 hardware security keys (roaming
    authenticators), FIDO2 platform authenticators with hardware TPM at specified
    assurance level
  - Satisfies M-22-09 phishing-resistant MFA requirement
  - Required for: High-impact systems, systems processing sensitive PII, privileged
    access to High systems, any system subject to IA-2(6)

Mapping Summary:
  System Baseline | Minimum AAL | Phishing-Resistant Required?
  Low             | AAL2        | Yes (per M-22-09, all federal systems)
  Moderate        | AAL2        | Yes (per M-22-09)
  High            | AAL3        | Yes (per M-22-09 and IA-2(6) requirement)

Note: M-22-09 effectively raises the floor for all federal systems to phishing-resistant
AAL2 or AAL3, superseding the plain AAL2 baseline reading of IA-2(1)/(2).


PART 5 — PIV vs. FIDO2 vs. SMS/TOTP: PRACTICAL COMPARISON
===========================================================

Criterion               | PIV/CAC        | FIDO2 HW Key   | TOTP App       | SMS OTP
------------------------|----------------|----------------|----------------|--------
Phishing-resistant      | YES            | YES            | NO             | NO
Replay-resistant        | YES            | YES            | Partial        | NO
Verifier impersonation  | YES (origin    | YES (origin    | NO             | NO
resistant               |  bound)        |  bound)        |                |
Hardware-protected key  | YES (FIPS 140) | YES            | NO             | NO
Federal mandate (M-22)  | APPROVED       | APPROVED       | NOT APPROVED   | NOT APPROVED
HSPD-12 compliant       | YES            | NO*            | NO             | NO
Suitable for PIV-req.   | YES            | NO             | NO             | NO
systems (IA-2(12))      |                |                |                |
Works without network   | YES (offline   | YES (offline   | YES (offline   | NO
                        |  card reader)  |  USB/NFC)      |  TOTP)         |
Phishing sim. training  | Immune         | Immune         | Vulnerable     | Vulnerable

*FIDO2 keys are not HSPD-12/FIPS 201 PIV credentials, but they satisfy phishing-
resistant MFA per M-22-09. For systems requiring PIV per HSPD-12 and IA-2(12), only
PIV/CAC satisfies both requirements simultaneously. Agencies may use FIDO2 as a
supplemental or alternative phishing-resistant method where PIV is not technically
feasible (e.g., mobile devices, developer APIs).


PART 6 — IMPLEMENTATION GUIDANCE FOR FEDERAL SYSTEMS
=====================================================

Step 1: Determine System Impact Level
  - Conduct FIPS 199 categorization and document in the system categorization form
  - High-impact systems must implement IA-2(1), IA-2(2), IA-2(6), IA-2(8), IA-2(12)
  - Moderate systems must implement IA-2(1), IA-2(2), IA-2(8), IA-2(12)
  - Low systems must implement IA-2(1), IA-2(2), IA-2(12)
  - All systems, regardless of baseline, must implement phishing-resistant MFA per M-22-09

Step 2: Select Phishing-Resistant Authenticator(s)
  Option A — PIV/CAC (preferred for federal employees and contractors):
    - Deploy PIV card readers at workstations
    - Integrate with agency Active Directory/LDAP using PKINIT or smart card logon
    - For web applications, implement PIV authentication via agency IdP (e.g., GSA
      Login.gov, agency ICAM solution)
    - Validate certificates against FPKI trust anchors
    - Implement OCSP checking for real-time revocation validation (configure caching
      for continuity of operations)

  Option B — FIDO2 Hardware Security Keys:
    - Deploy WebAuthn/FIDO2 at the application or IdP layer
    - Register keys to user accounts with attestation verification
    - Enforce enterprise-attestation or AAL3-level authenticators via RP policy
    - Suitable for developer workflows, API access, cloud services, and mobile
    - Document in SSP as supplemental phishing-resistant MFA method

  Option C — Hybrid (PIV primary, FIDO2 fallback):
    - PIV for primary workstation authentication
    - FIDO2 for remote access, cloud services, and mobile scenarios
    - Centralize both through agency IdP using SAML 2.0 or OIDC federation

Step 3: Address Legacy Systems
  - Legacy systems that cannot natively support PIV or FIDO2 must use a PIV-enabled
    IdP or proxy to front-end the authentication (e.g., Shibboleth, Okta, Azure AD
    with PIV federation)
  - Document compensating controls in the SSP if a short-term legacy exception exists
  - Include a Plan of Action and Milestones (POA&M) item with a specific remediation
    date for any system not yet meeting phishing-resistant MFA requirements

Step 4: Document in the SSP (System Security Plan)
  For each MFA control, the SSP narrative should address:

  IA-2(1) Implementation Statement (example structure):
    "The [System Name] implements multi-factor authentication for all privileged
    accounts using PIV/CAC smart cards (FIPS 201) as the primary authentication
    mechanism, supplemented by FIDO2 hardware security keys for privileged access
    from mobile or remote environments where PIV card readers are unavailable.
    Privileged account authentication is managed through [Agency IdP Name] using
    [SAML 2.0 / PKINIT / smart card logon]. Certificate validation is performed
    against the Federal PKI Common Policy Root CA. OCSP responses are cached locally
    for [X hours] to support operations during network outages. This implementation
    satisfies AAL3 requirements per NIST SP 800-63B and phishing-resistant MFA
    requirements per OMB M-22-09."

Step 5: Assessment Considerations (SP 800-53A)
  Assessors will examine, interview, and test:
  - Examine: SSP narratives, PIV/FIDO2 configuration documentation, IdP configuration,
    certificate validation policies, identity proofing records (IA-12)
  - Interview: ISSO, system administrator, identity management personnel
  - Test: Attempt authentication without second factor (should fail); verify PIV
    certificate validation (including revocation checking); test FIDO2 attestation
    enforcement; verify that SMS/TOTP methods are not enabled for accounts subject
    to phishing-resistant MFA requirements


PART 7 — COMPLIANCE CHECKLIST SUMMARY
======================================

Requirement                                         | Source        | All Baselines?
----------------------------------------------------|---------------|---------------
Implement MFA for privileged accounts               | IA-2(1)       | Yes (L/M/H)
Implement MFA for non-privileged accounts           | IA-2(2)       | Yes (L/M/H)
Accept PIV credentials from other agencies          | IA-2(12)      | Yes (L/M/H)
Implement replay-resistant authentication           | IA-2(8)       | M/H only
Implement MFA via separate device                   | IA-2(6)       | H only
MFA must be phishing-resistant (PIV/FIDO2)          | EO 14028 /    | Yes — ALL
                                                    | OMB M-22-09   | federal systems
SMS and TOTP OTP are NOT acceptable                 | CISA / M-22-09| Yes — prohibited
PIV certificates must be validated via FPKI         | IA-5(2)       | M/H
Identity proofing at IAL2/IAL3 before issuing creds | IA-12         | M/H
High-impact systems require AAL3 authenticators     | SP 800-63B    | H only


AUTHORITATIVE REFERENCES
========================

1. NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and
   Organizations (September 2020, updated December 2020)
   Controls: IA-2, IA-2(1), IA-2(2), IA-2(6), IA-2(8), IA-2(12), IA-5, IA-5(2)
   https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final

2. NIST SP 800-53B — Control Baselines for Information Systems and Organizations
   (October 2020) — Defines Low, Moderate, and High baseline control selections
   https://csrc.nist.gov/publications/detail/sp/800-53b/final

3. NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle
   Management (Rev 3, June 2017) — Defines AAL1, AAL2, AAL3 and approved
   authenticator types
   https://csrc.nist.gov/publications/detail/sp/800-63b/final

4. NIST SP 800-53A Rev 5 — Assessing Security and Privacy Controls (January 2022)
   — Assessment procedures for all SP 800-53 Rev 5 controls
   https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final

5. Executive Order 14028 — Improving the Nation's Cybersecurity (May 12, 2021)
   Section 3: Federal Government Cybersecurity
   https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/
   executive-order-on-improving-the-nations-cybersecurity/

6. OMB Memorandum M-22-09 — Moving the U.S. Government Toward Zero Trust
   Cybersecurity Principles (January 26, 2022)
   Phishing-resistant MFA mandate: Section II (Identity pillar)
   https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

7. FIPS 201-3 — Personal Identity Verification (PIV) of Federal Employees and
   Contractors (January 2022) — PIV card specification
   https://csrc.nist.gov/publications/detail/fips/201/3/final

8. HSPD-12 — Policy for a Common Identification Standard for Federal Employees
   and Contractors (August 2004) — Foundational PIV policy mandate

9. CISA — Implementing Phishing-Resistant MFA (October 2022)
   https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-
   phishing-resistant-mfa-508c.pdf

10. OMB M-11-11 — Continued Implementation of HSPD-12 (February 2011)
    Requirement for all agencies to accept PIV credentials from other agencies (IA-2(12))

==============================================================================
Response generated using NIST SP 800-53 Rev 5 Compliance Skill
Skill: nist-800-53 | Eval: eval-118 | Date: 2026-05-07
==============================================================================

NIST SP 800-53 Rev 5 Multi-Factor Authentication Requirements and Executive Order 14028
=====================================================================================

OVERVIEW
--------
Multi-factor authentication (MFA) is a critical security control for federal systems. NIST SP 800-53 Rev 5 addresses MFA requirements primarily within the Identification and Authentication (IA) control family, with additional references in Access Control (AC) and other families. Executive Order 14028 strengthens these requirements with specific mandates for phishing-resistant MFA across federal systems.


PART 1: SP 800-53 REV 5 CONTROLS REQUIRING MFA
-----------------------------------------------

1. IA-2: Identification and Authentication (Organizational Users)
   The primary MFA control. Requires that the information system uniquely identifies and authenticates organizational users.

   Key enhancement sub-controls requiring MFA:

   IA-2(1) - Multi-Factor Authentication to Privileged Accounts
   - Requires MFA for access to privileged accounts (e.g., system administrators, root accounts)
   - Baseline applicability: LOW, MODERATE, HIGH
   - One of the most universally required MFA controls across all baselines

   IA-2(2) - Multi-Factor Authentication to Non-Privileged Accounts
   - Requires MFA for access to non-privileged accounts
   - Baseline applicability: MODERATE, HIGH
   - Not required in the LOW baseline but strongly recommended

   IA-2(6) - Access to Accounts — Separate Device
   - Requires MFA using a device separate from the system gaining access
   - Baseline applicability: Not in any baseline by default (organization-defined)
   - Often implemented in HIGH environments and by policy overlay

   IA-2(8) - Phishing-Resistant Multi-Factor Authentication to Privileged Accounts
   - Requires phishing-resistant MFA specifically for privileged accounts
   - Phishing-resistant methods include: PIV/CAC smart cards, FIDO2/WebAuthn hardware keys
   - Baseline applicability: HIGH (introduced prominently in Rev 5)
   - Directly supports EO 14028 mandates

   IA-2(12) - Acceptance of PIV Credentials
   - Requires systems to accept Personal Identity Verification (PIV) credentials
   - PIV credentials inherently provide MFA (something you have + something you know)
   - Baseline applicability: LOW, MODERATE, HIGH
   - Applies to all federal systems — aligns with HSPD-12 requirements

   IA-2(13) - Out-of-Band Authentication
   - Requires out-of-band authentication for non-privileged accounts in certain scenarios
   - Baseline applicability: Organization-defined; common in HIGH environments

2. IA-5: Authenticator Management
   While not exclusively an MFA control, IA-5 governs the management of authenticators used in MFA solutions.

   IA-5(1) - Password-Based Authentication
   - Sets minimum complexity and management requirements for passwords used as one factor
   - Baseline applicability: LOW, MODERATE, HIGH

   IA-5(2) - Public Key Infrastructure (PKI)-Based Authentication
   - Requires validation of PKI certificates, directly supports smart card/PIV MFA
   - Baseline applicability: MODERATE, HIGH

   IA-5(6) - Protection of Authenticators
   - Requires protection of authenticators (tokens, smart cards, etc.)
   - Baseline applicability: Organization-defined

   IA-5(7) - No Embedded Unencrypted Static Authenticators
   - Prevents embedding of static credentials, supports MFA integrity
   - Baseline applicability: MODERATE, HIGH

3. IA-8: Identification and Authentication (Non-Organizational Users)
   Addresses MFA requirements for external users, contractors, and partners.

   IA-8(1) - Acceptance of PIV Credentials from Other Agencies
   - Requires acceptance of PIV credentials from other federal agencies
   - Baseline applicability: LOW, MODERATE, HIGH

   IA-8(2) - Acceptance of External Authenticators
   - Requires acceptance of external authenticators meeting NIST SP 800-63 standards
   - Baseline applicability: LOW, MODERATE, HIGH

   IA-8(4) - Use of Defined Profiles
   - Systems must use profiles as defined in SP 800-63 for identity assurance
   - Baseline applicability: LOW, MODERATE, HIGH

4. AC-17: Remote Access
   AC-17(3) - Managed Access Control Points
   - Requires the use of MFA for remote access sessions
   - Baseline applicability: MODERATE, HIGH
   - Critical for VPN and remote desktop scenarios

5. AC-2: Account Management and AC-3: Access Enforcement
   These controls, while not explicitly mandating MFA, require implementation of mechanisms (including MFA) to enforce least privilege and access controls, especially for privileged accounts.


PART 2: BASELINE APPLICABILITY SUMMARY TABLE
--------------------------------------------

Control             | LOW | MODERATE | HIGH | Notes
--------------------|-----|----------|------|-------------------------------
IA-2(1)             |  X  |    X     |  X   | MFA for privileged accounts
IA-2(2)             |     |    X     |  X   | MFA for non-privileged accounts
IA-2(6)             |     |          |      | Org-defined, often HIGH
IA-2(8)             |     |          |  X   | Phishing-resistant MFA, privileged
IA-2(12)            |  X  |    X     |  X   | PIV credential acceptance
IA-5(2)             |     |    X     |  X   | PKI-based authentication
IA-8(1)             |  X  |    X     |  X   | PIV from other agencies
IA-8(2)             |  X  |    X     |  X   | External authenticators (SP 800-63)
AC-17(3)            |     |    X     |  X   | MFA for remote access

Note: LOW baseline systems still require MFA for privileged accounts (IA-2(1)) and PIV
acceptance (IA-2(12)), making MFA universally applicable across all federal systems.


PART 3: EXECUTIVE ORDER 14028 REQUIREMENTS FOR PHISHING-RESISTANT MFA
----------------------------------------------------------------------

Executive Order 14028, "Improving the Nation's Cybersecurity," signed May 12, 2021, established sweeping cybersecurity mandates for the federal government. Key MFA-related requirements include:

3.1 Core MFA Mandate (Section 3 — Modernizing Federal Government Cybersecurity)
   - Section 3(b)(ii): Federal agencies must adopt multi-factor authentication within 180 days of the order
   - MFA must be implemented across all federal information systems, including both privileged and non-privileged accounts
   - The mandate applies to cloud services, on-premises systems, and hybrid environments

3.2 Phishing-Resistant MFA Specifically
   EO 14028 does not use the exact phrase "phishing-resistant" directly in every clause, but the Office of Management and Budget (OMB) and CISA subsequently clarified through implementing guidance (OMB M-22-09) that:

   OMB Memorandum M-22-09 (Zero Trust Architecture Strategy, January 2022) — implementing EO 14028:
   - Requires agencies to use phishing-resistant MFA methods, specifically:
     * PIV/CAC (Personal Identity Verification / Common Access Card) smart cards
     * FIDO2/WebAuthn hardware security keys
   - Explicitly prohibits reliance on weaker MFA methods (SMS OTP, voice call OTPs, push notifications without number matching) as the sole MFA mechanism for high-value assets
   - Agencies must achieve phishing-resistant MFA for:
     * All privileged users (system admins, privileged access workstations)
     * All federal employees accessing federal systems
     * Where technically feasible, all non-privileged users

3.3 Phishing-Resistant Methods Defined
   Under EO 14028 / OMB M-22-09 / CISA guidance, phishing-resistant MFA is defined as:
   - Authentication that cryptographically verifies both the authenticator and the relying party (the system being accessed)
   - Resistant to real-time phishing attacks (adversary-in-the-middle attacks)
   - Acceptable methods:
     * PIV/CAC smart cards (FIPS 201-compliant)
             - Hardware-based, certificate-backed
        - Satisfies AAL3 under SP 800-63B
     * FIDO2/WebAuthn with hardware security keys (e.g., YubiKey)
        - Cryptographic binding to the origin/relying party
        - Resistant to credential theft and real-time phishing
        - Satisfies AAL2 or AAL3 depending on implementation
   - Non-phishing-resistant methods (acceptable for limited use cases only):
     * TOTP (time-based one-time passwords via authenticator apps) — susceptible to real-time phishing
     * SMS/voice OTP — susceptible to SIM swapping and real-time phishing

3.4 CISA Binding Operational Directives
   CISA BOD 22-02 and subsequent guidance under EO 14028 authority:
   - Agencies must enumerate all internet-accessible systems and enforce MFA
   - Specific timelines were established for remediation of systems lacking MFA
   - Privileged accounts must use phishing-resistant MFA first, then extended to all users

3.5 Timeline and Accountability
   - 60 days: Agencies to document MFA deployment plans
   - 180 days: Implement MFA across all systems
   - 1 year: Achieve phishing-resistant MFA for privileged users
   - Ongoing: OMB oversight and agency reporting requirements


PART 4: INTEGRATION OF SP 800-53 AND EO 14028 FOR FEDERAL SYSTEM IMPLEMENTATION
---------------------------------------------------------------------------------

4.1 Alignment
   - IA-2(8) (Phishing-Resistant MFA for Privileged Accounts) directly codifies EO 14028 / M-22-09 requirements in SP 800-53 Rev 5 control language
   - IA-2(12) (PIV Acceptance) supports the PIV-based phishing-resistant pathway
   - SP 800-63B AAL2/AAL3 provides the technical standards underpinning both SP 800-53 and EO 14028 guidance

4.2 Implementation Recommendations for Federal System MFA
   Step 1: Identify all privileged accounts — implement phishing-resistant MFA immediately (IA-2(1), IA-2(8))
   Step 2: Enable PIV/CAC acceptance for all organizational users (IA-2(12))
   Step 3: Extend MFA to all non-privileged accounts (IA-2(2))
   Step 4: Enforce MFA for all remote access sessions (AC-17(3))
   Step 5: Manage and protect authenticators per IA-5 requirements
   Step 6: Accept external credentials per IA-8 for cross-agency/partner access
   Step 7: Document in SSP and validate during ATO process

4.3 Key Supporting Standards
   - NIST SP 800-63B: Authentication and Lifecycle Management (defines AAL1/2/3)
   - FIPS 201-3: PIV standard for federal employees and contractors
   - NIST SP 800-157: Guidelines for Derived PIV Credentials (mobile devices)
   - OMB M-22-09: Federal Zero Trust Architecture Strategy
   - CISA Zero Trust Maturity Model: Implementation guidance


SUMMARY
-------
For federal systems:

1. All baselines (LOW, MODERATE, HIGH): IA-2(1) requires MFA for privileged accounts; IA-2(12) requires PIV acceptance universally.

2. MODERATE and HIGH baselines additionally require: IA-2(2) for non-privileged accounts, IA-5(2) for PKI authentication, AC-17(3) for remote access MFA.

3. HIGH baseline additionally requires: IA-2(8) for phishing-resistant MFA on privileged accounts.

4. EO 14028 / OMB M-22-09 mandate phishing-resistant MFA (PIV/CAC or FIDO2/WebAuthn) for all privileged users and, where feasible, all federal employees — going beyond baseline checkbox compliance to require cryptographically strong, origin-binding authentication methods that defeat real-time phishing and adversary-in-the-middle attacks.

Agencies that implement PIV/CAC or FIDO2 hardware keys for all users simultaneously satisfy both the SP 800-53 control requirements and the EO 14028 / M-22-09 phishing-resistant MFA mandates.

================================================================================
SYSTEM SECURITY PLAN (SSP) CONTROL NARRATIVE
NIST SP 800-53 Rev 5 — SC-8(1): Transmission Confidentiality and Integrity |
Cryptographic Protection
================================================================================

SYSTEM NAME:        [Organization Federal Information System Name]
SYSTEM IDENTIFIER:  [System Identifier / FISMA UID]
IMPACT LEVEL:       Moderate (FIPS 199 High-Water Mark)
SSP VERSION:        1.0
DATE:               2026-05-07
PREPARED BY:        Information System Security Officer (ISSO)
REVIEWED BY:        System Owner / Authorizing Official Designated Representative

--------------------------------------------------------------------------------
CONTROL INFORMATION
--------------------------------------------------------------------------------

Control ID:           SC-8(1)
Control Family:       System and Communications Protection (SC)
Control Title:        Transmission Confidentiality and Integrity | Cryptographic
                      Protection
SP 800-53B Baseline:  Moderate, High
Control Type:         System-Specific (see Control Designation section)
Enhancement Of:       SC-8 — Transmission Confidentiality and Integrity
Related Controls:     SC-8, SC-12, SC-13, SC-17, SC-28(1), AC-17, IA-3, IA-8,
                      MA-4, SI-8

--------------------------------------------------------------------------------
CONTROL STATEMENT (NIST SP 800-53 Rev 5)
--------------------------------------------------------------------------------

SC-8:    Implement cryptographic mechanisms to prevent unauthorized disclosure
         of information and to detect changes to information during transmission
         unless otherwise protected by [Assignment: organization-defined
         alternative physical safeguards].

SC-8(1): Implement cryptographic mechanisms to prevent unauthorized disclosure
         of information and detect changes to information during transmission.

Note: SC-8(1) removes the alternative of physical safeguards available in the
base SC-8 control. For Moderate impact systems, cryptographic protection is
mandatory for all data-in-transit — physical alternatives are not acceptable.

--------------------------------------------------------------------------------
IMPLEMENTATION STATUS
--------------------------------------------------------------------------------

  [X] Implemented
  [ ] Partially Implemented
  [ ] Planned
  [ ] Not Applicable
  [ ] Alternative Implementation

Implementation Date:     [Date]
Planned Completion Date: N/A

--------------------------------------------------------------------------------
CONTROL DESIGNATION
--------------------------------------------------------------------------------

Designation:  System-Specific / Hybrid

Rationale: The base cryptographic policy (SC-8(1) policy and standards) is
inherited as a Common Control from the organization's enterprise Information
Security Policy and the Network Security Standards document maintained by the
Enterprise Security Operations Center (ESOC). However, specific configuration
and enforcement of cryptographic protocols within the application layer, API
endpoints, and inter-service communications are System-Specific responsibilities
implemented and maintained by the system team.

  Common (Inherited) Component:
    - Enterprise TLS configuration standards and approved cipher suite lists
      (inherited from [Organization] Enterprise SC-8 Common Control)
    - Enterprise PKI / Certificate Authority infrastructure (inherited from
      SC-12, SC-17 common control provider)
    - Boundary protection device TLS termination policy (inherited from
      network/infrastructure team)

  System-Specific Component:
    - TLS configuration on application servers, APIs, and microservices
    - Certificate lifecycle management for system-specific certificates
    - Verification that all data paths use approved cryptographic protocols
    - Prohibition and removal of deprecated protocol support (TLS 1.0, TLS 1.1,
      SSL v2/v3)

--------------------------------------------------------------------------------
IMPLEMENTATION DESCRIPTION
--------------------------------------------------------------------------------

1. OVERVIEW

The [System Name] implements cryptographic protection for all information
transmitted across internal and external networks in accordance with SC-8(1).
All data in transit — including user-to-application, application-to-database,
service-to-service, and administrative communications — is protected using
FIPS-validated cryptographic modules and NIST-approved algorithms. This
implementation satisfies the Moderate baseline requirement that cryptographic
mechanisms, rather than alternative physical safeguards, be used to protect
transmission confidentiality and integrity.

2. CRYPTOGRAPHIC STANDARDS AND FIPS VALIDATION

2.1 FIPS 140-2 / FIPS 140-3 Validated Modules

All cryptographic operations protecting data in transit are performed using
FIPS 140-2 or FIPS 140-3 validated cryptographic modules, consistent with
the requirements of SC-13 (Cryptographic Protection) and FIPS 140-3 (March
2019 transition).

  a. Web and Application Layer (External-Facing):
     - Module: OpenSSL FIPS Object Module (FIPS 140-2, Certificate #[CMVP #])
       OR
     - Module: Microsoft Windows CNG (Cryptographic Next Generation) FIPS 140-2
       Validated (Certificate #[CMVP #])
     - These modules are validated under NIST's Cryptographic Module Validation
       Program (CMVP) and listed on the NIST CMVP active certificates list.

  b. Cloud Infrastructure Layer (if applicable — e.g., AWS GovCloud):
     - AWS uses FIPS 140-2 validated endpoints (e.g., s3.us-gov-west-1.amazonaws.com
       FIPS endpoints; AWS Key Management Service FIPS module).
     - Verified via AWS FIPS compliance documentation and CMVP certificate
       references published by the CSP.

  c. Database and Backend Communications:
     - Native TLS libraries within [Database Platform, e.g., PostgreSQL 15 /
       Microsoft SQL Server 2019] configured to use the OS-level FIPS-validated
       cryptographic provider.

2.2 Approved Algorithms (per SC-13 / NIST SP 800-175B Rev 1)

  Confidentiality: AES-256-GCM (preferred), AES-128-GCM
  Integrity:       HMAC-SHA-256, HMAC-SHA-384
  Key Exchange:    ECDHE (secp256r1 / P-256, secp384r1 / P-384), DHE-2048 (minimum)
  Authentication:  RSA-2048 (minimum), ECDSA P-256 / P-384
  Certificates:    SHA-256 or stronger signature hash; RSA 2048-bit minimum key
                   length or ECC 256-bit minimum

3. TLS PROTOCOL VERSION REQUIREMENTS AND ENFORCEMENT

3.1 Approved Protocol Versions

  APPROVED:
    - TLS 1.3  (preferred for all new deployments and where supported)
    - TLS 1.2  (acceptable; required minimum for all in-scope communication paths)

  PROHIBITED — Explicitly Disabled:
    - TLS 1.1  (disabled; deprecated per NIST SP 800-52 Rev 2, RFC 8996)
    - TLS 1.0  (disabled; deprecated per NIST SP 800-52 Rev 2, RFC 8996)
    - SSL v3   (disabled; vulnerable to POODLE attack, RFC 7568)
    - SSL v2   (disabled)

3.2 Enforcement Mechanism

TLS version restrictions are enforced at multiple layers:

  a. Load Balancer / Reverse Proxy (e.g., AWS ALB, NGINX, F5):
     - SSL/TLS policy configured to [Organization]-defined approved policy
       (e.g., "ELBSecurityPolicy-TLS13-1-2-2021-06" or equivalent).
     - Cipher suites restricted to approved list; weak ciphers (RC4, 3DES,
       NULL, EXPORT-grade) are explicitly disabled.
     - Configuration managed via [Infrastructure-as-Code tool, e.g., Terraform]
       and enforced through configuration management baselines (see CM-6, CM-7).

  b. Application Server Layer:
     - Web/application servers (e.g., Apache HTTP Server, Nginx, IIS) configured
       with SSLProtocol directives or equivalent restricting to TLS 1.2 and 1.3.
     - Verified via automated configuration scanning (see Section 7, Evidence).

  c. Database / Backend Services:
     - Database connections require TLS; unencrypted connections are rejected.
     - Connection strings and drivers configured to enforce TLS with certificate
       validation (not "accept any certificate" mode).

  d. API Gateway:
     - All REST and SOAP API calls require TLS 1.2 or TLS 1.3.
     - API Gateway (e.g., AWS API Gateway, Kong) configured with matching TLS
       policy; HTTP (unencrypted) endpoints are disabled.

  e. Inter-Service / Microservice Communications (Internal):
     - Internal service mesh (e.g., Istio / AWS App Mesh) enforces mutual TLS
       (mTLS) for east-west traffic between microservices.
     - mTLS certificates issued by internal Certificate Authority through the
       enterprise PKI (SC-12, SC-17).

4. SCOPE OF CRYPTOGRAPHIC PROTECTION

The following communication paths are within scope for SC-8(1) and are
confirmed to use approved cryptographic protection:

  Path                                      Protocol     Notes
  ----------------------------------------- ------------ -------------------------
  User browser to web application           TLS 1.2/1.3  Public internet; HSTS enforced
  Mobile client to API Gateway              TLS 1.2/1.3  Certificate pinning applied
  Application to database server            TLS 1.2/1.3  Client cert auth (mTLS)
  Application to external APIs / 3rd party  TLS 1.2/1.3  Validated at integration testing
  Admin/SSH access (ISSO / admins)          TLS / SSH-2  SSH-2 with approved algorithms
  Remote maintenance connections (MA-4)     TLS 1.2/1.3  Encrypted VPN + TLS
  Batch file transfer (SFTP / FTPS)         SSH-2 / TLS  Replaces FTP (FTP is prohibited)
  Monitoring / logging data streams         TLS 1.2/1.3  To SIEM collector endpoints
  Cloud storage API calls                   TLS 1.2/1.3  FIPS endpoints used
  Inter-AZ / inter-region replication       TLS 1.2/1.3  CSP-managed encryption in transit

5. CERTIFICATE MANAGEMENT

  a. Public-Facing Certificates:
     - Issued by [Trusted CA, e.g., DigiCert Federal SSP, IdenTrust] consistent
       with the Federal PKI (FPKI) framework.
     - Certificate validity: Maximum 398 days (per CA/Browser Forum Baseline
       Requirements); renewal tracked in the certificate inventory.

  b. Internal / Service Certificates:
     - Issued by the organization's internal CA (subordinate to the enterprise
       root CA) under the SC-12 / SC-17 common control.
     - Certificate inventory maintained in [Certificate Management Tool, e.g.,
       Venafi, AWS Certificate Manager, HashiCorp Vault PKI].

  c. Certificate Revocation:
     - OCSP (Online Certificate Status Protocol) and/or CRL (Certificate
       Revocation List) checked for all certificate validations.
     - Revocation procedures documented in [PKI Policy / CPS document].

  d. Cipher Suite Order (TLS 1.3 — negotiated by protocol):
     TLS_AES_256_GCM_SHA384
     TLS_AES_128_GCM_SHA256
     TLS_CHACHA20_POLY1305_SHA256 (if supported)

  e. Cipher Suite Order (TLS 1.2 — explicit configuration):
     TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
     TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
     TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
     [All CBC-mode and RC4 cipher suites disabled]

6. RELATIONSHIP TO RELATED CONTROLS

SC-8(1) is implemented as part of an integrated cryptography and communications
protection strategy that includes the following related controls:

  SC-8   (Base Control): The base control requirement is fully satisfied by the
         cryptographic implementation described herein. No physical alternative
         safeguard is used or claimed.

  SC-12  (Cryptographic Key Establishment and Management): Cryptographic keys
         used for TLS sessions are managed through the enterprise PKI and
         automated certificate management platform. Key generation uses approved
         random number generators within FIPS-validated modules. Session keys
         are ephemeral (via ECDHE/DHE key exchange), providing forward secrecy.

  SC-13  (Cryptographic Protection): All algorithms and modules referenced in
         this narrative comply with SC-13 requirements — only FIPS-validated
         modules and NIST-approved algorithms are used. SC-8(1) and SC-13 are
         implemented in concert; SC-13 defines the cryptographic standards that
         SC-8(1) applies to data in transit.

  SC-17  (Public Key Infrastructure Certificates): Certificates used for TLS
         authentication are issued in compliance with SC-17, using either the
         Federal PKI (for external-facing systems) or the organization's internal
         CA (for internal services).

  SC-28(1) (Protection of Information at Rest | Cryptographic Protection):
         Data at rest is protected separately by SC-28(1), which uses AES-256
         encryption via FIPS-validated modules for all sensitive data stored
         within the system's databases, file systems, and backup media. SC-8(1)
         and SC-28(1) together provide end-to-end cryptographic coverage —
         SC-8(1) covers data in motion; SC-28(1) covers data at rest. This
         layered approach ensures no sensitive information exists in plaintext
         at any point in its lifecycle within the authorization boundary.

  AC-17  (Remote Access): Remote administrative access is encrypted per SC-8(1).
         VPN tunnels use IKEv2/IPsec with AES-256 and SHA-384.

  MA-4   (Nonlocal Maintenance): Maintenance sessions conducted remotely are
         performed exclusively over encrypted channels (TLS 1.2/1.3 or SSH-2)
         consistent with this control.

  IA-3   (Device Identification and Authentication): mTLS client certificates
         used for inter-service authentication are provisioned and managed
         consistently with this control.

7. CONFIGURATION MANAGEMENT INTEGRATION

TLS configurations are treated as security-relevant configuration parameters
(CM-6) and are:

  - Documented in the system's approved baseline configuration (CM-2).
  - Restricted from unauthorized modification through change control (CM-3).
  - Scanned for compliance deviations via automated vulnerability scanning
    tools (RA-5) and configuration compliance tools (CM-6, CM-7).
  - Deviation from the approved TLS configuration generates a finding that is
    tracked in the Plan of Action and Milestones (POA&M) if not remediated
    within [30] days (consistent with RA-5 organizational parameters).

8. CONTINUOUS MONITORING

SC-8(1) implementation is verified on an ongoing basis through:

  a. Automated TLS/SSL scanning: [Tool, e.g., Qualys SSL Labs Enterprise,
     Tenable.io, AWS Security Hub] scans all externally and internally exposed
     TLS endpoints [frequency: monthly minimum, or upon significant change].
     Scans confirm:
       - TLS 1.0 and 1.1 are not negotiable
       - No weak or deprecated cipher suites are offered
       - Certificate validity and chain of trust
       - HSTS header presence (for HTTPS endpoints)

  b. Web Application Vulnerability Scanning (RA-5): DAST scans include checks
     for insecure protocol negotiation and certificate issues.

  c. Penetration Testing (CA-8): Annual third-party penetration test includes
     TLS configuration assessment as part of network and application testing.

  d. SIEM Alerting: TLS handshake failures and anomalous cipher negotiation
     attempts are logged and alerted via the SIEM (AU-2, AU-12, SI-4).

--------------------------------------------------------------------------------
RESPONSIBLE ROLES
--------------------------------------------------------------------------------

Role                              Responsibility
--------------------------------- -----------------------------------------------
Information System Owner (ISO)    Accountable for overall SC-8(1) compliance;
                                  approves cryptographic standards deviations

Information System Security       Authors and maintains this SSP narrative;
Officer (ISSO)                    reviews TLS scan results; manages POA&M items
                                  related to SC-8(1)

System/Application Administrator  Implements and maintains TLS configuration on
                                  application servers, load balancers, and APIs;
                                  manages certificate renewals

Network Security Engineer         Configures and maintains boundary protection
                                  devices, load balancers, and VPN endpoints;
                                  enforces TLS policy at network layer

Cloud/Infrastructure Engineer     Maintains IaC templates enforcing TLS policy;
                                  manages cloud service FIPS endpoint configuration

Enterprise PKI Team               Issues, renews, and revokes certificates;
                                  maintains CA infrastructure (SC-12, SC-17)

Security Operations (SOC)         Monitors TLS-related alerts; responds to
                                  certificate expiration alerts and anomalous
                                  TLS events

Third-Party Assessor (3PAO)       Assesses SC-8(1) implementation during annual
                                  security assessment (CA-2) per SP 800-53A

--------------------------------------------------------------------------------
EVIDENCE AND ARTIFACTS
--------------------------------------------------------------------------------

The following artifacts are available to a 3PAO assessor for examination,
interview, and test activities (per SP 800-53A Rev 5 assessment procedures):

Artifact                                    Type        Location / Reference
------------------------------------------- ----------- ---------------------------
SC-8 / SC-8(1) Policy Statement             Examine     [Organization] Information
                                                        Security Policy, Section [X]
                                                        Version [X], dated [Date]

TLS/SSL Configuration Standards             Examine     Network Security Standards
Document                                                Document, Section [X]
                                                        (approved [Date])

System-Specific TLS Configuration           Examine     System Security Plan,
Baseline (CM-2)                                         Appendix [X] — Baseline
                                                        Configuration

Load Balancer / Proxy TLS Config            Examine /   [IaC repo path] or [config
(e.g., Nginx ssl.conf, ALB policy)          Test        file location]; confirms
                                                        TLS 1.0/1.1 disabled

TLS Scan Results (Qualys SSL / Tenable)     Examine /   [Artifact repository] —
                                            Test        Most recent scan report,
                                                        dated [Date]; A or A+ rating

FIPS 140-2/3 CMVP Certificate References    Examine     NIST CMVP listing:
                                                        https://csrc.nist.gov/projects/
                                                        cryptographic-module-validation-
                                                        program/validated-modules
                                                        Certificate #[CMVP #]

Certificate Inventory / Management          Examine     [Venafi / ACM / Vault]
Records                                                 dashboard export, dated [Date]

Penetration Test Report (Annual)            Examine     [3PAO Firm Name] Penetration
                                                        Test Report, dated [Date],
                                                        Section [X] — TLS Assessment

SIEM Alert Configuration for TLS           Examine /   [SIEM Platform] alert rule
Events                                      Interview   configuration, Rule ID [X]

mTLS Configuration (inter-service)          Examine /   Service mesh configuration
                                            Test        (e.g., Istio PeerAuthentication
                                                        policy); demonstrates
                                                        STRICT mode enforced

Vulnerability Scan Results (RA-5)          Examine     [Scanning tool] output
                                                        confirming no MEDIUM or HIGH
                                                        TLS-related findings open

Interview — ISSO / System Admin             Interview   Confirm awareness of TLS
                                                        requirements; demonstrate
                                                        configuration change process

--------------------------------------------------------------------------------
ASSESSOR NOTES — 3PAO ASSESSMENT GUIDANCE
--------------------------------------------------------------------------------

Assessment Method Mapping (per SP 800-53A Rev 5, SC-8(1)-1):

  Examine:  SC-8(1) policy; procedures addressing transmission confidentiality
            and integrity; system design documentation; system configuration
            settings and associated documentation; system audit records; other
            relevant documents or records.

  Interview: Organizational personnel with information security responsibilities;
             system/network administrators.

  Test:     Mechanisms implementing transmission confidentiality and integrity
            protection; FIPS-validated cryptographic mechanisms.

Key Assessor Test Procedures:

  1. Use SSL/TLS testing tool (e.g., testssl.sh, Qualys SSL Labs, nmap --script ssl*)
     to verify that TLS 1.0 and TLS 1.1 are NOT negotiable on any in-scope
     endpoint. A finding of TLS 1.0 or 1.1 being accepted = OTS finding.

  2. Verify cipher suites offered do not include RC4, 3DES, NULL, EXPORT, or
     any anonymous (aNULL) cipher suites.

  3. Confirm that all cipher suites offered use ECDHE or DHE key exchange
     (forward secrecy). RSA key exchange (non-ephemeral) = OTS finding.

  4. Verify FIPS 140-2 or 140-3 CMVP certificate numbers are current and active
     on the NIST CMVP website for all cryptographic modules in use.

  5. Test at least three representative endpoints covering: (a) external
     user-facing HTTPS, (b) API endpoint, (c) internal service-to-service path.

  6. Review certificate attributes: key length, signature algorithm, validity
     period, revocation mechanism. SHA-1 signatures = OTS finding.

  7. Verify HTTP (port 80) is either disabled or redirects to HTTPS with HSTS.
     HTTP accepted without redirect = OTS finding.

  8. Review IaC or configuration management records to confirm TLS settings
     are version-controlled and subject to change control (CM-3).

  9. Confirm the SC-8(1) implementation links to SC-13 (only approved algorithms
     used) and SC-28(1) (complementary at-rest encryption in place).

  10. Verify there are no active POA&M items related to deprecated TLS versions
      or weak cipher suites that have exceeded their scheduled completion date.

--------------------------------------------------------------------------------
ORGANIZATION-DEFINED VALUES (ODVs)
--------------------------------------------------------------------------------

  ODV Parameter                             Assigned Value
  ----------------------------------------- ----------------------------------
  Minimum TLS protocol version              TLS 1.2
  Preferred TLS protocol version            TLS 1.3
  Prohibited protocol versions              SSL v2, SSL v3, TLS 1.0, TLS 1.1
  Minimum RSA key length                    2048 bits
  Minimum ECC key length (curve)            256 bits (P-256 / secp256r1)
  FIPS validation requirement               FIPS 140-2 or FIPS 140-3 (active
                                            CMVP certificate required)
  TLS scan frequency                        Monthly (or upon significant change)
  Certificate maximum validity period       398 days (external); 825 days
                                            (internal, per PKI policy)
  OCSP/CRL checking                         Required for all certificate
                                            validations

--------------------------------------------------------------------------------
REVISION HISTORY
--------------------------------------------------------------------------------

Version  Date        Author        Description
-------- ----------- ------------- -------------------------------------------
1.0      2026-05-07  [ISSO Name]   Initial narrative — SC-8(1) Moderate baseline
                                   implementation; TLS 1.2/1.3, FIPS 140-2/3,
                                   SC-13 and SC-28(1) linkage documented.

--------------------------------------------------------------------------------
REFERENCES
--------------------------------------------------------------------------------

  - NIST SP 800-53 Rev 5, SC-8 and SC-8(1) — Transmission Confidentiality
    and Integrity | Cryptographic Protection (September 2020)
  - NIST SP 800-53B — Control Baselines for Information Systems and
    Organizations (October 2020)
  - NIST SP 800-53A Rev 5 — Assessing Security and Privacy Controls
    (January 2022) — SC-8(1) assessment procedures
  - NIST SP 800-52 Rev 2 — Guidelines for TLS Implementations (August 2019)
    [TLS 1.0/1.1 deprecated; TLS 1.3 recommended]
  - NIST SP 800-175B Rev 1 — Guideline for Using Cryptographic Standards
    in the Federal Government: Cryptographic Mechanisms (March 2020)
  - FIPS 140-2 / FIPS 140-3 — Security Requirements for Cryptographic Modules
  - FIPS 199 — Standards for Security Categorization of Federal Information
    and Information Systems
  - FIPS 200 — Minimum Security Requirements for Federal Information Systems
  - RFC 8996 — Deprecating TLS 1.0 and TLS 1.1 (March 2021)
  - RFC 7568 — Deprecating Secure Sockets Layer Version 3.0 (June 2015)
  - OMB M-22-09 — Moving the US Government Toward Zero Trust Cybersecurity
    Principles (January 2022)
  - NIST CMVP — Cryptographic Module Validation Program:
    https://csrc.nist.gov/projects/cryptographic-module-validation-program

================================================================================
END OF SC-8(1) CONTROL NARRATIVE
================================================================================

SSP CONTROL NARRATIVE
System Security Plan (SSP) — Control Implementation Description

Control:        SC-8(1) — Transmission Confidentiality and Integrity | Cryptographic Protection
Impact Level:   Moderate
Date:           2026-05-07

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CONTROL STATEMENT (REFERENCE)

SC-8(1): The information system implements cryptographic mechanisms to prevent
unauthorized disclosure of information and detect changes to information during
transmission unless otherwise protected by [organization-defined alternative
physical safeguards].

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

RESPONSIBLE ROLES

Control Owner:          Chief Information Security Officer (CISO)
Implementation Owner:   Infrastructure / Platform Engineering Team
Review Frequency:       Annual and upon significant change


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART A — CONTROL SUMMARY

This system implements FIPS 140-2/140-3 validated cryptographic mechanisms on
all transmission paths to protect the confidentiality and integrity of federal
information in transit. Cryptographic protection applies to all data flows
between end users and the system, between system components, and between this
system and external services or interconnected systems. No unencrypted
transmission of sensitive federal data is permitted across any network boundary,
including internal network segments carrying CUI or other sensitive information.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART B — IMPLEMENTATION NARRATIVE

1. CRYPTOGRAPHIC STANDARDS AND FIPS COMPLIANCE

   The organization enforces the use of FIPS 140-2 validated (or FIPS 140-3
   validated where available) cryptographic modules for all transmission
   encryption across the system boundary. This requirement is codified in the
   organization's Cryptographic Policy and enforced through system configuration
   baselines.

   Approved algorithms in use include:
   - Symmetric encryption:  AES-256 (GCM or CBC mode with HMAC-SHA-256) for
                            bulk data encryption in transit.
   - Asymmetric / key exchange: ECDHE (P-256 or P-384 curves) or RSA-2048+
                                for session key establishment.
   - Integrity / authentication: HMAC-SHA-256 or HMAC-SHA-384; digital
                                 signatures using RSA-2048+ or ECDSA P-256.
   - Hash functions:        SHA-256 or SHA-384 (SHA-1 is prohibited).

   Use of MD5, RC4, DES, 3DES, export-grade ciphers, and SSL 3.0 / TLS 1.0 /
   TLS 1.1 is explicitly prohibited and blocked at the infrastructure level.


2. EXTERNAL-FACING TRANSMISSION PATHS (USER TO SYSTEM)

   All user-facing interfaces — including the web application portal, REST APIs,
   and any mobile or thick-client endpoints — enforce TLS 1.2 at minimum, with
   TLS 1.3 preferred. This is enforced at the Application Load Balancer / TLS
   termination layer.

   TLS configuration enforces:
   a. Strong cipher suites only (e.g., TLS_AES_256_GCM_SHA384 for TLS 1.3;
      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS 1.2 fallback).
   b. Perfect Forward Secrecy (PFS) through ECDHE key exchange, ensuring
      session keys cannot be retroactively decrypted if long-term keys are
      compromised.
   c. Server certificate validation using a certificate issued by a NIST-
      approved or FedRAMP-authorized Certificate Authority (CA), with
      certificates following a 2-year maximum validity cycle.
   d. HSTS (HTTP Strict Transport Security) headers with a minimum max-age of
      31,536,000 seconds, preventing protocol downgrade attacks.
   e. HTTP is redirected to HTTPS at the load balancer layer; plain HTTP
      connections are rejected and logged.

   TLS cipher suite and protocol enforcement is validated quarterly using
   automated scanning tools (e.g., SSL Labs API or equivalent government-
   approved tooling) and upon any change to TLS termination configuration.


3. INTERNAL / EAST-WEST TRANSMISSION PATHS (COMPONENT TO COMPONENT)

   Data flows between internal system components — including microservices,
   application servers, database servers, message queues, and caching layers —
   are encrypted in transit using mutual TLS (mTLS) 1.2/1.3 enforced by the
   service mesh (e.g., Istio, Linkerd, or equivalent). This ensures that both
   the calling and receiving services authenticate each other and that the
   channel is encrypted, preventing lateral-movement-based interception even
   within the private network.

   Specific internal paths and their cryptographic controls:
   a. Application tier to database tier: TLS 1.2+ enforced at the database
      driver/connector level; certificates issued by the internal private CA
      managed by the organization. Database connections using cleartext are
      rejected by firewall policy.
   b. Application tier to cache (e.g., Redis / ElastiCache): TLS enforced at
      the client configuration; in-transit encryption enabled at the managed
      service level.
   c. Application tier to message broker (e.g., Kafka, SQS, RabbitMQ): TLS
      1.2+ enforced; messages containing CUI additionally apply envelope
      encryption at the application layer prior to queuing.
   d. Container-to-container communication within Kubernetes clusters: Network
      policies restrict pod-to-pod traffic; mTLS enforced via the service mesh
      for all sensitive service communication.

   Where physical separation of network segments (e.g., dedicated private
   subnets, VLANs with no routing to untrusted segments) is employed as an
   alternative or complementary safeguard, this is documented in the system's
   network diagram and the relevant segment is identified in the SSP as
   operating under [organization-defined alternative physical safeguards].
   However, even in those cases, TLS encryption is applied as defense-in-depth.


4. INTERCONNECTIONS WITH EXTERNAL SYSTEMS AND THIRD PARTIES

   All connections to interconnected systems — federal agencies, cloud service
   providers (CSPs), SaaS vendors, or other system interconnections governed by
   Interconnection Security Agreements (ISAs) / Memoranda of Understanding
   (MOUs) — traverse encrypted channels:

   a. Encrypted VPN tunnels (IPsec IKEv2 with AES-256-GCM and SHA-256
      integrity) or dedicated encrypted private circuits are used for
      site-to-site connections to partner agency networks.
   b. API-based integrations with external CSPs or SaaS use TLS 1.2+;
      API gateway configurations reject connections using deprecated protocols.
   c. SFTP or FTPS (TLS-based) with AES-256 is used for any scheduled bulk
      file transfers; plain FTP is prohibited and blocked by firewall ACL.
   d. Email containing CUI uses S/MIME or encrypted secure file transfer
      portals; unencrypted SMTP for CUI is prohibited.


5. CERTIFICATE AND KEY MANAGEMENT

   The organization maintains a Certificate Management Procedure that governs
   the full lifecycle of all certificates used for transmission encryption:

   a. Certificate issuance: Certificates are issued by a NIST SP 800-57-
      compliant CA. Public-facing certificates use a publicly trusted CA;
      internal certificates use the organization's private CA integrated with
      the enterprise PKI.
   b. Key length and algorithm: RSA keys are minimum 2048-bit; ECC keys use
      P-256 or P-384 curves.
   c. Certificate validity: Maximum validity period is 2 years for internal
      certificates; 1 year for public-facing certificates, aligned with current
      CA/Browser Forum and NIST guidance.
   d. Certificate renewal: Automated renewal processes (e.g., ACME protocol /
      Let's Encrypt for public certs, or enterprise SCEP/EST for internal certs)
      are in place to renew certificates at least 30 days before expiration.
      Expiration monitoring alerts are configured with a 60-day and 14-day
      notification threshold.
   e. Certificate revocation: CRL and/or OCSP stapling is configured to enable
      revocation checking. Compromised certificates are revoked within 24 hours
      of confirmed compromise.
   f. Private key protection: Private keys for TLS certificates are stored in
      a Hardware Security Module (HSM) or a FIPS 140-2 Level 2 validated
      secrets management solution (e.g., HashiCorp Vault with HSM backing, AWS
      CloudHSM, or Azure Key Vault HSM tier). Keys are never stored in plaintext
      in configuration files, source code repositories, or environment variables.
   g. Key rotation: Session keys are ephemeral (PFS ensures new keys per
      session). Long-term signing and encryption keys follow the organization's
      key rotation schedule (minimum annual rotation for RSA/ECC keys, or upon
      suspected compromise).


6. ENFORCEMENT AND PREVENTION OF NON-ENCRYPTED TRANSMISSIONS

   Technical controls are implemented to prevent non-encrypted transmissions:

   a. Network Security Groups (NSGs) / firewall rules block inbound and
      outbound cleartext protocol ports (TCP/21 for FTP, TCP/23 for Telnet,
      TCP/80 for HTTP as a destination, TCP/143 for IMAP cleartext, etc.) at
      the network perimeter and internal segment boundaries.
   b. Web Application Firewall (WAF) rules are configured to block HTTP
      requests and enforce HTTPS.
   c. Configuration management tooling (e.g., Ansible, Terraform) enforces
      TLS-enabled configurations as code and flags any non-compliant
      configuration as a policy violation in the CI/CD pipeline prior to
      deployment.
   d. Compliance-as-code / SIEM alerting triggers an alert and creates a
      security incident ticket if a network flow is detected on a prohibited
      cleartext protocol port involving a system asset.


7. OPERATING SYSTEM AND APPLICATION HARDENING SUPPORTING SC-8(1)

   System hardening baselines (aligned with DISA STIGs or CIS Benchmarks at
   Level 2, as applicable) include specific settings that support transmission
   encryption enforcement:

   a. SSH is configured to use only SSHv2; SSHv1 is disabled. SSH ciphers are
      restricted to AES-128-CTR, AES-192-CTR, AES-256-CTR, AES-128-GCM,
      AES-256-GCM; weak ciphers (arcfour, 3des-cbc, blowfish) are disabled.
   b. Operating system TLS libraries (e.g., OpenSSL) are maintained at current
      patch levels and configured to enforce minimum TLS 1.2.
   c. Application frameworks are configured with TLS-only modes; application
      configuration is reviewed during security code review to confirm no
      cleartext fallback options are enabled.


8. MONITORING, AUDITING, AND CONTINUOUS MONITORING

   The effectiveness of cryptographic transmission controls is continuously
   monitored:

   a. Network traffic analysis tools (IDS/IPS with SSL inspection capability
      on perimeter flows) monitor for anomalous unencrypted traffic or use of
      deprecated TLS versions.
   b. Automated TLS/SSL configuration scanning is performed quarterly and after
      changes to identify any protocol or cipher suite weaknesses.
   c. Certificate expiration monitoring is automated; alerts are sent to the
      security operations team at 60-day and 14-day intervals before expiration.
   d. SIEM dashboards include metrics for TLS protocol version distribution
      across detected sessions; deviations from expected TLS 1.2/1.3 usage
      trigger investigation.
   e. Annual penetration testing explicitly includes testing for SSL/TLS
      weaknesses (e.g., BEAST, POODLE, DROWN, ROBOT attack susceptibility)
      and validates that no downgrade attacks are possible.
   f. Results of TLS scanning and certificate audits are retained as artifacts
      in the continuous monitoring repository and are made available to the AO
      and assessors upon request.


9. POLICIES AND PROCEDURES SUPPORTING THIS CONTROL

   The following organizational policies and procedures directly govern SC-8(1)
   implementation:

   - Cryptographic Policy (CP-001): Defines approved algorithms, key lengths,
     and prohibited ciphers in alignment with NIST SP 800-175B.
   - System and Communications Protection Policy (SCP-001): Establishes the
     organization's requirement for encryption of all sensitive data in transit.
   - Certificate Management Procedure (CMP-001): Documents the lifecycle
     management of all cryptographic certificates used by the system.
   - Network Security Policy (NSP-001): Defines prohibited cleartext protocols
     and firewall rule requirements.
   - Configuration Management Policy (CMP-002): Ensures TLS configurations
     are included in baseline configurations subject to change control.

   All policies are reviewed annually and approved by the CISO.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART C — EVIDENCE ARTIFACTS (FOR 3PAO ASSESSMENT)

The following artifacts should be provided to the 3PAO assessor to substantiate
this control implementation:

1. Network architecture / data flow diagrams annotating all transmission paths
   and the encryption protocol applied to each.
2. TLS/SSL configuration scan reports (e.g., SSL Labs API output or equivalent)
   for all external-facing endpoints, dated within the last 90 days.
3. Firewall / Network Security Group rule exports demonstrating that cleartext
   protocol ports are blocked.
4. Current certificate inventory (hostname, CA, algorithm, key length,
   expiration date) for all system certificates.
5. FIPS 140-2/140-3 certificate numbers for cryptographic modules in use
   (reference NIST CMVP database listings).
6. Configuration management baseline excerpts showing TLS enforcement settings
   for load balancers, web servers, database connectors, and service mesh.
7. Organization's Cryptographic Policy and Certificate Management Procedure.
8. Evidence of mTLS enforcement in service mesh (e.g., Istio PeerAuthentication
   policy configuration screenshots or exports).
9. HSM or secrets manager configuration evidence showing private key storage
   protection.
10. Penetration test report excerpt covering TLS/SSL testing results (most
    recent annual test).
11. SIEM alert rules and sample alert evidence for cleartext protocol detection.
12. Certificate expiration monitoring alert configuration and evidence.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART D — RELATED CONTROLS

SC-8         Transmission Confidentiality and Integrity (base control)
SC-8(2)      Pre/Post Transmission Handling
SC-12        Cryptographic Key Establishment and Management
SC-13        Cryptographic Protection
SC-17        Public Key Infrastructure Certificates
SC-28        Protection of Information at Rest
IA-3         Device Identification and Authentication (supports mTLS)
SA-9         External Information System Services (ISAs/MOUs)
AU-2 / AU-12 Audit Events / Audit Record Generation (logging of TLS events)
CM-6         Configuration Settings (enforcing TLS baselines)
CM-7         Least Functionality (disabling cleartext protocols)


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART E — CONTROL ORIGINATION AND INHERITANCE

Control Origination:    Hybrid
  - Inherited (from CSP/FedRAMP Authorized IaaS/PaaS, if applicable):
      The underlying infrastructure provider's FedRAMP authorization inherits
      physical layer protections and some network-layer encryption services
      (e.g., encrypted VPC peering, underlying TLS libraries on managed
      services). Specific inherited capabilities are documented in the
      Customer Responsibility Matrix (CRM) provided by the CSP.
  - System-Specific (this system's responsibility):
      Application-layer TLS configuration, certificate management, cipher
      suite enforcement, mTLS for internal service communication, prohibition
      of cleartext protocols via firewall policy, and all monitoring and
      auditing activities described above are the responsibility of this
      system's operators.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART F — PARAMETER VALUES (ORGANIZATION-DEFINED)

Per SC-8(1), the organization has defined the following parameter:

  [organization-defined alternative physical safeguards]:
      Dedicated private network segments (air-gapped or VLAN-isolated) within
      the organization's classified enclave for intra-enclave processing paths
      that are physically secured and access-controlled. These segments are
      documented in the network architecture diagram (Appendix [X]) and are
      subject to physical access controls per PE-3. Cryptographic encryption
      is applied as an additional layer even on these segments.

  Note: For Moderate impact systems, physical safeguards alone are NOT accepted
  as a substitute for cryptographic protection on any path that traverses a
  shared or untrusted network segment. Cryptographic protection is therefore
  applied universally across this system's transmission paths.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

IMPLEMENTATION STATUS:  Implemented
ASSESSMENT RESULT (PLACEHOLDER):  [To be completed by 3PAO]
DATE OF LAST REVIEW:    2026-05-07
NEXT SCHEDULED REVIEW:  2027-05-07

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

================================================================================
NIST SP 800-53 EXPERT RESPONSE
Topic: FedRAMP Moderate Authorization for ISO 27001:2022-Certified Organizations
================================================================================

QUESTION: We are preparing for our first FedRAMP Moderate authorization. We
currently have ISO 27001:2022 certification. What is the relationship between SP
800-53 Moderate controls and ISO 27001:2022 Annex A, what gaps will we likely
have, and how does the RMF process work for FedRAMP?

================================================================================
SECTION 1 — ISO 27001:2022 ANNEX A → SP 800-53 MODERATE CONTROL FAMILY MAPPING
================================================================================

ISO 27001:2022 and NIST SP 800-53 Rev 5 share substantial conceptual overlap,
but they differ in scope, prescriptiveness, and the specific controls each
requires. Your ISO 27001:2022 certification provides a meaningful starting point,
but it is not a substitute for the SP 800-53 Moderate baseline. The table below
maps each ISO 27001:2022 Annex A control domain to the corresponding SP 800-53
Rev 5 control family (or families) and identifies the nature of the alignment.

--------------------------------------------------------------------------------
ISO 27001:2022 Annex A Domain          | SP 800-53 Rev 5 Family / Controls
--------------------------------------------------------------------------------
5.1–5.14 Organizational Controls       | PL (Planning), PM (Program Mgmt),
  (Policies, roles, asset mgmt,        |   PS (Personnel Security),
  info classification, supplier        |   RA (Risk Assessment),
  security, threat intelligence,       |   SA (System & Services Acquisition),
  incident management)                 |   SR (Supply Chain Risk Management)
                                       |
5.15–5.18 Access Control               | AC (Access Control): AC-1 through
  (Access rights, privileged           |   AC-25; particularly AC-2, AC-3,
  access, information access           |   AC-5, AC-6, AC-17
  restriction, authentication)         |
                                       |
5.19–5.22 Supplier Relationships       | SR-1 through SR-12 (Supply Chain
  (Supplier security policy,           |   Risk Management); SA-9 (External
  managing supplier services,          |   System Services)
  cloud services)                      |
                                       |
5.23–5.28 Incident Management          | IR-1 through IR-10 (Incident
  (Planning, reporting, response,      |   Response); CA-2 (Assessments);
  lessons learned)                     |   AU (Audit & Accountability)
                                       |
5.29–5.30 Business Continuity          | CP-1 through CP-13 (Contingency
  (ICT continuity, redundancy)         |   Planning); CP-7, CP-9, CP-10
                                       |
5.31–5.36 Legal / Compliance           | CA (Assessment, Authorization,
  (Legal requirements, IP, privacy,    |   Monitoring); PT (PII Processing
  evidence, compliance review)         |   & Transparency); RA-5
                                       |
5.37 Documented Operating Procedures   | CM-1 (Config Policy); PL-2 (SSP)
                                       |
6.1–6.8 People Controls                | AT-1 through AT-6 (Awareness &
  (Screening, terms, awareness,        |   Training); PS-1 through PS-9
  training, disciplinary, remote       |   (Personnel Security); AC-17
  working, reporting)                  |
                                       |
7.1–7.14 Physical Controls             | PE-1 through PE-23 (Physical &
  (Physical perimeter, entry,          |   Environmental Protection)
  securing offices, monitoring,        |
  delivery areas, equipment)           |
                                       |
8.1–8.2 Operational Security           | CM-2, CM-6 (Configuration);
  (User endpoint devices,              |   SC-28 (Data at Rest)
  privileged access workstations)      |
                                       |
8.3–8.8 Asset / Vulnerability Mgmt     | CM-8 (Inventory); RA-5 (Vuln
  (Info deletion, masking,             |   Scanning); SI-2 (Patching);
  data leakage prevention,             |   MP (Media Protection)
  vulnerability management)            |
                                       |
8.9–8.13 Configuration & Change        | CM-1 through CM-14 (Config Mgmt);
  (Configuration mgmt, info            |   CP-9, CP-10 (Backup/Recovery);
  deletion, data backup)               |   SA-10 (Developer Config Mgmt)
                                       |
8.14–8.16 Redundancy / Monitoring      | CP-7, CP-11 (Availability);
  (Redundancy, monitoring,             |   AU-2 through AU-13 (Audit);
  logging, clock sync)                 |   SI-4 (System Monitoring)
                                       |
8.17–8.22 Network Security             | SC-1 through SC-51 (System &
  (Network segmentation, web           |   Communications Protection);
  filtering, cryptography,             |   SC-7, SC-8, SC-28; IA controls
  network connections)                 |
                                       |
8.23–8.28 Application Security         | SA-11, SA-15 (Dev Security Testing);
  (Secure development, testing,        |   SI-3 (Malware); SC-18
  source code)                         |   (Mobile Code)
                                       |
8.29–8.32 Secure Dev / Change          | SA-3 (SDLC); CM-3, CM-4 (Change
  (DevSecOps, outsourced dev,          |   Control); SA-8, SA-10, SA-11
  separation environments, change      |
  management)                          |
                                       |
8.33–8.34 Test / Audit                 | CA-2 (Security Assessments);
  (Test information, protection        |   RA-5; AU (Audit); SA-11
  of audit tools)                      |
--------------------------------------------------------------------------------

SUMMARY OF ALIGNMENT: Your ISO 27001:2022 certification confirms that you have a
functioning Information Security Management System (ISMS) covering policy,
risk assessment, supplier management, incident response, physical security,
business continuity, and access control at an organizational level. SP 800-53 Rev 5
derives from a common heritage with ISO 27001 and the two frameworks share roughly
70–80% conceptual overlap at the domain level.

However, alignment at the domain level does not equate to compliance at the
control level. SP 800-53 is significantly more prescriptive, more granular, and
carries U.S. federal-law specificity that ISO 27001 does not.

================================================================================
SECTION 2 — FEDRAMP MODERATE GAPS FOR ISO 27001:2022-CERTIFIED ORGANIZATIONS
================================================================================

The gaps below represent areas where ISO 27001:2022 certification typically
provides little or no coverage for FedRAMP Moderate requirements. These are
the highest-priority remediation items.

--------------------------------------------------------------------------------
GAP 1 — FIPS 140-2 / FIPS 140-3 VALIDATED CRYPTOGRAPHIC MODULES
--------------------------------------------------------------------------------
Controls: SC-13 (Cryptographic Protection), IA-7 (Cryptographic Module Auth)
Baseline: Moderate (required)

ISO 27001:2022 Annex A 8.24 requires "use of cryptography" and says
algorithms must be "appropriate." It does not mandate FIPS 140-validated
modules.

FedRAMP requirement: ALL cryptographic modules used in the system must be
validated to FIPS 140-2 or FIPS 140-3 (the successor standard). This applies
to:
  - TLS/HTTPS implementations (must use FIPS-approved cipher suites)
  - Data-at-rest encryption (SC-28; disk encryption libraries must be validated)
  - VPN / remote access tunnels (SC-8(1))
  - SSH implementations
  - Any key management system

Action items:
  - Inventory all cryptographic implementations across the system
  - Verify each against the NIST Cryptographic Module Validation Program (CMVP)
    at csrc.nist.gov/projects/cryptographic-module-validation-program
  - Replace or reconfigure any non-validated modules (e.g., OpenSSL must be
    used in FIPS mode with a FIPS 140-2/3 validated build)
  - Document FIPS validation certificate numbers in the SSP under SC-13

--------------------------------------------------------------------------------
GAP 2 — PIV / PIV-INTEROPERABLE MULTI-FACTOR AUTHENTICATION (MFA)
--------------------------------------------------------------------------------
Controls: IA-2(1), IA-2(2), IA-2(12), IA-8(1), IA-8(2), IA-8(4)
Baseline: Moderate (required)

ISO 27001:2022 Annex A 8.5 ("Secure Authentication") requires MFA for
privileged access but does not specify PIV (Personal Identity Verification)
cards as the required authenticator type.

FedRAMP/HSPD-12 requirement: Federal policy (OMB M-11-11, HSPD-12, OMB
M-19-17) mandates that all privileged users and all users accessing
federal systems use PIV credentials or PIV-Interoperable (PIV-I) credentials
for network authentication:

  - IA-2(1): MFA for privileged accounts (network access) — PIV required
  - IA-2(2): MFA for non-privileged accounts (network access) — PIV or
    PIV-I required for federal employee/contractor access
  - IA-2(12): PIV credentials accepted and verified
  - IA-8(1)/(2)/(4): Non-organizational users (public, contractors not
    issued PIV) must use NIST IAL/AAL-aligned credentials per SP 800-63B

Action items:
  - Implement PIV card authentication for all privileged users
  - For SaaS/cloud offerings, implement PIV-compatible identity federation
    via SAML or OIDC with a PIV-capable IdP (e.g., Azure AD Government,
    Okta FedRAMP, Ping Identity FedRAMP)
  - Document authenticator types, IAL/AAL levels, and PIV certificate
    validation procedures in SSP IA-2 narratives

--------------------------------------------------------------------------------
GAP 3 — CONTINUOUS MONITORING (CONMON) FREQUENCIES
--------------------------------------------------------------------------------
Controls: CA-7 (Continuous Monitoring), RA-5 (Vulnerability Monitoring),
          SI-2 (Flaw Remediation), CM-6 (Configuration Settings)
Baseline: Moderate (required)

ISO 27001:2022 requires vulnerability management and monitoring but does not
specify frequencies. FedRAMP ConMon requirements are prescriptive:

  Activity                          | FedRAMP Frequency
  ----------------------------------|-------------------
  OS vulnerability scans            | Monthly
  Web application vulnerability scans| Monthly
  Database vulnerability scans      | Weekly
  Annual 3PAO control assessment    | Annual
  Annual penetration test (3PAO)    | Annual
  POA&M updates                     | Monthly
  Inventory updates                 | Monthly
  Significant Change Requests       | Before major changes

Remediation deadlines (FedRAMP):
  - Critical vulnerabilities: 30 days
  - High vulnerabilities: 90 days
  - Moderate vulnerabilities: 180 days
  - Low vulnerabilities: 1 year (or risk acceptance)

Action items:
  - Implement automated vulnerability scanning at required FedRAMP frequencies
  - Stand up a monthly POA&M management process
  - Procure a 3PAO-accredited assessor for annual assessment and penetration test
  - Document ConMon strategy in CA-7 SSP narrative with specific frequencies
    and responsible parties
  - Establish a FedRAMP Significant Change Request process

--------------------------------------------------------------------------------
GAP 4 — US-CERT / CISA INCIDENT REPORTING
--------------------------------------------------------------------------------
Controls: IR-6 (Incident Reporting), IR-6(1), IR-7, IR-8
Baseline: Moderate (required)

ISO 27001:2022 Annex A 5.26 ("Response to information security incidents")
and 5.27 require incidents be managed and lessons learned, but reporting
timelines are organization-defined. ISO 27001 does not require reporting to
external government bodies.

FedRAMP incident reporting requirements (OMB M-17-25, US-CERT Federal
Incident Notification Guidelines):
  - All security incidents affecting federal data must be reported to US-CERT
    (now CISA) within 1 hour of discovery for critical/major incidents
  - Monthly operational reports to FedRAMP PMO and agency Authorizing Official
  - Incident handling procedures must reference the US-CERT reporting portal
    and use US-CERT severity categories (CAT 0 through CAT 6)

FedRAMP IR-6 ODV (Organization-Defined Value): Report within 1 hour to
FedRAMP PMO and agency customer(s); submit US-CERT notification within
1 hour for CAT 1/2 incidents.

Action items:
  - Update IR policy and procedures to include US-CERT/CISA reporting
    obligations and timelines
  - Train incident response team on FedRAMP-specific reporting procedures
  - Establish secure communications channel with agency customers for
    incident notification
  - Document IR-6 SSP narrative with specific reporting timelines and
    escalation procedures
  - Include IR-8 (Incident Response Plan) that references FedRAMP IR
    Playbook template

--------------------------------------------------------------------------------
GAP 5 — THIRD-PARTY ASSESSMENT ORGANIZATION (3PAO) REQUIREMENT
--------------------------------------------------------------------------------
Controls: CA-2 (Control Assessments), CA-8 (Penetration Testing)
Baseline: FedRAMP-specific requirement (not in standard SP 800-53B baseline)

ISO 27001:2022 requires internal audits (Clause 9.2) and management review
(Clause 9.3), and certification body audits. However, the ISO certification
body (CB) auditor is not equivalent to a FedRAMP 3PAO.

FedRAMP requirement: All assessments must be conducted by an accredited 3PAO:
  - 3PAOs must be accredited by either:
    a. American Association for Laboratory Accreditation (A2LA) under R311
    b. FedRAMP PMO directly (for select organizations)
  - The 3PAO conducts the initial assessment (producing the SAR) and all
    annual assessments thereafter
  - 3PAOs must be independent from the CSP — internal teams cannot serve
    as the 3PAO

Action items:
  - Identify and engage an accredited 3PAO early in the process
    (list available at marketplace.fedramp.gov)
  - Budget for initial 3PAO assessment (typically 6–18 weeks engagement)
    and recurring annual assessments
  - Provide 3PAO with a complete readiness package: SSP, policies,
    architecture diagrams, system inventory, prior audit evidence
  - Consider engaging 3PAO for a FedRAMP Readiness Assessment (FRA)
    before the full assessment to identify gaps

--------------------------------------------------------------------------------
GAP 6 — FEDRAMP ORGANIZATION-DEFINED VALUES (ODVs)
--------------------------------------------------------------------------------
Controls: Multiple — AC-2(3), AC-7, AU-11, IA-5(1), SI-2, CA-7, and others
Baseline: FedRAMP-specific parameter values

ISO 27001:2022 leaves most operational parameters to the organization
(e.g., password complexity, log retention, account lockout thresholds).
FedRAMP prescribes specific ODV values that override organization discretion.

Key FedRAMP ODV requirements for Moderate systems:

  Control   | Parameter                        | FedRAMP Required Value
  ----------|----------------------------------|------------------------
  AC-2(3)   | Disable inactive accounts after  | 90 days
  AC-7      | Account lockout threshold        | 3 invalid attempts
  AC-7      | Lockout duration                 | 30 minutes (or admin unlock)
  AU-11     | Audit log retention              | 90 days online; 1 year archived
  IA-5(1)   | Minimum password length          | 15 characters
  IA-5(1)   | Password complexity              | Upper, lower, number, special
  IA-5(1)   | Password history                 | 24 passwords remembered
  IA-5(1)   | Maximum password age             | 60 days (privileged);
            |                                  | No max for PIV/MFA accounts
  RA-5      | Vulnerability scan frequency     | Monthly (OS/web); Weekly (DB)
  SI-2      | Patch critical vulns within      | 30 days
  SI-2      | Patch high vulns within          | 90 days
  CA-7      | ConMon frequency                 | See Section 3 above

Action items:
  - Conduct an ODV gap analysis comparing your current operational parameters
    against FedRAMP-required values
  - Update technical configurations (AD Group Policy, SIEM retention settings,
    vulnerability scanner schedules) to meet FedRAMP ODVs
  - Document all ODVs explicitly in the SSP; FedRAMP reviewers specifically
    check that ODV parameters are populated (not left as "[organization-defined]")

--------------------------------------------------------------------------------
GAP 7 — FEDRAMP SSP TEMPLATE AND DOCUMENTATION FORMAT
--------------------------------------------------------------------------------
Controls: PL-2 (System Security Plan), CA-2, CA-7
Baseline: FedRAMP-specific requirement

ISO 27001:2022 requires a Statement of Applicability (SoA) and documented
ISMS policies, but does not specify SSP format.

FedRAMP requirement: CSPs must use the official FedRAMP SSP template
(available at fedramp.gov/documents-templates). The template is ~350+ pages
when fully completed and includes:

  - System description (architecture, boundaries, data flows)
  - FIPS 199 categorization determination
  - All 325+ Moderate baseline controls with implementation narratives
  - Responsible roles for each control
  - Implementation status (Implemented / Partially Implemented / Planned /
    Not Applicable)
  - Control inheritance designations (system-specific vs. inherited from CSP,
    IaaS/PaaS provider, or common control provider)
  - Customer responsibilities (controls customers must implement)

Additional FedRAMP package documents required:
  - System Security Plan (SSP) — FedRAMP template
  - SSP Attachments: Control Implementation Summary (CIS), Customer
    Responsibility Matrix (CRM), FIPS 199 categorization, system inventory,
    network diagrams, data flow diagrams, ports/protocols/services list
  - Security Assessment Plan (SAP) — developed by 3PAO
  - Security Assessment Report (SAR) — produced by 3PAO
  - Plan of Action and Milestones (POA&M) — maintained by CSP
  - FedRAMP Readiness Assessment Report (RAR) — optional but recommended

Action items:
  - Download the current FedRAMP SSP template from fedramp.gov
  - Map your existing ISO 27001 documentation (SoA, ISMS policies,
    risk assessment) to SSP sections — most will supplement rather than
    replace SSP narratives
  - Assign ISSO / compliance team to write control narratives for all
    325+ Moderate controls
  - Develop architecture diagrams and data flow diagrams at FedRAMP
    required detail level
  - Engage a FedRAMP consultant or use FedRAMP Marketplace CSP resources
    for SSP template guidance

--------------------------------------------------------------------------------
GAP SUMMARY TABLE
--------------------------------------------------------------------------------

Gap Area                | ISO 27001 Coverage  | FedRAMP Moderate Requirement
------------------------|---------------------|--------------------------------
FIPS 140 Cryptography   | "Appropriate algs"  | FIPS 140-2/3 validated modules
                        | (8.24)              | for ALL crypto (SC-13, IA-7)
PIV/PIV-I MFA           | MFA required (8.5)  | PIV cards required; SP 800-63B
                        |                     | IAL/AAL alignment (IA-2(1)(2)(12))
ConMon Frequencies      | Unspecified         | Monthly scans, weekly DB scans,
                        |                     | annual 3PAO assessment (CA-7)
US-CERT Incident        | Internal reporting  | 1-hour US-CERT reporting for
Reporting               | (5.26)              | major incidents (IR-6)
3PAO Requirement        | CB audits           | Accredited 3PAO for all
                        |                     | assessments (CA-2, CA-8)
FedRAMP ODVs            | Org-defined         | Specific numeric values mandated
                        |                     | (AC-2, AC-7, AU-11, IA-5, SI-2)
SSP / Package Format    | SoA + policies      | FedRAMP SSP template; full
                        |                     | authorization package (PL-2)

================================================================================
SECTION 3 — RMF PROCESS FOR FEDRAMP (SP 800-37 Rev 2 ADAPTED)
================================================================================

FedRAMP is operationalized through the NIST Risk Management Framework
(SP 800-37 Rev 2), adapted with FedRAMP-specific requirements. There are two
authorization paths:

  AGENCY ATO PATH: CSP works directly with a specific federal agency customer.
    The agency Authorizing Official (AO) grants an Authority to Operate (ATO).
    Fastest for single-agency relationships.

  JAB P-ATO PATH: CSP works with the Joint Authorization Board (JAB) —
    comprised of DoD CIO, DHS CIO, and GSA CIO. Results in a Provisional ATO
    (P-ATO) accepted by all federal agencies. Highest rigor; longest timeline.
    JAB prioritizes CSPs using the FedRAMP Connect process.

Both paths follow the same seven RMF steps:

--------------------------------------------------------------------------------
STEP 1 — PREPARE
SP 800-37 Rev 2, Chapter 2; FedRAMP: fedramp.gov/prepare/
--------------------------------------------------------------------------------
Purpose: Establish the organizational and system context; assign roles;
         understand the authorization path.

Key tasks for FedRAMP Moderate:
  1. Assign FedRAMP roles:
     - Authorizing Official (AO): agency CISO or designated senior official
       (for Agency ATO) or JAB representatives (for P-ATO)
     - System Owner (SO): CSP executive accountable for the system
     - Information System Security Officer (ISSO): manages day-to-day
       security operations and SSP
     - FedRAMP Point of Contact (POC): CSP contact for FedRAMP PMO
  2. Understand FedRAMP boundary: define what is "in scope" for authorization
     (the Authorization Boundary — all components processing, transmitting,
     or storing federal data)
  3. Select authorization path (Agency ATO vs. JAB P-ATO)
  4. Conduct initial gap assessment against FedRAMP Moderate baseline
  5. Develop remediation roadmap and project plan
  6. Register system in FedRAMP Marketplace (fedramp.gov/marketplace)
  7. Engage 3PAO early

Key outputs: Assigned roles; selected authorization path; gap remediation plan;
             FedRAMP Marketplace registration.

Timeline estimate: 1–3 months

--------------------------------------------------------------------------------
STEP 2 — CATEGORIZE
FIPS 199; SP 800-60; FedRAMP: FIPS 199 template
--------------------------------------------------------------------------------
Purpose: Determine the system's security impact level (Low, Moderate, or High)
         based on the federal data it processes, stores, and transmits.

Key tasks for FedRAMP Moderate:
  1. Identify all federal information types processed using SP 800-60 Vol II
  2. Assess Confidentiality, Integrity, and Availability impact for each type
  3. Apply the high-water mark: overall system category = highest C/I/A value
  4. For FedRAMP Moderate: system must be categorized as FIPS 199 Moderate
     (at least one of C/I/A = Moderate; none = High)
  5. Complete and sign the FIPS 199 Security Categorization document
     (AO and SO signatures required)
  6. Incorporate categorization into SSP Section 2

Note: If categorization yields a High impact level for any objective, the
system requires the FedRAMP High baseline (~421 controls), not Moderate.

Key outputs: Signed FIPS 199 Security Categorization document; system
             description in SSP Sections 1–2.

Timeline estimate: 2–4 weeks

--------------------------------------------------------------------------------
STEP 3 — SELECT
SP 800-53B (Moderate baseline); FedRAMP baseline documentation
--------------------------------------------------------------------------------
Purpose: Select, tailor, and document the controls for the system.

Key tasks for FedRAMP Moderate:
  1. Start with SP 800-53B Moderate baseline (~325 controls/enhancements)
  2. Apply FedRAMP overlay: FedRAMP-specific ODV values override the standard
     baseline parameters (see Gap 6 above)
  3. Identify inherited controls:
     - Controls implemented by your underlying IaaS/PaaS provider
       (e.g., AWS GovCloud, Azure Government, Google Cloud) that are inherited
     - Document in the Control Implementation Summary (CIS) and SSP
     - Your IaaS/PaaS provider must have a FedRAMP authorization for
       you to inherit their controls
  4. Identify customer-responsible controls: controls the agency customer
     must implement (document in Customer Responsibility Matrix — CRM)
  5. Identify system-specific controls: controls you implement yourself
  6. Assign ODV parameter values for all controls with organization-defined
     parameters (use FedRAMP-required values where specified)
  7. Document tailoring decisions in SSP
  8. Develop Continuous Monitoring Strategy (CA-7 narrative)

Key outputs: Complete control selection documented in SSP; ConMon strategy;
             CIS; CRM.

Timeline estimate: 2–4 months (dependent on SSP writing resources)

--------------------------------------------------------------------------------
STEP 4 — IMPLEMENT
SP 800-53 Rev 5 (implementation guidance); FedRAMP SSP template
--------------------------------------------------------------------------------
Purpose: Implement all selected controls and document implementation in the SSP.

Key tasks for FedRAMP Moderate:
  1. Implement all system-specific controls (technical, operational,
     and management controls)
  2. Write SSP control narratives for all ~325 controls:
     - For each control: what is implemented, how it is implemented,
       who is responsible, what evidence exists
     - Address all control parameters (ODV values must be populated)
     - Distinguish base control from enhancements
  3. Complete SSP attachments:
     - System architecture diagrams (with authorization boundary marked)
     - Data flow diagrams (showing federal data flows)
     - Network diagrams (logical and physical)
     - Hardware/software inventory (CM-8)
     - Ports, protocols, services list
     - User types and privileges list
  4. Conduct internal pre-assessment / readiness review
  5. Complete POC for FedRAMP Readiness Assessment (optional but strongly
     recommended for first-time authorizations)

Key outputs: Completed SSP with all narratives; all SSP attachments;
             implemented controls with evidence artifacts.

Timeline estimate: 3–9 months (typically the longest phase for first ATO)

--------------------------------------------------------------------------------
STEP 5 — ASSESS
SP 800-53A Rev 5; FedRAMP SAP/SAR templates; 3PAO-conducted
--------------------------------------------------------------------------------
Purpose: Determine if controls are implemented correctly, operating as intended,
         and producing the desired outcome.

Key tasks for FedRAMP Moderate:
  1. 3PAO develops Security Assessment Plan (SAP) using SP 800-53A procedures
     and FedRAMP SAP template
  2. CSP reviews and approves SAP; agency AO concurs (for Agency ATO path)
  3. 3PAO conducts assessment using three methods:
     - EXAMINE: Review SSP, policies, procedures, configuration files,
       architecture diagrams, audit logs, training records
     - INTERVIEW: Discuss implementation with ISSO, system administrators,
       operators, developers, end users
     - TEST: Run vulnerability scans, penetration test, configuration checks,
       firewall rule reviews, backup restoration tests, access control tests
  4. 3PAO produces Security Assessment Report (SAR):
     - Executive summary with authorization recommendation
     - Control-by-control findings (Satisfied vs. Other Than Satisfied)
     - Risk ratings for OTS findings
     - Penetration test results
  5. CSP responds to SAR findings:
     - Remediate findings where possible before authorization
     - Open POA&M items for findings not yet remediated
  6. CSP develops initial POA&M from SAR OTS findings

FedRAMP-specific assessment requirements:
  - Annual penetration test using FedRAMP penetration test guidance
  - Automated vulnerability scanning results submitted to FedRAMP PMO
  - FedRAMP SAR template must be used
  - 3PAO independence must be maintained (no conflict of interest)

Key outputs: SAP; SAR; initial POA&M; 3PAO authorization recommendation.

Timeline estimate: 2–4 months (3PAO assessment engagement)

--------------------------------------------------------------------------------
STEP 6 — AUTHORIZE
SP 800-37 Rev 2, Chapter 2.7; FedRAMP authorization process
--------------------------------------------------------------------------------
Purpose: Senior official (Authorizing Official) formally accepts residual risk
         and grants or denies Authority to Operate.

Authorization package (submitted to AO or JAB):
  1. System Security Plan (SSP) — with all attachments
  2. Security Assessment Report (SAR) — produced by 3PAO
  3. Plan of Action and Milestones (POA&M) — with remediation timelines
  4. FedRAMP Authorization Package cover letter / executive summary

Agency ATO path:
  - CSP submits complete authorization package to agency AO
  - Agency reviews package (often with FedRAMP PMO support)
  - Agency AO makes authorization decision:
    * Authorization to Operate (ATO) — risk is acceptable; valid for 1 year
      (with ConMon) or up to 3 years
    * Denial of Authorization to Operate (DATO) — risk not acceptable;
      system must not process federal data until remediated
  - ATO letter issued; system listed as "FedRAMP Authorized" in Marketplace

JAB P-ATO path:
  - FedRAMP PMO conducts package review (kick-off through final package)
  - JAB technical reviewers assess the package
  - JAB issues Provisional ATO (P-ATO) if risk is acceptable
  - P-ATO can be leveraged by all federal agencies (reduces per-agency review)

Key FedRAMP authorization metrics (Moderate systems):
  - No unmitigated Critical or High risks at time of authorization
  - Open High POA&M items must have realistic remediation plans
  - AO accepts residual risk for all open POA&M items

Key outputs: ATO letter (Agency path) or P-ATO letter (JAB path);
             FedRAMP Marketplace listing updated to "Authorized."

Timeline estimate: 1–4 months (Agency ATO); 6–18 months (JAB P-ATO)

--------------------------------------------------------------------------------
STEP 7 — MONITOR
SP 800-37 Rev 2, Chapter 2.8; SP 800-137; FedRAMP ConMon Guide
--------------------------------------------------------------------------------
Purpose: Maintain ongoing situational awareness about the security posture;
         detect and respond to changes; sustain the ATO.

FedRAMP ConMon ongoing requirements:
  1. Monthly deliverables to FedRAMP PMO and agency customers:
     - Vulnerability scan results (OS, web app — monthly; DB — weekly)
     - Updated POA&M (with remediation status)
     - Updated system inventory
     - Updated CIS (Control Implementation Summary)
  2. Annual deliverables:
     - Annual assessment by 3PAO (all controls or a selected subset per
       FedRAMP ConMon Strategy guide)
     - Annual penetration test by 3PAO
     - Updated SSP (reflecting any significant changes)
     - Annual security review
  3. Significant Change Requests (SCRs):
     - Required before making significant changes to the authorization
       boundary, architecture, or security posture
     - CSP submits SCR to FedRAMP PMO; may trigger re-assessment
     - Examples: new cloud region, new external service, major architecture
       change, new data type
  4. Incident reporting:
     - US-CERT / CISA notification within 1 hour for major incidents
     - Agency customer notification per SLA / contract terms
     - Monthly operational reports to FedRAMP PMO
  5. Ongoing POA&M management:
     - Monthly updates required
     - Critical items: remediate within 30 days
     - High items: remediate within 90 days
     - Risk acceptances require ISSO, SO, and AO approval
  6. FedRAMP Marketplace status maintenance:
     - System remains "Authorized" only with current ConMon deliverables
     - FedRAMP PMO may revoke authorization for ConMon non-compliance

Continuous Authorization (preferred): Rather than periodic full re-authorization
every 3 years, FedRAMP encourages continuous authorization — the AO remains
continuously informed via ConMon deliverables and makes ongoing risk acceptance
decisions. This avoids the "big bang" re-authorization cycle.

Key outputs: Monthly ConMon deliverables; updated POA&M; annual 3PAO assessment;
             incident reports; SCRs as needed; sustained ATO status.

================================================================================
SECTION 4 — RECOMMENDED FEDRAMP MODERATE READINESS ROADMAP
================================================================================

Based on your ISO 27001:2022 certification, we recommend the following phased
approach:

Phase 1 — Prepare and Gap Analysis (Months 1–2):
  - Complete FedRAMP Marketplace registration
  - Engage 3PAO for FedRAMP Readiness Assessment (FRA)
  - Conduct FIPS 140 cryptographic module inventory
  - Assess PIV/MFA gaps with your IdP vendor
  - Download FedRAMP SSP template and begin scoping

Phase 2 — Remediate Critical Gaps (Months 3–8):
  - Implement FIPS 140-validated cryptographic modules throughout
  - Implement PIV/PIV-I authentication via federated IdP
  - Configure all ODVs to FedRAMP-required values
  - Stand up monthly vulnerability scanning program
  - Update IR policy with US-CERT reporting procedures
  - Begin writing SSP control narratives (can leverage ISO SoA as input)
  - Complete architecture diagrams and data flow diagrams

Phase 3 — SSP Completion and Pre-Assessment (Months 6–10):
  - Complete all 325+ SSP control narratives
  - Complete all SSP attachments
  - Conduct internal readiness review
  - Engage 3PAO for formal readiness assessment (optional but recommended)
  - Remediate readiness assessment findings

Phase 4 — 3PAO Assessment (Months 10–14):
  - 3PAO develops SAP and conducts full assessment
  - Respond to SAR findings; remediate where possible
  - Open POA&M for unresolved findings

Phase 5 — Authorization (Months 14–18):
  - Submit authorization package to agency AO or JAB
  - Respond to agency / FedRAMP PMO review questions
  - Receive ATO / P-ATO

Phase 6 — Sustain ConMon (Month 18+):
  - Begin monthly ConMon deliverables
  - Annual 3PAO assessment and pen test
  - Maintain POA&M; remediate findings on schedule

================================================================================
KEY REFERENCES
================================================================================

  NIST SP 800-53 Rev 5    — Security and Privacy Controls (control catalog)
  NIST SP 800-53B         — Control Baselines (Moderate baseline definition)
  NIST SP 800-53A Rev 5   — Assessment Procedures
  NIST SP 800-37 Rev 2    — Risk Management Framework
  NIST SP 800-60 Vol I/II — Information Types and Impact Levels
  NIST SP 800-63B         — Digital Identity (authenticator assurance)
  NIST SP 800-137         — Continuous Monitoring
  FIPS 140-3              — Cryptographic Module Validation Standard
  FIPS 199                — Standards for Security Categorization
  FIPS 200                — Minimum Security Requirements
  FedRAMP.gov             — SSP template, baseline documentation, 3PAO list,
                            ConMon guide, incident communications guide
  CMVP (csrc.nist.gov)    — Cryptographic Module Validation Program
  FedRAMP Marketplace     — marketplace.fedramp.gov (authorized CSPs, 3PAOs)

================================================================================
END OF RESPONSE
================================================================================

EXPERT RESPONSE: FedRAMP Moderate Authorization — SP 800-53, ISO 27001:2022 Mapping, Gap Analysis, and RMF Process

==============================================================================
1. RELATIONSHIP BETWEEN NIST SP 800-53 MODERATE AND ISO 27001:2022 ANNEX A
==============================================================================

Both NIST SP 800-53 (Rev. 5) at the Moderate baseline and ISO 27001:2022 Annex A are comprehensive security control frameworks, but they differ substantially in origin, philosophy, scope, and prescriptiveness.

STRUCTURAL OVERVIEW:

- SP 800-53 Rev. 5 Moderate baseline contains approximately 323 controls and control enhancements across 20 control families (AC, AT, AU, CA, CM, CP, IA, IR, MA, MP, PE, PL, PM, PS, PT, RA, SA, SC, SI, SR).
- ISO 27001:2022 Annex A contains 93 controls organized into 4 themes: Organizational Controls (37), People Controls (8), Physical Controls (14), and Technological Controls (34).

PHILOSOPHICAL DIFFERENCES:

SP 800-53 is prescriptive, parameter-driven, and process-oriented. It specifies not just what to do but frequently how to do it, with defined frequencies, technical standards, and federal-specific requirements (e.g., FIPS 140-3 validated cryptography, PIV/CAC for multi-factor authentication, FISMA reporting requirements). Controls include specific parameter values at the Moderate baseline — for example, AU-11 requires audit log retention for a defined period, and the Moderate baseline specifies 3 years for some categories.

ISO 27001:2022 Annex A is risk-driven and principle-based. Organizations select controls from Annex A based on a Statement of Applicability (SoA) derived from their risk assessment. There is significant flexibility in implementation. ISO 27001 does not mandate specific cryptographic standards, specific authentication mechanisms, or prescribe audit retention periods.

CONTROL FAMILY CORRESPONDENCE (HIGH LEVEL):

The following rough mappings exist between SP 800-53 families and ISO 27001:2022 Annex A themes:

Access Control (AC) <-> 5.15-5.18 (Identity/Access Management), 8.2-8.5 (Logical access controls), 8.18-8.20
Audit and Accountability (AU) <-> 8.15 (Logging), 8.16 (Monitoring activities), 5.33 (Protection of records)
Security Assessment and Authorization (CA) <-> 5.35 (Independent review), 5.36 (Compliance with policies), 8.8 (Management of technical vulnerabilities)
Configuration Management (CM) <-> 8.9 (Configuration management), 8.32 (Change management)
Contingency Planning (CP) <-> 5.30 (ICT readiness for business continuity), 8.13 (Information backup), 8.14 (Redundancy)
Identification and Authentication (IA) <-> 5.16 (Identity management), 5.17 (Authentication information), 8.5 (Secure authentication)
Incident Response (IR) <-> 5.24-5.28 (Incident management), 6.8 (Information security event reporting)
Maintenance (MA) <-> 8.6 (Capacity management) — partial; SP 800-53 MA is more specific to federal asset maintenance
Media Protection (MP) <-> 7.10 (Storage media), 8.10 (Information deletion)
Physical and Environmental Protection (PE) <-> 7.1-7.14 (Physical controls)
Planning (PL) <-> 5.1 (Policies), 5.37 (Documented operating procedures)
Program Management (PM) <-> 5.1-5.8 (Organizational controls, GRC program)
Personnel Security (PS) <-> 6.1-6.5 (People controls: screening, terms, awareness, disciplinary process, offboarding)
PII Processing and Transparency (PT) <-> 5.34 (Privacy and protection of PII) — partial
Risk Assessment (RA) <-> 5.7 (Threat intelligence), 8.8 (Vulnerability management), 6.1.2 (Information security risk assessment in the main standard)
System and Services Acquisition (SA) <-> 5.19-5.22 (Supplier relationships), 8.25-8.31 (Secure development)
System and Communications Protection (SC) <-> 8.20-8.26 (Network security, segregation, filtering, cryptography)
System and Information Integrity (SI) <-> 8.7 (Malware protection), 8.8 (Vulnerability management), 8.16 (Monitoring)
Supply Chain Risk Management (SR) <-> 5.19-5.22 (Supplier security), 5.20 (Addressing security in supplier agreements)

IMPORTANT DISTINCTION: ISO 27001:2022 Annex A maps reasonably well to SP 800-53 at a conceptual level, but the SP 800-53 Moderate baseline contains many controls with no meaningful ISO 27001 equivalent, particularly those related to federal compliance mandates (FISMA, FedRAMP-specific requirements, federal authentication standards, SCIF requirements, etc.).


==============================================================================
2. LIKELY GAPS MOVING FROM ISO 27001:2022 TO SP 800-53 MODERATE (FedRAMP)
==============================================================================

Organizations with ISO 27001:2022 certification will typically find they have a strong foundation but significant gaps in the following areas:

GAP CATEGORY 1: FEDERAL-SPECIFIC TECHNICAL REQUIREMENTS

- Cryptography (SC-13, SC-28): FedRAMP mandates FIPS 140-3 validated cryptographic modules for all cryptographic operations. ISO 27001 A.8.24 requires "use of cryptography" but does not mandate FIPS validation. If your cloud service uses non-FIPS-validated libraries (e.g., standard OpenSSL builds, unvalidated TLS implementations), you must remediate this.

- Multi-Factor Authentication (IA-2, IA-2(1), IA-2(2)): FedRAMP Moderate requires MFA for all privileged accounts and remote access. More specifically, for federal information systems, PIV/CAC credentials are strongly preferred. ISO 27001 A.8.5 covers secure authentication but does not mandate specific mechanisms. You likely satisfy the general MFA requirement but may lack PIV/CAC capability.

- DNS Security (SC-20, SC-21, SC-22): FedRAMP requires DNSSEC implementation and validation. ISO 27001 does not address DNSSEC specifically.

- Email Security (SI-8): FedRAMP has specific requirements around anti-spam, anti-phishing (DMARC, DKIM, SPF) that go beyond ISO 27001's general malware protection controls.

GAP CATEGORY 2: AUTHORIZATION AND CONTINUOUS MONITORING

- Authority to Operate (CA-6): FedRAMP requires a formal ATO from an authorizing official (federal agency or JAB). There is no ISO 27001 equivalent — ISO 27001 certification is not an ATO. You must complete the full RMF authorization process.

- Continuous Monitoring (CA-7): FedRAMP's ConMon requirements are highly specific — monthly vulnerability scanning, annual penetration testing, ongoing POA&M management, monthly reporting to the sponsoring agency or FedRAMP PMO. ISO 27001 A.8.8 covers vulnerability management but does not mandate monthly scanning frequencies, specific reporting to government bodies, or the ConMon deliverable cadence.

- POA&M Management (CA-5): FedRAMP requires a formal Plan of Action and Milestones with tracked remediation timelines. While ISO 27001 involves corrective actions, the FedRAMP POA&M format, reporting cadence, and remediation deadline requirements (e.g., critical findings remediated within 30 days) are more prescriptive.

- Security Assessment (CA-2, CA-7, CA-8): FedRAMP requires assessments by a FedRAMP-authorized Third Party Assessment Organization (3PAO). Your ISO 27001 certification body is not a 3PAO and cannot perform FedRAMP assessments. Annual penetration testing (CA-8) to a defined scope is mandatory.

GAP CATEGORY 3: SUPPLY CHAIN AND EXTERNAL SERVICES

- Supply Chain Risk Management (SR family): SP 800-53 Rev. 5 introduced the SR control family with 12 controls covering supply chain risk plans, supply chain controls and processes, supplier reviews, and supply chain incident response. ISO 27001:2022 improved supplier security coverage in A.5.19-5.22, but SR controls go significantly further, including requirements for hardware and software acquisition controls, component authenticity verification (SR-11), and supply chain risk management plans (SR-2).

- External System Connections (CA-3): FedRAMP requires formal Interconnection Security Agreements (ISAs) or Memoranda of Understanding (MOUs) for all connections to external systems. This is more prescriptive than ISO 27001's general third-party access controls.

GAP CATEGORY 4: CONFIGURATION AND HARDENING

- Configuration Baselines (CM-6, CM-7): FedRAMP requires documented, implemented, and monitored configuration baselines aligned with USGCB (United States Government Configuration Baseline), DISA STIGs, or CIS Benchmarks. ISO 27001 A.8.9 covers configuration management but does not require alignment with federal configuration baselines.

- Least Functionality (CM-7): FedRAMP's interpretation of least functionality requires disabling all ports, protocols, and services not required for system operation. This level of rigor may exceed your current ISO 27001 implementation.

- Change Management (CM-3, CM-4): FedRAMP requires security impact analysis for all changes before implementation, with documented approval workflows. Your ISO 27001 change management may not capture the security impact analysis requirement explicitly.

GAP CATEGORY 5: INCIDENT RESPONSE AND REPORTING

- Incident Reporting Timelines (IR-6): FedRAMP requires reporting security incidents to US-CERT within 1 hour of discovery for major incidents, with specific reporting to the sponsoring agency. ISO 27001 A.6.8 covers event reporting but has no federal reporting obligation.

- Incident Response Testing (IR-3): FedRAMP requires annual IR tabletop exercises or simulations with documented results. While ISO 27001 encourages testing, the annual requirement and documentation expectations are more specific under FedRAMP.

GAP CATEGORY 6: AUDIT AND ACCOUNTABILITY

- Audit Log Content (AU-2, AU-3, AU-12): FedRAMP specifies required audit events and required audit record content in greater detail than ISO 27001 A.8.15. You may need to expand your audit event catalog and ensure audit records capture all required fields.

- Audit Log Protection (AU-9): FedRAMP requires cryptographic protection of audit logs and controls to prevent unauthorized modification. This may exceed current ISO 27001 implementations.

- Audit Reduction and Review (AU-6): FedRAMP requires regular review of audit logs with documented procedures. Automated audit review tools may be required at Moderate.

GAP CATEGORY 7: DOCUMENTATION AND EVIDENCE

- System Security Plan (PL-2): FedRAMP requires a comprehensive SSP documenting all 323+ Moderate controls, system boundaries, data flows, interconnections, and implementation details. This is a substantial documentation artifact with no ISO 27001 equivalent. Your ISMS documentation (policies, SOA, risk assessment) will inform the SSP but cannot substitute for it.

- Privacy Threshold Analysis / Privacy Impact Assessment (PT controls): FedRAMP requires privacy documentation including a PTA and potentially a full PIA if PII is processed. ISO 27001 A.5.34 covers PII protection but is less prescriptive.

- Data Flow Diagrams and Network Diagrams: FedRAMP requires detailed, up-to-date data flow diagrams (including data types, ports/protocols, encryption in transit markers) and network architecture diagrams as part of the SSP. These must be maintained as living documents.

GAP CATEGORY 8: PERSONNEL SECURITY

- Position Categorization and Screening (PS-1 through PS-9): FedRAMP requires position sensitivity designations and background checks aligned with OPM standards for personnel in sensitive roles. ISO 27001 A.6.1 covers screening but not to OPM standards. For cloud service providers, this typically applies to personnel with administrative access to the system.

GAP CATEGORY 9: AREAS WHERE ISO 27001:2022 LIKELY PROVIDES ADEQUATE COVERAGE

Your existing certification likely provides good coverage for:
- Physical security controls (PE family / ISO 27001 Annex A Section 7) — if your data centers are certified
- Policy and procedure documentation (PL, PM)
- User awareness and training (AT-2, AT-3 / ISO 27001 A.6.3)
- Business continuity and backup (CP-9, CP-10 / ISO 27001 A.8.13, A.5.30)
- General access control principles (AC / ISO 27001 A.8.2-8.5)
- Vulnerability management processes (RA-5, SI-2 / ISO 27001 A.8.8)
- Risk management program foundations (RA / ISO 27001 Clause 6.1)


==============================================================================
3. HOW THE RMF PROCESS WORKS FOR FedRAMP
==============================================================================

The Risk Management Framework (RMF), defined in NIST SP 800-37 Rev. 2, provides the authorization process that FedRAMP uses. FedRAMP operationalizes RMF specifically for cloud service providers (CSPs) offering services to federal agencies.

FEDRAMP AUTHORIZATION PATHS:

There are three primary paths to FedRAMP authorization:
1. Agency Authorization: A specific federal agency sponsors the CSP, and the agency's Authorizing Official (AO) grants the ATO.
2. JAB Provisional ATO (P-ATO): The Joint Authorization Board (consisting of DOD, DHS, and GSA CISOs) grants a P-ATO, which other agencies can then leverage.
3. FedRAMP Authorization Act Path: More recent formalized agency authorization with PMO involvement.

For a first-time FedRAMP Moderate authorization, most CSPs pursue Agency Authorization unless their offering has very broad federal market potential warranting JAB pursuit.

RMF STEP 1 — CATEGORIZE (SP 800-60)

The system is categorized using FIPS 199 and SP 800-60 Volume II. Information types processed, stored, and transmitted by the system are identified and their confidentiality, integrity, and availability impact levels (Low, Moderate, High) are determined. The overall system impact level is the high-water mark across all three objectives.

For Moderate authorization: the system's overall impact level must be Moderate (at least one security objective is Moderate, none are High). FedRAMP provides categorization guidance in the SSP template.

Key deliverable: Completed FIPS 199 categorization documented in the SSP.

RMF STEP 2 — SELECT (SP 800-53)

The appropriate control baseline is selected based on categorization. For Moderate impact systems, the SP 800-53 Rev. 5 Moderate baseline is the starting point. FedRAMP has tailored this baseline in the FedRAMP Moderate baseline spreadsheet, which includes:
- Additional FedRAMP-specific parameter values
- Additional FedRAMP-required controls beyond the NIST baseline
- Guidance on control responsibilities (CSP-responsible, agency-responsible, shared)

The CSP identifies which controls are implemented, which are inherited from underlying infrastructure providers (e.g., AWS, Azure, GCP FedRAMP-authorized IaaS/PaaS), and which are shared responsibility. This produces a Customer Responsibility Matrix (CRM).

Key deliverables: Selected control baseline, initial CRM, tailoring decisions documented in SSP.

RMF STEP 3 — IMPLEMENT

Controls are implemented across the system. For a cloud service, this involves:
- Implementing all CSP-responsible controls
- Inheriting controls from FedRAMP-authorized underlying providers (leveraging their existing P-ATOs)
- Documenting implementation details for every control in the SSP

The SSP is the primary output — a detailed document (often 300-500+ pages) describing the system boundary, all information types, data flows, interconnections, and implementation status and description for every applicable control.

Supporting artifacts include:
- System Security Plan (SSP)
- Customer Responsibility Matrix (CRM)
- Information System Contingency Plan (ISCP)
- Incident Response Plan (IRP)
- Configuration Management Plan (CMP)
- Control Implementation Summary (CIS)
- User Guide
- Privacy Threshold Analysis (PTA) / Privacy Impact Assessment (PIA) if applicable

Key deliverable: Complete SSP package ready for assessment.

RMF STEP 4 — ASSESS (SP 800-53A)

A FedRAMP-authorized Third Party Assessment Organization (3PAO) conducts an independent assessment of control implementation. The 3PAO is selected by the CSP but must be on the FedRAMP authorized 3PAO list.

The 3PAO performs:
- Security Assessment Plan (SAP): Documents assessment scope, methodology, schedule, and test cases.
- Assessment Execution: Combination of interviews, document review, observation, and technical testing (including vulnerability scanning and penetration testing).
- Security Assessment Report (SAR): Documents findings, risk ratings (Critical, High, Moderate, Low, Informational), and recommendations. Each finding becomes either a Risk Acceptance or a POA&M item.

For Moderate systems, penetration testing must cover the entire authorization boundary and test for the OWASP Top 10, infrastructure vulnerabilities, and cloud-specific attack vectors.

The 3PAO assessment for a Moderate system typically takes 4-8 weeks for the assessment itself, with 2-4 weeks for the SAR.

Key deliverables: SAP, SAR, penetration test report.

RMF STEP 5 — AUTHORIZE

The authorization package is submitted to the Authorizing Official (agency AO for Agency Authorization, or JAB for P-ATO). The package includes:
- System Security Plan (SSP) and all supporting plans
- Security Assessment Report (SAR)
- Plan of Action and Milestones (POA&M)
- Any additional agency-required documentation

The AO reviews the package, assesses residual risk, and makes an authorization decision:
- ATO (Authority to Operate): Granted, typically for 3 years
- ATO with Conditions: Granted with specific remediation requirements
- DATO (Denial of ATO): System may not operate

The FedRAMP PMO reviews the package before JAB authorization (for P-ATOs) or for Agency ATOs may review for completeness. The FedRAMP PMO does not make ATO decisions for Agency Authorizations — that authority rests with the agency AO.

POA&M: All open findings from the SAR with risk ratings of Low or above that are not accepted must be documented in the POA&M with remediation timelines. FedRAMP mandates: Critical findings remediated within 30 days, High within 30 days, Moderate within 90 days, Low within 180 days.

Key deliverable: ATO letter from the authorizing official.

RMF STEP 6 — MONITOR (Continuous Monitoring)

Post-authorization, FedRAMP's ConMon program requires ongoing activities:

Monthly:
- Vulnerability scanning of all operating system components, web applications, and databases
- Submission of updated POA&M to the sponsoring agency
- Submission of scan results to the sponsoring agency and FedRAMP PMO (for JAB P-ATOs)
- Inventory updates

Annually:
- Significant change assessments for any major changes to the system boundary, architecture, or controls
- Penetration testing (annual or as required by major changes)
- Review and update of all SSP documentation

Continuous:
- Incident reporting (within 1 hour for major incidents to US-CERT)
- Ongoing log monitoring and security event review
- Configuration baseline compliance monitoring
- Personnel security reviews

Significant Changes: Any change to the system boundary, data types, underlying infrastructure, or control implementations that may affect the security posture must be assessed. Significant changes may require a new 3PAO assessment of affected controls (called a Significant Change Request or SCR). Examples include: adding a new cloud region, migrating to a new database platform, changing authentication mechanisms, adding new data types.


==============================================================================
4. PRACTICAL RECOMMENDATIONS FOR YOUR FEDRAMP MODERATE JOURNEY
==============================================================================

Given your ISO 27001:2022 certification, here is a prioritized remediation and preparation approach:

PHASE 1 — FOUNDATION (Months 1-3):

1. Engage a FedRAMP-authorized 3PAO early to conduct a readiness assessment. This identifies your specific gaps before committing to a full assessment timeline.

2. Identify a federal agency sponsor if pursuing Agency Authorization. The agency must agree to sponsor and will have their own onboarding requirements.

3. Define your FedRAMP authorization boundary precisely. What is in scope? What underlying infrastructure will you inherit controls from? Ensure your IaaS/PaaS providers have existing FedRAMP authorizations.

4. Map your existing ISO 27001 controls to SP 800-53 Moderate controls using NIST's SP 800-53 to ISO 27001 crosswalk (NIST Interagency Report 8011 and SP 800-53B appendices provide mapping guidance). This reveals your actual coverage and prioritizes gaps.

5. Begin SSP development. The SSP template is available from FedRAMP.gov. Start populating system boundary, information types, and high-confidence controls immediately.

PHASE 2 — GAP REMEDIATION (Months 3-9):

1. Achieve FIPS 140-3 validated cryptography across all cryptographic operations. This often requires library upgrades and may affect system performance — plan accordingly.

2. Implement federal configuration baselines (USGCB/STIG/CIS) for all applicable components. This is often the most time-consuming technical remediation.

3. Establish ConMon tooling and processes: automated vulnerability scanning (e.g., Tenable Nessus, Qualys), SIEM for log aggregation and monitoring, POA&M tracking system.

4. Develop all required documentation artifacts: ISCP, IRP, CMP, PTA/PIA, Rules of Behavior, user guides, CIS/CRM.

5. Address supply chain risk management gaps — develop an SR program, conduct supplier reviews, implement SCRM plan.

6. Conduct internal tabletop exercises for incident response and contingency plan testing.

PHASE 3 — 3PAO ASSESSMENT (Months 9-15):

1. Conduct a formal readiness assessment with your 3PAO before the full assessment. This is optional but strongly recommended for first-time authorizations.

2. Remediate readiness assessment findings.

3. Execute formal 3PAO assessment (SAP execution, penetration testing, SAR development).

4. Develop POA&M for all SAR findings. Remediate Critical and High findings before submitting the authorization package.

5. Submit authorization package to agency AO.

TIMELINE EXPECTATION: First-time FedRAMP Moderate authorizations typically take 12-18 months from kickoff to ATO for well-prepared organizations. ISO 27001 certification shortens this by establishing foundational processes but does not eliminate the FedRAMP-specific work described above.

COST CONSIDERATION: 3PAO assessment costs for Moderate systems typically range from $250,000 to $500,000+ depending on system complexity. Internal preparation costs (personnel, tooling, documentation) can equal or exceed assessment costs.


==============================================================================
5. KEY RESOURCES
==============================================================================

- FedRAMP.gov: Authorization packages, SSP templates, 3PAO list, ConMon guidance
- NIST SP 800-53 Rev. 5: Control catalog and Moderate baseline
- NIST SP 800-53B: Control baselines (Moderate baseline definition)
- NIST SP 800-37 Rev. 2: RMF process
- NIST SP 800-53A Rev. 5: Assessment procedures
- NIST SP 800-60 Vol. II: Information type categorization
- FIPS 199: Security categorization standards
- FIPS 200: Minimum security requirements
- FedRAMP Moderate Baseline Spreadsheet (FedRAMP.gov): Parameter values, additional requirements
- NIST IR 8011: Automation of SP 800-53 controls (assessment automation guidance)
- FedRAMP Continuous Monitoring Strategy Guide (FedRAMP.gov)

==============================================================================

Response generated: 2026-05-07
Knowledge basis: General expert knowledge of NIST SP 800-53 Rev. 5, FedRAMP Moderate requirements, ISO 27001:2022, and NIST RMF (SP 800-37 Rev. 2)

EU AI ACT COMPLIANCE ANALYSIS: AI-POWERED CV SCREENING AND CANDIDATE RANKING TOOL
US SaaS Provider — Launch in Germany and France (Q1 2026)

=============================================================================
STEP 1: SCOPE AND ROLE IDENTIFICATION
=============================================================================

The EU AI Act (Regulation (EU) 2024/1689) applies on a territorial basis: it covers AI systems placed on the EU market or put into service in the EU, regardless of where the provider is established (Art. 2(1)(a)). As a US company making your CV screening and candidate ranking tool available to European employers in Germany and France, you fall squarely within the Act's territorial scope.

Your roles under the Act (Art. 3):

- YOU are the PROVIDER (Art. 3(3)): You develop the AI system and make it available on the EU market under your own name or trademark. Providers bear the heaviest compliance burden under the Act.

- Your EUROPEAN EMPLOYER CUSTOMERS are DEPLOYERS (Art. 3(4)): They use the AI system under their own authority in a professional context (employment decisions). They carry their own set of obligations under Art. 26, distinct from yours.

- Because you are a non-EU provider, you must appoint an AUTHORISED REPRESENTATIVE established in the EU (Art. 3(5) and Art. 22). This representative must have a written mandate, be established in one of the Member States where you operate (Germany or France), and be registered in the EU AI database on your behalf.

Timeline note: Your Q1 2026 launch date matters significantly. The high-risk system obligations under Annex III (Arts. 8–26, 43–50) apply from 2 August 2026. However, the prohibited practices (Art. 5) have applied since 2 February 2025. You must be fully compliant before making the system available — which for Art. 5 means immediately, and for high-risk obligations means completing your conformity assessment and registration before placing the system on the EU market.


=============================================================================
STEP 2: AI SYSTEM DEFINITION CHECK (Art. 3(1))
=============================================================================

Your CV screening and candidate ranking tool qualifies as an AI system under Art. 3(1). It is a machine-based system that operates with varying levels of autonomy, infers from inputs (CV data, job requirements, behavioral/skills signals) how to generate outputs (rankings, scores, filter decisions) that affect real environments — specifically, which candidates proceed in a recruitment process.

The system is not a General Purpose AI (GPAI) model (Art. 3(63)) in its own right. It is a task-specific AI system built for a defined purpose (recruitment screening), not trained at scale to perform a wide range of distinct tasks. If your system is built on top of a third-party GPAI model (e.g., a large language model for CV parsing), the GPAI obligations fall on that upstream model's provider — your obligations as a downstream provider building a high-risk application on top of it remain governed by Arts. 9–17. You would, however, need downstream information from that GPAI provider under Art. 53 and Annex XII to meet your own obligations.


=============================================================================
STEP 3: PROHIBITED PRACTICES SCREEN (Art. 5 — applies from 2 Feb 2025)
=============================================================================

Running through all eight prohibited categories:

Art. 5(1)(a) — Subliminal/manipulative techniques: Your system filters and ranks candidates based on CV data and skills assessment. It does not appear to use subliminal techniques targeting candidates. NOT TRIGGERED — provided your system does not use dark patterns or deceptive interfaces against candidates.

Art. 5(1)(b) — Exploitation of vulnerabilities: Filtering based on skills and predicted fit does not target individuals' vulnerability based on age, disability, or socioeconomic circumstances as such. NOT TRIGGERED — however, monitor that "predicted fit" proxies do not serve as a vehicle for discriminatory scoring that disproportionately impacts vulnerable groups.

Art. 5(1)(c) — Social scoring: Social scoring covers evaluating persons based on social behavior or inferred personal characteristics to produce detrimental treatment in unrelated social contexts. Employment screening within its own context is not social scoring per se. NOT TRIGGERED — but the line blurs if your "predicted fit" model draws on behavior signals from social media, spending patterns, or other life-domain data unrelated to job performance.

Art. 5(1)(d) — Predictive criminal risk assessment: Not applicable. NOT TRIGGERED.

Art. 5(1)(e) — Untargeted facial image scraping: Not applicable. NOT TRIGGERED.

Art. 5(1)(f) — Emotion inference in the workplace or educational institutions: If your system incorporates any emotion recognition or sentiment analysis of candidates during video interviews or interactions, this prohibition applies in the employment context. RISK AREA — audit your system for any emotion inference components. If present, they are prohibited under Art. 5(1)(f) unless the strictly limited medical/safety exception applies (which it will not for candidate screening).

Art. 5(1)(g) — Biometric-based categorization for sensitive attributes: If your system uses biometric data from video interviews or photos to infer race, political opinions, religion, sex life, or sexual orientation of candidates, this is prohibited. RISK AREA — confirm no biometric attribute inference occurs.

Art. 5(1)(h) — Real-time remote biometric identification by law enforcement: Not applicable. NOT TRIGGERED.

CONCLUSION ON PROHIBITED PRACTICES: Your core tool (skills assessment and CV-based ranking) does not trigger the prohibitions, provided it contains no emotion recognition from video interviews, no biometric inference of protected attributes, and no social scoring drawing on life-domain behavioral data. These must be verified by auditing your full feature set.


=============================================================================
STEP 4: RISK TIER DETERMINATION — HIGH RISK (Art. 6 + Annex III, Area 4)
=============================================================================

Your CV screening and candidate ranking tool is a HIGH-RISK AI SYSTEM under Art. 6(2), specifically Annex III, Area 4(a).

Annex III, Area 4 covers: "Employment, Workers Management, and Access to Self-Employment" and specifically includes at Area 4(a): "recruitment and selection: targeted job advertising, application filtering/screening, candidate evaluation and selection."

Your system directly matches this description. It:
- Filters job applications (application filtering/screening)
- Ranks candidates (candidate evaluation and selection)
- Operates in the context of employment decisions made by European employers

There is no applicable non-high-risk exception under Art. 6(2). The narrow exceptions (narrow procedural task; improving result of previously completed human activity without influencing it; detecting decision-making patterns without replacing human assessment; performing preparatory tasks for Annex III assessments) do not apply because your system actively filters and ranks candidates in a way that directly influences — and, for filtered-out candidates, effectively replaces — human assessment of who progresses.

Critically: Art. 6(3) provides an overriding rule that any Annex III system that profiles natural persons is ALWAYS high-risk regardless of any exceptions. Candidate ranking based on skills and "predicted fit" constitutes profiling of natural persons (Art. 3(52) — automated processing of personal data to evaluate natural persons, including work performance and behavior). This locks in high-risk classification independently.

This is not Path A (Art. 6(1)) — your system is not a safety component of an Annex I sectoral product. It is Path B (Art. 6(2)) — listed in Annex III.


=============================================================================
STEP 5: HIGH-RISK PROVIDER OBLIGATIONS (Arts. 8–17, 43–49)
=============================================================================

As a provider of a high-risk AI system, the following obligations apply before you place the system on the EU market. For Annex III systems, the compliance deadline is 2 August 2026 — but given your Q1 2026 launch target, you should begin work immediately and plan to have all requirements met before launch.

--- Art. 9 — Risk Management System ---

You must establish, implement, document, and maintain a continuous risk management system throughout your system's entire lifecycle. This is not a one-time exercise.

Required steps:
1. Identify all known and reasonably foreseeable risks to candidates' fundamental rights (particularly discrimination risks in candidate filtering and ranking), to deploying employers, and to third parties.
2. Estimate and evaluate risks under all intended uses (screening for multiple job types, industries, seniority levels) and reasonably foreseeable misuse (e.g., employers using the tool for demographic filtering).
3. Evaluate risks emerging from post-market monitoring data as the system is used in Germany and France.
4. Adopt risk mitigation measures in priority order: design-based elimination first, then technical/organizational mitigations, then information provision to deployers.
5. Assess residual risk acceptability and document reasoning.

Specific testing obligation (Art. 9(7)): Before market placement, test the system against pre-defined metrics using representative test data that reflects the diversity of candidates and job contexts in the German and French labor markets.

Discrimination risk is the paramount concern here. CV screening AI has well-documented patterns of discriminating on the basis of gender, age, ethnicity, and other protected characteristics (explicitly protected under German AGG and French Labor Code, and under EU equal treatment Directives). Your risk management system must specifically address:
- Bias in training data (historical hiring data reflecting past discrimination)
- Proxy discrimination through features that correlate with protected characteristics (e.g., name, postcode, educational institution)
- Differential performance rates across demographic groups

--- Art. 10 — Data and Data Governance ---

Your training, validation, and testing datasets must be:
- Relevant to the intended purpose (CV screening and ranking for the types of roles and sectors your deployers serve)
- Sufficiently representative of the persons your system will process — this means representative of the German and French candidate populations, including demographic diversity
- Free of errors where appropriate
- Complete for the intended purpose

Data governance documentation must cover: design choices, data collection methods, data origins, annotation and labeling procedures, and — critically — bias examination and gap identification.

For Art. 10(5): If you process special-category personal data (GDPR Art. 9 — racial/ethnic origin, health, religion, trade union membership, sexual orientation) for bias detection purposes, strict conditions apply: no adequate alternative, technical/organizational protections in place, minimum necessary access, no third-party transfer, deletion upon completion of bias testing, and documented justification.

Practical note: You almost certainly cannot use historical hiring data from employers' past recruitment as training data without careful auditing — such data typically encodes historical discrimination patterns.

--- Art. 11 — Technical Documentation (Annex IV) ---

Before placing the system on the EU market, you must produce comprehensive technical documentation including:
- General description: intended purpose (CV screening and candidate ranking), provider identity, system version, interactions with other software
- Detailed development description: training methodologies, algorithms, design choices, data used
- Training data description: origin, annotation procedures, design choices
- Validation and testing: procedures, metrics, performance benchmarks (including fairness/bias metrics), testing datasets
- Risk management system documentation (Art. 9)
- Human oversight measures (Art. 14)
- Changes made to the system over its lifecycle
- List of harmonised standards applied or alternative conformity solutions

This documentation must be maintained for 10 years from market placement.

--- Art. 12 — Record-Keeping and Automatic Logging ---

Your system must be technically capable of automatically generating event logs throughout its operation. These logs must enable post-deployment reconstruction of circumstances surrounding any identified risk. As provider, you must build in this logging capability.

Your deployer customers (Art. 26(6)) must retain automatically generated logs for a minimum of 6 months. You must provide them with the technical means to do so through your system design and inform them of this obligation in your instructions for use.

--- Art. 13 — Transparency and Instructions for Use to Deployers ---

You must design the system with sufficient transparency that deployers can interpret its outputs and use it appropriately. Your instructions for use must include:
- Your identity and contact address
- System characteristics, capabilities, and intended purpose
- Performance metrics: accuracy levels, robustness, cybersecurity specifications
- Known or foreseeable circumstances that may lead to risks or unexpected performance degradation (e.g., performance degradation for non-standard CV formats, for under-represented candidate profiles)
- System performance for specific persons or groups — critically, you must disclose differential performance rates across demographic groups if they exist
- Input data specifications (CV formats, data types accepted)
- Information on changes vs. prior versions
- Description of human oversight measures (Art. 14) and how to implement them
- Description of logging mechanisms

--- Art. 14 — Human Oversight ---

You must design the system so that deployers (European employers) are able to:
- Understand the system's capabilities and limitations
- Recognize automation bias (over-reliance on AI rankings without independent assessment)
- Correctly interpret AI outputs — including understanding what "predicted fit" means, how confidence scores are derived, and what their limitations are
- Decide not to use, disregard, override, or reverse the AI's outputs for any individual candidate
- Intervene through a stop function or similar mechanism

This is a design obligation on you as provider. In practical terms, your user interface must present AI rankings as recommendations, not determinations; must display confidence levels and their meaning; must make it easy for recruiters to review and override individual ranking decisions; and must not nudge deployers toward accepting AI outputs without review.

Deployers bear the Art. 14(4) obligation to assign oversight responsibility to personnel with competence, training, authority, and resources. Your instructions for use should guide them on what competencies are required.

--- Art. 15 — Accuracy, Robustness, and Cybersecurity ---

Accuracy: You must achieve and declare appropriate accuracy levels for your intended purpose. Accuracy must be maintained throughout the system lifecycle. The declared accuracy metrics must appear in your instructions for use. For a CV screening system, relevant metrics include: precision and recall by candidate subgroup; false positive and false negative rates for qualified candidates; and consistency of rankings across equivalent CVs.

Robustness: The system must perform consistently across the full range of inputs (different CV formats, languages — German and French are minimum requirements — industries, and candidate backgrounds). Inconsistent or degraded performance for atypical inputs (non-native speakers, non-standard CV formats, candidates from diverse educational backgrounds) constitutes a robustness failure.

Cybersecurity: Your system must be resilient against data poisoning (contamination of training data), model poisoning, adversarial inputs (manipulated CVs designed to game rankings), and confidentiality attacks. CV data is personal data of job seekers; security failures expose you to concurrent AI Act and GDPR liability.

--- Art. 16 — Full Provider Obligations Checklist ---

Before placing the system on the EU market in Germany and France, you must have completed all 12 items:

1. Ensure system complies with Arts. 9–15 requirements
2. Display your company name, trademark, and contact address on the system or documentation
3. Establish and implement a Quality Management System (Art. 17)
4. Keep technical documentation (Art. 11, Annex IV)
5. Retain automatically generated logs where under your control
6. Complete the required conformity assessment (Art. 43) — SELF-ASSESSMENT for Area 4 systems
7. Draw up the EU Declaration of Conformity (Art. 47)
8. Affix CE marking (Art. 48)
9. Register in the EU AI database (Art. 49) before market placement
10. Take immediate corrective action for non-conforming systems; notify authorities and deployers
11. Demonstrate conformity upon request of national competent authority
12. Ensure accessible design where required (Directives 2016/2102, 2019/882)

--- Art. 17 — Quality Management System ---

You must establish and maintain a documented QMS covering 13 required components:
1. Regulatory compliance strategy including conformity assessment procedures
2. Design techniques and procedures for controlling and verifying the system
3. Development quality control procedures
4. Testing and validation (before, during, and after development)
5. Technical standards application
6. Data management (acquisition, labeling, storage, filtering, retention, cleaning)
7. Risk management per Art. 9
8. Post-market monitoring per Art. 72
9. Serious incident reporting procedures per Art. 73
10. Authority communication procedures for corrective actions and recalls
11. Record-keeping and documentation with retention periods
12. Resource management including supply-chain security (including any AI components/APIs you rely on)
13. Accountability framework — clear responsibility assignment for all above components

The QMS must be proportionate to your organization's size. If you already have an ISO 9001 or ISO 42001 QMS, it can be adapted. ISO 42001:2023 certification would provide strong alignment with the Art. 17 requirements.


=============================================================================
STEP 6: CONFORMITY ASSESSMENT AND CE MARKING (Arts. 43–49)
=============================================================================

Your system falls under Annex III, Area 4 — which is Points 2–8 of Annex III (employment is Area 4, which is Point 4). For all Annex III Points 2–8 systems, the conformity assessment is SELF-ASSESSMENT ONLY (Art. 43) — no notified body (third-party auditor) is required or available.

Self-assessment path (Annex VI):
You conduct an internal control procedure assessing your system against all applicable requirements (Arts. 9–15). This is documented in your technical documentation and results in:

1. EU Declaration of Conformity (Art. 47): A formal document signed by you (or your authorised representative) declaring compliance with the AI Act. Must be maintained for 10 years. Must be in machine-readable format and translated into languages required by German and French authorities.

2. CE Marking (Art. 48): After completing the conformity assessment and drawing up the Declaration of Conformity, you affix the CE marking to the system (visible on the product, packaging, or documentation). This cannot be affixed before completion of the conformity assessment.

3. EU AI Database Registration (Art. 49): Before placing on the EU market, you (or your authorised representative) must register the system in the EU AI database maintained by the European Commission. The database becomes operational on 2 August 2026. Registration information includes: provider and representative identity; system description and intended purpose; accuracy and performance data; conformity assessment procedure followed. Note: The EU AI database's operational date aligns with the high-risk obligation compliance date, not your Q1 2026 target. Monitor Commission announcements regarding early registration procedures.

Substantial modifications: If you make substantial modifications to the system post-launch (changes to core ranking algorithms, new capabilities, significant retraining), the conformity assessment must be repeated and the CE marking re-affixed.


=============================================================================
STEP 7: AUTHORISED REPRESENTATIVE REQUIREMENT (Art. 22)
=============================================================================

As a non-EU provider, you must appoint an Authorised Representative established in Germany or France (or another EU Member State) before placing the system on the EU market. The representative:
- Must have a written mandate from you
- Acts on your behalf regarding compliance with the AI Act
- Is the contact point for EU market surveillance authorities (German Bundesnetzagentur / French Autorité de régulation de la communication audiovisuelle et numérique or designated AI authority)
- Is registered in the EU AI database
- Can be held jointly and severally liable in some enforcement contexts

This is a hard prerequisite — you cannot lawfully place the system on the EU market without it.


=============================================================================
STEP 8: DEPLOYER OBLIGATIONS — YOUR CUSTOMER RESPONSIBILITIES (Art. 26)
=============================================================================

While you bear provider obligations, your European employer customers are deployers and bear separate obligations under Art. 26. You should understand these to inform your contractual arrangements and the guidance you provide in your instructions for use:

1. Use the system in accordance with your instructions for use
2. Assign human oversight responsibility to personnel with necessary competence and training
3. Where they control input data: ensure it is relevant and sufficiently representative
4. Continuously monitor operations; notify you and market surveillance authorities if risks are identified; suspend use where appropriate
5. Immediately report serious incidents to you, then to market surveillance authorities
6. Retain automatically generated logs for at least 6 months
7. Notify workers and worker representatives BEFORE deploying the system in their employment processes (Art. 26(7)) — this is a significant obligation; your deployer customers must inform their works councils (Betriebsrat in Germany, comité social et économique in France) in advance. This has direct implications for enterprise sales timelines.
8. GDPR compliance: deployers must conduct Data Protection Impact Assessments (DPIAs) under GDPR Art. 35 given the high-risk nature of profiling in employment decisions

Public authority deployers (public sector employers) also have additional registration obligations (Art. 60) and must conduct a Fundamental Rights Impact Assessment (FRIA) under Art. 27 before deployment.

Contractual implication: Your customer agreements should clearly allocate obligations between you as provider and your customers as deployers, confirm their obligations under Art. 26, and include provisions for incident notification and log retention cooperation.


=============================================================================
STEP 9: POST-MARKET MONITORING AND INCIDENT REPORTING (Arts. 72–73)
=============================================================================

Art. 72 — Post-Market Monitoring:
You must establish and document a post-market monitoring plan proportionate to your system's risks. For a CV screening system, this means ongoing monitoring of:
- System accuracy and fairness metrics across the deployed German and French customer base
- Any differential performance patterns emerging from production data
- Feedback from deployer customers on unexpected outputs or failures
- Emerging research on bias in AI recruitment systems

The Commission must publish a standardised template for post-market monitoring plans by 2 February 2026.

Art. 73 — Serious Incident Reporting:
A serious incident includes any AI system malfunction that directly or indirectly leads to infringement of obligations under Union law protecting fundamental rights. Systematic discrimination against protected groups in candidate filtering is precisely this type of fundamental rights infringement.

If a serious incident occurs:
- You as provider must report to the market surveillance authority of the Member State where the incident occurred (Bundesnetzagentur for Germany; relevant French authority)
- Timing: within 15 days for serious incidents (immediately for life-threatening incidents, within 2 days for widespread safety threats)
- Your deployer customers must immediately notify you upon identifying a serious incident


=============================================================================
STEP 10: GDPR INTERSECTION
=============================================================================

CV screening involves extensive processing of candidates' personal data (biographical information, skills, education history, employment history, and potentially sensitive data). The AI Act and GDPR apply concurrently.

Key intersections:
- GDPR Art. 22 (automated decision-making): Candidates have the right not to be subject to solely automated decisions that produce significant legal effects. Automated candidate filtering and rejection decisions trigger Art. 22 unless an exception applies (explicit consent, necessity for contract performance, or EU/national law authorization). Your deployers must implement GDPR Art. 22 safeguards — your instructions for use must guide them on this.
- GDPR Art. 35 (DPIA): Your deployer customers must conduct DPIAs given the systematic profiling of individuals in employment decisions.
- GDPR Art. 13/14 (transparency to data subjects): Candidates must be informed that their data is being processed through AI screening — your deployers are the data controllers in this relationship.
- Data minimization and purpose limitation: The CV data processed must be limited to what is necessary for the stated purpose.

Your data processing agreements with European employers must comply with GDPR Art. 28 (processor obligations) if you process personal data on their behalf.


=============================================================================
COMPLIANCE TIMELINE AND ACTION PLAN
=============================================================================

IMMEDIATE (already applies — pre-Q1 2026):
- Audit system for Art. 5 prohibited practices (emotion recognition, biometric inference) — complete before any EU market activity
- Begin appointment process for EU Authorised Representative in Germany or France
- Begin work on Risk Management System (Art. 9) and technical documentation (Art. 11)

Q1 2026 (TARGET LAUNCH — note: high-risk obligations formally apply 2 Aug 2026):
- Complete technical documentation (Annex IV)
- Complete conformity assessment (self-assessment per Annex VI)
- Draw up EU Declaration of Conformity (Art. 47)
- Affix CE marking (Art. 48)
- Register in EU AI database (Art. 49) — subject to database operational status; monitor Commission announcements
- Authorised Representative confirmed and mandated
- Instructions for use finalised and provided to all deployer customers
- Quality Management System (Art. 17) documented and operational
- Post-market monitoring plan established

ONGOING (from launch):
- Post-market monitoring (Art. 72): continuous performance and fairness monitoring
- Serious incident reporting (Art. 73): notification procedures in place
- Log retention: ensure deployers are retaining logs per Art. 26(6)
- Update technical documentation for any substantial system changes
- Update conformity assessment if substantial modifications made


=============================================================================
PENALTIES FOR NON-COMPLIANCE (Art. 99)
=============================================================================

The stakes for non-compliance are material:

| Violation | Maximum Fine |
|-----------|-------------|
| Prohibited practice violations (Art. 5) | €35,000,000 or 7% of global annual turnover (whichever is higher) |
| Provider/deployer obligation violations (Arts. 9–17, 26, etc.) | €15,000,000 or 3% of global annual turnover (whichever is higher) |
| Incorrect/misleading information to authorities | €7,500,000 or 1% of global annual turnover |

For SMEs and startups: the lower of the fixed amount or the percentage applies. Proportionality factors include nature and gravity of violation, company size, intentionality, and cooperation.

Both Germany and France will have national market surveillance authorities with powers to inspect documentation, test datasets, and source code.


=============================================================================
SUMMARY ASSESSMENT
=============================================================================

DOES THE EU AI ACT APPLY?
Yes. Without question. Your system meets the AI system definition (Art. 3(1)), you are a provider placing a system on the EU market (Art. 2(1)(a)), and the employment screening function falls directly within Annex III, Area 4(a) — making it a HIGH-RISK AI SYSTEM under Art. 6(2).

WHAT ARE YOUR KEY OBLIGATIONS?
As provider:
1. Appoint an EU Authorised Representative (Art. 22) — prerequisite for market access
2. Build and maintain a Risk Management System (Art. 9) with specific focus on discrimination risks
3. Ensure rigorous data governance for training/validation datasets (Art. 10)
4. Produce Annex IV technical documentation (Art. 11)
5. Build in automatic logging capability (Art. 12)
6. Provide comprehensive instructions for use to deployer customers (Art. 13)
7. Design for human oversight — rankings must be overridable, automation bias warnings built in (Art. 14)
8. Declare and achieve appropriate accuracy, robustness, and cybersecurity standards (Art. 15)
9. Complete self-assessment conformity assessment (Art. 43, Annex VI)
10. Draw up EU Declaration of Conformity (Art. 47) and affix CE marking (Art. 48)
11. Register in EU AI database (Art. 49) before market placement
12. Establish a Quality Management System (Art. 17)
13. Implement post-market monitoring (Art. 72) and serious incident reporting procedures (Art. 73)

As to your deployer customers: educate and contractually require them to comply with Art. 26 (including the worker notification obligation under Art. 26(7), which has significant implications for enterprise deals in Germany and France given codetermination rights).

CRITICAL RISK AREAS:
- Bias and discrimination: This is the central regulatory risk for your system type. The German AGG and French anti-discrimination law overlay EU equal treatment requirements, and systematic discriminatory filtering would constitute both an AI Act serious incident and GDPR/national law violation.
- Prohibited practice audit: Verify that no emotion recognition or biometric attribute inference is embedded in any product feature (Art. 5(1)(f) and (g)).
- GDPR Art. 22: Fully automated rejection decisions without human review may violate GDPR — your system must be positioned as a tool for human decision support, not autonomous determination.
- Worker notification: Your deployer customers in Germany must notify works councils (Betriebsrat) before deployment — this is a hard requirement under both Art. 26(7) of the AI Act and German co-determination law (BetrVG). Factor this into your sales and onboarding timelines.

EU AI ACT COMPLIANCE ANALYSIS: AI-POWERED CV SCREENING AND CANDIDATE RANKING TOOL
FOR US SAAS COMPANY LAUNCHING IN GERMANY AND FRANCE (Q1 2026)

================================================================================
EXECUTIVE SUMMARY
================================================================================

Yes, your CV screening and candidate ranking tool almost certainly falls under the EU AI Act, and it is very likely classified as a HIGH-RISK AI system. This classification carries substantial compliance obligations that must be addressed before your Q1 2026 launch. Launching without compliance exposes you to significant fines and potential market access restrictions.

================================================================================
1. DOES THE EU AI ACT APPLY TO YOUR COMPANY?
================================================================================

1.1 Territorial Scope

The EU AI Act has broad extraterritorial reach. Under Article 2, the Act applies to:

- Providers that place AI systems on the EU market or put them into service in the EU, regardless of where the provider is established
- Providers and deployers established in third countries (including the US) where the output of their AI system is used in the EU
- Deployers of AI systems established or located in the EU

As a US company selling to European employers in Germany and France, you are a "provider" under the Act because you are placing your AI system on the EU market. The fact that your company is based in the US does not exempt you. The Act explicitly covers non-EU providers whose systems are used in the EU.

1.2 Who Are the Relevant Parties?

Under the EU AI Act:

- You (the US SaaS company) = the "Provider" (the entity that develops and places the AI system on the market)
- Your European employer customers = the "Deployers" (entities that use the AI system under their own authority)

Both providers and deployers have obligations under the Act, though providers carry the heavier compliance burden.

================================================================================
2. RISK CLASSIFICATION: HIGH-RISK
================================================================================

2.1 The Classification Framework

The EU AI Act classifies AI systems into four categories:
- Unacceptable risk (prohibited)
- High-risk
- Limited risk (transparency obligations only)
- Minimal risk

2.2 Why Your Tool Is Almost Certainly High-Risk

Annex III of the EU AI Act explicitly lists employment-related AI systems as high-risk. Specifically, it covers AI systems used for:

"Recruitment or selection of natural persons, notably for advertising vacancies, screening or filtering applications, evaluating candidates in the course of interviews or tests."

And also:

"Making decisions affecting terms and conditions of employment, promotion and termination of work-related contractual relationships, task allocation and monitoring and evaluation of performance and behavior of persons in such relationship."

Your tool performs two functions that fall squarely within this definition:

(a) Filtering job applications: This is explicitly named in Annex III as a high-risk use case.
(b) Ranking candidates based on predicted fit: This constitutes evaluating candidates, which is also explicitly listed.

There is virtually no reasonable interpretation under which your tool would escape the high-risk classification. The European Parliament and Council specifically included CV screening and candidate ranking as paradigmatic examples of high-risk employment AI precisely because such tools can perpetuate or amplify discrimination, affect livelihoods, and operate with significant information asymmetry relative to the candidates being evaluated.

2.3 Note on General Purpose AI (GPAI)

If your underlying model is a GPAI model (e.g., built on top of a foundation model), that layer has separate obligations under Title VIII of the Act. However, your application layer—the CV screening and ranking tool—is still assessed separately as a high-risk application.

================================================================================
3. TIMELINE AND ENTRY INTO FORCE
================================================================================

The EU AI Act entered into force on August 1, 2024. The high-risk employment provisions (Annex III, Section 4) apply from August 2, 2026—meaning the 24-month transition period runs through August 2026.

Critically for your Q1 2026 launch: You will be placing the system on the EU market before the full high-risk obligations become mandatory (August 2026). However:

- You should design your system to be compliant from day one, because full enforcement begins shortly after your anticipated launch date
- Planning and building compliance into the system before launch is far less costly than retrofitting later
- Some obligations (e.g., GPAI rules, prohibited AI rules) apply earlier
- German and French national authorities may begin preparatory enforcement activities
- Your deployer customers (European employers) will demand contractual assurances of compliance well before August 2026
- Regulators can investigate practices that began before the enforcement date if they continue after it

Practical guidance: Plan for full compliance at or before your Q1 2026 launch. The compliance runway is short.

================================================================================
4. OBLIGATIONS AS A HIGH-RISK AI PROVIDER
================================================================================

The following obligations apply to you as the provider of a high-risk AI system under Chapter 2 of Title III:

4.1 Conformity Assessment (Article 43)

Before placing your system on the EU market, you must conduct a conformity assessment demonstrating that your system meets all requirements of the Act. For employment AI systems, this is typically a self-assessment (you do not need a notified body, unlike some other high-risk categories), but it must be documented rigorously and result in the issuance of an EU Declaration of Conformity.

4.2 Risk Management System (Article 9)

You must establish, implement, document, and maintain a risk management system throughout the AI system's lifecycle. This includes:

- Identification and analysis of known and reasonably foreseeable risks
- Estimation and evaluation of risks that may emerge during intended use
- Adoption of risk management measures
- Testing to ensure risk management measures are effective
- Particular attention to risks from:
  - Unintended use or foreseeable misuse
  - Bias and discrimination against protected groups (gender, age, ethnicity, disability, etc.)
  - Opacity of decision-making

For a CV screening tool, bias risk is paramount. Your risk management must specifically address how the model may have learned discriminatory patterns from historical hiring data.

4.3 Data Governance (Article 10)

Training, validation, and testing datasets must meet strict requirements:

- Relevant, representative, and free from errors (to the extent possible)
- Appropriate data governance and management practices
- Examination for possible biases that could lead to discrimination against protected groups under EU law (including GDPR, the Equal Treatment Directive, and other anti-discrimination law)
- Data must cover relevant populations—you must ensure your training data represents the demographic diversity of EU job markets in Germany and France specifically

This is one of the most demanding obligations. You will need to document your training data sources, conduct bias audits across protected characteristics, and demonstrate that your data governance practices meet EU standards.

4.4 Technical Documentation (Article 11 + Annex IV)

You must prepare comprehensive technical documentation before placing the system on the market. Annex IV specifies what this must include:

- General description of the AI system and its intended purpose
- Description of system components (hardware, software, training processes)
- Description of the development process
- Information about training methodologies, techniques, and data
- Validation and testing procedures and results
- Risk management documentation
- Changes made during the system's lifecycle
- Standards applied
- EU Declaration of Conformity
- Post-market monitoring plan

This documentation must be kept for 10 years after the system is placed on the market and must be made available to national competent authorities on request.

4.5 Transparency and Information to Deployers (Article 13)

High-risk AI systems must be sufficiently transparent to enable deployers to interpret and use outputs correctly. You must provide deployers (your European employer customers) with:

- A clear, comprehensible instructions-for-use document
- Information about the system's intended purpose
- Performance characteristics, including accuracy, precision, and recall metrics
- Foreseeable unintended outcomes and sources of risk
- Specific input data requirements
- Circumstances where the system should not be relied upon
- Any foreseeable misuse scenarios
- Technical measures for human oversight
- Expected lifetime and maintenance/updating requirements

4.6 Human Oversight (Article 14)

This is a critical obligation for employment AI. The system must be designed and built so that natural persons can effectively oversee it during use. Specifically:

- The system must allow deployers to interrupt, override, or revert to manual processes
- The system must be interpretable enough that human reviewers can meaningfully evaluate its outputs
- You must provide tools or mechanisms that allow deployers to understand the basis for rankings and decisions
- Outputs must not be presented in a way that induces automation bias (over-reliance on AI output)

For practical purposes, this means your rankings should come with explainability features—why was Candidate A ranked above Candidate B? What factors drove the score? Deployers must be able to exercise genuine human judgment, not rubber-stamp AI rankings.

4.7 Accuracy, Robustness, and Cybersecurity (Article 15)

High-risk AI systems must:

- Achieve appropriate levels of accuracy for their intended purpose
- Be resilient against errors, faults, and inconsistencies
- Be robust against attempts to alter or manipulate behavior (adversarial robustness)
- Include technical redundancies where appropriate

You must define accuracy metrics appropriate for your use case, measure them, and document them. You should also consider robustness against applicants who might game the system (e.g., keyword stuffing CVs).

4.8 Quality Management System (Article 17)

Providers must implement a quality management system covering:

- Regulatory compliance strategy
- Data management procedures
- Technical documentation procedures
- Post-market monitoring procedures
- Incident reporting procedures
- Staff training and competence management
- Record-keeping practices

This is effectively an organizational and process requirement—you need internal governance structures, not just technical compliance.

4.9 Logging and Record-Keeping (Article 12 and 19)

High-risk AI systems must automatically generate logs of operation, to the extent technically feasible. Providers must keep logs for at least six months (unless other law requires longer retention). These logs should capture:

- System operation events
- When the system was used and by which deployer
- Input and output data records sufficient to trace decisions back

Deployers have separate logging obligations, but you need to build the technical capability for this into your system.

4.10 EU Declaration of Conformity (Article 47)

Before market placement, you must draw up an EU Declaration of Conformity, signed by an authorized representative, stating that the system meets all applicable requirements of the Act. This document must be kept for 10 years.

4.11 CE Marking (Article 48)

High-risk AI systems must bear the CE marking before being placed on the EU market. This indicates conformity with the Act's requirements.

4.12 Registration in the EU Database (Article 49 and 71)

High-risk AI systems must be registered in the EU database for high-risk AI systems before market placement. This is a publicly accessible database maintained by the European AI Office. You will need to create an account and register your system with specified information about its intended purpose, risk category, and your identity as provider.

4.13 Authorized Representative in the EU (Article 22)

As a non-EU provider, you are required to appoint a natural or legal person established in the EU as your authorized representative before placing the system on the market. This representative acts as your point of contact with EU authorities and can be held responsible for compliance. Practically, this means you need either a subsidiary, a partner company in the EU, or a specialized EU AI Act representative service.

4.14 Post-Market Monitoring (Article 72)

After launch, you must operate a post-market monitoring system that actively collects and analyzes data on system performance. This should be capable of:

- Detecting previously unknown risks
- Monitoring accuracy and bias over time in production
- Triggering corrective actions when issues are identified
- Reporting serious incidents to authorities

For employment AI, this means ongoing monitoring of outcomes—are certain demographic groups being systematically scored lower? Are hiring outcomes downstream of your rankings showing discriminatory patterns?

4.15 Serious Incident Reporting (Article 73)

If you become aware of a serious incident (e.g., a malfunction that causes harm or discriminatory outputs at scale), you must report it to the national competent authority in the member state where the incident occurred within specified timeframes. Germany's national authority is the Federal Network Agency (Bundesnetzagentur); France is still designating its national authority but is expected to designate CNIL or a dedicated body.

================================================================================
5. OBLIGATIONS ON YOUR DEPLOYERS (EUROPEAN EMPLOYERS)
================================================================================

While your primary compliance burden is as a provider, you should understand deployer obligations because your contracts and product design must enable deployers to meet them. Under Article 26, deployers must:

- Use the system in accordance with your instructions for use
- Ensure staff using the system have sufficient AI literacy and training
- Implement human oversight measures as specified by you
- Monitor the system for risks and inform you of issues
- Keep logs of system use as required
- Not use the system for purposes other than its intended use
- Conduct a Fundamental Rights Impact Assessment (FRIA) before deploying the system

The FRIA is particularly significant: deployer employers using your CV screening tool must assess the potential impact on fundamental rights (equality, non-discrimination, privacy) before deployment. Your documentation and design should make it easy for them to conduct this assessment.

You should contractually require deployers to comply with these obligations and provide them with the documentation they need.

================================================================================
6. INTERSECTION WITH OTHER EU LAW
================================================================================

6.1 GDPR

CV screening processes extensive personal data. GDPR obligations are separate from and run in parallel with the EU AI Act:

- Article 22 GDPR: Individuals have rights not to be subject to solely automated decisions with significant effects. CV screening and ranking likely triggers this. You and your deployer customers must ensure a human is genuinely involved in the decision, and that candidates can request human review.
- Data minimization: Only process personal data necessary for the legitimate purpose
- Legal basis: Typically legitimate interest or consent; explicit consent is required for special category data
- Transparency: Candidates must be informed their application is being processed by AI
- Data subject rights: Candidates have rights to access, rectification, and erasure

GDPR data processing agreements (DPAs) must be in place between you (as data processor) and your European employer customers (as data controllers).

6.2 EU Anti-Discrimination Law

The Equal Treatment Directives prohibit discrimination on grounds of sex, racial or ethnic origin, religion or belief, disability, age, and sexual orientation in employment contexts. Your AI system must not produce discriminatory outcomes, and you cannot shelter behind "the algorithm did it"—deployers and providers share responsibility for discriminatory AI outputs.

6.3 German Employment and Works Council Law (Betriebsverfassungsgesetz)

In Germany, works councils (Betriebsräte) have co-determination rights over the introduction and use of technical systems that monitor employee behavior or screen applicants. Your deployer customers in Germany may need to negotiate with their works councils before deploying your tool. You should disclose this in your documentation and commercial discussions.

6.4 The European Works Council Directive

For larger organizations, European Works Councils may also need to be informed and consulted about AI tools affecting employment decisions.

================================================================================
7. PRACTICAL COMPLIANCE ROADMAP FOR Q1 2026 LAUNCH
================================================================================

Given the Q1 2026 timeline (which is very tight), here is a prioritized roadmap:

IMMEDIATE (Now - 3 months):
- Appoint an EU Authorized Representative
- Commission an independent bias audit of your training data and model outputs across protected characteristics (gender, age, ethnicity) relevant to EU labor markets
- Begin drafting technical documentation per Annex IV
- Engage EU privacy and AI counsel in Germany and France
- Conduct a GDPR gap assessment and prepare DPA templates for deployers

SHORT-TERM (3-6 months before launch):
- Implement explainability features so rankings are interpretable
- Build human oversight tools into the product (override mechanisms, score explanations)
- Design and document your risk management system
- Develop instructions-for-use documentation for deployers
- Build logging infrastructure
- Draft and finalize your EU Declaration of Conformity

PRE-LAUNCH (1-2 months before launch):
- Complete conformity assessment
- Register the system in the EU database for high-risk AI
- Affix CE marking
- Implement post-market monitoring framework
- Train customer success and sales teams on EU AI Act obligations
- Execute DPAs with all EU deployer customers
- Establish serious incident reporting procedures

POST-LAUNCH (Ongoing):
- Continuous bias monitoring in production
- Quarterly review of post-market monitoring data
- Update technical documentation when making significant changes
- Respond to any regulator inquiries through your authorized representative

================================================================================
8. PENALTIES FOR NON-COMPLIANCE
================================================================================

The EU AI Act penalties are substantial:

- Violations of prohibited AI rules: Up to EUR 35 million or 7% of global annual turnover (whichever is higher)
- Violations of high-risk AI obligations (your primary risk): Up to EUR 15 million or 3% of global annual turnover (whichever is higher)
- Providing false or misleading information to authorities: Up to EUR 7.5 million or 1.5% of global annual turnover

For a US SaaS company, turnover-based fines can be very significant. Enforcement also includes the ability for national authorities to require withdrawal of non-compliant systems from the market, which would mean your EU revenue stream is cut off.

================================================================================
9. COMPETITIVE AND STRATEGIC CONSIDERATIONS
================================================================================

- Your European employer customers will increasingly demand proof of EU AI Act compliance as a procurement requirement. Early compliance becomes a competitive differentiator.
- Building explainability and bias mitigation into your product improves quality and defensibility regardless of regulation.
- The EU AI Act compliance framework overlaps significantly with best practices for responsible AI, so compliance investment strengthens the product overall.
- Consider whether your bias audit reveals model improvements that benefit global performance.
- US federal and state AI regulation is following a similar trajectory; compliance infrastructure built for the EU AI Act will be partially reusable.

================================================================================
10. CONCLUSION
================================================================================

Your AI-powered CV screening and candidate ranking tool is a high-risk AI system under the EU AI Act. As a US SaaS provider selling to European employers, you are subject to the Act's full high-risk provider obligations. The core requirements include: conducting a conformity assessment, establishing a risk management system, implementing rigorous data governance and bias testing, preparing detailed technical documentation, providing explainability and human oversight features, registering in the EU database, appointing an EU authorized representative, bearing the CE marking, and maintaining post-market monitoring.

The Q1 2026 launch timeline is achievable but tight. Compliance must be treated as an immediate priority, not a post-launch remediation task. Engagement with specialist EU AI and employment law counsel in Germany and France is strongly recommended, as is an independent technical bias audit, given that employment AI discrimination risk is the primary regulatory concern for systems of this type.

Failure to comply risks both significant financial penalties and loss of market access in the EU—outcomes that would be particularly damaging for a company entering the EU market for the first time.

================================================================================
DISCLAIMER
================================================================================

This analysis is based on general knowledge of the EU AI Act as published and applicable guidance available through August 2025. It does not constitute legal advice. You should engage qualified EU legal counsel with expertise in AI regulation and employment law in Germany and France before launching your product. Regulatory guidance and implementing acts may have evolved since the knowledge cutoff date.

EU AI ACT COMPLIANCE ANALYSIS: PREDICTIVE POLICING AI TOOL FOR NEIGHBOURHOOD CRIME RISK SCORING
================================================================================================

EXECUTIVE SUMMARY

The proposed deployment of an AI tool that scores neighbourhoods by crime risk using historical arrest data, social media monitoring, and demographic data triggers multiple provisions of Regulation (EU) 2024/1689 (the EU AI Act). The vendor's characterisation of the system as merely a "decision support tool" does not determine its legal classification — the Act classifies AI systems by their function, purpose, and the data they use, not by marketing labels. This system faces serious risk of being classified as a prohibited AI practice under Article 5(1)(d) and/or Article 5(1)(c), and at minimum constitutes a high-risk AI system under Annex III, Area 6 (Law Enforcement). Deployment may be unlawful from 2 February 2025 onward.

---

STEP 1: ROLE AND SCOPE IDENTIFICATION (Art. 3)

The municipality is the DEPLOYER (Art. 3(4)): a public authority using an AI system under its own authority for law enforcement and public safety purposes. The vendor is the PROVIDER (Art. 3(3)): the entity that developed the system and places it on the market.

Both parties bear distinct obligations. Critically, as a public authority deployer, the municipality bears specific obligations under Art. 26 and Art. 27, and cannot lawfully deploy the system if it falls within a prohibited category or if the provider has not completed registration in the EU AI database (Art. 60).

Member State of operation: An EU Member State municipality — the Act applies in full.

---

STEP 2: AI SYSTEM CLASSIFICATION (Art. 3(1))

The system clearly meets the Art. 3(1) definition of an AI system: it is a machine-based system that, for a given objective (crime risk scoring), infers from inputs (historical arrest data, social media data, demographic data) how to generate outputs (neighbourhood risk scores) that affect real environments (policing decisions and resource allocation). The "decision support" framing is legally irrelevant to this determination.

---

STEP 3: PROHIBITED PRACTICES SCREEN (Art. 5 — applies from 2 February 2025)

This is the most critical legal question. The system must be screened against all eight prohibited practices. Two categories are highly likely to apply; a third raises serious concerns.

3A. Art. 5(1)(d) — Predictive Criminal Risk Assessment [HIGH PROBABILITY OF PROHIBITION]

Article 5(1)(d) prohibits AI systems that assess the risk of natural persons committing criminal offenses based solely on profiling or on assessment of personality/character traits.

The described system scores neighbourhoods based on:
- Historical arrest data (a proxy for criminal conduct of past individuals in an area)
- Social media monitoring (behavioural and character-based signals)
- Demographic data (group-level attributes including protected characteristics)

Although the system scores neighbourhoods rather than named individuals, this does not automatically escape the prohibition. The Recitals and the Act's fundamental rights framing make clear that systems assessing crime risk through profiling — even at an area level — fall within this prohibition when they are used to direct law enforcement action toward individuals or groups. When police resources are directed to a neighbourhood because its residents have a high "crime risk score," the system functionally profiles those residents as criminal threats based on demographic and historical data rather than on objective, verifiable facts directly linked to their own criminal activity.

The single exception in Art. 5(1)(d) applies only to systems "supporting human assessment based on objective, verifiable facts directly linked to criminal activity." This exception is narrow. Historical arrest data is not equivalent to verified criminal conduct (arrests do not prove criminality); demographic data has no direct link to individual criminal activity; and social media monitoring produces inferred behavioural signals, not verified facts. The system does not qualify for this exception.

Conclusion: There is a strong legal argument that this system is prohibited under Art. 5(1)(d). Any deployment from 2 February 2025 risks enforcement action.

3B. Art. 5(1)(c) — Social Scoring [SIGNIFICANT RISK]

Article 5(1)(c) prohibits AI systems that evaluate or classify natural persons or groups based on social behaviour over a period of time or inferred personal characteristics, where this leads to:
- Detrimental or unfavourable treatment of persons or groups in unrelated social contexts; OR
- Treatment that is disproportionate or unjustified relative to the social context in which the behaviour occurred.

A neighbourhood crime risk score derived from demographic data and social media monitoring constitutes an evaluation of groups based on inferred personal characteristics and social behaviour. When those scores result in increased police presence, stop-and-search activity, or resource allocation affecting residents, this constitutes detrimental treatment of persons based on where they live and their demographic profile — not based on any personal action they have taken. This is precisely the discriminatory social scoring dynamic that Art. 5(1)(c) prohibits.

The use of demographic data as a scoring input is particularly problematic. Demographic data as a predictor of crime risk functions as a proxy for protected characteristics (race, ethnicity, national origin, socioeconomic status), leading to systematically disproportionate treatment of communities based on their composition rather than individual conduct.

Conclusion: Significant risk that the system also constitutes prohibited social scoring under Art. 5(1)(c).

3C. Art. 5(1)(g) — Biometric Categorisation for Sensitive Attributes [ASSESS FURTHER]

If the social media monitoring component involves facial recognition, image analysis, or biometric processing that infers race, political opinion, or other protected attributes to contribute to the score, Art. 5(1)(g) is additionally engaged. This depends on the specific technical implementation and should be assessed with the vendor.

3D. Summary of Prohibited Practices Screen

The system presents a high probability of falling under Art. 5(1)(d) (predictive criminal assessment) and significant risk under Art. 5(1)(c) (social scoring). If either prohibition applies, the system cannot be lawfully deployed in the EU regardless of the vendor's characterisation, regardless of any contractual terms, and regardless of technical safeguards. No workaround or "decision support" labelling remedies a prohibited practice.

---

STEP 4: RISK TIER DETERMINATION — ASSUMING ARGUENDO THE SYSTEM IS NOT PROHIBITED

If a court or supervisory authority were to determine the system does not meet the prohibition threshold (which would be a contested finding), it would unambiguously be classified as HIGH-RISK under multiple Annex III areas.

4A. Annex III, Area 6 — Law Enforcement (Art. 6(2))

The system falls within at least the following Area 6 sub-categories:

- Annex III, Area 6(d): AI assessing the risk of offending or reoffending (including recidivism assessment). A neighbourhood crime risk score that informs policing of an area and its residents directly assesses offending risk at the population level.

- Annex III, Area 6(e): AI profiling natural persons in the course of criminal detection, investigation, or prosecution. Directing police resources based on demographic and behavioural scoring of neighbourhood residents constitutes profiling in the law enforcement context.

- Annex III, Area 6(a): AI for individual risk assessment of becoming a victim of criminal offences (secondary consideration; the system could be framed this way to attempt to avoid other sub-categories, but this does not escape high-risk classification).

4B. Art. 6(3) — Profiling Override

Even if a vendor attempted to argue the system qualifies for non-high-risk exceptions (narrow procedural task, preparatory work, etc.), Art. 6(3) provides a critical override: any Annex III system that profiles natural persons is ALWAYS classified as high-risk, regardless of the exceptions. This system manifestly profiles groups of natural persons. The override applies.

4C. "Decision Support" Framing Does Not Reduce Risk Classification

The vendor's claim that this is merely a "decision support tool" has no legal weight under the Act. The Act classifies systems by their function and data processing, not by whether a human makes a final decision. High-risk AI systems are typically deployed in precisely this "decision support" capacity; the framework anticipates human-in-the-loop scenarios and still classifies them as high-risk. The Art. 6(3) profiling override further eliminates any pathway to a lower classification.

---

STEP 5: HIGH-RISK OBLIGATIONS (Arts. 8–17, 26) — IF NOT PROHIBITED

Assuming (for analysis purposes) the system were not prohibited, the full high-risk compliance regime would apply from 2 August 2026:

PROVIDER OBLIGATIONS:

Art. 9 — Risk Management System: The vendor must implement a continuous, lifecycle-spanning risk management system covering all five required steps. This must include specific analysis of risks to fundamental rights, including the risk of discriminatory outcomes from demographic data use. Given the law enforcement context and the population affected, the risk profile is extremely high.

Art. 10 — Data Governance: Historical arrest data raises severe data quality and representativeness concerns. Arrest data reflects historical policing patterns, which are known to be correlated with race and socioeconomic status rather than actual crime rates. Using this data to train a crime risk model embeds and amplifies existing biases. The vendor must demonstrate the data is relevant, sufficiently representative, and free from errors (Art. 10(2)). Use of demographic data and social media data for law enforcement AI training also engages special-category personal data processing restrictions under Art. 10(5) and GDPR Art. 9 — very strict conditions apply.

Art. 11 — Technical Documentation: Full Annex IV technical documentation must be prepared and maintained for 10 years, covering training methodologies, design choices, dataset descriptions, performance metrics, and human oversight measures.

Art. 12 — Automatic Logging: The system must generate automatic event logs during operation enabling reconstruction of how scores were generated and what inputs influenced outcomes.

Art. 13 — Transparency to Deployers: The vendor must provide the municipality with comprehensive instructions for use, including known limitations, performance disparities across demographic groups, circumstances that may lead to risks, and measures for human oversight.

Art. 14 — Human Oversight: The system must be designed to allow oversight persons to understand capabilities and limitations, recognise automation bias, correctly interpret outputs, and override or disregard outputs. This is critical in a law enforcement context where automation bias — over-reliance on AI crime scores — could cause serious fundamental rights violations (unlawful stops, discriminatory policing, wrongful arrests). The municipality must assign persons with the competence, authority, and resources to exercise meaningful oversight.

Art. 15 — Accuracy, Robustness, Cybersecurity: Performance must meet declared accuracy standards throughout the system's lifetime. The vendor must address robustness against feedback loops — a common failure mode in predictive policing where increased police presence in "high-risk" areas produces more arrests, which feed back into the training data to further elevate risk scores, creating a self-reinforcing bias spiral.

Art. 16 — Provider Obligations: The vendor must complete conformity assessment (self-assessment for Annex III Points 2–8), draw up an EU Declaration of Conformity, affix CE marking, and register the system in the EU AI database before placing it on the market or putting it into service.

Art. 17 — Quality Management System: The vendor must maintain a documented QMS covering all 13 required components.

DEPLOYER OBLIGATIONS (ART. 26):

The municipality, as deployer, must:
- Use the system strictly in accordance with the vendor's instructions for use (Art. 26(1))
- Assign competent persons with authority and resources for human oversight (Art. 26(2))
- Ensure input data is relevant and representative where it controls the inputs (Art. 26(3))
- Monitor operations continuously and notify the vendor and market surveillance authority if risks are identified (Art. 26(4))
- Immediately notify if a serious incident occurs (Art. 26(5))
- Retain automatically generated logs for at least 6 months (Art. 26(6))
- Register its use of the system in the EU AI database before deployment (Art. 26(8), Art. 60) — the municipality cannot deploy an unregistered high-risk system

---

STEP 6: FUNDAMENTAL RIGHTS IMPACT ASSESSMENT (ART. 27)

As a public authority deploying a high-risk AI system in Annex III Area 6 (law enforcement), the municipality is required to conduct a Fundamental Rights Impact Assessment (FRIA) before deployment (Art. 27).

The FRIA must address:
- The processes in which the system will be used and the time period and frequency of use
- The categories of persons likely to be affected (this system disproportionately affects residents of certain neighbourhoods, who are likely to be drawn from specific demographic, racial, or socioeconomic groups)
- Specific risks of harm to affected persons (stigmatisation of communities, discriminatory policing, chilling effects on social media expression, violation of presumption of innocence)
- Human oversight measures planned under Art. 14
- Measures to address fundamental rights risks

Where GDPR also requires a Data Protection Impact Assessment (DPIA) — which it will, given the processing of personal data including special-category data at scale for law enforcement purposes — the FRIA may be conducted alongside or integrated into the DPIA.

---

STEP 7: CONFORMITY ASSESSMENT (ART. 43)

For Annex III Points 2–8 systems (which includes law enforcement — Area 6), the conformity assessment path is self-assessment by the provider under Annex VI (internal control procedure). Third-party notified body assessment is not available for this category (unlike biometric systems under Area 1). However, for law enforcement contexts, the relevant market surveillance authority may act in a supervisory capacity.

The provider must complete this conformity assessment before placing the system on the market, draw up the EU Declaration of Conformity (Art. 47, retained for 10 years), affix CE marking (Art. 48), and register in the EU AI database (Art. 49).

---

STEP 8: PENALTIES (ART. 99)

Violations carry severe financial penalties:

- Prohibited AI practices (Art. 5 violations, e.g., if system is found prohibited under Art. 5(1)(d) or 5(1)(c)): Up to €35,000,000 or 7% of total worldwide annual turnover for the preceding year — whichever is higher.

- Provider or deployer violations of high-risk obligations (Arts. 8–17, 26): Up to €15,000,000 or 3% of total worldwide annual turnover.

- Providing incorrect, incomplete, or misleading information to authorities: Up to €7,500,000 or 1% of total worldwide annual turnover.

In addition to financial penalties, national authorities have powers under Art. 79 to order withdrawal of the system from service, suspension of use, and prohibition of deployment. Public reputational damage for a municipality deploying an unlawful surveillance AI tool is also a significant non-financial risk.

---

GDPR INTERSECTION

Independent of the EU AI Act, the use of historical arrest data, social media monitoring, and demographic data by a public authority for law enforcement-adjacent purposes engages:

- GDPR Art. 5 (data minimisation, purpose limitation, accuracy principles)
- GDPR Art. 9 (special-category data — demographic data used as race or ethnicity proxy)
- GDPR Art. 22 (rights related to automated decision-making and profiling)
- Law Enforcement Directive (LED, 2016/680) if the processing is by a competent authority for prevention, investigation, detection, or prosecution of criminal offences
- GDPR Art. 35 / LED Art. 27: mandatory DPIA before processing likely to result in high risk to individuals' rights and freedoms

The use of social media monitoring for law enforcement purposes in particular raises serious concerns under GDPR's purpose limitation principle (Art. 5(1)(b)) — social media users did not consent to their data being used to generate crime risk scores about their neighbourhoods.

---

LEGAL RISK SUMMARY

| Risk | Basis | Probability | Consequence |
|---|---|---|---|
| System is prohibited (predictive criminal assessment) | Art. 5(1)(d) | HIGH | Immediate ban; €35M / 7% turnover fine |
| System is prohibited (social scoring) | Art. 5(1)(c) | SIGNIFICANT | Immediate ban; €35M / 7% turnover fine |
| System is high-risk, vendor non-compliant (no conformity assessment, registration, CE marking) | Arts. 16, 43, 48, 49 | HIGH if not prohibited | €15M / 3% turnover fine; withdrawal order |
| Municipality deploys without FRIA | Art. 27 | HIGH if deployed | €15M / 3% turnover fine |
| Municipality deploys without EU AI database registration | Art. 60 | HIGH if deployed | €15M / 3% turnover fine |
| GDPR violations from data processing | GDPR Arts. 5, 9, 22, 35 | HIGH | Separate €20M / 4% turnover fine under GDPR |
| Discrimination / fundamental rights violations | EU Charter Arts. 7, 8, 21; ECHR | HIGH | Judicial review, civil liability, public inquiry |

---

RECOMMENDATIONS FOR THE MUNICIPALITY

1. DO NOT PROCEED with deployment until a full legal opinion on Art. 5(1)(d) and 5(1)(c) applicability has been obtained from qualified EU AI Act counsel.

2. Commission an independent legal and technical assessment of whether the system meets the Art. 5(1)(d) prohibition criteria before any procurement or pilot. This assessment should be documented to demonstrate due diligence.

3. Require the vendor to demonstrate: (a) completed conformity assessment under Art. 43; (b) EU Declaration of Conformity under Art. 47; (c) CE marking under Art. 48; (d) EU AI database registration under Art. 49; (e) full Annex IV technical documentation under Art. 11; (f) instructions for use under Art. 13.

4. If proceeding, conduct a Fundamental Rights Impact Assessment (Art. 27) and integrate it with a GDPR DPIA (GDPR Art. 35) before any deployment.

5. If proceeding, register the municipality's use in the EU AI database (Art. 60) before deployment.

6. Do not rely on the "decision support" framing as a legal shield. The Act classifies systems by function and the Art. 6(3) profiling override eliminates any pathway to lower risk classification for this system type.

7. Consider whether the policy objective (improved public safety) can be achieved through less invasive and legally compliant means. This is relevant both to proportionality analysis under the EU Charter and to demonstrating that the system meets the Art. 5(1)(d) exception (objective, verifiable facts directly linked to criminal activity) — which this system does not currently meet.

CONCLUSION

The predictive policing tool described is almost certainly either prohibited under Article 5(1)(d) (predictive criminal assessment) and/or Article 5(1)(c) (social scoring) of the EU AI Act, with those prohibitions applying from 2 February 2025. Even if not prohibited, it is unambiguously a high-risk AI system under Annex III Area 6, triggering the full conformity regime. The vendor's "decision support tool" characterisation has no legal effect on this classification. Proceeding without thorough legal analysis and the required compliance steps exposes both the municipality and the vendor to penalties of up to €35 million or 7% of global annual turnover, regulatory enforcement orders, and significant reputational and legal liability under the EU Charter of Fundamental Rights and GDPR.

EU AI ACT COMPLIANCE ANALYSIS: PREDICTIVE POLICING AI FOR NEIGHBOURHOOD CRIME RISK SCORING
================================================================================================

EXECUTIVE SUMMARY
-----------------
The proposed predictive policing AI tool — scoring neighbourhoods by crime risk using historical arrest data, social media monitoring, and demographic data — almost certainly qualifies as a HIGH-RISK AI system under the EU AI Act (Regulation (EU) 2024/1689), and may even approach a PROHIBITED use case depending on implementation. The vendor's characterisation of it as merely a "decision support tool" does not change its legal classification. Deployment without full compliance with the Act's high-risk obligations would expose the municipality to severe legal, financial, and reputational risks.

---

PART 1: CLASSIFICATION UNDER THE EU AI ACT
-------------------------------------------

1.1 The "Decision Support Tool" Label Is Legally Irrelevant
------------------------------------------------------------
The EU AI Act classifies AI systems based on their intended purpose and potential impact, not on the labels vendors attach to them. Article 9 of Annex III and the risk classification provisions focus on what the system DOES and what domain it operates in. A system that produces crime risk scores used to inform law enforcement decisions cannot escape high-risk classification simply because outputs are framed as "suggestions" rather than "decisions."

Recital 47 of the Act explicitly addresses this: the fact that a human is "in the loop" does not automatically lower the risk classification if the AI output substantially influences human decision-making, especially in high-stakes contexts.

1.2 High-Risk Classification: Annex III, Category 6
-----------------------------------------------------
Under Annex III of the EU AI Act, AI systems used by or on behalf of law enforcement authorities are classified as HIGH-RISK when they are intended to be used:

- For individual risk assessments for criminal offending or reoffending, or assessing the risk of victimisation (Annex III, point 6(a))
- As polygraphs and similar tools (6(b))
- To detect emotional states of natural persons (6(c))
- To detect deep fakes in the context of law enforcement (6(d))
- To evaluate the reliability of evidence in criminal proceedings (6(e))
- For predicting the occurrence or recurrence of actual or potential criminal offences based on profiling natural persons or assessing personality traits and characteristics (6(f))
- For profiling in the course of detection, investigation, or prosecution of criminal offences (6(g))
- For crime analytics regarding natural persons (6(h))

The proposed neighbourhood crime risk scoring system falls squarely within at least points 6(a), 6(f), and 6(g). Even if framed as targeting "neighbourhoods" rather than individuals, the use of demographic data and social media monitoring of residents means individuals within those neighbourhoods are being profiled. The CJEU's interpretation of "individual" in data protection contexts, and the EU AI Act's own recitals (particularly Recitals 68–74), make clear that area-level profiling that has individual-level effects is treated as individual profiling for legal purposes.

1.3 Potential Prohibited Use: Article 5 Considerations
-------------------------------------------------------
Beyond high-risk classification, there are serious arguments that this system may engage in PROHIBITED AI practices under Article 5 of the EU AI Act:

a) Article 5(1)(d) — Real-Time Remote Biometric Identification in Public Spaces
   While the primary concern here is biometric identification, the broader architecture of Article 5 demonstrates that the EU legislature views social mass surveillance as fundamentally incompatible with EU values. Social media monitoring of entire neighbourhoods for crime prediction purposes occupies the spirit of this prohibition.

b) Article 5(1)(e) — AI Systems Creating or Expanding Facial Recognition Databases by Untargeted Scraping
   If social media monitoring includes scraping profile images or identifying individuals from public posts, this prohibition applies directly.

c) Article 5(1)(d) and related provisions on Social Scoring
   Article 5(1)(c) prohibits AI systems used by public authorities for social scoring — "the evaluation or classification of natural persons or groups of persons over a period of time based on their social behaviour or known or predicted personal or professional characteristics, with the social score leading to detrimental or unfavourable treatment of those persons." A neighbourhood crime risk score derived from demographic data and social media monitoring that then results in increased police presence, surveillance, or stops fits this description precisely. The European Data Protection Board (EDPB) and several EU legal scholars have specifically flagged predictive policing of this type as potentially prohibited social scoring.

d) Article 5(1)(b) — Exploitation of Vulnerabilities
   Using demographic data (which may serve as a proxy for socioeconomic status, ethnicity, or immigration status) to score communities could constitute exploiting the vulnerabilities of specific groups of people.

---

PART 2: HIGH-RISK OBLIGATIONS (IF NOT PROHIBITED)
---------------------------------------------------
Assuming the system is classified as high-risk rather than prohibited, the municipality and vendor must comply with the extensive obligations in Articles 9–15 of the EU AI Act:

2.1 Risk Management System (Article 9)
---------------------------------------
A continuous, iterative risk management system must be established and documented throughout the entire lifecycle of the AI system. This includes:
- Identification and analysis of known and reasonably foreseeable risks
- Risk estimation and evaluation for each intended purpose
- Evaluation of risks arising from reasonably foreseeable misuse
- Adoption of appropriate risk management measures

2.2 Data and Data Governance (Article 10)
------------------------------------------
High-risk AI systems must use training, validation, and test data that are:
- Subject to appropriate data governance and management practices
- Relevant, representative, free of errors, and complete (to the extent possible)
- Appropriate for the intended geographic, behavioural, or functional setting
- Examined for possible biases

This is particularly problematic for predictive policing tools using historical arrest data, because:
- Historical arrest data reflects past policing decisions, which are themselves biased (communities of colour and low-income areas have historically faced disproportionate policing)
- Using biased historical data to train predictive models encodes and amplifies existing biases
- Demographic data as a feature almost certainly introduces protected-characteristic proxies

2.3 Technical Documentation (Article 11 and Annex IV)
------------------------------------------------------
Extensive technical documentation must be prepared before market placement, covering system design, development methodology, training data characteristics, performance metrics, known limitations, and human oversight measures.

2.4 Record-Keeping and Logging (Article 12)
--------------------------------------------
The system must automatically record logs to enable traceability and auditability, including:
- Operational period and inputs
- Reference database against which input was checked
- Results of the AI's processing

2.5 Transparency and Provision of Information (Article 13)
-----------------------------------------------------------
Users (the municipality/law enforcement personnel) must receive instructions for use that include the system's intended purpose, level of accuracy, known or foreseeable limitations, and circumstances under which human oversight is necessary.

2.6 Human Oversight (Article 14)
---------------------------------
High-risk AI systems must be designed to allow for effective human oversight. Specifically:
- Natural persons must be able to understand the system's capabilities and limitations
- They must be able to detect anomalies, dysfunctions, and unexpected performance
- They must be able to disregard or override output
- No obligation to deploy the system must override the human's ability to exercise judgment

This is the article most directly undermined by the "decision support tool" framing. A system cannot claim human oversight compliance if operational pressures, resource constraints, or cognitive biases (automation bias) mean officers consistently follow algorithmic recommendations without genuine review.

2.7 Accuracy, Robustness, and Cybersecurity (Article 15)
----------------------------------------------------------
High-risk AI systems must achieve appropriate levels of accuracy and robustness, and be resilient to errors, faults, and inconsistencies (including adversarial attacks on training data).

2.8 Fundamental Rights Impact Assessment (Article 27)
------------------------------------------------------
Deployers of high-risk AI systems must conduct and document a Fundamental Rights Impact Assessment (FRIA) before deployment, covering:
- The population affected
- The nature and severity of impact on fundamental rights
- Expected benefits and risks
- Whether the system involves processing of special categories of personal data
- Measures taken to mitigate identified risks

2.9 Registration (Article 49 and the EU Database)
--------------------------------------------------
Before deploying a high-risk AI system listed in Annex III, the deployer must register the system in the EU database maintained by the Commission.

2.10 Conformity Assessment (Article 43)
----------------------------------------
For high-risk AI systems in Annex III areas involving law enforcement, a conformity assessment must be conducted before deployment. Depending on the specific category, this may require third-party involvement rather than self-assessment.

2.11 Notification to Market Surveillance Authorities
-----------------------------------------------------
The competent national authority (designated by each Member State) may require notification of deployment. Law enforcement AI systems may face heightened scrutiny from supervisory authorities.

---

PART 3: INTERACTION WITH GDPR AND OTHER EU LAW
------------------------------------------------

3.1 GDPR / Law Enforcement Directive (LED)
-------------------------------------------
Law enforcement processing of personal data is governed not by the GDPR (Regulation 2016/679) but by the Law Enforcement Directive (LED, Directive 2016/680). The LED:
- Requires a clear and specific legal basis for processing
- Restricts processing of special categories of data (including racial or ethnic origin, which demographic data may proxy) to cases of strict necessity
- Requires that automated decision-making in individual cases has specific legal basis and appropriate safeguards
- Imposes data minimisation, purpose limitation, and storage limitation obligations

Using demographic data (which likely constitutes or proxies for racial/ethnic origin, a special category under Article 10 LED) for crime risk scoring requires Member State law explicitly authorising such processing and providing adequate safeguards — a very high bar.

3.2 ECHR Article 8 (Right to Privacy) and Article 14 (Non-Discrimination)
--------------------------------------------------------------------------
The European Court of Human Rights has found that predictive policing and algorithmic profiling tools may violate Article 8 where they lack a sufficiently precise legal basis, are not necessary in a democratic society, or are applied without adequate procedural safeguards. The use of demographic data raises serious Article 14 ECHR concerns about discriminatory application.

3.3 EU Charter of Fundamental Rights
--------------------------------------
Articles 7 (respect for private life), 8 (protection of personal data), 21 (non-discrimination), and 47 (right to an effective remedy) are all engaged. The EU AI Act itself, in its Recitals and Article 27, explicitly links the FRIA requirement to the Charter.

3.4 Schufa Holding / Automated Profiling Case Law
--------------------------------------------------
The CJEU's ruling in Schufa Holding (C-634/21, 2023) established that even presenting an AI-generated score as purely informational and leaving the ultimate decision to a human does not necessarily take the process outside the scope of Article 22 GDPR (prohibition on solely automated decisions with significant effects). By analogy, under the LED, neighbourhood risk scores that systematically direct police resources cannot evade scrutiny by the "support only" label.

---

PART 4: SPECIFIC LEGAL RISKS FOR THE MUNICIPALITY
--------------------------------------------------

4.1 Regulatory Enforcement
----------------------------
- Market surveillance authorities and national AI supervisory bodies (to be designated under Article 70) can investigate, require corrective action, impose usage restrictions, or order withdrawal of the system.
- Fines under Article 99 of the EU AI Act for deploying a prohibited AI system can reach €35 million or 7% of global annual turnover (whichever is higher). For high-risk violations (non-compliance with obligations), fines can reach €15 million or 3% of global turnover.
- The municipality as a public authority deploying the system is the "deployer" under Article 3(4) and bears primary responsibility for deployment-phase compliance, while the vendor as "provider" bears responsibility for the system's design and documentation.

4.2 Data Protection Enforcement
---------------------------------
- The national data protection authority (DPA) can investigate under the LED and order processing to cease, impose corrective measures, and impose administrative fines (under LED framework).
- The EDPB has issued guidance on predictive policing that is highly skeptical and has encouraged DPAs to scrutinise such systems.

4.3 Civil Liability
---------------------
- Individuals who can show harm from discriminatory or incorrect risk scoring may bring civil claims under national law and, prospectively, under the EU AI Liability Directive (once adopted) which creates disclosure and causation presumption mechanisms for AI-related harm.
- The EU Product Liability Directive (revised version) may also apply to software causing harm.

4.4 Discrimination Law
------------------------
- Using demographic data that proxies protected characteristics (race, ethnicity, religion) in crime risk scoring creates exposure under EU anti-discrimination law (Race Equality Directive 2000/43/EC) and national equality law.
- Even facially neutral features can constitute indirect discrimination if they produce a disparate impact on protected groups without objective justification — a nearly impossible standard to meet in this context.

4.5 Procurement and Vendor Liability
--------------------------------------
- If the vendor provided false or misleading assurances about compliance ("just a decision support tool"), the municipality may have remedies against the vendor under the procurement contract and under general contract law principles.
- However, deployers cannot outsource their compliance obligations — the municipality remains liable to affected individuals and regulators regardless of vendor representations.

4.6 Reputational and Political Risk
-------------------------------------
- Several EU Member States (Netherlands, France, Denmark, Spain) have had high-profile controversies or judicial rulings on predictive policing tools. Dutch courts ordered the SyRI social scoring system to be shut down in 2020 on fundamental rights grounds.
- Public and civil society scrutiny of such systems is intense; municipalities face reputational damage from deploying discriminatory algorithmic tools even if full legal enforcement has not yet occurred.

---

PART 5: THE "DECISION SUPPORT" VENDOR CLAIM — WHY IT FAILS
------------------------------------------------------------

The vendor's characterisation of the tool as merely providing "decision support" is a common but legally insufficient argument for several reasons:

1. FUNCTIONAL TEST APPLIES: The EU AI Act applies a functional test — what does the system actually do, not what the vendor calls it.

2. AUTOMATION BIAS IS DOCUMENTED: Research consistently shows that when algorithms produce risk scores, human decision-makers give them disproportionate weight (automation bias), effectively converting "recommendations" into decisions. EU law recognises this; Article 14 requires that human oversight be genuinely effective, not merely formal.

3. SYSTEMIC EFFECT IS A LEGAL PROXY: Even if no individual decision is fully automated, if the aggregate effect of neighbourhood risk scores is to systematically concentrate police resources in certain areas, leading to more arrests, more data fed back into the model, and a self-reinforcing feedback loop, this constitutes a systemic harm that EU law addresses.

4. LED ARTICLE 11 SAFEGUARDS APPLY REGARDLESS: The LED's restrictions on profiling and automated processing apply to systematic processing in law enforcement contexts even where a human formally makes the final call.

5. PROHIBITED USE ASSESSMENT IS NOT AVOIDABLE: The question of whether the system is PROHIBITED under Article 5 must be assessed regardless of vendor framing. A municipality that deploys a prohibited system cannot defend itself by pointing to vendor labels.

---

PART 6: CONCLUSION AND RECOMMENDATIONS
----------------------------------------

CONCLUSION:
The proposed predictive policing AI tool as described is almost certainly a HIGH-RISK AI system under the EU AI Act, subject to comprehensive pre-deployment obligations. It may additionally constitute a PROHIBITED AI system under Article 5 if it is found to constitute social scoring by a public authority or to exploit the vulnerabilities of demographic groups. The "decision support tool" characterisation is legally irrelevant and provides no protection.

RECOMMENDATIONS FOR THE MUNICIPALITY:

1. HALT PROCUREMENT until a full independent legal and technical assessment is completed. The financial and reputational risks of deploying a non-compliant or prohibited system vastly outweigh any operational benefits.

2. COMMISSION A FUNDAMENTAL RIGHTS IMPACT ASSESSMENT (Article 27) before any deployment decision, conducted by qualified experts independent of the vendor.

3. OBTAIN A LEGAL OPINION on whether the specific system constitutes prohibited social scoring under Article 5(1)(c) or falls within another prohibition.

4. ENGAGE THE NATIONAL DPA AND AI SUPERVISORY AUTHORITY proactively to seek guidance. Several EU DPAs have published opinions on predictive policing; consulting the competent authority before deployment provides some protection and demonstrates good faith.

5. EVALUATE ALTERNATIVES that achieve legitimate public safety objectives without discriminatory profiling — community policing programmes, targeted and lawful investigative techniques, transparency-based approaches.

6. IF PROCEEDING, ensure full compliance with all high-risk obligations: risk management system, data governance audit (especially bias assessment of training data), technical documentation, conformity assessment, registration in the EU AI Act database, robust and genuine human oversight procedures, and staff training.

7. REVIEW THE PROCUREMENT CONTRACT to understand vendor warranties, compliance representations, indemnification provisions, and liability allocation.

8. NOTE THAT COMPLIANCE WITH THE AI ACT DOES NOT GUARANTEE COMPLIANCE WITH THE LED, GDPR (where applicable), ECHR, OR EU CHARTER — all must be independently satisfied.

The fundamental legal reality is this: using demographic data and social media monitoring to produce crime risk scores for neighbourhoods, applied by a public law enforcement authority, sits at the intersection of the EU AI Act's most sensitive categories. Neither the vendor's framing nor the municipality's good intentions change the legal classification or the rights of individuals affected. In the EU legal order as of 2024–2026, such systems face a very high — and likely insurmountable — compliance burden, and their prohibition must be seriously considered before any deployment proceeds.

---

REFERENCES AND APPLICABLE INSTRUMENTS
---------------------------------------
- EU AI Act: Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 (in force from 1 August 2024; most provisions applicable from 2 August 2026, but prohibited practices from 2 February 2025 and high-risk AI obligations progressively)
- Law Enforcement Directive: Directive (EU) 2016/680
- GDPR: Regulation (EU) 2016/679
- EU Charter of Fundamental Rights, particularly Articles 7, 8, 21, 47
- ECHR Articles 8 and 14
- Race Equality Directive: Directive 2000/43/EC
- CJEU, Schufa Holding v SCHUFA, C-634/21 (7 December 2023)
- EDPB Guidelines on Automated Individual Decision-Making and Profiling (Guidelines 04/2022 on the calculation of fines; Guidelines on Article 22 GDPR)
- Council of Europe, Committee of Ministers, Guidelines on Artificial Intelligence and Data Protection (2019)
- Dutch Court ruling in NJCM v. State of the Netherlands (SyRI case), The Hague District Court, 5 February 2020

NOTE ON TIMING: The EU AI Act's prohibition provisions (Article 5) became directly applicable on 2 February 2025. High-risk AI obligations under Annex III for law enforcement systems apply from 2 August 2026, but deployers are strongly advised to begin compliance preparations immediately. Member States are also in the process of designating national competent authorities and market surveillance authorities, creating an enforcement landscape that will become progressively more active.

EU AI ACT OBLIGATIONS FOR A GPAI MODEL PROVIDER
200B Parameter LLM, 15T Token Training, ~3×10²⁴ FLOPs, Open-Source Release
Regulation (EU) 2024/1689 — Compliance Analysis

═══════════════════════════════════════════════════════════════════════════════

SECTION 1: ROLE AND SCOPE IDENTIFICATION (Art. 3)
═══════════════════════════════════════════════════════════════════════════════

Your organisation is a PROVIDER under Art. 3(3) of the EU AI Act — you are a
natural or legal person developing a GPAI model and placing it on the market
under your own name or trademark (even via an open-source repository). The
Act applies to you if any of the following are true:

  • You are established in the EU; OR
  • The model is placed on the EU market or put into service in the EU; OR
  • The outputs of the model are used in the EU.

Open-source release does not remove provider status. You remain the provider
who places the model on the market. Downstream users who fine-tune or deploy
the model may themselves become providers or deployers of derived AI systems,
but your obligations as the upstream GPAI model provider persist.

═══════════════════════════════════════════════════════════════════════════════

SECTION 2: GPAI MODEL CLASSIFICATION (Art. 3(63), Art. 51)
═══════════════════════════════════════════════════════════════════════════════

2.1 Does your model qualify as a GPAI model under Art. 3(63)?

Yes — all four qualifying criteria are met:

  (i)  LARGE-SCALE TRAINING: 15 trillion tokens and ~3×10²⁴ FLOPs constitutes
       training with "large amounts of data using self-supervision at scale."

  (ii) SIGNIFICANT GENERALITY: A 200B parameter GPT-class LLM is designed to
       perform a wide range of distinct tasks — summarisation, translation,
       coding, reasoning, question-answering, content generation, etc.

  (iii) MULTIPLE PURPOSES: The model can serve multiple different purposes
       whether deployed directly or integrated into downstream AI systems.

  (iv) NOT IN PRE-RELEASE R&D: You intend to place it on the market via
       open-source release, so the pre-release exclusion does not apply.

Conclusion: Your model IS a GPAI model within the meaning of Art. 3(63). The
GPAI obligations framework (Arts. 51–55) governs your obligations, not the
general high-risk AI system framework (Arts. 8–17) — GPAI models are assessed
under Chapter V of the Act, not Chapter III.

2.2 Does your model have SYSTEMIC RISK under Art. 51?

CRITICAL FINDING — NO SYSTEMIC RISK (at this stage):

The Art. 51 automatic presumption of systemic risk is triggered when training
compute exceeds 10²⁵ FLOPs (100 septillion floating point operations).

Your model: ~3×10²⁴ FLOPs
Threshold:  10²⁵ FLOPs (i.e., 1×10²⁵ FLOPs)

Your compute is approximately one-third of the systemic risk threshold. You do
NOT automatically qualify as a systemic risk GPAI model under Art. 51(1).

HOWEVER — IMPORTANT CAVEATS:

  (a) COMMISSION DESIGNATION (Art. 51(2)): The European Commission retains
      the power to designate a model as having systemic risk based on criteria
      independent of the FLOPs threshold, including:
        • High-impact capabilities identified through model evaluation
        • Broad reach across the EU (e.g., a popular open-source model)
        • Potential negative effects on public health, safety, public security,
          or fundamental rights
        • Other criteria in Annex XIII (parameter count, user base size,
          domain specificity, multimodal capabilities)

      A 200B parameter model with broad open-source distribution could attract
      Commission attention under Annex XIII criteria, particularly if it
      achieves wide adoption or demonstrates high-impact capabilities on
      standard evaluations.

  (b) DYNAMIC THRESHOLD (Art. 51(3)): The Commission may amend the 10²⁵ FLOPs
      threshold via delegated acts. As compute efficiency improves and smaller
      models achieve greater capabilities, the threshold may be lowered,
      potentially capturing your model in future.

  (c) MONITORING OBLIGATION: Providers who "know or should reasonably know"
      their model is approaching the threshold should monitor total compute
      across all training runs. If you conduct additional pre-training,
      continual training, or other large-scale compute operations, the
      cumulative FLOPs may approach or exceed the threshold.

  (d) NOTIFICATION TRIGGER: If you cross the threshold, you must notify the
      AI Office within 2 weeks (Art. 51(4)).

CONCLUSION ON SYSTEMIC RISK: As currently described, you are a standard GPAI
model provider, NOT a systemic risk GPAI model provider. Your obligations are
governed exclusively by Art. 53 (universal GPAI obligations) and the
open-source exception therein, as detailed below.

═══════════════════════════════════════════════════════════════════════════════

SECTION 3: OPEN-SOURCE EXCEPTION — WHAT IT DOES (AND DOES NOT) COVER
(Art. 53(2))
═══════════════════════════════════════════════════════════════════════════════

Art. 53(2) provides a significant but conditional exemption for open-source
GPAI model providers. Providers releasing GPAI models under open-source or
free licences are EXEMPT from the following Art. 53 obligations:

  EXEMPT:  Art. 53(1)(a) — Technical documentation (Annex XI content)
  EXEMPT:  Art. 53(1)(b) — Downstream provider information (Annex XII content)

However, ALL of the following obligations continue to apply even to open-source
GPAI providers:

  MANDATORY: Art. 53(1)(c) — Copyright compliance policy
  MANDATORY: Art. 53(1)(d) — Public training content summary

And critically:

  MANDATORY: If the model is later designated as having systemic risk (whether
  by crossing the FLOPs threshold or by Commission designation), the
  open-source exception ceases to apply and FULL Art. 53 + Art. 55 obligations
  are immediately triggered.

The practical effect: your open-source release strategy provides meaningful
regulatory relief today, but does not immunise you from future obligations if
your model's reach or capabilities lead to a systemic risk designation.

═══════════════════════════════════════════════════════════════════════════════

SECTION 4: YOUR MANDATORY OBLIGATIONS AS AN OPEN-SOURCE GPAI PROVIDER
(Art. 53(1)(c) and (d) — Applies from 2 August 2025)
═══════════════════════════════════════════════════════════════════════════════

4.1 COPYRIGHT COMPLIANCE POLICY — Art. 53(1)(c)
    [Directive (EU) 2019/790 on Copyright in the Digital Single Market]

You must implement and maintain a policy to comply with EU copyright law,
specifically:

  REQUIREMENT: Establish mechanisms to respect text and data mining (TDM)
  opt-outs reserved by rights-holders under Art. 4(3) of Directive 2019/790.

Under Art. 4(3) of the DSM Copyright Directive, rights-holders may opt out of
permitting TDM of their works for purposes other than scientific research.
These opt-outs must be expressed in a machine-readable format (e.g., robots.txt
directives, HTTP headers, or metadata tags).

Practical implementation requirements:

  (a) DOCUMENTATION: Maintain records of your training data sources and
      demonstrate that rights-holder TDM opt-outs were honoured during training.

  (b) TECHNICAL MECHANISMS: Implement systems to detect and respect opt-out
      signals when crawling or acquiring training data. For an already-trained
      model, this means documenting the compliance steps taken during the
      training data acquisition phase.

  (c) PUBLIC DESCRIPTION: The policy must be publicly described — rights-holders
      and the public must be able to understand what mechanisms exist.

  (d) ONGOING APPLICABILITY: If you conduct further training runs or fine-tune
      the model on new data, the policy must govern those activities.

Note: Failure to respect TDM opt-outs could expose you to copyright
infringement liability under national law implementing Directive 2019/790,
independent of AI Act enforcement. The AI Act Art. 53(1)(c) obligation is the
regulatory compliance layer on top of substantive copyright law.

4.2 PUBLIC TRAINING CONTENT SUMMARY — Art. 53(1)(d)

You must draw up and make publicly available a sufficiently detailed summary
of the content used to train your GPAI model.

Format: Must follow a template published by the European Commission (template
required to be issued by the Commission under the Act; currently being
developed through the GPAI Code of Practice process).

Content requirements (based on the Act and draft Codes of Practice guidance):

  (a) CATEGORIES OF TRAINING DATA: Describe the types and sources of data
      used — web crawl data, books, code repositories, scientific papers,
      etc. — at a level of granularity that enables understanding without
      necessarily revealing proprietary details.

  (b) LANGUAGES: Languages represented in the training corpus.

  (c) DATA PROCESSING: Overview of filtering, deduplication, quality
      screening, and safety-related data curation steps applied.

  (d) EXCLUSIONS AND OPT-OUTS: Description of how TDM opt-outs and
      exclusion lists were applied.

  (e) SCALE: Approximate data volumes (you have publicly stated 15T tokens,
      which would satisfy this element).

  (f) TIME PERIOD: When data was collected and from what time periods.

Purpose of this obligation: Enable downstream AI system providers who
integrate your model, and the general public, to understand what the model
was trained on — relevant for bias assessment, copyright attribution, and
downstream compliance.

Publication: The summary must be publicly available, meaning accessible
without restriction (consistent with the open-source ethos of your release).
Publishing it alongside your model card or in your model repository would
satisfy the publication requirement.

═══════════════════════════════════════════════════════════════════════════════

SECTION 5: OBLIGATIONS THAT APPLY IF OPEN-SOURCE EXCEPTION IS LOST
(Art. 53(1)(a) and (b) — Would Apply if Systemic Risk Designated)
═══════════════════════════════════════════════════════════════════════════════

While not currently mandatory given your open-source status and sub-threshold
compute, understanding these obligations is essential for risk planning.

5.1 TECHNICAL DOCUMENTATION — Art. 53(1)(a) [Annex XI Content]

If your open-source exception were lost, you would need to prepare and
maintain technical documentation covering (Annex XI):

  • General description: intended purpose, types of tasks performable,
    interaction modes (API, inference endpoint, local deployment)
  • Development process: data sources, data processing and filtering methods,
    training techniques (architecture, training objectives, RLHF or other
    alignment steps), compute infrastructure, and total compute used
  • Testing and evaluation: benchmarks used (e.g., MMLU, HumanEval, BIG-Bench),
    evaluation results, safety testing (red-teaming) methodology and outcomes
  • Known limitations: performance degradation conditions, hallucination rates,
    biases identified, out-of-distribution failure modes
  • Foreseeable risks: misuse scenarios, potential for harmful outputs
  • Responsible disclosure: contact information for reporting safety issues,
    vulnerability disclosure programme
  • Keep up-to-date and provide to AI Office and national authorities on request

5.2 DOWNSTREAM PROVIDER INFORMATION — Art. 53(1)(b) [Annex XII Content]

If required, you must document and make available to downstream AI system
providers who integrate your model:

  • Capabilities and limitations (enabling them to meet their own obligations)
  • Integration instructions and API/interface specifications
  • Security measures and recommendations
  • Results of evaluations conducted

Note: Even under the open-source exception, voluntarily providing model cards,
system cards, and integration documentation is strongly advisable — it protects
downstream developers and reduces the risk that your model is misused in ways
that could attract regulatory or reputational consequences.

═══════════════════════════════════════════════════════════════════════════════

SECTION 6: ADDITIONAL OBLIGATIONS IF SYSTEMIC RISK IS DESIGNATED
(Art. 55 — Would Apply Only if Systemic Risk Triggered)
═══════════════════════════════════════════════════════════════════════════════

For completeness and contingency planning:

6.1 MODEL EVALUATION AND ADVERSARIAL TESTING (Art. 55(1)(a))
  • Conduct model evaluation according to standardised protocols and
    state-of-the-art tools
  • Conduct adversarial testing / red-teaming to identify systemic risks
  • May be conducted in cooperation with the AI Office

6.2 RISK ASSESSMENT AND MITIGATION (Art. 55(1)(b))
  • Assess and mitigate possible systemic risks from development, placement,
    and deployment, including effects on public health, safety, security,
    and fundamental rights at Union level

6.3 SERIOUS INCIDENT REPORTING (Art. 55(1)(c))
  • Track, document, and promptly report serious incidents and corrective
    actions to the AI Office and relevant national competent authorities
  • Report without undue delay upon becoming aware of an incident

6.4 CYBERSECURITY (Art. 55(1)(d))
  • Ensure adequate cybersecurity protection for the model, physical
    infrastructure, and supply chain
  • Includes protection against model weight theft, unauthorised access,
    and adversarial attacks on model integrity

═══════════════════════════════════════════════════════════════════════════════

SECTION 7: PROHIBITED PRACTICES SCREEN (Art. 5 — Applies from 2 Feb 2025)
═══════════════════════════════════════════════════════════════════════════════

As a GPAI model provider releasing a general-purpose foundation model, the
Art. 5 prohibited practices apply to AI SYSTEMS, not to GPAI models in
isolation. However:

  • You must not design, train, or configure the model to perform prohibited
    practices (e.g., you must not intentionally embed capabilities for social
    scoring, mass biometric surveillance, or manipulation techniques).

  • Downstream deployers who use your model to build AI systems will bear
    primary Art. 5 liability for those systems. However, if you knowingly
    provide a model specifically designed to facilitate prohibited uses, you
    may face regulatory scrutiny and reputational consequences.

  • Your open-source release means you have limited control over downstream
    use — this makes your model documentation, usage policies, and Acceptable
    Use Policy (AUP) critically important as risk mitigation tools, even
    though they are not strictly mandated by the Act for a non-systemic-risk
    GPAI provider.

SPECIFIC PROHIBITED PRACTICES TO CONSIDER IN MODEL DESIGN:

  Art. 5(1)(a): Do not train or configure the model to use subliminal or
  manipulative techniques that distort behaviour causing significant harm.

  Art. 5(1)(c): Do not build social scoring functionality into the model.

  Art. 5(1)(e): Do not enable or encourage untargeted facial recognition
  database creation through model outputs.

  Art. 5(1)(f): Do not design the model specifically for workplace or
  educational emotion inference.

═══════════════════════════════════════════════════════════════════════════════

SECTION 8: HIGH-RISK AI SYSTEM FRAMEWORK — NOT DIRECTLY APPLICABLE
═══════════════════════════════════════════════════════════════════════════════

The high-risk obligations under Arts. 9–17 and 26 (risk management system,
data governance, technical documentation, record-keeping, transparency,
human oversight, accuracy/robustness, quality management system) apply to
HIGH-RISK AI SYSTEMS, not to GPAI models qua models.

Your obligations are:

  AS GPAI PROVIDER: Arts. 51–55 (Chapter V) — as analysed above.

  IF YOU ALSO DEPLOY the model in a high-risk use case yourself (e.g., you
  build and deploy a high-risk application on top of your own GPAI model):
  You would then ALSO bear provider obligations under Arts. 9–17 for that
  downstream high-risk AI system.

  FOR DOWNSTREAM PROVIDERS: Those who integrate your GPAI model into their
  own AI systems and deploy them in high-risk contexts will bear the Arts. 9–17
  obligations for their systems. Your Annex XII information (where required)
  is intended to facilitate their compliance.

═══════════════════════════════════════════════════════════════════════════════

SECTION 9: COMPLIANCE TIMELINE SUMMARY
═══════════════════════════════════════════════════════════════════════════════

| Obligation                              | Article        | Applies From    |
|----------------------------------------|----------------|-----------------|
| Prohibited practices screen             | Art. 5         | 2 Feb 2025      |
| Copyright compliance policy             | Art. 53(1)(c)  | 2 Aug 2025      |
| Public training content summary         | Art. 53(1)(d)  | 2 Aug 2025      |
| Technical documentation (if sys. risk)  | Art. 53(1)(a)  | 2 Aug 2025      |
| Downstream info (if systemic risk)      | Art. 53(1)(b)  | 2 Aug 2025      |
| Art. 55 systemic risk obligations       | Art. 55        | 2 Aug 2025      |
| AI Office notification (if threshold    |                |                 |
| crossed)                                | Art. 51(4)     | Within 2 weeks  |
|                                         |                | of threshold    |

NOTE: GPAI model obligations under Arts. 53–55 have applied since 2 August
2025. If your model is already on the market and you have not yet complied
with Arts. 53(1)(c) and (d), you are currently in breach.

═══════════════════════════════════════════════════════════════════════════════

SECTION 10: PENALTIES FOR NON-COMPLIANCE (Art. 99)
═══════════════════════════════════════════════════════════════════════════════

Violations of GPAI model obligations (Arts. 53–55) constitute violations of
provider/deployer obligations and are subject to:

  MAXIMUM FINE: €15,000,000 OR 3% of total worldwide annual turnover,
  whichever is higher (Art. 99(3)).

  For GPAI systemic risk violations specifically, the Commission itself may
  conduct investigations and impose fines directly (in addition to national
  competent authority enforcement).

  For SMEs and startups: the lower of the fixed amount or percentage applies
  (Art. 99(6)).

Enforcement of GPAI obligations rests primarily with the AI Office (Art. 64).

═══════════════════════════════════════════════════════════════════════════════

SECTION 11: COMPLIANCE PATHWAY AND CODES OF PRACTICE
═══════════════════════════════════════════════════════════════════════════════

The EU AI Act provides three compliance pathways for GPAI obligations:

  1. CODES OF PRACTICE (Primary pathway currently): Voluntary codes developed
     with AI Office involvement are the primary interim mechanism. The GPAI
     Code of Practice has been under development since late 2024 with the
     AI Office. Adherence to an approved Code creates a presumption of
     conformity. You should monitor and consider joining the Code of Practice
     process.

  2. HARMONISED STANDARDS: When published under a Commission mandate to
     European standards bodies (CEN/CENELEC), compliance with harmonised
     standards creates a presumption of conformity. Standards are still being
     developed.

  3. ALTERNATIVE ADEQUATE MEANS: Providers may demonstrate compliance through
     other methods acceptable to the Commission.

RECOMMENDATION: Engage with the GPAI Code of Practice process through the
AI Office, even as an open-source provider. The Code provides practical
guidance on implementing Arts. 53(1)(c) and (d), and participation
demonstrates good faith to regulators.

═══════════════════════════════════════════════════════════════════════════════

SECTION 12: GOVERNANCE CONTACTS AND OVERSIGHT BODIES
═══════════════════════════════════════════════════════════════════════════════

AI OFFICE (Arts. 64–68): Primary regulator for GPAI models. Established
within the European Commission. Key contact point for:
  • Systemic risk notifications (Art. 51(4))
  • GPAI Code of Practice development
  • Serious incident reporting (Art. 55(1)(c)) if systemic risk applies
  • Model evaluation and compliance investigations
  • Access requests for model weights, documentation, training procedures

SCIENTIFIC PANEL (Arts. 68–70): Independent experts who may alert the AI
Office about high-impact capabilities that could trigger systemic risk
designation. May conduct capability assessments relevant to your model.

NATIONAL COMPETENT AUTHORITIES: Member State authorities retain market
surveillance powers and can request technical documentation. For an
open-source provider, the relevant national authority is typically in the
Member State where you are established.

═══════════════════════════════════════════════════════════════════════════════

SECTION 13: STRATEGIC RECOMMENDATIONS
═══════════════════════════════════════════════════════════════════════════════

IMMEDIATE ACTIONS (before or at release):

  1. TRAINING DATA AUDIT: Conduct a thorough review of your training data
     sources to identify any rights-holders who expressed TDM opt-outs under
     Art. 4(3) of Directive 2019/790. Document your review. This is the
     foundation of your Art. 53(1)(c) compliance.

  2. DRAFT COPYRIGHT COMPLIANCE POLICY: Publish a clear, publicly accessible
     policy describing how you identified and respected TDM opt-outs, what
     mechanisms exist for rights-holders to raise concerns, and your commitment
     to ongoing compliance.

  3. DRAFT TRAINING DATA SUMMARY: Prepare your public training content summary
     per Art. 53(1)(d). Publish it in your model repository and on your website.
     Even before the Commission template is published, a comprehensive model
     card addressing training data provenance is advisable.

  4. IMPLEMENT ACCEPTABLE USE POLICY (AUP): While not strictly required for a
     non-systemic-risk open-source GPAI provider, an AUP prohibiting use for
     Art. 5 prohibited practices is a critical risk mitigation measure and
     demonstrates responsible deployment.

  5. MONITOR COMPUTE ACCUMULATION: Track total training compute across all
     runs. Maintain an internal record. If future fine-tuning or additional
     pre-training runs approach the 10²⁵ FLOPs threshold, initiate notification
     procedures.

  6. ENGAGE WITH AI OFFICE: Consider proactive engagement with the AI Office
     and the GPAI Code of Practice process. Early engagement is viewed
     favourably and provides guidance on evolving expectations.

ONGOING:

  7. MONITOR COMMISSION DESIGNATION CRITERIA: Watch for any Commission
     guidance or decisions under Art. 51(2) and Annex XIII that could affect
     your model's designation status as it achieves wider adoption.

  8. SAFETY INCIDENT TRACKING: Even without a formal Art. 55 obligation,
     maintain internal records of known safety issues, misuse reports, and
     significant harms. This positions you for compliance if systemic risk
     obligations are later triggered.

  9. SUPPLY CHAIN TRANSPARENCY: Provide good-faith model cards, evaluation
     results, and safety documentation to support downstream providers meeting
     their own obligations — this is both best practice and reduces the risk
     that downstream misuse is attributed to inadequate upstream disclosure.

═══════════════════════════════════════════════════════════════════════════════

SUMMARY TABLE: YOUR OBLIGATIONS AS AN OPEN-SOURCE GPAI PROVIDER
═══════════════════════════════════════════════════════════════════════════════

| Obligation                          | Article        | Required?      | Notes                                    |
|-------------------------------------|----------------|----------------|------------------------------------------|
| Copyright compliance policy         | Art. 53(1)(c)  | YES            | Core mandatory obligation                |
| Public training content summary     | Art. 53(1)(d)  | YES            | Core mandatory obligation                |
| Technical documentation (Annex XI)  | Art. 53(1)(a)  | NO (currently) | Open-source exception applies            |
| Downstream provider info (Annex XII)| Art. 53(1)(b)  | NO (currently) | Open-source exception applies            |
| Model evaluation / red-teaming      | Art. 55(1)(a)  | NO (currently) | Only if systemic risk designated         |
| Risk assessment and mitigation      | Art. 55(1)(b)  | NO (currently) | Only if systemic risk designated         |
| Serious incident reporting          | Art. 55(1)(c)  | NO (currently) | Only if systemic risk designated         |
| Cybersecurity measures              | Art. 55(1)(d)  | NO (currently) | Only if systemic risk designated         |
| AI Office notification              | Art. 51(4)     | MONITOR        | Required within 2 weeks if FLOPs cross   |
|                                     |                |                | 10²⁵ threshold or designation occurs     |
| Prohibited practices compliance     | Art. 5         | YES            | Model must not be designed for Art. 5    |
|                                     |                |                | prohibited uses                          |

═══════════════════════════════════════════════════════════════════════════════

This analysis is based on Regulation (EU) 2024/1689 (EU AI Act) as published
in the Official Journal of the European Union, and applicable provisions of
Directive (EU) 2019/790 (DSM Copyright Directive). It reflects the regulatory
framework as of May 2026. Implementing acts, delegated acts, Commission
guidance, and harmonised standards continue to be developed and should be
monitored for updates.

EU AI ACT OBLIGATIONS FOR GPAI MODEL PROVIDERS: ANALYSIS FOR A 200B PARAMETER, OPEN-SOURCE LLM

Prepared: May 2026
Regulation Reference: Regulation (EU) 2024/1689 of the European Parliament and of the Council (the "AI Act"), in force from 1 August 2024; GPAI provisions apply from 2 August 2025.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. PRELIMINARY CLASSIFICATION: ARE YOU A GPAI MODEL PROVIDER?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1.1 Definition of a GPAI Model

Article 3(63) of the AI Act defines a "general-purpose AI model" (GPAI model) as an AI model — including where trained with a large amount of data using self-supervision at scale — that displays significant generality and is capable of performing a wide range of distinct tasks, and which can be integrated into a variety of downstream systems or applications. The definition explicitly captures large language models trained at scale.

Your model — 200 billion parameters, trained on 15 trillion tokens — unambiguously falls within this definition. GPT-class models of this scale are paradigmatic GPAI models.

1.2 Who Is the "Provider"?

Article 3(3) defines a provider as any natural or legal person that develops an AI model (including a GPAI model) and places it on the market or puts it into service under their own name or trademark. Placing a model under an open-source licence constitutes placing it on the market. Accordingly, your organisation is the GPAI model provider for all purposes of Chapter V of the AI Act.

1.3 Geographic Scope

The AI Act applies whenever:
  (a) the model is placed on the EU market, regardless of where the provider is established; or
  (b) the output of the model is used in the EU.

Open-source release on platforms such as Hugging Face, GitHub, or similar repositories that are accessible to EU users satisfies condition (a). You are therefore subject to the Regulation irrespective of whether your organisation is domiciled inside or outside the EU.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. THE SYSTEMIC-RISK THRESHOLD AND ITS CONSEQUENCES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2.1 The 10^25 FLOP Threshold

Article 51(1) creates a sub-category of GPAI models "with systemic risk." A model is presumed to have systemic risk if the cumulative amount of compute used for its training, measured in floating-point operations (FLOPs), exceeds 10^25 FLOPs.

Your training compute is approximately 3 × 10^24 FLOPs.

This figure is BELOW the 10^25 FLOPs threshold by roughly a factor of three. Accordingly, your model does NOT trigger the automatic presumption of systemic risk under Article 51(1)(a).

2.2 Discretionary Designation by the AI Office

Article 51(1)(b) preserves the power of the European AI Office to designate a model as having systemic risk based on qualitative criteria, even below the compute threshold. Factors the AI Office may consider include:
  - The number of parameters (200 billion is at the frontier of current publicly available models);
  - The size of the training dataset (15 trillion tokens is extremely large);
  - Modalities and capabilities (including capabilities relevant to CBRN risks, cyber-offensive capabilities, or the ability to influence public opinion at scale);
  - The degree of autonomy and ability to self-replicate;
  - The breadth of downstream deployment.

A 200B parameter model of this training scale sits materially close to the systemic-risk threshold. The AI Office has stated that it will monitor models near the threshold and may initiate designation procedures on its own initiative or upon notification by the provider. Providers should therefore proactively engage with the AI Office and should not assume that being below 10^25 FLOPs provides permanent immunity from systemic-risk obligations.

2.3 Self-Notification Duty

Under Article 52(1), providers of GPAI models must notify the AI Office before placing the model on the market if they believe, or have reason to believe, that their model may qualify as having systemic risk. Given the proximity to the threshold and the model's scale, legal counsel should assess whether a precautionary notification is warranted.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. BASELINE GPAI MODEL OBLIGATIONS (ALL GPAI PROVIDERS — ARTICLE 53)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Every GPAI model provider, regardless of systemic-risk designation, must comply with the following obligations under Article 53(1). These apply to you in full.

3.1 Technical Documentation (Article 53(1)(a))

You must draw up and keep up-to-date technical documentation before placing the model on the market. The documentation must be sufficient to enable the AI Office to assess compliance and must include, at minimum:

  (i)   A general description of the GPAI model, including its intended purposes, the tasks it can perform, and its capabilities and limitations;
  (ii)  Information about the training process, including the training methodology, objectives, and key design choices;
  (iii) Information about the training data, including the type and provenance of training data, data collection and processing procedures, and — critically — a description of how copyright law has been complied with in data sourcing (see Section 4 below);
  (iv)  The model's architecture and number of parameters;
  (v)  Information on compute resources used for training (in your case, approximately 3 × 10^24 FLOPs);
  (vi)  Information on evaluation, testing, and red-teaming conducted;
  (vii) Known and foreseeable risks, including mitigation measures.

Annex XI to the AI Act specifies the minimum information required. The AI Office is empowered to adopt delegated acts supplementing Annex XI; providers should monitor for updates.

3.2 Information to Downstream Providers (Article 53(1)(b))

You must make available to downstream providers (i.e., persons who build AI systems or products using your model) information and documentation adequate for them to understand the model's capabilities and limitations, so that they can comply with their own obligations under the AI Act. This must include at a minimum:

  - A model card describing the intended use cases, capabilities, and limitations;
  - Known risks relevant to deployment;
  - Technical specifications sufficient for integration and safety assessment;
  - Information about the training data and compute used;
  - Any evaluations or benchmarks performed.

This information must be made publicly available in machine-readable form (e.g., a structured model card published alongside the weights). The AI Act does not require you to disclose trade secrets, but the level of detail must be sufficient for downstream providers to discharge their own compliance obligations.

3.3 Copyright Compliance Policy (Article 53(1)(c))

You must put in place a policy to comply with EU copyright law, and in particular with the text and data mining (TDM) exception and opt-out mechanism established under Article 4 of Directive (EU) 2019/790 (the Digital Single Market Directive).

This obligation requires you to:

  (a) Implement technical measures to honour opt-out reservations made by rights-holders under Article 4(3) of Directive 2019/790 (i.e., machine-readable opt-outs such as the TDM reservation standard or robots.txt-style declarations);
  (b) Document your data sourcing methodology and demonstrate that data was either (i) in the public domain, (ii) licensed for TDM purposes, (iii) used under the Article 3 TDM exception for scientific research, or (iv) used under Article 4 for commercial TDM in the absence of a valid opt-out;
  (c) Maintain records of the data sources used and their copyright status.

Note: This is among the most practically challenging obligations for LLMs trained at scale on web-crawled data. You should conduct a thorough review of your training data sources and document the copyright compliance rationale for each major corpus.

3.4 Summary of Training Data (Article 53(1)(d))

You must publish a sufficiently detailed summary of the content used for training the GPAI model. The AI Office has published guidelines on what constitutes a "sufficiently detailed" summary. At minimum, this typically includes:

  - The broad categories of data sources (e.g., web crawl data, books, code repositories, academic papers, licensed datasets);
  - The languages represented;
  - The approximate proportions of each category;
  - Any notable inclusions or exclusions relevant to model behaviour.

This summary must be made publicly available, for example alongside the model release on a public repository or on your organisation's website. It need not disclose commercially sensitive specifics, but must give downstream users and the public a meaningful understanding of the training corpus.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. OPEN-SOURCE RELEASE: THE FREE AND OPEN-SOURCE EXCEPTION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

4.1 Scope of the Exception

Article 53(2) provides a partial exemption from obligations under Article 53(1)(b) and (d) — but NOT from (a) and (c) — for providers of GPAI models that are released under a free and open-source licence. The rationale is that open-source release of the weights and technical documentation itself satisfies the transparency objectives underlying those sub-obligations, because downstream users can inspect the model directly.

To qualify, your licence must meet the following conditions:
  - The parameters (weights) of the model are made publicly available;
  - The licence allows users to access, use, modify, and distribute the model and its modifications; and
  - The licence terms do not restrict the use of the model in a way that would prevent compliance with the AI Act by downstream providers.

Common licences such as Apache 2.0, MIT, and the BigScience RAIL licence may qualify, but certain "open-source" licences with restrictive use clauses (e.g., Llama 2's custom licence restricting commercial use above a threshold) may NOT qualify for the exemption. You should obtain legal advice on whether your chosen licence satisfies Article 53(2).

4.2 What the Exception Does and Does NOT Cover

COVERED BY THE EXCEPTION (obligations reduced or removed):
  - Article 53(1)(b): You are not required to separately provide information to downstream providers beyond what is already publicly available through the open-source release, provided the published documentation is sufficient.
  - Article 53(1)(d): The public summary of training data may be satisfied by publication of your model card and data documentation alongside the open-source release.

NOT COVERED BY THE EXCEPTION (obligations remain in full):
  - Article 53(1)(a): You MUST still prepare and maintain full technical documentation for the AI Office. This is a regulatory compliance document, not merely a user-facing one, and must be available for inspection.
  - Article 53(1)(c): The copyright compliance policy obligation applies in full, regardless of open-source status.

4.3 Systemic-Risk Models: No Open-Source Exemption

If your model were to be designated as having systemic risk (whether now or in the future), the open-source exception under Article 53(2) would NOT apply to the additional systemic-risk obligations under Article 55. Those obligations would apply in full regardless of licensing. This is a critical point for models near the threshold.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. ADDITIONAL OBLIGATIONS IF DESIGNATED AS A SYSTEMIC-RISK GPAI MODEL (ARTICLE 55)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Although your model is currently below the systemic-risk threshold, you should plan for the possibility of designation. The following obligations would apply under Article 55 if your model is designated:

5.1 Adversarial Testing and Red-Teaming

You would be required to perform model evaluations, including adversarial testing (red-teaming), to identify and mitigate systemic risks at EU level. The AI Office is mandated to develop common methodologies and standards for such evaluations in coordination with the European standardisation bodies.

5.2 Incident Reporting

You would be required to report serious incidents and possible corrective actions to the AI Office without undue delay. "Serious incidents" include those resulting in, or risking, significant harm at EU level — for example, large-scale misuse for disinformation, CBRN misuse, or critical infrastructure attacks.

5.3 Cybersecurity Measures

You would be required to implement adequate cybersecurity protection for the model, its training infrastructure, and its weights. For open-source models, this presents particular challenges, since once weights are released, access cannot be revoked.

5.4 Enhanced Technical Documentation

The technical documentation required of systemic-risk providers is more extensive than baseline requirements and must include detailed results of evaluations, red-teaming exercises, and risk mitigation measures.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. CODES OF PRACTICE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

6.1 Mandatory Participation in Code Development

Article 56 establishes that the AI Office shall facilitate the preparation of Codes of Practice for GPAI providers. GPAI model providers are expected — and in practice will be strongly encouraged — to participate in drafting and adhering to these codes. While formal adherence is described as voluntary, compliance with an applicable code creates a rebuttable presumption of compliance with the corresponding obligations under the AI Act.

As of the knowledge cutoff, the AI Office convened drafting processes beginning in late 2024, with Codes of Practice expected to be finalised by August 2025. Your organisation should monitor and engage with this process.

6.2 Compliance as Default

Pending adoption of formal codes, the AI Office expects GPAI providers to demonstrate good-faith compliance with the spirit of Article 53 requirements. Proactive engagement with the AI Office, transparent publication of model documentation, and participation in voluntary evaluations are advisable.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
7. RELATIONSHIP WITH DOWNSTREAM PROVIDERS AND DEPLOYERS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

7.1 Responsibility Allocation

The AI Act distinguishes between:
  - GPAI model providers (you): responsible for the model's intrinsic characteristics and the obligations in Article 53/55;
  - Providers of AI systems built on GPAI models (downstream providers): responsible for compliance of the AI system, including conformity assessment for high-risk AI systems under Article 16;
  - Deployers: responsible for appropriate use in context.

Under Article 25, where a downstream provider builds a high-risk AI system using your GPAI model, they bear primary responsibility for compliance of that system. However, you bear a duty to ensure that the information and documentation you provide is sufficient for them to meet those obligations. Insufficient documentation from you could expose downstream providers to compliance risk and could also expose you to enforcement action.

7.2 Open-Source and Liability

Under Article 53(2), open-source providers benefit from reduced documentation obligations toward downstream providers. However, the licence terms you adopt may affect how courts interpret liability for downstream harms. Licences that disclaim all warranties and limit liability are standard in open-source AI, but they do not displace regulatory obligations under the AI Act. The AI Act imposes public-law obligations on providers regardless of contractual terms.

7.3 Downstream Use in High-Risk AI Systems

If your model is used as a component in a high-risk AI system (e.g., in medical diagnosis, credit scoring, employment, law enforcement contexts listed in Annex III), the downstream provider — not you — is the primary responsible party for the AI system's high-risk compliance. However, you must:
  (a) Clearly communicate in your model card and documentation the capabilities, limitations, and known risks;
  (b) Not actively market your model for deployment in high-risk applications without adequate safety guidance; and
  (c) Provide sufficient technical documentation for downstream conformity assessment.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
8. ENFORCEMENT, SUPERVISION, AND PENALTIES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

8.1 The AI Office as Primary Supervisor

For GPAI models, the primary supervisory authority is the European AI Office (established within the European Commission). National market surveillance authorities handle AI systems and deployers, but GPAI model-level compliance falls to the AI Office.

8.2 Powers of the AI Office

The AI Office may:
  - Request technical documentation and access to models for evaluation;
  - Require providers to conduct and submit evaluations;
  - Issue decisions requiring compliance;
  - Impose fines.

8.3 Financial Penalties

Non-compliance with GPAI model obligations exposes providers to administrative fines of up to:
  - EUR 15,000,000 or 3% of total worldwide annual turnover (whichever is higher) for violations of Article 53 or 55 obligations;
  - EUR 30,000,000 or 6% of total worldwide annual turnover for providing incorrect, incomplete, or misleading information to the AI Office.

These penalties apply regardless of where the provider is established, provided the model is available in the EU.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
9. INTERACTION WITH OTHER EU LEGAL FRAMEWORKS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

9.1 GDPR

If your training data or the model's operational use involves personal data of EU individuals, the General Data Protection Regulation (GDPR) applies. Key points:
  - Training on personal data scraped from the web requires a lawful basis;
  - Individuals have rights (access, erasure, rectification) that can be difficult to operationalise in large-scale LLMs;
  - You should conduct a Data Protection Impact Assessment (DPIA) if not already done;
  - Data minimisation and purpose limitation principles apply.

The intersection of GDPR and LLM training remains an area of active regulatory development, with the Italian, French, and Irish DPAs having all taken positions on LLM data practices.

9.2 EU Copyright Law (DSM Directive)

As noted in Section 3.3, the TDM exception under Article 4 of Directive 2019/790 and the need to honour rights-holder opt-outs is both a copyright law obligation and an AI Act obligation. Non-compliance with the copyright policy requirement under Article 53(1)(c) engages both regulatory (AI Act) and civil (copyright infringement) liability.

9.3 Digital Services Act (DSA)

If your model is accessed via a platform that meets the DSA's definition of a Very Large Online Platform (VLOP) or Very Large Search Engine (VLSE), or if you operate such a platform, the DSA's obligations regarding systemic risks (including AI-generated content and recommendation systems) may apply.

9.4 Product Liability Directive (AI Liability)

The proposed AI Liability Directive (still under negotiation as of the knowledge cutoff) would, if enacted, create a presumption of fault for AI providers in certain civil liability claims where causation is difficult to prove. GPAI model providers could be exposed to liability if their model causes harm that a downstream deployer is unable to remedy.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
10. PRACTICAL COMPLIANCE ROADMAP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The following action items should be completed before or contemporaneously with the model's public release:

BEFORE RELEASE:

1. Technical Documentation (Article 53(1)(a))
   - Prepare full Annex XI-compliant technical documentation;
   - Document model architecture, training methodology, compute (3 × 10^24 FLOPs), dataset composition, evaluation results, and known risks;
   - Establish a process for keeping this documentation current as the model is updated.

2. Copyright Policy (Article 53(1)(c))
   - Conduct a data provenance audit across all training corpora;
   - Document the legal basis for each major data source;
   - Implement and document procedures for honouring TDM opt-outs for future training runs;
   - Retain records demonstrating copyright compliance.

3. Training Data Summary (Article 53(1)(d))
   - Draft and publish a public summary of training data categories, languages, and sources;
   - Ensure this is accessible alongside the model weights.

4. Model Card and Downstream Information (Article 53(1)(b))
   - Publish a comprehensive model card including: capabilities, limitations, intended and prohibited uses, safety evaluations, and known risks;
   - Ensure the model card is sufficient for downstream providers to conduct their own compliance assessments.

5. Licence Selection
   - Confirm that the chosen open-source licence qualifies for the Article 53(2) exemption;
   - Obtain legal advice on licence terms, particularly regarding commercial use restrictions.

6. AI Office Engagement
   - Register with the AI Office's GPAI model registry (details expected from delegated acts);
   - Consider proactive notification given proximity to the systemic-risk threshold;
   - Participate in Code of Practice development.

7. Safety Evaluations
   - Conduct pre-release red-teaming and capability evaluations, particularly for:
     - CBRN (chemical, biological, radiological, nuclear) uplift;
     - Cybersecurity offensive capabilities;
     - Large-scale disinformation potential;
     - Manipulation and deceptive capabilities.
   - Document and publish evaluation methodology and results (or a summary thereof).

ONGOING (POST-RELEASE):

8. Monitor AI Office Guidance
   - Track delegated acts supplementing Annex XI and Annex XII;
   - Monitor for any designation procedures that could elevate the model to systemic-risk status;
   - Track Code of Practice adoption and update compliance accordingly.

9. Incident Monitoring
   - Establish mechanisms for receiving reports of misuse or harm from downstream users;
   - Develop an incident response and reporting protocol aligned with Article 55 requirements (anticipating possible future systemic-risk designation).

10. Documentation Updates
    - Update technical documentation whenever the model is substantially modified, fine-tuned, or extended;
    - Maintain version control of all compliance documentation.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
11. SUMMARY TABLE: OBLIGATIONS APPLICABLE TO YOUR MODEL
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Obligation                              | Legal Basis          | Applies? | Notes
─────────────────────────────────────── | ──────────────────── | ──────── | ─────────────────────────────────────────
Technical documentation (Annex XI)      | Art. 53(1)(a)        | YES      | Full obligation; not reduced by OS licence
Information to downstream providers     | Art. 53(1)(b)        | REDUCED  | Open-source exception applies; model card
Copyright compliance policy             | Art. 53(1)(c)        | YES      | Full obligation; not reduced by OS licence
Public training data summary            | Art. 53(1)(d)        | REDUCED  | Satisfied by public publication alongside
Systemic-risk evaluations (Art. 55(1))  | Art. 55(1)(a)        | NO*      | Unless designated by AI Office
Incident reporting (Art. 55(1)(b))      | Art. 55(1)(b)        | NO*      | Unless designated by AI Office
Cybersecurity measures (Art. 55(1)(c))  | Art. 55(1)(c)        | NO*      | Unless designated by AI Office
Code of Practice adherence              | Art. 56              | YES      | Expected; presumption of compliance
AI Office registration                  | Delegated acts       | YES      | Details to be confirmed by AI Office
GDPR compliance                         | GDPR                 | YES      | Separate obligation; DPIA recommended
TDM opt-out honouring                   | DSM Dir. Art. 4      | YES      | Underpins Art. 53(1)(c) obligation

*Subject to possible future designation by the AI Office.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
12. KEY RISK AREAS AND STRATEGIC CONSIDERATIONS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

12.1 Proximity to Systemic-Risk Threshold

Your 3 × 10^24 FLOPs training compute is approximately one-third of the systemic-risk threshold. This proximity creates regulatory uncertainty. Future training runs, continued pre-training, or the AI Office's interpretation of cumulative compute (including fine-tuning runs) could change your classification. Plan compliance architecture to accommodate rapid escalation to systemic-risk obligations if designation occurs.

12.2 Irrevocability of Open-Source Release

Once model weights are released under an open-source licence, they cannot be "recalled." Any future systemic-risk designation or mandatory safety mitigation (e.g., mandatory access controls or deployment restrictions) would be effectively unenforceable against third parties who have already downloaded the weights. The AI Act does not currently resolve this tension, but the AI Office may issue guidance on obligations for open-source providers post-designation. This represents a significant legal and reputational risk that should be evaluated before release.

12.3 Training Data Copyright Exposure

Large-scale LLM training on web-crawled data carries material copyright infringement risk across multiple jurisdictions. The AI Act's copyright compliance policy requirement under Article 53(1)(c) means this risk is now also a regulatory compliance issue, not merely a civil litigation risk. Thorough data provenance documentation is strongly recommended.

12.4 Capability Evaluations

Even below the systemic-risk threshold, responsible AI governance standards (and Code of Practice expectations) will likely require pre-release capability evaluations for dangerous capabilities. A 200B parameter model trained at this scale may possess emergent capabilities not present in smaller models. Investing in robust red-teaming and third-party evaluation before release reduces both regulatory and reputational risk.

12.5 Interaction with Member State Law

The AI Act is a Regulation and directly applicable in all EU Member States without implementation into national law. However, certain provisions — notably on penalties — allow Member States discretion in specific areas. Some Member States (notably France, Germany, and Spain) are also developing supplementary AI governance frameworks. Monitor national developments alongside the central AI Act regime.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CONCLUSION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Your organisation is clearly a GPAI model provider within the meaning of the EU AI Act and is subject to the baseline obligations of Article 53. The open-source licence reduces — but does not eliminate — your obligations: you retain full duties with respect to technical documentation for the AI Office and copyright compliance policy.

Your model sits below the systemic-risk threshold of 10^25 FLOPs, so the additional obligations of Article 55 do not currently apply. However, the proximity to the threshold warrants careful monitoring and proactive engagement with the AI Office to avoid being caught unprepared by a discretionary designation.

The most operationally demanding obligations are: (a) preparing Annex XI-compliant technical documentation; (b) conducting and documenting a copyright compliance review of your training data; and (c) preparing and publishing a meaningful training data summary and model card. These should be prioritised in your pre-release compliance programme.

Given the complexity of the regulatory landscape and the novelty of many of these obligations, obtaining specialist EU AI regulatory legal advice before release is strongly recommended.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
REFERENCES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

- Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), OJ L, 2024/1689, 12.7.2024.
- Directive (EU) 2019/790 of the European Parliament and of the Council on copyright and related rights in the Digital Single Market (DSM Directive), OJ L 130, 17.5.2019.
- Regulation (EU) 2016/679 (General Data Protection Regulation), OJ L 119, 4.5.2016.
- European AI Office, Guidelines on the definition of a general-purpose AI model (anticipated 2025).
- European AI Office, GPAI Code of Practice (drafting process initiated 2024; final text anticipated August 2025).
- AI Act, Annex XI (Technical documentation for GPAI models).
- AI Act, Annex XII (Information to be provided by GPAI model providers).

Note: This analysis reflects the text of the EU AI Act as enacted and general knowledge of regulatory guidance available as of August 2025. It does not constitute legal advice. Providers should consult qualified EU legal counsel for advice specific to their circumstances.

EU AI ACT COMPLIANCE ANALYSIS: AI DIAGNOSTIC IMAGING TOOL IN A HOSPITAL SETTING
CE-Marked Class IIa Medical Device (EU MDR Regulation 2017/745) / Safety Component

====================================================================================
EXECUTIVE SUMMARY
====================================================================================

Your CE marking under EU MDR (Regulation 2017/745) does NOT fully cover you under the
EU AI Act (Regulation (EU) 2024/1689). The diagnostic imaging AI tool is classified as
HIGH-RISK under the EU AI Act via Article 6(1) — the Annex I "safety component" path —
and carries significant additional obligations for both the vendor (as provider) and your
hospital (as deployer). The CE mark from the MDR conformity assessment is integrated into
the AI Act conformity procedure but does not replace it; you must ensure the vendor has
completed the additional AI Act-specific steps and that your hospital fulfils all deployer
obligations. Below is a full structured analysis.

====================================================================================
STEP 1: SCOPE AND ROLE IDENTIFICATION
====================================================================================

Your hospital is a DEPLOYER under Article 3(4) of the EU AI Act: you are using an AI
system under your own authority in the course of professional activity (operating a
radiology department). The vendor who developed and CE-marked the diagnostic imaging AI
tool is the PROVIDER under Article 3(3).

This distinction is critical: the AI Act assigns different — though overlapping —
obligations to providers and deployers. Your primary obligations arise under Article 26,
but you also bear responsibilities related to monitoring, incident reporting, and ensuring
the provider has met its obligations before you deploy.

====================================================================================
STEP 2: AI SYSTEM DEFINITION CHECK (ART. 3(1))
====================================================================================

An AI diagnostic imaging tool that analyses medical images (X-rays, CT scans, MRI) to
generate diagnostic predictions, findings, or recommendations clearly meets the Article
3(1) definition of an AI system: it is a machine-based system that, for given objectives
(detecting pathologies, anomalies, or conditions), infers from inputs (medical images and
patient data) how to generate outputs (diagnostic predictions or recommendations) that
affect real environments (clinical decisions and patient care). The threshold is met.

====================================================================================
STEP 3: PROHIBITED PRACTICES SCREEN (ART. 5 — IN FORCE FROM 2 FEBRUARY 2025)
====================================================================================

None of the eight prohibited practices under Article 5 apply to a standard diagnostic
imaging AI tool used for radiology support:

- No subliminal manipulation (Art. 5(1)(a))
- No exploitation of vulnerabilities (Art. 5(1)(b))
- No social scoring (Art. 5(1)(c))
- No predictive criminal profiling (Art. 5(1)(d))
- No untargeted biometric database scraping (Art. 5(1)(e))
- No prohibited workplace emotion inference (Art. 5(1)(f))
- No sensitive-attribute biometric categorisation (Art. 5(1)(g))
- No real-time remote biometric identification in public spaces for law enforcement (Art. 5(1)(h))

The system is not prohibited and may proceed to risk classification.

====================================================================================
STEP 4: RISK TIER DETERMINATION — HIGH-RISK VIA ART. 6(1), ANNEX I PATH
====================================================================================

This system is HIGH-RISK under BOTH available paths under Article 6.

PATH A — ART. 6(1): SAFETY COMPONENT OF AN ANNEX I PRODUCT (PRIMARY PATH)
---------------------------------------------------------------------------
Article 6(1) classifies an AI system as high-risk when two cumulative conditions are
satisfied:

Condition 1: The AI system is a safety component of a product (or is itself such a
product) covered by Annex I harmonisation legislation.

SATISFIED: Annex I, Section A, Item 11 of the EU AI Act explicitly lists "Medical
devices — Regulation 2017/745 (EU MDR)" as Annex I harmonisation legislation. Your
diagnostic imaging AI tool has been CE-marked under EU MDR as a Class IIa medical
device. Your vendor additionally describes it as a "safety component for your radiology
department." Either characterisation satisfies this limb: a CE-marked medical device
under the MDR is per se an Annex I product, and the vendor's own characterisation as a
safety component confirms the safety role.

Condition 2: The product must require third-party conformity assessment under the
relevant Annex I legislation.

SATISFIED: Under EU MDR Regulation 2017/745, Class IIa medical devices require
involvement of a notified body in the conformity assessment procedure. This is a
mandatory third-party assessment requirement — the self-certification route is not
available for Class IIa devices. The second condition is therefore met.

Conclusion on Path A: Both conditions under Article 6(1) are met. The AI diagnostic
imaging tool is definitively a HIGH-RISK AI system under the EU AI Act.

PATH B — ART. 6(2), ANNEX III: INDEPENDENT ALTERNATIVE BASIS
-------------------------------------------------------------
Even without the Annex I path, Annex III, Area 5(a) provides an independent basis for
high-risk classification: "AI systems intended to be used by or on behalf of competent
authorities or public authorities for the purpose of evaluating the eligibility of natural
persons for public assistance benefits and services, including healthcare." Where the
hospital is an NHS-equivalent or publicly funded hospital, this path may also apply.
However, the Annex I path under Article 6(1) is the primary and more certain
classification route here.

====================================================================================
STEP 5: DOES THE CE MARK UNDER EU MDR COVER YOU UNDER THE EU AI ACT?
====================================================================================

THE SHORT ANSWER: NO — THE MDR CE MARK DOES NOT SUBSTITUTE FOR AI ACT COMPLIANCE,
BUT IT IS INTEGRATED INTO (NOT SEPARATE FROM) THE AI ACT CONFORMITY PROCEDURE.

Here is the precise legal position:

1. INTEGRATION, NOT REPLACEMENT (ART. 43(3) AND RECITAL 88)
   For AI systems that are safety components of Annex I products, Article 43(3) of the
   AI Act provides that the conformity assessment of the AI system shall be carried out
   as part of the conformity assessment procedure applicable under the relevant Annex I
   legislation — in this case, the EU MDR procedure. The notified body that assessed
   the medical device under EU MDR therefore also forms part of the AI Act conformity
   pathway. There is no entirely separate AI Act notified body assessment for these
   systems.

   However — and this is the critical point — this integration means the MDR conformity
   assessment procedure must be conducted in a manner that ALSO covers compliance with
   the AI Act's Section 2 requirements (Arts. 9–15). The existing MDR CE certification
   alone, conducted before the AI Act applied, does not accomplish this. The notified
   body would need to have assessed compliance with the AI Act's specific requirements
   (risk management system under Art. 9, data governance under Art. 10, technical
   documentation under Art. 11, logging under Art. 12, transparency/instructions for use
   under Art. 13, human oversight under Art. 14, accuracy/robustness/cybersecurity under
   Art. 15) as part of or alongside the MDR assessment.

2. TIMING: AI ACT OBLIGATIONS FOR ANNEX I SAFETY COMPONENTS APPLY FROM 2 AUGUST 2027
   The AI Act's high-risk obligations for Annex I product safety components (including
   medical devices under EU MDR) do not apply until 2 August 2027 — one year later than
   the 2 August 2026 date for Annex III systems. This gives the vendor and your hospital
   additional time, but planning must begin now.

3. SEPARATE EU AI ACT DECLARATION OF CONFORMITY REQUIRED
   Article 47 requires a separate EU Declaration of Conformity for AI Act compliance.
   This is distinct from the EU Declaration of Conformity under the MDR. The AI Act DoC
   must specifically confirm compliance with all applicable AI Act requirements and must
   be maintained for 10 years from market placement. Your vendor must draw this up.

4. CE MARKING CARRIES DUAL MEANING BUT DUAL REQUIREMENTS
   After completing AI Act-compliant conformity assessment, the CE marking affixed under
   Article 48 of the AI Act signals conformity with both the MDR and the AI Act. The
   same physical CE mark is used, but the legal basis is dual: the vendor must have
   satisfied both regulatory frameworks. A CE mark obtained solely under the MDR before
   AI Act applicability is insufficient to signal AI Act conformity.

5. EU AI DATABASE REGISTRATION (ART. 49)
   The vendor, as provider, must register the AI system in the EU AI database before
   market placement (for Annex I systems, this registration obligation also applies).
   MDR registration (EUDAMED) is a separate database and does not substitute for EU AI
   database registration.

====================================================================================
STEP 6: PROVIDER OBLIGATIONS — WHAT YOUR VENDOR MUST DO
====================================================================================

As the hospital, you should verify that your vendor has met or has a compliant plan to
meet the following obligations before 2 August 2027 (the applicability date for Annex I
safety component systems):

ART. 9 — RISK MANAGEMENT SYSTEM
The vendor must establish and maintain a continuous, lifecycle-spanning risk management
system covering all known and reasonably foreseeable risks to patients, clinical staff,
and third parties. This must include five documented steps: risk identification, risk
estimation/evaluation, post-market monitoring integration, risk mitigation (design-first
hierarchy), and residual risk acceptability assessment. Testing against pre-defined
metrics before market placement is required.

ART. 10 — DATA AND DATA GOVERNANCE
Training, validation, and testing datasets must be representative of the patient
populations and imaging conditions the system will encounter in your radiology department.
Bias examination and gap identification are mandatory. If special-category health data
was used to detect/correct bias in training, the vendor must satisfy all six conditions
of the Article 10(5) exception.

ART. 11 — TECHNICAL DOCUMENTATION (ANNEX IV)
Comprehensive technical documentation per Annex IV must be created before market
placement and kept up to date throughout the system's lifecycle. This must include
the full description of the system, training methodologies, data used, validation
results, risk management documentation, and all changes made over the lifecycle.
Retention period: 10 years from market placement.

ART. 12 — AUTOMATIC LOGGING CAPABILITY
The system must be technically capable of automatically generating event logs throughout
operation. For a diagnostic imaging tool, this means logging should capture the
circumstances surrounding outputs (image inputs, model version, output confidence scores,
timestamps) to enable post-incident reconstruction and audit.

ART. 13 — TRANSPARENCY AND INSTRUCTIONS FOR USE
The vendor must provide your radiology department with clear instructions for use
covering: the system's intended purpose, performance metrics (accuracy, robustness),
known limitations, human oversight measures, input data specifications, and logging
mechanisms. These instructions are the basis on which your hospital's deployer
obligations rest.

ART. 14 — HUMAN OVERSIGHT DESIGN
The system must be designed to allow radiologists and clinical staff to:
- Understand the system's capabilities and limitations
- Recognise automation bias (over-reliance on AI output without independent clinical
  judgment)
- Correctly interpret AI outputs — including interpretability or explainability features
  showing which image features drove a finding
- Override or disregard AI outputs
- Intervene via a stop/interrupt mechanism

ART. 15 — ACCURACY, ROBUSTNESS, AND CYBERSECURITY
The vendor must declare and maintain appropriate accuracy levels throughout the system's
operational lifetime. Robustness against errors, image quality variations, and
foreseeable misuse is required. Cybersecurity protections must address data poisoning,
model poisoning, adversarial image attacks, and confidentiality attacks.

ART. 16 — FULL PROVIDER CHECKLIST
The vendor must complete all 12 provider obligations, including: compliance with Arts.
9–15; quality management system (Art. 17); technical documentation maintenance; EU
Declaration of Conformity (Art. 47); CE marking (Art. 48); and EU AI database
registration (Art. 49).

ART. 17 — QUALITY MANAGEMENT SYSTEM
The vendor must have a documented QMS covering 13 components, including regulatory
compliance strategy, design control, testing and validation, data management, risk
management, post-market monitoring, and serious incident reporting procedures. Existing
MDR QMS requirements (ISO 13485) can be adapted and integrated to avoid duplication,
but must be supplemented to cover AI Act-specific elements.

ART. 72 — POST-MARKET MONITORING SYSTEM
The vendor must establish a post-market monitoring system proportionate to the risks,
collecting and analysing performance data from deployed systems throughout operational
lifetime. Existing MDR post-market surveillance requirements can be integrated into
this system (Recital 88 and Art. 72 permit integration with sectoral post-market
monitoring obligations).

====================================================================================
STEP 7: DEPLOYER OBLIGATIONS — WHAT YOUR HOSPITAL MUST DO (ART. 26)
====================================================================================

As the deployer, your hospital bears the following independent obligations under Article
26, applicable from 2 August 2027 for Annex I systems (note: some general obligations
take effect on the broader 2 August 2026 date if the system is also classifiable under
Annex III):

1. INSTRUCTIONS COMPLIANCE (ART. 26(1))
   Use the AI diagnostic imaging tool only in accordance with the vendor's instructions
   for use (Art. 13). Do not use the system for purposes, patient populations, or imaging
   modalities outside those specified by the vendor.

2. STAFF COMPETENCE AND OVERSIGHT ASSIGNMENT (ART. 26(2) AND ART. 14(4))
   Assign human oversight of AI outputs to radiologists or clinical staff with the
   necessary competence, authority, and resources. Train oversight personnel on the
   system's capabilities and limitations, and specifically on automation bias risk —
   the tendency to over-rely on AI outputs without independent clinical assessment.

3. INPUT DATA CONTROL (ART. 26(3))
   Where your hospital controls the input data (e.g., image acquisition protocols,
   patient preparation, PACS integration), ensure input data is relevant and
   sufficiently representative. If your patient population differs materially from the
   training dataset described in the vendor's technical documentation, flag this to the
   vendor and assess whether additional validation is needed.

4. CONTINUOUS MONITORING (ART. 26(4))
   Monitor the operation of the AI system in your radiology department. If you identify
   risks to health, safety, or fundamental rights arising from actual use, you must
   notify the vendor/importer/distributor AND the relevant market surveillance authority.
   Where appropriate, suspend use pending investigation.

5. SERIOUS INCIDENT REPORTING (ART. 26(5) AND ART. 73)
   Immediately notify the vendor if the AI tool is involved in a serious incident —
   meaning an event that directly or indirectly leads or could lead to death, serious
   damage to health, or serious and irreversible harm. Additionally notify the market
   surveillance authority of the Member State where the incident occurred. For a hospital,
   this interacts with your existing MDR vigilance reporting obligations; Art. 72 and
   Recital 88 contemplate integration of these reporting channels.

6. LOG RETENTION (ART. 26(6))
   Retain automatically generated logs of the AI system's operation for a minimum of
   6 months. Where applicable Union or national law (including MDR post-market
   surveillance requirements) imposes longer retention periods, the longer period applies.

7. GDPR DPIA (ART. 26(9))
   Conduct a Data Protection Impact Assessment under GDPR Article 35 before deploying
   the system if the processing of health data (which is special-category data under
   GDPR Article 9) presents a high risk to patient rights. For a diagnostic imaging AI
   processing identifiable patient health data, a DPIA is almost certainly required and
   should be completed before deployment.

8. FUNDAMENTAL RIGHTS IMPACT ASSESSMENT (ART. 27)
   If your hospital is a public authority or body, Art. 27 may require a Fundamental
   Rights Impact Assessment before deploying high-risk AI systems. This assessment covers:
   the processes in which the system will be used, the time period and frequency,
   categories of persons affected, specific risks to those persons, and planned human
   oversight measures. Even where Art. 27 does not apply as a legal mandate (e.g., for
   private hospitals), conducting a FRIA-equivalent assessment is strongly recommended
   given the vulnerability of the patient population.

====================================================================================
STEP 8: PRACTICAL COMPLIANCE ACTION PLAN
====================================================================================

| Requirement                        | Article      | Who        | Deadline        | Action Required                                                                                    |
|------------------------------------|--------------|------------|-----------------|-----------------------------------------------------------------------------------------------------|
| Prohibited practices screen         | Art. 5       | Both       | Already applies | Confirm tool does not fall within any of the 8 prohibited categories (confirmed above: it does not)|
| Verify vendor AI Act readiness      | Arts. 9–17   | Hospital   | Before deploy   | Request confirmation from vendor that AI Act-compliant conformity assessment is planned/completed  |
| AI Act EU Declaration of Conformity | Art. 47      | Vendor     | 2 Aug 2027      | Vendor must draw up AI Act DoC separate from MDR DoC                                              |
| EU AI database registration         | Art. 49      | Vendor     | 2 Aug 2027      | Vendor must register system before market placement/service in AI Act database (not EUDAMED alone)|
| CE marking (dual basis)             | Art. 48      | Vendor     | 2 Aug 2027      | Vendor must affix CE marking reflecting AI Act conformity (integrated with MDR procedure)          |
| Staff training on AI oversight      | Arts. 14, 26 | Hospital   | Before deploy   | Train radiologists on system limits, automation bias, override capabilities                        |
| Instructions for use review         | Art. 13      | Hospital   | Before deploy   | Review vendor instructions; confirm use is within intended purpose and patient population           |
| Log retention procedures            | Art. 26(6)   | Hospital   | Before deploy   | Establish procedure to retain AI system logs for minimum 6 months                                  |
| Continuous monitoring protocol      | Art. 26(4)   | Hospital   | Ongoing         | Establish clinical governance process to monitor AI performance and flag anomalies                  |
| Incident reporting procedure        | Art. 73      | Hospital   | Before deploy   | Define clear escalation pathway: AI incident → vendor → market surveillance authority              |
| GDPR DPIA                          | Art. 26(9)   | Hospital   | Before deploy   | Complete DPIA for processing of patient health data through diagnostic AI system                   |
| FRIA (if public body)              | Art. 27      | Hospital   | Before deploy   | If public hospital, complete Fundamental Rights Impact Assessment                                   |
| Post-market monitoring integration  | Art. 72      | Both       | 2 Aug 2027      | Integrate AI Act post-market monitoring with existing MDR post-market surveillance programme        |
| QMS review                         | Art. 17      | Vendor     | 2 Aug 2027      | Vendor must supplement existing ISO 13485 QMS with AI Act-specific components                      |

====================================================================================
STEP 9: SPECIFIC ANSWER ON CE MARKING — WHAT IT COVERS AND WHAT IT DOES NOT
====================================================================================

Your existing CE mark under EU MDR (Regulation 2017/745) demonstrates that:
- The diagnostic imaging AI tool has undergone notified body review as a Class IIa
  medical device
- The device meets EU MDR safety and performance requirements for medical devices
- The device's clinical performance and safety have been assessed under MDR Annex IX
  or XI procedures

Your existing CE mark does NOT demonstrate that:
- The AI system complies with AI Act Article 9 (risk management system for AI risks)
- The AI system complies with AI Act Article 10 (AI-specific data governance)
- The AI system was assessed against AI Act Article 11/Annex IV (AI technical
  documentation requirements — which go beyond MDR technical file requirements)
- The AI system has automatic logging capability compliant with Art. 12
- The instructions for use meet Art. 13 requirements (which include AI-specific
  transparency requirements such as automation bias warnings and oversight instructions)
- The system is designed with Art. 14 human oversight mechanisms
- The system has been assessed for AI-specific cybersecurity risks under Art. 15
- The vendor has drawn up an AI Act EU Declaration of Conformity (Art. 47)
- The system is registered in the EU AI Act database (Art. 49)

The pathway forward under Art. 43(3) is that the MDR notified body assessment is
INTEGRATED into the AI Act conformity procedure — not replaced by it. Your vendor must
work with their notified body to extend the conformity assessment scope to cover the
AI Act's specific requirements, produce the AI Act Declaration of Conformity, and
register in the EU AI database. This is additional work on top of the MDR CE marking,
not a duplication of it.

====================================================================================
STEP 10: PENALTIES FOR NON-COMPLIANCE
====================================================================================

Failure to comply with AI Act obligations for providers and deployers can result in
fines under Article 99:

- Violations of provider/deployer obligations (Arts. 16, 26, etc.): up to €15,000,000
  or 3% of total worldwide annual turnover, whichever is higher.
- Incorrect or misleading information provided to authorities: up to €7,500,000 or 1%
  of total worldwide annual turnover.

Market surveillance authorities in each Member State have enforcement powers including
requiring corrective action, withdrawal from service, and recalls (Art. 74). The MDR's
existing market surveillance infrastructure will interface with AI Act enforcement for
medical device AI systems.

====================================================================================
CONCLUSION
====================================================================================

Your hospital's AI diagnostic imaging tool is unambiguously HIGH-RISK under the EU AI
Act via Article 6(1) — it is a safety component of a product (Class IIa medical device
under EU MDR, an Annex I law) that requires third-party conformity assessment. High-risk
obligations for Annex I safety components apply from 2 AUGUST 2027.

The CE mark under EU MDR is NOT sufficient to cover EU AI Act compliance. It is
integrated into the AI Act conformity pathway (Art. 43(3)) but does not replace the
additional AI Act-specific requirements: AI risk management (Art. 9), data governance
(Art. 10), AI technical documentation (Art. 11/Annex IV), automatic logging (Art. 12),
AI-specific transparency/instructions for use (Art. 13), human oversight design (Art. 14),
AI accuracy and cybersecurity assessment (Art. 15), AI Act EU Declaration of Conformity
(Art. 47), and EU AI database registration (Art. 49).

As the deployer, your hospital must: use the system per vendor instructions, assign
competent human oversight and train for automation bias, retain logs for at least 6
months, monitor operations and report serious incidents, conduct a GDPR DPIA, and
(if a public body) a Fundamental Rights Impact Assessment.

Engage your vendor now to confirm their AI Act compliance roadmap, obtain contractual
commitments regarding their provider obligations, and begin building your internal
governance framework for AI oversight in your radiology department. The 2 August 2027
deadline allows time for preparation, but the governance infrastructure — training,
monitoring protocols, incident reporting pathways, and DPIA — should be in place at or
before initial deployment.

EU AI ACT COMPLIANCE ANALYSIS: AI DIAGNOSTIC IMAGING TOOL IN A HOSPITAL SETTING
CE-Marked Class IIa Medical Device (EU MDR 2017/745)

================================================================================
EXECUTIVE SUMMARY
================================================================================

Yes, you likely need to take additional steps beyond your existing CE marking under the EU MDR. The EU AI Act (Regulation 2024/1689, in force from August 2024, with most provisions applying from August 2026) establishes a parallel, complementary regulatory layer that interacts with — but does not fully replace — your existing medical device obligations. Whether the CE marking already covers you depends critically on which conformity assessment route was used and whether it was specifically updated to address the AI Act's requirements.

================================================================================
1. CLASSIFICATION OF YOUR AI SYSTEM UNDER THE EU AI ACT
================================================================================

1.1 High-Risk AI System Classification

Your AI diagnostic imaging tool almost certainly qualifies as a HIGH-RISK AI SYSTEM under the EU AI Act. Annex III of the Regulation lists categories of AI systems presumed to be high-risk. Point 5(a) of Annex III explicitly includes:

  "AI systems intended to be used as safety components of products, or as products themselves, covered by the Union harmonisation legislation listed in Annex I..."

EU MDR (Regulation 2017/745) is listed in Annex I of the EU AI Act. Since your tool:
  (a) Is covered by EU MDR as a Class IIa medical device, AND
  (b) The vendor designates it as a "safety component" of your radiology department's operations,

...it falls squarely within the high-risk category under Annex III, Point 5.

1.2 What "Safety Component" Means

The EU AI Act defines a safety component as a component of a product or system that fulfils a safety function for that product or system, or the failure or malfunctioning of which endangers the health and safety of persons. In diagnostic imaging AI, failures (false negatives missing cancer, false positives triggering unnecessary procedures) directly affect patient safety. The vendor's characterization appears legally sound and works against any argument that this system is lower-risk.

1.3 No Exemption for Already CE-Marked Devices

There is no blanket exemption in the EU AI Act for AI systems that are already CE-marked under EU MDR. The two frameworks operate in parallel.

================================================================================
2. THE RELATIONSHIP BETWEEN EU MDR CE MARKING AND THE EU AI ACT
================================================================================

2.1 The "Fast-Track" Pathway Under Article 8 and Annex I

The EU AI Act creates a mechanism for AI systems that are already subject to EU harmonisation legislation listed in Annex I (which includes EU MDR). Under Article 8(1), high-risk AI systems that are already covered by those sector-specific laws may meet some EU AI Act requirements through compliance with those sector-specific laws — BUT ONLY IF:

  - The existing sector legislation covers the same objectives and requirements as the corresponding EU AI Act obligations; AND
  - The conformity assessment was conducted by a Notified Body and already addresses AI-specific risks.

This is NOT a full exemption. It is a potential streamlining mechanism, often called the "single conformity assessment" pathway.

2.2 What EU MDR Does and Does Not Cover

EU MDR (2017/745) already requires, for Class IIa devices:
  - Risk management systems (ISO 14971)
  - Clinical evaluation and post-market surveillance
  - Quality management systems (typically ISO 13485)
  - Technical documentation
  - Notified Body involvement in conformity assessment

However, EU MDR does not fully address all EU AI Act requirements. Specific AI Act obligations NOT typically covered by EU MDR alone include:
  - Transparency and explainability requirements for AI-specific decision logic
  - Human oversight mechanisms specific to AI systems (as opposed to general device supervision)
  - Data governance requirements specific to training, validation, and test datasets
  - Accuracy, robustness, and cybersecurity requirements framed in AI-specific terms
  - AI system logging and auditability of AI decisions (immutable logs of AI outputs)
  - Conformity with technical specifications for AI accuracy and bias mitigation
  - Post-market monitoring specifically targeting AI model drift and retraining events

2.3 The "Presumption of Conformity" Does Not Apply Automatically

Your existing CE mark does not automatically create a presumption of conformity with the EU AI Act's requirements. The AI Act's presumption of conformity mechanisms relate to adherence to harmonized standards developed under the AI Act (e.g., by CEN/CENELEC) or to common specifications adopted by the European Commission — most of which were still under development as of mid-2025.

================================================================================
3. OBLIGATIONS UNDER THE EU AI ACT THAT APPLY TO YOU AS A DEPLOYER
================================================================================

The EU AI Act distinguishes between "providers" (those who develop and place the AI system on the market) and "deployers" (those who use the AI system in a professional context). As a hospital, you are a DEPLOYER. However, deployers of high-risk AI systems have significant, non-trivial obligations.

3.1 Deployer Obligations Under Article 26

As a deployer you must:

  a) USE THE SYSTEM AS INTENDED: Only use the AI system in accordance with the provider's instructions of use. Any use outside the intended purpose may transfer provider obligations to you.

  b) IMPLEMENT HUMAN OVERSIGHT: Designate individuals with the necessary competence, authority, and resources to exercise meaningful human oversight over the AI system. In a radiology context, this means ensuring qualified radiologists can understand, question, and if necessary override AI outputs. Human oversight must be real and not merely nominal.

  c) MONITOR FOR ANOMALIES: Conduct ongoing monitoring to detect unexpected performance or outputs inconsistent with the system's intended purpose. You must have processes in place to detect when the system may be operating outside its validated parameters (e.g., patient population drift, equipment changes affecting image quality).

  d) SUSPEND USE WHEN RISKS ARISE: If you identify a risk to health, safety, or fundamental rights not addressed by the provider, you must inform the provider and, if necessary, suspend use. You must have a defined protocol for this.

  e) MAINTAIN LOGS: To the extent technically possible, ensure the keeping of automatically generated logs. You must retain logs for at least six months (or as otherwise required by EU or national law, which may be longer in healthcare contexts).

  f) INFORM AFFECTED PERSONS: Natural persons (patients) subject to decisions from the AI system have the right to be informed that they are subject to an AI system. You must have a mechanism for disclosing AI involvement to patients and, upon request, providing a meaningful explanation of the AI's role in their care pathway.

  g) CONDUCT A FUNDAMENTAL RIGHTS IMPACT ASSESSMENT (FRIA): Under Article 27, deployers that are bodies governed by public law OR operators of critical infrastructure (hospitals may qualify as both) must conduct a Fundamental Rights Impact Assessment before deploying the high-risk AI system. This assessment must:
     - Describe the processes in which the AI system will be used
     - Identify the categories of natural persons affected
     - Assess specific risks to fundamental rights (non-discrimination, dignity, privacy)
     - Identify measures to address those risks
     - Be documented and registered

  h) REGISTER IN THE EU DATABASE: Under Article 49 and the EU AI Act's database provisions, deployers that are public bodies must register their use of high-risk AI systems in the EU-wide database (managed by the European AI Office). Private hospitals may have analogous obligations depending on how "public body" is interpreted in your jurisdiction.

3.2 Operator Obligations That May Shift to You

If you materially modify the AI system (change its purpose, retrain it, significantly alter its use environment beyond what the provider envisioned), you may assume provider obligations — including full conformity assessment obligations. Carefully document the scope of your deployment to avoid inadvertently becoming a "provider" under the AI Act.

================================================================================
4. OBLIGATIONS THAT REMAIN WITH THE VENDOR (PROVIDER)
================================================================================

While your vendor bears primary responsibility for the AI system's conformity as a high-risk AI system, you should verify that they have fulfilled their obligations, because deploying a non-compliant system exposes you to enforcement risk.

Confirm with your vendor that they have:

  a) Registered the AI system in the EU database for high-risk AI systems (Article 49)
  b) Drawn up EU Declaration of Conformity specifically under the AI Act (not just under MDR)
  c) Affixed the CE marking in compliance with AI Act requirements (noting that for Annex I products, the AI Act CE marking is folded into the existing CE mark but must specifically cover AI Act compliance)
  d) Established a post-market monitoring system for the AI model specifically, tracking model performance, drift, and incidents under AI Act Article 72
  e) Provided you with instructions of use that specifically address AI Act requirements: intended purpose, performance levels, known limitations, foreseeable misuse scenarios, human oversight measures, cybersecurity requirements
  f) Established an EU-based representative if they are a non-EU provider
  g) Implemented a quality management system covering the AI system's lifecycle

================================================================================
5. TECHNICAL REQUIREMENTS YOU SHOULD VERIFY
================================================================================

5.1 Accuracy, Robustness, and Cybersecurity (Article 15)

The AI system must be designed and developed to achieve an appropriate level of accuracy, robustness, and cybersecurity throughout its lifecycle. You should verify with your vendor:
  - The validated performance metrics (sensitivity, specificity, AUC) on representative European patient populations
  - How the system performs on subpopulations (age, sex, ethnicity, equipment type) — bias and fairness testing
  - Adversarial robustness provisions
  - Cybersecurity measures protecting the AI model from manipulation

5.2 Data Governance

The training, validation, and test datasets must have met requirements for relevance, representativeness, and freedom from errors. Request evidence from your vendor that:
  - Training data included representative patient populations for your clinical use cases
  - Data governance practices met EU AI Act Article 10 standards
  - Any known data limitations are disclosed in the instructions of use

5.3 Logging and Auditability

Ensure your IT infrastructure can capture and retain the logs that the AI system automatically generates. These logs must be capable of tracing AI outputs back to specific inputs (patient images) and must be kept for the legally required period. In healthcare, this likely means integration with your RIS/PACS and conformance with your clinical records retention policies.

================================================================================
6. TRANSITIONAL PROVISIONS AND TIMELINE
================================================================================

The EU AI Act entered into force on 1 August 2024. For high-risk AI systems covered by Annex III (which includes your system), the compliance deadline is 2 August 2026. However:

  - Prohibited AI practices: Applied from 2 February 2025
  - GPAI model obligations: Applied from 2 August 2025
  - High-risk Annex III systems (your category): 2 August 2026
  - High-risk Annex I systems (products under harmonisation law): 2 August 2027

IMPORTANT DISTINCTION: Your system likely falls under BOTH Annex I (as an EU MDR product) and Annex III (as an AI safety component). Where a system is covered by both, the more specific classification should be applied, but regulatory guidance from the European AI Office should be consulted. The 2027 deadline for Annex I products may apply, but you should not assume the later deadline applies without verifying your system's precise classification.

For systems already on the market before the AI Act compliance dates, transitional provisions in Article 111 may provide additional time, subject to conditions (no significant changes to the system after the relevant dates).

================================================================================
7. INTERACTION WITH OTHER EU LAW
================================================================================

7.1 GDPR

AI diagnostic imaging involves special category health data under GDPR. Your AI Act compliance must be coordinated with your GDPR obligations, particularly:
  - Legal basis for processing health data in AI systems
  - Data Protection Impact Assessment (DPIA) under GDPR Article 35 (likely mandatory for high-risk AI processing health data at scale)
  - Rights of data subjects including the right not to be subject to solely automated decisions (Article 22 GDPR) — important where AI influences clinical decisions
  - Data retention and deletion obligations

7.2 EU MDR Post-Market Surveillance

Your EU MDR post-market surveillance plan should be updated to specifically monitor AI-specific failure modes: model drift, dataset shift, performance degradation on new equipment, and unexpected error patterns. This aligns with but goes beyond the AI Act's post-market monitoring requirements.

7.3 NIS2 Directive

Hospitals are designated as "essential entities" under NIS2. Your AI system introduces cybersecurity considerations that must be addressed in your NIS2 compliance framework, particularly regarding supply chain security (your vendor as a critical supplier) and incident reporting for AI system failures.

================================================================================
8. PRACTICAL STEPS YOU SHOULD TAKE NOW
================================================================================

IMMEDIATE ACTIONS (Within 3-6 Months):

1. Obtain documentation from your vendor confirming their AI Act compliance roadmap and whether they have or will obtain EU Declaration of Conformity under the AI Act in addition to EU MDR CE marking.

2. Review the vendor's instructions of use specifically for AI Act-required content (human oversight measures, performance limits, known risks).

3. Designate a responsible person internally (could be your medical AI governance lead, Chief Medical Information Officer, or equivalent) with oversight responsibility for AI Act compliance.

4. Conduct or commission a Fundamental Rights Impact Assessment (FRIA) under Article 27 if you are a public hospital or operate as critical infrastructure.

5. Map your existing EU MDR technical file and quality management system to the EU AI Act's high-risk AI system requirements to identify gaps.

SHORT-TERM ACTIONS (6-12 Months):

6. Establish or update your human oversight protocols for AI-assisted radiology: define the radiologist's supervisory role, decision authority, and documentation requirements when AI outputs are used.

7. Implement log retention policies for AI system outputs, integrated with your clinical records management.

8. Develop a patient information and transparency mechanism (consent documentation, patient-facing notices) disclosing AI involvement in diagnostics.

9. Update your IT vendor management framework to treat your AI vendor as a high-risk supplier under both AI Act and NIS2.

10. Register your use of the AI system in the EU database (if applicable for deployers in your jurisdiction).

MEDIUM-TERM ACTIONS (12-24 Months):

11. Implement ongoing performance monitoring: establish thresholds for acceptable AI performance, protocols for suspending use if performance degrades, and a clear escalation path to notify the vendor.

12. Coordinate your AI Act compliance with your GDPR DPIA, NIS2 security obligations, and EU MDR post-market surveillance plan into a unified AI governance framework.

13. Train radiology staff on AI Act obligations: their role in human oversight, incident reporting, and documentation requirements.

14. Establish contractual protections with your vendor: require notification of model updates, retraining events, performance changes, and regulatory status changes; require cooperation in your incident reporting obligations.

================================================================================
9. DOES THE CE MARKING ALREADY COVER YOU?
================================================================================

DIRECT ANSWER: No, not fully.

Your existing CE marking under EU MDR:
  - DOES demonstrate conformity with medical device safety and performance requirements
  - DOES involve Notified Body assessment for a Class IIa device
  - DOES address risk management, clinical evaluation, and quality management
  - MAY overlap with some EU AI Act technical requirements where the MDR requirements are equivalent

Your existing CE marking DOES NOT:
  - Constitute a Declaration of Conformity under the EU AI Act
  - Address AI-specific transparency, explainability, and logging requirements
  - Cover your deployer obligations under the AI Act (FRIA, human oversight protocols, patient information)
  - Automatically register the system in the EU AI Act database
  - Satisfy the AI Act's specific accuracy, robustness, and bias testing requirements as framed in the AI Act

WHAT THE VENDOR SHOULD PROVIDE: The vendor should be updating their conformity assessment and technical documentation to cover EU AI Act requirements, and should issue a supplementary or updated Declaration of Conformity that specifically addresses AI Act compliance in addition to EU MDR conformity. If your vendor claims the existing CE mark is sufficient without any additional steps, that claim should be examined very carefully and legal/regulatory advice sought.

================================================================================
10. KEY RISKS OF NON-COMPLIANCE
================================================================================

- Market surveillance authorities (national competent authorities for AI in each Member State) can require corrective actions, withdrawal, or prohibition of use
- Administrative fines under the AI Act for providers: up to EUR 15 million or 3% of global annual turnover for violations of high-risk AI system obligations; up to EUR 30 million or 6% for prohibited AI practice violations
- Fines for deployers are determined by Member States and may be significant
- Patient safety incidents involving non-compliant AI systems create liability exposure under both the AI Act and EU MDR
- Reputational risk in a regulated healthcare environment
- Potential conflict with your hospital's accreditation requirements if AI governance is found inadequate

================================================================================
CONCLUSION
================================================================================

Your AI diagnostic imaging tool is almost certainly a high-risk AI system under the EU AI Act, and the existing CE marking under EU MDR does not alone satisfy the EU AI Act's requirements. You face a dual regulatory framework: continue meeting EU MDR obligations while also building out the additional governance, oversight, documentation, and transparency infrastructure required by the AI Act. The compliance deadline for your category of system is 2 August 2026 (or possibly 2027 for Annex I products — seek guidance on this point).

You should engage your vendor immediately to confirm their AI Act compliance roadmap, begin your internal gap assessment, and conduct a Fundamental Rights Impact Assessment. Given the clinical stakes and regulatory complexity, engaging a regulatory affairs specialist with specific EU AI Act and EU MDR expertise is strongly recommended.

================================================================================
DISCLAIMER
================================================================================

This analysis is based on general knowledge of the EU AI Act (Regulation 2024/1689) and EU MDR (Regulation 2017/745) as of early 2026. It does not constitute legal advice. Regulatory guidance, harmonized standards, and implementing acts under the EU AI Act continue to evolve. You should consult qualified legal counsel and regulatory affairs professionals for advice specific to your situation and jurisdiction.

EU AI Act Compliance Analysis: E-Commerce Customer-Facing Chatbot
Regulation (EU) 2024/1689

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STEP 1 — SCOPE AND ROLE IDENTIFICATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

You are a DEPLOYER under Art. 3(4): you are using an AI system under your own authority in a professional context (operating an e-commerce business and placing the chatbot in front of customers). You are not developing or placing an AI system on the market under your own name — the underlying GPAI model is developed and placed on the market by your third-party API provider, who holds the role of PROVIDER under Art. 3(3).

This deployer/provider split is critical: the EU AI Act assigns distinct and largely non-overlapping obligation sets to each role. You bear deployer obligations; your third-party GPAI model vendor bears provider and GPAI obligations.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STEP 2 — AI SYSTEM AND GPAI CLASSIFICATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Your chatbot is an AI system within the meaning of Art. 3(1): it is a machine-based system that infers from inputs (user queries, browsing history) how to generate outputs (product answers, return processing decisions, product recommendations) that affect real environments (customer purchasing behaviour and satisfaction).

The underlying third-party model accessed via API is almost certainly a GPAI model under Art. 3(63) — it is trained on large amounts of data using self-supervision at scale, displays significant generality, and performs a wide range of distinct tasks. The chatbot you build on top of it is a GPAI system under Art. 3(64).

This GPAI classification has compliance implications for your vendor (not for you), which are addressed in Step 7 below.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STEP 3 — PROHIBITED PRACTICES SCREEN (Art. 5 — in force from 2 February 2025)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Running through all eight prohibited categories:

Art. 5(1)(a) — Subliminal/manipulative techniques: A standard e-commerce chatbot answering product questions and processing returns does not deploy subliminal techniques. However, the product recommendation function warrants scrutiny. Recommendations based on browsing history that are honest (showing products genuinely relevant to the user's interests) are not manipulative. Recommendations designed to exploit psychological weaknesses, create false urgency, or use hidden persuasion techniques could cross into this prohibition. Ensure your prompting and recommendation logic does not direct the model to use deceptive or manipulative tactics.

Art. 5(1)(b) — Exploitation of vulnerabilities: Not applicable for a standard product chatbot, provided you do not target users based on vulnerability characteristics (age, disability, socioeconomic circumstances).

Art. 5(1)(c) — Social scoring: Not applicable. Your chatbot does not evaluate or classify persons based on social behaviour over time to make consequential decisions in unrelated social contexts.

Art. 5(1)(d) — Predictive criminal risk assessment: Not applicable.

Art. 5(1)(e) — Untargeted facial recognition database creation: Not applicable.

Art. 5(1)(f) — Emotion inference in workplace or educational institutions: Not applicable to a customer-facing e-commerce chatbot.

Art. 5(1)(g) — Biometric categorization for sensitive attributes: Not applicable, provided your chatbot does not process biometric data.

Art. 5(1)(h) — Real-time remote biometric identification: Not applicable.

CONCLUSION: No prohibited practices are engaged, provided you avoid manipulative recommendation techniques. The system may lawfully be deployed in the EU.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STEP 4 — RISK TIER DETERMINATION (Art. 6)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

High-Risk Path A (Art. 6(1) — Annex I safety component): Your chatbot is not a safety component of any product covered by harmonised sectoral legislation (machinery, medical devices, civil aviation, etc.). Path A does not apply.

High-Risk Path B (Art. 6(2) — Annex III listed use case): Review of all eight Annex III areas:

- Area 1 (Biometrics): No biometric identification, categorization, or emotion recognition. Not engaged.
- Area 2 (Critical infrastructure): Not a safety component of road traffic, water, energy, or digital infrastructure management. Not engaged.
- Area 3 (Education): Not applicable to an e-commerce context.
- Area 4 (Employment/workers): Not used for recruitment, promotion, termination, or performance evaluation of workers. Not engaged.
- Area 5 (Essential services — creditworthiness, insurance, benefits): This is the most important area to examine for your chatbot. The chatbot answers questions, processes returns, and makes product recommendations. It does not evaluate creditworthiness (Area 5(b)), assess insurance risk (Area 5(c)), determine eligibility for public assistance (Area 5(a)), or dispatch emergency services (Area 5(d)). Not engaged for standard functions.
- Area 6 (Law enforcement): Not applicable.
- Area 7 (Migration/border control): Not applicable.
- Area 8 (Justice and democratic processes): Not applicable.

IMPORTANT CAVEAT — Art. 6(3) profiling override: If your chatbot's recommendation engine performs "profiling" within the meaning of Art. 3(52) — automated processing of personal data to evaluate natural persons' preferences, behaviour, or economic situation — this warrants legal attention. However, profiling alone does not make a system high-risk under Art. 6(3); it is only an override when the system is already within an Annex III category. Since your chatbot does not fall within any Annex III area, the profiling override does not elevate it to high-risk.

RISK TIER CONCLUSION: Your e-commerce chatbot is LIMITED RISK under Art. 50.

It is NOT high-risk. The primary legal obligation is transparency under Art. 50(1) (chatbot disclosure), with potential additional GDPR obligations given the processing of browsing history and personal data.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STEP 5 — YOUR OBLIGATIONS AS DEPLOYER
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Because your chatbot is limited-risk (not high-risk), the full Art. 26 deployer obligation regime (which applies only to high-risk systems) does not apply. Your obligations are as follows:

A. ART. 50(1) — MANDATORY AI DISCLOSURE (applies from 2 August 2026)

This is your primary obligation and it is unambiguous.

Art. 50(1) requires that deployers of AI systems intended to interact with natural persons — chatbots — ensure that users are informed they are interacting with an AI system. This disclosure must be made:
- At the latest at the time of first interaction
- In a clear and distinguishable manner
- In a format meeting accessibility standards under Directive 2019/882

The only exception is when it is "obvious to a reasonably well-informed user given the context and circumstances." A customer-facing chatbot on an e-commerce website does NOT meet this standard — not all customers will assume they are speaking with an AI, and the law does not permit that assumption to substitute for actual disclosure. You must disclose.

Practical implementation:
- Display a clear message at the start of every chat session, such as: "You are chatting with an AI assistant."
- Do not give the chatbot a name that implies it is a human (e.g., "Hi, I'm Sarah from customer support").
- The disclosure does not need to reveal which AI model powers the chatbot, only that the user is interacting with an AI system.

B. GDPR — DATA PROTECTION OBLIGATIONS (concurrent, applies now)

Your chatbot processes personal data (browsing history, return requests, purchase history). GDPR applies in full, independently of the AI Act. Key obligations:
- Art. 13/14 GDPR: Inform users in your privacy notice that their data is processed by an AI system for personalisation purposes, what data is used, the legal basis, and their rights.
- Art. 6 GDPR: Establish a valid legal basis for processing browsing history for recommendations. Consent (Art. 6(1)(a)) or legitimate interests (Art. 6(1)(f)) are the most likely bases; legitimate interests requires a balancing test.
- Art. 22 GDPR: If return decisions are made fully automatically without meaningful human review and produce legal or similarly significant effects on customers, Art. 22 may apply, requiring either human review, a right to contest, or explicit consent.
- Art. 35 GDPR: Consider whether a Data Protection Impact Assessment (DPIA) is required, particularly for large-scale profiling of individuals based on browsing history.

C. VOLUNTARY BEST PRACTICES (no mandatory obligation but strongly recommended)

Even though high-risk obligations (Arts. 9–17, 26) do not apply, the following practices are commercially prudent and may be required by your contractual relationship with your GPAI API vendor:
- Maintain usage policies consistent with the provider's terms of service
- Implement input/output monitoring to detect misuse or harmful outputs
- Establish an escalation path for complex queries or complaints that routes to a human agent
- Document your risk assessment concluding the system is limited-risk (this is good practice under Art. 6(3) documentation norms and provides a defence if ever challenged)


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STEP 6 — CONFORMITY ASSESSMENT AND CE MARKING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Conformity assessment (Art. 43), CE marking (Art. 48), and EU AI database registration (Art. 49) are PROVIDER obligations for high-risk systems. Since your chatbot is limited-risk and you are the deployer (not the provider of the underlying model), NONE of these obligations fall on you.

Your third-party GPAI model vendor (the provider) handles these obligations for their model. You should verify in your contract that your vendor confirms their model is compliant with applicable AI Act requirements as they come into force.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STEP 7 — GPAI OBLIGATIONS (your vendor's obligations, not yours — but relevant contractually)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The GPAI obligations under Arts. 51–55 fall on the model PROVIDER (your API vendor), not on you as deployer. However, these obligations matter to you because:

Art. 53 — Universal GPAI obligations (your vendor must comply from 2 August 2025):
- Produce technical documentation (Annex XI)
- Make available to downstream system providers (you) information about capabilities and limitations enabling your own compliance — this is the Annex XII downstream information obligation
- Maintain a copyright compliance policy
- Publish a training data summary

You should, as a downstream system provider building on the GPAI model via API, request and obtain the Annex XII information from your vendor. This information helps you understand the limitations of the model you are deploying, which is relevant to accurate user communications and responsible use.

Art. 51/55 — Systemic risk GPAI: If your vendor's model was trained on compute exceeding 10²⁵ FLOPs (which major frontier models may meet), it may be subject to additional Art. 55 obligations (model evaluation, adversarial testing, serious incident reporting to the AI Office, cybersecurity). Again, these fall on the vendor. However, you should ask whether your vendor has designated systemic-risk status, as this affects the robustness of their compliance programme and your own supply-chain risk.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

STEP 8 — POST-MARKET MONITORING AND INCIDENT REPORTING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Formal post-market monitoring (Art. 72) and serious incident reporting to market surveillance authorities (Art. 73) are mandatory only for HIGH-RISK AI system providers. Since your chatbot is limited-risk, these are not mandatory obligations.

However, as a responsible deployer, you should:
- Monitor chatbot outputs regularly for harmful, inaccurate, or misleading responses
- Maintain a feedback mechanism for customers to flag problematic interactions
- If a serious incident does occur (e.g., automated return decisions causing customer harm), your contractual agreement with your vendor should establish notification pathways


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ANSWER TO THE DISCLOSURE QUESTION: YES — YOU MUST DISCLOSE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Art. 50(1) is unambiguous: deployers of chatbots (AI systems intended to interact with natural persons) must ensure users are informed they are interacting with an AI system, unless it is obvious from context. A customer chatbot on an e-commerce site does not meet the "obvious" exception — disclosure is mandatory.

The disclosure requirement applies from 2 August 2026.

You do NOT need to:
- Name the specific model or vendor powering the chatbot
- Provide technical details about how the AI works
- Obtain consent for the AI interaction itself (though GDPR consent or legitimate interests applies to the data processing involved)

You DO need to:
- Clearly state at the start of each chat that the user is speaking with an AI
- Make this disclosure before the user has provided substantive input
- Meet accessibility standards in the disclosure format


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

COMPLIANCE SUMMARY TABLE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Requirement              | Article        | Applies To You? | Applies From    | Action Required
-------------------------|----------------|-----------------|-----------------|------------------------------------------
AI disclosure to users   | Art. 50(1)     | YES             | 2 Aug 2026      | Add clear "You are chatting with an AI" message at session start
Prohibited practices     | Art. 5         | YES             | 2 Feb 2025      | Verify recommendation logic avoids manipulation
GDPR compliance          | GDPR           | YES             | Now             | Privacy notice, legal basis, DPIA assessment
Risk management system   | Art. 9         | NO (provider)   | —               | Vendor obligation; request confirmation via contract
Technical documentation  | Art. 11        | NO (provider)   | —               | Vendor obligation
Conformity assessment    | Art. 43        | NO (provider)   | —               | Vendor obligation
CE marking               | Art. 48        | NO (provider)   | —               | Vendor obligation
EU AI database reg.      | Art. 49        | NO (provider)   | —               | Vendor obligation
Annex XII info request   | Art. 53        | Indirect        | 2 Aug 2025      | Request capabilities/limitations info from GPAI vendor
Post-market monitoring   | Art. 72        | NO (mandatory)  | —               | Recommended voluntarily
Serious incident report  | Art. 73        | NO (mandatory)  | —               | Establish internal escalation and vendor notification process
Human oversight          | Art. 14        | NO (mandatory)  | —               | Recommended: human escalation path for complex cases


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PENALTIES FOR NON-COMPLIANCE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Violations of Art. 50 (including failure to disclose AI interaction) are deployer/provider violations falling under Art. 99's second tier: up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For SMEs and startups, the lower of the fixed amount or percentage applies.

Violations of Art. 5 prohibited practices: up to €35,000,000 or 7% of global annual turnover.


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

KEY IMMEDIATE ACTIONS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

NOW (pre-August 2026):
1. Audit your recommendation logic for any manipulative design patterns that could trigger Art. 5(1)(a) — this prohibition applies from 2 February 2025.
2. Complete GDPR compliance: update privacy notice to disclose AI-powered personalisation, establish legal basis for browsing history processing, assess DPIA need.
3. Review your GPAI vendor contract: ensure it requires them to provide Annex XII downstream information by 2 August 2025 and commits them to ongoing AI Act compliance.

BY 2 AUGUST 2026:
4. Implement Art. 50(1) AI disclosure: display a clear notification at the start of every chat session confirming the user is interacting with an AI system.
5. Conduct and document a risk classification assessment confirming your chatbot is limited-risk (not high-risk), retaining it in case of regulatory enquiry.

ONGOING:
6. Monitor chatbot outputs for quality, accuracy, and potential harms.
7. Maintain an accessible human escalation pathway for return disputes and complex queries.

EU AI ACT COMPLIANCE OBLIGATIONS FOR AN E-COMMERCE CHATBOT DEPLOYER
=====================================================================

SCENARIO SUMMARY
----------------
- System: Customer-facing chatbot on an e-commerce website
- Functions: Answering product questions, processing returns, recommending products based on browsing history
- Underlying technology: Third-party General Purpose AI (GPAI) model accessed via API
- Role in the AI value chain: You are the DEPLOYER (not the provider/developer of the underlying AI model)

---

PART 1: UNDERSTANDING YOUR ROLE UNDER THE EU AI ACT
----------------------------------------------------

The EU AI Act (Regulation (EU) 2024/1689, which entered into force on 1 August 2024, with most provisions applying from 2 August 2026) distinguishes between several actors in the AI value chain:

- PROVIDER: The entity that develops or places an AI system on the market (in your case, the GPAI model vendor, e.g., OpenAI, Anthropic, Google, etc.)
- DEPLOYER: An entity that uses an AI system under its own authority for a specific purpose (THIS IS YOU — you are integrating the GPAI model into your e-commerce chatbot and deploying it to customers)
- IMPORTER / DISTRIBUTOR: Not directly relevant here

As the DEPLOYER, your obligations differ from those of the PROVIDER. However, you bear significant responsibilities, particularly around risk management, transparency, and human oversight.

---

PART 2: RISK CLASSIFICATION OF YOUR CHATBOT
--------------------------------------------

The EU AI Act establishes a tiered risk framework. Correctly classifying your system is the first step.

2.1 Is it a Prohibited AI Practice?
The chatbot as described does NOT fall under any of the prohibited practices listed in Article 5 (e.g., subliminal manipulation, social scoring, real-time biometric surveillance in public spaces). You are safe on this front.

2.2 Is it High-Risk AI?
High-risk AI systems are listed in Annex III of the Act. The categories most relevant to e-commerce include:
- Biometric categorisation systems
- AI used in employment and workers management
- AI used for access to essential private services and public services / benefits

A standard e-commerce chatbot handling product queries, returns, and product recommendations does NOT ordinarily fall into the Annex III high-risk categories. The product recommendation engine based on browsing history is a profiling activity but does not constitute a "high-risk" AI system under the Act's current Annex III definitions, as it is not making consequential decisions about access to essential services, creditworthiness, or similar impactful areas.

IMPORTANT CAVEAT: If your chatbot were extended to make credit decisions (e.g., buy-now-pay-later eligibility) or employment screening, the risk classification would change. Stick to the described scope and you are outside the high-risk tier.

CONCLUSION ON RISK TIER: Your chatbot most likely falls into the LIMITED RISK or MINIMAL RISK category.

---

PART 3: TRANSPARENCY OBLIGATIONS (LIMITED RISK — ARTICLES 50 AND 52)
---------------------------------------------------------------------

Even though your chatbot is not high-risk, it is subject to TRANSPARENCY OBLIGATIONS under Article 50 of the EU AI Act. This is the most immediately actionable set of obligations for you.

3.1 Mandatory AI Disclosure — Article 50(1): THE ANSWER IS YES, YOU MUST DISCLOSE

Article 50(1) states: "Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the circumstances or the context of use."

As a DEPLOYER, Article 50(1) also imposes an obligation on you (since you are deploying this system to interact with customers). The disclosure obligation applies to chatbots by design.

Specifically:
- You MUST inform users they are talking to an AI, not a human
- This disclosure must be made BEFORE or AT THE START of the interaction, not buried in terms and conditions
- The disclosure must be clear and intelligible
- Exception: If it is "obvious from the circumstances" — however, regulators and guidance suggest this exception is narrow; you should not assume obviousness and should always disclose proactively

3.2 What the Disclosure Must Say
The Act does not mandate a precise form of words, but the disclosure must:
- Be in plain language
- Be prominent (not hidden in a footer or FAQ)
- Clearly indicate the user is interacting with an AI system
- Ideally, name it as a chatbot or AI assistant

Example compliant disclosure: "Hi! I'm [Brand Name]'s AI assistant. How can I help you today?" or a persistent label such as "AI-Powered Assistant" visible throughout the conversation.

3.3 Prohibition on Impersonating Humans — Article 50(3)
Article 50(3) prohibits AI systems from impersonating real persons or creating the false impression of being human. Your chatbot must not:
- Claim to be a human customer service agent
- Use a human name without clearly indicating it is AI (e.g., "Hi, I'm Sarah" without disclosing Sarah is an AI)
- Deny being an AI when directly asked by a user

This is one of the strongest obligations in the Act for chatbot operators.

3.4 Emotion Recognition and Biometric Categorisation
If your chatbot uses any emotion recognition (e.g., sentiment analysis to flag frustrated customers) or biometric categorisation, additional transparency requirements apply under Article 50(3)-(4). These likely do not apply to the described scenario, but review your technical stack carefully.

---

PART 4: OBLIGATIONS SPECIFICALLY FOR DEPLOYERS — ARTICLE 26
------------------------------------------------------------

Article 26 of the EU AI Act sets out obligations for deployers. Even for a limited-risk or minimal-risk system, the following considerations apply:

4.1 Use in Accordance with Instructions
You must use the AI system in accordance with the provider's instructions of use (the GPAI model provider's terms of service and usage policies). If the provider has specified permissible use cases, you must not operate outside those use cases.

4.2 Human Oversight
You must implement appropriate measures to enable human oversight of the AI system's outputs, particularly:
- Monitoring for harmful, incorrect, or misleading outputs
- Establishing processes for customers to escalate to a human agent
- Reviewing chatbot interactions for quality and accuracy

4.3 Data Governance and Logging
You should maintain logs of interactions to the extent necessary to monitor system behaviour and investigate complaints. This also intersects with GDPR obligations (see Part 7 below).

4.4 Fundamental Rights Impact Assessment (FRIA)
Article 27 requires deployers of HIGH-RISK AI systems to conduct a Fundamental Rights Impact Assessment (FRIA) before deployment. Since your chatbot is not high-risk, a formal FRIA is not legally required. However, it is best practice to consider potential impacts on consumer rights, privacy, and non-discrimination before launch.

---

PART 5: GPAI MODEL — YOUR RELATIONSHIP WITH THE PROVIDER
----------------------------------------------------------

Because you are using a third-party GPAI model via API, you need to understand the obligations that flow upstream.

5.1 GPAI Provider Obligations (Not Yours Directly)
Under Articles 53-55, GPAI providers (the model developers) must:
- Maintain technical documentation
- Have a copyright compliance policy
- Publish a sufficiently detailed summary of training data (for transparency to the public)
- If the model is "systemic risk" GPAI (very large models, >10^25 FLOPs training compute): additional obligations including adversarial testing, incident reporting, cybersecurity measures

These obligations fall on the GPAI provider (e.g., your API vendor), not on you as the deployer of an application built on top of that model.

5.2 What You Should Do As Deployer Using a GPAI Model
- Review the GPAI provider's documentation and ensure their model is compliant with the EU AI Act (they should be able to provide assurances or documentation to this effect)
- Review the provider's Terms of Service — ensure your use case is permitted
- Ensure you have a contract with the provider that clearly defines their responsibilities under the EU AI Act vs. your responsibilities
- Obtain and review any model cards, transparency summaries, or capability disclosures the GPAI provider publishes

5.3 Liability Allocation
The EU AI Act creates a division of liability. If a GPAI provider fails to meet their obligations (e.g., inadequate documentation), liability may rest with them. However, if you deploy the system in a manner that exceeds the provider's specified instructions or in a prohibited context, liability shifts to you.

---

PART 6: PRODUCT RECOMMENDATIONS BASED ON BROWSING HISTORY — PROFILING CONSIDERATIONS
--------------------------------------------------------------------------------------

The product recommendation feature involves processing browsing history data to personalise recommendations. This is a form of automated profiling. Key considerations:

6.1 Under EU AI Act
Automated profiling for product recommendations on an e-commerce site does not by itself trigger high-risk classification, as it does not make decisions with significant legal or similarly significant effects on individuals (compare to credit scoring or insurance pricing). However:
- You must be transparent about this automated personalisation (also required under GDPR — see below)
- If the recommendation engine were to affect access to pricing, discounts, or services in a discriminatory way, the risk profile could change

6.2 Non-Discrimination
AI-driven recommendations must not discriminate against users on the basis of protected characteristics (race, gender, religion, etc.) under applicable EU law. While the EU AI Act's non-discrimination provisions are most stringent for high-risk systems, you should ensure your recommendation model is not producing discriminatory outputs.

---

PART 7: INTERSECTION WITH GDPR
--------------------------------

The EU AI Act does not replace GDPR — both apply simultaneously. For your e-commerce chatbot, GDPR implications include:

7.1 Legal Basis for Processing
- Browsing history used for recommendations: Typically requires consent (GDPR Article 6(1)(a)) or legitimate interests assessment (Article 6(1)(f)) — but consent is strongly preferred for this type of profiling
- Conversation logs: May be processed under contract performance or legitimate interests, depending on purpose

7.2 Right to Explanation / Right Not to Be Subject to Automated Decisions
GDPR Article 22 applies where decisions are made "solely by automated means" and produce "legal or similarly significant effects." Product recommendations on an e-commerce site typically do not reach this threshold, but if the chatbot were used to make decisions about user accounts, credit, or access, Article 22 rights would be triggered.

7.3 Privacy Notice Updates
Your privacy notice must disclose:
- That an AI chatbot is used
- The nature of the personal data processed by the chatbot (conversation content, browsing history)
- Any third-party GPAI provider that processes personal data (as a data processor)
- Retention periods for conversation logs

7.4 Data Processing Agreement (DPA)
You must have a GDPR-compliant Data Processing Agreement (DPA) with your GPAI API provider, since they will process personal data contained in user queries on your behalf (Article 28 GDPR).

---

PART 8: TIMELINE AND APPLICABILITY
------------------------------------

Key EU AI Act timeline dates:
- 1 August 2024: Act entered into force
- 2 February 2025: Prohibited AI practices (Article 5) became applicable
- 2 August 2025: Obligations for GPAI providers (Articles 53-55) became applicable
- 2 August 2026: Most remaining obligations, including deployer obligations and transparency obligations (Article 50), become fully applicable
- 2 August 2027: High-risk AI system obligations for certain legacy systems

For a new deployment in 2026 or beyond, you need to be compliant with Articles 26 and 50 from day one of your launch.

If you are already operating such a chatbot, you should be working toward compliance now, particularly on the transparency/disclosure requirements which are straightforward to implement.

---

PART 9: PRACTICAL COMPLIANCE CHECKLIST FOR YOUR CHATBOT
--------------------------------------------------------

MUST-DO (Legal Requirements):

[ ] 1. AI DISCLOSURE: Display a clear disclosure at the start of every conversation that the user is interacting with an AI system. Example: "You're chatting with our AI assistant."

[ ] 2. NO HUMAN IMPERSONATION: Ensure the chatbot does not claim or imply it is a human. If given a name (e.g., "Aria"), clearly label it as an AI assistant.

[ ] 3. HONEST RESPONSE TO "ARE YOU AN AI?": Program the chatbot to always acknowledge it is an AI when directly asked. Never deny being an AI.

[ ] 4. USE WITHIN PROVIDER TERMS: Review and comply with the GPAI API provider's acceptable use policy. Ensure your use case (returns processing, recommendations) is permitted.

[ ] 5. HUMAN ESCALATION PATH: Provide users with a clear and accessible way to speak with a human agent. This supports the human oversight requirement.

[ ] 6. DATA PROCESSING AGREEMENT: Execute a GDPR-compliant DPA with your GPAI API provider.

[ ] 7. PRIVACY NOTICE UPDATE: Update your website's privacy notice to disclose the use of AI, the data processed by the chatbot, and the GPAI provider as a processor.

[ ] 8. CONSENT FOR BROWSING HISTORY PROFILING: Ensure you have valid GDPR legal basis (preferably consent) for using browsing history to power recommendations.

SHOULD-DO (Best Practice):

[ ] 9. INTERACTION LOGGING AND MONITORING: Log chatbot interactions for quality assurance and safety monitoring, with appropriate retention limits.

[ ] 10. INTERNAL DOCUMENTATION: Document your AI system, its purpose, the underlying model, and your compliance measures (helpful if ever audited by a national authority).

[ ] 11. BIAS AND FAIRNESS REVIEW: Periodically review recommendation outputs for discriminatory patterns.

[ ] 12. INCIDENT RESPONSE PLAN: Establish a process to handle complaints or incidents involving the chatbot, including escalation to human agents and reporting mechanisms.

[ ] 13. CONTRACTUAL PROTECTIONS: Ensure your contract with the GPAI provider includes EU AI Act compliance warranties and allocates liability appropriately.

[ ] 14. STAFF TRAINING: Train customer service and technical staff on AI Act obligations, how the chatbot works, and how to handle escalations.

---

PART 10: ENFORCEMENT AND PENALTIES
------------------------------------

The EU AI Act is enforced by national market surveillance authorities (each EU Member State designates one). For deployers:
- Violations of transparency obligations (Article 50) can result in fines of up to EUR 15,000,000 or 3% of global annual turnover (whichever is higher)
- Violations of prohibited practices (Article 5) carry fines of up to EUR 35,000,000 or 7% of global annual turnover
- Supplying incorrect or misleading information to authorities can result in fines of up to EUR 7,500,000 or 1% of global annual turnover

Given the relatively low compliance cost for a limited-risk chatbot (primarily a disclosure notice and process controls), the risk/benefit analysis strongly favours early compliance action.

---

SUMMARY ANSWER TO THE CORE QUESTIONS
--------------------------------------

Q: What are your EU AI Act obligations as the deployer?

A: As a deployer of a limited-risk AI chatbot, your primary obligations are:
1. Transparency/disclosure to users (Article 50)
2. Using the AI within the provider's instructions (Article 26)
3. Implementing human oversight mechanisms (Article 26)
4. Reviewing GPAI provider compliance documentation

You do NOT have the extensive obligations of a high-risk AI system deployer (formal conformity assessments, CE marking, registration in EU database, etc.) unless your chatbot's scope expands into high-risk use cases.

Q: Do you need to disclose it is an AI?

A: YES — UNAMBIGUOUSLY. Article 50(1) of the EU AI Act requires that users interacting with an AI chatbot be clearly informed they are interacting with an AI, unless it is obvious from the context. This obligation applies to your chatbot. It is one of the clearest and most straightforward obligations in the Act. You must implement this disclosure before or at the beginning of each interaction, and you must never allow the chatbot to deny being an AI when asked.

---

DISCLAIMER: This analysis reflects the EU AI Act as enacted (Regulation (EU) 2024/1689) and the state of regulatory guidance as of mid-2026. The EU AI Act is supplemented by delegated acts, implementing acts, and guidance from the AI Office that continue to evolve. Always consult qualified legal counsel for advice specific to your organisation's circumstances.

Completing an Accessibility Conformance Report (ACR) Using the VPAT 2.x WCAG Edition

As a SaaS vendor responding to a federal RFP that requires a VPAT, you are entering a formal procurement process governed by Section 508 of the Rehabilitation Act (29 U.S.C. § 794d), as implemented by the Revised Section 508 Standards (36 CFR Part 1194, effective January 18, 2018). Below is a complete walkthrough of the ACR process for your web-based project management tool.

---

STEP 1: UNDERSTAND THE TEMPLATE

Use the VPAT 2.x WCAG Edition template published by ITI (Information Technology Industry Council), available at www.itic.org. Do not use older VPAT 1.x templates — federal agencies now require the 2.x series because it maps directly to the 2018 Revised Section 508 Standards, which incorporate WCAG 2.0 Level A and AA (via provision E205).

The VPAT 2.x WCAG Edition ACR has the following major sections:

  1. Product Information — Product name, version, report date, vendor contact, and a brief description of the product.
  2. Evaluation Methods Used — Describe what tools, assistive technologies, browsers, and manual methods you used.
  3. Table 1: Success Criteria, Level A — One row per WCAG 2.0 Level A success criterion.
  4. Table 2: Success Criteria, Level AA — One row per WCAG 2.0 Level AA success criterion.
  5. Table 3: Functional Performance Criteria — How your product supports users with various disabilities independent of specific technical criteria.
  6. Chapter 5 (Software) and Chapter 6 (Support Documentation and Services) — Applicable if your product includes native software components or has support documentation requirements.

For a pure web-based SaaS product, Tables 1, 2, and 3 are the core deliverables. Chapters 5 and 6 apply if you have downloadable clients or published help documentation.

---

STEP 2: UNDERSTAND THE THREE MAIN TABLES

Table 1 — WCAG 2.0 Level A Success Criteria
This table covers the baseline accessibility requirements. Key criteria for a project management tool include:
  - 1.1.1 Non-text Content (A): All icons, avatars, chart images, and status indicators must have meaningful alt text.
  - 1.3.1 Info and Relationships (A): Tables, lists, headings, and form labels must use proper semantic markup.
  - 2.1.1 Keyboard (A): Every feature — task creation, drag-and-drop, modals, menus — must be fully operable by keyboard alone.
  - 2.1.2 No Keyboard Trap (A): Users must be able to navigate away from every component using keyboard alone.
  - 4.1.2 Name, Role, Value (A): All interactive UI components (buttons, dropdowns, date pickers, custom widgets) must expose their name, role, and state to assistive technologies via ARIA or native HTML semantics.

Table 2 — WCAG 2.0 Level AA Success Criteria
These are the additional requirements that Section 508 mandates for federal procurement. Key criteria include:
  - 1.4.3 Contrast Minimum (AA): Text must have at least 4.5:1 contrast ratio (3:1 for large text). Check all text colors, disabled state labels, and placeholder text.
  - 1.4.4 Resize Text (AA): The application must remain functional and readable when text is scaled to 200% in the browser.
  - 2.4.5 Multiple Ways (AA): Users must be able to find content via multiple means (navigation, search, sitemap).
  - 2.4.6 Headings and Labels (AA): All headings and form labels must be descriptive.
  - 2.4.7 Focus Visible (AA): The keyboard focus indicator must be visible at all times.
  - 3.3.3 Error Suggestion (AA): When a form error occurs (e.g., invalid date, missing required field), the error message must suggest how to correct it.

Table 3 — Functional Performance Criteria (Chapter 3)
This table evaluates whether users with various disability types can independently use your product, even if they rely on methods not covered by the WCAG criteria alone. The criteria are:
  - 302.1 Without Vision — Can a blind user access all features using a screen reader?
  - 302.2 With Limited Vision — Can a low-vision user access features using magnification and high contrast?
  - 302.3 Without Perception of Color — Is color never the sole indicator of status or meaning?
  - 302.4 Without Hearing — Is all audio content available as text (captions, transcripts)?
  - 302.5 With Limited Hearing — Is audio quality sufficient for users with partial hearing?
  - 302.6 Without Speech — Does the product function without voice input?
  - 302.7 With Limited Manipulation — Can users with limited dexterity operate all features (no fine-motor-required gestures)?
  - 302.8 With Limited Reach and Strength — All controls operable without requiring sustained physical effort.
  - 302.9 With Limited Language, Cognitive, and Learning Abilities — Content uses plain language and consistent navigation.

For each row in all three tables, you must supply a Conformance Level and Remarks.

---

STEP 3: UNDERSTAND THE FOUR CONFORMANCE LEVELS

Each row in Tables 1, 2, and 3 requires one of exactly four conformance level values:

  1. Supports
     The product fully meets the success criterion across all relevant functionality. There are no known failures. Example: "All interactive controls expose their name and role via native HTML semantics and ARIA; verified with JAWS 2024 + Chrome and NVDA + Firefox."

  2. Partially Supports
     The product meets the criterion in some instances but not all. You must specify in the Remarks column exactly where it fails. Example: "Most form fields have associated labels via <label> elements. However, the custom date-picker widget in the task creation modal does not expose its current value to screen readers (SC 4.1.2 failure)."

  3. Does Not Support
     The product does not meet the criterion. You must describe the failure and, ideally, your remediation timeline. Example: "Drag-and-drop task reordering has no keyboard-accessible equivalent (SC 2.1.1 failure). Remediation planned for Q3 2026 release."

  4. Not Applicable
     The criterion does not apply to the product. You must justify this. Example: "SC 1.2.1 Audio-only and Video-only: The product contains no pre-recorded audio-only or video-only content. Not Applicable."

Important: Do not use "Not Applicable" as an escape hatch. Auditors will challenge unjustified Not Applicable entries. If your product has any video tutorials, embedded media, or dynamic content, those criteria apply.

---

STEP 4: CONDUCT THE REQUIRED TESTING

You cannot complete an accurate ACR without real testing. Self-attestation based on code inspection alone is not sufficient and will be challenged during agency review. Complete the following testing phases before filling in the VPAT tables.

Phase 1 — Automated Scanning (Start Here)
Run automated accessibility scanners as a first pass. Recommended tools:
  - axe DevTools (browser extension or axe-core API) — the industry standard; integrates with CI/CD pipelines
  - WAVE (WebAIM) — browser extension with visual overlay of errors
  - Google Lighthouse — built into Chrome DevTools; run the Accessibility audit

Important caveat: Automated tools catch approximately 30-40% of WCAG failures. They reliably detect missing alt text, duplicate IDs, missing form labels, and obvious contrast failures. They cannot detect logical reading order failures, meaningful focus order problems, or whether a screen reader actually announces custom widgets correctly. Automated results are a floor, not a ceiling.

Phase 2 — Keyboard-Only Navigation
Test every workflow in your project management tool using only Tab, Shift+Tab, Enter, Space, Escape, and Arrow keys. Verify:
  - All task creation, editing, and deletion flows are keyboard operable.
  - Modal dialogs trap focus correctly (focus stays inside the modal) and release focus properly on close.
  - Dropdown menus and custom selects are operable by keyboard.
  - Drag-and-drop functionality has a keyboard-accessible alternative.
  - There are no keyboard traps (SC 2.1.2).
  - Focus order is logical (SC 2.4.3).
  - Focus indicator is always visible (SC 2.4.7).

Phase 3 — Screen Reader + Browser Combinations
Test with the following assistive technology and browser combinations. Each combination reflects real-world usage patterns among federal government users:

  - JAWS (latest version) + Google Chrome — JAWS is the most widely used screen reader in federal environments. Chrome is the dominant browser.
  - NVDA (latest version) + Mozilla Firefox — NVDA is the primary free/open-source screen reader; Firefox has strong ARIA support.
  - NVDA (latest version) + Google Chrome — Cross-test NVDA with Chrome to catch browser-specific rendering differences.
  - VoiceOver + Safari on macOS — Required for Mac users and for testing ARIA live regions on WebKit.
  - VoiceOver + Safari on iOS — Test mobile responsiveness for government employees using iPads or iPhones.
  - TalkBack + Chrome on Android — Android is common on federal mobile devices.

For each combination, walk through the primary user workflows: logging in, creating a project, creating a task, assigning a user, setting a due date, and viewing a dashboard. Document what the screen reader announces at each step.

Phase 4 — Color Contrast Verification
Use the Colour Contrast Analyser (TPGi) or the browser DevTools contrast checker to verify:
  - All body text: minimum 4.5:1 ratio (SC 1.4.3)
  - Large text (18pt/14pt bold and above): minimum 3:1 ratio
  - Focus indicators: verify visible against adjacent colors
  - Status badges and tags (e.g., "High Priority" in red): ensure contrast meets threshold

Phase 5 — Zoom and Reflow Testing
Set browser zoom to 200% and verify no content is lost or obscured. At 400% zoom (WCAG 2.1 SC 1.4.10, Reflow — not required by 508 but good practice), content should reflow to a single column without horizontal scrolling.

Phase 6 — Document Results
For each failure found, record: the WCAG success criterion number and name, the specific element or workflow, the assistive technology/browser combination that revealed it, a screenshot or video clip, and the severity (Critical, High, Medium, Low).

---

STEP 5: FILL IN THE VPAT TABLES

With test results in hand:

1. Complete the Product Information section: include product name, version number, report date, company name, and a description of what the product does.

2. Complete the Evaluation Methods section: list every tool and AT combination used (e.g., "axe DevTools 4.x, NVDA 2024.1 + Firefox 125, JAWS 2024 + Chrome 124, VoiceOver + Safari 17 on macOS Sonoma, keyboard-only navigation testing, manual code inspection").

3. For each row in Table 1 and Table 2: assign the appropriate conformance level and write a Remarks entry. The Remarks must be specific — cite the affected component, the failure mode, and your remediation status. Vague remarks like "Generally supports this criterion" will not satisfy agency reviewers.

4. For each row in Table 3: describe how your product supports the functional category. Reference your screen reader test results and keyboard test results.

5. Complete Chapters 5 and 6 if applicable.

---

STEP 6: WRITE THE REMARKS CORRECTLY

Federal agency evaluators read the Remarks column carefully. Best practices:

- For "Supports": briefly confirm and cite the mechanism (e.g., "All images use <img> with meaningful alt text or alt='' for decorative images. Verified with axe-core and NVDA + Firefox.").
- For "Partially Supports": name the specific component that fails and the failure mode. Do not leave this vague.
- For "Does Not Support": state the failure clearly and include your remediation commitment if you have one.
- For "Not Applicable": provide a one-sentence justification tied to your product's actual functionality.

---

PROCUREMENT OBLIGATIONS SUMMARY

Under FAR clause 52.239-2 (when incorporated) and the agency's 508 program requirements, you may be required to:
  - Submit the completed ACR with your RFP response or within 30 days of contract award.
  - Provide updated ACRs with each major product release.
  - Remediate Critical issues (keyboard traps, complete screen reader failures) within 30 days of identification; High issues within 60 days; Medium within 90 days.
  - Provide an alternative means of access if claiming undue burden on any criterion.

If your product has known gaps, do not hide them. Agencies expect gaps in commercial products. A "Partially Supports" entry with a clear remediation timeline is far preferable — legally and practically — to a false "Supports" claim that unravels during agency accessibility testing.

---

REGULATORY CITATION SUMMARY

- Section 508 authority: 29 U.S.C. § 794d; Revised Standards: 36 CFR Part 1194 (effective January 18, 2018)
- Web/software/document requirement: E205 (incorporates WCAG 2.0 Level A and AA)
- Functional Performance Criteria: Chapter 3 (302.1–302.9)
- VPAT template source: ITI (Information Technology Industry Council), VPAT 2.x WCAG Edition
- FAR procurement clause: 52.239-2 (AccessIbilty of ICT)

Completing an Accessibility Conformance Report (ACR) Using the VPAT 2.x WCAG Edition Template

Overview

When responding to a federal agency RFP that requires a Voluntary Product Accessibility Template (VPAT), you must produce an Accessibility Conformance Report (ACR). The ACR is your formal, documented statement of how well your product meets accessibility standards. Federal agencies use it to evaluate whether your SaaS product complies with Section 508 of the Rehabilitation Act, which incorporates WCAG 2.0 Level A and AA success criteria by reference (via the 2017 ICT Final Rule).

The VPAT 2.x templates are published and maintained by the Information Technology Industry Council (ITI). For a web-based product, the correct template is the VPAT 2.x WCAG Edition. As of the current versions (VPAT 2.4 and later revisions), this template is available directly from the ITI website (www.itic.org). Do not use older VPAT 1.x templates; federal procurement reviewers will expect the 2.x format.


Step 1: Testing Before You Fill Out the VPAT

You cannot accurately complete a VPAT without prior accessibility testing. Completing a VPAT based on assumptions or developer intent — rather than actual test results — is a serious error that can expose your company to legal risk and damage your agency relationship. Testing should precede document authoring.

1a. Automated Testing (First Step — Necessary but Not Sufficient)

Start with automated scanning tools. These are fast, repeatable, and catch a well-defined subset of issues. Common tools include:

- axe (Deque Systems) — available as a browser extension and CI/CD integration
- WAVE (WebAIM) — browser extension and API
- Lighthouse (Google) — built into Chrome DevTools, also available via CLI
- IBM Equal Access Checker
- Siteimprove Accessibility Checker

Important caveat: Automated tools can reliably detect roughly 30–40% of WCAG failures (some estimates range from 20–57% depending on the tool and ruleset). They cannot assess cognitive usability, logical reading order in complex layouts, the meaningfulness of alt text, or whether interactive components are operable by keyboard in practice. Automated testing is a starting point, not a finishing point.

1b. Manual Keyboard Testing

Navigate your entire application using only a keyboard (Tab, Shift+Tab, Enter, Space, Arrow keys, Escape). Verify that:
- All interactive elements receive visible focus
- Focus order is logical
- No keyboard traps exist
- Modals and custom widgets (date pickers, drag-and-drop, rich text editors) are fully keyboard-operable

1c. Assistive Technology Testing

You must test with real assistive technology (AT) paired with specific browsers, because AT/browser combinations behave differently. Required combinations for a thorough VPAT covering a web product include at minimum:

- JAWS (Job Access With Speech) + Chrome on Windows — the most common enterprise screen reader combination; JAWS is widely used in federal government
- NVDA (NonVisual Desktop Access) + Firefox on Windows — open-source screen reader, widely used; pairing with Firefox tests a distinct rendering path
- VoiceOver + Safari on macOS — required for Apple ecosystem coverage
- VoiceOver + Safari on iOS (iPhone/iPad) — if your product has a mobile-responsive interface
- TalkBack + Chrome on Android — for mobile coverage
- Dragon NaturallySpeaking (Dragon Professional) + Chrome — for speech input testing (relevant to WCAG 2.1 success criteria and Section 508 functional performance criteria)

At minimum, cover JAWS + Chrome, NVDA + Firefox, and VoiceOver + Safari to address the most common federal user scenarios.

1d. Color Contrast and Visual Testing

Use tools like the Colour Contrast Analyser or browser dev tools to verify all text meets the 4.5:1 ratio (normal text) and 3:1 ratio (large text) required by WCAG 1.4.3.

1e. User Testing with People with Disabilities

Where possible, include participants with disabilities in usability testing. This is not strictly required for the VPAT but strengthens the credibility of your conformance claims.


Step 2: Understanding the VPAT 2.x WCAG Edition Structure

The ITI VPAT 2.x WCAG Edition template contains three primary tables you must complete:

Table 1: Success Criteria, Level A

This table lists all WCAG 2.x Level A success criteria (the minimum baseline requirements). For a web application, this includes criteria such as:
- 1.1.1 Non-text Content
- 1.3.1 Info and Relationships
- 2.1.1 Keyboard
- 4.1.2 Name, Role, Value
...and all other Level A criteria.

For each criterion, you provide:
- A conformance level (see Step 3)
- Remarks and explanations describing how your product meets or does not meet the criterion, and what specific issues exist

Table 2: Success Criteria, Level AA

This table lists all WCAG 2.x Level AA success criteria, which are required by Section 508 (the 2017 ICT Final Rule incorporates WCAG 2.0 Levels A and AA). Examples include:
- 1.4.3 Contrast (Minimum)
- 1.4.4 Resize Text
- 2.4.7 Focus Visible
- 3.3.3 Error Suggestion

The same conformance level and remarks structure applies.

Note: The VPAT 2.x template also includes an optional Level AAA table. Federal agencies do not require Level AAA conformance, but you may include it voluntarily.

Table 3: Functional Performance Criteria (FPC)

This table is specific to Section 508 and does not map directly to individual WCAG criteria. Instead, it addresses the functional outcomes that the product must support, corresponding to 36 CFR 1194.31. The criteria include:

- Without Vision — usable without sight (screen reader access)
- With Limited Vision — usable with low vision (magnification, contrast)
- Without Perception of Color — usable when color is not available
- Without Hearing — usable without audio
- With Limited Hearing — usable with limited hearing
- Without Speech — operable without spoken input
- With Limited Manipulation — operable with limited hand/arm dexterity
- With Limited Reach and Strength — operable with limited physical reach
- With Limited Language, Cognitive, and Learning Abilities — usable by people with cognitive disabilities
- With Photosensitivity — does not cause seizures

For each FPC, you again provide a conformance level and narrative explanation.

The template also includes a header section where you document: product name and version, report date, contact information, evaluation methods used, and applicable standards (WCAG 2.x, Revised Section 508).


Step 3: Understanding the Four Conformance Levels

Every row in every VPAT table must be assigned one of four conformance levels. These are standardized terms — do not use alternatives like "Mostly Supports" or "N/A with asterisk."

1. Supports
The product fully meets the success criterion without exception. All functionality that is within scope of the criterion works in an accessible manner. Use this level only when you have confirmed through testing that there are no failures.

2. Partially Supports
Some functionality meets the success criterion, but some does not. This is the most commonly used level for products that have some accessibility issues but are not completely inaccessible for a given criterion. Your remarks must explain what works, what does not, and ideally describe the specific defect (e.g., "The modal dialog closes on Escape in Chrome but does not return focus to the triggering element in NVDA + Firefox").

3. Does Not Support
The product does not meet the success criterion. The functionality exists but is not accessible in the way the criterion requires. Your remarks should explain the nature of the failure.

4. Not Applicable
The success criterion does not apply to your product because the relevant feature type is not present. For example, if your project management tool has no audio or video content, criteria like 1.2.1 (Audio-only and Video-only) would be Not Applicable. Document clearly why the criterion does not apply.

Important note on honesty: Federal agencies and their 508 coordinators are increasingly sophisticated in reviewing VPATs. Overclaiming "Supports" where issues exist will damage your credibility during procurement. It is better to acknowledge "Partially Supports" with a clear remediation roadmap than to claim full conformance inaccurately.


Step 4: Writing the Remarks and Explanations Column

For every row where conformance is not "Supports" or "Not Applicable," the Remarks and Explanations column must provide enough detail for the agency to understand:
- What specific functionality is affected
- What the failure mode is
- What user impact results (e.g., screen reader users cannot access the Gantt chart export function)
- What your remediation plan and timeline is (optional but strengthens the submission)

Vague remarks like "Some issues exist" are insufficient. Specificity demonstrates that you have actually tested the product.


Step 5: Scoping Your VPAT

For a web-based project management SaaS tool, you need to define what is in scope before you begin. Typical scope considerations:

- Core application features: task creation, project dashboards, user management, reporting
- Authentication flows: login, MFA, password reset
- Third-party embedded components: if you use a third-party Gantt chart widget, rich text editor, or file picker, you are responsible for its accessibility in your product
- Help documentation and support portal (if web-based): also subject to Section 508
- Mobile web experience: if your app is responsive or has a mobile site
- Out of scope: things genuinely not part of your product offering (document clearly)


Step 6: Keeping the ACR Current

An ACR is a point-in-time document. Federal agencies expect it to reflect the version of the product being procured. When you release new versions with significant UI changes, update the ACR. Some agencies will ask for an ACR dated within the past 12–18 months. Maintain version control on your ACR alongside your product releases.


Summary Checklist for VPAT Completion

1. Select the correct template: VPAT 2.x WCAG Edition from ITI (itic.org)
2. Define scope (what features and user flows are covered)
3. Run automated scans (axe, WAVE, Lighthouse) — document tool versions and scan dates
4. Conduct manual keyboard testing across all workflows
5. Test with AT/browser combinations: at minimum JAWS + Chrome, NVDA + Firefox, VoiceOver + Safari
6. Complete Table 1 (Level A criteria) with conformance levels and remarks
7. Complete Table 2 (Level AA criteria) with conformance levels and remarks
8. Complete Table 3 (Functional Performance Criteria) with conformance levels and remarks
9. Fill in the header: product name, version, report date, evaluation methodology, contact
10. Review for honesty and specificity before submission
11. Plan a remediation roadmap for any "Partially Supports" or "Does Not Support" findings
12. Update the ACR with each significant product release

Section 508 / WCAG 2.0 Keyboard Accessibility Analysis and Remediation Plan
Federal Internal Web Application — Keyboard Navigation Failures

===========================================================================
SECTION 1: VIOLATED WCAG 2.0 SUCCESS CRITERIA
===========================================================================

The issues described — focus disappearing during navigation and dropdown menus
that require a mouse — map to three specific WCAG 2.0 success criteria
incorporated into the Revised Section 508 Standards (36 CFR Part 1194, E205):

-----------------------------------------------------------------------
SC 2.1.1 Keyboard (Level A) — PRIMARY VIOLATION
-----------------------------------------------------------------------
Requirement: All functionality of the content is operable through a keyboard
interface without requiring specific timings for individual keystrokes, except
where the underlying function requires input that depends on the path of the
user's movement and not just the endpoints.

Violation: Dropdown menus that cannot be opened without a mouse are a direct
failure of SC 2.1.1. Every interactive function — including opening, navigating,
and selecting options from dropdown menus — must be fully operable via keyboard
(Tab, Enter, Space, Arrow keys). If any mouse-only interaction exists, the
application Does Not Support this criterion.

Applicable Section 508 provision: E205.4 (WCAG 2.0 Level A and AA)

-----------------------------------------------------------------------
SC 2.4.7 Focus Visible (Level AA) — SECONDARY VIOLATION
-----------------------------------------------------------------------
Requirement: Any keyboard operable user interface has a mode of operation where
the keyboard focus indicator is visible.

Violation: Users reporting that "focus disappears" describes a direct failure of
SC 2.4.7. When a user tabs through the application and cannot see which element
currently has focus, they are operating blind. Common causes include:
  - CSS rule: outline: none or outline: 0 applied to :focus selectors without
    a replacement focus indicator
  - Focus being moved programmatically to a non-visible element
  - Focus being set on a container element with no visible styling

Applicable Section 508 provision: E205.4 (WCAG 2.0 Level AA)

-----------------------------------------------------------------------
SC 2.1.2 No Keyboard Trap (Level A) — POTENTIALLY VIOLATED
-----------------------------------------------------------------------
Requirement: If keyboard focus can be moved to a component of the page using a
keyboard interface, then focus can be moved away from that component using only
a keyboard interface, and, if it requires more than unmodified arrow or tab keys,
the user is advised of the method for moving focus away.

Violation: The report of focus "disappearing" may indicate one of two conditions:
  (a) Focus is genuinely lost — moved to a non-focusable element or off-screen
      element — rather than trapped, which is a SC 2.4.7 failure; OR
  (b) Focus enters a component (e.g., a modal, custom widget, or dropdown) and
      cannot be moved out without a mouse, which is a SC 2.1.2 keyboard trap.

Both conditions should be tested. If a user can Tab into a dropdown or modal but
cannot Escape or Shift-Tab out, SC 2.1.2 is violated.

Applicable Section 508 provision: E205.4 (WCAG 2.0 Level A)

-----------------------------------------------------------------------
ADDITIONAL CRITERION TO VERIFY
-----------------------------------------------------------------------
SC 2.4.3 Focus Order (Level A): If the programmatic focus order does not match
the visual/logical order of the interface (e.g., focus jumps unexpectedly after
interacting with a dropdown), SC 2.4.3 may also be violated.

SC 4.1.2 Name, Role, Value (Level A): Custom dropdown widgets built from
non-semantic HTML elements (e.g., <div> or <span> used as menus) will have no
keyboard role by default and may fail SC 4.1.2 in addition to SC 2.1.1.

===========================================================================
SECTION 2: REMEDIATION PLAN
===========================================================================

The following phased plan addresses each violation with specific technical fixes,
responsible owners, effort estimates, and recommended timelines aligned with
federal remediation SLA guidance (Critical issues: 30 days; High: 60 days).

---------------------------------------------------------------------------
Phase 1 — Critical (Target: 30 days)
---------------------------------------------------------------------------

Issue 1: Dropdown menus not operable by keyboard
Criterion: SC 2.1.1 Keyboard (Level A) — Critical
Fix:
  Option A (Preferred): Replace custom dropdown widgets with native HTML
  <select> elements. Native controls are keyboard-accessible by default, require
  no additional scripting, and are supported by all assistive technologies.

  Option B (If custom UI required): Implement the ARIA Authoring Practices Guide
  (APG) Listbox or Disclosure Navigation patterns:
    - The trigger button must be a <button> element (or have role="button") so
      it receives focus and responds to Enter/Space.
    - Arrow keys (Up/Down) must move focus between menu items.
    - Escape must close the menu and return focus to the trigger button.
    - Home/End keys should optionally jump to first/last item.
    - Each menu item must have role="menuitem" (or "option" for listboxes) and
      tabindex="-1" so Arrow keys control focus within the widget.
  Reference: https://www.w3.org/WAI/ARIA/apg/patterns/

  NEVER use event listeners bound only to mousedown, mouseenter, or click
  without equivalent keyboard event handlers (keydown for Enter, Space, Arrows).

Owner: Front-end development team
Effort: Medium (2–5 days per widget type)
Timeline: 30 days

Issue 2: Keyboard trap in dropdown or modal components
Criterion: SC 2.1.2 No Keyboard Trap (Level A) — Critical
Fix:
  - Ensure Escape key closes any open dropdown, modal, or custom widget and
    returns focus to the element that triggered it.
  - Implement focus containment in modals (Tab and Shift-Tab should cycle only
    within the modal while it is open), and focus must be released when the
    modal closes.
  - Audit all third-party component libraries for keyboard trap issues; if a
    vendor component is the source, escalate to the vendor with reference to
    SC 2.1.2 and require a patch or replace the component.

Owner: Front-end development team
Effort: Low–Medium (1–3 days)
Timeline: 30 days

---------------------------------------------------------------------------
Phase 2 — High (Target: 60 days)
---------------------------------------------------------------------------

Issue 3: Disappearing focus indicator
Criterion: SC 2.4.7 Focus Visible (Level AA) — High
Fix:
  Step 1 — Audit CSS: Search the entire stylesheet for the following patterns
  and remove or replace every instance:
    *:focus { outline: none; }
    *:focus { outline: 0; }
    a:focus { outline: none; }
    button:focus { outline: none; }
  Use of outline: none without a replacement focus style is the single most
  common cause of this failure and is never acceptable.

  Step 2 — Implement a visible focus style: Apply a high-contrast focus
  indicator to all interactive elements. Recommended approach:
    :focus-visible {
      outline: 3px solid #005FCC;   /* high-contrast blue */
      outline-offset: 2px;
    }
  Alternatively, use a box-shadow focus ring. The indicator must be visible
  against both light and dark backgrounds used in the application.

  Step 3 — Verify programmatic focus: Search for JavaScript calls to
  element.focus() and confirm the target element is visible in the viewport
  and has a visible focus style. If focus is set on a <div> or <span>, ensure
  the element has tabindex="0" and an appropriate focus indicator.

  Step 4 — Do not suppress :focus styles for mouse users only without also
  providing them for keyboard users. The :focus-visible pseudo-class can be
  used to show focus rings only during keyboard navigation without affecting
  mouse interactions, but the keyboard indicator must always be present.

Owner: Front-end development team / UX/design team
Effort: Low (1–2 days for CSS audit and fix; additional time for design review)
Timeline: 60 days

Issue 4: Non-semantic custom widgets lacking keyboard roles
Criterion: SC 4.1.2 Name, Role, Value (Level A) — High
Fix:
  - Audit all custom interactive components (dropdowns, tabs, accordions,
    tooltips, date pickers) built from <div>, <span>, or <a> elements.
  - Add appropriate ARIA roles, states, and properties per the APG patterns.
  - Ensure every interactive element has an accessible name (aria-label,
    aria-labelledby, or visible text label).
  - Add tabindex="0" to any custom focusable element that is not a native
    interactive element.

Owner: Front-end development team
Effort: Medium (varies by number and complexity of components)
Timeline: 60 days

---------------------------------------------------------------------------
Phase 3 — Ongoing / Systemic (Target: 90 days and continuous)
---------------------------------------------------------------------------

Issue 5: Prevent recurrence — developer standards
Fix:
  - Establish a coding standard that mandates use of native semantic HTML
    elements for interactive controls wherever possible.
  - Add automated accessibility testing to the CI/CD pipeline using axe-core
    (axe-core npm package or axe DevTools) to catch regressions on every build.
    Note: automated tools catch ~30–40% of issues; manual testing is still
    required.
  - Require keyboard-only smoke testing as part of QA sign-off for every sprint
    that touches UI components.

Owner: Engineering lead, QA team, DevOps
Effort: Medium
Timeline: 90 days

===========================================================================
SECTION 3: TESTING APPROACH
===========================================================================

Before and after remediation, perform the following structured keyboard-only
test. Do NOT use a mouse at any point during this test.

-----------------------------------------------------------------------
Keyboard-Only Tab-Through Test Procedure
-----------------------------------------------------------------------

Tools needed: Any modern browser (Chrome or Firefox recommended); no mouse or
trackpad input during testing.

Step 1 — Establish baseline
  Load the application in the browser and note the starting focus position
  (or lack thereof). The browser tab itself may have initial focus; press Tab
  once to enter the page.

Step 2 — Tab through all interactive elements
  Press Tab repeatedly and verify:
  [ ] A visible focus indicator appears on each focusable element.
  [ ] Focus moves in a logical, top-to-bottom / left-to-right order matching
      the visual layout (SC 2.4.3 Focus Order).
  [ ] Focus never becomes invisible or moves to an element that cannot be seen
      or identified (SC 2.4.7 Focus Visible).
  [ ] Focus does not become trapped in any component — you can always Tab
      forward or Shift-Tab backward to exit (SC 2.1.2 No Keyboard Trap).

Step 3 — Operate all interactive controls by keyboard
  For each interactive element reached by Tab, test:
  [ ] Links: press Enter to activate.
  [ ] Buttons: press Enter or Space to activate.
  [ ] Dropdown menus: press Enter or Space to open; Arrow keys to navigate
      options; Enter to select; Escape to close without selecting.
  [ ] Checkboxes: press Space to toggle.
  [ ] Radio buttons: use Arrow keys within the group to change selection.
  [ ] Text fields: type to enter text.
  [ ] Modals/dialogs: verify Tab cycles within the modal; Escape closes it
      and returns focus to the trigger (SC 2.1.2, SC 2.4.3).
  [ ] Date pickers, sliders, tabs, accordions: follow APG keyboard patterns.

Step 4 — Document every failure
  For each failure, record:
  - Element type and location (page, section, element ID or description)
  - WCAG 2.0 success criterion violated
  - Screenshot or video capture showing the failure
  - Steps to reproduce

Step 5 — Supplement with automated scanning
  Run axe DevTools or WAVE on each page after manual testing to capture
  additional programmatic failures (missing labels, invalid ARIA, etc.).

Step 6 — Screen reader verification (after keyboard fixes are deployed)
  Confirm fixes with NVDA + Chrome and JAWS + Chrome to ensure ARIA roles
  and focus management work correctly with assistive technologies.

===========================================================================
SECTION 4: VPAT / ACR IMPACT
===========================================================================

The application's current Accessibility Conformance Report (ACR/VPAT) must
be updated to reflect:

  SC 2.1.1 Keyboard (Level A):       Does Not Support → (target) Supports
  SC 2.1.2 No Keyboard Trap (A):     Partially Supports or Does Not Support
                                       (confirm via testing) → Supports
  SC 2.4.7 Focus Visible (Level AA): Does Not Support → Supports

Until remediation is complete, the agency must document these failures in the
ACR and, per E205, provide an alternative means of access for users who cannot
operate the application with a mouse (e.g., an accessible alternative workflow,
a phone-based service, or an accessible offline process). Retain the written
determination and alternative access documentation for audit purposes.

===========================================================================
REFERENCES
===========================================================================

- 36 CFR Part 1194 — Revised Section 508 Standards (2018)
- WCAG 2.0, Guideline 2.1 (Keyboard Accessible): https://www.w3.org/TR/WCAG20/#keyboard-operation
- WCAG 2.0, SC 2.1.1: https://www.w3.org/TR/WCAG20/#keyboard-operation-keyboard-operable
- WCAG 2.0, SC 2.1.2: https://www.w3.org/TR/WCAG20/#keyboard-operation-trapping
- WCAG 2.0, SC 2.4.7: https://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-visible
- ARIA Authoring Practices Guide (APG): https://www.w3.org/WAI/ARIA/apg/
- ARIA APG Menu Button Pattern: https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/
- Section508.gov Testing Guide: https://www.section508.gov/test/
- axe-core: https://github.com/dequelabs/axe-core

Section 508 Keyboard Accessibility: Violated WCAG 2.0 Success Criteria and Remediation Plan
==============================================================================================

OVERVIEW
--------
Section 508 (revised 2018) incorporates WCAG 2.0 Level A and Level AA success criteria by reference.
The reported issues — disappearing focus and mouse-only dropdown menus — map to several specific
violations that must be addressed to achieve compliance.


VIOLATED WCAG 2.0 SUCCESS CRITERIA
------------------------------------

1. SC 2.1.1 Keyboard (Level A) — PRIMARY VIOLATION
   "All functionality of the content is operable through a keyboard interface without requiring
   specific timings for individual keystrokes."

   Applicability: Dropdown menus that cannot be opened or operated without a mouse directly violate
   this criterion. Every interactive element — menus, buttons, links, form controls, modal dialogs —
   must be fully operable via keyboard alone (Tab, Shift+Tab, Enter, Space, arrow keys as appropriate).

2. SC 2.4.7 Focus Visible (Level AA)
   "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator
   is visible."

   Applicability: When users report that "focus disappears," the application is hiding the browser's
   default focus ring, most commonly via CSS rules such as `outline: none` or `outline: 0` applied
   globally or to focused elements without providing an alternative visible indicator. This is a
   direct violation of 2.4.7.

3. SC 2.1.2 No Keyboard Trap (Level A)
   "If keyboard focus can be moved to a component of the page using a keyboard interface, then focus
   can be moved away from that component using only a keyboard interface, and if it requires more
   than unmodified arrow or tab keys to move focus away, the user is informed of the method."

   Applicability: When focus "disappears" it may indicate that focus is being sent to an element
   that cannot be reached again (a trap or dead-end). Dropdown menus implemented with custom
   JavaScript that intercept key events can inadvertently trap focus. This criterion is violated
   when a user cannot Tab or Shift+Tab away from an interactive component, or when focus is
   programmatically moved to a non-interactive element where it becomes stranded.

4. SC 2.4.3 Focus Order (Level A) — Secondary concern
   "If a Web page can be navigated sequentially and the navigation sequences affect meaning or
   operation, focusable components receive focus in an order that preserves meaning and operation."

   Applicability: Custom dropdown implementations often inject DOM elements dynamically, which can
   cause focus to jump to unexpected locations in the page, violating logical reading/navigation order.


CONCRETE REMEDIATION PLAN
--------------------------

PHASE 1 — AUDIT (Week 1-2)

   1. Keyboard-Only Tab-Through Test
      - Disconnect or disable the mouse entirely.
      - Starting from the top of each page, use the Tab key to cycle through all interactive
        elements and Shift+Tab to reverse.
      - Document every element that:
          a. Cannot receive focus at all.
          b. Receives focus but shows no visible indicator.
          c. Traps focus (cannot Tab away).
          d. Cannot be activated with Enter or Space.
      - Test all dropdown menus specifically: Tab to the trigger, press Enter/Space to open,
        use arrow keys to navigate options, press Escape to close.
      - Use browser DevTools to inspect computed CSS on focused elements, looking for
        `outline: none`, `outline: 0`, or `opacity: 0` on `:focus` pseudo-class rules.

   2. Automated Scan
      - Run axe-core, WAVE, or IBM Equal Access Checker against each page to flag missing
        focusable elements and absent focus styles. Note: automated tools catch ~30-40% of
        keyboard issues; manual testing is essential.

PHASE 2 — FIX FOCUS VISIBILITY (Week 2-3)

   1. Remove or override global `outline: none` rules.
      - Search codebase for: `outline: none`, `outline: 0`, `:focus { outline`.
      - Replace with a visible, high-contrast focus indicator, for example:
          :focus {
            outline: 3px solid #005FCC;
            outline-offset: 2px;
          }
      - If a custom focus style is desired for aesthetics, use `:focus-visible` to show the
        indicator for keyboard users while suppressing it for mouse clicks (with a fallback
        `:focus` rule for browsers that do not support `:focus-visible`).

   2. Ensure focus indicators meet contrast requirements (WCAG 1.4.11 Non-text Contrast,
      Level AA — 3:1 ratio minimum against adjacent colors).

PHASE 3 — FIX DROPDOWN KEYBOARD OPERABILITY (Week 3-5)

   Option A — Use Native HTML Controls (Preferred for simplicity)
      - Replace custom dropdown widgets with native `<select>`, `<button>`, or `<details>`/`<summary>`
        elements. Native HTML controls are keyboard-accessible by default and require no additional
        ARIA or JavaScript.

   Option B — Implement ARIA Keyboard Patterns (Required for custom widgets)
      - Follow the ARIA Authoring Practices Guide (APG) patterns for the specific widget type:
          * Navigation menus: use the "Disclosure Navigation Menu" or "Menu Button" pattern.
          * Dropdown/listbox: implement the "Combobox" or "Listbox" pattern.
      - Required keyboard behaviors for a menu button dropdown:
          * Tab: moves focus to the menu button trigger.
          * Enter or Space: opens the menu; focus moves to first menu item.
          * Arrow Down/Up: moves focus among menu items.
          * Escape: closes the menu; returns focus to the trigger button.
          * Tab (while menu is open): closes the menu; moves focus to next element in page.
      - Apply correct ARIA roles and states:
          * Trigger: `role="button"` (or use `<button>`), `aria-haspopup="true"`, `aria-expanded="false/true"`.
          * Menu container: `role="menu"`.
          * Menu items: `role="menuitem"`.
      - Manage focus programmatically with JavaScript (`element.focus()`) when menu opens and closes.

   Option C — Third-Party Accessible Component Libraries
      - Adopt a library with built-in accessibility support (e.g., Headless UI, Radix UI, Adobe
        React Aria, or Deque's cauldron) to replace custom implementations. These libraries
        implement ARIA patterns and keyboard handling correctly.

PHASE 4 — FIX KEYBOARD TRAPS (Week 3-4)

   1. Audit all modal dialogs, slide-out panels, and menus for focus containment logic.
   2. For modal dialogs: focus SHOULD be contained within the dialog while it is open (this is
      intentional and correct per the ARIA modal pattern). Ensure Tab cycles within the dialog
      and Escape closes it, returning focus to the trigger element.
   3. For non-modal components (dropdowns, tooltips): focus must NOT be trapped. Pressing Tab
      or Escape must always allow the user to leave the component.
   4. Use a focus-trap utility (e.g., focus-trap-js) for modals only; ensure it is not
      accidentally applied to non-modal elements.

PHASE 5 — REGRESSION TESTING AND VALIDATION (Week 5-6)

   1. Re-run the full keyboard-only tab-through test after fixes.
   2. Test with actual assistive technology:
      - NVDA + Chrome (Windows)
      - JAWS + Chrome or Edge (Windows)
      - VoiceOver + Safari (macOS/iOS)
   3. Conduct user testing with at least one keyboard-only user if possible.
   4. Run automated scans again to confirm no regressions.
   5. Document findings and remediation in a Voluntary Product Accessibility Template (VPAT)
      to track conformance.

PHASE 6 — PROCESS IMPROVEMENTS (Ongoing)

   1. Add keyboard accessibility checks to Definition of Done for all UI stories.
   2. Integrate axe-core or similar into CI/CD pipeline to catch regressions automatically.
   3. Establish a developer training module on ARIA patterns and keyboard navigation.
   4. Designate an accessibility SME or engage a third-party accessibility consultant for
      periodic audits.


SUMMARY TABLE OF VIOLATIONS AND FIXES
--------------------------------------

| Issue Reported               | WCAG 2.0 SC Violated         | Level | Primary Fix                                      |
|------------------------------|------------------------------|-------|--------------------------------------------------|
| Dropdowns require mouse      | 2.1.1 Keyboard               | A     | Native HTML or ARIA keyboard patterns            |
| Focus disappears             | 2.4.7 Focus Visible          | AA    | Remove outline:none; add visible :focus styles   |
| Focus stranded/lost          | 2.1.2 No Keyboard Trap       | A     | Fix JS event handlers; use focus management      |
| Focus jumps unexpectedly     | 2.4.3 Focus Order            | A     | Correct DOM order; manage focus programmatically |


REFERENCES
----------
- WCAG 2.0: https://www.w3.org/TR/WCAG20/
- ARIA Authoring Practices Guide: https://www.w3.org/WAI/ARIA/apg/
- Section 508 Standards: https://www.access-board.gov/ict/
- Revised 508 Standards Mapping to WCAG 2.0: https://www.access-board.gov/ict/wcag2ict.html

PDF Accessibility Remediation for Section 508 Compliance: Requirements and Process
====================================================================================

Your 200 PDF forms fall under Section 508 provision E205, which requires electronic documents to conform to WCAG 2.0 Level A and AA success criteria. For PDFs specifically, the governing standards are SC 1.3.1 (Info and Relationships), SC 4.1.2 (Name, Role, Value), SC 3.1.1 (Language of Page), SC 1.1.1 (Non-text Content), and SC 3.3.2 (Labels or Instructions), cross-referenced against PDF/UA (ISO 14289).

---

SPECIFIC PDF ACCESSIBILITY REQUIREMENTS
----------------------------------------

1. Tagged PDF with Correct Tag Hierarchy (SC 1.3.1, 4.1.2)

Every PDF must be a "Tagged PDF." Tags are hidden metadata that describe the document structure to screen readers. Without tags, a screen reader user experiences the PDF as a stream of unordered text or complete silence. The tag tree must follow a correct hierarchy:

  - Document (root tag)
    - H1, H2 ... H6 (headings in logical order)
    - P (paragraphs)
    - Table > TR > TH / TD (data tables with header associations)
    - L > LI > Lbl + LBody (lists)
    - Form (form containers)
    - Figure (images)
    - Link (hyperlinks)
    - Artifact (decorative content excluded from reading order)

Scanned image-based PDFs (PDF images of paper forms) cannot be made accessible by tagging alone — they require OCR to produce actual text, followed by full remediation.

2. Accessible Form Field Names (SC 4.1.2, 3.3.2)

Every interactive form field (text boxes, checkboxes, radio buttons, dropdowns, signature fields) must have an accessible name that is programmatically exposed to screen readers. In Adobe Acrobat Pro, this is set in the form field properties under the "General" tab — the "Tooltip" field is what JAWS, NVDA, and VoiceOver announce when a user moves focus to that field. A field labeled visually with nearby text but lacking a Tooltip value will be announced only by its internal field name (often a meaningless string like "Text1") or announced as "blank."

Steps in Acrobat Pro:
  - Open the Forms editor (Tools > Prepare Form)
  - Right-click each field > Properties > General tab
  - Enter a descriptive Tooltip (e.g., "First Name," "Date of Birth (MM/DD/YYYY)," "Applicant Signature")
  - For radio button groups, each button should have the Tooltip set to the group question (e.g., "Are you a U.S. citizen? Yes" / "Are you a U.S. citizen? No")

3. Alt Text for All Images (SC 1.1.1)

Every image in the PDF that conveys information must have Alt text set in the tag properties. Decorative images (dividers, background graphics) must be marked as Artifacts so screen readers skip them.

In Acrobat Pro:
  - Open the Tags panel
  - Locate each <Figure> tag
  - Right-click > Properties > Tag tab > enter Alt Text
  - For decorative images: right-click the tag > Change Tag to Artifact

Charts, graphs, logos with informational content, and signature line graphics all require meaningful Alt text descriptions.

4. Document Language Set in Document Properties (SC 3.1.1)

The default human language of the document must be programmatically declared so that screen readers apply the correct speech synthesis engine and pronunciation rules. A form with no language set will be read with the screen reader's default language, which may produce unintelligible output for non-English speakers or cause the wrong language engine to be applied even to English text.

In Acrobat Pro:
  - File > Properties > Advanced tab
  - Under "Reading Options," set the Language field to the appropriate IETF language tag (e.g., "en-US" for American English, "es" for Spanish)

5. Correct Reading Order (SC 1.3.2)

The order in which a screen reader reads content must match the logical visual order. Multi-column layouts, sidebars, and complex form layouts often produce incorrect reading order in tagged PDFs. Use Acrobat Pro's Reading Order tool (Tools > Accessibility > Reading Order) to inspect and correct the sequence. The Order panel shows the numerical reading sequence and allows drag-and-drop reordering.

6. Meaningful Hyperlink Text (SC 2.4.4)

All hyperlinks must have descriptive link text. A link tagged as "click here" or a raw URL ("https://www.agency.gov/very-long-path") fails SC 2.4.4. Update link display text in the tag properties or via the Link tool in Acrobat.

7. Table Header Associations (SC 1.3.1)

Data tables must use TH (table header) tags with a Scope attribute (Row or Column) or explicit ID/Headers associations. Layout tables used purely for visual positioning should be marked as Artifacts or have their table role removed.

8. Document Title Set (SC 2.4.2)

The document title — not the filename — must be set in Document Properties and configured to display as the window title. This allows screen reader users to identify the document.

In Acrobat Pro: File > Properties > Description tab > enter a meaningful Title, then in the Initial View tab set "Show" to "Document Title."

---

REMEDIATION PROCESS FOR 200 PDF FORMS
---------------------------------------

Given the volume, a phased triage-and-batch approach is recommended.

Phase 1 — Triage and Prioritization (Weeks 1–2)

Categorize all 200 forms by type:
  - Category A: Scanned image-only PDFs (require OCR + full rebuild — highest effort)
  - Category B: Digitally created PDFs with no tags (require tagging + form field remediation)
  - Category C: Tagged PDFs with incomplete or incorrect tags (require audit and repair)

Prioritize by public impact: forms used in high-volume public-facing transactions (applications, benefits, enrollment) should be addressed before internal administrative forms.

Run an automated pre-screening using Acrobat Pro's Full Accessibility Check (Tools > Accessibility > Full Check) on each PDF. Export results to identify the most common failure categories across your inventory. This surfaces patterns (e.g., all forms missing language, all forms have untagged images) that allow batch processing.

Phase 2 — Remediation (Weeks 3–12, scaled to staff/vendor capacity)

For each form:
  1. If scanned image-only: run OCR (Tools > Scan & OCR > Recognize Text), then proceed to tagging.
  2. Apply or correct the tag tree to establish correct Document > heading > paragraph > table > list hierarchy.
  3. Set reading order using the Reading Order tool and Order panel.
  4. Add Tooltip/accessible name to every form field via the Prepare Form editor.
  5. Add Alt text to all informational Figure tags; mark decorative images as Artifacts.
  6. Set document language in File > Properties > Advanced > Reading Options.
  7. Set document title in File > Properties > Description; configure Initial View to display title.
  8. Verify table header (TH) Scope attributes for all data tables.
  9. Update any non-descriptive hyperlink text.

For large batches of structurally similar forms, consider using the Acrobat Action Wizard to automate repetitive steps (adding language, title settings) across multiple files simultaneously.

Phase 3 — Verification and Testing (Concurrent with Phase 2)

After each form is remediated, run the Full Accessibility Check in Acrobat Pro (Tools > Accessibility > Full Check). This check tests against the PDF/UA standard and flags issues including: missing tags, missing Alt text, missing form field names, missing document language, incorrect reading order, and table structure problems. Review each flagged item and resolve before sign-off.

Supplement automated checking with manual screen reader testing using NVDA + Chrome (for PDF opened in browser) or JAWS + Adobe Acrobat Reader. Tab through all form fields and confirm each is announced with its correct Tooltip name. Navigate headings using the H key in NVDA/JAWS to verify heading hierarchy is correct.

Use the Acrobat Pro Tags panel and Order panel for visual inspection of tag structure and reading sequence.

Phase 4 — Quality Assurance and Publication (Ongoing)

Establish a sign-off checklist for each form before it is re-published:
  [ ] Tagged PDF confirmed (File > Properties > Description > "Tagged PDF: Yes")
  [ ] Full Accessibility Check passes with zero errors
  [ ] All form fields have Tooltip values confirmed via screen reader test
  [ ] Document language set (en-US or applicable language code)
  [ ] Document title set and displayed as window title
  [ ] Reading order verified manually
  [ ] At least one screen reader spot-check completed (NVDA or JAWS)

---

APPLICABLE WCAG 2.0 SUCCESS CRITERIA SUMMARY
----------------------------------------------

  SC 1.1.1 (Level A)    — Alt text for all informational images
  SC 1.3.1 (Level A)    — Tagged structure with correct hierarchy; table headers
  SC 1.3.2 (Level A)    — Logical reading order
  SC 2.4.2 (Level A)    — Document title set
  SC 2.4.4 (Level A)    — Descriptive hyperlink text
  SC 3.1.1 (Level A)    — Document language declared
  SC 3.3.2 (Level A)    — Labels or instructions for form fields (Tooltip/accessible name)
  SC 4.1.2 (Level A)    — Form fields expose name, role, value to assistive technology

All of the above are Level A requirements, meaning they are non-negotiable baseline requirements — no undue burden exception applies to Level A criteria unless the agency head makes a formal written determination and provides an alternative means of access.

---

TOOLING SUMMARY
----------------

  Adobe Acrobat Pro        — Primary remediation tool (tag editor, Reading Order tool, Prepare Form, Full Accessibility Check, Action Wizard for batch)
  NVDA (free) + Chrome     — Screen reader verification
  JAWS + Acrobat Reader    — Additional screen reader verification
  PAC 2024 (PDF Accessibility Checker) — Free standalone tool that validates PDF/UA conformance; useful as a second automated check alongside Acrobat's built-in checker

If your agency lacks Acrobat Pro licenses at scale, consider CommonLook PDF or Equidox as enterprise-grade PDF remediation platforms that integrate with Section 508 workflows and support batch processing with audit trails.

---

If you would like a phased remediation plan table with effort estimates by category, a procurement template for outsourcing this work to a 508 remediation vendor, or a form-by-form audit issue tracker template, I can provide those as well.

Section 508 PDF Accessibility: Requirements and Remediation Process
===================================================================

Section 508 of the Rehabilitation Act requires federal agencies to ensure their electronic and information technology, including PDF documents and forms, is accessible to people with disabilities. For PDFs, the relevant technical standard is WCAG 2.0 Level AA (incorporated by reference in the Revised 508 Standards) and PDF/UA (ISO 14289).

---

SPECIFIC REQUIREMENTS FOR PDF ACCESSIBILITY
--------------------------------------------

1. Tagged PDFs with Correct Tag Hierarchy
   PDFs must be "Tagged PDFs" — meaning they contain a hidden tag structure that screen readers use to interpret content order and meaning. The tag tree must follow a logical hierarchy:
   - <Document> as the root tag
   - Headings: <H1>, <H2>, <H3>, etc. used in proper nesting order
   - Paragraphs: <P> tags for body text
   - Tables: <Table>, <TR>, <TH>, <TD> tags with proper header associations
   - Lists: <L>, <LI>, <Lbl>, <LBody> tags
   - Figures/Images: <Figure> tags with Alt text
   - Form fields: <Form> tags
   Tags must reflect the logical reading order of the document.

2. Accessible Form Fields
   All interactive form fields must have accessible names so screen readers can announce the purpose of each field. In Adobe Acrobat Pro's form editor, this is set via the Tooltip field in each form field's properties dialog. The Tooltip becomes the accessible name read by assistive technology. Every text field, checkbox, radio button, dropdown, and button must have a descriptive, meaningful Tooltip/name.

3. Alternative Text for Images
   All meaningful images (figures, charts, logos, icons) must have alternative text (Alt text) set in the tag properties. In Acrobat Pro, this is done by opening the Tags panel, right-clicking the <Figure> tag, selecting "Properties," and entering descriptive Alt text. Decorative images should be marked as artifacts so screen readers skip them.

4. Document Language
   The primary language of the PDF must be specified in Document Properties. In Acrobat Pro: File > Properties > Advanced tab > Reading Options > Language. Setting the correct language (e.g., "EN-US") allows screen readers to use the correct pronunciation and speech engine.

5. Logical Reading Order
   The order of tags in the tag tree must match the intended reading order of the document. Use the Order panel or Tags panel in Acrobat Pro to verify and correct reading order.

6. Color and Contrast
   Text must meet minimum contrast ratios (4.5:1 for normal text, 3:1 for large text) per WCAG 2.1 SC 1.4.3. Information must not be conveyed by color alone.

7. Bookmarks
   PDFs with 21 or more pages must include bookmarks (an outline/navigation structure) to allow users to navigate without reading every page.

8. Document Title
   The document title must be set in Document Properties (File > Properties > Description tab > Title) and configured to display the title (rather than filename) in the title bar (Initial View tab > Show: Document Title).

9. No Inaccessible Security Settings
   Document security settings must not block screen reader access. Assistive technology access must be permitted.

10. Tables: Headers and Scope
    Data tables must use proper header cells (<TH>) with Scope attributes (Column, Row, Both) to associate headers with data cells.

---

REMEDIATION PROCESS FOR 200 PDF FORMS
---------------------------------------

Phase 1: Inventory and Prioritization
- Catalog all 200 forms with metadata (form name, size, complexity, usage frequency).
- Prioritize based on public usage volume — highest-traffic forms first.
- Identify whether source files (Word, InDesign, etc.) are available, as remediating from the source is faster than remediating the PDF directly.

Phase 2: Tooling Setup
Required tools:
- Adobe Acrobat Pro DC (or current version) — primary remediation tool
- PAC 3 or PAC 2024 (PDF Accessibility Checker) — free tool for PDF/UA validation
- NVDA (free) or JAWS screen reader — for manual testing
- Microsoft Word or InDesign — if regenerating from source

Phase 3: Automated Pre-Scan
- Run Adobe Acrobat Pro's Full Accessibility Check (Tools > Accessibility > Full Check) on each PDF to identify categories of failures.
- This check evaluates tagged structure, alt text, form field names, reading order, language, contrast, and more.
- Use results to estimate remediation effort per document and group similar issues for batch fixing.

Phase 4: Remediation (Per Document)
For each PDF form, perform the following steps:

Step 1 — Add/Repair Tags:
  - If the PDF has no tags: Use Acrobat's "Add Tags to Document" auto-tagger (Tools > Accessibility > Add Tags to Document), then manually correct the resulting tag tree.
  - Open the Tags panel to review the tag hierarchy.
  - Correct heading levels, ensure paragraphs use <P>, tables use full table markup.

Step 2 — Fix Reading Order:
  - Use the Reading Order tool or Order panel to verify content flows logically.
  - Reorder tags as needed by dragging in the Tags panel.

Step 3 — Set Alt Text on Images:
  - In the Tags panel, locate each <Figure> tag.
  - Right-click > Properties > Alternate Text field — enter descriptive alt text.
  - Mark purely decorative images as Artifacts (right-click > Change Tag to Artifact).

Step 4 — Remediate Form Fields:
  - Open the Forms editor (Tools > Prepare Form).
  - Double-click each form field to open its properties.
  - In the General tab, fill in the Tooltip field with a clear, descriptive label that matches the visible label on the form.
  - Ensure tab order (Tab Order in the Pages panel) follows a logical sequence.
  - Verify required fields are marked as required.

Step 5 — Set Document Language:
  - File > Properties > Advanced > Reading Options > Language — set to the appropriate language code (e.g., EN-US).

Step 6 — Set Document Title and Metadata:
  - File > Properties > Description — set Title, Author, Subject.
  - File > Properties > Initial View — set "Show" to "Document Title."

Step 7 — Add Bookmarks (if 21+ pages):
  - Use the Bookmarks panel to create a navigable outline matching the heading structure.

Step 8 — Fix Table Headers:
  - In the Tags panel, right-click <TH> cells > Properties > set Scope attribute.
  - Use the Table Editor (in the Reading Order tool) to assign header relationships.

Phase 5: Verification and Testing
- Run the Full Accessibility Check in Adobe Acrobat Pro (Tools > Accessibility > Full Check) — this must pass with zero errors for all accessibility categories.
- Validate against PDF/UA standard using PAC 3 or PAC 2024 (free tool from PDF Association).
- Perform manual testing with a screen reader (NVDA + Firefox or JAWS + Internet Explorer/Edge):
  - Navigate headings, form fields, tables, and images.
  - Confirm all form fields are announced with correct labels.
  - Confirm images are announced with appropriate alt text.
  - Confirm reading order is logical.
- Conduct testing with a user with a disability if possible.

Phase 6: Quality Assurance and Documentation
- Document the remediation performed on each form.
- Maintain a Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR) for each form if required.
- Establish a process so future forms are created accessibly from the start (accessible templates, author training).

Phase 7: Publication and Monitoring
- Replace inaccessible PDFs on the website with remediated versions.
- Set up periodic re-checks (e.g., annually) to ensure PDFs remain accessible as content is updated.
- Establish an accessibility feedback mechanism on the website so users can report barriers.

---

ESTIMATED EFFORT
----------------
- Simple text-heavy PDF (few images, no forms): 1-3 hours per document
- Complex form with many fields, tables, images: 4-8+ hours per document
- For 200 forms, consider engaging a Section 508 remediation vendor for volume efficiency.
- Some vendors offer batch remediation using automated tools supplemented by manual review.

---

KEY STANDARDS AND REFERENCES
------------------------------
- Revised Section 508 Standards (36 CFR Part 1194), effective January 18, 2018
- WCAG 2.0 Level AA (incorporated by reference in the Revised 508 Standards)
- PDF/UA (ISO 14289-1) — the international standard for accessible PDFs
- GSA's Section508.gov — provides guidance, training, and testing resources
- HHS Section 508 Program Office guidance on PDF accessibility

Section 508 Requirements for Case Management System Procurement

This guidance covers three areas: what to include in your RFP, how to evaluate VPAT responses, and what deficiencies to watch for.

---

PART 1: RFP REQUIREMENTS

Regulatory Mandate

Your RFP must include FAR Clause 52.239-2 (Access to Diagnostic and Therapeutic Equipment), which implements the Section 508 procurement requirements under FAR Subpart 39.2. This clause mandates that ICT delivered under the contract conform to the Revised Section 508 Standards (36 CFR Part 1194), effective January 18, 2018.

Core Provisions to Reference in the RFP

1. Applicable Technical Standards
   - E205 (Web / Software / Electronic Documents): WCAG 2.0 Level A and AA — this is the primary standard for a case management system's web-based or desktop software interface.
   - Chapter 3 (Functional Performance Criteria): Must support users without vision, without color perception, without hearing, without speech, with limited fine motor control, and with limited cognitive/language/learning abilities.
   - Chapter 5 (Software): Applies to native software components not covered by WCAG 2.0.
   - Chapter 6 (Support Documentation and Services): All user guides, help documentation, and support services must also be accessible.

2. Required Deliverables — VPAT / ACR
   Include the following language:
   "The vendor shall provide an Accessibility Conformance Report (ACR) using the VPAT 2.x (WCAG Edition) template, published by the Information Technology Industry Council (ITI), within 30 days of contract award. The ACR must correspond to the exact product version being delivered under this contract. An ACR for a different product version will not be accepted."

3. Testing Methodology Requirements
   Require vendors to document the methodology used to produce their VPAT, including:
   - Automated tools used (e.g., axe-core, WAVE, Lighthouse)
   - Screen readers tested (e.g., JAWS + Chrome, NVDA + Firefox, VoiceOver + Safari)
   - Manual testing performed (keyboard-only navigation, color contrast verification, zoom to 200%)
   - Dates of testing and versions of assistive technologies used

4. Assistive Technology Compatibility
   Specify the assistive technologies the system must support consistent with your agency's environment, at minimum:
   - JAWS (current and prior major version) with Google Chrome
   - NVDA with Mozilla Firefox
   - Windows Magnifier and/or ZoomText
   - Dragon NaturallySpeaking (speech input)
   - Microsoft Narrator (where applicable)

5. Remediation SLAs (Post-Award)
   Include enforceable remediation timelines in the contract. Recommended SLAs by severity:
   - Critical (keyboard trap, complete screen reader blockage, login inaccessible): 30 calendar days
   - High (major workflows inaccessible, missing alt text on functional images, form fields unlabeled): 60 calendar days
   - Moderate (partial support failures, inconsistent navigation, contrast failures): 90 calendar days
   - Low (minor informational issues, low-impact WCAG AA gaps): 180 calendar days

   These SLAs should run from the date of written notice from the Contracting Officer's Representative (COR) or agency accessibility team.

6. Ongoing ACR Refresh
   Require the vendor to provide an updated ACR with each major product release or significant update during the contract period of performance.

7. Undue Burden Provisions
   If the vendor claims undue burden for any provision, require:
   - Written justification referencing the specific Section 508 provision at issue
   - Proposed alternative means of access for affected users
   - Agency COR review and acceptance before any exception is granted

---

PART 2: EVALUATING VENDOR VPAT RESPONSES

Step 1 — Verify Template Version
Confirm the vendor used the VPAT 2.x (WCAG Edition) template. Older templates (VPAT 1.x) do not map to the Revised 508 Standards and are not acceptable. The VPAT 2.x WCAG Edition includes tables for WCAG 2.x Level A and AA success criteria, Functional Performance Criteria, and Chapter 5/6 provisions. If the submitted ACR uses any other template format, reject it and request a conforming document.

Step 2 — Verify Product Version Match
Confirm that the product name and version documented in the ACR match exactly the version being delivered. A VPAT for version 4.1 is not valid evidence for version 5.0. Require the vendor to certify in writing that the ACR covers the procured version.

Step 3 — Evaluate Completeness
Every WCAG 2.0 Level A and Level AA success criterion must have an entry. For each criterion, look for:
- A conformance level: Supports, Partially Supports, Does Not Support, or Not Applicable
- Substantive remarks — not just a repeated conformance level
   - "Supports" entries must explain HOW the product meets the criterion
   - "Partially Supports" entries must identify WHICH scenarios succeed and which fail
   - "Does Not Support" entries must describe the nature of the failure
   - "Not Applicable" entries must justify why the criterion does not apply

Step 4 — Assess Testing Methodology
The ACR should include a methodology section. Red flags:
- No testing methodology disclosed
- Only automated scanning listed (automated tools catch only 30-40% of issues)
- No screen reader testing documented
- Testing performed on a different version than the one being procured

Step 5 — Score Weighted Criteria
Weight your evaluation toward criteria most critical for a case management system:
- 2.1.1 Keyboard (A): Full keyboard operability — critical for screen reader and motor-impaired users
- 4.1.2 Name, Role, Value (A): Programmatic names for all UI components — essential for JAWS/NVDA compatibility
- 1.3.1 Info and Relationships (A): Form field labels, table structure, heading hierarchy
- 3.3.1 Error Identification (A) and 3.3.2 Labels or Instructions (A): Error handling in data entry workflows
- 1.4.3 Contrast Minimum (AA): Text contrast at 4.5:1 ratio
- 2.4.7 Focus Visible (AA): Visible keyboard focus indicator throughout

Step 6 — Request a Demonstration
For top-ranked vendors, require a live accessibility demonstration with an agency assistive technology user or certified accessibility tester. VPAT claims should be verifiable against the live product.

---

PART 3: COMMON VPAT DEFICIENCIES TO WATCH FOR

1. Outdated VPAT Template
The vendor submits a VPAT 1.x document or a proprietary format rather than the ITI VPAT 2.x (WCAG Edition). These templates do not cover all Revised 508 Standards criteria and cannot serve as valid ACRs under the current regulatory framework.

2. Unsupported "Supports" Claims Without Evidence
The vendor marks criteria as "Supports" with no explanatory remarks — or with boilerplate text like "Our product fully supports all WCAG criteria." Without specific, verifiable evidence of how conformance is achieved, these claims have no probative value. Each "Supports" entry must include substantive explanation.

3. Overuse of "Not Applicable"
Vendors frequently mark criteria as "Not Applicable" to avoid disclosing failures. For a case management system, very few WCAG 2.0 AA criteria are genuinely not applicable. Be especially skeptical of "Not Applicable" for: 1.3.1 (Info and Relationships), 2.1.1 (Keyboard), 3.3.1 (Error Identification), and 4.1.2 (Name, Role, Value). Require justification for every "Not Applicable" entry.

4. Missing or Vague Testing Methodology
The ACR omits the testing methodology section, lists only automated scanning, or fails to name specific assistive technologies and versions. Automated tools alone are insufficient. A credible VPAT must reference manual keyboard testing, named screen readers (JAWS, NVDA, VoiceOver), contrast analysis tools, and zoom testing.

5. Version Mismatch
The ACR covers a prior product version, a demo environment, or a "similar" product rather than the exact version being procured. Conformance data from a different version is not valid evidence of the procured version's conformance. This is one of the most common — and consequential — deficiencies in federal procurements.

6. Blanket "Partially Supports" Without Scope
The vendor marks a criterion as "Partially Supports" without describing which components or workflows partially conform and which do not. A conforming ACR must scope the partial support — for example: "SC 2.1.1: The main navigation and search functions support keyboard operation. The bulk-upload module does not currently support keyboard-only operation."

7. No Functional Performance Criteria Coverage
Chapter 3 (Functional Performance Criteria) is omitted entirely or marked "Not Applicable" without justification. These criteria ensure usability for users across all disability categories and must be addressed for any ICT that does not fully satisfy the technical standards.

8. No Chapter 6 (Support Documentation) Coverage
Vendors frequently omit coverage of user guides, help content, training materials, and support services. All documentation delivered under the contract must also meet accessibility requirements under Chapter 6 / E205.

---

SUMMARY CHECKLIST FOR PROCUREMENT OFFICERS

RFP Must Include:
[ ] FAR Clause 52.239-2 (FAR Subpart 39.2)
[ ] Reference to 36 CFR Part 1194 and applicable provisions (E205, Chapter 3, Chapter 5, Chapter 6)
[ ] Requirement for VPAT 2.x (WCAG Edition) matching the exact procured version
[ ] Documented testing methodology requirement
[ ] Specified assistive technology compatibility requirements
[ ] Remediation SLAs by severity (Critical: 30 days, High: 60 days, Moderate: 90 days)
[ ] Updated ACR requirement with each major release

VPAT Evaluation — Watch For:
[ ] Wrong template version (VPAT 1.x or proprietary format)
[ ] Unsupported "Supports" claims (no explanatory remarks)
[ ] Excessive "Not Applicable" without justification
[ ] Missing testing methodology or automated-only testing
[ ] Version mismatch between ACR and procured product
[ ] Vague "Partially Supports" without scope description
[ ] Missing Chapter 3 (Functional Performance) or Chapter 6 (Support Documentation) coverage

Section 508 Requirements for Case Management System Procurement: RFP Language, VPAT Evaluation, and Common Deficiencies
==========================================================================================================================

1. LEGAL BASIS AND PROCUREMENT MANDATE
---------------------------------------

All federal IT procurements must comply with Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. § 794d), and the Access Board's revised standards published at 36 CFR Part 1194 (effective January 18, 2018). On the acquisition side, the primary regulatory hook is FAR Subpart 39.2 — Information and Communication Technology, which implements Section 508 requirements in federal contracting. Specifically, FAR clause 52.239-2 (Access to Nonpublic Information) and the broader requirements of FAR 39.203 mandate that agencies must include Section 508 standards in solicitations and contracts for ICT supplies and services.

Your RFP should cite 36 CFR Part 1194 directly, reference the applicable Technical Standards (typically WCAG 2.1 Level AA for web-based case management software under Chapter 5 of the Revised 508 Standards), and incorporate FAR Subpart 39.2 as the procurement authority. The contracting officer should coordinate with the agency's Section 508 Program Manager to ensure the correct standards apply.

2. WHAT TO INCLUDE IN YOUR RFP
--------------------------------

A. Mandatory 508 Conformance Statement
Include a statement requiring vendors to demonstrate how their proposed solution meets or exceeds the applicable Section 508 Technical Standards, specifically:
  - Chapter 5 (Software) — for application functionality
  - Chapter 6 (Support Documentation and Services) — for user guides, help content, and training materials
  - WCAG 2.1 Level AA — for any web-based components (via Chapter 7 / E205)

B. VPAT Requirement
Require vendors to submit a completed Voluntary Product Accessibility Template (VPAT), version 2.x — specifically the WCAG Edition or INT (International) Edition, not older pre-2017 templates. The VPAT 2.x (published by the Information Technology Industry Council, ITI) maps to the Revised 508 Standards and WCAG 2.1. Older VPAT formats based on the original 1194.21/1194.22 standards are not acceptable for procurements under the Revised 508 Standards.

The VPAT must:
  - Reflect the exact product name, version number, and release date being proposed
  - Be completed no more than 12–18 months prior to submission (or updated to match the proposed version)
  - Include the name, title, and contact information of the evaluator
  - Describe the evaluation methodology used (e.g., automated testing tools, manual testing, assistive technology combinations)

C. Testing Methodology Disclosure
Require vendors to describe how they tested their product:
  - Which automated tools were used (e.g., axe, WAVE, Deque tools)
  - Which assistive technologies were tested (e.g., JAWS, NVDA, VoiceOver, Dragon NaturallySpeaking)
  - Whether testing was conducted by an independent third party or internally
  - The scope of testing (all modules, specific workflows, representative sample)

D. Remediation SLAs
The RFP should specify, and the resulting contract must include, remediation service level agreements (SLAs) for accessibility defects discovered post-award:
  - Critical barriers (completely blocks access for users with disabilities): remediation within 30 days of written notice
  - Significant deficiencies (substantially impairs access): remediation within 60–90 days
  - Moderate issues (workarounds exist but accessibility is degraded): remediation within 180 days or within the next scheduled release cycle
  - SLAs should be tied to contract performance metrics and, where appropriate, financial penalties or cure notices

E. Ongoing Conformance
Include requirements for:
  - Updated VPATs with each major release or version update
  - Notification to the contracting officer within 30 days of any accessibility regression introduced in a new release
  - Access to the vendor's accessibility roadmap and bug tracking process

F. Market Research and Exceptions
Document that you conducted pre-solicitation accessibility market research. If no fully conformant solution exists, the agency may need to invoke an exception under 36 CFR 1194.3 (e.g., undue burden or fundamental alteration), which requires written documentation approved by the agency head.

3. HOW TO EVALUATE VENDOR VPAT RESPONSES
------------------------------------------

A. Verify Version and Template Currency
Check that the submitted VPAT uses version 2.x (the current ITI template). Look for the version notation in the document header. Reject or flag submissions using the legacy VPAT 1.x format, which does not map to the Revised 508 Standards.

B. Match VPAT to Proposed Product Version
Confirm that the VPAT explicitly identifies the product version that matches the version the vendor is offering. A VPAT for version 3.1 is not valid for a proposal offering version 4.0. This is a frequent and significant discrepancy.

C. Review Conformance Level Entries
For each criterion, vendors may claim: Supports, Partially Supports, Does Not Support, or Not Applicable. Evaluate each entry:
  - "Supports" claims must be accompanied by meaningful remarks explaining how the feature works accessibly. Bare "Supports" with no remarks is a red flag.
  - "Partially Supports" entries should describe specifically what works and what does not, and ideally identify a remediation timeline.
  - "Not Applicable" claims require justification. Overuse of "Not Applicable" — particularly for common criteria like keyboard access (2.1.1), focus order (2.4.3), or color contrast (1.4.3) — is a significant deficiency.
  - "Does Not Support" entries should be understood as known accessibility barriers.

D. Assess Testing Methodology Quality
A credible VPAT will describe:
  - Specific assistive technologies and browser combinations tested
  - Whether an independent accessibility auditor was involved
  - The date of testing relative to the proposed product version
VPATs with vague methodology sections (e.g., "tested internally") with no specifics warrant skepticism.

E. Score or Weight the VPAT in Evaluation Criteria
Consider including accessibility conformance as a rated technical factor in the source selection, not merely a pass/fail checkbox. Agencies with strong 508 programs may weight third-party-validated VPATs higher than self-attested ones.

F. Request a Demonstration
For critical workflows (e.g., case intake, search, document management), request a live accessibility demonstration using JAWS or NVDA as part of the technical evaluation. This can surface gaps not reflected in the VPAT.

4. MOST COMMON VPAT DEFICIENCIES TO WATCH FOR
------------------------------------------------

1. Outdated Template Version
   The vendor submits a VPAT using the pre-2017 format (VPAT 1.x), which references the original 1194.21 (desktop software) and 1194.22 (web) standards rather than the Revised 508 Standards. This template is not aligned with WCAG 2.1 Level AA and should be rejected.

2. Product Version Mismatch
   The VPAT covers a different version than what is being proposed. For example, the VPAT was written for version 2.5 but the vendor is offering version 3.0, which may have undergone significant UI changes. Always require the VPAT to match the exact proposed version.

3. Unsupported "Supports" Claims Without Evidence
   A vendor marks dozens of success criteria as "Supports" but provides no remarks, no description of implementation, and no testing evidence. This is the most common and most misleading deficiency. A credible VPAT explains how conformance is achieved for non-trivial criteria.

4. Overuse or Misuse of "Not Applicable"
   Vendors mark critical accessibility criteria as "Not Applicable" without legitimate justification. Common examples: marking keyboard accessibility (SC 2.1.1) as N/A for a web application, or marking color contrast (SC 1.4.3) as N/A. These criteria apply to virtually all software products.

5. Missing or Vague Testing Methodology
   The VPAT does not describe how the product was tested — no mention of assistive technologies, browsers, testing tools, or whether the evaluation was conducted by a qualified accessibility professional. Without this, the VPAT cannot be verified or trusted.

6. Stale VPAT — Not Updated for Recent Releases
   The product has had multiple releases since the VPAT was written, but the vendor resubmits an unchanged document. New features, redesigns, or UI framework changes can introduce new barriers not reflected in an old VPAT.

7. Incomplete Coverage of Product Modules
   The VPAT covers only the main dashboard or homepage, while ignoring complex workflows like case creation, document upload, search results, data entry forms, or reporting modules — which are often the least accessible parts of case management systems.

8. No Remarks for "Partially Supports" Entries
   Vendors acknowledge partial conformance but provide no detail about what works, what does not, and what the remediation plan is. This provides insufficient information for the agency to assess risk.

9. No Contact Information for the Evaluator
   The VPAT lacks the name, title, organization, and contact information of the person or firm that conducted the evaluation, making it impossible to follow up with questions.

5. SUMMARY CHECKLIST FOR YOUR RFP
-----------------------------------

[ ] Cite FAR Subpart 39.2 and incorporate FAR 39.203 requirements
[ ] Reference 36 CFR Part 1194 (Revised 508 Standards)
[ ] Require VPAT 2.x (WCAG Edition or INT Edition) — reject VPAT 1.x
[ ] Require VPAT to match the exact product version being procured
[ ] Require disclosure of testing methodology and assistive technologies used
[ ] Include remediation SLAs: critical (30 days), significant (60-90 days), moderate (180 days)
[ ] Require updated VPATs with each major version release post-award
[ ] Consider weighted evaluation factor for accessibility in source selection
[ ] Reserve right to conduct independent accessibility testing as part of evaluation
[ ] Document market research on accessible alternatives per FAR 39.203(c)

---
Prepared: 2026-05-16
Scope: Federal Agency Procurement Advisory — Section 508 / ICT Accessibility

SECTION 508 UNDUE BURDEN EXCEPTION: LEGAL BASIS, PROCESS, AND ALTERNATIVE ACCESS REQUIREMENTS
================================================================================================

Your situation — a legacy grants management system requiring $3.5M in remediation against a constrained IT budget — is precisely the scenario the undue burden exception was designed to address. Here is a complete analysis.

---

1. LEGAL BASIS
--------------

The undue burden exception is grounded in two authorities:

  a) 29 U.S.C. § 794d — Section 508 of the Rehabilitation Act of 1973, as amended, which establishes the accessibility mandate for federal ICT and expressly authorizes agencies to claim an exception when compliance would impose an undue burden.

  b) E202.5 of the Revised Section 508 Standards (36 CFR Part 1194) — the operative regulatory provision. E202.5 states that agencies are not required to conform to the Standards where doing so would impose an "undue burden" on the agency, defined as a significant difficulty or expense.

Additionally, the legacy ICT exception under E202.7 of 36 CFR Part 1194 may independently apply to ICT that was acquired or deployed before January 18, 2018 (the effective date of the Revised Standards) and has not been altered. However, the undue burden exception provides the stronger, more thoroughly documented path for systems that are still actively in use and maintained.

---

2. DEFINITION AND FACTORS: WHAT "UNDUE BURDEN" MEANS
------------------------------------------------------

Under E202.5, "undue burden" means significant difficulty or expense. This is not an absolute dollar threshold — it is a proportionality analysis. The Revised Standards require agencies to consider all of the following factors when making the determination:

  - The nature and cost of the action needed to achieve compliance
  - The overall financial resources of the agency or component involved
  - The number of employees at the agency or component
  - The type of operations of the agency or component
  - The impact of the action on the operations of the agency or component
  - The agency's total IT budget (not just the budget of a single program or office)

For your situation, relevant evidence to document would include:
  - The $3.5M remediation estimate (with vendor quotes or independent cost analysis)
  - Your total agency IT budget for the fiscal year
  - The ratio of remediation cost to overall IT budget (if $3.5M equals or exceeds total IT budget, this is strong evidence)
  - Whether the remediation cost would crowd out other mission-critical IT obligations
  - The age and technology stack of the 15-year-old system
  - Any scheduled replacement or modernization timeline

---

3. REQUIRED PROCESS: WRITTEN DETERMINATION
-------------------------------------------

E202.5 imposes mandatory procedural requirements. An agency cannot simply decide internally that compliance is too expensive — the exception requires formal documentation. The specific steps are:

  Step 1 — Document the ICT at issue
    Identify the specific system (grants management system), its functions, the user population, and the specific Section 508 provisions that cannot be met.

  Step 2 — Calculate the cost of full compliance
    Obtain formal vendor quotes or independent cost estimates. The $3.5M figure must be documented and defensible, not a rough estimate. Break down by remediation activity (e.g., front-end UI remediation, back-end accessibility, document remediation, testing).

  Step 3 — Assess agency resources
    Document your agency's total financial resources: IT budget, overall appropriations, and any competing capital obligations. Show the proportionality analysis.

  Step 4 — Obtain a signed written determination from the agency head (or properly delegated official)
    This is a hard requirement under E202.5. The determination must be:
      - In writing
      - Signed by the agency head or an official to whom the agency head has formally delegated this authority (typically the CIO or Deputy Administrator)
      - Specific to the ICT in question — a blanket agency-wide determination is not sufficient
      - Based on the documented factors above

  Step 5 — Retain documentation
    The written determination and supporting evidence must be retained and made available for audit by oversight bodies (e.g., OMB, GAO, agency Inspector General, or in the event of a complaint to the Access Board or DOJ).

  Step 6 — Re-evaluate when the ICT is altered or replaced
    The exception is not permanent. Under E202.5, the undue burden determination must be re-evaluated whenever the ICT is substantially altered or replaced. If your agency undertakes a modernization effort, the exception lapses and the new or altered system must achieve full 508 conformance.

---

4. ALTERNATIVE MEANS OF ACCESS — THIS IS NOT A FULL EXEMPTION
--------------------------------------------------------------

This is the most critical point: claiming an undue burden exception does NOT exempt your agency from all accessibility obligations. E202.5 explicitly requires that the agency still provide an alternative means of access to the information or functionality for individuals with disabilities.

The alternative means of access must be:
  - Genuinely equivalent in the information or service it provides — it cannot be a lesser or degraded substitute
  - Available without unreasonable delay (comparable to the time a non-disabled user can access the system)
  - Provided at no additional cost to the user with a disability
  - Documented and publicized so that users with disabilities know how to access it

Common acceptable alternatives for a grants management system may include:
  - A staffed accessible helpline (phone or video relay) where agency personnel complete transactions on behalf of the user
  - A fully accessible PDF or HTML alternative format for grant applications and status reporting
  - A dedicated accessibility contact (email/phone) with a documented service-level response commitment
  - In-person assistance at an accessible agency office

The alternative means must not simply tell users to "call us" without ensuring the person answering can actually complete the full transaction.

---

5. RE-EVALUATION OBLIGATION WHEN ICT IS ALTERED OR REPLACED
------------------------------------------------------------

Under E202.5 of 36 CFR Part 1194, the undue burden determination is tied to the current state of the ICT. If your agency:
  - Undertakes any substantial alteration of the grants management system (new modules, UI redesign, platform migration, API integration)
  - Replaces the system entirely through a modernization or re-procurement effort

...the exception must be re-evaluated. Any alteration that is within scope of the agency's resources must be made accessible at the time of that alteration, even if full system remediation remains an undue burden. In practice, this means your next procurement or upgrade project must include 508 conformance requirements from day one, and FAR clause 52.239-2 (for contract-based systems) must be applied.

---

6. STRATEGIC RECOMMENDATIONS
-----------------------------

Given your circumstances, here is a practical path forward:

  a) Pursue a partial remediation strategy alongside the undue burden claim. Even if full remediation is an undue burden, the agency should remediate the highest-impact barriers (e.g., keyboard accessibility, screen reader compatibility for core grant application workflows) with whatever resources are available. This demonstrates good faith and reduces legal risk.

  b) Document the system replacement timeline. If a system modernization is already planned (even in a 3–5 year horizon), include that timeline in the written determination and ensure the replacement procurement requires full 508 conformance from the outset via the VPAT/ACR requirement and FAR 52.239-2.

  c) Contact the U.S. Access Board. The Access Board provides free technical assistance (508@access-board.gov) and can advise on the adequacy of your written determination and alternative access plan before you finalize them.

  d) Review E202.7 (Legacy ICT exception). If the system was deployed before January 18, 2018 and has not been substantially altered, you may have an independent exemption under E202.7. Consult your agency counsel on whether this applies and whether it is simpler to document than a full undue burden analysis.

  e) Brief your agency's Section 508 Program Manager, General Counsel, CIO, and (if required) your IG on the determination before it is signed, to ensure it will withstand audit scrutiny.

---

SUMMARY TABLE
-------------

| Element                        | Requirement                                                      |
|-------------------------------|------------------------------------------------------------------|
| Legal authority                | 29 U.S.C. § 794d; E202.5 of 36 CFR Part 1194                   |
| Standard                       | "Significant difficulty or expense" — proportionality analysis  |
| Key factors                    | Cost of compliance, agency size, total financial resources       |
| Written determination required | Yes — signed by agency head or delegated official               |
| Full exemption from 508?       | No — alternative means of access must still be provided         |
| Re-evaluation trigger          | Any alteration or replacement of the ICT                        |
| Documentation retention        | Required — must be audit-ready                                   |

---

Cite these provisions in your written determination:
  - 29 U.S.C. § 794d(a)(1)(B) — undue burden authorization
  - 36 CFR § 1194, E202.5 — Revised Standards undue burden provision
  - 36 CFR § 1194, E202.7 — Legacy ICT exception (if applicable)

SECTION 508 UNDUE BURDEN EXCEPTION: GUIDANCE FOR FEDERAL AGENCIES

QUESTION: Can a small federal agency claim an undue burden exception for a legacy grants management system with $3.5M remediation costs that exceed the entire IT budget?

SHORT ANSWER: Yes, an undue burden exception may be available, but it is not a full exemption from accessibility obligations. The agency must follow a specific process, document the determination formally, and still provide alternative means of access to people with disabilities.

---

1. LEGAL BASIS

The undue burden exception for federal agencies is grounded in two primary authorities:

a) Section 508 of the Rehabilitation Act of 1973, as amended — codified at 29 U.S.C. § 794d. This statute requires federal agencies to ensure that electronic and information technology (EIT) developed, procured, maintained, or used by the federal government is accessible to people with disabilities, but it includes provisions for exceptions where compliance would impose an undue burden.

b) E202.5 of the Revised Section 508 Standards (36 CFR Part 1194), published by the U.S. Access Board (effective January 18, 2018). This provision explicitly establishes the Undue Burden Exception, stating that an agency is not required to comply with Section 508 requirements where doing so would impose an "undue burden" on the agency. This is the operative regulatory provision governing the process and scope of the exception.

---

2. WHAT "UNDUE BURDEN" MEANS AND THE FACTORS CONSIDERED

Under E202.5 and the broader framework of Section 508, "undue burden" is defined as significant difficulty or expense. This is not a bright-line financial threshold — it is a fact-specific determination that must weigh multiple factors, including:

- The overall financial resources of the agency as a whole (not just the component or program office managing the system)
- The size of the agency, including number of employees
- The nature and cost of the specific accessibility compliance measures required
- The impact of the compliance cost relative to the agency's total IT budget and annual appropriations
- Whether alternative approaches exist that would reduce cost while still improving accessibility
- The type of operation of the agency and the financial impact on the agency's overall program

In your scenario, the $3.5M remediation cost relative to an entire IT budget is a strong factual predicate for an undue burden finding — but it must be documented and assessed against all available resources, not just the immediate IT budget line.

---

3. REQUIRED PROCESS: WRITTEN DETERMINATION BY AGENCY HEAD

The undue burden exception is NOT self-executing. Agencies cannot simply decide internally that compliance is too expensive and move on. The Revised Section 508 Standards require a formal process:

Step 1 — Document the Finding: The agency must prepare a written determination that explains the basis for the undue burden claim. This documentation must include:
  - A description of the ICT (Information and Communications Technology) at issue (the legacy grants management system)
  - The specific accessibility requirements that cannot be met
  - A detailed analysis of the costs of compliance (the $3.5M remediation estimate)
  - An analysis of the agency's available resources and why compliance would impose significant difficulty or expense
  - A description of the alternative means of access that will be provided

Step 2 — Signed by Agency Head or Designee: The written determination must be signed by the agency head or a duly authorized official to whom the agency head has formally delegated this authority. This cannot be a line manager or program officer decision alone — it requires senior leadership accountability.

Step 3 — Maintain the Documentation: The agency must retain this documentation and make it available as needed (e.g., for audits, congressional oversight, or complaints filed with oversight bodies).

Step 4 — Periodic Re-evaluation: The undue burden determination is not permanent. It must be revisited and re-evaluated when circumstances change — specifically, if the ICT is subsequently altered, upgraded, or replaced, the agency must reassess whether full compliance is now achievable.

---

4. ALTERNATIVE MEANS OF ACCESS IS STILL REQUIRED

This is a critical point: the undue burden exception does NOT excuse the agency from all accessibility obligations. Even where a valid undue burden determination is made, the agency must still provide an alternative means of access to the information or functionality for individuals with disabilities.

This means the agency must:
- Identify what the grants management system does and what outputs/functions people with disabilities need
- Provide a functionally equivalent alternative pathway — this could include:
  * Accessible document versions of key data outputs
  * A staffed help desk or point of contact who can assist users with disabilities in accessing grants information
  * Accessible alternative formats (e.g., accessible PDFs, data exports in accessible formats)
  * Phone-based or in-person assistance to complete grant-related tasks
- Document what alternative means of access will be provided in the written undue burden determination

The alternative access must be genuinely usable and not impose unreasonable burdens on the individual with a disability. Providing a phone number that goes unanswered, for example, would not satisfy this requirement.

---

5. RE-EVALUATION WHEN ICT IS ALTERED OR REPLACED

The undue burden exception is tied to the current state of the ICT and the agency's current resources. If the grants management system is:
- Significantly altered or upgraded
- Replaced with a new system
- Subject to a new procurement or modernization initiative

...then the agency must re-evaluate whether the undue burden exception still applies or whether the new system must be made fully Section 508 compliant from the outset. In practice, a modernization or re-procurement is an opportunity — and likely an obligation — to build in full accessibility compliance, since new systems do not inherit the undue burden exception of their predecessors.

---

6. PRACTICAL RECOMMENDATIONS

Given the scenario described:

a) Engage your agency's Section 508 Coordinator immediately — every federal agency is required to have one.

b) Commission a phased remediation analysis — the $3.5M figure may assume full immediate remediation; a phased approach over multiple budget cycles may reduce the annual burden and make compliance more achievable.

c) Consult with the agency's General Counsel before finalizing the undue burden determination — the written determination must withstand legal scrutiny.

d) Notify the Access Board and OMB if required — some agencies are required to report accessibility exceptions through established reporting mechanisms.

e) Document the alternative means of access in detail, and test it with actual users with disabilities where possible.

f) Include Section 508 compliance requirements in any future modernization planning or budget requests to ensure successor systems are fully compliant.

---

SUMMARY TABLE

| Element                     | Requirement                                                  |
|-----------------------------|--------------------------------------------------------------|
| Legal authority             | 29 U.S.C. § 794d; E202.5, 36 CFR Part 1194                  |
| Standard                    | "Significant difficulty or expense"                          |
| Factors                     | Agency resources, size, cost vs. budget, nature of operation |
| Documentation               | Written determination required                               |
| Who signs                   | Agency head or formally delegated official                   |
| Full exemption?             | NO — alternative access must still be provided               |
| Duration                    | Must be re-evaluated if ICT is altered or replaced           |

---

This guidance is based on the Revised Section 508 Standards (2018) and the underlying statute. Agencies should consult legal counsel and their Section 508 Coordinator for agency-specific implementation guidance.