ISO 27001:2022 vs 2013 — What Changed and How to Migrate

Published May 19, 2026 · AxVeil Compliance · 14 min read

ISO/IEC 27001:2022 was published in October 2022. The International Accreditation Forum (IAF) set a three-year transition window that closes on 31 October 2025 — every active 27001 certificate must now be on the 2022 standard. The major certification bodies (BSI, DNV, LRQA, TUV, Schellman) effectively stopped taking 2013 recertification audits in mid-2024 and locked all 2013 surveillance activity by spring 2025. If your last certificate is 2013 and you have not transitioned, you are out of certification scope. This article unpacks the Annex A restructure, the 11 new controls, the attributes model, and a 90-day playbook to land cleanly on the 2022 baseline.

The transition deadline and what cert bodies are actually doing

The IAF MD 26:2023 mandate is unambiguous: ISO/IEC 27001:2013 certificates are withdrawn on 31 October 2025. Every accredited certification body publishes its own cut-over calendar at least six months earlier so the accreditation body (UKAS, ANAB, NABCB, RvA, JAS-ANZ) can close out paperwork. By the second half of 2024, recertification under 2013 was unavailable from the top tier of cert bodies; by early 2025, even transition audits were scarce and command a premium because demand spikes against fixed auditor capacity. Organisations that transitioned in 2023 / early 2024 paid the lowest fees and had the most scheduling flexibility. Starting now, expect a 60-to-90-day booking lead.

Headline changes at a glance

• Annex A restructure — 114 controls in 14 clauses (A.5 – A.18) became 93 controls in 4 themes.
• 11 new controls — almost all of them addressing modern cloud, monitoring, data protection, and software-supply-chain risks.
• 24 merged controls — 57 separate 2013 controls were consolidated into 24 single 2022 controls where the practical guidance overlapped.
• 58 updated controls — re-worded, scope clarified, or alignment with newer references (ISO/IEC 27017, 27018, NIST 800-53 r5).
• 35 unchanged controls — the same intent, same scope, new identifier.
• Attributes — every Annex A control now carries five filterable attributes drawn from ISO/IEC 27002:2022.
• Clauses 4 – 10 — minor wording changes only; the management system architecture is intact.

The four themes

The Annex A:2022 controls now sit under four themes that map roughly to the actors and domains that have to operate the control:

• A.5 Organizational controls — 37 controls covering policies, roles, supplier relationships, classification, incident handling, continuity, and legal/regulatory hygiene.
• A.6 People controls — 8 controls covering screening, terms of employment, awareness, disciplinary process, off-boarding, NDAs, remote working, and event reporting.
• A.7 Physical controls — 14 controls covering perimeters, entry, monitoring, equipment, clear desk/screen, secure disposal, and utilities.
• A.8 Technological controls — 34 controls covering authentication, access, cryptography, secure development, monitoring, capacity, web filtering, secure coding, and a number of cloud and data-protection topics.

The 11 new controls (and why they exist)

Every one of the new controls is a direct response to a class of incident that was common between 2017 and 2022. Read the "why" column as an internal threat-model — if your environment exhibits the underlying risk, the control needs design and evidence, not just a checkbox in the SoA.

The 11 new controls are the findings magnets on a first transition audit. Build the evidence for each in advance — every one depends on operational metrics over a window of time, not on a point-in-time policy document.

2013 → 2022 sample mapping (high-impact controls)

Annex B of ISO/IEC 27002:2022 publishes the complete two-way mapping (2013 → 2022 and 2022 → 2013). Use that table verbatim when you rewrite your SoA — auditors check it row-by-row.

Clauses 4 – 10 — the management-system body

The management system requirements (Clauses 4 through 10) have only minor changes between 2013 and 2022 — there is no overhaul of the Plan-Do-Check-Act backbone, the risk-treatment process, or the certification life cycle. The shifts that do exist are worth knowing:

• Clause 4.2 — the requirement now explicitly asks which interested-party requirements will be addressed by the ISMS. A simple traceability table from regulator / customer / employee expectation to ISMS clause is sufficient and saves time on the audit.
• Clause 6.2 — objectives must be measurable and monitored. Several certification bodies treat "monitored" as a stricter requirement than 2013 — show period-over-period metrics, not just an annual review.
• Clause 6.3 — newly emphasised "planning of changes". Document how ISMS changes are themselves managed (governance change-control). Most teams already do this via the management-review minutes.
• Clause 8.1 — re-worded to clarify that outsourced processes remain within ISMS scope. If you have offshored ops or use MSSPs, the SLA + monitoring evidence is auditable.
• Clauses 9 & 10 — restructured (e.g. nonconformity & corrective action is now 10.1; continual improvement is 10.2). No new substantive requirements; renumbering only.

Attributes — the new tagging model

ISO/IEC 27002:2022 attaches five attributes to every Annex A control. The attributes are advisory — auditors do not test the attribute tagging itself — but they change how you operate the control library inside your ISMS tooling:

1. Control type — preventive, detective, corrective. Useful for balancing the SoA (a programme heavy on preventive controls but light on detective ones has a blind spot).
2. Information-security properties — confidentiality, integrity, availability. Filter the control set when you scope a new system: an availability-critical pipeline draws a different subset than a confidentiality-critical record store.
3. Cybersecurity concepts — identify, protect, detect, respond, recover. These are the NIST CSF verbs — Annex A:2022 explicitly imports them, which makes 27001-to-CSF mapping near-trivial.
4. Operational capabilities — 15 capability tags including governance, asset management, IAM, threat & vulnerability management, continuity, supplier relationships security, secure configuration, and so on. The capability dimension is how you carve the control set into team-ownership lanes.
5. Security domains — governance & ecosystem, protection, defence, resilience. The coarsest of the five and the one you will use least operationally.

