ISO 27001:2013 to 2022 Transition and Migration Guide

Marcus Feld found out his certificate had lapsed from a procurement portal, not from his certification body.

Marcus was VP of Security at Ferrovia Cargo Systems, a mid-sized logistics-technology firm that ran freight-tracking software for rail and intermodal shippers across North America. Ferrovia had held ISO/IEC 27001:2013 certification since 2019 — hard-won, well-documented, a genuine source of pride for a 220-person company that had built its security program from nothing. The certificate had renewed cleanly every three years. Surveillance audits came back clean. Nobody at Ferrovia thought of ISO 27001 as a risk. They thought of it as a solved problem.

That was the mistake.

When ISO/IEC 27001:2022 was published in October 2022, Marcus registered the change the way most operators register a distant regulatory update: noted, filed, deprioritized. His certification body sent the standard transition-period notices — first at publication, then again as the 31 October 2025 deadline for accredited certificates approached. Marcus forwarded the emails to his GRC analyst with a note that said, essentially, "let's get to this in Q2." Q2 became Q3. Q3 became "after the SOC 2 renewal." The transition project never got a budget line, a project owner, or a date on the calendar, because nothing was visibly on fire.

In September 2025, Ferrovia was seven weeks from finalizing a three-year contract renewal with Continental Intermodal Logistics, a European logistics conglomerate that accounted for $6.2 million of Ferrovia's annual recurring revenue — nearly a quarter of the company's book. Continental's updated vendor security addendum, drafted to align with its own supply-chain assurance program, required every technology vendor to hold a current ISO/IEC 27001:2022 certificate — not 2013, not "in transition," current. Ferrovia's procurement liaison had assumed, reasonably, that a company with an ISO 27001 badge on its website already met the bar.

The deadline passed on 31 October 2025. Ferrovia's certification body could no longer keep a 2013-scope certificate active under accreditation rules, and Ferrovia had not scheduled a transition audit. The certificate lapsed. Continental's compliance team flagged it during a routine vendor-portal recheck three weeks later, froze the renewal, and gave Ferrovia 60 days to either produce a valid 2022 certificate or lose the contract to a competitor who already had one.

Marcus spent the next eleven weeks doing, under emergency conditions and at rush-project cost, exactly what this article walks through in a controlled sequence: a gap analysis against the 2022 controls, a full Statement of Applicability remap, implementation of controls his ISMS had never needed to address, a risk register overhaul, a crash awareness campaign, and a compressed transition audit squeezed into his certification body's calendar through a premium-priced expedite fee. Ferrovia kept the contract — barely, and at a renegotiated rate that gave Continental a pricing concession as compensation for the compliance risk exposure during the lapse. The total cost of the scramble, including consulting fees, the expedite premium, and the discount Ferrovia had to grant to keep the deal, came to just under $340,000. A project that should have cost a fraction of that, run over eight unhurried months, instead became a fire drill that nearly cost Ferrovia its largest customer.

Marcus's mistake wasn't technical. Ferrovia's security program was genuinely mature; almost everything the 2022 controls required already existed somewhere in the organization's practice. His mistake was sequencing: treating a fixed regulatory deadline as a flexible internal priority. That is, by a wide margin, the most common way organizations get hurt in this transition — not because the work is hard, but because it gets scheduled last.

Who This Is For

This guide is written for the ISMS manager, CISO, or compliance lead who holds — or held — an ISO/IEC 27001:2013 certificate and now needs to move it to the 2022 edition. It assumes you already understand the basics of your ISMS and don't need a primer on what ISO 27001 is; you need a project plan. You'll walk away with a concrete six-step migration sequence, a working Statement of Applicability remapping table, an implementation checklist for the eleven controls that are genuinely new, and a realistic picture of the timeline, cost, and audit mechanics involved — whether you're transitioning proactively, mid-scramble like Ferrovia, or trying to re-certify after your 2013 certificate has already lapsed.

The Deadline Reality: It Has Already Passed

Here is the fact this entire article is built around, and it is worth stating without softening: the accredited-certification transition deadline for ISO/IEC 27001:2022 was 31 October 2025. If you're reading this after that date and your organization is still certified only to the 2013 edition, your certificate is no longer valid under accreditation rules. You are not "due for a transition." You are currently uncertified, in the same position Ferrovia was in the moment Continental's portal flagged them.

