Why ISO 27001:2022 Annex A matters more than it used to
When ISO/IEC 27001:2022 was published in October 2022, it brought the most significant restructuring of Annex A since the standard was first released. The old 2013 version had 114 controls across 14 domains. The new version has 93 controls across 4 themes. That sounds simpler, but the 2022 revision also introduced 11 completely new controls — many of them directly addressing modern threats: cloud services, remote working, threat intelligence, data masking, and secure coding.
If you're preparing for ISO 27001:2022 certification — or upgrading from a 2013 certification (the IAF transition deadline was October 2025, so all active certifications should now be against the 2022 standard) — understanding Annex A is non-negotiable. It drives your Statement of Applicability (SoA), your risk treatment decisions, and your Stage 2 audit evidence.
This guide covers: what changed from 2013, the 11 new controls in depth, what auditors actually check, and how to run a gap assessment that prepares you for certification.
What changed from ISO 27001:2013 to ISO 27001:2022
The 2022 revision wasn't a minor housekeeping update. Here's the structural change:
| ISO 27001:2013 | ISO 27001:2022 |
|---|---|
| 114 controls | 93 controls |
| 14 control domains (A.5–A.18) | 4 control themes (Organisational, People, Physical, Technological) |
| 35 controls from 2013 unchanged | 58 controls merged from multiple 2013 controls |
| 1 control deleted (A.11.2.5 — removal of assets, now merged) | 11 new controls added |
The restructuring into four themes (A.5 Organisational, A.6 People, A.7 Physical, A.8 Technological) makes the standard more intuitive to navigate. But the 11 new controls are where organisations most often have gaps — they represent the areas where 2013 implementations typically had no explicit coverage.
The 11 new ISO 27001:2022 controls explained
These are the controls that didn't exist in ISO 27001:2013. If you're upgrading from a 2013 certification, these are your primary gap-assessment targets:
A.5.7 — Threat intelligence
This control requires a formal threat intelligence process — not just subscribing to a threat feed, but collecting, analysing, and acting on threat intelligence relevant to your organisation. The intelligence must feed into your risk assessment process (Clause 6.1.2). Useful sources include MITRE ATT&CK, sector-specific ISACs (Information Sharing and Analysis Centers), ENISA's annual threat landscape, and commercial threat feeds.
Auditor expectation: documented threat intelligence process, subscriptions to relevant feeds, evidence that threat intelligence informed recent risk assessments. A zero-evidence situation ("we just check the news") is a finding.
A.5.23 — Information security for use of cloud services
ISO 27001:2013 was pre-cloud-first. A.5.23 explicitly requires a process for selecting, using, managing, and exiting cloud services. It covers: cloud risk assessment before adoption, shared responsibility model documentation, cloud provider security certifications review (SOC 2 Type II, ISO 27017), and exit/portability planning for critical services.
Many organisations have dozens of cloud services in use with no registry, no exit plan, and no documented shared responsibility understanding. This is consistently one of the top findings in transition audits.
A.5.30 — ICT readiness for business continuity
This control focuses specifically on technology readiness within your BCM programme. It requires defined RTOs and RPOs for critical systems, tested through documented exercises. The test results must be retained. This overlaps with DORA Art. 12 for financial entities — if you're subject to DORA, your ICT continuity testing programme likely already satisfies A.5.30.
Auditor expectation: written RTOs/RPOs for critical systems, DR test plans and results (with pass/fail assessment), date of last test. A DR plan that's never been tested doesn't satisfy A.5.30.
A.5.24 — Information security incident management planning and preparation
The 2022 standard restructured incident management into four distinct controls (A.5.24 through A.5.28). A.5.24 specifically covers the planning and preparation phase: documented Incident Response Plan (IRP), defined IR team roles and responsibilities (RACI), escalation paths, communication procedures, and evidence of IRP testing.
A.5.29 — Information security during disruption
A frequently overlooked control — it requires that your security controls remain effective during disruptive events. When you activate your BCP, do your access controls, monitoring, and authentication controls still work? Emergency access procedures must still enforce authorisation. Remote-only operations during an incident must maintain endpoint security.
A.6.7 — Remote working
Post-pandemic, this is now an explicit control. It requires a documented remote working policy covering: VPN or ZTNA requirements for corporate access, MDM/endpoint management for remote devices, clean desk requirements in home offices, screen privacy, secure disposal of printed materials at home, and visitor considerations in home offices. BYOD for remote work must be addressed separately.
Auditor expectation: remote working policy signed by employees, evidence of VPN/ZTNA enforcement, MDM enrolment records for all devices used for remote work.
A.6.8 — Information security event reporting
The reporting mechanism must be widely known and genuinely accessible. Near-misses and suspicious activity (not just confirmed incidents) must be in scope. A zero-incident-report history is a red flag for auditors — it suggests either no incidents occurred (unlikely) or that people don't report (likely). The control requires a no-blame culture to be actively promoted.
A.7.4 — Physical security monitoring
Explicit coverage of CCTV and physical monitoring. If you use CCTV, it must comply with GDPR (DPIA, appropriate signage, defined retention period — typically 30 days unless justified). For cloud-first organisations, this control is often satisfied by reference to your colocation provider's or cloud provider's physical security certifications.
A.8.9 — Configuration management
Configuration baselines must be defined, documented, and monitored for drift. Industry standards to reference: CIS Benchmarks for operating systems, cloud services, and applications; DISA STIGs for US government-adjacent organisations; vendor hardening guides. For cloud environments, drift detection must be automated — tools like AWS Config Rules, Azure Policy, and GCP Security Command Center are the standard approach.
A.8.10 — Information deletion
Data that's no longer required must be securely deleted. This is critical for GDPR Article 17 (right to erasure) and Article 5(1)(e) (storage limitation). The challenging part: deletion must cascade to backups within your defined retention period. Simply deleting from the primary system while backups retain the data for 90 days doesn't satisfy GDPR or A.8.10.
A.8.11 — Data masking
Sensitive and personal data must not appear in test and development environments without masking or anonymisation. Production data exports for testing are a significant GDPR risk (purpose limitation Art. 5(1)(b), data minimisation Art. 5(1)(c)). Tokenisation, pseudonymisation, and synthetic data generation are the standard technical approaches.
A.8.12 — Data leakage prevention
DLP must cover outbound email scanning, cloud upload monitoring (CASB or native DLP), removable media, and printing. Policies must define what counts as sensitive data, what actions to block vs. alert, and how false positives are managed to prevent alert fatigue. This is one of the harder controls to implement well — a poorly tuned DLP that generates hundreds of false positives daily is almost worse than no DLP.
A.8.16 — Monitoring activities
Explicit monitoring requirements for networks, systems, and applications for anomalous behaviour. Must define: what is monitored, by whom, at what frequency, and what constitutes an alert. Alert SLAs must be defined and met. SIEM is the standard implementation. Zero-alert environments are a finding.
A.8.23 — Web filtering
DNS or proxy-based filtering to block malicious and high-risk categories. Particularly important for defending against phishing (credential harvesting sites) and malware distribution. DNS filtering tools (Cloudflare Gateway, Cisco Umbrella, Zscaler) provide logging evidence that auditors can verify.
A.8.28 — Secure coding
Explicit secure coding requirements referencing OWASP Top 10, OWASP Mobile Top 10, OWASP API Security Top 10, and SANS CWE Top 25. Language/framework-specific secure coding guidelines must be documented. Secure code review must be a mandatory step in the SDLC. Developer training records are key evidence.
A.8.29 — Security testing in development and acceptance
Security testing throughout the SDLC, including external penetration testing for significant new systems and after major changes. Penetration test findings must feed into a remediation tracker with defined SLAs. Retesting after remediation is required. Penetration test report without a remediation tracker is a finding.
The Statement of Applicability (SoA) — the most important document
The SoA is Clause 6.1.3 of ISO 27001 and is one of the first documents your Stage 1 auditor will review. It must list every Annex A control, state whether it's applicable or excluded, document the implementation status, and provide justification for any exclusions.
Common exclusion mistakes:
- Excluding A.7.x (Physical controls) for cloud-first organisations without proper justification. You can exclude physical controls for your own premises if you have none, but you need to document how your cloud/colocation provider satisfies the requirement via their certifications (ISO 27001, SOC 2 Type II). Simply writing "N/A — cloud company" is insufficient.
- Excluding A.6.3 (Screening) for small teams. You can apply proportionality arguments for micro-businesses, but auditors will scrutinise this. If you have staff with access to client data, screening is expected.
- Excluding new 2022 controls without evidence they're genuinely not applicable. An exclusion of A.8.11 (data masking) when you have developers using production data in test environments is a major non-conformity waiting to happen.
How to run a proper Annex A gap assessment
A gap assessment evaluates your current implementation against each control requirement and identifies what needs to be built, improved, or documented before your Stage 2 audit. Here's a practical process:
Phase 1: Understand the control requirements (don't use only ISO 27001)
ISO 27001:2022 defines the controls. ISO/IEC 27002:2022 provides the implementation guidance. You need both. ISO 27002 explains what each control means in practice, gives implementation examples, and clarifies what auditors expect to see as evidence. NIST SP 800-53 Rev 5 is a useful cross-reference for US-aligned organisations.
Phase 2: Assess each control — four statuses
For each control: Implemented (meets the control requirement with evidence), Partially implemented (some controls in place, gaps exist), Not implemented (no controls in place), or Not applicable (with documented justification). Document your reasoning and evidence sources for each.
Phase 3: Prioritise by weight
Not all controls carry equal audit risk. Controls that are Critical (access control, privileged access, vulnerability management, logging, encryption, incident management) are always auditor priorities. A not-implemented finding on a critical control is a potential major non-conformity (MNC) — which can block certification.
Phase 4: Build the remediation roadmap
Organise remediation into three phases:
- Phase 1 (0-3 months): Critical control gaps — anything that represents an MNC risk. Incident management plan, privileged access controls, MFA for all remote access, vulnerability management with defined SLAs, logging with SIEM, encryption policy.
- Phase 2 (3-6 months): High-priority gaps — security awareness training programme, supplier risk management framework, new 2022 controls (threat intelligence process, cloud services registry, remote working policy, configuration management).
- Phase 3 (6-12 months): All remaining controls implemented, internal audit completed, management review completed, SoA v2 finalised, Stage 1 audit documentation review, Stage 2 audit preparation.
What Stage 1 and Stage 2 auditors actually look for
Stage 1 (documentation review) — Your auditor will review: ISMS scope document, Information Security Policy (signed by management), SoA, Risk Assessment methodology and results, Risk Treatment Plan, all mandatory documented information from Clause 7.5 (policies, procedures, records). They're checking that your framework exists and is coherent — not yet whether it's working.
Stage 2 (implementation audit) — Your auditor will sample evidence that controls are actually working: access review records, training completion records, vulnerability scan reports and remediation records, incident log entries, penetration test reports, supplier assessments, change records, configuration compliance reports, physical access logs. "We have a policy for that" without evidence of it working is a finding.
Common major non-conformities (MNCs) that block certification:
- No management review records
- No internal audit conducted
- SoA not completed or excluding controls without justification
- No documented risk assessment or risk treatment plan
- Critical controls (access management, vulnerability management) not implemented
- No incident management plan
Assess your Annex A controls now
ComplyKit's free ISO 27001:2022 Annex A Controls Gap Assessment covers all four themes — Organisational (A.5), People (A.6), Physical (A.7), and Technological (A.8) — including all 11 new 2022 controls. Answer the assessment questions for each control, and the tool generates a detailed gap analysis with:
- Per-theme scorecard with certification readiness score
- Critical gap cards with specific audit risk and remediation actions
- Deep dive on the 11 new ISO 27001:2022 controls
- Statement of Applicability guidance
- Three-phase certification roadmap based on your status
- Certification body and Stage 1/Stage 2 audit preparation tips
→ Use the ISO 27001:2022 Annex A Gap Assessment free
Also useful: ISO 27001 High-Level Gap Assessment for an initial readiness check, or SOC 2 Gap Assessment if you're evaluating both frameworks.