ISO 27001:2013 vs ISO 27001:2022: What Changed and Why It Matters

If you're reading this, you're probably certified — or halfway through implementing — under the 2013 version of ISO 27001, and you need to know exactly what changed in the 2022 revision, why the change happened, and precisely what you must do before your certification lapses.

The Cold Open: A Recertification That Wouldn't Close

Dana Whitfield had run information security at Corvane Logistics for six years, and in that time she had never once had an audit finding roll over to the next cycle. So when her lead auditor, sitting across the conference table with his laptop angled slightly away from her, said the words "we can't close this as a straightforward recertification," she felt the floor tilt.

It was February 2024. Corvane's ISO 27001:2013 certificate was due to expire in five months, and its single largest customer — a global freight forwarder responsible for roughly $38 million of Corvane's annual revenue — had a contractual clause requiring "current and valid ISO 27001 certification" as a condition of the master services agreement. Not "ISO 27001 certification." Current and valid.

The problem wasn't that Corvane had let anything lapse. The problem was that the rules had changed underneath them. ISO had published ISO 27001:2022 back in October 2022, and the certification body Corvane used had already begun transitioning its accreditation. Recertification audits scheduled from mid-2023 onward were now expected to assess against the new Annex A control set — 93 controls organized into four themes — not the 114 controls across 14 domains that Corvane's Statement of Applicability had been built around for six straight years.

Dana had heard about the update. She'd filed away a vague sense that "some controls got merged" and moved on, because Q3 was budget season and there was a ransomware tabletop exercise to run and a new DPO to onboard. That vague sense turned out to be an expensive mistake. The gap assessment her consultant ran over the next three weeks turned up eleven controls in the new standard that Corvane's ISMS had never formally addressed — things like configuration management, data leakage prevention, and threat intelligence — plus a Statement of Applicability that still cited clause numbers and control groupings the auditor's checklist no longer recognized.

The recertification audit that should have taken two days took five, spread across seven weeks, with a major nonconformity raised against the missing controls. Corvane kept its certificate, but only after an unplanned $61,000 in consulting fees, a frantic six-week sprint to write and implement a cloud security policy that should have existed already, and a distinctly uncomfortable phone call to the customer's procurement team explaining why the "current and valid" certificate had an asterisk next to it for a month.

Dana's story isn't unusual. I've walked more than a dozen organizations through this exact transition since the 2022 revision dropped, and the pattern repeats: leadership treats a standard revision like a version-number bump, not a structural rewrite of the control framework that underpins the entire management system. It is a structural rewrite. This article exists so you don't have to learn that the way Dana did.

Who This Is For / What You'll Walk Away With

This article is for you if:

• You hold (or your organization holds) ISO 27001:2013 certification and haven't yet completed the transition to ISO 27001:2022.

• You're mid-implementation on the 2013 version and are deciding whether to pivot to 2022 now rather than certify against a superseded standard.

• You're a compliance manager, ISMS owner, vCISO, or internal auditor who needs a precise, defensible answer to "what exactly changed" for a board, a customer security questionnaire, or an audit committee.

• You've missed the transition deadline entirely and need to understand your current certification status and the fastest safe path forward.

By the end of this article, you will have:

1. A clause-by-clause understanding of what changed in the management system requirements (Clauses 4–10).

2. A precise map of the Annex A overhaul — the 11 new controls, the merges that took 114 controls down to 93, and the shift from 14 domains to 4 themes.

3. An understanding of the 5 attributes introduced in ISO 27002:2022 and why they matter beyond compliance theater.

4. A realistic transition timeline, including where things stand now that the original deadline has passed.

5. A concrete, phased transition action plan you can hand to your ISMS team this week — not a summary you read and forget.

If you want the foundational background first, our companion pieces on what ISO 27001 is and how the standard works, how ISO 27001 relates to ISO 27002, and the full history of the standard from BS 7799 onward are worth reading alongside this one. But if you're already certified or mid-implementation, stay here — this is the operational document.

Why ISO Revised the Standard at All

ISO standards run on a five-year systematic review cycle, and ISO/IEC 27001 was overdue. The 2013 version — itself a light restructuring of the 2005 original — had aged in ways that had nothing to do with grammar and everything to do with the threat landscape and the technology stack it was supposed to govern.

Three forces converged to push the revision through:

First, cloud computing had gone from an emerging risk to the default operating model. In 2013, "the cloud" was still something organizations debated moving workloads into. By the early 2020s, a majority of the organizations I assess run the bulk of their infrastructure, and often their entire ISMS scope, on someone else's servers. The 2013 Annex A had no dedicated control for cloud services. Auditors and practitioners had spent nearly a decade bolting cloud governance onto controls that were never designed for it — usually A.15 (Supplier Relationships) stretched well past its intended purpose.

