ISO 27001:2022 Transition — What Auditors Actually Found

The Deadline Has Passed

October 31, 2025 was not a soft target. The International Accreditation Forum (IAF) mandated that all ISO 27001:2013 certificates would be invalidated after this date, with no extensions and no exceptions. Organisations that had not completed their transition audit by that deadline lost their certification entirely.

The scale of this transition was substantial. According to the ISO Survey of Certifications 2024, there were 96,709 ISO 27001 certificates worldwide — representing approximately 35% growth from the 71,549 certificates recorded in the 2022 survey. Early in 2024, Protiviti estimated that only around 25% of certified organisations had completed the transition, with projections suggesting roughly 75% completion by end-2024.

For any organisation that missed the deadline, the path forward is not a transition audit. It is full recertification — a materially different, longer, and more expensive process. We address this in detail below.

What Changed: The 2022 Revision in Numbers

ISO/IEC 27001:2022 restructured the control framework significantly. The changes are not merely cosmetic — they reflect a decade of evolution in the threat landscape and how organisations actually manage information security.

The four new themes replace the previous 14-domain structure:

The reduction from 114 to 93 controls is misleading if read as simplification. The 11 new controls address areas that were either absent or insufficiently covered in the 2013 edition, and auditors have scrutinised them heavily during transition assessments.

The Top Non-Conformances

Audit findings from the transition period reveal consistent patterns across certification bodies. The following categories represent the most frequently raised non-conformances, based on published guidance from BSI Group, DNV, SGS, URM Consulting, and Bridewell.

Statement of Applicability Failures

The Statement of Applicability (SoA) was the single most common source of non-conformances during transition audits. This is not surprising — the SoA is the document that maps every Annex A control to the organisation's risk treatment decisions, and the restructured control set required every SoA to be rebuilt.

Common findings included:

• Omitted controls without justification: Organisations excluded controls from their SoA but provided no documented rationale for the exclusion, as required by Clause 6.1.3(d).
• Invalid exclusions: Controls marked as "not applicable" when the risk assessment clearly indicated otherwise — particularly prevalent with the new technological controls.
• Scope misalignment: The SoA did not accurately reflect the certified scope of the ISMS, often because scope boundaries had shifted since the original certification.
• Lack of management ownership: No evidence that senior management had reviewed or approved the updated SoA.
• Set-and-forget approach: Organisations updated the SoA once for the transition audit but had no process for ongoing review as risks changed.

Risk Assessment Methodology

Auditors consistently flagged risk assessments that relied on copy-pasted templates rather than reflecting the organisation's actual environment. Generic risk registers with pre-populated threats and identical likelihood/impact ratings across disparate assets were treated as evidence of a non-functional risk process.

Access Control Implementation

Access control procedures that existed in policy but were not mapped to operational implementation. Auditors found gaps between documented access review cycles and evidence that reviews had actually occurred, particularly for privileged accounts and cloud service access.

Management Review Inputs

ISO 27001:2022 introduced new requirements for management review inputs under Clause 9.3.2(c), including explicit consideration of the needs and expectations of interested parties. Organisations that ran management reviews using their 2013-era agenda templates frequently missed this requirement.

Internal Audit Programme Coverage

Internal audit programmes that failed to cover all ISMS processes and controls within the audit cycle. Organisations often focused internal audits on operational controls while neglecting governance processes such as competence management (Clause 7.2) and documented information control (Clause 7.5).

The 11 New Controls — Which Ones Tripped Up Organisations

The 11 controls introduced in ISO 27001:2022 had no direct predecessor in the 2013 edition. For transition audits, these represented entirely new evidence requirements. The following controls generated the highest volume of audit findings, based on reporting from ISMS.online, High Table, and Advisera.

A.5.7 — Threat Intelligence

Organisations demonstrated that they collected threat intelligence — subscribing to feeds, receiving vendor advisories, monitoring sector alerts. What they could not demonstrate was action taken in response.