That is not a reason to panic, and it is not a reason to delay further — it's a reason to move in the sequence this article lays out, starting today, with urgency proportional to what an uncertified status is already costing you in stalled deals, failed vendor reviews, and renewal risk. If you're mid-transition — gap analysis done, SoA half-remapped, audit not yet scheduled — the same sequence applies; you're simply further along, and closing it out is now the priority ahead of new project work.

A certificate that lapsed on or shortly after 31 October 2025 doesn't mean your ISMS collapsed — it means your accredited proof of it did. The work you did to earn the 2013 certificate is still real, still useful, and still the foundation you'll build the 2022 transition on. What changed is the mapping between what you have and what the standard now requires you to demonstrate, which is the entire subject of the next section.

Being uncertified in practice tends to show up in three places before it shows up anywhere else: vendor security questionnaires that ask for a current certificate number and auditor-verifiable expiry date, procurement portals (like the one that caught Ferrovia) that cross-check certification registries automatically, and RFP disqualification criteria that treat an expired or non-current certificate the same as no certificate at all. None of these are dramatic events on their own — no one calls to tell you you've been quietly excluded from a shortlist — which is exactly why the exposure compounds silently until it surfaces as a lost deal, the way it did for Marcus. If you manage vendor relationships that depend on your certification status, it's worth proactively notifying key customers of your transition timeline rather than waiting for them to discover a lapsed certificate on their own; a customer told in advance reads it as diligence, a customer who finds out from a portal reads it as risk.

What Changed at a Glance

Before you can plan a migration, you need the shape of the target. This section is deliberately compressed — a full breakdown of every clause and control change lives in our companion piece on what changed between the 2013 and 2022 editions — with the full backstory in our history and evolution of ISO 27001 piece — but you need these facts pinned down before the gap analysis in Step 1 will make sense. If any of the terminology in this article is unfamiliar, our ISO 27001 glossary of terms is a faster reference than digging through the standard itself.

The headline change is structural. ISO/IEC 27001:2013 organized Annex A into 114 controls spread across 14 domains (A.5 through A.18). ISO/IEC 27001:2022 reorganizes the same territory into 93 controls across 4 themes. No control was deleted outright — the standard's drafters achieved the reduction almost entirely through merging: 57 of the 2013 controls were consolidated into 24 broader 2022 controls, folding related requirements together instead of listing them as separate line items. Eleven controls are genuinely new, addressing security practices that either didn't exist as distinct disciplines in 2013 or had matured enough since then to warrant their own control.

The Four 2022 Themes

The 14 domains disappear; everything now sits under one of four themes. If your 2013 documentation is organized by the old domain numbering (A.5 Information Security Policies, A.6 Organization of Information Security, A.9 Access Control, and so on), your remap in Step 2 is essentially a translation exercise between two organizing schemes covering mostly the same ground.

The Eleven New Controls

These eleven are the only controls in the entire 2022 Annex A with no 2013 predecessor. Everything else in your existing ISMS has an ancestor control somewhere in the old structure, even if it's now bundled with two or three others. These eleven are where your gap analysis will find genuinely new implementation work rather than just relabeling.

ISO/IEC 27002:2022's Five Attributes

Alongside the renumbering, ISO/IEC 27002:2022 introduces five attributes attached to every control, letting you filter and view the same 93 controls through different lenses — useful for reporting to different audiences without maintaining separate control sets.

You don't have to adopt the attributes to pass a transition audit, but most organizations find them genuinely useful once the SoA remap is done — they make it far easier to produce a "here's our detective coverage" or "here's our incident-response-aligned control set" report for a board or a customer security questionnaire without rebuilding anything.

Why This Restructuring Happened

It's worth understanding the logic behind the merge-heavy approach, because it changes how you should think about the remap in Step 2. The 2013 structure grew organically over several standard revisions going back to BS 7799, and by 2013 it showed the seams — related requirements split across separate controls in ways that made sense historically but created documentation overhead without adding security value. A 2013 auditor testing "cryptographic controls," for instance, worked across two separate controls (A.10.1.1 and A.10.1.2) that 2022 collapses into a single control 8.24 with the same substantive requirement. The 2022 drafters explicitly aimed to reduce that duplication while tightening the standard's focus on outcomes that had grown in importance since 2013 — cloud computing, data protection regulation, and continuous monitoring chief among them, which is exactly why those areas are where the eleven genuinely new controls concentrate. Understanding that the reduction in control count (114 to 93) did not represent a reduction in scope or rigor — if anything, the opposite — will help you push back internally on anyone who reads "93 controls" as "less to do than 2013." It isn't. It's the same substantive ground, organized more efficiently, with real new ground added at the edges.