Second, the threat landscape had industrialized. Threat intelligence sharing, security operations centers, and structured detection-and-response capability had moved from "nice to have" to baseline expectation in any mature security program, yet the 2013 control set had nothing that named threat intelligence, monitoring activities, or web filtering as first-class requirements. Data leakage prevention and data masking — now standard line items in any competent security architecture — were similarly absent by name.

Third, ISO wanted to harmonize the standard's structure with how ISO/IEC 27002 — the companion implementation guidance standard — was being reorganized, and to bring the management system clauses (4–10) into closer alignment with the Annex SL harmonized structure used across other ISO management system standards (ISO 9001, ISO 22301, ISO 45001, and so on). That harmonization is why the clause-level changes, while individually modest, matter: they make it easier to run an integrated management system across multiple ISO standards without duplicating documentation.

The result, published on 25 October 2022, is a standard that looks broadly familiar — the ten-clause structure is untouched, and roughly 80% of what your ISMS already does still applies — but whose control appendix has been substantially rebuilt.

"People kept asking me if 2022 was a 'minor update.' I told them: your clause structure barely moved, but your entire Annex A got gutted and rebuilt from the studs out. Call that whatever you want, just don't call it minor." — Priya Nandakumar, CISO, Fennimore Health Analytics

Annex SL Harmonization: Why the Clauses Now Read Like Every Other ISO Standard

If you've ever implemented ISO 9001 (quality), ISO 22301 (business continuity), or ISO 45001 (occupational health and safety) alongside ISO 27001, you'll recognize the ten-clause skeleton immediately — Context of the Organization, Leadership, Planning, Support, Operation, Performance Evaluation, Improvement. That's not a coincidence. ISO mandates a common high-level structure, identical core text, and common terms and definitions for all of its management system standards, under a framework practitioners still call Annex SL (formally Annex L in the current ISO/IEC Directives).

ISO 27001:2013 was already built on this harmonized skeleton, but the 2022 revision tightens the alignment further — the sub-clause splits in 9.2 and 9.3, the new 6.3 on planned change, and the tightened wording in 4.2 and 8.1 all bring ISO 27001 a notch closer to the current Annex SL template used across the family. For an organization running a single management system, this is mostly invisible. For an organization running an integrated management system spanning two or more ISO standards — increasingly common among manufacturers, logistics providers, and regulated service organizations — it matters a great deal, because shared procedures (document control, internal audit, management review, corrective action) can now be written once and referenced across every certified standard rather than duplicated per standard.

The practical payoff shows up at management review and internal audit. If your organization holds multiple ISO certifications, a single combined management review meeting and a single internal audit program covering shared processes is now easier to defend to an auditor than it was under the 2013 text, precisely because the clause language across standards is converging rather than diverging. For readers building or maintaining an integrated management system, this is worth a dedicated look — our forthcoming piece on Integrated Management Systems: ISO 27001 with ISO 9001, 22301, and 45001 goes deeper into how to structure shared documentation without triggering duplicate-effort audit findings.

The Clause-Level Changes: Modest but Real

Let's deal with the management system clauses first, because most transition conversations skip straight to Annex A and miss real, auditable changes in Clauses 4 through 10. None of these individually will blow up your ISMS, but an auditor checking your documentation against the 2022 text will flag every one of them if you haven't updated your references.

4.2 — Understanding the Needs and Expectations of Interested Parties. The 2022 version adds a third requirement: you must now determine which of the requirements of interested parties will be addressed through the ISMS. In 2013, you had to identify interested parties and their requirements. In 2022, you also have to explicitly decide — and document — which of those requirements your ISMS is actually going to address, versus which are handled elsewhere or not at all. This closes a gap auditors had complained about for years: organizations listing regulators, customers, and insurers as interested parties without ever stating which of their expectations the ISMS scope actually covers.

4.4 — Information Security Management System. The wording now explicitly requires the organization to determine the processes needed for the ISMS "and their interactions," reinforcing the process-based approach that Annex SL management standards are built around. It's a small wording change, but it gives auditors a hook to ask you to map your ISMS as a set of interacting processes rather than a static document set.

6.3 — Planning of Changes (new clause). This is the most substantive clause-level addition. It's a single sentence: "When the organization determines the need for changes to the information security management system, the changes shall be carried out in a planned manner." Short, but not trivial — it means any change to your ISMS (new scope, new technology, restructured risk methodology, merger and acquisition activity) now needs a documented, planned approach rather than an ad hoc update. I've seen this clause bite organizations that bolt on new business units without running a change-impact assessment against the existing ISMS.

