The 2022 revision restructured Annex A from 114 controls to 93 across four themes. If you hold a certificate to the old version, the work is mostly re-mapping rather than rebuilding.
ISO/IEC 27001:2022 was published in October 2022. The requirements clauses changed relatively little. Annex A changed a great deal, and that is where the transition effort sits.
What actually changed
The old Annex A had 114 controls in 14 domains. The new one has 93 controls in four themes:
- Organisational controls (37)
- People controls (8)
- Physical controls (14)
- Technological controls (34)
The count went down because controls were merged, not because requirements were dropped. Fifty-seven of the old controls were consolidated into 24 new ones. A small number were genuinely new.
The new controls
Eleven controls were added, and they are the ones worth reading properly because they reflect how attacks and infrastructure have actually changed:
- Threat intelligence
- Information security for use of cloud services
- ICT readiness for business continuity
- Physical security monitoring
- Configuration management
- Information deletion
- Data masking
- Data leakage prevention
- Monitoring activities
- Web filtering
- Secure coding
Two of those catch most organisations out. Cloud services is now explicit rather than something you inferred from supplier management, and it expects you to have thought about the security implications of each service you use and how you would exit it. Information deletion is the other, because it asks you to demonstrate that data is actually removed when it should be, which is harder than it sounds once you count backups.
Attributes: useful, not mandatory
The 2022 version introduces attributes for each control, tagging them by control type, information security property, cybersecurity concept, operational capability and security domain. These are a way of viewing and filtering the controls, not additional requirements. You do not have to use them. Some organisations find them useful for reporting to a board.
The clause changes
The main clauses changed less than people expect. The notable additions are an explicit requirement to determine how interested party needs will be addressed, a requirement to plan changes to the ISMS rather than making them ad hoc, and tightened wording around defining processes and their criteria in clause 8.
What a transition actually involves
In practice, five steps:
- Re-map your Statement of Applicability. This is the bulk of the work. Every existing control needs mapping to its new reference, and the SoA needs rebuilding around the new structure. ISO publishes a correspondence table that makes this mechanical rather than difficult.
- Assess the eleven new controls. For each, decide whether it applies and, if so, what you already do and what is missing. Most organisations find they are already doing several of them without documenting it.
- Close the genuine gaps. Usually cloud services, information deletion, and secure coding if you develop software.
- Update the risk assessment so treatments reference the new control identifiers.
- Run an internal audit against the new version and take it through management review before your assessor sees it.
For an organisation with a functioning ISMS this is typically a few weeks of work rather than a rebuild. For one whose ISMS was never really operating, the transition tends to expose that, and the honest answer is that the underlying problem is the ISMS rather than the version.
If you are starting from scratch
Start on the 2022 version. There is no reason to implement a superseded edition. The structure is more logical than the old one, particularly the split into four themes, and the newer controls map more naturally onto how businesses actually run their IT now.
Our ISO 27001 consultancy covers the risk assessment, Statement of Applicability, Annex A controls and support through stage 1 and stage 2. If you already hold a certificate and want the transition handled, that is ongoing system support.
‹ Back to all articles