The ISO 22301 module tracks a business continuity management system (BCMS) against ISO 22301:2019, Security and resilience. Business continuity management systems. Requirements. The standard is certifiable and is adopted by any organisation that needs to show a customer, a scheme or a supervisor that its most important activities would continue or be recovered during a disruption: payment and e-money institutions, banks and insurers, cloud and managed service providers, operators of essential services and their suppliers.
ISO 22301 is not itself a legal obligation. It is the recognised way to build and evidence the continuity capability that other instruments presuppose: the business continuity policy, business impact analysis, tested plans, crisis function and internal audit of the recovery plans that DORA Articles 11 and 12 require of financial entities, the business continuity and crisis management measure of NIS2 Article 21(2)(c), and the four ISO 27001 Annex A controls that assume a BIA and tested ICT continuity.
What Venvera tracks
The standard has ten clauses. Clauses 1 to 3 are scope, normative references and terms and create no obligations; the standard has no annexes. Clauses 4 to 10 contain 45 requirement clauses, and those 45 are what Venvera ships as requirement rows, referenced by clause number with the prefix BC (for example BC-8.2.2 for the business impact analysis). They are grouped into eight areas that follow the life of a BCMS rather than the clause numbering.
| Area | Clauses | What it covers |
|---|---|---|
| Scope and context | 4.1 to 4.4 | The organisation and its context, interested parties and their requirements, legal and regulatory continuity requirements, the scope of the BCMS and the system itself |
| Leadership and resources | 5.1 to 7.5.3 | Leadership, the policy and its communication, roles and authorities, risks and opportunities for the BCMS, objectives and their plans, planning of change, resources, competence, awareness, communication and documented information |
| Business impact analysis | 8.2.1 to 8.2.2 | The BIA and risk assessment process, and the BIA itself: impact over time, MTPD, RTO, RPO, minimum acceptable capacity, resources and dependencies |
| Risk assessment and strategy | 8.2.3 to 8.3.5 | The risk assessment of disruption, and the identification, selection, resourcing, implementation and maintenance of continuity strategies and solutions |
| Plans and response structure | 8.4.1 to 8.4.5 | The response structure and teams, warning and communication procedures, the business continuity plans and the return to normal operations |
| Suppliers and dependencies | 8.1 | Operational planning and control, including outsourced processes and the supply chain |
| Exercising and evaluation | 8.5 to 8.6 | The exercise and testing programme, and the evaluation of the BIA, strategies, plans and procedures after tests, incidents and changes |
| Performance, audit and improvement | 9.1 to 10.2 | Monitoring and measurement, internal audit and its programme, management review (inputs and outputs), nonconformity and corrective action, continual improvement |
Dashboard
The dashboard shows implementation coverage across the 45 requirements, a breakdown by the eight areas, and the maturity score from the gap assessment if one has been completed. Coverage and maturity answer different questions: coverage says whether a requirement is implemented, maturity says how well the judgement calls behind it have been made. A requirement scoped out of the BCMS under clause 4.3 with a recorded justification counts as covered when it is marked not applicable.
The three time values
Clause 8.2.2 produces, for each prioritised activity, three time values and one capacity value that recur throughout the module. The maximum tolerable period of disruption (MTPD) is the point after which the impact of not performing the activity becomes unacceptable. The recovery time objective (RTO) is the target time to resume the activity at a minimum acceptable capacity, and it must sit inside the MTPD with margin. The recovery point objective (RPO) is the maximum acceptable data loss, which sets the backup interval and replication lag. The minimum acceptable capacity is the level of service during recovery, in measurable terms. Two consistency rules make these auditable: the RTO is shorter than the MTPD for every activity, and no supporting system, supplier or site has a recovery objective longer than the RTO of the activities that depend on it. The gap assessment asks both.
Recurring duties
The standard says "at planned intervals" everywhere and fixes no date, so each cadence below is the certification-practice default; adjust it per obligation if your cycle differs. Fourteen obligations land on the compliance calendar with owners, dates and reminders, each naming the clause it serves.
Annual, clauses 8.2.2 and 8.6. Confirm the impact criteria, MTPD, RTO, RPO, minimum capacity and dependencies with the activity owners and have top management approve the result.
Annual, clauses 8.2.3 and 8.3. Re-assess the risks of disruption and confirm that every selected solution can still meet the RTO and minimum capacity in the current BIA.
Annual, clauses 8.5 and 8.3.5. Run the exercises so that every team, activity and solution is validated within the cycle, and measure the achieved recovery time and data loss of the ICT solutions against the RTO and RPO.
Annual, clauses 8.4.4, 4.2.2 and 8.1. Re-approve every plan with its team and contact data, review the register of continuity obligations, and refresh the assurance that each critical supplier can meet its commitments.
Annual (the performance report quarterly), clauses 7.2, 7.3, 9.1, 9.2 and 9.3. Train the role holders, report the indicators, audit the whole scope with independent auditors and hold the management review against the full input list.
Annual, clauses 5.2.1, 6.2.1 and 4.1 to 4.3. Top management confirms or revises the policy and objectives, and the context, interested parties and scope are re-approved with any exclusion justified.
Where the DORA evidence comes from
For a financial entity, the DORA ICT continuity file is a subset of the BCMS file. The overall business continuity policy (Article 11(1)), the business impact analysis (Article 11(5)), the ICT business continuity plans (Article 11(2) and (4)), the yearly test (Article 11(6)), the crisis management function (Article 11(7)), the backup and restoration procedures (Article 12) and the internal audit of the response and recovery plans (Article 11(3)) are all produced by the clauses in this module. On the crosswalk, the plans requirement (BC-8.4.4) shares the business continuity group with DORA, NIS2 and ISO 27001; the other DORA links are left for you to make, because a DORA reviewer checks the ICT-specific content, so attach the same document to the DORA requirement yourself where it genuinely answers it.