5.3 — Roles, Responsibilities and Authorities. Minor wording tightened around "relevant" roles and reporting to top management, aligning with Annex SL language. Practically unchanged in substance.

7.4 — Communication. The 2013 version required you to determine what to communicate, when, with whom, and how. The 2022 version simplifies this by removing the "how" as a mandatory bullet, folding it into general communication planning. A minor simplification, not a substantive removal of obligation.

8.1 — Operational Planning and Control. The 2022 text adds explicit language requiring the organization to establish criteria for security processes and to implement control of those processes in accordance with the criteria — plus explicit reference to controlling "externally provided processes, products or services that are relevant to the ISMS." That last phrase is doing real work: it's ISO tightening the screws on supply chain and outsourcing governance, which dovetails with the new cloud services control in Annex A.

9.2 — Internal Audit. Split into 9.2.1 (General) and 9.2.2 (Internal Audit Programme) as a structural change aligning with Annex SL. No new substantive requirement, but your internal audit procedure documentation should reference the new sub-clause structure.

9.3 — Management Review. Split into 9.3.1 (General), 9.3.2 (Management Review Inputs), and 9.3.3 (Management Review Results), with an added required input: changes in the needs and expectations of interested parties that are relevant to the ISMS. This ties directly back to the 4.2 change — what you determine at 4.2 now has to resurface as a standing agenda item at management review.

10.1 and 10.2 — Reordered and Renamed. In 2013, 10.1 was "Nonconformity and Corrective Action" and 10.2 was "Continual Improvement." In 2022, they swap: 10.1 is now "Continual Improvement" and 10.2 is "Nonconformity and Corrective Action." It's an ordering and framing change more than a content change, but it signals ISO's intent — continual improvement as the standing, proactive clause; nonconformity handling as the reactive backstop underneath it.

Here's the clause-change summary in one table:

None of this alone justifies the anxiety I see in ISMS teams facing transition. But an auditor working from a 2022 checklist will ask about every row in that table, and "we didn't realize the clause numbering changed" is not an answer that keeps a recertification audit short.

The Big Story: Annex A Gets Rebuilt

Here's where the real work is. ISO 27001:2013 came with Annex A: 114 controls, organized into 14 domains numbered A.5 through A.18 (Information Security Policies, Organization of Information Security, Human Resource Security, Asset Management, Access Control, Cryptography, Physical and Environmental Security, Operations Security, Communications Security, System Acquisition/Development/Maintenance, Supplier Relationships, Incident Management, Business Continuity, and Compliance).

ISO 27001:2022 replaces that entire structure with 93 controls organized into four themes. (If you want a control-by-control reference beyond what this article covers, our companion Annex A Controls Deep-Dive: All 93 Controls Explained walks through each of the 93 individually with implementation notes.)

• Organizational controls — 37 controls, numbered 5.1 through 5.37

• People controls — 8 controls, numbered 6.1 through 6.8

• Physical controls — 14 controls, numbered 7.1 through 7.14

• Technological controls — 34 controls, numbered 8.1 through 8.34

That's a reduction from 114 to 93 — a drop of 21 controls on paper. But here's the fact that trips up nearly every team I've worked with on this transition: no control was deleted outright. Every security requirement that existed in the 2013 Annex A is still represented in 2022, in one form or another. The reduction came entirely from consolidation — 57 of the original 114 controls were merged together into 24 new, broader controls. The remaining controls carried forward with renaming and, in most cases, some degree of rewording to modernize the language, plus 11 genuinely new controls added to close gaps the 2013 version never addressed.

"Clients hear '114 down to 93' and assume they can delete 21 controls from their Statement of Applicability and call it a day. That's backwards. You're not doing less. You're doing the same work, organized differently, plus eleven new things you almost certainly weren't doing before." — Marcus Webb, Lead Auditor, Ashgrove Certification Body

From 14 Domains to 4 Themes: The Full Mapping

This is the mapping table every ISMS owner making this transition needs pinned to the wall. It shows where each 2013 domain's controls landed in the 2022 theme structure.

*ICT readiness for business continuity is listed as Organizational in the official 27002:2022 numbering (5.30), despite its technical subject matter — a reminder that theme placement follows ISO's categorization logic, not always intuitive subject grouping.

The lesson from this table: your Statement of Applicability cannot simply be relabeled. Every legacy control reference in your risk treatment plan, your internal audit checklist, your supplier due-diligence questionnaire, and your policy suite that cites "A.12.1.2" or "A.9.2.3" needs to be traced forward to its 2022 equivalent — and in the roughly 24 cases where multiple old controls merged into one new control, that tracing is a many-to-one mapping, not a simple renumbering exercise.

