ISO 22301 vs ISO 27001: Where A.5.30 Stops Being Enough

ISO 22301 vs ISO 27001 is the question you reach when your ISMS auditor accepts your disaster recovery plan and then a customer asks for something bigger. Both standards touch continuity, but only one of them is a business continuity management system.

This post is about the seam between them: what Annex A.5.30 actually requires, and where a full BCMS starts. For the standalone continuity picture, see the ISO 22301 guide.

The Short Answer

• ISO 27001 certifies an ISMS. Continuity appears inside it, scoped to keeping information available.
• ISO 22301 certifies a BCMS. Its subject is the organization's ability to keep delivering during disruption, whatever the cause.

The overlap is real but narrow. ISO 27001 asks for ICT recovery capability that has been planned and tested. ISO 22301 asks you to work out which activities matter, how long they can be down, what resources they need, and then prove the whole response structure works under exercise conditions.

What ISO 27001 Actually Requires for Continuity

In ISO 27001:2022 the continuity requirements are concentrated in two Annex A controls:

• A.5.29, information security during disruption. Maintain information security at an appropriate level while you are disrupted. In other words, your recovery must not become the incident. No shared admin passwords during failover, no unencrypted recovery copies, no logging gap while you rebuild.
• A.5.30, ICT readiness for business continuity. Plan, implement, maintain, and test ICT continuity so that systems and data can be recovered to meet continuity objectives.

Note the wording of A.5.30. It requires ICT readiness measured against continuity objectives, but the standard does not tell you to derive those objectives with a business impact analysis. Many teams supply them from a technical judgement call instead. That passes an ISO 27001 audit and is exactly the gap a BCMS closes.

The supporting guidance is ISO 27031, which covers ICT readiness in detail. It is guidance, not a certifiable standard, so it shapes how you implement A.5.30 rather than giving you something to show a customer.

If you are still building the ISMS itself, the ISO 27001 checklist covers the wider control set.

What ISO 22301 Adds on Top

ISO 22301:2019 requires a chain of work that has no ISO 27001 equivalent:

1. Business impact analysis (BIA). Identify your activities, the products and services they support, and the impact of losing each one over time.
2. Recovery objectives derived from that analysis. Recovery time objective (RTO), recovery point objective (RPO), and the maximum tolerable period of disruption. These come out of impact evidence, not a technical guess.
3. Minimum business continuity objective. The reduced level of delivery you commit to sustaining during a disruption.
4. Continuity strategies and solutions for every priority activity, covering people, premises, technology, information, suppliers, and equipment.
5. Response structure. Named teams, defined authority to invoke, escalation paths, communication plans for staff, customers, and regulators.
6. Business continuity plans at the activity level, not just the system level.
7. An exercise and testing programme with documented results, plus post-exercise improvement.

Points 1, 4, 5, and 7 are where the real distance sits. An ISO 27001 programme can satisfy A.5.30 with a tested failover runbook. A BCMS cannot, because failover says nothing about what happens when the people who run the failover cannot get to work.

ISO 22301 vs ISO 27001: Side by Side

Both use the harmonized clause structure, so clauses 4 to 10 are near-identical in shape. Scope, leadership, competence, documented information, internal audit, management review, corrective action: one set of machinery, two subjects. That is the same integration logic described in ISO 9001 vs ISO 27001.

When A.5.30 Is Genuinely Enough

Not every ISO 27001 holder needs ISO 22301 certification. A.5.30 plus A.5.29 is a reasonable stopping point when:

• Your delivery is entirely software, running on cloud infrastructure with managed redundancy.
• Your workforce is remote or distributed, so no single site failure stops work.
• Your supplier concentration risk is low, or your critical suppliers are large cloud providers with their own published continuity posture.
• No customer contract or tender names ISO 22301.

In that shape, the honest answer is that a BIA would confirm what you already know: the systems are the business. Spend the effort on tested recovery instead of a second certificate.

When You Need the Full BCMS

Push to ISO 22301 when any of these are true:

• A customer or tender asks for it by name. This is the most common trigger, and the cheapest to justify internally.
• Physical operations matter. Warehouses, labs, clinics, manufacturing, field teams. A.5.30 has nothing to say about a flooded site.
• Concentrated people risk. A handful of individuals hold the knowledge to run a critical activity.
• Regulated continuity obligations. Financial services and critical infrastructure regimes increasingly require operational resilience evidence that looks like a BCMS.
• You are already answering continuity questionnaires with hedged answers, and the sales cycle keeps stalling there.

The overlap with SOC 2's Availability criterion is a separate comparison, covered in ISO 22301 vs SOC 2 availability.

The Evidence Each Auditor Asks For

The clearest way to see the gap is to compare what you hand over in an audit.

An ISO 27001 auditor testing A.5.30 wants:

• Documented ICT continuity requirements tied to your continuity objectives
• Recovery plans for in-scope systems
• Evidence of a test within the period, with results and any follow-up actions
• Evidence that security controls held during that test, which is A.5.29
• Backup records showing successful restores, not just successful jobs

An ISO 22301 auditor wants all of that, plus:

• The business impact analysis, with the method used and the criteria applied
• Prioritized activities with RTOs, RPOs, and the maximum tolerable period of disruption, traceable back to impact evidence
• Resource requirements per activity, covering people, premises, technology, information, suppliers, and equipment
• Continuity strategies with the rationale for the option chosen
• The response structure, with named roles, invocation authority, and contact arrangements
• An exercise programme, not a single test, with a schedule, scenario variety, and post-exercise improvement actions
• Evidence you evaluated supplier continuity capability, not just supplier security

The line to notice is traceability. ISO 27001 accepts recovery targets as an input. ISO 22301 asks you to show where each number came from. That single requirement is why a BCMS build takes longer than teams expect, and why it cannot be retrofitted from a runbook the week before an audit.

What the BIA Usually Reveals

Teams often treat the business impact analysis as documentation of what they already know. In practice, the first honest BIA tends to surface three findings:

The tested RTO does not match the business tolerance. Engineering tested a four-hour recovery and considered it good. Finance says invoicing cannot be down past one day, but customer support says the queue becomes unrecoverable after two hours. Nobody had compared the numbers before.

A non-technical dependency is the real single point of failure. A licence held by one person, a supplier with no alternate, a physical document required to release payments. None of these appear in an ICT continuity plan.

Some activities were never in scope for anything. Payroll, regulatory reporting, and contract renewals often sit outside both the ISMS and the DR plan, because neither was scoped to catch them.

If those findings feel unlikely for your organization, that is a reasonable argument that A.5.30 is sufficient for now. If any of them feel familiar, you already have your answer.

Running Both Without Duplicating Work

If you hold ISO 27001 and are adding ISO 22301, the sequence that avoids rework:

1. Do the BIA first. It produces the recovery objectives your A.5.30 evidence has been assuming. Expect at least one uncomfortable finding where the tested RTO does not match the business impact.
2. Extend the scope statement rather than writing a new one. One management system, two standards.
3. Keep one risk methodology. Information risk and disruption risk score on the same scale, with separate registers.
4. Promote your ICT recovery plans into the BCMS as the technology component of activity-level plans. Do not rewrite them.
5. Merge the exercise programme. An exercise that tests site loss can test ICT failover and information security during disruption in the same run. One exercise, evidence for both standards.
6. One internal audit programme, one management review with a section per standard. Ask your certification body for a combined audit.

The trap to avoid is a BCMS that lives in a separate document library owned by a different team. When the two sets of plans drift, the audit finds the contradiction before you do. Our overlap analysis shows where the shared control evidence sits across frameworks.

Neighbouring Standards Worth Knowing

Teams comparing ISO 22301 vs ISO 27001 usually run into three adjacent standards in the same search:

• ISO 27031 — guidance on ICT readiness for business continuity. Use it to implement A.5.30 well. Not certifiable.
• ISO 27701 — a privacy extension to ISO 27001 for a privacy information management system. Different subject, same host management system.
• ISO 20000 — IT service management. Overlaps operationally through incident and change management, and shares the harmonized clause structure.

None of these replace ISO 22301, and none of them are the continuity certificate a customer means when they ask for one.

For the full BCMS build, see the ISO 22301 guide and the ISO 22301 service page. For the security programme it attaches to, see the ISO 27001 checklist and the ISO 27001 service page. For the availability comparison, read ISO 22301 vs SOC 2 availability.

Frequently Asked Questions

What is the difference between ISO 27001 and ISO 22301? ISO 27001 protects information, and its continuity requirements exist to keep information available, mainly through A.5.29 and A.5.30. ISO 22301 protects your ability to keep delivering during any disruption. A flood that closes your only site is an ISO 22301 problem and barely an ISO 27001 one.

Can you be certified to ISO 22301? Yes. ISO 22301:2019 is a certifiable management system standard on the same three-year cycle as ISO 27001. That sets it apart from guidance such as ISO 22313 or ISO 27031, which you can follow but cannot certify against. Confirm your certification body is accredited for ISO 22301 specifically.

Is ISO 27001 outdated? No. ISO 27001:2022 restructured Annex A into 93 controls and added controls for cloud services, threat intelligence, and ICT readiness. It is deliberately generic, so it will not hand you technical hardening baselines, but that is a design choice rather than obsolescence.

Is NIST better than ISO 27001? They do different jobs. NIST CSF and SP 800-53 are freely adoptable guidance with no certificate. ISO 27001 is certifiable, which is what contracts and tenders ask for. Many teams implement with NIST material and certify with ISO 27001.

Does ISO 27001 A.5.30 satisfy business continuity requirements? It satisfies ICT readiness, which is a subset. A.5.30 does not require a business impact analysis, recovery objectives for non-ICT activities, supply chain continuity, or a documented exercise programme. If your risk is concentrated in systems and data, it may be enough. If people, premises, or suppliers can stop delivery, it is not.

Not Sure Whether A.5.30 Covers You?

ShieldKey Solutions runs the gap assessment that answers it: what your ISMS continuity evidence already proves, what a BIA would change, and whether ISO 22301 certification is worth the build for your risk profile.

Schedule a scoping call →