The most concrete use of attributes is in GRC tools (Drata, Vanta, OneTrust, Strike Graph) — every modern platform filters and reports on the attribute dimensions natively. If your ISMS lives in a spreadsheet, add five columns next to each control and complete them once from the 27002:2022 reference text. Half a day of work, permanent dividend.

The 90-day migration playbook

For organisations that already hold a 2013 certificate and need to land cleanly on 2022, this is the schedule we run. It assumes a single ISMS scope and a competent internal owner (CISO, head of compliance, or equivalent). Multi-scope or multi-entity programmes scale the timeline linearly.

Days 0 – 14: Gap assessment against the 11 new controls

Start with the 11 new controls because they are where almost all the work lives. For each control, write down: the owner, the current state, the design intent, and the evidence sources. A simple traffic-light tracker against the 11 IDs above is fine — the point of this exercise is honest scoping, not pretty deliverables. Do not be tempted to map every existing 2013 control first; that is wasted motion at this stage because the 2013 control text largely carries over and the merged/renamed controls are mechanically translatable.

Expect the gap assessment to expose between three and six control areas that need design, not just documentation. The most common gaps are: A.5.7 (no intel intake process), A.8.9 (no documented baselines / no drift detection), A.8.12 (no DLP at all on at least one egress channel), A.8.16 (a SIEM exists but no documented use cases), and A.8.28 (secure coding policy exists but no enforced static analysis in CI).

Days 15 – 45: Design & build to close gaps

Run the work as a single Jira / Linear epic so management review has a single status artifact. Each gap closes with a triplet: a policy or procedure update, a technology change or configuration, and an evidence stream that will be present at audit time. The evidence stream is the key — auditors will not accept "we deployed X on day 60" for a transition audit on day 90. You need at least 30 – 60 days of operating evidence. Start the evidence clock as early as possible.

For organisations doing this work alongside a parallel SOC 2 programme, there is heavy overlap. Many of the new 2022 controls — A.5.7, A.8.9, A.8.16, A.8.28 — have direct SOC 2 trust-services-criteria equivalents (CC7.x for monitoring, CC8.x for change management). Reuse the evidence streams. See our companion piece on the SOC 2 readiness checklist for the overlap mapping.

Days 30 – 60: Statement of Applicability rewrite

Rebuild the SoA from the 27002:2022 control list. For each of the 93 controls, record: applicability (yes/no), the justification for inclusion or exclusion, the linked policy/procedure, the linked evidence locations, and the owner. Use the official Annex B mapping table to migrate the 2013 references. Do not delete the old SoA — keep it as a controlled archived document so the audit trail is intact.

A common stumble is forgetting that "not applicable" needs a defensible justification. "We do not use cloud services" is rarely true in 2026 and the auditor will challenge it. "We have no internally developed software" only flies if you really have no developers of any kind — including no business-user low-code tooling, which sneaks in under most org radars.

Days 45 – 75: Internal audit & management review

Run the internal audit against the 2022 controls. Use a different auditor than the one who closed the 2013 surveillance — independence matters and the cert body will check. Track findings in the same nonconformity log; close them or accept the risk before management review. Management review must cover the new clause requirements (planning of changes — Clause 6.3) and explicitly approve the new SoA. The minutes are evidence.

Days 60 – 90: Cert-body transition or recertification audit

Coordinate with your cert body for a transition audit (typically 1 – 2 days of effort on top of the surveillance cycle for organisations under 500 staff, more for larger scopes). The auditor reviews the new SoA, the 11 new-control evidence streams, the internal audit / management-review records, and samples a handful of 2022 controls in depth. If the cert body has already moved you past the 2013 stop date, you may need a full recertification rather than a transition audit — pricing is usually 1.5x to 2x a transition audit so budget accordingly.

Common stumbles

• Mis-mapped 2013 → 2022 controls in the SoA. The 24 merged controls are where this happens most often. Do not improvise the mapping — paste it from Annex B of 27002:2022.
• Late SoA. Treating the SoA as a closing artifact rather than the first deliverable. The auditor wants to see the SoA before they walk into the kick-off — it tells them which controls to sample.
• Evidence rot on the new controls. Building the control on day 45 and going to audit on day 60. There is no operating evidence to test. Push evidence-generating work to the start of the 90-day window even if the policy is not yet ratified.
• Treating attributes as auditable. They are not. Spending hours debating whether A.8.16 is "preventive" or "detective" (it is detective) is interesting only if you are designing your control library — auditors will not test the attribute itself.
• Ignoring the cloud control (A.5.23). Even small organisations now use a long tail of SaaS — payroll, expense, document management, video. The control applies to all of them, not just the production cloud accounts.
• Forgetting Clause 6.3. "Planning of changes" is new. Have a one-paragraph procedure that says ISMS changes go through the same change-control process as IT changes, and reference it in management-review minutes.

How AxVeil supports the transition

Our compliance engineering team has run dozens of 27001:2013-to-2022 transitions through 2024 and 2025, and we built our delivery model on the 90-day playbook above. The services we run on engagements:

• Gap assessment against the 11 new controls — output is a single tracker and a fixed-effort closure plan.
• SoA rebuild against the 27002:2022 control list with Annex B mapping.
• Evidence-stream design for A.5.7 / A.8.9 / A.8.12 / A.8.16 / A.8.28 — the controls that fail first audits.
• Internal audit and pre-audit dry-run.
• Coordination with the certification body to schedule the transition or recertification audit.

Engagements run as either fixed-fee transition projects or as part of a wider compliance advisory retainer. For first-time ISO 27001 certifications we recommend reading our SOC 2 vs ISO 27001 — which first primer before scoping the work, and pairing the audit with a current VAPT engagement to keep A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance) on evidence.

FAQ