The 11 New Controls

These are the controls that did not exist in any form in ISO 27001:2013. If your ISMS was built and last reviewed before October 2022, there is a strong chance your Statement of Applicability has no corresponding control for most of these — which is exactly the gap that caught Dana Whitfield's team at Corvane Logistics.

Look at that list again as a set, not individually — nine of the eleven are heavily weighted toward technology operations (cloud, configuration, data handling, monitoring, filtering, coding), while only one is people-adjacent and one is physical. That distribution tells you where ISO believed the 2013 standard was thinnest: the operational and engineering layer of security, not the governance layer. Most organizations I assess already had reasonably mature policy and governance documentation under 2013; almost none had a documented secure coding standard, a formal data masking policy, or a defined configuration management baseline that an auditor could actually test against. Threat intelligence tends to be the least understood of the eleven by name even where a security team is quietly already doing pieces of it through vendor advisories and ISAC memberships — see our planned explainer, Threat Intelligence Under ISO 27001: Control 5.7 Explained, for how to formalize that into an auditable control.

"Every single client I've onboarded post-2022 has had at least six of these eleven controls operating informally — someone's doing configuration management, nobody's written it down. The transition audit isn't asking you to invent new security work. It's asking you to prove the work you're already doing is actually a control, with an owner, evidence, and a review cycle." — Elena Torres, ISMS Program Manager, Bracknell Financial Group

Deep Dive: 5.23 Cloud Services — the Control Most Auditors Probe Hardest

Of the eleven new controls, 5.23 draws the most auditor attention, because nearly every organization I assess has some cloud footprint but very few have a written policy addressing the full lifecycle ISO expects: acquisition criteria, ongoing management, monitoring of the provider's security posture, and — the piece almost everyone misses — a documented exit strategy if the relationship ends. Auditors increasingly ask a pointed question: "If your primary cloud provider terminated your contract with 30 days' notice, what does your documented exit process say?" If the honest answer is "we'd figure it out," that's a finding waiting to happen. A workable 5.23 policy names the shared-responsibility boundary explicitly, per provider, rather than assuming everyone already understands where the provider's responsibility ends and yours begins. Our planned deep-dive, Cloud Security Controls in ISO 27001:2022 (Control 5.23), walks through a sample exit-strategy document auditors have accepted in practice.

Deep Dive: 8.9 Configuration Management — Why IT Ops Resists Owning It

Configuration management is, on paper, the most straightforward of the eleven new controls: establish, document, monitor, and review secure configurations for hardware, software, services, and networks. In practice it's the one I see stall the longest, because it sits at the intersection of security and infrastructure teams, and neither wants to be the documented owner of a baseline the other team actually maintains day to day. The fix that works: treat your infrastructure-as-code repository (Terraform, Ansible, or equivalent) as the evidence source rather than asking someone to write a parallel configuration standard nobody will keep updated. If you're already defining baselines in code, 8.9 compliance is largely a documentation and review-cadence exercise, not a build-from-scratch one — a point our planned Configuration Management Control 8.9: Building the Baseline explainer covers in more detail.

Deep Dive: 8.28 Secure Coding — Proving It's More Than a SAST License

Organizations with a software development function often assume a static analysis tool subscription satisfies 8.28. It doesn't, on its own. The control expects documented secure coding principles — applicable both to in-house development and outsourced or third-party code — covering things like input validation standards, secure defaults, and a defined process for handling discovered vulnerabilities in code. Auditors will ask to see the actual coding standard document and evidence that developers were trained against it, not just a tool's dashboard. If your organization outsources development, 8.28 also expects contractual language requiring the vendor to follow equivalent secure coding practices — a clause many outsourcing agreements written before 2022 don't contain. Our companion piece, Secure Coding Control 8.28: What Auditors Look For, catalogs the exact evidence requests I've seen most often.

The Data Lifecycle Trio: Masking, Leakage Prevention, and Deletion

Three of the eleven new controls — 8.10 Information Deletion, 8.11 Data Masking, and 8.12 Data Leakage Prevention — work best understood as a single data lifecycle story rather than three unrelated line items. Deletion governs the end of data's useful life: do you actually purge records once retention obligations expire, or do they quietly accumulate in a data warehouse forever? Masking governs how sensitive data is represented when it's used outside its original, tightly controlled context — test environments, analytics pipelines, support tooling. Leakage prevention governs the boundary: technical controls that stop sensitive data leaving approved channels in the first place. Organizations under GDPR or similar privacy regimes typically have informal versions of all three already, driven by privacy rather than security requirements; the 2022 gap assessment is usually less about building new capability and more about formally documenting the security control ownership of work privacy or legal teams are already doing. I log this as one of the highest-leverage findings to fix, since it often means writing three policies rather than building three new technical capabilities. Our planned resource, Data Masking and Data Leakage Prevention Controls Explained, covers a template policy structure for all three at once.

