The transition window from ISO 27001:2013 to 27001:2022 closed in October 2025. Certificates issued against the 2013 version are no longer valid, and every certified organisation has either completed the transition or lost the certificate. The transitions completed under deadline pressure rarely produced the same ISMS quality as transitions completed earlier with adequate runway. Surveillance audits are now testing the converted systems, and the gaps that show up are predictable enough to characterise — and to remediate.
The Annex A Restructure Was the Visible Change
The 2022 update reorganised Annex A from 114 controls in 14 domains down to 93 controls in four themes — Organisational, People, Physical, Technological. The reorganisation looks substantial and is mostly cosmetic; the underlying control content largely persists from the 2013 version with some consolidation. Updating the Statement of Applicability to the new control numbering and themes is procedurally necessary and rarely the substantive transition challenge. Organisations that focused their transition effort here without addressing the new controls produced a paper-compliant transition that surveillance audits are now testing.
The Eleven New Controls That Matter
The eleven new controls introduced in 2022 reflect the threats and technologies that emerged after the 2013 version was written — 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, and secure coding. Each new control requires a substantive implementation, not just a Statement of Applicability entry. Organisations that wrote a single paragraph in their SoA for "we have data leakage prevention" without a substantive DLP programme are the ones whose surveillance audits are surfacing the gap.
Attributes and the Hashtag System
The 2022 version introduced control attributes — categorisations that classify each control by control type, information security properties, cybersecurity concepts, operational capabilities, and security domains. The attributes enable cross-cutting analyses that the previous flat structure did not support easily. Few organisations have used the attributes meaningfully in their ISMS operations, and the auditor expectation around them is modest. Where they have been used — for instance, to surface the controls that support a particular cybersecurity concept like protect or detect — they have added analytical value. Where they have not been used, no audit consequence has followed yet.
A pattern in 2022 transition surveillance audits: the organisation updated its Statement of Applicability to the new control numbering, mapped its existing controls to the 2022 themes, and addressed the new controls superficially in policy without operational implementation. The surveillance auditor samples the new controls and finds that threat intelligence is a vendor feed with no analyst engagement, data leakage prevention is a default-off configuration in the email platform, and secure coding is a policy paragraph with no developer practice behind it. The nonconformity is substantive even though the SoA is structurally compliant.
Cloud Services Treated as a Standalone Topic
Control 5.23, information security for use of cloud services, formalises an area that most organisations had been handling implicitly. The control expects the organisation to define how it acquires, uses, manages, and exits cloud services — with security considerations integrated throughout. Organisations that operate substantially in cloud environments cannot satisfy 5.23 with a single procurement policy; the control reasonably reads as a cloud security programme. Organisations that were already mature here had little additional work; organisations that were not are catching up under audit pressure.
Threat Intelligence as a Required Capability
Control 5.7, threat intelligence, expects organisations to collect and analyse information about threats relevant to them and use it operationally. The control does not prescribe sources or sophistication — a small organisation can satisfy it with sector ISAC participation and disciplined vendor advisory monitoring — but it does require the intelligence to inform something. SoA entries that describe threat intelligence as "monitoring of public sources" without evidence of operational consequence are the kind of paper compliance the new control was written to discourage.
A Post-Transition Remediation Programme
- Audit the eleven new controls substantively rather than relying on the post-transition Statement of Applicability
- For each new control, verify operational implementation, not just policy text
- Address cloud services as a programme — acquisition, usage, management, exit — rather than as a procurement clause
- Build threat intelligence into an operational rhythm that produces specific actions
- Implement data leakage prevention as a configured and monitored capability, not as a default control
- Treat secure coding as a developer practice with training, tooling, and review, not as a policy paragraph
- Use the surveillance audit findings to drive a genuine remediation programme rather than minimal closure
- Review the SoA annually to keep applicability statements aligned with operational reality
Why the Substantive Work Cannot Be Deferred
The certification body has discretion over how aggressively to test the new controls during surveillance, and that discretion is being applied more rigorously as the post-transition period matures. Organisations that complete substantive remediation now position themselves for clean surveillance audits and the next recertification cycle. Organisations that hope the auditor will continue to accept paper compliance are betting against the trajectory of audit rigour. The remediation effort is bounded and feasible; the alternative is escalating findings and eventual certificate risk.