The requirements page lists all 45 requirement clauses of ISO 22301:2019. Each carries an implementation status, an owner, implementation notes, evidence and a review date, and each has authored guidance describing what satisfies it, what a certification auditor rejects, the common gaps and what is proportionate for a small firm and for a group.

The ISO 22301 requirements list with references, readiness scores, evidence counts and Request evidence buttons
The 45 ISO 22301 requirements, ordered by what moves the score most, each with its readiness score, evidence count and a request for evidence - shown with sample data.

Status values

The same four values used across every Venvera framework: Not Implemented, Partial, Implemented and Not Applicable. Use Not Applicable only for a requirement genuinely outside the scope of your BCMS, and record the justification in the applicability note: clause 4.3 allows a scoped certification, but an exclusion that removes a function other activities depend on is a finding, and the management system clauses (4 to 7, 9 and 10) can never be excluded.

The requirement text

ISO 22301 is copyrighted, so the requirement text in Venvera is written in the platform's own words as what a certification auditor verifies, not reproduced from the standard. The only quantitative statements are the MTPD and RTO relationships, which are definitional. Where the text says "at least annually", that is certification practice, not a requirement of the standard, and the compliance calendar lets you set your own cadence.

The evidence guidance

Every requirement has an authored guidance block with four parts: the expected artefacts a reviewer asks for, each with a description of what it must contain and what gets rejected; the common pitfalls; a checklist an internal auditor can tick; and sizing notes stating what is proportionate for a small firm and what a large or group firm is expected to show. Use the artefact list as the acceptance test before you attach a document, and use the checklist as the agenda for your own internal audit.

⚠
A continuity solution counts as implemented only once it has been proven to work. A backup that has never been restored, an alternate site that has never been checked and a workaround that staff have never practised are recorded as not implemented by a certification auditor, however well they are described. Attach the test result, not the design document.

The requirements a first audit usually fails

Certification auditors concentrate on a small number of clauses because that is where the judgement calls the standard leaves to the firm go wrong. Check these first.

RequirementWhat goes wrong
BC-4.3 ScopeDefined by organisation chart rather than by products and services, or excluding a group function or data centre that prioritised activities depend on
BC-8.2.2 Business impact analysisRTO equal to or longer than the MTPD; a supplier or ICT recovery objective longer than the RTO it supports; timescales set by the continuity team without business owner validation; no RPO for data
BC-8.3.1 to BC-8.3.3 StrategyNo strategy document, only plans; existing arrangements written up as the only option; a solution that cannot meet the RTO with no residual risk acceptance recorded
BC-8.1 SuppliersCritical suppliers with no continuity obligation in the contract and no assurance that their own plans work
BC-8.4.4 PlansNo activation criteria or stand-down process; plans inconsistent with the BIA timeframes; plans held only on the systems they are meant to recover
BC-8.5 ExercisingOnly tabletop exercises, never a technical test; no post-exercise report; actions raised but never closed; the same comfortable scenario every year
BC-9.2.1 Internal auditThe BCMS owner auditing their own system; audits that check documents exist without testing effectiveness
BC-10.1 NonconformityFindings corrected without cause analysis, so the same finding recurs at the next audit

Owners

Responsibilities routing assigns a default owner from the requirement's category: the compliance officer for the governance and business process clauses, the risk manager for clause 6 and the BIA and risk assessment, security operations for the monitoring clauses and internal audit for clause 10. Most firms reassign the clause 8 requirements to the BCM lead and the ICT solution requirements to IT operations; the fourteen calendar obligations already route to the BCM lead, the risk manager, IT operations, the compliance officer, procurement, HR, internal audit and the CEO by role.

Evidence and the crosswalk

Attach evidence to the requirement it supports. Three ISO 22301 requirements are on the crosswalk, where evidence propagates to the linked requirements: the business continuity plans (BC-8.4.4) sit in the business continuity group with the plan requirements of DORA, NIS2, ISO 27001, SOC 2, NIST CSF, NIST SP 800-53, HIPAA, GDPR, NDPA, the Saudi ECC and the UAE IA; competence for continuity roles (BC-7.2) is linked to NIST SP 800-53 CP-3; and the exercise programme (BC-8.5) to NIST SP 800-53 CP-4. Everything else is deliberately left unlinked: the BIA is not an ICT risk assessment, exercising is not the DORA digital operational resilience testing programme, and an ISMS audit or management review does not evidence a BCMS audit, so an automatic link would claim coverage a certification auditor would not accept. Where one document genuinely answers both frameworks, attach it to each requirement.

Policy templates

Ten policy templates cover the documents a BCMS needs: the business continuity policy, the BIA methodology, the continuity risk assessment procedure, the business continuity strategy, the business continuity plan template, the ICT disaster recovery plan, the crisis communication plan, the exercise and testing programme, the supplier continuity requirements and the management review procedure. Each section of each template cites the requirements it satisfies, so a generated policy appears on the Policies tab of every requirement it covers, and together the ten templates cover all 45 requirements.