The 2022 revision of ISO/IEC 27001 produced a lot of noise about control counts and comparatively little about what actually matters, which is whether your Statement of Applicability still says something true. This article separates the structural change from the substantive change.
The structural change
Annex A was reorganised from 114 controls across fourteen domains into 93 controls across four themes: organisational (37), people (8), physical (14) and technological (34). Most of the reduction is consolidation — controls that addressed the same objective from different angles were merged. Very little was deleted outright.
Each control also gained attributes — control type, information security property, cybersecurity concept, operational capability and security domain — intended to help organisations filter and map controls to other frameworks. The attributes are informative, not requirements, and an auditor will not ask you to populate them.
The eleven new controls
| Control | What it addresses |
|---|---|
| 5.7 Threat intelligence | Collecting and analysing information about threats relevant to your context |
| 5.23 Information security for use of cloud services | Acquisition, use, management and exit from cloud services |
| 5.30 ICT readiness for business continuity | ICT continuity planned against business continuity objectives |
| 7.4 Physical security monitoring | Continuous monitoring of premises for unauthorised access |
| 8.9 Configuration management | Establishing, documenting and monitoring secure configurations |
| 8.10 Information deletion | Deleting information no longer required, including from third parties |
| 8.11 Data masking | Masking in line with access control policy and business requirements |
| 8.12 Data leakage prevention | Measures applied to systems, networks and devices processing sensitive information |
| 8.16 Monitoring activities | Monitoring networks, systems and applications for anomalous behaviour |
| 8.23 Web filtering | Managing access to external websites to reduce exposure to malicious content |
| 8.28 Secure coding | Applying secure coding principles to software development |
Two of these deserve particular attention because organisations consistently underestimate them. Control 5.23 on cloud services is not satisfied by a cloud provider’s own certification — it asks about your processes for acquiring, configuring, managing and exiting cloud services, which is your responsibility under every shared responsibility model. And control 8.10 on information deletion is genuinely difficult in practice: it includes information held by third parties, which means your processors and your backups.
Rebuilding the Statement of Applicability
The SoA is where transition work actually lands. It is not a mapping exercise. The requirement is that control selection is driven by risk treatment, and that inclusions and exclusions are justified.
- Revisit the risk assessment first — the new controls exist because the threat landscape changed, and your risk register probably should too
- Map existing controls to the new Annex A structure, noting that merged controls may now cover more than your implementation does
- Assess each of the eleven new controls against your risk assessment and decide, with reasoning, whether it applies
- Write the justification for every inclusion and every exclusion — "not applicable" without a reason is the most commonly raised SoA finding
- Update the risk treatment plan so that it and the SoA agree with each other
Transition status
The transition period for organisations certified to ISO/IEC 27001:2013 ended on 31 October 2025. Certificates against the 2013 version are no longer valid. Organisations that did not transition require initial certification against the 2022 version rather than a transition audit.