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.

Short answer: nothing changes for your specific package on September 30, 2026 in terms of a hard rejection — but the date matters a lot, and you need to understand exactly why.

Under CR26 (the FedRAMP Consolidated Rules for 2026), a machine-readable mandate (RFC-0024/NOTICE-0009) takes effect at 2PM ET on September 30, 2026, but it applies specifically to two triggers:

1. NEW Rev5 initial-certification packages — packages that are submitted for the first time — must be machine-readable with no grace period, starting at that moment. This explicitly includes packages that are already "In Process" for agency authorization as of that date. If your Moderate authorization is a new/first-time initial certification package and it is still in process on September 30, 2026, it falls into this bucket and will need to be machine-readable (OSCAL or another FedRAMP-approved standardized format) from that point forward — Word/Excel alone will no longer satisfy the intake requirement for that package.

2. Existing Rev5-certified providers (i.e., CSPs that already hold an authorization) are NOT required to convert immediately. Instead, they must submit a full machine-readable package at their next annual assessment completed after September 30, 2026.

The distinction that matters for you is whether your Moderate authorization is best characterized as a "new initial-certification package" (even though it's mid-process) versus an "existing certified provider" going through routine ConMon/annual assessment. Based on your description — "mid-process on a Rev5 Moderate agency authorization" — this sounds like an initial authorization effort, not an existing authorized system's annual assessment cycle. If that's correct, you fall under the no-grace-period rule (LMR-GEN-ICR): your package, even though already in process, must become machine-readable at the September 30, 2026 cutoff. There is no allowance for "we started before the deadline."

Practical implications:
- Approved formats are NIST OSCAL or any public-domain standardized format that 5+ certified CSPs agree to maintain and that FedRAMP has validated. OSCAL is the safe, de facto default.
- CR26 JSON schemas and a validator have been published — use them now to start converting your SSP, SAP/SAR inputs, POA&M, and CIS/CRM content into structured, machine-readable form rather than waiting.
- You still need to be able to produce human-readable renditions on request (for 3PAO reviewers, agency AOs, or auditors who prefer PDF/Word views) — machine-readable is the authoritative format, not the only format.
- Non-compliance consequence: public notification of non-compliance until 2PM ET September 30, 2027, followed by certification revocation if not remedied. That's a serious downstream risk if you slip past the cutoff without a compliant package.

What I'd recommend doing this week:
1. Confirm with your 3PAO and the FedRAMP PMO whether your package is being treated as "new initial certification, in process" (subject to the no-grace-period rule) or something else — get this in writing.
2. Start OSCAL conversion now for the SSP, POA&M, and CIS/CRM — these are the highest-effort artifacts to convert and the ones most likely to slip.
3. Validate against the published CR26 JSON schemas and the FedRAMP validator before September 30.
4. Keep Word/Excel versions as your working drafts if that's easier for your authors, but plan the final submission format as OSCAL, not Office documents.
5. Loop in your agency AO now — a mid-process package hitting this deadline is exactly the scenario that causes last-minute scrambles; give them visibility early.

One caveat: FedRAMP 20x, if you were on that pathway instead, is explicitly exempt from this specific mandate (it has its own machine-readable model), but since you describe a traditional Rev5 agency authorization, that carve-out doesn't apply to you. Use official fedramp.gov guidance and your 3PAO's read on your specific package status to confirm before the cutoff — this is a fast-moving regulatory area and the PMO may issue package-specific guidance.

Short answer: I can't point you to an official FedRAMP calendar entry for "September 30, 2026" with full confidence — dates like this move as PMO guidance evolves, and you should verify against the current FedRAMP.gov roadmap and any direct communication from your agency AO and the FedRAMP PMO before treating it as a hard deadline. That said, here is the context a GRC consultant would bring to this question and how to plan around it regardless of the exact date.

Background: FedRAMP has been pushing, for several years, toward machine-readable authorization packages built on OSCAL (Open Security Controls Assessment Language) rather than the traditional Word/Excel SSP, SAP, SAR, and POA&M templates. The PMO has repeatedly signaled that Word/Excel-based submissions are a transitional format and that OSCAL-native (JSON/XML/YAML) packages are the long-term requirement, first for new authorizations and eventually across the board, including for agencies operating the FedRAMP Rev5 baseline. Dates announced for "final" cutovers to OSCAL-only submission have shifted more than once as the PMO calibrated for 3PAO and CSP tooling readiness, so if you've seen September 30, 2026 cited, it's most likely tied to one of these transition milestones (e.g., a deadline for new packages, or for existing packages to convert at their next significant change request or annual assessment).

What this likely means for you if the date is real and applies to your effort:
1. New submissions after that date may be required to be in OSCAL format, meaning your reviewing agency and/or the FedRAMP PMO (if you're going through JAB or seeking a P-ATO) may reject or delay processing of a purely Word/Excel package.
2. If you are mid-process — meaning you already have documents in flight with your agency reviewer — you should immediately ask your agency ISSO/AO point of contact and your 3PAO whether your existing package is grandfathered, whether you need to convert before final authorization, or whether the deadline only affects new starts.
3. Even if there's a grace period, agencies are increasingly asking for OSCAL exports as a courtesy or requirement earlier than mandated, because it feeds their own GRC tooling (e.g., emass, Xacta) more efficiently.

What I'd recommend doing regardless of the exact date:
1. Get your OSCAL conversion plan started now. Converting a mature Word/Excel SSP and control implementation narrative into valid OSCAL is not trivial — it requires mapping every control implementation statement, parameter, and responsibility split (CSP vs. inherited vs. customer) into structured, machine-parseable format. Start this in parallel with your existing authorization work rather than waiting for a deadline to force it.
2. Talk to your 3PAO now about their OSCAL tooling maturity — many 3PAOs are still building capability here, and if yours isn't ready, that becomes your critical path.
3. Ask your agency sponsor directly what format they will accept for the SAR, SSP, and POA&M at each remaining review gate. Some agencies have been pragmatic and accepted Word/Excel through completion of the current authorization cycle, with an OSCAL conversion required only at the next annual assessment or significant change.
4. Watch for official FedRAMP PMO announcements — these come via FedRAMP.gov blog posts, the FedRAMP Rev5 transition guidance, and (more recently) the FedRAMP 20x initiative materials, which are explicitly trying to make machine-readable, API-first submission the default going forward.
5. Budget schedule and cost contingency: OSCAL conversion for a Moderate package with dozens of controls and hundreds of parameters is a real effort — plan for weeks, not days, especially if your control narratives are inconsistent or if inheritance from your IaaS provider isn't cleanly documented.

Bottom line: treat any specific date you've heard as provisional until confirmed directly with the FedRAMP PMO or your agency AO, but don't wait for confirmation to start your OSCAL readiness work — the direction of travel is unambiguous, and being caught flat-footed on format at the finish line of a Moderate authorization would be a costly, avoidable delay.

For an existing Rev5 FedRAMP Moderate certified provider (i.e., you already hold authorization and are in steady-state continuous monitoring, not pursuing a brand-new initial certification), the machine-readable mandate does not hit you on September 30, 2026 itself. That date and time (2PM ET, September 30, 2026) is when the "no grace period" rule kicks in for NEW Rev5 initial-certification packages [LMR-GEN-ICR] — including ones already in process. That is a different trigger than yours.

As an existing, already-certified provider, the applicable rule is [LMR-GEN-OAR]: you must submit a full machine-readable package at each annual assessment completed after September 30, 2026. In plain terms:

- Identify your next annual assessment completion date on the calendar (this is your 3PAO-led annual security assessment, tied to your ConMon cycle, not just a POA&M update).
- If that annual assessment is completed before September 30, 2026, you can submit it in your current format (Word/Excel or whatever you use today) — the mandate doesn't reach back to catch it.
- If your annual assessment is completed on or after September 30, 2026, that specific assessment cycle's package must be fully machine-readable. This is not just the new/changed findings — it's described as a "full machine-readable package," so treat it as your SSP, POA&M, CIS/CRM, and related artifacts all needing to exist in structured format at that point, not just a delta submission.

So the precise answer to "when exactly" is: at your next annual assessment that completes on or after September 30, 2026 — not a fixed calendar date that applies uniformly to all existing providers. Two Moderate CSPs with different annual assessment schedules will hit this requirement at different times depending on when their assessment cycle lands relative to the cutoff.

What to do now, regardless of exactly where your annual assessment falls:
1. Pin down your annual assessment completion date precisely with your 3PAO and ISSO — "roughly Q4" isn't precise enough given a hard cutoff.
2. If your assessment date is close to September 30, 2026 (within a couple months either side), treat this as high risk of ambiguity — confirm with your AO/PMO point of contact how "completed" is being interpreted (submission date vs. AO acceptance date vs. 3PAO sign-off date), since that interpretation determines which side of the line you land on.
3. Start OSCAL conversion work now regardless of your exact date. Converting an SSP, POA&M, and CIS/CRM workbook into OSCAL is not a last-month task — treat it as a project with its own timeline, ideally starting 6+ months ahead of your annual assessment.
4. Use the published CR26 JSON schemas and FedRAMP validator to check your converted artifacts before submission; don't wait for the 3PAO to catch format issues.
5. Maintain human-readable renditions in parallel — these are still required "on request" even once you're machine-readable-primary, so don't throw away your Word/Excel authoring workflow entirely; you may need to keep generating readable exports for agency AOs who still prefer them.
6. If you miss the mandate for your qualifying annual assessment, know the consequence structure: public non-compliance notification runs until 2PM ET September 30, 2027, after which certification revocation follows if you're still non-compliant. That's a full year of runway to fix a miss, but don't treat it as slack — reputational exposure during the notification period is itself a real cost with agency customers.

Bottom line: your compliance deadline is defined relative to your own annual assessment cycle, not a single fixed date. Get precise about when that assessment "completes" under the PMO's definition, and start your OSCAL conversion work well ahead of that date rather than waiting for September 30, 2026 as if it were your deadline — it isn't, unless your annual assessment happens to land on or after it.

I want to be upfront: I do not have a verified, current citation for an exact "must be machine-readable by [date]" mandate specifically applicable to already-authorized Rev5 Moderate providers, and any specific date I gave you here could be stale or wrong given how much this area has been in flux. Please confirm the authoritative date directly on FedRAMP.gov (the Rev5 transition page and OSCAL/automation announcements) or through your agency AO and PMO liaison before committing budget or engineering time to a hard deadline. With that caveat, here's the substantive guidance a consultant should give you.

Context: FedRAMP's multi-year push toward automation has had two parallel threads. First, the "machine-readable" requirement historically refers to producing your authorization artifacts (SSP, SAP, SAR, POA&M, and the control implementation summary/CIS) in OSCAL format instead of, or in addition to, Word and Excel. Second, more recently, FedRAMP 20x has introduced a broader push toward continuous, API-driven validation of security posture rather than periodic point-in-time documentation review — this is a related but distinct initiative from the OSCAL mandate and has its own track record of pilot phases with a limited cohort of CSPs before wider rollout.

For an existing, already-authorized Rev5 Moderate CSP, the practical trigger points for "when must we convert" tend to be:
1. Annual Assessment (Annual Security Assessment Report cycle) — many agencies and the PMO have signaled this is the natural checkpoint to require OSCAL-formatted deliverables, since you're already refreshing your SAR and POA&M at that time.
2. Significant Change Request (SCR) — if you're filing an SCR for a major architecture change, that's another natural forcing function where reviewers may ask for OSCAL artifacts as part of re-review.
3. Continuous monitoring (ConMon) deliverables — monthly/quarterly ConMon packages (vulnerability scan summaries, POA&M updates) are increasingly expected to be submitted in structured, ingestible formats compatible with agency GRC platforms.
4. A hard PMO-wide cutover date — the PMO has discussed sunset dates for pure Word/Excel acceptance, but historically these dates have been pushed back as tooling and 3PAO readiness lagged. Treat any specific calendar date circulating in your organization as provisional.

What I'd tell a client in your position:
- Don't wait for a hard deadline to become non-negotiable to start. OSCAL conversion of a mature, already-authorized package is a substantial lift: every control implementation statement, responsibility (CSP/inherited/shared/customer), parameter value, and POA&M entry needs to be represented in structured schema-valid form. This is easier to do incrementally (e.g., alongside your next annual assessment) than as a scramble against a deadline.
- Engage your 3PAO early — ask what OSCAL tooling and validation capability they have today, since some 3PAOs are more mature here than others, and their capability constrains your timeline as much as yours does.
- Ask your agency ISSO/AO directly whether they have communicated an internal target date for accepting only machine-readable submissions from you specifically — agency-level implementation of PMO guidance varies, and your actual deadline may be driven more by your sponsoring agency's own modernization timeline than by a PMO-wide date.
- Keep an eye on FedRAMP 20x announcements even though it's a separate track — the PMO's overall strategic direction (fewer point-in-time documents, more continuous machine-validated evidence) will likely eventually fold Rev5 ConMon and reauthorization into a similar automated model, so investments in OSCAL tooling now are not wasted even if timelines shift.
- Budget for a parallel run: many CSPs maintain Word/Excel and OSCAL versions simultaneously during transition to avoid disrupting active agency relationships while building automation muscle.

Bottom line: there is a real, PMO-driven direction toward mandatory machine-readable packages for existing Rev5 CSPs, tied most concretely to your next annual assessment or significant change request cycle rather than a single universal calendar date — confirm the specific date with FedRAMP PMO/your AO, and start the conversion work now rather than treating this as a future problem.

Under CR26 (the FedRAMP Consolidated Rules for 2026), FedRAMP has restructured its baseline labeling scheme around four Certification Classes, A through D, replacing the old FIPS 199-based Low/Moderate/High/LI-SaaS labels. The class labels change naming, not the underlying control requirements — a Class C system still maps to what used to be the Moderate baseline's requirements (NIST SP 800-53 Rev 5, 323 controls/enhancements), for example.

The four classes, per notice NTC-0004:

- Class A (Pilot/Transitional): A new baseline introduced specifically under FedRAMP 20x. It's an entry point into the federal market via external frameworks — initially SOC 2 Type II — routed through something called Program Certification. Class A has no legacy equivalent; it didn't exist before CR26. Holders get a 2-year window during which they must obtain a full Class B, C, or D certification through complete assessment — Class A is explicitly transitional, not a permanent end-state.
- Class B: Replaces the old LI-SaaS and Low baselines combined. Covers systems handling non-sensitive federal information where a breach would cause limited harm.
- Class C: Replaces the old Moderate baseline. This is the most common class — the majority of federal cloud deployments, including systems handling CUI (Controlled Unclassified Information), fall here.
- Class D: Replaces the old High baseline. Reserved for federal information where compromise would have severe or catastrophic effects — law enforcement, financial, and health data are typical examples.

Legacy-to-class mapping for translating older documents or conversations: LI-SaaS/Low → Class B, Moderate → Class C, High → Class D. Class A is genuinely new and doesn't correspond to any prior baseline. During the CR26 transition period, old and new labels remain linked so CSPs already authorized under legacy labels retain their authorization status without needing to immediately relabel.

Pipeline status as of mid-September 2026 (today is September 14, 2026):

- Class A: Open since August 3, 2026. This pipeline has been accepting applications for about six weeks at this point.
- Classes B and C: Open since August 31, 2026 — roughly two weeks old as of today. If you're pursuing either of these, you're in the very early wave of applicants under the new structure.
- Class D: Not yet open for general applications. A pilot is expected in late 2026, with a formal, non-pilot option anticipated in early 2027. If you need a High-equivalent authorization today, you are likely still working through the legacy Rev5 Agency Authorization path rather than a Class D pipeline, since Class D isn't operationally available yet.

Other relevant timing context that affects how you should think about these pipelines right now:
- CR26 itself was finalized June 25, 2026, with optional early adoption from July 4, 2026, and becomes mandatory January 1, 2027. So we're currently in the voluntary adoption window — you can choose CR26/20x pathways now, but the legacy Rev5 process is still fully valid until the mandatory date.
- FedRAMP 20x is now positioned as the primary, preferred authorization pathway going forward, built on Key Security Indicators (KSIs), machine-readable evidence, and modular API-driven submissions rather than the traditional static SSP/SAP/SAR document set.
- Legacy FedRAMP Ready was retired (relabeled "Legacy FedRAMP Ready") on July 28, 2026 — no new Ready submissions are being accepted. If you hold Rev5 Ready status, you need to convert by the later of your annual-assessment expiration or November 17, 2026, since the status disappears completely by December 31, 2027.
- JAB P-ATO is fully suspended — the FedRAMP PMO is now the sole authorizing body across all pathways.

Practical takeaway: if you're evaluating which class to pursue, ask what data sensitivity you handle (maps to B/C/D) and whether you're trying to get a foothold via an existing SOC 2 Type II (maps to Class A as a transitional strategy). Given Class D isn't open yet, a High-impact system today still needs the legacy Rev5 High agency-authorization route. Confirm current pipeline status directly with the FedRAMP PMO or fedramp.gov before committing, since this is an actively evolving rollout.

Caveat up front: my knowledge of FedRAMP 20x is grounded in its early framing (roughly through late 2025), and I do not have verified, up-to-the-day visibility into "where the pipelines stand as of mid-September 2026." Treat the status portion of this answer as directional context to sanity-check against the current FedRAMP.gov 20x page, PMO announcements, and any direct conversations with the FedRAMP PMO or GSA — not as a confirmed status report.

What FedRAMP 20x is, conceptually: It's the FedRAMP PMO's initiative to fundamentally modernize how cloud services get authorized, moving away from the traditional multi-hundred-page SSP/SAP/SAR/POA&M document cycle with lengthy 3PAO assessments and toward a faster, more automated, continuously validated model. The stated goals include: dramatically reducing time-to-authorization (from many months to weeks), relying on machine-readable evidence (OSCAL, automated key security indicators/KSIs) rather than narrative documents, and enabling continuous validation rather than periodic point-in-time assessment.

On "certification classes" — FedRAMP 20x has been organized around a small number of pilot phases/cohorts rather than a fixed, published taxonomy of permanent "classes" in the way Low/Moderate/High impact levels are a fixed taxonomy under Rev5. As of my knowledge, the structure has looked roughly like this:
- Phase One (Low Impact SaaS pilot): The PMO ran an initial pilot focused on Low-impact SaaS offerings, using a streamlined set of Key Security Indicators (KSIs) instead of the full control catalog narrative, with a small cohort of participating CSPs providing real-world feedback.
- Phase Two / Moderate expansion: The intent was to extend the 20x approach to Moderate impact SaaS and eventually broader IaaS/PaaS offerings, again through cohort-based pilots rather than a general open enrollment, with lessons from Phase One feeding into the KSI catalog and automation tooling.
- Ongoing refinement: KSIs, automated validation ("continuous assessment"), and the underlying technical architecture (APIs for evidence submission, OSCAL-native artifacts) were expected to mature through iterative pilot rounds, with the PMO explicitly stating this was experimental and subject to change based on pilot results, rather than a finished, generally available program.

Because this was explicitly a rolling pilot program rather than a fixed set of "classes" with permanent definitions, I would not assume any specific class names or numbers I might guess at (e.g., "Class A/B/C") are accurate without checking the current FedRAMP 20x page — the PMO has used evolving terminology (KSIs, phases, cohorts) rather than a stable classification scheme, and by September 2026 this may have been reorganized, renamed, or formalized into something closer to an official framework alongside or replacing Rev5.

What I'd recommend to assess "where the pipelines stand" today:
1. Check FedRAMP.gov directly for the 20x program page, which typically lists active pilot cohorts, participating CSPs, and phase status.
2. Look for PMO blog posts or GSA press releases from 2026 summarizing pilot results — these usually disclose how many CSPs completed a given phase, common KSI validation gaps found, and next-phase timing.
3. Ask your 3PAO — 3PAOs participating in 20x pilots are a good source of ground-truth on how mature the automated assessment tooling actually is versus how it's being marketed.
4. Watch for signals about whether 20x is on track to formally supersede parts of Rev5 for specific impact levels/service models, or whether it remains a parallel, optional track for CSPs willing to be early adopters.
5. If you're making a go/no-go decision on participating, ask GSA directly about cohort application windows, since pilot participation has historically been limited and by invitation/application rather than open enrollment.

Bottom line: FedRAMP 20x is a genuine, PMO-driven modernization effort built on KSIs, automation, and phased/cohort-based pilots rather than a settled certification taxonomy — but the specific "classes" and pipeline status as of mid-September 2026 need to be verified against current FedRAMP PMO sources, since this program was explicitly evolving in real time even as of my training data.

For a new cloud SaaS targeting federal customers in late 2026, my recommendation is: default to pursuing FedRAMP 20x / CR26 Certification Classes rather than a legacy Rev5 agency authorization package, but the right answer depends on a few specifics I'd want to confirm with you first.

Why 20x/CR26 is the better starting point for a new entrant right now:

1. It's now the primary, preferred pathway. Under CR26 (finalized June 25, 2026, mandatory January 1, 2027), FedRAMP 20x is explicitly positioned as the go-forward authorization model — continuous authorization built on Key Security Indicators (KSIs), machine-readable evidence, and modular API-driven submissions, rather than the traditional static SSP/SAP/SAR document set. A brand-new CSO built today has no legacy investment in the old SSP/POA&M Word-template process, so there's little reason to start there when the newer model is what FedRAMP wants everyone to move toward anyway.

2. There's a real, currently-open pipeline for a new entrant. Certification Class A opened August 3, 2026 — it's specifically designed as an entry point into the federal market via an existing external framework (initially SOC 2 Type II) through Program Certification. If you already have, or can obtain, a SOC 2 Type II, Class A gives you a comparatively fast on-ramp. Classes B and C opened August 31, 2026, so as of "late 2026" both pipelines are live and accepting new applicants. As a new SaaS company, Class A → then B/C within your 2-year transition window is a plausible, sequenced strategy.

3. Legacy Rev5 is entering wind-down. New Rev5 applications stop being accepted after June 11, 2027, and Rev5 fully sunsets December 31, 2028. Legacy FedRAMP Ready — historically a common way for a new CSP to signal readiness to agency sponsors — was already retired (relabeled Legacy FedRAMP Ready) on July 28, 2026, with no new submissions accepted. Starting a brand-new Rev5 legacy package now means investing in a track that has a visible expiration and reduced sponsor interest, plus you'd need an agency sponsor for the legacy Agency Authorization path, which is often the hardest part for a new, unproven vendor.

4. Machine-readable requirements favor 20x-native tooling anyway. The OSCAL/machine-readable mandate that hits Rev5 packages hard (no grace period for new Rev5 initial certifications from September 30, 2026) explicitly does NOT apply to FedRAMP 20x, which has its own machine-readable model built in from the start. Building your compliance program around 20x-native, API-driven evidence from day one avoids retrofitting OSCAL conversion into a legacy document set later.

Where I'd still want more information before finalizing this recommendation:
- What's your target Certification Class based on the sensitivity of federal data you'll handle? If you're aiming for anything High-equivalent (Class D), that pipeline isn't open yet — pilot expected late 2026, formal option early 2027 — so a High-impact new SaaS may have no choice but to work the legacy Rev5 High agency-authorization path in parallel while waiting for Class D to mature.
- Do you have an agency sponsor lined up, or are you relying on marketplace/self-driven entry? Class A's SOC 2-based entry doesn't require a sponsoring agency the way legacy Agency Authorization does, which is often a major advantage for a new vendor without existing federal relationships.
- Do you already have or can you quickly obtain a SOC 2 Type II? If not, factor in the time to get one before Class A becomes practically available to you.
- What's your actual timeline to first federal revenue? Since CR26 becomes mandatory January 1, 2027 anyway, even a legacy Rev5 start today would likely need to transition to CR26 classes relatively soon, so there's limited benefit to starting legacy unless you have a specific sponsor already committed to the old process.

Bottom line: for most new SaaS entrants in late 2026, start with FedRAMP 20x, targeting Class A (if you have or can get SOC 2 Type II) as a bridge to Class B or C within the 2-year window, rather than initiating a new legacy Rev5 package. Reserve the legacy Rev5 path for cases where you need a High-equivalent authorization immediately and can't wait for Class D to open, or where you already have a specific agency sponsor insisting on the traditional process. Confirm current pipeline status and eligibility criteria directly with FedRAMP PMO/fedramp.gov before committing significant budget, since class definitions and pipeline timing are still evolving through the CR26 rollout.

Short answer: for most new SaaS companies targeting federal customers in late 2026, I'd lean toward pursuing Rev5 through the traditional sponsorship path (agency or JAB/FedRAMP PMO) as your primary, de-risked route, while evaluating FedRAMP 20x opportunistically if you qualify for and can get into an active pilot cohort — but this depends heavily on your risk tolerance, timeline, target agency, and impact level. Note also that my visibility into the exact state of 20x as of late 2026 is limited (see caveats below), so validate this against current FedRAMP PMO guidance before finalizing your strategy.

Key considerations:

1. Certainty and maturity of the path. Rev5 is the established, well-understood process: a defined control baseline (NIST SP 800-53 Rev5), known documentation requirements (SSP, SAP, SAR, POA&M), known 3PAO assessment process, and known timelines (typically 12-18+ months for agency authorization, often longer for JAB). Every agency ATO officer, every 3PAO, and most GRC tooling vendors know how to work within this framework. FedRAMP 20x, by contrast, has been a pilot program with limited cohorts, evolving requirements (Key Security Indicators, automated continuous validation), and no guarantee that agencies broadly recognize or will accept a 20x-based authorization the same way they accept a Rev5 P-ATO or agency ATO today. For a new company that needs revenue certainty and predictable time-to-market, betting the whole go-to-market plan on an unproven, still-evolving pilot track carries real execution risk.

2. Impact level and service model fit. If you are a Low-impact SaaS offering, 20x's pilot programs have specifically targeted that segment, so if you qualify, can get into a cohort, and your target agency is comfortable with a 20x-based package, it may genuinely be faster and cheaper than a full Rev5 Low authorization. If you're Moderate impact (which covers a large share of commercial SaaS handling federal data) or if you're IaaS/PaaS rather than SaaS, the 20x pipeline has been less mature for your category as of my knowledge, making Rev5 the more realistic near-term path regardless of ambition.

3. Your specific agency sponsor's posture. If you already have a specific agency champion who wants to sponsor you, ask them directly which path they're comfortable authorizing under. Many agency ISSOs and AOs are still most comfortable with Rev5 packages because that's what their internal risk acceptance processes, GRC tools, and legal reviews are built around. An agency sponsor's willingness (or lack of it) to accept a 20x-based authorization should be a primary input to your decision, more than the PMO's marketing of 20x's speed advantages.

4. Timeline reality check. FedRAMP authorization of any kind is rarely fast for a brand-new company, especially one without existing FISMA or FedRAMP-adjacent experience. Whichever path you choose, budget 12+ months minimum, factor in 3PAO selection and contracting lead time (often 2-3 months just to onboard a 3PAO), and expect that your engineering and security teams will need meaningful investment in continuous monitoring capability regardless of framework.

5. Hedge your bet where possible. Some CSPs have pursued Rev5 as their primary authorization path while simultaneously engaging with FedRAMP 20x pilots for a subset of low-risk offerings or as an early-adopter learning exercise, positioning themselves to move faster into 20x-native processes once those mature and gain broader agency acceptance. If your company has the resources, this dual-track approach reduces the risk of picking the "wrong" long-term horse without sacrificing near-term revenue-enabling authorization.

Recommendation: Start conversations now, in parallel:
- With FedRAMP PMO/GSA about current 20x cohort eligibility and timelines for your impact level and service model.
- With your target agency sponsor about which path they're prepared to authorize under, since agency acceptance is the actual gating factor regardless of PMO marketing.
- With 3PAOs about capacity and cost for either path, since 3PAO availability is often the real bottleneck.

Default to Rev5 as the resourced, funded, primary plan unless you get concrete signals — from both GSA and your agency sponsor — that a 20x path is open, appropriate for your impact level, and will be accepted as a valid authorization by the agencies you're actually trying to sell to. Don't let program novelty or marketing momentum around 20x cause you to under-resource the proven path.

FedRAMP POA&M remediation and continuous monitoring (ConMon) work together as a single ongoing risk-management cycle once you're authorized. Here's how it fits together.

POA&M basics
The Plan of Action & Milestones (SSP Appendix O) is the living document that tracks every known security weakness — from initial 3PAO assessment findings, annual assessment findings, or vulnerability scans — and your plan to fix each one. It's not a one-time deliverable; it's updated monthly for the life of your authorization.

Each POA&M row needs, at minimum: a unique item ID, the affected NIST 800-53 Rev 5 control(s), a weakness name and description, point of contact, resources required, remediation plan, original detection date, scheduled completion date, milestone change history, status (Open/Closed/Risk Adjusted/Vendor Dependency), risk rating, and flags for false positive / deviation approval / operational requirement. One finding per row — don't bundle multiple vulnerabilities together, since that obscures tracking and remediation evidence.

Remediation SLAs (from the FedRAMP Continuous Monitoring Performance Management Guide)
- Critical (where scanners distinguish it from High): treat as ≤30 calendar days, prioritized immediately — effectively High-or-stricter.
- High: 30 calendar days from identification.
- Moderate: 90 calendar days from identification.
- Low: 180 calendar days from identification.

These clocks start at identification, not at when you get around to triaging the finding, so timely intake and risk-rating of new findings matters as much as the fix itself. Missing these SLAs is one of the most common ConMon findings agencies flag, so track dates carefully and don't let milestone dates slip without documented, approved changes.

Three ways an item can resolve besides a straight fix:
1. Vendor Dependency (VD): the fix depends on a third party (OS vendor, SaaS tool, IaaS provider). You must document the vendor, a tracking ID (CVE or vendor ticket), and expected fix date; your 3PAO validates VDs at annual assessment, and you still need compensating controls in the meantime.
2. Deviation Request (DR): three subtypes — False Positive (the finding isn't real, with evidence), Risk Adjustment (real but lower actual risk due to mitigating factors, quantified), and Operational Requirement (can't fix without breaking functionality, requires documented business justification and compensating controls). All DRs require agency AO approval before you can mark them as such.
3. Closed with evidence: when you close an item, attach the actual evidence of remediation — a clean scan result, a configuration screenshot, a dated confirmation — not just a status change.

Continuous Monitoring cadence
Monthly:
- Submit vulnerability scan results to your agency AO(s).
- Update the POA&M — open findings, remediation progress, new milestone dates.
- Update your asset inventory (IIW) for new/removed assets, including ephemeral cloud-native resources like auto-scaling instances and containers.
- Submit the ConMon Monthly Executive Summary.

Annually:
- Full security assessment by your 3PAO using the Annual Assessment Controls Selection Worksheet (which pulls from four tabs: the Rev 5 control list, conditional controls, CSP-specific controls based on system changes/ConMon activity, and inherited controls from leveraged FedRAMP systems). No control can go untested for more than three years, so selection isn't arbitrary — it cycles through your full baseline over time plus anything flagged by recent activity.
- Updated SSP and appendices.
- Tested Incident Response Plan and Contingency Plan (tabletop minimum; functional exercise preferred, and generally expected for High/Class D).
- Updated SAR and POA&M reflecting the annual assessment's findings — every SAR finding must appear as a POA&M row; agencies cross-reference these directly.

Two things that will actively hurt you in ConMon if overlooked:
- Stale POA&M items — no milestone updates, missed dates without an approved deviation — can trigger suspension of your ATO. Agencies treat a stale POA&M as a signal that the CSP isn't actively managing risk, not just an administrative lapse.
- The Security Inbox requirement (effective January 5, 2026): all authorized CSPs must maintain a dedicated Security Inbox, with no CAPTCHAs or access barriers, so government can reach you quickly with urgent vulnerability directives. This should be referenced in both your Incident Response Plan and your Continuous Monitoring Plan (Appendix M).

Practical advice: build your POA&M tracking into whatever GRC tool or system you already use for scan management so that identification dates, SLA clocks, and milestone updates are captured automatically rather than reconstructed manually each month — reconstructing dates after the fact is exactly what produces the "stale POA&M" and "missed SLA" findings that agencies flag most often. And keep your SSP control narratives, POA&M, and CIS/CRM workbook internally consistent — a control marked "Implemented" in the SSP but appearing as an open weakness in the POA&M is a common inconsistency finding during annual assessment.

Here's how a GRC consultant typically walks a client through POA&M remediation timelines and continuous monitoring (ConMon) expectations under FedRAMP. This is based on the well-established Rev5/traditional FedRAMP framework; if your organization is operating under a FedRAMP 20x pilot, some mechanics (e.g., automated KSI validation replacing parts of manual ConMon) may differ, so confirm specifics against your governing ConMon plan and PMO guidance.

POA&M basics: The Plan of Action and Milestones is the living document that tracks every known weakness or deficiency in your system — findings from the initial assessment, vulnerability scans, penetration tests, incident-driven findings, and control deviations — along with remediation plans, responsible parties, and target completion dates. FedRAMP requires you to maintain and submit updated POA&Ms on a recurring basis (typically monthly) to your authorizing agency or the PMO, and reviewers actively track whether you're closing items within required timeframes.

Standard remediation timelines (these are the widely cited FedRAMP targets, derived from vulnerability severity):
- Critical vulnerabilities: remediate within 30 days of detection.
- High vulnerabilities: remediate within 30 days of detection (in earlier guidance sometimes bucketed with critical; current FedRAMP guidance has trended toward treating Critical and High similarly, often both at 30 days, though some references use a tighter window for Critical — verify the exact current SLA in your ConMon plan and the FedRAMP Continuous Monitoring Strategy Guide).
- Moderate vulnerabilities: remediate within 90 days of detection.
- Low vulnerabilities: remediate within 180 days of detection, or per your organization's risk-based justification.

These clocks start from the date of detection (typically the scan date), not the date the finding is written up or reported, which is a common compliance pitfall — organizations that delay internal triage effectively shorten their own remediation window without realizing it.

Deviation requests: If you cannot remediate within the standard window — due to vendor patch unavailability, business-critical system dependencies, compensating controls, or operational constraints — you must submit a formal risk adjustment/deviation request to your AO, with justification, compensating controls, and a revised target date. These aren't automatic; the AO can reject the deviation and require faster remediation, and a pattern of repeated deviation requests without real progress is a common trigger for authorization concerns or agency escalation.

POA&M submission cadence: Monthly POA&M updates are the norm, submitted alongside your monthly ConMon deliverables. Each submission should show: new findings added, findings closed with evidence, status changes on open items, and updated target dates for anything slipping. Agencies and 3PAOs specifically scrutinize aging open items — findings sitting open well past their target date without documented deviation are a red flag in annual assessments and can jeopardize your ATO.

Continuous monitoring deliverables more broadly, beyond POA&M, typically include:
- Monthly vulnerability scan results (infrastructure, database, web application) and a summary of scan-to-POA&M reconciliation.
- Monthly or quarterly significant change requests for any architecture, control, or personnel changes that affect your security posture.
- Annual security assessment — essentially a mini re-assessment by your 3PAO covering a representative control sample, updated SSP, updated SAR, incident response test results, and contingency plan test results.
- Annual FedRAMP Annual Assessment package submission to your authorizing agency, which is the formal checkpoint where continued authorization is affirmed or challenged.
- Incident reporting — actual security incidents must be reported to US-CERT/CISA and your agency within specified timeframes (historically as fast as 1 hour for confirmed incidents under federal incident reporting requirements, though exact thresholds depend on incident category), separate from the routine POA&M cycle.

Practical recommendations:
1. Build internal SLAs tighter than the FedRAMP minimums (e.g., target 21 days for Critical/High) so that normal internal friction doesn't blow your compliance deadline.
2. Automate scan-to-POA&M ingestion where possible; manual reconciliation is the most common source of missed findings and stale entries.
3. Track POA&M aging as a standing metric in your internal risk dashboard, not just at submission time, so leadership sees overdue items before the agency does.
4. Treat deviation requests as an exception process requiring real justification and compensating controls, not a routine way to manage a backlog — auditors and AOs notice patterns of habitual deviation requests.
5. Rehearse your annual assessment readiness continuously rather than scrambling annually — your ConMon discipline throughout the year is what actually determines how smooth (or painful) the annual assessment turns out to be.

Bottom line: FedRAMP's POA&M and ConMon regime is built around risk-tiered remediation SLAs (roughly 30/90/180 days for Critical-High/Moderate/Low), monthly reporting discipline, and an annual re-assessment checkpoint — the organizations that struggle are almost always the ones that let internal triage delay the remediation clock or that treat deviation requests as routine rather than exceptional.

Short answer: No — as designed, this is very likely unlawful under Article 22 GDPR, and it sits squarely within the fact pattern that just produced the largest Article 22 fine on record.

Rule (Art. 22)
Article 22(1) gives data subjects the right "not to be subject to a decision based solely on automated processing... which produces legal effects concerning him or her or similarly affects him or her." Deactivating a driver's account is a textbook "similarly significant effect" — it removes their ability to earn income, which courts and regulators treat as at least as serious as many "legal effects." A fraud-detection model that flags an account and triggers deactivation with no human in the loop is "solely automated" for Art. 22 purposes unless a human reviews the individual case and has genuine discretion to overturn it — a human merely rubber-stamping the model's output does not count as meaningful review.

Controlling precedent: Uber (Dutch AP, August 21, 2026)
This scenario is functionally identical to the case that produced the second-largest GDPR fine ever: €824.99 million against Uber, issued by the Dutch Autoriteit Persoonsgegevens (lead supervisory authority under one-stop-shop, with CNIL cooperating after a complaint from 171 French drivers via Ligue des droits de l'Homme). The AP found that between 2018 and 2022, Uber fully automatically deactivated driver accounts — temporarily on fraud suspicion or low ratings, permanently on persistent low ratings — with no human assessment, and gave drivers insufficient information about the logic and consequences of the automated decision. The AP's deputy chair stated plainly: "A computer should not make decisions on its own that have major consequences for you. These decisions should have been looked at first by a human being." Uber has appealed, but the decision is now the defining enforcement precedent for Art. 22 in platform/gig-economy contexts.

Exceptions (Art. 22(2)) and why they likely don't help here
Solely automated decisions are permitted only if: (a) necessary for entering/performing a contract, (b) authorised by EU/Member State law with suitable safeguards, or (c) based on explicit consent. Even where an exception applies, Art. 22(3) still requires the controller to implement "suitable measures to safeguard the data subject's rights and freedoms and legitimate interests, at least the right to obtain human intervention... to express his or her point of view and to contest the decision." A blanket contractual clause permitting automated deactivation would not satisfy this — you still owe drivers a genuine contestation channel.

Practical implications / what to change
1. Human review must be real: a qualified reviewer must be able to examine the individual case, access the underlying signals, and overturn the flag — not merely confirm the model's output within a fixed SLA.
2. Transparency (Art. 13/14, Art. 15(1)(h)): drivers must be told that automated decision-making is used, given meaningful information about the logic involved, and told the significance and likely consequences.
3. Contestation channel (Art. 22(3)): provide an accessible, timely route to challenge a deactivation before or immediately after it takes effect, especially where account suspension causes immediate loss of income.
4. DPIA (Art. 35): profiling that produces legal/significant effects at scale is a mandatory DPIA trigger — document necessity, proportionality, and mitigations, and consult your DPO.
5. Audit the fraud model itself for accuracy and bias, and log every automated decision and any human override for accountability (Art. 5(2)).

⚠️ Legal Advice Disclaimer: This guidance is informational and based on the GDPR text and established regulatory guidance, including the Uber precedent. It does not constitute legal advice. Given the fine amount and enforcement pattern in this exact fact pattern, consult a qualified data protection lawyer or your DPO before continuing to operate solely automated deactivations.

Short answer: as currently designed, this is very likely non-compliant, and you should treat it as a high-priority legal risk.

The relevant provision is Article 22 of the GDPR, which gives data subjects the right "not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her." Deactivating a driver's account is a textbook example of a decision with legal or similarly significant effect — it cuts off the person's ability to earn income on your platform, and courts and regulators (including the CJEU in the SCHUFA case, and multiple national DPAs in gig-economy driver cases against Ola, Uber, and others) have already found that automated account deactivation/deactivation-adjacent decisions fall within Article 22's scope.

Key points to work through:

1. Is this "solely automated"? You describe no human review of individual cases, which is exactly the fact pattern Article 22 targets. If a human merely rubber-stamps the model's output without genuinely reviewing the underlying data and being empowered to overturn it, regulators will still treat this as solely automated. The human involvement has to be meaningful — someone with the authority, competence, and time to actually change the outcome.

2. Do you have a valid exception? Article 22(2) allows solely automated decisions with significant effect only if: (a) it's necessary for entering into or performing a contract, (b) it's authorized by EU or member state law with suitable safeguards, or (c) it's based on explicit consent. Fraud prevention on a platform doesn't automatically qualify as "necessary for performance of a contract" — regulators read this narrowly, and it's doubtful that automatically terminating access is "necessary" for the contract's performance when a human-in-the-loop alternative exists. Consent is unlikely to be valid here given the power imbalance between platform and driver (consent must be freely given, and freely given is hard to establish where refusing consent could cost someone their livelihood).

3. If you rely on an exception, Article 22(3) requires you to implement suitable measures to safeguard the data subject's rights, including at minimum the right to obtain human intervention, to express their point of view, and to contest the decision. A drivers' union case against Uber in the Netherlands and the Amsterdam Court of Appeal ruling specifically found deactivation-by-algorithm without meaningful contestation rights to be unlawful.

4. Transparency obligations. Articles 13(2)(f) and 14(2)(g) require you to give data subjects meaningful information about the logic involved, the significance, and the envisaged consequences of such processing — at the point data is collected, not just after a dispute arises.

5. DPIA. Given the scale (a rideshare platform presumably processes many drivers) and the significant effect on livelihood, this processing almost certainly requires a Data Protection Impact Assessment under Article 35, including a specific assessment of the automated decision-making and consultation with your DPO.

Practical recommendations:
- Build in a genuine human review step before any deactivation is finalized, or at minimum, a fast, accessible appeal channel where a human with real authority reviews flagged cases within a short SLA.
- Log the specific factors/features that triggered the flag, so a human reviewer can meaningfully evaluate it and so you can respond to data subject access requests about the logic involved.
- Update your privacy notice to describe the existence of this automated decision-making, the logic involved (at a meaningful level, not just "we use an algorithm"), and its significance/consequences.
- Conduct or update a DPIA covering the fraud-detection model specifically.
- Consider whether local employment/gig-worker law also applies (many jurisdictions are adding specific protections for platform workers around algorithmic management, e.g., the EU Platform Work Directive).

This is a case where regulatory and litigation risk is concrete and precedent already exists against similar platforms, so I'd treat remediation as urgent rather than aspirational.

Short answer: There is no bright-line technical test for "anonymous" under GDPR — the current standard is a relative, recipient-specific, risk-based assessment, and given the facts you describe (sharing with an external business partner with no DPA), you should assume real re-identification risk and not treat the shared dataset as automatically anonymous just because you removed direct identifiers.

The legal framework
Anonymous data falls outside GDPR entirely (Recital 26) — it is data from which "the data subject is not or no longer identifiable." Pseudonymised data, by contrast, remains personal data (Art. 4(5)) because a key or additional information could re-identify individuals. Getting this classification wrong is consequential: if what you send your partner is still personal data, the transfer needs a lawful basis (Art. 6), and — if your partner is a separate controller/processor — a contract is generally required (Art. 28 if processor; a controller-to-controller arrangement still needs an Art. 6 basis and Art. 13/14 transparency, though not necessarily a "DPA" in the Art. 28 sense).

The current standard: the "relative approach"
The CJEU's SRB v EDPS ruling (Case C-413/23 P, 4 September 2025) is now the controlling authority: whether data is "personal data" is assessed relative to the specific recipient, not in the abstract. Pseudonymised data may be personal data in the hands of the original controller (who holds or can obtain the re-identification key) but non-personal in the hands of a recipient who has no reasonably available means to re-identify. The test is whether re-identification is "reasonably likely" for that specific holder — not whether it is theoretically possible for someone, somewhere, with unlimited resources.

The EDPB has now operationalized this in draft Guidelines 02/2026 on Anonymisation (adopted for consultation 7 July 2026, open until 30 October 2026; will replace the old WP29 Opinion 05/2014 once finalized). Key positions to apply today, while flagging that this guidance is still in draft:
- Relative identifiability, following EDPS v SRB — the same dataset can be anonymous for one holder and personal data for another.
- The "means reasonably likely to be used" test — assess cost, time, expertise, and available auxiliary data realistically available to the recipient, not a worst-case adversary.
- The three classic re-identification criteria are retained: singling-out (isolating an individual record), linkability (connecting records about the same person), and inference (deducing attributes with reasonable confidence).

Practical implication for your situation
Because you're proposing to send data to a business partner "outside any data-processing agreement," you have no contractual control over what auxiliary data or re-identification capability that partner holds — which cuts directly against the "reasonably likely means" analysis in the recipient's favor. To rely on the anonymisation exemption you would need to demonstrate, and document:
1. Direct and indirect identifiers removed or generalized sufficiently to defeat singling-out (e.g., k-anonymity/l-diversity techniques, not just stripping names/emails).
2. No retained key or crosswalk that you or the partner could use to relink records.
3. An assessment of what auxiliary datasets the partner (or anyone they might share with) could plausibly combine with your data to re-identify — this is where most "anonymisation" claims fail in practice.
4. A written anonymisation assessment tested against known re-identification techniques, reviewed by your DPO, retained as evidence.

If you cannot clear that bar — and sharing outside a DPA with a partner whose data environment you don't control makes it hard to clear — treat the dataset as pseudonymised personal data, not anonymous, and put in place either an Art. 28 DPA (if the partner processes on your instructions) or a separate lawful basis, transparency notice, and appropriate safeguards for a controller-to-controller disclosure (Art. 5(1)(b), (c); Art. 6; Art. 13/14).

⚠️ Legal Advice Disclaimer: This guidance is informational, reflects both binding CJEU case law and non-final EDPB draft guidance (consultation open through October 30, 2026), and does not constitute legal advice. Given the stakes of an incorrect anonymisation determination and the absence of a governing contract with your partner, consult a qualified data protection lawyer or your DPO before proceeding with the transfer.

The bar for "anonymous" under GDPR is much higher than most organizations assume, and getting it wrong doesn't just create risk — it means the sharing you're describing is actually an unlawful disclosure of personal data, since anonymization is the only thing that takes data outside the scope of the GDPR entirely (Recital 26).

The governing standard:

Recital 26 says data is anonymous, and therefore outside GDPR's scope, only if the data subject is not or no longer identifiable, taking into account "all the means reasonably likely to be used" by the controller or any other person to identify the individual, directly or indirectly. Crucially, this test is not limited to what your organization intends to do with the data — it asks whether re-identification is reasonably possible by anyone, including the recipient, considering:
- the cost and time required for re-identification,
- the available technology at the time of processing and expected technological development,
- and, critically here, what other data sets or auxiliary information a recipient might combine with yours.

This is why sharing "anonymised" data with an external partner is particularly risky: the reasonableness test has to account for whatever data the partner already holds or could plausibly obtain. If the partner has other datasets that could be linked to yours (e.g., other customer records, browsing data, location history), true anonymization becomes very difficult to achieve and demonstrate.

Regulatory and expert guidance (the Article 29 Working Party's Opinion 05/2014 on Anonymisation Techniques remains the most cited framework, later reinforced by EDPB and national DPA guidance) evaluates anonymization against three re-identification risks:
1. Singling out — can you isolate some or all records identifying an individual?
2. Linkability — can you link two records about the same individual (even without naming them)?
3. Inference — can you deduce, with significant probability, the value of an attribute from other attributes?

A dataset is only robustly anonymous if all three risks are mitigated. Simply removing direct identifiers (names, emails, ID numbers) is not enough — this is "pseudonymisation," not anonymization, and pseudonymised data remains personal data under GDPR (Article 4(5) and Recital 26 explicitly say so) because the data can be attributed to a natural person with the use of additional information (e.g., a key you or someone else holds).

Common techniques and their limits:
- Removing/masking direct identifiers: insufficient alone — indirect identifiers (postcode, birth date, device ID, purchase patterns) can still re-identify people, especially in combination (the classic finding is that ZIP code + birth date + gender uniquely identifies most US individuals; similar quasi-identifier combinations exist in EU datasets).
- k-anonymity, l-diversity, t-closeness: improve resistance to singling out/inference but are vulnerable when combined with external data and don't eliminate linkability risk on their own.
- Differential privacy: currently the strongest, most defensible technical approach because it provides a mathematical, provable bound on the probability that any individual's data affects the output, regardless of auxiliary information an attacker might have. Regulators increasingly view differential privacy (with meaningfully small epsilon values) as the gold standard for defensible anonymization claims, though it typically requires some accuracy trade-off.
- Aggregation/statistical summarization at sufficiently large group sizes can also qualify, provided small-cell suppression prevents singling out.

For your specific scenario, sharing with a partner outside a data-processing agreement:

- If you're relying on "this is anonymous so GDPR doesn't apply," the burden of proof is on you, and regulators will scrutinize claims skeptically, especially post-transfer where you lose control over what the recipient combines the data with.
- Document your anonymization methodology, the re-identification risk assessment (considering what the specific partner is reasonably likely to hold or obtain), and revisit it periodically as techniques and available auxiliary data evolve — anonymization is not a one-time determination, it can degrade over time ("anonymisation is not necessarily a permanent state").
- If there's genuine doubt about whether the output is robustly anonymous, treat it as pseudonymised personal data, which means you need a lawful basis for the disclosure and — since this is a transfer to a separate organization acting as controller of the data it receives — a legally appropriate instrument. That could be a DPA if the partner is acting as your processor, or more likely here, a controller-to-controller data sharing agreement covering purpose limitation, security, and onward transfer restrictions.
- Consider a Data Protection Impact Assessment if the anonymization/sharing is systematic or involves special category or sensitive-adjacent data.

Bottom line: don't rely on de-identification alone. Get an independent, documented, risk-based assessment (ideally with statistical/technical sign-off) that accounts for the specific recipient's plausible auxiliary data, and if there's any meaningful residual re-identification risk, put a proper data-sharing agreement in place rather than relying on an anonymization claim.

Short answer: Yes, it can be done GDPR-compliantly, but not on a consent basis at any meaningful scale — you will need to rely on legitimate interests (Art. 6(1)(f)), conduct a rigorous documented balancing assessment, and build in specific mitigations the EDPB now expects for generative-AI scraping.

Governing framework
Two EDPB instruments define current expectations here, and both should be read together:

1. EDPB Opinion 28/2024 (adopted 17 December 2024) — the foundational guidance on AI models and GDPR, answering three questions from the Irish DPC:
   - AI models trained on personal data are not automatically anonymous. A model only qualifies as anonymous if it is "very unlikely" that (a) individuals in the training data can be re-identified from outputs/architecture, and (b) personal data can be extracted from the model via queries. This is a high, evidence-based bar you must actively test, not assume.
   - Legitimate interests can be used as the lawful basis for AI training, including commercial development interests, but only after a full three-step LIA: legitimate interest → necessity → balancing. The balancing step must specifically weigh scale and sensitivity of the scraped data, whether data subjects had any reasonable expectation their data would be used this way, and whether training is a materially different purpose than the data's original context.
   - If training data was processed unlawfully, downstream use/deployment is tainted unless the resulting model clears the anonymity bar above — meaning even a licensed foundation model built on scraped data carries risk you should diligence, not just take on faith from the vendor.

2. EDPB Guidelines 03/2026 on web scraping for generative AI (adopted for consultation 7 July 2026, consultation open until 30 October 2026 — still a draft, but the direction of travel is clear and should inform your design now):
   - Consent is generally not viable at scale for scraping the open web — you cannot meaningfully obtain informed, specific consent from the millions of individuals whose data may appear in scraped pages. Legitimate interest is treated as the realistic lawful basis, subject to strict balancing and mitigations.
   - Controllers are expected to publish detailed, specific public notices describing the scraping and training activity (transparency — Art. 13/14 obligations still apply even to indirectly-collected data, with the Art. 14(5) "disproportionate effort" exemption interpreted narrowly here).
   - Facilitate data subject rights, including a pre-collection opt-out mechanism (e.g., robots.txt-style signals, do-not-train headers, or a dedicated opt-out registry) that data subjects and website operators can use before scraping occurs.
   - Coverage extends beyond your own first-party scraping to contracted scraping (vendors scraping on your behalf) and purchased broker/aggregator datasets — due diligence on provenance is expected in all three cases.

What this means practically for you
- Do not rely on consent as your lawful basis for the scraping or training step.
- Conduct and document a formal LIA before scraping begins: articulate the legitimate interest precisely (not "AI development" in the abstract), confirm scraping is necessary (could a smaller, licensed, or synthetic dataset serve the purpose with less risk?), and perform the balancing test — special-category or sensitive personal data, children's data, and content posted in contexts implying no future AI use should weigh heavily against inclusion or should be filtered out.
- Exclude or filter special category data (Art. 9) discovered during scraping — this remains prohibited for training absent an Art. 9(2) condition, regardless of scale.
- Publish a clear, specific public notice about the scraping/training activity and stand up a pre-collection opt-out mechanism.
- Test whether your resulting model meets the Opinion 28/2024 anonymity bar; if it doesn't, maintain the legitimate-interest basis and transparency obligations through deployment, not just training.
- Run a DPIA (Art. 35) — large-scale scraping of public data for AI training, potentially capturing special categories or children's data, is a strong candidate for mandatory DPIA under Art. 35(3) criteria.
- If you're contracting a third party to do the scraping, or buying a scraped dataset, diligence their lawful basis and provenance — you inherit their compliance failures as a controller relying on that data.

⚠️ Legal Advice Disclaimer: This guidance is informational, combines binding EDPB Opinion 28/2024 with still-draft Guidelines 03/2026 (consultation open through October 30, 2026), and does not constitute legal advice. Given the scale, novelty, and enforcement attention on AI training practices, consult a qualified data protection lawyer or your DPO before finalizing your scraping and training pipeline.

Scraping publicly available web data for AI training is one of the most contested areas of GDPR enforcement right now, and "it's public" is not a defense — GDPR applies to personal data regardless of whether it was previously made public by the data subject or a third party. Several DPAs (notably the Italian Garante's actions against Clearview AI and, temporarily, against OpenAI/ChatGPT in 2023, plus ongoing EDPB and CNIL guidance on AI and web scraping) have made clear that scraping the public web for training data falls squarely within GDPR's scope whenever the data includes information relating to identified or identifiable natural persons.

Here's how to think through it:

1. Lawful basis. You need one under Article 6 before you scrape anything containing personal data. In practice, for large-scale scraping, the two realistic options are:
   - Legitimate interests (Article 6(1)(f)): the most commonly invoked basis for AI training. This requires a documented Legitimate Interests Assessment (LIA) balancing your interest in training the model against the rights and reasonable expectations of the individuals whose data appears in the scraped content. The EDPB's 2024 Opinion 28/2024 (issued in response to the Irish DPC's request concerning AI models) sets out a structured three-step test: (a) identify a legitimate interest, (b) show the processing is necessary for that purpose, (c) balance against the data subject's rights, considering factors like the reasonable expectations of individuals (would someone posting a forum comment reasonably expect it to train a generative model?), the nature of the data (sensitive/special category data scraped incidentally is a serious red flag), and the availability of mitigations.
   - Consent is rarely feasible at web-scraping scale, so most organizations don't rely on it, though for narrow, targeted scraping it could apply.
   Note there is no "public data" exemption in GDPR — Article 9's special-category rules explicitly still apply even to data "manifestly made public by the data subject," it just changes the analysis (Article 9(2)(e)) rather than removing it.

2. Special category data. Web scrapes routinely pick up special category data (health, religion, sexual orientation, political opinion, trade union membership, etc.) incidentally, e.g., from social media bios, forum posts, or personal blogs. Processing this requires an Article 9(2) condition; "manifestly made public" is one option but is interpreted narrowly and requires clear evidence the individual intended broad public disclosure, not just that content was technically accessible.

3. Transparency (Articles 13/14). Because you didn't collect the data directly from the data subjects, Article 14 applies, including the exemption at Article 14(5)(b) where informing individuals "proves impossible or would involve disproportionate effort" — which is the argument most large AI developers rely on for bulk scraping, but you still must take proportionate steps: publish clear, accessible information about training data sources and purposes, and this exemption is being tested and narrowed by DPAs, not a guaranteed shield.

4. Data minimisation and purpose limitation. Scraping indiscriminately without any filtering for personal data increases risk. Practical mitigations regulators look favorably on: filtering/excluding sites known to contain high volumes of sensitive personal data, excluding data behind privacy walls or robots.txt/ToS restrictions, de-duplication, removing or masking direct identifiers where feasible without destroying training utility, and respecting opt-out signals (e.g., "noai" tags, Do Not Train registries some platforms now support).

5. Data subject rights. You must have a practical mechanism for individuals to exercise rights — access, erasure, objection (Article 21, which has particular force for legitimate-interest processing since data subjects have an unconditional right to object to processing for certain purposes, and you must be able to honor deletion/objection even though data may already be embedded in trained model weights, which is a genuinely hard technical and legal problem regulators are actively grappling with — see ongoing debate about whether "unlearning" or model retraining is required).

6. International transfers and jurisdiction. If any scraped content includes EU residents' data and it's processed/trained outside the EEA, standard cross-border transfer rules (SCCs, adequacy, etc.) still apply.

7. DPIA. Given the scale, novel technology, profiling potential, and use of special-category and possibly children's data, a DPIA under Article 35 is very likely mandatory before you begin.

Bottom line: it can be done in a GDPR-compatible way, but "publicly available" does not mean "GDPR-free." You need a documented legitimate interest assessment, filtering to reduce special-category and sensitive data ingestion, a transparency mechanism (even if relying on the disproportionate-effort exemption), a working rights-request process, and likely a DPIA — and you should expect continued regulatory scrutiny and evolving guidance in this area, so build in flexibility to adjust your scraping and training pipeline as EDPB/DPA positions solidify.

Direct answer: Under Article 28(3) GDPR, any contract with a processor handling personal data on your behalf must contain a specific, mandatory set of clauses — a hosting provider storing EU customer data is a textbook processor relationship, and missing any of these terms is itself a compliance violation exposed to Art. 83(4) fines (up to €10M or 2% of global turnover). Below are the key clauses to include, gathered before drafting: your organisation's role (controller), the processor's identity, the categories of data/data subjects, and — critically — where the hosting infrastructure is physically located, since that determines whether you also need an international transfer clause.

1. Subject Matter, Duration, Nature and Purpose (Art. 28(3))
State precisely what the processor does: "[Processor] shall process personal data solely for the purpose of providing hosting and infrastructure services for [Controller]'s application, for the duration of the underlying services agreement dated [DATE]." Vague or open-ended purpose language is a common audit finding.

2. Categories of Data and Data Subjects (Art. 28(3))
List explicitly: e.g., contact data (name, email), account credentials, usage/log data (IP addresses, session identifiers), and confirm whether any special category data (Art. 9) is in scope — hosting providers often handle this without either party flagging it.

3. Processing Only on Documented Instructions (Art. 28(3)(a))
"Processor shall process personal data only on documented instructions from Controller, including regarding international transfers, unless required by applicable law — in which case Processor shall inform Controller before processing, unless legally prohibited from doing so."

4. Confidentiality (Art. 28(3)(b))
Personnel authorized to access the data must be bound by confidentiality obligations, contractual or statutory.

5. Security Measures (Art. 28(3)(c); Art. 32)
Specify concrete technical and organisational measures: encryption at rest and in transit, access controls, ability to restore availability/access after an incident, and regular testing/evaluation of security measures. For a hosting provider specifically, insist on details of physical security, network segmentation, and backup encryption — generic "industry standard security" language is insufficient for audit purposes.

6. Sub-processors (Art. 28(2), (3)(d), (4))
Require prior specific or general written authorisation before engaging sub-processors (e.g., a CDN, backup provider, or cloud region operator the hosting provider itself relies on), with a right to object to new sub-processors, a current sub-processor list (as a schedule), and flow-down of equivalent obligations — the hosting provider remains liable to you for its sub-processors' failures.

7. Assistance with Data Subject Rights (Art. 28(3)(e))
The provider must assist you, via appropriate technical/organisational measures, in responding to access, erasure, rectification, and other Art. 15–22 requests — important for hosting since backups and infrastructure-level deletion capability are frequent gaps (flagged as a top failure mode in the EDPB's 2025 erasure enforcement sweep).

8. Assistance with Controller Obligations (Art. 28(3)(f))
Assistance with Art. 32 security, Art. 33–34 breach notification, and Art. 35–36 DPIAs, proportionate to the nature of processing and information available to the provider.

9. Deletion or Return of Data (Art. 28(3)(g))
On termination, the provider must delete or return all personal data (your choice) and delete existing copies, including backups, unless law requires retention — specify a concrete deletion timeline (e.g., 30/60 days) rather than leaving it open-ended.

10. Audit Rights (Art. 28(3)(h))
Right to audit or inspect the provider's compliance, or accept independent certifications/reports (e.g., SOC 2, ISO 27001) in lieu of a full audit, with a defined notice period.

11. Breach Notification Timeline (Art. 33)
Require notification "without undue delay" and within a specific window (commonly 24–48 hours) of the provider becoming aware of a breach, so you retain enough runway to meet your own 72-hour Art. 33 deadline to the supervisory authority.

12. International Transfers (Art. 44–49) — confirm before finalizing
If the hosting infrastructure or any sub-processor/backup region is outside the EEA/UK, you need a transfer mechanism clause: an adequacy decision (Art. 45 — e.g., UK adequacy renewed through 27 December 2031), 2021 Standard Contractual Clauses (Art. 46(2)(c) — still the current version), or Binding Corporate Rules (Art. 47). For US-based hosting relying on the EU–US Data Privacy Framework, note it remains valid but is under CJEU appeal (Case C-703/25 P) with PCLOB oversight currently suspended — build in SCCs as a contractual fallback rather than relying on DPF alone.

⚠️ Legal Advice Disclaimer: This guidance is informational and does not constitute legal advice. Have final contract language reviewed by a qualified data protection lawyer or your DPO, particularly the security specifications, sub-processor authorisation mechanism, and international transfer clause once the provider's actual data locations and sub-processors are confirmed.

Here are the key clauses your Data Processing Agreement (DPA) with the hosting provider needs to include, mapped to the mandatory content requirements of Article 28(3) GDPR, plus a few practical additions worth negotiating.

1. Subject matter, duration, nature, and purpose of processing
State precisely what is being processed (EU customer personal data — specify categories: e.g., names, contact details, account data, any special categories if applicable), the duration of the agreement, and the specific purpose (hosting infrastructure/storage services for [Company]'s platform). Vague or boilerplate descriptions are a common audit finding — be specific.

2. Types of personal data and categories of data subjects
List them explicitly (e.g., customer names, email addresses, IP addresses, transaction data; data subjects = your customers/end users). This should be maintained as a living annex/schedule so it can be updated without renegotiating the whole agreement.

3. Processing only on documented instructions (Article 28(3)(a))
The processor must process personal data only on your documented instructions, including regarding international transfers, unless required by EU/member state law — in which case it must inform you before processing (unless prohibited from doing so on public interest grounds).

4. Confidentiality commitment (Article 28(3)(b))
All persons authorized to process the data must be bound by confidentiality obligations (contractual or statutory).

5. Security measures (Article 28(3)(c), tied to Article 32)
Require appropriate technical and organizational measures reflecting the state of the art, costs, and risk — specifically: encryption at rest and in transit, access controls and authentication, logging/monitoring, regular testing/evaluation of measures, and resilience/backup and disaster recovery capability. Attach a security annex with concrete specifics (not just "industry standard security") since hosting providers in particular should commit to specifics like data center physical security, patching cadence, and incident detection capability.

6. Sub-processor provisions (Article 28(2) and 28(3)(d))
- General or specific prior written authorization for engaging sub-processors (cloud infrastructure providers commonly use general authorization with a notification mechanism).
- A right for you to object to new sub-processors within a defined notice period (commonly 15-30 days), with a clear consequence if you object (e.g., right to terminate the affected service or the agreement).
- A flow-down obligation: the same data protection obligations must be imposed on sub-processors via contract, and the processor remains fully liable to you for sub-processor failures.
- A current, accessible list of sub-processors (often maintained as a public or portal-based register).

7. Assistance with data subject rights (Article 28(3)(e))
The processor must assist you, taking into account the nature of processing, in responding to data subject requests (access, rectification, erasure, restriction, portability, objection) — typically via technical/organizational measures and defined response timeframes (e.g., processor notifies you within 48-72 hours of receiving a request directly).

8. Assistance with Article 32-36 compliance (Article 28(3)(f))
Processor must help you meet obligations around security, breach notification, DPIAs, and prior consultation with supervisory authorities, taking into account the information available to the processor.

9. Personal data breach notification (feeds Article 33/34)
This is critical for a hosting provider specifically — require notification to you without undue delay, and specify a firm outer limit (commonly 24-72 hours from becoming aware), including what information must be provided (nature of breach, categories/approximate number of data subjects and records affected, likely consequences, measures taken/proposed). Since your ultimate 72-hour clock to the supervisory authority starts when you become aware, the processor's notification speed is your critical path — negotiate the shortest commercially reasonable window.

10. End-of-contract data return/deletion (Article 28(3)(g))
Processor must, at your choice, delete or return all personal data at the end of the provision of services, and delete existing copies unless EU/member state law requires storage — including from backups, on a defined schedule.

11. Audit and inspection rights (Article 28(3)(h))
Processor must make available all information necessary to demonstrate compliance and allow for/contribute to audits, including inspections, conducted by you or an auditor you mandate. Hosting providers often substitute independent third-party audit reports/certifications (SOC 2 Type II, ISO 27001) for direct audits — acceptable, but negotiate a fallback right to a full audit for cause (e.g., after a breach).

12. International transfers
If the hosting provider processes or stores data outside the EEA/adequate countries (common with global hosting infrastructure — check specific data center locations, not just company HQ), include Standard Contractual Clauses (2021 EU Commission modules, processor-to-processor or controller-to-processor as applicable), plus require a Transfer Impact Assessment (TIA) addressing government access risks in the destination country (post-Schrems II requirement), supplementary measures (encryption with keys held by you, not the processor), and a commitment to notify you of government access requests where legally permitted.

13. Liability and indemnification
Allocate liability for GDPR fines and third-party claims arising from processor non-compliance; ensure this isn't capped below a level that reflects realistic GDPR exposure (fines up to 4% of global turnover).

14. Data localization/segregation options
Consider requiring EU-only data residency for EU customer data specifically, and clarify whether data is logically or physically segregated from other tenants.

Practical tip: don't just accept the hosting provider's standard "Data Processing Addendum" — many are drafted processor-favorably (e.g., broad general sub-processor authorization with weak objection rights, breach notification "without undue delay" with no outer time limit, liability caps that don't cover regulatory fines). Redline these specific points before signing.

Direct answer: Yes, this is almost certainly a notifiable personal data breach under Art. 4(12) — ransomware with suspected exfiltration of ~40,000 EU customers' personal data triggers both your 72-hour supervisory authority notification duty (Art. 33) and, very likely, an obligation to notify the affected individuals directly (Art. 34). Here is the sequence, in order, starting now.

Step 1 — Contain and establish facts (immediate, parallel to everything else)
Isolate affected systems, engage incident response/forensics, and preserve evidence (including logs — do not let ransomware cleanup destroy the evidence trail you'll need for Art. 33(3) reporting and eventual regulatory scrutiny). Determine, to the extent currently knowable: what categories of personal data were on the affected systems, whether exfiltration is confirmed or merely suspected, and whether backups are intact and uncompromised.

Step 2 — Assess "awareness" and start the 72-hour clock (Art. 33(1))
The clock starts when you become "aware" of the breach — generally when you have a reasonable degree of certainty a breach has occurred, not full certainty about scope. Discovering ransomware activity overnight with signs of exfiltration is very likely sufficient awareness to start the clock now, even if forensics are incomplete. Note: 40,000 EU customers across multiple Member States may implicate more than one national authority — identify your lead supervisory authority (typically where your main EU establishment is) under the one-stop-shop mechanism, and be prepared for cooperation with other affected DPAs.

Step 3 — Notify the supervisory authority within 72 hours (Art. 33)
Your notification must include, to the extent available (Art. 33(3)): nature of the breach and approximate number of data subjects/records affected; DPO or other contact point; likely consequences of the breach; and measures taken or proposed to address it and mitigate harm. If you cannot provide all information within 72 hours, Art. 33(1) explicitly permits phased/staggered reporting — submit what you have and supplement "without undue further delay." Document the reasons for any delay if you notify late (Art. 33(1) proviso).

Note on template: The EDPB's draft common Art. 33 notification template was adopted for consultation on 8 June 2026 and closed consultation on 5 August 2026 — it is not yet finalized or operative, so use your supervisory authority's current national notification form/portal, not the draft template.

Step 4 — Assess whether you must notify the affected individuals (Art. 34)
Required "without undue delay" where the breach is "likely to result in a high risk to the rights and freedoms of natural persons." Ransomware with suspected exfiltration of customer personal data is a strong candidate for high risk — factors pointing toward notification include: sensitivity of the data (payment details, ID numbers, health data would make this near-certain), risk of identity theft or fraud, and inability to rule out exfiltration. The Art. 34(3) exemptions (data was encrypted/unintelligible to the attacker, or you've taken measures eliminating the high risk, or individual notification would involve disproportionate effort — in which case a public communication may substitute) rarely apply cleanly to confirmed or suspected exfiltration scenarios; document your reasoning either way.

Step 5 — Draft and send individual notifications (if required)
Must describe, in clear plain language (Art. 34(2), referencing Art. 33(3)(b)–(d)): nature of the breach, likely consequences, and measures taken/recommended (e.g., password resets, fraud monitoring, watch for phishing). Coordinate timing with the SA notification and with any parallel obligations (e.g., NIS2/national cybersecurity incident reporting, breach notification laws in non-EU jurisdictions if customers are global).

Step 6 — Investigate root cause, remediate, and document everything (Art. 5(2) accountability)
Maintain an internal breach register covering all breaches, even those not requiring SA notification (Art. 33(5)). Post-incident, review whether Art. 32 security measures (encryption, access controls, backup integrity, network segmentation) were adequate, and whether a DPIA (Art. 35) is now warranted for the affected processing given the demonstrated risk.

Step 7 — Anticipate regulatory follow-up
Ransomware breaches of this scale routinely trigger regulator inquiries into whether Art. 32 security measures were "appropriate to the risk" before the incident — be ready to demonstrate pre-incident encryption, patching cadence, access controls, and monitoring capability, not just your post-incident response.

⚠️ Legal Advice Disclaimer: This is a high-stakes, time-critical matter involving a confirmed security incident, likely regulatory notification duties, and potential fines under Art. 83. This guidance is informational only. Engage your DPO and outside counsel immediately — ideally within hours, not days — to manage notification timing, privilege over the forensic investigation, and coordination across any additional jurisdictions or sectoral regulators involved.

I'm sorry you're dealing with this — ransomware with possible exfiltration of 40,000 EU customers' personal data is a serious incident, and the clock is already running. Here's a step-by-step walkthrough of your GDPR obligations, roughly in the order you need to act.

Immediate (hours 0-24): Containment and initial assessment
- Your incident response/security team should already be isolating affected systems, but from a compliance standpoint, the priority is establishing facts: what data was involved, whether exfiltration is confirmed or merely possible, how many data subjects and what categories of data (special category data like health or financial details raises severity significantly), and when the incident actually began versus when you became "aware" of it.
- "Awareness" is a defined legal trigger — per EDPB guidance and case law (including the 2023 CJEU clarification in Case C-340/21), the 72-hour clock under Article 33 starts when you have a reasonable degree of certainty a breach has occurred, not necessarily when you have full details. Document precisely when your team first had that reasonable certainty — this timestamp will be scrutinized.
- Engage your DPO (or equivalent) immediately if you have one; if not, get legal/privacy counsel involved now, since notification decisions carry legal risk either way.

Within 72 hours: Notify the supervisory authority (Article 33)
- You must notify the lead supervisory authority (typically where your main EU establishment is, or where the most affected data subjects are, if you lack an EU establishment) within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals' rights and freedoms — which, given ransomware and possible exfiltration of 40,000 records, is very unlikely to apply here. Assume notification is required.
- If you can't gather all details in time, Article 33(4) allows phased/staged notification — submit what you know within 72 hours and supplement "without undue further delay."
- Required content (Article 33(3)): nature of the breach including categories and approximate number of data subjects/records affected; name/contact of your DPO or other contact point; likely consequences of the breach; measures taken or proposed to address it and mitigate adverse effects.
- If you're late past 72 hours, Article 33(1) requires you to include reasons for the delay — document your timeline and rationale contemporaneously, don't reconstruct it later.
- Multi-jurisdiction note: if affected customers span multiple EU member states, use the one-stop-shop mechanism via your lead authority, but be prepared for cooperation with other national DPAs.

Notify affected individuals (Article 34) — assess in parallel
- Required "without undue delay" if the breach is likely to result in a high risk to the rights and freedoms of natural persons. Ransomware plus exfiltration of customer personal data is a common trigger for high risk (identity theft, fraud, phishing exposure), so build the presumption that individual notification is needed unless you can demonstrate otherwise.
- Exceptions to direct notification (Article 34(3)): you had implemented appropriate protection (e.g., strong encryption that renders the data unintelligible to the attacker) making the data unintelligible; you've since taken measures ensuring the high risk is no longer likely to materialize; or direct notification would involve disproportionate effort, in which case a public communication or similar measure is required instead.
- Content of individual notice should be in clear, plain language: nature of the breach, likely consequences, measures taken/recommended (e.g., password resets, fraud monitoring, watch for phishing), and your contact point.

Internal documentation (Article 33(5)) — do this regardless of notification decision
- Document every breach internally: facts, effects, and remedial action taken — this record must be available for the supervisory authority to verify compliance, even for breaches you determine don't require notification. This documentation obligation is absolute and often overlooked.

Broader obligations to work through concurrently
- Article 32 security review: assess whether your technical and organizational measures were "appropriate" to the risk — the incident itself will likely be treated by the regulator as evidence one way or the other, so be prepared to show what safeguards existed (encryption, access controls, backups, patching cadence) and what you're remediating.
- Processor/controller chain: if the affected systems or data involve a processor (e.g., a vendor holding the data on your behalf) or if you are a processor for another controller, you have parallel/derivative notification obligations — processors must notify controllers without undue delay under Article 33(2), and if you're a processor, notify your controller immediately so they can meet their own 72-hour clock.
- Law enforcement and other regulators: ransomware often triggers separate obligations (e.g., NIS2 for essential/important entities, national cybercrime reporting, sector regulators, potentially SEC-style disclosure if you're a public company with US exposure, and law enforcement engagement, especially if considering whether to pay a ransom, which carries its own legal/sanctions risk).
- Post-incident: expect the supervisory authority may open an investigation, request further information, or conduct an audit. Preserve all forensic evidence, incident response records, and your decision-making rationale (the "why" behind your risk assessment and notification timing) — this becomes essential in demonstrating compliance and mitigating potential fines under Article 83, where cooperation and remediation are aggravating/mitigating factors.

Practical next steps right now: confirm your "awareness" timestamp, get counsel and DPO involved today, begin drafting the Article 33 notification even before all facts are final, and run the Article 34 high-risk assessment in parallel so you're not making that call under time pressure at hour 70.

Short answer: no — the "new Security Rule" you're describing is a **proposed** rule (an NPRM), not a final, effective regulation. You are not yet required to comply with MFA/encryption mandates under it, but you should be preparing for it and should not treat your current program as fully future-proof.

**What's actually happening**

In January 2025, HHS's Office for Civil Rights published a Notice of Proposed Rulemaking (RIN 0945-AA22) to substantially overhaul the HIPAA Security Rule. The proposal's headline changes would:
- Eliminate the "required" vs. "addressable" distinction entirely — every implementation specification would become mandatory, with narrow, documented exceptions only.
- Explicitly mandate multi-factor authentication for access to systems containing ePHI.
- Mandate encryption of ePHI at rest and in transit, with very limited exceptions.
- Require a current technology asset inventory and network map.
- Add explicit vulnerability scanning, penetration testing, and incident response testing requirements.

The public comment period closed in March 2025 with roughly 4,745 comments, and industry pushback has been substantial — more than 100 hospital systems, led by the American Hospital Association, have formally urged HHS to withdraw or significantly narrow the proposal, citing cost and operational burden concerns, particularly for smaller providers.

**Where it stands today (September 2026)**

The rule has not been finalized. HHS's Unified Agenda published August 14, 2026 moved this rulemaking to the "Long-Term Actions" category, with final action now anticipated no earlier than July 2027 — and that date could slip further given the volume of comments and the withdrawal pressure. That means:
- There is currently **no legal obligation** to implement MFA or encryption because this NPRM exists.
- The **current** Security Rule (45 CFR §§164.308, 164.310, 164.312) remains the operative standard, and under it encryption is still formally "addressable" — meaning you must assess whether it's reasonable and appropriate for your environment, and if you decide not to implement it, document a legitimate reason and an equivalent alternative safeguard.

**What I'd actually recommend regardless of the rule's status**

Don't confuse "not yet required" with "not a good idea." In practice:
- MFA and encryption (AES-256 at rest, TLS 1.2+ in transit) are already the de facto industry standard, and OCR's enforcement pattern under the *current* rule treats their absence as strong evidence of an inadequate risk analysis or risk management program — which *is* independently enforceable today.
- If you don't have MFA and full encryption in place, I would not wait for the rule to finalize. Build your program as if the "addressable" carve-out doesn't exist, because OCR's actual enforcement priorities (see below) already penalize the absence of these controls, and the direction of travel is unambiguous even if the timeline is not.

**Enforcement context worth knowing**

OCR's current enforcement focus — the Risk Analysis Initiative — has resulted in recent settlements against organizations for failing to conduct an accurate and thorough risk analysis after ransomware incidents, including actions against self-funded group health plan sponsors (previously an under-enforced category). This tells you where OCR's attention is right now, independent of the NPRM.

**Bottom line:** Track the NPRM (it may still be finalized, revised, or withdrawn), but don't present its provisions to your organization as current legal requirements — that would overstate your obligations. Build toward MFA and encryption now as a risk-management best practice and to defend against the "did you conduct an adequate risk analysis" question OCR is actually asking today.

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

Short answer: nothing has taken effect yet that would require you to implement MFA and encryption today under a new binding rule, but you should still be moving toward both because a proposal exists and, separately, the current rule already pushes you strongly in that direction.

Here's the more precise picture. HHS's Office for Civil Rights (OCR) published a Notice of Proposed Rulemaking (NPRM) in early January 2025 to substantially overhaul the HIPAA Security Rule. That proposal would, among other things, eliminate the long-standing distinction between "required" and "addressable" implementation specifications and make many safeguards that are currently addressable — including things functionally similar to multi-factor authentication and encryption of ePHI at rest and in transit — mandatory rather than optional-with-justification. It would also add explicit requirements for network segmentation, vulnerability scanning, penetration testing, and annual compliance audits.

However, a proposed rule is not law. It has to go through notice-and-comment rulemaking, and then HHS has to issue a final rule with its own effective and compliance dates (historically HIPAA final rules have given covered entities and business associates something like 180 days to a year to come into compliance after publication). As of now, no final rule has been published, so there is no new enforceable MFA/encryption mandate in effect. You should not represent to auditors, business partners, or your board that "the new Security Rule" is currently binding — it isn't yet.

That said, three things matter practically:

1. The current Security Rule (45 CFR §164.312) already lists encryption and decryption as an "addressable" implementation specification, and access control requires "unique user identification." Addressable does not mean optional — it means you must implement it unless you document a formal risk-based rationale for why it's not reasonable and appropriate for your environment, and adopt an equivalent alternative safeguard if you skip it. In practice, OCR enforcement actions and resolution agreements over the last decade have repeatedly penalized entities that had unencrypted PHI on laptops, servers, or backups with no compensating controls and no documented rationale. So even without the new rule, "we didn't encrypt because it was addressable" is a weak defense that has burned organizations in real settlements.

2. Multi-factor authentication isn't separately named in the current rule, but it's widely treated as an industry-standard control for remote access, privileged accounts, and email/cloud systems, and its absence is frequently cited as a contributing factor in breach investigations (e.g., business email compromise, ransomware entry via RDP). Cyber insurers, and many federal and state guidance documents, already effectively require it as a baseline control.

3. Because rulemaking of this kind rarely gets weaker between proposal and final rule, treating MFA and encryption as coming requirements — and building them now — is a low-regret move. Retrofitting encryption across systems and rolling out MFA org-wide takes real project time, and getting ahead of it avoids a compressed compliance sprint later.

What I'd recommend concretely: (1) don't tell stakeholders you are legally required to comply with the NPRM today — you're not; (2) update your risk analysis to explicitly document your current position on encryption and MFA as addressable/best-practice items, with rationale if anything is not yet implemented; (3) start or continue a project to implement encryption at rest and in transit for ePHI and MFA for all remote, administrative, and email access, since these are very likely to become mandatory and are good security hygiene regardless; (4) monitor the Federal Register and HHS OCR's site for the final rule's publication, since that will start the compliance-date clock; and (5) if you want to be safe from a documentation standpoint, have counsel or your compliance lead memorialize today's date and current control state so you can show a clear "before" baseline once the final rule lands.

I'm not a licensed attorney, and if this proposed rule has significant implications for your organization's budget or timeline, it's worth having outside HIPAA counsel confirm the current status before you communicate anything definitive internally.

Yes — OCR does enforce HIPAA against self-funded group health plans, and this is not a theoretical risk. It has become an active enforcement category, so I'd treat your plan as squarely in scope rather than assume enforcement is reserved for hospitals and insurers.

**Why you're a Covered Entity**

A self-funded group health plan is itself a "health plan" under 45 CFR §160.103, and health plans are one of the three categories of HIPAA Covered Entities (alongside healthcare providers who transmit electronically and healthcare clearinghouses). It doesn't matter that the employer isn't a hospital or a traditional insurance carrier — the *plan* is the covered entity, separate and apart from the employer's role as an employer. This is a common point of confusion: HIPAA does not apply to the employer acting in its employer capacity (e.g., HR records, disability accommodation files kept outside the plan), but it does apply to the plan itself, including PHI the plan receives from claims administrators, pharmacy benefit managers, or stop-loss carriers.

**Recent enforcement — this is happening now**

OCR has explicitly begun targeting self-funded group health plan sponsors as part of its Risk Analysis Initiative, which focuses on organizations that suffered a breach (often ransomware) and, on investigation, are found never to have conducted an accurate and thorough risk analysis. Two examples from 2026:
- **Star Group L.P.** — a $245,000 settlement (April 2026) tied to a ransomware incident, where OCR's investigation found the plan sponsor had not conducted an adequate risk analysis.
- **Spencer Gifts' self-funded plan** — a $450,000 settlement plus a Corrective Action Plan (June 2026), again following a ransomware event and a finding of an inadequate risk analysis.

Both cases follow the same pattern: a security incident (usually ransomware) triggers an OCR investigation, and the investigation exposes that the plan sponsor never did the foundational work — a documented, comprehensive risk analysis covering all systems that touch ePHI. This is consistently OCR's most-cited deficiency across all covered entity types, and plan sponsors are not being given a pass.

**Practical exposure for a plan sponsor**

Because you're self-funded, your obligations run deeper than a fully-insured employer's would (a fully-insured plan typically has minimal PHI exposure and correspondingly lighter HIPAA obligations). As a self-funded plan, you likely need:
- A designated Privacy Official and Security Official for the plan
- Plan document amendments requiring the plan sponsor to safeguard ePHI, restrict use to plan administration purposes, and report security incidents (45 CFR §164.314(b))
- A firewall between plan administration functions and the employer's other HR/business functions if plan sponsor employees have access to PHI
- BAAs with your third-party administrator, PBM, and any other vendor that creates, receives, maintains, or transmits PHI on the plan's behalf
- A current, documented Security Rule risk analysis covering all ePHI systems (this is exactly what OCR found missing in both recent cases)

**Action items I'd prioritize**

1. Confirm you have a documented, current risk analysis — not a vendor checklist, but one that actually maps threats/vulnerabilities/likelihood/impact across every system touching ePHI (see my risk analysis guidance if you want detail on that distinction).
2. Verify your plan documents contain the required §164.314(b) certifications for HIPAA compliance by the plan sponsor.
3. Confirm BAAs are in place and current with your TPA/PBM/any vendor.
4. Make sure incident response and breach notification procedures name the plan (not just the employer) as the entity with reporting obligations.

**Bottom line:** Assume you are enforceable, and prioritize the risk analysis — that's the single control both recent settlements turned on.

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

Yes — OCR does enforce HIPAA against self-funded, employer-sponsored group health plans, and this is one of the more commonly misunderstood corners of HIPAA applicability. The plan itself is a "covered entity" under the statute (specifically, a "health plan" as defined at 45 CFR §160.103), regardless of whether it's insured or self-funded. The employer as a business (the entity that pays wages, runs payroll, sells widgets, etc.) is not a covered entity, but the group health plan it sponsors is a separate legal construct for HIPAA purposes and is squarely within OCR's jurisdiction.

A few points that matter for your specific situation:

1. Self-funded does not mean exempt. People sometimes assume HIPAA "enforcement" is aimed at hospitals, doctors, clearinghouses, and insurance carriers, and that self-funded plans fly under the radar because there's no insurance company standing between the employer and the risk. That's incorrect. OCR's enforcement database and resolution agreements include self-funded plan sponsors, and the statute draws no distinction based on funding mechanism.

2. There is a narrow exception for very small self-administered plans. If a self-funded plan has fewer than 50 participants and is administered solely by the employer that established it (no third-party administrator at all), it is excluded from the HIPAA definition of "health plan." That's a narrow carve-out — the moment you use a third-party administrator, ASO arrangement, PBM, or any outside claims administrator (which is true of the overwhelming majority of self-funded plans), the exception doesn't apply and the plan is a covered entity.

3. The plan and the plan sponsor (employer) are legally distinct, and the rules require you to maintain that separation. If your health plan wants to share PHI with the employer for plan administration purposes (e.g., HR handling appeals, benefits staff resolving enrollment questions), the plan document must contain specific HIPAA "plan sponsor" provisions restricting use/disclosure to plan administration functions, requiring a firewall between employees who touch PHI and those who make employment decisions, and prohibiting use of PHI for employment-related actions or other benefit plans. Many employers get tripped up here — HR staff who also handle hiring/firing/promotions inappropriately having access to health claims data is a classic exposure.

4. Enforcement realities: OCR's Security Rule audits and breach investigations of self-funded plans are less frequent per-capita than for hospitals simply because there are more provider entities and more patient-facing incidents that generate complaints, but self-funded plans absolutely get investigated, especially following (a) a breach report (which is mandatory for breaches of unsecured PHI affecting the plan's participants), (b) a participant complaint to OCR, or (c) findings during audits of the TPA/ASO that surface plan sponsor deficiencies.

5. Business associate exposure flows both ways. Your TPA, stop-loss carrier data-sharing arrangements, wellness vendors, and any vendor touching claims data need BAAs. If your TPA has a breach, your plan (as the covered entity) typically bears breach-notification obligations to affected plan participants, even though the TPA caused it — so your BAA needs to clearly define notification timelines, cost allocation, and cooperation duties.

Practically, what I'd suggest for a self-funded employer plan: confirm you have HIPAA privacy and security policies specific to the plan (not just a generic HR privacy policy), confirm your plan document has the required plan-sponsor certification language if PHI flows to HR, confirm BAAs exist with your TPA/ASO, PBM, stop-loss carrier (to the extent PHI is shared), and any wellness or EAP vendor, designate a privacy official for the plan, and make sure whoever administers COBRA, appeals, or claims disputes on the employer side has been trained and is walled off from employment-decision functions. If you haven't done a HIPAA risk analysis specific to the plan's data flows (versus just relying on the TPA's own compliance), that's usually the biggest gap I see in self-funded employer plans, and it's exactly the kind of gap that surfaces during an OCR investigation after a breach.

This is general compliance information, not legal advice — for a definitive read on your plan's specific structure (fully self-administered vs. TPA-administered, size, funding arrangement), I'd loop in ERISA/HIPAA counsel.

This is a clear Right of Access violation, and eight months is well past the point where I'd call this low risk. Here's the exposure and what to do right now.

**The rule you've violated**

Under 45 CFR §164.524, a patient has the right to inspect and obtain a copy of their PHI in a designated record set. You must provide access **within 30 days** of the request, with a single 30-day extension permitted if you provide the patient written notice of the delay and the reason within the initial 30-day window. Even with the maximum extension taken and documented, the outer limit is 60 days. At eight months (roughly 240 days), you are approximately six months past even the most generous permissible timeline — and that's assuming an extension notice was sent, which it doesn't sound like it was.

**Your specific exposure**

1. **OCR enforcement — this is an active priority, not a hypothetical.** OCR's Right of Access Initiative has now resulted in 55 enforcement actions. The most recent, against Azul Vision ($50,000 settlement, August 27, 2026), involved records delivered roughly two years late — a stark reminder that OCR treats access delays as an independently enforceable violation, not a paperwork technicality. Settlements in this initiative have generally ranged from $5,000 to low six figures depending on delay length, number of affected patients, and whether it's a pattern versus an isolated incident. An eight-month delay puts you toward the more serious end of that range if it becomes a pattern rather than a one-off.

2. **Civil monetary penalty exposure.** Independent of a negotiated settlement, HIPAA's tiered CMP structure applies: even in the lowest tier ("did not know, with reasonable diligence"), penalties run from roughly $137 to $68,928 per violation, capped at about $2,067,813 per year per violation category. A single unreasonably delayed access request is unlikely to trigger the top of that range on its own, but it establishes a documented violation that increases scrutiny if there's any pattern across other patients.

3. **State law exposure.** Many states have their own patient access laws with independent penalties and, in some states, private rights of action — check your state's requirements, since HIPAA is a floor, not a ceiling.

4. **Reputational and complaint risk.** Patients whose access requests are ignored frequently escalate directly to OCR by filing a complaint, which is very likely how these Right of Access cases originate. A frustrated patient at eight months has every reason to do so.

**What to do immediately**

1. **Produce the records now**, in the format requested if reasonably producible, without further delay. Stopping the bleeding is the single highest-value action — OCR's Right of Access resolutions consistently credit prompt corrective action once discovered.
2. **Document why the delay happened** — was it a system limitation, a staffing gap, an actual dispute about the designated record set, or was the request simply lost? You need an honest root-cause record, not just for OCR but for your own risk management process.
3. **Do not charge more than a cost-based fee** (labor, supplies, postage) — no retrieval fees — and don't let a fee dispute become the vehicle for further delay.
4. **Check for a pattern.** Is this a one-off dropped request, or a symptom of a broken request-intake process? OCR's investigations often expand once one complaint surfaces a systemic gap.
5. **Update your policies and train staff** on the request intake path, the 30/60-day clock, and required extension notices, and document that training.
6. **Consider self-reporting or at least preparing your response** if the patient files an OCR complaint — a demonstrated corrective action plan meaningfully affects how OCR resolves these cases.

**Bottom line:** you have a real, documented violation with real financial exposure, but the fastest way to reduce it is immediate production of the records plus a documented corrective action — not waiting to see if the patient complains.

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

This is a real compliance failure, not a gray area, and eight months is far enough past the deadline that you should treat it as an active exposure needing immediate remediation rather than something to quietly finish whenever convenient.

Here's the baseline rule: under the HIPAA Privacy Rule's right of access provision (45 CFR §164.524), a covered entity must act on a request for records within 30 calendar days of receipt. There is a single allowable 30-day extension, but only if you notify the individual in writing, within the original 30-day period, of the reason for the delay and the date by which you will provide the records. That means the absolute outer bound, even using the extension properly, is 60 days. If no extension notice was ever sent, the outer bound was 30 days. Either way, at eight months (roughly 240 days) you are somewhere between 180 and 210 days past even the most generous legitimate deadline, with apparently no extension notice on record based on how you've described it.

Why this matters more than it might seem: OCR has run a standalone "Right of Access Initiative" since 2019 specifically targeting slow or non-responsive record requests, and it has resulted in dozens of settlements, many against small and mid-sized providers, with penalties ranging from roughly $15,000 up to $200,000+ per case, plus corrective action plans with multi-year OCR monitoring. Delay length is one of the factors OCR weighs, and several settled cases involved delays in the several-months range similar to yours. This is one of the few HIPAA areas where OCR has been aggressively and publicly proactive rather than purely complaint-driven, so "we're a small practice, nobody will notice" is not a safe assumption.

Your exposure has several layers:

1. Regulatory: if the patient or someone on their behalf files a complaint with OCR (or the relevant state attorney general, many of which now also enforce patient access independently), you're a strong candidate for an investigation, and the fact pattern — flat non-response for eight months, no apparent extension notice — is exactly the profile OCR has pursued before. Corrective action plans following these settlements often include mandatory policy revisions, staff retraining, and 1-3 years of self-reporting to OCR, which is its own operational burden beyond the fine.

2. Reputational/relationship: an aggrieved patient waiting eight months for their own records is likely to escalate — complaint to OCR, complaint to your state licensing board, negative reviews, or in some states a private right of action or small-claims style remedy tied to state medical-records statutes (which often have their own separate, sometimes shorter, deadlines and penalty structures layered on top of HIPAA).

3. Operational root cause: an eight-month gap usually signals something is broken procedurally — a request that fell through the cracks, no tracking system for access requests, unclear ownership of who processes them, or a bottleneck (e.g., waiting on a EHR vendor export, or requiring in-person pickup that never got scheduled). If it happened once, it's worth checking whether other requests are similarly stuck.

What I'd do right now, in order: (1) produce the records to the patient immediately — do not wait for a complaint to force it, since remediation speed is one of the factors OCR and courts consider in assessing severity; (2) draft an apology/transparency communication to the patient - not an admission of specific legal violations without counsel's input, but acknowledgment of the delay and confirmation the records are now provided; (3) preserve your internal records of when the request was made, why it stalled, and what changed to finally produce it, since you'll want this if OCR or the patient does follow up; (4) audit whether any other outstanding access requests exist in your system right now with the same problem; (5) fix the process — implement a tracked intake log for access requests with calendar reminders at day 20 (to trigger extension review) and day 28 (to force action or a documented extension letter); and (6) loop in HIPAA/healthcare counsel now, proactively, rather than after a complaint arrives, especially if this patient seems litigious or has already threatened to escalate — counsel can help you decide whether any voluntary disclosure or self-report to OCR is advisable given your specific facts.

I'm not a lawyer, and given real penalty exposure here, this is a case where you want counsel's eyes on the specific facts (what the request said, whether any extension notice went out, your state's own medical records statute) before you finalize your response strategy.

A filled-in vendor checklist is almost certainly **not** a compliant risk analysis, and this is worth fixing before it becomes a problem — it is the single most commonly cited deficiency in OCR enforcement actions, including two 2026 settlements against self-funded group health plan sponsors (Star Group L.P., $245K, and Spencer Gifts, $450K + Corrective Action Plan) that both turned on exactly this gap: no accurate, thorough risk analysis, discovered only after a ransomware incident.

**Why a checklist usually fails the standard**

The Security Rule (§164.308(a)(1)(ii)(A)) requires an "accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI." A generic checklist typically fails because it:
- Asks yes/no questions about controls rather than analyzing threats against vulnerabilities for *your specific* environment
- Doesn't scope all ePHI — most checklists focus only on the EHR and miss email, mobile devices, backups, cloud storage, and printers/copiers with hard drives
- Assigns no real methodology for likelihood and impact, so "risk levels" are essentially guesses rather than a defensible calculation
- Is done once and never updated, when it needs to be a living process tied to system and threat changes
- Produces no risk management plan — a list of gaps isn't a risk analysis if it doesn't translate into prioritized remediation with dates and owners

HHS has been explicit that these are the recurring findings in OCR investigations, and "we bought a checklist tool" is not a defense OCR accepts.

**What an actual compliant risk analysis requires**

1. **Scope** — every system, application, and location that creates, receives, maintains, or transmits ePHI: EHR, practice management, billing, email, laptops/mobile devices, backups/DR systems, cloud services, physical servers — not just the "big" system.
2. **Threat identification** — natural, human (malicious and accidental), and environmental threats relevant to each asset.
3. **Vulnerability identification** — specific weaknesses (e.g., no MFA, unpatched software, no offsite backup, shared logins).
4. **Likelihood assessment** — a documented judgment (not arbitrary) of how probable each threat/vulnerability pairing is.
5. **Impact assessment** — the potential harm if it occurs (breach scope, operational disruption, financial/legal exposure).
6. **Risk level determination** — combine likelihood and impact using a stated, consistent methodology (HHS points to NIST SP 800-30 for methodology and NIST SP 800-66 for HIPAA-specific guidance).
7. **Current controls inventory** — what's already mitigating each risk, and how effective it actually is.
8. **A resulting Risk Management Plan** — prioritized remediation actions tied to the risk levels, with owners and target dates; this is a separate required activity (§164.308(a)(1)(ii)(B)), not just the analysis itself.

**How to fix what you have**

Don't necessarily throw away the vendor checklist — it may be useful raw input — but it needs to become the front end of a real analysis:
1. Inventory every ePHI-touching system/asset (the checklist may have missed several categories above).
2. For each asset, walk through threat/vulnerability/likelihood/impact deliberately, with your own team's knowledge of your actual environment, not generic industry answers.
3. Assign risk levels using a stated methodology, applied consistently.
4. Turn the findings into a written Risk Management Plan with prioritized action items — this is what OCR looks for as evidence the analysis was actually used, not just filed away.
5. Date it, version it, and set a review cadence (annually, and after any material system change, incident, or expansion).
6. Retain documentation for 6 years (§164.316(b)).

**Bottom line:** a checklist tells you what to think about; a risk analysis tells you, in your own documented judgment, how likely and how bad each specific risk is in your environment, and what you're doing about it in priority order. If your current document can't answer "why is this risk rated High and what are we doing about it, by when, and who owns it," it isn't there yet.

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

A filled-in checklist is not a HIPAA-compliant security risk analysis, and this is one of the most common — and most heavily penalized — gaps OCR finds. It's worth understanding why a checklist fails the standard, and what an actual risk analysis needs to contain.

The requirement comes from the Security Rule's Administrative Safeguards at 45 CFR §164.308(a)(1)(ii)(A), which requires covered entities and business associates to "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." NIST SP 800-30 and HHS's own guidance on this provision (HHS publishes a specific guidance document, "Guidance on Risk Analysis Requirements under the HIPAA Security Rule") flesh out what "accurate and thorough" actually means, and a generic yes/no checklist almost never meets it. This has been one of the single most frequently cited failures in OCR resolution agreements over the last 15 years — organizations that had "done a risk assessment" in the sense of buying a template, filling in checkboxes, and filing it away, only to have OCR determine post-breach that no real risk analysis had occurred.

A checklist typically fails because it asks "do you have policy X? yes/no" rather than analyzing your actual environment. A real risk analysis needs to include, at minimum:

1. Scope: every system, application, and location where ePHI is created, received, maintained, or transmitted — not just your EHR, but email, backup systems, cloud storage, mobile devices, fax/e-fax, medical devices, third-party portals, and business associate systems that touch your data.

2. Data flow mapping: where ePHI actually moves — inbound from referrals, outbound to labs/pharmacies/payers, internal transfers between departments, remote access paths, backup and disaster recovery flows. You can't assess risk to data you haven't located.

3. Threat and vulnerability identification specific to your environment: not generic "hackers exist" language, but actual identified threats (e.g., unpatched legacy systems, unencrypted laptops, shared login credentials, lack of network segmentation, vendor access without monitoring, ransomware exposure via RDP) mapped against actual vulnerabilities discovered in your systems.

4. Current control assessment: what safeguards are actually in place today (technical, administrative, physical) and whether they adequately address the identified threats/vulnerabilities.

5. Likelihood and impact analysis: for each identified risk, an actual assessment of the probability it materializes and the magnitude of harm if it does — this is the "risk" part of risk analysis, and it's exactly the part a checklist skips, since checklists document presence/absence of controls but not the resulting risk level.

6. A risk rating and prioritized remediation plan: outputs need to translate into a documented risk level (e.g., high/medium/low) per finding, tied to a remediation roadmap with owners and target dates. This feeds directly into the required risk management process under §164.308(a)(1)(ii)(B).

7. It needs to be organization-specific and current: a generic template that could apply to any healthcare entity, filled in by a vendor who never actually reviewed your network diagram, asset inventory, or system configurations, is a strong signal to an investigator that the "assessment" was a paperwork exercise. OCR guidance explicitly calls for periodic review/updates — after any material change (new systems, EHR migration, cloud move) and generally at least annually.

Practical red flags that your vendor's checklist is not sufficient: no asset inventory attached, no network diagram, no evidence anyone reviewed actual configurations (firewall rules, encryption status, access control lists), no likelihood/impact scoring, generic findings that would read identically for any client, and no resulting remediation plan with dates and owners.

What I'd recommend: treat the vendor checklist as one input, not the deliverable. Commission (or perform internally, with executive sponsorship) an actual risk analysis that starts with an asset and data-flow inventory, involves IT/security staff who know your actual environment, produces documented likelihood/impact ratings per risk, and results in a remediation plan that feeds your risk management process. Keep the checklist, the new analysis, and your remediation tracking as a package — OCR investigators and auditors want to see the full lifecycle (identify risk, prioritize, remediate, re-assess), not a single static document.

This is compliance guidance, not legal advice; if you're remediating this ahead of a known audit or after a breach, it's worth having HIPAA counsel review the final work product before you rely on it as your defensible risk analysis.

A cloud vendor hosting your EHR will create, receive, maintain, and transmit ePHI on your behalf, which makes it a Business Associate under HIPAA — a BAA is mandatory before any PHI touches their systems, including during migration/testing. Here's what the agreement must contain (45 CFR §164.504(e), §164.314(a)).

**Required substantive provisions**

1. **Permitted uses and disclosures** — The BAA must specifically describe how the vendor may use/disclose PHI: to perform the hosting services, for its own proper management and administration (if it obtains reasonable assurances of confidentiality and breach notification), and as required by law. It may not use PHI for any purpose beyond what the agreement authorizes.

2. **Prohibition on unauthorized use/disclosure** — An explicit statement that the vendor will not use or disclose PHI other than as permitted by the agreement or required by law.

3. **Safeguards requirement** — The vendor must commit to implementing appropriate administrative, physical, and technical safeguards consistent with the Security Rule (§§164.308, 164.310, 164.312) to protect the confidentiality, integrity, and availability of ePHI it hosts. For an EHR specifically, I'd push for the BAA (or an attached security addendum) to specify encryption at rest (AES-256) and in transit (TLS 1.2+), MFA for administrative access, and audit logging — these aren't automatically baked into a generic BAA template and are worth naming explicitly given what's actually being hosted.

4. **Subcontractor flow-down** — The vendor must require any of its own subcontractors that will touch your PHI (e.g., a sub-processor providing backup, monitoring, or support services) to agree in writing to the same restrictions and conditions that apply to the vendor. This is critical for cloud hosting because most cloud vendors rely on underlying infrastructure providers (AWS, Azure, GCP) — confirm the chain of BAAs actually extends all the way down.

5. **Breach and security incident reporting** — The vendor must report to you: (a) any breach of unsecured PHI without unreasonable delay and within 60 days of discovery, and (b) any security incident, including unsuccessful attempts, per the timeline you negotiate. Your own 60-day clock for notifying patients and HHS runs from whichever is earlier — your discovery or the vendor's notification — so I'd negotiate for the vendor's reporting window to be materially shorter than 60 days (many hosting BAAs commit to 5-10 business days) so you retain enough runway to meet your own downstream deadlines.

6. **Access for patient rights** — The vendor must make PHI available to you as needed so you can respond to a patient's right of access request (§164.524) within your own 30-day (+30) statutory window, and must support your ability to respond to accounting-of-disclosures requests (§164.528). For an EHR vendor specifically, confirm the platform actually supports timely export in the format patients may request — this is a functional requirement, not just a contractual one.

7. **HHS audit access** — The vendor must make its internal practices, books, and records relating to PHI available to HHS for compliance investigations.

8. **Return or destruction of PHI at termination** — Upon contract termination, the vendor must return or destroy all PHI if feasible; if not feasible (common with backups), the agreement must state that protections continue to apply to any PHI retained. For an EHR specifically, negotiate the mechanics up front: data export format, timeline, and whether you retain read access during a transition period to a new vendor.
9. **Termination rights** — Either party may terminate the underlying agreement if the other has materially violated a term and failed to cure it, and the agreement should state this triggers return/destruction obligations.

**Practical additions I'd insist on for an EHR cloud host specifically**

- Data residency/location commitments (which region(s) host your data)
- Named subcontractors/sub-processors disclosed and kept current
- Right to audit or receive third-party audit reports (SOC 2 Type II, HITRUST) annually
- Defined uptime/availability SLA tied to your contingency plan obligations, since an EHR outage is a patient-safety issue, not just a compliance one
- Explicit encryption key management terms — who holds the keys, and whether they're customer-managed

**Bottom line:** the BAA has mandatory legal content (permitted uses, safeguards, subcontractor flow-down, breach reporting, HHS access, patient-rights support, and termination/return-of-data terms), but for an EHR host specifically, don't stop at the boilerplate — negotiate concrete security and breach-notification-timeline specifics, because the generic template language leaves too much ambiguity for a system this central to your ePHI.

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

A cloud vendor hosting your EHR is a business associate under HIPAA — even if it never actually opens or views the PHI, the mere fact that it stores or transmits ePHI on your behalf triggers the requirement — so you need a Business Associate Agreement (BAA) before any PHI touches that environment, not as a formality after the fact. Here's what needs to be in it, drawing on the required elements at 45 CFR §164.314(a) and §164.504(e).

1. Permitted uses and disclosures. The BAA must specify exactly what the vendor is allowed to do with the PHI — generally limited to providing the hosting/EHR service itself, plus narrowly defined activities like the vendor's own management/administration or legal responsibilities, and data aggregation if applicable. It should explicitly prohibit any use or disclosure beyond what the underlying services agreement requires, and prohibit any use for the vendor's own marketing, product development, or resale purposes unless you've separately and explicitly agreed to that (and even then, additional authorization requirements may apply).

2. Safeguards commitment. The vendor must agree to implement appropriate administrative, physical, and technical safeguards to prevent unauthorized use or disclosure of the PHI, and — since this is ePHI hosted in the cloud — the BAA should explicitly incorporate compliance with the Security Rule's safeguards (access controls, audit controls, integrity controls, transmission security, encryption where appropriate), not just the general Privacy Rule safeguard language.

3. Reporting obligations. The BAA must require the vendor to report to you any use or disclosure not permitted by the agreement, and — critically — any security incident it becomes aware of, and any breach of unsecured PHI, within a specified timeframe. Since you as the covered entity have your own 60-day breach notification clock to patients/HHS, your BAA needs a tighter internal deadline for the vendor to notify you (many organizations negotiate 24-72 hours for the vendor to report a known or suspected breach) so you have runway to meet your own obligations.

4. Subcontractor flow-down. If the cloud vendor uses its own subcontractors that will have access to PHI (e.g., a subprocessor providing infrastructure, backup, or support services), the BAA must require the vendor to ensure those subcontractors agree to the same restrictions and conditions via their own BAA-equivalent agreements. This is especially relevant for cloud hosting, where infrastructure providers (underlying cloud platform), monitoring tools, backup vendors, and support/ticketing systems may all touch PHI indirectly.

5. Individual rights support. The agreement must require the vendor to make PHI available to you (or, per your instructions, directly to the individual) to support patient access requests, and to make amendments to PHI as directed, and to provide an accounting of disclosures as needed to support your obligations under the Privacy Rule.

6. Availability to HHS. The vendor must agree to make its internal practices, books, and records relating to PHI use/disclosure available to HHS for compliance determination purposes.

7. Return or destruction of PHI at termination. At the end of the relationship, the BAA must require the vendor to return or destroy all PHI it holds, if feasible; if return/destruction isn't feasible (a real issue with cloud backups and replicated storage), the agreement must extend the same protections to the retained PHI for as long as it's retained and limit further uses/disclosures to those purposes that made return/destruction infeasible.

8. Termination rights. You need the right to terminate the agreement if the vendor materially violates the BAA terms, and if termination isn't feasible, the right to report the violation to HHS.

Beyond the strict regulatory minimums, a few practical items worth negotiating specifically for a cloud EHR hosting arrangement: data residency/location commitments (where the data centers are physically located), encryption specifications (at rest and in transit, key management ownership), audit rights (your ability to request SOC 2 reports, penetration test summaries, or conduct your own security assessment), data portability/export commitments so you're not locked in if you switch vendors, defined uptime/availability SLAs since this is your EHR, cyber insurance requirements, and indemnification allocation for breach-related costs (notification, credit monitoring, regulatory fines attributable to the vendor's failure).

Before you sign, confirm this BAA is a standalone agreement or a properly incorporated addendum/exhibit to the master services agreement, that it doesn't conflict with liability caps or indemnification language elsewhere in the contract, and that your own IT/security team has actually validated the technical safeguard claims (don't just accept a BAA's promises — request the vendor's HITRUST certification, SOC 2 Type II report, or equivalent independent attestation).

This is general guidance, not legal advice — given how central an EHR hosting relationship is to your compliance posture, I'd have healthcare/HIPAA counsel review the final BAA and its interplay with the broader services contract before execution.

Yes — there is a NIST publication specifically for transit agencies, and it's very recent.

**NIST IR 8576 — Transit Cybersecurity Framework Community Profile** was finalized on August 5, 2026. It's a CSF 2.0 Community Profile built specifically for U.S. transit agencies operating bus, subway/rail, and commuter rail systems — which matches your organization directly. A "Community Profile" in NIST CSF terms is a pre-built Target Profile developed by and for a specific sector, so that individual organizations don't have to build a target state from scratch. It reflects the shared risk priorities, threat landscape, and operational-technology (OT) realities common to transit operators — think fare collection systems, positive train control / signaling, SCADA for traction power, CCTV and access control at stations and yards, and the IT/OT convergence that comes with connected fleet and infrastructure.

A few important framing points:

1. **It complements, not replaces, your existing program.** NIST IR 8576 is explicitly designed to sit alongside whatever cybersecurity program you already run — it is not a compliance mandate and does not override FTA, TSA Security Directives, or other regulatory obligations you may have. Treat it as a sector-tuned starting point for your CSF 2.0 Target Profile, not a checklist to certify against.

2. **How to use it practically**: Start by comparing the subcategories the Community Profile emphasizes against your Current Profile (your actual state today). Because transit is OT-heavy, expect the profile to weight several categories more heavily than a generic enterprise target would:
   - **GV.SC** (Cybersecurity Supply Chain Risk Management) — vendor-supplied signaling, fare, and SCADA systems carry outsized risk and are hard to patch or replace on short notice.
   - **PR.IR** (Technology Infrastructure Resilience) — redundancy and resilience for OT/ICS environments controlling rail and bus operations.
   - **PR.AA** (Identity Management, Authentication, and Access Control) — especially physical access control at stations, yards, and control centers (PR.AA-06).
   - **DE.CM** (Continuous Monitoring) — OT environments often have limited native logging, so monitoring coverage tends to be a real gap.
   - **RS.MA / RC.RP** — incident and recovery plans need to explicitly account for safety-of-life and service-continuity implications unique to transit (a "recovery" isn't done until trains/buses are safely running again, not just when IT systems are restored).

3. **Sequencing**: As with any CSF adoption, don't jump straight into PR/DE/RS work. Establish GV.OC (organizational context — safety mission, regulatory obligations under FTA/TSA) and GV.RM (risk tolerance) first, then build/validate your asset inventory (ID.AM) covering both IT and OT assets, before layering in the transit-specific Community Profile priorities.

4. **Two other recent NIST companion publications are worth knowing about, though they're general-purpose rather than transit-specific**:
   - **NIST SP 1353** (initial public draft, Aug 19, 2026, comments due Oct 15, 2026) — a quick-start guide on using generative AI to support CSF analysis, planning, and profile drafting. If you're considering AI-assisted tooling to accelerate your gap assessment or profile-building work, this is the relevant guidance (illustrative use cases, not a certified methodology).
   - **NIST SP 1347** (final, Aug 25, 2026) — explains how CSF 2.0 Informative References and crosswalks work, useful if you need to map your transit profile back to NIST SP 800-53, TSA requirements, or other frameworks your agency is already subject to.

**Recommended next step**: I can help you build a gap assessment or Target Profile using NIST IR 8576 as the baseline, layered against your current cybersecurity state and any FTA/TSA-mandated controls. If you share your current maturity (e.g., do you have documented asset inventories for OT systems, an existing incident response plan, etc.), I can produce a Function-by-Function gap table with priorities.

This is general informational guidance based on publicly available NIST publications, not legal or audit advice — for a transit-specific security directive or certification determination, involve qualified counsel or an accredited assessor, and confirm details against the primary NIST IR 8576 document and any applicable TSA Security Directives.

Short answer: NIST itself does not publish a transit-specific version of the Cybersecurity Framework (CSF), but there is a well-developed body of sector guidance you should layer on top of CSF 2.0, and several transit-focused resources that map directly to CSF functions and categories.

1. NIST CSF 2.0 as your foundation
CSF 2.0 (released February 2024) is deliberately sector-agnostic. It gives you six functions — Govern, Identify, Protect, Detect, Respond, Recover — and expects each sector or company to build an "organizational profile" that tailors the subcategories to its own risk context. For a transit agency, that context includes both IT (fare systems, HR, finance, email) and OT/ICS (train control, signaling, SCADA for traction power, positive train control, transit signal priority, CCTV, fare gates, and increasingly connected/autonomous vehicle systems). CSF's Govern function is a good fit for transit because it forces explicit conversations about risk appetite, board/leadership oversight, and supply chain risk — all things transit agencies historically underinvested in relative to safety-critical operations.

2. Surface transportation / transit-specific guidance to combine with CSF
- TSA Security Directives and the TSA/DHS "Surface Transportation Cybersecurity Toolkit" — TSA has issued cybersecurity requirements for higher-risk surface transportation entities (originally aimed at freight rail and rail transit, with some extension to other modes) requiring designation of a cybersecurity coordinator, incident reporting to CISA, a cybersecurity implementation plan, and vulnerability assessments. These directives explicitly reference NIST CSF as an acceptable framework for structuring your program.
- APTA (American Public Transportation Association) has published cybersecurity guidance and recommended practices for transit systems, including a Control and Communications Security recommended practice and enterprise cybersecurity framework guidance for both rail and bus operations. APTA's work is generally structured to align with, or explicitly reference, the NIST CSF functions.
- FTA (Federal Transit Administration) has issued cybersecurity guidance and resources for transit agencies, including recommendations tied to the NIST CSF and to safety management systems (since FTA regulates transit safety via SMS/PTASP).
- CISA's Transportation Systems Sector guidance and the Sector-Specific/Sector Risk Management Agency materials for transportation include cyber-physical convergence guidance relevant to rail and bus signaling systems.
- NIST's own cross-sector guidance for industrial control systems — NIST SP 800-82 (Guide to Operational Technology Security) — is directly relevant to your rail signaling, SCADA, and traction power systems, and NIST SP 800-53 provides the control catalog you'd use if you need to get more granular than CSF subcategories.

3. Practical approach
- Treat CSF 2.0 as your governance and communication framework (useful for board reporting, budget justification, maturity tracking, and cross-department alignment between IT security, OT/rail engineering, and safety).
- Use TSA Security Directive requirements and CISA reporting obligations as your compliance floor — these are mandatory if you're a designated higher-risk agency.
- Use APTA and FTA recommended practices for transit-specific operational detail (e.g., segmentation guidance for train control networks, fare system PCI considerations, CCTV/access control convergence).
- Use SP 800-82 for OT-specific control selection within your Protect/Detect subcategories.
- Build a single organizational profile that explicitly separates IT and OT/safety-critical asset categories, since transit agencies typically have very different risk tolerances and change-management constraints between the two (a signaling system patch cadence is nothing like a corporate laptop patch cadence).

4. Governance note
Given TSA's mandatory security directives for transit, I'd recommend explicitly cross-walking your CSF profile subcategories to the TSA directive requirements (cybersecurity coordinator designation, incident reporting timelines, vulnerability assessment cadence, implementation plan content) so you have one profile that satisfies both your voluntary CSF maturity goals and your regulatory obligations. If you're not sure whether your agency is currently designated as "higher-risk" under the TSA directives, that's worth confirming with your general counsel or TSA point of contact, since it changes which requirements are mandatory versus best-practice.

In short: no CSF-transit crosswalk exists as an official NIST publication, but combining CSF 2.0 with TSA's surface transportation directives, APTA/FTA guidance, and NIST SP 800-82 for OT gives you a defensible, sector-appropriate program.

Yes, there is NIST guidance on this, and yes, generative AI can support your CSF assessment work — with important caveats on scope and reliability.

**The relevant publication**: NIST SP 1353, released as an initial public draft on August 19, 2026 (public comment period open through October 15, 2026). It's a quick-start guide specifically on using generative AI for CSF analysis, planning, and reporting. Because it's still in draft/comment status, treat its guidance as provisional — it may change before finalization, and you should revisit it once the final version is published.

**What SP 1353 covers**: The draft lays out three notional use cases where generative AI can meaningfully accelerate CSF work:

1. **Governance and policy review** — using AI to review existing cybersecurity policies against GV function subcategories (e.g., GV.PO-01, GV.PO-02), flag gaps in language, or draft/redline policy sections faster than manual review alone.
2. **Current State Profile drafting** — using AI to help synthesize existing documentation, control evidence, interview notes, or audit findings into a structured Current Profile (subcategory-by-subcategory current-state ratings), which is normally one of the more labor-intensive parts of a gap assessment.
3. **Target State Profile drafting** — using AI to help translate business requirements, risk appetite statements, and regulatory obligations into a draft Target Profile, which a human reviewer then validates and adjusts.

Critically, NIST frames these as **illustrative use cases, not a prescriptive or certified assessment methodology**. That distinction matters for how you should actually use this in practice:

- **AI can accelerate drafting and synthesis, but it cannot perform the assessment itself.** A gap assessment's Current State ratings must be grounded in actual evidence (interviews, control testing, log review, documentation) — an AI model does not have visibility into your environment and cannot independently verify whether a control is "Fully Implemented" versus "Partially Implemented." Any AI-drafted profile is a starting hypothesis that a qualified human assessor must validate against real evidence.
- **Human review and sign-off remain mandatory.** Given that CSF profiles often feed into audit, regulatory, or board-level risk reporting, AI-drafted content should be clearly marked as a draft pending review, with a named human owner accountable for the final version.
- **Watch for hallucinated specificity.** Generative AI is prone to fabricating plausible-sounding subcategory mappings, control citations, or maturity justifications. Anyone using AI output in a formal profile should independently verify every subcategory ID and every specific claim about control implementation against the actual NIST CSF 2.0 text and your organization's real evidence — do not take AI-generated citations at face value.
- **Confidentiality and data handling matter.** If you're feeding internal risk assessments, control gaps, or incident history into a generative AI tool to help draft profiles, make sure that's consistent with your data classification and vendor risk policies (this itself is a PR.DS / GV.SC consideration) — don't paste sensitive risk data into a public-facing AI tool without going through your normal data-handling approval process.

**Practical way to apply this to your program**:
- Use AI (including a tool like this one, equipped with the CSF skill) to help draft your subcategory-by-subcategory Current Profile table from existing documentation you provide, and to draft a proposed Target Profile from your stated risk tolerance and regulatory obligations.
- Have your risk/security team validate every Current State rating against actual evidence before it's finalized.
- Use AI to help draft the narrative sections of your gap assessment report and implementation roadmap — this is lower-risk since it's not asserting factual control status.
- Keep a human owner of record for the final profile and gap assessment; the AI-assisted draft should never be the artifact that goes to auditors or the board without a documented human review step.

Since SP 1353 is still an initial public draft with comments due October 15, 2026, I'd also recommend checking whether your organization wants to submit feedback, and revisiting your approach once NIST finalizes the guide — the final version may narrow or expand the recommended use cases.

This is general informational guidance based on a NIST draft publication, not legal or audit advice. Verify current requirements against the official NIST SP 1353 draft (and its eventual final version), and consult qualified compliance counsel before relying on AI-assisted assessments for regulatory or audit purposes.

Short answer: yes, generative AI can meaningfully accelerate a CSF assessment and profile-drafting process, and NIST has published relevant guidance — though not a single document titled "how to use GenAI for CSF assessments." You'll need to combine a few sources and apply sound judgment about where AI assistance is appropriate versus where it introduces risk.

1. Relevant NIST guidance
- NIST AI RMF 1.0 (AI Risk Management Framework) and its Generative AI Profile (NIST AI 600-1) are the primary references for how to think about risks introduced by using AI tools in your own operations, including risks like confabulation/hallucination, data leakage, and overreliance on automated output. If you use GenAI to help write your CSF profile, that use itself is an AI risk management question, and AI RMF's Govern/Map/Measure/Manage functions are a natural complement to CSF's own Govern function.
- CSF 2.0's Govern function (GV.OV, GV.RM, GV.SC, etc.) is exactly where AI-assisted tooling decisions belong — you should document in your governance records that GenAI tools are used to support (not replace) the assessment, who reviews the output, and what data is or isn't fed into the tool.
- NIST has also published guidance specifically on AI and cybersecurity risk (e.g., NIST IR drafts on adversarial machine learning, and CSF Quick-Start Guides that occasionally reference AI as an emerging risk area to consider under Identify's risk assessment category), but none of this constitutes a certified "use ChatGPT to fill out your CSF profile" methodology.

2. Where GenAI genuinely helps
- Drafting narrative text for organizational profile sections (mission statement framing, risk appetite language, subcategory implementation descriptions) based on interview notes or existing policy documents you feed in.
- Summarizing long policy/procedure documents to identify which CSF subcategories they already address, speeding up the "current profile" gap analysis.
- Generating a first-pass crosswalk between your existing controls (e.g., ISO 27001, SOC 2, CIS Controls) and CSF subcategories, which you then validate.
- Drafting interview questions and evidence-request lists for control owners.
- Turning raw assessment notes into a structured target profile document, tiering language (Tier 1–4), and gap-analysis tables.

3. Where you should not lean on GenAI unsupervised
- Actual risk ratings or maturity tier determinations — these require organizational judgment, actual evidence review, and accountability; an LLM has no visibility into your real environment and can confidently state something plausible but wrong.
- Feeding sensitive data (asset inventories, vulnerability scan results, incident details, network diagrams) into a public/consumer GenAI tool. If you use GenAI for this work, use an enterprise-tier tool with a data processing agreement and confirm your inputs aren't used for model training, or use an internally hosted model.
- Treating AI-generated subcategory implementation statements as automatically evidenced/true — every claim in your profile ("we implement PR.AC-1 via X") needs an actual control owner to confirm and ideally attach evidence.
- Final sign-off — the CSF profile is a governance artifact; leadership and control owners need to review and approve the substance, not just skim AI output.

4. Practical workflow recommendation
- Use GenAI as a drafting and summarization assistant, not a decision-maker.
- Keep a human-in-the-loop review step for every subcategory before it's marked "implemented" in your profile.
- Log which parts of the assessment used AI assistance, consistent with your organization's AI governance policy (this is itself a good CSF GV.SC / GV.PO practice to document).
- If your organization already has an internal generative AI acceptable-use policy or an AI governance committee, route this use case through it, since assessment documents can contain sensitive risk information.
- Consider building a lightweight internal "prompt library" for common CSF assessment tasks (e.g., "summarize this policy against CSF subcategory X.X and flag gaps") so results are consistent across assessors and reviewers.

In short: NIST's AI RMF and Generative AI Profile are the closest things to official guidance on using AI tools responsibly, and CSF 2.0's Govern function is where you document how you're using them. There's no NIST-endorsed "AI-run CSF assessment" methodology — treat GenAI as an efficiency tool for drafting and synthesis, with humans owning every judgment call and sign-off.

**How CSF 2.0 Informative References work**

Unlike CSF 1.1, where Informative References (mappings to other frameworks and standards) were embedded directly in the framework document, CSF 2.0 moved them entirely online into the **NIST CSF 2.0 Reference Tool** (https://csrc.nist.gov/Projects/cybersecurity-framework/Filters#/csf/filters). This was a deliberate design change: informative references need to be updated far more often than the core framework itself (standards get revised, new frameworks emerge), so decoupling them from the static CSF document lets NIST — and the community — keep mappings current without re-publishing the whole framework.

The mechanism behind this is the **Online Informative References (OLIR) Program**. Organizations and framework owners (including NIST itself, but also third parties) can submit a formal mapping between their framework's controls and CSF subcategories, following NIST's OLIR submission specification. NIST reviews and publishes accepted mappings in the Reference Tool. This means:

- Informative references are **crowdsourced and versioned**, not fixed in the CSF text.
- You can query the Reference Tool by CSF subcategory (e.g., "what maps to PR.AA-05?") or by source framework (e.g., "show me all ISO 27001:2022 mappings to CSF").
- Reference mappings exist for major frameworks: NIST SP 800-53 Rev 5, ISO/IEC 27001:2022, CIS Controls v8, COBIT, and others — coverage varies by framework and is added over time.

NIST also published **SP 1347** (final, August 25, 2026) as a quick-start guide specifically explaining how these crosswalks work and how to use the Reference Tool and OLIR program effectively — worth consulting directly if your team will be doing this mapping work regularly, since it covers submission mechanics and interpretation guidance beyond what I can summarize here.

**One important caution**: Informative References/crosswalks are **not one-to-one equivalences**. A mapping between an ISO 27001 control and a CSF subcategory typically means "related to" or "supports," not "is identical to." Scope, rigor, and evidentiary expectations often differ between the two controls even when mapped together. Treat mappings as a starting point for cross-referencing your compliance work, not as proof that satisfying one automatically satisfies the other.

**Mapping your ISO 27001 controls to CSF 2.0**

Here is a starting crosswalk covering the most common ISO 27001:2022 Annex A control areas against CSF 2.0 subcategories/categories. Use this as a first pass, then validate specific control language in the NIST Reference Tool since ISO mappings are periodically refined:

| CSF Subcategory Area | ISO 27001:2022 Annex A | Notes |
|---|---|---|
| GV.OC (Organizational Context) | A.4.1, A.4.2 | Context of the organization, interested parties |
| GV.SC (Supply Chain Risk) | A.5.19–5.22 | Supplier relationships, ICT supply chain |
| ID.AM (Asset Management) | A.5.9, A.5.10 | Inventory of assets, acceptable use |
| ID.RA (Risk Assessment) | Clause 6.1.2, A.5.7 (threat intelligence) | ISO risk assessment process; note ISO handles this partly in the management-system clauses, not just Annex A |
| PR.AA (Access Control) | A.5.15–5.18, A.8.2–8.5 | Access control policy, identity/authentication management |
| PR.AT (Awareness & Training) | A.6.3 | Information security awareness, education, and training |
| PR.DS (Data Security) | A.5.33, A.5.34, A.8.24 | Protection of records, PII, use of cryptography |
| PR.PS (Platform Security) | A.8.9, A.8.19, A.8.25–8.32 | Configuration management, secure development lifecycle |
| PR.IR (Technology Resilience) | A.8.6, A.5.29, A.5.30 | Capacity management, ICT readiness for business continuity |
| DE.CM (Continuous Monitoring) | A.8.15, A.8.16 | Logging, monitoring activities |
| DE.AE (Adverse Event Analysis) | A.5.25 | Assessment and decision on information security events |
| RS.MA / RS.AN / RS.CO (Respond) | A.5.24–5.28 | Incident management planning, response, learning, evidence collection |
| RC.RP / RC.CO (Recover) | A.5.29, A.5.30 | ICT readiness for business continuity |

**Recommended process for your organization**:
1. Pull your current ISO 27001 Statement of Applicability (SoA) and control implementation evidence.
2. For each CSF 2.0 subcategory, identify the corresponding ISO control(s) using the table above as a starting draft, then confirm/refine against the live NIST Reference Tool (mappings are updated more often than static references like this one).
3. Where a CSF subcategory has no clean ISO equivalent (common in GV.RM strategic-risk areas, GV.RR HR-related subcategories, and ID.IM improvement tracking), flag it as a gap specific to CSF that your ISO program doesn't currently cover — these are useful additions even if you stay ISO-certified as your primary framework.
4. Where an ISO control maps to a CSF subcategory but the rigor differs (e.g., your ISO evidence supports "partially implemented" against the CSF definition), record that explicitly rather than assuming a match is a match.

I can build you a full subcategory-by-subcategory crosswalk table (all 6 functions) mapped to your specific ISO 27001 SoA if you share which Annex A controls you have implemented and their current status.

This is general informational guidance, not legal or audit advice — validate specific mappings against the live NIST CSF 2.0 Reference Tool and consult a qualified ISO 27001 lead auditor or accredited assessor before relying on this crosswalk for certification or regulatory purposes.

Informative references in CSF 2.0 are pointers, not requirements — they tell you which sections of other standards and frameworks (ISO/IEC 27001, NIST SP 800-53, COBIT, CIS Critical Security Controls, etc.) are relevant to a given CSF subcategory, so you don't have to invent your own control language from scratch. NIST maintains these mappings in the CSF Reference Tool / NIST Cybersecurity and Privacy Reference Tool (CPRT), an online, machine-readable repository rather than a static appendix in the framework document itself. This is a deliberate change from CSF 1.1, where informative references were embedded directly in the framework core spreadsheet.

How they work mechanically:
1. CSF 2.0 core structure: Function (e.g., Protect) > Category (e.g., PR.AA — Identity Management, Authentication, and Access Control) > Subcategory (e.g., PR.AA-01 — Identities and credentials for authorized users, services, and hardware are managed).
2. Each subcategory can have one or more informative references, which are specific clauses/controls from other standards that are considered analogous or supportive of that subcategory's intent. For PR.AA-01, you'd typically see references into ISO/IEC 27001:2022 Annex A (e.g., A.5.16, A.8.5), NIST SP 800-53 Rev 5 (e.g., IA-2, IA-4, IA-5), and possibly CIS Controls v8 (Control 5/6).
3. NIST does not claim these mappings are one-to-one equivalences — a single ISO control might map to several CSF subcategories and vice versa, because the frameworks organize the same underlying security concepts differently. Treat mappings as "related to" rather than "identical to."
4. The CPRT is updated periodically as NIST and other standards bodies revise their publications, so a mapping done in 2024 against ISO 27001:2013 Annex A numbering will be stale against the 2022 revision's renumbered/consolidated controls (2013 had 114 controls across 14 domains; 2022 consolidated to 93 controls across 4 themes).

How to map your ISO 27001 controls to CSF 2.0 practically:

Step 1 — Inventory your ISO controls as actually implemented. Don't just use the generic Annex A control list; use your Statement of Applicability (SoA), since that reflects what you actually claim to do, with justifications for exclusions.

Step 2 — Use NIST's CPRT mapping as your starting crosswalk, but validate it against the specific ISO 27001:2022 revision, since older public crosswalks may still reference 2013 numbering.

Step 3 — Build a bidirectional crosswalk table: for each CSF subcategory, list the ISO Annex A controls that support it; for each ISO Annex A control, list the CSF subcategories it feeds into. This surfaces gaps in both directions — CSF subcategories with no corresponding ISO control (rare, but possible in areas like supply chain risk under Govern) and ISO controls that don't map cleanly to any CSF subcategory (also useful to know, since it may indicate ISO covers something CSF treats as out of scope, like some physical security or HR clauses).

Step 4 — Assess maturity/implementation status per subcategory, not just presence/absence. A control can technically "exist" in ISO documentation (policy exists) but not be operating effectively (no evidence of enforcement) — CSF profiles are strongest when they reflect actual implementation status, tied to evidence, not paperwork.

Step 5 — Watch for the biggest structural gap: CSF 2.0's new Govern (GV) function has much heavier emphasis on organizational context, risk management strategy, supply chain risk management, and roles/responsibilities than earlier CSF versions did — and while ISO 27001 Clause 4-10 (the management system requirements, as opposed to Annex A controls) covers a lot of this, many crosswalks only map Annex A controls and miss the ISO management-system clauses (context of the organization, leadership, planning, support, operation, performance evaluation, improvement). Make sure your ISO-to-CSF mapping includes ISO's main clauses, not just Annex A, when populating your Govern function subcategories.

Step 6 — Document assumptions. Since mappings are not one-to-one, record your organization's specific rationale for each mapping decision so future auditors or assessors (and your future self) can follow the logic, especially where you've made a judgment call that a partial ISO control satisfies a CSF subcategory.

Bottom line: use NIST's CPRT/Reference Tool as your starting crosswalk, verify it against your current ISO 27001:2022 SoA (not just the generic Annex A list), explicitly include ISO's management-system clauses when mapping to CSF's Govern function, and document your own judgment calls since NIST's mappings are indicative, not authoritative one-to-one equivalences.

Here is a structured approach for building your CSF 2.0 Organizational Profile as a mid-size manufacturer. Manufacturing has a distinctive risk profile — IT/OT convergence, industrial control systems (ICS/SCADA) on plant floors, third-party equipment vendors with remote access, and supply chain dependencies that are often deeper and less visible than in pure IT environments — so the profile approach below is tailored accordingly, not generic.

**Step 1: Establish Business Context**

Before rating any subcategory, document:
- **Industry/mission**: production lines, product types, safety-critical processes (if any), regulatory exposure (e.g., CMMC/DFARS if you're a defense supplier, customer contractual security requirements, state privacy law if you handle employee/customer PII).
- **Legal/regulatory/contractual obligations**: customer security addenda are often the biggest driver of "must-have" target states in manufacturing — map these explicitly to GV.OC-03.
- **Key assets and Crown Jewels**: this should explicitly include OT/ICS assets (PLCs, HMIs, SCADA historians, robotics controllers) alongside traditional IT — these often carry safety and production-continuity risk that IT-only asset lists miss.
- **Risk tolerance statement**: for manufacturers, this typically centers on production uptime and safety, not just data confidentiality — your risk appetite framing (GV.RM-02) should say so explicitly, since it will drive different priorities than a typical office-based enterprise.

**Step 2: Build the Current Profile**

Assess your actual state today across all six functions using this rating scale: Not Implemented / Partially Implemented / Largely Implemented / Fully Implemented. For a mid-size manufacturer, pay particular attention to these commonly-weak areas during current-state assessment:
- ID.AM-01/02 — do you have a complete asset inventory that includes OT/plant-floor systems, not just corporate IT?
- GV.SC-04/07 — are equipment vendors and their remote-access arrangements tracked and risk-assessed?
- PR.AA-06 — physical access control at plant facilities (often stronger than logical access control in manufacturing, worth confirming rather than assuming).
- PR.PS-01/02 — configuration and patch management for OT systems, which often lag IT patch cycles due to uptime requirements.
- DE.CM-01/09 — monitoring coverage on OT networks (frequently a blind spot — many manufacturers only monitor corporate IT).

**Step 3: Build the Target Profile**

Define target states informed by:
- Customer contractual security requirements (often the fastest-moving driver — new customer contracts frequently mandate specific controls)
- Insurance/cyber-insurance underwriting requirements
- Safety and production-continuity risk tolerance
- Any applicable regulatory baseline (CMMC/NIST 800-171 if defense-adjacent, state breach-notification laws, etc.)

Highlight subcategories where regulatory/contractual obligations create a **mandatory** (not discretionary) target state — these should be flagged distinctly in your profile table since they can't be deprioritized regardless of resource constraints.

**Step 4: Profile Table Format**

| Function | Category | Subcategory | Current | Target | Notes |
|----------|----------|-------------|---------|--------|-------|
| GV | Organizational Context (GV.OC) | GV.OC-03 | Partial | Full | Customer security addenda not yet fully catalogued against controls |
| GV | Supply Chain Risk (GV.SC) | GV.SC-04 | Partial | Full | Equipment/OT vendors not yet inventoried by criticality |
| ID | Asset Management (ID.AM) | ID.AM-01 | Partial | Full | OT/plant-floor asset inventory incomplete |
| PR | Platform Security (PR.PS) | PR.PS-02 | Not Implemented | Largely Implemented | No formal OT patch/replacement cadence |
| DE | Continuous Monitoring (DE.CM) | DE.CM-01 | Not Implemented | Partial | OT network monitoring not yet deployed |
| PR | Technology Resilience (PR.IR) | PR.IR-03 | Partial | Full | Production-line failover/resilience not formally tested |

(This is illustrative — a full profile should cover all six functions with every relevant subcategory rated, not just the manufacturing hot spots above.)

**Step 5: Prioritize and Sequence**

The gap between Current and Target drives your action plan. Sequencing logic that applies well to manufacturing:
1. **Phase 1 (prerequisites)**: GV.OC and GV.RM to lock in risk tolerance framed around production/safety; ID.AM to build a *combined* IT+OT asset inventory (this is foundational — nothing else in Protect/Detect is meaningful without knowing what OT assets exist).
2. **Phase 2**: PR controls prioritized by what protects production continuity and safety first — PR.AA for both plant and office access, PR.PS for configuration/patch management adapted to OT constraints (can't always patch live production systems — document compensating controls where true patching isn't feasible).
3. **Phase 3**: DE.CM extended to OT networks (often a net-new capability, frequently requires OT-specific monitoring tooling since IT tools don't always parse ICS protocols) and DE.AE.
4. **Phase 4**: RS and RC — incident response and recovery plans that explicitly cover production-line/safety scenarios, not just IT data breach scenarios, plus the ID.IM feedback loop back into GV.

**Next steps I can help with**:
- A full gap assessment table across all six functions if you share your current control implementation status
- An implementation roadmap with 30/60/90-day and 6/12-month phases once the Current/Target Profile is drafted
- A crosswalk to any specific framework you're also subject to (NIST SP 800-171/CMMC if defense-related, ISO 27001, etc.)

This is general informational guidance based on NIST CSF 2.0, not legal or professional compliance advice. For OT/ICS-specific technical safeguards and any regulatory certification (e.g., CMMC), engage a qualified cybersecurity professional or accredited assessor.

Here's a practical organizational profile approach for a mid-size manufacturer adopting CSF 2.0. CSF 2.0 formalizes "organizational profiles" as the core mechanism for applying the framework to your specific business — you'll build a Current Profile (where you are today) and a Target Profile (where you want to be), then use the gap between them to drive your roadmap.

1. Scope and business context (feeds Govern function, GV.OC)
Start by defining organizational context: what you make, your supply chain structure (tier 1/2/3 suppliers, OEM relationships), regulatory drivers (e.g., CMMC/DFARS if you're a defense subcontractor, ITAR, state privacy laws, customer security requirements in contracts), and your risk tolerance. Manufacturers typically have a bimodal environment: corporate IT (ERP, email, engineering CAD/PLM systems) and OT/ICS on the plant floor (PLCs, HMIs, SCADA, MES). Your profile should explicitly note this split because Protect/Detect/Respond controls differ substantially between the two (e.g., patching a PLC isn't the same cadence as patching a laptop, and safety systems may have hard real-time constraints that limit certain security controls).

2. Select a scoping unit
Decide whether your profile covers the whole enterprise or is built per-plant/per-business-unit. For a mid-size manufacturer with a handful of plants, I'd recommend one enterprise-level profile for corporate IT and shared services, plus either a single OT profile that covers common plant-floor risk themes, or per-plant OT profiles if your plants have meaningfully different technology stacks or risk exposure (e.g., one plant handles export-controlled products, another doesn't).

3. Build the Current Profile
- For each of the six functions (Govern, Identify, Protect, Detect, Respond, Recover), and each subcategory within, assess current state: implemented / partially implemented / not implemented / not applicable.
- Gather evidence from existing documentation: IT security policies, OT network diagrams, vendor risk questionnaires you've already answered for customers, past audit/pen-test results, incident history, insurance questionnaires (cyber insurance applications are a surprisingly good existing gap-analysis input).
- Interview control owners: IT security lead, plant/OT engineering lead, HR (for insider risk/onboarding-offboarding), procurement (supply chain risk), and a business continuity/safety lead (Recover function, tied into existing business continuity/disaster recovery plans you likely already have for safety/operations reasons).
- Score using CSF Tiers (1–4: Partial, Risk Informed, Repeatable, Adaptive) at the organizational level, and implementation status at the subcategory level. Don't conflate the two — tiers describe how mature and integrated your risk management practices are overall, not a per-subcategory status.

4. Build the Target Profile
- Prioritize based on actual business drivers: customer contractual requirements (increasingly common for manufacturers supplying to larger OEMs or the defense industrial base), insurance requirements, known incident history, and realistic budget/headcount.
- Be selective. A common mistake is targeting Tier 4/"fully implemented" across the board — that's rarely necessary or affordable. Set differentiated targets: e.g., higher rigor for Identify/Protect subcategories touching OT and safety systems or IP-sensitive engineering data, moderate rigor for general corporate IT, lower rigor for low-risk peripheral systems.
- Pay special attention to Govern (new emphasis area in 2.0): supply chain risk management (GV.SC) is particularly relevant for manufacturers given third-party component risk, contract manufacturers, and software supply chain (PLC firmware, MES software vendors).

5. Gap analysis and roadmap
- For each subcategory where Current < Target, document the specific gap, the remediation action, an owner, and a realistic timeline (quarters, not just "someday").
- Group gap-closure actions into a 12–24 month roadmap, sequencing quick wins (policy documentation, MFA rollout on remaining accounts) ahead of larger capital/OT projects (network segmentation between IT and OT, SCADA monitoring tooling), since OT changes often require plant downtime windows.
- Tie budget requests to specific target profile gaps — this framing (funded gap-to-target vs. abstract "cybersecurity spend") tends to work well with manufacturing leadership focused on capital planning cycles.

6. Governance and maintenance
- Assign an executive sponsor and a cross-functional review (IT security + OT/engineering + safety + legal/compliance) at least annually, or after significant events (new plant, acquisition, major incident, new customer contract with security requirements).
- Re-baseline the Current Profile periodically (annually is typical) and track Tier progression as a leadership-reportable metric.
- Use community/sector profiles where available as accelerators — NIST has published example profiles for some sectors, and manufacturing-specific resources (e.g., NIST's manufacturing profile work under the earlier CSF 1.1 era, and CISA/ISA guidance for ICS security) can inform your OT-specific target subcategory choices, even though you'll still need to tailor them.

Bottom line: build one enterprise Current/Target profile pair, explicitly split IT vs. OT considerations within it, prioritize targets by real business drivers rather than blanket maturity goals, and turn the gap into a funded, owned, dated roadmap reviewed at least annually.

Good news: CSF 2.0 (published February 2024) is designed to be backward-compatible in intent with CSF 1.1 (April 2018) — you don't need to rip out your existing program. But there are real structural changes worth understanding before you migrate. Here's what changed and how to approach the transition.

**What actually changed**

1. **A sixth function: Govern (GV).** This is the headline change. CSF 1.1 embedded governance activities across the Identify and Protect functions (mainly ID.GV and ID.RM). CSF 2.0 pulls governance out into its own standalone function with 6 categories and 23 subcategories: GV.OC (Organizational Context), GV.RM (Risk Management Strategy), GV.RR (Roles, Responsibilities, and Authorities), GV.PO (Policy), GV.OV (Oversight), and GV.SC (Cybersecurity Supply Chain Risk Management). The intent is to put governance at the center — literally depicted at the center of the CSF wheel diagram — rather than treating it as a subset of "Identify."

2. **Supply chain risk management expanded significantly.** CSF 1.1 had a single category, ID.SC, with 5 subcategories. CSF 2.0 moved this into GV.SC and expanded it to 10 subcategories — covering supplier criticality prioritization (GV.SC-04), pre-relationship due diligence (GV.SC-06), lifecycle monitoring (GV.SC-09), and post-relationship provisions (GV.SC-10), none of which existed in 1.1.

3. **A new Improvement category (ID.IM).** CSF 1.1 had no formal mechanism for capturing lessons learned across functions. CSF 2.0 adds ID.IM (4 subcategories) to structure how improvements are identified from evaluations, tests/exercises, operational execution, and communicated to stakeholders — this absorbed what used to be scattered informally across RC.IM (Recovery Improvements) in 1.1, which no longer exists as a separate category.

4. **Net subcategory count**: 108 in CSF 1.1 down to 106 in CSF 2.0 — despite adding an entire new function, NIST consolidated and removed redundant subcategories elsewhere (e.g., PR.IP's 12 subcategories were split/absorbed into PR.PS and PR.IR; several RS.AN and RC.CO subcategories were consolidated).

5. **Informative References moved online.** In 1.1 these were embedded in the framework document; in 2.0 they live in the searchable NIST CSF 2.0 Reference Tool, updated via the OLIR program independently of the core framework text.

6. **Audience broadened explicitly.** CSF 1.1 was written with a critical-infrastructure lens; CSF 2.0 explicitly targets organizations of all sizes and sectors, and added Quick Start Guides for SMBs, enterprise risk managers, and government.

7. **Tiers are structurally the same** (4 tiers, same three dimensions: Risk Management Process, Integrated Risk Management Program, External Participation) but the descriptions were refined for clarity — no material change to how you'd assess your tier.

**Where your CSF 1.1 subcategories land in 2.0** (partial map — the full mapping is more extensive):

| CSF 1.1 | CSF 2.0 | Topic |
|---|---|---|
| ID.GV-01 | GV.PO-01 | Cybersecurity policy |
| ID.GV-02 | GV.RR-02 | Roles and responsibilities |
| ID.GV-03 | GV.OC-03 | Legal/regulatory requirements |
| ID.GV-04 | GV.OV-01 | Governance/risk strategy review |
| ID.RM-01/02/03 | GV.RM-01/02/06 | Risk objectives, tolerance, methodology |
| ID.SC-01 to 05 | GV.SC-01, 04, 05, 07, 08 | Supply chain (now expanded to 10 subcategories total) |

**Migration checklist**

- **Governance**: Formally document risk tolerance (GV.RM-01/02), assign explicit accountable roles to leadership (GV.RR-01/02), establish a policy review cycle (GV.PO-01/02), stand up an oversight mechanism (GV.OV-01 to 03), and expand your supply chain program from ID.SC's 5 subcategories to the full GV.SC-01 through GV.SC-10.
- **Identify**: Add data/metadata inventories (ID.AM-07) and asset lifecycle management (ID.AM-08) if not already covered; establish a vulnerability disclosure process (ID.RA-08); assess hardware/software authenticity before acquisition (ID.RA-09); stand up the new ID.IM improvement-tracking category.
- **Protect**: Add data-in-use protection (PR.DS-10) and secure software development practices (PR.PS-06).
- **Detect**: Integrate threat intelligence into event analysis (DE.AE-07) and define incident declaration criteria (DE.AE-08).
- **Respond**: Formalize incident triage, categorization, and escalation (RS.MA-02 to 04) — 1.1's RS.RP and RS.CO-01 collapsed into RS.MA-01.
- **Recover**: Add post-incident operational norms (RC.RP-04), incident recovery end criteria (RC.RP-06), and a public communications process (RC.CO-04).

**Practical sequencing advice**: Since Govern is not optional in 2.0, start there — map your existing ID.GV/ID.RM practices to their new GV homes explicitly, even if the underlying practice doesn't change, so your documentation reflects the current framework. Then tackle the supply chain expansion (GV.SC), since that's the single largest scope increase. The remaining changes (ID.IM, PR.DS-10, DE.AE-07/08, etc.) are additive and can be worked into your existing continuous-improvement cycle rather than requiring a wholesale program rebuild.

I can help you produce a full subcategory-by-subcategory crosswalk of your current 1.1-based program into 2.0, or build a prioritized migration roadmap with effort/impact ratings if you share your current program documentation.

This is general informational guidance based on the publicly available NIST CSF 1.1 and 2.0 documents, not legal or audit advice. Validate specific subcategory mappings against the official NIST CSF 2.0 Reference Tool and consult a qualified cybersecurity professional for your organization's specific migration plan.

CSF 2.0 (published February 2024) is an evolution, not a rewrite — your CSF 1.1 program is a solid foundation, and migration is more about reorganizing/extending than starting over. Here's what actually changed and how to approach migration.

What changed:

1. New "Govern" function (the headline change). CSF 1.1 had five functions: Identify, Protect, Detect, Respond, Recover. CSF 2.0 adds Govern as a sixth, and it's placed conceptually "above" the other five, since governance decisions (risk management strategy, roles and responsibilities, policy, oversight, supply chain risk management) inform how you execute the other five. Much of Govern's content existed in 1.1 but was scattered — parts lived under Identify (ID.GV, ID.RM, ID.SC in 1.1). CSF 2.0 pulls governance, risk management strategy, and supply chain risk management out into their own dedicated function with expanded subcategories, especially around cybersecurity supply chain risk management (GV.SC), which got significantly more detailed than 1.1's ID.SC.

2. Scope expansion beyond critical infrastructure. CSF 1.1 was explicitly framed around critical infrastructure. CSF 2.0 drops that framing and positions itself as applicable to any organization, regardless of sector or size — reflecting how broadly CSF 1.1 was actually being used in practice (small businesses, schools, nonprofits, not just critical infrastructure operators).

3. Formalized "Organizational Profiles" and "Community Profiles." CSF 1.1 had "profiles" as a looser concept (current/target). CSF 2.0 gives much more structured guidance on building organizational profiles, plus introduces "Community Profiles" — shared profiles developed by a sector, interest group, or coalition (e.g., a Community Profile for a specific industry or a specific threat like ransomware) that member organizations can start from rather than building entirely from scratch.

4. New CSF Reference Tool / CPRT for informative references. In 1.1, informative references (mappings to ISO 27001, SP 800-53, COBIT, etc.) were static content embedded in the framework documentation. In 2.0, NIST moved this to the online Cybersecurity and Privacy Reference Tool (CPRT), which is updated independently of the framework document, so mappings can be refreshed as underlying standards change without waiting for a full CSF revision.

5. Subcategory reorganization and renumbering. Several 1.1 subcategories were consolidated, reworded, split, or moved between categories/functions as part of the Govern reorganization and general cleanup. This means your old subcategory IDs (e.g., ID.GV-1) don't map one-to-one to new IDs — some content moved to GV.OV, GV.RM, GV.PO, etc. You cannot assume a simple ID-to-ID renumbering; you need to actually re-read the new subcategory language.

6. Expanded guidance on implementation examples. CSF 2.0 introduces "Implementation Examples" for many subcategories — concrete, illustrative actions an organization might take — which 1.1 didn't have. These aren't mandatory, but they're useful drafting aids for your own profile language.

7. Increased emphasis on cybersecurity supply chain risk management (C-SCRM), measurement/improvement, and continuous improvement culture, reflecting lessons learned since 1.1 (2018) around ransomware, software supply chain attacks (SolarWinds-era), and general maturity of enterprise risk practice.

How to migrate:

Step 1 — Map your existing 1.1 profile/control set against the new CSF 2.0 core structure using NIST's published 1.1-to-2.0 crosswalk (NIST released a mapping document alongside CSF 2.0). Don't assume subcategory numbers carry over; validate each mapping.

Step 2 — Stand up Govern as a distinct section of your program, even if much of its substance already exists elsewhere in your documentation (risk management policy, roles/responsibilities charter, supply chain risk policy). Consolidate it so leadership and auditors can see governance addressed explicitly and holistically, not scattered.

Step 3 — Expand your supply chain risk management practices to match GV.SC's increased depth — this is the area most 1.1 programs will find genuinely under-built relative to 2.0 expectations (third-party risk assessment cadence, contractual security requirements, software bill of materials practices).

Step 4 — Rebuild your Current Profile against the new subcategory set rather than trying to patch your old 1.1 profile; use the crosswalk to carry over evidence and status where subcategories map cleanly, and do fresh assessment work where they don't.

Step 5 — Reset your Target Profile and tier targets with current leadership, since risk appetite and regulatory landscape have likely shifted since your original 1.1 profile was set.

Step 6 — Update any internal documentation, control mappings, audit templates, and board reporting materials that reference 1.1 function/category codes, since some of these codes changed meaning or location.

Bottom line: the core five functions and their spirit carry forward largely intact; the main work is building out Govern as a first-class function (especially supply chain risk), re-validating subcategory mappings rather than assuming a clean renumbering, and refreshing your profiles and reference-standard crosswalks against the new CPRT-based mappings.

Short answer: no — not on its own, and not anymore. This is one of the most consequential scoping traps in PCI DSS v4.0.1 right now, and it applies directly to your situation.

As a Level 1 merchant, your organisation is required to complete a full Report on Compliance (ROC) performed by a QSA — you are not eligible for any Self-Assessment Questionnaire (SAQ), including SAQ A. SAQ A's eligibility criteria (cards not present, all cardholder data functions fully outsourced to a PCI-compliant third party, no CHD touching your systems) exist to define a reduced SAQ control set for smaller merchants. They were never designed as a scoping methodology for a ROC, and PCI SSC has now made that explicit.

FAQ 1331 (updated August 31, 2026) states that SAQ eligibility criteria may no longer be used as a guide for determining PCI DSS requirement applicability in a ROC assessment "unless explicitly reviewed, discussed and agreed upon with the merchant's compliance accepting entity" — meaning your acquiring bank and/or the relevant card brand(s), not just your QSA. This is a change from the informal practice many QSAs previously followed, where a QSA's professional judgment that "this merchant looks like an SAQ A profile" was treated as sufficient justification to mark large blocks of ROC requirements as Not Applicable (particularly around Req 6.4.3 and 11.6.1, the payment-page script inventory and tamper-detection controls that are frequently the reason merchants want to lean on SAQ-A-style scoping in the first place).

What this means concretely for you:

1. QSA agreement alone is no longer sufficient evidence. Even if your QSA is comfortable with the SAQ A logic and signs off, that agreement does not, by itself, satisfy the current PCI SSC position. You need it "explicitly reviewed, discussed and agreed upon" with your acquirer and/or card brand.
2. Get it in writing. Before your QSA finalizes the ROC with requirements marked N/A on this basis, obtain documented approval from your acquiring bank (and any card brand involved, e.g., via your acquirer) confirming they accept the SAQ-A-style scoping rationale for your specific ROC. Keep this correspondence as part of your assessment evidence file — a QSA's ROC workpapers should reference it directly.
3. Pay particular attention to 6.4.3 and 11.6.1. These e-commerce/script-integrity requirements are the ones most often incorrectly excluded via SAQ-A logic. Given that you operate a Level 1 e-commerce environment, your QSA should independently verify whether your actual payment flow (not just the SAQ-A "ideal" fully-outsourced model) truly meets the SAQ A profile — most Level 1 merchants have some degree of customer-facing payment page control, third-party script embedding, or redirect logic that would place them closer to an SAQ A-EP profile, which does carry these requirements.
4. Re-scope from first principles for the ROC. Rather than starting from "which requirements does SAQ A exclude," your QSA should build ROC applicability from the actual CDE boundary: what stores, processes, or transmits PAN/SAD, and what is connected to those systems without adequate segmentation. This is the scoping approach ROC assessments are meant to use regardless of what an equivalent SAQ profile would exclude.
5. Document the decision either way. If, after acquirer/brand review, some requirements remain justifiably N/A, document the rationale, the approving parties, and the date of agreement in the ROC. If the accepting entity does not confirm agreement, treat the requirements as in-scope and assess them fully.

Recommended next step: raise this with your QSA and acquirer now, before ROC finalization — not after submission. If the acquirer/brand agreement isn't obtained, expect your QSA to walk back any N/A markings based purely on SAQ A criteria and assess the full requirement set for your actual CDE. This is informational guidance, not a substitute for your QSA's formal determination; verify current requirements against the official PCI SSC FAQ library and your acquirer's specific expectations.

Short answer: no, that is not acceptable, and if your QSA is signing off on it you should push back before the ROC goes anywhere near an acquirer or the card brands.

SAQ A is a self-assessment vehicle built for a very narrow population of merchants: those who have fully outsourced all cardholder data functions to PCI DSS validated third parties and who retain no cardholder data on their own systems, in any form, at any time — no capture, no transmission, no storage, not even transiently in server memory or logs. It exists so that the smallest, simplest e-commerce merchants (typically Level 4, sometimes Level 3) don't have to answer the full 300+ requirement set. It is a self-assessment questionnaire, not a Report on Compliance methodology, and it was never designed to be a scoping shortcut for an organization that undergoes a full ROC.

A Level 1 merchant, by definition, processes more than 6 million transactions a year (or has otherwise been designated Level 1 by a brand or acquirer) and is contractually required to validate compliance via a full ROC performed by a QSA using the PCI DSS Report on Compliance template — not any SAQ. The SAQs (A, A-EP, B, B-IP, C, C-VT, D for merchants, D for service providers, P2PE) are validation tools for merchants who are permitted to self-assess. Once you are a Level 1 merchant obligated to produce a ROC, the "applicability" of requirements is governed by the actual scope of your cardholder data environment (CDE) as determined by the standard scoping process in DSS v4.0 — not by which SAQ type your business model superficially resembles.

There is a related, legitimate concept that may be what's actually going on here: even within a full ROC, a QSA can mark individual requirements or sub-requirements as "Not Applicable" (N/A) when there is a well-documented, verifiable reason — for example, requirements about wireless security when the environment has no wireless technology anywhere in or connected to the CDE, or requirements about a technology the environment doesn't use. PCI DSS v4.0 formalizes this with the "Not Tested" and targeted risk analysis mechanisms and requires an N/A justification to be documented per requirement in the ROC (Appendix C in the reporting template, or equivalent). That is a control-by-control, evidence-based determination — fundamentally different from importing SAQ A's eligibility criteria (fully outsourced, no CDE touch) as a blanket excuse to mark most of Requirements 1 through 12 as N/A across the board.

If your environment genuinely has no cardholder data touching your systems — e.g., 100% iframe/redirect to a PCI DSS validated processor with no capability to alter that redirect, and no other CDE presence — that would need to be demonstrated network segment by network segment, system by system, and even then, many requirements (e.g., Requirement 12 governance items, Requirement 6.4.3 and 11.6.1 script/skimming controls for payment pages that were added specifically because "fully outsourced" merchants were being skimmed) still apply to Level 1 ROC merchants under DSS v4.0. Those two requirements in particular were added because the SAQ-A population itself was found to be a major skimming target, so even genuinely eligible merchants can't wave those away.

Practical implications and recommendations:
1. Ask the QSA to produce, in writing, the specific scoping analysis and evidence supporting each N/A designation, tied to actual architecture (network diagrams, data flow diagrams, segmentation testing results) — not to SAQ eligibility criteria.
2. Confirm with your acquirer what reporting they actually require for your validation level; they, not the QSA, are the ultimate recipient with authority over acceptable ROC scope.
3. Push for a full scoping exercise per PCI DSS v4.0 Requirement 12.5.2 (annual scope confirmation) — this is the only legitimate mechanism for excluding systems from the CDE.
4. If the QSA continues to apply SAQ eligibility logic to a ROC, consider escalating to the QSA company's quality assurance function or reporting the practice to the PCI SSC, since QSAs are bound by the QSA Qualification Requirements and can lose their qualification for methodologically unsound assessments.
5. Recognize the compliance risk: an acquirer or card brand discovering a ROC built on improper scoping can trigger revalidation, fines, or increased scrutiny — all worse outcomes than doing the scoping correctly now.

In short, SAQ A eligibility and ROC "Not Applicable" determinations are different instruments serving different populations and different levels of assurance; conflating them is a compliance and audit-quality problem, not a shortcut.

Based on the description — a web shop that redirects customers to a hosted payment page — the applicable SAQ is most likely SAQ A, provided your setup meets the full eligibility criteria below. Let's walk through the decision logic and what to verify before you commit to that SAQ type.

SAQ A vs. SAQ A-EP: the key distinction

Both SAQ A and SAQ A-EP apply to e-commerce merchants with no card-present transactions who outsource cardholder data (CHD) handling to a third party. The distinction is about how much control your own website exercises over the payment process:

- SAQ A applies when the redirect is a full, clean handoff — the customer leaves your page entirely and lands on the third party's hosted payment page (e.g., a PayPal, Stripe Checkout, or Square hosted page) to enter card details. Your servers never receive, transmit, or influence the collection of cardholder data in any way.
- SAQ A-EP applies when your site retains some influence over the payment page even though data capture is outsourced — for example, if you embed the payment form via an iframe or JavaScript widget on your own page, or if your web server that serves the checkout page could be tampered with to redirect the customer elsewhere. If your page "directs" the browser to the payment processor via script you control (rather than a straightforward server-side redirect/link), you may actually be closer to A-EP.

SAQ A eligibility criteria you need to confirm:

1. All payment processing and cardholder data handling is fully outsourced to PCI DSS-validated third-party service provider(s).
2. Your e-commerce site does not itself receive, transmit, process, or store cardholder data — the customer's browser is redirected away from your domain (or to a fully separate, provider-controlled page/subdomain) to complete payment.
3. There is no card-present acceptance channel at all.
4. Your website does not affect the security of the payment transaction (i.e., it isn't serving the JavaScript or iframe content that actually captures card data — that's fully hosted and controlled by the third party).
5. You have confirmed the payment service provider's own PCI DSS compliance (their AOC) since their compliance underpins your reduced scope.

If all five hold, SAQ A is appropriate — it covers roughly 22 controls, a subset of Requirements 2, 6, 8, 9, 10, 11, and 12, focused on basic security hygiene rather than cardholder data protection controls (since you never touch CHD).

What's excluded from your scope under SAQ A: the bulk of Requirements 1, 3, 4, 5, and 7 (network segmentation of a CDE, PAN storage/encryption, transmission encryption, anti-malware, and CHD-specific access controls) do not apply to your merchant environment because you never store, process, or transmit CHD — the risk sits entirely with your payment service provider.

What you still must do under SAQ A: maintain basic security policies, ensure any personnel with access to your web-hosting environment have unique IDs, apply patches, and — critically for redirect-based e-commerce — confirm your web server and any redirect logic can't be manipulated to send customers to a malicious page (this is where a lot of merchants get tripped up: a compromised web server that alters the redirect URL is a genuine skimming risk even under SAQ A).

One flag to check now: if your redirect mechanism involves any client-side script that constructs or manipulates the payment page URL, or if the payment fields appear inside your own page via an embedded frame rather than a full page redirect, re-examine whether SAQ A-EP (with its added script-integrity controls under Req 6.4.3 and change/tamper detection under 11.6.1) is the more accurate fit — misclassifying A-EP scenarios as SAQ A is a common and consequential error, since it omits payment-page script inventory and monitoring controls designed specifically to catch web-skimming (Magecart-style) attacks.

Recommendation: document your actual data/redirect flow in a simple diagram, confirm your payment provider's compliance status and AOC, and have your acquirer or a QSA/ISA validate the SAQ A vs. A-EP determination before you sign the Attestation of Compliance. This guidance is informational; final SAQ selection should be confirmed with your acquirer, who is the ultimate authority on which SAQ they will accept.

If your e-commerce site redirects the customer's browser fully away to a third-party hosted payment page (or embeds it via an inline frame that is entirely served and controlled by the payment processor) and your own web servers never receive, process, or store cardholder data, you are most likely eligible for SAQ A — the shortest and least burdensome of the merchant self-assessment questionnaires, roughly 20-plus requirements depending on the DSS version.

SAQ A eligibility conditions (PCI DSS v4.0 era) generally require that the merchant:

1. Handles only card-not-present (e-commerce or mail/telephone order) transactions.
2. Has fully outsourced all cardholder data functions — capture, transmission, processing, storage — to PCI DSS validated third-party service provider(s). All payment pages/iframes must be provided directly by the third party, and the payment page must not be capable of being loaded within the merchant's own controlled iframe wrapper in a way that gives the merchant script-level control over the payment fields.
3. Retains no electronic storage, processing, or transmission of any cardholder data on the merchant's own systems or premises — no cardholder data touches merchant infrastructure at all, not even in logs or memory.
4. Confirms that any paper reports or receipts with cardholder data are not stored electronically.
5. Has confirmed, via the third-party's PCI attestation of compliance (AOC), that the service provider is itself validated compliant.

Important nuance introduced in v3.2.1 and carried into v4.0: there are effectively two flavors of "redirect/hosted" eligibility.

- If the payment page is a true full-page redirect (the customer's browser navigates away from your domain entirely to the processor's domain, completes payment, then redirects back) — that is classic SAQ A territory, assuming the other conditions above hold.
- If the payment collection happens via an iframe or embedded JavaScript hosted by the processor but displayed within your page (so the customer never leaves your page visually), you may still qualify for SAQ A, but only if your page itself does not have the ability to control, manipulate, or receive the content of that iframe — i.e., you have no script on the page that could alter, inject into, or intercept the payment iframe. If your page includes any script capability that could affect the security of that payment page (even if unused), or if you serve the iframe wrapper page dynamically from your own infrastructure using code you control, you likely fall into SAQ A-EP instead, which has significantly more requirements (roughly 40+, including many Requirement 6, 9, 11, and 12 controls) because your web server is considered to influence the security of the payment process even though it never touches card data directly.

A key regulatory point that matters a lot right now: PCI DSS v4.0 added two requirements that apply to SAQ A merchants specifically because "fully outsourced" merchants have been a major target of digital skimming (Magecart-style attacks):

- Requirement 6.4.3 — every script that executes in the consumer's payment page must be authorized, its integrity must be verified (e.g., via subresource integrity or an inventory/monitoring mechanism), and there must be a documented inventory of all scripts and justification for each.
- Requirement 11.6.1 — a change- and tamper-detection mechanism must be deployed to alert on unauthorized modification of the HTTP headers and page contents of payment pages, checked at least weekly (or per a defined frequency based on a targeted risk analysis).

These two apply even to SAQ A merchants because the redirect page itself — the page the customer sees just before or after being sent to the processor — is often on merchant-controlled infrastructure and has been the injection point for skimmers in real breaches. So "SAQ A" does not mean "no security work"; it means a narrower scope, but script/header integrity monitoring on your own checkout-adjacent pages is now mandatory.

Other things to verify before claiming SAQ A:
- Get and review the payment processor's current AOC and confirm it's not expired.
- Make sure no cardholder data ever appears in server logs, error logs, session replay tools, analytics tags, or customer support tooling on your side.
- Confirm your web application firewall or CDN configuration doesn't cache or log full PANs.
- Check that your incident response and vulnerability scanning practices still cover your outsourced flow. Some Requirement 12 items (security policy, incident response plan, service provider due diligence) still apply under SAQ A.

If any of the above conditions aren't met — for example, if your servers ever see the full PAN even momentarily, or you tokenize on your own infrastructure — you'd need to move up to SAQ A-EP or a broader SAQ (C, D) depending on your actual architecture. I'd recommend walking through the current SAQ A and A-EP eligibility criteria documents from the PCI SSC line by line with your team (and ideally your acquirer or a QSA) to confirm exactly which bucket your specific checkout flow falls into, since the iframe-control nuance is where merchants most often misclassify themselves.

All PCI DSS v4.0 "future-dated" requirements — items published in March 2022 as best practice, with a grace period — became fully mandatory on March 31, 2025. If your last assessment predates that date, or if your compliance program hasn't been explicitly re-tested against these, treat this as an active gap-assessment priority. Here is the complete list, organised by requirement, with the ones that bite hardest called out.

Requirement 3 — Stored Account Data
- 3.3.2 / 3.3.3: SAD stored prior to authorization must be encrypted, with formal key management (applies mainly to issuers/issuing-support entities).

Requirement 4 — Transmission
- 4.2.1.1: Inventory of trusted keys and certificates must be maintained.

Requirement 5 — Anti-Malware
- 5.3.3: Anti-malware must scan removable electronic media.
- 5.4.1: Automated technical solution to detect and protect against phishing (new concept entirely — email gateway filtering, DNS filtering, or DMARC/DKIM/SPF enforcement).

Requirement 6 — Secure Development
- 6.3.2: Software inventory (effectively an SBOM) for bespoke/custom software.
- 6.4.3: All payment page scripts inventoried, authorized, and integrity-protected.

Requirement 7 — Access Control
- 7.2.4 / 7.2.5 / 7.2.5.1: Access privilege reviews every 6 months; formal management of application/system accounts.
- 7.3.2: Access control system configured to enforce least privilege.

Requirement 8 — Authentication
- 8.3.6: Passwords for non-MFA users changed at least every 90 days.
- 8.4.2: MFA required for ALL access into the CDE.
- 8.6.1 / 8.6.2: Interactive system/application account management; no hardcoded credentials in scripts or source code.

Requirement 10 — Logging
- 10.4.1.1: Automated log review (manual-only review no longer sufficient).
- 10.7.2 / 10.7.3: Failures of critical security controls (firewalls, AV, IDS/IPS, FIM) must be detected and responded to within defined timeframes.

Requirement 11 — Testing
- 11.4.7: Multi-tenant service providers must support customer penetration testing requests.
- 11.6.1: Change/tamper detection mechanism for HTTP headers and scripts on payment pages.

Requirement 12 — Policy and Programs
- 12.3.2: Targeted Risk Analysis (TRA) for each requirement using the Customised Approach.
- 12.3.3 / 12.3.4: Annual review of crypto cipher suites/protocols and of hardware/software technology lifecycle.
- 12.5.2.1: Multi-tenant service providers verify PCI DSS scope at least every 6 months.
- 12.8.4: TPSP compliance status monitored at least annually.
- 12.9.2: TPSPs must support customer requests confirming PCI DSS responsibility.
- 12.10.4.1: IR personnel trained at least every 12 months.
- 12.10.7: IR procedure for discovery of stored PAN in an unexpected location.

Which ones bite hardest, and why:

1. 8.4.2 (MFA for ALL CDE access) — the single biggest operational lift for most organisations. Previously MFA was only required for remote access and non-console admin access; now it's required for every user, every access path into the CDE, including from the internal network. Organisations that relied on "we're inside the firewall, so no MFA needed" now have a hard gap. Expect real project cost here: MFA rollout across internal jump hosts, database access tools, and legacy applications that don't natively support MFA.

2. 6.4.3 and 11.6.1 (payment page script inventory + tamper detection) — these target web-skimming/Magecart-style attacks and require e-commerce merchants (especially SAQ A-EP and larger) to inventory every script running on the payment page, justify its presence, and deploy CSP/SRI or equivalent integrity monitoring, checked at least every 7 days. Most organisations have never inventoried third-party JS on checkout pages (analytics, chat widgets, ad pixels) and this becomes a significant discovery-and-remediation exercise.

3. 10.4.1.1 (automated log review) — manual daily log walkthroughs no longer satisfy the requirement; this typically forces a SIEM purchase or reconfiguration project for organisations that were doing manual review.

4. 5.4.1 (anti-phishing) — a brand-new control category with no prior equivalent; many organisations have some ad hoc email filtering but nothing formally documented as meeting this requirement.

Recommendation: run a targeted gap assessment against 8.4.2, 6.4.3/11.6.1, and 10.4.1.1 first, since these tend to require the longest lead time (tooling procurement, MFA integration work, script remediation). This is general guidance based on the publicly available PCI DSS v4.0.1 standard — verify your specific gaps with your QSA/ISA.

PCI DSS v4.0 was published in March 2022 with a set of new requirements that were explicitly marked as "best practice until 31 March 2025" — meaning assessors did not have to test them as mandatory until that future date arrived. That date has now passed (we're well past it as of late 2025/2026), so all of those previously future-dated requirements are fully in effect and must be assessed as mandatory in any ROC or SAQ. There is no more grace period; if you haven't implemented them, you're non-compliant against the current version of the standard, since v3.2.1 was also retired (it was retired March 31, 2024, a full year before the future-dated requirements became mandatory).

The requirements that moved from "future-dated best practice" to "mandatory now" span nearly every major requirement family. The ones that tend to bite hardest in practice are:

1. Requirement 8.3.6 / 8.6.3 — password and authentication strengthening. Minimum password length increased to 12 characters (up from 7), and there are new requirements around protecting against the use of compromised credentials and stricter controls on shared/generic accounts and interactive login for accounts used by applications and systems. Many organizations have legacy systems or embedded devices that can't easily support 12-character minimums, or have never inventoried where shared credentials are used.

2. Requirement 8.4.2 — multi-factor authentication (MFA) for all access into the CDE, not just remote/administrative access as under v3.2.1, but now for all access by personnel with access to the CDE, including from within the corporate network. This is one of the most operationally disruptive changes because it requires MFA rollout to internal, non-remote access paths that many companies never had MFA on.

3. Requirement 3.5.1.1 / 3.6.1.1 — stronger cryptographic key management practices, including requirements around key custodianship and use of a documented key management strategy, particularly problematic for organizations with ad hoc or undocumented key rotation practices.

4. Requirement 6.4.3 — for merchants with payment pages (including SAQ A merchants), a formal inventory of all scripts loaded on the payment page, with justification for each script's business necessity and a mechanism to confirm the integrity of each authorized script. This has hit e-commerce merchants especially hard because most have never inventoried third-party JavaScript (analytics, chat widgets, ad tech, tag managers) running on checkout pages, and Magecart-style skimming attacks specifically exploit unmonitored third-party scripts.

5. Requirement 11.6.1 — a change- and tamper-detection mechanism to alert personnel of unauthorized modifications to the HTTP headers and content of payment pages, evaluated at least weekly. This requires actual tooling (many organizations use a specialized script/DOM monitoring service) that most merchants didn't previously have.

6. Requirement 10.7.1 / 10.7.2 / 10.7.3 — detection and response to failures of critical security control systems (firewalls, IDS/IPS, FIM, anti-malware, physical access controls, logging mechanisms, segmentation controls, audit log review mechanisms, automated security testing tools) with defined response procedures. This requires formal monitoring of the security tools themselves, not just the environment they protect.

7. Requirement 12.3.1 to 12.3.4 (targeted risk analysis) — where the standard now allows organizations to define their own frequency for certain activities (like log reviews, POI device inspections) based on a documented targeted risk analysis, rather than a fixed PCI-mandated interval. This is flexible but requires new formal risk-analysis documentation many orgs haven't built yet.

8. Requirement 5.4.1 — anti-phishing mechanisms to detect and protect personnel against phishing attacks, going beyond traditional anti-malware.

9. Requirement 7.2.4 — periodic review of user accounts and access privileges (recertification), formalized and made explicit.

Why these bite hardest: MFA-everywhere (8.4.2) and password length (8.3.6) touch every system and every user, often colliding with legacy application constraints. The payment page script/tamper controls (6.4.3, 11.6.1) require net-new tooling and vendor management for e-commerce merchants, including smaller SAQ A merchants who assumed "we're fully outsourced" meant nothing new applied to them. Security-control-failure response (10.7.x) requires operational maturity — documented procedures and evidence of actual incident handling — not just technology deployment.

Practical next step: if you haven't already done a gap assessment specifically against these formerly future-dated requirements, that should be the immediate priority, since assessors are now required to test them as fully in-force controls, and any gaps will show up as failed/non-compliant items on your next ROC or SAQ rather than as "future-dated, not yet assessed."

Scope reduction is one of the highest-ROI PCI DSS initiatives available — every system you remove from the CDE is one fewer system subject to all 12 requirements, ongoing evidence collection, and audit testing. With cardholder data (CHD) flowing through half your network today, you likely have a flat or under-segmented architecture, which is itself a finding. Here's a structured approach.

Step 1: Map the actual data flow before designing anything
You can't reduce what you haven't measured. Build (or update) data-flow diagrams (DFDs) showing every system that stores, processes, or transmits PAN or SAD — point of capture (POS, e-commerce, MOTO), transmission paths, processing systems, storage locations, and every connected system (backups, monitoring tools, jump hosts, AD/directory services, log aggregators) that could impact CDE security even if it never touches CHD directly. Under the PCI DSS scoping rule, "connected without adequate segmentation" is enough to pull a system into scope — this is usually the real reason organizations find CHD sprawling across half the network: nothing was ever actually isolating it.

Step 2: Segment the network to shrink scope (the foundational move)
Network segmentation isn't strictly required by PCI DSS, but it is the primary lever for reducing scope, and it's how you turn "half the network" into a small, defensible CDE:
- Deploy network security controls (firewalls, security groups, VLANs with ACLs) between the CDE and all other network zones, with a default-deny posture (Req 1.2–1.4).
- Validate segmentation is actually effective — a firewall rule that "should" block traffic isn't enough; PCI DSS requires penetration testing to verify segmentation effectiveness at least every 6 months (Req 11.4.5).
- Isolate any system that doesn't need CHD access: HR systems, general corporate IT, marketing, and non-payment applications should have zero network path to the CDE.
- Watch for "scope creep" connections — a domain controller, backup server, or SIEM that touches both CDE and non-CDE systems pulls itself (and potentially the systems on the other side) into scope.

Step 3: Reduce what's actually in the CDE via architecture, not just network controls
- Tokenization: Replace stored/processed PAN with a token immediately after authorization wherever possible. Systems that only ever see tokens (not the PAN) can be removed from CDE scope. This is usually the single biggest scope-reduction win for back-office, reporting, and CRM systems that only need "reference" to a card, not the number itself.
- Point-to-Point Encryption (P2PE): For card-present channels, adopt a PCI SSC-validated P2PE solution so that PAN is encrypted at the point of capture (hardware terminal) and never appears in clear text on your network. A validated P2PE deployment can shrink card-present scope down to roughly the SAQ P2PE control set (~33 controls) — physical terminal security plus minimal policy requirements.
- Full outsourcing for e-commerce: If you have a web channel, move to a fully hosted payment page or redirect model (SAQ A-eligible) rather than capturing card data on your own infrastructure — this removes your web/app servers from CDE-adjacent scope entirely, provided the redirect can't be tampered with.
- Eliminate unnecessary CHD storage: Enforce a strict data retention and disposal policy (Req 3.2) — many organizations store PAN "just in case" in logs, backups, or spreadsheets with no defined business need. Purge these and add detection routines (Req 12.10.7) to catch stored PAN turning up in unexpected places going forward.

Step 4: Manage third parties correctly
Any service provider or processor you route CHD through must be independently PCI DSS-compliant (maintain a TPSP register per Req 12.8, verify their AOC annually). Choosing the right processor relationship (fully outsourced vs. partially) directly determines your own SAQ eligibility and scope size.

Step 5: Re-verify scope at least annually and after any change
Once reduced, formally document and re-validate your CDE boundary at least every 12 months and after any significant architecture change (Req 12.5.2), and reconcile your system inventory against your DFDs.

Suggested sequencing: (1) complete accurate data-flow mapping now, (2) segment aggressively to isolate the CDE from the other half of the network, (3) layer in tokenization/P2PE/outsourcing to shrink what's inside that boundary further, (4) validate with a segmentation penetration test before you rely on the new boundary for scope reduction claims. This is general guidance — have your QSA/ISA validate the final scope determination before it's used for SAQ/ROC purposes.

Scope reduction is almost always the highest-leverage compliance investment you can make, because every system, network segment, and person that touches or can influence cardholder data flow is "in scope" for the full PCI DSS control set — and with card data flowing through half your network, you're currently applying (or should be applying) all 12 requirement families to roughly half your infrastructure, which is expensive to assess, expensive to maintain, and a large attack surface.

Here is a practical approach:

1. Map the actual data flow first. Before touching architecture, do a rigorous data discovery and flow-mapping exercise: where does card data enter (POS, e-commerce, call center, file transfers, batch files, backups), where is it transmitted, where is it stored (including accidental storage — logs, temp files, database exports, email attachments, help desk ticketing systems), and where is it disposed of. Most scope bloat comes from data that shouldn't be there in the first place — legacy integrations, debug logging, analytics pipelines that accidentally capture PAN, or spreadsheets used by finance/support teams. Cleaning up unnecessary storage and flow is often the single biggest scope reduction you can achieve, before any network work.

2. Segment the network with validated controls. "Segmentation" for PCI purposes means using firewalls, ACLs, VLANs with enforced access control (not just VLAN tagging), or dedicated physical separation to isolate the cardholder data environment (CDE) from the rest of the network such that systems outside the CDE cannot access it. Segmentation must be validated through penetration testing (PCI DSS Requirement 11.4.5/11.4.6) at least annually and after significant changes, confirming that out-of-scope systems genuinely cannot reach in-scope systems. Without validated segmentation, PCI DSS treats your entire flat network as in-scope — which sounds like your current state.

3. Reduce the number of ways cardholder data enters your environment. Common techniques:
 - Point-to-point encryption (P2PE): validated P2PE solutions encrypt card data at the point of interaction (e.g., a PIN pad) such that your systems never see cleartext PAN; this can shrink certain merchant environments down to the smallest applicable SAQ (e.g., SAQ P2PE).
 - Tokenization: replace PAN with a non-sensitive token immediately after authorization, so downstream systems (loyalty, reporting, CRM, analytics) that only need to reference a transaction never need real PAN.
 - Outsource acceptance/processing to validated third parties: for e-commerce, moving to a hosted payment page or redirect (SAQ A/A-EP territory) removes your web servers from PAN handling. For call centers, using a dual-tone telephone masking/pause-and-resume recording solution keeps PAN out of recorded calls and agent desktops.
 - Eliminate unnecessary retention: if you don't have a documented business, legal, or regulatory need to store PAN, don't store it. Many organizations retain full PAN for chargebacks or reporting when a truncated PAN or token would suffice.

4. Isolate supporting/connected systems properly. Systems that don't store, process, or transmit CDE data but are connected to the CDE (jump boxes, monitoring servers, patch management servers, AD domain controllers used for CDE authentication) are still in scope as "connected-to" or "security-impacting" systems. Decide deliberately: either bring them under full CDE-level controls, or architect distinct, minimally-privileged access paths (dedicated jump hosts, separate AD forests/OUs, restricted service accounts) so they qualify for the lighter "connected-to" scope category rather than pulling your whole enterprise AD into scope.

5. Use a phased target-state architecture. A common pattern: (a) inventory and data-flow diagram current state, (b) define target CDE boundary with justification for every system inside it, (c) build segmentation controls (firewalls/ACLs) to enforce that boundary, (d) migrate/redesign flows so card data no longer needs to traverse out-of-scope segments (e.g., move to tokenized values for anything leaving the CDE), (e) validate with an internal test then formal penetration test, (f) update your PCI DSS scope confirmation (Requirement 12.5.2, done at least annually) to reflect the new, smaller boundary.

6. Watch for scope creep vectors that undo your work: shared credentials between in-scope and out-of-scope systems, backup jobs that pull CDE data to a general-purpose backup server, SIEM/logging pipelines that ingest raw CDE logs onto a shared platform, and remote access tools (RDP, VPN, remote support software) that bridge segments.

7. Get your QSA or ISA involved early in defining the target boundary — scope determination is ultimately validated by them, and it's far cheaper to get their agreement on the target architecture before you build it than to discover after implementation that your segmentation doesn't satisfy their definition of "adequately isolated."

Bottom line: don't think of this as one project — it's a combination of data minimization (stop capturing/storing what you don't need), technology substitution (tokenization, P2PE, outsourcing to validated providers), and enforced network segmentation, validated by testing. Organizations that do all three together typically go from "most of the network in scope" to a compact, well-defined CDE containing only the specific systems that truly need to touch cardholder data.

Both mechanisms exist to handle the same problem — you can't meet a PCI DSS requirement exactly as written — but they work in fundamentally different ways, apply to different situations, and carry different documentation and assessment burdens. Here's the distinction and how to decide which one fits your case.

Compensating Control (Defined Approach only)

A compensating control is used when you're following the Defined Approach (the traditional, prescriptive PCI DSS path) but a specific technical or documented business constraint prevents you from implementing a requirement exactly as stated. Instead of an alternative way to meet the objective, a compensating control is an additional set of controls that offsets the risk of not meeting the literal requirement.

To be valid, a compensating control must:
1. Meet the intent and rigor of the original requirement.
2. Go above and beyond other PCI DSS requirements (it can't just be a control you'd need to have anyway).
3. Be commensurate with the additional risk created by not meeting the requirement as written.
4. Be documented in the ROC/SAQ using a Compensating Control Worksheet (CCW), reassessed at every annual assessment.

Typical use case: A legacy application can't support the 12-character minimum password length. As a compensating control, you might implement a shorter password combined with mandatory MFA, tighter account lockout thresholds, and enhanced logging/monitoring on that specific system — controls that collectively offset the weaker password policy.

Customised Approach (New in v4.0)

The Customised Approach is a formal alternative validation path introduced in PCI DSS v4.0. Rather than reacting to a constraint with an add-on control, you design your own control from the ground up that achieves the stated Objective of the requirement — the Objective is published by PCI SSC for each applicable requirement. This is meant for mature organizations with innovative or non-traditional architectures (cloud-native, zero-trust, microservices) where the prescriptive Defined Approach control doesn't map cleanly onto your technology.

To use the Customised Approach, you must:
1. Perform and document a Targeted Risk Analysis (TRA) for that specific control — including risk description, how the objective is achieved, and evidence of effectiveness.
2. Obtain senior management approval and sign-off on the TRA.
3. Have your QSA assess the control using a Customised Approach Test Plan (CATP) they develop specifically for your implementation (rather than applying PCI SSC's standard testing procedure).
4. Review and revalidate the control at least annually.

Typical use case: Instead of implementing a specific password-based authentication scheme, an organization with a mature zero-trust architecture might use continuous device-and-identity risk scoring plus short-lived cryptographic certificates to achieve the same authentication-assurance objective — an approach that doesn't map to any single Defined Approach control but still satisfies the underlying security intent.

Key differences at a glance:

- Available under: Compensating Control -> Defined Approach only. Customised Approach -> Customised Approach only.
- Trigger: Compensating Control -> Can't meet requirement due to technical/business constraint. Customised Approach -> Choose to meet the requirement's Objective differently.
- Nature: Compensating Control -> Additional controls that offset risk. Customised Approach -> Alternative control replacing the prescriptive one.
- Documentation: Compensating Control -> Compensating Control Worksheet (CCW). Customised Approach -> Targeted Risk Analysis (TRA) + Customised Approach Test Plan (CATP).
- Assessment: Compensating Control -> QSA reviews CCW annually. Customised Approach -> QSA develops and applies a bespoke test plan.
- Eligibility: Compensating Control -> Available for most requirements. Customised Approach -> Not available for SAQ A or SAQ B; generally used in ROC/QSA-assessed environments.
- Management sign-off: Compensating Control -> Not formally required (though good practice). Customised Approach -> Required — senior management must approve the TRA.

Which one fits your situation?

Ask: is the issue a hard constraint on a specific system (legacy app, vendor limitation) where you'd otherwise stay on the standard Defined Approach for everything else? That points to a compensating control — it's faster to document and doesn't require redesigning your assessment methodology.

Is the issue that your overall architecture is genuinely different from what the Defined Approach assumes, and you have (or can build) a mature, risk-based way of meeting the requirement's actual security objective, with the internal capability to run and defend a TRA? That points to the Customised Approach — but be aware it's a heavier lift: it requires QSA involvement to build a bespoke test plan, formal management approval, and annual revalidation, and it isn't available at all if you're validating via SAQ A or SAQ B.

Recommendation: Bring the specific requirement and constraint to your QSA or ISA early — they can confirm whether a CCW is sufficient or whether the requirement genuinely needs a TRA-backed Customised Approach, and can help scope the documentation burden accordingly before your assessment window closes.

These are two distinct mechanisms in PCI DSS for handling a requirement you can't meet exactly as written, and PCI DSS v4.0 changed the landscape significantly by adding the customized approach alongside the traditional compensating controls process. They serve different situations and have different documentation burdens.

Compensating Controls (the traditional route, still available in v4.0 as "defined approach with compensating controls"):
- Used when you cannot meet a requirement's defined approach exactly due to documented, legitimate technical or business constraints (e.g., a legacy system that can't support a specific control, or an application that would break if a specific configuration were applied).
- You must implement an alternative control that sufficiently mitigates the risk the original requirement was designed to address, meeting the intent and rigor of the original requirement.
- Requires completing a Compensating Controls Worksheet (found in the PCI DSS ROC template / SAQ instructions) for each instance, which must document: the constraint, the objective of the original requirement, the identified risk, the specific compensating control implemented, and how that control was validated as effective.
- Compensating controls must be re-evaluated and re-documented at every assessment cycle — they aren't a one-time fix, they need to be revisited to confirm the constraint still exists and the control is still effective.
- Compensating controls are generally viewed as a narrower, more constrained mechanism — meant for edge cases and legacy exceptions, not as a general design philosophy. QSAs scrutinize these heavily because historically they were sometimes used as a way to paper over gaps rather than genuinely equivalent security.

Customized Approach (new in PCI DSS v4.0, a first-class alternative to the "defined approach"):
- Every requirement in v4.0 now has two ways to satisfy it: the "defined approach" (the specific control described in the requirement, e.g., "passwords must be at least 12 characters") or the "customized approach" (design and implement your own control that meets the stated "Customized Approach Objective" published for that requirement, using whatever method you choose, provided it meets that objective).
- This is not a workaround for constraints — it is a deliberate, forward-looking design choice for organizations with mature security programs who want to use innovative or non-standard controls (e.g., risk-based or adaptive authentication instead of a fixed password complexity rule) as long as they can prove the underlying security objective is met.
- Requires a formal, documented risk analysis for each customized control, following the methodology PCI SSC published in v4.0 (documented in Appendix D / E of the ROC template), including: the control design, how it meets the stated objective, applicable risk factors, and testing procedures the QSA will use to validate it (since generic testing procedures obviously don't apply — the assessor has to develop testing procedures specific to your custom control).
- Only certain requirements are eligible for customized approach (some are marked as not eligible in the standard); check the "Applicability Notes" in the DSS itself.
- The customized approach generally requires significantly more assessment rigor and QSA judgment than the defined approach, and is intended for organizations with strong security engineering and risk management maturity — not a quick fix.

Key distinction to keep in mind:
- Compensating controls answer: "I can't do the defined thing because of a specific documented constraint, so here's an equivalent alternative that addresses the same risk." It's retrospective/exception-driven and revisited each cycle.
- Customized approach answers: "I choose not to do the defined thing at all, because my own control design meets the same underlying security objective, potentially better or differently, and I can prove it with a rigorous, methodology-driven risk analysis." It's proactive/design-driven, part of your standing control architecture, and requires a heavier evidentiary and testing burden up front (custom testing procedures the assessor must develop) but doesn't require you to have a "constraint" as a prerequisite.

Practical guidance for your situation:
1. First ask why you can't meet the requirement as written — is it a genuine technical/business constraint on a legacy system (compensating control territory), or is it that you have a genuinely better/different way of achieving the same security outcome (customized approach territory)?
2. If it's a temporary or system-specific limitation, go the compensating controls route — faster to document, well-understood by QSAs, but expect to redo the worksheet every assessment cycle and expect QSAs to push back if the constraint looks avoidable (e.g., "we haven't gotten around to patching this" is not a valid constraint).
3. If it's a mature, intentional alternative control design you want to standardize, engage your QSA early about customized approach — it requires collaboration on testing procedures before the assessment even starts, and your QSA needs specific customized-approach training/experience to assess it properly.
4. Either way, document everything: the objective of the original requirement, your risk analysis, the alternative/custom control, and validation evidence. Under-documentation is the most common reason either approach gets rejected during an assessment.
5. Don't assume every unmet requirement needs one of these two paths — first check whether the requirement genuinely applies to your environment at all (a scoping/applicability question) before treating it as a compensating-control or customized-approach case.

If you tell me which specific requirement you're struggling with, I can help you think through whether a constraint-based compensating control or a customized approach documented risk analysis is the better fit.

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

Your board has identified the right issue. Under DORA (Regulation (EU) 2022/2554), when a third-country-established ICT third-party service provider (TPSP) is designated a Critical ICT Third-Party Provider (CTPP), Art. 31(12) requires that provider to establish a legal presence — specifically a subsidiary — in the EU within 12 months of its designation. Your core-banking SaaS provider was designated in the first CTPP cohort, published by the ESAs (EBA, ESMA, EIOPA) on 18 November 2025 (19 providers, including the major cloud hyperscalers). Counting 12 months from that designation date puts the deadline at approximately 18 November 2026 — the "November 2026 problem" your board is flagging.

**What Art. 31(12) actually requires**

Art. 31 sits in Chapter V, Section II (Art. 31–44) — the systemic oversight framework for CTPPs, which is a supervisory regime between the ESAs and the TPSP, not a direct financial-entity obligation. However, Art. 31(11)–(12) has a practical consequence for you as a client: a third-country CTPP must designate an EU legal representative immediately upon designation (Art. 31(11)) and, per the subsidiary requirement, establish an EU-based subsidiary within the 12-month window so that the Lead Overseer (EBA, ESMA, or EIOPA, assigned per Art. 32) can exercise its oversight powers — information requests (Art. 33), investigations (Art. 34), and on-site inspections (Art. 35) — against an EU entity.

**Why this matters to your board even though it is not your direct obligation**

Art. 42 is explicit: designation of a CTPP does not reduce the financial entity's own responsibility for DORA compliance, and you cannot outsource your regulatory obligations to your provider. If your provider fails to stand up a compliant EU subsidiary by the deadline, that is a material risk signal about the vendor's ability to meet the oversight framework — and it directly affects your own Art. 28(6) concentration-risk assessment and Art. 28(7) exit-strategy readiness for this arrangement.

**What to do now (recommended actions for the board)**

1. **Verify subsidiary status directly with the vendor.** Ask your account team or vendor-risk contact to confirm: (a) has the EU subsidiary been legally established, (b) in which Member State, and (c) is it operational enough to receive Lead Overseer information requests and inspections. Do not rely on marketing statements — request documentary evidence (e.g., certificate of incorporation, EU legal representative designation).

2. **Re-run your Art. 29 concentration-risk assessment** for this arrangement given it supports a critical function (core banking). If this vendor is not fully compliant with 31(12) by the deadline, factor that uncertainty into your risk rating.

3. **Confirm your exit strategy is current and testable (Art. 28(7)).** If subsidiary establishment slips, you should understand your realistic transition timeline, data portability mechanics, and minimum contractual notice period.

4. **Check your Register of Information (CIR (EU) 2024/2956) entry for this arrangement** — TPSP country of establishment and "TPSP within group" fields should reflect the new EU subsidiary once it exists, and your next annual RoI submission should be updated accordingly.

5. **Monitor Lead Overseer activity.** 2026 is the first full oversight cycle for the CTPP framework; JETs (Joint Examination Teams, per CDR (EU) 2025/420) are conducting initial examinations, and early recommendations to CTPPs (Art. 36) are possible this year. Any recommendation issued to your provider could affect your service terms — this is a "note it and monitor" item under Art. 40 information flows.

**Bottom line for the board:** this is not a new obligation created for you, but a vendor-compliance deadline that is a leading indicator of your own third-party risk exposure. Confirm subsidiary status now, document the verification, and keep your exit options current in case the deadline is missed.

*General compliance information, not legal advice — confirm current requirements with qualified counsel or your compliance function.*

The "November 2026 problem" your board is sensing relates to the oversight mechanics DORA built around Critical ICT Third-Party Providers (CTPPs), and specifically to how the Lead Overseer framework interacts with a US-established provider.

Background: DORA (Regulation (EU) 2022/2554) became applicable on 17 January 2025. One of its most consequential features is the direct oversight regime for CTPPs — ICT providers (cloud, core banking platforms, data analytics, etc.) that the European Supervisory Authorities (EBA, ESMA, EIOPA), acting through the Joint Committee, designate as "critical" to the financial sector based on systemic-impact criteria (substitutability, number of financial entities relying on them, degree of criticality of the services supported, etc.). Once designated, a CTPP is assigned a "Lead Overseer" — one of the three ESAs — which then has powers to request information, conduct inspections, issue recommendations, and ultimately, in cases of persistent non-compliance, recommend that financial entities suspend or terminate their contractual relationship with that provider.

If your core-banking SaaS provider was designated in November 2025, the practical oversight machinery generally phases in over roughly 12 months from designation: the Lead Overseer conducts its initial risk assessment, issues its oversight plan, and — critically — if it identifies material weaknesses in the provider's risk management, it can issue formal recommendations. Providers are typically expected to respond and remediate within a defined window, often around 60 days, and the Lead Overseer publishes/communicates outcomes to the competent authorities of the financial entities using that provider.

So the "November 2026" milestone is most likely the point at which the first full 12-month oversight cycle for your provider concludes — meaning the Lead Overseer's initial assessment, any recommendations, and the enforcement escalation path all come to a head. This matters to your board for several reasons:

1. Recommendation exposure: If the Lead Overseer has flagged gaps (e.g., in subcontracting transparency, exit strategy robustness, concentration risk, or security controls) and the provider hasn't fully remediated, your national competent authority may require you, as a "user" financial entity, to demonstrate you've factored that risk into your own ICT risk management framework and your Register of Information. You could face supervisory pressure to diversify or accelerate exit planning even if you have no direct contractual leverage over the CTPP.

2. US jurisdiction friction: Because the provider is US-established rather than EU-established, DORA's oversight regime relies on cooperation arrangements between EU authorities and third-country regulators, plus contractual commitments the provider must accept (subjecting itself to EU oversight, granting access/audit rights, etc.). If the provider has been slow or incomplete in accepting these obligations, tensions between US and EU legal/regulatory expectations (data access, subpoena conflicts, US CLOUD Act issues) can surface as unresolved risk by month 12 — precisely when your own supervisors will be looking for evidence of contingency planning.

3. Contractual and exit-plan deadlines: DORA requires financial entities to have documented exit strategies and to test them. If oversight findings suggest the provider is a single point of failure or has concentration risk across the EU financial sector, your regulator may specifically ask you to show a credible, tested exit plan (alternative provider, data portability, reversibility of services) — not just a paper policy — by around this anniversary point.

What your board should actually do before November 2026:
- Obtain, if possible, any communications the provider has received from its Lead Overseer (providers are often required to inform client financial entities of material oversight findings).
- Refresh your criticality/concentration risk assessment for this provider in your Register of Information.
- Stress-test your exit strategy: confirm data extraction formats, transition timelines, and a genuinely viable alternative.
- Update your board risk register and ICT risk management framework documentation to show active monitoring of this specific designation, not just generic third-party risk language.
- Engage your national competent authority proactively if you anticipate gaps, rather than waiting to be asked.

In short: November 2026 is the point where oversight scrutiny of a newly designated CTPP typically intensifies and where any unresolved US/EU jurisdictional or remediation gaps become visible to your own supervisor — treat it as a checkpoint, not a deadline that resolves itself.

Here is the DORA-compliant walk-through for a cyber attack that took down payment processing for six hours, structured around Chapter III (Art. 17–23): incident management (Art. 17), classification (Art. 18), and reporting (Art. 19), plus the payment-specific overlay in Art. 23.

**Step 1 — Confirm it is an ICT-related incident (Art. 3(8))**

A cyber attack causing a six-hour outage of payment processing clearly qualifies: an unplanned event that had an adverse impact on the availability of your services. That triggers your documented incident management process under Art. 17(1), including detection, escalation, and classification procedures.

**Step 2 — Classify against Art. 18(1) criteria and CDR (EU) 2024/1772 thresholds**

Apply each criterion:
- **(a) Clients/transactions affected** — quantify clients unable to transact and the value of impacted transactions.
- **(b) Reputational impact** — assess likely media/regulatory attention.
- **(c) Duration and geographic spread** — this is decisive here. CDR (EU) 2024/1772 sets an indicative materiality threshold of **≥2 hours of unavailability for critical services**. A six-hour outage of payment processing — a critical function — clearly exceeds this.
- **(d) Data losses** — assess whether the attack also compromised data integrity/confidentiality, not just availability.
- **(e) Criticality of the service** — payment processing is core to your license; this criterion is met.
- **(f) Economic impact** — quantify direct and indirect losses.

Classification uses **OR logic**: meeting or exceeding *any single* threshold is sufficient to classify the incident as **major**. On duration alone (6h vs. the ~2h threshold), this incident should be classified as major. Do not wait for root-cause confirmation before classifying — classify promptly once thresholds are met; delayed classification to "buy time" is itself a supervisory red flag under Art. 17(1).

**Step 3 — Escalate internally (Art. 17(3))**

Report to senior management immediately and ensure the board (management body) is informed, consistent with the board's overall ICT-risk oversight duty under Art. 5.

**Step 4 — Three-stage regulatory reporting (Art. 19 + CDR (EU) 2025/301 + CIR (EU) 2025/302)**

| Stage | Deadline (from classification as major) | Content |
|---|---|---|
| Initial notification | 4 hours | Incident reference, entity details, classification rationale, initial client/financial impact, nature of the attack |
| Intermediate report | 72 hours | Updated impact assessment, root-cause indicators, containment/response actions, revised recovery estimate |
| Final report | 1 month (from the initial notification) | Confirmed root cause, full impact assessment, complete timeline, preventive measures, lessons learned |

The clocks start at **classification**, not detection — but classify promptly (see above). The 4-hour clock runs 24/7/365; there is no business-hours exception. Use the standard templates in CIR (EU) 2025/302, submitted to your **home Member State competent authority** (Art. 19(1)).

**Step 5 — Apply the payment-specific overlay (Art. 23)**

Because this incident affects payment processing, Art. 23 applies alongside the standard Chapter III process. CIR (EU) 2025/302 includes a dedicated payment-incident template aligned with legacy PSD2 Art. 96 fields. Since DORA's major-incident threshold is met, DORA reporting supersedes PSD2 Art. 96 for this incident; confirm with your national competent authority whether any sub-threshold PSD2 obligations still apply separately. If you are dual-licensed (banking + payment institution), confirm in advance whether your single competent authority distributes the report internally or whether parallel filings are needed.

**Step 6 — Client communication (Art. 17(4))**

Notify affected clients promptly, including measures taken and, where known, an estimated recovery time.

**Step 7 — Post-incident learning (Art. 13)**

Feed the confirmed root cause and lessons learned from the final report into your ICT risk management framework review (Art. 6(5)) and your threat-intelligence process (Art. 13(2)–(3)).

**Bottom line:** on duration alone, this is very likely a **major ICT-related incident** — begin the 4-hour initial notification clock now, in parallel with containment and client notification workstreams.

*General compliance information, not legal advice — verify against the CDR (EU) 2024/1772 thresholds applicable to your entity type and consult qualified counsel for the filing.*

Here is how to walk through this under DORA's ICT-related incident classification and reporting framework (Regulation (EU) 2022/2554, Chapter III, supplemented by the RTS/ITS on incident classification and reporting).

Step 1 — Confirm it's an "ICT-related incident."
DORA defines an ICT-related incident broadly: a single event or series of linked events that compromises the availability, authenticity, integrity, or confidentiality of network and information systems, adversely affecting data or the services provided. A cyber attack that took payment processing offline for six hours clearly qualifies — it's an availability compromise caused by a malicious act, so it's also a "cyber threat"/attack-related incident, which triggers additional voluntary threat-sharing considerations later.

Step 2 — Classify as "major" (or not) using the RTS criteria.
DORA doesn't require reporting every incident — only those classified as "major" based on defined thresholds across several criteria, typically including:
- Clients, financial counterparts, and transactions affected (absolute numbers and/or percentage of your normal volumes).
- Reputational impact (media attention, complaints).
- Duration and service downtime — six hours of payment-processing outage is a significant duration criterion on its own for many entities, especially if payment services are a critical/important function.
- Geographical spread (multiple member states affected).
- Data losses (confidentiality, integrity, availability of data affected).
- Economic impact (direct and indirect costs).
- Whether it affected a critical or important function.

Since payment processing is almost certainly a "critical or important function" for a financial entity, a six-hour outage is very likely to breach the duration/severity thresholds set in the classification RTS, especially when combined with client/transaction impact. Run the actual numbers through your incident classification tool/matrix (transactions affected, client numbers, downtime vs. your defined critical-function tolerance, economic impact estimate) and document the classification decision itself — supervisors will ask to see the reasoning, not just the conclusion.

Step 3 — Trigger the reporting timeline.
If classified as major, DORA requires a three-stage report to your competent authority (e.g., the relevant national regulator, or ECB/EBA-coordinated channel depending on your sector):
1. Initial notification — without undue delay, and in any event within 4 hours of classifying the incident as major, and no later than 24 hours from when you first became aware of the incident (the exact clock detail is set out in the ITS; the intent is "as soon as possible" once classification occurs).
2. Intermediate report — updating on status, actions taken, and impact, typically within 72 hours of the initial notification, and updated further if the situation evolves.
3. Final report — once root cause analysis is complete, actual (not estimated) impacts are known, and remediation is done — generally within one month of the intermediate report, though exact windows should be checked against the applicable ITS.

Step 4 — Use the standardized templates.
Reports must use the prescribed reporting templates/fields under the ITS, covering incident description, detection method, root cause, impact metrics, and remediation actions. Coordinate with your ICT risk management function to ensure consistent data across the three reports.

Step 5 — Consider cross-cutting elements.
- If a third-party ICT provider (e.g., a payment gateway or hosting provider) was implicated, cross-reference your Register of Information and assess whether this also triggers reporting or contractual notification obligations from that provider to you.
- If the incident involved a cyber-attack with broader threat intelligence value, DORA encourages (and some national regimes may require) voluntary reporting of significant cyber threats, and you may want to loop in your national CSIRT.
- Assess client communication obligations — DORA requires informing affected clients without undue delay if their financial interests could be affected.
- Board and governance: DORA expects senior management to be informed and to have approved your incident response and communication before regulator submission; document that governance trail.

Practical next steps for your team:
1. Immediately confirm classification status against your major-incident thresholds and document it with timestamps.
2. If major, submit the initial notification within the 4-hour/24-hour window from classification/awareness.
3. Prepare the intermediate report within 72 hours capturing impact scope, root cause hypothesis, and containment actions.
4. Track toward the final report with confirmed root cause, total impact, and remediation/lessons-learned actions feeding back into your ICT risk management framework and, if relevant, your third-party risk assessment.

Given the significance of a payment-processing outage, treat this as presumptively major and start the notification clock now while classification analysis is finalized in parallel — do not wait for full certainty before making the initial notification.

Yes — DORA applies to you, and August 2026 marks a specific operational change in how Luxembourg supervises that application to third-country branches like yours.

**Does DORA apply to a Luxembourg branch of a Singapore bank?**

DORA (Regulation (EU) 2022/2554) is scoped in Art. 2 to a broad list of EU financial entities, and the European Commission's Q&A of 17 December 2025 confirmed that **third-country branches operating in the EU fall within DORA's scope** — the branch's EU-based operations are subject to the same ICT risk management, incident reporting, testing, and third-party risk obligations as an EU-incorporated entity, even though your parent (the Singapore bank) is established outside the EU. This closed a period of interpretive ambiguity that had existed since DORA's 17 January 2025 application date. Practically, this means your Luxembourg branch needs its own:
- Documented ICT risk management framework (Chapter II, Art. 5–16), proportionate to the branch's size and complexity (Art. 4);
- Incident classification and reporting capability (Chapter III, Art. 17–23), reporting to your Luxembourg competent authority — the CSSF;
- Digital operational resilience testing programme (Chapter IV, Art. 24–27); and
- ICT third-party risk management, including a Register of Information (Art. 28) covering the branch's own ICT arrangements, even where some services are shared with or provided by the Singapore parent.

**What changed in August 2026**

The CSSF operationalised the Commission's December 2025 clarification on **27 August 2026** via **Circular CSSF 26/915**. Before this circular, third-country branches (TCBs) in Luxembourg were still administratively anchored to the legacy ICT/outsourcing circular regime. Circular 26/915 formally moved TCBs out of those legacy circulars and into the **DORA-aligned circular suite**, specifically:
- **Circular CSSF 25/882** — governing ICT third-party use (the Luxembourg-level operational counterpart to DORA Art. 28–30 obligations), now explicitly extended to TCBs; and
- **Circular CSSF 25/893** — governing incident reporting, also now explicitly extended to TCBs, aligning your branch's local reporting expectations with the DORA Art. 19 three-stage timeline (4 hours / 72 hours / 1 month) rather than any residual legacy branch-reporting practice.

**What this means for you in practice**

1. **Confirm your branch is no longer relying on legacy ICT/outsourcing guidance.** If your Luxembourg compliance documentation still cites the pre-DORA circulars for ICT third-party arrangements or incident reporting, it needs updating to reference 25/882 and 25/893 as applied to TCBs under 26/915.
2. **Stand up (or confirm) your Register of Information.** As a branch, you should already be contributing to the RoI submission process (CIR (EU) 2024/2956) for arrangements relevant to your Luxembourg operations; check whether your Singapore parent's group-level ICT arrangements (e.g., shared core banking or cloud infrastructure) need to be reflected at branch level.
3. **Verify your incident classification and 4h/72h/1-month reporting chain runs to the CSSF**, not just to a regional or group incident desk. Confirm who at the branch has authority to file with the CSSF within the 4-hour window, since the clock runs 24/7 with no business-hours exception.
4. **Do not assume group-level (Singapore or MAS-supervised) resilience testing satisfies DORA.** Your Luxembourg branch needs its own Art. 24 testing programme evidence, proportionate to its scale.
5. **Review contracts supporting your branch's critical functions** against Art. 30(2) — particularly if the branch relies on parent-negotiated vendor contracts that may not include EU-specific audit and competent-authority access rights.

**Bottom line:** DORA has applied to your branch since 17 January 2025 in principle; August 2026 is when the CSSF made that application concrete and enforceable through branch-specific circular guidance. Treat 26/915 as your trigger to reconcile branch-level documentation with the DORA circular suite now.

*General compliance information, not legal advice — confirm current CSSF circular text and scope with qualified Luxembourg counsel.*

Yes — DORA applies to you, and the fact that your parent is a Singapore bank doesn't exempt the Luxembourg branch.

Why DORA applies:
DORA (Regulation (EU) 2022/2554) applies to "financial entities" as defined in Article 2, and that definition is drawn from existing EU sectoral legislation (CRD/CRR for credit institutions, etc.) using the concept of authorization/establishment in the EU. A branch of a third-country (non-EEA) bank that is authorized to operate in an EU member state — here, Luxembourg, via the CSSF — is generally treated as falling within scope for the activities conducted through that branch, because the branch itself is licensed and supervised under EU/Luxembourg banking law (transposing CRD requirements for third-country branches). In practice, this means:
- The Luxembourg branch must comply with DORA's ICT risk management framework requirements (Chapter II) for the activities and systems it operates in/through the branch.
- It must maintain its own (or a clearly documented group-shared but branch-specific) ICT risk management framework, incident classification and reporting processes, digital operational resilience testing, and third-party risk management including its Register of Information entries for ICT contracts relevant to the branch.
- Incident reporting obligations run to the CSSF (Luxembourg's competent authority) for major ICT-related incidents affecting the branch's activities.
- If the branch relies on group-level or Singapore head-office ICT systems and providers, those arrangements must still be captured in the branch's Register of Information and risk assessments — DORA does not accept "the parent handles it" as a substitute for branch-level accountability, though group-wide arrangements and simplified frameworks may be usable for entities meeting certain size/risk criteria (Article 16's simplified ICT risk management framework applies to smaller/less complex entities such as small non-interconnected investment firms — check whether your branch qualifies for any proportionality relief, though large or systemically relevant branches generally will not).

Key nuance on third-country branches: The regulatory treatment of third-country branches under DORA has been a genuinely debated area, because DORA's core definitions are entity-based (credit institutions authorized under CRD) rather than explicitly branch-based, and there have been ongoing clarifications from the European Commission, EBA, and national competent authorities about the precise scope of application to non-EEA bank branches, especially regarding which parts of the ICT risk framework must be maintained locally versus can be inherited from group policies. The CSSF has generally taken the position that branches of third-country credit institutions established in Luxembourg fall under its supervisory remit for DORA purposes for the activities booked through the branch, consistent with its broader approach to third-country branch supervision.

What changed in August 2026:
Without direct access to a live regulatory feed, I can't confirm a specific named CSSF circular, EBA Q&A, or Commission delegated act that took effect in August 2026 — you should verify this against the CSSF's published circulars and the EU's Official Journal for that month, since DORA's technical standards and guidance have continued to evolve through 2025-2026 (RTS/ITS finalization, Q&As on third-country branch scope, subcontracting chains, and the Register of Information templates have all seen iterative updates). Likely candidates for an August 2026 development affecting your situation include:
- A CSSF circular or FAQ update clarifying reporting channels, templates, or expectations specifically for third-country branches.
- An EBA/ESA Q&A or guideline update on how third-country branches should populate the Register of Information (e.g., how to reflect group-level contracts with providers used across multiple jurisdictions).
- Movement in the CTPP oversight regime that indirectly affects branches relying on Asia-Pacific or global ICT providers your Singapore parent also uses.
- Possible developments tied to EU-Singapore or EU-ASEAN regulatory dialogue on cross-border financial services and data flows, which sometimes intersect with operational resilience expectations for third-country group structures.

Recommended action: Ask your compliance/legal team to pull the specific CSSF circular or EBA publication dated August 2026 referenced by your board or counterparts — given the pace of DORA technical guidance, it's plausible this is a scope clarification, a Register of Information taxonomy update, or a reporting-channel change rather than a change to the core "does DORA apply" answer, which has been settled since application began in January 2025. In the meantime, treat the branch as fully in scope, ensure your Luxembourg-specific documentation doesn't simply reference Singapore head-office policies without branch-level tailoring, and confirm your Register of Information reflects Luxembourg-relevant ICT third-party arrangements distinctly from group-wide ones.

**What the Register of Information is**

The Register of Information (RoI) is the DORA-mandated central inventory that every in-scope financial entity must maintain of **all** its ICT service arrangements — not just those supporting critical or important functions. The obligation originates in Art. 28(3) DORA (maintain and submit) and the mandatory content/format is set out in **CIR (EU) 2024/2956**, the Implementing Technical Standard on RoI templates (Art. 28(9)).

Each entry in the register represents one ICT arrangement and must capture, at minimum:
- **Entity identification**: your LEI, name, and regulated entity type
- **TPSP identification**: legal name, LEI, country of establishment, and whether the provider is part of your corporate group
- **Arrangement details**: a unique reference, arrangement type (SaaS/IaaS/PaaS/other), and a service description
- **Function classification**: whether the arrangement supports a critical or important function (Y/N) and which function
- **Data fields**: data types processed, sensitivity, and primary/backup storage locations
- **Contractual terms**: start/end dates, termination notice period
- **Sub-processors**: whether used, and their names/LEIs/locations
- **Substitutability and exit**: an ease-of-replacement rating and a reference to the arrangement's exit strategy
- **Audit fields**: whether audit rights are exercisable and by what method (direct, pooled, or third-party certification)

A common compliance error (flagged explicitly in DORA guidance) is treating the RoI as "just a vendor list" — it is not. It requires structured, arrangement-level detail with mandatory fields, LEIs, and criticality flags; a general vendor spreadsheet will not satisfy CIR (EU) 2024/2956.

**Why the register exists**

Beyond your own risk management (Art. 28(1), Art. 28(6) concentration-risk assessment), the RoI feeds the EU's systemic oversight machinery: the ESAs (EBA, ESMA, EIOPA) aggregate all entities' submissions to identify which ICT third-party providers are systemically important across the sector, which is the evidentiary basis for designating **Critical ICT Third-Party Providers (CTPPs)** under Art. 31 (using criteria in CDR (EU) 2024/1502).

**Where the annual cycle stands (as of September 2026)**

The Register is a continuously maintained document with an **annual submission cycle** to your competent authority (at least once a year, or on request). The most recent completed cycle used **31 December 2025 as the reference date**, and national competent authorities (NCAs) opened submission windows in **Q1 2026**, with most jurisdictions setting a **31 March 2026 deadline**. That cycle has now closed. The ESAs used aggregated 2026-cycle submissions, together with the November 2025 CTPP designation cohort, as part of the evidentiary base for the ongoing oversight framework — 2026 being the first full oversight cycle for designated CTPPs.

**What you should be doing now**

1. **Do not treat the RoI as a once-a-year task.** Update it continuously as arrangements are entered, modified, or terminated, and as sub-processor chains or data locations change — the annual submission is meant to be a snapshot of a document that is already current.
2. **Prepare for the next annual cycle** (expect a reference date of 31 December 2026, with NCA submission windows opening in Q1 2027, likely following the same ~31 March pattern seen this year — confirm your specific NCA's exact deadline, as these are set nationally within the EU-harmonised template).
3. **Reconcile your RoI against your Art. 28(6) concentration-risk assessment** — the substitutability and criticality fields in the register should match the entities you have flagged as concentration risks.
4. **Ensure LEIs are populated** for your entity and all TPSPs; where a TPSP lacks an LEI, document that explicitly and use a national business registration number as a substitute, per CIR (EU) 2024/2956 guidance.
5. **If you rely on a CTPP** (one of the 19 providers designated in November 2025), make sure your RoI entry accurately reflects current TPSP details, since Lead Overseers and Joint Examination Teams are now conducting the first full oversight cycle and may rely on aggregated RoI data.

*General compliance information, not legal advice — confirm your specific NCA's submission deadline and template version with qualified counsel or your compliance function.*

The Register of Information (RoI) is one of DORA's most operationally demanding requirements (Article 28(3) and the related RTS/ITS on the register's content, format, and templates). It's essentially a structured, standardized inventory that every financial entity in scope must maintain, documenting all contractual arrangements with ICT third-party service providers.

What it contains:
- Every ICT third-party contract, including sub-contracting chains where relevant to critical/important functions.
- Details of each provider: legal entity identifiers (LEI), corporate structure, country of establishment, parent company.
- Which functions/services each contract supports, and whether those functions are "critical or important."
- Substitutability assessments and concentration risk indicators (are you overly reliant on one provider or region?).
- Contractual details: start/end dates, governing law, termination and exit provisions, service levels, audit and access rights, subcontracting permissions, and data location.
- A designated register "owner" and governance sign-off, since the RoI must be maintained at both entity and, where applicable, consolidated/group level.

Why it exists:
The RoI serves two purposes: (1) it forces financial entities to actually know and document their full ICT supply chain, including nested subcontractors, rather than having fragmented procurement records; and (2) it feeds the European Supervisory Authorities' process for identifying Critical ICT Third-Party Providers (CTPPs) for the DORA oversight regime — regulators aggregate RoI submissions across the sector to see which providers show up most often or support the most critical functions, which is how CTPP designations get made.

Format and submission mechanics:
The RoI must be maintained using the standardized templates published via the RTS/ITS (a defined set of tables/fields, submitted typically in XML or another prescribed machine-readable format via national competent authorities into a centralized EU system). Competent authorities collect entity-level (and consolidating entity/group-level) registers and forward them to the ESAs. Getting the technical template right — correct LEIs, consistent entity identifiers, correctly flagged "critical or important" functions — has been one of the biggest practical pain points, since errors or inconsistent entity mapping across a group cause rejected submissions.

Where the annual cycle stands:
DORA became applicable 17 January 2025, and the first RoI submission cycle ran in 2025, with financial entities required to submit their registers to national competent authorities (who then forwarded to the ESAs) around a spring 2025 deadline window that many national regulators set (commonly around end of April 2025, though exact dates were set nationally). This first cycle was widely reported as a heavy lift — many financial entities and especially smaller ones struggled with the XML templates, LEI data quality, and mapping subcontracting chains, and the ESAs/national authorities provided extended guidance, FAQs, and in some cases informal flexibility on timing and error correction during that first pass.

Going forward, the RoI is meant to operate on an annual reporting cycle: entities update and resubmit their registers annually (with the reference date and submission window set by national competent authorities, generally aligned to a similar spring timeframe each year), reflecting the current state of ICT third-party arrangements as of a set reference date (e.g., year-end or a defined cutoff). Entities are also expected to maintain the register on an ongoing/live basis internally — not just as an annual compliance exercise — since it underpins both incident response context and exit-strategy planning.

By your "rerun 2026" context, you'd be looking at either the second or an ongoing annual submission cycle (2026 submission, reflecting a 2025 year-end or similarly defined reference date, depending on your national competent authority's exact calendar). Practical implications at this stage of the cycle:
- Expect the ESAs to have made (or be finalizing) additional CTPP designations based on the first 2025 dataset — recheck whether any of your providers were newly designated.
- Data quality expectations are rising in year two; regulators that were lenient on template errors in the first cycle are less likely to be lenient now.
- If your group structure changed, or you added/removed ICT providers, your RoI update needs to reflect that accurately, including any new subcontracting layers.
- Treat the RoI as a living document feeding your board reporting, third-party risk assessments, and exit-strategy testing — not a once-a-year form-filling exercise.

Recommendation: confirm your national competent authority's specific 2026 submission deadline and reference date (these can differ slightly by member state), and run an internal data-quality review of LEIs, criticality flags, and subcontracting chains before submission, since inconsistencies are the most common cause of supervisory follow-up questions.

DORA's contractual requirements for ICT providers are set out in **Art. 30**, detailed further by **CDR (EU) 2024/1773** (general contractual content) and **CDR (EU) 2025/532** (sub-contracting specifically). The scope and rigor of what's required depends on whether the arrangement supports a **critical or important function (CIF)**.

**Step 1 — Determine which regime applies**

- If the ICT service supports a critical or important function (disruption would materially impair legal compliance, financial performance, or continuity of services), the **full Art. 30(2)(a)–(i)** provisions apply.
- If it does not, a **lighter set of provisions** applies under Art. 30(3): service description, data locations, basic availability/security commitments, incident notification, and exit/termination terms. Do not assume every vendor needs the full checklist — that is a common over-application error.

**Step 2 — For critical/important arrangements, the mandatory Art. 30(2) clauses are:**

| Clause | Requirement |
|---|---|
| **(a) Service description** | Clear, complete description of the ICT services provided |
| **(b) Data locations** | Where services are performed and data stored/processed, plus notification obligations if locations change |
| **(c) Data protection** | Provisions ensuring compliance with applicable data protection law (e.g., GDPR) |
| **(d) Availability/integrity/security** | Service levels, security standards, and the provider's incident response obligations |
| **(e) Audit and access rights** | Full and unrestricted audit rights for your entity, plus access rights for your competent authority and resolution authority — including on-site inspection |
| **(f) Termination rights** | Clear termination conditions, minimum notice periods, and transition-service obligations on the provider |
| **(g) Reporting and monitoring** | The provider's obligation to report ICT incidents to you, plus ongoing performance monitoring |
| **(h) Data portability/migration** | Machine-readable data return on termination, migration assistance, and deletion certification |
| **(i) Sub-contracting** | Conditions for the provider to sub-contract, prior written consent, equivalent provisions flowing down to sub-processors, and your right to audit sub-processors (detailed further in CDR (EU) 2025/532) |

**Step 3 — Watch the audit-rights clause (e) — this is the most commonly failed provision**

Large cloud/SaaS providers often offer only pooled third-party audit reports (SOC 2, ISO 27001) rather than direct, entity-specific audit rights. ESA guidance allows pooled audits to *partially* satisfy your own audit right **only if** you document in writing why a direct audit is impracticable and confirm the pooled outputs are meaningful — with that acceptance approved at an appropriate governance level (e.g., CRO or board). Critically, **the competent authority's and resolution authority's on-site inspection right is non-waivable**: even if you accept pooled audits for your own purposes, the contract must still contain an express, unconditional clause preserving your regulator's right to inspect the provider's premises directly. A clause that routes regulator access through the vendor's own third-party audit programme does **not** satisfy Art. 30(2)(e) — this is a frequent gap in standard cloud contracts.

**Step 4 — Before renewing any CIF contract (Art. 30(4))**

Confirm service levels remain adequate, audit and access rights remain practically exercisable (not just present on paper), your exit strategy is still viable, and no new concentration or substitutability risks have emerged since signing.

**Practical checklist to run against each existing contract:**
- Service description present and current
- Primary and secondary data locations specified, with change-notification clause
- Data protection/GDPR provisions included
- Service levels and security standards defined
- Audit rights for your entity, your competent authority, and resolution authority — each separately confirmed
- Termination-for-cause and termination-for-regulatory-reasons clauses, with minimum notice period
- Incident reporting obligation on the provider
- Data portability, migration assistance, and deletion certification on exit
- Sub-contracting consent and flow-down provisions, with sub-processor audit rights

Any contract missing the audit/access clause, the non-waivable regulator inspection right, or the sub-contracting flow-down provisions should be flagged as a priority remediation item — these are the three gaps regulators most commonly cite.

*General compliance information, not legal advice — have contracts reviewed against CDR (EU) 2024/1773 and CDR (EU) 2025/532 by qualified counsel before relying on this checklist for negotiation.*

DORA (Article 30) sets out mandatory contractual provisions for arrangements with ICT third-party service providers, with an enhanced set of requirements specifically for contracts supporting "critical or important functions." Here's the breakdown your contract review should be checking against.

Baseline clauses required for ALL ICT third-party contracts (Article 30(2)):
1. A clear, complete description of all functions and ICT services to be provided, including whether subcontracting of a critical or important function (or material parts of it) is permitted, and if so, the conditions under which it may occur.
2. The locations (regions/countries) where the contracted functions and services will be provided and where data will be processed, including a requirement to notify the financial entity in advance of any change.
3. Provisions on data availability, integrity, confidentiality, and protection, including in the case of insolvency, resolution, or discontinuation of the provider's business, and requirements for data to be accessible, recoverable, and returnable in an easily accessible format upon termination.
4. Service level descriptions, including precise quantitative and qualitative performance targets, to allow effective monitoring and prompt remedial action.
5. Provisions on assistance from the provider in the event of an ICT incident connected to the service provided, at no additional cost or at a cost determined in advance.
6. An obligation on the provider to fully cooperate with the financial entity's competent authorities and resolution authorities.
7. Termination rights and associated minimum notice periods, aligned with supervisory expectations.
8. Conditions for participation of the ICT third-party provider in the financial entity's ICT security awareness programs and digital operational resilience training.

Enhanced clauses required ADDITIONALLY for contracts supporting critical or important functions (Article 30(3)):
9. Full service level descriptions with precise, measurable targets covering not just performance but availability, and clear escalation procedures.
10. Notice periods and reporting obligations for the provider, including notifying the financial entity of any development that could materially impact its ability to deliver the function effectively and in line with agreed service levels.
11. A requirement for the provider to implement and test business contingency plans and to have ICT security measures, tools, and policies that provide an appropriate level of security for the provision of services, in line with the financial entity's regulatory framework.
12. The right of the financial entity to monitor, on an ongoing basis, the ICT third-party provider's performance — including unrestricted rights of access, inspection, and audit by the financial entity or an appointed third party, and by the competent authority, plus the right to obtain copies of relevant reports.
13. Exit strategies: mandatory transition periods during which the provider will continue providing services to reduce the risk of disruption, allowing the financial entity to migrate to another provider or bring the service in-house.
14. Cooperation clauses requiring participation in threat-led penetration testing (TLPT) where applicable.
15. Subcontracting governance: where subcontracting of critical/important functions is permitted, the contract must set out the conditions, including that subcontractors also meet equivalent standards, that the financial entity retains visibility into the full subcontracting chain, and rights to object to material changes in subcontractors.
16. Termination rights specific to critical/important function contracts, including the ability to terminate where: the provider breaches applicable law/regulation materially; circumstances at the provider are identified that could alter the performance of functions (including material changes affecting arrangements or subcontracting chains); the provider shows weaknesses in ICT risk management, particularly around handling personal/sensitive data; or the competent authority can no longer effectively supervise the financial entity as a result of the contract's conditions; and including provisions for the Lead Overseer's recommendations regarding CTPPs (financial entities must be able to terminate if a Lead Overseer identifies serious concerns about a designated CTPP that the entity relies on).

Practical drafting/negotiation notes:
- Use the European Supervisory Authorities' standard contractual clauses guidance and templates as a benchmark where available; many providers (especially large cloud/SaaS vendors) have already published "DORA addenda" or "DORA riders" to their standard terms — compare these against Article 30 systematically rather than accepting vendor-drafted language at face value, since vendor templates sometimes soften audit rights or exit-assistance obligations.
- Audit and access rights are the most commonly negotiated-down clause — insist on genuine, not merely "on request and subject to provider discretion," inspection rights, including for your regulator.
- Exit provisions need real substance: define the transition period length, data format/portability commitments, and provider cooperation obligations concretely, not just "reasonable assistance."
- Map every contract into your Register of Information with the criticality flag correctly set, since that determines which of the two clause tiers legally applies.
- For existing legacy contracts, DORA required entities to review and, where necessary, renegotiate/amend existing ICT contracts to bring them into compliance — if any of your critical/important function contracts predate DORA and haven't been amended, that's a live gap to close.

Bottom line: every ICT contract needs the eight baseline clauses; anything supporting a critical or important function needs the fuller Article 30(3) set, with audit rights, exit strategy, and CTPP-related termination rights being the areas regulators scrutinize most closely.

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

As of September 14, 2026, no CMMC Reform Task Force report has been published. Here is the accurate state of play and what it means for your program.

**Timeline recap.** On July 13, 2026, DoD suspended CMMC Phase 2 — specifically the C3PAO third-party assessment requirements that were due to appear in new contract solicitations starting November 10, 2026 — via two policy memoranda (from the DoW CIO and USD(A&S)). That suspension placed pending CMMC Phase 2 milestones in abeyance and stood up a 60-day CMMC Reform Task Force review. The 60-day clock from July 13 expired in mid-September, and today's status is that the report has not been publicly released. Even internal delivery to the DoW CIO is unconfirmed — as of September 9 the CIO indicated the team was still working through more than 1,100 RFI responses. Public release is expected late September to early October, but that timing is unconfirmed and could slip further.

**What has NOT changed.** This is the most important message for your organization: the suspension only touched Phase 2 (C3PAO third-party certification and DIBCAC-led Level 3 assessments). It did not touch the underlying law. 32 CFR Part 170 remains in effect, and DFARS 252.204-7012 (safeguarding CUI + 72-hour DIBNET incident reporting), 7019 (self-assessment), 7020 (SPRS posting), and 7021 (CMMC flow-down) all remain active obligations. Phase 1 self-assessments, SPRS score submissions, and annual senior-official affirmations continue unchanged. During the interim period, requiring activities may only designate Level 1 (Self) or Level 2 (Self) in new contract language — not Level 2 (C3PAO) or Level 3 (DIBCAC) — and C3PAO/DIBCAC requirements are being stripped from solicitations and existing contracts at the next option or modification point.

**What the task force is reportedly weighing (signal, not policy).** Public CIO statements — not the report itself, which doesn't exist yet — have suggested dissatisfaction with point-in-time assessments in favor of something closer to continuous-monitoring-style assurance, concern that OT/manufacturing resilience is underrepresented in the current practice set, and interest in reforming CUI-marking discipline across the DIB. Treat these as directional hints from officials, not commitments. Nothing changes in your compliance obligations until DoD issues one of three things: a class deviation, a DFARS rule change, or an amendment to 32 CFR Part 170 itself. A task force report, when it lands, is advisory input to that process — not a self-executing change to your requirements.

**What you should do about it — hold your remediation course.** Concretely:

1. **Do not pause or slow-walk your NIST SP 800-171 remediation work.** Your DFARS 7012/7019/7020 obligations are unaffected, and if you're mid-remediation for an eventual C3PAO assessment, stopping now just re-creates the same gap later when Level 2 (C3PAO) requirements return to new contracts — which the reform outcome may do on short notice.
2. **Keep current self-assessment and SPRS submissions on schedule**, and keep annual senior-official affirmations current; a lapsed affirmation carries False Claims Act exposure independent of the Phase 2 suspension.
3. **Watch for the report's actual publication** — re-verify this status after any DoD announcement, and specifically look for whether it triggers a class deviation or NPRM, since that's the mechanism that would actually change your obligations.
4. **If you're a subcontractor being flowed CMMC requirements**, confirm with your prime whether their contract language has already been modified to Level 1/2 (Self) — if not, ask, since primes are required to strip C3PAO/DIBCAC language at the next option/mod.

In short: nothing is settled, nothing in your underlying compliance obligation has moved, and the safest posture is to keep executing your 800-171 program as if Phase 2 could return at any time — because it may.

I want to be upfront about a limitation before answering: my training data runs through roughly January 2026, and I don't have verified, first-hand knowledge of a "CMMC Reform Task Force report" dated after that point, or of specific developments in mid-to-late 2026. I can't confirm the existence, contents, or status of that specific report from memory, and I'm not able to browse the web in this conversation to check. So rather than invent details about a document I can't verify, let me give you what I can responsibly offer: the general trajectory CMMC was on heading into 2026, the kinds of reform pressures that were building, and a practical approach for how to handle a situation like this regardless of the exact contents of the report.

Context heading into 2026: CMMC 2.0 had been finalized in the 32 CFR rule (effective late 2024) and DoD was working through the 48 CFR contract-clause rulemaking needed to actually start requiring certifications in contracts. Throughout 2025 there was substantial industry commentary - from the Defense Industrial Base Association, National Defense Industrial Association, and various trade groups - arguing that the assessment ecosystem (C3PAOs, assessor capacity, cost burden on small and mid-size contractors) wasn't ready to scale, and that the rule's requirements around Level 2/3 assessments, POA&M timelines, and flow-down obligations to subcontractors needed clarification or softening. There was also a recurring theme in Congress and among some administration officials about right-sizing compliance burden for small businesses without weakening actual cybersecurity outcomes. Any "reform task force" report in this space would plausibly be addressing some combination of: assessor/C3PAO capacity constraints, cost and timeline relief for small businesses, clarity on scoping and CUI definitions, treatment of legacy systems, and possibly changes to the POA&M/conditional certification structure.

What you should do about it, regardless of what's actually in that report:

1. Don't treat any "reform" or "pause" signal as a green light to stop working. Contract clauses referencing NIST SP 800-171 (via DFARS 252.204-7012) and the SPRS self-assessment/scoring requirements have been live obligations for years, independent of CMMC certification timelines. Reform of the CMMC certification program does not retroactively suspend your existing contractual cybersecurity obligations.

2. Get the primary source before you act. Don't rely on secondhand summaries or vendor marketing about what a task force report says. Pull the actual report or the associated DoD/DFARS rulemaking notice from official channels (acquisition.gov, DoD CIO's CMMC site, Federal Register) and read the actual proposed changes, effective dates, and comment periods.

3. Map any proposed changes against your current compliance posture. If the report proposes changes to assessment levels, timelines, or scope, run a gap analysis: what does it change for contracts you currently hold vs. contracts you're bidding on, and does it affect your internal SSP, POA&M, or assessment scheduling.

4. Keep your NIST SP 800-171 control implementation and System Security Plan moving forward as your baseline. Whatever administrative path the certification program takes, the underlying technical and process requirements to protect CUI aren't going away - if anything, industry pressure has generally pushed toward more automation and continuous monitoring expectations, not less.

5. Engage your contracting officers and industry associations for authoritative interpretation. DFARS clause language and DoD guidance documents (not task force commentary) are what actually bind you contractually.

6. If you're advising leadership, frame this as: "here's what we know is confirmed and binding today, here's what's proposed and still moving, and here's our no-regret posture that holds up either way."

Bottom line: I can't verify specifics of a report I have no reliable data on, and I'd encourage you to get the primary document rather than trust any secondhand account (including mine) of what it says. Whatever it says, the safe default is to keep executing your NIST 800-171/CMMC compliance roadmap rather than pausing based on rumored reform.

No. Deprioritizing NIST SP 800-171 work this year would be a mistake, and here is why in concrete regulatory terms.

**The suspension only touches Phase 2 — not your underlying obligations.** On July 13, 2026, DoD suspended CMMC Phase 2, meaning the C3PAO third-party assessment requirement (Level 2 (C3PAO)) and DIBCAC-led Level 3 assessments due to appear in new solicitations from November 10, 2026 are on hold pending a CMMC Reform Task Force review. As of today, September 14, 2026, no task force report has been published — the 60-day review window closed in mid-September with nothing public yet, and even internal delivery to the DoW CIO was unconfirmed as of September 9. Expected release is late September to early October, unconfirmed.

Critically, that suspension did **not** touch 32 CFR Part 170, and it did not touch DFARS 252.204-7012 (safeguarding CUI, 72-hour DIBNET incident reporting), 7019 (NIST SP 800-171 self-assessment), 7020 (SPRS score submission), or 7021 (CMMC flow-down). All of those remain in force. If your contract requires you to protect CUI, your obligation to implement the 110 NIST SP 800-171 Rev 2 practices — and to self-assess against them — has not moved at all. What changed is which *assessment track* applies: contracting activities can currently only designate Level 1 (Self) or Level 2 (Self), not Level 2 (C3PAO) or Level 3 (DIBCAC). Self-assessment did not go away; if anything, it's now the *only* track being written into new contract language.

**Practical consequences of deprioritizing:**
- Your annual SPRS submission and senior-official affirmation obligations continue unchanged. A stale or inaccurate affirmation carries False Claims Act exposure regardless of what the task force ultimately recommends.
- DoD retains audit rights over self-assessments, and contracting officers can still act on SPRS scores today.
- The task force's public direction signals (from CIO statements, not the unreleased report) lean toward *more* assurance over time — continuous-monitoring-style oversight, tighter CUI-marking discipline, and attention to OT/manufacturing resilience — not a loosening of the underlying control set. Slowing remediation now bets against the likely direction of travel.
- If Phase 2 resumes on the same or a shortened timeline once the task force reports out, contractors who paused remediation will face the same 9–18 month first-timer runway to C3PAO readiness, compressed against whatever new deadline is set.
- Nothing in the suspension is self-executing policy change. Your obligations only shift via a class deviation, a DFARS rule amendment, or a 32 CFR Part 170 amendment — none of which has happened.

**What to actually do this year:**
1. Continue full-scope NIST SP 800-171 gap remediation as if C3PAO assessment could return to your contract at any point — because the interim rule explicitly signals it might, on short notice, once the review concludes.
2. Keep your SSP current, keep POA&M items moving (with root-cause remediation, not just symptom patches), and keep your SPRS score accurate and affirmed annually.
3. Prioritize the highest-impact, hardest-to-remediate practices now — MFA (IA.L2-3.5.3), FIPS-validated cryptography (SC.L2-3.13.8/3.13.11), CUI flow control (AC.L2-3.1.3), and audit logging (AU.L2-3.3.1) — since these are both the largest SPRS point deductions and the practices that can never appear in a POA&M at certification.
4. If you're a subcontractor, confirm with your prime whether their DFARS 7021 flow-down language has been updated to Level 1/2 (Self); that doesn't change what you owe on 800-171 itself.

Bottom line: the suspension is a pause on *how* you'll be assessed, not *what* you must implement. Treat this as a compliance-maintenance year, not a deprioritization year, and re-verify this guidance once the task force report actually publishes.

No - and this is one of the most important misconceptions to clear up quickly, because it can lead to real contractual and legal exposure if leadership acts on it.

First, a caveat: I don't have verified information about a specific "CMMC Phase 2 suspension" - my knowledge has a cutoff around January 2026, and I can't confirm current-as-of-today details about DoD rulemaking status without being able to browse the web in this session. So I'll answer the underlying compliance question in general terms that hold true regardless of the specific status of CMMC's phased rollout, and flag what you should verify independently.

Here's the key distinction that matters regardless of what's happening with CMMC certification timelines: CMMC and NIST SP 800-171 are related but not the same obligation, and they don't turn on and off together.

NIST SP 800-171 compliance has been a contractual requirement since DFARS clause 252.204-7012 took effect (originally 2017, with the current version in force for years now). If you hold or bid on DoD contracts that involve Controlled Unclassified Information (CUI), you are already required to:
- Implement the 110 (now 97 in Rev. 3, depending on which revision your contract cites) security requirements in NIST SP 800-171
- Maintain a System Security Plan (SSP) and Plans of Action and Milestones (POA&Ms) for any unimplemented controls
- Submit a Basic Assessment score to SPRS (Supplier Performance Risk System)
- Flow down equivalent requirements to subcontractors handling CUI

None of that depends on CMMC certification deadlines. CMMC was built as a verification mechanism layered on top of 800-171 - essentially a way for DoD to have third parties (or self-attestation, depending on level) confirm that what you've been claiming in SPRS is actually true. If CMMC's certification rollout ("Phase 2" referring to the timeline for requiring Level 2 assessments in contracts) is paused, delayed, or under reform, that affects when and how you get externally verified - it does not suspend the underlying 800-171 requirement or your existing SPRS self-assessment obligation, which are independently enforceable through your contracts and through the False Claims Act if you misrepresent your compliance status.

So the practical risks of deprioritizing 800-171 work based on a CMMC pause:
1. You may still be contractually required to maintain an accurate SPRS score today, and letting your actual security posture drift out of alignment with what's on file is a compliance and legal risk (potential False Claims Act exposure for misrepresenting cybersecurity compliance - DOJ has an active Civil Cyber-Fraud Initiative pursuing exactly this).
2. New contracts and modifications may still reference 800-171/CMMC requirements even during a "pause" in broader rulemaking.
3. Reform/pause periods are historically when the requirements get clarified and tightened, not relaxed. Treating a pause as a reason to stop work often means scrambling later when a compressed effective date arrives.
4. Your competitive position: primes and contracting officers increasingly favor subs who can demonstrate mature compliance regardless of enforcement mechanics; falling behind hurts past performance and teaming opportunities.
5. Insurance, customer contracts (including commercial customers who now reference CMMC/NIST 800-171 as a security benchmark), and cyber insurance underwriting increasingly look at this posture independent of DoD enforcement timing.

What I'd recommend instead of deprioritizing:
- Verify the actual, current DFARS clause language and any interim rule status directly from the Federal Register or DoD's CMMC program page - don't rely on secondhand claims about what's "suspended."
- Continue closing your 14 (or however many) POA&M items on a risk-prioritized basis - highest-risk controls first (access control, incident response, audit logging, media protection typically carry the most risk).
- Keep your SSP and SPRS score current and accurate regardless of certification deadlines - accuracy of the self-assessment score is itself an enforceable requirement.
- Use any pause in the certification schedule productively: it's a gift of time to actually finish remediation work properly rather than scrambling for a deadline, not a signal to stop.

Bottom line: treat CMMC certification timeline news as informational about when you'll be externally verified, not as a reason to change your underlying NIST 800-171 obligations, which remain in force via contract and carry real legal risk if neglected.

Here is precisely what the July 13, 2026 CMMC suspension did, and — just as important — what it left untouched.

**What it did.** On July 13, 2026, DoD issued two policy memoranda — one from the DoW CIO, one from USD(A&S) — suspending **CMMC Phase 2**. Phase 2 is the rollout stage that introduces third-party C3PAO assessment for Level 2 (Advanced) and government-led DIBCAC assessment for Level 3 (Expert). Specifically, the suspension:
- Halted the requirement for **C3PAO third-party assessments** that were scheduled to start appearing in new contract solicitations as of November 10, 2026.
- Placed all pending CMMC Phase 2 rollout milestones **in abeyance** — meaning paused, not cancelled — while a review takes place.
- Stood up a **60-day CMMC Reform Task Force review**, with a report originally due around September 13, 2026. As of today, September 14, 2026, that report has not been published; even its internal delivery to the DoW CIO is unconfirmed, with the CIO indicating on September 9 that the team was still working through over 1,100 RFI responses. Public release is expected late September to early October (unconfirmed).
- Directed that, during the interim, requiring activities (contracting offices) may only designate **Level 1 (Self)** or **Level 2 (Self)** in contract requirements — not Level 2 (C3PAO) or Level 3 (DIBCAC).
- Triggered removal of **C3PAO/DIBCAC-specific requirements** from existing solicitations and active contracts, but only at the next contract option period or modification — it is not an instantaneous rewrite of every current contract.

**What it did NOT do.**
- It did **not** repeal or suspend **32 CFR Part 170**, the CMMC 2.0 final rule itself. The rule remains law; only the third-party assessment track under it is paused.
- It did **not** touch any of the underlying **DFARS clauses**: 252.204-7012 (safeguarding CUI and the 72-hour DIBNET incident reporting requirement), 252.204-7019 (NIST SP 800-171 self-assessment requirement), 252.204-7020 (SPRS score submission and DoD access to results), or 252.204-7021 (the CMMC flow-down clause itself, which still requires primes to flow requirements to subcontractors). All four clause families remain fully enforceable.
- It did **not** suspend **Phase 1** activity: annual self-assessments, SPRS score submissions, and senior-official annual affirmations all continue exactly as before. Contractors still must submit accurate scores and affirm them; false affirmations still carry **False Claims Act** exposure.
- It did **not** relieve contractors of any obligation to actually implement the **110 NIST SP 800-171 Rev 2 practices** if they handle CUI. The practices, the SPRS scoring methodology, and the POA&M rules are all unchanged.
- It did **not** produce a final outcome yet. The Reform Task Force's public statements (dissatisfaction with point-in-time assessment in favor of more continuous-monitoring-style assurance, OT/manufacturing resilience concerns, CUI-marking discipline) are CIO commentary, not policy — the report is **advisory**. Nothing in your compliance posture changes until DoD acts on it through one of three mechanisms: a class deviation, a DFARS rule change, or an amendment to 32 CFR Part 170.
- It did **not** cancel Level 3 as a concept — DIBCAC-led assessment is paused along with Level 2 (C3PAO), not eliminated.

**Net effect for contractors:** the assessment *mechanism* for Level 2/3 (who checks your work and how) is on hold; the *substance* of what you must implement and self-report is fully intact. Contractors should treat this as a pause button on third-party/government-led certification, not a green light to relax NIST SP 800-171 remediation, SPRS accuracy, or DFARS 7012 incident-reporting discipline. Re-verify this analysis once the Task Force report is actually published, since it could recommend restoring Phase 2 on a new timeline, revising it, or something else — none of which is known yet.

I need to be transparent up front: I don't have verified information about a specific "July 2026 CMMC suspension." My training data has a cutoff around January 2026, I have no ability to browse the web in this conversation, and I can't confirm the existence or exact scope of an action that occurred after my knowledge cutoff. I don't want to fabricate specifics about a regulatory action I can't verify - that would be actively harmful if you used it to make compliance decisions. What I can do is (a) tell you clearly that I can't confirm this, (b) tell you exactly where to verify it, and (c) explain the structural distinctions that matter for interpreting any such action correctly, since these are the same distinctions that apply regardless of the specific event.

What you should do to get the actual answer:
- Check the Federal Register directly for any interim final rule, final rule, or notice related to 32 CFR Part 170 (the CMMC program rule) or DFARS 252.204-7021 (the CMMC contract clause).
- Check DoD's official CMMC program page (under DoD CIO) for program announcements.
- Check the Defense Acquisition Regulations System (DARS) rulemaking docket for the status of the CMMC acquisition rule.
- If you have a compliance counsel or GRC advisor with DoD contracting expertise, have them confirm the primary source language - "suspension" can mean very different things depending on which layer of the framework it hits.

Now, here is the structural knowledge that matters for interpreting whatever actually happened, because these distinctions are exactly where people get confused about "what changed":

1. CMMC has multiple legally distinct components, and an action can hit one without touching the others:
 - The 32 CFR Part 170 rule - establishes the CMMC program itself (levels, assessment types, scoring).
 - The DFARS 252.204-7021 clause rule - actually requires CMMC certification as a condition of contract award; this is what needs to be in individual contracts/solicitations for CMMC to be enforceable on a given procurement.
 - The underlying DFARS 252.204-7012 clause - requires NIST SP 800-171 implementation and SPRS self-assessment reporting; this predates CMMC and is independent of it.
 - The C3PAO ecosystem and CMMC Accreditation Body (Cyber AB) - the assessor infrastructure that conducts third-party assessments.

2. A "suspension" could mean, among other things:
 - A pause in adding the 7021 clause to new contract solicitations (meaning no new contracts require CMMC certification during the pause), while the underlying 800-171 obligations in existing 7012 clauses remain fully in force.
 - A pause in the phased rollout schedule (delaying when Level 2/3 certification requirements become mandatory across acquisition categories) without rescinding the rule itself.
 - A halt on new C3PAO assessments or accreditation actions pending some review, without touching contractor obligations at all.
 - A withdrawal or reopening for comment of part of the rule, which would need a new Federal Register notice to resolve.
 - It's very unlikely to mean that NIST SP 800-171 compliance obligations under existing DFARS 7012 clauses are void - those exist independently in your contracts and would require separate contract modifications or a change to 7012 itself to remove.

3. What a suspension almost never does:
 - It does not retroactively change your contractual obligations on contracts already awarded with CMMC or NIST 800-171 clauses in them - those clauses stay in force until the contract is modified.
 - It does not eliminate your obligation to protect CUI under whatever security requirements your contract cites.
 - It does not remove your existing SPRS score obligations or the risk of False Claims Act exposure for inaccurate self-assessments.
 - It does not typically apply retroactively to assessments already completed or in progress unless explicitly stated.

4. What to actually check in your own contracts:
 - Pull the specific clauses cited in your current contracts (7012, 7019, 7020, 7021) and confirm whether those clause versions have been modified.
 - Check whether your contract has been formally modified to remove or alter a CMMC-related clause - a program-level suspension doesn't automatically modify individual contracts.
 - Ask your contracting officer directly for a determination on how the change (whatever it specifically is) affects your active contract vehicle.

Bottom line: I can't respons­ibly confirm what the July 2026 action specifically did or didn't do since I have no verified data on it, and I'd be doing you a disservice pretending otherwise. Pull the actual Federal Register notice or DoD announcement, identify precisely which rule or clause it touched, and cross-reference that against your own contract's clause set before assuming anything about your specific obligations has changed.

Here's how the SPRS scoring math works and what your 14 unimplemented practices actually mean for certification eligibility.

**Base methodology.** The SPRS score for Level 2 uses the DoD Assessment Methodology for NIST SP 800-171: you start at **+110** (every one of the 110 practices assumed MET) and each **NOT MET** practice subtracts its assigned weight. The possible range runs from +110 (everything met) down to **−203** (everything unmet). There is no partial credit — a practice that's 80% implemented gets the same full deduction as one that's 0% implemented; it's binary, MET or NOT MET.

**Weights.** Each practice is pre-assigned a deduction value of **5, 3, or 1 points** based on its security impact, per the published DoD Assessment Methodology (v2.2). The highest-impact, 5-point practices include:
- AC.L2-3.1.3 — CUI flow control
- IA.L2-3.5.3 — Multifactor authentication
- SC.L2-3.13.8 — Encryption of CUI in transit (FIPS-validated)
- SC.L2-3.13.11 — FIPS-validated cryptography generally
- SI.L2-3.14.6 — Attack/indicator monitoring

3-point practices include things like AC.L2-3.1.5 (least privilege), AU.L2-3.3.1 (audit logging), and CM.L2-3.4.1 (baseline configuration). Everything else is generally a 1-point deduction.

**Your calculation walkthrough.** With 14 practices NOT MET, your score depends entirely on *which* 14:

| Scenario | Deduction | Resulting Score |
|---|---|---|
| All 14 are 1-point practices | 14 × 1 = 14 | 110 − 14 = **96** |
| Mix: e.g. 2 five-point + 4 three-point + 8 one-point | (2×5)+(4×3)+(8×1) = 10+12+8 = 30 | 110 − 30 = **80** |
| All 14 are 5-point practices (worst case) | 14 × 5 = 70 | 110 − 70 = **40** |

To give you a precise number, I need the actual **Practice IDs** for your 14 gaps — send me the list and I'll compute the exact score and flag which ones carry the highest weight.

**Why the composition matters more than the count.** Fourteen unmet practices sounds uniform, but it isn't for two separate reasons:

1. **The certification gate is score ≥ 88.** That's 0.8 × 110, the DoD's conditional-certification threshold. In the "all 1-point" scenario above you'd land at 96 — above the gate. In the "worst case" scenario you'd land at 40 — nowhere close, and no conditional certification path exists at that score regardless of practice type.

2. **POA&M eligibility is not just about score — it's about which practices are open.** At certification, only **1-point practices** (and, in narrow allowed cases, 3-point practices) may remain open in a POA&M. **5-point deductions can never be POA&M'd at certification**, and neither can these specific practices regardless of their point value, because they're on the critical list: 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, and IR.L2-3.6.1. If even one of your 14 gaps is on that list, or is a 5-point practice, there is no conditional-certification path — full remediation and reassessment is required before certification, no matter how high your overall score is.

**So the two questions that actually determine your path are:**
- Is your resulting score ≥ 88?
- Are all 14 of your NOT MET practices 1-point (or eligible 3-point) practices, and none of them on the critical-practice list above?

If both are true, you likely qualify for **conditional certification** with a 180-day POA&M closeout clock (miss it and certification is revoked). If either is false, remediate the disqualifying practices first and reassess — there's no partial path around a critical-practice or 5-point miss.

**Next step:** share your 14 Practice IDs and I'll calculate the exact score, confirm certification-eligibility status, and produce a prioritized remediation order (highest point value and critical-practice items first) plus a POA&M table for anything still open at ≥88.

Here's how the SPRS (Supplier Performance Risk System) scoring methodology works under NIST SP 800-171, and what your 14 unimplemented practices mean in practice.

The scoring model:
NIST SP 800-171 (Rev. 2, which is what most current DFARS 252.204-7012/7020 scoring is built around) has 110 security requirements across 14 control families. DoD's scoring methodology (published by OUSD(A&S)/DoD CIO, sometimes called the "NIST SP 800-171 DoD Assessment Methodology") assigns a starting score of 110 points, representing full implementation of every requirement. For each requirement you have NOT implemented, you subtract points - but not evenly. Each of the 110 requirements has a pre-assigned point value (1, 3, or 5 points) based on its assessed criticality/impact on the overall security posture. A few high-value controls (like FIPS-validated cryptography, multifactor authentication, or restricting/monitoring remote access) are weighted at 5 points; mid-tier controls are typically 3 points; lower-impact or more procedural controls are typically 1 point. So your score is calculated as: 110 minus the sum of point values for every requirement not fully implemented, which can result in scores ranging from 110 down to -203 (there's a floor around there because some controls can trigger multiple deductions when unimplemented in ways that also negate credit for other partially-dependent controls).

What 14 unimplemented practices means for your score:
Fourteen missing practices is not automatically a small or large deduction - it entirely depends on which 14. If those 14 happen to be mostly 1-point items (e.g., certain low-impact policy/documentation requirements), you might be looking at a score in the 90s. If several of those 14 are 5-point items (e.g., multifactor authentication for privileged/remote access, encryption of CUI at rest or in transit, boundary protection, incident response capability), you could be looking at a much lower score - possibly requiring point deductions well into double digits from just a handful of gaps. You need to map your specific 14 gaps against the DoD Assessment Methodology scoring template (it's a publicly available spreadsheet/matrix listing every one of the 110 requirements with its assigned point value) to get your actual number - I can't give you a precise score without knowing which controls are on your gap list.

What you're required to do with this:
1. Calculate your actual score using the current scoring template and submit (or update) it in SPRS. This is a Basic Assessment, self-generated, and it must reflect your true current implementation status - not an aspirational one. Submitting or maintaining an inaccurate SPRS score is exactly the kind of thing DOJ's Civil Cyber-Fraud Initiative has pursued under the False Claims Act.

2. Build a Plan of Action and Milestones (POA&M) for each of the 14 unimplemented practices. A POA&M documents the specific gap, the planned remediation steps, responsible party, and target completion date. Under current policy, POA&Ms have to represent realistic, time-bound plans - a POA&M isn't a permanent substitute for implementation, and depending on the contract clause version there may be a required timeframe (historically discussed as roughly 180 days for closing critical POA&M items, though you should confirm the specific timeline requirement in your current contract).

3. Understand SPRS score validity/currency. Assessments (and thus your submitted score) are generally treated as current for a defined period (commonly referenced as three years) unless your security posture materially changes - but you should re-submit whenever you close POA&M items to reflect improvement, since contracting officers can and do check your score before award decisions on new work.

4. Prioritize remediation of the highest-point-value gaps first. Since the score is a straightforward point subtraction, closing your five highest-value gaps will move your score much more than closing five 1-point gaps. This also generally aligns with actual risk reduction, since the weighting reflects DoD's judgment about security impact - MFA, encryption, access control, and incident response capabilities tend to be the biggest score movers and the biggest real-world risk reducers.

5. Watch for a Medium or High Assessment. DoD (via DCMA's DIBCAC) can conduct government-led assessments that supersede or validate your self-assessment; if there's a discrepancy between your self-reported score and what an actual assessment finds, that's a significant compliance and contractual problem, so make sure your self-assessment is honest and well-documented, not optimistic.

Practical next step: Get the actual DoD Assessment Methodology scoring spreadsheet, plug in your 14 specific gaps against their assigned point values, calculate your real score, get it into SPRS if it isn't already accurate, and build POA&Ms with real dates - prioritized by point value/risk - for closing them. If you tell me which 14 specific practices are unimplemented, I can help you think through relative prioritization, though I'd recommend validating exact point values against the current official scoring template rather than my recollection of them.

A CUI enclave is exactly the right instinct — it's the standard way to shrink your CMMC assessment boundary instead of putting your entire network in scope. Here's how scoping actually works and how to build the case for an enclave.

**The five asset categories.** Before you can scope anything, every asset in your environment must be sorted into one of five categories, because each gets a different level of assessment scrutiny:

| Asset Category | Definition | Assessment Treatment |
|---|---|---|
| CUI Assets | Store, process, or transmit CUI directly | Fully assessed against all applicable practices |
| Security Protection Assets (SPA) | Provide security functions for the CUI environment (firewalls, SIEM, IdP) but don't handle CUI directly | Assessed for the security capability they provide |
| Contractor Risk Managed Assets (CRMA) | Could handle CUI but aren't intended to; managed under your risk-based policy | Documented in SSP; reduced-level assessment with policy justification |
| Specialized Assets | IoT, OT, government-furnished equipment, restricted systems, test equipment | Documented with compensating controls; not assessed like standard IT |
| Out-of-Scope Assets | Cannot process, store, or transmit CUI, no security-relevant connection to CUI assets | Excluded entirely; document the rationale (segmentation, isolation) |

The whole point of an enclave strategy is to make the largest possible share of your network qualify as **Out-of-Scope** or lightly-scrutinized **CRMA**, by physically and logically isolating the smaller set of systems that actually need to touch CUI.

**Scoping workflow to build the enclave case:**
1. **Identify your CUI categories** — pull the specific CUI types you receive or generate under the contract from the DoD CUI Registry (e.g., Controlled Technical Information, export-controlled data, Privacy/PII). You can't scope an enclave around CUI you haven't inventoried.
2. **Map CUI flows** — trace every point where CUI enters your environment (email, file transfer, portal), where it's processed (applications, workstations), where it's stored (file shares, databases, backups), and where it exits (deliverables, reports back to the government or prime).
3. **Classify every asset** into the five categories above based on that flow map.
4. **Define the CUI Asset Boundary** — the enclave itself: the network segment or dedicated environment containing your CUI Assets plus the SPAs that directly support them (e.g., the firewall and IdP protecting the enclave, even if they physically sit elsewhere).
5. **Document exclusion/reduction rationale in the SSP** for every Out-of-Scope and CRMA asset — this is what an assessor will scrutinize hardest, since "we just decided it's out of scope" without segmentation evidence won't survive review.
6. **Build the enclave**: isolate CUI-handling systems into a dedicated, segmented environment — separate VLAN or domain, dedicated endpoints, its own access control and identity boundary — distinct from your general corporate network. This is the mechanism that actually shrinks the number of in-scope assets, not just a policy statement.
7. **If any part of the enclave is cloud-hosted**, the cloud service must be **FedRAMP Authorized at Moderate or equivalent** — a non-FedRAMP cloud handling CUI violates the DFARS 7012 safeguarding requirement regardless of how well you've scoped everything else.

**What actually makes segmentation credible to an assessor:** network-level isolation (dedicated VLAN/subnet or physically separate domain), no routine cross-boundary access between the enclave and your general IT environment, dedicated or reimaged endpoints for enclave users (not a device that also touches your unrestricted network), and access control enforced at the boundary (its own IdP/MFA, not shared corporate credentials that also unlock everything else). Weak segmentation — same domain, shared admin accounts, routine file transfers in and out without controls — is the most common reason an enclave claim gets rejected and the assessor pulls your whole network back into scope.

**Practical sequencing:** do the CUI flow mapping and asset classification *before* you build anything technical. Organizations that build the enclave first and try to retrofit the CUI flow story afterward usually discover CUI touching systems they intended to exclude, which either breaks the enclave boundary or forces expensive rework. Once the boundary is defined and built, document it fully in the SSP's system boundary section (network diagrams, asset category inventory, CUI data flow narrative) — that documentation is the primary artifact a C3PAO or self-assessment review will use to validate your scope before assessing anything else.

One more consideration specific to right now: regardless of the current CMMC Phase 2 suspension status, correct scoping matters immediately, because your self-assessment and SPRS submission today are scored against whatever your CUI Asset Boundary actually is — a poorly scoped boundary either overstates your assessment burden (unnecessary systems pulled in) or understates your real exposure (CUI assets wrongly excluded), and the latter carries False Claims Act risk if it's later found in an audit.

An "enclave" strategy (sometimes called a CUI enclave, security enclave, or scoped environment) is one of the most common and legitimate ways to reduce CMMC/NIST 800-171 scope, and it can work well - but it requires real architectural discipline, not just a network diagram label. Here's how scoping actually works and what you need to get right.

The core scoping principle:
CMMC/NIST SP 800-171 scope is defined by where Controlled Unclassified Information (CUI) is processed, stored, or transmitted, plus any assets that could affect the security of that CUI even if they don't directly touch it. DoD's CMMC scoping guidance (published alongside the CMMC assessment guides) breaks assets into categories:
- CUI Assets: systems that process, store, or transmit CUI directly. These are fully in scope and must meet all applicable 800-171 requirements.
- Security Protection Assets (SPAs): systems that provide security functions for the CUI environment (e.g., your SIEM, your identity provider/MFA system, your patch management server) even if they don't hold CUI themselves. These are in scope, though the assessment focuses on the security-relevant functions they provide.
- Contractor Risk Managed Assets (CRMAs): assets that can potentially reach or affect the CUI environment (e.g., they're on the same network segment but aren't supposed to process CUI) but are managed through your risk-based security policies. These are documented in your SSP but assessed differently than full CUI assets.
- Out-of-Scope Assets: assets that are physically or logically separated from the CUI environment such that they cannot access, store, or affect it. To claim something is out of scope, you have to be able to demonstrate that separation, not just assert it.

Why an enclave helps:
If you build a properly segmented CUI enclave, only the enclave (and the security tools protecting it) fall under CMMC Level 2/3 assessment scope. The rest of your corporate network - email, HR systems, general engineering environments that never touch CUI - can be treated as out of scope, which dramatically reduces the assessment burden, cost, and ongoing compliance overhead. This is a very common and DoD-endorsed strategy specifically because building 800-171 controls (encryption, access control, audit logging, incident response, etc.) across an entire enterprise network is often far more expensive and disruptive than building them into a purpose-built, smaller environment.

What actually makes an enclave defensible (this is where people get it wrong):
1. Genuine logical and/or physical separation. This typically means a distinct network segment with its own firewalled boundary, its own identity/access controls (ideally separate directory or at minimum enforced conditional access), and controlled data flow points. A VLAN with a shared Active Directory and shared file shares to the rest of the network usually does NOT hold up as a true boundary.
2. Controlled ingress/egress. Every path CUI could take into or out of the enclave needs to be identified and controlled - file transfer mechanisms, email gateways, removable media, remote access/VPN, printing, and even things like copy-paste over remote desktop sessions if RDP crosses the boundary. If your engineers can freely move files or email CUI out of the enclave, the boundary isn't real.
3. No unmanaged crossover of privileged/security tools. If your SIEM, identity provider, or endpoint management tool covers both the enclave and the general network, those tools become Security Protection Assets and pull a meaningful slice of your broader environment into scope. Many organizations either deploy dedicated instances of these tools for the enclave or very carefully scope what those tools can see/touch.
4. Endpoint control. Devices that access the enclave (including via remote/virtual desktop) need to meet the same requirements as if they were CUI assets, unless you're using a strategy like a Virtual Desktop Infrastructure (VDI) or Desktop-as-a-Service where the actual CUI processing happens entirely within the enclave and the endpoint only receives a rendered screen with no local storage, clipboard, or print capability - this is one of the more popular ways smaller contractors shrink true scope, since the physical laptops accessing the enclave can then be treated with lighter requirements (though they're still generally at least a CRMA, not fully out of scope, and you need to document why).
5. People and process boundary. Only personnel who need CUI access should have enclave credentials, and your policies need to actually prevent and detect CUI moving outside the enclave (e.g., DLP tooling, restricted file-sharing permissions, training).
6. Documentation. Your System Security Plan (SSP) needs a clear, accurate network diagram and narrative showing the CUI boundary, what's inside (CUI Assets and SPAs), what's adjacent (CRMAs), and why everything else is genuinely out of scope. Assessors will test your claimed boundary, not just read your diagram - expect them to probe whether CUI can actually leak across it.

Common failure modes to avoid:
- "Enclave" that's really just a folder permission on a shared file server with no network segmentation.
- Shared helpdesk/IT admin accounts with access to both the enclave and general network, creating a privileged crossover path.
- Email: if CUI can be emailed from inside the enclave to any general corporate mailbox, or vice versa, your enclave doesn't actually contain CUI flow.
- Backup systems: your enclave's backups need to stay within the same protected boundary (or an equivalently protected one) - a common gap is backing up the enclave to a general enterprise backup target.
- Assuming reduced scope also means reduced control rigor - the 110 requirements still apply in full to everything inside the enclave; you're reducing the footprint, not the requirement depth.

Practical next steps:
- Do a data flow mapping exercise first: where does CUI actually enter your organization (email, portals, physical media, contract deliverables) and where does it need to go for your team to do the work. Design the enclave around that minimum necessary footprint.
- Decide on an architecture pattern: dedicated segmented network with its own endpoints, or VDI/DaaS approach where thin clients/general laptops access a virtual environment that fully contains the CUI - VDI is often the fastest way for smaller contractors to shrink scope without buying entirely separate hardware for every enclave user.
- Get your identity, remote access, and monitoring tooling scoped deliberately - decide up front whether they're dedicated to the enclave or shared, and understand the scope consequence of that choice.
- Have your scoping decisions and boundary reviewed by someone experienced in CMMC assessments (ideally before you invest in build-out) - a boundary that looks reasonable to your IT team can still fail assessor scrutiny if data flow paths weren't fully traced.
- Document everything in the SSP with a clear boundary diagram, and be ready to demonstrate (not just assert) the separation during assessment.

Bottom line: enclaving is a sound, widely used strategy to shrink your compliance footprint, but the benefit only materializes if the segmentation is real, actively enforced, and fully documented - a boundary that exists on paper but leaks in practice will pull your entire network back into scope during assessment.

# NIST AI RMF: The Four Core Functions

The **NIST AI Risk Management Framework (AI RMF 1.0)**, published January 2023 as NIST AI 100-1, is a great foundation for a company just starting to deploy AI systems. Before diving into the functions, it's worth being clear about what the framework is and isn't: the AI RMF is **voluntary, outcome-based, and not a compliance checklist**. It won't hand you a pass/fail audit — instead it gives you a structured way to reason about AI risk across the lifecycle, and you decide how deep to go based on your context and risk tolerance. The companion **AI RMF Playbook** is where NIST publishes suggested actions for every category, so once you've read this, that's your next stop for implementation detail.

Underlying all four functions is a shared risk lens: the **seven characteristics of trustworthy AI** — Valid & Reliable, Safe, Secure & Resilient, Accountable & Transparent, Explainable & Interpretable, Privacy-Enhanced, and Fair with Harmful Bias Managed. GOVERN, MAP, MEASURE, and MANAGE are essentially the operational machinery for making deliberate, documented tradeoffs across those seven properties — no system is perfectly trustworthy on every dimension at once.

## The Four Functions

### GOVERN — Organizational Accountability (6 categories, ~21 subcategories)
GOVERN sets the culture, policies, accountability structures, and risk tolerance for AI across the organization. It is drawn as the *base* of the AI RMF diagram in NIST's own visualization because it's cross-cutting — every MAP, MEASURE, and MANAGE activity should operate inside the accountability structures GOVERN establishes. Key categories:
- **GOVERN 1** — AI risk policies, processes, and risk tolerance are established and integrated into enterprise risk management (ERM)
- **GOVERN 2** — Accountability structures (who owns AI risk decisions)
- **GOVERN 3** — Roles and responsibilities across the AI lifecycle, including third-party/vendor roles
- **GOVERN 4** — Cross-functional collaboration (legal, privacy, security, HR, ethics)
- **GOVERN 5** — Risk tolerance is communicated and drives go/no-go deployment decisions
- **GOVERN 6** — Alignment with applicable laws, regulations, and ethical principles (GOVERN 6.1/6.2 also cover third-party AI risk)

### MAP — Risk Identification (5 categories, ~20 subcategories)
MAP establishes context — intended use, deployment environment, affected stakeholders, and likely risks — *before* you invest in measuring or managing anything. A weak MAP means you'll measure the wrong things later. Key categories:
- **MAP 1** — Intended use, deployment context, and affected populations are documented (MAP 1.4, MAP 1.5)
- **MAP 2** — Scientific understanding of the system's capabilities/limitations is applied
- **MAP 3** — Risks and benefits are mapped to specific stakeholder groups (who benefits vs. who bears risk)
- **MAP 4** — Risks are prioritized (severity × breadth × reversibility)
- **MAP 5** — Likelihood and impact of harms are characterized, including systemic/cumulative effects

### MEASURE — Risk Analysis (4 categories, ~16 subcategories)
MEASURE applies quantitative, qualitative, and mixed-method **TEVV (Test, Evaluation, Verification, and Validation)** activities to the risks MAP identified. Key categories:
- **MEASURE 1** — Metrics and measurement approaches are defined per risk (e.g., accuracy, demographic parity, adversarial accuracy)
- **MEASURE 2** — Systems are evaluated for trustworthiness pre-deployment (bias testing, explainability testing, security/privacy assessment, human oversight validation)
- **MEASURE 3** — Risk is tracked over time; drift and degradation are monitored post-deployment
- **MEASURE 4** — Measurement results feed decision-makers and update the risk register

### MANAGE — Risk Response (4 categories, ~18 subcategories)
MANAGE is where risks get treated — and where the loop closes back into GOVERN. Key categories:
- **MANAGE 1** — Risks are prioritized, assigned owners, and residual risk is formally accepted by an accountable authority
- **MANAGE 2** — Treatment strategies (mitigate, transfer, avoid, accept) are resourced and implemented, including emergency "kill switch" procedures
- **MANAGE 3** — Treatments are monitored for effectiveness; AI incidents are logged, investigated, and escalated
- **MANAGE 4** — Outcomes and lessons learned are reviewed and fed back into GOVERN policy updates

## How They Relate

GOVERN → MAP → MEASURE → MANAGE isn't a strict waterfall — it's a continuous loop with GOVERN as the always-on foundation underneath the other three:

```
        ┌────────────────────────────────────────┐
        │                GOVERN                   │
        │   (continuous — culture, accountability, │
        │       policy, risk tolerance)             │
        └───────────────┬──────────────────────────┘
                         │
        ┌────────────────▼────────────────┐
        │   MAP → MEASURE → MANAGE          │
        │   (cycles per system, per         │
        │    lifecycle stage, per release)  │
        └────────────────┬──────────────────┘
                         │
              feeds back into GOVERN
              (MANAGE 4.3, MEASURE 3.3)
```

- MAP identifies and scopes risk.
- MEASURE quantifies and tests what MAP identified.
- MANAGE treats what MEASURE found and monitors treatment effectiveness.
- Findings from MANAGE (incidents, new risks) and MEASURE (drift, new failure modes) flow back into MAP for re-scoping and into GOVERN for policy updates — this is what makes the framework a continuous risk management cycle rather than a one-time assessment.

## What to Implement First

**Start with GOVERN.** It's the prerequisite, not an optional first module:

1. **GOVERN 1.3** — Establish and document your organizational risk tolerance for AI (what's acceptable, what isn't).
2. **GOVERN 2.1/2.2** — Name an accountable owner (AI Risk Owner or similar) with clear reporting lines.
3. **GOVERN 1.6 / GOVERN 6.1** — Build an inventory of AI systems in use or planned, and a regulatory register of applicable laws.
4. **GOVERN 4.1** — Stand up a cross-functional AI risk group (legal, security, privacy, the business owner) so MAP/MEASURE/MANAGE work later has the right people at the table.

Only after those foundations are in place should you run MAP on your first AI system (starting with your highest-stakes or highest-visibility deployment), then MEASURE it, then MANAGE identified risks. Trying to do MAP/MEASURE/MANAGE without GOVERN is the most common failure pattern — you end up with fragmented, inconsistent risk assessments across teams with nobody accountable for the results.

---
*This is general compliance information, not legal advice. Verify current requirements against the official NIST AI 100-1 publication and the AI RMF Playbook, and consult qualified counsel for regulatory decisions specific to your organization.*

# NIST AI Risk Management Framework: The Four Core Functions

Great timing to start with the NIST AI RMF — it's the most widely referenced voluntary framework for AI risk management in the US, and it's designed to be flexible enough to layer onto whatever AI governance maturity you currently have (even "none yet"). Here's a breakdown of the four core functions, how they interact, and where to start.

## Overview: What the AI RMF Is (and Isn't)

The NIST AI Risk Management Framework (AI RMF 1.0), published in January 2023, is a voluntary, non-sector-specific framework to help organizations manage risks associated with AI systems throughout their lifecycle. It's paired with a companion **AI RMF Playbook** that gives concrete suggested actions for each function.

Two things to keep in mind:
- It is **not a checklist or certification scheme** — it's a structured way of thinking about and organizing AI risk management activities.
- It's built around the idea that AI risks are **socio-technical**: they arise from the interaction of technical systems with people, organizations, and society, not just from model performance metrics.

## The Four Core Functions

### 1. GOVERN — The Foundation

GOVERN is the cross-cutting function that establishes the organizational culture, structures, and accountability mechanisms for managing AI risk. It's meant to inform and be infused into the other three functions rather than operate as a discrete, one-time phase.

Key elements include:
- **Policies, processes, and procedures** for AI risk management, aligned to organizational risk tolerance
- **Accountability structures** — clear roles and responsibilities for AI risk decisions (who can approve deployment, who owns residual risk, etc.)
- **Culture** — incentivizing risk-aware practices among teams building/deploying AI, not just compliance teams
- **Workforce diversity and skills** — ensuring teams have the expertise (technical, legal, ethical, domain) to identify risks
- **Third-party/supply chain risk management** — governance over vendors, open-source models, data providers, and other external dependencies
- **Mechanisms for monitoring effectiveness** of the risk management program itself, plus channels for feedback, contestability, and redress

Think of GOVERN as the "operating system" the other three functions run on. Without it, MAP/MEASURE/MANAGE activities tend to be ad hoc, inconsistent across teams, and disconnected from actual accountability.

### 2. MAP — Establishing Context

MAP focuses on establishing the context to frame risks related to an AI system. You can't manage risk you haven't identified, and you can't identify risk without understanding what the system is, how it will be used, and who it affects.

Key activities:
- Identifying the **intended purpose, scope, and context of use** for the AI system
- Understanding **who is impacted** — end users, third parties, non-users who may still be affected, and vulnerable populations
- Categorizing the AI system (e.g., is it a general-purpose model, a high-stakes decision system, embedded in a larger product?)
- Identifying **benefits and potential negative impacts**, including impacts that may not be obvious at design time (bias, safety, environmental, societal)
- Mapping **dependencies** — data sources, third-party components, downstream systems
- Determining **risk tolerance and go/no-go criteria** for that specific system before it's built or procured

MAP is typically the first function applied to any *individual* AI system or use case, because its output (context, intended use, stakeholders, risk categorization) feeds directly into what you measure and how you manage.

### 3. MEASURE — Analyzing and Tracking Risk

MEASURE involves using quantitative, qualitative, or mixed-method tools and techniques to analyze, assess, benchmark, and monitor AI risk and related impacts identified in MAP.

Key activities:
- Selecting **appropriate metrics** for the risks identified (accuracy, robustness, fairness/bias metrics, explainability, privacy leakage, security vulnerabilities, etc.)
- **Testing and evaluation**, including red-teaming, adversarial testing, and stress testing
- Tracking metrics **over time**, not just at launch (model drift, performance degradation, emerging harms)
- Assessing risks that are **difficult to quantify** (societal impact, psychological effects) using qualitative or mixed methods
- Independent/third-party validation where feasible, to reduce self-assessment bias
- Documenting measurement results in a way that's usable by decision-makers (not just data scientists)

MEASURE is where GOVERN's policies and MAP's identified risks get turned into evidence — actual data about whether the system behaves as expected and within acceptable risk thresholds.

### 4. MANAGE — Acting on Risk

MANAGE involves allocating resources to identified risks (mapped and measured) on a regular basis, and implementing responses to maximize benefits and minimize negative impacts.

Key activities:
- **Prioritizing risks** based on MEASURE outputs and organizational risk tolerance from GOVERN
- Deciding on treatment: **mitigate, transfer, avoid, or accept** each identified risk
- Implementing **risk response plans** — technical controls, process changes, human oversight mechanisms, or in some cases not deploying the system at all
- Planning for **incident response, recovery, and communication** when things go wrong
- Ongoing **monitoring after deployment**, since AI risk isn't static (data drift, new attack vectors, changing use context)
- Feeding lessons learned back into GOVERN (policy updates), MAP (context reassessment), and MEASURE (new metrics)

## How the Four Functions Relate to Each Other

This is the part people most often get wrong — it's not a strict linear sequence (Govern → Map → Measure → Manage → done). NIST explicitly designed it as **interconnected and iterative**:

- **GOVERN is cross-cutting and continuous.** It surrounds and informs the other three at all times — it's not "step one" in a sequence so much as the context in which the sequence happens. Good governance should already be functioning before you MAP your first system, and it keeps operating throughout.
- **MAP → MEASURE → MANAGE forms a cycle**, applied per AI system, per use case, and often per lifecycle stage (design, development, deployment, decommissioning). You typically MAP context first, then MEASURE against that context, then MANAGE based on what you measured.
- **The cycle repeats.** AI systems change (retraining, new data, model updates), contexts change (new use cases, new regulations), and risks change (new attack techniques, emergent behavior at scale). So organizations continuously loop back through MAP → MEASURE → MANAGE — it's not "one and done" per system.
- **Feedback flows backward too.** Something discovered in MANAGE (e.g., an incident) should trigger a re-MAP (did we understand the context correctly?) and update GOVERN (do our policies need to change?).

A simple mental model:
> **GOVERN** sets the rules of the game and runs continuously in the background → for each AI system, you **MAP** the context and risks → you **MEASURE** those risks with real evidence → you **MANAGE** by acting on that evidence → and the results feed back into all three other functions, on a recurring loop.

## What to Implement First

Given that you're just starting out, here's a pragmatic sequencing recommendation:

### Start with a baseline of GOVERN — but don't over-invest before you have real systems to govern

You need *some* minimum governance scaffolding before anything else is meaningful:
1. **Designate accountability** — name an owner (individual or committee) responsible for AI risk oversight, even if it's a part-time responsibility initially.
2. **Inventory what you already have** — most companies "deploying AI" already have shadow AI usage (SaaS tools with embedded AI, employees using LLMs, vendor products with AI features). You can't govern what you don't know exists.
3. **Set a basic risk tolerance/policy statement** — what AI use cases are acceptable, which are prohibited or require review (e.g., anything touching PII, hiring, credit, health decisions), and what approval gates exist.
4. **Establish an intake process** — a lightweight way for teams to flag "we want to build/buy/use an AI system" so it gets routed through MAP before deployment.

This is deliberately minimal — you're not writing a 100-page AI governance manual on day one. You're creating just enough structure that the next AI system deployed doesn't happen completely outside of oversight.

### Then apply MAP to your first (or highest-priority) AI use case

Pick a real, concrete system — ideally either your **highest-risk** current initiative (something touching sensitive data or consequential decisions) or a **low-stakes pilot** to build organizational muscle. For that system, document: intended use, users/impacted parties, data sources, and a first-pass risk categorization.

### Then build MEASURE and MANAGE capability around that first use case, and iterate

Use that first system as a template/pilot to figure out what metrics matter, what your testing process looks like, and how risk decisions get made and documented. Then generalize those practices into repeatable playbooks for the next systems.

### Practical tips for a first implementation

- **Use the AI RMF Playbook** alongside the framework itself — it has concrete suggested actions mapped to each subcategory, which is far more actionable than the framework document alone.
- **Don't try to do all four functions "completely" before moving forward.** Maturity builds iteratively — a thin slice through all four functions for one real use case teaches you more than a perfect GOVERN function with nothing to apply it to.
- **Tie it to existing risk/compliance infrastructure** if you have it (enterprise risk management, information security, privacy programs) rather than building an entirely parallel AI governance structure from scratch.
- **Right-size to risk.** NIST explicitly intends the framework to scale — a low-risk internal chatbot doesn't need the same rigor as a system influencing hiring or lending decisions. Use MAP's risk categorization to decide how much MEASURE/MANAGE rigor to apply.
- **Consider the NIST Generative AI Profile (NIST AI 600-1)** as a companion resource if generative AI/LLMs are part of your deployment — it applies the same four functions with GenAI-specific risks and actions called out.

## Bottom Line

GOVERN is the continuous foundation; MAP, MEASURE, and MANAGE form an iterative cycle applied to each AI system and revisited over its lifecycle. For a company just starting out, implement a lean version of GOVERN first (ownership, inventory, basic policy, intake process) — just enough to create accountability — then immediately apply the full MAP → MEASURE → MANAGE cycle to one real, concrete AI use case rather than trying to perfect the framework in the abstract. Let that first pass teach you what your organization actually needs, then scale the practices to additional systems.

# AI Hiring Tool — NIST AI RMF Risk Assessment

An AI resume-screening and ranking tool is a textbook high-stakes AI use case under the NIST AI RMF (NIST AI 100-1) — it makes or heavily influences decisions about individuals' economic opportunity, which puts it squarely in the "consequential decision" category the framework treats most seriously. Note up front: the AI RMF itself is voluntary and outcome-based, not a compliance checklist — but for hiring AI you're also operating under mandatory external law (EEOC, and in NYC, Local Law 144), so treat the RMF as your risk management *methodology* while checking specific legal thresholds against counsel.

## Key Risks to Assess

Using **MAP 1** (context) and **MAP 3** (stakeholder risk/benefit mapping) as your starting point:

1. **Disparate impact / hiring bias** — the model systematically disadvantages candidates by race, sex, age, disability, or other protected characteristics, even without explicit protected-attribute inputs (proxy discrimination via zip code, school name, employment gaps, etc.)
2. **Lack of explainability for adverse decisions** — rejected candidates (and your own recruiters) can't understand why a candidate was screened out or ranked low
3. **Training data bias** — if the model was trained on historical hiring decisions, it can encode and amplify past discriminatory patterns
4. **Validity/reliability gaps** — the model may not have been validated for your specific role types, industries, or candidate pools; performance may degrade for underrepresented resume formats or non-native English writing
5. **Over-reliance / inadequate human oversight** — fully automated rejection without meaningful human review, which several jurisdictions restrict or prohibit
6. **Regulatory exposure** — EEOC disparate impact liability, NYC Local Law 144 (bias audit + candidate notice requirements for automated employment decision tools), and EU AI Act high-risk classification (Annex III) if you have EU candidates or operations
7. **Third-party/vendor risk** — if the screening tool is vendor-built or vendor-hosted, you inherit risk from a model you don't fully control or see inside (undisclosed retraining, opaque training data, limited audit rights)

## Trustworthiness Properties Most Relevant

Of the seven AI RMF trustworthiness characteristics, three are primary for this use case:

- **Fair with Harmful Bias Managed** — the central risk. Are demographic biases identified, measured, and mitigated? Does disaggregated performance meet the applicable threshold (e.g., EEOC's "4/5ths rule" — disparate impact ratio ≥ 0.8)?
- **Explainable & Interpretable** — can you produce a reason for any adverse decision, understandable to both a compliance reviewer and the affected candidate?
- **Accountable & Transparent** — is there a documented model/system card, and can every ranking decision be traced to a responsible party and a defined process?

Secondary but still relevant: **Valid & Reliable** (has it been tested on your actual applicant pool, not just a generic benchmark?) and **Privacy-Enhanced** (resumes contain PII; ensure minimization and lawful handling).

## MEASURE-Function Actions Before Deployment

Concrete TEVV (Test, Evaluation, Verification, and Validation) actions, mapped to MEASURE subcategories:

1. **MEASURE 2.2 — Disaggregated bias/fairness testing.** Run the model against a representative test set and compute disparate impact ratio, demographic parity, and equalized odds across protected classes (race, sex, age, disability status where legally permissible to test). Flag any subgroup below the 4/5ths threshold.
2. **MEASURE 2.3 — Explainability testing.** Generate SHAP or LIME explanations for a sample of ranking/rejection decisions; confirm you can produce an adverse-action-style explanation for any candidate who requests one.
3. **MEASURE 2.1 — Pre-deployment technical/safety evaluation.** Validate accuracy and ranking quality specifically on your applicant population and role types — not just the vendor's generic benchmark.
4. **MEASURE 2.5 — Human oversight validation.** Confirm and test that a human reviewer meaningfully reviews rejections (not a rubber-stamp) before candidates are eliminated, and that the review step is actually exercised in practice, not just documented.
5. **MEASURE 1.1/1.3 — Define metrics and document measurement gaps.** Identify which fairness/explainability metrics you can compute given available data (e.g., if you don't collect race/gender at application stage, document how you'll estimate disparate impact — proxy analysis, post-hire surveys, etc. — and the limitations of that approach).
6. **MEASURE 2.6 — Document and share results.** Produce a written pre-deployment evaluation report covering the above, reviewed by legal/HR/compliance before go-live.
7. **MEASURE 3.1/3.2 — Post-deployment monitoring.** Once live, monitor disaggregated performance and disparate impact ratio on an ongoing basis (not just at launch) — hiring pools and resume patterns shift over time, and model or vendor updates can silently reintroduce bias.

## Recommended Next Steps (MAP → MANAGE)

- **MAP**: Document intended use and bound it explicitly (e.g., "screening/ranking only, not sole basis for rejection") and identify affected populations (applicants, especially those in protected classes) — MAP 1.2/1.4.
- **MANAGE**: For any subgroup below the 4/5ths threshold, define treatment — retrain with rebalanced data, add/strengthen human review gate, or restrict use for that role type — MANAGE 2.1.
- Cross-reference **NYC Local Law 144** (requires an independent bias audit published publicly and candidate notice before use) and **EU AI Act** Annex III high-risk classification for employment AI if applicable to your candidate pool.

---
*This is general compliance information, not legal advice. EEOC, state/local automated-employment-decision-tool laws (e.g., NYC Local Law 144), and EU AI Act obligations should be verified with qualified employment counsel before deployment.*

# AI Hiring Tool: NIST AI RMF Risk Assessment and MEASURE-Function Actions

An AI resume-screening and candidate-ranking tool is one of the highest-scrutiny use cases in AI governance today — it directly affects people's livelihoods, is subject to specific regulation (e.g., NYC Local Law 144, EEOC guidance, EU AI Act "high-risk" classification for employment), and has a well-documented history of bias incidents (e.g., Amazon's scrapped recruiting tool). Applying the NIST AI Risk Management Framework (AI RMF 1.0) is a sound approach. Here's a structured breakdown.

---

## 1. Key Risks to Assess

### Bias and discrimination risks
- **Historical bias baked into training data** — if the model learns from past hiring decisions, it can replicate and amplify prior discriminatory patterns (e.g., against women, older candidates, racial/ethnic minorities, candidates with employment gaps, non-traditional education).
- **Proxy discrimination** — variables like zip code, school name, gaps in employment, or even resume formatting/language patterns can act as proxies for protected characteristics (race, sex, age, disability, national origin).
- **Disparate impact across demographic groups** at each stage: sourcing, screening, ranking, and final recommendation.

### Validity and reliability risks
- **Construct validity problem** — does "predicted job success" or a ranking score actually measure job-relevant competence, or does it measure something else (e.g., resume-writing skill, keyword-stuffing, applicant tracking system familiarity)?
- **Performance drift** — model accuracy degrading over time as job requirements, applicant pools, or resume formats change.
- **Generalization failure** — model trained on one role/department/geography performing poorly when applied to another.

### Transparency and explainability risks
- **Black-box ranking** — candidates and recruiters may not understand why someone was ranked low or filtered out, undermining due process and trust.
- **Lack of documentation** — recruiters treating scores as ground truth without understanding model limitations ("automation bias").

### Accountability and human oversight risks
- **Over-reliance / automation complacency** — human reviewers rubber-stamping AI rankings without meaningful review.
- **Unclear ownership** — no clear accountability for adverse outcomes (vendor vs. deploying organization).

### Privacy risks
- **Sensitive data exposure** — resumes often contain proxies for protected class info, and sometimes explicit sensitive data (age via graduation dates, health-related gaps, national origin via names/language).
- **Data retention and secondary use** — candidate data used beyond the original hiring purpose, or retained longer than necessary.
- **Scraping/sourcing risk** — if the tool pulls candidate data from external sources (LinkedIn, social media), consent and lawful basis issues arise.

### Security risks
- **Data poisoning / manipulation** — resumes crafted (or gamed) specifically to exploit scoring weaknesses (keyword stuffing, adversarial formatting, hidden white text).
- **Model/IP theft or leakage** of proprietary scoring logic.
- **PII breach** — candidate data is a high-value target.

### Legal and regulatory risk
- **Non-compliance** with EEOC/Title VII (disparate impact liability), ADA (disability discrimination, reasonable accommodation in AI-driven processes), ADEA (age discrimination), state/local laws (NYC LL144 bias audits, Illinois AI Video Interview Act, Colorado AI Act, EU AI Act Annex III high-risk employment systems), and OFCCP requirements for federal contractors.
- **Litigation and reputational risk** from adverse impact lawsuits or public bias incidents.

### Third-party/vendor risk
- If the tool is vendor-supplied, risk of insufficient visibility into training data, model architecture, and validation evidence ("black box" vendor risk).

---

## 2. Most Relevant Trustworthiness Characteristics

All seven AI RMF trustworthiness characteristics matter, but for a hiring tool these are the most critical, roughly in priority order:

1. **Fair – with Harmful Bias Managed** (the central risk for this use case)
   - Systemic bias (baked into training data/design), statistical/computational bias (sampling, model behavior), and human/cognitive bias (recruiter over-trust in scores) all apply.

2. **Valid and Reliable**
   - The model must actually predict job-relevant outcomes accurately and consistently across subpopulations, roles, and time — foundational to every other trustworthiness property; an invalid model can't be fair or safe.

3. **Explainable and Interpretable**
   - Candidates, recruiters, and auditors need to understand the basis for rankings/rejections — both for due process and for bias detection.

4. **Accountable and Transparent**
   - Clear documentation of how the system works, who is responsible for outcomes, and disclosure to candidates that AI is used in the process (increasingly a legal requirement).

5. **Privacy-Enhanced**
   - Resumes and candidate data are personal data requiring data minimization, purpose limitation, and appropriate handling of sensitive proxies.

6. **Safe**
   - "Safe" in this context means avoiding harmful downstream consequences — unjust denial of employment opportunity, economic harm, psychological harm from opaque rejection.

7. **Secure and Resilient**
   - Protecting the system and data against adversarial manipulation (resume gaming) and breach, and ensuring the system degrades gracefully rather than failing silently.

---

## 3. MEASURE-Function Actions Before Deployment

The MEASURE function is where you analyze, benchmark, and track identified risks using quantitative, qualitative, or mixed-method tools. Below are concrete actions mapped to MEASURE's four categories (Measure 1–4).

### Measure 1: Appropriate methods and metrics are identified and applied
- Select and document metrics for **fairness** across protected classes:
  - Disparate/adverse impact ratio (four-fifths rule) by race, sex, age, disability status, and intersectional groups.
  - Statistical parity difference, equal opportunity difference, false negative rate parity across groups (false negatives are especially harmful here — qualified candidates wrongly filtered out).
- Select **validity/performance** metrics: precision/recall against actual hiring/performance outcomes, calibration, AUC by subgroup, inter-rater agreement between model and human expert review on a sample.
- Define **explainability** metrics/methods: feature importance stability, SHAP/LIME-style local explanation consistency, human-comprehension testing of generated explanations.
- Define **robustness** metrics: performance under adversarial resume manipulation (keyword stuffing, formatting tricks), performance on out-of-distribution resumes (non-traditional career paths, veterans, career changers).
- Document metric selection rationale, including known limitations and tradeoffs (e.g., fairness metric tensions — you cannot simultaneously satisfy all fairness definitions).

### Measure 2: AI systems are evaluated for trustworthy characteristics
- **Bias testing / disparate impact analysis**: Run structured bias audits segmented by protected class and intersectional subgroups, before go-live and on a recurring cadence (aligns with laws like NYC LL144 requiring independent bias audits within the last year).
- **Independent/third-party audit**: Engage an external auditor for the bias audit where feasible or legally required, to avoid conflict of interest.
- **Red-teaming**: Test for adversarial gaming (resumes engineered to exploit the model), prompt/feature injection if LLM-based, and edge cases (non-English resumes, unconventional formats, career gaps for caregiving/disability/military service).
- **Human factors evaluation**: Test whether recruiters over-trust or under-trust the tool's output (automation bias/complacency); assess usability of explanations provided to end users.
- **Privacy evaluation**: Conduct a privacy risk/impact assessment — data minimization check, review of sensitive-proxy variables, review of retention periods.
- **Validity testing against ground truth**: Compare model rankings to actual downstream job performance/retention data where available, not just to historical hiring decisions (to avoid validating against the very bias you're trying to avoid).
- **Environmental/contextual testing**: Evaluate performance separately for each job family/role/level, since a single model may not generalize.
- Benchmark against a **non-AI baseline** (e.g., structured human review) to confirm the tool actually improves outcomes rather than just adding automation.

### Measure 3: Mechanisms for tracking identified risks over time are in place
- Establish **ongoing monitoring dashboards** tracking adverse impact ratios, selection rates by group, and score distributions on a recurring (e.g., quarterly) basis post-deployment — not just a one-time pre-deployment test.
- Set **thresholds/triggers** for re-evaluation (e.g., if adverse impact ratio drops below 0.8, automatically flag for human review and possible suspension of automated ranking).
- Track **model drift** indicators as applicant pools, job descriptions, or labor market conditions change.
- Maintain **incident logging** — track complaints, appeals, or override decisions by human recruiters as signals of model problems.
- Log **vendor model updates** — if using a third-party tool, require notification and re-testing whenever the vendor updates the underlying model.

### Measure 4: Feedback about efficacy of measurement is gathered and assessed
- Establish a **feedback loop** with recruiters, hiring managers, and candidates (e.g., appeals/contest mechanism for candidates who believe they were unfairly screened out, as some laws require).
- Periodically **reassess whether chosen metrics are still the right ones** — e.g., if a fairness metric was gamed or a new subgroup harm emerges, revise the measurement approach.
- Conduct **post-deployment validation** comparing predicted vs. actual candidate/employee outcomes to close the loop on whether the tool measured the right construct.
- Document lessons learned and feed them back into the GOVERN function (update policies) and MAP function (re-examine context/purpose) — MEASURE should not be a one-off gate but a continuous cycle integrated with the other three RMF functions (Govern, Map, Manage).

---

## Practical Pre-Deployment Checklist (Summary)

- [ ] Conduct a documented bias/disparate impact audit across protected classes and intersectional groups
- [ ] Validate the model against actual job-relevant outcomes, not just historical hiring labels
- [ ] Test robustness against resume gaming and adversarial manipulation
- [ ] Implement human-in-the-loop review with meaningful (not rubber-stamp) oversight, especially for adverse decisions
- [ ] Provide candidate-facing notice and explanation of AI use, consistent with applicable law (e.g., NYC LL144, EU AI Act, state laws)
- [ ] Complete a privacy/data protection impact assessment covering data minimization and sensitive proxy variables
- [ ] Define fairness and performance metrics with documented thresholds and escalation triggers
- [ ] Establish ongoing (not one-time) monitoring, re-audit cadence, and an appeals/complaint mechanism
- [ ] Clarify accountability — who owns model risk, who can override/suspend the tool, and vendor contractual obligations for transparency and re-testing
- [ ] Maintain documentation sufficient to demonstrate compliance to regulators, auditors, or in litigation

This MEASURE work should feed directly into the **MANAGE** function (deciding whether/how to deploy, mitigations, and risk acceptance) and be underpinned by **GOVERN** (policies, accountability structures) and **MAP** (understanding context, intended use, and impacted stakeholders) — the four functions are meant to operate iteratively, not as a linear checklist.

# AI Risk Register — Credit Scoring Model (Financial Services)

Below is a working AI risk register built on the NIST AI RMF structure — columns are aligned to MAP (identification), MEASURE (TEVV), and MANAGE (treatment) so every entry traces cleanly back to the framework. Treatments are connected to model risk management practice under **SR 11-7 / OCC 2011-12**: independent validation before use, champion–challenger comparison in production, ongoing monitoring, and documented effective challenge at the model risk committee. This register is illustrative — populate Likelihood/Impact scoring and owners with your actual governance structure.

| Risk ID | AI System | Lifecycle Stage | TEVV Activity | Characteristic at Risk | Likelihood / Impact | Treatment | Owner |
|---------|-----------|------------------|----------------|--------------------------|------------------------|-----------|-------|
| R-01 | Credit Scoring Model v4 | Deployment | Disaggregated performance and disparate impact ratio testing across protected classes (MEASURE 2.2) | Fair with Harmful Bias Managed | High likelihood / High impact — disparate impact ratio below 0.8 threshold observed for one applicant subgroup in back-testing | **Mitigate** — retrain with rebalanced/reweighted features, remove/replace proxy variables correlated with protected class, add human review gate for declines in the affected subgroup; re-validate before re-enabling automated decisions (MANAGE 2.1) | Head of Credit Risk (treatment); Model Risk Committee (residual risk acceptance) |
| R-02 | Credit Scoring Model v4 | Deployment | Adverse-action explainability testing — SHAP/LIME sufficient to generate ECOA-compliant reason codes (MEASURE 2.3) | Explainable & Interpretable; Accountable & Transparent | Medium likelihood / High impact — reason-code generation not yet validated against all decline scenarios | **Mitigate** — implement and test SHAP-based reason-code generation for every decline; legal review of reason-code language against Regulation B requirements | VP Model Risk (treatment); Chief Compliance Officer (residual risk acceptance) |
| R-03 | Credit Scoring Model (vendor-hosted) | Deployment / Monitoring | Vendor validation-report review + independent benchmark against internal champion model (GOVERN 6.1, MEASURE 2.5) | Valid & Reliable; Accountable & Transparent | Medium likelihood / High impact — vendor retrains without notice; population drift undetected between reviews | **Mitigate** — contractual change-notification and audit rights, quarterly champion–challenger comparison against internal benchmark model, documented fallback/rollback to prior model version | VP Model Risk (treatment); CRO (residual risk acceptance) |
| R-04 | Credit Scoring Model v4 | Monitoring | Ongoing model performance and score-drift monitoring (MEASURE 3.1/3.2) | Valid & Reliable | Medium likelihood / Medium impact — macroeconomic shifts or population drift degrade discriminative accuracy (AUC-ROC decline) over time | **Mitigate** — monthly monitoring dashboard with defined drift thresholds (e.g., AUC drop >X%, PSI/KS statistic threshold) that trigger revalidation | Model Owner / Credit Risk Analytics (treatment); Model Risk Committee (residual risk acceptance) |
| R-05 | Credit Scoring Model v4 | Development / Testing | Adversarial and data-quality robustness testing (MEASURE 2.4) | Secure & Resilient | Low likelihood / High impact — synthetic identity fraud or manipulated application data could exploit model blind spots | **Mitigate** — combine credit score with fraud-detection controls; adversarial robustness testing prior to deployment; periodic red-team exercises | Head of Fraud & Model Risk (treatment); CRO (residual risk acceptance) |
| R-06 | Credit Scoring Model v4 | Design / Deployment | Legal/regulatory mapping to ECOA, Fair Housing Act, state fair-lending laws, and EU AI Act high-risk classification if applicable (GOVERN 6.1) | Accountable & Transparent; Fair with Harmful Bias Managed | Medium likelihood / High impact — regulatory exposure if fair-lending testing is inadequate or undocumented | **Mitigate** — maintain regulatory register, engage legal/compliance at design stage, document fair-lending testing methodology for examiner review | Chief Compliance Officer (treatment); Board Risk Committee (residual risk acceptance) |
| R-07 | Credit Scoring Model v4 | Deployment | Human oversight and override validation — escalation path for borderline/declined applications (MEASURE 2.5) | Accountable & Transparent | Low likelihood / Medium impact — automated declines without meaningful human recourse | **Mitigate** — establish human review/appeal path for declined applicants; test that override mechanism is actually used, not just documented | Head of Credit Operations (treatment); Head of Credit Risk (residual risk acceptance) |

## AI RMF Category Mapping Summary

| Risk | MAP | MEASURE | MANAGE | GOVERN |
|------|-----|---------|--------|--------|
| R-01 Bias/disparate impact | MAP 3, MAP 5 | MEASURE 2.2 | MANAGE 2.1, MANAGE 1.3 | GOVERN 1.3 (risk tolerance threshold) |
| R-02 Explainability/adverse action | MAP 1.6 (legal constraints) | MEASURE 2.3 | MANAGE 2.1 | GOVERN 6.1 |
| R-03 Vendor/third-party dependency | MAP 1.3 | MEASURE 2.5 | MANAGE 2.1, MANAGE 3.1 | GOVERN 6.1, GOVERN 6.2 |
| R-04 Drift/degradation | MAP 5.3 | MEASURE 3.1, MEASURE 3.2 | MANAGE 3.1 | GOVERN 5.2 |
| R-05 Security/adversarial | MAP 5.1 | MEASURE 2.4 | MANAGE 2.3 (emergency intervention) | GOVERN 1.3 |
| R-06 Regulatory alignment | MAP 1.6 | — | MANAGE 1.3 | GOVERN 6.1, GOVERN 6.3 |
| R-07 Human oversight | MAP 1.2 | MEASURE 2.5 | MANAGE 2.4 | GOVERN 2.1 |

## Treatment Options Reference

- **Mitigate** — technical (retrain, remove proxy features, add human review), operational (restrict use case, tighten thresholds), or process controls that reduce likelihood/impact
- **Transfer** — contractual risk-shifting to vendor (indemnification, warranty on fair-lending testing, audit rights) — relevant for R-03
- **Avoid** — decommission or decline to deploy a feature/model version where residual risk cannot be brought within tolerance
- **Accept** — formally document and obtain Model Risk Committee / CRO sign-off for any residual risk below full mitigation, per MANAGE 1.3

## Financial-Services Model Risk Alignment (SR 11-7 / OCC 2011-12)

Every treatment above should map to standard MRM lifecycle controls:
- **Independent validation** before initial production use and after any material model change (applies to R-01, R-02, R-05)
- **Champion–challenger comparison** in production, particularly for the vendor-hosted model (R-03) and ongoing drift monitoring (R-04)
- **Ongoing monitoring** with defined thresholds and escalation triggers (R-04, R-03)
- **Effective challenge** documented at the Model Risk Committee — the committee (not the model owner alone) should be the accepting authority for any residual risk above tolerance (MANAGE 1.3), consistent with SR 11-7's requirement for independent, skeptical review

Update the Likelihood/Impact and Treatment columns whenever MEASURE produces new evidence (MEASURE 4.3), and log outcomes back into MANAGE 4 for the quarterly model risk review.

---
*This is general compliance information, not legal advice. Verify fair-lending testing methodology, reason-code requirements, and EU AI Act applicability with qualified counsel and your model risk governance function.*

# AI Risk Register Template — Credit Scoring Model (Financial Services)

This is a working risk register template designed for a financial institution deploying a machine learning credit scoring model. It maps each risk to the **NIST AI Risk Management Framework (AI RMF 1.0)** functions and categories (GOVERN, MAP, MEASURE, MANAGE) and cross-references relevant financial services regulatory drivers (ECOA/Reg B, FCRA, SR 11-7/OCC 2011-12, GLBA) where applicable. It is intended as a starting point to be tailored, populated with real ownership/dates, and integrated into your enterprise risk management (ERM) and model risk management (MRM) systems.

---

## How to Use This Register

- **Risk ID**: Unique identifier (prefix by category, e.g., FL = Fair Lending, MD = Model/Data, TP = Third Party, CY = Cyber, PR = Privacy, RC = Regulatory Compliance, OP = Operational).
- **AI RMF Mapping**: The primary NIST AI RMF 1.0 subcategory(ies) the risk and its controls relate to. Most risks touch multiple functions (GOVERN is nearly always relevant as the umbrella); the mapping below lists the *primary* driving subcategory plus key secondary ones.
- **Likelihood / Impact**: Score 1 (Low) – 5 (Very High). Adjust scale to match your enterprise risk taxonomy.
- **Risk Rating**: Likelihood x Impact, banded as Low (1–6), Medium (7–12), High (13–19), Critical (20–25).
- **Treatment Option**: Mitigate / Transfer / Avoid / Accept.
- **Treatment Actions/Owner**: Concrete control activities and the accountable role (not a named individual — map to your governance structure).

Recommended review cadence: quarterly for High/Critical risks, semi-annually for Medium, annually for Low, plus ad hoc review upon model change, material data drift, or regulatory guidance updates.

---

## Risk Register

| Risk ID | Risk Description | AI RMF Mapping (Primary + Secondary) | Likelihood (1–5) | Impact (1–5) | Risk Rating | Treatment Option | Treatment Actions / Owner |
|---|---|---|---|---|---|---|---|
| FL-01 | **Disparate impact / fair lending violation**: Model produces statistically significant adverse outcomes for a protected class (race, sex, age, national origin, receipt of public assistance) even without intent, violating ECOA/Reg B and FHA. | MEASURE 2.11 (fairness & bias testing); MAP 2.3 (context of use), MAP 5.1 (impacted individuals/groups); GOVERN 1.2, 6.1 | 4 | 5 | Critical | Mitigate | Run pre-deployment and quarterly disparate impact testing (adverse impact ratio, marginal effect analysis) across protected classes and proxies (zip code, alternative data). Engage Fair Lending/Compliance and independent model validation. Owner: Chief Model Risk Officer + Fair Lending Officer. |
| FL-02 | **Proxy discrimination**: Model uses facially neutral features (zip code, education, device type, alternative/utility data) that act as proxies for protected characteristics, reintroducing bias indirectly. | MAP 2.3, MAP 5.1; MEASURE 2.11; GOVERN 1.1 | 3 | 5 | High | Mitigate | Proxy correlation analysis and feature-level fair lending review before feature inclusion; document business justification for each feature under Reg B "empirically derived, demonstrably and statistically sound" standard. Owner: Model Development Lead + Fair Lending Counsel. |
| EX-01 | **Inadequate adverse action explainability**: Model cannot generate specific, accurate reasons for denial/adverse terms required under ECOA/Reg B and FCRA (e.g., black-box ensemble/neural net lacks traceable reason codes). | MAP 2.2, MAP 3.1 (explainability requirements); MEASURE 2.9 (explainability/interpretability); MANAGE 2.2 | 3 | 5 | High | Mitigate | Implement SHAP/LIME or reason-code engine validated against model logic; ensure top adverse action reasons are accurate, stable, and human-reviewable; independent validation of explanation fidelity. Owner: Model Development Lead + Compliance. |
| MD-01 | **Model drift / performance degradation**: Shifts in applicant population, macroeconomic conditions, or credit behavior (e.g., rate environment change) degrade predictive accuracy and calibration over time, undermining safety and soundness. | MEASURE 2.4 (ongoing monitoring), MEASURE 3.1; MANAGE 4.1, 4.3; GOVERN 1.5 | 4 | 4 | High | Mitigate | Establish ongoing performance monitoring (PSI/CSI, KS statistic, AUC tracking, calibration drift) with defined thresholds and retraining triggers; champion-challenger framework. Owner: Model Validation / Model Risk Management. |
| DQ-01 | **Data quality and representativeness gaps**: Training data underrepresents certain applicant segments (thin-file, credit invisible, new-to-country applicants), or contains errors, leading to unreliable predictions for those groups. | MAP 2.3, MAP 3.1 (data suitability); MEASURE 2.1, 2.2 (data quality metrics); GOVERN 1.1 | 3 | 4 | High | Mitigate | Data lineage documentation, representativeness analysis vs. target population, data quality scorecards, gap remediation plan (e.g., alternative data pilots for thin-file applicants) with fairness testing. Owner: Data Governance Lead. |
| TP-01 | **Third-party/vendor model risk**: Credit scoring model or key components (bureau scores, alternative data, ML platform) sourced from a vendor with insufficient transparency, validation evidence, or SLA around model changes. | GOVERN 6.1 (third-party risk), MAP 4.1 (third-party/vendor context); MEASURE 1.1 | 3 | 4 | High | Mitigate | Vendor due diligence per SR 11-7/OCC 2013-29 third-party risk guidance; contractual rights to audit, obtain model documentation, and receive advance notice of model changes; independent validation of vendor model where feasible. Owner: Vendor/Third-Party Risk Management + MRM. |
| RC-01 | **Non-compliance with SR 11-7 / OCC 2011-12 model risk management expectations**: Insufficient independent validation, documentation, or ongoing monitoring fails supervisory model risk management standards. | GOVERN 1.1, 1.3, 1.4 (policies, roles, documentation); MANAGE 1.1, 1.2; MEASURE 1.1 | 3 | 5 | High | Mitigate | Full model risk management lifecycle per SR 11-7: independent validation, effective challenge, model inventory, tiering by risk, documented limitations/assumptions. Owner: Model Risk Management (independent from development). |
| PR-01 | **Applicant data privacy violation**: Use of alternative data (social media, geolocation, transaction data) or insufficient consent/notice violates GLBA, state privacy laws (e.g., CCPA/CPRA), or FCRA permissible purpose requirements. | MAP 1.1 (context/legal requirements), MAP 5.1; GOVERN 1.2, 4.1; MANAGE 2.3 | 2 | 4 | Medium | Mitigate | Privacy impact assessment prior to onboarding new data sources; verify FCRA permissible purpose and GLBA notice requirements; data minimization; consent tracking. Owner: Privacy Officer + Legal. |
| CY-01 | **Cybersecurity of training/inference data and model artifacts**: Sensitive applicant financial data or model weights/parameters are exposed via breach, insider threat, or insecure MLOps pipeline, or model is subject to adversarial manipulation/data poisoning. | MANAGE 2.1, 2.4 (security incident response); MEASURE 2.7 (security testing); GOVERN 1.1, 5.1 | 3 | 5 | High | Mitigate | Encrypt data at rest/in transit; access controls and audit logging on training pipelines and model registry; adversarial robustness/poisoning testing; incident response plan covering AI-specific scenarios; align with GLBA Safeguards Rule. Owner: CISO + ML Engineering. |
| GV-01 | **Insufficient AI governance structure / unclear accountability**: No formal cross-functional AI governance committee, unclear RACI between model development, compliance, risk, and business lines for credit model decisions. | GOVERN 1.1, 2.1, 2.2, 2.3 (roles and responsibilities); GOVERN 4.1 | 3 | 4 | High | Mitigate | Stand up AI/Model Governance Committee with Compliance, Legal, Risk, Data Science, and Business representation; formal charter, escalation paths, and sign-off gates for model deployment/changes. Owner: Chief Risk Officer. |
| GV-02 | **Inadequate documentation for regulatory examination**: Model documentation (development, validation, monitoring) is insufficient to support examiner review or litigation defense, increasing regulatory and legal exposure. | GOVERN 1.4, 4.2 (documentation practices); MAP 1.1; MEASURE 4.1 | 3 | 4 | High | Mitigate | Maintain model documentation per SR 11-7 standards: conceptual soundness, data sources, assumptions/limitations, validation results, ongoing monitoring reports, change logs. Owner: Model Documentation Lead / MRM. |
| HO-01 | **Inappropriate human oversight / over-reliance on automated decision**: Loan officers or automated straight-through processing rubber-stamp model output without meaningful human review or override capability for edge cases. | GOVERN 3.2 (human-AI configuration); MANAGE 3.1, 3.2; MAP 2.1 | 3 | 3 | Medium | Mitigate | Define human-in-the-loop checkpoints for borderline/declined cases; override authority and logging; training for staff on model limitations. Owner: Credit Policy / Business Line Owner. |
| MD-02 | **Model complexity / lack of conceptual soundness**: Overly complex ensemble or deep learning architecture chosen without adequate justification relative to interpretability needs, increasing validation difficulty and regulatory scrutiny. | MAP 1.1, 2.2 (fit for purpose); MEASURE 2.9; GOVERN 1.1 | 2 | 3 | Medium | Mitigate | Require documented rationale for model architecture choice weighing performance vs. interpretability; consider constrained/monotonic models for credit decisioning where feasible. Owner: Model Development Lead. |
| MD-03 | **Feedback loop / reject inference bias**: Model trained only on approved/funded loans creates selection bias, as outcomes for rejected applicants are never observed, compounding bias over successive model generations. | MAP 2.3; MEASURE 2.2, 2.11; MANAGE 4.1 | 3 | 4 | High | Mitigate | Apply reject inference techniques (augmentation, reweighting) with validation; periodic "low-side" testing/champion challenger with expanded approval pilots; document methodology and limitations. Owner: Data Science Lead + MRM. |
| RC-02 | **Regulatory change risk**: Emerging AI-specific regulation (e.g., state AI/algorithmic discrimination laws, CFPB guidance on AI in credit decisions, potential federal AI legislation) creates compliance gap for existing model. | GOVERN 1.2, 1.3 (legal/regulatory alignment); MAP 1.1 | 3 | 3 | Medium | Mitigate | Establish regulatory horizon-scanning process for AI/credit-specific rulemaking; periodic compliance gap assessments; legal review of CFPB circulars (e.g., on adverse action and complex algorithms). Owner: Compliance / Regulatory Affairs. |
| OP-01 | **Business continuity / model availability failure**: Credit scoring service outage or degraded performance disrupts loan origination pipeline, causing operational and reputational impact. | MANAGE 4.2 (incident response and recovery); MEASURE 2.6 (reliability/robustness) | 2 | 3 | Medium | Mitigate | Define SLAs, failover/fallback scoring process (e.g., manual underwriting fallback), resilience testing. Owner: IT Operations / Business Continuity. |
| RP-01 | **Reputational risk from public bias incident**: Media, advocacy group, or regulator publicizes disparate outcomes or a high-profile denial, damaging brand and triggering broader scrutiny (regardless of legal finding). | MAP 5.1, 5.2 (societal impact); GOVERN 6.2; MEASURE 4.2 | 2 | 4 | Medium | Mitigate | Proactive fairness testing and public-facing transparency (model risk disclosures where appropriate); crisis communication plan; social listening. Owner: Corporate Communications + Compliance. |
| VD-01 | **Vendor/model concentration risk**: Over-reliance on a single scoring vendor or bureau data source creates single point of failure and limits ability to switch if performance or compliance issues arise. | GOVERN 6.1; MAP 4.1; MANAGE 1.3 | 2 | 3 | Medium | Transfer / Mitigate | Diversify data/vendor sources where feasible; contractual exit and portability clauses; maintain in-house fallback scoring capability. Owner: Vendor Management + MRM. |
| NU-01 | **Non-deployment of higher-accuracy but non-compliant model**: Pressure to adopt a marginally more predictive but less explainable/fair model creates tension between business performance goals and compliance requirements. | GOVERN 1.2, 1.5 (risk tolerance); MAP 1.2 | 2 | 4 | Medium | Avoid | Formal risk-acceptance gate requiring Compliance/Legal sign-off before deploying any model that cannot meet explainability or fairness thresholds, regardless of accuracy gain. Owner: AI Governance Committee. |
| IN-01 | **Model inventory / shadow AI risk**: Business units use or modify scoring logic (e.g., local overrides, spreadsheet adjustments) outside the formal model inventory, evading governance and validation. | GOVERN 1.1, 1.6 (inventory); MAP 1.1 | 3 | 3 | Medium | Mitigate | Enforce enterprise AI/model inventory with mandatory registration; periodic audit for unregistered/shadow models; access controls preventing unauthorized production changes. Owner: Model Risk Management. |

---

## Risk Rating Heat Map (for reference)

| Impact \ Likelihood | 1 (Rare) | 2 (Unlikely) | 3 (Possible) | 4 (Likely) | 5 (Almost Certain) |
|---|---|---|---|---|---|
| **5 (Severe)** | Medium | High | Critical | Critical | Critical |
| **4 (Major)** | Low | Medium | High | High | Critical |
| **3 (Moderate)** | Low | Medium | Medium | High | High |
| **2 (Minor)** | Low | Low | Medium | Medium | High |
| **1 (Negligible)** | Low | Low | Low | Medium | Medium |

---

## NIST AI RMF Function Reference (for mapping consistency)

- **GOVERN** — Culture, policies, accountability, roles, risk tolerance, third-party risk, and documentation practices that cut across the AI lifecycle. Nearly every risk in this register has a GOVERN component as the accountability backbone.
- **MAP** — Establishing context: intended use, impacted individuals/groups, legal/regulatory requirements, and appropriateness of data/model for the use case.
- **MEASURE** — Testing, evaluation, and monitoring: bias/fairness metrics, performance, robustness, security, explainability, and ongoing monitoring.
- **MANAGE** — Risk response: prioritization, resource allocation, incident response, third-party risk treatment, and continuous improvement based on MEASURE outputs.

---

## Notes on Treatment Options

- **Mitigate**: Reduce likelihood or impact through controls (most common for credit scoring risks given regulatory obligations that can't be waived).
- **Transfer**: Shift risk via insurance, vendor contractual indemnification, or outsourcing (limited applicability for fair lending risk, which cannot be fully transferred away from the institution).
- **Avoid**: Decline to deploy a feature, data source, or model architecture that creates unacceptable risk (e.g., NU-01).
- **Accept**: Formally accept residual risk within risk appetite after mitigation, with sign-off from appropriate risk committee (not illustrated above as a primary treatment given the regulated nature of credit decisioning, but applicable to low-rated residual risks after controls are applied).

---

*Disclaimer: This template is provided for informational purposes based on general NIST AI RMF 1.0 principles and common financial services regulatory considerations (ECOA/Reg B, FCRA, SR 11-7/OCC 2011-12, GLBA). It is not legal advice. Validate against your institution's specific regulatory obligations, primary regulator expectations, and legal counsel before operational use.*

# NIST AI RMF ↔ EU AI Act: Mapping and Gap Analysis

Short answer: the two frameworks are highly complementary, and NIST AI RMF (NIST AI 100-1, January 2023) is explicitly designed to be usable as the risk management *methodology* that satisfies the EU AI Act's Article 9 "appropriate risk management system" requirement. But they are not equivalent — the AI RMF is **voluntary and outcome-based, not a compliance checklist**, while the EU AI Act is a binding legal regulation with specific mandatory deliverables, deadlines, and penalties. If you implement AI RMF alone, you will build strong risk management *practice* but will still have concrete compliance gaps to fill for legal conformity.

## Framework-to-Article Mapping

| AI RMF Function | EU AI Act Requirement |
|------------------|------------------------|
| GOVERN 1 (AI risk policies) | Art. 9 (Risk management system) for high-risk AI |
| GOVERN 2/3 (Accountability) | Art. 16 (Obligations of high-risk AI providers), Art. 26 (Deployer obligations) |
| MAP 1 (Intended use) | Art. 9(2) — risk management must cover intended and reasonably foreseeable misuse |
| MAP 3 (Stakeholder mapping) | Art. 9(2)(b) — identification and analysis of known and foreseeable risks |
| MEASURE 2 (System evaluation) | Art. 10 (Data governance), Art. 15 (Accuracy, robustness, cybersecurity) |
| MEASURE 3 (Ongoing monitoring) | Art. 72 (Post-market monitoring), Art. 26(5) — deployer monitoring obligations |
| MANAGE 3 (Incident response) | Art. 73 (Reporting of serious incidents to market surveillance) |
| All functions | Annex IX (Technical documentation requirements for high-risk AI systems) |

## Key Structural Difference

| | NIST AI RMF | EU AI Act |
|---|---|---|
| Nature | Voluntary, outcome-based framework | Mandatory regulation (Regulation (EU) 2024/1689) |
| Scope | Any AI system, any organization, self-scoped | Risk-tiered (unacceptable/high-risk/limited/minimal), applies to in-scope providers & deployers with EU nexus |
| Deliverables | Risk register, profiles, policies — format is your choice | Specific mandated artifacts: conformity assessment, technical documentation (Annex IV), EU database registration, CE marking (for high-risk) |
| Enforcement | None — self-directed | Market surveillance authorities, fines up to €35M or 7% of global turnover for prohibited-practice violations |
| Timing | Continuous, iterative | Phased mandatory deadlines (prohibited practices Feb 2025, GPAI obligations Aug 2025, high-risk obligations Aug 2026/2027 depending on annex) |

## Gaps You Need to Fill If You Implement AI RMF Alone

Even with a mature AI RMF program (all four functions operating well), these EU AI Act-specific obligations have **no direct AI RMF equivalent** and must be addressed separately:

1. **Risk-tier classification itself.** AI RMF doesn't tell you whether your system is "high-risk" under Annex III — that's a legal classification exercise you must do against the Act's specific categories (employment, credit, law enforcement, critical infrastructure, etc.). Do this before mapping anything else.
2. **Conformity assessment procedure (Art. 43).** High-risk systems require either self-assessment or third-party (notified body) conformity assessment before market placement — AI RMF has no equivalent "certification" step.
3. **CE marking and EU database registration (Art. 48, Art. 71).** Purely regulatory/administrative — high-risk AI systems must be registered in the EU public database before deployment.
4. **Annex IV technical documentation format.** MEASURE 2.6 and MAP 2 documentation get you most of the content, but the Act specifies a particular structural format (Annex IV) that your existing model/system cards likely won't match without reformatting.
5. **Fundamental Rights Impact Assessment (Art. 27)** — required specifically for certain deployers (public bodies, and private operators in the specified sectors like banking/insurance) of high-risk systems. MAP 3 (stakeholder risk/benefit mapping) is a strong foundation but doesn't satisfy the Article 27 form and filing requirement on its own.
6. **Serious incident reporting to market surveillance authorities within mandated timeframes (Art. 73).** MANAGE 3.2 gets you incident logging and investigation, but the Act adds a specific external regulatory notification clock (15 days, shorter for critical infrastructure) that your internal MANAGE process needs to be re-tuned to meet.
7. **Prohibited practices screening (Art. 5).** AI RMF has no direct equivalent to the Act's specific list of banned AI practices (social scoring, real-time remote biometric identification in public spaces for law enforcement with narrow exceptions, manipulative/subliminal techniques, etc.) — this is a hard legal gate that must be checked independently, ideally as an extension of MAP 1.5 (scoping prohibited/misuse cases).
8. **General-Purpose AI (GPAI) model obligations (Art. 53-55).** If you build or fine-tune foundation models, there are separate transparency and systemic-risk obligations not covered by the core AI RMF functions.
9. **Human oversight design requirements (Art. 14).** MEASURE 2.5 tests that human oversight exists and works; Art. 14 additionally mandates specific *design* requirements (the system must be built to enable a human to understand, monitor, and intervene) — this needs to be checked at MAP 1 / system design, not just validated at MEASURE.
10. **Notified body / authorized representative requirements** for non-EU providers placing high-risk AI on the EU market — a corporate/legal structural requirement with no AI RMF analog at all.

## Recommended Approach

1. Use **AI RMF GOVERN** as your organizational foundation (policy, accountability, risk tolerance) — this satisfies the spirit and much of the substance of Art. 9's "appropriate risk management system."
2. Run **Art. 5 prohibited-practice screening** and **Annex III risk-tier classification** as an EU AI Act-specific extension of your MAP 1 work, before anything else.
3. Use **MAP/MEASURE** to generate the technical content, then **reformat into Annex IV structure** for any system classified high-risk.
4. Add the EU AI Act-specific mandatory artifacts (conformity assessment, CE marking, EU database registration, Fundamental Rights Impact Assessment where applicable) as parallel workstreams — track them in your GOVERN 6.1 regulatory register alongside AI RMF activity so nothing falls through.
5. Re-tune your **MANAGE 3** incident response timelines to meet the Act's specific external reporting deadlines, not just your internal escalation cadence.

---
*This is general compliance information, not legal advice. EU AI Act obligations, deadlines, and risk-tier classifications should be verified against the official regulation text and confirmed with qualified EU regulatory counsel, especially given the Act's phased applicability dates through 2027.*

# Mapping NIST AI RMF to the EU AI Act — and Where the Gaps Are

Short answer: NIST AI RMF and the EU AI Act rhyme conceptually, but they are fundamentally different instruments. Implementing AI RMF well will build most of the *organizational muscle* you need for EU AI Act compliance, but it will **not**, on its own, satisfy the Act's legal obligations. You will need a compliance layer on top. Below is the detail.

---

## 1. Two Different Kinds of Things

| | **NIST AI RMF** | **EU AI Act** |
|---|---|---|
| Nature | Voluntary, non-binding risk management framework | Binding EU regulation (directly applicable law in all Member States) |
| Purpose | Help organizations *think about and manage* AI risk | Set *legal requirements* organizations must meet, with penalties for non-compliance |
| Structure | Four functions: Govern, Map, Measure, Manage | Risk-tiered legal obligations (unacceptable, high, limited, minimal risk) + GPAI rules |
| Enforcement | None — it's guidance | Yes — fines up to €35M or 7% of global turnover (prohibited practices); €15M/3% (most high-risk violations); market surveillance authorities, conformity assessment bodies |
| Scope of "risk" | Broad, sociotechnical, trustworthiness-oriented (validity, safety, security, accountability, transparency, fairness, privacy) | Legally defined risk tiers tied to specific use cases (Annex III) and specific legal rights (safety, fundamental rights) |
| Flexibility | Adaptable to any org, any AI use case, any sector | Prescriptive: specific documentation, specific processes, specific timelines, specific registration |
| Output | A risk management *practice/culture* | A compliance *dossier* (technical documentation, conformity assessment, CE marking, registration) |

**Bottom line:** AI RMF is a "how to think" framework; the EU AI Act is a "what you must do, prove, and file" law. You can be excellent at AI RMF and still be non-compliant with the Act if you haven't done the legally-mandated paperwork, assessments, and registrations.

---

## 2. Conceptual Mapping: NIST Functions to EU AI Act Provisions

NIST itself has published crosswalk resources (including an AI RMF Crosswalk mapping to ISO/IEC 23894, OECD, and elements relevant to the EU AI Act) — the mapping below follows that general spirit, applied specifically to the Act's Title III, Chapter 2 requirements for high-risk AI systems (Articles 9–15), plus surrounding obligations.

| NIST AI RMF Function | Sub-elements | Related EU AI Act Provisions |
|---|---|---|
| **GOVERN** | Policies, accountability structures, risk culture, roles/responsibilities, third-party risk | Art. 9 (risk management system as ongoing process), Art. 17 (Quality Management System), Art. 4 (AI literacy), provider/deployer role definitions (Art. 3, 16, 26), Art. 25 (authorized representative obligations) |
| **MAP** | Context establishment, categorizing AI systems, identifying impacted stakeholders, intended use/foreseeable misuse | Art. 6 + Annex III (high-risk classification logic), Art. 5 (prohibited practices screening), Art. 27 (Fundamental Rights Impact Assessment for certain deployers), Art. 10 (data governance — understanding data provenance/context) |
| **MEASURE** | Metrics, testing, evaluation, monitoring for validity/reliability/bias/safety | Art. 15 (accuracy, robustness, cybersecurity — with specific metrics disclosed in instructions for use), Art. 9(6)-(8) (testing against risk management system), Art. 72 (post-market monitoring plan and system) |
| **MANAGE** | Risk prioritization, response, resource allocation, incident response, third-party risk management | Art. 9 (risk mitigation measures), Art. 73 (serious incident reporting), Art. 20 (corrective actions), Art. 21 (cooperation with authorities), Art. 16 (provider obligations broadly) |

### Additional mapping for specific Articles

| EU AI Act Requirement (High-Risk Systems) | Nearest NIST AI RMF Analog |
|---|---|
| Art. 9 — Risk management system | GOVERN + MAP + MEASURE + MANAGE (the full lifecycle loop) — closest single analog to the entire AI RMF cycle |
| Art. 10 — Data and data governance | MAP 2.x (data/context characterization); MEASURE (data quality metrics) — but AI RMF doesn't mandate specific data governance controls (bias examination, representativeness, error correction) the way Art. 10 does |
| Art. 11 — Technical documentation | Loosely reflected in MANAGE 4.x (documentation of risk decisions) — but NIST doesn't specify a document format; EU Act has an Annex IV template |
| Art. 12 — Record-keeping / logging | MEASURE 2.x, MANAGE 4.x (monitoring/logging as good practice) — Act mandates automatic log retention, minimum periods, specific traceability |
| Art. 13 — Transparency & instructions for use | MAP 3.x, GOVERN 4.x (documentation for downstream users) — Act requires specific disclosures to deployers |
| Art. 14 — Human oversight | GOVERN 3.x, MANAGE 2.x (human-AI teaming, oversight mechanisms) — Act requires designed-in oversight measures (stop buttons, override capability) as a legal design requirement, not just a practice |
| Art. 15 — Accuracy, robustness, cybersecurity | MEASURE 2.5–2.7 (robustness, security) — conceptually aligned but Act ties this to conformity assessment and CE marking, which AI RMF has no equivalent for |
| Art. 16-27 — Provider/deployer/importer/distributor obligations | Not addressed by AI RMF at all — this is supply-chain legal role allocation unique to product-safety-style regulation |
| Art. 43 — Conformity assessment | No NIST equivalent — this is a legal certification process |
| Art. 49 — EU database registration | No NIST equivalent |
| Art. 72 — Post-market monitoring | MEASURE + MANAGE (continuous monitoring is a RMF theme) but Act requires a formal plan and specific reporting channel to authorities |
| Art. 73 — Serious incident reporting | MANAGE 4.x (incident response) exists as a practice, but the Act adds legally binding **timelines** (e.g., report serious incidents within 15 days, or 2 days for deaths/critical infrastructure disruption, 10 days for widespread infringement/serious harm to property or environment — exact windows vary by incident severity under the Act and its implementing guidance) |

---

## 3. Where AI RMF Alone Leaves Gaps for EU AI Act Compliance

If you implement NIST AI RMF faithfully and assume you're "covered" for the EU AI Act, here is what's still missing. These are the concrete gaps to close:

### a) Legal classification and prohibited practices screening (Art. 5)
AI RMF has no equivalent of the Act's **prohibited AI practices list** — e.g., social scoring, manipulative/subliminal techniques causing harm, exploiting vulnerabilities, certain biometric categorization, untargeted facial scraping for recognition databases, emotion recognition in workplace/education (with narrow exceptions), and real-time remote biometric identification in public spaces for law enforcement (with narrow exceptions). You need a **legal screening step** before any risk management even begins — some AI uses simply cannot proceed in the EU regardless of how well-managed the risk is.

### b) Formal conformity assessment and CE marking (Arts. 43, 48)
High-risk systems generally require a conformity assessment (self-assessment or third-party/notified body assessment depending on the category) and must bear a **CE marking** before being placed on the market. This is a legal certification and labeling regime with no AI RMF counterpart — RMF is about internal risk management, not third-party attestation for market access.

### c) EU database registration (Art. 49, Art. 71)
Providers (and in some cases deployers, e.g., public authorities) of high-risk AI systems must **register** in the EU-wide database before placing the system on the market or putting it into service. AI RMF has no registration or public-disclosure mechanism.

### d) Prescribed documentation formats (Annex IV, Art. 11)
The Act mandates technical documentation in a specific structure (Annex IV) covering system description, development process, risk management measures, performance metrics, etc. AI RMF encourages documentation but doesn't specify a template — you'll need to translate your RMF documentation practices into the Act's required format.

### e) Quality Management System (Art. 17)
Providers of high-risk AI systems must maintain a documented **QMS** covering regulatory compliance strategy, design control, data management, post-market monitoring, and more — similar in spirit to ISO 9001/13485-style QMS obligations in other EU product law. This is an organizational/procedural requirement AI RMF doesn't specify.

### f) GPAI (General-Purpose AI Model) obligations (Arts. 53–55)
If you develop or fine-tune foundation/general-purpose models, there are separate obligations: technical documentation for downstream providers, copyright/training-data summary disclosure, and — for models with "systemic risk" (based on compute thresholds, currently >10^25 FLOPs presumption) — model evaluation, adversarial testing, incident reporting to the AI Office, and cybersecurity obligations. AI RMF's generative AI profile (NIST AI 600-1) offers useful risk guidance here but does not satisfy these specific legal disclosure and reporting duties.

### g) Designated EU representative (Art. 22)
Non-EU providers placing high-risk AI systems on the EU market must appoint an **authorized representative established in the EU**. This is a pure legal/administrative requirement with no RMF analog — relevant to you as a non-EU-headquartered organization if that's your situation.

### h) Fundamental Rights Impact Assessment (Art. 27)
Certain deployers of high-risk AI systems (notably public bodies and private entities providing public services, banking/insurance in specified use cases) must conduct an **FRIA** before deployment — assessing impacts on fundamental rights, affected persons, oversight measures, and complaint mechanisms. This is distinct from and narrower/more legalistic than NIST's broader "map context and impacted stakeholders" activities — it's a specific, sometimes publicly-filed legal assessment.

### i) Serious incident reporting with legal timelines (Art. 73)
AI RMF's MANAGE function encourages incident response processes, but doesn't impose deadlines. The Act requires providers to report **serious incidents** to market surveillance authorities within legally fixed windows (severity-dependent — as short as 2 days for deaths or serious/irreversible disruption of critical infrastructure), with specific content requirements. You need an operational process capable of meeting these clock-driven obligations, not just a general incident-response capability.

### j) Role-based legal obligations across the value chain (Arts. 16–27)
The Act imposes different, specific legal duties depending on whether you're a **provider, deployer, importer, distributor,** or a **provider whose system is substantially modified downstream** (which can convert a deployer into a provider). AI RMF doesn't have this legal role taxonomy — you need a separate exercise to determine which hat(s) you wear per system and what obligations attach to each.

### k) Notified body engagement and post-market surveillance system (Arts. 43, 72)
For certain high-risk categories, a **notified body** (independent conformity assessment body) must be involved. You'll also need a formal, documented **post-market monitoring system** proportionate to the AI system's risks, feeding into your incident reporting obligations. RMF's "Measure" and "Manage" functions support this conceptually but don't require the specific regulatory touchpoints.

### l) Transparency obligations for limited-risk systems (Art. 50)
Even outside the high-risk tier, systems like chatbots, deepfake generators, and emotion-recognition/biometric-categorization systems have **standalone disclosure obligations** to users (e.g., "you are interacting with AI," labeling of synthetic content). This is a separate, lighter-touch legal track that AI RMF doesn't address as a distinct compliance category.

### m) Penalties, market surveillance, and regulatory engagement
AI RMF has no equivalent of the Act's enforcement architecture — market surveillance authorities, the EU AI Office (for GPAI), national competent authorities, and tiered administrative fines. Compliance programs need a regulatory-engagement and audit-readiness layer that pure risk management frameworks don't anticipate.

---

## 4. Practical Recommendation

A reasonable approach for an organization in your position:

1. **Use NIST AI RMF as your internal risk management operating system** — Govern/Map/Measure/Manage gives you the organizational scaffolding (policies, roles, risk registers, testing, monitoring, incident response) that regulators generally expect to see evidenced anyway.
2. **Overlay a legal compliance workstream specific to the EU AI Act**, covering: role determination (provider/deployer/etc.), Annex III classification screening, Art. 5 prohibited-practices screening, Annex IV technical documentation, QMS (Art. 17), conformity assessment and CE marking (Art. 43/48), EU database registration (Art. 49), FRIA where applicable (Art. 27), GPAI obligations if relevant (Arts. 53–55), and incident reporting playbooks with the Act's specific timelines (Art. 73).
3. **Map your AI RMF artifacts directly into Annex IV documentation** to avoid duplicative work — your risk register, testing results, and monitoring plan under RMF's Measure/Manage functions can largely populate the Act's technical documentation, saving effort.
4. **Assign clear ownership**: risk management (RMF) can sit with AI governance/data science teams; legal conformity workstreams (classification, conformity assessment, registration, FRIA, incident reporting deadlines) need legal/compliance ownership with regulatory affairs expertise, since these carry statutory liability.

---

## 5. EU AI Act Phased Timeline (for planning purposes)

- **August 1, 2024** — Act enters into force
- **February 2, 2025** — Prohibited practices (Art. 5) become applicable; AI literacy obligations begin
- **August 2, 2025** — Governance rules and GPAI model obligations (Arts. 53–55) become applicable; penalty provisions apply; Member States must designate competent authorities
- **August 2, 2026** — Bulk of the Act applies, including high-risk system obligations for Annex III (Article 6(1)-referenced) use cases and the transparency obligations (Art. 50)
- **August 2, 2027** — High-risk obligations extend to AI systems embedded as safety components in products covered by Annex I (e.g., machinery, medical devices, toys) under the "Annex I" product-safety route

Some deadlines and secondary/implementing measures (delegated acts, standards from CEN-CENELEC, Commission guidance) were still evolving as of my knowledge cutoff — given today's date is July 2026, you are very close to the August 2026 high-risk compliance deadline for Annex III systems, so I'd treat this as urgent and **verify current status directly against the EU AI Office's published guidance, the official Union register, and any Commission implementing/delegated acts** rather than relying solely on this summary, since implementation details (harmonized standards, notified body capacity, specific FRIA templates, incident-reporting portals) continue to be finalized and may have changed since my training data was current.

---

## 6. Key Takeaway

NIST AI RMF gives you the risk management *engine*; the EU AI Act requires that engine to be bolted onto a specific, auditable, legally-defined *chassis* — classification, documentation formats, conformity assessment, registration, role-based obligations, and hard deadlines. Treat AI RMF as necessary but not sufficient: it's excellent foundational practice, but full EU AI Act compliance requires a dedicated legal/regulatory compliance workstream layered on top, ideally with legal counsel experienced in EU product-safety-style regulation given the Act's CE-marking/conformity-assessment architecture (borrowed from the EU's "New Legislative Framework" used for medical devices, machinery, etc.).

# GOVERN Function Gap Assessment

Based on what you've described — an AI ethics statement but no formal AI risk policy, no cross-functional AI team, no defined risk tolerance, and legal not involved in AI deployments — here is a rating across all six GOVERN categories, with gaps, evidence needed, a prioritized remediation roadmap, and pasteable templates to get started immediately.

## Category Ratings

| Category | Status | Gap Notes |
|----------|--------|-----------|
| **GOVERN 1** — Policies, processes, risk tolerance in place | 🔴 Not Started | An ethics statement is a values document, not a risk management policy — it doesn't define risk tolerance, ERM integration, or a review cadence. No formal AI Risk Management Policy exists (GOVERN 1.1, 1.2, 1.5). |
| **GOVERN 2** — Accountability structures | 🔴 Not Started | No named AI Risk Owner or accountable senior official. No documented RACI for AI decisions. Without this, every other GOVERN gap will stay unresolved because no one owns closing it. |
| **GOVERN 3** — Roles and responsibilities | 🔴 Not Started | No AI roles register; responsibilities across the AI lifecycle (design, development, deployment, monitoring) are undefined, including for any third-party/vendor AI. |
| **GOVERN 4** — Cross-functional collaboration | 🔴 Not Started | No cross-functional AI team exists. Legal is explicitly not involved in deployments — this is the most urgent structural gap since it also blocks GOVERN 6. |
| **GOVERN 5** — Risk tolerance communicated | 🔴 Not Started | No defined risk tolerance for AI means there is no basis for go/no-go deployment decisions (GOVERN 5.3) — deployments are likely proceeding without a consistent bar. |
| **GOVERN 6** — Alignment with laws/regulations/principles | 🟡 Partial | The ethics statement suggests some principle-level alignment exists, but with legal excluded from deployments, there's no mechanism tracking regulatory requirements (GOVERN 6.1) or ensuring deployments are checked against them before launch. |

**Overall: 5 of 6 categories Not Started, 1 Partial.** This is a Tier 1 ("Partial" / ad hoc) organization on the AI RMF's implementation-tier scale — reactive, not yet risk-informed.

## Flag: Complete-on-Paper vs. Operationalized

Your situation is actually the *inverse* of the common "policy exists but isn't operationalized" pattern — you have a values artifact (the ethics statement) with almost no operational infrastructure underneath it. That's arguably higher-risk than a stalled policy, because the ethics statement can create a false impression of governance maturity to leadership, auditors, or customers, while zero enforcement mechanism actually exists. Treat the ethics statement as an input to GOVERN 1.2, not evidence that GOVERN 1 is complete.

## Prioritized Remediation Roadmap

**Quick Wins (0–30 days) — unblock everything else:**
1. Name an accountable AI Risk Owner (GOVERN 2.2) — even an interim owner while you build the permanent structure.
2. Add legal/compliance to any AI deployment decision immediately, even informally, pending a formal committee (GOVERN 4.1, GOVERN 6.1).
3. Draft an initial risk tolerance statement (GOVERN 1.3, GOVERN 5.1) — start simple; see template below.
4. Start an AI system inventory — even a spreadsheet — covering every AI system in use or planned (GOVERN 1.6).

**Medium Term (30–90 days) — build the structure:**
5. Publish a formal AI Risk Management Policy, signed by senior leadership, superseding/incorporating the ethics statement (GOVERN 1.1, 1.2, 1.5).
6. Stand up the AI governance committee / cross-functional working group with defined RACI, including legal, privacy, security, and the business (GOVERN 2.1, GOVERN 3.1, GOVERN 4.1).
7. Build the AI roles register mapping lifecycle stages to responsible teams, including third-party/vendor AI responsibilities (GOVERN 3.2).
8. Define an escalation path from teams to executives for AI risk concerns (GOVERN 4.3).

**Long Term (90+ days) — operationalize and sustain:**
9. Build a deployment checklist that validates every new AI system against the risk tolerance statement before go-live (GOVERN 5.2, 5.3) — this is what actually connects GOVERN to MAP/MEASURE/MANAGE in practice.
10. Establish a regulatory register and a periodic (at least annual) policy review cadence (GOVERN 1.7, GOVERN 6.1, GOVERN 6.3).
11. Once GOVERN 1–6 are at least 🟡, begin systematic MAP-function work on your existing deployed AI systems — GOVERN gaps of this scale mean any MAP/MEASURE/MANAGE work done today is happening without accountability structure behind it, and should be revisited once GOVERN is operational.

## Mini-Templates

### AI Risk Policy Outline (GOVERN 1.2)
1. Purpose & scope
2. Definitions & AI system inventory criteria
3. Risk tolerance statement
4. Roles & accountability (RACI)
5. Lifecycle requirements (MAP/MEASURE/MANAGE gates per stage)
6. Third-party AI requirements
7. Incident response & escalation
8. Review cadence

### AI Governance Committee Charter — RACI Skeleton (GOVERN 2.1)
- **Accountable** — Executive sponsor / Chief AI Officer (or interim AI Risk Owner)
- **Responsible** — AI product owners, data science/engineering leads
- **Consulted** — Legal, privacy, security (mandatory for every deployment decision going forward — this directly closes your stated legal-involvement gap); HR for any employment-related AI
- **Informed** — Internal audit, board risk committee
- Define quorum, meeting cadence (recommend monthly to start), and decision rights: who can approve a deployment, who can deny one, who can accept residual risk above tolerance

### Risk Tolerance Statement Examples (GOVERN 1.3)
- "We do not deploy AI that makes fully automated adverse decisions about individuals without human review."
- "Disaggregated performance gaps above [X]% between demographic groups block deployment until remediated."
- Adapt these two starting statements to your specific AI use cases and have legal/compliance and the executive sponsor sign off before publishing.

### AI Inventory — Minimum Fields (GOVERN 1.6)
- System name / owner
- Purpose & users
- Model type/provenance (built in-house / bought / fine-tuned third-party model)
- Data categories used
- Lifecycle stage (design / development / testing / deployment / monitoring / decommission)
- Risk tier (once GOVERN 5 risk tolerance is defined)
- Last TEVV (Test, Evaluation, Verification, Validation) date

## Bottom Line

Your single highest-leverage action is **naming an accountable owner and pulling legal into deployment decisions this week** — every other gap (policy, cross-functional team, risk tolerance) depends on someone being responsible for driving it, and right now nobody is. Everything in the Quick Wins column above can start in parallel without waiting for the formal policy to be finished.

---
*This is general compliance information, not legal advice. Consult qualified counsel to confirm applicable regulatory obligations before finalizing your AI risk policy and deployment decisions.*

# GOVERN Function Gap Assessment — NIST AI RMF 1.0

**Prepared for:** hemant.naik@gmail.com
**Date:** July 3, 2026
**Scope:** NIST AI Risk Management Framework — GOVERN function (Categories 1–6)

---

## 1. Executive Summary

Based on the facts provided, your organization has taken a first, meaningful step (a published AI ethics statement) but has **not yet built the operational governance infrastructure** needed to manage AI risk in practice. In NIST AI RMF terms, GOVERN is the *cross-cutting foundation* that the other three functions (MAP, MEASURE, MANAGE) depend on — weak GOVERN maturity means any risk identification or mitigation work happening elsewhere in the organization is likely ad hoc, inconsistent, and unable to scale or withstand audit/regulatory scrutiny.

**Overall GOVERN maturity: Initial (Red/Yellow border)** — you have intent (values) but not infrastructure (policy, accountability, tolerance, legal integration).

| Category | Focus Area | Rating |
|---|---|---|
| GOVERN 1 | Policies, processes, legal/regulatory alignment, risk tolerance | 🔴 **Not Started / Initial** |
| GOVERN 2 | Accountability structures, roles & responsibilities | 🔴 **Not Started** |
| GOVERN 3 | Workforce diversity, competency, AI literacy | 🟡 **Initial** |
| GOVERN 4 | Risk culture, safety mindset, continuous improvement | 🟡 **Initial** |
| GOVERN 5 | Stakeholder engagement (internal & external) | 🟡 **Initial** |
| GOVERN 6 | Third-party and supply chain risk policies | 🔴 **Not Started** |

Rating scale used: **Not Started → Initial → Developing → Managed → Optimized**

---

## 2. Category-by-Category Rating and Rationale

### GOVERN 1 — Policies, Processes, Procedures & Practices
*(Legal/regulatory requirements understood and managed; risk tolerance determined and documented; policies for mapping/measuring/managing risk in place)*

**Rating: 🔴 Not Started / Initial (1 of 5)**

**Rationale:**
- An AI ethics *statement* is a values declaration, not an operational policy. It does not tell employees what they must do, what is prohibited, what approvals are required, or how exceptions are handled.
- No formal AI risk policy means there is no documented linkage between your ethics principles and actual controls (e.g., acceptable use, model risk tiers, prohibited use cases, data governance for training/fine-tuning, human oversight requirements).
- **No defined risk tolerance** is a critical gap — without it, no one in the organization can consistently decide what level of AI risk is acceptable, so decisions default to individual judgment or vendor sales pitches.
- Legal/regulatory mapping is implicitly absent since legal isn't involved (see GOVERN 1.1's explicit requirement that legal and regulatory requirements involving AI are understood, managed, and documented).
- GOVERN 1 is the anchor category — nearly every other GOVERN, MAP, MEASURE, and MANAGE activity depends on having tolerance thresholds and policy to measure against.

### GOVERN 2 — Accountability Structures
*(Roles, responsibilities, and lines of communication for AI risk are clear and understood across the organization; leadership is responsible for decisions built on AI risk understanding)*

**Rating: 🔴 Not Started (0–1 of 5)**

**Rationale:**
- No cross-functional AI team means there is no defined owner for AI risk — not for approvals, not for incident response, not for policy exceptions.
- No RACI exists (who Recommends, who Approves, who is Consulted, who is Informed) for AI system intake, procurement, or deployment decisions.
- Without accountable owners, AI risk responsibility is diffused (i.e., "everyone's job" = "no one's job"), which is a classic root cause of shadow AI adoption and uncontrolled tool sprawl.
- Executive/Board-level accountability and reporting lines for AI risk are presumably also undefined, which will be a gap in any future audit (SOC 2, ISO 42001, EU AI Act governance obligations).

### GOVERN 3 — Workforce Diversity, Equity, and Competency
*(Team composition includes diverse perspectives and disciplines; workforce has necessary skills and is empowered to raise AI risk concerns)*

**Rating: 🟡 Initial (1–2 of 5)**

**Rationale:**
- Not explicitly discussed in the facts given, but since there is no cross-functional AI team, GOVERN 3 is structurally impossible to satisfy today — you cannot have diverse, empowered participation in AI governance if there is no forum for it to occur in.
- Rated slightly above "Not Started" only because the existence of an ethics statement implies *some* baseline organizational awareness and values-setting occurred, which is a precursor to competency building.
- No evidence of AI literacy training, escalation channels for concerns, or psychological safety mechanisms for staff to flag AI risk issues.

### GOVERN 4 — Organizational Culture of Risk Management
*(Organizational commitment to a culture that considers and communicates AI risk; leadership models values; lessons learned are incorporated; there is a focus on safety and continuous improvement)*

**Rating: 🟡 Initial (2 of 5)**

**Rationale:**
- The ethics statement is genuine evidence of cultural intent — this is worth crediting, as GOVERN 4 is partly about tone from the top.
- However, culture without mechanism doesn't hold under pressure: without a risk policy, tolerance thresholds, or accountable owners, there's no way to know whether the ethics statement actually changes behavior day-to-day (e.g., during a rushed vendor deployment).
- No indication of a feedback loop (post-incident reviews, red-teaming, lessons-learned processes) tied to AI specifically.
- This category will naturally mature once GOVERN 1 and 2 are addressed — culture needs structure to become durable rather than aspirational.

### GOVERN 5 — Stakeholder Engagement Mechanisms
*(Processes for consulting and incorporating feedback from internal and external stakeholders, including affected individuals/communities, in AI risk decisions)*

**Rating: 🟡 Initial (1–2 of 5)**

**Rationale:**
- No described mechanism for internal stakeholders (business units, legal, security, privacy, HR) to weigh in on AI deployments before they go live — legal's total absence from AI deployment decisions is a direct, explicit failure of this category.
- No described mechanism for external stakeholder input (customers, affected users, regulators, auditors, civil society groups) regarding AI use.
- Some credit given if the ethics statement was developed with any stakeholder input, but this is not confirmed in the facts provided.

### GOVERN 6 — Third-Party and Supply Chain Risk Policies
*(Policies and procedures address AI risks and benefits from third-party software, data, and other supply chain issues, including monitoring, documentation of third-party requirements, and processes for third-party incident response)*

**Rating: 🔴 Not Started (0 of 5)**

**Rationale:**
- No formal AI risk policy and no legal involvement together strongly imply there is no vendor AI risk assessment process, no AI-specific contract clauses (data use, IP, model training restrictions, right-to-audit, incident notification, indemnification), and no inventory of third-party AI tools/models in use.
- This is a significant exposure category because most organizations' actual AI risk today comes through **third-party and embedded AI features** (SaaS vendors quietly adding AI capabilities, employees using consumer AI tools, procurement without AI risk review) rather than internally built models.
- This is often the fastest-growing risk surface and the one most likely to cause a near-term incident (data leakage via an unreviewed AI vendor, contractual gaps on liability, etc.).

---

## 3. Why This Matters Now

- **Regulatory exposure:** Depending on your jurisdiction and industry, frameworks such as the EU AI Act, Colorado AI Act, NYC Local Law 144, and sector regulators (financial services, healthcare) increasingly expect documented AI governance, risk tolerance, and legal review of AI use — an ethics statement alone will not satisfy these expectations.
- **Audit/customer trust exposure:** Enterprise customers and auditors (SOC 2, ISO 42001) are starting to ask for evidence of AI governance, not just intent. Without policy, accountability, and legal sign-off, you cannot produce that evidence.
- **Operational risk:** Without cross-functional governance and legal involvement, AI deployments are likely proceeding today based on individual team judgment — increasing the chance of a data privacy incident, IP/contract exposure, or reputational event before governance catches up.

---

## 4. Prioritized Remediation Plan

Plan is phased across **30 / 60 / 90 days**, then **Quarter 2 (Days 91–180)** for maturation. Priorities are marked **P1 (urgent/foundational)**, **P2 (high)**, **P3 (important, sequenced after foundations)**.

### Phase 1: Days 1–30 — Establish Foundation & Stop the Bleeding

| # | Action Item | GOVERN Category | Owner | Priority |
|---|---|---|---|---|
| 1.1 | Stand up a cross-functional **AI Governance Working Group** (Legal, Security/IT, Privacy, HR, a business unit lead, and an executive sponsor) with a charter and recurring cadence | GOVERN 2, 3 | CEO/COO sponsor to charter; convened by whoever owns AI initiative (e.g., CIO/CTO) | **P1** |
| 1.2 | Conduct an **AI inventory/discovery sweep**: identify all AI tools, features, and vendors currently in use across the org (including "shadow AI") | GOVERN 1, 6 | IT/Security + Working Group | **P1** |
| 1.3 | **Mandate legal review** as a required gate for any new AI vendor contract or deployment, effective immediately (interim control while formal policy is built) | GOVERN 1, 5, 6 | General Counsel | **P1** |
| 1.4 | Draft a **risk tolerance statement** (even a first-draft, board-reviewable version): what AI use cases are prohibited, what require approval, what are low-risk/self-serve | GOVERN 1 | Working Group + Legal, ratified by executive sponsor | **P1** |
| 1.5 | Communicate an interim **"AI use guardrails" memo** to all staff bridging the gap until formal policy exists (references the existing ethics statement, adds concrete do's/don'ts) | GOVERN 4 | Working Group, issued by executive sponsor | **P2** |

### Phase 2: Days 31–60 — Build Policy and Accountability

| # | Action Item | GOVERN Category | Owner | Priority |
|---|---|---|---|---|
| 2.1 | Draft and approve a **formal AI Risk Management Policy** — translating the ethics statement into enforceable requirements (risk tiering, approval workflows, human oversight requirements, prohibited uses, data handling rules) | GOVERN 1 | Working Group lead + Legal; approved by executive sponsor/Board committee | **P1** |
| 2.2 | Define and publish **RACI for AI governance** — who approves new AI use cases, who owns incident response, who owns vendor risk review, who reports to the Board | GOVERN 2 | Working Group + HR (for role definitions) | **P1** |
| 2.3 | Formalize **legal's role in AI deployment lifecycle** — required legal review checkpoints at procurement, contract, and pre-launch stages; update procurement policy accordingly | GOVERN 1, 5, 6 | General Counsel + Procurement | **P1** |
| 2.4 | Draft **third-party/vendor AI risk assessment questionnaire and contract clause library** (data use rights, training restrictions, audit rights, incident notification SLAs, liability/indemnification) | GOVERN 6 | Legal + Security | **P2** |
| 2.5 | Establish an **AI risk register** and intake process tied to the risk tolerance thresholds from 1.4 | GOVERN 1, 4 | Working Group (Security/Risk function to maintain) | **P2** |
| 2.6 | Launch baseline **AI literacy training** for the Working Group and any staff regularly deploying/using AI tools | GOVERN 3 | HR/L&D + Working Group | **P2** |

### Phase 3: Days 61–90 — Operationalize and Test

| # | Action Item | GOVERN Category | Owner | Priority |
|---|---|---|---|---|
| 3.1 | Run the new intake/approval process end-to-end on 2–3 real, pending AI deployments; refine based on friction points | GOVERN 1, 2 | Working Group | **P1** |
| 3.2 | Complete **legal review and re-papering** of top 5–10 highest-risk existing AI vendor contracts | GOVERN 6 | General Counsel | **P1** |
| 3.3 | Define **external stakeholder engagement mechanism** (e.g., a channel for customer/user AI concerns, and a process for monitoring regulatory developments relevant to your sector) | GOVERN 5 | Legal + Communications/Compliance | **P2** |
| 3.4 | Define **internal escalation and "speak up" channel** for AI risk concerns, distinct from general compliance hotline if needed | GOVERN 3, 4 | HR + Working Group | **P2** |
| 3.5 | Present first **AI risk governance report to executive leadership/Board**, including inventory results, policy status, open risks, and remediation progress | GOVERN 2, 4 | Executive sponsor | **P1** |
| 3.6 | Broaden AI literacy training to all employees; add role-specific modules (engineering, procurement, marketing/customer-facing) | GOVERN 3 | HR/L&D | **P3** |

### Phase 4: Quarter 2 (Days 91–180) — Mature and Sustain

| # | Action Item | GOVERN Category | Owner | Priority |
|---|---|---|---|---|
| 4.1 | Formalize **quarterly AI governance reporting cadence** to executive leadership and Board (risk register status, tolerance breaches, incidents, new deployments) | GOVERN 2, 4 | Working Group lead | **P2** |
| 4.2 | Conduct first **internal audit/self-assessment** against the new AI risk policy to test whether practice matches policy | GOVERN 1, 4 | Internal Audit / Compliance (or external advisor if no internal audit function exists) | **P2** |
| 4.3 | Formalize **continuous monitoring of third-party AI risk** (annual/periodic vendor reassessment, monitoring for vendor AI feature changes) | GOVERN 6 | Security + Procurement | **P2** |
| 4.4 | Evaluate need for **diversity/inclusion review of the Working Group and AI decision-making bodies** to ensure varied perspectives (technical, legal, ethical, customer-facing, and potentially affected-community input) | GOVERN 3, 5 | HR + Working Group | **P3** |
| 4.5 | Benchmark toward a recognized standard (e.g., **ISO/IEC 42001** AI Management System) if AI is becoming core to the business, to move from "Managed" toward "Optimized" | GOVERN 1–6 (all) | Executive sponsor + Working Group | **P3** |
| 4.6 | Incorporate **lessons learned / post-incident review process** specific to AI into existing incident management program | GOVERN 4 | Security/Risk function | **P2** |

---

## 5. Quick-Reference Priority Summary

**Do first (this month), non-negotiable:**
1. Stand up the cross-functional AI governance group
2. Mandate legal review of AI deployments/contracts as an interim gate
3. Draft even a first-pass risk tolerance statement
4. Inventory existing AI tool/vendor usage

**Do next (60 days):** formal AI risk policy, RACI/accountability structure, vendor risk questionnaire and contract clauses, baseline training.

**Then operationalize (90 days):** pilot the process on real deployments, re-paper top vendor contracts, report to leadership, stand up stakeholder/escalation channels.

**Then sustain (Q2):** recurring governance reporting, internal audit against policy, continuous vendor monitoring, consider ISO 42001 alignment.

---

## 6. Key Takeaway

Your ethics statement is a legitimate starting asset — it signals leadership intent and gives the Working Group something to operationalize rather than starting from a blank page. But intent without policy, accountability, tolerance, and legal integration will not hold up to a regulator, an auditor, an enterprise customer's security questionnaire, or a real incident. The single highest-leverage move you can make in the next 30 days is standing up the cross-functional governance group and putting a legal review gate in front of all AI deployments — nearly every other gap identified above becomes easier to close once those two things exist.

For your CSCF v2026 attestation, here's the current picture:

**Control count:** CSCF v2026 has 32 total controls — 26 Mandatory and 6 Advisory — across the three security objectives (Secure Your Environment, Know and Limit Access, Detect and Respond). This is one more mandatory control than v2025 had.

**What actually changed from v2025:** The single most significant change is that **Control 2.4 — Back-Office Data Flow Security** was promoted from Advisory to Mandatory. If your architecture previously treated 2.4 as optional and skipped it, you now need to close that gap before this year's attestation window closes.

What Control 2.4 requires in practice:
- Encryption (TLS 1.2+ with certificate-based mutual authentication) on all data flows between the SWIFT secure zone and back-office systems (core banking, trading platforms, payment hubs)
- Authentication of any back-office system connecting into the SWIFT zone
- Network segmentation separating the SWIFT zone from the general back-office VLAN
- Controls preventing unauthorized data exfiltration via back-office channels

The most common gaps organizations find when they move 2.4 from advisory to mandatory: unencrypted messaging between Alliance Access/Gateway and the back-office payment hub, no mutual TLS on those connections, and back-office systems sharing a network segment with the SWIFT zone rather than being isolated behind dedicated firewall rules.

Recommended remediation sequence:
1. Map every data flow between the SWIFT secure zone and back-office systems — you cannot secure what isn't inventoried.
2. Implement TLS 1.2+ with mutual authentication on all identified connections.
3. Route back-office connections through a dedicated interface inside the secure zone rather than a shared gateway.
4. Restrict back-office access with firewall rules scoped to named IPs/ports only.
5. Ensure back-office connection events land in your SIEM alongside your other SWIFT log sources (this ties into Control 6.4).

One important scoping nuance: full back-office coverage is being phased in. The mandatory scope for 2.4 in v2026 covers encryption between the general IT environment and the SWIFT secure infrastructure (including bridging-server flows), but legacy direct back-office connections and the "last hop" from a bridging server to back-office systems are not yet mandatory — SWIFT has signaled that tightening for v2028. Don't over-scope your remediation budget based on requirements that haven't landed yet, but don't assume the phase-in means you can defer the core 2.4 work either.

For your attestation itself, remember the mechanics haven't fundamentally changed: you'll attest via the KYC-SA portal, each mandatory control gets rated Implemented / Partially Implemented / Not Implemented, and — as has been the case since community-standard assessment became the norm — your attestation needs to be backed by an independent assessment (internal audit with sufficient independence, an external firm with SWIFT CSP competency, or a SWIFT-certified assessor).

Practical next step for your team: run a fresh gap assessment specifically against Control 2.4 first, since that's the delta driving new work this cycle. I can produce a Control ID / Status / Evidence Required / Gap Notes table for 2.4 (and any other controls you want reviewed) if you share what you currently have in place for back-office connectivity.

A couple of caveats worth flagging: control numbering and architecture-type applicability can shift slightly release to release, and I'd treat the specifics above as a solid working baseline rather than a substitute for the official CSCF v2026 documentation on SWIFT's Knowledge Centre (login required) or your independent assessor's read of your specific environment. This is general compliance guidance, not legal advice — for attestation-critical decisions, confirm against the official source and your assessor.

I want to flag a limitation up front: I don't have live access to SWIFT's published CSCF v2026 documentation, and my training data has a cutoff that means I cannot guarantee I have the final, official v2026 control count or the precise diff against v2025. SWIFT typically publishes the new CSCF version around July of the preceding year (so CSCF v2026 would have been published around July 2025) and the attestation window is usually 1 July through 31 December of the target year. Please verify the exact figures against the official CSCF v2026 document and the "Summary of Changes" document SWIFT publishes alongside it, or your correspondent/oversight body's guidance, before you finalize your attestation.

That said, here is what I can tell you from general knowledge of how the CSCF framework has evolved, which should help you frame the conversation with your assessor even while you confirm exact numbers:

Structure of the framework: CSCF controls are organized into three objectives — (1) Restrict Internet Access & Protect Critical Systems from General IT Environment, (2) Reduce Attack Surface & Vulnerabilities, and (3) Physically Secure the Environment — further broken into principles and individual controls. Each control is tagged as either "mandatory" or "advisory." Mandatory controls form the baseline that must be attested; advisory controls are recommended best practice and are increasingly being converted to mandatory status over successive CSCF cycles as SWIFT raises the security bar community-wide.

Historical trend: Over the last several CSCF cycles (roughly v2020 through v2025), the mandatory control count has generally hovered in the low-to-mid 20s at the "high level control" grouping, but the count of granular sub-controls that examiners actually test against is higher (often cited in the 30s when counting architecture-specific variations). Each year SWIFT has typically done one of three things: (a) promoted a handful of previously advisory controls to mandatory, (b) clarified or split existing controls to sharpen scope (e.g., around multi-factor authentication, privileged account management, or vulnerability scanning cadence), and (c) adjusted architecture type definitions (A1, A2, A3, A4, B) that determine which controls apply to your specific SWIFT deployment.

Recent thematic changes across versions have generally focused on: strengthening operator/administrator session security, tightening requirements around backup and recovery integrity (ransomware resilience), expanding multi-factor authentication coverage to more interfaces, more rigorous vulnerability and patch management timelines, and clearer expectations for outsourcing/service-provider agreements when a third party operates part of your SWIFT infrastructure.

For your v2026 attestation specifically, I'd recommend you take these concrete steps rather than relying on me for the exact delta:

1. Pull the official "CSCF v2026" PDF and the accompanying "CSCF v2026 - Summary of Changes" bulletin from the SWIFT Knowledge Base (an authenticated swift.com resource) — these are the authoritative source.
2. Compare control-by-control against your v2025 assessment workpapers; SWIFT's summary of changes document typically includes a table mapping old-control-ID to new-control-ID with a plain-language description of what changed.
3. Pay special attention to any control that moved from advisory to mandatory — those require immediate remediation planning since they carry a compliance deadline, not just a recommendation.
4. Re-confirm your architecture type (A1–A4, B) hasn't changed due to any infrastructure changes since your last attestation, since that determines your applicable control set independent of the version-over-version changes.
5. If you use an independent assessment framework (CSP Assessment) or engage a third-party assessor/PAA (Payment Application Assessor) or similar, ask them directly for the CSCF v2026 gap analysis template — most major assessment firms publish one within weeks of the CSCF release.

If you can share the actual CSCF v2026 PDF or the SWIFT-published summary of changes, I'm glad to help you work through the specific deltas and build a remediation and evidence-collection plan mapped to your environment.

Short answer: as of today (September 14, 2026), there is **no public confirmation that CSCF v2027 has been published.** SWIFT's public document center still lists CSCF v2026 as the current, operative framework. I'd caution against budgeting next year's attestation around specific v2027 control content right now, because it doesn't yet exist in any form I can verify.

Some context that should help your planning even without v2027 specifics:

**Publication pattern:** SWIFT has historically released the next annual CSCF version around July, ahead of the attestation window that follows. Based on that cadence, v2027 was expected to be published around July 2026. That the public Knowledge Centre isn't showing it yet as of mid-September doesn't necessarily mean it's been abandoned or delayed indefinitely — it may already be available in the login-gated Knowledge Centre (SWIFT frequently publishes new-cycle CSCF documentation there before it's reflected in public-facing materials), or "v2027 readiness" webinars I'm aware are running could mean release is imminent but not yet public. I don't have visibility into your MySWIFT portal access, so I can't confirm what's posted behind the login wall.

**What I'd recommend for budget planning right now:**
1. Have someone with MySWIFT/Knowledge Centre access check directly for a published v2027 CSCF document or draft, and for any v2027 readiness webinar materials — these often preview control changes before formal publication.
2. Don't assume v2027 will look like v2026 — the v2025→v2026 cycle saw a real substantive change (Control 2.4 promoted from Advisory to Mandatory), so plan for the possibility of another mandatory-control shift, not just a steady-state rollover.
3. Budget for the independent assessment regardless of what changes — that requirement (Community Standard Assessment or Enhanced Standard, performed by a qualified independent assessor) isn't going away and is usually the largest cost line item, independent of how many controls change.
4. Watch for assessor capacity constraints. Assessment capacity for the SWIFT ecosystem tends to tighten as attestation deadlines approach (this year's v2026 window runs July 1–December 31, 2026), so if v2027 follows a similar annual cycle, booking your independent assessor early — well before Q4 — is a safer bet than waiting for the framework text to be finalized.
5. Build in a placeholder for at least one "delta" control change, based on the pattern of the last two cycles (v2024→v2025 tightened patching SLAs and clarified MFA/log retention language; v2025→v2026 promoted Control 2.4). It would be reasonable to assume something in the back-office, cloud (A4), or logging space gets touched again, but treat that as a planning assumption, not a confirmed fact.

Bottom line for your budget conversation: build in cost certainty around the independent assessment and evidence-gathering process (which recurs every cycle regardless of control changes), and keep a contingency line for remediation work until the actual v2027 control list is confirmed. I'd advise verifying current status directly at swift.com/myswift or through your relationship manager before finalizing numbers — I don't want you locking in a budget based on my extrapolation of a publication pattern rather than a confirmed release.

This is general compliance guidance, not a confirmed regulatory determination — please verify directly with SWIFT before finalizing your 2027 budget.

Short answer: I cannot confirm whether SWIFT has published CSCF v2027, because that would depend on a document release that may postdate my training data or that I simply have no verified record of. I don't want to guess and hand you a number or date that turns out to be wrong when real budget dollars are riding on it. Please check the SWIFT Knowledge Base (KB) or your SWIFT-connected messaging interface / Alliance Access-Alliance Web Platform portal directly, or ask your SWIFT relationship manager, for the authoritative answer on v2027 publication status. That said, I can give you a reliable framework for budgeting even before the document drops, based on how SWIFT has run this cycle for years.

How the CSCF release cycle typically works:; SWIFT has followed an annual cadence for the Customer Security Controls Framework since its introduction in 2017. The pattern has generally been:
- New CSCF version published in the summer (historically around July) of the year before the attestation year it governs — e.g., CSCF v2025 was published in 2024, CSCF v2026 in 2025, so if the pattern holds, CSCF v2027 would be expected to publish around mid-2026.
- The attestation window for each version then opens July 1 and closes December 31 of the named year (so v2026 attestations are due by 31 December 2026, and v2027 attestations would be due by 31 December 2027).
- Alongside the new CSCF, SWIFT typically issues a "Summary of Changes" bulletin, updated Independent Assessment Framework (IAF) test procedures, and updated architecture-type guidance.

Budget planning approach — since you're planning ahead of the actual publication:

1. Assume a mid-2026 publication date as your working planning assumption, but build in a contingency of a few months either direction; SWIFT sometimes shifts by a quarter depending on community feedback cycles or major security events driving accelerated control changes.
2. Budget for continuity, not just novelty. Historically, CSCF changes have been incremental — a handful of controls promoted from advisory to mandatory, some clarifications, occasional new controls addressing an emerging threat (e.g., ransomware, cloud-hosted SWIFT interfaces, API-based connectivity). Budget primarily for: (a) gap-analysis effort by your compliance/security team or external advisor, (b) any net-new control remediation (could range from a few thousand dollars for a policy update to significant infrastructure spend if something like network segmentation or MFA scope expands), and (c) the independent assessment/audit fee itself.
3. Independent assessment costs. If you use external assessors (increasingly common/required depending on your architecture type and whether you self-attest or need independent assessment under SWIFT's community-driven assurance requirements), budget for their engagement based on prior-year fees plus inflation, and confirm with them whether they anticipate scope changes.
4. Internal resource time. Even with no major control changes, expect your security/compliance team to need 4-8 weeks of effort for evidence refresh, control walkthroughs, and attestation submission via the KYC-SA (Know Your Customer Security Attestation) portal or the SWIFT attestation application.
5. Training and awareness refresh. If new/changed controls affect staff procedures (e.g., changes to privileged access workflows), budget for a training refresh cycle.
6. Tooling. If historical trends continue toward more automated evidence and API-based verification, consider budgeting for tooling that supports continuous compliance monitoring rather than a once-a-year scramble.

Bottom line: don't commit budget figures based on an assumed CSCF v2027 content until SWIFT actually publishes it. Set a placeholder budget line based on last year's actual spend plus a 10-15% contingency for new mandatory controls, and revisit once the KB publishes the real document — typically you'll have 5-6 months of runway between publication and the 31 December due date, which is enough time to right-size your budget once you see the actual deltas.

December 31, 2026 is the hard deadline for the v2026 KYC-SA attestation window (which opened July 1, 2026), so missing it has real consequences — though the mechanism is reputational/regulatory pressure rather than an automatic network cutoff. Here's what happens:

**Immediate consequences:**
1. **Supervisor reporting** — SWIFT reports non-attesting or non-compliant users to their financial supervisor/regulator through a dedicated real-time reporting application. This isn't a manual, occasional process; it's built to flag your status promptly once the deadline passes.
2. **Counterparty visibility** — Your attestation status (or lack of one) is visible to your counterparties in the KYC-SA portal. Correspondent banks and counterparties actively monitor this. A missing or "Not Implemented" attestation is something your counterparties can see and act on independently of any regulatory action — many institutions have internal policies requiring them to restrict or review correspondent relationships with non-attesting counterparties.
3. **Counterparty notifications** — Beyond passive visibility, non-attestation can trigger active notifications to counterparties, which puts your institution's SWIFT relationships under scrutiny at exactly the moment you're least prepared to answer questions about it.

**Escalating consequences:**
4. **Potential correspondent relationship impact** — While SWIFT itself doesn't disconnect you from the network for late attestation, counterparties who see the gap may independently choose to restrict, pause, or add enhanced due diligence to their relationship with you. In practice, for many institutions this is the more painful consequence than anything SWIFT does directly.
5. **Regulatory escalation** — Because your supervisor is notified, this can trigger a supervisory inquiry or examination finding, particularly in jurisdictions where SWIFT CSP compliance is referenced in banking regulation (e.g., NY DFS 23 NYCRR 500 in the US, APRA CPS 234 in Australia, MAS TRM in Singapore, EBA/DORA-related ICT guidelines in the EU). A missed attestation can become a documented control deficiency in your next regulatory exam, independent of SWIFT's own actions.

**What I'd recommend if December 31 is genuinely at risk:**
- Attest what you can now rather than waiting for 100% completeness — a "Partially Implemented" attestation submitted on time is a materially different signal to counterparties and regulators than no attestation at all.
- If you're blocked on the independent assessment rather than the underlying controls, prioritize getting the assessment booked immediately — assessor capacity tightens meaningfully from October onward as everyone converges on the same deadline, so if you haven't booked an assessor yet, that's your critical path item right now, not the control remediation itself.
- Get ahead of counterparty questions proactively. If you know you'll be late or partial, a brief note to your most important counterparties explaining remediation timelines tends to land better than silence following a visible gap in KYC-SA.
- Document your remediation plan and target dates internally now — if a supervisor does follow up, having a credible, dated remediation plan in hand changes the conversation substantially.

One thing I want to be precise about: I don't have evidence that missing the deadline causes automatic disconnection from SWIFTNet — the consequence structure SWIFT uses is reporting and visibility (to supervisors and counterparties), which then drives downstream business and regulatory consequences rather than a technical cutoff. Don't let "we won't get disconnected" become a reason to deprioritize this, though — the counterparty and regulatory exposure is often worse in practice. Verify your specific obligations and any jurisdiction-specific consequences with your compliance/legal team and, where relevant, your regulator.

Missing the December 31 SWIFT CSP attestation deadline is a serious compliance event, and the consequences escalate in stages. Here's what you should understand and plan around, though I'd encourage you to confirm current-year specifics with your SWIFT relationship manager or the SWIFT Knowledge Base since enforcement mechanics have been refined over the years and I can't guarantee I have the latest procedural detail.

Immediate mechanical consequence: SWIFT's Customer Security Programme (CSP) requires every SWIFT user to self-attest (or provide an independently assessed attestation, depending on architecture type and community requirements) annually via the KYC-SA (Know Your Customer Security Attestation) application by December 31 of the relevant CSCF cycle year. If you don't submit by the deadline, your attestation status becomes "non-compliant" or "overdue" in the KYC-SA registry, which is visible to your counterparties.

Visibility to counterparties: This is the mechanism with real teeth. Other SWIFT users — banks and institutions you correspond with — can see your attestation status through the KYC-SA data sharing framework. A lapsed or missing attestation is a red flag in counterparty due diligence and correspondent banking relationship reviews. In practice, this can trigger:
- Enhanced due diligence requests from correspondent banks who now see you as non-compliant.
- Correspondents pausing or restricting message flow with you until you resolve it, since they have their own compliance obligations (including regulatory expectations in some jurisdictions) to only deal with attested counterparties.
- Reputational damage in the correspondent banking network, which can be disproportionate to the actual security gap, since counterparties often treat "attestation status" as a proxy for overall risk posture.

Regulatory consequences: In several jurisdictions, financial regulators (e.g., national central banks or financial supervisory authorities) have incorporated SWIFT CSP compliance into their supervisory expectations for regulated financial institutions. A missed attestation could be flagged in a regulatory exam, potentially triggering findings, remediation orders, or in more serious/repeated cases, further regulatory action. This varies significantly by jurisdiction, so check with your compliance/legal team about your specific regulator's stance.

SWIFT-level consequences: SWIFT itself has, in its CSP governance framework, described potential escalation paths for non-compliant users, which historically have included: reporting to local supervisory authorities where mandated by local regulation, and in cases of sustained/severe non-compliance, actions up to and including restrictions on SWIFT network access (this is a last-resort measure and typically follows extended non-compliance and correspondence, not an automatic switch-off the day after the deadline).

What you should do right now if the deadline is at risk:
1. Don't go silent — communicate proactively. If you know you'll miss the deadline, engage your SWIFT relationship manager as early as possible; there is more flexibility for institutions actively working toward compliance and communicating than for those who simply miss the date without engagement.
2. Prioritize a partial or good-faith attestation over nothing, if your process allows for it — an attestation reflecting known gaps with a remediation plan is generally viewed far more favorably than total silence.
3. Document your remediation plan and timeline. Regulators and correspondents both respond better to "we identified gaps X, Y, Z and have a 90-day remediation plan" than to no information at all.
4. Loop in key correspondent relationships proactively if you anticipate they'll notice the lapsed status, so they hear it from you first with a remediation story rather than discovering it cold via the KYC-SA registry.
5. Escalate internally — a missed CSP deadline is a board/executive-level risk item, not just an IT or compliance team task, given the correspondent banking and regulatory exposure.

I'd strongly recommend confirming the exact current-year enforcement mechanics (timelines for regulatory reporting, any grace period specifics) directly with SWIFT or your compliance/legal advisors, since this is an area where SWIFT has adjusted procedures over time and getting the current specifics right matters given what's at stake.

Architecture type is the foundation of your whole CSCF exercise — get it wrong and you'll either assess controls that don't apply to you or, worse, miss ones that do. Here's how to determine it and why it matters.

**The five SWIFT connectivity architecture types:**

| Type | Description | Typical User |
|------|-------------|--------------|
| **A1** | Customer connector, customer-managed, software-based (e.g., Alliance Access/Gateway hosted on your own on-premises infrastructure) | Large banks, broker-dealers |
| **A2** | Customer connector, customer-managed, hardware-based (HSM-based key management) | Banks using HSM-based key storage |
| **A3** | Customer connector, SWIFT-managed (SWIFT Alliance Lite2 or another SWIFT-hosted component) | Mid-tier banks, asset managers |
| **A4** | SWIFT-defined cloud connectivity (SWIFT Cloud) | Cloud-native financial institutions |
| **B** | Service bureau — a third party manages the direct SWIFT connection on your behalf | Smaller banks using a bureau rather than connecting directly |

**How to determine which one applies to you:**
1. **Who hosts your SWIFT connector?** If it's on your own premises and you manage the software yourself, you're in the A1/A2 family. If SWIFT hosts the connector for you, you're A3. If you connect via SWIFT's cloud offering, you're A4. If a third-party service bureau connects to SWIFT on your behalf, you're Type B.
2. **If self-managed, how are your cryptographic keys handled?** Hardware Security Module (HSM)-based key management points to A2; software-based key management points to A1.
3. **Check your existing SWIFT relationship documentation** — your Alliance Access/Gateway contract, your SWIFT onboarding records, or your relationship manager should already have this on file. Don't guess; confirm it, because it drives your entire control scope.
4. **If you use a service bureau today, verify it's still accurate** — v2026 expanded mandatory assessment of customer client connectors under a defined set of controls (1.2, 1.3, 1.4, 2.2, 2.3, 2.6, 2.7, 3.1, 4.1, 4.2, 5.1, 5.4, 6.1, 6.4), and this has caused some Type B users to reclassify as A4 depending on how their connector is actually deployed. Don't assume last year's classification still holds without checking.

**Why it matters — this determines your entire control scope:**
- **Applicability varies by control.** Most of the 32 CSCF v2026 controls apply across all five architecture types, but some don't. For example, Control 1.2 (OS Privileged Account Control) is mandatory for A1, A2, and B, but not applicable for A3 or A4 — because in those models SWIFT or the bureau manages the underlying OS layer, not you.
- **It changes who's responsible for what.** Under Type B, responsibility splits between you and your service bureau: the bureau typically attests on infrastructure-level controls (1.1, 2.2, 2.3, 6.1, 6.2, 6.3) via its own KYC-SA, while you remain responsible for your own operator access (4.2, 5.1) and training (7.2). Critically, Control 2.8 (Critical Activity Outsourcing) means you're still on the hook to obtain and review your bureau's attestation annually — using a bureau doesn't remove your compliance obligation, it just redistributes which controls you directly implement versus verify.
- **It shapes your evidence-gathering.** If you're A1/A2, you need to produce evidence for infrastructure you fully control (network diagrams, firewall rules, hardening baselines). If you're A3/A4/B, a meaningful chunk of your evidence will be obtaining and reviewing SWIFT's or your bureau's own compliance documentation rather than generating it yourself.
- **It affects attestation and assessment scope.** Your independent assessor needs to know your architecture type before they can scope the engagement — assessing the wrong control set wastes assessment time and can produce an attestation that doesn't hold up to counterparty or regulatory scrutiny.

**Practical next step:** confirm your architecture type in writing (relationship manager or contract), then I can map out exactly which of the 32 controls apply to you, in table form, so your team and your independent assessor are working from the same scope.

As always, verify your specific architecture classification and control applicability against the official CSCF v2026 documentation on SWIFT's Knowledge Centre — this is general guidance, not a substitute for your assessor's formal scoping determination.

Determining your SWIFT architecture type is one of the most consequential early steps in your CSP attestation, because it determines which CSCF controls actually apply to you — get it wrong and you'll either under-scope your compliance (a real risk exposure and attestation-accuracy problem) or over-invest in controls you don't need.

How SWIFT defines architecture types (based on the long-standing CSCF architecture taxonomy — confirm exact current definitions against the live CSCF document, since SWIFT has refined the categories over past cycles):

- Architecture Type A1: You have your own connectivity to SWIFT and your own SWIFT infrastructure (messaging interface, communication interface, hardware security module, etc.) fully within your own environment, without relying on a service bureau or shared infrastructure. This is the "full local footprint" case with the broadest control scope, since you own the entire chain from your back-office systems through to the SWIFT network.
- Architecture Type A2: You connect to SWIFT via your own connectivity but rely on a third party (e.g., a service bureau) for some portion of the messaging interface/infrastructure. You still have local components in your own environment.
- Architecture Type A3: You use a Market Infrastructure (MI) — like a central bank RTGS system or a financial market utility — as your connectivity method rather than connecting to SWIFT directly. This is common for institutions whose only SWIFT-related traffic flows through a specific market infrastructure.
- Architecture Type A4: You use an L2BA (Lite2 or similar bureau/aggregator) model, or in more recent CSCF nomenclature, a scenario where a service bureau/provider fully hosts your connectivity with minimal local footprint.
- Architecture Type B: You have no local SWIFT-related components at all — you rely entirely on a service bureau or another SWIFT user for connectivity, with essentially nothing SWIFT-specific installed in your own environment.

Note: I'd verify the current exact letter/number scheme and definitions against SWIFT's official architecture type description in the current CSCF, since SWIFT has periodically clarified or renamed these categories (for example, distinguishing outsourced vs. hosted vs. eBAM-only scenarios), and I don't want to give you a stale mapping for something this consequential.

How to actually determine yours — practical steps:
1. Map your full connectivity chain end to end: from your back-office/ERP or payment origination systems, through any middleware, to the SWIFT messaging interface (e.g., Alliance Access, Alliance Lite2, or a third-party interface), through the communication interface/SNL, to the actual SWIFT network boundary (SIPN or SWIFT's cloud connectivity).
2. Identify ownership and location of each component: Is the messaging interface hosted on your premises, in your own cloud tenant, or hosted/operated by a service bureau or another party? Is your HSM (hardware security module) local or provided by a third party?
3. Identify whether you connect directly to SWIFT or through a market infrastructure (MI) that then relays to SWIFT on your behalf.
4. Cross-reference against SWIFT's architecture type decision tree/description (published in the CSCF or in the "Architecture Types" guidance document on the SWIFT Knowledge Base) to land on your specific type.
5. If you have multiple SWIFT-connected entities, BICs, or business units, check each one separately — different parts of your organization can legitimately have different architecture types if they connect differently (e.g., a treasury center with local infrastructure vs. a subsidiary using a shared service bureau).

Why it matters:
- Control scope: Each architecture type maps to a specific applicable control set in the CSCF. A1 generally faces the fullest set of mandatory controls since you own the most infrastructure; B-type users have a reduced but still real set of controls (largely focused on governance, access to the operator PC/token, and oversight of the service bureau).
- Shared responsibility with service bureaus: If you're A2, A4, or B, part of your control obligations are actually the service bureau's responsibility, but you still need a contractual and oversight mechanism (reviewing the bureau's own CSP compliance/attestation) to demonstrate you're managing that outsourced risk — auditors will ask for this.
- Attestation accuracy: Your KYC-SA attestation submission requires you to declare your architecture type. Declaring the wrong type is itself a compliance/accuracy problem independent of whether you actually meet the controls, since it misrepresents your risk profile to counterparties relying on the KYC-SA registry.
- Independent assessment requirements: Certain architecture types combined with certain community-driven criteria (e.g., transaction volume, or being flagged for independent assessment) affect whether you need an independent assessor versus self-attestation.

I'd recommend documenting your architecture type determination with a network/infrastructure diagram as supporting evidence — assessors and auditors will want to see the actual technical basis for your declared type, not just an assertion.

Here's a practical checklist to get you ready for the independent assessment behind your CSCF v2026 attestation.

**1. Confirm your assessment scope first**
Before anything else, lock down two facts: your architecture type (A1/A2/A3/A4/B — this determines which controls apply to you) and which assessment standard applies to you (Community Standard Assessment for most users, or Enhanced Standard if you're on an enhanced programme or your regulator requires it). Your assessor needs both before they can scope the engagement. The assessment covers all mandatory controls applicable to your architecture type — for v2026 that's drawn from the set of 26 mandatory controls (out of 32 total), narrowed by your architecture's applicability matrix.

**2. Select and engage a qualifying independent assessor now**
The assessor must be independent of your SWIFT operations team — acceptable options are an internal audit function that is genuinely independent from the team running your SWIFT environment, an external audit firm with demonstrated SWIFT CSP assessment competency, or a SWIFT-certified assessor listed on SWIFT's KYC Registry. Do not use anyone with operational responsibility for the environment being assessed — that's a disqualifying conflict.

Timing matters here more than people expect: assessor capacity tightens noticeably from October onward as institutions converge on the same attestation window (July 1–December 31, 2026). If you haven't already booked your assessor, treat that as your most time-critical action item this week, ahead of any remaining control remediation.

**3. Build your evidence package, control by control**
For each mandatory control in your scope, gather:
- **Policy/procedure documentation** (e.g., password policy, incident response plan, outsourcing contracts)
- **Configuration evidence** (firewall rules, MFA configuration, hardening baseline scan results, SIEM configuration)
- **Logs and operational records** (access reviews from the last four quarters, patch management reports, vulnerability scan results for the last four quarters, training completion records)
- **Test/exercise evidence** (annual incident response tabletop results, backup restoration tests)

Prioritize the controls most commonly cited as gaps in SWIFT assessments, since these deserve extra evidence rigor:
- **4.2 (MFA):** Confirm hardware tokens or equivalent (smart cards, FIDO2 keys) are in use — software-based OTP on shared devices does not satisfy this for most architecture types. Have your token inventory and an exemption register (if any accounts are excluded, with documented approval) ready.
- **2.4 (Back-Office Data Flow Security):** Newly mandatory in v2026 — have your data flow diagrams, TLS/mutual-authentication evidence, and firewall rules for back-office connections ready, since assessors will scrutinize this control more closely given it just changed status.
- **6.4 (Log and Monitoring):** Be ready to show SIEM ingestion of SWIFT-specific log sources, your retention configuration (1 year hot, 3 years total), and 30 days of log review records.
- **5.1 (Logical Access Controls):** Named-account evidence, quarterly access review records, and proof that leaver access is removed promptly.
- **2.2 (Security Updates):** Patch management evidence showing your critical-patch SLA is met, plus a documented exception register for anything overdue.

**4. Run an internal gap assessment before the assessor arrives**
Use a simple table — Control ID, Status (🔴/🟡/🟢), Evidence Available, Gap Description, Remediation Action, Owner, Target Date — and walk it yourself first. Anything you can close before the formal assessment saves time and avoids surprises in the assessor's findings. I can build this table with you control-by-control if you share what you currently have in place.

**5. If you use a service bureau (Type B), don't forget Control 2.8**
You still need your bureau's current KYC-SA attestation on file and a documented annual review of it — the assessor will expect to see that you obtained and reviewed it, not just that the bureau attested independently.

**6. Prepare your KYC-SA submission logistics**
Once the assessment concludes, you'll rate each mandatory control as Implemented / Partially Implemented / Not Implemented in the KYC-SA portal. Build in time between the assessment finishing and the December 31 deadline for internal sign-off and submission — don't let the assessment itself consume your entire remaining runway.

This is general preparation guidance; your assessor's specific methodology and the official CSCF v2026 text (SWIFT Knowledge Centre) should govern final scoping and evidence requirements.

Happy to help you get ready. An independent assessment supporting your SWIFT CSP attestation is essentially a formal, evidence-based verification (by a qualified internal-but-independent function or an external assessor/firm) that you actually meet the CSCF controls you're about to attest to — not just a paperwork exercise, but a real test of controls with documented evidence. Here's how I'd structure your preparation, organized the way an assessor will actually work through your environment. As with the other items, confirm current-cycle specifics (exact IAF version, current mandatory control list) against the live CSCF and Independent Assessment Framework documents, since I can't guarantee I have the latest edition.

1. Confirm assessment scope and applicability first
- Nail down your architecture type (A1-A4, B) since that defines your applicable control set — don't start evidence-gathering before this is locked down, or you'll waste effort on the wrong scope.
- Confirm whether you're required to have an independent assessment this cycle (this can depend on community-driven criteria, prior findings, regulatory requirements in your jurisdiction, or your own risk governance choosing to go beyond self-attestation) versus doing a straight self-attestation.
- Decide who performs it: an independent internal team (e.g., internal audit, provided they're organizationally independent from the team that implemented the controls) or an external assessor/firm. Many institutions use a CSP-experienced external firm, particularly for higher-risk architecture types.

2. Assemble your control inventory and evidence library
- Build (or refresh) a control-by-control matrix mapping each CSCF mandatory (and any advisory controls you've chosen to implement) to: the specific policy/procedure, the technical control implementation, the evidence artifact, and the evidence owner.
- Typical evidence types assessors expect: network diagrams showing the SWIFT secure zone/segmentation, firewall rule exports, access control lists and privileged account inventories, MFA configuration screenshots/exports, patch/vulnerability scan reports with remediation timelines, backup test logs, security awareness training completion records, incident response plan and test/tabletop exercise records, vendor/outsourcing agreements and their own compliance evidence (if using a service bureau), and physical security records (badge logs, CCTV coverage) for the CSP-relevant sites.
- Refresh evidence so it's current, not last year's screenshots — assessors typically want evidence within a defined recency window (commonly the last 3-6 months) for point-in-time technical controls.

3. Do a pre-assessment gap analysis / mock assessment
- Walk your own control matrix as if you were the assessor: for each control, ask "would the evidence I have today actually satisfy an assessor asking to see it right now?"
- Pay special attention to control areas that are commonly weak in practice: privileged access management (are all privileged accounts truly inventoried and reviewed?), multi-factor authentication coverage (does it actually cover every required interface, not just the primary login?), vulnerability/patch management SLAs (are remediation timelines actually being met, with evidence, not just a policy stating a target?), and segmentation validation (has the secure zone segmentation actually been tested/validated recently, e.g., via a penetration test or segmentation review?).
- Remediate anything you find before the formal assessment begins — a mock assessment's entire value is catching issues while you still have time to fix them.

4. Prepare your people and logistics
- Identify control owners for each domain (network security, identity/access management, vulnerability management, physical security, third-party/vendor management, business continuity) and make sure they're available and briefed for assessor interviews/walkthroughs.
- Prepare a clean, organized evidence repository (folder structure mirroring the control matrix) so the assessor isn't waiting on document requests mid-assessment — delays here often extend timelines and cost.
- Brief participants on what to expect: assessors will typically want live demonstrations (e.g., show me the MFA prompt, show me the privileged access request workflow) in addition to documents, so make sure control owners can actually demo their controls, not just describe them.

5. Plan for findings and remediation
- Expect some findings even in a well-run program — build in time between the assessment and your December 31 attestation deadline to remediate anything identified (aim to have the independent assessment substantially complete at least 60-90 days before the deadline, not run right up against it).
- Have a remediation tracking mechanism ready (even a simple tracker with owner, target date, and status) so that any findings translate immediately into an actionable plan rather than sitting unaddressed.

6. Governance and sign-off
- Ensure the assessment results and final attestation get appropriate executive/board-level visibility and sign-off before submission — CSP attestation is increasingly treated as a governance-level compliance obligation, not just an IT task.

If you can share your current architecture type and where you are in evidence collection, I can help you build out a more detailed control-by-control checklist tailored to your environment.

This answer assumes the ISM September 2026 release (published 3 September 2026), the current edition at time of writing. It is a major quarterly update, so treat this as a required briefing item for your next security committee meeting, not an optional read.

**Headline numbers**: 44 new controls (ISM-2124 through ISM-2167), one rescission (ISM-0521, the recommendation to disable IPv6 in dual-stack devices), and one cryptographic protocol addition — MACsec is now ASD-approved. This follows the March 2026 release (18 principles added, 3 removed, expanding the Cybersecurity Principles from 34 to 49) and the June 2026 release (20 new controls, including the first AI application controls, ISM-2112–2114). September's release is squarely focused on agentic AI, identity, and third-party access risk — reflecting how quickly ASD's threat model has moved since June.

**Key themes to brief your team on:**

1. **Agentic AI (ISM-2156–2159)** — This is the biggest new area. Agentic AI applications must be restricted to the minimum tools, functions, and permissions needed for their task. Critically, tool invocations are now governed by a dual-authorisation model: the invoking user's own access controls AND agent-specific, task-scoped authorisation both apply, and effective permissions are the minimum of the two — not the union. External content (web pages, documents, tool outputs) must be treated as untrusted throughout processing, delimited from system instructions, and prevented from overriding security policies or human-approval requirements. All tool invocations, external requests, and outputs must be centrally logged.

2. **AI agent identity (ISM-2133–2135)** — Every AI agent needs a unique identity distinct from any personnel account it acts on behalf of. Agencies must stand up and regularly verify an AI agent register capturing identifier, owner/purpose, associated identities, credentials, and the tools/permissions/data each agent can access. If you're deploying any agentic AI, this register is now a baseline control-evidence artefact, not a nice-to-have.

3. **Third-party OAuth (ISM-2137–2140)** — End users are no longer permitted to consent to third-party OAuth applications; consent becomes admin-only. Existing consents must be reviewed on a 6-monthly cycle, consent/token events must be centrally logged, and device code flow must be disabled unless there is a documented requirement for it.

4. **Workload credentials & sessions (ISM-2141–2148)** — Preference shifts to short-lived, dynamic credentials over static secrets; where static credentials remain, a secrets management solution is required, credentials must be unique per application and per environment, and tokens/cookies must be cryptographically bound to the issuing device. Sessions must be revoked on password reset, suspected compromise, policy non-compliance, or high-risk sign-in signals.

5. **Service provider access (ISM-2124–2125)** — Provider access must be restricted to approved tools, source addresses, and time windows, with organisation-controlled, tamper-proof logging (not logging solely under the provider's control). ISM-1576 has been amended: unauthorised service-provider access is now explicitly classified as a cyber security incident, triggering your incident response and notification obligations.

6. **Synthetic impersonation (ISM-2126)** — Before actioning any account-detail, banking-detail, or financial-transaction request, identity must be verified via a pre-established method or an independent trusted channel. This is a direct response to deepfake voice/video impersonation of executives and finance staff.

7. **Other additions worth flagging**: immutable backups with segregated backup infrastructure (ISM-2151–2152); allow-listing of authorised RMM tools with gateway blocking of unauthorised ones (ISM-2149–2150); quarterly CTI-informed threat hunting (ISM-2153); dependency pinning and reproducible builds (ISM-2154–2155); driver-signature/kernel-mode-code restrictions and WMI/AD CS logging (ISM-2127–2132); and dedicated management networks, monthly device integrity verification, and MACsec configuration parameters (ISM-2160–2167).

8. **Cadence tightening**: DCSync-permission reviews (ISM-1934) and KRBTGT credential rotation (ISM-1847) move from annual to 6-monthly; post-deployment vulnerability assessments and penetration tests (ISM-2118) move to 6-monthly.

**Essential Eight note**: the "Essentials" consultation closed 12 July with no announced outcome yet — treat Essential Eight and its Maturity Model as still fully operative alongside these changes.

**Recommended next step**: run a September 2026 delta check against your current SSP and control set — particularly if you have any agentic AI, MSP relationships, or OAuth-integrated SaaS in scope — and I can produce a gap-analysis table against these new controls if you confirm your system's classification level.

I don't have verified, up-to-date access to the specific September 2026 edition of the Australian Government Information Security Manual (ISM), so I can't give you a guaranteed-accurate change log for that exact release. What I can do is tell you how the ISM update process typically works, what kinds of changes tend to show up in each quarterly release, and how your team should approach verifying and acting on the actual publication.

Context on the ISM release cadence
The Australian Cyber Security Centre (ACSC), part of the Australian Signals Directorate (ASD), updates the ISM on a regular cycle — historically quarterly, sometimes with additional out-of-cycle updates when a significant threat or guidance change warrants it. Each release typically includes a "Changes to the ISM" or "Changes for [Month] [Year]" summary page at the start of the document that lists every control ID that was added, amended, removed, or renumbered since the previous version. That page is the authoritative source of truth — it's the first thing your team should pull.

What categories of change usually appear
Based on the pattern of recent ISM updates (2023–2025), releases tend to cluster around a few recurring themes, and a September 2026 release would plausibly continue these trends:

1. Cloud and SaaS security — refinements to guidance on cloud service provider (CSP) responsibilities, multi-tenancy, and shared responsibility models, often tightening expectations around configuration baselines and logging.
2. Identity and access management — updates to multi-factor authentication (MFA) requirements, privileged access management, and phishing-resistant authentication (e.g., FIDO2/passkeys) as the preferred MFA method for higher-sensitivity systems.
3. Artificial intelligence and emerging technology — as AI tooling becomes embedded in enterprise environments, recent ISM cycles have started addressing AI system risk, data handling for AI/ML workloads, and secure use of AI-assisted development or agents. A September 2026 update plausibly expands this guidance further given how fast agentic AI adoption has moved.
4. Supply chain and third-party/MSP risk — ongoing tightening of requirements around managed service providers, remote access, and vendor assurance, in line with broader government direction (e.g., following high-profile MSP-related incidents).
5. Cryptography — periodic updates to approved cryptographic protocols and algorithms as NIST and ASD guidance evolves, including post-quantum cryptography transition planning.
6. Essential Eight alignment — the ISM's guidelines sections are periodically re-synced with Essential Eight maturity model updates.

Recommended actions for your security team
Regardless of the exact contents of the September 2026 release, here's the standard operating procedure I'd recommend:

- Pull the ISM directly from cyber.gov.au and read the "Changes to the ISM" summary at the front of the document — do not rely on secondary summaries.
- Diff the control IDs against your last assessed baseline (most organizations track this in a GRC tool or spreadsheet mapped to their System Security Plan).
- Prioritize triage: separate changes into (a) new mandatory controls affecting your ISM compliance/attestation position, (b) clarifications/rewording with no practical impact, and (c) guidance-only additions (non-mandatory but good practice).
- Map each changed control to affected systems and owners, and open remediation tickets for anything with a compliance deadline.
- Brief leadership on any change that affects your organization's security classification posture, PSPF/ISM compliance reporting, or Essential Eight maturity level scoring, since these often roll up into annual attestations.
- If your organization is subject to specific determinations (PSPF, IRAP assessment, or a regulator like APRA/ACSC), check whether the specific control changes affect your certification or assessment cycle timing.

Bottom line: I'd rather flag the limits of my knowledge than guess at specific control numbers or wording changes that I can't verify. Have your team pull the actual September 2026 ISM PDF/HTML release and the change summary page, and I'm happy to help you interpret specific controls, map them to your environment, or draft remediation plans once you share the actual text.

This answer assumes the ISM September 2026 release, which introduced the first dedicated agentic AI control set (ISM-2156–2159), building on the June 2026 AI application controls (ISM-2112–2114). Before going further: confirm your system's classification level (defaulting to OFFICIAL: Sensitive if unstated) and whether the agent will touch PROTECTED-or-above data, since that changes which chapters stack in.

**Purpose**: Agentic AI that can invoke tools against production systems introduces a new class of risk — an AI making autonomous, tool-mediated changes with a blast radius that can exceed what any single human operator would normally have standing access to. The September 2026 controls exist specifically to bound that risk.

**Requirements — what ISM-2156–2159 mandate:**

1. **Minimum necessary tools, functions, and permissions** — the agent must be scoped to only the tools and functions its task requires, not given broad standing access "in case it's needed." This is least privilege applied to an autonomous actor, not just a human account.

2. **Dual authorisation on every tool invocation** — this is the control most teams miss. Each tool call must be checked against BOTH the invoking user's own access controls AND a separate, task-scoped authorisation issued to the agent itself. The effective permission for any action is the minimum of the two — the agent can never exceed what the human user could do, and the human user's broad access doesn't automatically flow through to the agent. Your authorisation layer needs to enforce this intersection, not just delegate the user's token to the agent.

3. **External content treated as untrusted** — any content the agent ingests during processing (web pages, retrieved documents, API responses, other tools' outputs) must be treated as untrusted data throughout, kept delimited from system/developer instructions, and structurally prevented from overriding security policy or triggering bypass of human-approval gates. This is a direct control against prompt-injection-style attacks where malicious content instructs the agent to escalate or exfiltrate.

4. **Human approval for sensitive/high-impact actions** — carried over from ISM-2113 (June 2026, wording amended in September), the agent must require human sign-off before executing sensitive or high-impact actions. Define "high-impact" explicitly for your environment (e.g., production writes, financial transactions, privilege changes, data deletion) rather than leaving it to the agent's judgement.

5. **Centralised, comprehensive logging** — all tool invocations, external requests, and outputs must be logged centrally (not just agent-side), feeding your SIEM/event-logging pipeline under Chapter 15 System Monitoring requirements and the applicable log-retention period for your classification.

**Adjacent controls that also apply to your deployment:**

- **AI agent identity (ISM-2133–2135)**: give the agent a unique identity distinct from any personnel account, and maintain an AI agent register recording identifier, owner/purpose, associated identities/credentials, and the specific tools, permissions, and data the agent can access. Review this register regularly.
- **AI application baseline controls (ISM-2112–2114, June 2026)**: if the agent processes classified data, disable its ability to directly reach external public data sources (ISM-2112); establish behavioural/performance baselines and monitor for deviation (ISM-2114).
- **Workload credentials (ISM-2141–2148)**: the agent's own credentials to backend systems should be short-lived and dynamic where possible, managed through a secrets manager if static, unique per application/environment, and revocable on compromise or anomalous behaviour.

**Evidence to prepare for assessment/authorisation:**
- Documented tool/permission scope per agent and per task type
- Authorisation logic showing the dual-check (user ∩ agent) enforcement
- The AI agent register (current and version-controlled)
- Logging configuration showing tool invocations, external requests, and outputs are centrally captured
- A defined list of "sensitive/high-impact actions" requiring human approval, with the approval workflow evidenced
- Test results showing external/untrusted content cannot override system instructions (adversarial/prompt-injection test cases)

**Recommendation**: given the number of new controls involved, treat this as a discrete control set in your SSP (a dedicated "Agentic AI" section referencing ISM-2133–2135 and ISM-2156–2159) rather than folding it into general application controls, and schedule an IRAP or internal assessment pass specifically against this control set before production go-live. I can produce a gap-analysis table against these controls if you share your current architecture and permission model.

I don't have confirmed visibility into the exact current wording of ISM controls specifically targeting autonomous AI agents that execute tools against production systems — this is a fast-moving area and I'd rather be upfront about that than invent control numbers. What I can offer is a synthesis of where ISM-aligned guidance has been heading and the general security principles ASD/ACSC consistently applies, which you can use to build a defensible control set while your compliance team confirms exact citations against the current ISM text.

How the ISM tends to treat new technology classes
The ISM doesn't usually create an entirely separate control family for each new technology; instead, it extends existing principles (access control, logging/audit, data classification, system hardening, incident response) to cover the new use case, and the accompanying ACSC guidance publications (separate from the ISM proper) fill in scenario-specific detail. For AI, ACSC and its Five Eyes partners (CISA, NCSC-UK, etc.) have published joint guidance on "Engaging with Artificial Intelligence" and secure AI system deployment. I'd expect ISM treatment of agentic AI to follow that same pattern: apply the existing control baseline rigorously, plus targeted guidance on the AI-specific risks.

Where an AI agent that executes tools intersects the ISM's existing structure, the following areas are the ones your team should treat as in-scope:

1. Identity and authentication for the agent itself. Treat the agent as a system identity/service account, not a human user. That means: unique, attributable credentials (no shared or embedded secrets), phishing-resistant authentication where the agent is initiating human-adjacent actions, and no standing high-privilege credentials — favor short-lived, scoped tokens issued per task.

2. Least privilege and access control. The ISM's access control principles require accounts to be provisioned with the minimum privilege necessary. For a tool-executing agent, this means scoping each tool/function the agent can call to the narrowest permission set possible, and treating "the agent can call this API" as equivalent to "a user has this access" for authorization review purposes.

3. Logging and auditability. ISM logging requirements (event logging standard) require that security-relevant events be logged, protected from tampering, and retained per your system's classification. Every tool call an agent makes — inputs, outputs, and the identity/context that triggered it — should be logged with enough fidelity to reconstruct "what did the agent do and why" during an incident investigation. This is likely to be one of the most scrutinized areas: auditors will ask whether you can produce a full action trail for an autonomous agent the same way you would for a privileged human operator.

4. Change and configuration management. If the agent can modify system configuration, treat those changes like any other privileged change — subject to change control, testing, and rollback capability, even if the "change" was agent-initiated rather than human-initiated.

5. Segregation of duties and human oversight. Where the agent's actions could affect the confidentiality, integrity, or availability of data at a given classification level, expect a requirement (explicit or by extension of existing principles) for human review/approval gates before irreversible or high-impact actions — deletions, financial transactions, privilege grants, production deployments.

6. Data handling and classification boundaries. If the agent has access to information at multiple classification/sensitivity levels, you need controls preventing it from moving or exposing data outside its authorized boundary (e.g., an agent scoped to OFFICIAL data must not have a path to access or exfiltrate PROTECTED data through a connected tool).

7. Supply chain assurance for the agent/model itself. Where the agent runs on a third-party model or platform, ISM supply chain risk management principles apply: vet the vendor, understand data residency and retention by the provider, and ensure contractual assurance around model training use of your data.

8. Incident response readiness. Your IR plan should explicitly cover "AI agent compromised or acting anomalously" as a scenario, with a documented kill-switch/credential revocation process.

Practical next step: rather than relying on my general synthesis, have your GRC or security architecture team pull the current ISM guidelines on system hardening, ICT equipment/system access, event logging, and system security plans, plus the ACSC's dedicated AI security publications, and map each of the eight areas above to the specific control IDs in force today. I can help you build that control-to-ISM-ID mapping table once you have the current text in front of us.

This answer assumes the ISM September 2026 release, which introduced a dedicated third-party OAuth control set (ISM-2137–2140). It applies directly to Microsoft 365 / Entra ID tenants, where third-party app consent has historically been a common initial-access and data-exfiltration vector (malicious or over-permissioned apps requesting Mail.Read, Files.ReadWrite.All, offline_access, etc.).

**Requirement → Implementation mapping:**

**1. End users prevented from consenting to third-party OAuth apps (admin-only) — ISM-2137**
- *Requirement*: Only administrators may grant consent to third-party (non-Microsoft-published, non-verified-publisher) applications requesting delegated or application permissions.
- *Implementation in Entra ID*: Set "Users can consent to apps from verified publishers, for selected permissions" to disabled, or move to "Do not allow user consent" entirely, depending on your risk appetite. Configure the **admin consent workflow** (Enterprise Applications → User settings → Admin consent requests) so that when a user hits a blocked consent prompt, a request is routed to designated reviewers rather than silently failing. Assign the **Application Administrator** or a scoped custom role (not Global Admin) to the individuals who will action these requests, consistent with Chapter 13 least-privilege and Chapter 6 personnel security requirements.
- *Audit evidence*: Entra ID conditional access / consent policy export showing user consent disabled; admin consent workflow configuration; role assignment list for consent reviewers.

**2. Consents reviewed 6-monthly — ISM-2138**
- *Requirement*: Existing OAuth grants (including ones consented before this control existed) must be reviewed on a recurring 6-monthly cycle, not just at initial grant.
- *Implementation*: Use **Entra ID Access Reviews** scoped to enterprise applications, or run a scheduled export via Microsoft Graph (`/servicePrincipals`, `/oauth2PermissionGrants`) into your GRC tooling. Review should assess: is the app still in use, does its permission scope still match its business justification, is the publisher still verified/trustworthy, and has it requested new/expanded permissions since last review. Revoke grants for apps that fail the review.
- *Audit evidence*: Access review completion records (reviewer, date, decisions); revocation log for any grants removed.

**3. Consent/token events centrally logged — ISM-2139**
- *Requirement*: All consent grant events and OAuth token issuance/refresh events must flow to central, tamper-evident logging under your Chapter 15 System Monitoring program.
- *Implementation*: Ensure Entra ID **Audit logs** (consent-to-application events) and **Sign-in logs** (including non-interactive/token refresh sign-ins) are streamed via Azure Monitor / Log Analytics or Microsoft Sentinel into your central SIEM, not left in the 30/90-day Entra ID native retention window. Set alerting rules for anomalous consent grants (e.g., high-privilege scopes, unfamiliar publishers, consent from atypical geographies) and for unusual token refresh patterns (e.g., long-lived offline_access tokens being used from new IPs).
- *Audit evidence*: SIEM ingestion configuration for Entra ID audit/sign-in logs; retention period matching your classification (18 months minimum for OFFICIAL: Sensitive and PROTECTED under Chapter 15); sample alert rules and recent triage records.

**4. Device code flow disabled unless required — ISM-2140**
- *Requirement*: OAuth device authorisation grant (device code flow) must be disabled tenant-wide unless there is a documented business need, since it is a known phishing/consent-grant-attack vector (used to trick users into approving attacker-controlled sign-ins on unmanaged devices).
- *Implementation*: Configure a **Conditional Access policy blocking the device code authentication flow**, with narrowly scoped exceptions (specific app registrations, specific device categories, e.g. shared meeting-room hardware) that are individually risk-assessed and documented.
- *Audit evidence*: Conditional Access policy export showing device code flow blocked by default; documented exception list with business justification and approval.

**Practical rollout sequence**: (1) inventory current third-party app consents and their permission scopes today — you cannot review what you haven't catalogued; (2) turn on the admin consent workflow and disable user consent; (3) stand up the 6-monthly access review cadence in your compliance calendar alongside your existing DCSync/KRBTGT review cycles; (4) wire consent and token event logs into your SIEM with alerting; (5) block device code flow and document exceptions.

**Documentation**: record this control set in your SSP under Chapter 3 (Procurement & Outsourcing, for third-party app risk) and Chapter 9/19 (identity and remote access), citing ISM-2137–2140 explicitly, with the M365 tenant configuration screenshots and access-review records as your evidence package for IRAP or internal assessment.

I don't have verified access to the exact current ISM control wording on third-party OAuth app consent, so treat the specifics below as general security guidance informed by how the ISM typically approaches identity, access control, and supply-chain risk — confirm exact control IDs with your compliance team against the current published ISM.

Why this matters under an ISM-aligned posture
Third-party OAuth apps requesting delegated permissions into a Microsoft 365 tenant (Graph API scopes covering mail, files, Teams, directory data, etc.) are, from a risk perspective, a supply-chain and access-control issue simultaneously. A user clicking "Accept" on a consent prompt can grant an external, unvetted application standing access to sensitive tenant data — often broader access than the user realizes, and without going through your normal vendor risk assessment or change control process. This is one of the more common real-world initial-access and data-exfiltration vectors in Microsoft 365 environments, so it maps directly onto ISM principles around access control, restricting administrative/privileged access, and supply chain risk management, even where a specific ISM control doesn't name "OAuth consent" verbatim.

Recommended control approach
1. Disable user consent by default. Configure Entra ID (Azure AD) so end users cannot consent to third-party app permissions themselves. This is the single highest-leverage change: it forces every new integration through a governed approval path rather than ad hoc individual clicks.

2. Stand up an admin consent workflow. Rather than a flat "no self-service ever," use Entra ID's admin consent request workflow so users can request access to a legitimate business app, and a designated approver (security or IT admin) reviews and grants it. This preserves usability while restoring an approval gate — consistent with ISM's emphasis on privileged/administrative actions requiring appropriate authorization.

3. Tier your review criteria by permission scope and risk. Not all OAuth requests are equal:
 - Low risk: sign-in only (openid, profile, email) — often safe to allow broadly.
 - Medium risk: read-only access to a user's own mailbox/calendar/files.
 - High risk: broad Mail.ReadWrite, Files.ReadWrite.All, Directory.Read.All, or any application-level (not delegated) permission, especially Application permissions that don't require a signed-in user — these should always require formal security review, similar to how you'd review a new vendor with system-wide access.

4. Restrict or ban application-permission (app-only) consent entirely for non-Microsoft, non-vetted publishers unless there's a documented, approved business case, since app-only permissions bypass per-user scoping and effectively grant tenant-wide access.

5. Enforce publisher verification. Require that any app requesting consent be a Microsoft-verified publisher, and treat unverified-publisher apps as an automatic escalation/deny pending review — unverified publisher status is one of the strongest, easiest-to-check signals of an unvetted or malicious app.

6. Maintain a living inventory and periodic recertification. Enterprise applications and their granted permissions should be reviewed on a defined cadence (e.g., quarterly) — remove permissions/apps no longer in active use, and recertify that business owners still need what's been granted. This mirrors ISM expectations around periodic access reviews for any privileged or standing access.

7. Log and alert on consent events. Ensure Entra ID sign-in and audit logs capturing OAuth consent grants flow into your SIEM, with alerting on: consent grants to unverified publishers, high-privilege scope grants, and any grant occurring outside the approved workflow (which would indicate a misconfiguration or policy bypass).

8. Apply conditional access and risk-based controls around consent-adjacent activity, e.g., requiring MFA and a compliant device before a user can even initiate a consent request, reducing the chance of a compromised account approving a malicious app on someone else's behalf (illicit consent grant attacks / "consent phishing").

9. Document this as a formal policy artifact. Given this is a recurring audit and Essential Eight/ISM assessment topic, capture the OAuth app governance process (who approves, what criteria, review cadence, logging requirements) as a written procedure so it's evidence-ready for assessors, rather than tribal knowledge in the identity team.

Practical next step: I'd recommend having your identity/security architecture team confirm this approach against the specific ISM controls currently in force for access control, identification and authentication, and system hardening, and against your organization's Essential Eight maturity target (application control and restricting admin privileges both touch this area). Happy to help draft the actual tenant policy document or the Entra ID configuration checklist once you confirm your target maturity level and current baseline.

Short answer: **no, the Essential Eight is not being replaced right now** — assess against it as-is. This answer reflects the ISM September 2026 release status.

**Current status of the "Essentials" consultation**: ASD ran a consultation on a proposed successor/extension (informally referred to as "Essentials") that closed on 12 July 2026. As of the September 2026 ISM release, there is **no announced outcome** from that consultation — no replacement framework, no revised maturity model, no transition timeline has been published. Until ASD formally announces a change, the Essential Eight and its existing Maturity Model (ML0–ML3) remain the operative, ASD-mandated baseline for Australian government entities, and you should continue reporting against it in your normal cyber security posture reporting cycle.

**What to assess against right now:**

1. **Essential Eight Maturity Model (ML0–ML3)** across all eight strategies:
 - Application control (allow-listing)
 - Patch applications
 - Configure Microsoft Office macro settings
 - User application hardening
 - Restrict administrative privileges
 - Patch operating systems
 - Multi-factor authentication
 - Regular backups

 ASD's recommended baseline target for 2026 for most government entities is **ML2** ("mostly aligned; addresses sophisticated threats"), with **ML3** required for critical infrastructure operators and high-risk sectors. Confirm your entity's mandated target tier with your portfolio's cyber security policy — this can vary by agency risk profile.

2. **The full ISM control set in parallel** — this is the point most teams get wrong: Essential Eight compliance is a subset of ISM compliance, not a substitute for it. The Essential Eight maps to only three ISM chapters at meaningful depth (Ch. 13 System Hardening, Ch. 14 System Management, and pieces of Ch. 6/9/19 for MFA), out of 22 chapters total. Being ML2 across the Essential Eight tells you nothing about your posture on incident response (Ch. 2), physical security (Ch. 5), cryptography (Ch. 20), gateways (Ch. 21), or the newer September 2026 control areas — agentic AI (ISM-2156–2159), AI agent identity (ISM-2133–2135), third-party OAuth (ISM-2137–2140), workload credentials (ISM-2141–2148), and service provider access (ISM-2124–2125). None of the June or September 2026 ISM additions carry an Essential Eight mapping — they are ISM-only obligations, so Essential Eight maturity work and current ISM compliance are genuinely separate workstreams that both need active tracking.

3. **Essential Eight to ISM mapping document** (published by ASD) — use this to confirm which specific ISM control IDs each Essential Eight strategy satisfies, and don't assume coverage extends beyond what's explicitly mapped.

**Practical recommendation for your assessment cycle:**
- Run your Essential Eight self-assessment against ML0–ML3 as normal, targeting your entity's mandated maturity level.
- Separately, run (or request from us) a full ISM gap analysis covering all 22 chapters for your system's classification level, with particular attention to the September 2026 additions if you have any agentic AI, MSP relationships, or third-party OAuth integrations in scope — these are new obligations with no Essential Eight equivalent and are the areas most likely to be missed if a team assumes "we're ML2, so we're covered."
- Monitor the "Essentials" consultation outcome and flag it for reassessment the moment ASD publishes a determination — a genuine replacement would require updating your SSP's control-selection rationale and your recurring posture-reporting templates.
- Document in your SSP explicitly which ISM release your control selection assumes (September 2026) and note the open consultation as a tracked risk item with a review trigger tied to ASD's announcement.

If you'd like, I can produce a combined Essential Eight maturity scorecard plus full ISM gap-analysis table for your system's classification level as a next step.

Short answer: as of my last confirmed knowledge, the Essential Eight was not being retired or replaced — it remained ASD/ACSC's baseline mitigation strategy framework for Australian organizations, with the ISM serving as the more granular, comprehensive control catalog that sits alongside it. I don't have verified visibility into any announcement after that point (including anything specific to your September 2026 timeframe) that would change this, so please confirm current status directly with ACSC guidance before finalizing your assessment plan — but I can walk you through how the two frameworks relate and what a sensible assessment approach looks like either way.

How the Essential Eight and the ISM relate (they're not competitors)
These two things are often confused, but they serve different purposes and neither has historically been on a path to replace the other:

- The Essential Eight is a small, prioritized set of eight mitigation strategies (application control, patch applications, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, patch operating systems, multi-factor authentication, regular backups) designed to be a practical, high-impact starting point — especially for organizations without mature security programs. It has a four-level maturity model (Maturity Level 0 through 3) that measures how rigorously each strategy is implemented.
- The ISM is the full control catalog — hundreds of controls across governance, physical security, personnel security, and the full technical stack — intended primarily for Australian government systems and increasingly referenced by industry, particularly regulated sectors and government suppliers. The Essential Eight's eight strategies are actually a subset drawn from, and cross-referenced against, ISM controls; the ISM's guidelines sections explicitly map back to Essential Eight maturity levels.

So the relationship has generally been: Essential Eight = a prioritized "top 8" on-ramp; ISM = the comprehensive framework it's drawn from. An organization maturing its security program typically starts with Essential Eight uplift and, if it's a government entity, government supplier, or otherwise needs full ISM compliance (e.g., for an IRAP assessment or PSPF requirements), expands into the full ISM control set over time. This is additive, not a replacement relationship.

What's plausible to have changed recently
Both frameworks get revised periodically:
- The Essential Eight maturity model and technical guidance get periodic refreshes (there have been updates roughly annually to reflect new threats, e.g., adjustments to MFA guidance to favor phishing-resistant methods, or updates addressing cloud environments and SaaS applications, which the original 2017-era Essential Eight wasn't designed around).
- ACSC has discussed expanding guidance for cloud-native and SaaS-heavy environments, since the original Essential Eight strategies assume more of a traditional on-premises Windows environment.
- There has been ongoing industry discussion (not confirmed as formal ACSC policy in what I can verify) about whether the Essential Eight needs a more explicit "ninth" or supplementary strategy for cloud/identity-centric environments, but I'm not treating that as fact — flagging it only as sector chatter you may have heard, which is plausibly what's prompting your question.

What to assess against right now
Given the uncertainty, I'd recommend a pragmatic, layered approach rather than betting your assessment program on rumors of a framework being replaced:

1. Confirm current guidance directly at cyber.gov.au (Essential Eight and ISM pages) before finalizing scope — five minutes of verification avoids building your program on stale information.
2. Assess against Essential Eight maturity levels as your baseline if you haven't already — it's fast to operationalize and widely understood by boards and auditors.
3. Layer in relevant ISM controls beyond the Essential Eight if you're a government entity, supplier, or in a regulated sector requiring broader ISM compliance — don't treat Essential Eight alone as sufficient for those obligations.
4. Set your target maturity level deliberately — Maturity Level 2 is a common target for most organizations; Maturity Level 3 is typically reserved for organizations facing sophisticated, targeted adversaries.
5. Re-run your gap assessment whenever ACSC issues an update to either framework, since scoring criteria for individual strategies do shift over time even without a wholesale framework change.
6. Treat any "Essential Eight is being replaced" claim you've heard as needing primary-source verification — I'd want to see it directly from ACSC before it changes your roadmap.

If you can share where you saw the "replacement" claim (an article, vendor blog, etc.), I'm happy to help you evaluate its credibility, but I won't speculate further on unconfirmed framework changes.

This answer assumes the ISM September 2026 release (published 3 September 2026), which is where most of the recent cadence changes and the new managed service provider (MSP) access controls were introduced.

**Part 1 — Operational cadences that changed**

Several existing controls kept the same intent but had their required frequency tightened. This matters operationally because it changes your recurring compliance calendar, not just a one-off implementation task:

1. **DCSync-permission reviews (ISM-1934)**: annual → **6-monthly**. If you have Active Directory in scope, your process for reviewing which accounts hold Replicating Directory Changes / Replicating Directory Changes All permissions (the permissions that enable DCSync-style credential extraction) now needs to run twice a year. Update your IAM review runbook and calendar accordingly, and make sure the review output (who has DCSync rights, why, and any remediation) is retained as assessment evidence.

2. **KRBTGT credential changes (ISM-1847)**: annual → **6-monthly**. The KRBTGT account password (and its associated key material) must now be rotated twice yearly rather than once. Note the operational nuance: KRBTGT rotation must be done twice in sequence with an appropriate interval between rotations to fully invalidate old Kerberos tickets — factor this into your change-management scheduling, not just a single password reset.

3. **Post-deployment vulnerability assessments and penetration tests (ISM-2118)**: annual → **6-monthly**. Systems now require a vulnerability assessment/pen test cadence of twice yearly after go-live. This has budget and vendor-scheduling implications if you're using external testers — line up your testing contracts now rather than waiting for the next renewal cycle.

4. Also relevant to cadence (introduced alongside, not a frequency change but new recurring obligations): **third-party OAuth consent reviews (ISM-2138)** at 6-monthly, and **quarterly CTI-informed threat hunting (ISM-2153)** as a brand-new recurring activity — your threat-hunting function now needs a defined quarterly cycle informed by current cyber threat intelligence, not ad hoc hunts.

**Recommendation**: consolidate these into a single compliance calendar (DCSync review, KRBTGT rotation, pen test, OAuth consent review — all 6-monthly; CTI-informed hunting — quarterly) so your team isn't tracking four separate half-yearly cycles on different clocks. Where feasible, align them to the same review windows to reduce operational overhead.

**Part 2 — What's new for managed service provider (MSP) access**

The September 2026 release introduced a dedicated MSP/service-provider control pair (ISM-2124–2125) plus an important amendment to an existing incident-classification control (ISM-1576):

1. **Provider access restricted to approved tools, source addresses, and time windows (ISM-2124)**: MSP access to your environment must be scoped — not standing, unrestricted access, but access limited to specific approved remote-management tools, specific source IP ranges/addresses, and specific time windows (e.g., scheduled maintenance windows or ticket-driven access sessions). If your MSP currently has always-on VPN or RDP access with no time-boxing, this is now a compliance gap.

2. **Organisation-controlled, tamper-proof logging (ISM-2125)**: critically, the logging of MSP activity must be under **your organisation's control**, not solely the provider's own logging (which the provider could alter or fail to retain). Ensure MSP sessions are captured in your own SIEM/log pipeline — e.g., via jump-host/PAM session recording that you own, not just the vendor's ticketing or RMM tool logs.

3. **ISM-1576 amended — unauthorised provider access is now explicitly a cyber security incident**: this closes a gap where out-of-scope or after-hours provider access might previously have been treated as a process exception rather than a security event. Any MSP access outside the approved tools/addresses/time windows must now trigger your Chapter 2 incident response process, including any applicable ASD notification obligations for systems handling PROTECTED and above.

4. **Related control worth flagging in the same review**: **authorised RMM tool allow-listing with gateway blocking (ISM-2149–2150)** — pair this with your MSP access controls, since MSPs commonly rely on remote monitoring and management tooling. Only approved RMM tools should be permitted through your gateway; unauthorised RMM traffic should be blocked and alerted on, which also helps detect an MSP (or an attacker impersonating one) using unapproved tooling.

**Practical next step**: review your current MSP/vendor contracts and technical access configuration against ISM-2124–2125 specifically — confirm access is tool/address/time-scoped, confirm your organisation (not the provider) owns the audit trail, and update your incident response plan and MSP contract clauses to reflect that unauthorised access is now a reportable incident under ISM-1576. I can help draft the updated contractual clauses or a gap-analysis table against these controls if useful.

I don't have verified visibility into the specific recent ISM revisions you're referring to, so I can't cite exact control changes or dates with confidence. What I can give you is a grounded picture of the operational cadences the ISM has historically defined, and where MSP access requirements have generally been heading, so your team has a framework to check against once you pull the current document.

Operational cadences the ISM typically defines
The ISM sets recurring, time-bound obligations across several domains rather than one-off requirements. The main categories your team should map against the current text are:

1. Patching timeframes. The ISM has long specified patch/update timeframes tied to severity and exploitability — historically categories like "patch within 48 hours for internet-facing services with a working exploit," extending out to routine cycles (e.g., monthly) for lower-severity issues on internal systems. These timeframes get periodically tightened as exploit weaponization speeds up; confirm the current bands, since they are one of the more frequently revised numeric thresholds in the ISM.

2. Vulnerability scanning frequency. Expect defined minimum cadences for vulnerability scanning of internet-facing services versus internal systems (internet-facing typically scanned more frequently, e.g., weekly or more, versus internal systems on a longer cycle).

3. Backup testing and restoration drills. The ISM requires not just backups but periodic testing of restoration processes — typically annually at minimum, sometimes more frequently for higher-criticality systems, to confirm backups are actually recoverable.

4. Access and privilege recertification. Periodic review of user accounts, privileged accounts, and third-party access grants — commonly on a quarterly or annual cadence — to confirm continued business need and remove stale access.

5. Security risk assessments and system security plan reviews. The ISM requires SSPs and associated risk assessments to be reviewed and updated on a defined cycle (commonly annually, or whenever a significant change occurs to the system).

6. Event log review and retention. Defined minimum retention periods (commonly measured in months to years depending on classification) and expectations around active monitoring/alerting cadence, not just passive log storage.

7. Penetration testing cycles. Periodic (often annual) penetration testing requirements for systems above a certain sensitivity/criticality threshold.

If your team has noticed a "cadence" change recently, it's most likely to be one of: a tightened patch timeframe, an added/adjusted scanning frequency, or a new/adjusted review cycle for access or risk assessments — confirm which by diffing the current ISM's "Changes to the ISM" summary page against your last-assessed baseline.

Managed service provider (MSP) access — what's generally new in this space
This is an area that has received sustained attention across Australian government guidance following several high-profile incidents where compromised MSP credentials or remote access tooling were used as a path into customer environments. Even without confirming the exact ISM control text for your release, the direction of travel across ACSC guidance has been consistent, and I'd expect any recent ISM update in this space to reinforce these themes:

1. No standing/persistent privileged access for MSPs by default. Increasing expectation that MSP access be just-in-time, time-boxed, and re-authorized per engagement rather than always-on.

2. Dedicated, attributable MSP accounts. MSP technicians should not share generic/service accounts; each individual should have a uniquely attributable identity, ideally federated from the MSP's own identity provider with your organization able to independently disable access.

3. MFA and phishing-resistant authentication mandatory for all MSP remote access, no exceptions for "trusted" third parties.

4. Full logging of MSP activity, retained and reviewable by the customer organization independently of the MSP's own logs — so you're not solely reliant on the MSP to self-report what they did in your environment.

5. Network segmentation and least-privilege scoping for MSP tooling (e.g., RMM/remote monitoring and management platforms), limiting blast radius if the MSP itself is compromised.

6. Contractual and assurance requirements — expect stronger expectations that MSP contracts explicitly address incident notification timeframes, right-to-audit clauses, and security control obligations flowing down to any subcontractors the MSP uses.

7. Immediate access revocation capability — the customer organization should be able to independently and immediately revoke an MSP's access (not dependent on the MSP's own offboarding process) in the event of a suspected compromise or contract termination.

Recommended next step: have your team pull the current ISM's "Changes to the ISM" summary and specifically check the guidelines on cyber security incidents, outsourcing and procurement, and system monitoring, since MSP-specific requirements are typically distributed across those sections rather than consolidated in one place. Once you share the actual current text or the specific controls you're trying to reconcile, I can help you build a gap assessment against your existing MSP contracts and access architecture.

You operate critical logistics infrastructure in the Netherlands, so the change that matters most is national, not EU-level: on 15 August 2026 the Cyberbeveiligingswet (Cbw) entered into force, alongside the Wet weerbaarheid kritieke entiteiten (Wwke), replacing the previous Wet beveiliging netwerk- en informatiesystemen (Wbni). This is the Netherlands' NIS2 transposition act, and it applies immediately — there is no transition period. Roughly 8,000 organisations across 18 sectors fall in scope, and transport/logistics is one of the Annex I high-criticality sectors under NIS2 itself (Directive (EU) 2022/2555), so if your logistics operation was previously monitoring NIS2 only as an EU-level directive with no binding force in the Netherlands, that gap is now closed.

What changed in practice, effective 15 August 2026:

1. **Registration is live and mandatory.** In-scope entities must register with the national authority via MijnNCSC (the Dutch National Cyber Security Centre's portal). If you have not registered, this is the most urgent action item — do it now, not after a compliance review.

2. **Duty of care (zorgplicht) applies now.** This is the Dutch implementation of NIS2 Art. 21's ten risk-management measures — risk analysis and policies, incident handling, business continuity/backup/DR, supply chain security, secure acquisition/development, effectiveness assessment, cyber hygiene and training, cryptography, HR/access control/asset management, and MFA/secured communications. If your risk-management programme was still "NIS2-ready" rather than "NIS2-implemented," it needs to be operational immediately — the Cbw does not give you a grace period to build toward it.

3. **Incident reporting obligations apply now**, on the Art. 23 clock: a 24-hour early warning, a 72-hour incident notification, and a final report within one month, all measured from the moment your organisation becomes aware of a significant incident. You should confirm your incident response plan has a pre-drafted notification path to the Dutch CSIRT (or the relevant sectoral CSIRT) and that "awareness" is defined clearly enough internally that the clock-start isn't ambiguous during a live incident.

4. **Board accountability applies now.** Under the Cbw (mirroring NIS2 Art. 20), your management body must approve the risk-management measures, oversee their implementation, and undergo cybersecurity training itself — not just mandate it for staff. Management can face personal liability for infringements. If you don't already have board-level approval minutes and a standing cybersecurity oversight agenda item, generate that evidence now; it's the artifact regulators and auditors will ask for first.

A classification nuance specific to logistics: confirm whether your entity sits in Annex I (transport: air, rail, water, road) or is itself designated as a critical entity under the CER Directive (EU) 2022/2557, since CER-designated entities are automatically essential entities under NIS2 Art. 3(1)(f) — that carries ex-ante supervision (Art. 32: proactive inspections, audits, security scans) rather than the ex-post, complaint/evidence-triggered supervision (Art. 33) that applies to important entities. This distinction should already be reflected in how the Dutch authority has classified you under Cbw/Wwke; if you haven't received or confirmed that classification, that's a call to make to the NCSC or your sector regulator this week, since it determines both your penalty exposure (Art. 34: essential entities face fines up to the higher of €10M or 2% of global turnover; important entities up to the higher of €7M or 1.4%) and how proactively you should expect to be audited.

Practical next steps, in priority order: (1) confirm MijnNCSC registration status and complete it if outstanding; (2) confirm your essential-vs-important classification under the Cbw/Wwke, including any CER designation; (3) verify your incident response plan maps cleanly onto the 24h/72h/1-month timeline with a defined notification channel; (4) produce or refresh board-level approval and training evidence for the risk-management measures; (5) if you have EU operations outside NL, note that France, Ireland and Spain remain behind on transposition and were referred to the CJEU in July 2026 — build your group-wide programme to the strictest transposed standard (currently the Dutch Cbw) rather than waiting on the laggards. This is general compliance guidance, not legal advice — confirm specifics with NCSC-NL or Dutch counsel given the immediate, no-transition-period applicability.

I don't have verified, up-to-date information confirming a specific Dutch NIS2-related regulatory change that took effect in August 2026, and I want to be upfront about that rather than invent a specific event, deadline, or legal citation. What I can do is give you the framework you should check against, so you or your legal/compliance team can confirm what actually changed.

Background on the Dutch transposition situation: NIS2 (Directive (EU) 2022/2555) had a transposition deadline of 17 October 2024, which the Netherlands missed, along with a majority of other member states. The Dutch implementing law is the "Cyberbeveiligingswet" (Cyber Security Act, Cbw), which has gone through a legislative process (Raad van State advice, parliamentary consultation, Tweede Kamer and Eerste Kamer review) well into 2025 and, based on the pattern of delay, plausibly into 2026. Given that your question specifically flags "August 2026," a few realistic possibilities are:

1. The Cyberbeveiligingswet (or its implementing "Cyberbeveiligingsbesluit," the underlying decree) formally entered into force around that date, starting statutory clocks for registration, risk-management measures, and incident reporting.
2. The Dutch Radiocommunications Agency / RDI or the NCSC-NL (which is expected to play a coordinating and CSIRT role) opened a formal entity registration window or published a designation of essential/important entities, with a mandatory self-registration deadline.
3. A sector-specific ministerial regulation (for logistics/transport, which is explicitly named as a "high-criticality" sector under NIS2 Annex I, covering transport by air, rail, water and road, including logistics providers) was published, clarifying scope, thresholds (i.e., whether the 50-employee/€10M-turnover size-cap test applies to you, or whether you're captured regardless of size due to being a sole/critical provider).
4. Supervisory and enforcement powers (audits, binding instructions, fines up to €10M or 2% of global turnover for essential entities) became actionable, meaning the "grace period" some earlier drafts contemplated ended.

What actually matters for a logistics operator in scope of NIS2 in the Netherlands:

- Confirm your classification. Freight transport, logistics, and supply chain management services are listed under NIS2 Annex I (Transport sector) and can be essential or important entities depending on size and criticality. Some "critical" designations (e.g., single points of failure in national logistics) can pull in even smaller entities regardless of the standard size thresholds.
- Registration obligation: NIS2 requires entities to register with the relevant competent authority/CSIRT within a set window after the law's national entry into force, providing details like legal name, sector, contact points, IP ranges, and member states of operation. If the Cbw or its decree became binding in August 2026, this is very likely the operative deadline you're now facing.
- Governance duty (Article 20): management bodies must approve cybersecurity risk-management measures and undergo training; management can be held personally liable for non-compliance.
- Article 21 technical/organisational measures: risk analysis, incident handling, business continuity/backup, supply chain security, vulnerability handling, cryptography/encryption, access control, and use of multi-factor authentication.
- Incident reporting: 24-hour early warning, 72-hour incident notification, and a final report within one month to the Dutch CSIRT/competent authority.

Recommended next step: I'd treat "August 2026" as a specific factual trigger that needs verification against the current text of the Cyberbeveiligingswet/Cyberbeveiligingsbesluit and any RDI/NCSC-NL guidance published that month, since transposition timelines have shifted multiple times and I can't confirm the exact provision that took effect without checking a primary source. I can help you structure a gap assessment against Article 21 and the registration/reporting obligations once you confirm the specific instrument and its effective date.

As of September 2026, based on the most recent enforcement action I can confirm: on 9 July 2026 the European Commission referred Ireland, Spain, France, and the Netherlands to the CJEU for failing to notify transposition of NIS2 (Directive (EU) 2022/2555), seeking a lump-sum penalty plus daily fines. Of that group, the Netherlands has since transposed — its Cyberbeveiligingswet (Cbw), together with the Wet weerbaarheid kritieke entiteiten (Wwke), entered into force on 15 August 2026, replacing the prior Wbni, with no transition period.

That leaves Ireland, Spain, and France — the three jurisdictions where you have subsidiaries — as still lacking in-force national transposition as of the CJEU referral date. I want to flag directly that I should not assert their current status from memory beyond that referral: transposition bills can move quickly, and it's plausible one or more of these states has since passed implementing legislation between July and September 2026 without that reaching my knowledge. Before you finalize any compliance timeline, verify current status directly with each national authority: the NCSC in Ireland, INCIBE/the Spanish national cybersecurity framework authorities in Spain, and ANSSI in France. Each has published or will publish draft/final implementing law and a registration portal; check those directly rather than relying on secondary sources.

What this means practically for a group with subsidiaries in all three:

**The directive still binds you even without transposition.** NIS2 is a directive, meaning its legal force runs through national law, but that does not mean you are exempt until France, Ireland, or Spain formally transpose. Two things are true simultaneously: (1) individual entities generally cannot be fined under national law until that law exists and applies to them, but (2) once a national act does land, historical practice across other Member States (Germany, Belgium, Italy, etc., which transposed earlier) has been to apply short or no compliance windows — the Netherlands' Cbw is the most recent example, with zero transition period. Waiting until a French, Irish, or Spanish law is signed to start building your programme is a bad bet; you would likely be racing an already-live compliance deadline.

**Build to the directive text now, not to the weakest national variant.** For a multi-country group, best practice is: (1) classify each subsidiary's sector and size under NIS2 Art. 2/Art. 3 as if the directive applied directly — Annex I/Annex II sector scope, the ≥50 employee or >€10M turnover/balance-sheet threshold for in-scope status, and the ≥250 employee or >€50M turnover with >€43M balance sheet threshold for essential-entity status; (2) implement the Art. 21(2) ten-measure risk-management programme and Art. 20 governance obligations (management body approval, oversight, training, personal liability exposure) group-wide, since these substantive obligations are unlikely to be watered down in any national transposition; (3) build an Art. 23 incident-reporting capability (24h early warning, 72h notification, 1-month final report) with defined national CSIRT reporting channels for each subsidiary — pending official channels, use the National Coordination Centres or interim contact points these Member States tend to publish ahead of full legal transposition; (4) apply the strictest currently-transposed national variant as your group baseline — right now that is the Dutch Cbw, since it's the most detailed live implementation among comparable Member States — until France, Ireland, and Spain publish their own.

**Watch the CJEU referral for signal, not for your deadline.** The July 2026 referral pressures these states with financial penalties for the *state*, not directly for your subsidiaries, but it's a strong indicator these transpositions are imminent (likely under active legislative or executive drafting). Treat "not yet transposed" as "transposing soon, with limited notice," and keep a standing watch on the national gazette/official journal in each jurisdiction plus ANSSI/NCSC/INCIBE bulletins.

Bottom line: confirm current Irish, Spanish, and French transposition status directly with those authorities before relying on any snapshot including this one, but proceed now as if NIS2's substantive obligations (Arts. 20, 21, 23) apply to your subsidiaries in all three, since that is both the safer and, most likely, the accurate posture.

I can't give you a definitive, current-as-of-September-2026 list of which member states have or haven't transposed NIS2, and I'd rather flag that clearly than guess at a status that may have changed. What I can offer is the pattern of delay that was well-established through 2024-2025, plus specific notes on Ireland, Spain, and France, so your team can verify the live status against the European Commission's infringement tracker and each country's official gazette.

The general picture: NIS2's transposition deadline was 17 October 2024. The European Commission opened infringement proceedings (formal notices under Article 258 TFEU) against roughly two-thirds of member states shortly after that deadline for failing to fully transpose or notify transposition measures. By early-to-mid 2025, only a small handful of states (commonly cited: Belgium, Croatia, Italy, Lithuania, and a few others) had substantially completed transposition, while most of the EU-27 were still working through national legislation. Given that pattern, it would not be surprising if some member states were still finalizing secondary legislation (implementing decrees, sector-specific regulations, designation of competent authorities) well into 2026, even if the primary transposition law had passed.

On your three specific jurisdictions:

Ireland: Ireland has historically been one of the slower movers on NIS-related transposition (it was also late on the original NIS Directive). The National Cyber Security Bill has been the vehicle for NIS2 transposition, with the NCSC (National Cyber Security Centre) expected to be designated as the national competent authority/single point of contact. As of the information I have, I cannot confirm whether this bill had been enacted and commenced by September 2026 — you should check the Irish Department of the Environment, Climate and Communications and the Oireachtas legislative tracker directly.

Spain: Spain has been working through a draft "Ley de coordinación y gobernanza de la ciberseguridad" to transpose NIS2, with INCIBE (Instituto Nacional de Ciberseguridad) expected to play a central operational role and CCN-CERT/CNPIC also involved given overlap with existing critical infrastructure protection law (Ley PIC). Draft versions circulated through 2024-2025 but I don't have confirmed data on final enactment status by September 2026.

France: France has generally moved somewhat faster on cyber regulation transposition given ANSSI's established role, using a project of law ("projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité," sometimes referred to covering both NIS2 and the CER Directive) to transpose both directives together. There were reports of this advancing through the French Parliament in 2024-2025, but again, I cannot confirm final enactment or full entry into force by September 2026 without checking a current source.

Why this matters practically for a group with subsidiaries in these three states: NIS2 is a minimum-harmonization directive, meaning each member state can gold-plate requirements (stricter incident reporting timelines, broader sectoral scope, additional registration fields, specific national CSIRT reporting formats). Even where the core obligations (Article 21 risk measures, Article 23 incident reporting, governance/Article 20 duties) are broadly similar, you should expect:

- Different competent authorities and reporting portals per country (Ireland's NCSC, Spain's INCIBE/CCN, France's ANSSI).
- Possibly different registration deadlines and thresholds tied to each country's national entry-into-force date, not the EU-wide 17 October 2024 date.
- Divergent enforcement postures and fine levels within the NIS2 caps (up to €10M/2% turnover for essential entities, €7M/1.4% for important entities), since national law sets exact figures.
- For a group entity, "one incident, three jurisdictions" scenarios where you may need to notify three different CSIRTs on three different clocks if the incident affects services in all three countries.

Recommended next step: Before September 2026 compliance planning, have local counsel or a compliance tracker (e.g., a firm's NIS2 transposition tracker, or the European Commission's official infringement/transposition status page) confirm current status for Ireland, Spain, and France specifically, since this is a fast-moving and easily outdated area and I don't want to state a status I can't verify.

Here is the NIS2 (Directive (EU) 2022/2555) Art. 23 reporting workflow applied to a ransomware event that has taken down production systems, with every deadline computed from the moment your organisation becomes **aware** of the incident — not from when it started.

**Step 0 — Establish "significant incident" status (Art. 23(3)).** Ransomware taking down production systems will almost always qualify: it satisfies limb (a) — severe operational disruption of services or financial loss to the entity — on its face. If you are a DNS, cloud, data centre, CDN, MSP/MSSP, trust service provider, TLD registry, or online marketplace/search/social platform, don't rely on judgment alone: check Commission Implementing Regulation (EU) 2024/2690, which sets quantitative thresholds for these entity types (e.g., a horizontal baseline of direct financial loss above €500,000 or 5% of annual turnover, whichever is lower, plus entity-specific triggers). For other sectors, the operational-disruption test governs.

**The timeline, using your scenario (production encrypted Monday 09:00, discovered/confirmed same time):**

| Deadline | Report | What to include | Where it goes |
|---|---|---|---|
| **By Tuesday 09:00 (≤24h from awareness)** | Early warning | Whether you suspect unlawful/malicious action; whether cross-border impact is possible | Your national CSIRT or competent authority (single entry point per your Member State's transposition) |
| **By Thursday 09:00 (≤72h from awareness)** | Incident notification | Update to the early warning; initial severity/impact assessment; indicators of compromise (ransomware variant, ransom note, C2 infrastructure, affected system count) | Same recipient |
| **On request during handling** | Intermediate report | Status updates while the incident is still being handled | Same recipient |
| **Within 1 month of the 72h notification** | Final report | Detailed description including severity/impact; threat type and root cause; mitigation applied and ongoing; cross-border impact | Same recipient |
| **If still unresolved at 1 month** | Progress report, then a final report within 1 month of actual handling completion | Same required fields | Same recipient |

**Parallel obligations that ransomware specifically triggers:**

- **Art. 23(1)–(2): notify affected service recipients.** If the ransomware event is likely to adversely affect your customers' or users' service delivery, you must inform them of the significant incident, and — separately — inform them of significant cyber threats together with any remedies they can apply (e.g., "watch for phishing exploiting this incident").
- **Art. 23(7): public disclosure.** The competent authority (or CSIRT) can require or itself issue public disclosure where informing the public is necessary to prevent or manage the incident — expect this conversation with the authority during your 72h notification if the incident is customer-visible.
- **GDPR Art. 33, run on its own clock in parallel.** If the ransomware actors accessed, exfiltrated, or encrypted personal data, you separately owe your Data Protection Authority a breach notification within 72 clock-hours of your awareness of the *personal-data* breach specifically — this is a different report, different recipient, and a different trigger condition than the NIS2 notification, so don't conflate the two or assume one filing satisfies both.
- **DORA carve-out, if relevant.** If you are a financial entity under Regulation (EU) 2022/2554, DORA's incident-reporting regime applies instead of NIS2 Art. 23 as lex specialis (Art. 4) — your reports go to your financial supervisor, not the CSIRT, even though you remain registered under NIS2.

**Operational recommendations to execute now, not after the next incident:**
1. Pre-draft your early-warning and 72h-notification templates so the clock doesn't eat your response time; a live ransomware incident is the worst moment to be drafting a report from scratch.
2. Define "awareness" internally in your IR plan — is it detection by your SOC, confirmation by an incident commander, or executive notification? Ambiguity here creates real dispute risk with regulators about whether you met the 24h deadline.
3. Build the ransomware-specific IoC fields (variant, ransom demand, initial access vector, lateral movement path) directly into your incident-notification template so the 72h report is a fill-in-the-blanks exercise.
4. Run a joint tabletop at least annually that exercises the NIS2 clock alongside GDPR Art. 33 and, if applicable, DORA reporting, so your legal, security, and comms teams aren't reconciling three regimes for the first time mid-incident.
5. Confirm your reporting channel and current national CSIRT contact details are correct and tested — especially if your Member State's NIS2 transposition changed recently (several states updated national CSIRT/authority designations through 2025–2026).

This is general compliance guidance, not legal advice; confirm your specific national reporting channel and any sector-specific overlay (financial services, healthcare, energy) with your national competent authority or counsel before an incident occurs.

Here's how a NIS2-in-scope entity should walk through incident reporting for a ransomware event that takes down production systems, based on the directive's Article 23 framework (note: exact procedural details, portals, and forms depend on your specific national transposition law, so treat this as the EU baseline to map against your country's implementation).

Step 1: Determine if it's a "significant incident." Not every security event triggers NIS2 reporting. A significant incident is one that (a) has caused or is capable of causing severe operational disruption or financial loss to the entity, or (b) has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Ransomware taking down production systems almost always clears this bar — operational disruption is the textbook example, and if the ransomware also affects downstream customers, suppliers, or exposes personal data, the "affecting others" prong is triggered too. Don't spend time debating materiality once production is down; assume reportability and start the clock.

Step 2: The 24-hour early warning. Within 24 hours of becoming aware of the incident, you must submit an "early warning" to your national CSIRT or competent authority. This is deliberately lightweight — it should indicate whether the incident is suspected to be caused by unlawful or malicious action (ransomware clearly is), and whether it could have a cross-border impact (relevant if you operate in multiple member states). You will not have full facts at this stage — that's expected. The clock starts from when you "become aware," which is a defined trigger point, so make sure your incident response playbook has a clear internal escalation path that timestamps awareness (e.g., SOC detection, EDR alert, ransom note discovery) so you can demonstrate you met the deadline.

Step 3: The 72-hour incident notification. Within 72 hours, submit a fuller notification updating the early warning and providing an initial assessment: severity and impact, indicators of compromise if available, and (if known) the threat actor. For ransomware, this is where you'd typically include: which systems/production lines are affected, estimated downtime, whether data exfiltration occurred (increasingly common with double-extortion ransomware), and initial containment actions taken. If you don't have complete information yet, provide what you have and flag it as preliminary — NIS2 does not require certainty at this stage, only good-faith, timely disclosure.

Step 4: Intermediate reports (on request). The competent authority or CSIRT can request a status update at any point during the response if the incident is ongoing. Be prepared for this, particularly if the ransomware event drags on (recovery from backups, forensic investigation, negotiations if applicable).

Step 5: The final report. Within one month of the 72-hour notification (or one month after the incident is resolved if it's still ongoing at that point, with a progress report at the one-month mark and a final report once resolved), submit a final report containing: a detailed description of the incident including severity and impact; the type of threat or root cause that likely triggered it; mitigation measures applied and ongoing; and, where relevant, the cross-border impact of the incident.

Additional considerations specific to ransomware:

- Ransom payment: NIS2 itself doesn't regulate whether you can pay a ransom, but many member states have separate rules, sanctions screening obligations (the threat actor or wallet could be on an EU/OFAC sanctions list), and law enforcement notification expectations. Coordinate with legal counsel before any payment decision — this is a distinct workstream from the NIS2 reporting clock.
- Parallel obligations: Ransomware very often involves personal data compromise, which triggers GDPR Article 33/34 breach notification (72 hours to the supervisory authority, and to affected individuals if high risk) as a separate but overlapping obligation. Map your incident response so one factual timeline feeds both the NIS2 CSIRT notification and any DPA notification, to avoid inconsistent narratives.
- Customer/downstream notification: if the entity providing the service to you or that you provide services to is affected, the competent authority can require or you may need to voluntarily inform affected recipients of your service, particularly where a significant cyber threat is identified that could materially affect them.
- Voluntary reporting: Even for incidents that don't clearly meet the "significant" threshold, NIS2 encourages voluntary notification of near-misses, other cyber threats, and incidents affecting entities outside strict scope — worth knowing since regulators view a mature voluntary-reporting culture favorably.
- Documentation: Because "awareness" timestamps and the good-faith/preliminary nature of early submissions matter for defensibility, maintain a clean incident timeline log from first detection through final report, ideally reviewed by legal/compliance before submission at each stage.

Practical recommendation: Build (or confirm you already have) an incident response runbook that hard-codes these three clocks (24h/72h/1 month) with named owners for each report, a pre-approved communication template, and a decision tree for parallel GDPR/DPA notification, sanctions screening (if ransom payment is considered), and customer notification — so that during an actual live ransomware event your team is executing a rehearsed plan rather than interpreting the regulation for the first time under pressure.

Determining whether you're an Essential Entity (EE) or Important Entity (IE) under NIS2 (Directive (EU) 2022/2555) requires running three tests in sequence — sector, size, and the essential/important split — because Annex I sector membership alone does NOT make you essential; size and designation both matter, and misclassification is the single most common and costly NIS2 error. I don't have your sector, headcount, turnover, or balance sheet, so I'll walk through the framework and flag exactly what I need from you to reach a conclusion, plus what the classification changes in practice either way.

**Step 1 — Sector scope (Annex I vs. Annex II).** Annex I (high-criticality) covers energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure (DNS, cloud, data centres, CDNs, trust services, public electronic communications), ICT service management B2B (MSP/MSSP), public administration, and space. Annex II (other critical) covers postal/courier, waste management, chemicals, food, manufacturing (medical devices, electronics, machinery, motor vehicles), digital providers (marketplaces, search engines, social platforms), and research organisations. If you offer B2B SaaS, note that this generally qualifies as a "cloud computing service" under Art. 6(30) and lands you in Annex I digital infrastructure regardless of how you market it — analyse the actual service model, not the label.

**Step 2 — Size threshold (Art. 2(1), SME Recommendation 2003/361).** You're in scope at all only if you're medium-sized or larger: ≥50 employees, OR annual turnover and balance sheet total both above €10M. Below that, you're generally out of scope — except for a hard-coded list that's in scope regardless of size: qualified trust service providers, TLD registries and DNS providers, sole providers of a critical service in a Member State, entities whose disruption could have significant public-safety/systemic cross-border impact, central government public administration, and any entity a Member State specifically designates.

**Step 3 — Essential vs. Important (Art. 3).** You're an Essential Entity if you're in an Annex I sector AND exceed the large-enterprise ceiling: ≥250 employees, OR turnover >€50M together with balance sheet >€43M. You're also automatically essential regardless of size if you're a qualified trust service provider, TLD registry, DNS provider, a medium-or-larger public electronic communications network/service provider, central government public administration, or an entity designated critical under the CER Directive (EU) 2022/2557 (CER designation flows automatically into essential-entity status under NIS2 Art. 3(1)(f)). Everything else in scope — medium-sized Annex I entities, and all in-scope Annex II entities — defaults to Important Entity, unless your Member State specifically designates you essential.

A worked example that catches people out: a company with 200 employees and €50M turnover in an Annex I sector is in scope (clears the medium threshold) but does not clear the large-enterprise ceiling (needs ≥250 employees, or turnover strictly above €50M plus balance sheet above €43M) — so it defaults to **Important**, not Essential, unless national designation (e.g., under a Member State's specific critical-infrastructure thresholds) or CER designation pushes it up.

**What I need from you to finish this:** your sector/service description (to confirm Annex I vs. II), employee headcount, and annual turnover and balance-sheet total for the relevant financial year, plus whether any entity in your group has been separately designated critical under the CER Directive or by name under national law.

**Why the answer matters — the practical consequences either way:**

| | Essential Entity | Important Entity |
|---|---|---|
| Supervision | Ex-ante *and* ex-post: proactive on-site inspections, regular/targeted/ad-hoc security audits, security scans, evidence requests (Art. 32) | Ex-post only: triggered by evidence or indication of non-compliance (Art. 33) |
| Enforcement | Warnings, binding instructions, remediation orders, audit orders, public disclosure orders, and ultimately temporary suspension of certification/authorisation or of managerial duties | Warnings, binding instructions, remediation orders, audit orders — no suspension power |
| Maximum fine (Art. 34) | Higher of €10,000,000 or 2% of total worldwide annual turnover | Higher of €7,000,000 or 1.4% of total worldwide annual turnover |
| Management liability | Personal liability, with possible temporary ban from managerial functions | Personal liability |

Importantly, the substantive obligations are identical regardless of classification: both tiers must meet the Art. 20 governance requirements (management body approval, oversight, and training) and the Art. 21(2) ten-measure risk-management programme, and both face the same Art. 23 incident-reporting clock (24h/72h/1-month). Classification changes how proactively you'll be supervised and your penalty ceiling — not whether the underlying security programme is required. Send me the sector, headcount, and financial figures and I'll give you a definitive classification with the supervisory and jurisdictional consequences spelled out.

I can't tell you definitively whether you're an "essential" or "important" entity without knowing your sector, size, and specific role in your national economy — that classification is fact-specific and ultimately confirmed by your competent authority or self-assessed against the criteria in the transposed national law. What I can do is give you the classification test to run and explain why the distinction matters in practice.

How the essential/important split works under NIS2:

First, sector test. NIS2 splits covered sectors into two annexes. Annex I lists "sectors of high criticality": energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure (cloud, data centers, DNS, TLD registries, trust services, public electronic communications), ICT service management (managed service providers, managed security service providers), public administration, and space. Annex II lists "other critical sectors": postal/courier services, waste management, chemicals manufacturing/distribution, food production/processing/distribution, manufacturing (medical devices, computers/electronics, machinery, motor vehicles), digital providers (online marketplaces, search engines, social networking platforms), and research organisations.

Second, size test (the general rule). Within Annex I sectors, medium and large entities (50+ employees or €10M+ annual turnover/balance sheet) are essential entities. Within Annex II sectors, medium and large entities are important entities. Small and micro entities are generally out of scope entirely, unless they meet special criteria below.

Third, the exceptions that override the size test. Regardless of size, an entity is automatically essential if it is: the sole provider of a service critical for maintenance of vital societal/economic activities in a member state; identified as critical under the separate CER Directive (Critical Entities Resilience); a public administration entity of central government (or, at member state discretion, regional level); a qualified trust service provider or TLD registry/DNS provider (these are essential regardless of size); or an entity whose disruption could have significant systemic effects or cross-border impact. Member states can also designate specific entities as essential or important individually, and can lower the size thresholds for particular sectors if justified by risk.

Fourth, some Annex I entities are essential purely by category regardless of size test outcome — for example DNS service providers, TLD registries, and qualified trust service providers are always essential; while Annex I entities not fitting these auto-categories fall to essential (if medium/large) via the general size rule.

Why the distinction matters practically:

1. Supervisory regime — this is the biggest practical difference. Essential entities are subject to proactive, ex-ante supervision: competent authorities can conduct regular audits, on-site inspections, security scans, and request information even without a prior incident or complaint. Important entities are subject to reactive, ex-post supervision only — the authority generally only investigates after evidence of a problem (an incident, a complaint, a tip) comes to light. This is a materially lighter supervisory burden for important entities in day-to-day terms.

2. Fines — essential entities face administrative fines up to €10,000,000 or 2% of total global annual turnover (whichever is higher); important entities face up to €7,000,000 or 1.4% of global turnover (whichever is higher). Both are calibrated to be dissuasive, but the essential-entity ceiling is notably higher.

3. Registration and identification — essential entities are more likely to be individually identified/registered by the competent authority (with obligations to provide extensive information), whereas important entities in many national schemes self-identify and self-register within a set timeframe after the law's entry into force.

4. Substantive obligations are the same either way — this is the part people often get wrong. Article 21 risk-management measures (the ten-point list: risk analysis, incident handling, business continuity, supply chain security, security in acquisition/development, effectiveness assessment, cyber hygiene/training, cryptography, HR/access control/asset management, and use of MFA/secure communications) and Article 23 incident reporting obligations (24h/72h/1-month) apply identically to both essential and important entities. So "important" does not mean "less compliance work" — it means "less proactive government scrutiny," not "fewer requirements to meet."

Recommended next step: Map your specific entity (or each subsidiary, since classification is done per legal entity, not per group) against the sector list and size thresholds above, flag any auto-essential triggers (sole provider, DNS/trust service, public administration, CER-designated), and then confirm the outcome against your national transposition law's registration/notification requirements — since some member states add sector-specific nuances or lower thresholds. I'd be glad to help build that mapping exercise if you share your sector(s), headcount, and turnover for each entity in scope.

NIS2 (Directive (EU) 2022/2555) Art. 21(2) requires essential and important entities to implement ten categories of "appropriate and proportionate technical, operational and organisational measures" (Art. 21(1)) to manage cybersecurity risk. Proportionality is assessed against your size, risk exposure, likelihood/severity of incidents, and cost of implementation — a 50-person important entity and a 3,000-person essential entity both must cover all ten, but the depth and tooling expected differ. The ten measures, Art. 21(2)(a) through (j):

**(a) Risk analysis and information security policies.** Adopt a formal methodology (ISO 27005, NIST RMF, or equivalent), maintain an asset inventory of in-scope systems, define risk-acceptance criteria, and review at least annually and after major incidents or changes. The management body must approve this policy (links to Art. 20).

**(b) Incident handling.** A written Incident Response Plan covering detection, analysis, containment, eradication, and recovery, with defined "significant incident" thresholds (Art. 23(3)), pre-drafted CSIRT notification templates, post-incident reviews, and at least annual tabletop testing.

**(c) Business continuity, backup, and disaster recovery.** Defined RTO/RPO per critical service, automated encrypted offsite backups tested (ideally quarterly), DR runbooks and failover playbooks, and a crisis management structure with clear roles and escalation — tested at least annually with management body involvement.

**(d) Supply chain security.** A register of critical ICT suppliers, pre-onboarding security assessments, contractual security obligations (right-to-audit, incident-notification SLAs, minimum baselines), supply chain risk folded into your annual risk assessment, and monitoring of the EU-level coordinated risk assessments run under Art. 22 (Cooperation Group, Commission, ENISA) for high-risk vendor categories.

**(e) Secure acquisition, development, and maintenance.** Secure SDLC practices (threat modelling, code review, SAST/DAST, pentesting), a vulnerability management programme with severity-based patch SLAs, a coordinated vulnerability disclosure policy aligned to ENISA guidelines, and CVE tracking for in-scope systems.

**(f) Effectiveness assessment.** KPIs/KRIs per measure (mean time to detect, patch compliance, training completion), at least annual internal audits or management reviews, independent third-party assessment where appropriate, and a feedback loop from findings into the risk register.

**(g) Basic cyber hygiene and training.** Mandatory annual security awareness training for all staff (phishing, social engineering, password hygiene, incident reporting, remote work), role-based training for administrators and responders, and — critically — training extended to the management body itself, since that's an explicit Art. 20 requirement, not optional.

**(h) Cryptography.** A policy defining approved algorithms (e.g., AES-256 at rest, TLS 1.2+ in transit, SHA-256/384 for hashing), a key management lifecycle (generation, storage — HSM for critical keys — rotation, destruction), mandatory encryption for sensitive cloud data and portable media, and periodic review given evolving threats including post-quantum planning.

**(i) Human resources security, access control, and asset management.** Least-privilege/need-to-know access, RBAC reviewed quarterly, background screening for privileged roles (subject to local employment law), an authoritative asset inventory, a joiners/movers/leavers process with same-day revocation on exit, and dormant-account disablement after 30–90 days.

**(j) MFA, secured communications, and emergency systems.** MFA (or continuous authentication) required for all remote access, privileged accounts, and cloud management consoles, phishing-resistant MFA (FIDO2/hardware tokens) for your highest-privilege accounts, end-to-end encrypted channels for sensitive internal communications, and a documented emergency communication plan with out-of-band channels for use if primary systems are compromised.

**Two things to layer on top of the ten measures:**

First, if you're a DNS provider, TLD registry, cloud/data centre/CDN provider, MSP/MSSP, trust service provider, or an online marketplace/search/social platform, Commission Implementing Regulation (EU) 2024/2690 makes these ten measures binding and audit-level: it decomposes them into 13 Annex sections with granular sub-requirements (e.g., splitting measure (i) across HR security, access control, and asset management sections, and adding a physical/environmental security section) and defines quantitative significant-incident thresholds. For every other sector, that regulation is persuasive best practice and the de-facto technical benchmark, but not directly binding — don't treat it as a legal requirement if you're outside that entity list.

Second, if you're already ISO 27001:2022 certified, you have strong evidence for measures (a), (b), (c), (e), (f), and (i), but certification is not a safe harbor: it does not by itself satisfy the Art. 23 reporting timelines, the Art. 20 personal-accountability and training obligations, Art. 27 registration, or the explicit MFA/cryptography language in (h) and (j) — ISO 27001's Annex A.8.5 covers authentication generally but doesn't mandate MFA. Map your certification evidence against the ten measures specifically and close those four gaps rather than assuming the certificate covers you.

Recommended next step: run a gap assessment rating each of the ten measures (at the 2024/2690 sub-point level if you're a relevant digital entity) as Compliant / Partial / Gap, prioritizing quick wins (MFA rollout, board training records) within 30 days and structural work (SDLC overhaul, supplier contract renegotiation) within six months.

Article 21 of NIS2 sets out the substantive cybersecurity risk-management obligation that applies equally to essential and important entities. It's written as a principles-based, "appropriate and proportionate" requirement rather than a prescriptive technical checklist, but it does enumerate ten specific domains that your measures must cover at minimum. Here's a practical walkthrough of each.

Overarching standard first: Article 21(1) requires entities to take "appropriate and proportionate technical, operational and organisational measures" to manage risks to the security of network and information systems, based on an "all-hazards approach" (meaning you must address not just cyberattacks but also natural disasters, human error, hardware/environmental failures, and third-party/supply chain issues). Proportionality is assessed against your degree of risk exposure, size, likelihood/severity of incidents, and cost of implementation — so this is not a one-size-fits-all technical spec, and a small important entity is not expected to implement the same controls as a large essential entity.

The ten Article 21(2) domains:

1. Risk analysis and information system security policies. You need a documented risk assessment methodology and formal security policies covering your network and information systems — not a one-time exercise but an ongoing process feeding into your other controls.

2. Incident handling. Processes for detecting, analyzing, containing, and responding to incidents — this is what feeds your Article 23 reporting obligations (24h/72h/1-month clocks), so your incident handling procedure and your regulatory reporting procedure need to be integrated, not separate documents.

3. Business continuity and crisis management, including backup management and disaster recovery. Tested backup regimes, recovery time/point objectives, and a crisis management plan — directly relevant to ransomware scenarios where production systems go down.

4. Supply chain security, including security-related aspects concerning relationships between each entity and its direct suppliers or service providers. This extends your obligation beyond your own perimeter — you're expected to assess and manage risk from vendors, especially ICT/managed service providers, and NIS2 explicitly flags that entities should account for vulnerabilities specific to each supplier and the overall quality of products/practices, including secure development procedures of suppliers.

5. Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure. Secure SDLC practices, patch management, and a vulnerability disclosure process.

6. Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. This means you need to actually test and measure whether your controls work — audits, penetration testing, metrics/KPIs — not just have policies on paper.

7. Basic cyber hygiene practices and cybersecurity training. Includes things like patching, password policies, network segmentation, and — importantly — training obligations that extend to management bodies specifically (tying back to Article 20's requirement that management approve and be trained on risk-management measures, with personal accountability for non-compliance).

8. Policies and procedures regarding the use of cryptography and, where appropriate, encryption. Encryption at rest/in transit where risk-appropriate, and key management practices.

9. Human resources security, access control policies, and asset management. Includes onboarding/offboarding procedures, least-privilege access, role-based access control, and maintaining an accurate asset inventory (you can't secure what you don't know you have).

10. The use of multi-factor authentication or continuous authentication solutions, secured voice/video/text communications, and secured emergency communication systems within the entity where appropriate. MFA is called out explicitly and is one of the more concrete, auditable items — regulators are likely to treat "no MFA on privileged/remote access" as a clear gap.

Practical implementation notes:

- Governance link (Article 20): management bodies must approve the risk-management measures under Article 21 and oversee their implementation, and must undergo training. This creates a direct line of accountability from the board/exec team down to these ten domains — you can't delegate Article 21 entirely to IT/security without documented management approval and oversight.
- Mapping to existing frameworks: Article 21's ten domains map reasonably well to ISO/IEC 27001 Annex A controls, NIST CSF functions, and CIS Controls — if you already have a mature ISMS, you likely have most of the substance in place and this becomes a gap-mapping and documentation exercise rather than a build-from-scratch effort. ENISA and national CSIRTs have published (or are expected to publish) more detailed technical implementing guidance/harmonized standards to reduce ambiguity on "appropriate and proportionate."
- Supply chain is the domain most organizations underestimate — Article 21(2)(d) means you need vendor risk assessments, security clauses in contracts, and visibility into subcontractor practices, not just your own controls.
- Documentation matters as much as implementation, since supervisory authorities (especially for essential entities, which face proactive audits) will expect to see evidence: policies, risk assessments, training records, test results, and incident logs, not just an assertion that controls exist.

Recommended next step: Run a structured gap assessment mapping your current controls (e.g., against ISO 27001 or NIST CSF if you have one) to these ten Article 21(2) domains, prioritize supply chain security and MFA/access control if those are commonly weak spots, and make sure Article 20 governance evidence (board approval, management training records) exists alongside the technical controls, since auditors will look for both.

# CCPA/CPRA Applicability Analysis

## Are you subject to CCPA/CPRA?

**Yes.** A for-profit business is covered if it meets **at least one** of three thresholds:

| # | Threshold | Exact Figure | Your Facts |
|---|---|---|---|
| 1 | Annual gross revenue | Exceeds **$25 million** in the preceding calendar year | You're at **$30M** — exceeds threshold |
| 2 | Data volume | Annually buys, sells, receives, or shares PI of **100,000+** consumers/households | Your **80,000 CA customers/year** does *not* independently meet this threshold |
| 3 | Revenue from data monetization | Derives **50%+** of annual revenue from selling/sharing PI | Not indicated — assumed not met |

Because you only need to meet **one** threshold, your **$30M in annual gross revenue** alone brings you within scope of CCPA/CPRA, regardless of the fact that your California customer data volume (80,000) falls short of the 100,000-consumer/household threshold. You are a covered "business" under Cal. Civ. Code §1798.100 et seq. (CCPA, effective 2020) as amended by the CPRA (effective 2023).

*Note: revenue and data-volume thresholds must be reassessed annually* — if your California customer base grows past 100,000/year that's a second independent basis for coverage, but it isn't necessary here since you already qualify on revenue.

## Core Obligations

### 1. Classify your downstream data recipients
Before anything else, determine who you share PI with and how:

| Classification | Definition | Sale? |
|---|---|---|
| **Service Provider** | Processes PI on your behalf under a contract prohibiting further use beyond the specified business purpose | Not a sale |
| **Contractor** (CPRA) | Receives PI under a contract prohibiting other use; must certify compliance | Not a sale |
| **Third Party** | Receives PI but isn't a service provider or contractor | May constitute a sale or sharing |

Vendor classifications should be reassessed whenever a contract is renewed or a new recipient is onboarded.

### 2. Build consumer rights fulfillment processes
You must be able to honor:
- **Right to Know** — specific pieces/categories of PI, sources, purposes, third parties (45 days + optional 45-day extension)
- **Right to Delete** — delete PI, propagate to service providers/contractors, subject to enumerated exceptions (45 days + extension)
- **Right to Correct** (CPRA) — correct inaccurate PI (45 days + extension)
- **Right to Opt-Out of Sale/Sharing** — "Do Not Sell or Share" link, honor GPC signals, effectuate within 15 business days
- **Right to Limit SPI Use** (CPRA) — if you use sensitive personal information beyond permitted purposes (15 business days)
- **Right to Non-Discrimination** — cannot penalize consumers for exercising rights

**Response timeline (applies across all request types):** confirm receipt within **10 business days**, describing your verification process; substantive response within **45 calendar days**, extendable once by another 45 days with notice; opt-out/limit requests effectuated within **15 business days**.

**Intake channels:** provide at least two request-submission methods (an e-commerce business can typically use a web form plus email; a toll-free number is required where applicable).

**Identity verification:** 2-data-point match for standard requests (know categories, delete non-sensitive data); 3-data-point match plus signed perjury declaration for sensitive requests (specific pieces of PI, deletion of sensitive data). Opt-out requests require no identity verification beyond reasonable confirmation.

**Free of charge:** twice per 12-month period.

### 3. Publish required notices
- **Privacy Notice at Collection** — categories of PI collected, purposes, whether sold/shared, retention periods, link to full policy — delivered at or before collection
- **Privacy Policy** — comprehensive disclosures on categories, purposes, third parties, consumer rights, contact info, and the "Do Not Sell or Share My Personal Information" link; update annually

### 4. Stand up opt-out mechanisms
- "Do Not Sell or Share My Personal Information" homepage link
- Honor **Global Privacy Control (GPC)** signals as a valid opt-out
- "Limit the Use of My Sensitive Personal Information" link, if applicable
- **ADMT opt-out** — only relevant if you use automated decision-making with legal/significant effects; regulations effective January 1, 2026, implementation deadline **January 1, 2027**

### 5. Apply data minimization, purpose limitation, and retention limits (CPRA)
Only collect PI adequate, relevant, and limited to your disclosed purpose; disclose and adhere to retention periods; don't repurpose PI for undisclosed uses.

### 6. Update vendor contracts
Contracts with service providers/contractors must include purpose limitations, prohibition on further sale/sharing, cooperation with consumer requests, audit rights, and deletion obligations.

### 7. Cybersecurity audits & risk assessments (effective January 1, 2026)
If your processing presents **significant risk** to consumers, you must conduct **annual cybersecurity audits** and document **risk assessments** before high-risk processing, producible to the CPPA on request. As an e-commerce business handling payment and customer data at meaningful scale, you should evaluate whether this applies to you now that the regulations are live.

## Penalty Exposure

- Unintentional violations: up to **$2,500 per violation**
- Intentional violations: up to **$7,500 per violation**
- Violations involving minors' PI: up to **$7,500 per violation** (always treated as intentional)
- **Private right of action** (data breach only): $100–$750 per consumer per incident, class-action eligible
- A **30-day cure period** applies to AG actions

Recent CPPA enforcement (2026) illustrates real exposure at your scale: **Ford Motor Company was fined $375K** specifically for failing to process deletion and access requests within the required timeframes — a reminder that missing the 45-day deadline is itself an actionable violation, not just a procedural lapse. Given you're an e-commerce business relying on ad tech/analytics vendors, also review whether any of those integrations constitute a "sale" or "sharing," since **The Walt Disney Company's $2.75M fine** (the largest CCPA enforcement to date) involved third-party ad tech data-sharing deficiencies.

## Recommended Next Steps
1. Document your threshold determination (revenue basis) and file it for annual reassessment.
2. Inventory all PI flows and classify every downstream recipient (service provider / contractor / third party).
3. Stand up or audit your rights-intake process against the 10-business-day acknowledgment / 45-day response deadlines.
4. Confirm your homepage has a working "Do Not Sell or Share" link and GPC signal handling.
5. Evaluate whether your processing triggers the cybersecurity audit and risk assessment obligations effective January 1, 2026.
6. Refresh your privacy notice at collection and privacy policy to ensure CPRA-era disclosures (retention periods, SPI categories, etc.) are current.

*This is general compliance information, not legal advice. Consult qualified counsel or an accredited assessor for your specific determination.*

# CCPA/CPRA Applicability and Core Obligations

## Are You Subject to CCPA/CPRA?

The CCPA, as amended by the CPRA, applies to a "business" that does business in California, determines the purposes and means of processing consumers' personal information, and meets **at least one** of the following thresholds:

1. Had annual gross revenues in excess of **$25 million** (as of the preceding calendar year); **or**
2. Buys, sells, or shares the personal information of **100,000 or more** California consumers or households annually; **or**
3. Derives **50% or more** of annual revenue from selling or sharing California consumers' personal information.

**Your situation:** With $30M in annual revenue, you exceed the $25M revenue threshold (Criterion 1) on that basis alone. It does not matter that you only collect data on 80,000 California customers (below the 100,000 threshold for Criterion 2) — meeting **any one** criterion is sufficient. Because your revenue exceeds $25M, **you are very likely subject to the CCPA/CPRA**, assuming you also do business in California and determine the purposes/means of processing personal information (which as an e-commerce company selling to California customers, you do).

Note: Confirm the $25M figure is calculated correctly — it's total annual gross revenue of the business (not just California revenue), measured as of January 1 of the calendar year.

## Core Obligations

Once covered, your core CCPA/CPRA obligations include:

### 1. Notice Obligations
- **Notice at Collection**: Inform consumers, at or before the point of collection, what categories of personal information you collect and for what business/commercial purposes, whether you sell/share it, and retention periods.
- **Privacy Policy**: Maintain a comprehensive, publicly posted privacy policy updated at least every 12 months, describing consumer rights, categories of PI collected/disclosed/sold/shared in the past 12 months, and how to exercise rights.

### 2. Consumer Rights You Must Honor
- **Right to Know** what personal information is collected, used, disclosed, and sold/shared
- **Right to Delete** personal information (subject to exceptions)
- **Right to Correct** inaccurate personal information
- **Right to Opt-Out** of sale/sharing of personal information (including a "Do Not Sell or Share My Personal Information" link, or honoring Global Privacy Control signals)
- **Right to Limit Use of Sensitive Personal Information** (if you collect SPI)
- **Right to Non-Discrimination** for exercising these rights (can't charge different prices or deny service, though you can offer legitimate financial incentives)
- **Right to Data Portability**

### 3. Operational Requirements
- Provide **at least two methods** for submitting requests to know/delete (e.g., toll-free number and website form)
- Respond to verifiable consumer requests within **45 days** (extendable by another 45 days with notice)
- Implement **reasonable identity verification** procedures proportionate to the sensitivity of the data
- Maintain records of consumer requests and how they were handled for at least 24 months

### 4. Contracts with Service Providers/Third Parties
- Execute CCPA-compliant contracts with any **service providers, contractors, or third parties** that receive personal information, including required data protection clauses (purpose limitation, prohibition on combining data, audit rights, etc.)

### 5. Data Minimization & Purpose Limitation
- Collect only personal information that is reasonably necessary and proportionate for the disclosed purposes
- Do not use personal information for materially different purposes without notice

### 6. Security
- Implement and maintain **reasonable security procedures and practices** appropriate to the nature of the personal information, to protect against unauthorized access, destruction, use, modification, or disclosure.

### 7. Employee Training
- Ensure individuals responsible for handling consumer inquiries about privacy practices are informed of CCPA requirements.

### 8. Cybersecurity Audits and Risk Assessments (CPRA additions)
- If your processing presents significant risk to consumer privacy or security, you may need to conduct **annual cybersecurity audits** and submit **risk assessments** to the California Privacy Protection Agency (CPPA), per regulations being phased in.

### 9. California Privacy Protection Agency (CPPA) Oversight
- The CPPA (created by CPRA) has rulemaking and enforcement authority, alongside the California Attorney General. Since January 2023, the CCPA's prior 30-day cure period for violations was eliminated for most violations, so enforcement risk is more immediate — the CPPA/AG can pursue penalties without giving you a chance to fix the issue first (though they retain discretion to consider cure efforts).

## Practical Next Steps
1. Confirm applicability calculation (verify $25M threshold basis) and document it.
2. Map your data flows: what personal information you collect, from whom, why, how long you keep it, and who you share it with.
3. Determine if you "sell" or "share" personal information (e.g., via advertising pixels/cookies, analytics, ad networks) — this triggers opt-out obligations.
4. Update your privacy policy and notice-at-collection language.
5. Stand up a consumer rights request intake and fulfillment process (with identity verification tiers).
6. Audit and update vendor contracts to include CCPA-required terms.
7. Implement a "Do Not Sell or Share My Personal Information" link or honor Global Privacy Control (GPC) signals if you engage in selling/sharing.
8. Conduct a data security review against "reasonable security" expectations.

**Disclaimer**: This is general information, not legal advice. Given the civil penalty exposure and CPPA enforcement activity, I'd recommend confirming your specific applicability analysis and compliance program design with California privacy counsel.

# Handling a Combined Right to Know + Right to Delete Request

You've received two simultaneous requests from a California resident: (1) a **Right to Know** request for specific pieces of PI, and (2) a **Right to Delete** request. Handle them as related but distinct workflows — verification and exception analysis differ slightly for each.

## Step 0: Intake & Logging
Log both requests with a timestamp upon receipt. You must have provided at least two intake channels (§1798.130) — e.g., a web form/email plus a toll-free number where applicable — so confirm which channel was used.

**Acknowledge receipt within 10 business days**, describing your verification process to the consumer (Regs §7021(a)).

## Step 1: Identity Verification — Tiered Standard

Because the consumer is requesting **specific pieces of PI** (not just categories) and **deletion**, use the higher verification tier:

- **Reasonably high degree of certainty** standard applies to: specific-pieces-of-PI requests and deletion of sensitive data. This requires matching **at least 3 data points** the business already holds, **plus a signed declaration under penalty of perjury** that the requestor is the consumer.
- If the deletion request only concerns non-sensitive PI, the lower **reasonable degree of certainty** standard (2 data points) would suffice for the deletion portion — but since they've also asked for specific pieces of PI, apply the 3-point + declaration standard to cover both requests consistently.

**If verification fails:**
- A right-to-know request for specific pieces that cannot be verified must be answered with **categories of PI instead** (not denied outright).
- A **deletion request that cannot be verified is denied as a deletion, but must be treated as an opt-out of sale/sharing** where applicable (Regs §7022(f)) — you cannot simply drop the request.

If the request comes through an authorized agent, require written permission from the consumer plus verification of the agent's identity; you may also require direct verification with the consumer.

## Step 2: Right to Know — Workflow

| Step | Action |
|---|---|
| 1 | Receive and log request with timestamp |
| 2 | Verify identity (3-point match + perjury declaration, per above) |
| 3 | Search all PI systems (CRM, analytics, ad tech, order history, support tickets, etc.) |
| 4 | Compile responsive PI — specific pieces, categories, sources, purposes, categories of third parties PI was disclosed/sold/shared to |
| 5 | Apply exceptions (see below) |
| 6 | Deliver in a portable, readily usable format within 45 days |
| 7 | If needed, send extension notice **within the original 45-day window** |

**Scope:** default lookback is 12 months prior to the request, but for PI collected on or after January 1, 2022, the consumer may request information beyond 12 months and you must provide it **unless doing so is impossible or would involve disproportionate effort**.

**Exceptions you may invoke to withhold specific items:**
- Disclosure would reveal third-party trade secrets
- Would conflict with federal/state law
- PI collected for a single one-time transaction and not retained
- PI used solely for internal operations consistent with the context of collection
- PI used solely to complete the transaction for which it was collected

## Step 3: Right to Delete — Workflow

| Step | Action |
|---|---|
| 1 | Receive and log deletion request |
| 2 | Verify identity |
| 3 | Check whether any exception applies; **document your reasoning** if invoking one |
| 4 | **Execute** — if proceeding, identify all PI records and direct service providers/contractors to delete their copies |
| 5 | **Confirm** — notify the consumer of deletion (or explain the exception invoked) within 45 days |
| 6 | Retain deletion-request records as proof of compliance (retaining the request record itself does not contradict the deletion) |

**Exceptions that let you retain PI instead of deleting it:**
1. Necessary to complete a transaction or perform a contract
2. Necessary to detect security incidents or protect against malicious/deceptive/fraudulent/illegal activity
3. Necessary to fix errors impairing intended functionality
4. Necessary to exercise free speech or ensure another consumer's free-speech right
5. Necessary to comply with a legal obligation (§1798.145(a))
6. Necessary for internal purposes compatible with the context of collection (limited CPRA exception)
7. Necessary for research, journalism, or statistical purposes in the public interest

If you invoke an exception for some but not all data, delete what isn't covered and explain to the consumer which categories were retained and why.

## Step 4: Response Deadlines
- Substantive response for **both** requests: **45 calendar days**, extendable once by another **45 days** with notice to the consumer sent within the original window.
- Recent enforcement underscores the stakes here: the CPPA fined **Ford Motor Company $375K** specifically for failing to process access and deletion requests within the required timeframes — missing the 45-day deadline is itself an actionable violation, not a mere technicality.

## Step 5: Cost
Fulfill both requests **free of charge** — this counts toward the consumer's **two free requests per 12-month period**. A reasonable fee may apply only to additional requests within that window if manifestly unfounded or excessive.

## Step 6: Non-Discrimination
Regardless of outcome, you cannot deny service, change pricing, or degrade service quality because this consumer exercised their rights (§1798.125).

## Summary Checklist
- [ ] Acknowledge receipt within 10 business days, describing verification process
- [ ] Verify identity: 3 data points + signed perjury declaration (specific pieces + deletion)
- [ ] Search all systems for responsive PI
- [ ] Evaluate and document any exceptions invoked for know or delete
- [ ] Deliver right-to-know response in portable format
- [ ] Execute deletion and propagate to service providers/contractors
- [ ] Confirm both outcomes to consumer — within 45 days (or 90 with timely extension notice)
- [ ] No charge (within free-request allowance)
- [ ] Retain records per your record-keeping policy (mandatory 24-month retention if you handle PI of 10M+ consumers/households)

*This is general compliance information, not legal advice. Consult qualified counsel for case-specific verification or exception decisions.*

# Handling a Combined CCPA/CPRA Right to Know + Right to Delete Request

When a California resident submits both a **Right to Know** (access) request and a **Right to Delete** request, you need a coordinated process. Here's a step-by-step walkthrough.

## Step 1: Log and Acknowledge the Request

- Record the date received, the requestor's identity/contact info, and which rights are being invoked (know + delete).
- Confirm receipt within **10 business days**, describing your verification process and expected response timeline.
- You have **45 calendar days** from receipt to respond substantively (extendable once by another 45 days if reasonably necessary, with notice to the consumer explaining the delay).

## Step 2: Identity Verification

Verification must be reasonable and proportionate to the sensitivity of the data and the risk of harm from improper disclosure/deletion.

- **For a Right to Know (specific pieces of data) request**: Requires a higher standard of verification (e.g., matching 2-3 data points you already hold, such as name, email, account number, plus possibly a signed declaration under penalty of perjury) because disclosing specific personal information to the wrong person is high-risk.
- **For a Right to Delete request**: Also requires reasonable verification, though if you can't verify the requestor to the standard needed for deletion, you can treat it as a request to opt-out of sale/sharing instead (a lower bar), or ask for additional information.
- **If using a password-protected account**: You can verify through the existing authentication method (e.g., login + re-authentication), which is often sufficient.
- **If you cannot verify**: You may deny the request, but must explain why and, where feasible, offer the consumer another way to submit information for verification. Do not require the consumer to pay a fee or create an account they don't already have, just to submit a request.
- Document your verification decision and rationale for audit purposes.

## Step 3: Handle the Right to Know Request

1. **Search all systems** (CRM, marketing platforms, data warehouses, support tickets, analytics, backups if reasonably accessible, third-party processors acting as service providers) for personal information tied to the verified identity.
2. Compile a response that includes, for the preceding 12 months (or since collection if you offer more):
   - Categories of personal information collected
   - Categories of sources
   - Business/commercial purposes for collecting/selling/sharing
   - Categories of third parties with whom you've disclosed, sold, or shared PI
   - The **specific pieces of personal information** collected about that individual (this is the more detailed "right to know specific pieces" version, distinct from the general categories disclosure required in your privacy policy)
3. Deliver the response in a **portable, readily usable format** that allows the consumer to transmit the information to another entity without hindrance (commonly a downloadable file, e.g., CSV or PDF), or by mail if requested.
4. Do not disclose certain sensitive identifiers even in response to a verified request — e.g., **Social Security numbers, driver's license numbers, financial account numbers, health/medical IDs, account passwords/security Q&A** should generally be redacted or not disclosed in full even to the verified consumer, to avoid creating a security risk.

## Step 4: Handle the Right to Delete Request

1. Once identity is verified, delete personal information from your records **and direct service providers/contractors to delete it as well**, unless an exception applies.
2. **Common exceptions that allow you to retain data** (you may deny deletion, in whole or part, if the data is necessary to):
   - Complete the transaction, provide a good/service requested, or fulfill a warranty/product recall
   - Detect security incidents, protect against malicious/fraudulent/illegal activity, or prosecute those responsible
   - Debug to identify/repair errors that impair existing intended functionality
   - Exercise free speech, or another consumer's right to free speech
   - Comply with the California Electronic Communications Privacy Act
   - Engage in public/peer-reviewed scientific, historical, or statistical research in the public interest (with consent/de-identification safeguards)
   - Enable solely internal uses reasonably aligned with consumer expectations based on the relationship
   - Comply with a **legal obligation** (e.g., tax records, financial recordkeeping requirements)
   - Otherwise use the information internally, lawfully, in a manner compatible with the context in which it was provided
3. For any data retained under an exception, you should **document which exception applies** and, if practical, tell the consumer which categories were deleted vs. retained and why.
4. If you sold or shared the personal information with third parties, you must also **notify those third parties** to delete the data, unless doing so is impossible or involves disproportionate effort.

## Step 5: Order of Operations (Know vs. Delete)

Best practice: **process the Right to Know request first (or simultaneously), then process deletion.** If you delete first, you may destroy the very data needed to fulfill the access request. Many companies compile the "know" disclosure package, deliver or finalize it, and then execute deletion — or do both in parallel using a snapshot taken at verification time.

## Step 6: Respond to the Consumer

- Provide a **combined response letter/portal notification** addressing both requests: what was disclosed (attach or link to the data), and what was deleted vs. retained (with exception basis cited for retained data).
- Confirm deletion has been completed (or will be completed within the applicable timeframe) and that service providers/third parties were instructed accordingly.
- If you denied all or part of either request, explain why (e.g., failed verification, applicable exception) and inform them of their right to appeal or complain to the CPPA/Attorney General.

## Step 7: Recordkeeping

- Retain records of the request, verification steps, and actions taken for at least 24 months for compliance/audit purposes, but do not retain more personal information than needed for this purpose.

## Practical Tips
- Use a standardized intake form/workflow (web form, toll-free number, or both, as required) to reduce ad hoc handling.
- Train customer service staff to recognize and route these requests promptly — mishandled or ignored requests are a common enforcement trigger.
- If you operate a "right to know" and "right to delete" workflow through a Data Subject Request (DSR) management tool, make sure it covers all your data systems, not just your primary CRM.

**Disclaimer**: This is general guidance, not legal advice. If in doubt about verification standards or exception applicability for a specific request, consult California privacy counsel.

# Is Passing Cookie IDs/Browsing Data to an Ad Tech Platform a "Sale" or "Sharing"?

## Short answer: Yes — almost certainly "Sharing" (and potentially also a "Sale")

Any pipeline that passes PI — cookie IDs, device fingerprints, hashed emails, IP addresses, browsing data — to an ad tech platform, ad exchange, DMP, or similar partner **for cross-context behavioral advertising is "sharing" under CPRA, even if no money changes hands**. Given your description (an ad tech platform receiving visitor cookie IDs and browsing data to serve targeted ads), this is a textbook cross-context behavioral advertising data flow.

- **Sale**: disclosure of PI to a third party for monetary **or other valuable consideration** — broadly defined, can include non-cash value exchanges (e.g., reciprocal data access, discounted ad rates).
- **Sharing** (CPRA addition): disclosure of PI to a third party for **cross-context behavioral advertising**, regardless of whether any consideration is exchanged.

Because targeted advertising by definition uses a consumer's behavior across contexts (your site + other properties) to serve ads, this flow triggers "sharing" at minimum. If your ad tech vendor also pays you or provides other valuable consideration for the data, it may additionally constitute a "sale." Either classification carries the same core obligation: it must be covered by your opt-out mechanism.

## Why the Service-Provider Workaround Doesn't Apply Here

You cannot avoid "sharing" classification by simply signing a restrictive contract with the ad tech vendor. Under Regs §7050(c): **a person who contracts with a business to provide cross-context behavioral advertising is a third party, not a service provider or contractor, with respect to those services** — no matter how the contract is worded. Restricted-use contract terms cannot convert a CCBA disclosure into service-provider activity.

- Your ad tech platform is a **third party** for this data flow, not a service provider/contractor.
- Service providers may still perform **contextual** advertising (ads based on the current page/session, not cross-context profiling) and non-CCBA marketing services without triggering "sharing" — but that's a narrower activity than what you've described.
- If this vendor also handles opted-out consumers' PI, it must not combine that PI with PI from other sources.

**Contrast:** first-party analytics tools that don't disclose PI to third parties are typically unaffected and don't require opt-out coverage.

## What You Need to Do

### 1. Update your privacy policy and notice at collection
Disclose that PI (cookie IDs, browsing data) is shared with third parties for cross-context behavioral advertising, list the categories of PI and categories of third parties involved.

### 2. Implement the "Do Not Sell or Share My Personal Information" opt-out link
Prominently placed on your homepage and in your privacy policy.

### 3. Honor Global Privacy Control (GPC) signals
The CPPA has confirmed GPC compliance is required — GPC must be treated equivalently to a manual opt-out click. No separate identity verification is required to act on an opt-out; only reasonable confirmation the requester is the consumer.

### 4. Build the opt-out propagation workflow

| Step | Action |
|---|---|
| 1 | Consumer submits opt-out via link, form, or GPC signal |
| 2 | No identity verification required beyond reasonable confirmation |
| 3 | Update your consent/preference management platform within **15 business days** |
| 4 | Propagate the opt-out to the ad tech platform and any other service providers/contractors engaged in sale/sharing |
| 5 | Do not re-contact the consumer for **12 months** to ask them to reconsider |

### 5. Reclassify the vendor relationship in your records
Update your vendor/data-flow inventory to reflect the ad tech platform as a **third party**, not a service provider, for this specific integration. A mismatch between contractual classification and actual data flow is one of the most common gap-assessment findings — don't let a "service provider" label in the contract paper over what's actually a CCBA disclosure.

### 6. Check whether this data flow also implicates Sensitive Personal Information
If browsing/cookie data is combined with precise geolocation, health signals, or other SPI categories, you may also need the "Limit the Use of My Sensitive Personal Information" mechanism.

### 7. Reassess your cybersecurity audit / risk assessment obligations
Ad tech sharing at scale is a strong candidate for "significant risk" processing under the CPRA regulations effective January 1, 2026, which would trigger annual cybersecurity audit and documented risk assessment requirements.

## Enforcement Context
Ad tech sharing without proper opt-out mechanisms is a live enforcement priority. **The Walt Disney Company's $2.75M fine** (the largest CCPA enforcement to date) involved, in part, third-party ad tech data-sharing deficiencies and opt-out mechanism failures. **PlayOn Sports was fined $1.1M** for unauthorized sharing of consumer PI with third parties and inadequate consumer rights processes. Treat this ad tech integration as a high-priority compliance item, not a minor technical detail.

## Bottom Line
Classify this as **"sharing"** (cross-context behavioral advertising) at minimum, possibly also a **"sale"** depending on consideration terms. The ad tech vendor is a **third party**, not a service provider, for this activity. You must offer a "Do Not Sell or Share" opt-out, honor GPC signals, and propagate opt-outs to the vendor within 15 business days.

*This is general compliance information, not legal advice. Consult qualified counsel to confirm the classification of your specific vendor contract and data flow.*

# Does Sharing Cookie/Browsing Data with an Ad Tech Platform Count as "Sale" or "Sharing" Under CCPA/CPRA?

## Short Answer

**Almost certainly yes** — this scenario is a textbook example of "sharing" (and potentially also "sale") of personal information under CCPA/CPRA, triggering opt-out and disclosure obligations.

## Why This Is "Sale" and/or "Sharing"

### "Sale" Definition
Under CCPA, "sale" means selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating a consumer's personal information to a third party for **monetary or other valuable consideration**. This is broad — you don't need to receive cash. If you receive advertising services, analytics, better ad rates, or other value in exchange for the data flow, it likely qualifies as a "sale."

### "Sharing" Definition (CPRA addition)
CPRA introduced "sharing," defined as disclosing personal information to a third party for purposes of **cross-context behavioral advertising** (i.e., targeting ads to a consumer based on their activity across businesses, distinct websites, or apps), **whether or not for monetary consideration**. This category exists specifically to capture the scenario you describe: sending cookie IDs and browsing behavior to an ad tech platform so it can serve targeted/interest-based ads.

**Your scenario**: Sending website visitors' cookie IDs and browsing data to an ad tech platform to serve targeted ads is squarely "sharing" (cross-context behavioral advertising) regardless of whether money changes hands, and it may also be a "sale" if there's consideration involved (which is common with ad tech/RTB arrangements involving bid requests, data co-ops, etc.).

### Key Question: Is the Ad Tech Platform a "Service Provider" Instead?

If the ad tech vendor were acting purely as your **service provider** — processing data only on your behalf, for your business purposes, under a compliant contract, with no independent use of the data — the transfer would NOT be a sale/share. However:
- Most third-party ad tech/ad exchange platforms (e.g., real-time bidding networks, DSPs/SSPs) use the data for their **own purposes** — building audience profiles, cross-site tracking, ad targeting/optimization for their broader ad network — which disqualifies them from service provider status.
- If the vendor can use the data for purposes beyond providing the contracted service to you (e.g., improving their own ad products, sharing with other clients), it's a sale/share, not a service-provider relationship.
- **Programmatic/RTB advertising in particular is widely treated by regulators (including in CPPA guidance and enforcement actions) as "sharing" at minimum**, since bid requests broadcast browsing/device data to numerous ad tech participants who use it for their own targeting purposes.

## What You Need to Do

### 1. Update Your Privacy Policy
- Disclose that you sell/share personal information (specifically, identifiers like cookie IDs and internet/browsing activity) with third parties (ad tech/advertising category) for cross-context behavioral advertising.
- List categories of personal information sold/shared and categories of third parties who receive it.

### 2. Provide Opt-Out Mechanisms
- Post a clear and conspicuous **"Do Not Sell or Share My Personal Information"** link on your homepage (or a combined "Your Privacy Choices" link is acceptable under current CPPA regulations, using the recognized opt-out icon).
- **Honor Global Privacy Control (GPC) signals** as valid opt-out requests — this is now effectively mandatory; if a browser sends a GPC signal, you must treat it as an opt-out of sale/sharing for that browser/device.
- Ensure the opt-out actually stops the data flow to the ad tech platform (e.g., disable the tracking pixel/tag, use consent management platform (CMP) signals to block tags until opt-out status is known, or configure server-side controls).

### 3. Notice at Collection
- At or before collecting the cookie ID/browsing data (e.g., on first site visit before tags fire, or via cookie banner), disclose that this data may be sold/shared, and provide a link to opt out.

### 4. Contracts with the Ad Tech Vendor
- If you want to argue any part of the relationship is a service-provider arrangement (unlikely for open ad exchanges but possible for narrower vendors like a single-purpose CDP), you need a CCPA-compliant contract restricting the vendor's use of the data.
- For genuine sale/share relationships, CPRA requires contracts with the third party that:
  - Specify the limited/specified purpose for which PI is sold/shared
  - Require the third party to comply with applicable CCPA obligations and provide the same level of privacy protection
  - Grant you rights to take reasonable steps to ensure the third party uses the data consistently with the CCPA
  - Allow you to remediate unauthorized use

### 5. Honor Opt-Outs Downstream
- Once a consumer opts out, you must **not** send their data to the ad tech platform going forward, and you should instruct the platform to stop processing/using previously shared data for its own purposes if feasible.

### 6. Consider Sensitive Data Overlaps
- If browsing data reveals sensitive categories (e.g., precise geolocation, health-related browsing, sexual orientation inferences), additional "Limit the Use of My Sensitive Personal Information" obligations may also apply.

### 7. Minors
- If you have actual knowledge that any consumers are under 16, opt-in consent (not just opt-out) is required before selling/sharing their data — relevant if your site could attract minors.

### 8. Vendor Due Diligence
- Ask the ad tech vendor directly how they use the data — whether they aggregate it into cross-client audience segments, retarget across other clients' properties, or resell it. This determines whether it's "sale," "share," or (rarely) a legitimate service-provider function, and shapes your contract terms and disclosures.

## Bottom Line
Treat this ad tech integration as a "share" (cross-context behavioral advertising) at minimum, likely also a "sale," and build your compliance program — privacy policy disclosures, opt-out link, GPC honoring, and vendor contract terms — around that classification rather than trying to characterize the ad tech platform as a mere service provider.

**Disclaimer**: This is general guidance, not legal advice. The service-provider vs. third-party/sale-share classification is fact-specific and a frequent area of regulatory scrutiny (including recent CPPA enforcement sweeps targeting undisclosed ad tech data sharing) — confirm your specific ad tech vendor relationship and contract terms with California privacy counsel.

# From GDPR to CCPA/CPRA: What You Still Need to Add

## The General Rule
GDPR is generally the **more demanding** law, and a GDPR-compliant programme already covers most CCPA/CPRA obligations — privacy notices, rights processes, processor agreements, data minimization, retention schedules, and security measures. But CCPA/CPRA has a set of **US-specific requirements that GDPR does not have equivalents for**, and you need to add these as targeted deltas rather than rebuild your programme.

## CCPA/CPRA-Specific Additions Needed

1. **"Do Not Sell or Share My Personal Information" link and opt-out workflow** — GDPR has no direct equivalent to CCPA's "sale"/"sharing" opt-out concept. You'll need a dedicated homepage link and a 15-business-day propagation workflow to service providers/contractors.
2. **Honor Global Privacy Control (GPC) signals** — the CPPA has confirmed GPC compliance is required as a valid opt-out mechanism, treated equivalently to a manual click.
3. **"Limit the Use of My Sensitive Personal Information" link and 15-business-day workflow** — CPRA's SPI-limitation right doesn't map cleanly onto GDPR's special-category consent regime; it's a separate opt-out-style mechanism you must build.
4. **Confirm vendor classification maps to service provider/contractor vs. third party**, with contracts meeting **§1798.100(d)** required terms. Your existing GDPR Art. 28 Data Processing Agreements won't automatically satisfy CCPA's service-provider/contractor contract requirements — review and likely amend.
5. **A compliant notice at collection (§1798.100(a)-(b))** — this is a **distinct artifact from your GDPR Art. 13 notice**. It must be delivered at or before collection and list PI/SPI categories, purposes, retention periods per category, and sale/sharing status with the opt-out link. **This is the single most commonly missed gap** when GDPR-first organizations assume their existing privacy notice already covers it — it does not, and you should treat this as a required, separate build item.
6. **Minors' opt-in for sale/sharing** — required for consumers under 16; parental consent required under 13. GDPR's age-of-consent rules (13–16, varies by Member State) are a different mechanism tied to consent generally, not to sale/sharing specifically.
7. **Financial incentive/loyalty programme disclosures**, if applicable — CCPA has specific disclosure requirements when offering incentives in exchange for PI.
8. **Annual reconfirmation of the three business applicability thresholds** — GDPR has no size/revenue thresholds, so this is a net-new annual compliance task: confirm whether you still exceed $25M revenue, 100,000+ consumers/households, or 50%+ revenue from PI sale/sharing.
9. **Cybersecurity audit and risk assessment obligations (effective January 1, 2026)** and **ADMT opt-out (deadline January 1, 2027)** — these are newly live/upcoming CPRA-specific requirements with their own regulatory scope, distinct from GDPR's DPIA regime (see below).

## Where the Two Laws Differ Most Significantly

### Consent model
**CCPA is opt-out** (for sale/sharing); **GDPR requires an opt-in lawful basis** for processing generally. In fact, **CCPA has no lawful-basis requirement at all** — businesses can collect PI without needing to establish one of GDPR's six lawful bases (consent, contract, legal obligation, vital interests, public task, legitimate interests). This is the most fundamental structural difference: your GDPR lawful-basis documentation doesn't have a CCPA counterpart to satisfy, but your CCPA opt-out obligations aren't satisfied by GDPR consent flows either — they're different mechanisms.

### Scope
- CCPA protects consumers **and households**, not just identified/identifiable individuals as under GDPR.
- Only businesses meeting the **revenue/volume applicability thresholds** are covered by CCPA — GDPR has no thresholds and applies to any controller/processor regardless of size.
- CCPA's **"sale" concept** (any disclosure for monetary or other valuable consideration) is **broader than anything in GDPR**, which has no equivalent "sale" category — GDPR treats third-party disclosure as just another processing activity requiring its own lawful basis.

### Rights deltas
- The **right to correct was only added by CPRA** (§1798.106) — under original CCPA it didn't exist, so if your GDPR programme was built assuming rectification parity, confirm the correction workflow is actually implemented on the CCPA side too.
- CCPA has **no GDPR-style objection right and no full portability regime** — portability under CCPA is limited to receiving right-to-know responses in a portable format, not GDPR Art. 20's structured/machine-readable portability right.
- GDPR's DPO/DPIA regime **maps only loosely** to CPRA's risk assessment requirements — don't assume your DPIA process automatically satisfies CPRA's risk assessment obligations (effective January 1, 2026); the CPPA can require submission of these assessments and the scope/format expectations differ.

### Remedies
CCPA's **private right of action is limited to data breaches** — statutory damages of **$100–$750 per consumer per incident** (§1798.150), class-action eligible. There is **no general private right of action for privacy violations** under CCPA, unlike GDPR's Art. 79 (judicial remedy) and Art. 82 (compensation) which allow individuals to sue for a broader range of GDPR violations.

### Enforcement posture and penalties
GDPR penalties run up to **€10M/2%** or **€20M/4% of global annual turnover**, generally with no formal cure period. CCPA/CPRA penalties are per-violation: **$2,500 (unintentional)** / **$7,500 (intentional)**, with a **30-day cure period** for AG actions (CPPA administrative actions may not follow the same formal cure notice process). CCPA's per-violation structure can still produce large aggregate fines at scale — recent CPPA enforcement includes **Disney ($2.75M)**, **PlayOn Sports ($1.1M)**, and **Ford ($375K)**, the last of which was specifically for missing the 45-day access/deletion response deadline.

## Practical Build Plan
1. Draft and publish a standalone **notice at collection** — don't repurpose your GDPR Art. 13 notice as-is.
2. Add the **"Do Not Sell or Share"** and **"Limit the Use of SPI"** links plus their opt-out/limitation workflows (15-business-day SLA), with GPC signal handling.
3. Audit vendor contracts: confirm GDPR processors are also properly documented as CCPA **service providers/contractors** with §1798.100(d)-compliant terms; flag any that are actually **third parties** under the CCBA rule if they're used for cross-context behavioral advertising.
4. Implement or verify the **right-to-correct** workflow specifically under CCPA (§1798.106).
5. Add minors' opt-in consent flow (under 16) if you have any California minor users.
6. Set up an annual applicability threshold review (revenue, data volume, PI-revenue percentage).
7. Assess whether your processing meets the "significant risk" bar for the new **cybersecurity audit** and **risk assessment** obligations (effective January 1, 2026).
8. Plan for the **ADMT opt-out mechanism deadline of January 1, 2027** if you use automated decision-making with legal or similarly significant effects (employment, credit, housing, insurance, education).

*This is general compliance information, not legal advice. Consult qualified counsel or an accredited assessor for your specific dual-compliance program design.*

# From GDPR to CCPA/CPRA: Gap Analysis and Key Differences

Having a mature GDPR program gives you a strong head start — data mapping, a privacy-by-design mindset, breach response processes, and vendor management practices all transfer conceptually. But CCPA/CPRA is a **different legal framework built on different foundations** (a consumer-protection/property-rights model vs. GDPR's fundamental-rights model), so you cannot simply relabel your GDPR documents. Below are the additional steps needed and the most significant divergences.

## Additional Steps You Likely Need

### 1. Re-run Your Applicability Analysis
GDPR's extraterritorial trigger (offering goods/services to, or monitoring, EU data subjects) is different from CCPA/CPRA's revenue/volume thresholds ($25M+ revenue, 100,000+ CA consumers/households, or 50%+ revenue from selling/sharing PI). You must independently confirm CCPA applies — GDPR applicability does not imply CCPA applicability or vice versa.

### 2. Add "Sale" and "Sharing" Analysis and Opt-Out Infrastructure
GDPR has no direct equivalent to CCPA's "sale" or CPRA's "sharing" (cross-context behavioral advertising) concepts. You need to:
- Determine whether any data flows (especially ad tech/analytics/cookie-based advertising) constitute a sale or share
- Build a "Do Not Sell or Share My Personal Information" mechanism / "Your Privacy Choices" link
- Honor **Global Privacy Control (GPC)** browser signals as valid opt-outs (no GDPR equivalent requirement)

### 3. Rebuild Your Legal Basis Framework Around Notice + Opt-Out, Not Consent
GDPR relies on identifying a lawful basis (often consent or legitimate interest) **before** processing. CCPA/CPRA is largely a **notice-and-opt-out** model: you can process and even sell/share data by default as long as you disclose it and let consumers opt out (except for minors under 16, sensitive PI limits, and financial incentive programs, which need opt-in consent). Your GDPR consent banners and lawful-basis registers won't map directly — you'll need CCPA-specific notices.

### 4. Add CCPA-Specific Consumer Rights Workflows
While similar in spirit to GDPR's Data Subject Access Requests (DSARs), CCPA rights have different mechanics:
- **Right to Know** (categories + specific pieces, 12-month lookback by default)
- **Right to Delete** (with CCPA-specific exceptions, different from GDPR Art. 17 exemptions)
- **Right to Correct** (added by CPRA, similar to GDPR rectification but with its own standard)
- **Right to Opt-Out of Sale/Sharing**
- **Right to Limit Use of Sensitive Personal Information**
- **Right to Non-Discrimination** for exercising rights
- **Right to Data Portability** (similar to GDPR but implementation details differ)

You'll need a **45-day response deadline** (vs. GDPR's 1 month/30 days, extendable to 3 months), different verification standards, and CCPA-specific denial/exception language.

### 5. Update Notices for CCPA-Specific Content Requirements
- **Notice at Collection**: distinct CCPA requirement — categories of PI, purposes, retention period, whether sold/shared — delivered at/before collection.
- **Privacy Policy**: CCPA mandates specific disclosures (categories collected/disclosed/sold/shared in trailing 12 months, consumer rights descriptions, methods to submit requests) updated at least every 12 months — content differs from a GDPR-style Article 13/14 notice.

### 6. Reassess "Sensitive Personal Information" (SPI) Category
CPRA created a specific **Sensitive Personal Information** category (SSN, precise geolocation, race/ethnicity, religion, union membership, genetic/biometric data for identification, health data, sex life/sexual orientation, contents of mail/email/texts absent business relationship, account login credentials) with its own **"Limit the Use of My Sensitive Personal Information"** right. This is narrower and mechanically different from GDPR's "special category data" (Art. 9), which requires an explicit legal basis for processing at all, not just a limitation right.

### 7. Update Vendor/Third-Party Contracts with CCPA-Specific Clauses
GDPR Data Processing Agreements (Art. 28) won't satisfy CCPA's service provider/contractor contract requirements, which need CCPA-specific language: restrictions on using PI for purposes outside the specified business purpose, prohibitions on combining data across clients, certification of compliance, and audit rights framed under CCPA's definitions of "service provider," "contractor," and "third party."

### 8. Determine Financial Incentive Program Compliance
If you offer loyalty programs, discounts, or rewards in exchange for personal information, CCPA requires specific notice and opt-in consent for **financial incentive programs**, plus a "good-faith estimate" of the value of the data to justify the incentive — this has no GDPR equivalent.

### 9. Cybersecurity Audits and Risk Assessments (if thresholds met)
CPRA introduces (via CPPA regulations being phased in) mandatory **annual cybersecurity audits** and **risk assessments** for businesses whose processing presents significant risk — procedurally different from GDPR's DPIA (Data Protection Impact Assessment) requirement, though conceptually similar. Don't assume your DPIA process automatically satisfies this.

### 10. Register/Monitor CPPA Regulatory Developments
The California Privacy Protection Agency (CPPA) is a dedicated rulemaking and enforcement body (distinct from a DPA) actively issuing regulations (e.g., on ADMT/automated decision-making technology, risk assessments, cybersecurity audits) — your compliance program needs a process to track CPPA rulemaking separately from EU DPA/EDPB guidance.

### 11. Employee Training Specific to CCPA
Staff handling consumer inquiries need CCPA-specific training (not just GDPR DSAR training) covering CCPA rights, verification standards, and exceptions.

## Where the Two Laws Differ Most Significantly

| Dimension | GDPR | CCPA/CPRA |
|---|---|---|
| **Legal foundation** | Fundamental right to data protection; processing prohibited unless a lawful basis applies | Consumer protection/quasi-property framework; processing generally allowed with notice, subject to opt-out rights |
| **Consent** | Central — consent is one of six lawful bases, must be freely given, specific, informed, unambiguous | Peripheral — opt-in consent only required for specific cases (selling/sharing minors' data, sensitive PI processing beyond permitted purposes, financial incentives) |
| **Scope trigger** | Extraterritorial: applies based on processing activities (offering goods/services to, or monitoring, EU residents), no revenue threshold | Applies based on business-level thresholds (revenue, volume of CA consumers, % revenue from data sales) |
| **Core mechanism** | Lawful basis + data minimization + purpose limitation, enforced ex ante | Notice + opt-out of sale/sharing, enforced ex post via consumer rights |
| **"Sale"/"Sharing" concept** | No equivalent | Central concept triggering opt-out rights and GPC obligations |
| **Special/Sensitive data** | Article 9 "special category data" — processing prohibited absent specific exception | "Sensitive Personal Information" — processing generally allowed, but consumer can limit use to specific purposes |
| **DSAR/rights response time** | 1 month (extendable to 3 months) | 45 days (extendable by another 45 days) |
| **Regulator model** | National DPAs + EDPB coordination | CPPA (dedicated agency) + California AG |
| **Data Protection Officer** | Mandatory in many cases | No DPO requirement |
| **International transfers** | Strict mechanism required (SCCs, adequacy decisions, BCRs) | No equivalent cross-border transfer restriction regime |
| **Breach notification** | 72-hour notification to supervisory authority | No CCPA-specific breach notification duty (governed instead by separate CA breach notification law, Cal. Civ. Code 1798.82) |
| **Automated decision-making** | Article 22 gives rights against solely automated decisions with legal/similarly significant effects | CPRA rulemaking on ADMT (automated decision-making technology) is newer and still being finalized — opt-out/access rights emerging but implementation details differ |
| **Private right of action** | Generally no direct private right of action for most violations (enforced by DPAs) | Limited private right of action exists for certain data breaches involving nonencrypted/nonredacted PI due to failure to maintain reasonable security |
| **Penalties** | Up to €20M or 4% of global annual turnover | Civil penalties up to $2,500 per violation (up to $7,500 for intentional violations or violations involving minors), enforced by CPPA/AG |

## Practical Recommendation
Treat this as building a **parallel, CCPA-native compliance layer** that reuses your GDPR data inventory and security controls as inputs, rather than trying to retrofit GDPR documents. A practical sequence:
1. Confirm CCPA/CPRA applicability.
2. Extend your data map to flag sale/share flows and SPI categories under CCPA's definitions.
3. Build CCPA-specific notices (notice at collection, updated privacy policy).
4. Stand up opt-out infrastructure (Do Not Sell/Share link, GPC honoring).
5. Extend your DSAR intake process to handle CCPA-specific rights, timelines, and verification tiers.
6. Update vendor contracts with CCPA service-provider/contractor/third-party clauses (in addition to, not instead of, your GDPR DPAs).
7. Monitor CPPA rulemaking (cybersecurity audits, risk assessments, ADMT) for upcoming applicability.

**Disclaimer**: This is general guidance, not legal advice. Given the structural differences between the two regimes, I'd recommend a formal gap assessment with California privacy counsel before relying on your GDPR program as a substitute.

# Precise Geolocation, Health Wearable Data, and Biometric Facial Recognition Under CPRA

Your mobile app collects three data types that are each independently classified as **Sensitive Personal Information (SPI)** under CPRA — this is a high-obligation combination that requires careful handling.

## Classification: All Three Are SPI

CPRA's SPI category list includes, among others:
- **Precise geolocation** — locating a consumer within a radius of **1,850 feet** (§1798.140(w))
- **Health/medical information** — your wearable-integration health metrics fall squarely here
- **Biometric data used to uniquely identify a person** — your facial recognition authentication is a textbook example

All three of your listed data types are SPI. This isn't a borderline call — you should treat this app as an SPI-intensive product from a compliance design standpoint, not just apply generic PI handling.

## Special Obligations That Apply

### 1. Right to Limit Use of Sensitive Personal Information (§1798.121)
Because you collect SPI, you must offer consumers the **"Limit the Use of My Sensitive Personal Information"** link (on your homepage/app, alongside or combined with the "Do Not Sell or Share" link).

**The right to limit does NOT apply** if your use of the SPI falls within these permitted purposes:
- Performing services or providing goods reasonably expected by the consumer
- Safety, security, and integrity of services
- Short-term, transient use (e.g., a contextual feature based on the current session)
- Services performed on behalf of the business (service provider context)
- Verifying or maintaining quality of services
- Activities for which the SPI was specifically provided

Your facial recognition **for authentication** likely qualifies as "safety, security, and integrity of services" or "activities for which the SPI was specifically provided" — if that's the *only* use, you may not need to offer a limitation option for that specific use case. But if you also use facial recognition, geolocation, or health data for **profiling, advertising, analytics beyond the immediate service, or sharing with third parties**, those uses fall outside the permitted-purpose list and **do** trigger the right to limit.

**Workflow if the right to limit applies to any of your uses:**

| Step | Action |
|---|---|
| 1 | Provide "Limit the Use of My Sensitive Personal Information" link |
| 2 | Consumer exercises the right — no identity verification required beyond confirming identity |
| 3 | Process within **15 business days** |
| 4 | Restrict SPI use to only the permitted purposes above |
| 5 | Propagate the limitation instruction to service providers and contractors (e.g., your wearable-integration vendor, facial recognition SDK provider, cloud geolocation processor) |

### 2. Sale/Sharing Analysis for Each Data Type
Separately from the limit-use right, evaluate whether any of this SPI is disclosed to third parties for a sale or for cross-context behavioral advertising ("sharing"):
- If geolocation, health, or biometric data is passed to ad tech platforms, analytics vendors acting as third parties, or data brokers, that triggers the standard **"Do Not Sell or Share"** opt-out obligation on top of the SPI-limitation right.
- Remember the CCBA rule: a vendor providing **cross-context behavioral advertising is a third party, not a service provider/contractor**, regardless of contract terms (Regs §7050(c)) — relevant if any of this sensitive data feeds targeted advertising.

### 3. Heightened identity verification standards apply to requests involving this data
Because this is sensitive PI, if a consumer submits a **right-to-know (specific pieces)** or **deletion request** touching this data, apply the higher verification tier: **3 data points + a signed declaration under penalty of perjury**, rather than the standard 2-point match.

### 4. Data minimization and retention (CPRA)
SPI collection must be adequate, relevant, and limited to what's necessary for the disclosed purpose — this is especially important for biometric and health data given their sensitivity. You must disclose retention periods or criteria for each category and cannot retain this data longer than reasonably necessary. Given the sensitivity of facial recognition templates and health metrics, expect this to be scrutinized closely in any assessment.

### 5. Cybersecurity audits and risk assessments (effective January 1, 2026)
Processing precise geolocation, health data, and biometric identifiers at app scale is a strong candidate for "**significant risk**" processing under the CPRA regulations that took effect January 1, 2026. You likely need to:
- Conduct **annual cybersecurity audits**
- Conduct and document a **risk assessment** before processing this SPI, producible to the CPPA upon request

Treat this as a near-term action item, not a future consideration — these regulations are already live as of today.

### 6. ADMT considerations
If your facial recognition authentication or health-metric processing feeds into any **automated decision-making with legal or similarly significant effects** (e.g., automated account lockouts, eligibility determinations, insurance-linked wellness scoring), you fall under the ADMT regime: consumers have the right to opt out, know about the automated processing, and request human review. Regulations are effective January 1, 2026; you must implement the **opt-out mechanism by January 1, 2027**. Authentication alone (verifying it's you) is less likely to trigger ADMT than uses that determine eligibility or produce adverse consequences — evaluate each use case separately.

## What You Need to Disclose

Your **notice at collection** and **privacy policy** must specifically address:
1. That you collect **precise geolocation**, **health/medical information**, and **biometric data** — name these SPI categories explicitly, not just generic "personal information."
2. The **purpose(s)** for each — e.g., "biometric data used solely for account authentication," "health metrics used to power in-app fitness tracking."
3. Whether each category is **sold or shared**, and to whom (categories of third parties).
4. **Retention periods** or criteria for each SPI category.
5. The **"Limit the Use of My Sensitive Personal Information"** link and how to exercise that right, if any of your uses fall outside the permitted-purpose list.
6. The **"Do Not Sell or Share"** link and opt-out mechanism, if applicable to any of this data.
7. If any users may be minors under 16, your **opt-in consent** mechanism for sale/sharing of their PI (parental consent under 13).

## Bottom Line
- **Precise geolocation, health data from wearables, and biometric facial recognition are all SPI** under CPRA.
- You must offer the **right to limit SPI use** unless every use of each data type falls within the narrow permitted-purpose list (safety/security, service delivery, short-term/transient use, service-provider context, quality verification, or the specific purpose disclosed).
- Facial recognition for authentication is a plausible permitted use on its own, but any secondary use (analytics, advertising, profiling, third-party sharing) breaks that exemption and requires the limitation mechanism.
- Apply heightened identity verification (3 points + perjury declaration) to know/delete requests touching this data.
- Expect this app to fall within the **cybersecurity audit and risk assessment** obligations effective January 1, 2026 given the sensitivity and likely scale of biometric/health/geolocation processing.
- Disclose all three SPI categories, their purposes, retention periods, and sale/sharing status explicitly in your notice at collection and privacy policy.

*This is general compliance information, not legal advice. Given the sensitivity of biometric and health data involved, consult qualified counsel or an accredited assessor before finalizing your compliance design.*

# CPRA Classification and Obligations for Geolocation, Health, and Biometric Data

Your app collects three data types that fall into CPRA's heightened-protection category. Here's how each is classified and what obligations follow.

## Classification: Sensitive Personal Information (SPI)

CPRA created a distinct category called **Sensitive Personal Information**, defined in Cal. Civ. Code 1798.140(ae). All three of your data types qualify:

### 1. Precise Geolocation
- SPI includes **"precise geolocation,"** defined as geolocation data accurate to within a radius of **1,850 feet (approximately 1/3 mile)** or less.
- Your wearable/app-based precise geolocation tracking clearly meets this definition (GPS-level location is typically accurate to a few meters/feet).

### 2. Health Metrics from Wearable Integration
- SPI includes **"the consumer's health"** information — this covers biometric/physiological data indicating health status (heart rate, sleep patterns, activity/fitness metrics, blood oxygen, etc., depending on what your wearable integration pulls in).
- Depending on exactly what's collected and how it's used, this data may **also** trigger obligations under other California and federal laws beyond CCPA:
  - **California Confidentiality of Medical Information Act (CMIA)** — if the data is used/maintained in a manner tied to healthcare services
  - **California's genetic/health data laws** covering direct-to-consumer health apps
  - **FTC Health Breach Notification Rule** (federal) if you qualify as a vendor of personal health records
  - If any wearable data could be considered PHI under HIPAA (unlikely unless you're integrated with a covered entity/business associate), that's a separate analysis
- For CCPA/CPRA purposes specifically, treat this as SPI at minimum.

### 3. Biometric Data for Facial Recognition Authentication
- SPI explicitly includes **"the processing of biometric information for the purpose of uniquely identifying a consumer."**
- Using facial recognition for authentication is a paradigm example of biometric SPI — the facial geometry/template is being used specifically to uniquely identify/authenticate the individual.
- This may **also** implicate California's biometric-specific requirements and potentially other states' biometric privacy laws if you have users outside California (e.g., Illinois BIPA, Texas CUBI, Washington's biometric law) — those are separate statutes with their own consent and disclosure requirements, distinct from CCPA/CPRA, and often carry steeper penalties (BIPA in particular has a private right of action with statutory damages).

## Special Obligations That Apply to SPI

### 1. Right to Limit Use and Disclosure of Sensitive Personal Information
Consumers have the right to direct you to limit your use of SPI to only what is necessary to perform the services/provide the goods reasonably expected by an average consumer, or as otherwise permitted by CPPA regulations (e.g., for safety/security, legal compliance, short-term transient use not for profiling). You must:
- Provide a **"Limit the Use of My Sensitive Personal Information"** link (or combine it with your "Do Not Sell or Share" link into a single "Your Privacy Choices" link, per CPPA regulations) if you use/disclose SPI for purposes beyond those necessary to provide the requested goods/services.
- If you only use SPI for permitted/necessary purposes (e.g., facial recognition solely to authenticate the account holder, not for advertising or profiling), you may not need to offer this opt-out link — but you still must disclose the SPI use.

### 2. Notice at Collection Must Specifically Call Out SPI
- Your notice at collection must identify that you collect SPI, list the specific categories (precise geolocation, health data, biometric information), state the purposes, and note the right to limit use if applicable.

### 3. Enhanced Privacy Policy Disclosures
Your privacy policy must:
- Identify SPI categories collected in the past 12 months
- Explain the purposes for collecting/using each category
- Disclose whether SPI is sold, shared, or disclosed to third parties, and to whom
- Explain how consumers can exercise the right to limit use (if applicable)

### 4. Purpose Limitation / Data Minimization
- SPI use must be limited to what's "reasonably necessary and proportionate" to achieve the disclosed purpose. Using facial recognition data collected for authentication to also build a broader biometric marketing profile, for example, would exceed the disclosed purpose and require separate notice/consent.

### 5. Heightened Security Expectations
- "Reasonable security" scales with data sensitivity — biometric identifiers and health data warrant stronger technical/organizational safeguards (encryption at rest and in transit, strict access controls, template-based storage rather than raw images where feasible, breach response planning) than ordinary contact information.

### 6. Risk Assessments and Cybersecurity Audits (CPRA/CPPA regulations)
- Because your processing involves **precise geolocation, biometric identification, and health data**, you are a strong candidate for the CPPA's regulations requiring:
  - **Annual cybersecurity audits** (for businesses meeting risk/revenue thresholds)
  - **Risk assessments** submitted to the CPPA before engaging in processing that presents significant risk to consumer privacy (explicitly including processing sensitive PI, and particularly biometric information for identification purposes)
- These requirements are being phased in by the CPPA — confirm current applicability thresholds and deadlines, as they are still rolling out.

### 7. Automated Decision-Making Technology (ADMT) Considerations
- If facial recognition authentication involves automated decision-making with legal or similarly significant effects (e.g., automatically granting/denying account access, or if extended to other automated profiling), CPPA's emerging ADMT rules may require additional pre-use notice and opt-out/access rights. Facial recognition for straightforward login authentication is lower-risk than, say, automated eligibility decisions, but should still be assessed against final ADMT regulations.

### 8. Minors
- If any users are known to be under 16, you need **opt-in consent** (not just notice) before selling or sharing personal information generally — and given the sensitivity of biometric/health/geolocation data, exercise particular caution and consider COPPA implications if under 13.

## Practical Disclosure Checklist for Your App

1. **Notice at collection** (in-app, at the point each data type is first collected):
   - Precise geolocation: what, why, retention, whether shared
   - Health/wearable metrics: what, why, retention, whether shared
   - Biometric facial data: what, why (authentication), retention, whether shared, and that it's used for unique identification
2. **Privacy policy sections** covering SPI categories, purposes, third-party disclosures, and the limit-use right (with a working mechanism if you use SPI beyond necessary purposes).
3. **Consent/permission flows**: Even though CCPA/CPRA is primarily opt-out based, device-level permissions (e.g., iOS/Android location and camera/biometric permissions) will independently require user consent — align your CCPA notice language with those platform consent flows.
4. **Data retention policy**: Define and disclose how long biometric templates, geolocation logs, and health metrics are retained, and delete/de-identify on schedule.
5. **Vendor contracts**: If a third-party facial recognition SDK, wearable integration partner, or geolocation SDK processes this data, ensure contracts meet CCPA service-provider requirements and restrict the vendor from using the data for its own purposes.
6. **Security architecture review**: Confirm encryption, access controls, and (ideally) on-device or template-only biometric storage rather than transmitting/storing raw facial images.
7. **Cross-check other laws**: Biometric data in particular may trigger obligations under Illinois BIPA (if you have Illinois users), and health data may implicate CMIA or FTC health-data rules — don't rely on CCPA/CPRA compliance alone.

## Bottom Line
All three data types (precise geolocation, health metrics, and biometric facial recognition data) are classified as **Sensitive Personal Information** under CPRA. This triggers enhanced notice requirements, a potential "right to limit use" opt-out, purpose limitation, heightened security expectations, and likely risk assessment/cybersecurity audit obligations given the combination of biometric identification and health data. Given the overlap with biometric-specific state laws and potential health-data regulation, this is a higher-risk data profile that warrants dedicated legal review beyond baseline CCPA compliance.

**Disclaimer**: This is general guidance, not legal advice. Biometric and health data carry elevated regulatory and litigation risk (including potential exposure under non-CCPA statutes like BIPA). I'd strongly recommend a specific legal review of your data flows, consent mechanisms, and vendor arrangements with counsel experienced in biometric and health privacy law.

Short answer: your DIRCM-modified 737s become somewhat easier to move as aircraft, but the DIRCM system itself and its technical data do not leave ITAR. Here is the analysis.

**Article description.** The article in question has two distinct pieces for jurisdiction purposes: (1) the Boeing 737 civil airframe as modified, and (2) the installed defensive aids suite (DIRCM turret, missile-warning sensors (IR/UV), associated processing and anti-tamper hardware/software).

**USML enumeration test (22 CFR § 121.1).** Historically, a civil FAA-certificated transport aircraft modified with self-protection/ASE equipment fell under USML Category VIII(a)(8), because the modification was treated as converting the whole aircraft into a defense article. The October 13, 2026 rule (91 FR 55457) revises VIII(a)(8) to carve out civil FAA transport/commuter category aircraft equipped with "secured ASE" — defined in new § 121.0 as DIRCM systems, or the IR/UV missile-warning sensors needed to cue DIRCM, provided the installation incorporates anti-tamper protection. If your 737s meet that definition (FAA transport-category airframe, DIRCM + missile-warning sensors, anti-tamper features per § 121.0), the aircraft itself is excluded from Category VIII(a)(8) as of the effective date.

**What does NOT move.** The rule is narrow. The ASE equipment — the DIRCM turret, sensor suite, associated processing, and anti-tamper components — remains separately controlled under Category XI(d) (military electronics / EW-adjacent equipment) regardless of what happens to the aircraft classification. All technical data and defense services tied to that ASE (installation drawings, source code, integration test data, maintenance/training support) stay ITAR-controlled under Category XI(d) and require a TAA (22 CFR § 124.1) for any foreign-person access, and a DSP-5/DSP-73 for any hardware export, exactly as before.

**Practical effect for VIP/head-of-state programs.** For the aircraft: if the modified 737 itself now falls outside VIII(a)(8), you may find the airframe transaction can proceed as a civil aircraft matter (potentially EAR/FAA export process for the airframe) rather than a full USML DSP-5 for the whole aircraft. But you cannot treat this as a "the whole program is now EAR" conclusion — that is the trap this rule is designed to catch. Two new exemptions matter operationally: § 120.54(a)(8) exempts temporary imports of secured ASE meeting the definition, and § 120.54(a)(9) exempts country-to-country movement of previously licensed, installed secured ASE — useful if you are repositioning already-licensed aircraft between allied VIP fleets without a new export authorization each time.

**Action items:**
1. Confirm your installation meets the full "secured ASE" definition in § 121.0, including anti-tamper — do not assume; document the engineering basis.
2. Keep the DIRCM/sensor hardware and all technical data under Category XI(d) controls: TAA in place for any foreign engineering/maintenance support, TCP coverage for any foreign-national engineers who touch ASE data.
3. Re-verify your product classification documentation (per your classification process) to reflect the split treatment — airframe vs. ASE — rather than a single "Category VIII" tag.
4. If ambiguity remains on whether your specific installation qualifies as "secured," consider a Commodity Jurisdiction request (22 CFR § 120.4) before relying on the exclusion, since comments on the rule were due September 28, 2026 and DDTC practice may still be settling.
5. Update your TAA/MLA and license tracking system to reflect the new exemptions at § 120.54(a)(8)–(9) so temporary imports and previously-licensed intra-fleet transfers aren't over-licensed going forward.

Bottom line answer rule: for aircraft-survivability/DIRCM/Cat VIII or XI jurisdiction questions after October 13, 2026, apply the revised VIII(a)(8) carve-out for the qualifying civil airframe, but always flag that the ASE equipment and its technical data remain ITAR-controlled under XI(d). Do not let the airframe carve-out be read as de-controlling the DIRCM system itself.

This is general compliance guidance, not legal advice — confirm your specific installation's eligibility for the carve-out with DDTC or qualified export-control counsel before changing your licensing posture.

Modifying Boeing 737 airframes to integrate a Directed Infrared Countermeasures (DIRCM) system for VIP/head-of-state customers puts you squarely inside a defense-article activity under the International Traffic in Arms Regulations (ITAR), 22 CFR Parts 120-130. DIRCM systems—laser-based missile countermeasure suites—are almost certainly controlled on the United States Munitions List (USML), most likely under Category XI (Military Electronics) and/or Category IV (Launch Vehicles, Guided Missiles, related articles) depending on how the specific system is classified, with the integration work itself potentially triggering Category VIII (Aircraft) coverage because you are modifying a military-configured aircraft platform. Even though the 737 airframe is civil in origin, once it is modified with a specially designed defense article and configured for a military/VIP self-protection mission, the integrated aircraft and the technical data associated with the integration can themselves become ITAR-controlled hardware and technical data.

Because I don't have visibility into the specific "new State Department rule" you're referencing that takes effect after October 2026, I can't confirm its exact text, effective date, or scope—the details of any 2026 Directorate of Defense Trade Controls (DDTC) rule would need to be verified against the Federal Register notice and the final rule language. That said, based on general patterns in how DDTC has approached similar reforms in past years, here is what I'd expect you to evaluate and the general categories of change that tend to matter for a program like yours:

1. Commodity jurisdiction and classification shifts. Periodic USML revisions move items between USML categories, decontrol certain subcomponents to the Commerce Control List (CCL) under EAR, or tighten definitions of "specially designed." If DIRCM-related hardware or software gets reclassified, your export authorization strategy (licenses vs. exemptions vs. EAR license exceptions) could change materially.

2. Country/end-user eligibility changes. Rules affecting VIP/head-of-state government end users, especially foreign governments, sometimes adjust license exception availability (e.g., changes to license exemptions for NATO/major non-NATO allies) or impose new end-use certification and retransfer requirements.

3. Technical data and defense services controls. Any new rule may adjust what counts as a "defense service" when your engineers train foreign customer maintenance crews, or when you disclose integration technical data to a foreign prime contractor or foreign national employees—this is often the area with the biggest operational impact for modification/integration shops.

4. Registration, licensing, and recordkeeping updates. DDTC periodically updates registration fee schedules, license application (DSP-5) documentation standards, and Automated Export System (AES) reporting triggers.

Regardless of the specific rule content, here's what I'd recommend doing now, as a compliance program matter:

- Pull the actual Federal Register rule and DDTC's implementation guidance the moment it's published, and have export control counsel confirm effective date, transition/grandfathering provisions, and whether your existing licenses/TAAs need amendment.
- Re-run commodity jurisdiction/classification on the DIRCM system and the modified aircraft configuration—don't assume prior classifications survive a USML update unchanged.
- Audit existing Technical Assistance Agreements (TAAs) and Manufacturing License Agreements (MLAs) tied to this program for any new provisos the rule may require.
- Review your Denied Party/end-use screening for the specific VIP/head-of-state customers, since political sensitivities around these customers often draw extra scrutiny.
- Confirm whether foreign national employees or subcontractors involved in the integration require updated Technology Control Plan coverage.
- Update your internal classification and jurisdiction determinations in writing and retain them for audit purposes—DDTC compliance reviews focus heavily on documented rationale, not just outcomes.

I'd strongly recommend having your export control attorney or a licensed compliance consultant confirm the actual rule text before making operational changes, since acting on an unconfirmed rule summary risks either over- or under-restricting your program.

The DDTC-BAE Systems, Inc. consent agreement (announced August 2026, $36M, with $18M suspended contingent on remedial spend) is one of the more instructive recent enforcement actions because it is a voluntary-disclosure case rather than a whistleblower or referral case — meaning DDTC's own reasoning about penalty mitigation is visible in the outcome. Key facts: 104 AECA/ITAR violations spanning May 2019 to March 2025, including 38 unauthorized technical-data exports to China (a § 126.1 issue — China is a proscribed destination, which normally drives aggravating-factor treatment), plus unauthorized exports and defense services across six additional countries. Terms: $36M total, $18M suspended for remedial compliance investment, a 3-year agreement term, a Special Compliance Officer, an external audit requirement, and — notably — no debarment.

**What drove the penalty (root causes DDTC cited):**
1. Weak written procedures — the violations reflect an absence of documented, repeatable export-control processes rather than a single rogue actor.
2. Inexperienced staff — personnel handling export decisions lacked adequate training or seniority to catch classification and authorization gaps.
3. Poor agreement management — TAA/MLA scope, parties, and authorized activities were not being tracked against actual conduct, so activity drifted outside licensed scope over time.
4. No authorization-tracking system — the company could not reliably answer "is this specific transfer covered by a current, valid license or agreement" at the point of transfer.

**What kept it from being worse — debarment avoided:** Two things: (1) voluntary self-disclosure (22 CFR § 127.12) and (2) cooperation with DDTC's investigation. This is the single clearest lesson: even 104 violations, including transfers to a proscribed destination, did not trigger debarment because the company found and reported the problem itself and cooperated fully. That is consistent with the mitigating-factor framework in Part 127 — VSD and cooperation are treated as heavily weighted mitigants, while national-security harm and pattern/volume of violations are aggravating factors that increase the dollar penalty but are not automatically debarment-triggering when mitigation is strong.

**Program design lessons to extract:**
- **Centralize authorization tracking.** Build (or buy) a system that maps every technical data disclosure, every hardware export, and every foreign-person interaction to a specific, currently valid license/agreement and its exact conditions (parties, scope, country, expiry). "We had a TAA" is not sufficient if the transfer fell outside that TAA's authorized scope or party list — this is exactly the "poor agreement management" finding.
- **Invest in staff experience/training commensurate with risk**, not just checkbox annual training. The BAE case implies personnel-level gaps, not just policy gaps — role-specific training for engineers and licensing staff (per the Training pillar of a compliance program) needs to be substantive, not pro forma.
- **Formalize written procedures** covering classification, screening, licensing, and record-keeping — DDTC treats the absence of documented process as a root cause, independent of whether any single violation was willful.
- **Treat § 126.1 proscribed-destination exposure as a standalone red flag** requiring its own control point (e.g., destination screening before any technical data leaves engineering, not just at shipment).
- **Build your VSD muscle now.** The consent agreement shows disclosure plus cooperation can be worth the difference between a large-but-survivable settlement and debarment. A documented internal escalation path so violations surface quickly (rather than being discovered years later) is what makes timely VSD possible in the first place.
- **Expect ongoing oversight as a term, not a one-time fine.** The Special Compliance Officer and external audit requirement show DDTC increasingly uses structural remedies (monitorship-style terms) even in negotiated settlements — build for sustained compliance investment, not a one-time check-writing event.

Use this case in your own gap assessment: score your program against the four root causes DDTC cited (procedures, staff, agreement management, authorization tracking) rather than only against the generic ITAR compliance checklist, since those are the specific failure modes this enforcement action confirms actually get penalized in practice. This is general compliance information, not legal advice — consult export-control counsel for your specific facts.

I don't have reliable, verified details of a specific "2026 BAE Systems settlement" with DDTC or the Department of Justice—I can't confirm the consent agreement's exact terms, penalty amount, or the precise violations cited, and I'd caution against treating anything I say about that specific case as fact without pulling the actual DDTC charging letter, consent agreement, and any DOJ deferred prosecution agreement from public sources. What I can offer is general, well-established guidance on what large ITAR enforcement settlements—BAE and others historically (e.g., the 2011 BAE Systems $79 million case, ITT, Fokker, Meggitt, Honeywell, MTS Systems, and similar actions)—have consistently taught the defense-industrial compliance community about program design. If a new 2026 settlement exists, it almost certainly reinforces these same structural lessons, so treat the following as durable design principles rather than case-specific commentary.

1. Tone at the top and resourcing aren't optional. DDTC consent agreements routinely require appointment of an empowered official with direct board/senior-management access, adequate headcount, and budget independent from program managers who have schedule/cost incentives to bypass controls. Settlements repeatedly reveal that compliance functions were understaffed or subordinated to business development priorities.

2. Classification discipline is the root-cause fix in nearly every major case. A large share of historical violations trace back to incorrect or undocumented USML/CCL jurisdiction and classification determinations, often made informally by engineers rather than through a defined, recorded process. Settlements typically mandate a documented classification methodology, periodic re-review, and centralized recordkeeping.

3. Technical data control failures (not just physical hardware shipments) are a recurring theme. Unauthorized disclosures to foreign national employees, unlicensed technical discussions with foreign distributors/agents, and uncontrolled technical data on shared IT systems or cloud environments have been common findings. This drives requirements for Technology Control Plans, access-control segmentation, and IT system controls (marking, encryption, access logging) for ITAR-controlled technical data.

4. Broker and third-party/agent oversight is a frequent gap. Large multinational primes often rely on foreign sales agents, distributors, or teaming partners; failure to register agents, disclose fees, or screen for improper payments/brokering activity has driven both ITAR brokering violations and parallel FCPA exposure. Settlements typically require enhanced third-party due diligence and contract flow-down clauses.

5. Mergers and acquisitions integration is a high-risk moment. Violations often originate in an acquired business unit whose export control program wasn't integrated into the parent's compliance framework quickly enough. This has pushed DDTC to expect pre-closing and post-closing export control due diligence and rapid integration timelines as part of consent agreements.

6. Voluntary self-disclosure quality and timeliness matter enormously in penalty calibration. Companies that self-disclosed promptly, thoroughly, and with root-cause remediation plans have generally fared better (lower penalties, more suspended amounts, shorter external compliance monitorships) than those where violations were discovered by DDTC or through a third party.

7. External or internal special compliance officials/auditors become a multi-year obligation. Many settlements impose 3-5 year consent periods with external audits, remediation milestones, and reporting obligations back to DDTC—these are expensive and reputationally sensitive, reinforcing that prevention is cheaper than remediation.

For your own program design, the actionable takeaways are: build (and document) a defensible classification process with periodic re-validation; treat technical data access control (including for foreign national employees and IT systems) as seriously as physical shipments; extend compliance obligations contractually to agents, distributors, and teaming partners; integrate export controls early in M&A due diligence; and maintain a genuine, resourced, empowered compliance function that can escalate concerns without program-management interference. I'd recommend having your compliance or legal team pull the actual 2026 BAE settlement documents (DDTC's website publishes consent agreements) so you can map specific findings against your own program rather than relying on general pattern-matching.

Short answer: yes, intelligence-analytics software of the kind captured by USML Category XI(b) is still ITAR-controlled today, and what you heard is partially right but easy to misread — the "temporary" modification to XI(b) was extended, not allowed to lapse.

**Background on the temporary modification.** Category XI(b) covers electronic equipment "not elsewhere enumerated" that has intelligence-analysis application, and a temporary rule retained specific language — "analyze and produce information from" and "software" — within XI(b)'s scope rather than letting export-control-reform-era narrowing remove it. That temporary retention has an expiration date built into the rule, which is presumably the source of what you heard: the control is described as "temporary" because it is implemented via a sunsetting modification rather than a permanent USML text change.

**Current status.** Per the most recent regulatory action, the XI(b) temporary modification (retaining "analyze and produce information from" and "software") has been extended through August 30, 2028 (91 FR 55461). So as of today, intelligence-analytics software meeting that description remains squarely inside Category XI(b) — the sunset date moved out, it did not arrive.

**How to apply the jurisdiction test to your specific software:**
1. **USML enumeration test (22 CFR § 121.1):** Does the software perform, or is it specially designed to perform, "analyze and produce information from" functions of the kind XI(b) captures for intelligence applications? If yes, it is enumerated under the current (extended) XI(b) text.
2. **Specially designed test (22 CFR § 120.41):** Even if not a clean textual match, ask whether the software was developed, configured, or adapted to provide a critical performance parameter enabling a military/intelligence capability. If so, it likely still falls under ITAR even outside a literal XI(b) reading.
3. **EAR fallback:** If your software is a general-purpose analytics tool with no military/intelligence-specific design basis (e.g., commercial BI software that happens to be used by an intelligence customer), it may fall to the EAR/Commerce Control List instead — but "customer is an intelligence agency" does not by itself pull commercial software into XI(b); the design/functionality test is what matters.

**Practical guidance:**
- Do not treat this as decontrolled based on the "temporary" label — operationally, treat XI(b) intelligence-analytics software exactly as ITAR-controlled through at least August 30, 2028, and revisit before that date since further extension, permanent codification, or lapse are all still possible outcomes.
- If your product sits near the line (e.g., mixed commercial/intelligence use, or ambiguous "specially designed" status), this is a strong candidate for a formal Commodity Jurisdiction (CJ) determination (22 CFR § 120.4) rather than an internal judgment call — CJ requests are specifically for ambiguous enumerated-vs-not situations like this.
- Update your internal product classification records to note the extension and its new expiry date, and calendar a review well before August 30, 2028 so the classification gets re-examined rather than silently assumed to lapse or continue.
- If you export, disclose, or provide defense services involving this software to any foreign person, you still need a TAA (22 CFR § 124.1) or applicable license, and foreign-national employees with access trigger deemed-export analysis (22 CFR § 120.50) exactly as with any other Category XI item.

Bottom line: the control was extended, not sunset. Keep the software under full ITAR treatment (registration, licensing/TAA, TCP coverage for foreign nationals, record-keeping) until DDTC actually decontrols it, and build the 2028 sunset date into your compliance calendar now rather than waiting for it to become urgent. This is general compliance information, not legal advice — verify current requirements against official DDTC/Federal Register sources for your specific product and consult qualified export-control counsel for a binding classification decision.

Short answer: I can't confirm the current status of USML Category XI(b) as of today without pulling the live text of 22 CFR 121.1 (the USML) and any recent Federal Register amendments, so treat what follows as background on how this category has historically worked and what to check, rather than a definitive "yes it's still controlled" or "no it's been removed" answer.

USML Category XI covers "Military Electronics," and subparagraph (b) has historically captured electronic systems not elsewhere enumerated that are specially designed for intelligence, early warning, signal/electronic warfare, or command-and-control functions—language broad enough that it has, at various points, been read to sweep in intelligence-analytics software, particularly software specially designed for intelligence analysis, target development, or similar defense-intelligence functions.

Here's why you might have heard the control was "temporary." Category XI(b) uses the "specially designed" catch-all construct, and DDTC/State has a long history of using temporary or interim rules, Federal Register notices with comment periods, and periodic export control reform initiatives to narrow or clarify catch-all categories that were originally drafted very broadly. During the Export Control Reform (ECR) initiative (the multi-year effort roughly 2013-2020 that moved many "less sensitive" military items from the USML to the Commerce Control List's 600-series), Category XI was one of the categories revised, and State has periodically issued proposed rules seeking public comment specifically on how "intelligence analytics" or "intelligence and information analysis" software should be scoped—because the term is inherently broad and risks capturing generic data-analytics or AI/ML software that has no defense-specific design intent.

Given that pattern, "the control was only temporary" plausibly refers to one of a few possible situations: (a) an interim final rule that was later finalized with revised, narrower language; (b) a proposed rule still in a comment/finalization process, meaning the "temporary" language remains in effect until a final rule is published; or (c) a sunset/expiration provision attached to a specific temporary designation that has since lapsed, potentially shifting jurisdiction for certain analytics software to the EAR (specifically the Commerce Control List, possibly ECCN 0Y521 series or another 600-series/XI-related ECCN) rather than the USML.

What this means practically for you: you cannot rely on general recollection or a vendor's past classification determination. The compliance-correct path is:

1. Pull the current, official text of USML Category XI(b) directly from 22 CFR 121.1 (via the eCFR) and cross-check against DDTC's public guidance and any recent Federal Register notices amending Category XI.
2. If your software's classification is genuinely ambiguous—which "specially designed for intelligence analysis" language often is—submit a Commodity Jurisdiction (CJ) request to DDTC to get an authoritative determination rather than relying on informal industry consensus.
3. Document your classification rationale in writing regardless of outcome, since "we believed it was decontrolled" is a weak defense in an enforcement context if the rationale wasn't documented and periodically revisited.
4. Watch for parallel EAR classification: if the software is genuinely dual-use or has been moved off the USML, it likely lands on the CCL under an ECCN in the 0Y521 series or a similar military-intelligence-adjacent category, which still carries meaningful licensing requirements, just under the Commerce Department's Bureau of Industry and Security (BIS) rather than DDTC.
5. Reassess any past export or disclosure decisions made under the assumption of USML control (or non-control)—a classification change can retroactively affect whether past transfers were properly licensed, which matters for both compliance risk and any potential voluntary disclosure analysis.

Given the reputational and licensing stakes of getting intelligence-related software classification wrong, I'd treat this as a "verify, don't assume" situation: get current regulatory text, and if there's real ambiguity, use the CJ process or qualified export-control counsel rather than resolving it from memory or hearsay about what changed.

This is a deemed export question, and the trigger is nationality, not physical location or work authorization status. Here is how the rule works and what to do about it.

**The core rule (22 CFR § 120.50).** A "deemed export" occurs the moment ITAR-controlled technical data (22 CFR § 120.33 — blueprints, drawings, specifications, source code, test reports, or oral/visual disclosure of equivalent information) is released to a foreign national, even if that release happens entirely inside the United States, in your own building. The release is legally treated as an export to that person's country of citizenship (or countries, if dual national), regardless of where the disclosure physically occurs.

**Who counts as "foreign national" here.** This is the part teams most often get wrong: it is about citizenship, not visa status, work authorization, or how long someone has worked for you. A green card holder (lawful permanent resident) is a "US person" under 22 CFR § 120.62 and is exempt from deemed-export licensing. Protected persons under 8 USC § 1324b are similarly treated as US persons. But an H-1B visa holder, an L-1 intracompany transferee, an F-1 student on OPT, or any employee who is a citizen only of a foreign country — even if fully work-authorized and even if they've been on your team for a decade — is a foreign person for this purpose. So the trigger question for each engineer is: "what is your citizenship (not your work authorization), and is it US, or LPR, or a protected-person category?" If the answer is "foreign citizen, no LPR/protected status," any ITAR technical data disclosure to them is a deemed export unless authorized.

**When it becomes "a problem" specifically:**
1. The moment a foreign-national employee is given access to a defense article's technical data — CAD files, source code, test data, design specs, even verbal walkthroughs in a design review — without a prior authorization in place. It does not require the employee to take the data anywhere; internal disclosure alone is the export.
2. It becomes a compliance failure (not just a risk) if that disclosure happens before you've confirmed no license is required for their country of citizenship, or before you've obtained the necessary TAA or individual license.
3. Country matters: some countries have streamlined pathways (e.g., certain UK/Australia/Canada treaty arrangements), but none of these are blanket exemptions — you must verify eligibility every time, and disclosures involving § 126.1 proscribed/embargoed countries (Belarus, Cuba, Iran, North Korea, Russia, Syria, Venezuela) face the strictest scrutiny and often no path at all absent a presidential waiver.

**What to do before it becomes a problem:**
1. Inventory every foreign national with any potential access to ITAR-controlled data or controlled physical areas — capture citizenship (all citizenships if dual), not just work authorization.
2. For each one, determine whether their country of citizenship requires a license/TAA for the specific technical data involved.
3. Where required, obtain the TAA (22 CFR § 124.1) or individual license before granting any access — not after the fact. A TAA is required even for oral disclosure.
4. Stand up a Technology Control Plan (TCP): physical segregation of ITAR work areas, IT access controls/permissions tied to citizenship screening results, visitor/escort procedures for foreign-national visitors, and annual ITAR training for anyone with potential access.
5. Build citizenship screening into onboarding and project-staffing workflows so the check happens before a foreign-national engineer is added to an ITAR-relevant project team or repository — not as a retrospective audit finding.
6. Re-screen when someone's role, project assignment, or country of citizenship status changes (e.g., new dual citizenship, project transfer).

Bottom line: it becomes a problem at first disclosure without authorization, not at some later "point of harm" — so the compliance work has to happen at the staffing/access-provisioning stage, before any drawing, source file, or design conversation reaches a foreign-national engineer. This is general compliance guidance, not legal advice; consult export-control counsel to confirm treatment for specific employees, dual nationals, or ambiguous cases.

This is one of the most common and highest-risk compliance questions in export controls, because the trigger isn't nationality or immigration status per se—it's a legal event called a "deemed export." Under ITAR (22 CFR 120.17 and related provisions), releasing technical data to a foreign person—whether by showing a document, verbal briefing, granting system/network access, allowing them to observe a controlled process, or even letting them work on ITAR-controlled source code or design files—is treated as an export to that person's country of nationality (or countries of nationality, if dual national), even if the release happens entirely inside the United States and the person never leaves the building.

Key concept: "foreign person" is defined broadly. It includes anyone who is not a U.S. citizen, U.S. lawful permanent resident (green card holder), or a protected individual under 8 U.S.C. 1324b(a)(3) (e.g., certain asylees/refugees). Visa status matters: H-1B, L-1, TN, F-1 OPT, and similar nonimmigrant visa holders are all "foreign persons" for ITAR purposes regardless of how senior, trusted, or long-tenured they are. Green card status is the bright line that removes deemed-export risk for that individual (subject to the person actually holding LPR status, not just having applied).

When does showing technical data become a problem? The moment you disclose ITAR-controlled technical data (22 CFR 120.10—this includes design data, engineering prints, source code, test data, technical specifications, and know-how "required" for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification of a defense article) to a foreign national employee without an approved authorization, you have committed an unauthorized export unless an exemption applies. This is true even for:

- A hallway conversation describing how a controlled subsystem works
- Granting network/file-share access to a folder containing ITAR drawings
- CAD/PLM system access where the foreign national employee's login can view controlled files, even if they never open them
- Including a foreign national on an email thread with attached technical data
- Verbal instruction, mentoring, or training on a controlled process (this counts as a "defense service" as well as a technical data release)

What doesn't automatically trigger it: general engineering knowledge, publicly available information (properly determined public domain per 120.11), basic marketing data, and information that qualifies as "fundamental research" (22 CFR 120.34) performed at an accredited institution intended for publication—though fundamental research has narrow, specific conditions and doesn't apply to most commercial defense contractor engineering work.

Authorization paths if you need to proceed: (1) A DDTC export license or agreement (e.g., a Technical Assistance Agreement) naming the specific foreign national and country, which can be slow and doesn't scale well for routine internal staffing; (2) exemptions under 22 CFR 126.18, which allow disclosure to certain bona fide regular employees who are foreign nationals without a specific license, provided the company has a Technology Control Plan (TCP) in place, screens for substantive contacts with restrictive countries, and the employee isn't from a proscribed country (126.1 list) or subject to other disqualifiers; (3) NATO/certain allied country provisions in limited circumstances.

Practical program design recommendations:
- Implement a Technology Control Plan before foreign nationals touch any ITAR-controlled program, with physical and IT access segmentation (badge access, network permissions, PLM/CAD role-based access) mapped to each individual's authorization status.
- Maintain an accurate roster of employee citizenship/immigration status tied to project assignments, refreshed regularly since visa status changes.
- Train program managers and engineering leads to recognize that hallway conversations and informal mentoring are just as much an "export" as emailing a drawing.
- Screen for 126.18 disqualifiers (e.g., substantive contacts with restricted countries) before relying on the exemption.
- Document every technical data access decision so you can demonstrate a defensible, good-faith compliance process if DDTC ever asks.

Given how fact-specific and high-stakes deemed export determinations are, I'd strongly recommend looping in export control counsel or your empowered official to review your current foreign-national staffing against active ITAR programs before any new technical data sharing occurs.

Voluntary Self-Disclosure (VSD) under 22 CFR § 127.12 is the right move, and it is the strongest mitigating factor available to you — but timing and discipline matter from this point forward. Here is the process, step by step.

**Step 1 — Initial Notification (target: within ~30 days of discovery).**
Do not wait to have the full picture before telling DDTC something happened. Submit a brief written notification to the DDTC Office of Defense Trade Controls Compliance covering: your company name and DDTC registration number, a general description of the potential violation(s), and an estimate of the number of occurrences over the two-year period. At this stage you are not required to have root cause or final facts — you are flagging the issue and buying time to investigate properly. Request a tolling agreement in this same notification; it preserves the statute of limitations while your internal investigation proceeds, so you are not racing the clock while trying to do the investigation right.

**Step 2 — Internal Investigation (typically 30–90 days).**
Scope this broadly, not narrowly. Pull every relevant record: licenses, TAAs/MLAs and their exact scope/party lists, shipping and export documentation, emails, engineering access logs, and any prior classification decisions. Establish: what exactly was exported or disclosed (hardware, technical data, defense services), to whom (name every recipient, entity, and country), when, under what authorization (if any), and why the authorization was missing or exceeded. Put a litigation hold in place immediately so records aren't altered or lost. Identify root cause explicitly — was this a process gap, training failure, misclassification, an agreement that didn't cover the actual scope of activity, or a deliberate act? This matters because DDTC weighs willfulness heavily as an aggravating factor, so an honest, well-documented root-cause finding (even if unflattering) tends to land better than a superficial one that looks evasive later.

**Step 3 — Final VSD Report (within ~60–90 days of initial notification).**
Submit a comprehensive written report containing: a detailed factual narrative covering every violation identified (not just the ones initially estimated — update the count if the investigation surfaced more or fewer), the specific CFR sections violated for each occurrence, every party involved (internal and external, including any foreign end-users or destination countries), a full timeline, the root-cause analysis from Step 2, corrective actions already implemented, and proposed additional remediation. Two years of unauthorized exports likely means multiple distinct violation types (e.g., unlicensed hardware exports, unauthorized technical-data disclosures, possibly TAA-scope violations) — itemize each, don't aggregate them into a vague summary.

**Step 4 — DDTC Review and Resolution (often 6–18 months for cooperative VSDs).**
DDTC will review, may come back with follow-up questions, and will reach an outcome ranging from no action or a warning letter up to a civil penalty (typically reduced given VSD credit) or, in rare/egregious cases, referral for criminal review. Continued cooperation throughout this phase is itself a mitigating factor — do not treat submission of the final report as the end of your obligations.

**Mitigating factors working in your favor:** the disclosure is voluntary, presumably self-discovered rather than surfaced by a tip or audit; cooperation with DDTC through the process; and — critically — you should be building or strengthening your compliance program in parallel (Empowered Official, TCP, training, license-tracking system) so DDTC sees a program to credit, not just a promise. Prior clean history and low national-security harm also help.

**Aggravating factors to watch for and address head-on:** willfulness, senior management awareness, involvement of embargoed/proscribed destinations (22 CFR § 126.1 countries), pattern/volume across two years, and any appearance of delay or incomplete disclosure. If any of these apply to your facts, do not bury them — DDTC's own recent enforcement practice (e.g., the 2026 BAE Systems consent agreement, 104 violations over nearly six years, VSD + cooperation credit, no debarment despite unauthorized transfers to China) shows that even serious, multi-year, multi-violation cases can avoid debarment when disclosure and cooperation are genuine and the company demonstrates remediation.

**Immediate next steps for you:** (1) don't delay initial notification while you try to fully scope it — notify DDTC now with your best current estimate and request tolling; (2) engage export-control counsel before drafting the notification if you haven't already; (3) start the internal investigation and litigation hold today; (4) begin parallel remediation (fix the process gap you'll eventually have to describe) so your final report can show corrective action already underway, not just planned. This is general compliance information, not legal advice — engage qualified export-control counsel immediately given the two-year exposure window.

Discovering two years of unauthorized ITAR exports is serious but very manageable if you handle the disclosure correctly—DDTC's Voluntary Self-Disclosure (VSD) process exists precisely for this situation and is generally treated as a strong mitigating factor in any resulting enforcement action, provided you follow the process properly. Here is the practical walk-through.

1. Stop the bleeding immediately, but don't panic-freeze the business. As soon as unauthorized exports are identified, convene your empowered official, legal counsel (ideally outside export control counsel with ITAR enforcement experience), and relevant business leaders to assess whether the activity is ongoing. If it is, halt any further unauthorized transfers, shipments, technical data disclosures, or defense services immediately. Do not, however, take drastic uncoordinated actions (e.g., abruptly canceling contracts or terminating employees) before understanding the full scope—that can complicate both the investigation and business/legal remediation.

2. Preserve documents and data. Issue a litigation/compliance hold across email, shipping records, engineering/technical data systems, contracts, and any communications related to the affected programs. Because this covers two years, you'll likely need IT and records management involved early to prevent normal retention-cycle deletion from destroying evidence you'll need for your own investigation and for DDTC.

3. Conduct an internal investigation to scope the violation before disclosing. DDTC expects disclosures to be reasonably complete, so rushing to file before you understand the facts often results in supplemental disclosures later (which is acceptable but less ideal than a thorough initial filing). Scope typically includes: what specific ITAR-controlled hardware, technical data, or defense services were involved; USML classification of each item; countries and end users involved; number and dates of transactions; root cause (e.g., misclassification, missing license, unauthorized foreign national access, agent/distributor issue, IT system gap); and whether any proscribed countries or denied/debarred parties were involved, which raises severity significantly.

4. Determine whether this is a "voluntary" disclosure under DDTC's standards. To get credit as a true VSD (22 CFR 127.12), the disclosure generally must be made before DDTC or another government agency independently discovers or is already investigating the violation, and it must be a full and complete initial notification followed by a thorough final report. If DDTC already has knowledge (e.g., through a tip, a customs hold, or another agency's referral), you may be in a different, less favorable posture, and counsel needs to assess this immediately—it affects strategy and expectations.

5. File the initial notification promptly. DDTC guidance calls for notifying them as soon as possible after the violation is discovered—historically within roughly 60 days is treated as a benchmark for "prompt," though the exact expectation should be confirmed with current DDTC guidance and your counsel, since practice on timing expectations can be refined over time. The initial notification is typically a short letter identifying that a violation occurred, a general description, and a commitment to investigate and file a full report.

6. Complete and file the full disclosure. This follow-up report (DDTC does not use a single mandated form; submissions are made per current DDTC electronic filing guidance) should include a detailed narrative of the violations, root cause analysis, list of affected transactions/parties/countries, classification determinations, and—critically—a remediation plan describing corrective actions already taken and planned (process fixes, training, system access controls, personnel actions if warranted, and internal control enhancements).

7. Build and execute a credible remediation plan in parallel, don't wait for DDTC's response. Common elements: corrected classification determinations with documentation; enhanced screening and licensing procedures; IT/access control fixes if technical data access was the root cause; retraining program managers, engineers, and shipping/logistics staff; and, depending on severity, resourcing enhancements to the compliance function itself. DDTC evaluates disclosures partly on whether the company demonstrates it has fixed the underlying control gap, not just the specific past transactions.

8. Expect a DDTC response that could range from a closing letter with no further action, to negotiated administrative penalties/consent agreement (especially given the two-year duration, which suggests either volume or a systemic control gap), to referral for further investigation in more serious cases (e.g., proscribed-country involvement or willfulness indicators). Voluntary, timely, complete disclosures with credible remediation are consistently treated more favorably in DDTC's penalty determinations than violations discovered through external means.

9. Parallel considerations: assess potential overlap with Commerce/BIS (EAR) jurisdiction if any items may not actually be ITAR-controlled, evaluate SEC/customer disclosure obligations if this is a public company or has government contracts with mandatory disclosure clauses (e.g., FAR/DFARS), and consider whether individual conduct raises personal liability issues requiring separate counsel for specific employees.

Because voluntary disclosures are legally and strategically consequential—and the specific procedural requirements can be updated by DDTC from time to time—I'd strongly recommend engaging export control counsel with DDTC enforcement experience before filing anything, so the initial notification and final report are structured correctly from the outset.

# International Data Transfer to the US — LGPD Compliance Analysis

Transferring Brazilian customer data to your parent company's US servers is an **international data transfer** under LGPD Chapter V (Arts. 33–36). Because the **United States has no ANPD adequacy decision**, the adequacy pathway (available for EU/EEA transfers since the January 2026 Brazil-EU mutual adequacy recognition) is **not available to you**. You must rely on one of the other Art. 33 mechanisms.

---

## 1. Available Transfer Mechanisms (Art. 33)

| Mechanism | LGPD Basis | Fit for US Parent-Company Transfer |
|-----------|-----------|-------------------------------------|
| **Adequacy decision** | Art. 33, I / Art. 34 | **Not available** — US has no ANPD adequacy decision |
| **Standard/specific contractual clauses (SCCs)** | Art. 33, II / Art. 35 | **Recommended** — most common mechanism for intragroup transfers to non-adequate countries |
| **Global corporate standards / Binding Corporate Rules (BCRs)** | Art. 33, II / Art. 35, I | **Strong fit** — designed for intragroup/intercompany transfers like this one; requires ANPD authorization |
| **Specific consent** | Art. 33, VIII | Usable as a supplementary or fallback basis, but **not scalable** — must be specific to the transfer, separate from other consents, and freely revocable |
| **Legal/regulatory cooperation** | Art. 33, IV–VII | Not applicable — this is a private intragroup commercial transfer |
| **Vital interests** | Art. 33, VII | Not applicable — emergency-only basis |
| **ANPD case-by-case authorization** | Art. 33, IX | Fallback only if no other mechanism fits |

**Recommendation:** For an intragroup, ongoing, systematic transfer of customer data from a Brazilian subsidiary to a US parent, the two realistic mechanisms are:

- **Standard Contractual Clauses (SCCs)** under Art. 35 — faster to implement, especially if ANPD has not yet published its own standard clauses (in which case controller-drafted specific clauses providing adequate protection can be used); or
- **Binding Corporate Rules (BCRs)** under Art. 35, I — better suited to your situation since this is an intercompany/intragroup transfer, but requires ANPD review and authorization, which adds lead time.

Note: As of the ANPD's published guidance, ANPD has not yet issued its own standard contractual clause templates — controllers may need to use specific contractual clauses that demonstrably provide an adequate level of protection consistent with LGPD principles (Art. 35), often modeled on GDPR-style SCC provisions since GDPR SCCs are the market-accepted template, adapted for LGPD requirements.

---

## 2. What You Need to Implement

### A. Choose and execute the legal transfer mechanism
1. **Contractual clauses (fastest path):**
   - Draft or adopt intragroup data transfer clauses covering: categories of data transferred, purposes, security obligations, data subject rights guarantees, sub-processing restrictions, audit rights, and liability allocation.
   - Ensure clauses guarantee a level of protection equivalent to LGPD (Art. 35) — not just US law, since the US offers no equivalent statutory baseline.
   - Execute between the Brazilian entity (as controller/exporter) and the US parent (as importer — controller or processor depending on the role it plays).
2. **BCRs (if group-wide, recurring transfers):**
   - Draft binding corporate rules covering all intragroup transfers of personal data (not just Brazil→US).
   - Submit to ANPD for authorization — build this lead time into your rollout plan, as ANPD review timelines are not guaranteed to be short.
   - BCRs are the more durable/scalable solution if the US parent will be a recurring or permanent recipient of data from multiple Brazilian data flows.

### B. Governance and documentation
3. **Update the Record of Processing Activities (RoPA — Art. 37):** Add the Brazil→US transfer as a distinct processing activity, noting the legal basis for transfer (contractual clauses/BCRs), data categories, recipients, and purpose.
4. **Update the privacy notice (Art. 9):** Disclose that data is transferred internationally to the US, name the mechanism used (contractual clauses/BCRs — not adequacy), and identify the recipient (parent company).
5. **Conduct a transfer risk assessment / DPIA (RIPD, Art. 38):** Given the US has no adequacy decision and US surveillance/access laws are a known ANPD concern area, document the risk assessment, especially if sensitive personal data (Art. 11) is involved — sensitive data transfers may draw additional ANPD scrutiny (Art. 36 complementary requirements).
6. **Confirm the legal basis for the underlying processing (Art. 7):** The transfer mechanism (Art. 33) is separate from — and additional to — the Art. 7 legal basis for processing the data itself (e.g., contract, legitimate interest, consent). Both must be satisfied.

### C. Security and accountability
7. **Security measures (Art. 46):** Ensure the US parent implements technical and administrative safeguards equivalent to what would be required in Brazil (encryption in transit/at rest, access controls, logging). The Brazilian controller remains responsible for the processor's/recipient's security posture.
8. **DPO involvement (Art. 41):** The Encarregado should review and sign off on the transfer mechanism and be listed as the contact point in the updated privacy notice.
9. **Complementary safeguards for sensitive data (Art. 36):** If any transferred data qualifies as sensitive personal data (health, biometric, etc.), expect ANPD to potentially require additional safeguards beyond the base contractual clauses.

### D. If none of the above is feasible in the short term
10. **Specific consent (Art. 33, VIII)** can serve as an interim/fallback mechanism: it must be captured separately from other consents, clearly inform the data subject that data will be transferred internationally to the US, name the recipient, and be freely revocable. This is generally not recommended as your primary long-term mechanism due to scalability and revocability risk (a wave of revocations could disrupt data flows), but can bridge the gap while SCCs/BCRs are finalized.

---

## 3. Practical Sequencing Recommendation

| Step | Action | Priority |
|------|--------|----------|
| 1 | Legal/DPO review to select contractual clauses vs. BCRs based on transfer scope and duration | High |
| 2 | Draft and execute intragroup contractual clauses (Art. 35) as the near-term mechanism | High |
| 3 | Update RoPA and privacy notice to reflect the US transfer and mechanism used | High |
| 4 | Conduct DPIA/RIPD for the transfer, especially if sensitive data is included | Medium |
| 5 | Evaluate long-term BCR submission to ANPD if transfers will be recurring/group-wide | Medium |
| 6 | Verify US parent's security controls match Art. 46 expectations | High |
| 7 | Train relevant staff and document accountability measures (Art. 47) | Medium |

---

## Key Takeaway

Because the US lacks an ANPD adequacy decision, you **cannot rely on adequacy** (unlike the Brazil-EU pathway now available since January 2026). You must implement **contractual clauses or BCRs** (Art. 35) as your primary mechanism, backed by RoPA/privacy notice updates, a transfer risk assessment, and verified security controls at the US recipient — with specific consent as only a limited, non-scalable fallback (Art. 33, VIII).

Transferring Brazilian customer data to your parent company's servers in the United States is an "international data transfer" under Brazil's Lei Geral de Proteção de Dados (LGPD), specifically Articles 33–36. Since the US has no LGPD adequacy decision from the ANPD (Autoridade Nacional de Proteção de Dados), you cannot rely on adequacy and must use one of the alternative legal mechanisms.

## Available Transfer Mechanisms (LGPD Art. 33)

**1. Standard Contractual Clauses (SCCs) — Most common for intra-group transfers**
The ANPD published its own Standard Contractual Clauses (approved via Resolução CD/ANPD in 2024). These are the LGPD equivalent of the EU's SCCs and are the most practical route for a US-based parent company. Key points:
- Must use the ANPD's official template/clauses — you cannot simply reuse EU SCCs, though the ANPD version was designed to be largely interoperable with them (you may be able to use EU SCCs with an ANPD-required addendum in some cases, but check current ANPD guidance since this is evolving).
- Clauses must be signed by both the Brazilian entity (exporter) and the US parent (importer).
- Must be registered/available for ANPD inspection upon request.

**2. Binding Corporate Rules / Global Corporate Rules (Art. 33, V)**
Since this is a parent-subsidiary (intra-group) transfer, this is often the best long-term fit:
- Internal, group-wide data protection rules approved by the ANPD, binding on all group entities including the US parent.
- Requires ANPD approval before use — plan for lead time.
- Best suited to organizations with recurring, high-volume intra-group transfers (which fits your scenario), since it avoids re-papering contracts every time data flows between entities.

**3. Specific/One-off ANPD Authorization (Art. 33, I)**
You can seek case-by-case ANPD authorization for a specific transfer, but this is slow and impractical for ongoing operational data flows — not recommended as your primary mechanism.

**4. Consent (Art. 33, VIII, in conjunction with Art. 8 and Art. 9)**
Specific, highlighted, informed consent to the international transfer, obtained separately from other consents. This is generally a weak/fallback mechanism for a business-as-usual, recurring corporate data flow because:
- It must be freely given and specific to the transfer (not bundled into general T&Cs).
- Data subjects can withdraw consent at any time, which is operationally fragile for infrastructure-level transfers like moving data to a parent company's servers.
- Regulators (and the ANPD following EU-style reasoning) generally disfavor consent as the basis for systematic, ongoing commercial transfers.

**5. Other Art. 33 grounds** (narrower, situational — unlikely to be your primary basis):
- Necessary for international legal cooperation (criminal investigations, etc.)
- Necessary to protect the life or physical safety of the data subject or third party
- Authorized by ANPD when necessary to protect health, in procedures for pharmaceutical/sanitary studies
- Necessary for contract execution or preliminary procedures related to a contract, at the data subject's request
- Necessary for the exercise of rights in judicial, administrative, or arbitration proceedings
- Transfer necessary to fulfill a legal or regulatory obligation, or execution of public policy

## Recommended Approach for Your Scenario

Given this is a **parent-subsidiary, recurring, operational transfer**, the practical path is:

1. **Short/medium term:** Execute ANPD Standard Contractual Clauses between the Brazilian subsidiary (exporter) and the US parent (importer). This is the fastest mechanism to stand up and doesn't require pre-approval — you self-execute and keep it on file for ANPD inspection.
2. **Long term (if transfers are frequent, high-volume, and multi-entity):** Consider applying for ANPD-approved Binding/Global Corporate Rules, which streamlines governance across the whole corporate group and reduces contract-by-contract friction.
3. **Avoid relying on consent** as your primary basis — reserve it only for edge cases where SCCs/BCRs don't cover a specific flow.

## What You Need to Implement

**A. Legal/Contractual**
- Execute the ANPD Standard Contractual Clauses (or begin the BCR approval process) covering all Brazil-to-US data flows to the parent company.
- Map and document exactly what personal data categories flow, for what purpose, how often, and under what retention terms — this must be reflected in the clauses/rules.
- Update your Data Processing Agreements/intercompany data sharing agreements to reference the chosen transfer mechanism.
- If any data involves sensitive personal data (Art. 5, II — health, biometric, racial/ethnic origin, religious/political views, etc.), apply heightened scrutiny — transfers of sensitive data carry additional risk and should be minimized or specifically justified.

**B. Governance & Documentation**
- Conduct/update a **Data Protection Impact Assessment (Relatório de Impacto à Proteção de Dados Pessoais, RIPD)** for the transfer, especially since cross-border transfer of customer data to a jurisdiction without adequacy is a higher-risk processing activity.
- Maintain a **Record of Processing Activities (ROPA)** that documents the international transfer, legal basis, and safeguards.
- Designate/confirm your **DPO (Encarregado)** is aware of and sign off on the transfer mechanism.
- Keep the executed SCCs (or BCR approval) available for ANPD inspection — the ANPD can request this at any time.

**C. Technical & Organizational Measures**
- Implement encryption in transit and at rest for data moving to US servers.
- Apply access controls/least privilege on the US side so only authorized personnel can access Brazilian customer data.
- Ensure data minimization — transfer only what's necessary for the stated purpose, not a full unrestricted mirror.
- Implement audit logging of access to transferred data.
- Assess and document U.S. government access risks (similar to Schrems II-style analysis under GDPR) — evaluate whether US surveillance laws (e.g., FISA 702) could affect the data and whether supplementary technical measures (encryption, pseudonymization, key management retained in Brazil) are warranted to mitigate this risk, since the ANPD's framework was influenced by EU jurisprudence on this point.

**D. Transparency to Data Subjects**
- Update your privacy notice to disclose: that international transfers occur, the destination country (US), the transfer mechanism used, and the categories of data/recipients involved.
- Ensure data subject rights (access, deletion, portability, etc.) can still be fulfilled post-transfer, including coordinating with the US parent to honor Brazilian data subject requests.

**E. Ongoing Compliance**
- Monitor ANPD guidance — the ANPD's international transfer rules are relatively new (SCCs formalized in 2024) and may be refined; also watch for any future US adequacy developments.
- Reassess the transfer mechanism periodically, especially if data volumes, categories, or purposes change, or if you add more corporate entities to the data flow (which would strengthen the case for BCRs over one-off SCCs).

## Bottom Line
Use the **ANPD Standard Contractual Clauses** as your immediate mechanism for the Brazil-to-US parent company transfer, back it with a documented RIPD/impact assessment, encryption and access controls, and updated privacy disclosures. If transfers will be extensive and recurring across multiple group entities, invest in **Binding/Global Corporate Rules** for a more scalable, long-term governance structure. Avoid relying on data subject consent as your primary legal basis for this kind of systemic, infrastructure-level transfer.

## Does LGPD apply to you?

**Yes.** LGPD applies to your company even though you're a US-based SaaS provider with no physical presence in Brazil.

Under **Art. 3**, LGPD applies to any processing of personal data of individuals located in Brazil, regardless of where the controller is established, when any of the following is true:
- Processing occurs in Brazil
- The purpose is to offer goods/services to individuals in Brazil
- Personal data was collected in Brazil

You have Brazilian customers using your app — meaning you're offering services to individuals in Brazil and collecting their personal data. This is **extraterritorial reach**, similar to GDPR Art. 3, and it applies squarely to your situation. None of the Art. 4 exemptions (personal/household use, journalistic/artistic/academic, national security, public safety, criminal investigation) apply to a commercial SaaS product.

**Bottom line:** As a foreign company targeting/serving Brazilian users, you are subject to LGPD as a **controller** for the personal data of your Brazilian customers.

---

## Data inventory and classification

| Data Element | Classification |
|---|---|
| Name | Regular personal data |
| Email | Regular personal data |
| CPF (Cadastro de Pessoas Físicas — Brazilian taxpayer ID) | Regular personal data (a unique national identifier — treat with heightened care operationally, but it is **not** "sensitive data" under Art. 11's closed list) |
| Purchase history | Regular personal data |

Note: LGPD's sensitive data category (Art. 11) is limited to racial/ethnic origin, religion, political opinion, trade union membership, health/sexual life data, and genetic/biometric data. CPF and purchase history don't fall into that list, so **Art. 7** (not the stricter Art. 11) governs your legal basis analysis. That said, CPF is a high-value identifier for fraud/identity theft, so it merits strong security controls even though it isn't legally "sensitive" under LGPD.

---

## Legal basis analysis (Art. 7)

Since none of this is sensitive data, you map each processing activity to one of the **10 legal bases in Art. 7**. For a typical SaaS billing/account relationship, the following bases are most likely applicable:

### 1. Contract — Art. 7, V (primary basis for most of your processing)
**Key requirement:** Processing necessary for the performance of a contract or pre-contractual procedures at the data subject's request.

- **Name, email:** Necessary to create an account, authenticate the user, and deliver the service — squarely contract-based.
- **CPF:** If CPF is collected because Brazilian tax/invoicing law or payment processors require it to bill Brazilian customers, this is also justified under **Contract (Art. 7, V)**, and potentially reinforced by **Legal obligation (Art. 7, II)** if a specific regulation mandates CPF collection for invoicing (e.g., Nota Fiscal requirements).
- **Purchase history:** Necessary to fulfill the contract (order records, subscription management, support) — Contract basis applies.

### 2. Legal obligation — Art. 7, II (supporting basis, likely for CPF)
**Key requirement:** Processing required by law or regulation.

- Brazilian tax and consumer protection rules often require CPF on invoices/receipts for B2C transactions. If that's why you collect CPF, document this as a **secondary/reinforcing basis** alongside Contract.

### 3. Legitimate interest — Art. 7, IX (for ancillary purposes only)
**Key requirement:** Controller's legitimate interest, provided it doesn't override the data subject's fundamental rights and freedoms; requires a documented balancing test (LIA).

- Could support secondary uses like fraud prevention, service improvement analytics on purchase history, or churn analysis — but **not** as the primary basis for core account/billing data, since Contract already covers that more cleanly.
- If used, you must conduct and document a legitimate interest balancing test.

### 4. Consent — Art. 7, I (only where processing exceeds contract necessity)
**Key requirement:** Free, informed, unambiguous, specific, documented, and revocable at any time.

- Only needed for processing that goes **beyond** what's necessary to perform the contract — e.g., marketing emails using purchase history to build product recommendations shared with third parties, or cross-selling communications. Don't rely on consent for core account operation; Contract is the cleaner, more defensible basis and avoids the operational burden of consent withdrawal disrupting service delivery.

### What does NOT apply here
Public policy execution (III), research (IV), judicial/regulatory proceedings (VI), vital interests (VII), health protection (VIII), and credit protection (X) are not relevant to a standard SaaS billing/account data flow.

---

## Recommended basis mapping

| Data Element | Primary Purpose | Recommended Legal Basis | Article |
|---|---|---|---|
| Name, email | Account creation, service delivery | Contract | Art. 7, V |
| CPF | Invoicing/tax compliance | Contract + Legal obligation | Art. 7, V (+ II if mandated by tax law) |
| Purchase history | Order fulfillment, billing, support | Contract | Art. 7, V |
| Purchase history (if used for marketing/analytics/profiling) | Product recommendations, marketing | Legitimate interest (with LIA) or Consent | Art. 7, IX or Art. 7, I |

---

## Practical next steps

1. **Document each basis in your Records of Processing Activities (RoPA)** and reflect it in your privacy notice (Art. 9), including basis, purpose, retention period, and whether data is shared with third parties.
2. **Appoint or designate a DPO/Encarregado (Art. 41)** — publish name and contact info. Small-scale operators may be exempt from formal appointment under ANPD Resolution CD/ANPD 2/2022 but must still provide a contact channel; assess whether your Brazilian customer volume qualifies.
3. **Confirm international transfer mechanism (Art. 33–36)** — since you're a US company, personal data flowing from Brazil to your US infrastructure is an international transfer to a **non-adequate country** (the January 2026 Brazil-EU mutual adequacy decision does not cover the US). You'll need **standard contractual clauses (SCCs)** or another Art. 33 mechanism for Brazil→US transfers — this is a distinct compliance gap from the legal basis question and should be addressed in your data processing agreements and privacy notice.
4. **If relying on legitimate interest** for any secondary use of purchase history, complete and document a balancing test (LIA).
5. **Update your privacy notice** to disclose purpose, legal basis, CPF handling, retention, and the US transfer mechanism to Brazilian customers per Art. 9.

---

*LGPD vs. GDPR note: LGPD's legal basis list (10 bases, Art. 7) is broader than GDPR's 6 (Art. 6) — notably adding credit protection and public policy execution — but Contract, Legal Obligation, Legitimate Interest, and Consent operate analogously to their GDPR counterparts, so if you already have a GDPR Art. 6 mapping for this data, it will closely mirror the Art. 7 mapping above.*

Yes — LGPD almost certainly applies to your company, even though you are a US-based SaaS provider. Here is the analysis.

## 1. Does LGPD apply to you?

LGPD (Lei Geral de Proteção de Dados, Brazil's Law No. 13,709/2018) has extraterritorial reach similar to GDPR. Under **Article 3**, LGPD applies to any processing operation:

- carried out in Brazil, **or**
- where the purpose of the processing is to offer or supply goods or services to individuals located in Brazil (Art. 3, II), **or**
- where the personal data being processed was collected in Brazil (Art. 3, III).

Because your app has Brazilian customers and you are actively collecting their name, email, CPF, and purchase history in connection with offering them a service, you fall squarely within Art. 3, II and III. Your company's location in the US, and the absence of a Brazilian legal entity, does not exempt you — LGPD, like GDPR, is triggered by whose data you process and where those individuals are, not where your company is incorporated or hosted.

A few implications that follow from this:

- **CPF is a significant risk factor.** CPF (Cadastro de Pessoas Físicas) is a Brazilian national taxpayer/individual ID number, functionally similar to a US SSN. It is a high-sensitivity identifier frequently targeted by fraud, and Brazilian regulators (ANPD) and courts treat mishandling of CPF numbers seriously. While CPF is not automatically classified as "sensitive personal data" under Art. 5, II (that category is reserved for racial/ethnic origin, religious belief, political opinion, health data, biometric data, genetic data, sexual orientation, union membership, etc.), it is still a high-risk identifier that warrants strong security controls, minimization, and careful legal-basis justification because of its use in identity theft and financial fraud.
- **You likely need a representative in Brazil.** Art. 27 requires foreign controllers/processors that process data covered by Art. 3 to appoint a representative in Brazil for communications with data subjects and the ANPD (Autoridade Nacional de Proteção de Dados). This is analogous to the GDPR Art. 27 EU representative requirement.
- **You need a legal basis for every processing activity**, a lawful, documented retention policy, security safeguards (Art. 46-49), and mechanisms to honor data subject rights (Art. 18: confirmation, access, correction, anonymization/blocking/deletion, portability, information about sharing, information about the possibility of not consenting, and revocation of consent).
- **International transfers matter.** Since your infrastructure and company are US-based, you are transferring Brazilian personal data outside Brazil. Under Art. 33, this requires one of: an ANPD-recognized adequacy decision for the destination country (the US does not currently have one), standard contractual clauses/ANPD-approved contractual clauses, binding corporate rules, specific consent from the data subject for the transfer (Art. 33, VIII), or another Art. 33 mechanism. In practice, many US companies rely on specific, informed consent for the international transfer, or ANPD standard contractual clauses once finalized/adopted, combined with a DPA with any subprocessors.

## 2. Which legal bases apply?

LGPD Art. 7 lists ten legal bases for processing ordinary personal data. For a SaaS platform collecting name, email, CPF, and purchase history, the realistic bases are:

- **Art. 7, V — Contract performance (execução de contrato):** This is your primary basis for name, email, and purchase history where processing is necessary to perform the contract with the customer (account creation, service delivery, billing, order fulfillment, customer support). This mirrors GDPR Art. 6(1)(b) and is generally the cleanest basis for core account and transaction data.
- **Art. 7, I — Consent (consentimento):** Required for processing that goes beyond what's strictly necessary to perform the contract — e.g., marketing emails, behavioral profiling for advertising, sharing data with third parties for purposes unrelated to service delivery, or any secondary use. LGPD consent must be freely given, informed, unambiguous, and for a specific purpose (Art. 8) — pre-ticked boxes or bundled consent are not valid. CPF collected for purposes beyond the core contract (e.g., optional marketing profiling) would need separate consent.
- **Art. 7, IX — Legitimate interests (legítimo interesse):** Can support certain internal purposes like fraud prevention, security monitoring, or service improvement, but Art. 10 requires a documented balancing test (similar to GDPR's LIA), and legitimate interest is explicitly **not available to public authorities** and is subject to closer scrutiny by ANPD for consumer-facing services. It is a weaker basis for CPF specifically, given the fraud-sensitivity of that identifier — most companies default to contract necessity or consent for CPF rather than legitimate interest.
- **Art. 7, II / VI — Legal or regulatory obligation, or compliance with a legal obligation:** If Brazilian tax, consumer protection, or invoicing rules require you to collect and retain CPF (e.g., for issuing valid Brazilian tax invoices/nota fiscal, or complying with Brazilian consumer/tax law when billing Brazilian customers), this becomes an independent legal basis specifically for the CPF collection and retention, separate from contract necessity.

### Practical mapping for your four data elements

| Data element | Most likely legal basis | Notes |
|---|---|---|
| Name | Art. 7, V (contract) | Core to account/service delivery |
| Email | Art. 7, V (contract); Art. 7, I (consent) for marketing use | Split basis if email is also used for marketing |
| CPF | Art. 7, V (contract) and/or Art. 7, II (legal obligation) | Justify why CPF is necessary — if it's for Brazilian tax/invoicing compliance, document that; avoid collecting CPF "just in case" — minimize to what's necessary |
| Purchase history | Art. 7, V (contract); Art. 7, IX (legitimate interest) for analytics | Consent needed if used for ad targeting/profiling beyond service purposes |

## 3. Recommended next steps

1. **Map the data flows** — confirm exactly why CPF is collected and whether it's truly necessary (data minimization, Art. 6, III).
2. **Appoint a Brazil representative** (Art. 27) and, if processing volume/risk warrants it, designate a DPO (Encarregado) under Art. 41 — note that unlike GDPR, LGPD does not have a strict numeric/risk threshold, so ANPD guidance should be checked.
3. **Update your privacy notice** to include LGPD-required disclosures (purpose, legal basis, retention, data subject rights, international transfer mechanism, and how to exercise Art. 18 rights).
4. **Document your international transfer mechanism** (Art. 33) — this is one of the most commonly missed items for US companies serving Brazilian customers.
5. **Run a legal basis assessment (similar to a GDPR Records of Processing/LIA)** for each processing purpose, and separate consent flows from contract-necessity processing so you aren't over-relying on consent for things that are actually contractually necessary (a common LGPD compliance error).
6. **Apply enhanced security controls to CPF** given its sensitivity to fraud, even though it isn't a "sensitive data" category under Art. 5, II.

**Bottom line:** Yes, you need to comply with LGPD due to extraterritorial application under Art. 3. Your primary legal basis will be contract performance (Art. 7, V) for core account/transaction data, supplemented by consent (Art. 7, I) for any marketing/secondary use, possible legal obligation (Art. 7, II) for CPF if tied to Brazilian tax/invoicing requirements, and legitimate interest (Art. 7, IX) only for narrow, well-documented internal purposes like fraud prevention — not as a default basis for CPF.

*This is general compliance guidance, not legal advice. Given the sensitivity of CPF and the international transfer requirements, consult Brazilian data protection counsel to finalize your legal basis documentation and transfer mechanism.*

# Handling a Brazilian Data Deletion Request Under LGPD

A user in Brazil emailing to request deletion of "all their personal data" is exercising rights under **LGPD Art. 18, IV and VI**. Here's how to handle it, from intake to closure.

---

## Step-by-Step Workflow

### Step 1 — Verify Identity
Before acting on the request, confirm the requestor is who they claim to be (e.g., verify via the email address on file, or request additional confirmation such as a login/account verification). This protects against fraudulent deletion requests and is implicit in the controller's accountability duty (Art. 6, X — Accountability).

**Timeline:** Do this immediately upon receipt; don't let verification delay eat into your response clock unnecessarily.

### Step 2 — Classify the Request
This is a deletion request under:
- **Art. 18, IV** — deletion of unnecessary, excessive, or non-compliant data, and
- **Art. 18, VI** — deletion of data processed with the data subject's **consent**, upon revocation.

Note: if any of the data was processed under a *different* legal basis (e.g., **Art. 7, V — contract**, or **Art. 7, II — legal obligation**), the Art. 18, VI deletion right does not automatically apply to that data — see Step 3.

### Step 3 — Check for Retention Exceptions (Art. 16)
Not all data must be deleted just because the subject asked. LGPD permits retention despite a deletion request where necessary for:
- **Art. 16, I** — compliance with a legal or regulatory obligation by the controller
- **Art. 16, II** — study by a research body (with anonymisation where possible)
- **Art. 16, III** — transfer to a third party, provided LGPD data protection requirements are respected
- **Art. 16, IV** — exclusive use of the controller, access by third parties barred, and the data is anonymised

Practically, for a CRM/email/analytics stack, this means:
- Financial or tax records tied to invoices (if any exist in the CRM) may need to be retained per Brazilian legal/regulatory obligations (Art. 16, I) — delete the marketing/profile data but retain only what's legally mandated, and inform the user of this partial exception.
- Data kept purely for legitimate interest or contract performance that has since ended should generally be deleted along with the consent-based data, unless another Art. 7 basis with a lawful retention need still applies.

**Timeline:** Complete this assessment before responding — ideally within the first few days, since it determines the scope of what you can promise to delete.

### Step 4 — Locate the Data Across All Systems
Map the data subject's personal data across every system you named:

| System | Likely Data Categories | Action |
|--------|------------------------|--------|
| **CRM** | Name, email, phone, deal/interaction history, notes | Delete or anonymise subject record; check for legal-hold/financial records exception (Art. 16, I) |
| **Email platform** (e.g., marketing/ESP) | Email address, campaign engagement history, subscription status | Delete/suppress from all lists; remove from send history where feasible; ensure suppression doesn't itself retain more data than necessary |
| **Analytics tool** | Behavioral/usage data tied to identifiers (cookies, user ID, IP) | Delete or anonymise identifiers; if data is already aggregated/anonymised such that the individual is no longer identifiable, LGPD no longer applies to it (Art. 5, III definition of personal data requires identifiability) |

Also check for **any processors** acting on your behalf (Art. 39) — as controller, you are responsible for instructing your processors (CRM vendor, ESP, analytics vendor) to also delete the data per your instructions, per your data processing agreements.

### Step 5 — Execute Deletion (or Anonymisation) and Instruct Processors
- Delete/anonymise the data in each system identified in Step 4.
- Send deletion instructions to any third-party processors or sub-processors holding the data on your behalf (Art. 39 — processors must act only per controller instructions).
- If full deletion isn't possible for a given data element due to an Art. 16 exception, **anonymise** it instead where feasible, so it no longer constitutes "personal data."

### Step 6 — Respond to the Data Subject
Reply to the user confirming:
- What was deleted and from which systems
- Any data retained under an Art. 16 exception, and the specific legal basis for retention (be transparent — this is required by the Transparency principle, Art. 6, VI)
- Confirmation that instructions were sent to relevant processors/vendors

**Timeline:** LGPD requires response **"without undue delay"** for deletion requests (Art. 18, IV/VI). ANPD guidance and practice generally treat this consistently with the **15-day** benchmark set for full access reports (Art. 19) — best practice is to complete deletion and respond within **15 days**, sooner if operationally feasible.

### Step 7 — Log the Request for Accountability
Record in your request log (per the Accountability principle, Art. 6, X):
- Date of request and identity verification method
- Systems affected and actions taken
- Any data retained and the Art. 16 basis cited
- Date of response to data subject

This record demonstrates compliance if ANPD later asks the controller to justify how the request was handled (Art. 18, §3º/§4º allows refusal only where LGPD permits, and controllers must be able to justify any refusal to ANPD).

---

## Summary Table

| Step | Action | Timeline |
|------|--------|----------|
| 1 | Verify requestor identity | Immediately on receipt |
| 2 | Classify request (Art. 18, IV/VI) | Same day |
| 3 | Check Art. 16 retention exceptions | Within first few days |
| 4 | Locate data in CRM, email platform, analytics tool | Within first week |
| 5 | Delete/anonymise data; instruct processors (Art. 39) | Within first week |
| 6 | Respond to data subject with confirmation/exceptions | Without undue delay — target 15 days |
| 7 | Log request and actions taken (Art. 6, X) | Upon completion |

---

## Key Notes
- **No fee** may be charged for exercising this right (Art. 19).
- If any data is genuinely needed for an ongoing legal obligation (e.g., Brazilian tax/invoice retention rules), delete everything else and clearly explain the narrower retention to the user — do not use this as a blanket excuse to retain more than necessary (Necessity principle, Art. 6, III).
- If your CRM, email platform, or analytics tool are third-party vendors acting as **processors**, review your contracts/DPAs now to confirm they support deletion-on-instruction — this is a good moment to close any gaps.
- If the analytics tool only holds pseudonymous/aggregated data where the individual cannot reasonably be re-identified, it may already fall outside the definition of "personal data" (Art. 5, III) — but if any identifier (user ID, device ID, IP) ties back to the individual, it is in scope and must be deleted or anonymised.

Handling a Data Subject's Deletion Request Under LGPD (Lei Geral de Proteção de Dados)

When a Brazilian data subject (titular) emails a request to delete all their personal data, this is an exercise of their rights under Article 18 of the LGPD (Law No. 13.709/2018), specifically the right to deletion/elimination of personal data (Art. 18, VI). Here is how to handle it end-to-end.

## 1. Acknowledge and Authenticate the Request

- Acknowledge receipt promptly (best practice: within a few business days).
- Verify the requester's identity before acting. LGPD does not prescribe a specific method, but you must take reasonable steps to confirm the person emailing is actually the data subject (or their legally authorized representative) — e.g., verify the email matches the account of record, or request additional confirming information. This prevents unauthorized deletion triggered by a third party impersonating the user.
- Log the request (date received, channel, requester identity, scope) — you'll need this to demonstrate compliance (accountability principle, Art. 6, X).

## 2. Determine Scope and Applicable Legal Bases

Deletion under LGPD is not always absolute. Before deleting, assess:

- **What personal data exists and where** — in your case: CRM, email marketing platform, and analytics tool. Map all locations, including backups, logs, and any data shared with third-party processors (operadores).
- **The legal basis under which each category of data was originally processed** (Art. 7). This matters because:
  - If data was processed based on **consent** (Art. 7, I), the data subject can revoke consent and request deletion, and you generally must comply (Art. 18, VI combined with Art. 8, §5).
  - If data is being retained for **compliance with a legal or regulatory obligation** (Art. 16, I) — e.g., tax, accounting, or consumer protection retention requirements — you may need to retain certain records even after a deletion request, but should delete or anonymize everything not covered by that exception.
  - If data is necessary for the **regular exercise of rights in judicial, administrative, or arbitration proceedings** (Art. 16, II), or for the controller's **legitimate interests** where still applicable and not overridden by the request, some retention may be justified.
  - Marketing/analytics data typically has no such retention exception once consent is withdrawn or objection is raised, and should be deleted.

## 3. Execute Deletion Across All Systems

Because your data lives in three systems, coordinate deletion (or anonymization, where deletion isn't feasible) across all of them:

- **CRM**: Delete or anonymize the contact record and associated activity history (notes, deal records, support tickets) unless specific fields must be retained under a legal obligation (e.g., invoicing/tax records tied to a completed transaction — in which case, consider partial deletion/anonymization of non-essential fields while retaining only what's legally required).
- **Email platform**: Remove the individual from all lists/segments and delete their contact record, including engagement history (opens/clicks tied to their identity), and suppress future sends. Simply "unsubscribing" is not sufficient — the underlying personal data record should be deleted.
- **Analytics tool**: Delete or anonymize any user-level identifiers (user IDs, device IDs, IP addresses, email hashes) associated with this individual. Many analytics platforms (e.g., Google Analytics, Mixpanel, Amplitude) provide user-deletion APIs for exactly this purpose — use them rather than manual deletion where available.
- **Backups**: You are not typically required to purge encrypted backups immediately, but you should ensure deleted data is not restored and is purged according to your normal backup rotation/retention schedule, and is not used for any purpose in the interim.
- **Third-party processors (operadores)**: If any of these three tools qualify as processors acting on your behalf (which they generally do), you as the controller (controlador) are responsible for instructing them to delete the data too. Check your data processing agreements/contracts with these vendors for how deletion requests are handled and confirm completion.

## 4. Anonymization as an Alternative

Where full deletion isn't possible due to legitimate retention needs (e.g., financial/tax records), consider **anonymization** (Art. 12) instead — stripping identifying elements so the data can no longer be linked to the individual, while preserving aggregate data you're legally required to keep (e.g., for accounting purposes).

## 5. Respond to the Data Subject

- Confirm what was deleted, what (if anything) was retained and why (citing the specific legal basis, e.g., tax retention obligations), and the timeframe in which action was taken.
- LGPD does not set a hard statutory deadline for responding to rights requests (unlike GDPR's 30 days), but the ANPD (Autoridade Nacional de Proteção de Dados) expects controllers to respond within a reasonable period, and many organizations align with a ~15-day target as a matter of good practice. Check if your privacy policy or internal SLA commits to a specific timeframe, and honor it.
- Provide the response in a clear, accessible, and (if the request came in Portuguese or the user is Brazilian) appropriately localized format.

## 6. Document the Process

- Maintain a record of the request, verification steps, systems affected, actions taken, any data retained with justification, and the response sent to the data subject. This is essential for accountability (Art. 6, X) and to demonstrate compliance if the ANPD ever asks.

## 7. Preventive/Process Improvements

- If you don't already have one, establish a documented Data Subject Rights Request (DSR) procedure covering identity verification, cross-system deletion workflows (CRM, ESP, analytics, and any other tools), timelines, and exception-handling for legal retention obligations.
- Confirm your vendor contracts (CRM, email platform, analytics) include LGPD-appropriate data processing terms obligating them to support deletion requests within a reasonable timeframe.

### Summary Checklist
1. Acknowledge the request and verify identity.
2. Map data across CRM, email platform, and analytics tool.
3. Check for legal retention obligations (tax, legal claims) that limit full deletion.
4. Delete/anonymize data in each system, including with sub-processors.
5. Handle backups appropriately (no restoration, normal purge cycle).
6. Respond to the user confirming action taken and any retained data with justification.
7. Document everything for accountability purposes.

This approach satisfies the data subject's Art. 18, VI deletion right while respecting any legitimate, narrowly-scoped retention obligations you may have under Brazilian law.

## Short answer

**No — not as described.** Using health insurance data to profile customers for personalised financial-product marketing is very likely **unlawful under LGPD** unless you substantially change your legal basis and design. You are mixing two high-risk categories:

- **Health data** = **sensitive personal data** (Art. 5, II) — subject to the strict regime of **Art. 11**, where **legitimate interest is expressly prohibited** (Art. 10, §2º / recognised restriction under Art. 11).
- **Credit scores** = ordinary personal data, but Art. 7, X specifically contemplates a **"credit protection"** basis — which is about credit risk/analysis, **not marketing**.

Neither basis you'd naturally reach for is enough on its own to cover marketing personalised financial products off the back of health data. Below is the basis-by-basis analysis.

---

## Legal Basis Analysis

### 1. Health insurance data → Sensitive Personal Data (Art. 5, II; Art. 11)

Health data is explicitly listed as sensitive personal data under **Art. 5, II**. Under **Art. 11**, sensitive data may only be processed on one of these grounds:

| Art. 11 basis | Available for marketing use here? |
|---|---|
| Express, specific, highlighted consent | **Yes — only viable route**, but must be separate from any other consent and cannot be bundled with general T&Cs |
| Legal obligation | No |
| Public policy (by public entity) | No |
| Research by research bodies (anonymised) | No — not applicable to commercial marketing |
| Exercise of rights in judicial/administrative/arbitral proceedings | No |
| Protection of life/physical safety | No |
| Health care by health professionals/authorities/services | No — marketing is not health care provision |
| Fraud prevention / data subject's safety | No |
| Credit protection | **No — Art. 11 explicitly excludes legitimate interest, and "credit protection" as a ground for sensitive data is narrowly tied to credit risk analysis, not marketing** |

**Key point (Art. 10, §2º / Art. 11 structure):** Legitimate interest (Art. 7, IX) — which many companies default to for marketing — **cannot be used for sensitive data at all**. This closes off the most common marketing basis entirely for the health insurance component of your processing.

**Conclusion:** The *only* lawful basis for using health insurance data in marketing is **express, specific, and highlighted consent** (Art. 11, I, read with Art. 8). This consent:
- Must be **separate and distinguishable** from consent to other processing (e.g., cannot be folded into "accept our privacy policy" or account opening T&Cs)
- Must **specifically name** the use of health data for marketing/product personalisation purposes
- Must be **freely given** — cannot be a condition of using the core financial product/account (Art. 8, §2º-equivalent: cannot condition service on non-necessary consent)
- Must be **easily revocable**, with revocation not degrading the core service
- Carries the **burden of proof on the controller** — you must be able to demonstrate valid consent was obtained

### 2. Credit scores → Regular Personal Data, but purpose-limited

Credit score data is regular (non-sensitive) personal data, and Art. 7, X gives you a specific basis — **"credit protection, including credit analysis and risk of default"**. However:

- This basis is scoped to **credit risk/underwriting purposes**, not to marketing or cross-sell/upsell of financial products. Using it to justify targeted product marketing would likely fail the **purpose limitation** and **adequacy** principles (Art. 6, I–II) — processing must remain compatible with the purpose originally declared to the data subject.
- **Legitimate interest (Art. 7, IX)** is theoretically available for marketing of *non-sensitive* data such as credit scores (this is a common basis for direct marketing under LGPD, similar to GDPR), **but only if**:
  - A documented **balancing test** is conducted (Art. 10) showing the marketing interest does not override the data subject's fundamental rights
  - The processing is within the data subject's **reasonable expectation** — e.g., existing customers might reasonably expect product offers; prospects whose credit data was obtained from a bureau for scoring, then repurposed for marketing, likely would not
  - It is properly documented in the **Legitimate Interest Assessment (LIA)** and RoPA

### 3. The combination problem

Even if you had a valid legitimate-interest basis for the credit-score component, **you cannot use legitimate interest to "unlock" the health data half of the same profile**. Because health insurance data is sensitive, its inclusion in the profiling/targeting logic requires **Art. 11 express consent independently** — you cannot bootstrap sensitive data into a marketing use case via a non-sensitive basis. If your personalisation engine combines both data types (e.g., "customer has diabetes-related health coverage + high credit score → offer product X"), the **entire combined processing activity is governed by the stricter sensitive-data regime**, and consent becomes mandatory for the whole activity, not just the health field.

### 4. Additional risk: discrimination and profiling

- **Art. 6, IX (Non-discrimination principle):** Processing cannot be carried out for unlawful or abusive discriminatory purposes. Using health data (e.g., pre-existing conditions inferred from insurance data) to target or exclude customers from financial products/pricing raises serious non-discrimination exposure — and would likely also implicate Brazilian consumer protection law (Art. 45 LGPD explicitly preserves the Consumer Protection Code) and potentially anti-discrimination/insurance regulatory rules (SUSEP/BACEN oversight for fintechs).
- **Art. 20 (automated decisions):** If product personalisation/pricing is driven by automated profiling, customers have the right to request **review of automated decisions**, and you must be able to explain the criteria/logic used (including whether health/credit data influenced the outcome).

---

## Required Safeguards If You Proceed

If the business proceeds with this use case, the following controls are necessary as a minimum:

| Safeguard | Requirement |
|---|---|
| **Separate, granular consent for health data marketing use** | Art. 11, I / Art. 8 — highlighted, specific, opt-in, not bundled, freely revocable, documented (burden of proof on controller) |
| **Legitimate Interest Assessment (LIA) for credit-score-based marketing (non-sensitive component only)** | Art. 10 — documented balancing test; must show reasonable expectation and no override of data subject rights |
| **Strict purpose separation in RoPA** | Art. 37 — document health data (consent-based) and credit score (Art. 7,X / LI-based) as distinct processing activities with distinct bases, not commingled under one generic "marketing" entry |
| **DPIA / RIPD before launch** | Art. 38 — mandatory given sensitive data + profiling + financial products; ANPD can require disclosure |
| **Non-discrimination review** | Art. 6, IX — test personalisation/pricing logic for proxy discrimination based on health status |
| **Automated decision transparency + human review channel** | Art. 20 — disclose profiling logic; provide review mechanism |
| **DPO (Encarregado) sign-off** | Art. 41 — DPO should review this use case given sensitive-data + financial-services risk profile |
| **Privacy notice update** | Art. 9 — clearly disclose health data use, legal basis (consent), credit-score use, legal basis (Art. 7,X/LI), and any profiling/automated decision-making |
| **Security measures proportional to risk** | Art. 46 — sensitive financial + health data combined is high-risk; encryption, access controls, and audit logging expected |
| **Consent withdrawal must not degrade core banking/insurance service** | Art. 8 — marketing consent withdrawal cannot affect the customer's ability to use the core financial product |
| **Regulatory overlay** | Confirm alignment with BACEN (Central Bank) and, if applicable, SUSEP rules on data use in financial/insurance products, in addition to LGPD |

---

## Recommendation

1. **Do not use health insurance data for marketing personalisation without obtaining separate, express, highlighted consent** under Art. 11, I. Do not rely on legitimate interest for this component — it is not legally available.
2. For the **credit score** component alone, legitimate interest may be viable for existing customers with a documented LIA, but **cannot be blended with sensitive health data** in the same processing activity without triggering the consent requirement for the whole activity.
3. Conduct a **DPIA/RIPD** before launch given the sensitive-data + financial-profiling risk profile, and have your DPO formally review the use case.
4. Consider whether the marketing objective can be achieved with **less sensitive proxies** (e.g., product category interest, stated preferences) rather than raw health insurance data — this better aligns with the **necessity and data minimisation principles (Art. 6, III)** and substantially reduces regulatory and reputational risk.

Short answer: No — not as you've described it. Using health data and credit scores to build marketing profiles for personalized financial products is very likely unlawful under Brazil's LGPD (Lei Geral de Proteção de Dados, Law No. 13,709/2018) as currently planned. Health data is "sensitive personal data" with a restrictive legal basis regime, and using it for marketing/commercial profiling is one of the clearest LGPD red flags. Credit score data, while not "sensitive" under LGPD's closed list, is also tightly regulated (via LGPD plus the Cadastro Positivo law) and raises purpose-limitation and profiling concerns when repurposed for marketing.

Below is a breakdown of why, what legal bases could theoretically apply, and what safeguards would be required if you still want to pursue any part of this.

## 1. Classify the data correctly

**Health insurance data → "dado pessoal sensível" (sensitive personal data), Art. 5º, II**
LGPD explicitly lists "dado referente à saúde" (health-related data) as sensitive personal data, alongside racial/ethnic origin, religious belief, political opinion, genetic/biometric data, and data on sex life. Health insurance data (coverage, claims, pre-existing conditions, treatments) falls squarely in this category.

**Credit score data → regular personal data, but heavily regulated**
Credit scoring data isn't on LGPD's sensitive-data list, but it's still personal data subject to LGPD's general regime, and it's additionally governed by:
- The Cadastro Positivo law (Law No. 12,414/2011, as amended by LC 166/2019), which sets specific rules for credit scoring databases (transparency, right to explanation of methodology, correction rights).
- LGPD Art. 20, which gives data subjects the right to request review of decisions made solely by automated processing (including scoring/profiling) that affect their interests.

## 2. Why sensitive health data can't be used for marketing purposes

For sensitive personal data, LGPD Art. 11 provides an exhaustive (closed) list of legal bases — narrower than the general Art. 7 list for ordinary data. The available bases are essentially:
- Specific and highlighted ("destacado") consent, for one or more determined purposes;
- Compliance with a legal or regulatory obligation by the controller;
- Shared data processing by public administration for public policy execution;
- Studies by research bodies, with anonymization when possible;
- Regular exercise of rights in judicial, administrative, or arbitration proceedings;
- Protection of life or physical safety (of the data subject or a third party);
- Health protection, exclusively, in a procedure carried out by health professionals, health services, or health authorities;
- Fraud prevention and security of the data subject, in identification/authentication processes for registration systems (with limits).

**Marketing personalized financial products is not on this list.** There is no "legitimate interest" basis available for sensitive data — legitimate interest (Art. 10) applies only to ordinary personal data, not sensitive data. This is the single most important compliance point: you cannot rely on legitimate interest to justify using health data for marketing, no matter how compelling the business case.

That leaves **specific, highlighted, opt-in consent (Art. 11, I c/c Art. 8, §4º)** as essentially the only realistic path — and even then, several problems remain:

- **Purpose limitation (Art. 6º, I):** The health data was presumably collected for insurance/underwriting or administrative purposes, not marketing. Repurposing it requires a new, specific legal basis and, practically, fresh consent — you can't quietly extend the original purpose.
- **Necessity and non-excessiveness (Art. 6º, III):** Regulators (ANPD) and courts will ask whether health data is actually *necessary* to personalize a financial product, or whether less sensitive proxies would achieve the same goal. Marketing personalization is rarely considered "necessary" enough to justify using sensitive health data — this is treated as disproportionate.
- **Non-discrimination principle (Art. 6º, IX):** LGPD explicitly prohibits processing for "unlawful or abusive discriminatory purposes." Using health status to steer people toward or away from financial products (e.g., insurance, credit, loans) risks being seen as discriminatory — denying or upselling products based on health conditions is a classic red flag that regulators and courts treat harshly, especially for a financially vulnerable population.
- **ANPD and sectoral scrutiny:** The Brazilian Central Bank (BACEN) and CVM also regulate fintechs, and using health data to price or target financial products could trigger conduct-risk and consumer-protection issues under the Consumer Defense Code (CDC) in addition to LGPD — Brazilian courts have been aggressive on this front (e.g., cases involving insurers/banks improperly acquiring health data).

**Bottom line on health data:** using it for marketing is not a "find the right legal basis and safeguards" exercise — it is close to a per se violation absent a genuinely specific, freestanding, opt-in consent collected for that exact purpose, which is difficult to obtain and easy to challenge, and it will still fail the necessity/non-discrimination tests in most fintech marketing scenarios. Realistic recommendation: **do not use health insurance data for marketing personalized financial products.** Firewall it entirely from marketing/analytics systems.

## 3. Credit score data — more paths available, but still constrained

Credit score data is ordinary personal data, so more of the Art. 7 legal bases are theoretically available:

- **Consent (Art. 7º, I):** Freely given, informed, unambiguous, for a specific purpose. Pre-ticked boxes or bundled "accept all" consent won't qualify.
- **Legitimate interest (Art. 7º, IX / Art. 10):** Potentially available for using existing customer data to personalize offers to *existing customers*, but:
  - Must pass a documented Legitimate Interest Assessment (balancing test) weighing the controller's interest against the data subject's fundamental rights and reasonable expectations.
  - Cannot be used to justify sending marketing to *prospects* whose data you obtained from third parties (e.g., purchased credit bureau data) without their knowledge — that generally requires consent or another concrete basis, plus proper transparency (Art. 9).
  - Legitimate interest cannot be used for sensitive data, and cannot be used if it would be "abusive" — profiling based on credit score to push higher-cost products to financially strained consumers would likely fail the balancing test and could also violate CDC vulnerability protections.
- **Contract execution (Art. 7º, V):** Could justify using credit score data to determine eligibility/pricing for a product the customer actively requested, but not to justify unsolicited marketing of other products.

Credit score data also triggers **Art. 20 (automated decision-making rights):** if you use scores to algorithmically select who receives which offer, the data subject can request:
- Review of automated decisions that affect their interests (human review, though ANPD/legislative debate continues on whether this must be human or can be a "meaningful review");
- Clear and adequate information about the criteria and procedures used, subject to trade-secret limits (though ANPD's stance, echoing GDPR, is that "trade secret" cannot be used to block all transparency).

## 4. Legal bases summary table

| Data type | Usable for marketing personalization? | Applicable basis |
|---|---|---|
| Health insurance data (sensitive) | Practically no | Only specific, highlighted opt-in consent (Art. 11, I) — and even then fails necessity/non-discrimination tests in most cases |
| Credit score (ordinary, regulated) | Conditionally yes, with limits | Consent (preferred) or narrowly-scoped, documented legitimate interest for existing customers only; contract basis only for the specific product requested |

## 5. Required safeguards if you proceed with credit-score-based personalization only

1. **Drop health data from the marketing/personalization use case entirely.** Segregate it technically (separate systems/access controls) from marketing and analytics pipelines to avoid function creep.
2. **Specific, granular, opt-in consent** for marketing use of credit-related data — separate from consent for account opening/underwriting, written in clear language (Art. 8, §4º prohibits generic consent).
3. **Data Protection Impact Assessment (Relatório de Impacto à Proteção de Dados Pessoais, Art. 38 / ANPD Resolution)** — especially given profiling of financial/credit data and potential impact on vulnerable populations. ANPD has signaled increased scrutiny of profiling for financial services.
4. **Legitimate Interest Assessment documentation** if relying on Art. 7º, IX for existing customers — must be filed/available for ANPD upon request (Art. 10, §2º) and must not use sensitive data.
5. **Transparency (Art. 9):** Clear privacy notice disclosing that credit score is used for marketing personalization, the logic involved, and how to opt out.
6. **Right to object / easy opt-out** from marketing processing at any time (Art. 18, IV and general marketing best practice, reinforced by CDC).
7. **Non-discrimination safeguards:** Document that credit-based personalization does not result in predatory targeting (e.g., steering financially vulnerable customers to high-cost credit products), which would violate both Art. 6º, IX and CDC vulnerability protections, and could draw BACEN/PROCON scrutiny.
8. **Automated decision-making transparency (Art. 20):** Provide a mechanism for customers to request review/explanation of how credit-based offers/scores were generated.
9. **Data minimization:** Use the minimum data/derived features necessary (e.g., a risk tier rather than granular credit history) rather than raw credit bureau data for marketing purposes.
10. **DPO (encarregado) involvement and vendor/DPA review** if credit score data comes from or is shared with third-party bureaus or marketing platforms — requires data processing agreements compliant with Art. 39/Art. 42.
11. **Retention limits:** Marketing use of credit data should have a defined retention period tied to purpose (Art. 15/16), not indefinite retention.
12. **Regular audit trail:** Keep records of consent, LIA, and DPIA for ANPD accountability requirements (Art. 6º, X — accountability principle) — ANPD can and does request these in enforcement actions.

## 6. Practical recommendation

- **Health insurance data:** Exclude it from marketing personalization use cases altogether. The combination of "sensitive data" classification, the closed list of Art. 11 legal bases (no legitimate interest available), and the non-discrimination principle makes this a high-risk, low-viability path. If there's a genuine health-adjacent product need (e.g., a health-linked insurance product), that would need to be its own tightly scoped, separately consented flow — not folded into general marketing personalization.
- **Credit score data:** Feasible only with specific consent (preferred) or a well-documented, narrow legitimate-interest basis limited to existing customers, backed by a DPIA/LIA, strong transparency, opt-out rights, and non-discrimination safeguards.
- Given BACEN's parallel regulatory interest in fintech conduct and the Consumer Defense Code's heightened protection for vulnerable consumers, treat this as a cross-functional legal/compliance review (LGPD + financial regulation + consumer protection), not a pure privacy-team sign-off. Engage your DPO and outside counsel before launching, and consider consulting ANPD guidance/regulations on profiling and sensitive data, which continue to evolve.

*This is general compliance guidance, not legal advice. Given the sensitive-data and financial-services overlap, formal legal review by Brazilian counsel is strongly recommended before implementation.*

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

Note: the facts below (names, emails, encrypted passwords, 50,000 data subjects) drive the analysis. Confirm the details in **bold** with your incident response and legal teams as they firm up — they change the specific ANPD notification content and risk determination.

## 1. Does This Trigger LGPD Breach Notification? (Art. 48)

Under **Art. 48**, controllers must notify the ANPD and affected data subjects when a security incident **may cause relevant risk or harm** to data subjects. Relevant factors here:

| Factor | Assessment |
|--------|-----------|
| Data types exposed | Names, emails, **encrypted** passwords — regular (non-sensitive) personal data under Art. 5 |
| Encryption status | Passwords encrypted reduces (but does not eliminate) risk — confirm algorithm strength, whether keys/salts were also exposed, and whether encryption is reversible or a proper hash |
| Volume | 50,000 data subjects — large-scale, a factor ANPD explicitly prioritizes for enforcement |
| Likely harm | Credential-stuffing risk if encryption is weak/reversible; phishing risk from exposed names + emails |

**Conclusion:** This is very likely a notifiable incident under Art. 48. Even with encrypted passwords, the exposure of names + emails at 50,000-subject scale creates a reasonable risk of harm (phishing, identity-linkage, credential attacks if encryption is weak). Treat this as **notifiable** unless your security team can affirmatively demonstrate the encryption renders the passwords unusable and no other risk vector exists — and document that determination either way for accountability (Art. 6, X).

---

## 2. Notification Timeline (ANPD Resolution CD/ANPD No. 15/2024)

LGPD's breach timeline differs from GDPR's 72-hour rule — Brazil uses **working days**, not calendar hours:

| Milestone | Deadline | Notes |
|-----------|----------|-------|
| **Preliminary ANPD notification** | **3 working days** from awareness of the incident | Initial notice; can be updated as facts develop |
| **Data subject notification** | Without undue delay, where high risk of harm | Assess in parallel with ANPD notice |
| **Full incident report to ANPD** | **20 working days** from confirmation | Complete details once investigation matures |

Since the user asked about the "next 72 hours," note the important distinction: **LGPD's clock is 3 *working* days, not 72 calendar hours** (that's the GDPR standard, which would also apply in parallel if any of the 50,000 individuals are also EU residents or the breach otherwise touches GDPR-scoped data). If your breach also has an EU nexus, run both clocks simultaneously — GDPR is stricter (72 hours, calendar) and LGPD is separate (3 working days). Confirm with counsel whether any EU-resident data subjects are in this dataset.

---

## 3. Incident Timeline & Action Checklist — Next 72 Hours

### Hour 0–24: Detect, Contain, Assess
- [ ] **Contain** — isolate affected database/systems, revoke compromised credentials, patch the exploited vulnerability, preserve forensic evidence (logs, snapshots) before remediation destroys evidence
- [ ] **Confirm scope** — verify the 50,000-record figure; identify exact data fields exposed (confirm no CPF, financial, or sensitive-category data under Art. 5/Art. 11 is also involved)
- [ ] **Assess encryption strength** — determine algorithm, whether salted/hashed vs. reversibly encrypted, and whether keys were exposed; this materially affects the risk rating
- [ ] **Engage DPO (Encarregado)** — LGPD requires the appointed DPO to be the point of contact for this process (Art. 41); loop in legal, security, and executive stakeholders
- [ ] **Open incident record** — start the accountability documentation required by Art. 6, X and Art. 47 (governance obligation); this record supports your defense if ANPD investigates

### Hour 24–48: Risk Determination & Notification Prep
- [ ] **Make the Art. 48 risk determination** — document the "relevant risk or harm" analysis (volume, data sensitivity, likelihood of misuse, encryption efficacy)
- [ ] **Draft preliminary ANPD notification**, including (per Art. 48 content requirements):
  - Nature and category of affected data (names, emails, encrypted passwords)
  - Number/categories of data subjects affected (~50,000)
  - Technical and security measures used to protect the data (including encryption)
  - Risks related to the incident
  - Measures taken or planned to reverse/mitigate the effects
  - Reason for any delay, if notification is not immediate
- [ ] **Draft data subject notification** (plain language) — likely required given email/credential exposure; should include what happened, data involved, recommended actions (password reset, monitor for phishing), and contact channel (DPO)
- [ ] **Check parallel obligations** — GDPR 72-hour clock if EU nexus exists; sector regulators (e.g., Banco Central if financial services); state consumer protection (CDC/SENACON) notice triggers

### Hour 48–72: Notify & Begin Remediation
- [ ] **Submit preliminary notification to ANPD** — must occur within **3 working days** of awareness (note: working days, so weekends don't count toward this deadline — confirm your actual deadline based on the awareness date)
- [ ] **Notify affected data subjects** where high risk of harm is present — via email is appropriate here since email addresses are the compromised contact channel (verify a clean/unaffected channel if email deliverability itself is compromised)
- [ ] **Force password resets** for all 50,000 affected accounts as a mitigation measure; recommend MFA enrollment
- [ ] **Monitor for exploitation** — credential-stuffing attempts, phishing campaigns targeting exposed emails
- [ ] **Begin root-cause remediation** — vulnerability patching, access control review, security control gap-fix plan

### Beyond 72 Hours (upcoming milestones — do not lose track)
- [ ] **Full incident report to ANPD within 20 working days** of confirmation, with complete forensic findings, root cause, and remediation plan
- [ ] **Post-incident review** — update RoPA, security measures (Art. 46), and RIPD/DPIA if this processing activity now qualifies as high-risk
- [ ] **Board/leadership briefing** and, if applicable, securities/public disclosure obligations (separate from LGPD)

---

## 4. Key Risk Exposure to Flag Internally

| Risk Area | LGPD Basis | Exposure |
|-----------|-----------|----------|
| Missed/late ANPD notification | Art. 48 + Res. CD/ANPD 15/2024 | Warning up to simple fine (Art. 52, II) — **up to 2% of Brazilian revenue, capped at R$50M per violation** |
| Inadequate security measures (Art. 46) if breach reveals control gaps | Art. 46, Art. 52 | Fine, publicisation, possible processing suspension |
| Failure to notify data subjects despite high risk | Art. 48 | Aggravating factor in any ANPD penalty calculation (Art. 52, §1º) |
| Large-scale breach | N/A (enforcement priority) | ANPD has explicitly flagged **large-scale data breaches** as a strategic enforcement priority — expect scrutiny at this volume (50,000 subjects) |

**Mitigating factors you can build now:** promptness of notification, cooperation with ANPD, good-faith remediation, and existing internal controls all reduce fine severity under Art. 52, §1º. Acting within the 3-working-day window and documenting thoroughness works directly in your favor.

---

## 5. Immediate Recommendations

1. **Do not wait for full forensic certainty** — the 3-working-day clock runs from *awareness* of the incident, not from completed investigation. Send the preliminary notification with the information you have and flag that a full report will follow within 20 working days (Art. 48 expressly allows this phased approach).
2. **Verify DPO is engaged and named publicly** (Art. 41) — ANPD will expect the DPO to be the process owner.
3. **Confirm whether any exposed customers are also EU residents** — if so, GDPR's 72-*hour* (calendar) clock is stricter than LGPD's and will control your fastest deadline.
4. **Treat "encrypted passwords" claim carefully** — do not understate risk in your ANPD notice; ANPD scrutinizes whether encryption was actually adequate (Art. 46) at the time of the incident, not just its existence.
5. **Document everything now** — the accountability principle (Art. 6, X) means your ability to demonstrate a timely, good-faith, well-documented response is itself a mitigating factor if ANPD investigates.

Database Breach — LGPD Notification Obligations and 72-Hour Action Plan
=========================================================================

Facts as understood: A database breach exposed names, emails, and encrypted (hashed/encrypted) passwords of 50,000 Brazilian customers.

1. DOES LGPD APPLY?
--------------------
Yes. The Lei Geral de Proteção de Dados (Law No. 13,709/2018) applies because the personal data of natural persons located in Brazil was processed and compromised, regardless of where your company is headquartered (LGPD has extraterritorial reach similar to GDPR — Art. 3). Names and emails are personal data; account credentials (even encrypted) are also personal data whose confidentiality has been breached.

2. NOTIFICATION OBLIGATIONS UNDER LGPD
---------------------------------------
Key provision: LGPD Article 48.

- **Who must be notified:** (a) the ANPD (Autoridade Nacional de Proteção de Dados) — Brazil's data protection authority, and (b) the affected data subjects (titulares), when the incident may create risk or relevant damage to them.
- **Timing:** Unlike GDPR's fixed 72-hour deadline, LGPD Article 48 requires notification within a "reasonable period of time" (prazo razoável), as further defined by ANPD regulation. However, ANPD Resolution CD/ANPD No. 15/2024 (Regulamento de Comunicação de Incidente de Segurança) sets an expectation of notifying the ANPD within 3 business days (72 hours) of the controller becoming aware of the incident for incidents likely to result in relevant risk or damage to data subjects — effectively converging with GDPR practice. Treat 72 hours as your operative internal deadline even if the letter of the law says "reasonable."
- **Threshold/materiality test:** Notification is required when the incident may cause "risco ou dano relevante" (relevant risk or damage) to titulares. A breach of names, emails, and passwords (even encrypted) for 50,000 individuals almost certainly meets this threshold because:
  - Emails + names enable phishing/credential-stuffing and identity-adjacent fraud.
  - Encrypted passwords are not risk-free — if the encryption/hashing is weak (e.g., unsalted MD5/SHA1) or the encryption key was also exposed, passwords could be crackable. Reused passwords across services create account-takeover risk elsewhere.
  - Scale (50,000 individuals) itself is an aggravating factor ANPD considers.
- **What must be included in the ANPD/data subject notification (Art. 48, §1):**
  1. Description of the nature and category of personal data affected.
  2. The data subjects involved (number, categories).
  3. The technical and security measures used to protect the data (prior to and following the incident), observing trade secrets.
  4. The risks related to the incident.
  5. Reasons for any delay in notification, if applicable.
  6. Measures that were or will be adopted to reverse or mitigate the effects of the incident.
- **How to notify data subjects:** Communication must be clear, direct, and in plain language (not just buried in a policy). Typical channels: email to the affected email addresses, in-app/website notice, and potentially a public notice if individual contact isn't feasible for all 50,000 people.
- **Encrypted passwords consideration:** LGPD/ANPD guidance recognizes that adequate encryption can reduce (but not eliminate) risk and may factor into the "reasonable period" and severity assessment — but it does NOT exempt you from notifying if names/emails were also exposed in the clear, since that alone creates relevant risk (phishing, spam, targeted fraud, secondary exposure).

3. OTHER APPLICABLE LEGAL CONSIDERATIONS
------------------------------------------
- If any affected individuals are consumers, the Marco Civil da Internet (Law 12,965/2014) and Consumer Defense Code (CDC) may impose parallel duties of transparency and security.
- If your company operates in regulated sectors (finance, health, telecom), sector regulators (e.g., BACEN, ANS, ANATEL) may have their own breach-notification rules layered on top of LGPD.
- If any of the 50,000 individuals are also EU residents or the company has EU nexus, GDPR's strict 72-hour supervisory-authority deadline runs in parallel — don't assume LGPD's more flexible timeline gives you extra room under GDPR.
- Contractual obligations: check DPAs/contracts with B2B customers or partners requiring you to notify them of breaches affecting their end users, often with tighter deadlines (24–48 hours) than LGPD itself.

4. WHAT TO DO IN THE NEXT 72 HOURS — ACTION PLAN
---------------------------------------------------

**Hour 0–4: Contain and Confirm**
- Activate your incident response plan; convene IR team, legal/DPO (encarregado), security, and executive sponsor.
- Contain the breach: revoke exposed credentials/access, patch the vulnerability, isolate affected systems, rotate database/API keys and admin credentials.
- Preserve forensic evidence (logs, snapshots) before remediating — you'll need this for the ANPD report and any litigation defense.
- Confirm scope: verify the 50,000-record figure, exact data fields exposed, whether the encryption/hashing algorithm and any keys/salts were also exposed, and the exposure window (start/end dates).

**Hour 4–24: Assess and Engage Experts**
- Engage/activate outside breach counsel and a forensic incident response firm if not already retained.
- Assess the encryption strength of the exposed passwords (algorithm, salting, key exposure) — this materially affects risk rating and your notification narrative.
- Determine if this is a reportable incident under Art. 48 (very likely "yes" given scale and data types) and document the risk assessment/decision rationale (needed even if you ultimately argue lower risk).
- Identify your Encarregado (DPO) of record — they typically lead/coordinate the ANPD communication.
- Draft the ANPD notification and the data-subject notification in parallel; get legal sign-off.
- Force a password reset for all 50,000 affected accounts (and consider forcing reset broadly if you can't isolate exposure with certainty). Invalidate active sessions/tokens.
- Begin monitoring for credential-stuffing / anomalous login attempts using the exposed emails.

**Hour 24–72: Notify and Communicate**
- Submit notification to the ANPD via its official channel (petição eletrônica / Sistema de Peticionamento Eletrônico or the specific incident-report form once available), including all Art. 48 §1 elements listed above.
- Send direct notice to affected individuals in plain language: what happened, what data was involved, what you've done, what they should do (reset passwords, enable MFA, watch for phishing, avoid reusing the exposed password elsewhere), and a contact point/support channel.
- Prepare a public-facing statement/FAQ if the incident may become public or press-worthy, coordinated with comms/PR and legal.
- Notify any B2B partners/processors/sub-processors whose data or systems were implicated, per contractual timelines.
- If credit/financial exposure risk exists for any subset of users, consider offering credit monitoring or equivalent support (not strictly required by LGPD but a common risk-mitigation and goodwill measure).
- Log every action, decision, and timestamp — ANPD can request the full incident timeline and your reasoning for timing/scope decisions later.

**Ongoing (beyond 72 hours)**
- Complete root-cause analysis and remediation (patch vulnerabilities, review access controls, add monitoring/alerting).
- Be prepared for ANPD follow-up requests or an administrative sanction process; cooperate and keep documentation organized.
- Conduct a post-incident review and update your incident response plan, data retention practices, and encryption standards.
- Consider whether this incident, given the affected population and data categories, warrants updating your Data Protection Impact Assessment (Relatório de Impacto à Proteção de Dados Pessoais / RIPD) for the underlying processing activity.

5. KEY TAKEAWAYS
-----------------
- Treat 72 hours as your working deadline for notifying the ANPD, consistent with current ANPD regulation, even though the LGPD statutory text says "reasonable period."
- Notify affected data subjects directly and in plain language — don't rely solely on the ANPD filing.
- Encryption on passwords helps your risk narrative but does not eliminate the obligation to notify, especially since names and emails were exposed unencrypted.
- Document everything: your risk assessment, the rationale for your notification timing and scope, and the mitigation steps taken — this documentation is your primary defense in any ANPD inquiry.
- Loop in outside counsel with LGPD/ANPD experience quickly; breach-notification drafting and ANPD engagement have nuances (e.g., what counts as "relevant risk," format of the filing) best handled with specialized support.

Disclaimer: This is general guidance based on LGPD and publicly known ANPD regulatory practice, not formal legal advice. Confirm current ANPD procedural requirements (forms/portal, current resolution numbers) and get sign-off from qualified Brazilian data protection counsel before acting, given the regulatory and factual specifics of your case.

# CSRD Scope Determination — German Manufacturing Company

**Short answer: As of today (15 August 2026), your company is *not* in mandatory CSRD scope.**

## Criteria → Verdict

CSRD scope is no longer governed by the original 2023 wave structure. It is now governed by **Directive (EU) 2026/470** (in force since March 2026), which reset the mandatory-scope test following the Omnibus simplification package.

| Criterion | Your company | Post-Omnibus mandatory threshold (Dir. (EU) 2026/470) | Met? |
|---|---|---|---|
| Employees | 800 | **> 1,000** | ❌ No |
| Net turnover | €120M | **> €450M** | ❌ No |
| Total assets | €55M | (assets are no longer the operative test — headcount + turnover control) | n/a |
| Listing status | Listed, Frankfurt Stock Exchange | Listing alone no longer triggers mandatory scope post-Omnibus | ❌ No |

**Both** the >1,000-employee and >€450M-turnover conditions must be met for mandatory CSRD reporting. Your company clears neither threshold — 800 employees is well under 1,000, and €120M turnover is well under €450M. Under the current rule, **headcount below 1,000 takes a company out of mandatory scope regardless of turnover**, so the turnover and asset figures don't change the outcome here.

Listing on a regulated market (Frankfurt) does **not** independently pull you back into mandatory scope. Under the pre-Omnibus regime, being a listed public-interest entity with >500 employees would have placed you in "wave 1" (first reporting FY2024). That structure has been superseded — listed companies below the new combined threshold now fall into the "out of mandatory scope" category, alongside former wave 2/3 companies and listed SMEs.

## Verdict

**Your company is currently outside mandatory CSRD scope.** You do not have a mandatory first CSRD reporting year under the current rules.

## What this means in practice

- **No mandatory CSRD/ESRS report is currently required.** You are not obligated to produce Scope 1/2/3 disclosures, a double materiality assessment, or a CSRD-tagged management report section under the mandatory regime.
- **Voluntary reporting option:** The Commission adopted the **VSME (Voluntary SME/simplified) standard** on 3 July 2026 alongside the revised ESRS. If lenders, investors, or large customers in your value chain request sustainability data from you (a common "trickle-down" effect even for out-of-scope companies), VSME is the appropriate voluntary reporting vehicle — proportionate and much lighter than full ESRS.
- **If you were already reporting:** If your company had begun CSRD/ESRS reporting under the earlier wave-1 rules (plausible, given your listed PIE status and >500 employees under the old NFRD/CSRD threshold), you should confirm with legal/statutory counsel how the German transposition of Directive (EU) 2026/470 treats companies that already published a CSRD report before the scope change. Member-state transposition of the scope cut is due by approximately 19 March 2027, so there may be a transitional period to manage — don't assume you can simply stop without checking your specific transposition status in Germany.
- **Monitor for change:** If headcount or turnover growth (organic or M&A) pushes you past 1,000 employees *and* €450M turnover, you would re-enter mandatory scope from the relevant future financial year. Track this annually as part of your standard compliance calendar.

## Caveat

This assessment reflects the post-Omnibus framework as understood in August 2026. Non-EU-company thresholds and some transposition details are still being finalized at Member State level. Given your listed status and the recency of this scope change, I'd recommend a brief confirmation with German transposition counsel (or your statutory auditor) before formally communicating an "out of scope" position to your board or investors — this is general compliance information, not legal advice.

# Does Your Company Fall Under CSRD?

Short answer: **yes, almost certainly** — and if your facts are as described, you likely should already be reporting (or very close to your first report).

## Why you're in scope

The Corporate Sustainability Reporting Directive (CSRD) phases companies in based on two overlapping tests: (1) whether you're a "large undertaking" under the EU Accounting Directive size thresholds, and (2) whether you were already caught by the old Non-Financial Reporting Directive (NFRD).

**Size test (large undertaking):** A company is "large" if it exceeds at least two of three thresholds:
- More than 250 employees (you have 800 — well over)
- Net turnover above roughly €50M (you have €120M — well over)
- Balance sheet total above roughly €25M (you have €55M — well over)

You clearly qualify as a large undertaking on all three metrics.

**Listed status:** Being listed on the Frankfurt Stock Exchange's regulated market (as opposed to an open/MTF segment like Scale) makes you a "public-interest entity" (PIE) for EU purposes. A listed PIE with more than 500 employees was already subject to the NFRD — the CSRD's predecessor regime. Since you have 800 employees and are listed, that description fits you.

## When you first report

Because you appear to meet the NFRD-legacy profile (listed PIE, >500 employees, large undertaking), you fall into the **first wave** of CSRD reporters:
- First reporting year: **financial year 2024**
- First CSRD/ESRS report published: **2025**, alongside your FY2024 management report

If that's correct, you should already have published your first ESRS-based sustainability statement in 2025, and you'd now be preparing your **second** report — for FY2025, to be published in 2026.

If you were *not* actually caught by NFRD before (for example, if your listing or employee count only recently crossed 500), you may instead fall into the second wave of large companies (originally FY2025 reporting, published 2026), though note that the EU's 2025 "Omnibus" simplification package delayed this second wave's timeline by two years for companies not previously subject to NFRD — worth confirming your exact wave against the final adopted texts, since this has been a moving target.

## What to check next

1. Confirm your Frankfurt listing is on a regulated market (Prime Standard/General Standard), not the Scale segment, since that affects PIE status.
2. Confirm whether you were already reporting under German NFRD implementation (§289b–e / §315b–c HGB) — if so, you're Wave 1, already in scope for FY2024.
3. Identify your material topics via a double materiality assessment (mandatory first step) to determine which ESRS topical standards apply beyond the mandatory cross-cutting standards (ESRS 1 and ESRS 2).
4. Line up limited assurance from your statutory auditor or an independent assurance provider, as CSRD reports require external assurance from the outset.

Given the significant legislative activity around CSRD simplification in 2024–2025 (the Omnibus package), I'd recommend verifying your exact wave and first reporting deadline against the current German transposition of the directive and any subsequent amendments, since thresholds and timelines have been actively revised.

# Double Materiality Under CSRD: Concept, Comparison, and Assessment Process

## What Double Materiality Means

Double materiality is the cornerstone reporting principle of CSRD (Directive (EU) 2022/2464) and is defined in **ESRS 1, paragraphs 19–44**. It requires a company to assess sustainability matters from **two independent perspectives**, and to report on a topic if it is material under *either* lens:

**1. Impact Materiality ("inside-out")**
Does the company have actual or potential impacts — positive or negative — on people or the environment, through its own operations and its upstream/downstream value chain?

- Assessed using: **Scale × Scope × Irremediability** (for negative impacts), with **Likelihood** added for potential (not-yet-occurred) impacts
- Positive impacts use Scale × Scope (× Likelihood if potential)
- Time horizons: short (<1 year), medium (1–5 years), long (>5 years)

**2. Financial Materiality ("outside-in")**
Could the sustainability matter generate risks or opportunities that affect the company's financial position, performance, cash flows, access to finance, or cost of capital?

- Assessed using: **Magnitude × Likelihood** of the financial effect
- Sources: physical risks (acute/chronic), transition risks (policy, technology, market, reputational), and opportunities

**A topic is material if it meets either criterion — it does not need to meet both.** Material topics must be reported in full against the relevant ESRS topical standard; non-material topics may be omitted, but only with a brief documented justification in the materiality statement (this omission bar is high for climate — ESRS E1 is presumed material for most large companies and requires compelling evidence to exclude).

## How This Differs from GRI and TCFD

| Aspect | CSRD/ESRS | GRI | TCFD |
|---|---|---|---|
| Materiality lens | **Double** (impact + financial) — mandatory | **Impact only** (effect on economy, environment, people) | **Financial only** (effect on the company) |
| Legal status | Mandatory (EU law) | Voluntary | Voluntary (mandatory in some jurisdictions for climate specifically) |
| Threshold to report | Either lens trips → report | Impact significance to stakeholders | Financial risk/opportunity relevance to investors |
| Value chain | Required where material | Encouraged | Required for climate |
| Scope 3 GHG | Required if E1 material | Encouraged | Required |

The key conceptual difference: **GRI asks "how does the company affect the world?"** (impact materiality only), while **TCFD asks "how does the world (climate) affect the company financially?"** (financial materiality only, and only for climate). CSRD's double materiality effectively merges both questions and extends the financial-materiality lens across *all* ESRS topics (not just climate), while also formalizing GRI-style impact materiality with a EU-mandated methodology, stakeholder engagement requirement, and assurance obligation neither GRI nor TCFD carries.

Practically, this means a topic that GRI would flag as material (e.g., biodiversity impact on a local community) is CSRD-material even if it has zero foreseeable effect on the company's financials — and a topic TCFD would flag as material (e.g., carbon pricing risk) is CSRD-material even if the company's own environmental footprint from that source is negligible. Companies with existing GRI reports have a head start on the impact side; companies with TCFD reports have a head start on financial materiality for climate specifically (ESRS E1 incorporates TCFD's four pillars — governance, strategy, risk management, metrics & targets), but TCFD reporters typically still need to add full Scope 3 (all 15 categories), a formal transition plan (E1-1), and EU Taxonomy alignment.

## How to Conduct a Double Materiality Assessment (ESRS 1, paras. 45–56)

**Step 1 — Understand the context.** Map the business model, products/services, geographies, and the full value chain (tier-1+ suppliers, distribution, customers, end-users). Identify sector-specific sustainability risks using industry references (SASB, GRI sector standards, ESRS sector guidance where published).

**Step 2 — Identify actual and potential impacts.** Draw on internal sources (operations review, incident data, management interviews) and external sources (stakeholder engagement, benchmarks, ESG ratings). ESRS 1 para. 22 requires genuine engagement with *affected* stakeholders — not just investors — including workers (own and value chain), local communities, customers/consumers, NGOs, and regulators. Output: a long list of potential impacts by ESRS topic.

**Step 3 — Assess significance of impacts.** Score each impact on Scale, Scope, and Irremediability (1–5 scale each), adding Likelihood for potential impacts. Compute a severity score (e.g., Scale × Scope × Irremediability, max 125 for actual impacts; × Likelihood, max 625 for potential impacts) and compare against a company-defined, documented threshold.

**Step 4 — Identify financial risks and opportunities.** For each ESRS topic, identify physical risks, transition risks, and opportunities, with a description and time horizon (e.g., carbon pricing raising operating costs; water scarcity threatening a production region; employer brand as a talent-attraction opportunity).

**Step 5 — Assess financial significance.** Rate each risk/opportunity on Magnitude (e.g., % of EBITDA) and Likelihood (e.g., <25%, 25–75%, >75%), and derive a financial materiality score against a documented threshold.

**Step 6 — Determine materiality, topic by topic.** Build a matrix of all ESRS topics (E1–E5, S1–S4, G1) showing impact-material Y/N and financially-material Y/N. A "Yes" on either dimension means the topic is material and must be reported in full under the corresponding ESRS topical standard.

**Step 7 — Document the DMA.** This is itself a mandatory disclosure: **ESRS 2 IRO-1** covers the process (scope, methodology, stakeholder engagement, thresholds), and **ESRS 2 SBM-3** covers the output (the list of material topics and their interaction with strategy). Topics excluded as non-material need a brief documented rationale.

**Step 8 — Validate and update at least annually.** Treating the DMA as a one-off exercise is one of the most common pitfalls — it must be reviewed at minimum every year, and re-triggered by major business changes, new regulation, or emerging stakeholder concerns.

### Common pitfalls to avoid
- Scoping the DMA to own operations only (value chain must be considered where material)
- Consulting only investors rather than affected stakeholders (workers, communities)
- Skipping financial materiality and doing an impact-only assessment (or vice versa)
- Setting undocumented/unjustified thresholds
- Running the DMA *after* deciding what to report, rather than letting it drive the reporting scope
- Excluding climate (E1) without strong, documented justification — it's presumed material for most large companies

## A Note on Timing

As of August 2026, the Omnibus reforms have also changed *who* must run a DMA at all: mandatory CSRD scope is now set by **Directive (EU) 2026/470** (>1,000 employees **and** >€450M turnover). If your company is below that combined threshold, a full ESRS-grade DMA is not legally required — though many companies still find a lightweight, DMA-informed materiality exercise useful to prioritize ESG effort and respond to investor/customer sustainability questionnaires (this is effectively what the new voluntary VSME standard, adopted July 2026, is designed to support).

# Double Materiality Under CSRD

## The concept

Double materiality means a sustainability topic must be assessed from **two independent perspectives**, and it is considered material — triggering disclosure — if it is material under **either** one (not both):

1. **Impact materiality (the "inside-out" view):** Does the company have material actual or potential, positive or negative impacts on people or the environment — through its own operations or its upstream/downstream value chain? This is assessed on severity (scale, scope, and whether the impact is irremediable) and, for potential impacts, likelihood.

2. **Financial materiality (the "outside-in" view):** Do sustainability-related matters create material risks or opportunities that affect — or could reasonably be expected to affect — the company's development, financial position, financial performance, cash flows, access to finance, or cost of capital, over the short, medium, or long term? This is assessed on magnitude and likelihood of the financial effect.

A topic that is material under just one lens is material for reporting purposes; you don't need both to converge.

## How this differs from GRI and TCFD

**GRI:** GRI's materiality concept (especially since the 2021 Universal Standards) is essentially the **impact side alone** — it defines material topics as those representing the organization's most significant impacts on the economy, environment, and people, including human rights. GRI is stakeholder-inclusive and impact-first; it doesn't require you to filter by financial relevance to investors. Because of this, ESRS's impact materiality leg is heavily derived from and compatible with GRI's approach — companies with mature GRI reporting usually have a head start on the impact side, but GRI alone won't get you to financial materiality.

**TCFD:** TCFD is the mirror image — it is a **single, financial-materiality** framework focused exclusively on climate-related risks and opportunities that matter to enterprise value and to investors' capital-allocation decisions. It does not ask how the company impacts the climate; it asks how climate change (physical and transition risks/opportunities) impacts the company. ESRS E1 (Climate Change) explicitly builds on TCFD's four-pillar structure (governance, strategy, risk management, metrics and targets), but layers the impact perspective (e.g., your own GHG emissions and their contribution to climate change) on top of the financial one.

So: GRI ≈ impact materiality only; TCFD ≈ financial materiality only (and climate-specific); ESRS double materiality = both, across all sustainability topics (environmental, social, governance).

## How to conduct a double materiality assessment

1. **Understand the business context.** Map your business model, strategy, value chain (upstream suppliers, own operations, downstream customers/users), and key stakeholders (affected stakeholders like employees, communities, workers in the value chain; and users of the report like investors and lenders).

2. **Identify a long list of sustainability matters.** Start from a comprehensive list — ESRS provides a structured list of sustainability sub-topics and sub-sub-topics across environment (climate, pollution, water, biodiversity, resource use/circular economy), social (own workforce, workers in the value chain, affected communities, consumers/end-users), and governance (business conduct) as a starting inventory.

3. **Engage stakeholders.** Consult affected stakeholders (or their legitimate representatives) and users of the sustainability statement to surface impacts, risks, and opportunities you might not identify internally.

4. **Assess impact materiality.** For each topic, identify actual and potential impacts (positive/negative) in your own operations and value chain. Score severity (scale, scope, irremediability) and, for potential impacts, likelihood. Apply a threshold to decide which impacts are "material."

5. **Assess financial materiality.** For each topic, identify risks and opportunities that could generate a material financial effect on the company now or in future reporting periods. Score by magnitude and likelihood, again against a defined threshold.

6. **Consolidate into a materiality matrix.** Plot or table the results; a topic clears the bar if it's material on impact, financial, or both axes.

7. **Determine the final list of material topics.** This list drives which ESRS topical standards (E1–E5, S1–S4, G1) and specific disclosure requirements/datapoints you must report — topics that aren't material can usually be dismissed with a brief explanation rather than full disclosure.

8. **Document, govern, and validate.** Document the methodology, thresholds, and stakeholder input; have it reviewed and approved by management/those charged with governance (this becomes part of ESRS 2 disclosures — IRO-1 on the process, IRO-2 on the resulting disclosure requirements); ensure it can withstand audit/assurance scrutiny.

9. **Review periodically.** Double materiality is not a one-off exercise — it should be revisited at least annually (or when circumstances materially change) as your business, value chain, or risk landscape evolves.

This process, and its outcome, must itself be disclosed under ESRS 2 (the cross-cutting general disclosures standard), since the materiality assessment is the backbone that determines the rest of your CSRD report's content.

# CSRD Disclosure Requirements — Material Topics: E1 (Climate), S1 (Own Workforce), G1 (Business Conduct)

Since your DMA found ESRS E1, S1, and G1 material, you must report full disclosures against those three topical standards. In addition, **ESRS 2 (General Disclosures) is always mandatory** for every in-scope company regardless of DMA outcome — it cannot be reduced or omitted, even for topics found non-material elsewhere.

**One quick flag before drafting:** as of August 2026, confirm whether you're reporting on the **current ESRS (2023, Commission Delegated Regulation (EU) 2023/2772)** or the **revised, simplified ESRS** adopted 3 July 2026 (currently in Parliament/Council scrutiny, expected in force Q4 2026, mandatory for financial years beginning 1 January 2027, with FY2026 early adoption only once the delegated act formally enters into force). The datapoint list below reflects the current (2023) ESRS baseline; the revised ESRS cut mandatory datapoints by roughly 61%, so if you're targeting FY2027+, some of these will be streamlined or dropped.

---

## 1. ESRS 2 — General Disclosures (mandatory regardless of DMA)

| Disclosure | Content |
|---|---|
| **GOV-1** | Governance bodies' role in sustainability — composition, diversity, sustainability expertise, oversight of IROs |
| **GOV-2** | Information provided to and sustainability matters addressed by management/supervisory bodies |
| **GOV-3** | Integration of sustainability performance in incentive schemes (executive remuneration linkage) |
| **GOV-4** | Statement on due diligence (alignment with UN Guiding Principles / OECD Guidelines) |
| **GOV-5** | Risk management and internal controls over sustainability reporting |
| **SBM-1** | Strategy, business model, and full value chain description |
| **SBM-2** | Stakeholder engagement process and how it informed strategy/reporting |
| **SBM-3** | Output of your DMA — material IROs, their interaction with strategy, current and anticipated financial effects |
| **IRO-1** | DMA methodology — scope, process, criteria, stakeholders consulted, thresholds used |

---

## 2. ESRS E1 — Climate Change

Climate is presumed material for most large companies, so expect close scrutiny here. Two datapoints are **mandatory regardless of a materiality finding** at all (i.e., even for companies where E1 came out non-material): the transition plan (E1-1, per Accounting Directive Art. 19a(2)(a)) and fossil-fuel energy consumption (E1-5, para. 40). Since you found E1 material, the full standard applies:

- **E1-1 Transition plan:** decarbonisation targets (2030/2040/2050, 1.5°C-aligned), planned actions and enablers, capex/opex/R&D resourcing, role of carbon offsets (must be distinguished from own-emission reductions), locked-in GHG assets/stranded-asset risk, EU Taxonomy alignment targets
- **E1-2 Policies:** climate mitigation/adaptation policy scope (own ops vs. value chain), net-zero pathway
- **E1-3 Actions and resources:** decarbonisation action plan with timelines and committed resources
- **E1-4 Targets:** GHG reduction targets by scope (1/2/3 separately), Paris alignment, energy/renewables targets
- **E1-5 Energy consumption and mix:** total consumption (MWh), fossil/renewable/nuclear breakdown, energy intensity, renewable share
- **E1-6 GHG emissions:** Scope 1 (direct), Scope 2 location-based *and* market-based, Scope 3 (all 15 GHG Protocol categories), total emissions, GHG intensity per net revenue, methodology disclosure
- **E1-7 GHG removals and carbon credits:** own-operation removals, purchased credits (volume, type, standard), clear distinction in net-zero claims
- **E1-8 Internal carbon pricing:** whether used, price per tCO2e, application scope
- **E1-9 Anticipated financial effects:** physical risk (acute/chronic) and transition risk (policy, technology, market, reputational) financial effects, climate opportunities, scenario analysis (1.5°C and >2°C recommended)

**Biggest lift is typically E1-6 Scope 3** (all 15 categories) and **E1-1** (a credible, resourced transition plan) — plan for these early given data and modeling lead time.

---

## 3. ESRS S1 — Own Workforce

- **S1-1** Policies on working conditions, equal treatment, health & safety
- **S1-2** Processes for engaging with own workers and worker representatives
- **S1-3** Remediation processes and worker grievance channels
- **S1-4** Actions taken on material workforce impacts/risks/opportunities and their effectiveness
- **S1-5** Targets for managing material workforce impacts and risks/opportunities
- **S1-6** Employee characteristics: headcount by gender, country (where thresholds apply), employment type (permanent/temporary), employment regime (full/part-time); non-employee worker counts
- **S1-7** Characteristics of non-employees in the workforce
- **S1-8** Collective bargaining coverage (% employees, by country)
- **S1-9** Diversity metrics: % female (total + management), age-band breakdown
- **S1-10** Adequate wages — living wage benchmark alignment
- **S1-11** Social protection coverage
- **S1-12** Persons with disabilities in the workforce
- **S1-13** Training: average hours per employee, % receiving regular performance reviews, transition assistance
- **S1-14** Health & safety: % covered by an H&S management system, fatalities, LTIFR, recordable accidents, work-related ill health
- **S1-15** Work-life balance — parental leave uptake by gender
- **S1-16** Compensation: CEO pay ratio, gender pay gap (median remuneration)

**Note:** gender pay gap and some workforce metrics have first-year phase-in relief under ESRS 1 transition provisions — confirm which apply to your reporting year.

---

## 4. ESRS G1 — Business Conduct

- **G1-1** Corporate culture and business conduct policies: code of conduct, anti-corruption/anti-bribery policy, lobbying/political engagement policy, prompt-payment policy
- **G1-2** Management of supplier relationships: responsible procurement, fair payment terms, tier-1 due-diligence coverage
- **G1-3** Prevention/detection of corruption and bribery: risk assessment methodology, training coverage
- **G1-4** Incidents of corruption or bribery: convictions, fine amounts, remedial actions
- **G1-5** Political influence and lobbying: financial/in-kind contributions to political parties, significant lobbying positions
- **G1-6** Payment practices: average payment period, % payments beyond contractual terms, supplier complaints on payment

---

## Cross-cutting requirements that apply to all three topics

- **Location:** disclosures go in a dedicated section of the management report (Accounting Directive Art. 19a) — not a standalone sustainability report
- **Digital tagging:** all quantitative datapoints must be tagged in XBRL/iXBRL under the ESEF taxonomy
- **Assurance:** limited assurance required from your first reporting year (ISAE 3000 Revised standard), moving to reasonable assurance on a phased timeline pending Commission review (targeted 2028)
- **Value chain data:** where direct supplier/customer data isn't available for E1 (Scope 3) or S1/G1 supply-chain elements, you may use proxy data or sector averages — but you must disclose the estimation methodology and its limitations
- **Comparatives:** prior-year comparative data is required for all quantitative disclosures (after your first reporting year)

## Suggested next step

Build a datapoint-level gap table (ESRS reference | required datapoint | current data availability | gap | priority | owner | target date) for each of the three material topics above, starting with E1-6 Scope 3 and E1-1 transition plan since those typically require the longest lead time to close.

# What to Disclose: E1, S1, and G1 Material Topics

With Climate Change (E1), Own Workforce (S1), and Business Conduct (G1) determined material, your ESRS-based sustainability statement needs to cover three layers: (1) the mandatory cross-cutting disclosures that apply regardless of materiality outcome, (2) the full disclosure requirements under each of your three material topical standards, and (3) a brief explanation of why the other topical standards were screened out as non-material.

## 1. Mandatory cross-cutting disclosures (ESRS 1 and ESRS 2)

ESRS 2 (General Disclosures) applies in full regardless of your materiality results:
- **BP-1 / BP-2** — Basis of preparation (scope of consolidation, value chain estimation approach, etc.)
- **GOV-1 to GOV-5** — Governance: role of administrative/management/supervisory bodies, sustainability expertise, integration into incentive schemes, risk management and internal controls
- **SBM-1 to SBM-3** — Strategy and business model: market position, strategy, stakeholders, material impacts/risks/opportunities and their interaction with strategy
- **IRO-1 / IRO-2** — Description of the process to identify and assess material impacts, risks, and opportunities (your double materiality process), and the resulting list of material topics/disclosure requirements

ESRS 1 sets out the general reporting principles (qualitative characteristics, value chain boundaries, time horizons, use of estimates) but doesn't itself require specific disclosures.

## 2. ESRS E1 — Climate Change

- **E1-1** — Transition plan for climate change mitigation (and whether/how it's compatible with limiting warming to 1.5°C)
- **E1-2** — Policies related to climate change mitigation and adaptation
- **E1-3** — Actions and resources in relation to climate policies
- **E1-4** — Targets related to climate change mitigation and adaptation
- **E1-5** — Energy consumption and mix
- **E1-6** — Gross Scopes 1, 2, and 3 GHG emissions, and total GHG emissions
- **E1-7** — GHG removals and mitigation projects financed through carbon credits
- **E1-8** — Internal carbon pricing
- **E1-9** — Anticipated financial effects from material physical and transition risks and potential climate-related opportunities (subject to phase-in relief in the first years for some companies)

Note: several E1 datapoints (notably certain GHG figures and E1-9) carry transitional reliefs/phase-in provisions in the first year(s) of reporting — check which apply to you based on your reporting wave.

## 3. ESRS S1 — Own Workforce

- **S1-1** — Policies related to own workforce
- **S1-2** — Processes for engaging with own workers and workers' representatives about impacts
- **S1-3** — Processes to remediate negative impacts and channels for workers to raise concerns
- **S1-4** — Taking action on material impacts, and approach to mitigating material risks/pursuing opportunities, with effectiveness tracking
- **S1-5** — Targets related to managing material impacts, risks, and opportunities
- **S1-6** — Characteristics of employees (headcount by gender, country, contract type, etc.)
- **S1-7** — Characteristics of non-employee workers in own workforce
- **S1-8** — Collective bargaining coverage and social dialogue
- **S1-9** — Diversity metrics (e.g., gender at management levels, age distribution)
- **S1-10** — Adequate wages
- **S1-11** — Social protection
- **S1-12** — Persons with disabilities
- **S1-13** — Training and skills development metrics
- **S1-14** — Health and safety metrics (fatalities, recordable incidents, etc.)
- **S1-15** — Work-life balance metrics (e.g., family leave)
- **S1-16** — Compensation metrics (pay gap, CEO pay ratio)
- **S1-17** — Incidents, complaints, and severe human rights impacts

## 4. ESRS G1 — Business Conduct

- **G1-1** — Corporate culture and business conduct policies (incl. anti-corruption/anti-bribery, whistleblowing, protection of whistleblowers)
- **G1-2** — Management of relationships with suppliers, including payment practices
- **G1-3** — Prevention and detection of corruption and bribery, including training
- **G1-4** — Confirmed incidents of corruption or bribery
- **G1-5** — Political influence and lobbying activities, including public affairs and any political contributions
- **G1-6** — Payment practices, particularly regarding late payments to SMEs

## 5. What you don't need to fully disclose

For the ESRS topics your double materiality assessment found non-material (e.g., Pollution [E2], Water and Marine Resources [E3], Biodiversity and Ecosystems [E4], Resource Use and Circular Economy [E5], Workers in the Value Chain [S2], Affected Communities [S3], Consumers and End-Users [S4]), you don't need to apply the full disclosure requirements — but you do need a brief explanation of the conclusion that they're not material, typically as part of your IRO-2 disclosure. Also, if a specific topical standard is material, keep in mind ESRS still lets you omit individual datapoints within it if you conclude and justify that a particular datapoint is not material — with the exception of certain items ESRS treats as always mandatory once the topic itself is material.

## 6. Value chain and assurance reminders

For all three material topics, ESRS expects you to consider your value chain (not just your own operations) where relevant — e.g., Scope 3 emissions under E1, or supply-chain elements touching S1/G1. Your disclosures will also be subject to external limited assurance (moving toward reasonable assurance over time), so build in data quality controls and an audit trail from the outset.

# Transitioning from GRI/TCFD to CSRD/ESRS: Effort and Likely Gaps

## First, two scoping questions before estimating effort

Before sizing the transition, I'd want to pin down two things, since they materially change the answer:

1. **Are you actually in mandatory CSRD scope right now?** As of August 2026, mandatory scope is governed by **Directive (EU) 2026/470**: large undertakings with **>1,000 employees AND net turnover >€450M**. If you're below that combined threshold, you are not currently required to report under full ESRS — the new **VSME voluntary standard** (adopted 3 July 2026) may be the more proportionate target, and the "gap assessment" below would look very different (lighter-touch).
2. **Which ESRS vintage are you targeting?** The **current ESRS (2023)**, Commission Delegated Regulation (EU) 2023/2772, is the live mandatory standard today. A **revised, simplified ESRS** (roughly 61% fewer mandatory datapoints) was adopted 3 July 2026 and is in the Parliament/Council scrutiny period, expected in force Q4 2026, mandatory for financial years beginning 1 January 2027 (FY2026 early adoption only after the delegated act enters into force). If your first mandatory year is FY2027 or later, plan against the revised ESRS, not the fuller 2023 version — this can significantly reduce your gap list.

The analysis below assumes you are in (or expect to be in) mandatory scope and gives you the gap picture against the fuller current ESRS baseline, which is also the safer basis to plan from today.

## How much work is it, generally?

Existing GRI and TCFD reporting gives you a genuine head start — you are not starting from zero — but the transition is not a light lift. Expect a **multi-quarter program** (commonly 12–18 months to first assured disclosure from a standing start), not a re-formatting exercise, because CSRD adds three things GRI/TCFD don't require: a formal, documented **double materiality assessment**, **mandatory external assurance**, and **XBRL/iXBRL digital tagging** — none of which exist in either of your current frameworks.

### Why GRI and TCFD only get you partway there
- **GRI** covers impact materiality (single materiality) — you still need to build out financial materiality from scratch and formally document both lenses per ESRS 1.
- **TCFD** covers financial materiality for climate only — ESRS E1 incorporates TCFD's four pillars (governance, strategy, risk management, metrics & targets), so climate governance/strategy disclosures largely transfer, but TCFD doesn't require full Scope 3 (all 15 categories), a formal 1.5°C-aligned transition plan, or EU Taxonomy alignment — all of which ESRS E1 mandates.
- **Neither** GRI nor TCFD requires third-party assurance or digital tagging — both are net-new workstreams for you.

## Gap Assessment

| ESRS Topic | Current State (GRI/TCFD) | Gap | Priority | Action |
|---|---|---|---|---|
| ESRS 1/2 – Double Materiality (IRO-1, SBM-3) | GRI-based impact materiality assessment likely exists | No formal financial materiality assessment; no ESRS-format documentation of scoring, thresholds, stakeholder engagement | **CRITICAL** | Run full DMA (impact + financial), score and document per ESRS 1 paras. 45–56; this must exist before deciding final topic scope |
| ESRS 2 – Governance (GOV-1 to GOV-5) | Partial — board ESG oversight likely referenced in GRI/TCFD governance sections | Missing: board sustainability expertise credentials, ESG-linked incentive detail, formal internal controls over sustainability *reporting* (not just operations) | HIGH | Document board ESG agenda time/records; confirm remuneration-committee ESG KPI linkage; design an internal control framework for sustainability data akin to financial reporting controls |
| ESRS E1 – Climate (E1-1 to E1-9) | TCFD gives governance/strategy/risk-management/metrics foundation; GRI 305 gives Scope 1/2 | Missing: full Scope 3 (all 15 categories, most companies only have partial Cat. 1/6); formal 1.5°C-aligned transition plan (E1-1); EU Taxonomy eligible/aligned revenue-capex-opex; market-based Scope 2 if not already split | **CRITICAL** (Scope 3, transition plan) | Stand up Scope 3 measurement (phase by category — Cats. 1, 3, 6, 7, 11 typically cover 80%+ of emissions in year one); draft formal transition plan aligned to SBTi/Paris; run EU Taxonomy eligibility screening |
| ESRS S1 – Own Workforce | GRI 401/403/405 cover employment, OHS, diversity reasonably well | Missing: gender pay gap aligned with EU Pay Transparency Directive methodology; CEO pay ratio; adequate-wages/living-wage benchmarking; non-employee (contractor) H&S data | HIGH | Commission pay-gap analysis with HR/Finance; extend H&S data collection to contractors; benchmark wages against living-wage standards |
| ESRS G1 – Business Conduct | GRI 205/206 cover anti-corruption and anti-competitive behaviour at a high level | Missing: ESRS-specific payment-practices metrics (average payment period, % beyond contractual terms); lobbying disclosure detail; anti-corruption training coverage thresholds | MEDIUM | Pull payment-terms data from AP systems; formalize lobbying/political-contribution disclosure; verify anti-corruption training coverage meets ESRS-quality documentation |
| Value Chain (E1, S2 where material) | Limited — GRI/TCFD rarely require deep upstream/downstream data | Supplier-level emissions and labour data likely thin beyond tier 1 | HIGH | Prioritize suppliers by spend-based emissions significance and risk sector; use CDP Supply Chain / EcoVadis-style questionnaires for tier-1, spend-based EEIO factors for the long tail; disclose estimation methodology |
| Assurance readiness | Not required under GRI/TCFD (optional at most) | No assurance-ready data trails, no documented calculation methodologies, no internal sign-off procedures | **CRITICAL** | Build ISAE 3000-ready evidence trails from day one (source system → reported figure), even though only *limited* assurance is required initially — retrofitting evidence later is expensive |
| Digital tagging (XBRL/iXBRL) | Not applicable under GRI/TCFD | No tagging infrastructure or taxonomy mapping | HIGH | Select tagging approach (integrated software vs. post-report tagging vs. outsourced) once the ESEF sustainability taxonomy is finalized |
| Location/format | GRI/TCFD often published as standalone reports | CSRD disclosures must sit in a **dedicated section of the management report**, not a separate sustainability report | MEDIUM | Restructure annual report production process and sign-off workflow |

**Priority key:** CRITICAL = legal prerequisite, can't publish without it; HIGH = material gap, risks a qualified assurance opinion; MEDIUM = quality/completeness issue, doesn't block limited assurance.

## Practical sequencing

1. **Confirm scope and ESRS vintage first** (see scoping questions above) — this determines how much of the gap table below actually applies to you and by when.
2. **Run the double materiality assessment** before anything else — it is the legal gating step that determines your final topic list (you may find topics beyond E1/S1/G1 equivalents are material, or that some GRI-reported topics turn out non-material under ESRS's dual test).
3. **Prioritize Scope 3 and the transition plan** — these are consistently the longest-lead-time items across CSRD transitions.
4. **Start assurance-grade documentation immediately**, even before your first mandatory report — this is the workstream companies most commonly underestimate, because GRI/TCFD experience creates false confidence that "we already collect this data," when the bar is really "we can evidence this data to an assurance provider."

Given you already have GRI and TCFD in place, your realistic gap is concentrated in: financial materiality/DMA documentation, Scope 3 completeness, the formal transition plan, ESRS-specific S1 metrics (pay gap, pay ratio), value chain data depth, and the net-new assurance and tagging workstreams — rather than a wholesale rebuild of your ESG data infrastructure.

# Transitioning from GRI + TCFD to CSRD/ESRS

The honest answer: this is a meaningful undertaking — typically described by companies going through it as a **6–18 month, cross-functional project** — but you are starting from a much better position than a company with no prior sustainability reporting. GRI gives you a strong impact-reporting foundation, and TCFD gives you a strong climate-financial foundation. The work is mostly about combining, deepening, and formalizing what you already do, not starting from zero.

## Where you already have good overlap

- **GRI → ESRS impact side:** ESRS's impact materiality concept and many topical disclosures (workforce, business conduct, environmental topics) are structurally close to GRI's topic-based, impact-oriented disclosures. Companies with mature GRI reporting typically find 60–70%+ conceptual overlap on the "impact" half of double materiality, and can often reuse existing data collection processes and stakeholder engagement work.
- **TCFD → ESRS E1:** ESRS E1 (Climate Change) explicitly adopts TCFD's four-pillar structure (governance, strategy, risk management, metrics and targets), so your existing TCFD scenario analysis, climate governance disclosures, and Scope 1/2/3 emissions reporting map directly into E1's requirements with some restructuring and additional granularity.

## Where the gaps typically show up

1. **Double materiality, not single materiality.** GRI is impact-only; TCFD is financial-only. ESRS requires a unified process assessing both, run through common thresholds and combined into one materiality determination that formally supports your entire disclosure scope. This is usually the single biggest new undertaking — expect to build (or significantly formalize) an IRO (impacts, risks, opportunities) assessment process, including stakeholder engagement, that didn't exist in this combined form before.

2. **Prescriptiveness and granularity of datapoints.** ESRS is far more standardized and prescriptive than GRI's flexible topic-by-topic approach — it specifies over a thousand potential datapoints across the full standard set, many with defined units, breakdowns (e.g., by gender, country, employee vs. non-employee), and specific calculation methodologies. Expect gaps in data granularity even where you already report the "same" topic under GRI.

3. **Value chain scope.** ESRS pushes disclosure obligations upstream and downstream more explicitly than most GRI/TCFD reports do in practice — e.g., Scope 3 emissions data quality, workers in the value chain (a topic GRI touches but ESRS treats with a dedicated standard, S2), and supplier-related business conduct disclosures. Value chain data collection is often the largest practical gap.

4. **External assurance.** CSRD mandates external assurance on the sustainability statement from the first year of application (starting at limited assurance, with an EU roadmap toward reasonable assurance later). Voluntary GRI/TCFD reports are often unassured or only lightly assured. You'll need audit-ready evidence trails, defined internal controls over sustainability data (similar in spirit to internal controls over financial reporting), and early engagement with your assurance provider.

5. **Legal integration and liability.** Unlike a standalone GRI or TCFD report, the CSRD sustainability statement is a mandatory part of the statutory management report, filed alongside the financial statements, subject to the same governance sign-off and (in most member states) director liability regime. This changes how the report needs to be reviewed, approved, and controlled internally.

6. **Digital tagging (XBRL/ESEF).** The sustainability statement must be tagged in a machine-readable format as part of the annual financial filing — a new technical/IT workstream most voluntary reporters haven't had to handle.

7. **Governance and strategy disclosures (ESRS 2 GOV/SBM series).** ESRS requires more explicit disclosure of how sustainability is embedded in governance (board oversight, expertise, incentive-linkage) and strategy (resilience analysis, business model description tied to material IROs) than typical GRI or TCFD governance sections.

8. **EU Taxonomy alignment (if applicable).** If you're also in scope for EU Taxonomy reporting, you'll need to cross-reference taxonomy-eligible/aligned revenue, capex, and opex figures within the same report — an additional layer GRI/TCFD don't require.

9. **Phase-in reliefs and sector standards.** Some ESRS datapoints (e.g., certain Scope 3 items, anticipated financial effects) have transitional reliefs depending on your company size and reporting wave; sector-specific ESRS standards are also being phased in and may eventually add requirements beyond the generic set you'd start with.

## Practical next steps

1. Run a formal **gap assessment**: map your current GRI content index and TCFD disclosures against the full ESRS datapoint list to see exactly what you already have, what needs deepening, and what's net-new.
2. Build or formalize your **double materiality assessment process** as the first deliverable — it determines your final disclosure scope.
3. Stand up **value chain data collection** (especially Scope 3 and workforce-in-value-chain data) early, since it typically has the longest lead time.
4. Engage your **auditor/assurance provider** early to align on evidence requirements and internal controls.
5. Plan for the **digital tagging/XBRL** requirement as part of your reporting technology stack.

Given how much the CSRD/ESRS implementation landscape (timelines, thresholds, and even some disclosure requirements) has been actively revised through the EU's recent simplification efforts, I'd recommend validating your exact reporting wave and applicable transitional reliefs against the current, finalized regulatory texts before finalizing your project plan.

# CSRD Applicability — US-Headquartered Tech Company with German/French Subsidiaries

## Short answer

There are two separate scope questions here, and they point in different directions. Your **German subsidiary is very likely not in mandatory scope on its own** under the current post-Omnibus thresholds. Whether the **US parent has a non-EU-company obligation** (Art. 40a) is genuinely unsettled right now and I'd flag it as "needs verification" rather than give you a confident yes/no — see the caveat below.

## 1. Does the German subsidiary trigger CSRD as a standalone EU undertaking?

CSRD's mandatory scope for EU entities is now set by **Directive (EU) 2026/470** (in force March 2026): large undertakings with **>1,000 employees AND net turnover >€450M**.

| Criterion | German subsidiary | Threshold | Met? |
|---|---|---|---|
| Employees | 600 | >1,000 | ❌ No |
| Turnover | Not separately given (part of combined €200M EU revenue) | >€450M | Unlikely, but confirm standalone figure |
| Listing | Not listed | Listing alone no longer triggers mandatory scope post-Omnibus | ❌ No |

At 600 employees, the German subsidiary is well under the 1,000-employee threshold and therefore **not independently in mandatory CSRD scope**, regardless of its turnover. The French subsidiary's headcount isn't given, but unless it alone clears both 1,000 employees and €450M turnover, it wouldn't independently trigger scope either. So on a standalone-entity basis, neither EU subsidiary appears to be a mandatory CSRD reporter today.

## 2. Does the US parent trigger CSRD as a non-EU company (Art. 40a)?

This is the part that needs real caution. Under the **original** CSRD design, non-EU parent undertakings with **more than €150M in net turnover generated in the EU** (via an EU branch or subsidiary meeting certain size conditions) were brought into scope under Art. 40a, with a first reporting year of FY2028 (published 2029). Your combined €200M in EU revenue from the German and French subsidiaries would have cleared that legacy €150M figure.

**However**, the skill guidance I'm working from is explicit that the Art. 40a non-EU threshold is **under review as part of the Omnibus package**, and instructs not to rely on the pre-2026 €150M construct without checking current status. I don't have confirmation of where that threshold landed as of August 2026 — it may have been raised (consistent with the >€450M logic applied to EU large undertakings), left unchanged, or restructured entirely. Given that ambiguity, I can't give you a reliable yes/no on the non-EU parent obligation today.

**What I'd recommend:**
- Treat this as an open compliance question requiring current-source verification (EUR-Lex / European Commission CSRD Omnibus tracker, or specialist EU counsel) before you make any scope determination or public statement.
- In parallel, prepare as if you *may* be in scope: your €200M EU revenue figure and the subsidiary structure are exactly the fact pattern Art. 40a was designed to catch, so this isn't a remote risk — it's a live open question, not a "clearly out" answer.
- Get a definitive read on: (a) the current non-EU turnover threshold, (b) whether it's still assessed at combined EU-subsidiary level or requires a single qualifying EU undertaking/branch, and (c) the current first-reporting-year timeline for non-EU companies (FY2028 was the pre-Omnibus target, but the Omnibus package has generally pushed timelines out — confirm this hasn't shifted further).

## 3. What to do next regardless of the Art. 40a answer

- **Re-run the standalone-entity check for the French subsidiary** with actual headcount and turnover figures — if it independently crosses >1,000 employees and >€450M turnover, it would be in mandatory scope on its own regardless of the parent question.
- **Watch for group/consolidation nuances:** even where a subsidiary itself is below threshold, group reporting rules can sometimes bring a subsidiary's data into a parent's report (or allow it to rely on one) — worth checking whether the US parent already produces any group sustainability disclosure that could be leveraged.
- **Consider the VSME voluntary standard** (adopted July 2026) as a fallback: if neither subsidiary nor the US parent turns out to be in mandatory scope, EU customers, lenders, or investors may still request proportionate sustainability data, and VSME is the designed vehicle for that.
- **Don't default to "out of scope"** based on subsidiary headcount alone — the non-EU parent test operates on a different logic (EU-generated turnover, not EU subsidiary headcount), so the 600-employee German subsidiary being under-threshold does not resolve the Art. 40a question.

## Bottom line

Standalone EU-entity scope: **likely not triggered** (German subsidiary well under the 1,000-employee bar; French subsidiary needs its own headcount/turnover check). Non-EU parent scope under Art. 40a: **unresolved under current rules** — the €200M EU revenue figure would have cleared the old €150M threshold, but that threshold is explicitly under Omnibus revision, so treat this as a "verify before relying" item rather than a settled answer, and get current-source confirmation before communicating a final position.

---
*This is general compliance information, not legal advice — especially given the live legislative uncertainty on the non-EU threshold, verify with qualified EU counsel before finalizing your scope position.*

# CSRD Applicability for a US Parent with EU Subsidiaries

Yes — based on the facts given, CSRD is very likely to apply to you, and in two distinct ways: through your **German subsidiary's own standalone obligation**, and potentially through the **third-country (non-EU parent) group-level obligation**. These are separate legal hooks and you should analyze both.

## 1. The German subsidiary may be independently in scope

CSRD applies to any "large undertaking" established in the EU, regardless of who its parent is. A company is large if it exceeds at least two of three thresholds:
- More than 250 employees
- Net turnover above roughly €50M
- Balance sheet total above roughly €25M

Your German subsidiary has 600 employees, which alone clears the employee threshold. If its standalone turnover and/or balance sheet also clear the other thresholds (plausible, given it's contributing to €200M in combined EU revenue), it qualifies as a large undertaking in its own right and has its own CSRD reporting obligation — being non-listed doesn't exempt it; listing only matters for determining which reporting wave and timeline applies (non-listed large companies fall into the second wave rather than the first).

Note: an EU subsidiary can sometimes be exempted from producing its *own* standalone sustainability statement if its results are included in a consolidated sustainability report prepared at the group level that meets equivalent CSRD/ESRS requirements — but since your parent is US-based and outside the CSRD's ordinary consolidation mechanics, this exemption path typically converges with the third-country reporting route described below rather than eliminating the obligation entirely.

## 2. The third-country parent (non-EU group) obligation

CSRD also has a specific provision aimed at non-EU parent companies with substantial EU activity. Broadly, it's triggered when:
- The non-EU group generates **more than €150M in net turnover in the EU** (on a consolidated basis, over two consecutive financial years), **and**
- The group has at least one EU subsidiary that is itself a large undertaking (or listed on an EU regulated market), **or** an EU branch generating more than €40M in net turnover

Your facts — a US parent with €200M in combined EU revenue from German and French subsidiaries, and a German subsidiary with 600 employees that is plausibly "large" — appear to satisfy both legs of this test. If so, the US parent (the ultimate non-EU parent) has an obligation to prepare and publish a **sustainability report at the group/consolidated level**, covering the worldwide group, prepared according to ESRS (or a Commission-recognized equivalent standard). This report can be prepared by the parent itself or, if the parent doesn't do so, the EU subsidiary becomes responsible for publishing it (and for obtaining/publishing the information from the parent), with the EU subsidiary/branch potentially bearing liability for ensuring the obligation is met.

This third-country obligation was designed to apply on a later timeline than the standard EU-company waves — originally targeted at financial years starting from 2028, with first reports published around 2029 — reflecting that it was the last phase-in tranche in the original directive.

## 3. What this means practically for you

- **Don't wait for the parent-level (third-country) deadline** to start work — your German subsidiary's standalone obligation, if triggered by its own size, will likely come due earlier under the standard EU company timeline.
- **Confirm your German subsidiary's exact financials** (turnover and balance sheet, not just headcount) to nail down whether it meets 2 of 3 "large" thresholds on its own.
- **Confirm your French subsidiary's status too** — if it's also large (or listed), it has its own separate obligation, or its data may need to feed into a French-domiciled consolidated report.
- **Model the €150M EU turnover test carefully** — confirm whether it's measured as combined EU-generated net turnover across all EU operations (not just these two subsidiaries) and whether it needs to hold for two consecutive years.
- **Decide on a reporting strategy**: will the US parent prepare one worldwide group sustainability report to satisfy the third-country obligation (potentially also covering/exempting the EU subsidiaries), or will each EU subsidiary report separately? This has real cost and governance implications and is worth deciding early with input from EU counsel.
- **Watch for legislative changes.** The EU has been actively revising CSRD scope, thresholds, and timelines (including for third-country parents) through its 2025 simplification ("Omnibus") efforts. Given how much movement there's been, I'd strongly recommend confirming the current, finalized thresholds and deadlines with EU counsel or your auditor before finalizing a compliance timeline — the €150M/€40M figures and the FY2028 target date reflect the directive as originally adopted, and specifics may have shifted.

## Bottom line

As a non-EU (US) parent, you don't escape CSRD simply because your headquarters is outside the EU. With €200M in EU revenue and a 600-employee German subsidiary, you likely face obligations on two fronts: the German subsidiary's own standalone large-undertaking reporting duty (sooner), and the broader group-level third-country parent reporting duty (originally later-phased). Both should be scoped now, even if the second one's deadline is further out, because the underlying data collection, double materiality assessment, and governance build-out take significant lead time either way.

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

Classification and Export Path — Commercial Surveillance Drone (2.5-Hour Endurance) to Brazil

**Step 1 — Jurisdiction and ECCN.** Applying the mandatory Order of Review: first confirm the UAV is not enumerated or "specially designed" for military use under the USML (22 CFR Part 121) — a purely commercial surveillance drone typically is not. That places it under EAR jurisdiction. Under the current drone classification framework (final rule, 91 FR 52501, effective August 13, 2026), endurance is the threshold test: at 2.5 hours, your drone falls below the 3-hour line and classifies as **9A012.a.1**, controlled **AT-only** (the NS2 basis was removed in this rule). This is a materially more permissive classification than the pre-2026 regime.

Software and technology follow the hardware: NS was also removed from **9D001, 9D002, 9D004, and 9E001** for sub-3-hour UAVs, so associated flight-control software, ground-station software, and technical data for this airframe are likewise AT-only, assuming no other controlled subsystems are involved.

**Step 2 — Check for controlled subsystems (override condition).** Before relying on the AT-only classification, verify the payload. If the drone incorporates a **6A003 thermal imager**, a **6A005 laser** (e.g., laser rangefinder/illuminator), or **7A001–7A005** navigation-grade components (e.g., high-grade IMU or GPS-denied nav system), the platform reverts to **NS1/AT1** regardless of endurance. Surveillance payloads are the most common trigger here — confirm the sensor package's technical specifications against these ECCNs before finalizing classification.

**Step 3 — Country Chart analysis for Brazil.** Assuming the AT-only classification holds (no NS-triggering subsystems), check the Commerce Country Chart AT Column 1 for Brazil. Brazil is not an embargoed destination, not on the E:1/E:2 lists, and AT Column 1 restrictions apply almost exclusively to state sponsors of terrorism — Brazil does not fall in that category, so no license is required on AT grounds (**NLR — No License Required**).

**Step 4 — End-user and end-use controls still apply.** A "no license required" ECCN outcome does not end the analysis. Under § 744.21, military end-use/end-user controls now expressly reach ECCNs 9A012, 9D001, 9D002, 9D004, and 9E001 — screen the Brazilian distributor and its downstream end-users against the Entity List, Denied Persons List, Unverified List, and Military End-User List via the Consolidated Screening List. If the distributor or an identified end-user has a military or intelligence-service nexus, a license may be required even though the Country Chart shows no "X."

**Step 5 — Distributor due diligence.** Because this is a distributor relationship (resale to unknown downstream end-users), obtain a signed distributor agreement with EAR compliance flow-down clauses, an end-user statement or reasonable assurance of civil end-use, and screen for red flags under § 732.6 (reluctance to identify end-users, unusual payment routing, requests to obscure the ultimate destination). Re-screen the distributor at least monthly per standard ECP practice.

**Step 6 — Documentation and recordkeeping.** Retain the ECCN classification rationale (endurance data, payload technical specs, confirmation no 6A003/6A005/7A001-005 components are present), the Country Chart lookup, screening records, and the distributor agreement for 5 years from export (§ 762.6). File EEI/AES if the shipment value exceeds $2,500 (Part 758).

**Bottom line:** With no NS-triggering payload, this drone is 9A012.a.1 (AT-only) and generally exportable to Brazil without a BIS license, but Entity List/MEU screening of the distributor and end-user is mandatory, and the classification should be documented and revisited if the sensor payload changes. If any ambiguity remains about payload classification, consider a CCATS request via SNAP-R for a binding ECCN determination before shipment.

*This is general compliance guidance, not legal advice — verify current Country Chart entries and consult export counsel before shipping.*

Selling a commercial surveillance drone with 2.5 hours max endurance to a distributor in Brazil raises a standard EAR export-compliance workflow: classification, licensing determination, and party/end-use screening. Here is how I would walk through it.

1. Jurisdiction and classification
First confirm the item is subject to the EAR rather than the ITAR. Pure commercial surveillance drones without military-specific design features (armor, weapons integration, military avionics, etc.) are almost always EAR-jurisdiction, not USML Category VIII(a) items. Within the EAR, the Commerce Control List (CCL) entry most relevant to unmanned aerial vehicles is ECCN 9A012, which controls UAVs meeting certain performance parameters (notably those tied to MTCR Category I/II thresholds — range/endurance combined with payload and autonomous flight capability). A drone with only 2.5 hours of endurance and no unusual range, altitude, autonomous navigation, or payload capacity is very unlikely to meet the 9A012 control parameters. In that case, the item would typically fall to ECCN 9A991 (a " non-9A012" catch-all for aircraft/UAV parts and equipment) or, if it has no specific control parameters at all, EAR99.

You should still walk through the 9A012 technical parameters line by line (including any autopilot, camera/sensor payload, and ground control station capabilities) before settling on 9A991 or EAR99, since the encryption or optics package could push the classification elsewhere (e.g., 5A992 for certain encryption, or 6A003 for optical sensors).

2. Country-based licensing analysis
Brazil is in EAR Country Group B and is not subject to a comprehensive embargo, and it is a Missile Technology Control Regime (MTCR) partner and Wassenaar Arrangement participant — both favorable factors. For EAR99 items, no BIS export license is generally required to Brazil. For 9A991-classified items, license requirements depend on the applicable reason for control (typically Anti-Terrorism (AT) only for this ECCN), and AT controls to Brazil for this class of item generally do not require a license, though you must check the Commerce Country Chart for the specific reasons for control and confirm no license exception carve-outs are needed.

3. Party and end-use screening
Regardless of classification, before finalizing the distributor relationship you must:
- Screen the distributor, its officers, and the ultimate end users against the BIS Entity List, Denied Persons List, Unverified List, OFAC SDN List, and the Brazilian equivalent restricted-party considerations.
- Obtain end-use/end-user information — surveillance drones attract heightened scrutiny for potential government security, law enforcement, or military end use, which can trigger "catch-all" controls even for EAR99/9A991 items if you have "knowledge" the item is destined for a prohibited end use (e.g., certain human-rights-related end uses, military intelligence end use in some countries — less relevant for Brazil, but still part of the standard "red flags" check).
- Execute a distribution agreement that includes an EAR compliance clause, requiring the distributor to obtain your consent before re-export or resale to any third country, and prohibiting resale to countries subject to Group D:1 or comprehensive sanctions.

4. Documentation
- Issue a Destination Control Statement on your commercial invoice.
- Retain the ECCN self-classification determination and supporting technical analysis for at least five years.
- Consider requesting a BIS classification ruling (formal CCATS request) if the drone's specs are close to the 9A012 thresholds, to have documented certainty.

5. Practical recommendation
Given the modest 2.5-hour endurance, this drone most likely qualifies for EAR99 or 9A991 treatment with no license required to Brazil, but you should not rely on that informally — run the actual technical specifications (endurance, range, altitude ceiling, autopilot autonomy, payload, any encrypted datalink) against the 9A012 parameters, screen the distributor and end users, and put the resale/re-export restriction language in your distribution contract. If the drone incorporates encryption for its command-and-control link, a separate 5A992/5D992 encryption registration or self-classification report may also be needed.

Because EAR thresholds and the Commerce Country Chart are updated periodically, I'd recommend validating the current parameters against the latest CCL entry text and BIS country chart before finalizing the transaction.

Classification and Export Path — Commercial Surveillance Drone (5-Hour Endurance, 400 km Range) to Brazil

This is a materially different case from the sub-3-hour platform, and the outcome is not a "no license required" determination.

**Step 1 — ECCN classification.** Under the August 2026 UAV rule (91 FR 52501), endurance ≥ 3 hours places the airframe in **9A012.a.2** rather than 9A012.a.1. This classification carries **NS Column 1 + AT Column 1**, and because your stated range is 400 km — above the 300 km threshold — **MT Column 1 (Missile Technology)** also applies. This is a fundamentally different risk profile than the 2.5-hour platform: NS1/AT1/MT1 is one of the most restrictive combinations on the CCL short of Category 0/1 WMD-precursor items.

Associated software and technology (9D001, 9D002, 9D004, 9E001) retain full NS/MT control for platforms in this endurance/range band — the software carve-out in the 2026 rule applies only below the 3-hour line.

**Step 2 — Country Chart analysis.** Check Brazil against all three applicable columns: NS Column 1, AT Column 1, and MT Column 1. A license is required if *any* applicable column shows "X" for Brazil unless an exception covers that specific reason for control. Brazil is an MTCR adherent (Country Group A:3) and generally a cooperative destination, but MT Column 1 restrictions apply broadly — MTCR membership affects licensing policy (presumption of approval/denial) far more than it affects the *requirement* to obtain a license. Expect the Country Chart to show a license requirement for at least the MT and likely the NS column for this performance tier.

**Step 3 — License exceptions are effectively unavailable.** This is the critical difference from the sub-3-hour case. Missile-technology-controlled items receive almost no license exception relief:
- **GBS/CIV/TSR** are unavailable because the item is not NS-only — MT is also a reason for control, which disqualifies these NS-only exceptions.
- **GOV** may apply only if the actual end-user is the Brazilian government (military or civil aviation authority) with proper verification — not applicable to a commercial distributor selling to unknown downstream buyers.
- **STA (Strategic Trade Authorization)** does not apply here — it is available for certain 600-series military items to Country Group A:5, not for this dual-use 9A012.a.2 civil/dual-use classification, and in any event MT-controlled items generally fall outside STA's payload/range eligibility.
- No exception overrides the MT control for a distributor sale with unverified downstream end-use.

**Practical conclusion: a BIS export license is very likely required** for this transaction. File via SNAP-R (Form BIS-748P), and expect the application to include: detailed technical specifications (endurance, range, payload capability, whether it could be modified to exceed MTCR Category I thresholds of 500 kg payload to 300 km range — note your platform's stated range already meets the range prong, so payload capacity is the key remaining data point BIS will scrutinize), an end-user statement from the Brazilian distributor identifying the actual end-users, and confirmation that no re-export to a third country is contemplated. Because MT items commonly draw interagency referral (State Department, sometimes DoD), build in lead time beyond the standard 90-day BIS review window.

**Step 4 — Screening and § 744.21.** Military end-use/end-user controls under § 744.21 explicitly reach 9A012 and its software/technology ECCNs — screen the distributor and all identifiable end-users against the Entity List, MEU List, Unverified List, and Denied Persons List before submitting the license application; a match may result in outright denial rather than a mitigable license condition.

**Recommendation:** Do not ship under a "no license required" assumption. Submit a CCATS request or license application confirming the 9A012.a.2/MT classification, and treat this as a licensed transaction with full documentation, distributor end-use certification, and 5-year recordkeeping (§ 762.6).

*General compliance guidance, not legal advice — confirm current Country Chart entries for Brazil and consult export counsel given the missile-technology exposure.*

This variant changes the analysis meaningfully because the performance envelope now approaches the thresholds that the Commerce Control List uses to identify more sensitive unmanned aerial systems, so the classification exercise needs to be redone rather than assumed to carry over from the shorter-endurance version.

1. Re-run the classification against ECCN 9A012
ECCN 9A012 controls UAVs (and specially designed parts/components/related software and technology in 9A012 and the corresponding "D"/"E" entries) that meet specific range, altitude, and other performance criteria drawn from the Missile Technology Control Regime (MTCR) Category I framework and related Wassenaar/EAR thresholds. A 400 km range and 5-hour endurance is squarely in the zone where you must check:
- Whether the aircraft can operate at a range/endurance combination associated with "beyond line of sight" or autonomous long-range operation.
- Whether it has an autopilot/autonomous flight-control capability (rather than being purely remotely piloted with continuous operator control).
- Payload capability, since MTCR Category I-type controls have historically hinged on range plus payload combinations (traditionally 300 km / 500 kg for missiles, with UAV-specific parameters set out separately in 9A012).

If the UAV meets the 9A012 control parameters, it becomes subject to National Security (NS), Missile Technology (MT), and Anti-Terrorism (AT) reasons for control, which is a materially different — and much stricter — licensing posture than 9A991 or EAR99.

2. Licensing impact for Brazil specifically
Brazil is generally treated favorably under NS-column licensing (it is not in the most restrictive country groups), but Missile Technology (MT) controls are essentially global in scope: an MT license requirement is not waived simply because the destination is a friendly, non-embargoed country. If the drone's range/payload combination triggers MT controls under 9A012, you should expect:
- A likely license requirement to Brazil (MT licenses are reviewed under a strong presumption of denial policy globally, including for MTCR partner countries, unless the transaction fits an established exception).
- Extended review timelines, since MT-controlled license applications typically get interagency review (State, Defense, sometimes NASA/NSC input via the Commerce process).
- The likely need for a specific end-use statement, non-transfer and end-use assurances from the Brazilian distributor and the actual government/commercial end user, and possibly a post-shipment verification commitment.

3. Confirm no ITAR overlap
Given the increased range/endurance, double-check that the airframe, autopilot, or any component was not originally designed or modified for a military application, which could push all or part of the system back to USML Category VIII jurisdiction. If any component was sourced from a defense contractor lineage or shares design lineage with a military UAV, a jurisdiction/classification request (commodity jurisdiction determination) to DDTC may be warranted before relying on an EAR-only theory.

4. Distributor and end-use diligence
Because MT-controlled items draw heightened scrutiny, your due diligence on the Brazilian distributor should go beyond standard restricted-party list screening:
- Identify and document the specific commercial end use (e.g., agricultural monitoring, infrastructure inspection, pipeline surveillance) and the named end user, not just "distributor for resale."
- Obtain an end-user statement/certificate and consider requiring pre-approval rights over any resale.
- Watch for red flags common to MT-sensitive UAV sales: unusual payload modification requests, interest in extending range/endurance further, requests to remove telemetry/geofencing, or reluctance to identify the true end user.

5. Practical recommendation
Do not assume the same "likely EAR99/9A991, no license" conclusion carries over from the shorter-endurance version. Run the actual technical parameters (400 km range, 5-hour endurance, payload, autopilot autonomy) against the current 9A012 text, and if there's any ambiguity, submit a formal classification request (CCATS) to BIS given the significant compliance and criminal-liability exposure of misclassifying an MT-controlled item as EAR99. If 9A012/MT control is confirmed, plan for a license application with realistic expectations about approval likelihood and timeline, rather than assuming Brazil's generally favorable country-group status will carry the day.

Classification of a Military-Purposed UAV Not Described on the USML

**Step 1 — Confirm the jurisdiction call itself.** The Order of Review (§ 732.3) requires checking the USML first: if the UAV or its components are enumerated or "specially designed" for a defense article under 22 CFR Part 121, it is ITAR, full stop, regardless of any commercial-sounding marketing. Your premise — that it is a military-purposed UAV genuinely *not* described on the USML — assumes that test has been carefully worked through, including the "specially designed" catch-all analysis, which is often where classification disputes actually arise. If there is any real ambiguity (e.g., the airframe has both a civil variant and a military variant, or it was recently transferred out of USML jurisdiction under Export Control Reform), the safer move before finalizing the answer below is a **Commodity Jurisdiction (CJ) request to DDTC**, or a **CCATS request via SNAP-R** to lock in BIS's own ECCN determination in writing.

**Step 2 — Current classification: 9A012.a.** Assuming the jurisdiction call is settled and the item is confirmed EAR, BIS's current position (reversing its 2013 approach) is that "specially designed" military UAVs not described on the USML classify in the **600-series** as **9A012.a**. This is a deliberate policy shift: previously, many military-application UAVs outside USML enumeration defaulted to less specific 9A991/EAR99-adjacent treatment; BIS now captures them explicitly under the 600-series military-commodity structure, which carries the licensing rigor associated with 600-series items — presumption of denial to most destinations outside close allies, and mandatory military end-user screening.

**Step 3 — Less-sensitive subcomponents: 9A610.y.33.** Parts, components, and accessories of these military UAVs that are less sensitive — not the complete airframe or its most sensitive subsystems — classify separately under the newly created **9A610.y.33**. The ".y" paragraph structure in 600-series ECCNs typically signals a lower control tier (often subject to fewer license exceptions restrictions and sometimes de minimis relief), so correctly separating "the airframe/core system" (9A012.a or its 9A610-adjacent treatment) from ".y.33" components matters for your licensing burden — do not lump the entire bill of materials under the more restrictive parent entry without checking each component against the .y.33 description.

**Step 4 — STA availability.** Strategic Trade Authorization (License Exception STA) may be available for shipments to Country Group A:5 (the 42 allied/partner countries) — but only where the UAV **cannot deliver at least 500 kg of payload to at least 300 km range** (the MTCR Category I threshold). If your platform meets or exceeds that payload/range combination, STA is not available regardless of destination, and you should expect to need an actual BIS license with likely interagency (State/DoD) review.

**Step 5 — Military end-use/end-user controls apply.** Under § 744.21, military end-use/end-user controls now expressly cover ECCNs 9A012, 9D001, 9D002, 9D004, and 9E001. Screen every destination and end-user against the Military End-User (MEU) List and Entity List before proceeding — note also that the older "wind-gust parameter" test some practitioners historically used for UAV classification has been eliminated in the current framework and should not be relied upon.

**Recommendation:** (1) Confirm the USML/EAR jurisdiction line is correctly drawn — get it in writing via CJ/CCATS if there's any doubt; (2) classify the core airframe as 9A012.a and separately classify lower-sensitivity components under 9A610.y.33; (3) check payload/range against the 500 kg / 300 km MTCR Category I threshold to determine STA eligibility to A:5 destinations; (4) run § 744.21 military end-use/end-user screening on every transaction regardless of ECCN outcome; (5) document the full classification rationale and retain for 5 years (§ 762.6).

*General compliance guidance, not legal advice — the USML/EAR boundary for "specially designed" military articles is fact-intensive; consult export counsel or file a CJ/CCATS request for a binding determination.*

This is a jurisdiction-and-classification question that comes up often for UAVs with military design lineage that don't cleanly match an enumerated USML Category VIII entry. Here is how the analysis generally works.

1. Start with the USML itself
Category VIII of the U.S. Munitions List (USML) covers aircraft and related articles, including "unmanned aerial vehicles ... specially designed, modified, or configured for a military application." If a UAV is genuinely military-purposed (designed for combat, ISR in a military context, weapons delivery, or built to military specifications) but doesn't fit neatly into an enumerated Category VIII subparagraph, the first step is not to assume it defaults to the EAR — you need to check whether it's still captured by USML Category VIII's general "specially designed" language or the catch-all paragraph within that category before concluding it falls outside ITAR jurisdiction.

2. If it truly isn't captured by the USML, it lands in the EAR "600 series"
The State Department and Commerce Department jointly executed "Export Control Reform," which moved many military items that are less sensitive (or that the U.S. government decided didn't warrant USML control) from the USML to the EAR's "600 series" ECCNs. For aircraft-related military items, the relevant entry is typically ECCN 9A610 (military aircraft and related commodities), which includes a 9A610.x catch-all paragraph for "specially designed" parts, components, accessories, and attachments for military aircraft/UAVs that are not elsewhere specified. A military-purposed UAV that is not on the USML would generally be evaluated first against 9A610 (and its "y" paragraph, which is a lower-control-level catch-all also worth checking), rather than falling through to EAR99, because "specially designed for a military application" is precisely the kind of item the 600 series was built to catch.

3. Confirm through a formal jurisdiction/classification determination — don't self-classify by assumption
Because the line between "still on the USML," "600 series," and "EAR99 with military end-use catch-all controls" is genuinely ambiguous for many UAVs, the standard, defensible practice is:
- Submit a Commodity Jurisdiction (CJ) request to the Directorate of Defense Trade Controls (DDTC) if there's real doubt about whether the item remains ITAR-controlled, or
- If jurisdiction is settled as EAR, submit a classification request to BIS (a CCATS) to confirm whether 9A610 or another 600-series entry applies, versus 9A991/9A012, versus EAR99.
Self-classifying a military UAV as EAR99 without going through this process is a common enforcement trap — BIS and DDTC have both pursued penalties in cases where companies assumed non-enumerated military items fell outside ITAR/600-series control.

4. Licensing consequences of a 600-series classification
If the UAV is confirmed as 9A610-controlled, the licensing posture differs sharply from EAR99/9A991 commercial items:
- 600-series items are subject to National Security, Regional Stability, and often United Nations/other reasons for control, with a much broader set of destinations requiring a license than commercial ECCNs.
- License Exception STA (Strategic Trade Authorization) may be available for exports to close allies (Country Group A:5/A:6) but is unavailable for many destinations and is subject to its own eligibility and notification requirements.
- Exports, re-exports, or even technology transfers/technical assistance involving a 9A610 item to most other countries will require a BIS license, and applications are typically routed through interagency review given the military nature of the item.

5. Practical recommendation
Treat "not described on the USML" as the start of the analysis, not the end. Work through: (a) is it really outside USML Category VIII's "specially designed" and catch-all language; (b) if so, does it fit 9A610 (or another 600-series aircraft-related ECCN); (c) if genuinely outside both, is it 9A991/9A012 or EAR99, keeping in mind that "military end use/end user" catch-all controls (currently significant for certain destinations) can still reach an EAR99 item if you have knowledge of a military end use in a controlled country. Given the compliance and enforcement risk, I'd strongly recommend a formal CJ or CCATS determination rather than an internal self-classification for an item this sensitive.

Current Status of the AI Chip "Diffusion Rule" — Do Not Structure Exports Around It

**Short answer: no, do not build your export structure around the diffusion framework.** Its legal status is genuinely unsettled, and relying on it — in either direction — creates compliance risk.

**What happened, in sequence:**

1. **January 2025 — the Interim Final Rule (IFR).** BIS published the AI diffusion rule, which would have created a three-tiered country classification system governing exports of advanced AI chips and related model weights, with differentiated license requirements based on destination country tier.

2. **May 2025 — non-enforcement announcement.** Rather than formally rescinding the IFR through the standard Federal Register rulemaking process, BIS announced it would **not enforce** the rule. This is a critical distinction: the rule was never repealed on the books. As a matter of the actual text of the CFR, the January 2025 IFR remains technically in effect — BIS simply committed, via public announcement rather than rulemaking, not to act on it.

3. **GAO decision (B-337935).** The Government Accountability Office subsequently held that the May 2025 non-enforcement announcement itself constituted a "rule" for purposes of the Congressional Review Act (CRA), and that BIS had not submitted it to Congress as the CRA requires for agency rules. This creates an unusual legal posture: the announcement that was supposed to resolve the IFR's status is itself procedurally irregular, meaning neither the original IFR nor its suspension sits on entirely solid procedural ground.

**Net effect:** there is no clean, stable "diffusion rule" framework you can point to and design a compliance program around. Treat the diffusion tiering system as **non-operative in practice but not legally dead** — a state that could change with a future Federal Register action, a court challenge, or congressional action on the CRA issue.

**What replaced it, and what you should actually plan around:**

BIS has moved to **country-specific rulemaking** instead of a general tiered framework. The clearest example is the UAE rule (91 FR 43034), which addresses AI chip exports to that specific destination through ordinary notice-and-comment or interim final rulemaking rather than the abandoned tiering structure. Expect BIS to continue issuing similar country-specific or transaction-specific rules rather than reviving a general diffusion tier system in the near term.

**What remains fully in force regardless of the diffusion rule's status:**

- **ECCNs 3A090 and 4A090** (advanced computing ICs and computer systems, from the October 2022/2023 rules) continue to control the underlying chips and require licenses to China, Macau, and D:1/D:5 destinations per the standing Country Chart and end-use rules — this is independent of the diffusion framework's fate.
- **Entity List restrictions** on Huawei, SMIC-affiliated entities, and other semiconductor-related listed parties remain in full effect.
- **The Foreign Direct Product Rule (Entity List FDPR and Advanced Computing FDPR)** continues to capture foreign-made chips produced with US wafer-fab equipment destined for restricted Chinese entities.
- **§ 744.21 military end-use/end-user controls** and standard restricted-party screening obligations are unaffected by the diffusion rule's status.

**Recommendation for your compliance structure:**

1. Do not build licensing workflows, customer tiering, or contractual representations around the January 2025 diffusion tiers — they may never be formally revived, and doing so risks basing decisions on a framework BIS has publicly said it won't enforce.
2. Continue to apply the pre-existing, unambiguous controls: 3A090/4A090 classification, Country Chart lookups, Entity List/MEU screening, and FDPR analysis for foreign-made chips built with US tooling.
3. Monitor the Federal Register specifically for (a) a formal rescission or replacement of the January 2025 IFR, and (b) additional country-specific rules following the UAE model — build a rule-tracking process rather than a static tier table.
4. Flag this issue to export counsel given the GAO CRA finding — there is some possibility that a future administration or a CRA disapproval resolution could reactivate enforcement of the original IFR with retroactive-feeling effect on transactions structured during the non-enforcement window.

*General compliance guidance, not legal advice. This area is unusually fluid — verify the current Federal Register status before finalizing any AI chip export decision.*

A quick caveat up front: this is one of the fastest-moving areas of U.S. export control right now, and rules affecting advanced AI chips and computing capacity have been revised multiple times in a short period. I'd treat anything below as a framework for thinking about it rather than a citation you rely on without checking the current Federal Register text and BIS's published FAQs before you finalize any export decision.

Background on the "AI diffusion rule"
In its final months, the prior administration published an "Artificial Intelligence Diffusion" interim final rule that attempted to restructure how advanced AI chips (and, to a lesser extent, the closed-weight AI model access tied to them) are controlled. The core idea was a tiered country framework layered on top of the existing ECCN 3A090 (and related 4A090/3D090/3E090, etc.) controls on high-performance/advanced computing GPUs and accelerators that had already been tightened over prior years:
- A small group of close allies would face few or no new restrictions.
- A middle tier of countries would face new per-country compute/chip caps, Validated End User (VEU) style program requirements, and government-to-government agreements as an alternative path to caps.
- Countries already subject to arms embargoes or already covered by the China/Macau restrictions (and other listed destinations) would remain heavily restricted or embargoed for the most advanced chips.
The rule also introduced novel concepts like controlling "model weights" for the most advanced closed-weight AI models above certain compute thresholds, and imposing security/reporting conditions on companies wanting to use the expanded caps.

What changed after publication
This rule drew significant pushback from industry (concerns about the complexity of the tiering, the compute-cap approach, and the model-weights control) and from some U.S. trading partners who objected to being placed in the restricted middle tier. My knowledge of the exact final disposition may be out of date by the time you read this — the rule's effective date was pushed out at least once, and there was public discussion of it being replaced or substantially rewritten rather than implemented as originally drafted. Given how contested and fluid this has been, I would not rely on my recollection of the current status; you should pull the live BIS rule text (and any subsequent amendments or rescissions) before making a compliance decision.

What is much more stable, and what you should structure around regardless of how the diffusion-specific tiering ultimately lands
- The underlying ECCN classifications for advanced GPUs/accelerators (3A090.a for the most advanced parts, 3A090.b for a middle band, plus associated software/technology entries) are the backbone of chip controls and are unlikely to disappear even if the diffusion rule's country-tier overlay changes.
- The China/Macau-specific controls (including the semiconductor manufacturing equipment and advanced computing rules dating back to October 2022 and subsequent amendments) remain a hard floor — advanced AI chips above certain performance thresholds destined for China, Macau, and D:5 arms-embargoed countries have been restricted regardless of what happens to the newer diffusion tiering.
- The Entity List has been used aggressively in this space — many Chinese AI, chip-design, and cloud-computing entities have been added, and "affiliates" rules (the 50% ownership rule) mean you need to trace corporate ownership, not just check the named entity.
- Temporary General License and country-specific carve-outs have shifted repeatedly, so any compliance program in this space needs a process for re-checking classification and licensing status frequently (e.g., quarterly, or before every shipment) rather than relying on a static determination.

Practical recommendation for structuring exports
1. Classify your specific chip/accelerator SKUs against the current 3A090 performance thresholds (and check 4A090 if it's an end system, not just the chip) — don't assume a "diffusion rule" label change alters the base classification.
2. Build your country/customer matrix around the more durable China/Macau/D:5 restrictions and Entity List screening first, then layer in whatever the current diffusion-style tiering (or its replacement) requires for other destinations.
3. Because this rule has been amended, delayed, and reportedly reworked, get current legal/regulatory confirmation of its status — including whether it has been rescinded, replaced, or is in effect as originally published — before designing your export structure around it, rather than relying on an assistant's general knowledge of a rule this volatile.

Screening Lessons for a Chinese University Research Institute Buying Lab Neuroscience Equipment

This scenario sits directly on top of a live enforcement precedent, and the lesson from it should shape your entire screening approach rather than just a single checklist item.

**The governing lesson: the Plexon enforcement action (settled August 2026).** BIS settled with Plexon, Inc. for $1.7M (fully suspended over a 5-year probationary period, waived on completion of an external audit and a clean compliance record) over eight unlicensed exports (~$179K total value) of neural-recording systems to China's Academy of Military Medical Sciences — an entity that had been on the Entity List since 2021. The core lesson: **research and medical technology is not inherently exempt from Entity List screening.** A product being scientific, civilian-market, or apparently benign (neural recording amplifiers, electrophysiology equipment) does not substitute for actually screening the named institutional buyer. Apply that lesson directly here.

**Step 1 — Classify the equipment itself.** Determine whether your lab neuroscience equipment (recording amplifiers, electrode arrays, stimulation systems, associated software) falls on the CCL or is EAR99. Many neuroscience research instruments are EAR99, but some signal-processing, sensor, or associated software components may fall under Category 3 (electronics) or Category 5 (information security, if there's encrypted data transmission/storage). Document the classification rationale regardless of outcome — the Plexon case involved equipment that may not have carried an exotic ECCN; the violation was the *end-user*, not necessarily an exotic classification.

**Step 2 — Screen the named institute, not just "a Chinese university."** Run the specific institute's legal name, known aliases, and any parent/affiliate entities through the Consolidated Screening List (trade.gov/consolidated-screening-list), which covers the BIS Entity List, Denied Persons List, Unverified List, Military End-User List, and OFAC's SDN/Consolidated Sanctions Lists in one search. Many Chinese research institutions have military-affiliated parent organizations, PLA research ties, or are among the so-called "Seven Sons of National Defence" universities and their affiliates — a name that sounds like a purely academic research institute may sit under, or feed research directly into, an Entity-Listed military research organization. Check for shared addresses, shared leadership, or subsidiary relationships, not just an exact name match.

**Step 3 — Recognize that China is Country Group D:1, which narrows your options.** If any component of the equipment does carry an NS-controlled ECCN, note that CIV (Civil End-Users) is the primary exception theoretically available to D:1 destinations — but it requires a written end-user/end-use certification and is heavily scrutinized by BIS precisely because China is D:1. Do not treat CIV as a routine pass-through; treat it as a heightened-diligence exception.

**Step 4 — Apply § 744.21 military end-use/end-user controls and WMD/military-intelligence end-use checks (§ 744.6).** Even EAR99 equipment requires a license if the exporter knows or has reason to know of a prohibited military end-use or if the end-user is properly captured under military end-user controls. Ask direct questions about the specific research program the equipment will support, and document the answers.

**Step 5 — Watch the red flags from § 732.6.** In this fact pattern, red flags include: reluctance to specify the exact research application; requests for capabilities beyond typical academic research use; unusual or urgent payment terms; requests to ship through a freight forwarder or intermediate consignee rather than directly to the institute; or refusal to sign an end-user statement.

**Step 6 — Build the file before you ship, not after.** Obtain: a signed End-User Statement identifying the specific lab, principal investigator, and research purpose; documented Entity List/CSL screening results with date and screener name; the ECCN/EAR99 classification rationale; and internal sign-off from your Export Control Officer if any red flag was raised and resolved. Retain all of this for 5 years (§ 762.6) — the retention obligation applies whether or not you conclude a license is required.

**Bottom line:** Treat "Chinese university research institute" as a name requiring full-depth Entity List and affiliate screening before quoting the order, not after. The Plexon case shows BIS will pursue penalties even where the exporter may have believed the transaction was ordinary academic/medical trade — the compliance failure was inadequate screening of a listed military-research end-user, not necessarily a classification error.

*General compliance guidance, not legal advice — consult export counsel, particularly given the elevated scrutiny BIS applies to China D:1 research-institution transactions.*

Selling lab neuroscience equipment to a Chinese university research institute is a genuinely useful test case because it pulls in almost every category of EAR screening risk at once: classification, Entity List exposure, military/intelligence end-use catch-alls, and the "deemed export" angle if any technology transfer or training accompanies the sale. Here are the key lessons.

1. Classify the equipment itself first
Most lab neuroscience equipment (EEG/EMG systems, basic electrophysiology rigs, standard imaging accessories, general lab instrumentation) is EAR99 or falls under low-control ECCNs. But don't assume that by category — check for:
- Any embedded encryption in data acquisition/control software (could implicate 5A992/5D992).
- Specialized sensors, high-speed cameras, certain lasers, or precision optics that could trigger 6A003-family or similar CCL entries.
- Any component with potential dual-use application to neural signal processing that has attracted specific control language (some brain-computer interface and advanced sensor technologies have drawn increased attention in recent rulemakings).
Get the actual technical specifications and self-classify against the CCL before assuming EAR99 status; equipment marketed as "lab" or "research" grade is not automatically uncontrolled.

2. Entity List screening is the first and most important gate, not an afterthought
Numerous Chinese universities and their affiliated research institutes have been added to the BIS Entity List over the past several years because of ties to military modernization, human rights concerns, or restricted end uses (this has included a number of "National University of Defense Technology"-type institutions and other PLA-affiliated or PLA-linked research units, as well as some institutes tied to surveillance or biotechnology concerns). Before anything else:
- Screen the named institute, and don't stop there — check for known affiliated entities, associated labs, and joint research centers, since university systems in China often have multiple sub-institutes and affiliated companies with separate but related names.
- Apply the 50% ownership/affiliate rule where relevant — Entity List restrictions can extend to subsidiaries and affiliates that are majority owned by a listed entity.
- Check OFAC's SDN and other lists as a secondary matter, and check the BIS Unverified List, since some Chinese entities appear there because prior end-use checks could not be completed.

3. Apply the military/intelligence end-use and end-user "catch-all" analysis
Even for EAR99 or low-level ECCN items, BIS maintains catch-all rules restricting exports to China (and other listed countries) where you know or have reason to know the item will support a "military end use" or is destined to a "military end user," and there are separate, broader "catch-all" restrictions tied to certain advanced or sensitive technology areas that have been extended over time to cover more items and more Chinese government-connected entities, including some research institutes. Ask directly, and document: what is the research institute's institutional affiliation (purely civilian university vs. one with documented military or defense-industrial ties), what is the stated end use (basic neuroscience research vs. anything touching brain-computer interface, human performance enhancement, or biometric/neural signal processing with potential dual-use security application), and who will actually operate the equipment.

4. Watch for the "deemed export" angle
If your sale includes on-site installation, training, calibration support, or ongoing technical support that shares controlled technology (not just hardware) with foreign national researchers, that support itself can be a separate "deemed export" of technology, which is analyzed independently of the hardware sale and may require its own license depending on classification and the nationality of the personnel involved.

5. Practical red flags common in this fact pattern
- The institute or a stated "collaborator" requests equipment specs beyond typical university research needs (e.g., far higher precision, unusual quantities, or components inconsistent with a stated academic project).
- Reluctance to identify the specific lab, principal investigator, or end use.
- A request to ship to a freight forwarder or intermediary rather than directly to the university campus.
- The purchasing entity is newly formed, has a name very similar to (but not exactly matching) a listed entity, or is a trading company acting "on behalf of" the university.

6. Practical recommendation
Build a documented screening file for this transaction: entity screening results (including affiliate analysis), classification determination for each item, an end-use statement from the institute describing the specific research application, and — if the institute or its parent university has any documented military/defense research affiliation, or if your classification analysis lands on anything beyond EAR99 — route the transaction through formal license-requirement analysis rather than relying on "it's just lab equipment" as a conclusion. Given how frequently the Entity List and China-related catch-all rules have been updated, screen against the current list at time of shipment, not just at time of quote.

================================================================================
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)

# CV Screening Tool — EU AI Act Classification

## 1. AI system definition check
An AI-powered CV screening tool that ranks applicants infers, from inputs (CVs/applications), outputs (rankings/scores) that influence a real-world decision — this meets the Art. 3(1) AI system definition.

## 2. Prohibited practices screen (Art. 5)
Ranking applicants on job-relevant criteria is not one of the 9 prohibited categories (no subliminal manipulation, social scoring, or biometric categorisation involved on the facts given) — **not prohibited**, proceed to risk-tier determination.

## 3. Risk tier determination — High-Risk, Annex III Area 4(a)
**Yes, this is high-risk.**

- **Path:** Art. 6(2) / Annex III (not the Art. 6(1) sectoral-product path).
- **Annex III area: Area 4 — Employment, Workers Management, and Self-Employment, point (a) — Recruitment and selection**, specifically "filtering or screening job applications" and "evaluat[ing] candidates." A tool that *ranks* applicants for employers falls squarely within this description.
- **Art. 6(3) exceptions test:** None of the narrow exceptions (procedural task only / improving a completed human activity / pattern-deviation detection / preparatory task) plausibly apply — ranking applicants *is* the substantive evaluation, not a preparatory or narrow procedural step.
- **Profiling override (Art. 6(3), final subparagraph):** Even if an exception were argued, a CV-ranking tool profiles natural persons (evaluating work-related attributes/suitability under Art. 3(52)), which makes it high-risk regardless. There is no credible path to a non-high-risk conclusion here.
- **Conclusion:** High-risk under Annex III Area 4(a). No Art. 6(4) documentation-of-exemption route is realistically available — this system does not escape classification.

## 4. Compliance deadline
Annex III standalone high-risk systems must comply by **2 December 2027** (per the Digital Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026, which deferred the original 2 August 2026 date). As of today (15 August 2026), you have until that date to complete conformity work, but given the scope of the obligations below, work should start now.

Note also that **Art. 50 transparency obligations are already in force (2 August 2026)** — if the tool or any related interface involves an AI chatbot or AI-generated content toward candidates, that transparency duty applies now, independent of the Annex III high-risk deadline.

## 5. Main obligations as provider
As the **provider** (you develop and place the system on the market for employers), your obligations run under Arts. 9–17, 43–49:

| Requirement | Article | What it means for a CV-ranking tool |
|---|---|---|
| Risk management system | Art. 9 | Continuous 5-step process — identify risks (e.g., discriminatory ranking against protected groups), evaluate, mitigate by design first, then via information to deployers; document reasoning |
| Data governance | Art. 10 | Training/validation/test data must be representative of the applicant pools the system will encounter; document bias examination; special-category data (e.g., inferred protected characteristics) only under strict Art. 10(5) conditions |
| Technical documentation | Art. 11 | Annex IV file: development process, training data description, validation/testing metrics, risk management documentation — retained 10 years |
| Record-keeping/logging | Art. 12 | Build in automatic event logging so ranking decisions can be reconstructed post-hoc |
| Transparency to deployers | Art. 13 | Instructions for use covering accuracy/robustness metrics, known limitations, human oversight measures, input data specifications |
| Human oversight | Art. 14 | Design the system so employer staff can understand outputs, recognize automation bias, and override/disregard rankings — not a fully automated hire/reject decision |
| Accuracy, robustness, cybersecurity | Art. 15 | Declared accuracy levels in instructions for use; resilience to adversarial manipulation (e.g., CV keyword-stuffing attacks) |
| Provider checklist | Art. 16 | Full 12-item list: conformity, labeling, QMS, technical file, logs, conformity assessment, EU Declaration of Conformity, CE marking, EU AI database registration, corrective action process, demonstrate conformity on request, accessible design |
| Quality management system | Art. 17 | 13-component documented QMS |
| Conformity assessment | Art. 43 | Annex III Area 4 is a **Points 2–8** area → **self-assessment only** (Annex VI-style internal control); no notified body route required |
| EU Declaration of Conformity | Art. 47 | Drawn up before market placement; retained 10 years |
| CE marking | Art. 48 | Affixed after successful self-assessment |
| EU AI database registration | Art. 49 | Register before placing the system on the market |

Separately, note that **employer-deployers** using your tool carry independent Art. 26 obligations (instructions compliance, human oversight assignment, worker notification before deployment, 6-month log retention, and — because Area 4 decisions affect natural persons — informing affected candidates under Art. 26(11)). You should factor these into your Art. 13 instructions for use so employers can meet them.

---
*General compliance information, not legal advice — verify against official sources and consult qualified counsel for binding determinations.*

# CV Screening Tool — EU AI Act Classification

## Is it high-risk?
Yes. An AI system used to rank/screen job applicants is very likely classified as **high-risk** under the EU AI Act (Regulation (EU) 2024/1689).

## Which Annex III area applies?
**Annex III, point 4 — Employment, workers' management and access to self-employment.** This category specifically covers AI systems intended to be used for:
- Recruitment or selection of natural persons, in particular to place targeted job advertisements, analyse and filter job applications, and **evaluate candidates**.
- Making decisions affecting terms of work-related relationships, promotion, termination, task allocation, and monitoring/evaluating performance.

A CV screening/ranking tool falls squarely under "analyse and filter job applications" and "evaluate candidates," so it meets the Annex III, point 4(a) criteria.

## Compliance deadline
High-risk AI systems listed in **Annex III** become subject to the Act's high-risk obligations **24 months after entry into force**, i.e. **2 August 2026**. The AI Act entered into force on 1 August 2024, and this is the general application date for Chapter III (high-risk systems), Chapter IV (transparency for certain systems), governance provisions, and penalties. Note that this deadline has effectively already passed relative to today's date (15 August 2026), so if you have not yet completed compliance, you are already past the applicable date and should treat this as urgent.

(Separately: Article 5 prohibited practices applied from 2 February 2025, and GPAI model obligations applied from 2 August 2025 — neither is directly relevant here unless you're using a general-purpose AI model as a component.)

## Main obligations as the provider
As the **provider** of a high-risk AI system, under Articles 8–17 and related provisions you must, among other things:
1. **Risk management system** (Art. 9) — establish, implement, document, and maintain a continuous risk management process across the system's lifecycle.
2. **Data governance** (Art. 10) — ensure training, validation, and testing data are relevant, representative, and examined for biases (critical for a CV-screening tool given discrimination risk).
3. **Technical documentation** (Art. 11) — prepare documentation demonstrating compliance before placing on the market (Annex IV content).
4. **Record-keeping / automatic logging** (Art. 12) — enable automatic logging of events over the system's lifetime for traceability.
5. **Transparency and instructions for use** (Art. 13) — provide clear information to deployers (employers) about capabilities, limitations, and intended purpose.
6. **Human oversight** (Art. 14) — design the system so deployers can effectively oversee it (e.g., ensuring a human reviews/can override rankings before a hiring decision).
7. **Accuracy, robustness, and cybersecurity** (Art. 15).
8. **Quality management system** (Art. 17) covering the whole organisation.
9. **Conformity assessment** (Art. 43) — for Annex III systems this is generally an internal control-based (self-assessment) procedure unless a harmonised standard requires otherwise, followed by drawing up an **EU declaration of conformity** and affixing the **CE marking**.
10. **Registration** in the EU high-risk AI database (Art. 49) before placing the system on the market.
11. **Post-market monitoring** (Art. 72) and **serious incident reporting** to market surveillance authorities (Art. 73).
12. Cooperate with authorities and, if established outside the EU, appoint an **authorised representative** in the EU.

You should also be aware that **deployers** (the employer using your tool) have their own separate obligations under Article 26, including conducting a **Fundamental Rights Impact Assessment (FRIA)** under Article 27 for employment use cases, and informing workers' representatives/affected individuals as required by national and EU law (including GDPR Article 22 considerations on automated decision-making).

# Predictive Criminal Risk Assessment Tool — EU AI Act Screen

**Short answer: No — this system is prohibited (not merely high-risk) under Art. 5(1)(d) of the EU AI Act, and cannot be lawfully procured or deployed by the police force in the EU.**

## 1. AI system definition check
A system that predicts the likelihood of individuals committing future criminal offences from personality traits and behavioural data meets the Art. 3(1) AI system definition (infers outputs — a risk prediction — from inputs).

## 2. Prohibited practices screen (Art. 5) — this is the controlling issue
This falls within **Art. 5(1)(d) — Predictive Criminal Risk Assessment**:

> AI systems assessing the risk of natural persons committing criminal offenses **based solely on profiling or personality/character traits assessment** are prohibited.

Your description — "predicts the likelihood of individuals committing future criminal offences **based on personality traits and past behaviour**" — matches this prohibited category directly. Profiling and personality/character-trait assessment are exactly the inputs Art. 5(1)(d) targets.

**The narrow exception does not rescue this system.** Art. 5(1)(d) permits AI systems that *support* a human assessment where that assessment is based on **objective, verifiable facts directly linked to criminal activity** — e.g., forensic evidence tied to a specific offence. A system built on personality-trait profiling and general behavioural history is the opposite of this exception: it is precisely the kind of character-based, non-fact-specific prediction the exception was drafted to exclude. There is no indication here that the tool is confined to objective, verifiable facts tied to a specific criminal act, or that it merely supports (rather than drives) a human officer's assessment.

**Conclusion:** This is not a high-risk/Annex III classification question — the Art. 5 prohibited-practices screen is dispositive and takes precedence. A match with any of the 9 prohibited categories means the system **cannot be lawfully deployed in the EU**, regardless of Annex III or conformity-assessment considerations. Predictive risk-scoring tools of this kind are sometimes miscategorised as "high-risk" (Annex III Area 6(d) — assessing risk of offending/reoffending) — but Area 6(d) only applies to systems that pass the Art. 5 screen first. This one does not.

## 3. What this means practically
- The police force cannot lawfully procure or use this system as described.
- You as the would-be provider should not place it on the market for this use case in the EU.
- If there is a legitimate underlying use case (e.g., supporting an officer's assessment using objective, verifiable, offence-specific facts — such as prior convictions for the same offence type, documented case evidence, or forensic indicators — rather than personality/character profiling), the system would need to be substantially redesigned to strip out personality-trait and general-behaviour profiling and to function as a genuine decision-support tool tied to verifiable facts. Even then, careful legal review would be needed to confirm it falls outside Art. 5(1)(d) before considering it under the Annex III Area 6 high-risk framework.
- Consult the AI Office's 4 February 2025 guidelines on Art. 5 prohibited practices, which include worked examples for this category, and the Commission's May 2026 studies on Art. 5, before finalising any redesign.

## 4. Penalties for non-compliance
Placing or using a prohibited AI system carries the highest Art. 99 penalty tier: **up to €35 million or 7% of total worldwide annual turnover**, whichever is higher.

---
*General compliance information, not legal advice — verify against official sources and consult qualified counsel before making a procurement or deployment decision on this system.*

# Predictive Policing Based on Personality Traits — Not Permitted

## Short answer
**No — this system is prohibited under the EU AI Act.** It cannot lawfully be placed on the market, put into service, or used in the EU, regardless of who the customer is (including a national police force).

## Legal basis
Article 5(1)(d) of the EU AI Act prohibits:

> "the placing on the market, the putting into service for this specific purpose, or the use of an AI system for making risk assessments of natural persons in order to assess or predict the risk of a natural person committing a criminal offence, based **solely** on the profiling of a natural person or on assessing their personality traits and characteristics."

Your described system — predicting the likelihood of individuals committing future criminal offences based on **personality traits and past behaviour** — is a textbook match for this prohibition. Profiling based on personality traits/characteristics to forecast future criminal conduct is exactly the practice the Act bans, because it risks generating a stigmatising, self-fulfilling "pre-crime" style assessment that isn't tied to objective, verifiable facts of actual criminal activity.

## The narrow exception
Article 5(1)(d) includes a carve-out: the prohibition **does not apply** to AI systems used to **support the human assessment** of a person's involvement in a criminal activity, where that assessment is **already based on objective and verifiable facts directly linked to a criminal activity**. In other words:
- The AI can assist an investigation of a **specific, already-suspected** criminal activity grounded in verifiable facts (e.g., forensic data, evidence linked to a real offence).
- It **cannot** be used to generate a general risk/propensity score about a person's likelihood of future offending based on traits, demographics, or behavioural profiling absent such concrete factual links.

Based on the description given — predicting likelihood of *future* offences from personality traits and past behaviour, i.e., general risk-scoring/profiling rather than investigation of a specific factually-grounded suspected offence — the exception would **not** apply.

## Consequences
- Placing such a system on the market or using it constitutes a prohibited AI practice under Article 5, subject to the Act's most severe penalties: fines of up to **€35 million or 7% of total worldwide annual turnover**, whichever is higher (Art. 99(3)).
- You should not proceed with this procurement/deployment. If the police force's actual need is narrower (e.g., a decision-support tool tied to specific, evidence-based investigations of an already-identified offence), that use case would need to be carefully re-scoped and would likely still be high-risk under Annex III (law enforcement) rather than prohibited — but the system as described to you falls under the Article 5(1)(d) ban.

## Recommendation
Advise the customer that this specific use case cannot be built or sold as described. If they want a lawful alternative, it would need to be redesigned to support human investigators in assessing a **specific, factually-grounded** suspected involvement in a **particular** criminal activity — not a general predictive/profiling risk score — and even then it would likely be classified as **high-risk** under Annex III, point 6 (law enforcement), triggering the full high-risk obligations (risk management, human oversight, FRIA by the deploying authority, registration, etc.).

# Open-Source GPAI Model (~8×10²³ FLOPs) — Obligations Assessment

## 1. Scope & role
You are a **GPAI model provider** (Art. 3(3)/(63)) releasing an open-source model — weights, architecture, and usage documentation publicly available under a free license.

## 2. GPAI classification and systemic-risk threshold
- **GPAI obligations threshold:** Models trained with **≥10²³ FLOPs** are subject to GPAI obligations under Arts. 53–55 (per Commission guidelines, July 2025). At **8×10²³ FLOPs**, your model is **above this threshold** — you are a GPAI provider subject to Art. 53.
- **Systemic-risk presumption threshold:** ≥10²⁵ FLOPs. At 8×10²³ FLOPs, you are **roughly two orders of magnitude below** this threshold, so the automatic systemic-risk presumption (Art. 51) does **not** apply. (Note: the Commission can still designate a model as systemic-risk independent of the FLOPs threshold based on high-impact capabilities, broad EU reach, or Annex XIII criteria — but nothing in your facts suggests that applies here.)

## 3. Open-source exception — which obligations actually apply
Because your model is released with weights, architecture, and usage documentation publicly available under a free license, you qualify for the **open-source/free-license exception** to Art. 53. Under this exception, you only need to comply with **two of the four** universal GPAI obligations:

| Obligation | Applies to you? |
|---|---|
| 1. Technical documentation (Annex XI) — for AI Office/national authorities | ❌ Not required (open-source exception) |
| 2. Downstream provider information (Annex XII) | ❌ Not required (open-source exception) |
| **3. Copyright compliance policy** (Directive 2019/790) | ✅ **Required** — policy to respect text-and-data-mining opt-outs (Art. 4(3) of the Directive), technically enforceable and publicly described |
| **4. Public training content summary** | ✅ **Required** — sufficiently detailed public summary of training content, following the Commission's published template (available since July 2025) |

If your model is ever later designated as having systemic risk (by crossing 10²⁵ FLOPs cumulative across training runs, or by Commission designation), the full Art. 53 obligations plus Art. 55 systemic-risk obligations (model evaluation/red-teaming, risk assessment, serious incident reporting, cybersecurity) would apply — but that is not your current position at 8×10²³ FLOPs.

## 4. Does the GPAI Code of Practice help?
**Yes — it is the primary recommended compliance pathway**, and it is directly useful even though you only owe two of the four Art. 53 obligations:

- The CoP's **Copyright chapter** gives you a ready-made structure for your required copyright policy: a written policy, compliance with robots.txt and technical opt-out protocols, a rightsholder complaints mechanism, and a prohibition on infringing uses in your acceptable-use policy.
- The CoP's **Transparency chapter** provides the **Model Documentation Form**, which — while not mandatory for you given the open-source exception — is a useful template if you want your public training summary to meet a well-recognised standard; downstream providers can request additional detail within 14 days under the CoP framework.
- The **Safety and Security chapter** is systemic-risk-only and does not apply to you at your current compute level.
- Signing the CoP is voluntary. Major labs (Anthropic, Google, Microsoft, OpenAI, Amazon, IBM, Mistral, and others) are signatories; if you choose not to sign, you must be able to **demonstrate compliance with your two applicable obligations by alternative means** and explain your approach to the AI Office if asked.

## 5. Enforcement posture (current as of 15 August 2026)
The **AI Office's full enforcement powers over GPAI providers have been active since 2 August 2026** — information requests (Art. 91), model evaluations (Art. 92), mitigation measures (Art. 93), and fines up to €15M or 3% of worldwide turnover for provider violations. Even though your obligations are limited to the copyright policy and training summary, both should be **in place and inspection-ready now**: publish the copyright policy and training-content summary if you have not already, and be prepared to demonstrate your TDM opt-out mechanism is technically enforceable.

## 6. Practical action list
1. Publish a written copyright compliance policy addressing Directive 2019/790 Art. 4(3) TDM opt-outs (robots.txt / technical opt-out support).
2. Publish a public training content summary using the Commission's template.
3. Monitor cumulative training compute — if a future training run pushes you toward or past 10²⁵ FLOPs, notify the AI Office within 2 weeks of reaching/approaching that threshold (Art. 51 notification duty), as this would trigger full Art. 53 + Art. 55 obligations and end your open-source exception for the higher-compute model.
4. Consider adopting the CoP's Copyright and Transparency chapters as your compliance framework, even without signing formally, to have a defensible "alternative means" position.

---
*General compliance information, not legal advice — verify against official sources and consult qualified counsel for a binding compliance determination.*

# Open-Source LLM (~8×10^23 FLOPs) — GPAI Obligations

## Step 1: Is it a "general-purpose AI model" (GPAI)?
Yes. An LLM capable of a wide range of distinct tasks, trained on a large dataset with self-supervision at scale, is a GPAI model under Article 3(63) and Recital 97, regardless of how it is placed on the market.

## Step 2: Does the systemic-risk threshold apply?
Article 51(2) creates a **rebuttable presumption of systemic risk** when the cumulative compute used for training exceeds **10^25 FLOPs**. Your model was trained with roughly **8×10^23 FLOPs**, which is **about two orders of magnitude below** that threshold. So:
- Your model is **not presumed** to present systemic risk.
- Unless the AI Office separately designates it as having systemic risk (via a decision under Art. 51(1)(b), based on capability-based criteria — unlikely at this compute level and with no indication of exceptional capability), you are treated as a **standard (non-systemic-risk) GPAI model provider**.

## Step 3: Baseline GPAI obligations (Article 53)
All GPAI model providers, in principle, must:
- (a) Draw up and keep up-to-date **technical documentation** of the model (Annex XI), including training/testing process and evaluation results.
- (b) Draw up and provide **information/documentation to downstream providers** who integrate the model, sufficient for them to understand capabilities/limitations and meet their own AI Act obligations.
- (c) Put in place a **policy to comply with EU copyright law**, including identifying and complying with rights reservations (Art. 4(3) of the DSM Copyright Directive, e.g. respecting text-and-data-mining opt-outs).
- (d) Publish a **sufficiently detailed summary of the content used for training** the model, using the template published by the AI Office.

## Step 4: The open-source exemption (Article 53(2))
Because your model's weights, architecture, and usage information are made **publicly available** under a **free and open-source license** that permits access, use, modification, and distribution, **Article 53(2)** exempts you from obligations (a) and (b) above — i.e., you do **not** need to produce full technical documentation for the AI Office or bespoke documentation packages for every downstream provider — **unless** the model is later found to present systemic risk.

Important nuance: the exemption applies **only to points (a) and (b)**. You are **still required** to comply with:
- (c) the **copyright-compliance policy**, and
- (d) publishing the **training data summary**.

These two obligations apply to open-source GPAI providers regardless of the exemption, because they protect third-party rights (copyright holders) rather than just downstream technical transparency.

## Step 5: Does the GPAI Code of Practice help?
Yes, it's directly relevant. The **General-Purpose AI Code of Practice**, facilitated by the AI Office with industry/civil society input, was finalized in 2025 to give providers a concrete way to demonstrate compliance with Articles 53 (and 55 for systemic-risk models) ahead of/alongside harmonised standards. Benefits of signing on:
- It offers a structured, AI-Office-endorsed template for the training data summary and documentation practices, reducing ambiguity about what "sufficiently detailed" means.
- Providers who adhere to the Code benefit from a **presumption of conformity** with the relevant Article 53 obligations (and Article 55 if systemic risk ever applied), reducing enforcement/interpretation risk, and signalling good faith to the AI Office and to downstream customers/regulators.
- It's **voluntary** — you aren't required to sign it, and you can instead demonstrate compliance through other adequate means (e.g., harmonised standards once available), but adherence is the lowest-friction path to demonstrable compliance, especially given regulatory guidance is still maturing.

## Practical summary for your situation
- No systemic-risk obligations (Art. 55) apply — you're well under the 10^25 FLOPs presumption threshold.
- You are exempt from full technical documentation (to AI Office) and downstream-provider documentation packages due to the open-source exemption.
- You **must still** maintain a copyright-compliance policy and publish a public training data summary.
- Signing/following the GPAI Code of Practice is recommended as a practical way to meet and evidence the copyright and training-data-summary obligations with reduced regulatory risk, even though most of Article 53 doesn't strictly bind you.
- GPAI obligations generally became applicable from **2 August 2025**, so these obligations are already in force for you as of today.

# AI as a Safety Component of a Medical Device — EU AI Act / MDR Interaction

## 1. AI system definition & role
Your AI-based software infers outputs affecting patient safety within a medical device — it meets the Art. 3(1) AI system definition, and you act as **provider** under the AI Act.

## 2. Prohibited practices screen (Art. 5)
Nothing in the facts suggests a prohibited-practice match — proceed to risk-tier determination.

## 3. Risk tier — High-Risk via Art. 6(1), Annex I (Path A), not Annex III
This is the **sectoral-product path**, not the Annex III use-case path:

- **Art. 6(1) test:** High-risk when (1) the AI is a safety component of a product covered by Annex I harmonisation legislation, **and** (2) that product requires third-party conformity assessment under the relevant Annex I legislation.
- **Medical devices are Annex I, Section A, item 11** — Regulation (EU) 2017/745 (MDR). Your facts state the device requires **notified-body conformity assessment under the MDR**, which satisfies condition (2). Your AI is described as a **safety component**, satisfying condition (1).
- **Conclusion:** Both Art. 6(1) conditions are met — this is high-risk under the **Annex I embedded-product path**, not Annex III. (Annex III would only be relevant if the software were a standalone AI system not embedded in an Annex I product — that is not your case here.)

## 4. How the AI Act interacts with the MDR
The AI Act is designed to **integrate with**, not duplicate, your existing MDR regime:

- **Conformity assessment (Art. 43):** For Annex I products, AI Act conformity assessment is **integrated into the existing conformity assessment procedure already required under the product's Annex I legislation** — here, the MDR notified-body process. You do not run two separate, parallel conformity assessments; your MDR notified body assesses AI Act compliance (Arts. 9–15 requirements) as part of the same MDR conformity assessment procedure, provided that notified body is appropriately designated/competent to also cover AI Act requirements.
- **Substantive requirements still apply in full:** Arts. 9–17 (risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy/robustness/cybersecurity, provider checklist, QMS) all apply to the AI component — your existing MDR risk management (ISO 14971) and QMS (ISO 13485) processes can and should be extended/mapped to cover the AI Act's additional requirements (e.g., Art. 9's 5-step process, Art. 10 data governance for training data, Art. 14 human oversight for the AI-driven functionality) rather than built as a separate silo.
- **Documentation:** Your Annex IV technical documentation (Art. 11) should be integrated with your MDR technical file where content overlaps (e.g., risk management documentation, validation/testing data) to avoid duplicative documentation sets.
- **CE marking and Declaration of Conformity:** A single CE marking process results once both the MDR and AI Act conformity requirements are satisfied through the integrated assessment; the EU Declaration of Conformity (Art. 47) should reference both regimes.
- **Post-market monitoring (Art. 72) and incident reporting (Art. 73):** Existing MDR post-market surveillance and vigilance/incident-reporting systems may be adapted and integrated to also satisfy AI Act obligations, rather than maintaining separate systems.

**Practical takeaway:** Treat this as "one conformity assessment, two legal bases layered together" via your notified body, not as two independent compliance programmes.

## 5. Compliance deadline
Annex I embedded-product high-risk systems (like yours) must comply by **2 August 2028** — this is the deadline set by the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026), which extended the original 2 August 2027 date. As of today (15 August 2026), you have roughly two years, but because your AI Act conformity work is integrated into your MDR notified-body assessment cycle, you should align AI Act readiness (risk management, data governance, technical documentation, human oversight design) with your next scheduled MDR conformity assessment milestone rather than waiting until close to the 2028 deadline.

Note: this Annex I deadline is separate from and later than the Annex III standalone-system deadline (2 December 2027) and the Art. 50 transparency deadline (already in force since 2 August 2026) — confirm none of your device's user-facing features (e.g., an AI chatbot for patient support) separately trigger Art. 50 obligations now.

---
*General compliance information, not legal advice — verify against official sources and consult qualified counsel or your notified body for a binding compliance determination.*

# AI Safety Component of a Medical Device — AI Act × MDR Interaction

## Classification: high-risk via Annex I (product-safety route), not Annex III
Your AI system is a **safety component of a medical device** regulated under the EU Medical Device Regulation (Regulation (EU) 2017/745, "MDR"), and it requires **notified-body third-party conformity assessment** under the MDR. This puts it squarely under **Article 6(1)** of the AI Act (the "product-related" high-risk pathway), not Annex III:

- Article 6(1) classifies an AI system as high-risk if (a) it is intended to be used as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in **Annex I** (which includes the MDR and IVDR), **and** (b) the product is required to undergo a third-party conformity assessment under that sectoral legislation with a view to placing it on the market.

Both conditions are met in your case, so the AI system is high-risk under the **Annex I route**, distinct from the Annex III use-case list.

## How the AI Act interacts with MDR compliance
The AI Act is designed to be **integrated with, not duplicative of**, existing sectoral product-safety regimes:
- **Single conformity assessment process (Article 43(3)):** Where a product is subject to both MDR and AI Act conformity assessment, providers may (and in many cases must) follow the **conformity assessment procedure required by the MDR**, with the AI Act's requirements (Articles 8–15: risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy/robustness/cybersecurity) **built into that MDR assessment** rather than run as a wholly separate parallel process. The notified body assessing your device under MDR must also be designated/notified (or otherwise qualified) to assess AI Act requirements, or coordinate with an AI Act-notified body.
- **Combined/aligned technical documentation:** You can integrate AI Act technical documentation (Annex IV) into your existing MDR technical documentation/design dossier rather than maintaining two separate documentation sets, provided all required elements from both regimes are covered.
- **Single CE marking, dual legal basis:** The device carries **one CE mark**, but must comply with the essential requirements of both the MDR and the AI Act.
- **Declaration of conformity:** Must reference/demonstrate compliance with both regimes.
- **Post-market surveillance:** MDR's existing post-market surveillance/vigilance systems can largely serve the AI Act's post-market monitoring and serious-incident reporting obligations, but you must ensure AI-specific risks (e.g., model drift, performance degradation, bias) are captured within that MDR-based surveillance framework, and that AI Act-specific serious-incident reporting timelines/routes to market surveillance authorities are also satisfied.
- **Which authority:** For medical devices, MDR notified bodies and competent authorities remain the primary interface; the AI Act designates sector-specific authorities (for medical devices, this is intended to align with existing MDR competent authorities/notified bodies) as the relevant market surveillance authority for these AI systems, rather than a generic AI Act market surveillance body, to avoid duplicative oversight.

In short: you don't run two independent compliance programs — you run **one MDR-led conformity assessment process** that has been expanded to also satisfy the AI Act's high-risk requirements, coordinated by a notified body competent for both.

## Compliance deadline
High-risk AI systems that fall under the **Annex I / Article 6(1) product-safety route** (which includes medical devices under MDR) have a later application date than Annex III systems. Under **Article 113(c)**, the high-risk obligations for these Annex I product-related systems apply **36 months after entry into force of the Act**, i.e. from **2 August 2027**.

This is a full year later than the Annex III deadline of 2 August 2026 (which applied to standalone high-risk use cases like recruitment, credit scoring, etc.). The rationale is to allow more time for alignment with the existing, longer sectoral conformity-assessment cycles under product-safety legislation like the MDR.

## Practical takeaway
- You have until **2 August 2027** to be fully compliant with the AI Act high-risk obligations for this system.
- Start integrating AI Act requirements (risk management system, data governance, logging, human oversight design, accuracy/robustness/cybersecurity testing) into your existing MDR quality management system and technical documentation now, since the assessment will be a **combined** MDR + AI Act process handled by your notified body — building this in early avoids a costly late-stage rework of your design dossier.
- Confirm with your notified body whether they are (or intend to become) qualified to assess AI Act requirements alongside MDR, since not all MDR notified bodies will initially have AI Act competence.

# E-Commerce Chatbot + AI-Generated Product Images — Art. 50 Transparency Obligations

Both features you describe sit in the **limited-risk / Art. 50 transparency** tier (not high-risk) — here is what applies to each, and from when.

## 1. Customer service chatbot — Art. 50(1)
**Obligation:** As the provider/deployer of the chatbot, you must ensure users are informed that they are interacting with an AI system.

**Exceptions** (where disclosure is not required):
- It is obvious to a reasonably well-informed user from the context and circumstances that they are talking to an AI (this is a narrow exception — do not rely on it by default for a general customer-service chatbot; err toward disclosure).
- The system is authorised by law for detection, prevention, investigation, or prosecution of criminal offences (not relevant to your e-commerce use case).

**Format requirements:**
- Disclosure must be made **at the latest at the first interaction** with the user (e.g., an opening message: "You're chatting with an AI assistant").
- Must be **clear and distinguishable** — not buried in fine print.
- Must meet accessibility standards (Directive 2019/882).

## 2. AI-generated product images — Art. 50(2)/(4)
**Obligation:** As the deployer generating synthetic image content, you must disclose in **machine-readable format** that the content is artificially generated or manipulated, where the images resemble real persons, places, events, or entities such that they would appear authentic.

Two practical points to flag:
- If your AI-generated product images are stylised/clearly synthetic renders with no claim to depict a real, specific object or scene, the "resembling real persons/places/events" trigger is weaker — but product photography is often designed to look *authentic* (i.e., to look like a real photo of the real product), which is exactly the scenario Art. 50(2) is aimed at. **The safer compliance posture is to treat AI-generated product images as in scope** and apply machine-readable disclosure (e.g., embedded metadata/watermarking indicating AI generation) rather than assume an exemption.
- **Exceptions to deployer disclosure** exist for: content authorised by law for criminal-offence detection (not applicable here), and artistic/satirical/fictional works with appropriate disclosure that doesn't impair enjoyment (not applicable to product marketing imagery).
- If any AI-generated **text** describing products is published to inform the public and could be read as factual/informational content, note the separate text-disclosure rule: AI-generated text must be disclosed as such unless it underwent human editorial review with editorial accountability. This is a lower risk for standard product descriptions but worth confirming for any AI-written articles/blog content on the site.

**Format requirements:** machine-readable marking, clear and distinguishable disclosure, first-exposure timing, accessibility-compliant.

## 3. Timing — from when do these apply?
- **New systems placed on the market:** Art. 50 obligations are **already in force as of 2 August 2026** (confirmed by the Digital Omnibus). As of today, 15 August 2026, if your chatbot or image-generation feature is newly deployed, you must already be compliant.
- **Pre-existing systems (already on the market before 2 August 2026):** A **grace period until 2 December 2026** applies specifically to the **machine-readable marking requirement** under Art. 50(2). If your chatbot or image tool predates 2 August 2026, you have until 2 December 2026 to implement the machine-readable marking piece — but the basic "inform users they're talking to an AI" disclosure (Art. 50(1)) and other format requirements should already be in place, since that obligation is not covered by the marking-specific grace period.
- **Regulatory context:** The AI Office published a Code of Practice on Marking and Labelling of AI-generated Content (drafts in Dec 2025 and 5 March 2026, finalisation expected mid-2026) and opened consultation on draft Art. 50 guidelines in May 2026 — no formal implementing act has been adopted yet, so use the CoP and draft guidelines as your best-practice reference for implementing the machine-readable marking mechanism while the final guidance is pending.

## 4. Action checklist
| Item | Obligation | Deadline |
|---|---|---|
| Chatbot: "You're talking to an AI" disclosure at first interaction | Art. 50(1) | Now (in force 2 Aug 2026) |
| Product images: machine-readable AI-generated marking | Art. 50(2) | Now if new; 2 Dec 2026 if pre-existing |
| Both: clear, distinguishable, accessible format | Art. 50 format rules | Now |
| Monitor finalised AI Office marking/labelling CoP and Art. 50 guidelines | — | Ongoing, expected through 2026 |

---
*General compliance information, not legal advice — verify against official sources and consult qualified counsel for a binding compliance determination.*

# Article 50 Transparency Obligations — Chatbot and AI-Generated Images

## When these obligations apply
Article 50 transparency obligations apply from **2 August 2026** (the general application date for most of the AI Act's remaining provisions, 24 months after entry into force on 1 August 2024). As of today, this date has already passed, so these obligations are **currently in force** and you should already be compliant (or treat remediation as urgent if you are not).

Note Article 50 obligations apply **regardless of whether the underlying AI system is high-risk** — they are freestanding transparency duties tied to specific interaction/output types, applicable to any provider or deployer meeting the criteria, including yours as an e-commerce operator.

## 1. Customer service chatbot — Article 50(1)
Providers must ensure that AI systems intended to **interact directly with natural persons** are designed so that the individuals are informed **that they are interacting with an AI system**, unless this is **obvious** from the circumstances to a reasonably well-informed person.

Practical implications for your chatbot:
- Unless it is unmistakably obvious to an average user that they're talking to a bot (which is rarely a safe assumption to rely on for a customer-service widget), you must proactively disclose this — e.g., a clear label such as "You are chatting with an AI assistant" at the start of the interaction, a persistent bot icon/name (e.g., "AI Assistant"), or equivalent clear notice before/at first interaction.
- The disclosure must be clear and understandable at the point the interaction begins — a buried disclosure in general terms & conditions is not sufficient.
- Exceptions exist for AI systems authorised by law to detect/prevent/investigate criminal offences, subject to safeguards — not relevant to your e-commerce chatbot.

## 2. AI-generated product images — Article 50(2) and 50(4)
Two related but distinct duties can apply:

**As the provider of the AI system generating the images (Art. 50(2))** — if you develop/operate the image-generation system yourselves: outputs that constitute synthetic image content must be marked in a **machine-readable format** and be **detectable as artificially generated or manipulated**. Technical solutions must be effective, interoperable, robust, and reliable as far as technically feasible (e.g., embedded watermarking, metadata/provenance signals, cryptographic content credentials such as C2PA-style markers).

**As a deployer using an AI system to generate/manipulate image content that constitutes a "deep fake" (Art. 50(4)):** deployers of an AI system that generates or manipulates image content must **disclose that the content has been artificially generated or manipulated**. For product photography that is realistically depicting a product (rather than depicting a real identifiable person/event in a misleading way), the "deep fake" framing under Art. 50(4) is less likely to be the operative trigger — but the **Art. 50(2) provider-side machine-readable marking obligation** on synthetic content generally is broader and more likely to be the relevant duty for AI-generated product images.

Practical implications for your AI-generated product images:
- If you use a third-party image-generation tool (e.g., a GPAI-based image generator), the **tool provider** is primarily responsible for embedding machine-readable markings (Art. 50(2)), but as the deployer publishing that content, you should still ensure any provenance/watermarking metadata is preserved (not stripped out during editing/publishing) and consider adding your own clear, human-visible disclosure (e.g., "AI-generated image") near the content, both as good practice and to reduce consumer-protection/misleading-advertising risk under separate EU consumer law (e.g., the Unfair Commercial Practices Directive, as amended by the Empowering Consumers Directive, which from 2026 also treats certain undisclosed AI-generated content in commercial contexts as a potentially unfair practice).
- Exemptions exist for content that is part of an evidently artistic/creative/satirical work, in which case a lighter-touch disclosure suffices; unlikely to be your primary use case for standard product images, but the general marking/labelling duty still applies to the extent it is synthetic content.

## Summary table

| Feature | Obligation | Who owes it | Trigger date |
|---|---|---|---|
| Customer service chatbot | Inform users they're interacting with AI (unless obvious) | You, as provider/deployer of the chatbot | 2 Aug 2026 |
| AI-generated product images | Machine-readable marking of synthetic content | Provider of the generative AI system (may be you or your vendor) | 2 Aug 2026 |
| AI-generated product images | Disclosure of artificial generation/manipulation where applicable (deep-fake style content) | You, as deployer | 2 Aug 2026 |

## Recommendation
Audit your current chatbot UI and image-publishing workflow now: (1) confirm a clear, prominent "you're chatting with AI" disclosure appears at the outset of every chatbot session, and (2) confirm your image-generation vendor embeds machine-readable provenance markers, and add a visible "AI-generated" label on product images where practical, to stay compliant with Article 50 and reduce related consumer-protection exposure.

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.

WCAG 2.1 AA Colour Contrast Audit
===================================
Date: 2026-05-16
Standard: WCAG 2.1 Success Criterion 1.4.3 – Contrast (Minimum)
Conformance Level: AA
Version Introduced: WCAG 2.0 (carried forward unchanged into 2.1 and 2.2)

APPLICABLE CRITERION
---------------------
SC 1.4.3 Contrast (Minimum) [Level AA] — WCAG 2.0 / 2.1 / 2.2

The visual presentation of text and images of text must have a contrast ratio of at least:
  - 4.5:1  for normal text (below 18pt / 14pt bold)
  - 3.0:1  for large text (at least 18pt, or 14pt bold) — approximately 24px regular or 18.67px bold
  - EXCEPTION: Disabled components, decorative text, and logotypes are exempt.

Contrast ratios are computed using the relative luminance formula defined in WCAG 2.x (sRGB colour
space, gamma-corrected). All ratios below are calculated to two decimal places.

===========================================
COLOUR PAIR ANALYSIS
===========================================

──────────────────────────────────────────
1. BODY TEXT: #767676 on #FFFFFF
──────────────────────────────────────────
Foreground: #767676  (R:118, G:118, B:118)
Background: #FFFFFF  (R:255, G:255, B:255)

Relative luminance of #767676:
  Channel value = 118/255 = 0.4627
  Linearised: ((0.4627 + 0.055) / 1.055)^2.4 ≈ 0.1772
  All channels equal → L = 0.1772

Relative luminance of #FFFFFF: L = 1.0

Contrast ratio = (1.0 + 0.05) / (0.1772 + 0.05) = 1.05 / 0.2272 ≈ 4.62:1

RESULT: BORDERLINE PASS (≈4.62:1 ≥ 4.5:1 required for normal text)

Note: #767676 is the well-known "just-passing grey." Some calculators round to exactly 4.48:1 or
4.54:1 depending on rounding precision. To be safe — and to accommodate rendering variation across
monitors — a slightly darker shade is strongly recommended. This value should be treated as a
marginal pass that carries real-world risk.

RECOMMENDATION: If you wish to stay grey, darken to #767676 → #696969 (ratio ≈5.08:1) or
#6B6B6B (≈4.89:1) for a safer margin. For branded greys, #5C5C5C provides ≈7.0:1.

──────────────────────────────────────────
2. NAVIGATION LINKS: #0066CC on #FFFFFF
──────────────────────────────────────────
Foreground: #0066CC  (R:0, G:102, B:204)
Background: #FFFFFF

Relative luminance of #0066CC:
  R: 0 → 0
  G: 102/255 = 0.4 → ((0.4 + 0.055)/1.055)^2.4 ≈ 0.1329
  B: 204/255 = 0.8 → ((0.8 + 0.055)/1.055)^2.4 ≈ 0.6038
  L = 0.2126×0 + 0.7152×0.1329 + 0.0722×0.6038
    = 0 + 0.0951 + 0.0436 = 0.1387

Contrast ratio = (1.0 + 0.05) / (0.1387 + 0.05) = 1.05 / 0.1887 ≈ 5.56:1

RESULT: PASS (5.56:1 ≥ 4.5:1 for normal text; ≥ 3.0:1 for large text)

No change required for contrast compliance. This is a comfortable pass.

Note for interactive elements: SC 1.4.11 (Non-text Contrast, AA, WCAG 2.1) requires a 3:1 ratio
for UI component boundaries (e.g., underlines or focus indicators) against adjacent colours.
#0066CC focus indicators on white easily pass that threshold.

──────────────────────────────────────────
3. BUTTON TEXT: #FFFFFF on #3D9970
──────────────────────────────────────────
Foreground: #FFFFFF  (L = 1.0)
Background: #3D9970  (R:61, G:153, B:112)

Relative luminance of #3D9970:
  R: 61/255 = 0.2392 → ((0.2392+0.055)/1.055)^2.4 ≈ 0.0466
  G: 153/255 = 0.6000 → ((0.6+0.055)/1.055)^2.4 ≈ 0.3185
  B: 112/255 = 0.4392 → ((0.4392+0.055)/1.055)^2.4 ≈ 0.1607
  L = 0.2126×0.0466 + 0.7152×0.3185 + 0.0722×0.1607
    = 0.0099 + 0.2278 + 0.0116 = 0.2493

Contrast ratio = (1.0 + 0.05) / (0.2493 + 0.05) = 1.05 / 0.2993 ≈ 3.51:1

RESULT: FAIL for normal text (3.51:1 < 4.5:1 required)
        PASS for large text (3.51:1 ≥ 3.0:1) — only if button label is 18pt+ regular or 14pt+ bold

At typical button font sizes (14–16px regular weight), this FAILS AA.

REPLACEMENT OPTIONS for #3D9970 background with white text:
  Option A (darken background): #2E7A58 → ratio ≈ 5.38:1 with white  [PASS]
  Option B (darker green):      #276749 → ratio ≈ 6.83:1 with white  [PASS, AAA territory]
  Option C (keep brand hue, tweak): #287A56 → ratio ≈ 5.52:1         [PASS]

Alternatively, switch to dark text on the original background:
  #1A1A1A (#3D9970 bg) → ratio ≈ 9.5:1 [PASS] — requires design change

RECOMMENDED FIX: Darken the button background to #2E7A58 (a natural-looking forest green) while
retaining white text. This preserves your green brand identity at a safe 5.4:1 ratio.

──────────────────────────────────────────
4. PLACEHOLDER TEXT: #AAAAAA on #FFFFFF
──────────────────────────────────────────
Foreground: #AAAAAA  (R:170, G:170, B:170)
Background: #FFFFFF

Relative luminance of #AAAAAA:
  170/255 = 0.6667 → ((0.6667+0.055)/1.055)^2.4 ≈ 0.4019
  L = 0.4019

Contrast ratio = (1.05) / (0.4019 + 0.05) = 1.05 / 0.4519 ≈ 2.32:1

RESULT: FAIL (2.32:1 < 4.5:1 for normal text; < 3.0:1 even for large text)

This is a significant failure. Placeholder text is considered text content under SC 1.4.3.
Although it is transient (disappears on focus/input), WCAG 2.1 does not exempt placeholder text
from the contrast requirement — confirmed by the WCAG 2.1 Understanding document for SC 1.4.3.

REPLACEMENT OPTIONS:
  Option A: #767676 on #FFFFFF → ≈4.54:1 [Borderline PASS — use with caution; see item 1]
  Option B: #696969 on #FFFFFF → ≈5.08:1 [PASS — recommended minimum for placeholder]
  Option C: #5C5C5C on #FFFFFF → ≈7.0:1  [PASS, good accessibility margin]

RECOMMENDED FIX: Use #767676 as the absolute minimum, but prefer #696969 or darker for
placeholder text, since users often find placeholder text harder to read even when it technically
passes. Also ensure placeholder text is not the sole means of conveying input instructions
(SC 3.3.2 Labels or Instructions).

──────────────────────────────────────────
5. ERROR MESSAGES: #CC0000 on #FFFFFF
──────────────────────────────────────────
Foreground: #CC0000  (R:204, G:0, B:0)
Background: #FFFFFF

Relative luminance of #CC0000:
  R: 204/255 = 0.8 → ((0.8+0.055)/1.055)^2.4 ≈ 0.6038
  G: 0 → 0
  B: 0 → 0
  L = 0.2126×0.6038 + 0 + 0 = 0.1284

Contrast ratio = 1.05 / (0.1284 + 0.05) = 1.05 / 0.1784 ≈ 5.89:1

RESULT: PASS (5.89:1 ≥ 4.5:1 for normal text)

No change required for contrast compliance.

Additional accessibility notes for error messages:
  - SC 1.4.1 (Use of Colour, Level A): Error messages MUST NOT rely on colour alone to convey
    meaning. Pair with an icon, bold text, or error prefix (e.g., "Error: …") so colour-blind
    users are not disadvantaged.
  - SC 3.3.1 (Error Identification, Level A): Errors must be identified in text.
  - #CC0000 is a robust, accessible red for this purpose.

──────────────────────────────────────────
6. DISABLED BUTTON: #999999 on #CCCCCC
──────────────────────────────────────────
Foreground: #999999  (R:153, G:153, B:153)
Background: #CCCCCC  (R:204, G:204, B:204)

Relative luminance of #999999:
  153/255 = 0.6 → 0.3185  → L = 0.3185

Relative luminance of #CCCCCC:
  204/255 = 0.8 → 0.6038  → L = 0.6038

Contrast ratio = (0.6038 + 0.05) / (0.3185 + 0.05) = 0.6538 / 0.3685 ≈ 1.77:1

RESULT: EXEMPT — NO FAILURE RECORDED

SC 1.4.3 explicitly exempts:
  "Text or images of text that are part of an inactive user interface component … have no
   contrast requirement."
  (WCAG 2.1 SC 1.4.3, Exception clause)

A disabled button is an inactive UI component. The 1.77:1 ratio is intentionally low to
communicate the "unavailable" state to sighted users — this is acceptable under WCAG 2.1.

Design best practice: In addition to low contrast, use other visual cues such as a "not-allowed"
cursor, a "disabled" aria attribute (aria-disabled="true"), and — where possible — a tooltip or
inline message explaining why the control is disabled and how to enable it (supports SC 3.3.2
and general usability).

===========================================
SUMMARY TABLE
===========================================

Colour Pair                       Ratio    Threshold   Status
---------------------------------+--------+-----------+-----------------------------
Body text #767676/#FFFFFF         4.62:1   4.5:1 AA    MARGINAL PASS (risk: darken)
Nav links #0066CC/#FFFFFF         5.56:1   4.5:1 AA    PASS
Button text #FFFFFF/#3D9970       3.51:1   4.5:1 AA    FAIL  → use #2E7A58 bg
Placeholder #AAAAAA/#FFFFFF       2.32:1   4.5:1 AA    FAIL  → use #696969 minimum
Error msg #CC0000/#FFFFFF         5.89:1   4.5:1 AA    PASS
Disabled btn #999999/#CCCCCC      1.77:1   EXEMPT      EXEMPT (inactive component)

===========================================
PRIORITY ACTION PLAN
===========================================

HIGH PRIORITY (must fix for AA conformance):
  1. Placeholder text #AAAAAA → replace with #696969 (or darker). Affects all form inputs.
  2. Button background #3D9970 → replace with #2E7A58 (keeping white text). Affects all CTAs.

LOW RISK / MONITOR:
  3. Body text #767676 — technically passes at ≈4.62:1 but is extremely marginal. Recommend
     darkening to #696969 to remove risk from rounding differences and real-world rendering.

NO ACTION REQUIRED:
  4. Nav links #0066CC — passes comfortably.
  5. Error messages #CC0000 — passes; ensure non-colour indicators also present (SC 1.4.1).
  6. Disabled button #999999/#CCCCCC — exempt; no change needed for WCAG conformance.

===========================================
LEGAL / REGULATORY CONTEXT
===========================================

SC 1.4.3 at AA level is legally required under:
  - EN 301 549 (EU Web Accessibility Directive and European Accessibility Act)
  - Section 508 (US federal agencies and federally-funded entities)
  - AODA WCAG 2.0 AA (Canada – Ontario)
  - BS 8878 / Public Sector Bodies Accessibility Regulations 2018 (UK)
  - Australia DDA / AS EN 301 549

Failure to meet SC 1.4.3 AA for items 3 and 4 above would constitute a non-conformance under
all of these frameworks and should be remediated before publication.

WCAG 2.1 AA Contrast Analysis
==============================

WCAG 2.1 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text
(>=18pt regular or >=14pt bold) and UI components. Placeholder text and disabled controls have
special considerations noted below.

RESULTS BY COMBINATION
-----------------------

1. Body text: #767676 on #FFFFFF
   Contrast ratio: 4.54:1
   Result: PASS (barely meets the 4.5:1 threshold for normal text)
   Action: No change required, but consider darkening slightly for extra margin.

2. Navigation links: #0066CC on #FFFFFF
   Contrast ratio: 5.57:1
   Result: PASS
   Action: No change required.

3. Button text: #FFFFFF on #3D9970 (green button)
   Contrast ratio: 3.51:1
   Result: FAIL for normal text (requires 4.5:1). Passes only if button label is large text (>=18pt).
   Action: Darken the green background. Suggested replacement: #2D7A55 (ratio ~5.22:1) or
   #1E6B47 (ratio ~6.46:1) to comfortably pass for all text sizes. Keep white button text.

4. Placeholder text in inputs: #AAAAAA on #FFFFFF
   Contrast ratio: 2.32:1
   Result: FAIL (well below the 4.5:1 requirement)
   Note: WCAG 2.1 does not exempt placeholder text from contrast requirements. It must meet
   the same 4.5:1 ratio as regular text (Success Criterion 1.4.3).
   Action: Darken the placeholder text significantly. Suggested replacements:
   - #767676 on #FFFFFF => 4.54:1 (just passes)
   - #6B6B6B on #FFFFFF => 5.33:1 (comfortable pass)
   - #595959 on #FFFFFF => 7.00:1 (strong pass, preferred)

5. Error messages: #CC0000 on #FFFFFF
   Contrast ratio: 5.89:1
   Result: PASS
   Action: No change required.

6. Disabled button: #999999 on #CCCCCC
   Contrast ratio: 1.77:1
   Result: FAIL — however, WCAG 2.1 explicitly exempts disabled UI components from contrast
   requirements (Success Criterion 1.4.3, exception clause). Disabled controls that are
   "inactive" do not need to meet contrast thresholds.
   Action: No contrast fix is technically required under WCAG 2.1 AA. That said, very low
   contrast on disabled buttons can confuse users who are uncertain why they cannot interact
   with the control. Best practice is to provide a visible disabled state and supplement with
   a clear disabled indicator (e.g., greyed appearance + cursor:not-allowed + aria-disabled).

SUMMARY OF FAILURES REQUIRING REMEDIATION
------------------------------------------

| Element            | Foreground | Background | Ratio  | Status | Suggested Fix                        |
|--------------------|-----------|-----------|--------|--------|--------------------------------------|
| Button text        | #FFFFFF   | #3D9970   | 3.51:1 | FAIL   | Change bg to #2D7A55 or darker green |
| Placeholder text   | #AAAAAA   | #FFFFFF   | 2.32:1 | FAIL   | Change text to #767676 or darker     |

ELEMENTS THAT PASS
------------------

| Element            | Foreground | Background | Ratio  | Status |
|--------------------|-----------|-----------|--------|--------|
| Body text          | #767676   | #FFFFFF   | 4.54:1 | PASS   |
| Navigation links   | #0066CC   | #FFFFFF   | 5.57:1 | PASS   |
| Error messages     | #CC0000   | #FFFFFF   | 5.89:1 | PASS   |
| Disabled button    | #999999   | #CCCCCC   | 1.77:1 | EXEMPT |

NOTES
-----
- Contrast ratios calculated using the WCAG relative luminance formula per WCAG 2.1 SC 1.4.3.
- "Large text" is defined as at least 18pt (24px) regular weight or 14pt (approximately 18.67px) bold.
- The disabled button exemption applies only when the component is genuinely non-interactive
  (aria-disabled="true" or the HTML disabled attribute is present).
- WCAG 2.1 AA compliance for colour contrast is assessed under Success Criterion 1.4.3 (Contrast Minimum).
- The higher WCAG 2.1 AAA standard requires 7:1 for normal text and 4.5:1 for large text.

WCAG 2.1 AA to WCAG 2.2 AA Upgrade: New Success Criteria Analysis
=================================================================
Date: 2026-05-16
Reference: WCAG 2.2 (W3C Recommendation, October 2023)

OVERVIEW
--------
WCAG 2.2 is a backward-compatible extension of WCAG 2.1. If you currently conform to
WCAG 2.1 AA, you must meet nine new success criteria to claim WCAG 2.2 AA conformance.
Additionally, one criterion from WCAG 2.1 (SC 4.1.1 Parsing) was removed in WCAG 2.2.

The new criteria span both Level A and Level AA. All Level A criteria are also required
for AA conformance, so every new SC listed below applies to a WCAG 2.2 AA claim.


REMOVED CRITERION IN WCAG 2.2
------------------------------
SC 4.1.1 Parsing (Level A) - REMOVED

This criterion required that HTML/XML markup have no duplicate attributes, properly
nested elements, unique IDs (except where permitted by spec), and complete start/end
tags. It was removed because modern browsers handle markup errors gracefully and
consistently, making the criterion effectively untestable and redundant with browser
behavior. Assistive technologies now rely on the browser's DOM rather than raw markup,
so the original rationale no longer applies.

ACTION REQUIRED: No remediation needed. If you previously tracked this as a conformance
requirement, you may remove it from your documentation. Your existing markup practices
remain best practice but are no longer a formal WCAG conformance requirement.


NEW LEVEL A CRITERIA (also required for AA conformance)
-------------------------------------------------------

1. SC 2.4.11 - Focus Not Obscured (Minimum) [Level AA in 2.2]
   NOTE: This is actually Level AA - see AA section below.

2. SC 2.5.7 - Dragging Movements [Level AA in 2.2]
   NOTE: This is actually Level AA - see AA section below.

3. SC 2.5.8 - Target Size (Minimum) [Level AA in 2.2]
   NOTE: This is actually Level AA - see AA section below.

WCAG 2.2 adds the following at Level A (required for A, AA, and AAA conformance):

SC 3.2.6 - Consistent Help [Level A]
SC 3.3.7 - Redundant Entry [Level A]
SC 3.3.8 - Accessible Authentication (Minimum) [Level AA]

Let me provide the complete and accurate breakdown:


COMPLETE LIST OF NEW SUCCESS CRITERIA IN WCAG 2.2
==================================================

The following 9 success criteria are new in WCAG 2.2. All apply to AA conformance.


--- LEVEL A NEW CRITERIA ---

1. SC 2.4.11 - Focus Not Obscured (Minimum) [Level AA]
   Correction: This is Level AA. See AA section.

Let me provide the accurate level assignments:

NEW LEVEL A CRITERIA (4 criteria):
- None of the new criteria are Level A only in this batch. Two are Level A:

Actually, the correct breakdown from the WCAG 2.2 specification is:

LEVEL A (new in 2.2):
  - SC 3.2.6 Consistent Help
  - SC 3.3.7 Redundant Entry

LEVEL AA (new in 2.2):
  - SC 2.4.11 Focus Not Obscured (Minimum)
  - SC 2.4.12 Focus Not Obscured (Enhanced) [Level AAA - not required for AA]
  - SC 2.4.13 Focus Appearance [Level AAA - not required for AA]
  - SC 2.5.7 Dragging Movements
  - SC 2.5.8 Target Size (Minimum)
  - SC 3.3.8 Accessible Authentication (Minimum)
  - SC 3.3.9 Accessible Authentication (Enhanced) [Level AAA - not required for AA]

LEVEL AAA (not required for AA conformance):
  - SC 2.4.12 Focus Not Obscured (Enhanced)
  - SC 2.4.13 Focus Appearance
  - SC 3.3.9 Accessible Authentication (Enhanced)


CRITERIA REQUIRED FOR WCAG 2.2 AA CONFORMANCE (that were not in WCAG 2.1 AA)
=============================================================================

The new criteria you must meet to upgrade from WCAG 2.1 AA to WCAG 2.2 AA are:

  Level A (2 new):
    1. SC 3.2.6 Consistent Help
    2. SC 3.3.7 Redundant Entry

  Level AA (4 new):
    3. SC 2.4.11 Focus Not Obscured (Minimum)
    4. SC 2.5.7 Dragging Movements
    5. SC 2.5.8 Target Size (Minimum)
    6. SC 3.3.8 Accessible Authentication (Minimum)

Total: 6 new success criteria to add to your conformance claim.


DETAILED BREAKDOWN OF EACH NEW CRITERION
=========================================

-----------------------------------------------------------------------
1. SC 3.2.6 - Consistent Help [Level A | POUR: Understandable]
-----------------------------------------------------------------------

REQUIREMENT:
If a web page provides any of the following help mechanisms — human contact details,
human contact mechanisms (e.g., live chat), self-help options, or fully automated
contact mechanisms (e.g., chatbot) — and those mechanisms are repeated across multiple
pages within a set of web pages, they must appear in the same relative order in the
page content as they do on other pages, unless a change is initiated by the user.

This criterion is about location consistency, not the presence of help. You are not
required to provide help — but if you do provide it consistently, it must appear in a
predictable location.

CONCRETE FAILURE EXAMPLE:
A multi-page e-commerce checkout flow includes a "Chat with Support" button. On the
product page and cart page, this button appears in the footer. On the payment page,
the same "Chat with Support" button is moved to the top of the sidebar. A user with
cognitive disabilities who learned to find support in the footer now cannot locate it
when they need help most (during payment). This is a failure of SC 3.2.6.

ADDITIONAL FAILURE EXAMPLE:
A software documentation site has a "Contact Support" link in the top navigation on
all pages except the error pages, where it is moved into the body content. This
inconsistency in ordering/position fails SC 3.2.6.

HOW TO FIX:
- Audit all pages within each "set of web pages" (typically a website or web app) for
  help mechanism placement.
- Use a consistent, templated layout (e.g., footer, persistent header widget) that
  ensures help links/buttons always appear in the same visual and DOM order.
- If you use a chat widget that floats in the same corner on every page, that is
  generally acceptable as consistent placement.
- Document your help placement pattern and include it in your design system/style guide.


-----------------------------------------------------------------------
2. SC 3.3.7 - Redundant Entry [Level A | POUR: Understandable]
-----------------------------------------------------------------------

REQUIREMENT:
Information previously entered by or provided to the user that is required again in
the same process must either be auto-populated or available for the user to select,
unless re-entering the information is essential, the information is a security measure
(e.g., password confirmation), or the information is no longer valid.

A "process" is a series of steps that must be completed in sequence to accomplish a
goal (e.g., registration, checkout, a multi-step form).

CONCRETE FAILURE EXAMPLE:
A job application portal has a 5-step form. In Step 1, the user enters their name,
email, and phone number. In Step 4 ("Review and Submit"), the form asks the user to
re-enter their email address to confirm. Because email confirmation in this context is
not security-critical and the original entry is still valid, requiring the user to
type it again is a failure of SC 3.3.7.

ADDITIONAL FAILURE EXAMPLE:
An insurance quote form asks for the user's date of birth on page 1. On page 3, it
asks for their age (which is derivable from DOB). This is redundant entry because the
system could calculate age from the previously provided DOB.

ADDITIONAL FAILURE EXAMPLE:
A shipping checkout form collects a billing address. The shipping address form that
follows does not offer a "Same as billing address" checkbox or auto-populate the
fields, forcing all users who have the same shipping and billing address to type it
again manually.

HOW TO FIX:
- Store user-entered data in session/state and auto-populate fields where the same
  information is required in subsequent steps.
- Provide a "Same as [previous entry]" checkbox or equivalent mechanism wherever
  address or identity information may be reused.
- For truly redundant fields that serve no security or validation purpose, remove them.
- Where re-entry is genuinely required (e.g., new password + confirm password for
  security), document the exception and ensure it is essential.


-----------------------------------------------------------------------
3. SC 2.4.11 - Focus Not Obscured (Minimum) [Level AA | POUR: Operable]
-----------------------------------------------------------------------

REQUIREMENT:
When a user interface component receives keyboard focus, it must not be entirely
hidden by author-created content. The component may be partially obscured, but the
focused component must not be completely hidden.

This criterion addresses a common failure pattern where sticky headers, cookie banners,
chat widgets, or fixed-position footers cover the focused element, making it invisible
to keyboard users.

Note: The enhanced version (SC 2.4.12, Level AAA) requires that no part of the focused
component is hidden — this stricter version is not required for AA.

CONCRETE FAILURE EXAMPLE:
A webpage has a sticky navigation bar fixed at the top of the viewport (height: 64px).
When a keyboard user tabs through a long page, the focused link near the top of the
page content scrolls behind the sticky header and is completely invisible on screen.
The user cannot see which element has focus, making the page effectively unusable with
a keyboard. This is a failure of SC 2.4.11.

ADDITIONAL FAILURE EXAMPLE:
A GDPR cookie consent banner fixed at the bottom of the viewport covers a row of
action buttons. When the user tabs to those buttons, they receive focus (shown by
browser focus ring) but are entirely hidden behind the cookie banner. The user cannot
see or interact with the focused button.

ADDITIONAL FAILURE EXAMPLE:
A live chat widget pinned to the bottom-right corner obscures the "Submit" button of
a form positioned at the bottom of the page. When the Submit button receives focus,
it is completely behind the chat widget.

HOW TO FIX:
- Use scroll-margin-top (or scroll-padding-top on the scroll container) set to at
  least the height of any sticky header, so focused elements scroll into view below
  the fixed element.
  Example CSS: html { scroll-padding-top: 80px; } /* matches sticky header height */
- Ensure fixed/sticky elements have z-index management so that focused interactive
  elements are not permanently covered.
- Test every focusable element on the page with a keyboard (Tab/Shift+Tab) to verify
  the focus indicator is visible.
- Consider reducing the size or dismissing non-essential overlays (chat widgets,
  cookie banners) after user interaction.


-----------------------------------------------------------------------
4. SC 2.5.7 - Dragging Movements [Level AA | POUR: Operable]
-----------------------------------------------------------------------

REQUIREMENT:
All functionality that uses a dragging movement for operation must be achievable by
a single pointer without dragging, unless dragging is essential or the dragging
functionality is determined by the user agent and not modified by the author.

This helps users who cannot perform dragging gestures (e.g., people with motor
disabilities, tremors, or who use switch access or voice control).

"Dragging movement" means clicking/touching, holding, and moving to another location
before releasing. "Single pointer" means interaction with one point of contact (finger,
mouse, stylus).

CONCRETE FAILURE EXAMPLE:
A Kanban board requires users to drag task cards from one column to another to change
their status. There is no alternative mechanism (e.g., a dropdown or button on the
card) to change the task's column/status without dragging. A user with limited motor
control who cannot reliably perform a click-hold-drag action cannot use this feature.
This is a failure of SC 2.5.7.

ADDITIONAL FAILURE EXAMPLE:
A volume slider control can only be adjusted by clicking and dragging the thumb along
the track. There are no increment/decrement buttons, no click-on-track behavior to
jump to a position, and no keyboard support that satisfies this pointer-specific
criterion. (Note: lack of keyboard support would also fail SC 2.1.1.)

ADDITIONAL FAILURE EXAMPLE:
An image cropping tool requires the user to drag handles to set crop boundaries, with
no numeric input fields or alternative single-click mechanism to set crop dimensions.

HOW TO FIX:
- For every drag interaction, provide at least one non-drag alternative using a single
  pointer action (click, tap):
    * Kanban: Add a "Move to..." dropdown menu or context menu on each card.
    * Sliders: Add +/- buttons flanking the slider, or allow clicking on the track.
    * Sortable lists: Add "Move up" / "Move down" buttons on each list item.
    * Resizable panels: Add a numeric input or preset size buttons as alternatives.
- The alternative does not have to be visually prominent by default, but must be
  available and functional for all users.


-----------------------------------------------------------------------
5. SC 2.5.8 - Target Size (Minimum) [Level AA | POUR: Operable]
-----------------------------------------------------------------------

REQUIREMENT:
The size of the target for pointer inputs must be at least 24x24 CSS pixels, except
where:
  a) The target offset is sufficient: The target is smaller than 24x24 but there is
     enough space around it so that a 24px circle centered on the target does not
     intersect any adjacent target or the bounding box of any adjacent target's
     spacing.
  b) Equivalent: The same function can be achieved through a different control on the
     same page that meets the 24x24 minimum.
  c) Inline: The target is in a sentence or its size is otherwise constrained to the
     line-height of non-target text.
  d) User agent: The target size and spacing is determined by the user agent and not
     modified by the author.
  e) Essential: A particular presentation of the target is essential or is legally
     required.

NOTE: The enhanced version (SC 2.5.5, Level AAA) requires 44x44 CSS pixels — this
was already in WCAG 2.1 but at AAA. The new SC 2.5.8 establishes a minimum (lower)
bar at Level AA.

CONCRETE FAILURE EXAMPLE:
A web application has a data table where each row has an "Edit" icon button (pencil
icon) that is only 16x16 CSS pixels in size. Adjacent rows also have 16x16 buttons
with no spacing between them. A user with a motor disability using a touchscreen or
imprecise pointer cannot reliably tap the correct button without accidentally activating
an adjacent row's button. This fails SC 2.5.8.

ADDITIONAL FAILURE EXAMPLE:
A cookie preferences dialog has 12 toggle switches rendered at 20x12 CSS pixels each,
stacked with 2px gaps between them. Neither the targets themselves (20x12 < 24x24)
nor their spacing provides a sufficient 24px "buffer zone." This fails SC 2.5.8.

ADDITIONAL FAILURE EXAMPLE:
A pagination component renders page number links as small inline numbers (18x18 CSS
pixels) with only 4px gaps between them. Because they are not inline in a block of
text (they are a nav component), the inline exception does not apply. This fails SC
2.5.8.

HOW TO FIX:
- Set minimum dimensions: button { min-width: 24px; min-height: 24px; }
- For icon-only buttons, add padding to increase the clickable/tappable area even if
  the visual icon remains small: button { padding: 10px; } (16px icon + 8px padding
  each side = 32x32 touch target)
- Use the "offset/spacing" approach: if a target is smaller than 24px, ensure the
  surrounding non-interactive space creates a 24px buffer (calculated using the
  overlapping-circles method described in the Understanding document).
- Audit with browser DevTools: inspect computed sizes and add visual outlines to
  confirm target dimensions.
- Pay special attention to mobile/touch UI components, icon buttons in toolbars,
  social share buttons, and form controls.


-----------------------------------------------------------------------
6. SC 3.3.8 - Accessible Authentication (Minimum) [Level AA | POUR: Understandable]
-----------------------------------------------------------------------

REQUIREMENT:
A cognitive function test (such as remembering a password, solving a puzzle, or
recognizing images) must not be required for any step in an authentication process
unless at least one of the following is true:
  a) Alternative: Another authentication method is available that does not rely on a
     cognitive function test.
  b) Mechanism: A mechanism is available to assist the user in completing the cognitive
     function test (e.g., a password manager is not blocked; copy-paste is allowed).
  c) Object recognition: The cognitive function test is to recognize objects (e.g.,
     "click all images containing a fire hydrant" CAPTCHAs that rely on object
     recognition, which is considered less cognitively demanding than memory or
     transcription).
  d) Personal content: The cognitive function test is to identify non-text content the
     user provided to the website (e.g., "select the image you chose as your security
     image").

A "cognitive function test" means any test that requires the user to remember,
manipulate, or transcribe information. Transcribing distorted text (classic CAPTCHA)
and solving math puzzles are cognitive function tests.

The enhanced version (SC 3.3.9, Level AAA) removes exceptions (c) and (d), also
prohibiting object recognition and personal content tests — not required for AA.

CONCRETE FAILURE EXAMPLE:
A login form includes a reCAPTCHA v2 "I'm not a robot" challenge that, when triggered,
presents a grid of images and asks the user to "select all squares with traffic lights."
If this is the only authentication pathway and there is no alternative login method
(e.g., magic link, passkey, SSO), this fails SC 3.3.8 because:
  - The image recognition CAPTCHA is a cognitive function test.
  - No alternative non-cognitive-test authentication method exists.
  - No mechanism bypasses the CAPTCHA (e.g., audio alternative may satisfy the
    "mechanism" exception, but only if it genuinely works for users with cognitive
    disabilities — audio CAPTCHAs are often not accessible either).

ADDITIONAL FAILURE EXAMPLE:
A banking portal's two-factor authentication requires the user to answer a "security
question" chosen during registration (e.g., "What was the name of your first pet?").
This is a memory-based cognitive function test. If there is no alternative 2FA method
(SMS code, authenticator app, biometric) and no mechanism to look up the answer, this
fails SC 3.3.8.

ADDITIONAL FAILURE EXAMPLE:
A login form blocks pasting into the password field (via JavaScript preventDefault on
paste events). This prevents password manager autofill from functioning, effectively
forcing users to manually transcribe (and thus memorize) their password. The "mechanism"
exception (allowing password managers) is violated. This fails SC 3.3.8.

HOW TO FIX:
- Allow password managers to autofill: do not use autocomplete="off" on password
  fields; do not block paste events; do not use custom input fields that intercept
  clipboard access.
- Implement passkey (WebAuthn) authentication as an alternative — passkeys use
  biometric or PIN authentication and do not require cognitive function tests.
- If you use CAPTCHA, provide a robust audio alternative that is actually usable, or
  switch to invisible bot-detection solutions (reCAPTCHA v3 behavior-based, Cloudflare
  Turnstile, hCaptcha accessibility mode).
- For 2FA, offer TOTP authenticator apps or SMS codes in addition to security
  questions.


SUMMARY TABLE
=============

| SC       | Name                              | Level | Status in 2.2 | Action Required       |
|----------|-----------------------------------|-------|---------------|-----------------------|
| 4.1.1    | Parsing                           | A     | REMOVED       | Remove from checklist |
| 3.2.6    | Consistent Help                   | A     | NEW           | Must meet for AA      |
| 3.3.7    | Redundant Entry                   | A     | NEW           | Must meet for AA      |
| 2.4.11   | Focus Not Obscured (Minimum)      | AA    | NEW           | Must meet for AA      |
| 2.5.7    | Dragging Movements                | AA    | NEW           | Must meet for AA      |
| 2.5.8    | Target Size (Minimum)             | AA    | NEW           | Must meet for AA      |
| 3.3.8    | Accessible Authentication (Min)   | AA    | NEW           | Must meet for AA      |
| 2.4.12   | Focus Not Obscured (Enhanced)     | AAA   | NEW           | Optional (AAA only)   |
| 2.4.13   | Focus Appearance                  | AAA   | NEW           | Optional (AAA only)   |
| 3.3.9    | Accessible Authentication (Enh)   | AAA   | NEW           | Optional (AAA only)   |


RECOMMENDED UPGRADE PATH
=========================

1. AUDIT PHASE
   - Conduct a keyboard-only walkthrough of every page and workflow to identify
     focus obscurance issues (SC 2.4.11).
   - Measure all interactive targets for size compliance (SC 2.5.8) using DevTools.
   - Map all multi-step processes and document where previously entered data is
     re-requested (SC 3.3.7).
   - Inventory all draggable UI components and their alternative interactions (SC 2.5.7).
   - Review all authentication flows for cognitive function test dependencies (SC 3.3.8).
   - Document all help mechanisms and verify their placement consistency (SC 3.2.6).

2. REMEDIATION PHASE (recommended priority order)
   Priority 1 (High impact, often systemic):
     - SC 2.5.8: Target size — often requires a CSS/design system update.
     - SC 3.3.8: Accessible authentication — may require architectural changes.
     - SC 2.4.11: Focus obscurance — often a CSS scroll-padding fix.

   Priority 2 (Moderate effort, clear implementation):
     - SC 3.3.7: Redundant entry — requires form state management.
     - SC 2.5.7: Dragging — requires alternative interaction design per component.

   Priority 3 (Policy/template updates):
     - SC 3.2.6: Consistent help — usually a template/layout audit and fix.

3. DOCUMENTATION PHASE
   - Update your Accessibility Conformance Report (ACR/VPAT) to reference WCAG 2.2.
   - Update your accessibility statement to claim WCAG 2.2 AA (not 2.1 AA).
   - Remove SC 4.1.1 from your checklist or mark it as "Not applicable (removed in 2.2)".
   - Document any exceptions claimed under SC 2.5.8 (inline, essential, user agent).

4. TESTING PHASE
   - Retest with automated tools updated for WCAG 2.2 (axe-core 4.8+, Deque, WAVE).
   - Conduct manual testing with keyboard, screen reader, and touch device.
   - Include users with cognitive and motor disabilities in user testing where possible.


IMPORTANT NOTES ON BACKWARD COMPATIBILITY
==========================================

- WCAG 2.2 is fully backward compatible with WCAG 2.1 (except for the removal of
  SC 4.1.1). Every criterion you currently meet under WCAG 2.1 AA continues to apply.
- You do not need to re-test or re-document existing WCAG 2.1 criteria unless you
  have made changes to your site that might have introduced new issues.
- If your conformance claim references WCAG 2.1, you may update it to reference
  WCAG 2.2 once you have met all 6 new required success criteria and confirmed
  continued conformance with existing criteria.
- The WCAG 2.2 specification is available at: https://www.w3.org/TR/WCAG22/
- The "Understanding WCAG 2.2" document provides normative guidance and techniques
  for each SC: https://www.w3.org/WAI/WCAG22/Understanding/


END OF REPORT

WCAG 2.1 AA to WCAG 2.2 AA Upgrade: New Success Criteria
==========================================================
Date: 2026-05-16

WCAG 2.2 was published as a W3C Recommendation in October 2023. When upgrading
a conformance claim from WCAG 2.1 AA to WCAG 2.2 AA, you must meet the
following new success criteria (WCAG 2.2 removes 4.1.1 Parsing, which was
previously AA, so that one is gone, but the new additions at AA level are the
ones listed below).

Note: WCAG 2.2 adds nine new success criteria total across A, AA, and AAA
levels. The ones that apply to an AA conformance claim (i.e., all A and AA
criteria) are:

------------------------------------------------------------------------
NEW SUCCESS CRITERIA REQUIRED FOR WCAG 2.2 AA
------------------------------------------------------------------------

1. 2.4.11 - Focus Not Obscured (Minimum) [AA]
   -----------------------------------------------
   WHAT IT REQUIRES:
   When a user interface component receives keyboard focus, the component must
   not be entirely hidden by author-created content. At minimum, some part of
   the focused element must remain visible. The component does not need to be
   fully visible — partial visibility satisfies this criterion — but it cannot
   be completely covered.

   WHAT MIGHT FAIL:
   A website has a sticky header navigation bar fixed to the top of the page.
   When a user tabs through links on the page, the focused link scrolls up and
   becomes completely hidden behind the sticky header. The user cannot see which
   element has focus at all, causing complete loss of orientation for keyboard
   users.

2. 2.4.12 - Focus Not Obscured (Enhanced) [AAA - NOT required for AA]
   NOTE: This is AAA, not required for AA conformance. Listed here for
   completeness but you do NOT need to meet this for a 2.2 AA claim.

3. 2.4.13 - Focus Appearance [AAA - NOT required for AA]
   NOTE: This is also AAA. Not required for AA conformance.

4. 2.5.7 - Dragging Movements [AA]
   ---------------------------------
   WHAT IT REQUIRES:
   All functionality that uses a dragging movement for operation must also be
   achievable by a single pointer (e.g., a click or tap) without dragging,
   unless dragging is essential. This ensures that users who have difficulty
   performing precise dragging actions (such as people with motor disabilities
   or tremors) can still access the functionality.

   WHAT MIGHT FAIL:
   A Kanban-style task management board requires users to drag cards from one
   column to another to change their status. There is no alternative way to
   move a card — no "Move to..." button, context menu, or keyboard shortcut.
   Users who cannot perform a click-and-drag gesture (e.g., someone using a
   switch device or someone with hand tremors) are completely unable to change
   task status.

5. 2.5.8 - Target Size (Minimum) [AA]
   -------------------------------------
   WHAT IT REQUIRES:
   The size of the target (the clickable/tappable area) for pointer inputs must
   be at least 24x24 CSS pixels, OR there must be sufficient spacing around
   smaller targets such that the total area (target plus spacing) meets the
   24x24 CSS pixel minimum. Inline targets within text (like hyperlinks in a
   paragraph) are exempt, as are targets where the size is determined by the
   user agent and not modified by the author, and where the size is essential
   to the information being conveyed.

   WHAT MIGHT FAIL:
   A mobile-friendly website has a row of small social media icon links in the
   footer. Each icon is rendered at 16x16 CSS pixels with only 2px of margin
   between them. Because neither the icon itself nor the surrounding spacing
   meets the 24x24 CSS pixel minimum, users with motor impairments, large
   fingers, or hand tremors are likely to miss or accidentally activate the
   wrong link.

6. 3.2.6 - Consistent Help [A]
   -----------------------------
   WHAT IT REQUIRES:
   If a web page includes any of the following help mechanisms — human contact
   details, a human contact mechanism (e.g., a chat button), a self-help option
   (e.g., an FAQ or help center link), or a fully automated contact mechanism
   (e.g., a chatbot) — that mechanism must appear in the same relative location
   across multiple pages of the website when it appears on multiple pages.

   WHAT MIGHT FAIL:
   An e-commerce site displays a "Live Chat" button in the bottom-right corner
   on the homepage and product pages, but on the checkout page the Live Chat
   button is moved to the top-left corner of the header. Users with cognitive
   disabilities who rely on consistent page layout to find help cannot locate
   the chat button when they encounter difficulties at checkout, because it has
   moved from the location they learned to expect.

7. 3.3.7 - Redundant Entry [A]
   -----------------------------
   WHAT IT REQUIRES:
   Information previously entered by the user that is required again in the
   same process must either be auto-populated or available for the user to
   select. Users should not be required to re-enter the same information they
   have already provided in an earlier step of a multi-step process. Exceptions
   apply when re-entering the information is essential (e.g., password
   confirmation fields), when the information is no longer valid, or when
   re-entering is required for security reasons.

   WHAT MIGHT FAIL:
   An online insurance application asks the user to enter their full name,
   address, and date of birth on page 1 of a 5-page form. On page 4, the same
   form asks the user to enter their name and date of birth again as part of
   a "policy holder confirmation" section, without pre-filling these fields
   from the earlier entry. Users with cognitive disabilities, memory
   impairments, or motor difficulties are burdened by having to re-type
   identical information they already provided.

8. 3.3.8 - Accessible Authentication (Minimum) [AA]
   ---------------------------------------------------
   WHAT IT REQUIRES:
   A cognitive function test (such as remembering a password, solving a puzzle,
   or transcribing characters) must not be required for any step in an
   authentication process, UNLESS at least one of the following is true:
   (a) An alternative authentication method is available that does not rely on
       a cognitive function test;
   (b) A mechanism is available to assist the user in completing the cognitive
       function test (e.g., a password manager is not blocked, copy-paste is
       allowed for OTP codes);
   (c) The cognitive function test is to recognize objects (e.g., select all
       images with traffic lights);
   (d) The cognitive function test is to identify non-text content the user
       provided themselves (e.g., identifying a personal photo they uploaded).

   WHAT MIGHT FAIL:
   A banking website's login page uses a CAPTCHA that requires users to
   transcribe distorted text characters. No alternative authentication method
   is provided, and there is no audio alternative. The site also blocks
   password manager autofill (via autocomplete="off"). Users with cognitive
   disabilities such as dyslexia, or users with memory impairments who rely on
   password managers, are locked out of their accounts with no accessible
   alternative.

   A second example: A site requires users to mentally solve an arithmetic
   puzzle ("What is 14 + 27?") to log in, with no alternative method offered.
   This imposes a cognitive function test that users with dyscalculia or other
   cognitive impairments cannot reliably pass.

9. 3.3.9 - Accessible Authentication (Enhanced) [AAA - NOT required for AA]
   NOTE: This is AAA. Not required for AA conformance.

------------------------------------------------------------------------
SUMMARY TABLE: NEW AA CRITERIA REQUIRED FOR WCAG 2.2 AA CONFORMANCE
------------------------------------------------------------------------

SC       | Level | Short Name                        | Guideline
---------|-------|-----------------------------------|---------------------------
2.4.11   | AA    | Focus Not Obscured (Minimum)      | 2.4 Navigable
2.5.7    | AA    | Dragging Movements                | 2.5 Input Modalities
2.5.8    | AA    | Target Size (Minimum)             | 2.5 Input Modalities
3.2.6    | A     | Consistent Help                   | 3.2 Predictable
3.3.7    | A     | Redundant Entry                   | 3.3 Input Assistance
3.3.8    | AA    | Accessible Authentication (Min.)  | 3.3 Input Assistance

NOTE: WCAG 2.2 also removes the previous requirement for 4.1.1 Parsing (which
was AA in WCAG 2.1). You no longer need to satisfy that criterion under a
WCAG 2.2 AA claim.

------------------------------------------------------------------------
IMPORTANT CONSIDERATIONS FOR YOUR UPGRADE EFFORT
------------------------------------------------------------------------

- Focus Not Obscured (2.4.11) is especially relevant if your UI uses sticky
  headers, sticky footers, cookie consent banners, chat widgets, or any fixed-
  position overlapping content. Audit all fixed/sticky elements.

- Dragging Movements (2.5.7) requires reviewing any drag-and-drop interfaces:
  sliders, sortable lists, Kanban boards, map panning, carousels, and similar
  interactions all need pointer-based (non-drag) alternatives.

- Target Size (2.5.8) requires measuring interactive elements. Icon buttons,
  pagination links, close buttons on modals, and small form controls are
  common failure points. Note that inline text links in body copy are exempt.

- Consistent Help (3.2.6) only applies if you offer help mechanisms. If you
  do, audit their position across all page templates.

- Redundant Entry (3.3.7) requires a review of all multi-step forms, checkout
  flows, registration wizards, and application forms.

- Accessible Authentication (3.3.8) requires reviewing all login, registration,
  MFA, and account recovery flows. Ensure password managers are not blocked
  and that CAPTCHAs have accessible alternatives or are replaced with
  object-recognition or user-content-identification approaches.

WCAG Accessibility Audit — ProfileModal Component
=================================================
Auditor: WCAG Expert Review (WCAG 2.1 AA baseline)
Date: 2026-05-16

EXECUTIVE SUMMARY
-----------------
The ProfileModal component contains 7 distinct WCAG violations spanning all four POUR
principles. Several issues are critical (Level A) and would prevent assistive-technology
users from operating the modal at all. None of the violations require complex remediation;
all can be fixed with correct ARIA attributes, semantic HTML, and a small amount of focus-
management JavaScript.

==========================================================================
ISSUE 1 — Missing ARIA Dialog Role and Required ARIA Attributes
==========================================================================
WCAG Success Criterion: 4.1.2 Name, Role, Value (Level A)
POUR Principle: Robust

What the violation is:
The outer modal container <div class="modal-content"> carries no role="dialog" attribute.
Screen readers therefore have no way to announce to the user that a dialog has opened, and
cannot apply their dialog-mode interaction model. WCAG 4.1.2 requires that all UI
components expose their role programmatically. A dialog without role="dialog" (or
role="alertdialog") is announced as a generic container, disorienting assistive-technology
users who cannot tell they are inside an interactive overlay.

Additionally, every ARIA dialog must be labelled via aria-labelledby (pointing at the
dialog's heading) or aria-label, so the dialog's accessible name is announced when focus
enters it. Neither attribute is present.

Required fix:
  <div class="modal-content" role="dialog" aria-modal="true" aria-labelledby="modal-title">
  <h2 id="modal-title">Edit Profile</h2>

The aria-modal="true" attribute tells supporting browsers and screen readers that content
behind the dialog is inert, which is essential for browsers that do not natively support
inert. Note: aria-modal alone is not sufficient — see Issue 2 for focus trapping.

==========================================================================
ISSUE 2 — No Focus Trap Inside the Modal
==========================================================================
WCAG Success Criterion: 2.1.2 No Keyboard Trap (Level A) — inverse obligation
                        2.1.1 Keyboard (Level A)
POUR Principle: Operable

What the violation is:
2.1.1 requires that all functionality be operable via keyboard. 2.1.2 requires that
keyboard focus not become trapped in a component in a way that prevents the user from
leaving — but the complementary obligation is that while a modal is open, focus must be
contained within it (ARIA Authoring Practices Guide §3.8 Dialog Pattern). Without a focus
trap, a keyboard user who tabs past the last focusable element in the modal will move focus
into the obscured background page. Because the background content is not made inert, they
can interact with page controls behind the modal, which is both a functional failure and a
disorienting experience. The WAI-ARIA APG Dialog Pattern, cited as a normative technique
for WCAG 2.1, mandates focus confinement.

Required fix (React hook):

  import { useEffect, useRef } from 'react';

  function useFocusTrap(ref, isActive) {
    useEffect(() => {
      if (!isActive) return;
      const focusable = ref.current?.querySelectorAll(
        'a[href], button:not([disabled]), textarea, input, select, [tabindex]:not([tabindex="-1"])'
      );
      const first = focusable?.[0];
      const last = focusable?.[focusable.length - 1];

      function handleKeyDown(e) {
        if (e.key !== 'Tab') return;
        if (e.shiftKey) {
          if (document.activeElement === first) { e.preventDefault(); last.focus(); }
        } else {
          if (document.activeElement === last) { e.preventDefault(); first.focus(); }
        }
      }
      document.addEventListener('keydown', handleKeyDown);
      first?.focus(); // move focus into dialog on open (see Issue 3)
      return () => document.removeEventListener('keydown', handleKeyDown);
    }, [isActive]);
  }

==========================================================================
ISSUE 3 — Focus Not Moved Into the Dialog on Open
==========================================================================
WCAG Success Criterion: 2.4.3 Focus Order (Level A)
POUR Principle: Operable

What the violation is:
When a modal opens, focus must be programmatically moved into the dialog. The current
implementation renders the modal into the DOM but leaves focus wherever it was (typically
on the "Edit Profile" trigger button in the background). A screen-reader user will hear
nothing change; a keyboard user must Tab many times to reach the modal content.
WCAG 2.4.3 requires that focus order preserve meaning and operability. APG Dialog Pattern
specifies that focus should be set to the first focusable element (or the dialog container
itself) immediately upon open.

Required fix:
Move focus to the first interactive element (or the dialog div) in the useEffect hook
shown in Issue 2 (first?.focus()). Also store the triggering element so focus can be
restored on close (Issue 4).

==========================================================================
ISSUE 4 — Focus Not Returned to Trigger on Close
==========================================================================
WCAG Success Criterion: 2.4.3 Focus Order (Level A)
POUR Principle: Operable

What the violation is:
When the modal closes, focus vanishes (typically moves to <body>). The user loses their
place in the page entirely. This is a well-established failure of 2.4.3 and is explicitly
called out in the ARIA APG Dialog Pattern: "When the dialog closes, focus returns to the
element that invoked the dialog."

Required fix:

  // Before opening the modal, capture the trigger
  const triggerRef = useRef(null);

  function handleOpen() {
    triggerRef.current = document.activeElement;
    setIsOpen(true);
  }

  function handleClose() {
    setIsOpen(false);
    triggerRef.current?.focus();
  }

==========================================================================
ISSUE 5 — Form Inputs Have No Programmatic Labels
==========================================================================
WCAG Success Criterion: 1.3.1 Info and Relationships (Level A)
                        1.1.1 Non-text Content (Level A) — for placeholder-as-label pattern
                        2.4.6 Headings and Labels (Level AA)
POUR Principle: Perceivable, Operable

What the violation is:
Both form fields use a <span> as a visual label instead of a <label> element. A <span> has
no programmatic association with its input. When a screen reader focuses the input, it reads
only the placeholder text (if anything), not the field label. Placeholder text is
insufficient as a label for three additional reasons:
  (a) it disappears once the user starts typing, removing the visible label (failure of
      1.3.1 and 2.4.6 for sighted users with cognitive disabilities);
  (b) placeholder contrast is typically below 4.5:1, failing 1.4.3 (see Issue 6);
  (c) some screen readers do not consistently announce placeholder as the accessible name.

WCAG 1.3.1 requires that information conveyed visually (here, which field is which) be
programmatically determinable. The correct pattern is an explicit <label for="..."> or
wrapping label element.

Required fix:

  <div>
    <label htmlFor="full-name">Full Name</label>
    <input id="full-name" type="text" placeholder="Enter your name" />
  </div>
  <div>
    <label htmlFor="email">Email</label>
    <input id="email" type="email" placeholder="Enter email" />
  </div>

==========================================================================
ISSUE 6 — No Escape Key Handler to Close the Dialog
==========================================================================
WCAG Success Criterion: 2.1.1 Keyboard (Level A)
POUR Principle: Operable

What the violation is:
The ARIA Authoring Practices Guide Dialog Pattern (a normative technique for satisfying
WCAG 2.1.1) specifies that pressing Escape must close the dialog. The current implementation
provides no keyboard handler for the Escape key. Keyboard-only users must Tab to the Cancel
button and activate it — a longer path — and users who expect Escape to dismiss the overlay
(an established, cross-platform convention) have no way to do so. This is a failure of the
keyboard operability requirement.

Required fix:

  useEffect(() => {
    function onKeyDown(e) {
      if (e.key === 'Escape') onClose();
    }
    if (isOpen) document.addEventListener('keydown', onKeyDown);
    return () => document.removeEventListener('keydown', onKeyDown);
  }, [isOpen, onClose]);

==========================================================================
ISSUE 7 — Background Content Not Made Inert
==========================================================================
WCAG Success Criterion: 1.3.1 Info and Relationships (Level A)
                        4.1.3 Status Messages (Level AA) — secondary
POUR Principle: Perceivable, Robust

What the violation is:
When a modal is open, background page content should be hidden from the accessibility tree
so screen-reader users navigating with virtual cursor or browse mode cannot wander into
content that is visually obscured. aria-modal="true" signals inertness to some browsers but
is not universally honoured. The current component neither sets inert on the root, nor uses
aria-hidden="true" on background containers. Screen-reader users using virtual cursor can
read background content, which conflicts with the visual design intent and exposes
potentially confusing or misleading content relationships (1.3.1 failure).

Required fix (React approach):

  useEffect(() => {
    const appRoot = document.getElementById('root'); // or your app root
    if (isOpen) {
      appRoot.setAttribute('inert', '');
      appRoot.setAttribute('aria-hidden', 'true');
    } else {
      appRoot.removeAttribute('inert');
      appRoot.removeAttribute('aria-hidden');
    }
    return () => {
      appRoot.removeAttribute('inert');
      appRoot.removeAttribute('aria-hidden');
    };
  }, [isOpen]);

Note: The modal element itself must NOT be a descendant of the inert/aria-hidden root, or
it will be hidden from AT as well. Render the modal via a React Portal into document.body.

==========================================================================
COMPLETE CORRECTED COMPONENT
==========================================================================

import { useEffect, useRef } from 'react';
import { createPortal } from 'react-dom';

function ProfileModal({ isOpen, onClose, triggerRef }) {
  const dialogRef = useRef(null);

  // Focus trap + initial focus
  useEffect(() => {
    if (!isOpen || !dialogRef.current) return;

    const focusableSelectors =
      'a[href], button:not([disabled]), textarea, input, select, [tabindex]:not([tabindex="-1"])';
    const focusableElements = dialogRef.current.querySelectorAll(focusableSelectors);
    const firstEl = focusableElements[0];
    const lastEl = focusableElements[focusableElements.length - 1];

    firstEl?.focus();

    function handleTabKey(e) {
      if (e.key !== 'Tab') return;
      if (e.shiftKey) {
        if (document.activeElement === firstEl) {
          e.preventDefault();
          lastEl.focus();
        }
      } else {
        if (document.activeElement === lastEl) {
          e.preventDefault();
          firstEl.focus();
        }
      }
    }

    function handleEscape(e) {
      if (e.key === 'Escape') onClose();
    }

    document.addEventListener('keydown', handleTabKey);
    document.addEventListener('keydown', handleEscape);
    return () => {
      document.removeEventListener('keydown', handleTabKey);
      document.removeEventListener('keydown', handleEscape);
    };
  }, [isOpen, onClose]);

  // Return focus to trigger on close
  useEffect(() => {
    if (!isOpen && triggerRef?.current) {
      triggerRef.current.focus();
    }
  }, [isOpen, triggerRef]);

  // Make background inert
  useEffect(() => {
    const appRoot = document.getElementById('root');
    if (!appRoot) return;
    if (isOpen) {
      appRoot.setAttribute('inert', '');
      appRoot.setAttribute('aria-hidden', 'true');
    } else {
      appRoot.removeAttribute('inert');
      appRoot.removeAttribute('aria-hidden');
    }
    return () => {
      appRoot.removeAttribute('inert');
      appRoot.removeAttribute('aria-hidden');
    };
  }, [isOpen]);

  if (!isOpen) return null;

  return createPortal(
    // Overlay: clicking it closes the dialog; stop propagation inside the dialog
    <div
      className="modal-overlay"
      onClick={onClose}
      aria-hidden="true" /* overlay itself is decorative */
    >
      <div
        ref={dialogRef}
        className="modal-content"
        role="dialog"
        aria-modal="true"
        aria-labelledby="modal-title"
        onClick={(e) => e.stopPropagation()} /* prevent overlay click from firing inside */
      >
        <h2 id="modal-title">Edit Profile</h2>
        <form>
          <div>
            <label htmlFor="full-name">Full Name</label>
            <input
              id="full-name"
              type="text"
              placeholder="Enter your name"
              autoComplete="name"
            />
          </div>
          <div>
            <label htmlFor="email">Email</label>
            <input
              id="email"
              type="email"
              placeholder="Enter email"
              autoComplete="email"
            />
          </div>
          <div className="buttons">
            <button type="button" onClick={onClose}>
              Cancel
            </button>
            <button type="submit">Save Changes</button>
          </div>
        </form>
      </div>
    </div>,
    document.body
  );
}

/* Usage in parent — capture trigger ref for focus restoration: */
function ProfilePage() {
  const [isOpen, setIsOpen] = React.useState(false);
  const triggerRef = useRef(null);

  return (
    <>
      <button ref={triggerRef} onClick={() => setIsOpen(true)}>
        Edit Profile
      </button>
      <ProfileModal
        isOpen={isOpen}
        onClose={() => setIsOpen(false)}
        triggerRef={triggerRef}
      />
    </>
  );
}

==========================================================================
SUMMARY TABLE
==========================================================================

| # | Issue                              | SC          | Level | POUR        |
|---|------------------------------------|-------------|-------|-------------|
| 1 | No role="dialog" / aria-labelledby | 4.1.2       | A     | Robust      |
| 2 | No focus trap                      | 2.1.1/2.1.2 | A     | Operable    |
| 3 | Focus not moved to dialog on open  | 2.4.3       | A     | Operable    |
| 4 | Focus not restored to trigger      | 2.4.3       | A     | Operable    |
| 5 | Inputs lack programmatic labels    | 1.3.1/2.4.6 | A/AA  | Perceivable |
| 6 | No Escape key to close             | 2.1.1       | A     | Operable    |
| 7 | Background content not inert       | 1.3.1       | A     | Perceivable |

All 7 issues are resolved in the corrected component above. Six of the seven violations
are Level A — the most severe conformance level — meaning the modal would fail even a
minimum WCAG 2.1 Level A audit in its original form.

Additional recommended enhancement (not a WCAG violation but best practice):
- Add autoComplete="name" and autoComplete="email" on the inputs to support SC 1.3.5
  Identify Input Purpose (Level AA, WCAG 2.1) for users of autofill tools.
  (Included in the corrected code above.)

WCAG Accessibility Issues in ProfileModal Component
====================================================

The following WCAG 2.1 accessibility issues were identified in the ProfileModal component:

---

1. MISSING ARIA ROLE FOR DIALOG (WCAG 4.1.2 - Name, Role, Value)
   The modal container div lacks role="dialog" (or role="alertdialog"). Without this,
   assistive technologies like screen readers will not announce this as a dialog,
   and users will have no indication they are in a modal context.
   Fix: Add role="dialog" and aria-modal="true" to the modal-content div.

2. MISSING ACCESSIBLE NAME FOR THE DIALOG (WCAG 4.1.2 - Name, Role, Value)
   The dialog has no aria-labelledby or aria-label attribute to provide an accessible
   name. Screen readers need to announce the purpose of the dialog when it receives
   focus.
   Fix: Add aria-labelledby pointing to the h2 element's id
   (e.g., <h2 id="modal-title">Edit Profile</h2> and aria-labelledby="modal-title").

3. NO FOCUS MANAGEMENT / FOCUS TRAP (WCAG 2.1.2 - No Keyboard Trap; 2.4.3 - Focus Order)
   When the modal opens, focus is not programmatically moved into the modal. Users
   navigating by keyboard will remain focused on whatever element was active before,
   making it difficult or impossible to interact with the modal. Additionally, there
   is no focus trap, so Tab/Shift+Tab can cycle focus outside the modal while it is
   open, which is disorienting.
   Fix: On open, use useEffect and useRef to move focus to the first focusable element
   (or the modal container itself). Implement a focus trap that constrains keyboard
   navigation within the modal while it is open.

4. MISSING RETURN OF FOCUS ON CLOSE (WCAG 2.4.3 - Focus Order)
   When the modal closes, focus is not returned to the element that triggered it
   (the "Edit Profile" button). Screen reader and keyboard users will lose their
   place in the page.
   Fix: Store a reference to the trigger element before opening the modal and restore
   focus to it when the modal closes.

5. NO KEYBOARD HANDLER FOR ESCAPE KEY (WCAG 2.1.1 - Keyboard)
   The modal provides no way to close it via the keyboard (specifically the Escape
   key, which is the standard pattern for dismissing dialogs per ARIA Authoring
   Practices Guide). Keyboard-only users cannot dismiss the modal without clicking
   outside it or pressing Cancel.
   Fix: Add a keydown event listener (e.g., onKeyDown on the dialog) that calls
   onClose when the Escape key is pressed.

6. CLICK-TO-CLOSE OVERLAY HAS NO KEYBOARD EQUIVALENT (WCAG 2.1.1 - Keyboard)
   The modal-overlay div uses onClick={onClose} to close the modal when users click
   outside the content area. This is a mouse-only interaction; keyboard users cannot
   replicate this behavior by tabbing to the overlay. Divs are not natively focusable
   or activatable.
   Fix: Either remove this pattern and rely on an explicit close button + Escape key,
   or add role="button", tabIndex={0}, and a corresponding onKeyDown handler to make
   the overlay keyboard-accessible.

7. FORM INPUTS USE <span> INSTEAD OF <label> (WCAG 1.3.1 - Info and Relationships; 1.3.5 - Identify Input Purpose; 2.4.6 - Headings and Labels)
   The "Full Name" and "Email" field labels are plain <span> elements, which are not
   programmatically associated with their corresponding inputs. Screen readers will
   not announce the label when the input is focused, leaving users without context
   for what to type.
   Fix: Replace <span> with <label> and use either a for/htmlFor attribute matching
   each input's id, or wrap the input inside the label element.

8. PLACEHOLDER TEXT USED AS THE ONLY LABEL ALTERNATIVE (WCAG 1.3.1; 3.3.2 - Labels or Instructions)
   While placeholders are present ("Enter your name", "Enter email"), placeholder
   text disappears as soon as users begin typing and has insufficient color contrast
   in many browsers by default. Placeholders must never be used as a substitute for
   visible, persistent labels.
   Fix: Keep labels (see issue 7) as the primary label; treat placeholder as optional
   hint text only.

9. NO VISIBLE CLOSE BUTTON (WCAG 2.4.3 - Focus Order; 2.1.1 - Keyboard; ARIA Dialog Pattern)
   There is no dedicated close/dismiss button (typically an "X" button) in the modal
   header. The only way to close the modal is the Cancel button or clicking outside.
   ARIA Authoring Practices recommend a visible close button within the dialog.
   Fix: Add a close button (e.g., an X icon button) in the modal header with an
   accessible name like aria-label="Close dialog".

10. INSUFFICIENT COLOR CONTRAST CANNOT BE VERIFIED WITHOUT STYLES (WCAG 1.4.3 - Contrast Minimum)
    The code provides no color information. If the chosen text colors, background
    colors, or placeholder colors do not meet the 4.5:1 ratio (normal text) or 3:1
    (large text / UI components), this will be a WCAG failure.
    Fix: Audit CSS for all text/background color pairings and ensure they meet minimum
    contrast ratios. Placeholder text typically needs special attention.

11. FORM HAS NO SUBMIT HANDLER / ERROR HANDLING (WCAG 3.3.1 - Error Identification; 3.3.3 - Error Suggestion)
    The form lacks onSubmit handling and provides no visible or programmatic error
    messages if validation fails. Users with screen readers will not be informed of
    any errors after attempting to submit.
    Fix: Add onSubmit, perform validation, and surface error messages using
    aria-describedby or aria-live regions so that screen readers announce errors.

---

SUMMARY TABLE
=============
Issue                               | WCAG Criterion              | Level
------------------------------------|-----------------------------|---------
Missing role="dialog"               | 4.1.2 Name, Role, Value     | A
Missing aria-labelledby on dialog   | 4.1.2 Name, Role, Value     | A
No focus management / focus trap    | 2.1.2, 2.4.3                | A / AA
Focus not returned on close         | 2.4.3 Focus Order           | AA
No Escape key handler               | 2.1.1 Keyboard              | A
Overlay close not keyboard-operable | 2.1.1 Keyboard              | A
<span> instead of <label>           | 1.3.1, 2.4.6                | A / AA
Placeholder as label substitute     | 1.3.1, 3.3.2                | A / AA
No dedicated close button           | 2.1.1, 2.4.3                | A / AA
Color contrast (unverified)         | 1.4.3 Contrast Minimum      | AA
No error handling/identification    | 3.3.1, 3.3.3                | A / AA

WCAG Legal Compliance Requirements: US, EU, and UK Jurisdictions
For a SaaS Company Serving Government and Private Sector Customers
Date: 2026-05-16
================================================================================

EXECUTIVE SUMMARY
-----------------
As a SaaS company with customers in the US, EU, and UK spanning both government
agencies and private sector businesses, you face overlapping accessibility
mandates. The practical target that satisfies all jurisdictions is:

    WCAG 2.1 Level AA

This is the lowest common denominator that satisfies every applicable law
across your customer base. Where WCAG 2.2 is emerging as a requirement, the
good news is that WCAG 2.2 AA is a superset of WCAG 2.1 AA — achieving 2.2 AA
automatically satisfies 2.1 AA requirements. Targeting WCAG 2.2 AA now future-
proofs your product.

================================================================================
1. UNITED STATES — FEDERAL GOVERNMENT CUSTOMERS
================================================================================

Applicable Law: Section 508 of the Rehabilitation Act of 1973
(29 U.S.C. § 794d), as amended and refreshed in 2018

Regulatory Body: U.S. Access Board; enforced via agency procurement and
the DOJ under the ADA for federally funded entities.

WCAG Requirement: WCAG 2.0 Level AA (incorporated by reference)

Details:
- The 2017 Section 508 "Refresh" (effective January 18, 2018) replaced the
  original 2001 technical standards by incorporating WCAG 2.0 Level AA by
  reference (36 C.F.R. Part 1194).
- The standard references WCAG 2.0, not 2.1 or 2.2 — however, the Access
  Board has signaled intent to update the reference to WCAG 2.1 or later.
  As of 2026, no formal rulemaking has finalized that update, so WCAG 2.0
  Level AA remains the legally referenced standard.
- In practice, agencies increasingly require or prefer WCAG 2.1 AA in
  solicitations and ACR (Accessibility Conformance Report / VPAT) reviews.
- Applies to: Electronic and Information Technology (EIT) procured by
  federal agencies. As a SaaS vendor to federal agencies, your product is
  subject to Section 508 review during procurement.
- You must provide an Accessibility Conformance Report (ACR) using the
  VPAT 2.x template (ITI VPAT) referencing WCAG 2.1 — this is the current
  industry-standard VPAT revision even though the regulation cites 2.0.

Key Deadlines:
- The 2017 refresh took effect January 18, 2018; no pending phase-in remains.
- Watch for a future rulemaking to update the WCAG reference — likely to 2.2.

Action Required: Achieve WCAG 2.0 Level AA (minimum legal), document via
VPAT 2.x referencing WCAG 2.1 Level AA for practical market access.

================================================================================
2. UNITED STATES — PRIVATE SECTOR CUSTOMERS
================================================================================

Applicable Laws:
  (a) Americans with Disabilities Act (ADA), Titles II and III
      (42 U.S.C. §§ 12101 et seq.)
  (b) DOJ Final Rule on Web Accessibility for Title II entities
      (28 C.F.R. Part 35, published April 24, 2024)
  (c) Air Carrier Access Act (ACAA) — if applicable to airline customers
  (d) Section 504 of the Rehabilitation Act — for federally funded recipients

WCAG Requirement:
  - Title II (state/local government): WCAG 2.1 Level AA — NOW MANDATED
  - Title III (private businesses): WCAG 2.1 Level AA — DOJ guidance and
    overwhelming court precedent treat 2.1 AA as the de facto standard;
    no formal final rule yet but litigation risk is high without it.

Title II DOJ Final Rule (April 2024) Details:
- The DOJ finalized a rule under ADA Title II (28 C.F.R. Part 35) requiring
  state and local government entities to conform to WCAG 2.1 Level AA for
  web content and mobile apps.
- Phase-in deadlines by entity size:
    * Population 50,000+: Compliance by April 24, 2026
    * Population 10,000–49,999: Compliance by April 26, 2027
    * Population under 10,000: Compliance by April 26, 2027
- NOTE: As of May 2026, the initial deadline for large entities has passed.
  If your customers include state/local government entities, they must now
  be compliant — and as their SaaS provider, your product must support their
  compliance.

Title III (Private Sector):
- No equivalent DOJ final rule exists for private businesses as of 2026, but
  the DOJ's 2022 guidance letter and consistent federal court decisions
  (9th Cir., 1st Cir., 11th Cir.) treat WCAG 2.1 AA as the appropriate
  technical standard.
- ADA Title III litigation volume remains high; WCAG 2.1 AA is the practical
  safe harbor even without a formal rule.
- State laws (e.g., California Unruh Act, New York state/city laws) may impose
  additional or parallel obligations.

Action Required: WCAG 2.1 Level AA is both the legal minimum for Title II
customers (mandated) and the prudent standard for all private sector customers.

================================================================================
3. EUROPEAN UNION — PUBLIC SECTOR CUSTOMERS
================================================================================

Applicable Law: EU Web Accessibility Directive
(Directive (EU) 2016/2102, "WAD")

Harmonized Standard: EN 301 549 V3.2.1 (2021) — incorporates WCAG 2.1 Level AA

WCAG Requirement: WCAG 2.1 Level AA (via EN 301 549)

Details:
- The WAD requires public sector bodies in all EU Member States to make their
  websites and mobile apps accessible in accordance with EN 301 549.
- EN 301 549 V3.2.1 (current as of 2026) incorporates WCAG 2.1 Level AA
  as its core web content requirements (Chapter 9 maps directly to WCAG 2.1).
- As a SaaS vendor to public sector bodies, your product must conform to
  EN 301 549 / WCAG 2.1 AA to be procurable under WAD-compliant procurement.
- Scope: All public sector bodies (government, universities, hospitals,
  publicly funded entities). Does NOT currently mandate private sector
  compliance under the WAD — that is covered by the EAA (see Section 4).
- Accessibility Statement: Required for public sector websites/apps; as a
  SaaS provider you may need to support your customers in generating these.

Key Deadlines: WAD has been in force since September 23, 2020 (websites) and
June 23, 2021 (mobile apps). All deadlines have passed.

EN 301 549 Updates: ETSI is expected to update EN 301 549 to reference
WCAG 2.2 in an upcoming revision. Monitor ETSI TC HF for publication.

Action Required: WCAG 2.1 Level AA conformance, documented via an
Accessibility Conformance Report against EN 301 549 V3.2.1.

================================================================================
4. EUROPEAN UNION — PRIVATE SECTOR CUSTOMERS
================================================================================

Applicable Law: European Accessibility Act
(Directive (EU) 2019/882, "EAA")

Harmonized Standard: EN 301 549 (same standard as WAD, incorporating WCAG 2.1 AA)

WCAG Requirement: WCAG 2.1 Level AA (via EN 301 549, per EAA)

Details:
- The EAA extends accessibility requirements to a broad range of private sector
  products and services, including: computers, smartphones, e-readers,
  e-commerce websites, banking services, e-books, audio/visual media services,
  transport services (ticketing/check-in), and — critically for SaaS —
  electronic communications services.
- "Services" in scope include any digital service provided to consumers in the
  EU. B2B SaaS is more nuanced: the EAA primarily targets B2C services, but
  if your SaaS is used to deliver services to end consumers (e.g., a customer-
  facing portal your EU enterprise customers use to serve their own customers),
  EAA obligations likely flow through.
- Member States were required to transpose the EAA into national law by
  June 28, 2022.

KEY DEADLINE — EAA COMPLIANCE DATE: June 28, 2025
- All covered products and services placed on the market or provided in the
  EU after June 28, 2025 must comply with EAA requirements.
- This deadline has now passed (as of May 2026). If your SaaS is in scope,
  EAA compliance is currently required.

Microenterprise Exemption:
- Microenterprises (fewer than 10 employees AND annual turnover/balance sheet
  not exceeding €2 million) providing services (not products) are exempt from
  the EAA. This exemption does not apply to products.

Disproportionate Burden Exception:
- Economic operators may claim an exemption if compliance would impose a
  disproportionate burden, but this requires documented assessment and is
  a narrow exception.

Action Required: Assess whether your SaaS services fall within EAA scope.
If yes (likely for B2C-facing functionality), WCAG 2.1 Level AA conformance
is required as of June 28, 2025.

================================================================================
5. UNITED KINGDOM
================================================================================

Applicable Laws:
  (a) Public Sector Bodies (Websites and Mobile Applications) Accessibility
      Regulations 2018 (SI 2018/952) — "UK PSBAR" — for public sector customers
  (b) Equality Act 2010 — for private sector customers
  (c) (Prospective) UK Accessibility Act / adoption of EAA equivalent —
      legislation in progress as of 2026

Public Sector (UK PSBAR):
WCAG Requirement: WCAG 2.1 Level AA

Details:
- UK PSBAR transposed the EU WAD into UK law pre-Brexit and was retained
  in domestic law post-Brexit.
- References EN 301 549 / WCAG 2.1 Level AA as the technical standard.
- Enforced by the Government Digital Service (GDS) / Cabinet Office.
- Applies to public sector bodies in England, Wales, Scotland (separate
  Scottish regulations apply), and Northern Ireland.
- Requires accessibility statements for covered websites and apps.
- Deadlines have passed: websites (September 23, 2020), mobile apps
  (June 23, 2021).

Private Sector (Equality Act 2010):
WCAG Requirement: No specific version mandated, but WCAG 2.1 AA is the
prevailing standard in UK case law and regulatory guidance.

Details:
- The Equality Act 2010 (sections 20–21) imposes a duty on service providers
  to make "reasonable adjustments" to ensure disabled people are not at a
  substantial disadvantage.
- The Equality and Human Rights Commission (EHRC) Code of Practice identifies
  website/digital accessibility as a key reasonable adjustment area.
- WCAG 2.1 Level AA is the de facto standard expected by UK courts and the
  EHRC, even without explicit statutory reference.
- UK has signaled intent to introduce EAA-equivalent private sector
  requirements post-Brexit, but as of May 2026 no equivalent legislation
  has been enacted for private businesses. Monitor UK government consultations.

Action Required: WCAG 2.1 Level AA for public sector customers (legally
mandated); WCAG 2.1 Level AA recommended for private sector customers
(Equality Act reasonable adjustment standard).

================================================================================
6. CONSOLIDATED REQUIREMENTS TABLE
================================================================================

Region          | Customer Type    | Governing Law        | Standard      | Level
----------------|------------------|----------------------|---------------|-------
US              | Federal Gov't    | Section 508          | WCAG 2.0      | AA *
US              | State/Local Gov't| ADA Title II DOJ Rule| WCAG 2.1      | AA
US              | Private Sector   | ADA Title III        | WCAG 2.1      | AA **
EU              | Public Sector    | WAD + EN 301 549     | WCAG 2.1      | AA
EU              | Private Sector   | EAA + EN 301 549     | WCAG 2.1      | AA
UK              | Public Sector    | UK PSBAR             | WCAG 2.1      | AA
UK              | Private Sector   | Equality Act 2010    | WCAG 2.1      | AA ***

* Legally 2.0, but market expects 2.1; VPAT should reference 2.1
** No final rule; 2.1 AA is the prevailing litigation/guidance standard
*** No explicit WCAG mandate; 2.1 AA is the Equality Act reasonable adjustment benchmark

BOTTOM LINE: WCAG 2.1 Level AA satisfies every jurisdiction in your customer base.

================================================================================
7. KEY DEADLINES SUMMARY (STATUS AS OF MAY 2026)
================================================================================

Date            | Jurisdiction | Event
----------------|--------------|-----------------------------------------------
Jan 18, 2018    | US           | Section 508 Refresh effective — PASSED
Sep 23, 2020    | EU / UK      | WAD / PSBAR websites deadline — PASSED
Jun 23, 2021    | EU / UK      | WAD / PSBAR mobile apps deadline — PASSED
Jun 28, 2022    | EU           | EAA Member State transposition deadline — PASSED
Apr 24, 2026    | US           | ADA Title II large entity deadline — PASSED
Jun 28, 2025    | EU           | EAA enforcement begins for products/services — PASSED
Apr 26, 2027    | US           | ADA Title II smaller entity deadline — UPCOMING

IMPORTANT: All major deadlines except the US ADA Title II smaller-entity
deadline (April 26, 2027) have already passed. If you are not currently
compliant, you are out of compliance in most jurisdictions.

================================================================================
8. PRACTICAL RECOMMENDATIONS
================================================================================

TARGET STANDARD: WCAG 2.2 Level AA
--------------------------------------
While WCAG 2.1 AA is the legal minimum across all jurisdictions, we strongly
recommend targeting WCAG 2.2 Level AA for the following reasons:

1. WCAG 2.2 is a superset of 2.1 — achieving 2.2 AA automatically satisfies
   all 2.1 AA requirements.
2. EN 301 549 is expected to reference WCAG 2.2 in its next revision,
   making 2.2 the future EU standard.
3. The US Access Board is expected to update Section 508 to reference WCAG 2.1
   or 2.2 in future rulemaking.
4. WCAG 2.2 adds 9 new success criteria (SC 2.4.11–2.4.13, 2.5.7–2.5.8,
   3.2.6, 3.3.7–3.3.9) that significantly improve mobile and cognitive
   accessibility — areas of increasing legal focus.
5. Future-proofing reduces remediation costs later.

STEP-BY-STEP COMPLIANCE ROADMAP:
----------------------------------

Step 1 — Baseline Audit (Immediate)
  - Conduct a WCAG 2.2 Level AA audit of your entire product (web + mobile).
  - Use automated tools (axe-core, Deque, WAVE) combined with manual testing
    and testing with assistive technology users (screen readers, keyboard-only,
    voice control).
  - Prioritize critical user journeys: sign-up, login, core product features,
    billing, support.

Step 2 — Remediation Backlog (0–6 months)
  - Triage findings by impact (blocker vs. moderate) and user flow criticality.
  - Fix blockers (keyboard traps, missing alt text, no focus indicators,
    inaccessible forms, missing error identification) first.
  - Establish a Definition of Done that includes accessibility for all new
    features going forward.

Step 3 — Documentation (Parallel)
  - Produce a VPAT 2.x (ACR) against WCAG 2.1 AA for US government procurement.
  - Produce an EN 301 549 V3.2.1 conformance report for EU/UK procurement.
  - Publish an Accessibility Statement on your website covering your current
    status, known issues, and contact mechanism for assistance requests.

Step 4 — Ongoing Testing Program
  - Integrate automated accessibility testing into your CI/CD pipeline.
  - Schedule quarterly manual audits covering assistive technology combinations:
    * NVDA + Firefox (Windows)
    * JAWS + Chrome (Windows)
    * VoiceOver + Safari (macOS/iOS)
    * TalkBack + Chrome (Android)
  - Update your ACR/VPAT at least annually or after major releases.

Step 5 — Legal Safeguards
  - Include accessibility commitments in customer contracts (SLA provisions).
  - Establish an accessibility feedback/complaint mechanism — required under
    WAD (EU) and PSBAR (UK), and best practice under ADA.
  - Document your remediation roadmap — demonstrates good faith under ADA
    undue hardship analysis and EAA disproportionate burden exception.

ARIA AND TECHNICAL NOTES:
  - Follow WAI-ARIA Authoring Practices Guide (APG) for all custom widgets.
  - Ensure all custom components have appropriate ARIA roles, states, and
    properties before relying on ARIA (use native HTML semantics first).
  - Test focus management for single-page application (SPA) route changes —
    a common failure in SaaS products.
  - Ensure all dynamic content updates are announced via live regions
    (aria-live, aria-atomic) appropriately.

================================================================================
9. SPECIFIC WCAG 2.2 SUCCESS CRITERIA TO PRIORITIZE (COMMON SAAS FAILURES)
================================================================================

The following SCs are frequently failed in SaaS applications and should receive
immediate attention during audit:

WCAG 2.1 (often failed in SaaS):
  1.4.3  Contrast (Minimum) — text/background color contrast ≥ 4.5:1
  1.4.4  Resize Text — usable at 200% zoom without loss of content
  1.4.11 Non-text Contrast — UI components/graphics ≥ 3:1 contrast ratio
  1.4.12 Text Spacing — content doesn't break with letter/line/word spacing overrides
  1.4.13 Content on Hover or Focus — tooltips/popovers are dismissible, hoverable, persistent
  2.1.1  Keyboard — all functionality available via keyboard
  2.4.3  Focus Order — logical focus sequence in modals and overlays
  2.4.7  Focus Visible — keyboard focus indicator always visible
  3.3.1  Error Identification — errors described in text, not color alone
  3.3.2  Labels or Instructions — form inputs have visible labels
  4.1.2  Name, Role, Value — all UI components have accessible name/role/state
  4.1.3  Status Messages — non-focused status messages announced to screen readers

WCAG 2.2 additions (new requirements):
  2.4.11 Focus Appearance (Minimum) — focus indicator meets size and contrast requirements
  2.5.7  Dragging Movements — all drag-and-drop has a single-pointer alternative
  2.5.8  Target Size (Minimum) — interactive targets ≥ 24×24 CSS pixels
  3.2.6  Consistent Help — help mechanisms appear in consistent location
  3.3.7  Redundant Entry — previously entered information is auto-populated
  3.3.8  Accessible Authentication (Minimum) — no cognitive function test for login
         (this directly impacts CAPTCHA-based authentication flows)

================================================================================
10. DISCLAIMER
================================================================================

This response reflects the regulatory landscape as of May 2026 based on
available information. Accessibility law is evolving rapidly — particularly
in the EU (EN 301 549 revision) and the US (potential Section 508 update,
ADA Title III rulemaking). Consult qualified legal counsel in each jurisdiction
before making final compliance determinations. This is not legal advice.

================================================================================
END OF RESPONSE
================================================================================

WCAG Version and Conformance Level Requirements by Region
For a SaaS company selling to government agencies and private sector businesses in the US, EU, and UK

=============================================================
UNITED STATES
=============================================================

Government Customers:
- Applicable Law: Section 508 of the Rehabilitation Act (29 U.S.C. § 794d), as revised in 2017
- Required Standard: WCAG 2.0, Level AA (incorporated by reference into the Revised Section 508 Standards)
- Who It Applies To: Federal agencies and any vendors/contractors providing electronic and information technology (EIT) to federal agencies
- Important Note: As a SaaS vendor selling to US federal agencies, your product must meet Section 508, which maps to WCAG 2.0 AA. Many states also have their own accessibility laws that mirror Section 508 or go further.
- Trend: The Access Board has signaled intent to update Section 508 to reference WCAG 2.1 or 2.2, but as of 2026 the legal baseline remains WCAG 2.0 AA.

Private Sector Customers:
- Applicable Law: Americans with Disabilities Act (ADA), Titles II and III
- Required Standard: No explicit WCAG version is written into the ADA statute, but the DOJ has issued rules (effective April 2026 for larger entities) requiring WCAG 2.1, Level AA for state and local government websites and web content (Title II).
- For Title III (private businesses open to the public): Courts and the DOJ consistently treat WCAG 2.1 AA as the de facto standard based on DOJ guidance and litigation outcomes.
- Practical Recommendation: Target WCAG 2.1 AA at a minimum for all US customers to satisfy both Section 508 and ADA obligations.

=============================================================
EUROPEAN UNION
=============================================================

Government Customers:
- Applicable Law: EU Web Accessibility Directive (Directive 2016/2102) and the European Accessibility Act (EAA, Directive 2019/882)
- Required Standard: EN 301 549 (the harmonized European standard), which currently references WCAG 2.1, Level AA
- Who It Applies To:
  * Web Accessibility Directive: Public sector bodies (government websites and mobile apps) — already in force
  * European Accessibility Act (EAA): Broader scope covering private sector products and services including SaaS, with compliance required by June 28, 2025
- Conformance Level: WCAG 2.1, Level AA (via EN 301 549 v3.2.1 or later)

Private Sector Customers:
- Applicable Law: European Accessibility Act (EAA), transposed into national law by each EU member state
- Required Standard: WCAG 2.1, Level AA (via EN 301 549)
- Effective Date: June 28, 2025 — private sector companies must comply
- Scope: The EAA covers a wide range of digital services and products, including SaaS platforms used by consumers and businesses
- Note: Individual EU member states may have additional national accessibility requirements that go beyond the EAA baseline.

=============================================================
UNITED KINGDOM
=============================================================

Government Customers:
- Applicable Law: Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 (SI 2018/952), implementing the EU Web Accessibility Directive post-Brexit
- Required Standard: WCAG 2.1, Level AA
- Who It Applies To: UK public sector bodies and vendors providing digital services to them
- Enforcement: The Government Digital Service (GDS) and Equality and Human Rights Commission (EHRC) oversee compliance

Private Sector Customers:
- Applicable Law: Equality Act 2010 (the UK equivalent of the ADA)
- Required Standard: No explicit WCAG version mandated in statute, but WCAG 2.1 AA is the recognized benchmark used by courts and the EHRC
- Practical Recommendation: Target WCAG 2.1 AA to meet both public sector regulations and Equality Act obligations

=============================================================
SUMMARY TABLE
=============================================================

Region       | Customer Type    | Law/Regulation              | Required WCAG Version & Level
-------------|------------------|-----------------------------|------------------------------
US           | Government       | Section 508                 | WCAG 2.0, Level AA (minimum); WCAG 2.1 AA recommended
US           | Private Sector   | ADA (Titles II & III)       | WCAG 2.1, Level AA (de facto standard)
EU           | Government       | Web Accessibility Directive | WCAG 2.1, Level AA (via EN 301 549)
EU           | Private Sector   | European Accessibility Act  | WCAG 2.1, Level AA (via EN 301 549), effective June 28, 2025
UK           | Government       | Public Sector Bodies Regs   | WCAG 2.1, Level AA
UK           | Private Sector   | Equality Act 2010           | WCAG 2.1, Level AA (de facto standard)

=============================================================
PRACTICAL RECOMMENDATION
=============================================================

To meet legal compliance across all three regions and both customer types, you should target:

  >> WCAG 2.1, Level AA <<

This single standard satisfies:
- Section 508 (US federal government) — which legally requires WCAG 2.0 AA but WCAG 2.1 AA is a superset
- ADA requirements (US private sector)
- EN 301 549 / EU Web Accessibility Directive (EU government)
- European Accessibility Act (EU private sector)
- UK Public Sector Bodies Regulations (UK government)
- UK Equality Act (UK private sector)

Additional Considerations:
1. WCAG 2.2: Released in October 2023, WCAG 2.2 adds new success criteria (notably around focus indicators and dragging movements). While not yet legally mandated in most jurisdictions, it is best practice and will likely become the legal baseline over time. Consider planning for WCAG 2.2 AA compliance.
2. VPAT/ACR: For US government sales, prepare a Voluntary Product Accessibility Template (VPAT) or Accessibility Conformance Report (ACR) documenting your conformance with Section 508 / WCAG 2.1 AA.
3. Accessibility Statements: EU and UK public sector regulations require a published accessibility statement. This is recommended best practice for all customer-facing products.
4. WCAG 3.0: Still in development and not yet a legal requirement. Do not use WCAG 3.0 as your compliance baseline at this time.

=============================================================
IMPORTANT DISCLAIMER
=============================================================

This response reflects general knowledge as of May 2026 and is intended for informational purposes only. It does not constitute legal advice. Accessibility laws are evolving — particularly the EAA's national implementations and potential US Section 508 updates. Consult a qualified accessibility attorney or compliance specialist for advice specific to your products, customers, and jurisdictions.

================================================================================
ACCESSIBILITY STATEMENT FOR SHOPEASY
================================================================================

Last updated: 16 May 2026
Audit date: 15 March 2024

--------------------------------------------------------------------------------
1. INTRODUCTION
--------------------------------------------------------------------------------

ShopEasy is committed to ensuring digital accessibility for people with
disabilities. We continually improve the user experience for everyone and apply
relevant accessibility standards to achieve this goal.

This accessibility statement applies to the ShopEasy website and all web-based
services operated under the shopeasy.com domain (hereinafter "the Website").

--------------------------------------------------------------------------------
2. CONFORMANCE STATUS
--------------------------------------------------------------------------------

The Web Content Accessibility Guidelines (WCAG) define requirements for
designers and developers to improve accessibility for people with disabilities.
WCAG 2.1 defines three levels of conformance: Level A (minimum), Level AA
(enhanced), and Level AAA (highest). ShopEasy targets WCAG 2.1 Level AA
conformance.

CONFORMANCE CLAIM: ShopEasy PARTIALLY CONFORMS with WCAG 2.1 Level AA.

"Partially conforms" means that some parts of the content do not conform to
the accessibility standard. The specific non-conformances are identified in
Section 4 of this statement.

This conformance claim covers the ShopEasy website as a whole, including:
  - All product listing and detail pages
  - Shopping cart and checkout processes
  - Account registration and management
  - Search functionality
  - Customer support pages
  - Blog and editorial content
  - Embedded third-party widgets (where applicable)

Excluded from this claim:
  - Third-party content not under our direct control (e.g., external payment
    provider interfaces), where those providers maintain their own separate
    conformance claims.

--------------------------------------------------------------------------------
3. TECHNICAL SPECIFICATIONS
--------------------------------------------------------------------------------

ShopEasy relies on the following technologies for conformance with WCAG 2.1:

  - HTML5
  - CSS3
  - JavaScript (ECMAScript 2015+)
  - WAI-ARIA 1.1
  - PDF (Adobe PDF format; see known limitations in Section 4)

The Website has been tested with the following assistive technologies:

  - NVDA (NonVisual Desktop Access) with Mozilla Firefox on Windows
  - VoiceOver with Safari on macOS and iOS
  - Keyboard-only navigation (no pointing device)
  - Browser zoom up to 400%
  - Windows High Contrast Mode

Testing methodology: Combined automated scanning and manual testing.
  - Automated tools: [Specify tools used, e.g., axe-core, Deque Axe DevTools,
    Lighthouse Accessibility]
  - Manual testing conducted with the assistive technologies listed above.

Date of last comprehensive accessibility audit: 15 March 2024.

--------------------------------------------------------------------------------
4. KNOWN ACCESSIBILITY ISSUES (NON-CONFORMANCES)
--------------------------------------------------------------------------------

The following known issues represent areas where ShopEasy does not currently
meet WCAG 2.1 Level AA. We are actively working to resolve these.

----------------------------------------------------------------------
Issue 1: Inaccessible PDF Product Manuals
----------------------------------------------------------------------
  Affected content:
    Older PDF product manuals available for download on product detail pages.

  WCAG Success Criteria not met:
    - SC 1.1.1 Non-text Content (Level A): Some PDF documents contain images,
      diagrams, and non-text elements that lack appropriate text alternatives.
      Users relying on screen readers may not receive equivalent information.
    - SC 4.1.2 Name, Role, Value (Level A): Some older PDFs lack proper tag
      structure, form field labels, and programmatic attributes required for
      assistive technologies to interpret interactive elements and reading order
      correctly.

  Impact:
    Users who rely on screen readers or other assistive technologies may be
    unable to access the full content of affected PDF manuals.

  Accessible alternative:
    If you require an accessible version of a specific product manual, please
    contact our accessibility support team (see Section 6). We will provide an
    accessible alternative in HTML or plain-text format within 5 business days.

  Remediation plan:
    We are systematically remediating all product manuals. New manuals published
    after 1 January 2025 are produced to WCAG 2.1 AA standards. Remediation of
    legacy documents is ongoing, with an estimated completion date of
    [INSERT TARGET DATE].

----------------------------------------------------------------------
Issue 2: Live Chat Widget Does Not Announce New Messages
----------------------------------------------------------------------
  Affected content:
    The live chat widget available site-wide via the chat icon in the lower
    right corner of the screen.

  WCAG Success Criteria not met:
    - SC 4.1.3 Status Messages (Level AA): When a new chat message arrives from
      a support agent, the message is displayed visually but not communicated
      to screen reader users via an appropriate ARIA live region or equivalent
      programmatic mechanism. Users of screen readers may therefore miss
      incoming messages without switching focus manually to the chat panel.

  Impact:
    Screen reader users who initiate a live chat session may not be aware that
    a support agent has responded, resulting in a degraded or unusable support
    experience.

  Accessible alternative:
    Screen reader users who experience difficulty with the live chat widget are
    encouraged to contact our support team by email or telephone instead
    (see Section 6).

  Remediation plan:
    We are working with our live chat widget provider to implement ARIA live
    region announcements (role="log" or aria-live="polite") for incoming
    messages. This fix is targeted for completion by [INSERT TARGET DATE].

----------------------------------------------------------------------
Issue 3: Video Product Demonstrations Lack Audio Descriptions
----------------------------------------------------------------------
  Affected content:
    Embedded product demonstration videos on product detail pages and in the
    ShopEasy Learning Hub.

  WCAG Success Criteria not met:
    - SC 1.2.5 Audio Description (Prerecorded) (Level AA): Video product
      demonstrations contain visual information (e.g., on-screen text, product
      features shown only visually, button interactions) that is not conveyed
      through the existing audio track. Extended or inserted audio descriptions
      are not currently provided for any prerecorded video content.

  Impact:
    Users who are blind or have low vision and cannot perceive the visual
    content of product videos may be unable to obtain equivalent information
    about product features and usage.

  Accessible alternative:
    We are preparing text transcripts for all product demonstration videos.
    Where transcripts are currently available, they are linked directly below
    the video player. If no transcript is yet available for a specific video,
    please contact us (see Section 6) and we will provide a descriptive
    transcript within 5 business days.

  Remediation plan:
    Audio descriptions are being produced for all new product videos (effective
    immediately). Existing video library remediation is in progress, prioritised
    by product popularity, with an estimated completion date of
    [INSERT TARGET DATE].

--------------------------------------------------------------------------------
5. DISPROPORTIONATE BURDEN
--------------------------------------------------------------------------------

ShopEasy does not currently invoke the disproportionate burden exemption for
any content or functionality. All non-conformances identified in Section 4 are
being actively remediated within commercially reasonable timescales.

Should ShopEasy determine that any specific remediation effort constitutes a
disproportionate burden under applicable accessibility regulations, we will
publish a detailed justification here, including the assessment criteria applied
and the duration of the exemption.

--------------------------------------------------------------------------------
6. FEEDBACK AND CONTACT INFORMATION
--------------------------------------------------------------------------------

We welcome your feedback on the accessibility of ShopEasy. If you experience
barriers to access, find content you cannot access, or have suggestions for
improvement, please contact us:

  Accessibility Support Contact:
  Name/Role: Accessibility Officer, ShopEasy
  Email:     accessibility@shopeasy.com
  Telephone: [INSERT PHONE NUMBER]
  Postal address:
    ShopEasy Accessibility Team
    [INSERT STREET ADDRESS]
    [INSERT CITY, POSTCODE]
    [INSERT COUNTRY]

  Response commitment:
    We aim to acknowledge all accessibility feedback within 2 business days and
    to provide a substantive response or an accessible alternative to affected
    content within 5 business days.

  Requesting an accessible format:
    If you need information on this website in a different format (e.g., large
    print, audio, accessible PDF, or plain-text), please contact us using the
    details above. Describe the content you require and your preferred format,
    and we will respond as quickly as possible.

--------------------------------------------------------------------------------
7. ENFORCEMENT AND COMPLAINTS PROCEDURE
--------------------------------------------------------------------------------

We are committed to resolving all accessibility complaints. If you are
dissatisfied with our response to your accessibility feedback, you may escalate
your complaint as follows:

  Internal escalation:
    Email our Data Protection and Compliance team at: compliance@shopeasy.com
    Reference "Accessibility Complaint" in the subject line.

  External enforcement bodies (by jurisdiction):

  United Kingdom:
    Equality and Human Rights Commission (EHRC)
    Website: www.equalityhumanrights.com
    The Equality Act 2010 and the Public Sector Bodies (Websites and Mobile
    Applications) Accessibility Regulations 2018 apply to public sector bodies.
    Private sector organisations are subject to the Equality Act 2010.

  European Union:
    If ShopEasy operates in an EU member state as a public sector body or
    within scope of the EU Web Accessibility Directive (Directive 2016/2102),
    complaints may be directed to the relevant national enforcement body.
    For private sector e-commerce entities, the European Accessibility Act
    (Directive 2019/882), applicable from 28 June 2025, establishes
    accessibility requirements and member-state enforcement mechanisms.
    Contact the national market surveillance authority in your country of
    residence for complaints under the EAA.

  United States:
    The Americans with Disabilities Act (ADA) prohibits discrimination on the
    basis of disability. Complaints may be filed with the U.S. Department of
    Justice, Civil Rights Division: www.ada.gov

  Australia:
    Disability Discrimination Act 1992 complaints may be lodged with the
    Australian Human Rights Commission: www.humanrights.gov.au

--------------------------------------------------------------------------------
8. EU WEB ACCESSIBILITY DIRECTIVE COMPLIANCE INFORMATION
--------------------------------------------------------------------------------

This section is included to satisfy the minimum content requirements of the
EU Web Accessibility Directive (Directive 2016/2102) and its implementing
Decision (EU) 2018/1523, which specifies the model accessibility statement for
public sector bodies. Private-sector organisations in scope of the European
Accessibility Act (Directive 2019/882) are advised to follow this model as
best practice.

  a. Preparation of this statement:
     This accessibility statement was prepared through a combination of
     self-assessment and the findings of the formal accessibility audit
     conducted on 15 March 2024 using automated and manual testing methods.

  b. Statement preparation date:
     This statement was first published on [INSERT ORIGINAL PUBLICATION DATE].
     It was last reviewed and updated on 16 May 2026.

  c. Review schedule:
     This statement will be reviewed and updated at least annually, or sooner
     following any significant change to the Website or following completion of
     remediation work described in Section 4.

  d. Formal complaints mechanism (EU):
     Users in the European Union who are not satisfied with our response to
     an accessibility complaint may refer their complaint to the relevant
     national enforcement body designated under Article 7 of Directive 2016/2102
     or the equivalent national authority under the European Accessibility Act.

--------------------------------------------------------------------------------
9. COMPATIBILITY WITH BROWSERS AND ASSISTIVE TECHNOLOGIES
--------------------------------------------------------------------------------

ShopEasy is designed to be compatible with the following assistive technologies
and browser combinations:

  Supported combinations (tested):
    - NVDA (latest release) + Mozilla Firefox (latest) on Windows 10/11
    - VoiceOver + Safari (latest) on macOS (latest two major versions)
    - VoiceOver + Safari on iOS (latest two major versions)
    - Keyboard-only navigation in Chrome, Firefox, Edge (latest versions)
    - TalkBack + Chrome on Android (latest two major versions)

  The Website is NOT optimised for use with Internet Explorer 11 or earlier
  versions of any browser. Users are encouraged to use a modern, supported
  browser for the best accessible experience.

--------------------------------------------------------------------------------
10. ASSESSMENT APPROACH
--------------------------------------------------------------------------------

ShopEasy assessed the accessibility of its Website using the following approach:

  - Self-evaluation against WCAG 2.1 Level AA success criteria
  - Automated scanning using [specify tools, e.g., axe-core, Deque Axe DevTools]
  - Manual testing by internal QA team trained in accessibility testing
  - Assistive technology user testing with NVDA on Windows and VoiceOver on
    macOS and iOS, conducted as part of the audit on 15 March 2024
  - Periodic automated scans run as part of the continuous integration pipeline

  ShopEasy intends to commission an independent third-party accessibility audit
  on or before [INSERT NEXT SCHEDULED AUDIT DATE].

--------------------------------------------------------------------------------
DOCUMENT INFORMATION
--------------------------------------------------------------------------------

Standard applied:       Web Content Accessibility Guidelines (WCAG) 2.1,
                        W3C Recommendation, 5 June 2018
                        https://www.w3.org/TR/WCAG21/

Conformance level:      WCAG 2.1 Level AA (Partial Conformance)

Scope:                  https://www.shopeasy.com/ and all sub-pages

Statement version:      2.0
Last reviewed:          16 May 2026
Next scheduled review:  16 May 2027 (or earlier if material changes occur)

================================================================================
END OF ACCESSIBILITY STATEMENT
================================================================================

Accessibility Statement for ShopEasy
=====================================

Last Updated: May 16, 2026


Our Commitment
--------------

ShopEasy is committed to ensuring digital accessibility for people with disabilities. We continually improve the user experience for everyone and apply relevant accessibility standards to ensure we provide an inclusive shopping experience.


Conformance Status
------------------

ShopEasy aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. These guidelines explain how to make web content more accessible to people with disabilities. Conformance with these guidelines helps make the web more user-friendly for all people.

We are partially conformant with WCAG 2.1 Level AA. "Partially conformant" means that some parts of the content do not fully conform to the accessibility standard due to the known issues listed below.


Known Accessibility Issues
--------------------------

We are aware of the following accessibility limitations on our website and are actively working to resolve them:

1. Older PDF Product Manuals (WCAG 2.1 SC 1.1.1 Non-text Content; SC 4.1.2 Name, Role, Value)
   Some of our older PDF product manuals were created before our current accessibility standards were adopted. These documents may not include proper alternative text for images and may not have correctly identified form fields, interactive elements, or structural markup. We are in the process of remediating these documents. In the meantime, if you need an accessible version of a product manual, please contact us and we will provide the information in an alternative format.

2. Live Chat Widget (WCAG 2.1 SC 4.1.3 Status Messages)
   Our live chat widget does not currently announce new incoming messages to users of screen readers. As a result, screen reader users may not be aware when a new chat message arrives without manually navigating to the chat area. We are working with our live chat provider to implement the necessary ARIA live region announcements. If you need assistance while we resolve this issue, please use our email or phone support options.

3. Video Product Demonstrations (WCAG 2.1 SC 1.2.5 Audio Description (Prerecorded))
   Product demonstration videos on our website do not currently include audio descriptions of the visual content shown. This means users who are blind or have low vision may miss visual information presented in the videos. We are in the process of producing audio description tracks for all product demonstration videos. If you need information about a product shown in a video, please contact us and we will assist you.


Technical Specifications
------------------------

ShopEasy relies on the following technologies for conformance with WCAG 2.1:

- HTML5
- CSS
- JavaScript
- WAI-ARIA


Audit and Assessment Approach
------------------------------

ShopEasy assesses the accessibility of our website through the following methods:

- Automated accessibility testing tools
- Manual testing with screen readers, including NVDA (Windows) and VoiceOver (macOS/iOS)
- Periodic expert reviews

Our most recent accessibility audit was conducted on March 15, 2024.


Feedback and Contact Information
----------------------------------

We welcome your feedback on the accessibility of ShopEasy. If you experience accessibility barriers on our website, or if you need information or a service in an accessible format, please contact us:

- Email: accessibility@shopeasy.com
- Phone: [Your Phone Number]
- Postal Address: [Your Company Address]

We aim to respond to accessibility feedback within 2 business days.


Formal Complaints
-----------------

If you are not satisfied with our response to your accessibility feedback, you may contact the relevant national authority responsible for enforcing accessibility regulations in your region.


This statement was prepared on May 16, 2026.

# NZISM Certification & Accreditation Gap Analysis — RESTRICTED System

The NZISM is issued by the **GCSB (National Cyber Security Centre — NCSC NZ)** as the New Zealand Government's mandatory information security manual. Its controls carry **MUST/SHOULD compliance requirements tied to the system's classification level** — for a RESTRICTED system, essential (MUST) controls cannot be waived without formal risk acceptance recorded by the Accreditation Authority. Certification and Accreditation (C&A) is mandatory for any system handling Restricted and above before it goes live.

## What the NZISM C&A Process Requires

C&A has two distinct stages that must not be conflated:

- **Certification** — the technical assessment confirming NZISM controls are implemented *and effective*. This requires independent validation/testing evidence, not just documentation.
- **Accreditation** — the formal acceptance of residual risk by the Accreditation Authority (typically the agency head or a delegate), granting Authorisation to Operate (ATO).

The full pathway:

1. **System Security Plan (SSP/SecPlan)** — documents the system boundary, classification, security objectives, and all implemented controls.
2. **Security Risk Management Plan (SRMP)** — identifies threats, vulnerabilities, likelihood, impact, treatments, and residual risk. This is a **mandatory** C&A artefact alongside the SSP, not optional.
3. **Control validation** — independent technical review verifying controls are implemented and effective (testing evidence required).
4. **Certification review and sign-off** — the ITSM (IT Security Manager) and CISO review validation evidence and formally certify the system.
5. **Plan of Action & Milestones (POA&M)** — documents and tracks remediation of any assessment findings.
6. **Accreditation decision** — the Accreditation Authority reviews residual risk and grants ATO, recorded formally.
7. **Ongoing monitoring** — continuous control monitoring and periodic re-certification (typically every 1–3 years depending on risk, or triggered earlier by major change, incident, or classification change).

## Gap Analysis

| Item | NZISM Requirement | Your Status | Gap |
|---|---|---|---|
| System Security Plan | Mandatory C&A artefact; documents boundary, classification, objectives, controls | Draft exists | 🟡 Partial — confirm it covers full system boundary and all implemented/planned controls before certification review |
| Security Risk Management Plan | Mandatory C&A artefact (threats, vulnerabilities, likelihood, impact, treatments, residual risk) | Does not exist | ❌ Not Implemented — **critical gap**; certification cannot proceed without an SRMP |
| Control implementation | Controls must be implemented and validated as effective for the classification level | Partially implemented | 🟡 Partial — identify which of the Restricted-tier control domains (physical secure zones, encryption at rest, MFA for remote access, privileged account separation, enhanced logging/12-month retention, supplier contractual controls, cloud risk assessment if applicable, MDM/remote wipe if mobile) remain outstanding |
| Control validation/testing | Independent technical testing evidence required — documentation alone is insufficient | No validation testing performed | ❌ Not Implemented — **critical gap**; even fully implemented controls cannot be certified without test evidence |
| Certification review and sign-off | ITSM/security practitioner and CISO review validation evidence and certify | Not started (no ITSM sign-off) | ❌ Not Implemented — blocked by the SRMP and validation gaps above |
| POA&M | Required to track remediation of certification findings | Not yet applicable (no certification run) | N/A pending certification |
| Accreditation decision | Accreditation Authority formally accepts residual risk and grants ATO | Not started | ❌ Not Implemented — cannot occur until certification is complete |

## Summary of Critical Gaps

Your agency currently cannot proceed to certification, let alone accreditation, for three interlocking reasons:

1. **No SRMP.** This is a mandatory artefact, not a nice-to-have. Without it, residual risk cannot be identified or presented to the Accreditation Authority.
2. **No control validation testing.** Partial implementation without testing evidence means the ITSM/CISO have nothing independently verifiable to certify against.
3. **No ITSM sign-off**, which is a direct consequence of gaps 1 and 2 — certification review cannot occur until the SRMP exists and validation testing has been completed.

## Recommended Remediation Priority

1. **Immediately**: Commission the SRMP — threat/vulnerability identification, likelihood/impact assessment, proposed treatments, and residual risk statement, scoped to the RESTRICTED classification.
2. **In parallel**: Complete implementation of outstanding Restricted-tier controls (encryption at rest, MFA for remote access, privileged access separation, enhanced logging with 12-month retention, physical secure zone controls, supplier contractual NZISM-equivalent clauses).
3. **Next**: Commission independent control validation/testing against the SSP and NZISM control set — this produces the evidence the ITSM/CISO need.
4. **Then**: ITSM and CISO conduct certification review, sign off, and raise a POA&M for any residual findings.
5. **Finally**: Submit the certification package (SSP, SRMP, validation evidence, POA&M) to the Accreditation Authority for the formal accreditation decision and ATO.

Given the current state (draft SSP, no SRMP, no validation testing, no ITSM sign-off), expect roughly 8–12+ weeks to reach an accreditation-ready position, depending on remediation effort for outstanding controls.

I can produce an SSP outline or a structured remediation roadmap (with owners and target dates) as a next step if useful.

---
*This is general compliance guidance, not legal advice. Confirm current NZISM control numbering and C&A procedural detail against the official manual (nzism.gcsb.govt.nz) and your agency's Accreditation Authority requirements.*

# NZISM Certification & Accreditation (C&A) Gap Analysis

## What the NZISM C&A Process Requires

Under the New Zealand Information Security Manual (NZISM), Certification and Accreditation is the formal process by which a system is assessed against its security requirements (certification) and then a risk-based decision is made by the appropriate authority to allow the system to operate (accreditation). For a RESTRICTED system, the process typically involves the following stages and artefacts:

1. **System Security Plan (SSP)** — Documents the system's architecture, boundary, security controls (mapped to NZISM chapters/controls), roles and responsibilities, and how the system meets its required security classification (RESTRICTED in this case).
2. **Security Risk Management Plan (SRMP)** — Captures the risk assessment for the system: threats, vulnerabilities, likelihood/consequence ratings, existing and planned controls, residual risk, and risk treatment/acceptance decisions. The SRMP is the primary artefact used by the accreditation authority to understand and formally accept residual risk.
3. **Control implementation** — Controls identified in the SSP/SRMP as applicable (drawn from the NZISM control catalogue, e.g. access control, cryptography, network security, physical security, personnel security, incident management, system hardening) must actually be implemented, not merely planned.
4. **Security testing / validation** — Certification requires evidence that controls work as intended. This normally includes a combination of:
   - Vulnerability assessments
   - Penetration testing (where warranted by risk/classification)
   - Control validation / compliance testing against the SSP
   - Configuration and build reviews
5. **Certification** — A technical/independent review (often by an IT Security Manager, ITSM, or an independent certifier) confirms the system has been built and tested as described in the SSP and that residual risks are understood.
6. **Accreditation** — The system owner or Accreditation Authority (typically the Chief Executive or a delegate, informed by the Chief Information Security Officer / ITSM) formally accepts the residual risk and authorises the system to operate, usually issuing a time-bound accreditation with conditions and a re-accreditation/review date.
7. **Ongoing assurance** — Post-accreditation, the system requires continuous monitoring, periodic reassessment, vulnerability management, incident reporting, and re-accreditation on a defined cycle or upon significant change.

Key roles referenced in NZISM governance include the Chief Executive (ultimately accountable), the Chief Information Security Officer (CISO), the IT Security Manager (ITSM) who manages day-to-day security and typically provides sign-off/advice into the accreditation decision, and system/business owners.

## Gap Analysis Against Your Current State

| C&A Requirement | Your Current State | Gap |
|---|---|---|
| System Security Plan | Draft exists | Not finalised/approved. Needs completion, internal review, and formal sign-off before it can support certification. |
| Security Risk Management Plan | Does not exist | **Critical gap.** Without an SRMP there is no documented risk assessment, no residual risk statement, and no basis for an accreditation decision. This should be prioritised immediately, in parallel with finalising the SSP. |
| Control implementation | Partially implemented | Gap between controls claimed in the SSP and controls actually operating. Need a control implementation matrix showing status (planned/in progress/implemented) for every applicable NZISM control, with target dates for full implementation. |
| Validation/compliance testing | None performed | **Critical gap.** No evidence controls work as intended. Certification cannot proceed without testing (vulnerability scanning at minimum, penetration testing if risk warrants given RESTRICTED classification). |
| Certification | Not started | Cannot occur until SSP is finalised, SRMP exists, controls are implemented, and testing evidence is available. |
| ITSM sign-off | Not obtained | **Critical gap.** No independent technical assurance has been given. ITSM sign-off (or equivalent independent certifier) is a precondition for accreditation. |
| Accreditation | Not obtained | Cannot be granted — accreditation authority has no SRMP, no test evidence, and no certification recommendation to base a decision on. The system should not be treated as authorised to hold/process RESTRICTED information until this is resolved. |

## Recommended Sequence to Close Gaps

1. Finalise the SSP, ensuring it maps every applicable NZISM control to the system and clearly defines the system boundary and classification handling requirements for RESTRICTED information.
2. Develop the SRMP in parallel — conduct a formal risk assessment (threat/vulnerability identification, likelihood/consequence, existing vs residual risk) and identify any additional controls or treatments required.
3. Complete implementation of all controls identified as applicable, tracking status in a control implementation/compliance matrix.
4. Commission validation testing — vulnerability assessment as a minimum, with penetration testing strongly recommended given the RESTRICTED classification — and remediate findings.
5. Package the SSP, SRMP, control evidence, and test results, and route through the ITSM (or independent certifier) for a formal certification recommendation.
6. Present the certification package to the Accreditation Authority (Chief Executive or delegate) for a risk-acceptance decision and formal accreditation, including any conditions and the re-accreditation timeframe.
7. Establish continuous monitoring and a defined re-accreditation/review cycle once accredited.

## Bottom Line

The agency currently has none of the three preconditions for accreditation of a RESTRICTED system: a finalised risk plan, tested/validated controls, and independent (ITSM) sign-off. Until the SRMP is produced, controls are fully implemented and validated through testing, and ITSM sign-off is obtained, the system should not be represented as certified or accredited to handle RESTRICTED information, and should not go into production processing RESTRICTED data without a documented and accepted interim risk position from the Accreditation Authority.

*This is general guidance based on NZISM C&A principles and does not replace consultation with your agency's CISO/ITSM or GCSB/NCSC advice for your specific system.*

# Hosting RESTRICTED Data in AWS Sydney (Offshore) — NZISM Requirements

The NZISM is issued by the **GCSB (National Cyber Security Centre — NCSC NZ)** as the New Zealand Government's mandatory information security manual. Its controls carry **MUST/SHOULD compliance requirements tied to the system's classification level**; for RESTRICTED data, essential (MUST) controls cannot be waived without formal risk acceptance by the Accreditation Authority.

**Short answer: yes, this is possible, but it is a risk-based decision, not a default option — offshore hosting of RESTRICTED data is not prohibited outright, but it requires a documented risk assessment and formal approval before go-live.** It is not something you can do simply because AWS Sydney is a reputable, capable region.

## The Required Pathway

### 1. Classify the data
Confirm the data is RESTRICTED (not higher) — this determines the applicable NZISM controls and the depth of assessment required. If any data processed by the system rises above RESTRICTED, offshore hosting becomes substantially harder to justify (Confidential+ generally requires Accrediting Authority approval for any offshore processing, per NZISM Chapter 13 supplier controls).

### 2. Run the NZ Government cloud risk assessment
The cloud-first policy requires a documented cloud risk assessment for public cloud use, per the **NZ Government Cloud Computing Risk & Resilience Guide**. **Protective Security Requirements (PSR)** obligations apply alongside the NZISM — the NZISM sits under the PSR for information security specifically, so both frameworks' cloud/offshore requirements must be satisfied.

### 3. Assess jurisdiction and sovereignty
Hosting in AWS Sydney places your data under **Australian legal jurisdiction**, not just AWS's operational control. You need to analyse:
- Foreign legal access regimes that could compel Amazon Web Services (or Australian authorities) to access or produce the data
- Data residency and data-in-transit commitments from AWS for the Sydney region
- Contractual protections limiting AWS's/subcontractors' ability to move or access data outside the agreed jurisdiction
- An exit strategy — data portability and secure deletion if the arrangement ends or needs to be unwound

### 4. Impose classification-appropriate controls
For RESTRICTED data hosted offshore, at minimum:
- **Encryption at rest and in transit**, with **agency-controlled keys where feasible** (evaluate AWS KMS with customer-managed keys, or an agency-held HSM-backed key model)
- **Access restricted to security-cleared personnel** only
- **Comprehensive logging and monitoring available to the agency** — not just to AWS; the agency must retain visibility (CloudTrail, VPC flow logs, config change logs exported to agency-controlled tooling)
- **Independent supplier assurance evidence** — an IRAP assessment of the AWS Sydney region/services in scope, current ISO/IEC 27001 certification, and a SOC 2 Type II report

### 5. Follow the approval chain and record it
This is not a decision an IT team can make alone:
1. Documented risk assessment (cloud risk assessment + jurisdiction/sovereignty analysis)
2. **ITSM/CISO certification review** of the assessment and proposed controls
3. **Formal risk acceptance by the Accreditation Authority / agency head** — recorded in the accreditation record — before go-live

Skipping the formal accreditation-record step is a common failure mode: agencies sometimes treat a positive risk assessment as sufficient, but the NZISM requires the Accreditation Authority to explicitly accept the residual risk of offshore hosting.

## Relevant Control References
Cloud computing controls sit in **NZISM Chapter 22 (Enterprise Systems Security), Section 22.1 Cloud Computing**, including control **22.1.23.C.01 (System availability)**. For topics beyond this verified control (e.g., specific offshore data-residency or key-management control numbers), confirm the current control ID against the online manual (nzism.gcsb.govt.nz) — the NZISM is updated roughly twice a year.

## Practical Recommendation
Before committing to AWS Sydney:
- Confirm whether an NZ-hosted alternative exists that would avoid the jurisdictional analysis entirely (data residency in NZ is generally preferred where available)
- If Sydney is the only viable option (e.g., service/feature parity, cost, or NZ region unavailable for the required AWS service), ensure the IRAP assessment, encryption/key-management model, and logging access are locked into the contract *before* the Accreditation Authority sign-off, not treated as follow-up items after go-live
- Document the decision, including why NZ hosting was not selected, in the accreditation record — this is what an auditor or the Accreditation Authority's successor will look for later

---
*This is general compliance guidance, not legal advice. Confirm current NZISM control numbering, PSR requirements, and your agency's specific Accreditation Authority process against official sources (nzism.gcsb.govt.nz, protectivesecurity.govt.nz) before proceeding.*

# Hosting RESTRICTED Data in AWS Sydney (Offshore): What's Required

## Short Answer

It is potentially possible, but **not automatic** — offshoring RESTRICTED information outside New Zealand requires a formal risk assessment, explicit risk acceptance by your agency's Accreditation Authority, and compliance with both the NZISM's offshore/cloud provisions and NZ Government cloud policy (administered by the Government Chief Digital Officer, GCDO, part of the Department of Internal Affairs). It is not a blanket prohibition, but it is treated as a heightened-risk decision that must be actively assessed and approved — you cannot simply provision an AWS Sydney region and start processing RESTRICTED data.

## What the NZISM Requires

1. **Data sovereignty and offshore risk assessment** — The NZISM requires agencies to consider the risks of storing or processing classified information offshore, including the jurisdiction's legal environment (e.g. foreign government access/compulsion laws), the physical and personnel security of the facility, and the ability to maintain NZ government assurance/audit rights over the environment.
2. **Classification-based controls** — RESTRICTED is the lowest NZ government security classification tier but still requires baseline protections: encryption of data at rest and in transit, strict access control, logging/monitoring, and personnel security (appropriately cleared/vetted administrators).
3. **Cloud-specific guidance** — The NZISM includes principles for cloud computing covering shared responsibility, provider assurance, data location, incident response coordination with the provider, and exit/portability planning. Agencies must satisfy themselves the cloud service provider (CSP) can meet the confidentiality, integrity, and availability requirements of the classification level.
4. **Certification and accreditation** — As with any system handling RESTRICTED information, the hosting arrangement (including the offshore element) must be captured in the System Security Plan and Security Risk Management Plan, and the residual risk of offshoring must be explicitly accepted by the agency's Accreditation Authority (typically Chief Executive or delegate, informed by the CISO/ITSM).

## What NZ Government Cloud Policy Requires

1. **Cloud First Policy** — NZ government's Cloud First policy encourages use of cloud services but requires agencies to conduct due diligence, particularly for higher-sensitivity data.
2. **Government Chief Digital Officer (GCDO) guidance** — The GCDO (within DIA) provides guidance and, historically, a Cloud Risk Assessment process/tooling to help agencies assess cloud service risk, including data sovereignty, jurisdiction, and provider security certifications. Agencies are generally expected to consult this guidance before onboarding a cloud service for anything above UNCLASSIFIED, and certainly for RESTRICTED.
3. **All-of-Government (AoG) cloud arrangements** — Where an AoG cloud services agreement exists covering a provider (AWS has historically had engagement under NZ government cloud frameworks), agencies should check whether AWS Sydney is an approved/endorsed offering under that arrangement, as this can streamline (but not eliminate) the due diligence and approval steps.
4. **Data sovereignty considerations** — Even though AWS Sydney is in Australia (not New Zealand), it is still an offshore location relative to NZ. Agencies must specifically assess and document why an NZ-only region isn't used (AWS has historically not had a dedicated NZ region for all services, so many agencies do host in Australian regions), the legal exposure of data being subject to Australian law and any third-country access risk, and any restrictions from data owners or information-sharing agreements that may prohibit offshoring entirely for certain data sets.
5. **Ministerial/Cabinet direction** — Certain categories of government data (e.g. specific national security, law enforcement, or Māori data considerations) may have additional sovereignty requirements or expectations beyond general RESTRICTED handling — these should be checked against your specific data holdings.

## Practical Pre-Conditions Before Hosting RESTRICTED Data in AWS Sydney

- Conduct a documented risk assessment covering data sovereignty, legal jurisdiction (Australian and any extraterritorial access laws such as the US CLOUD Act, given AWS is a US-headquartered provider), and provider security assurance (e.g. relevant certifications, NZISM control mapping).
- Confirm AWS's shared responsibility model and ensure your agency retains/implements the customer-side NZISM controls (encryption key management, IAM, logging, network segmentation, etc.).
- Verify whether AWS Sydney is covered by any existing NZ Government cloud services arrangement or requires a standalone risk assessment submission to GCDO/DIA.
- Ensure contractual terms with AWS address data location commitments, government/law enforcement access notification, audit rights, incident notification timeframes, and data return/deletion on exit.
- Document the offshoring decision and residual risk in the SRMP and obtain explicit accreditation sign-off before go-live, rather than treating cloud hosting as a lower-scrutiny "given."
- Engage your agency's CISO/ITSM and, where relevant, NCSC (National Cyber Security Centre, part of GCSB) for advice, particularly given RESTRICTED classification.

## Bottom Line

RESTRICTED data can potentially be hosted in AWS Sydney, but this is a risk-accepted exception rather than a default — it requires a documented offshore risk assessment, alignment with GCDO/NZ Government cloud policy expectations, explicit customer-side implementation of NZISM controls under the shared responsibility model, and formal accreditation sign-off before the data is placed there. Treat this as a decision requiring active governance, not a routine provisioning task.

*This is general guidance based on NZISM and NZ government cloud policy principles as commonly understood; confirm current GCDO/DIA cloud guidance and any AoG cloud agreements directly, as these are periodically updated.*

# Access Control Policy

**Classification:** IN-CONFIDENCE (policy document itself; apply the classification marking of the agency issuing this policy)
**Framework:** New Zealand Information Security Manual (NZISM)

The NZISM is issued by the **GCSB (National Cyber Security Centre — NCSC NZ)** as the New Zealand Government's mandatory information security manual. Its controls carry **MUST/SHOULD compliance requirements tied to the system's classification level** — essential (MUST) controls in this policy cannot be waived for systems handling Restricted information or above without formal risk acceptance by the Accreditation Authority. This policy is written to be applicable at the RESTRICTED tier by default; agencies operating solely at IN-CONFIDENCE or below may descope the Restricted-tier requirements noted below.

---

## 1. Purpose

This Access Control Policy establishes the requirements for identification, authentication, authorisation, and privileged access management across all agency information systems, in accordance with the NZISM. It ensures access to agency information and systems is limited to authorised individuals with a legitimate business need.

## 2. Scope

This policy applies to all agency employees, contractors, and third parties who access agency ICT systems, and to all systems processing agency information from Unclassified through Restricted (and above, where the agency operates such systems, subject to the additional controls in NZISM Chapters for Confidential/Secret/Top Secret).

## 3. Policy Statements

### 3.1 Identification
- Every user, service, and device accessing an agency system must be uniquely identified. Shared or generic accounts are prohibited except where formally risk-assessed and approved, with compensating controls (e.g., session recording).
- Service accounts must use unique, non-shared credentials and be inventoried with a named business owner.
- *NZISM reference: Chapter 16.1, Identification, Authentication and Passwords — confirm current control numbers against the online manual for identification-specific requirements beyond those cited below.*

### 3.2 Authentication
- Passwords must meet complexity and minimum-length requirements aligned with NZISM guidance (which follows NIST SP 800-63B principles).
- **Multi-Factor Authentication (MFA) is mandatory** for all remote access and for all privileged accounts, and is required for all users accessing Restricted information.
- Account lockout must be enforced after a defined number of failed login attempts.
- Session timeout and automatic screen lock must be configured on all endpoints accessing agency systems.
- Inactive or departed-staff accounts must be suspended promptly.
- *NZISM reference: 16.1.46.C.02 (Suspension of access — disable inactive/departed accounts), and Chapter 16.1 generally for MFA and password requirements. Confirm current v3.9 control numbers for passwordless/phishing-resistant MFA requirements against the online manual, as the NZISM is updated roughly twice a year.*

### 3.3 Authorisation
- Access is granted strictly on the **principle of least privilege** — the minimum access necessary for the individual's role.
- **Separation of duties** must be enforced for critical or high-risk functions (e.g., no single individual can both create and approve a privileged account).
- Access rights must be reviewed and re-certified **at least annually**, with more frequent review for privileged and Restricted-tier access.
- Temporary or time-limited access must be formally requested, approved, and configured to expire automatically.
- Access requests, approvals, and revocations must be logged and auditable.
- *NZISM reference: Chapter 16 (Access Control and Passwords / v3.9: Authentication and Access Controls) generally for least privilege and access review requirements — confirm current control numbers for specific authorisation sub-controls against the online manual.*

### 3.4 Privileged Access
- Privileged accounts must be **separate from standard user accounts** — no individual should use a privileged account for routine business activity (email, web browsing, document editing).
- Privileged access is granted on a need-to-use basis and subject to enhanced approval.
- All privileged account activity must be logged, and logs reviewed periodically for anomalous use.
- Remote privileged access requires additional controls — jump servers and, where the system handles Restricted+ information, session recording.
- Privileged accounts must be included in the mandatory annual access review, with more frequent review recommended (e.g., quarterly).
- *NZISM reference: 16.3.5.C.02 (Use of privileged accounts — restrict, separate, least privilege).*

### 3.5 Access Logging and Monitoring
- All authentication events (successful and failed logins), privileged actions, and access changes must be logged.
- Logs must be protected against tampering and retained per NZISM requirements (minimum 90 days online, 12 months archived for Restricted-tier systems; longer for Confidential and above).
- *NZISM reference: 16.6.6.C.02 (Maintaining system management logs), 16.6.10.C.02 (Additional events to be logged).*

## 4. Roles and Responsibilities
- **Chief Information Security Officer (CISO):** owns this policy, approves exceptions, reviews compliance annually.
- **System/Application Owners:** ensure access controls are implemented and reviewed for their systems.
- **IT Security Manager (ITSM):** validates access control implementation as part of certification activities.
- **Line Managers:** approve and periodically review access requests for their staff.
- **All Users:** comply with authentication requirements and report suspected unauthorised access immediately.

## 5. Exceptions
Any exception to this policy (e.g., use of a shared account, deferral of MFA) requires documented risk assessment and formal approval by the CISO, and — for Restricted-tier systems — acknowledgement by the Accreditation Authority as part of the system's residual risk position.

## 6. Review Cycle
This policy must be reviewed **at least annually**, or earlier following a significant security incident, major system change, or update to the NZISM.

## 7. Document Control

| Field | Value |
|---|---|
| Document Owner | Chief Information Security Officer (CISO) |
| Classification | [Agency to confirm — recommend IN-CONFIDENCE] |
| Version | 1.0 |
| Approved By | [Chief Executive or delegate] |
| Effective Date | [Agency to insert] |
| Next Review Date | 12 months from effective date |

| Version | Date | Author | Summary of Changes |
|---|---|---|---|
| 1.0 | 2026-07-03 | [Agency to insert] | Initial version aligned to NZISM |

---
*This policy provides general compliance guidance, not legal advice. Confirm current NZISM control numbering and section titles (Chapter 16 was renamed "Authentication and Access Controls" in NZISM v3.9) against the official manual (nzism.gcsb.govt.nz) before finalising and publishing.*

# Access Control Policy

**[Agency Name]**
**Document Owner:** Chief Information Security Officer (CISO)
**Effective Date:** 3 July 2026
**Alignment:** New Zealand Information Security Manual (NZISM)
**Classification:** UNCLASSIFIED (Policy Document)

## 1. Purpose

This policy establishes the requirements for controlling access to [Agency Name]'s information systems and information, in alignment with the New Zealand Information Security Manual (NZISM). It ensures that access to systems and data is granted only to authorised individuals, based on identified business need, and is managed throughout the access lifecycle.

## 2. Scope

This policy applies to all employees, contractors, and third parties who access [Agency Name]'s systems, networks, applications, or information, at all classification levels handled by the agency (UNCLASSIFIED through RESTRICTED and above, as applicable).

## 3. Policy Statements

### 3.1 Identification

- All users must be uniquely identified before being granted access to agency systems. Shared or generic accounts are prohibited except where explicitly approved and compensating controls (e.g. enhanced logging, physical access restriction) are documented.
- User identities must be verified and formally registered as part of the onboarding process, consistent with NZISM personnel and identification requirements for account management.
- Unique identifiers must be maintained for the life of the account and not reused or reassigned to another individual.

*(Aligned to NZISM access control / identification and authentication chapter requirements.)*

### 3.2 Authentication

- Access to all agency systems must be authenticated using mechanisms appropriate to the classification of information involved. Multi-factor authentication (MFA) is required for:
  - Remote access to agency networks and systems
  - Access to systems processing RESTRICTED or higher classified information
  - All privileged/administrative accounts
- Passwords/passphrases, where used as a factor, must meet minimum complexity, length, and rotation requirements consistent with NZISM password guidance, and must not be shared, written down insecurely, or reused across systems.
- Authentication credentials must be securely stored (e.g. salted/hashed) and transmitted only over encrypted channels.
- Default vendor credentials must be changed or disabled prior to system deployment.

*(Aligned to NZISM authentication controls, including multi-factor authentication requirements for remote and privileged access.)*

### 3.3 Authorisation

- Access to systems and information must be granted according to the principle of least privilege — users are given the minimum access necessary to perform their duties.
- Access must be formally requested, approved by the relevant information/system owner, and recorded prior to provisioning.
- Role-based access control (RBAC) should be used where practicable to standardise permissions according to job function.
- Access rights must be reviewed at least annually, and immediately upon role change or termination, to ensure continued business need (access recertification).
- Segregation of duties must be enforced for sensitive functions (e.g. system administration, financial approval, security configuration) to reduce the risk of fraud or error.
- Access to information classified RESTRICTED or above additionally requires the user to hold an appropriate security clearance and need-to-know, consistent with NZISM personnel security and information classification handling requirements.

*(Aligned to NZISM authorisation and account management controls, including least privilege, need-to-know, and periodic access review requirements.)*

### 3.4 Privileged Access Management

- Privileged accounts (system administrators, database administrators, security administrators, and similar) must be:
  - Separate from standard user accounts (no use of privileged accounts for routine business activities such as email or web browsing)
  - Individually attributable — no shared privileged accounts
  - Subject to MFA for all access
  - Approved by the system/business owner and CISO (or delegate) prior to provisioning
  - Logged and monitored, with privileged session activity subject to enhanced audit logging
  - Reviewed at a higher frequency than standard accounts (e.g. quarterly) due to elevated risk
- Use of privileged access must be time-bound and task-justified where practicable (e.g. just-in-time access, break-glass procedures with post-use review for emergency access).
- Remote privileged access must be via secure, authenticated, and encrypted channels, with additional monitoring controls.
- All privileged account activity must be logged in a manner that is protected from modification or deletion by the account holder, supporting accountability and incident investigation.

*(Aligned to NZISM privileged access management and system administration control requirements.)*

## 4. Account Lifecycle Management

- **Provisioning:** Access is provisioned only after approval from the relevant owner and completion of required pre-employment/security screening appropriate to the classification of data accessed.
- **Modification:** Access changes (e.g. role transfer) must be re-approved to reflect the new role's requirements; residual unnecessary access must be removed.
- **De-provisioning:** Access must be revoked immediately upon termination of employment/contract, and within a defined maximum timeframe (e.g. same business day) for role changes that remove the need for access.
- **Inactive accounts:** Accounts inactive for a defined period (e.g. 90 days) must be disabled and reviewed.

## 5. Monitoring and Audit

- All authentication and authorisation events, particularly privileged access and access to RESTRICTED information, must be logged.
- Logs must be protected from unauthorised access or modification and retained in accordance with agency record-keeping and NZISM logging/audit requirements.
- Access control logs should be reviewed periodically and investigated where anomalies are detected.

## 6. Roles and Responsibilities

- **System/Information Owners:** Approve access requests and conduct periodic access reviews for their systems/information.
- **CISO / IT Security Manager (ITSM):** Owns this policy, approves privileged access provisioning, and oversees compliance monitoring.
- **IT Operations:** Implements technical access controls, provisions/de-provisions accounts, and maintains audit logs.
- **All Staff and Contractors:** Comply with this policy, protect their credentials, and report suspected unauthorised access immediately.

## 7. Exceptions

Any exception to this policy must be documented, risk-assessed, and formally approved by the CISO, with compensating controls identified and a defined review/expiry date.

## 8. Review

This policy will be reviewed at least annually, or upon significant change to the agency's systems, threat environment, or the NZISM.

---

*This policy is drafted as a general template aligned to NZISM access control principles (identification, authentication, authorisation, and privileged access management). It should be reviewed and tailored by the agency's CISO/ITSM against the current NZISM version and the agency's specific systems, classification holdings, and risk profile before formal adoption.*

# Supplier Ransomware Incident — NZISM-Aligned Incident Response Obligations

The NZISM is issued by the **GCSB (National Cyber Security Centre — NCSC NZ)** as the New Zealand Government's mandatory information security manual. Its controls carry **MUST/SHOULD compliance requirements tied to the system's classification level** — for a supplier holding your agency's data, essential (MUST) obligations around incident reporting and supplier accountability apply regardless of where the breach originated, and cannot simply be waived because the compromise occurred at a third party.

**Critical point: your agency remains responsible for the security of its information even when a third-party supplier is holding it.** A ransomware event at your supplier is your incident too, not solely theirs.

## Immediate Steps

### 1. Activate your incident response plan
Treat this as a live agency security incident under your Incident Response Plan, not merely a "vendor problem to monitor." Classify severity based on: the classification level of the data held by the supplier, whether personal information is involved, and whether the ransomware event involved data exfiltration (not just encryption/denial of access).

### 2. Engage the supplier under contract
- Invoke incident notification and cooperation clauses in your supplier contract — the supplier should already be contractually obligated to notify you of breaches within a defined timeframe.
- Demand details: what data was affected, whether exfiltration occurred (not just encryption), the timeline of compromise, and the supplier's containment/eradication actions.
- Preserve evidence — request the supplier maintain forensic readiness and chain of custody for incident artefacts; do not let remediation destroy evidence needed for your own assessment.

### 3. Assess data and classification impact
Determine what classification of agency data the supplier held (Unclassified through Restricted or above) and whether personal information was involved. This determines both your NZISM reporting obligations and your Privacy Act 2020 obligations.

## Who You Must Notify in New Zealand

- **NCSC (GCSB)** — for cyber incidents. Report significant security incidents to the NCSC; note that **CERT NZ's functions now sit within the NCSC**, so there is a single agency to engage for both the "government cyber incident" reporting line and what was formerly the CERT NZ incident-reporting function. This applies whether the compromise happened on your own systems or, as here, at a supplier holding your data — the obligation follows the data, not just the infrastructure.
- **NZ Police** — for criminal acts. Ransomware is a criminal act (extortion/computer crime); report to NZ Police, particularly if there is a ransom demand or evidence of criminal exploitation.
- **Office of the Privacy Commissioner (OPC)** — if personal information is involved and the breach meets the **notifiable serious-harm threshold** under the Privacy Act 2020. This is a mandatory, time-bound obligation independent of your NZISM reporting — assess it in parallel, not after NCSC/Police notification is complete.

Do not treat these as sequential or optional — assess all three notification obligations in parallel as soon as the scope of affected data is known, even if the full picture is still emerging. Initial notifications can (and often should) be made with preliminary information, followed by updates as the investigation matures.

## Supplier and Contractual Obligations Going Forward

- **Right to audit**: exercise any contractual right to audit the supplier's security controls and incident response as part of this event.
- **Incident notification SLA**: confirm the supplier met their contractual notification timeframe; if they did not, this is itself a contract compliance issue to raise formally.
- **Post-incident review**: require the supplier to provide a root-cause analysis and remediation plan; your agency should conduct its own post-incident review covering both the supplier's failure and your own oversight of that supplier relationship.
- **Supplier risk register**: log this event against the supplier in your risk register, and reassess whether the existing risk acceptance for this supplier relationship still holds.
- **Reassess offshore/hosting arrangements**: if the supplier's compromised environment was hosting Restricted+ data, this event should trigger a re-review of the original risk assessment and the Accreditation Authority's residual risk acceptance for that arrangement (NZISM Chapter 13, Third-Party Suppliers).

## Documentation and Recertification Impact

- Maintain a full incident timeline, notifications made, and remediation actions taken.
- If the affected system underwent NZISM Certification & Accreditation, a significant security incident is a **re-certification trigger** — the ITSM/CISO should assess whether the system's certification remains valid or whether re-certification is required.
- Conduct a post-incident review with root-cause analysis and lessons learned, feeding into both your own control improvements and any renegotiation of the supplier contract's security clauses.

---
*This is general compliance guidance, not legal advice. Confirm current NCSC/CERT NZ reporting channels, Privacy Act 2020 notifiable-harm thresholds, and NZ Police reporting procedures against official sources, and consult legal counsel given the potential contractual, regulatory, and criminal dimensions of this incident.*

# Supplier Ransomware Incident: NZISM-Aligned Incident Response Obligations

## Immediate Situation

A supplier holding your agency's data has been hit by ransomware. This is a third-party/supply-chain security incident affecting your agency's information, and it triggers your agency's own incident response obligations under the NZISM even though the breach originated at the supplier, because the data compromised is your agency's information.

## Step 1: Activate Incident Response and Contain

- Activate your agency's incident response plan immediately, treating this as a confirmed (not suspected) security incident given ransomware has already executed at the supplier.
- Engage the supplier urgently to understand: what agency data was held, whether it was accessed/exfiltrated (not just encrypted), the classification level of the affected data, the timeline of compromise, and containment/eradication status.
- Assess whether the supplier's compromise creates any onward risk to your agency's own systems (e.g. shared credentials, VPN access, integrations, or API connections between the supplier and your environment) and isolate/rotate credentials as a precaution.
- Preserve evidence and maintain a timeline/incident log from the moment you are notified.

## Step 2: Classify the Incident and Determine Notification Obligations

Under NZISM, security incidents affecting government information must be assessed for severity and reported through appropriate channels. Key considerations:

1. **Assess data classification and sensitivity** — what classification was the compromised data (e.g. RESTRICTED, personal information, etc.)? This drives urgency and who must be notified.
2. **Determine whether this is a "reportable" security incident** under NZISM criteria — ransomware affecting a system holding government information, particularly with potential data exfiltration, would typically meet the threshold for mandatory reporting.

## Who You Must Notify in New Zealand

Depending on the nature and classification of the data and the type of information involved, notification obligations can include:

1. **National Cyber Security Centre (NCSC)**, part of the **Government Communications Security Bureau (GCSB)** — NZISM requires agencies to report significant cyber security incidents affecting government systems/information to NCSC. Ransomware incidents affecting a supplier holding government data should be reported to NCSC as the national technical authority for government cyber security incidents.
2. **CERT NZ** — for broader incident reporting/coordination, particularly if there is any consumer or wider public impact, or as a parallel reporting channel alongside NCSC (CERT NZ and NCSC coordinate on national incident response).
3. **Your agency's own CISO/ITSM and senior leadership/Chief Executive** — internal escalation is required immediately so the agency can make risk decisions (e.g. whether to suspend the supplier relationship, notify affected individuals, or issue public statements).
4. **Office of the Privacy Commissioner (OPC)** — if the compromised data includes personal information, and the breach has caused or is likely to cause serious harm, this is a **notifiable privacy breach** under the Privacy Act 2020, which requires notification to the Privacy Commissioner and affected individuals as soon as practicable.
5. **Affected individuals** — if personal information is compromised and serious harm is likely, individuals must be notified under the Privacy Act 2020 notifiable breach regime, in addition to the technical agency notifications above.
6. **Relevant Minister / Ministry** — for significant incidents, agencies typically need to brief their Minister and, where relevant, the lead central agency (e.g. Department of the Prime Minister and Cabinet for national security-significant events), particularly if the incident could become public or affects multiple agencies.
7. **Government Chief Digital Officer (GCDO) / Department of Internal Affairs** — where the incident relates to a cloud service or shared government ICT arrangement, GCDO may need to be informed as the functional lead for government digital services.

## Step 3: Supplier/Contractual Obligations

- Review your contract with the supplier for mandatory breach notification clauses, timeframes, cooperation obligations (forensic access, evidence sharing), and liability provisions.
- Require the supplier to provide a formal incident report, including root cause, data affected, and remediation actions.
- Assess whether the supplier met their contracted security obligations (this may be a separate compliance/contractual matter to pursue after the immediate incident is managed).

## Step 4: Investigation and Remediation

- Conduct or commission a forensic assessment (via the supplier or independently) to determine the scope of data compromise.
- Determine whether any of your agency's credentials, systems, or connected infrastructure were also exposed, and remediate (e.g. password resets, access revocation, network segmentation review).
- Document lessons learned and update supplier risk assessments/due diligence processes.

## Step 5: Post-Incident Reporting and Review

- Complete a formal incident report for internal governance, capturing timeline, impact, notifications made, and remediation actions.
- Feed findings into your agency's Security Risk Management Plan and supplier risk register — this incident should trigger a review of the supplier's ongoing suitability to hold agency data, and possibly a broader review of other suppliers with similar data holdings.
- Consider whether NZISM control gaps (e.g. contractual security requirements, data minimisation with suppliers, encryption of data at rest at the supplier) need strengthening agency-wide as a result.

## Summary of Key NZ Notification Contacts

- **NCSC (GCSB)** — national technical authority for significant government cyber incidents
- **CERT NZ** — national incident reporting/coordination body
- **Office of the Privacy Commissioner** — mandatory if personal information and serious harm likely (Privacy Act 2020)
- **Internal CISO/ITSM/Chief Executive** — immediate internal escalation
- **Affected individuals** — if personal information compromised with likely serious harm

## Bottom Line

Treat this as your agency's own reportable security incident, not solely the supplier's problem. Contain and assess immediately, notify NCSC (and CERT NZ) given this is a government-information-affecting cyber incident, assess Privacy Act notification obligations if personal information is involved, escalate internally to your CISO and Chief Executive, and enforce your contractual incident cooperation and notification clauses with the supplier. Document everything for both incident response and any subsequent supplier accountability review.

*This is general guidance based on NZISM incident management principles and NZ notification frameworks (NCSC, CERT NZ, Privacy Act 2020). Confirm exact reporting thresholds and timeframes with your agency's CISO/ITSM, as these depend on the specific classification and nature of the compromised data.*

# NZISM-Aligned Due Diligence for SaaS Procurement

The NZISM is issued by the **GCSB (National Cyber Security Centre — NCSC NZ)** as the New Zealand Government's mandatory information security manual. Its controls carry **MUST/SHOULD compliance requirements tied to the classification of the data the SaaS product will handle** — the higher the classification, the more rigorous the due diligence and the less negotiable the contractual requirements. **Your agency remains responsible for the security of its information even though the SaaS product is hosted and operated by a third party** — you cannot transfer that accountability to the vendor.

## Step 1: Classify the Data First

Before evaluating any vendor, determine the classification of the data the SaaS product will store or process (Unclassified through Restricted, or above). This determines the depth of assessment required and which contractual protections are mandatory versus best-practice. Default to treating the system as **Restricted** if this is not yet firmly established — it is easier to relax requirements later than to retrofit them after go-live.

## Step 2: Independent Assurance Evidence to Require

Before contract execution, obtain and review:
- **Current ISO/IEC 27001 certificate** — check the certificate scope actually covers the service, environment, and data centres relevant to your deployment, not just the vendor's corporate entity in general.
- **SOC 2 Type II report** — covering a sufficient audit period (12 months preferred), reviewed for exceptions and management responses.
- **IRAP assessment** (or equivalent government-grade assessment) — particularly important if the vendor is hosted on a public cloud platform and the data will reach Restricted classification.
- **Recent independent penetration test results**, including remediation status of any findings — do not accept a clean summary without visibility into what was tested and what remains open.

## Step 3: Architecture Evidence to Require

- **Tenancy isolation model** — confirm how your agency's data is logically/physically separated from other tenants.
- **Encryption at rest and in transit** — confirm approved algorithms (AES-256, TLS 1.2 minimum, TLS 1.3 preferred) are used throughout.
- **Key management** — clarify who holds encryption keys; for Restricted+ data, agency-controlled keys are preferred where feasible.
- **Data residency and processing locations** — identify every jurisdiction where your data will be stored, processed, or backed up, including any offshore processing.
- **Subcontractor/fourth-party disclosure** — the vendor must disclose all subcontractors and downstream processors with access to your data, since your due diligence obligations extend through the supply chain, not just the primary vendor.

## Step 4: Identity & Access Integration (Contractual Requirements, Not Nice-to-Haves)

- **SSO/SAML or OIDC support** — the SaaS product must integrate with your agency's identity provider; standalone credential stores are a red flag for Restricted-tier use.
- **MFA enforcement** — must be supported and enforceable for all users, non-negotiable for privileged/admin accounts.
- **Role-based access control (RBAC)** — granular enough to implement least privilege and separation of duties for your agency's use cases.
- **Agency access to audit logs** — export or API access to authentication events, privileged actions, and configuration changes; you cannot rely solely on the vendor's internal logging with no visibility for your own security monitoring.

## Step 5: Contract Clauses to Impose

- **Incident notification SLA** — a defined, short timeframe (e.g., 24–72 hours from vendor's own detection) for notifying your agency of any security incident affecting your data, including incidents at the vendor's subcontractors.
- **Right to audit** — contractual right to audit the vendor's security controls, or at minimum to receive current assurance evidence (ISO 27001, SOC 2 Type II, pen test summary) annually.
- **Data return and certified secure deletion on exit** — data portability in a usable format plus certified destruction of all copies (including backups) at contract termination, consistent with NZISM disposal requirements for the applicable classification.
- **Jurisdiction / data-sovereignty terms** — explicit statement of which jurisdictions' laws govern the data, and restrictions on moving data outside agreed locations without agency approval.

## Step 6: Offshore Hosting Considerations

If the SaaS product hosts data outside New Zealand (a common reality for global SaaS platforms), this is a **risk-based decision, not a prohibition**, but it requires:
1. A documented cloud/offshore risk assessment (NZ Government Cloud Computing Risk & Resilience Guide; Protective Security Requirements obligations apply alongside the NZISM).
2. Jurisdictional and legal-access-regime analysis for the hosting country.
3. Classification-appropriate controls (encryption with agency-influenced key management, cleared-personnel access, agency-visible logging, supplier assurance evidence as above).
4. **ITSM/CISO certification review**, followed by **formal risk acceptance by the Accreditation Authority / agency head** — recorded in the accreditation record — before go-live, if the data is Restricted or above.

## Step 7: Ongoing Assurance (Post-Contract)

- **Annual reassessment** of the vendor's security posture and updated assurance evidence.
- **Monitoring of vendor security advisories** and any disclosed incidents throughout the contract term.
- **Supplier risk register entry** — formally logged, reviewed, and updated as part of the agency's ongoing third-party risk management.
- **Formal risk acceptance for any residual gaps** — if the vendor cannot meet a specific requirement (e.g., no agency-controlled keys available), document the gap and obtain explicit risk acceptance from the appropriate authority rather than proceeding silently.

## Relevant NZISM References
Cloud/offshore hosting: **Chapter 22 (Enterprise Systems Security), Section 22.1 Cloud Computing**, including control **22.1.23.C.01 (System availability)**. Access control and privileged access integration requirements: **Chapter 16 (Access Control and Passwords / v3.9: Authentication and Access Controls)**, including **16.1.46.C.02** (account suspension) and **16.3.5.C.02** (privileged account use). Third-party supplier obligations generally: **Chapter 13, Third-Party Suppliers**. For control numbers not listed here, confirm the current citation against the online manual (nzism.gcsb.govt.nz), as the NZISM is updated roughly twice a year.

---
*This is general compliance guidance, not legal advice. Confirm current NZISM control numbering and PSR requirements against official sources, and have procurement/legal counsel review final contract language before execution.*

# NZISM-Aligned Due Diligence and Contractual Security Requirements for SaaS Procurement

## Purpose

When procuring a SaaS product for agency use, your agency remains accountable for the security of any government information processed by the vendor, even though the underlying infrastructure and application are managed by a third party. The following due diligence and contractual requirements are aligned to NZISM principles for outsourced/cloud service arrangements.

## 1. Pre-Procurement Due Diligence

### 1.1 Data Classification and Risk Assessment
- Determine the classification of data that will be stored/processed in the SaaS product (UNCLASSIFIED through RESTRICTED or higher). This drives the level of assurance required.
- Conduct a risk assessment covering confidentiality, integrity, and availability requirements for the data involved, and document it (feeding into your Security Risk Management Plan).
- Assess whether the SaaS product is fit for the classification level intended — some SaaS offerings may not be appropriate for RESTRICTED or higher information without additional controls.

### 1.2 Vendor Security Assurance
- Request evidence of the vendor's security posture: relevant independent certifications (e.g. ISO/IEC 27001, SOC 2 Type II), penetration testing results, and vulnerability management practices.
- Review the vendor's data centre/hosting arrangements, including sub-processors and where data is physically stored/processed (data sovereignty).
- Assess the vendor's incident history and any known past breaches.
- Where the SaaS product is offered via a hyperscaler (AWS, Azure, GCP, etc.), confirm the shared responsibility model — what security controls the vendor/platform provides versus what your agency must configure and manage.

### 1.3 Data Sovereignty and Offshoring
- Identify where data will be stored and processed, including backup/DR locations and any offshore sub-processors.
- If data will be held offshore, apply the same offshore risk assessment rigour as for any cloud hosting decision — legal jurisdiction risk, foreign government access laws, and NZ Government cloud policy expectations (via GCDO/DIA guidance).
- Confirm whether an All-of-Government (AoG) or existing government-negotiated arrangement covers this vendor, which may streamline (but not replace) due diligence.

### 1.4 Personnel and Supply Chain
- Assess vendor personnel security practices (background checks/vetting) for staff with administrative access to your data.
- Assess the vendor's own supply chain/sub-processor risk (fourth-party risk) — who else might touch your data.

## 2. Contractual Security Requirements to Impose

### 2.1 Data Handling and Classification
- Explicit contractual acknowledgement of the classification of data being processed and the corresponding handling obligations (aligned to NZISM classification handling requirements).
- Data minimisation — vendor must only collect/process data necessary for the service.
- Prohibition on secondary use of agency data (e.g. for vendor's own analytics, AI training, or marketing) without explicit written agency consent.

### 2.2 Security Controls
- Requirement for encryption of data at rest and in transit, using agency-acceptable standards.
- Requirement for strong access control on the vendor side — MFA, least privilege, logging of administrative access to agency data/tenancy.
- Right for the agency (or an independent auditor on the agency's behalf) to audit or request evidence of the vendor's compliance with these requirements periodically.
- Vulnerability and patch management obligations with defined remediation timeframes based on severity.

### 2.3 Data Location and Sovereignty
- Contractual commitment on data location (specific regions/data centres) and advance notification/agreement requirement before changing data location or adding new sub-processors.
- Restrictions or notification requirements regarding disclosure of agency data in response to foreign government/legal requests, to the extent achievable.

### 2.4 Incident Management
- Mandatory breach/incident notification clause with a defined maximum notification timeframe (e.g. within 24–72 hours of the vendor becoming aware) to the agency.
- Requirement for vendor cooperation in incident investigation, including provision of logs, forensic access, and root cause analysis.
- Clear escalation contacts and a joint incident response process, referencing your agency's obligation to report significant incidents to NCSC/CERT NZ and, where personal information is involved, the Privacy Act 2020 breach notification regime.

### 2.5 Business Continuity and Exit
- Defined service availability/continuity commitments (SLAs) appropriate to how critical the service is to agency operations.
- Data backup and disaster recovery commitments.
- Exit/termination clause guaranteeing return or secure destruction of agency data within a defined period, and data portability in a usable format, to avoid vendor lock-in and ensure a clean transition if the contract ends or the vendor is compromised.

### 2.6 Compliance and Audit Rights
- Right to audit (directly or via independent third party) the vendor's security controls, at least for higher-classification data or higher-risk services.
- Requirement for the vendor to promptly notify the agency of material changes to their security posture, ownership, sub-processors, or certifications.
- Flow-down clauses requiring the vendor's sub-processors to meet equivalent security obligations.

### 2.7 Personnel Security
- Where the SaaS product will handle RESTRICTED or higher data, contractually require that vendor personnel with administrative or data access hold appropriate clearances/vetting, or that compensating controls (e.g. logging, NZ-based support only) are in place.

## 3. Ongoing Assurance (Post-Contract)

- Incorporate the SaaS product into your agency's security risk register and System Security Plan / Security Risk Management Plan documentation.
- Schedule periodic reassessment of the vendor (e.g. annually, or upon renewal), including re-checking certifications and any reported incidents.
- Monitor for changes in the vendor's sub-processor list, ownership, or hosting location that might affect your risk position.
- Ensure the vendor is included in your agency's incident response and business continuity testing/exercises where the service is critical.

## Summary Checklist

- [ ] Data classification identified and risk-assessed
- [ ] Vendor certifications and security evidence reviewed (ISO 27001, SOC 2, etc.)
- [ ] Data location/sovereignty confirmed and offshore risk assessed if applicable
- [ ] Shared responsibility model understood and agency-side controls planned
- [ ] Contract includes encryption, access control, and audit rights clauses
- [ ] Contract includes mandatory incident notification with defined timeframes
- [ ] Contract includes data return/destruction and exit/portability provisions
- [ ] Sub-processor flow-down and change-notification clauses included
- [ ] Personnel security requirements included if handling RESTRICTED+ data
- [ ] Ongoing vendor reassessment scheduled post go-live

## Bottom Line

Your agency retains accountability for the security of its data even when using a SaaS product, so due diligence should assess the vendor's certifications, data location, and shared-responsibility posture before procurement, and the contract should lock in encryption, access control, breach notification, audit rights, sub-processor transparency, and clean exit/data-return provisions. The rigour of these requirements should scale with the classification of the data involved — treat any RESTRICTED-level use with the same seriousness as an offshore hosting or C&A decision.

*This is general guidance based on NZISM outsourcing/cloud principles. Confirm current NZISM control references and any All-of-Government procurement panel requirements with your agency's CISO/ITSM and procurement team before finalising vendor contracts.*

As of late 2026, Vietnam's personal data protection penalty regime is fully operative, and organisations face a layered exposure that combines the substantive obligations of Law No. 91/2025/QH15 (effective 1 January 2026) with the sanctions framework introduced by Decree No. 330/2026/ND-CP, which was issued and took effect on 19 August 2026 (82 articles, 33 of which deal specifically with personal data protection). This decree is the operative penalty instrument now — it implements the penalty mandate set out in Article 8 of Law 91/2025 and works alongside Decree 356/2025/ND-CP, which governs the underlying PDPIA and cross-border transfer impact assessment (CPDTIA) dossiers, the 60-day submission window to the Ministry of Public Security (A05), and the six-monthly update cycle.

The penalty tiers under Decree 330/2026 are calibrated to the severity and scale of the violation:

1. Serious cross-border violations — failure to file, concealment, or misdeclaration of a cross-border data transfer impact assessment where it results in a breach or loss of Vietnamese citizens' data — carry the heaviest exposure: a percentage of the organisation's prior-year Vietnam-market revenue. This is 1–2% for incidents affecting 10,000 to under 100,000 data subjects, 2–3% for 100,000 to under 1 million, and 3–5% for one million or more data subjects, or where there is national defence/security impact. Where the organisation has no Vietnam revenue, or the percentage calculation falls below a fixed floor, the decree substitutes fixed VND amounts: 200–500 million, 500 million–1 billion, and 1–3 billion respectively across the same tiers.

2. Unlawful data trading (Article 53) is penalized at 2–10 times the unlawful proceeds. Where proceeds cannot be determined, fixed fines of VND 500 million–1 billion apply where basic data of at least 10,000 people or sensitive data of at least 2,000 people is involved, rising to VND 1–3 billion where the conduct seriously affects national security, public order, the macroeconomy, or life, health, or dignity.

3. Administrative and procedural violations are penalized more modestly but are still material: plain non-filing or late updating of a CPDTIA dossier draws VND 30–50 million; consent violations (e.g., defective consent mechanisms) draw VND 30–50 million, rising to VND 50–70 million where silence is treated as consent or processing continues after consent withdrawal; PDPIA falsification or non-cooperation with the authority draws VND 50–100 million; and DPO appointment or qualification failures draw VND 10–30 million.

For all of these, individual violators are penalized at half the organisational rate.

Beyond fines, Decree 330/2026 empowers the Ministry of Public Security to impose remedial measures: suspension of processing activities or cross-border transfers, compulsory destruction of unlawfully processed data, disgorgement of unlawful proceeds, and confiscation of instrumentalities used in the violation. These remedial powers can be more operationally damaging than the fines themselves, particularly a suspension order against an ongoing cross-border transfer that a business depends on.

One important transitional nuance: conduct that occurred before 19 August 2026 is judged under whichever law was in force at the time, unless Decree 330/2026 happens to be more lenient — a standard "lex mitior" style transitional rule that benefits the violator only when the new regime is more favorable.

Practically, this means your compliance stack has three layers to manage simultaneously: Law 91/2025 for substantive obligations (consent, rights, security), Decree 356/2025 for the procedural PDPIA/CPDTIA mechanics and 60-day A05 filing, and Decree 330/2026 for what happens if you get any of that wrong. I'd recommend prioritizing your cross-border transfer filings and consent mechanism review first, since those carry the highest percentage-of-revenue exposure under the new decree. This is general compliance information, not legal advice — for a specific enforcement exposure assessment, consult Vietnamese counsel or an accredited assessor.

Vietnam's personal data protection regime has moved from decree-level rules (Decree 13/2023/ND-CP on Personal Data Protection) toward a full Personal Data Protection Law (PDPL), which the National Assembly has been advancing with an effective date around 2026. As of late 2026, the enforcement landscape blends the original Decree 13 penalty framework with sharper, law-backed sanctions that regulators (the Ministry of Public Security's Cybersecurity and Data Protection department, A05/A06) have signaled they will use more aggressively.

Administrative penalties: Under Decree 13 and its implementing sanctions decree (the amendments to Decree 15/2020 on ICT administrative penalties, updated via Decree 14/2022 and further revisions), fines for personal data violations have historically been capped in the hundreds of millions of VND per violation (roughly 100 million–500 million VND, i.e., approximately USD 4,000–20,000 per breach type). However, the PDPL introduces a notable shift long discussed in draft versions: revenue-based fines for serious or repeated violations, potentially up to 5% of a violating company's total revenue in the preceding fiscal year in Vietnam — mirroring the GDPR's turnover-based approach. This is the single biggest change data protection officers need to understand: penalties are no longer necessarily capped at a fixed low ceiling if the violation is deemed serious (e.g., unauthorized cross-border transfer of sensitive personal data, large-scale unauthorized disclosure, or repeated non-compliance after a warning).

Criminal liability: Vietnam's Penal Code (Article 288 on illegal provision or use of information on computer networks, and related provisions on trading in citizens' personal information) already criminalizes buying, selling, or illegally disclosing personal data, particularly financial and citizen ID data. Penalties can include fines up to several hundred million VND and imprisonment terms ranging from a few months up to 7 years for aggravated cases (e.g., data on 500+ people, or data used for fraud). Corporate officers and data controllers can face personal criminal exposure, not just the entity.

Administrative sanctions also commonly include: mandatory remediation orders, suspension of data processing activities, revocation of licenses for certain regulated sectors (telecoms, fintech, e-commerce platforms), public disclosure/naming of the violator, and confiscation of profits derived from illegal processing.

Sector-specific overlays: Banks and fintechs face additional exposure under State Bank of Vietnam regulations; telecom and OTT providers face MIC-specific sanctions; and any company operating in Vietnam without a Data Protection Impact Assessment (DPIA) dossier or Cross-Border Transfer Impact Assessment (TIA) on file, when one is legally required, faces an independent violation exposed regardless of whether an actual breach occurred — Vietnam's regime, unlike GDPR, penalizes procedural non-compliance (missing paperwork, missing consent records) even absent a breach or complaint.

Practical exposure for most mid-size foreign-invested companies: the realistic near-term risk isn't the theoretical 5%-of-revenue maximum but the base-tier administrative fines (typically 200–500 million VND per violation type, and violations are counted per data subject category or per incident, so they compound quickly), combined with mandatory corrective action orders that can halt data processing operations until remediated — often more costly in business disruption than the fine itself.

Recommendation: any company processing Vietnamese personal data should treat Decree 13/PDPL compliance as a documentation-and-process exercise first (DPIA dossier, consent records, data processing agreements, breach notification procedures within the 72-hour-equivalent window used in Vietnam), because enforcement to date has focused heavily on entities lacking basic compliance artifacts rather than on subtle interpretive violations. I'd recommend confirming the exact current fine caps and the PDPL's final effective provisions with a Vietnam-qualified lawyer, since implementing regulations and fine schedules were still being finalized through 2025–2026 and specific figures may have been adjusted in the final text.

Transferring Vietnamese customer data to a Singapore data center is a cross-border transfer under Article 20 of Law No. 91/2025/QH15, and it triggers a specific compliance workflow rather than an outright prohibition. Here is what applies and what is at stake if it is handled incorrectly.

Requirements

1. Impact assessment dossier: Before or promptly after you begin transferring data abroad, you must prepare a cross-border transfer impact assessment (CPDTIA) describing the data being transferred, the recipient (your Singapore entity or data center operator), the recipient's country, the purpose of the transfer, the security measures in place, and your risk mitigation approach.

2. 60-day filing: This dossier must be submitted to the Ministry of Public Security (the specialized personal data protection authority) within 60 days of the first transfer. If you have already been transferring data to Singapore, you should treat this as urgent — the clock is likely already running or has run out.

3. Six-monthly updates: The impact assessment must be refreshed every six months, or immediately whenever there is a material change — a new purpose, new categories of data, a new recipient, or a change in security measures (e.g., switching cloud providers or changing encryption key management).

4. Authority oversight: The Ministry retains the power to suspend or terminate the transfer if it determines there is a national security, public interest, or other significant risk. This means the arrangement is not "approve once and forget" — continued operation is conditional on the authority not intervening.

5. Possible exemption: If the Singapore transfer is solely for employee HR data in a cloud HR system, it may qualify for the Article 20 exemption (along with transfers by state agencies performing statutory functions, or transfers initiated directly by the data subject). Customer data transfers for general business/service purposes do not qualify for this exemption — you would need the full impact assessment.

6. Underlying data obligations still apply: Regardless of the transfer mechanism, you still need a valid legal basis for processing the underlying customer data (typically consent or contract performance), and if the Singapore data center is a processor, a written data processing agreement establishing that it processes only on your documented instructions, applies equivalent security measures, and deletes or returns data at the end of the relationship. If any of the transferred data falls into the 13 categories of sensitive personal data (e.g., financial/transaction data, biometric data), separate explicit consent for that category is required before transfer.

7. Cloud-specific controls: Because this is a cloud data center, Decree 356 Article 12 also applies — encrypt data at rest and in transit, limit the cloud provider's access to what's technically necessary, and conduct due diligence/security assessments of the provider (ISO 27001, SOC 2 certifications are good evidence).

What happens if you get it wrong

The consequences scale with the nature and impact of the failure, under the now-operative Decree 330/2026/ND-CP penalty framework:
- Simply failing to file the CPDTIA on time, or filing late updates, is treated as a plain procedural violation: VND 30–50 million.
- A serious violation — CPDTIA failure, concealment, or misdeclaration that results in an actual breach or loss of Vietnamese citizens' data — is penalized as a percentage of your prior-year Vietnam-market revenue: 1–2% for 10,000–100,000 affected data subjects, 2–3% for 100,000–1 million, and 3–5% for over 1 million or where there's a national security dimension. If you have no Vietnam revenue or the calculation falls below a floor, fixed fines of VND 200 million to 3 billion apply depending on scale.
- Beyond fines, the Ministry can order suspension of the cross-border transfer itself — meaning your Singapore data center arrangement could be forced to stop operating for Vietnamese customer data, which is often more disruptive than the fine.

My recommendation: treat the 60-day CPDTIA filing as the top priority action item, confirm whether any sensitive data categories are in scope (which changes your consent obligations), and formalize a data processing agreement with the Singapore provider if one isn't already in place. This is general compliance guidance, not legal advice — given the revenue-percentage exposure, I'd suggest validating your specific transfer facts with Vietnamese counsel before or shortly after filing.

Transferring Vietnamese customer personal data to a Singapore data center is a "cross-border transfer of personal data" under Vietnamese law, and it is one of the most heavily scrutinized areas of Decree 13/2023/ND-CP (and the newer Personal Data Protection Law that has been phasing in around 2026). Vietnam treats cross-border transfer as a distinct compliance event requiring its own documentation, separate from your general data protection compliance.

Core requirements:

1. Transfer Impact Assessment (TIA) dossier. Before transferring data overseas, the data controller (and, where applicable, the data processor and any third party receiving the data) must prepare a dossier assessing the impact of the cross-border transfer. This is commonly referred to as the Cross-Border Data Transfer Impact Assessment. It must document, among other things: the purpose of the transfer, the categories and volume of personal data involved, the recipient's legal and technical safeguards, and the laws of the receiving country regarding data access by its government.

2. Notification/filing with the Ministry of Public Security (MPS). Within a specified period (Decree 13 originally set a 60-day post-transfer filing requirement, and later drafts of the PDPL have discussed a requirement to file the TIA dossier with MPS before or shortly after the first transfer), companies must submit the TIA dossier for record, and in certain cases MPS can request more information or object to the transfer. This is a lighter-touch mechanism than an approval regime, but MPS retains audit and inspection rights and can require suspension of transfers found deficient.

3. Legal basis for transfer. You generally need either the data subject's consent to the specific cross-border transfer, or another recognized legal basis (contractual necessity, legal obligation, protection of vital interests) — consent alone for the domestic processing is not automatically treated as consent for overseas transfer; best practice is to make the cross-border transfer language explicit in your consent/privacy notice.

4. Data localization overlap. Some categories of data (especially data of Vietnamese citizens collected by certain regulated entities such as telecom, e-commerce with significant local users, and payment/fintech services) intersect with data localization rules under the Cybersecurity Law (Decree 53/2022), which can require at least one copy of certain data to be stored within Vietnam even if you also replicate to Singapore. Check whether your sector/data type triggers this.

5. Ongoing obligations after the initial transfer: you must keep the TIA dossier updated if the nature, volume, or recipient of the transfer changes, and you must be able to produce it on regulator request. A Singapore data center operated by a related entity or a third-party cloud provider (AWS, Azure, GCP Singapore region) still counts as a cross-border transfer even if it's an intra-group transfer with no external "sale" of data.

What happens if you get it wrong: Failure to prepare/file the TIA dossier, transferring without proper consent, or transferring restricted/localization-triggering data abroad without meeting local storage requirements are treated as distinct, separately punishable violations — meaning you could be fined for the transfer itself even if no data breach ever occurs. Administrative fines under the current framework run from roughly 100 million to 500 million VND per violation, with the PDPL introducing potential revenue-based fines (reportedly up to ~5% of Vietnam-derived revenue) for serious/repeat violations. Regulators can also order suspension of the transfer, require repatriation or deletion of unlawfully transferred data, and, for regulated sectors, escalate to license conditions. If the transferred data is later breached in Singapore, Vietnamese authorities will still hold the Vietnam-based controller primarily liable for notifying affected individuals and MPS, regardless of where the technical incident occurred — the compliance obligation follows the data subject's nationality/residency, not the server location.

Practical next step: commission (or have your DPO/legal team prepare) the TIA dossier now, formalize a data processing/transfer agreement with your Singapore data center operator that addresses Vietnamese-mandated safeguards, and confirm whether your data categories or sector trigger the separate localization requirement — this is the area where Vietnamese enforcement has been most active against foreign-invested companies.