For a deeper structural comparison of the two editions clause by clause and control by control, our 2013 vs 2022 comparison guide is the reference to work from alongside this migration plan.

The Migration Roadmap

Every successful transition I've run or advised on follows the same six-step spine, in the same order. Skipping ahead — implementing new controls before you've mapped where they land in the SoA, for instance — is how organizations end up redoing work.

Step 1: Run a Gap Analysis Against the 2022 Controls

Everything downstream depends on getting this step right, so resist the temptation to skip straight to remapping the SoA from memory. A proper gap analysis compares your current ISMS — policies, procedures, risk treatment, technical controls, evidence — against all 93 controls in the 2022 Annex A, not just the eleven new ones. You're looking for three categories of finding:

1. Direct carry-over — a 2013 control you already implement maps cleanly to a 2022 control with no material change in requirement (most access-control and HR-security controls fall here).

2. Merged and reworded — a 2022 control absorbs two or three 2013 controls; you likely already do most of what's required, but your documentation and SoA justification need consolidating to match the new structure.

3. Genuinely new — one of the eleven controls with no direct 2013 ancestor, where you need to assess whether the practice exists informally, exists nowhere, or exists but isn't yet documented as a formal control.

Run this gap analysis control-by-control, not domain-by-domain — a spreadsheet with all 93 controls as rows, your current 2013 control reference as one column, gap category as the next, and owner/target date as the last two, is enough. Our gap analysis methodology article walks through the assessment technique in more depth if you're building this from scratch, and the ISO 27001 Gap Analysis Tool in our resource library is built around exactly this row-per-control structure if you'd rather start from a template than a blank sheet.

"The gap analysis is where I see the most self-deception. Teams look at 'Configuration management' and think, 'we use a configuration management database, we're fine' — without asking whether that CMDB actually enforces secure baselines or just inventories assets. Those are two different maturity levels, and the auditor will find the gap between them even if you don't." — Priya Nakamura, vCISO, Solace Consulting

For most organizations coming from a mature 2013 program, the gap analysis surfaces somewhere between 15 and 30 controls needing real documentation or process work, concentrated heavily — but not exclusively — in the eleven new controls and in the technological theme generally, where 2022's granularity around monitoring, configuration, and data handling exceeds what 2013 required.

Resourcing the Transition: Who Should Own What

One reason Ferrovia's transition sat idle for two years is that it never had a name attached to it — it was "something the security team should get to," which in practice means it belongs to no one. Before you run the gap analysis, assign explicit ownership. The roles don't need to be new hires; in most organizations they map onto existing functions with a defined slice of accountability for the transition specifically.

Naming these roles explicitly, with target dates, converts the transition from an ambient obligation into a tracked project — the single highest-leverage move available before you touch a single control.

Step 2: Remap the Statement of Applicability

Your Statement of Applicability is the single document your certification body will scrutinize most closely during the transition audit, because it's the artifact that proves you've actually done the mapping — not just read about it. The SoA remap has three mechanical parts: retire the 114 old control references, adopt the 93 new ones, and for every 2022 control, document which 2013 control(s) it descends from, whether it's applicable to your scope, and why.

Do not treat this as a find-and-replace exercise. Several 2022 controls absorb two or three 2013 controls whose evidence currently lives in separate documents — your justification and evidence references need to be consolidated, not just relabeled. The table below shows a representative sample of the mapping pattern across all four themes; it is illustrative of the kind of one-to-one, many-to-one, and new-control mappings you'll encounter, not an exhaustive 114-to-93 crosswalk.

Build the full 93-row version of this table for your own environment before you touch a single new control — the Statement of Applicability Template in our resource library is pre-structured with the 2022 numbering, applicability justification, and implementation-status columns so you're not building the format from scratch. For every control, you still need the three SoA fundamentals the 2013 edition required: is it applicable, why or why not, and how is it implemented — the 2022 numbering doesn't change that discipline, it just changes what you're numbering.

