Your certification body won't accept your old Statement of Applicability forever. If you certified against ISO 27001:2013, your ISMS documentation references 114 controls across 14 domains. The 2022 revision restructured everything: 93 controls across 4 themes, with 11 entirely new controls that didn't exist before. The transition deadline of 31 October 2025 has passed. If you haven't updated your SoA, control mappings, and evidence packs, your next surveillance audit is going to be uncomfortable.
The changes aren't cosmetic. ISO 27001:2022 Annex A controls reflect how organisations actually operate now — cloud-first infrastructure, remote workforces, threat intelligence as a function, and data masking as a named requirement. Auditors are already asking for evidence against the new control set. "We're still on the 2013 structure" stopped being an acceptable answer months ago.
This post breaks down what actually changed in Annex A 2022, which new controls require immediate attention, and how to update your ISMS without rebuilding from scratch.
The Structural Overhaul: From 14 Domains to 4 Themes
The 2013 version organised controls into 14 domains: access control, cryptography, physical security, and so on. The 2022 revision collapses everything into four themes: Organisational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). Same total scope, different architecture.
This matters for your documentation. Your existing SoA probably maps controls to the old A.5 through A.18 structure. Auditors now expect mapping to A.5 through A.8 — the four new themes. You need a crosswalk document showing how your existing controls satisfy the 2022 requirements, and where gaps exist.
The good news: most existing controls map directly. A.9.1.1 (Access control policy) from 2013 becomes A.5.15 (Access control) in 2022. The bad news: 11 controls are genuinely new, and you cannot satisfy them by pointing at existing documentation.
The 11 New Controls You Cannot Ignore
These are the security controls that didn't exist in the 2013 framework. If your ISMS predates October 2022, you have gaps here:
- A.5.7 Threat intelligence — You need a documented process for collecting, analysing, and acting on threat intelligence. Subscribing to an NCSC feed isn't enough; show how intelligence reaches decision-makers.
- A.5.23 Information security for use of cloud services — Explicit requirements for cloud service acquisition, use, management, and exit. Your AWS or Azure deployment needs documented security requirements, not just a procurement checkbox.
- A.5.30 ICT readiness for business continuity — Goes beyond traditional BC/DR. Demonstrate that your technology stack can actually support continuity requirements, with tested recovery capabilities.
- A.7.4 Physical security monitoring — Continuous monitoring of physical premises. CCTV alone doesn't satisfy this; you need documented monitoring procedures and response processes.
- A.8.9 Configuration management — Baseline configurations for all systems, documented and enforced. This catches organisations running production systems with default settings.
- A.8.10 Information deletion — Explicit control for secure deletion when data is no longer needed. Ties directly to GDPR Article 17 obligations.
- A.8.11 Data masking — Techniques to protect sensitive data in non-production environments. If your test databases contain real customer data, this control is screaming at you.
- A.8.12 Data leakage prevention — Technical and procedural measures to prevent unauthorised data exfiltration. DLP tooling or equivalent controls, with documented policies.
- A.8.16 Monitoring activities — Networks, systems, and applications must be monitored for anomalous behaviour. SIEM or equivalent, with defined alerting thresholds.
- A.8.23 Web filtering — Control access to external websites to reduce malware exposure. DNS filtering, proxy controls, or equivalent technical measures.
- A.8.28 Secure coding — If you develop software, you need documented secure coding practices. OWASP Top 10 awareness isn't sufficient; show training records, code review processes, and security testing.
Common Mistakes During Transition
Mistake one: treating it as a paperwork exercise. Some organisations update their SoA numbering and call it done. Auditors will ask for evidence. If your SoA now references A.5.7 (Threat intelligence) but you have no threat intelligence process, you've created a nonconformity where none existed before.
Mistake two: ignoring the attributes. ISO 27001:2022 introduces control attributes — control types (preventive, detective, corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts, operational capabilities, and security domains. These aren't mandatory for certification, but they're invaluable for demonstrating control coverage to auditors and management.
Mistake three: not updating risk assessments. Your risk treatment plan references specific controls. If those control numbers have changed, your risk treatment plan is now inconsistent with your SoA. This creates audit findings that should never have happened.
Mistake four: assuming cloud controls are covered elsewhere. A.5.23 (Cloud services) is explicit and specific. Pointing at your general supplier management process won't satisfy an auditor asking how you assessed your cloud provider's security posture before deployment.
Practical Implementation Steps
Start with a gap analysis against the 93 controls. Map your existing controls to the 2022 structure, identify the 11 new controls, and assess your current state against each. Be honest — "partially implemented" is acceptable; "we'll sort it before the audit" is not.
Update your Statement of Applicability. Every control needs a justification for inclusion or exclusion. The new controls require fresh justifications. A.8.28 (Secure coding) might be "not applicable — no in-house development" if you genuinely don't develop software. But if you have a single Python script in production, that justification collapses.
Build evidence packs for the new controls. Threat intelligence needs documented sources, analysis processes, and examples of intelligence informing decisions. Cloud security needs your cloud security policy, provider assessments, and configuration standards. Data masking needs your masking procedures and evidence they're applied to non-production environments.
Brief your internal auditors. They need to audit against the 2022 structure, not the 2013 one they've been using for years. Update your internal audit checklists before your next cycle.
How Pyralink Helps
Pyralink delivers ISO 27001 implementation and transition support grounded in operational experience. Michael Adedeji (CISM, CISA) has guided organisations through certification and surveillance audits — not from a template pack, but from understanding how auditors think and what evidence actually satisfies them.
For organisations running cloud infrastructure, CloudAuditX provides automated control assessments across AWS, Azure, and Google Cloud. It maps findings directly to ISO 27001:2022 Annex A controls, identifying where your cloud configuration creates gaps against A.5.23, A.8.9, or A.8.16 requirements.
Pyralink's vCISO service (from £497/month) provides ongoing ISMS governance — maintaining your documentation, preparing for surveillance audits, and ensuring your security controls evolve with the standard. Backed by £5M professional indemnity insurance.
Your next audit will assess against the 2022 structure. Get ahead of it.