Merged, Renamed, and Restructured: A Sample of the 24 Merges

Fifty-seven of the original 114 controls were consolidated into 24 new controls in the 2022 structure. Here's a representative sample — not the full list, but enough to show the pattern you'll encounter across your entire Statement of Applicability.

Roughly 58 remaining controls were carried forward largely unchanged in substance but frequently renamed or reworded for clarity — for example, "A.6.1.5 Information security in project management" became "5.8 Information security in project management" with only cosmetic wording changes, while "A.12.4.1 Event logging" became "8.15 Logging" with an expanded scope covering event logs across systems, applications, and services rather than just security events.

The practical consequence: your control-to-risk traceability matrix, your Statement of Applicability, your internal audit program, and every policy document that cites a specific Annex A control number needs a full crosswalk exercise. This is not a find-and-replace job. Some 2013 controls map one-to-one. Some map many-to-one. A handful (like ICT readiness for business continuity) effectively split conceptually from an existing domain into a new standalone control. Budget real analyst time for this, not an afternoon.

Extended Crosswalk Reference: More of the 114-to-93 Mapping

The sample above covers twelve representative merges. Because the full 114-to-93 crosswalk runs to several pages in ISO's own transition guidance, here is a second-tier reference table covering additional high-traffic controls that come up constantly in gap assessments — the ones your policy suite is most likely to still cite by their old numbers.

If your team is running this crosswalk manually, budget for the fact that roughly a third of your 2013 applicable controls will map cleanly one-to-one, a third will fold into a merged control alongside one or two others, and the remainder will carry a renaming that's cosmetic enough not to change your evidence but real enough that every document citation needs updating.

The Five Attributes: ISO 27002:2022's Quiet Innovation

Alongside the control restructuring, ISO 27002:2022 introduced something that didn't exist in any prior edition: a formal attribute taxonomy attached to every one of the 93 controls. Each control is now tagged against five attribute types, letting you filter and view the control set through different lenses depending on the audience you're addressing.

Why should you care about a tagging system? Two reasons that matter operationally.

First, the cybersecurity concepts attribute maps almost directly onto the five functions of the NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover), which means organizations juggling both ISO 27001 and NIST CSF alignment — common in defense supply chain and critical infrastructure sectors — finally have a built-in Rosetta Stone between the two frameworks rather than having to build one from scratch.

Second, and more practically: the attributes let you build custom views of your control set for different stakeholders. Your board doesn't need to see 93 controls; they can see a four-quadrant security domains view. Your engineering team doesn't need governance-level framing; they can filter to Technological controls tagged "Detect" and "Protect." I've used the attribute taxonomy to build audit-committee dashboards that would have taken a full consulting engagement to construct manually under the 2013 structure.

"The attributes are the most underrated part of this whole revision. Nobody talks about them because they're not a control count you can put in a press release, but they're the thing that actually makes the standard usable for cross-framework reporting." — Devon Achebe, vCISO, Larkhill Advisory

Cross-Framework Mapping: ISO 27001:2022 Alongside SOC 2, PCI DSS, and GDPR

Very few organizations I work with run ISO 27001 in isolation. Most are simultaneously managing a SOC 2 Type II attestation for enterprise customers, PCI DSS compliance because they touch cardholder data, and GDPR obligations because they process EU personal data. The good news buried inside the 2022 revision is that the new control set, and especially the cybersecurity concepts attribute (Identify, Protect, Detect, Respond, Recover), makes cross-framework mapping meaningfully easier than it was under the 2013 structure.

The new controls in particular close gaps that SOC 2 and PCI DSS assessors have been asking about for years, independent of ISO. Data leakage prevention (8.12) and data masking (8.11) map almost directly onto PCI DSS requirements around cardholder data protection and tokenization. Threat intelligence (5.7) and monitoring activities (8.16) map onto SOC 2's Common Criteria monitoring requirements. Information deletion (8.10) maps onto GDPR's storage limitation principle and right-to-erasure obligations almost control-for-control.

The practical move: build one evidence repository tagged by control and framework, not four separate audit binders. Organizations that maintain both ISO 27001 and SOC 2 certification, for example, routinely cut their combined annual audit preparation time by a third once they stop treating each framework's evidence collection as a standalone project.

Transition Timeline and the Deadline