Auditors looked for what can be described as a "chain of action": threat intelligence sources feeding into analysis, analysis informing risk assessment updates, and risk assessment updates driving control adjustments. Organisations that consumed intelligence passively, without documented evidence of how it influenced their security posture, received non-conformances.

A.5.23 — Cloud Security

This was the most frequently audited of the new controls. The findings were consistent across certification bodies:

• Missing shared responsibility matrices: No documented agreement with cloud service providers (CSPs) on which party is responsible for which security controls.
• Cloud service inventory gaps: Organisations could not produce a complete inventory of cloud services in use, including data storage locations.
• No MFA on cloud management consoles: Administrative access to cloud environments without multi-factor authentication.
• Contractual gaps: Service agreements lacking right-to-audit clauses, incident notification obligations, or data location restrictions.

A.5.30 — ICT Readiness for Business Continuity

This control is entirely new — there is no 2013 predecessor. It requires organisations to ensure that their ICT infrastructure can support business continuity objectives.

The most common finding was what auditors described as a "golden thread" mismatch: the Business Impact Analysis (BIA) specified one set of recovery objectives while the Disaster Recovery Plan (DRP) documented materially different capabilities. For example, a BIA requiring a 4-hour Recovery Time Objective (RTO) for a critical system, while the actual backup restoration process required 24 hours.

Missing or outdated testing evidence compounded the problem. Organisations that had not tested their disaster recovery procedures within the audit cycle could not demonstrate that their stated recovery capabilities were achievable.

A.8.9 — Configuration Management

Auditors compared documented configuration baselines against the operational state of systems and found discrepancies. Hardening guides existed on paper but had not been applied consistently. Spot checks of live systems revealed configuration drift that the organisation had no process to detect or remediate.

A.8.12 — Data Leakage Prevention

Organisations implemented logging and monitoring of data flows but stopped short of active prevention. Auditors expected evidence of real-time detection and blocking capabilities — not merely retrospective analysis of data movement logs. Passive DLP implementations were flagged as insufficient.

A.8.16 — Monitoring Activities

Alert fatigue and detection without response were the dominant findings. Auditors asked a straightforward question: "Show me an alert that fired. Who investigated it? What was the outcome?" Organisations that could demonstrate detection but not documented investigation and resolution received non-conformances. The control requires not just monitoring, but evidence that monitoring outputs are acted upon.

A.8.23 — Web Filtering

Another entirely new control. The primary finding was poor exception management — organisations had web filtering in place but allowed bypass requests without documented justification or approval. Auditors expected a formal exception process: request, risk assessment, approval by an appropriate authority, time-limited allowance, and periodic review.

A.8.28 — Secure Coding

Secure coding requirements exposed significant gaps in development practices:

• No SAST integration: Static Application Security Testing not embedded in CI/CD pipelines.
• Missing SCA for dependencies: No Software Composition Analysis to identify vulnerable third-party libraries.
• Hardcoded secrets: Credentials and API keys found in source code repositories.
• No security-specific code review: Code reviews occurred but did not include security-focused review criteria.

If You Missed the Deadline

Organisations that did not complete the transition by October 31, 2025 face a fundamentally different path. Their ISO 27001:2013 certificates are now invalid, and they must pursue full initial certification against ISO 27001:2022 rather than a transition audit.

The differences are material:

Beyond the direct certification costs, the business consequences are significant. According to guidance published by A-LIGN and Ignyte Platform, organisations operating without a valid ISO 27001 certificate face:

• Contract termination risk: Customers whose agreements require ISO 27001 certification may exercise termination clauses.
• Procurement exclusion: Inability to participate in tenders that mandate ISO 27001 as a prerequisite.
• Regulatory non-compliance: In jurisdictions where ISO 27001 certification satisfies specific regulatory requirements (such as demonstrating "appropriate technical and organisational measures"), loss of certification creates a compliance gap.

The Compliance Trifecta: ISO 27001 + NIS2 + DORA

For organisations operating within the European Union, ISO 27001:2022 does not exist in isolation. The NIS2 Directive (Directive EU 2022/2555) and the Digital Operational Resilience Act (Regulation EU 2022/2554) impose overlapping but distinct requirements.