"I tell clients: don't delete your old SoA, archive it and build the new one as a companion document with an explicit crosswalk column. Auditors doing transition audits want to see the lineage — that you understood what a control used to be before you decided what it is now. A clean new SoA with no visible history reads as a fresh start, not a transition, and that's a different (and harder) audit." — Ingrid Kowalski, Technical Assessor, Northgate Certification

Step 3: Implement the Eleven New Controls

This is the step with the most net-new project work, and it's where organizations most often underestimate effort — because "new control" doesn't always mean "build something from zero." For several of these eleven, the practice already exists somewhere in a mature security program; the work is formalizing it as an owned, documented, evidenced control rather than an ambient practice nobody could point to on demand. For others, particularly data masking and DLP, there's genuine implementation work if you haven't already invested in the underlying tooling.

A few implementation notes worth flagging from experience running this across dozens of transitions:

5.23 (cloud services) is almost never a pure build. Most organizations already have vendor-management and supplier-security processes; the work is extending them explicitly to cloud, documenting the shared-responsibility boundary per provider, and folding it into the SoA under this specific number rather than leaving it scattered across supplier controls. It overlaps heavily with supplier relationship security, and most auditors expect to see it addressed there rather than as an isolated silo.

8.9 and 8.13 (configuration management and backup) are frequently implemented together because they share tooling and ownership in most environments — see our configuration management and backup guide for the combined approach.

8.10, 8.11, and 8.12 cluster as a data-protection trio — deletion, masking, and leakage prevention all touch the same data-classification foundation, and organizations that tackle them as one coordinated project (rather than three separate initiatives) tend to move faster; our data protection controls deep-dive covers the three together.

8.16 (monitoring activities) sits naturally alongside logging — see logging and monitoring — since most organizations already have a SIEM or log aggregation platform; the gap is usually in documented alert thresholds and response SLAs, not the underlying technology.

8.28 (secure coding) is best tackled as part of a broader secure development lifecycle project rather than in isolation — see the secure development lifecycle guide — because coding standards without lifecycle integration (code review gates, static analysis in CI/CD) tend to look good on paper and fail in practice.

7.4 (physical security monitoring) is often the fastest of the eleven for organizations with existing badge and CCTV systems — see physical security monitoring — the gap is usually documentation and retention policy rather than technology.

"The eleven new controls get treated like eleven separate projects, and that's the wrong mental model. Group them by who owns the underlying capability — IT operations owns configuration management and monitoring, data governance owns deletion and masking, security engineering owns secure coding — and you'll find you're running four or five workstreams, not eleven." — Devon Cho, ISMS Manager, BrightLedger Fintech

Step 4: Update Risk Assessment, Risk Treatment, and Documentation

The 2022 edition made only modest changes to Clauses 4–10 (the management-system requirements) compared to the overhaul in Annex A, but the risk treatment plan is where the two connect — and it's where a lot of transition projects quietly fall apart, because teams update the SoA and forget that the risk register references the old control numbering throughout.

Walk through these updates in order:

The risk treatment work deserves particular attention because it's substantive, not clerical. Controls like 5.23 (cloud services), 8.11 (data masking), and 8.12 (DLP) exist because the threat landscape shifted since 2013 — cloud adoption, data privacy regulation, and insider/exfiltration risk all matured as named categories of concern. If your risk assessment methodology hasn't touched those risk categories, the new controls will look like documentation exercises rather than genuine risk treatment, and an experienced auditor will notice the disconnect between "we implemented control 8.12" and "our risk register never identified a data leakage risk to treat." Re-run the risk identification step for the areas the new controls cover before you finalize the treatment plan — don't just retrofit justification after the fact.

"The transition audits I fail organizations on almost never come down to a missing control. They come down to a risk register that doesn't tell a coherent story — a SoA that says a control is implemented, but no risk assessment ever identified the risk it treats. That disconnect is the single most common nonconformity I write in a 2022 transition audit." — Ingrid Kowalski, Technical Assessor, Northgate Certification

