To track resilience maturity across business units, score every unit on the same grid: ten business continuity domains, five observable levels each, and a level counts only when its evidence exists. Repeat the assessment every year, consolidate with a weighted average shown next to the weakest unit, and present the result as a heatmap. The grid below is aligned with ISO 22301:2019 clauses 4 to 10.
A business continuity maturity grid is a scoring tool that describes, for each area of a continuity programme, what an organisation visibly does at each stage of development, from improvised to continually improving. This is ResiPlan's own grid. ISO 22301 sets requirements and does not define maturity levels, so the grid is aligned with its clauses; it is not an official ISO maturity model and it is not a certification test.
Download, free and without sign-up: Excel workbook (.xlsx).
What are the five maturity levels?
| Level | Name | What you can observe |
|---|---|---|
| 1 | Initial | Continuity depends on a few people and on improvisation. Little is written, nothing is approved, results vary from one event to the next. |
| 2 | Managed (repeatable) | Basic practices exist and are repeated for the main sites or activities, with a named owner. Methods differ between teams or entities. |
| 3 | Defined | One approved method applies across the whole scope. Documents are controlled and reviewed at planned intervals. Results are comparable between entities. |
| 4 | Measured | Performance is measured against targets (recovery times achieved, exercise results, action closure). Management decides on data. |
| 5 | Optimised | Lessons from incidents, exercises and peers drive continual improvement. Continuity is built into projects, purchasing and investment decisions. |
The grid: ten domains, five levels each
Each cell gives an observable criterion and the evidence that typically proves it. Clause numbers refer to ISO 22301:2019.
1. Governance and policy (clauses 5.1 to 5.3, 6.2, 7.1)
| Level | Observable criterion | Typical evidence |
|---|---|---|
| 1 | No approved policy; continuity is left to IT or to one volunteer | None, or an unapproved draft |
| 2 | Policy written and signed by a manager; part-time owner named | Signed policy, appointment email |
| 3 | Policy approved by top management and communicated; roles, deputies, budget and measurable objectives set | Board or executive minutes, RACI, objectives, budget line |
| 4 | Objectives tracked with indicators reported to top management at least yearly; resources adjusted on results | Management review minutes, indicator dashboard |
| 5 | Continuity built into decisions on projects, acquisitions and new suppliers; policy revised from lessons learned | Project gate checklist, policy revision log |
2. Context and scope (clauses 4.1 to 4.4)
| Level | Observable criterion | Typical evidence |
|---|---|---|
| 1 | Scope implicit; legal and contractual continuity obligations unknown | None |
| 2 | Scope written for the main site or activities; key customer requirements listed | Scope note, list of customer requirements |
| 3 | Documented scope with justified exclusions; register of interested parties and of legal, regulatory and contractual requirements; decision recorded on whether climate change is a relevant issue (Amendment 1:2024) | Scope statement, requirements register |
| 4 | Register reviewed at planned intervals and after each change; scope changes traced | Review dates, change log |
| 5 | New regulations, sites and acquisitions are reflected in scope and obligations before they apply | Regulatory watch notes, scope updated before go-live |
3. Business impact analysis (clause 8.2.2)
| Level | Observable criterion | Typical evidence |
|---|---|---|
| 1 | No BIA; recovery priorities assumed by IT | None |
| 2 | BIA done for some activities through interviews; recovery times set without business sign-off | Departmental spreadsheets |
| 3 | Common method and impact scale; prioritised activities with MTPD, RTO, RPO, minimum service level and dependencies (people, ICT, sites, suppliers), approved by business owners | Signed-off BIA records, dependency map |
| 4 | BIA reviewed yearly and after change; RTO and RPO compared with recovery times achieved in tests; gaps tracked | Gap report "required vs tested" |
| 5 | BIA linked to plans, suppliers and assets and kept current; impact figures used in investment cases | Linked records, investment files |
Guidance: ISO/TS 22317:2021. Method and template: business impact analysis.
4. Risk assessment (clause 8.2.3)
| Level | Observable criterion | Typical evidence |
|---|---|---|
| 1 | Disruption risks discussed only after incidents | None |
| 2 | List of main threats (fire, IT outage, cyber-attack, key supplier) without consistent scoring | Threat list |
| 3 | Documented method; risks of disruption to prioritised activities and their resources assessed; treatment decided and owned | Risk register with owners and treatment decisions |
| 4 | Risk indicators monitored; treatment effectiveness checked; register updated after incidents and exercises | Indicator reports, register history |
| 5 | Severe but plausible scenarios and concentration risks (shared suppliers, regions) analysed, linked to enterprise risk management | Scenario library, link to the enterprise risk register |
Clause 8.2.3 covers disruption risks; clause 6.1 covers risks and opportunities for the management system itself. Score them together here, but do not confuse them.
5. Strategies and solutions (clause 8.3)
| Level | Observable criterion | Typical evidence |
|---|---|---|
| 1 | Workarounds improvised on the day; no alternate resources | None |
| 2 | Some solutions exist (backups, spare laptops, second site) but are not linked to the BIA | Asset lists, backup reports |
| 3 | Strategies chosen from BIA and risk results for each prioritised activity; resource needs documented (people, data, premises, equipment, ICT, logistics, finance, partners and suppliers); solutions in place | Options analysis, contracts, recovery documentation |
| 4 | Solutions tested against RTO and RPO; cost and benefit reviewed | Test results showing achieved recovery times |
| 5 | Solutions shared across entities where it makes sense, automated where possible, resilience required in new designs | Architecture standards, design reviews |
6. Plans and procedures (clauses 8.4.1, 8.4.2, 8.4.4, 8.4.5)
| Level | Observable criterion | Typical evidence |
|---|---|---|
| 1 | No plan, or a generic document nobody has read | None |
| 2 | Plans exist for IT recovery or one site; contact lists partly out of date | Plan files, contact list |
| 3 | Response structure with activation criteria, crisis team and deputies; plans per prioritised activity with actions, resources and information flows; recovery and return-to-normal steps; controlled versions available offline | Plan set, version history, offline copies |
| 4 | Plans updated within a set time after each exercise or incident; contacts checked at a set frequency | Update log, contact check records |
| 5 | Modular plans and reflex cards that work for any scenario, reachable on mobile; peer reviews | Reflex cards, peer review notes |
Template: business continuity plan.
7. Exercises and tests (clauses 8.5, 8.6, 7.2, 7.3)
| Level | Observable criterion | Typical evidence |
|---|---|---|
| 1 | No exercise, or fire drills only | None |
| 2 | Occasional exercise (call tree, one tabletop) without report or follow-up | Invitation, attendance list |
| 3 | Multi-year exercise programme covering all plans and the crisis team, realistic scenarios, a report and actions after each exercise; plan owners trained | Programme, exercise reports, training records |
| 4 | Exercise objectives measured (time to convene, recovery time achieved); action closure tracked; harder formats over time (functional, failover, with suppliers) | Observation grids, metrics, action tracker |
| 5 | Unannounced and joint exercises with key suppliers or authorities; lessons shared across entities; scenarios drawn from threat intelligence | Joint exercise reports |
Scenarios: 10 crisis exercise scenarios.
8. Crisis communication (clauses 8.4.3, 7.4)
| Level | Observable criterion | Typical evidence |
|---|---|---|
| 1 | Whoever answers the phone speaks; no templates | None |
| 2 | Spokesperson named; a few templates; list of key stakeholders | Template folder, stakeholder list |
| 3 | Warning and communication procedures for staff, customers, suppliers, authorities and media; approval workflow; pre-approved holding statements; record of messages; fallback channels | Communication plan, templates, message log |
| 4 | Communication tested in exercises with measured delays (first staff message, first holding statement); regulatory notification deadlines rehearsed | Exercise metrics, notification drill records |
| 5 | Spokespeople trained for media; templates in every working language; social media monitored; group and entity messages coordinated | Training records, monitoring set-up |
Template: crisis communication plan.
9. Supplier continuity (clauses 8.1, 8.2.2, 8.3.4, 8.6)
| Level | Observable criterion | Typical evidence |
|---|---|---|
| 1 | Critical suppliers not identified | None |
| 2 | List of key suppliers known to purchasing; contracts reviewed case by case | Supplier list |
| 3 | Critical suppliers identified from the BIA; continuity terms in contracts (recovery times, incident notification, exit); suppliers' continuity capabilities evaluated; alternatives for single points of failure | Critical supplier register, contract clauses, questionnaires |
| 4 | Supplier performance and test results monitored; concentration on one supplier measured; key suppliers take part in exercises | Supplier review reports, joint test results |
| 5 | Joint continuity planning with strategic suppliers; dual sourcing and exit plans tested | Tested exit plan |
Guidance: ISO/TS 22318:2021.
10. Performance evaluation and improvement (clauses 9.1 to 9.3, 10.1, 10.2)
| Level | Observable criterion | Typical evidence |
|---|---|---|
| 1 | Nothing measured; problems fixed when they come back | None |
| 2 | Some reviews after incidents; actions tracked in emails | Emails, meeting notes |
| 3 | Indicators defined; internal audit programme; management review at planned intervals; nonconformities handled with corrective actions | Audit reports, review minutes, action register |
| 4 | Trends analysed; effectiveness of corrective actions verified; maturity re-assessed every year | Trend reports, verification records |
| 5 | Near misses, benchmarks and external reviews feed improvement; resilience reported to the board alongside financial indicators | Board reporting pack |
How to score?
- Score each domain from 1 to 5. Level 1 is the starting point; a higher level counts when its criterion is met and the evidence can be shown, and every level below it must be met too.
- No evidence, no level. Records such as tests, reviews and audits should be less than 12 months old.
- Whole numbers only: a domain "between 2 and 3" scores 2.
- The entity score is the average of the ten domains, always shown with the lowest domain.
- Set a target level per domain (see the FAQ); the gap between target and score drives the action plan.
- Regulated entities can add criteria to the relevant cells, for example DORA Article 5(2)(e) (the management body approves and periodically reviews the ICT business continuity policy) in domain 1, DORA Article 11(6) (yearly tests) in domain 7, and NIS2 Article 21(2)(c) (business continuity and crisis management) across domains 5 to 8.
How to track resilience maturity across business units?
- One grid, one period. All units use the same version of the grid and assess in the same quarter.
- Self-assessment, then calibration. Each unit scores itself with evidence; a group reviewer samples two or three domains per unit each year and corrects scores that lack evidence.
- Weight by criticality. Give each unit a weight from the group BIA (1 low, 2 medium, 3 critical), not by headcount alone.
- Show the average and the minimum side by side. A weighted average hides weak units; the minimum shows them.
- Red flags override averages. A critical unit at level 1 in BIA, plans, exercises or crisis communication is escalated whatever the group average.
- Assess shared services once. Group IT, shared providers and head-office functions are scored once; a unit cannot score higher on a domain than the shared service it fully relies on for it.
- Track the trend. Keep the previous score and the change for each cell; set targets by criticality (for example 3 to 4 for critical units, 2 to 3 for the others).
Illustrative heatmap (levels 1 to 5; in the spreadsheet, 1 to 2 shows red, 3 amber, 4 to 5 green):
| Unit (weight) | Gov. | Context | BIA | Risk | Strat. | Plans | Exerc. | Comm. | Suppl. | Perf. | Average |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Head office (3) | 3 | 3 | 3 | 3 | 2 | 3 | 3 | 3 | 2 | 3 | 2.8 |
| Plant, Belgium (3) | 2 | 2 | 3 | 2 | 2 | 2 | 2 | 1 | 2 | 2 | 2.0 |
| Distribution, Spain (2) | 2 | 2 | 1 | 2 | 2 | 2 | 1 | 2 | 1 | 1 | 1.6 |
| Services subsidiary (1) | 2 | 2 | 1 | 1 | 2 | 1 | 1 | 2 | 1 | 2 | 1.5 |
| Group, weighted average | 2.3 | 2.3 | 2.3 | 2.2 | 2.0 | 2.2 | 2.0 | 2.0 | 1.7 | 2.1 | 2.1 |
| Group, minimum | 2 | 2 | 1 | 1 | 2 | 1 | 1 | 1 | 1 | 1 | 1 |
Reading: supplier continuity is the weakest domain for the group (1.7), and the Belgian plant, a critical unit, sits at level 1 in crisis communication: these two go to the top of the action plan, before raising the head office from 3 to 4.
If you run this across many entities, ResiPlan's group workspace shows BIA coverage, plans, exercises and open actions entity by entity.
What does ISO 22301 require?
ISO 22301:2019 specifies requirements to implement, maintain and improve a management system that protects against, reduces the likelihood of, prepares for, responds to and recovers from disruptions. Clauses 1 to 3 (scope, normative references, terms) contain no requirements; the requirements sit in clauses 4 to 10.
| Clause | Main requirements | Grid domains |
|---|---|---|
| 4 Context of the organization | Internal and external issues (including whether climate change is relevant, since Amendment 1:2024), interested parties, legal and regulatory requirements, scope of the BCMS | 2 |
| 5 Leadership | Top management commitment, business continuity policy, roles, responsibilities and authorities | 1 |
| 6 Planning | Risks and opportunities for the BCMS, business continuity objectives, planned changes | 1, 4 |
| 7 Support | Resources, competence, awareness, communication, documented information | 1, 7, 8 |
| 8 Operation | Operational planning and control, BIA and risk assessment, strategies and solutions, plans and procedures (response structure, warning and communication, plans, recovery), exercise programme, evaluation of documentation and capabilities | 3 to 9 |
| 9 Performance evaluation | Monitoring and measurement, internal audit, management review | 10 |
| 10 Improvement | Nonconformity and corrective action, continual improvement | 10 |
To check conformity clause by clause rather than maturity, use the ISO 22301 checklist and gap analysis (Excel): the two tools complement each other.
ISO 22301 for small businesses: where to start?
ISO 22301 states that its requirements are generic and apply to all organisations regardless of type, size and nature, and that the extent of application depends on the organisation's operating environment and complexity. A small business does not need level 4 everywhere. Start here:
- Narrow scope: one site, the products and services that matter most (clause 4.3).
- Light BIA on 5 to 10 activities: MTPD, RTO, RPO and dependencies (clause 8.2.2).
- Top five risks to those activities and a decision for each (clause 8.2.3).
- One plan: crisis team, contacts, workarounds, IT recovery, communication (clause 8.4).
- One tabletop exercise with a short report and actions (clause 8.5).
- A yearly review by the manager, using this grid and the checklist (clause 9.3).
A realistic first-year target is level 2 in every domain, then level 3 in BIA, plans and exercises the year after. Step-by-step route: ISO 22301 in 10 steps.
FAQ
What is business continuity management?
Business continuity management (BCM) refers to the way an organisation identifies what it must keep running, prepares the means to do so during a disruption and recovers afterwards. ISO 22301 frames it as a management system (BCMS) that is planned, run, checked and improved.
Is this an official ISO 22301 maturity model?
No. ISO 22301 sets requirements; it does not define maturity levels. This grid is ResiPlan's, aligned with the clauses of ISO 22301:2019.
How is a maturity grid different from a gap analysis?
A gap analysis asks "do we meet each requirement?". A maturity grid asks "how well, and how consistently across units?". Use the gap analysis before certification, the grid to steer progress year after year.
How often should we re-assess?
Once a year, at the same period for all units, and after a major change such as an acquisition, a new site or a serious incident.
Which target level should we aim for?
It depends on criticality: level 3 is a sound target for most domains of a critical unit, level 2 for a small or low-impact unit, and level 4 where regulators or customers expect measured performance.
Sources
- ISO 22301:2019, Security and resilience — Business continuity management systems — Requirements
- ISO 22301:2019/Amd 1:2024, Climate action changes
- ISO 22313:2020, Guidance on the use of ISO 22301
- ISO/TS 22317:2021, Guidelines for business impact analysis
- ISO/TS 22318:2021, Guidelines for supply chain continuity management
- ISO/TC 292, published standards (security and resilience)
- Regulation (EU) 2022/2554 (DORA), Articles 5 and 11, EUR-Lex
- Directive (EU) 2022/2555 (NIS2), Article 21, EUR-Lex