The transition period for ISO/IEC 27001:2013 ends on 31 October 2025. After that date, certificates issued against the 2013 edition are no longer valid, regardless of when they were issued or when the next surveillance audit falls.
If you hold a 2013 certificate and have not scheduled a transition audit, this is the point to do it. Certification bodies are busiest in the months before a transition deadline, and audit slots become the constraint rather than your readiness.
What actually changed
The management system clauses — 4 to 10 — are substantially unchanged. If your ISMS is working, that part of your documentation largely survives.
The substantive change is Annex A, which was restructured against ISO/IEC 27002:2022:
- 114 controls became 93. Not by removing protection but by merging overlapping controls.
- 14 domains became 4 themes — organisational, people, physical and technological.
- 11 controls are new. These are where the work is.
- Controls now carry attributes — control type, information security properties, cybersecurity concepts, operational capabilities and security domains — intended to help with filtering and mapping.
The eleven new controls
Threat intelligence (5.7). Information security for use of cloud services (5.23). ICT readiness for business continuity (5.30). Physical security monitoring (7.4). Configuration management (8.9). Information deletion (8.10). Data masking (8.11). Data leakage prevention (8.12). Monitoring activities (8.16). Web filtering (8.23). Secure coding (8.28).
Most organisations find they were already doing several of these without documenting them as controls. Cloud services and configuration management in particular usually exist in practice; the gap is evidence, not capability.
The two that touch security testing
Worth calling out because they are where a penetration test becomes audit evidence:
A.8.8 — Management of technical vulnerabilities. Information about technical vulnerabilities in systems in use shall be obtained, exposure evaluated, and appropriate measures taken. Scanning, patching and testing evidence all land here.
A.8.29 — Security testing in development and acceptance. Security testing processes shall be defined and implemented in the development lifecycle. This is where penetration testing and secure code review are evidenced directly.
A current test report with retest results is among the cleanest evidence you can present against either.
What the transition involves
- Gap assessment against the 93 controls, focused on the 11 new ones.
- Update the Statement of Applicability. This is the document the auditor will scrutinise — it must reflect the 2022 Annex A structure with justifications for inclusion and exclusion.
- Close the gaps and generate evidence. Evidence needs to exist for long enough to be auditable; a control implemented the week before the audit is difficult to evidence as operating effectively.
- Transition audit, usually combined with a scheduled surveillance or recertification audit where timing allows.
A note on accredited scope
When arranging a transition audit, confirm that the conformity assessment body performing it holds accreditation for ISO/IEC 27001:2022 specifically — not merely for the 2013 edition. Accredited scope is published in the accreditation body’s public directory and is worth checking yourself before you commit.