It's also worth using this step to reinforce, internally, what ISO/IEC 27001 does and doesn't do for your regulatory posture. If your organization also carries obligations under GDPR, HIPAA, DORA, or similar regimes, an updated 2022-aligned ISMS — particularly the strengthened data-handling controls in 8.10 through 8.12 and the supply-chain rigor in 5.19 through 5.23 — genuinely supports those regulatory goals by giving you documented, auditable evidence of data protection and third-party risk management practice. It does not, on its own, make you "GDPR compliant" or "HIPAA compliant"; those are separate legal determinations with their own requirements. Be precise about that distinction in your internal communications during the transition — overstating what the certificate proves is a credibility risk with customers and regulators alike, and a careful auditor or legal team will notice the overreach immediately.

Step 5: Retrain and Rebuild Awareness

A remapped SoA and a set of new technical controls don't survive a transition audit if the people staff the auditor interviews can't describe them. Auditors test the management system by talking to people, not just reading documents — a control owner who can't explain why 8.9 (configuration management) exists or what "their" control does is a nonconformity waiting to happen, regardless of how good the underlying documentation is.

This doesn't need to be an elaborate program — most organizations can run the awareness refresh as a two-week push rather than a standing initiative, provided the control-owner briefings are specific rather than generic. "We're now ISO 27001:2022" as an announcement satisfies nobody in an interview room; "I own control 8.16, here's what monitoring activities we run and here's where the alert thresholds are documented" does. Our employee training program guide and the security awareness training deep-dive both cover the broader awareness program if you're rebuilding it alongside the transition rather than just refreshing it.

Step 6: The Transition Audit

The transition audit is where your certification body verifies the migration actually happened — not just that a new SoA exists, but that the ISMS behind it changed to match. Depending on your certificate's renewal timing, this happens one of two ways: bundled into a scheduled surveillance or recertification visit, or as a standalone dedicated transition audit if your renewal date doesn't line up conveniently. Either way, the auditor is testing the same things.

Auditors are, by design, more interested in evidence of genuine operational change than in documentation polish. A beautifully formatted SoA with weak interview performance from control owners will generate more findings than a slightly rough SoA backed by staff who clearly understand and operate the controls they own. If you only have budget for one or the other in the final weeks before your audit, prioritize control-owner readiness over document formatting.

"I've sat in transition audits where the SoA was immaculate and the ISMS manager could recite every control number from memory — and the audit still generated three nonconformities, because nobody else in the room could say a word about configuration management or DLP. The document proves the project team did the work. The interviews prove the organization absorbed it." — Tomas Reyes, Head of GRC, Anchorpoint Health Systems

Timeline and Effort: What This Realistically Takes

Every organization asks the same question first: how long is this actually going to take? The honest answer depends heavily on how mature your 2013 program already is and how many of the eleven new controls require net-new tooling versus formalization of existing practice. These figures are illustrative planning ranges drawn from typical transition patterns, not a guarantee — treat them as a starting estimate to pressure-test against your own gap analysis findings.

The compressed timeline in that last row is achievable — Ferrovia proved it — but it comes at a real cost premium: expedited consulting engagements, certification body rush fees where available, and often a compromise on the depth of risk re-assessment that a calmer timeline would have allowed. Every organization I've advised through a rushed transition has said, afterward, that the calendar cost of doing it early would have been a fraction of the cash cost of doing it late.

Doing It During a Surveillance Audit vs. a Dedicated Transition Audit

Most organizations don't get a free choice here — it's dictated by where your existing certificate sits in its three-year cycle relative to the work you have left to do — but understanding both paths helps you plan the calendar correctly.

If your recertification (the three-year renewal cycle) or your next surveillance audit falls within a comfortable runway of your transition readiness, bundling is almost always the better economic choice. If it doesn't — if your surveillance visit is eight months away but Continental-style contractual pressure means you can't wait — a dedicated transition audit, even at extra cost, is the correct call. Talk to your certification body early; capacity for dedicated transition audits tightened considerably as the October 2025 deadline approached, and while that specific crunch has passed, CBs are still working through a backlog of organizations that transitioned late or are recertifying for the first time under the 2022 edition.

Special Cases: Multi-Site, Multi-Certificate, and Group Transitions

The six-step sequence in this guide holds regardless of organizational complexity, but a few situations add wrinkles worth planning for explicitly rather than discovering mid-project.

