Skip to content
Audit-Checklist

Continuity · ISO Standards

ISO 22301: BIA, MTPD, and why a DR runbook is not a BCMS

How to build an ISO 22301:2019 business continuity management system — business impact analysis, strategies, tests, and certification sampling.

6 min read

ISO 22301 is a business continuity management system standard. It asks whether an organization can continue prioritized activities through disruption, not merely whether IT can restore servers. Disaster recovery is important, but it is only one part of continuity.

The paired checklist is the execution tool for policies, BIA, strategies, plans, exercises, and improvement. This guide explains the judgment behind those rows: which activities are truly prioritized, which dependencies matter, and whether recovery targets are believable.

In 2026, continuity depends heavily on SaaS, identity providers, cloud regions, third-party support, and remote operations. A plan that restores one database while ignoring the IdP, payment processor, contact center, or supplier network is not a resilient BCMS. For ISO 22301, the guide should make resilience measurable through business consequences. Ask what happens after two hours, one day, three days, and one week without a process, then compare that impact to actual recovery capability. The gap often appears outside IT: no manual billing path, no alternate approver, no supplier contact, no customer communication template, or no way to authenticate users when the IdP is down. Exercises should test those assumptions with the people who must act, not only the engineers who restore systems. A mature BCMS treats exercise findings as management information: some targets need funding, some commitments need renegotiation, and some plans need to admit a dependency cannot be recovered as promised. A useful way to read the rest of this guide is to separate evidence from judgment. Evidence shows that an activity happened: a review, record, test, approval, training, scan, exercise, assessment, or decision. Judgment explains why the activity was scoped that way, why the risk treatment is proportionate, why an exception is acceptable, and what would cause the decision to change. The paired checklist should collect evidence and owners, while the guide should help teams avoid false certainty. For each topic, ask what a knowledgeable reviewer would challenge after seeing the first answer. They may ask whether the scope matches production, whether suppliers are included, whether recurring work is current, whether leadership approved trade-offs, and whether public or customer-facing claims match operations. That second layer is where preparation becomes credible. It also keeps teams from overclaiming, because a documented limitation with a plan is usually stronger than a broad statement no one can support.

What ISO 22301 actually is

ISO 22301 defines requirements for establishing, operating, reviewing, and improving a BCMS. It includes context, leadership, planning, support, operation, performance evaluation, and improvement, using the same management-system structure as many ISO standards.

The BIA is the anchor. It identifies activities, impacts over time, dependencies, maximum tolerable periods of disruption, recovery time objectives, and recovery priorities. Without that analysis, continuity plans become a catalog of hopeful runbooks.

Strategies should follow the BIA. Manual workarounds, alternate suppliers, cross-trained staff, redundant facilities, cloud failover, communications plans, and customer prioritization can all be valid. The standard does not require one technology answer; it requires a reasoned strategy.

Decisions the checklist will not make for you

The checklist cannot decide what the organization must recover first. Executives and process owners need to rank products, services, obligations, customers, and internal dependencies. If everything is critical, nothing is actually prioritized.

It also cannot set realistic RTOs or MTPDs. A sales promise of one-hour recovery means little if systems, staff, suppliers, and data restoration cannot support it. Targets need business approval and technical validation.

The checklist cannot decide whether a SaaS dependency is within the continuity strategy. Identity, collaboration, ticketing, payroll, ERP, cloud hosting, and customer support providers can be single points of failure even when IT does not own them.

Where continuity programs actually fail

The common failure is calling IT disaster recovery the BCMS. A backup restore test does not cover customer communications, manual order handling, regulatory notifications, workforce availability, supplier interruption, or executive crisis decisions.

Fantasy RTOs are another problem. Teams select impressive recovery targets for every application, then never fund redundancy, staffing, testing, or supplier commitments. Auditors and customers will compare targets to exercise results.

Plans are often never exercised. Tabletop-only programs may miss access problems, call-tree failures, expired contacts, manual workaround gaps, and SaaS assumptions. Exercises should reveal weaknesses while there is still time to fix them.

How to use the paired checklist

Use the checklist in the same order the BCMS should mature: context, BIA, risk assessment, continuity strategies, plans, exercises, performance evaluation, and corrective action. Avoid writing detailed plans for activities that have not been prioritized.

For each activity, attach dependencies and evidence. Include systems, people, facilities, suppliers, data, recovery targets, workaround procedures, communications, and exercise results. This makes the checklist an operating map instead of an audit binder.

After exercises and incidents, update the checklist with lessons learned. ISO 22301 expects improvement. A finding from a tabletop, outage, or supplier interruption should become an owner, action, due date, and management-review input.

What teams get wrong

Business continuity is the same as IT disaster recovery.
DR supports technology recovery, while business continuity covers prioritized activities, people, suppliers, communications, workarounds, and crisis management.
RTOs can be set by ambition.
Recovery targets should reflect business impact and validated capability. Unrealistic targets create false assurance and audit exposure.
A written plan is enough if no incident happens.
Plans need exercises, updates, lessons learned, and management review. Untested plans often fail during the first real disruption.

When the checklist is enough — and when it is not

  • Use the checklist to build the BIA, continuity strategy, plans, exercises, and improvement tracker.
  • Ask a registrar or BCMS advisor when certification scope, exercise design, audit evidence, or management-system integration is unclear.
  • Ask counsel when regulatory continuity obligations, customer commitments, incident notices, or force majeure language are involved.
  • Treat this guide as practical orientation, not official ISO text; use the licensed standard and registrar expectations for authoritative wording.

Related checklists

Related field notes

The checklists and field notes provided on this website are for educational and informational purposes only. They do not constitute legal, financial, or professional advice. Completing a checklist does not guarantee compliance, certification, or immunity from audits. Always consult with a certified auditor or legal counsel for your specific organizational needs. Full disclaimer