ISO 27001:2022 was formally published on 25 October 2022. From that point, accredited certification bodies were given a defined transition window to update their own accreditation and begin auditing clients against the new standard, and organizations already certified to ISO 27001:2013 were given a transition period to move their certification across before the 2013 certificate ceased to be valid.

That transition period ran on a standard-set schedule, widely communicated across the certification industry as ending on 31 October 2025. Certificates issued or maintained against ISO 27001:2013 after that date are no longer valid under accredited certification schemes — meaning any organization still holding a 2013-only certificate today has, as a matter of fact, an expired or non-recognized certification, regardless of the date printed on the certificate itself.

If you are reading this well after that deadline and your organization has not transitioned, here is the blunt version: your ISO 27001:2013 certificate carries no accredited standing right now. Any customer, regulator, or procurement team checking your certificate against a certification body's public register or the accreditation body's directory will find it flagged as withdrawn or lapsed. This is not a paperwork nuance — contracts with "maintain valid ISO 27001 certification" clauses, cyber insurance policies with certification-contingent terms, and vendor risk assessments that gate on active accredited certification are all exposed the moment that gap is discovered.

If that's your situation, don't spend time mourning the missed deadline — move immediately to a gap assessment and, in most cases, a fresh initial certification audit against ISO 27001:2022 (transition audits are generally no longer available once the window has closed; check with your certification body, because a small number extended limited transition arrangements). The remediation plan later in this article applies whether you're mid-transition or starting from a lapsed position — the only difference is your certification body will likely require a two-stage initial audit rather than a lighter transition audit.

Common Transition Mistakes I See on Repeat

Across every transition engagement I've run, the failures cluster around the same handful of avoidable mistakes rather than genuinely novel problems. Naming them plainly is worth more than another paragraph of generic advice.

"I keep a one-line rule on my office whiteboard for every transition project: if a control exists only in someone's head, it doesn't exist. The 2022 revision didn't create that rule, it just made it impossible to hide from." — Renata Costa, ISMS Lead, Meridian Underwriters

The Step-by-Step Transition Action Plan

This is the section to bookmark. Whether you're mid-transition, haven't started, or discovered you're past the deadline, the sequence of work is the same — only the entry point and urgency differ. (If you want every phase below expanded into templates and checklists, our planned ISO 27001:2022 Transition Guide: Step-by-Step Roadmap is built specifically as the companion to this section.)

Step 1: Pull your current Statement of Applicability and risk treatment plan. You cannot plan a transition against a standard you haven't mapped your current state to. Get the actual documents in front of you, not a summary someone wrote two audit cycles ago.

Step 2: Run the crosswalk. Map every 2013 control currently marked "applicable" in your SoA to its 2022 equivalent, using the merge logic described above. Expect roughly a quarter of your applicable controls to now sit inside a merged control alongside one or two others — flag those for consolidated evidence review, not duplicate evidence collection.

Step 3: Gap-assess against all 11 new controls. For each of threat intelligence, cloud security, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding — determine whether you have (a) no coverage, (b) informal/undocumented coverage, or (c) documented coverage with evidence. In my experience assessing organizations through this transition, the median finding is "informal coverage, no documented control owner" for seven or eight of the eleven.

Step 4: Update your risk assessment methodology and risk register to reflect any new risk scenarios the new controls imply (for example, cloud service exit risk under 5.23, or insider data exfiltration risk under 8.12) even if your overall risk methodology itself doesn't need to change.

Step 5: Rewrite the Statement of Applicability from the 2022 control list, not by editing the old one in place. Reference both the new control number and, in an appendix or crosswalk column, the legacy 2013 control it maps from — auditors and your own team will thank you for the traceability during the transition audit cycle itself. (Our planned guide, Statement of Applicability (SoA): How to Write One, covers the exact column structure I use for this crosswalk appendix.)

Step 6: Update every downstream document that cites Annex A control numbers — policies, procedures, supplier questionnaires, internal audit checklists, training materials, incident response plans. This is the step teams most often underestimate in scope; expect to touch 15–40 documents depending on ISMS maturity.

Step 7: Train internal auditors and control owners on the new structure before running an internal audit against it. An internal audit conducted by auditors still thinking in 14-domain terms will miss gaps a certification body auditor working from the 2022 checklist will not.

Step 8: Run a full internal audit against ISO 27001:2022, treating it as a genuine gap assessment rather than a rubber-stamp exercise. Document findings and corrective actions with the same rigor you'd expect from an external audit.

Step 9: Schedule the transition audit (or, if past deadline, the initial certification audit) with your certification body, and be explicit with them about which path applies to your situation — do not assume; confirm in writing.

