ISO 27001:2013 to ISO 27001:2022: the transition deadline has passed. What this means for SaaS

The transition window closed on 31 October 2025. Here is what SaaS organisations should do if they already transitioned, missed the deadline, or are still implementing.

On 31 October 2025 the official transition window from ISO/IEC 27001:2013 to ISO/IEC 27001:2022 closed. If you are a SaaS company that is certified (or aiming to be), this is the moment where "we will do it next quarter" quietly turns into "this is now a customer and contract risk".

In a Nutshell

• The three-year transition period ended on 31 October 2025. After that date, ISO/IEC 27001:2013 certificates should be treated as expired or withdrawn, even if your certificate still shows a later expiry date.
• Transition audits were usually a delta audit added to a surveillance or recertification audit (think: +0.5 to +1 audit day), focused on your updated Statement of Applicability (SoA) and the new or changed controls.
• ISO/IEC 27001:2022 is not a full rewrite. The biggest practical change is Annex A: the controls were reorganised (114 controls became 93), and 11 new controls were added.
• For SaaS organisations, the most relevant changes tend to cluster around cloud governance, secure development, configuration management, monitoring and logging, data handling, and business continuity readiness.

The transition timeline (in human terms)

ISO/IEC 27001:2022 was published in October 2022, and the International Accreditation Forum (IAF) set a transition window of 36 months.

In practice, that meant:

• From 1 May 2024: initial certification audits and recertification audits should be performed against ISO/IEC 27001:2022.
• By 31 October 2025: all existing certifications based on ISO/IEC 27001:2013 should have transitioned. If not, those certificates should be treated as invalid.

If you want the official wording and timing, the most useful document to bookmark is IAF MD 26 (Transition Requirements for ISO/IEC 27001:2022): https://iaf.nu/iaf_system/uploads/documents/IAF_MD26_Issue_2_15012023.pdf.

What this means if you already have an ISO 27001 certificate

Scenario 1: You already transitioned to ISO 27001:2022

Good. You mostly need to ensure the transition is visible and defensible:

• Check that your certificate and any public trust page explicitly says ISO/IEC 27001:2022.
• Ensure your SoA, risk treatment plan, and internal audit reports match the 2022 control structure and numbering.
• Keep your transition evidence easy to find. In practice, that is your gap analysis, the updated SoA, and proof that new or changed controls are implemented and effective.

The goal is boring clarity. You want customers and auditors to see "2022" everywhere, consistently.

Scenario 2: You did not transition by 31 October 2025

Treat this like an expired passport. You may still be the same person, but you should not expect it to be accepted at the border.

What you can expect in the real world:

• Customers and prospects will increasingly reject "ISO 27001:2013" as outdated or invalid.
• Your certification body is likely to withdraw the 2013 certificate (or treat it as lapsed).
• To regain certification status, you will typically need a new certification decision against ISO/IEC 27001:2022. In many cases that means a full initial certification audit (Stage 1 + Stage 2), not just a small transition add-on.

Practical next steps:

• Contact your certification body immediately and ask what they require post-deadline (this varies in scheduling and process, but the end state is the same: you need 2022).
• Do a focused gap assessment against the 2022 Annex A controls, especially the 11 new controls.
• Run an internal audit and a management review against ISO/IEC 27001:2022 before your external audit. If you skipped these, auditors will notice.
• Update your external messaging. If your certificate is lapsed, do not keep presenting it as current. That is a trust problem waiting to happen.

What this means if you are currently implementing ISO 27001

If you are not certified yet, this is actually simpler: you should build directly against ISO/IEC 27001:2022.

Two practical implications for SaaS organisations:

• Do not waste time mapping your whole ISMS to 2013 control numbers first.
• Build your SoA and evidence structure on the 2022 control set from day one.

The most important changes (for SaaS organisations)

The 2022 update has two layers:

• 1) Small clause updates to the management system requirements.
• 2) A larger refresh and reorganisation of Annex A controls.

For most SaaS companies, Annex A is where the real work is.

1) Annex A got reorganised: 114 controls became 93

The controls were consolidated and grouped into four themes:

• Organisational controls
• People controls
• Physical controls
• Technological controls

This matters because your SoA, policies, audit checklists, and cross-references usually point to Annex A identifiers. Renumbering sounds trivial until you realise how many documents and tickets you have that refer to "A.12.6.1" or similar.

2) The 11 new controls, with details for SaaS companies

Here are the 11 new controls and what they usually mean in a SaaS context. You do not need to implement everything in the exact same way as everyone else, but you do need to make a clear, risk-based choice in your SoA and back it with evidence.

• A.5.7 Threat intelligence
  SaaS interpretation: demonstrate that you actively track relevant threats and translate them into action.
  Evidence ideas: CVE and vendor advisory monitoring, threat brief reviews, security backlog items linked to new threat info, periodic "what changed in the world" review in risk meetings.
• A.5.23 Information security for use of cloud services
  SaaS interpretation: cloud is not "someone else's problem". Show governance over AWS, GCP, Azure, and key SaaS vendors.
  Evidence ideas: shared responsibility matrix, supplier evaluation, cloud configuration standards, identity and access controls, logging strategy, exit considerations.