Multiple certificates under one parent organization. If your organization holds separate ISO/IEC 27001:2013 certificates for different business units, subsidiaries, or geographies, each certificate technically requires its own transition — its own gap analysis, its own SoA, its own audit. In practice, most groups in this position centralize the framework (a shared gap-analysis methodology, a shared eleven-new-controls implementation playbook, a shared training package) and localize only what genuinely differs by site or business unit, which cuts total effort substantially compared to running each transition in isolation.

Multi-site single certificate. If one certificate covers multiple physical locations under a single ISMS scope, the physical-theme controls — especially 7.4 (physical security monitoring), which is new in 2022 — need to be assessed and evidenced per site, even though the SoA and risk treatment plan remain unified. Don't let a head-office-centric gap analysis miss site-specific physical control gaps at satellite locations.

Recent mergers or acquisitions. If your organization has acquired or merged with another entity since your 2013 certification, use the transition as the natural checkpoint to also reconcile ISMS scope — confirming the acquired entity's systems, data, and physical locations are either properly included in scope or explicitly and defensibly excluded, with the eleven new controls assessed across the combined footprint rather than just the original scope.

Organizations transitioning and pursuing a new framework simultaneously. Some organizations use the 2022 transition as an opportunity to also pursue a complementary framework — most commonly SOC 2 for a North American customer base. Running both efforts together, mapping shared controls once rather than twice, is far more efficient than sequencing them, and our guide on running ISO 27001 and SOC 2 together covers the shared-control approach in depth if that applies to you.

Common Transition Mistakes

Across the transitions I've reviewed, run, or cleaned up after, the same handful of mistakes account for most of the pain. Most of them are sequencing and ownership errors, not technical failures.

"The single biggest predictor of a rough transition audit isn't the size of the gap — it's whether the project had an owner with real authority from day one. The transitions that go smoothly all have one thing in common: someone whose job it was, with a deadline on their calendar, not a shared spreadsheet nobody was accountable for." — Renata Voss, Lead Auditor, Meridian Assurance Group

There's a quieter version of the "no owner" mistake worth naming separately: partial ownership. Several organizations I've advised assigned an owner to the SoA remap and the audit logistics, but left the eleven new controls without individual owners, assuming the ISMS manager would "handle it." That works for documentation but fails for evidence — an ISMS manager can write a configuration management policy, but they can't personally demonstrate that engineering enforces secure baselines in production, because they're not the one running the systems. The controls that most often generate transition audit findings are exactly the ones where the ISMS manager wrote the policy alone, without a genuine operational owner who could speak to it in an interview.

Case Studies

Ferrovia Cargo Systems — the rushed recovery. Introduced at the top of this guide, Ferrovia's story ends better than it began. After the 60-day ultimatum from Continental Intermodal Logistics, Marcus Feld's team ran the full six-step sequence in compressed form: a one-week gap analysis using a spreadsheet built directly from the 93-control structure, a parallel SoA remap and new-control implementation sprint focused first on the controls Continental's own security questionnaire specifically probed (cloud services, DLP, and monitoring), and a dedicated transition audit secured through an expedite arrangement with their existing certification body. Total elapsed time from the ultimatum to a valid 2022 certificate: 71 days. Total cost: approximately $340,000, including consulting fees, the audit expedite premium, and a negotiated 8% rate concession Ferrovia granted Continental as a goodwill gesture for the compliance gap during the lapse. Ferrovia kept the contract. Marcus's postmortem to his executive team had one line in bold: "This should have been a $60,000, eight-month project. It became a $340,000, ten-week project because we didn't put an owner and a deadline on it in 2023."

BrightLedger Fintech — the proactive bundle. BrightLedger, a payments infrastructure provider certified since 2018, started its gap analysis in early 2024 — roughly 20 months ahead of the deadline — specifically so the transition audit could be bundled into its already-scheduled recertification visit rather than requiring a separate engagement. ISMS Manager Devon Cho ran the gap analysis in three weeks, found that roughly 18 controls needed real work (concentrated in cloud services, configuration management, and the data-protection trio), and spread implementation across five months alongside normal operations, with no overtime and no rush fees. The recertification-bundled transition audit generated two minor nonconformities — both administrative, both closed within the standard correction window — and cost BrightLedger roughly 15% more than a standard recertification audit alone, entirely attributable to the extra audit time, with zero rush premium. Devon's summary: "We treated it as a project with a deadline nineteen months out, not an emergency. It behaved like a normal project."

