In this guide
- The difference in one line
- Side by side
- What ISO 27001 already covers on continuity
- Where ISO 27001 stops
- What "exercised" actually means
- The shared skeleton, and why the second one is lighter work
- Both carry the climate amendment
- Which one first
- Running them as one system
- Where Singahi fits
- FAQ
- What is the difference between ISO 27001 and ISO 22301?
- Does ISO 27001 include business continuity?
- Do we need ISO 22301 if we already have ISO 27001?
- Which should we certify first?
- Can ISO 27001 and ISO 22301 be certified together?
- What are RTO, RPO, MTPD and MBCO?
- Is ISO 22301:2019 still the current version?
- Does a disaster recovery plan satisfy ISO 22301?
These two get compared as though you have to pick one. You do not. They answer different questions, and the honest version of the comparison is about sequence and overlap, not competition.
ISO 27001 asks: is your information protected? ISO 22301 asks: can you keep operating when something breaks? A company can pass one and fail badly at the other: encrypted, access-controlled, well-audited data that nobody can reach for four days is still a customer-facing outage.
The difference in one line
ISO 27001 protects information. ISO 22301 keeps the business running.
ISO 27001 certifies an information security management system (ISMS), built around confidentiality, integrity and availability, with 93 Annex A controls to draw from. ISO 22301 certifies a business continuity management system (BCMS), built around understanding which of your operations matter, how quickly they must come back, and proving through exercises that they will.
Availability is where the two touch. It is one of ISO 27001's three properties and the whole point of ISO 22301, which is exactly why people assume one covers the other.
Side by side
| ISO 27001:2022 | ISO 22301:2019 | |
|---|---|---|
| Manages | Information security (ISMS) | Business continuity (BCMS) |
| Core question | Is information confidential, intact and available? | Can critical operations continue and recover? |
| Triggered by | Breaches, unauthorised access, data loss, customer security review | Outages, supplier failure, facility loss, natural events, incidents |
| Control set | 93 Annex A controls across four domains, scoped via a Statement of Applicability | No Annex A equivalent; requirements live in clause 8 |
| Signature artefacts | Statement of Applicability, risk treatment plan, evidence per control | Business impact analysis, continuity strategies, tested plans, exercise records |
| Key measures | Risk likelihood and impact, control effectiveness | MTPD, RTO, RPO, MBCO |
| Proof of it working | Controls evidenced and operating | Plans exercised and evaluated, not just written |
| Shared structure | Annex SL clauses 4 to 10 | Annex SL clauses 4 to 10, near-identical |
| Certification | Accredited certification body, Stage 1 + Stage 2, three-year cycle | Accredited certification body, Stage 1 + Stage 2, three-year cycle |
| Who asks for it | Nearly every enterprise security questionnaire | Financial services, critical suppliers, regulated sectors, resilience-focused procurement |
What ISO 27001 already covers on continuity
More than people expect, and this matters, because it determines whether you need ISO 22301 at all.
Annex A includes four controls that sit squarely in continuity territory:
- A.5.29 Information security during disruption. Security controls must not evaporate when you fail over. If your disaster-recovery environment has weaker access control than production, that is a finding. Full guide: A.5.29.
- A.5.30 ICT readiness for business continuity. Added in the 2022 revision. It requires ICT continuity planning based on business continuity objectives, with recovery capability that is tested, not assumed. Full guide: A.5.30.
- A.8.13 Information backup. Backups taken, retained and, critically, restore-tested to an agreed schedule.
- A.8.14 Redundancy of information processing facilities. Sufficient redundancy to meet availability requirements.
Read together, that is a competent ICT disaster-recovery capability. For a lot of growing SaaS companies, it is genuinely enough.
Where ISO 27001 stops
The gap is scope and rigour, in three places.
It is ICT-shaped, not business-shaped. A.5.30 asks you to base ICT readiness on business continuity objectives. It does not require you to derive those objectives properly. ISO 22301 does: a formal business impact analysis identifying prioritised activities, their dependencies (including people, premises, suppliers and third parties) and the impact of losing each over time. Losing your payments provider, your only person who knows the deployment process, or your office is not an ICT problem, and Annex A does not systematically reach it.
It does not force the numbers. ISO 22301 makes you set and justify:
- MTPD, maximum tolerable period of disruption: the point past which the damage is unrecoverable
- RTO, recovery time objective: how fast an activity must be back, necessarily inside the MTPD
- RPO, recovery point objective: how much data you can afford to lose
- MBCO, minimum business continuity objective: the reduced level of service that is acceptable while you recover
These force uncomfortable, useful conversations. "Four hours" stops being a number in a policy and becomes a commitment that architecture, staffing and supplier contracts have to support.
They also cascade, which is the part that turns a BIA from paperwork into a design constraint. Take a payments reconciliation process where the business decides the maximum tolerable disruption is 24 hours. The RTO has to sit inside that, say 8 hours, which rules out restoring from nightly backups to a cold environment. If the RPO is 15 minutes, nightly snapshots are out entirely and you need continuous replication. And if the MBCO is "accept and queue transactions, settle later", that is a product decision requiring engineering work nobody scheduled.
Four numbers, and you have just specified your architecture, your on-call rota and a supplier requirement. That is the work ISO 27001 lets you skip and ISO 22301 does not.
It does not require an exercise programme. This is the big one. ISO 22301 clause 8.5 requires you to exercise your plans on a programme, evaluate the results, and act on what you learn. ISO 27001 asks for tested recovery capability; ISO 22301 asks for a rehearsed organisation: people who know their role at 3am, a call tree that reaches someone, a documented decision on who declares an incident.
Untested plans fail when you need them. That is the entire argument for ISO 22301, and the reason a written plan alone is not certifiable.
What "exercised" actually means
Clause 8.5 does not prescribe a format, which is why teams under-deliver against it. It requires a programme: a schedule, objectives, scope, scenarios, participants and evaluation criteria, with results acted on. In practice that means a ladder, and maturity is measured by how far up it you go.
| Exercise | What it proves | What it cannot prove |
|---|---|---|
| Call-tree test | Contact data is current and a message actually reaches people | Anything about the response itself |
| Tabletop | The team understands roles and the plan's logic holds under discussion | That the technology works |
| Walkthrough | Each step is executable and the documentation matches reality | Behaviour under time pressure |
| Simulation | Decision-making under a realistic scenario, including who declares an incident | That systems actually fail over |
| Live failover | Real recovery, and your true RTO and RPO against the stated ones | Little, which is why it is the goal |
The interesting failure is the gap between the last two rows. Plenty of organisations discover their documented four-hour RTO is really eleven hours only when they run a live failover. ISO 27001's A.8.13 gets you a restore test, which is one technical slice of the bottom row. ISO 22301 asks whether the organisation recovers, not just the database.
The shared skeleton, and why the second one is lighter work
Both standards follow Annex SL, ISO's harmonised high-level structure. Clauses 4 through 10 are near-identical in shape:
| Clause | Both standards ask for |
|---|---|
| 4 Context | Internal and external issues, interested parties, scope |
| 5 Leadership | Top-management commitment, policy, roles and responsibilities |
| 6 Planning | Risks and opportunities, objectives, planning of changes |
| 7 Support | Resources, competence, awareness, communication, documented information |
| 8 Operation | The standard-specific core: Annex A controls, or BIA, strategies, plans and exercises |
| 9 Performance evaluation | Monitoring and measurement, internal audit, management review |
| 10 Improvement | Nonconformity, corrective action, continual improvement |
Clause 8 is where they genuinely diverge. Everything else can be one system.
In practice that means a single context analysis, a single policy framework and approval route, one competence and awareness programme, one document control system, one internal audit programme covering both scopes, and one management review with both on the agenda. Accredited certification bodies will run a combined audit against both standards in a single visit, which cuts audit days and the disruption of hosting them.
If you already hold ISO 27001, a large share of the BCMS is built. What remains is mostly clause 8: do the business impact analysis properly, set and justify the recovery objectives, write plans that reflect them, and start exercising.
Both carry the climate amendment
ISO 27001:2022/Amd 1:2024 and ISO 22301:2019/Amd 1:2024 were both published in February 2024 as part of a set of climate action changes applied across ISO's management system standards. Both add the same two things:
- Clause 4.1: the organisation shall determine whether climate change is a relevant issue
- Clause 4.2: a note that interested parties can have climate-related requirements
They apply now, with no transition period. You may conclude climate change is not a relevant issue, provided the determination is documented and reasoned. But for a BCMS in particular, that conclusion deserves real thought. Flooding, heat, storm and grid disruption are ordinary continuity scenarios, and an auditor will expect the reasoning to reflect that.
Because the wording is identical in both standards, one context analysis in an integrated system answers it once.
Which one first
ISO 27001 first, in almost every case. It is what customers ask for, it carries the broader control set, and it establishes the management-system machinery that ISO 22301 then reuses. Starting with 22301 means building that machinery for the narrower standard and running the wider one through it later.
Take ISO 22301 seriously when:
- You are a critical supplier and customers ask continuity questions your ICT answers do not satisfy
- You are in financial services or a regulated sector where operational resilience is a supervisory expectation
- Your availability commitments are contractual, with SLA credits or penalties attached
- Disruption is a real risk to your operations: single-site dependency, concentrated key-person knowledge, a supply chain with obvious single points of failure
- Questionnaires keep asking for a BIA, tested plans or exercise records, and you are answering with a backup policy
ISO 27001 alone is usually enough when: you are a cloud-native product on resilient infrastructure, your continuity exposure is genuinely ICT-shaped, and nobody is asking for a certificate. Implement A.5.29, A.5.30, A.8.13 and A.8.14 properly and answer the questionnaire honestly.
Worth being plain about: ISO 22301 is asked for less often than ISO 27001 or SOC 2. Do not buy it speculatively. Buy it when a customer, a regulator or your own risk assessment asks for it.
Running them as one system
If you are doing both, build one system with two scopes rather than two systems that happen to share a building.
- One context and scope exercise, covering information assets and prioritised activities together, with the climate determination made once.
- One risk methodology. ISO 27001's information-security risk assessment and ISO 22301's disruption-focused analysis are different lenses on the same organisation. Run them as one process with two outputs, and the BIA feeds the ISMS risk register directly.
- One policy and document framework, so a single approval route and version control serves both.
- Recovery objectives as the shared spine. The BIA gives you RTO and RPO; those numbers then justify your A.8.13 backup schedule and A.8.14 redundancy design. Set them once and both audits point at the same evidence.
- One internal audit programme and one management review, with both scopes on the agenda.
- A combined certification audit, where your certification body assesses both in one visit.
Done this way, the second standard is an increment on the first rather than a second project. Done as two projects, you will maintain two context documents that disagree with each other, and an auditor will find the disagreement.
Where Singahi fits
We build both, and we build them as one system when you need both. That means a single scoping and gap assessment across the ISMS and BCMS, a business impact analysis that produces recovery objectives your architecture can actually meet, plans written to be used rather than filed, exercises run against them, and audit support through Stage 1 and Stage 2, combined where your certification body supports it.
The certificates come from an accredited certification body, not from us. We get you ready, and we make sure the continuity plan and your incident response agree with each other instead of contradicting each other at the worst possible moment.
See ISO 27001, ISO 22301, the ISO 27001 toolkit and ISO 22301 toolkit, or talk to a practitioner.
FAQ
What is the difference between ISO 27001 and ISO 22301?
ISO 27001 certifies an information security management system: protecting the confidentiality, integrity and availability of information, using 93 Annex A controls scoped through a Statement of Applicability. ISO 22301 certifies a business continuity management system: identifying your prioritised activities, setting recovery objectives, building and exercising plans so operations continue through disruption. Security keeps information safe; continuity keeps the business running.
Does ISO 27001 include business continuity?
Partly. Annex A contains A.5.29 (information security during disruption), A.5.30 (ICT readiness for business continuity), A.8.13 (information backup) and A.8.14 (redundancy of information processing facilities). Together these give you a tested ICT disaster-recovery capability. What ISO 27001 does not require is a formal business impact analysis, justified RTO, RPO, MTPD and MBCO values, or an exercise programme. That is the gap ISO 22301 fills.
Do we need ISO 22301 if we already have ISO 27001?
Only if something is asking for it: a customer questionnaire your ICT answers do not satisfy, a regulator with operational-resilience expectations, contractual availability commitments, or a risk assessment that shows real disruption exposure such as single-site dependency or key-person concentration. If you are cloud-native with genuinely ICT-shaped continuity risk, ISO 27001's continuity controls implemented properly are often enough.
Which should we certify first?
ISO 27001, in almost every case. It is the credential customers ask for, it carries the broader control set, and it stands up the management-system machinery (context, policy, competence, internal audit, management review) that ISO 22301 then reuses. Adding the BCMS afterwards is mostly clause 8 work.
Can ISO 27001 and ISO 22301 be certified together?
Yes. Both use Annex SL, so clauses 4 to 10 are near-identical and can be run as one integrated management system with two scopes. Accredited certification bodies will conduct a combined audit against both standards in a single visit, which reduces audit days and the disruption of hosting them.
What are RTO, RPO, MTPD and MBCO?
Four measures ISO 22301 requires you to set and justify. MTPD is the maximum tolerable period of disruption: the point past which damage becomes unrecoverable. RTO is the recovery time objective, how quickly an activity must be restored, which must sit inside the MTPD. RPO is the recovery point objective, how much data loss is acceptable. MBCO is the minimum business continuity objective, the reduced level of service that will do while you recover.
Is ISO 22301:2019 still the current version?
Yes. ISO 22301:2019 remains current, amended by ISO 22301:2019/Amd 1:2024, published in February 2024, which added the climate action changes to clauses 4.1 and 4.2. The same amendment was applied to ISO 27001:2022 and across ISO's other management system standards, and it applies immediately with no transition period.
Does a disaster recovery plan satisfy ISO 22301?
No. A DR plan is typically ICT-focused: systems, data and infrastructure. ISO 22301 covers the whole organisation (people, premises, suppliers and processes) and requires the business impact analysis that justifies your recovery objectives plus an exercise programme that proves the plans work. A DR plan is usually one component of a BCMS, not a substitute for it.