• A.5.30 ICT readiness for business continuity
  SaaS interpretation: your business continuity plan must include your actual tech stack and recovery ability.
  Evidence ideas: RTO and RPO defined, backup and restore tests, incident and DR runbooks, resilience testing, post-incident reviews that improve continuity.
• A.7.4 Physical security monitoring
  SaaS interpretation: often minimal if you are remote-first, but you still need a position.
  Evidence ideas: office access logs or building controls, camera coverage where relevant, third-party office provider assurances.
• A.8.9 Configuration management
  SaaS interpretation: treat configuration as a controlled asset, ideally as code.
  Evidence ideas: infrastructure-as-code repositories, change control via pull requests, hardened baselines, documented configuration standards, drift detection.
• A.8.10 Information deletion
  SaaS interpretation: prove you can delete data when required and that you do it consistently.
  Evidence ideas: retention schedules, deletion workflows, customer offboarding process, deletion logs, verification steps.
• A.8.11 Data masking
  SaaS interpretation: production data should not casually end up in dev, test, or screenshots.
  Evidence ideas: synthetic test data, anonymisation or pseudonymisation approach, masked exports, policy and technical enforcement for non-production.
• A.8.12 Data leakage prevention
  SaaS interpretation: reduce accidental exfiltration routes and prove you have controls for it.
  Evidence ideas: access restrictions, secret scanning, outbound sharing controls, endpoint controls (where applicable), monitoring of unusual exports.
• A.8.16 Monitoring activities
  SaaS interpretation: logging exists, but also show that someone looks at it and responds.
  Evidence ideas: centralised logging, alerting, on-call procedures, incident tickets linked to alerts, periodic review of detection rules.
• A.8.23 Web filtering
  SaaS interpretation: typically relevant for corporate devices and browsing controls, less so for product security.
  Evidence ideas: managed devices, acceptable use controls, DNS filtering, proxy policies.
• A.8.28 Secure coding
  SaaS interpretation: auditors will expect your secure development story to be coherent and evidenced.
  Evidence ideas: secure coding guidelines, code reviews, SAST, dependency scanning, security testing expectations, developer training, secure release gates.

If you are a SaaS organisation and you want a short list of what really matters, the controls that most often drive real work are:

• Cloud services and supplier governance (A.5.23)
• Secure coding (A.8.28)
• Configuration management (A.8.9)
• Monitoring activities (A.8.16)
• ICT readiness for business continuity (A.5.30)
• Data handling: deletion, masking, and leakage prevention (A.8.10, A.8.11, A.8.12)

3) Clause changes that show up in audits

ISO 27001:2022 also includes some management system clause updates, mainly aligning with other ISO standards. In practice, SaaS companies most often feel these as "show me you manage change, and show me you track objectives".

Examples that commonly surface in audits:

• Evidence that you plan and manage changes to the ISMS (not just changes to product code).
• Security objectives that are monitored (not just written down once a year).
• Clear understanding of interested parties (customers, regulators, suppliers) and which requirements you address in your ISMS.

What transition audits looked like (and what auditors focused on)

Transition audits were typically not a total rebuild. They were usually a targeted review that verified you updated the system and that the new or changed controls are implemented effectively.

In many cases, this was handled as:

• A transition add-on to a recertification audit (often about half a day extra).
• A transition add-on to a surveillance audit (often about a day extra).
• A separate special audit if timing demanded it.

What auditors commonly ask for first:

• Your updated Statement of Applicability (SoA) aligned to ISO 27001:2022 control numbering and structure.
• Your transition gap analysis and what you changed in response.
• Evidence for the new controls that are applicable to your environment, especially technological controls.

Common friction points for SaaS organisations:

• SoA still references 2013 numbering, or mappings are unclear.
• Secure coding is assumed but not documented, trained, or evidenced.
• Cloud governance exists in engineers' heads, but not in the ISMS.
• DR and continuity exist as intentions, but lack tested recovery evidence.
• Non-production data handling is messier than anyone wants to admit.

A practical checklist for SaaS organisations (post-deadline)

If you want a pragmatic "do this next" list:

• Confirm your status: are you certified to 2022, or did you miss the deadline?
• Make the SoA your single source of truth: correct numbering, clear applicability decisions, and justified exclusions.
• Do a focused gap assessment around the 11 new controls.
• Ensure you have an internal audit and management review performed against the 2022 version before your external audit.
• Build an audit evidence pack for SaaS reality.

Audit evidence pack examples:

• Secure development: reviews, scanning, release gates, training
• Cloud governance: responsibilities, logging, access controls, supplier control
• Monitoring and incident response: alerts, tickets, postmortems
• Continuity: backups, restore tests, DR exercises
• Data handling: deletion, masking, least privilege access to production data

Closing thoughts

ISO 27001:2022 is not designed to punish you with paperwork. It is designed to make sure your ISMS still maps to how modern companies actually build and operate systems, especially cloud-first SaaS organisations.

If you are already transitioned, you are mainly in "keep it consistent and keep improving" mode. If you missed the deadline, you are in "recover credibility fast" mode, and the fastest path is usually a structured gap assessment followed by a properly scoped certification audit to 2022.

If you want help translating the new controls into SaaS-friendly evidence (without turning your engineering team into a document factory), Coding Mammoth can help with gap assessments, ISO 27001 implementation support, and internal audits.

We can also help you to get a clear view of your status, especially if you are not sure where you stand and want external guidance, via our virtual CISO role.