Anchorpoint Health Systems — the early mover in a regulated sector. Anchorpoint, a healthcare technology firm whose ISMS also has to satisfy HIPAA-aligned customer expectations, began its transition in mid-2023, over two years ahead of the deadline, specifically because Head of GRC Tomas Reyes anticipated that healthcare customers would start demanding 2022-certified vendors well before the accreditation deadline forced the issue. That bet proved correct — by late 2024, two of Anchorpoint's largest enterprise health-system customers had already updated their vendor security requirements to specify the 2022 edition. Anchorpoint's transition ran over seven months, used a dedicated transition audit rather than waiting for its recertification cycle (which was 18 months out), and became a sales asset: Anchorpoint's account team used "already transitioned to ISO 27001:2022" as a competitive differentiator in three enterprise deals closed in 2024, collectively worth an estimated $2.1 million in new annual contract value that Tomas's team credits partly to being ahead of the market on certification currency.

After the Transition Audit: Keeping the ISMS Current

Passing the transition audit is a milestone, not a finish line, and it's worth being explicit about that before you close the project out — because the same drift that let Ferrovia's 2013 certificate age past relevance without anyone noticing can just as easily happen to a freshly transitioned 2022 ISMS if the new controls aren't folded into business-as-usual operating rhythm. A control implemented under project-mode urgency and then handed off with no ongoing owner tends to decay quietly until the next surveillance audit finds it.

The practical fix is to fold the eleven new controls — and the remapped SoA generally — into the same operating cadence that already governs the rest of your ISMS, rather than treating them as a one-time deliverable from the transition project.

Building this into your existing internal audit and management review rhythm — rather than standing up a separate "2022 controls" tracking process — is what keeps the transition from becoming a one-time compliance event that quietly degrades until the next crisis forces another scramble. The organizations that handle their next surveillance audit with the least drama are, without exception, the ones that treated the transition as the start of new operating habits rather than the end of a project.

The Strategic Close: This Is Not Just Paperwork

It's tempting to treat this whole migration as a compliance chore — a certificate to keep current so procurement portals stop flagging you. That framing misses the actual opportunity. The 2022 Annex A didn't add eleven controls arbitrarily; it added them because the threat landscape organizations operate in genuinely shifted since 2013. Cloud dependency, data exfiltration risk, configuration drift at scale, and the need for continuous monitoring rather than periodic review are not compliance fictions — they're the real operating conditions of 2026. An organization that does this migration properly doesn't just keep its certificate; it closes real gaps in its security posture that a purely 2013-era program would have left open.

That's also the commercial argument. Anchorpoint's $2.1 million in new contract value didn't come from a document — it came from being able to say "we're already there" while competitors were still explaining their transition timeline to a skeptical procurement team. As the market moves further past the October 2025 deadline, "we're certified to ISO 27001:2022" stops being a differentiator and starts being the baseline expectation, the way SOC 2 already is in software procurement. Organizations that treat this transition as a strategic project — not a scramble — are the ones that turn it into a sales asset instead of a liability recovery exercise.

If you're reading this with a lapsed certificate and a deal on the line like Marcus was, move now, in the sequence this guide laid out, and talk to your certification body today about scheduling — not after your gap analysis is finished. If you're reading this proactively, ahead of a renewal or a customer requirement, you have the luxury Ferrovia didn't: time to do this right, on a normal budget, without a rush premium. Use it.

Before you start building your own gap-analysis spreadsheet from scratch, our ISO 27001 Certification Readiness Checklist gives you a fast way to sanity-check overall readiness, and our Complete ISO 27001 Implementation Guide eBook walks through the full program in more depth than any single article can, including the mandatory-document and control-implementation detail this transition draws on. For a fast visual reference to the new numbering while you work through your remap, keep the Annex A — All 93 Controls at a Glance cheat sheet open in a second tab.

PentesterWorld works with organizations at every stage of this transition — from the early gap analysis through the final transition audit — and our team has run this exact six-step sequence enough times to know where the real risk hides versus where it's just paperwork. If your certificate has already lapsed, or your renewal window is closing faster than your project plan allows, talk to us before your next customer security questionnaire does the discovery for you.