Step 10: Close corrective actions before the audit, not during it. Nonconformities raised for the 11 new controls are entirely avoidable with even a modest remediation runway (I typically see 8–14 weeks needed for genuinely undocumented new controls, faster if informal practice already exists).

"The organizations that struggled weren't the ones with weak security. They were the ones who treated the transition as a documentation exercise and skipped the internal audit dry run. You cannot find out about a nonconformity for the first time from the certification body auditor if you had eight months of runway to find it yourself." — Sarah Lindqvist, Head of Compliance, Northglen Payments

DIY Transition vs. Bringing in External Help

Not every organization needs a consultant to manage this transition, but the decision shouldn't be made on budget alone. The honest deciding factor is whether your ISMS team has bandwidth to run a genuine gap assessment against all 93 controls while still doing their day jobs, and whether anyone internally has been through a 2013-to-2022 transition before. Our planned comparison piece, Choosing Between DIY and Outsourced ISO 27001 Transition Support, walks through the decision in more depth than the summary below.

A middle path I recommend often: bring in external help specifically for the gap assessment and crosswalk — the highest-skill, most time-consuming phase — then run remediation and documentation updates internally with periodic external review before the transition audit. This typically costs 40–60% of a fully outsourced engagement while still catching the gaps an inexperienced internal team would miss.

What This Actually Costs: Effort and Budget Tables

Every organization asks the same question after the structural overview: what does this actually cost, in hours and dollars? The honest answer depends heavily on how mature your existing ISMS documentation is and how many of the 11 new controls you're starting from zero on. The figures below are illustrative ranges drawn from the pattern I've seen across small, mid-size, and enterprise ISMS transitions — treat them as planning inputs, not quotes.

The single biggest cost lever I've seen across every engagement is not consulting fees — it's how many of the 11 new controls an organization can honestly claim informal, unmapped coverage for versus genuine greenfield build. Configuration management, threat intelligence, and secure coding are the three most commonly missing in full when I run initial gap assessments, largely because they require cross-functional ownership (IT operations, security, and engineering respectively) rather than sitting neatly inside a single security team's remit.

What Certification Body Auditors Actually Test For

Knowing the control text is one thing; knowing what an auditor will actually ask to see is another. Based on the transition and surveillance audits I've sat in on, here's the pattern of evidence requests that comes up most consistently for the highest-risk new controls. Our planned companion piece, ISO 27001:2022 Transition Audit: What Certification Bodies Actually Test, expands this into a full audit-prep script.

The consistent thread: auditors under the 2022 structure ask for a specific, dated artifact far more often than they did under 2013, where a policy document alone often sufficed. Our Certification Readiness Checklist is built around exactly this "prove it happened, on a date, to a named owner" evidence standard rather than "we have a policy that says we do this."

Industry-Specific Transition Considerations

The eleven new controls don't land with equal weight across every sector. If you want the fuller picture of which industries carry the highest ISO 27001 stakes generally, our industries and organizations that benefit most from ISO 27001 piece is worth reading alongside this one — but for transition purposes specifically, here's where I see the sharpest sector-by-sector gaps.

Fennimore Health Analytics's gap (data deletion and masking, discussed below) and Corvane Logistics's gap (cloud services) both track exactly the sector pattern in this table — which is precisely why I recommend running your gap assessment with your industry's typical failure points front of mind rather than working through all 93 controls in strict numerical order.

Documentation Housekeeping: What to Archive, Rewrite, and Keep

Not every 2013-era document needs a rewrite, and treating the transition as "throw everything out and start over" wastes budget you'll want later for actual control remediation.

The archive-versus-rewrite decision is where I see the most wasted consulting spend — teams frequently pay to have documents fully rewritten that only needed a numbering update, while genuinely new material for the 11 new controls gets under-resourced by comparison. Confirming which documents ISO actually requires versus which are optional artifacts your ISMS has accumulated over time is worth doing before you commit rewrite budget.

Mini Case Studies

Case Study 1: The Freight Forwarder That Nearly Lost Its Contract (Corvane Logistics)

Referenced in the opening of this article, Corvane Logistics discovered its transition gap only three months before its 2013 certificate expired, triggered by a customer contract renewal that hinged on active certification. The gap assessment found seven of the eleven new controls with no documented coverage at all, most critically 5.23 (cloud services) given Corvane's fully cloud-hosted logistics platform. Remediation required an emergency 8-week sprint, $61,000 in unplanned consulting spend, and a major nonconformity on the recertification audit that took an additional five weeks to close via corrective action evidence. Outcome: certificate retained, contract renewed, but at roughly 3.5x the cost and timeline of a planned transition. The lesson Dana now repeats internally: "start the crosswalk the week the new standard is announced, not the quarter your certificate expires."