Analysis from DataGuard and CEEYU indicates that ISO 27001:2022 covers approximately 80% of NIS2 requirements. This makes it a strong foundation, but not a complete answer. The gaps are concentrated in three areas:

Incident reporting timelines differ significantly across the three frameworks:

ISO 27001 requires an incident management process but does not mandate specific reporting timeframes. Organisations relying solely on their ISMS incident procedures will not meet NIS2 or DORA notification deadlines without supplementary controls.

Supply chain security requirements under NIS2 Article 21(2)(d) and DORA's ICT third-party risk management framework go beyond what ISO 27001 Annex A controls require. Both regulations mandate specific due diligence on suppliers, contractual security requirements, and ongoing monitoring — with a level of prescriptiveness that exceeds ISO 27001's risk-based approach.

Management body accountability under NIS2 Article 20 and DORA Article 5 creates personal liability for senior management that has no equivalent in ISO 27001. Board members must approve ICT risk management frameworks and can be held personally accountable for compliance failures — a requirement that demands governance structures beyond what an ISMS typically provides.

The recommended approach, as outlined by GRC Solutions and DataGuard, is to use ISO 27001:2022 as the management system foundation and layer approximately 20% additional regulatory-specific controls to address NIS2 and DORA gaps.

Remediation Priorities

For organisations addressing audit findings or preparing for surveillance audits, the following prioritisation reflects the frequency and severity of findings reported across the transition period:

1. SoA accuracy and completeness — This is the gating item. An inaccurate Statement of Applicability will block certification regardless of how well individual controls are implemented. Ensure every control has a documented status with rationale, and that the SoA is reviewed and approved by management.

2. Cloud security controls (A.5.23) — The highest-frequency finding among the new controls. Prioritise shared responsibility documentation, cloud service inventory, and administrative access controls.

3. Secure coding practices (A.8.28) — Integrate SAST and SCA into CI/CD pipelines. Remove hardcoded secrets. Establish security-specific code review criteria.

4. Threat intelligence chain of action (A.5.7) — Document how threat intelligence inputs flow through to risk assessment updates and control adjustments. The evidence trail matters more than the sophistication of the intelligence sources.

5. Business continuity testing (A.5.30) — Align BIA recovery objectives with tested DRP capabilities. Conduct and document recovery tests within the audit cycle.

6. Monitoring response documentation (A.8.16) — For every alert category in your monitoring system, document the expected response procedure and maintain evidence of investigation outcomes.

Sources

ISO and Accreditation Bodies

• ISO Survey of Certifications 2024 — iso.org
• IAF MD 26:2023 — Transition requirements for ISO/IEC 27001:2022 — iaf.nu
• IAF Communique on transition deadline — iaf.nu

Certification Bodies and Auditor Guidance

• BSI Group — ISO 27001:2022 transition guidance — bsigroup.com
• DNV — ISO/IEC 27001:2022 transition overview — dnv.com
• SGS — ISO 27001:2022 changes and transition — sgs.com

Consulting and Advisory Firms

• URM Consulting — Common ISO 27001:2022 audit findings — urm.co.uk
• Bridewell — ISO 27001:2022 transition observations — bridewell.com
• Protiviti — ISO 27001:2022 transition readiness survey — protiviti.com

Compliance Platforms and Analysts

• ISMS.online — ISO 27001:2022 new controls analysis — isms.online
• High Table — ISO 27001:2022 auditor perspectives — hightable.io
• Advisera — ISO 27001:2022 implementation guidance — advisera.com

NIS2 and DORA Alignment

• DataGuard — ISO 27001 and NIS2 mapping — dataguard.com
• CEEYU — NIS2 and ISO 27001 overlap analysis — ceeyu.io
• GRC Solutions — Integrated compliance approach — grcsolutions.com.au

Post-Deadline Guidance

• Ignyte Platform — ISO 27001:2022 recertification after deadline — ignyteplatform.com
• A-LIGN — Post-transition compliance options — a-lign.com
• StrongDM — ISO 27001:2022 transition impact — strongdm.com