ISO 22301 documentation: the documents and records a business continuity system needs, and what it does not

What counts as ISO 22301 documentation?

ISO 22301 calls everything it expects you to control documented information, on paper or in software. In a business continuity management system that term covers two different things.

Documents direct action. The scope, the business continuity policy, the plans that each response team follows and the procedures for returning to normal operations are documents. They change whenever the business changes: a new site, a new client obligation, a replaced supplier, an updated phone number.

Records prove that something happened: the completed business impact analysis, the risk assessment, the note of which strategy management chose and why, a post-exercise report, audit reports and review minutes. Once written, a record stays as it was. If an exercise reveals that the call tree failed, the report says so, and the fix appears in the next version of the plan rather than in an edited report.

The standard itself defines a business continuity plan as documented information that guides the response and the resumption, recovery and restoration of products and services. It is an instruction set for people under pressure, not a narrative about resilience.

What ISO 22301 requires you to document

ISO 22301:2019, with Amendment 1:2024, follows the harmonised structure shared by ISO 9001 and ISO/IEC 27001, so the management-system clauses (context, leadership, planning, support, performance evaluation, improvement) ask for the same kinds of evidence you would expect in any certified system. Clause 8, Operation, is where business continuity adds its own documentation. The table lists the core set at clause-title level.

Beyond this core, the standard leaves the rest to you: whatever documentation your own system needs to work reliably. A contact list or an IT recovery runbook earns its place because the plans depend on it. How to run the analysis behind the BIA record is covered in Business impact analysis: how to run one management will act on, and the exercise records in Business continuity exercises: from walk-through to full invocation.

What ISO 22301 does not ask for

Several documents appear in almost every template pack and are required by none of the clauses.

• A business continuity manual. Restating the standard adds nothing; a one-page map of where each required item lives is more useful.
• A written procedure for every clause. Internal audit, management review and corrective action can be described in a few lines each, or in the shared procedures of an existing ISO 9001 or ISO/IEC 27001 system.
• A separate plan for every scenario. Plans work better when built around the loss of a resource (a site, people, systems, a supplier) than around a list of causes.
• Pages of threat descriptions. The risk assessment needs to identify, analyse and evaluate the risks to prioritised activities and decide which need treatment. An encyclopaedia of hazards is not evidence of that.

At the certification body's Stage 1 readiness review, volume does not help; coherence does. The auditor follows one thread: from the scope to the prioritised activities in the BIA, to the selected solutions, to the plan that uses them, to the exercise that tested it.

A minimal document set for a small organisation

For a single-site organisation with one or two services in scope, the set below is usually enough. Items can share a file.

Sizes and owners are Sterling's working defaults, not requirements of the standard.

Keeping plans usable during a disruption

Document control in ISO 22301 has the usual components: identification, approval, version control, access, protection and retention. One point weighs more heavily here: the plans must be available when the normal environment has failed. A plan stored only on the server that has just gone down is not available. Effivity's business continuity module, which holds the BIA, generates the plan, records training on it and logs drills and tabletop exercises, also prints and shares plans for exactly this reason. See Effivity for ISO 22301: the guide.

• Hold copies outside the affected environment. Response-team members need the current plan and contact lists on a device or in a location that does not depend on the primary site or network.
• Control the copies you distribute. Withdraw superseded copies; a stale call tree is a common exercise finding.
• Review on triggers, not only on dates. The standard expects the BIA, risk assessment, strategies and plans to be evaluated at planned intervals, after an incident or invocation, and when significant changes occur.
• Let exercises edit the plans. Every post-exercise report should end with named actions, and the plan's revision history should show those actions arriving.

Documentation mistakes that auditors notice

The plan is an IT recovery document

If the only plan restores servers, nobody has planned for people, workspace and suppliers. The auditor will ask who does what when the building is closed and the systems are fine.

The BIA does not match the plans

Recovery time objectives in the analysis and timings in the plans drift apart, usually because plans were copied from a template before the analysis finished.

Every activity is prioritised

When the BIA calls every activity critical, the plans cannot say what to resume first.

Records that were never generated by the work

Exercise reports written after the fact, or review minutes identical each quarter, cast doubt on everything else.

ISO 22301 documentation: questions buyers ask