Case Study 2: The SaaS Provider That Turned Transition Into a Sales Advantage (Northglen Payments)

Northglen Payments, a mid-size payment processing SaaS provider, began its transition eleven months ahead of its recertification date after its compliance lead, Sarah Lindqvist, flagged the revision during a routine standards-watch review. Because Northglen had budgeted realistic runway, the team treated the 11 new controls as a chance to formalize practices that had been living informally in engineering (configuration management via infrastructure-as-code review, secure coding via existing SAST tooling). Total cost came in at $34,000 against a budgeted $50,000, the internal audit found only two minor nonconformities, and the certification body closed the transition audit in a single two-day visit with zero major findings. The team then used the new attribute taxonomy to build a customer-facing security overview mapped to NIST CSF functions, which the sales team credited with shortening security review cycles in two enterprise deals closed the following quarter by an estimated three weeks each.

Case Study 3: The Regional Health Data Analytics Firm That Missed the Deadline Entirely (Fennimore Health Analytics)

Fennimore Health Analytics, a healthcare data analytics firm holding ISO 27001:2013 certification tied to several hospital-system data processing contracts, deprioritized the transition through 2024 amid a leadership change, and its certification lapsed past the 31 October 2025 deadline with no transition audit scheduled. The gap was discovered when a prospective hospital-system client's procurement team flagged the certificate as "not found" on the certification body's accredited register during due diligence. Fennimore's CISO, Priya Nandakumar, initiated an emergency gap assessment and, working with the certification body, confirmed the transition window had fully closed and a new initial two-stage audit was required rather than a lighter transition audit. The process took seven months from gap assessment to certificate issuance — roughly double the typical planned-transition timeline — and the prospective hospital-system deal was paused for the duration, ultimately closing four months later than originally targeted. Fennimore's internal post-mortem attributed the delay entirely to treating a standards-watch function as optional during a leadership transition.

Maintaining Momentum: Surveillance Audits Under the New Standard

Getting through the transition audit is not the finish line — it's the new baseline your annual surveillance audits will be measured against from now on. Certification bodies typically sample a subset of controls each surveillance cycle rather than re-testing all 93 every year, and in my experience the 11 new controls stay on the sampling radar disproportionately for the first two surveillance cycles after transition, precisely because they're newest and most likely to have thin evidence trails.

The organizations that hold their transition gains are the ones that fold the new control ownership structure into business-as-usual operations immediately — named owners for each of the 11 new controls attend management review, evidence collection is scheduled rather than reactive, and the attribute taxonomy gets used for at least one recurring report (board dashboard, engineering scorecard, or customer-facing overview) so it doesn't quietly become shelfware. Northglen Payments's post-transition move — turning the attribute taxonomy into a customer-facing security overview — is the pattern I'd point every team toward: use the new structure for something beyond the audit itself, and it pays for the transition effort many times over.

The Strategic Close

The organizations that came through this transition cleanly weren't the ones with the biggest security budgets. They were the ones that treated a standards revision as a genuine planning event — something to be crosswalked, budgeted, and staged over months, not squeezed into the final quarter before a certificate expiry date. Dana Whitfield's team at Corvane got there in the end, but at a cost, timeline, and level of internal stress that a single afternoon of crosswalk work eighteen months earlier would have avoided entirely.

If you take one thing from this article, take this: the shift from 114 controls in 14 domains to 93 controls in 4 themes is not a renumbering exercise, and the 11 new controls are not optional extras you can defer to "phase two." They are, collectively, ISO's answer to a decade of threat landscape evolution that the 2013 standard never addressed. Treat the transition with the seriousness it deserves, and it becomes a genuine opportunity to formalize security practices that have likely been running informally in your organization for years. Treat it as paperwork, and it becomes exactly the kind of five-week, five-figure scramble that Corvane Logistics went through.

If you're not sure where your organization currently stands against the 93-control structure — whether you're mid-transition, haven't started, or suspect your certification may already have lapsed — PentesterWorld's compliance team runs structured ISO 27001:2022 gap assessments that map your existing Statement of Applicability against the current control set, flag every one of the 11 new controls by coverage status, and hand you a prioritized remediation plan rather than just a findings report. Reach out to our team to scope an assessment before your next audit finds the gaps for you.

Related Reading

• What Is ISO 27001? A Complete Beginner's Guide to Information Security Management

• ISO 27001 vs ISO 27002: Understanding the Difference

• History and Evolution of ISO 27001: From BS 7799 to ISO 27001:2022

• Who Needs ISO 27001? Industries and Organizations That Benefit Most