A critical system outage can run into millions, and boards are asking harder questions about resilience than they did five years ago. Yet the numbers meant to answer those questions are still assembled by hand. A 2025 cross-sector survey of UK financial firms by CMORG, the Bank of England convened resilience group, found that 96% of resilience metrics are still produced manually, that reporting is fragmented and inconsistent, and that resilience data rarely reaches every level of the organisation.
That is a strange gap. Boards have never been more engaged. The BCI's Continuity and Resilience Report 2025 found that 45.4% of organisations now have a dedicated resilience lead reporting directly to the board, and 65.5% report increased financial or resource support. The appetite for evidence is there. What is missing is the reporting that turns day to day continuity work into something a board can actually read, trust, and act on.
This guide covers the business continuity metrics that matter, the difference between programme metrics and recovery metrics, and how to report them to an audience that wants decisions rather than a data dump.
TL;DR
- Business continuity metrics fall into four groups: programme coverage, preparedness, recovery capability, and third party dependency.
- Recovery metrics such as RTO and RPO describe a single process. Programme metrics describe whether the whole programme is working. Report them separately.
- Boards want a small set of lead indicators tied to decisions, not a monthly dump of every plan's status.
- Reporting is where most programmes quietly fail: 96% of resilience metrics are still produced by hand, so the pack is late, inconsistent, and out of date the moment it is sent.
- A live platform turns reporting from a quarterly fire drill into a standing dashboard that updates itself.
What are business continuity metrics?
Business continuity metrics are the measures that show whether a continuity programme is genuinely ready to absorb a disruption, and whether it is improving over time. They sit across the whole continuity lifecycle, from the business impact analysis that identifies what matters, through planning, exercising, and incident response, and they exist so that someone who is not in the details every day can judge the state of readiness.
It helps to draw two distinctions that get blurred in most spreadsheets. The first is lead versus lag. A lag indicator tells you what already happened, such as how many plans were reviewed last quarter. A lead indicator tells you what is likely to happen, such as how many critical functions currently have a named owner and a tested recovery strategy. Boards make better decisions from lead indicators, but most packs are built entirely from lag.
The second distinction is programme metrics versus recovery metrics. Recovery metrics describe the tolerance of a single process, and you can read a full breakdown of those in our guide to RTO, RPO, MTD, and MAO. Programme metrics describe the health of the programme itself. Both belong in a report, but they belong in different sections, because they answer different questions.
One word of caution before the list below. More metrics is not more control. Teams that report thirty numbers usually report them inconsistently, and the board learns to skim. The discipline is to choose a small set that maps directly to decisions the board can make: fund a gap, accept a risk, or change a priority. If a metric does not connect to one of those decisions, it belongs in an appendix, not on the front page.
If you want the lifecycle view first, start with the six stages of the business continuity lifecycle.
Why measuring and reporting resilience is harder than most think
It is tempting to assume the hard part is the disruption itself. In practice, for most teams the hard part is proving readiness before anything goes wrong. Three things make that harder than it looks.
Buyers describe the symptom precisely. One enterprise continuity lead, describing their incumbent platform, called it clunky with limited reporting and heavy customization needs. The data was captured, but it never became a story anyone could act on. That is the gap this article is about.
The numbers live in different systems
A single reporting line can require plan status from the continuity tool, dependency data from a CMDB or asset register, supplier information from procurement, exercise results from a spreadsheet, and incident history from a ticketing system. Nothing talks to anything else, so someone reconciles it by hand every quarter. That reconciliation is the reason reporting slips and the reason numbers do not match when two people present the same programme.
The manual burden compounds. Once the pack is late, it gets trimmed. Once it is trimmed, the board sees less, asks fewer questions, and the programme loses the sponsorship that funding depends on. A reporting problem quietly becomes a resourcing problem.
There is also a reporting tax that rarely gets named. Every hour spent reconciling spreadsheets is an hour not spent closing gaps, running exercises, or working with the business on its impact analysis. Across a year that tax can add up to weeks of a small team's time, and it produces a report that is already stale by the time anyone reads it. Automating the assembly is not about looking modern. It is about giving that time back to the work that actually reduces risk.
Recovery metrics and programme metrics are not the same thing
RTO and RPO are excellent at describing what a process can tolerate, and terrible at describing whether your programme is healthy. A team can hit every RTO on paper and still have half its plans unowned, untested, and out of date. When those two ideas are mixed into one dashboard, the board reads green and the programme is amber.
The fix is structural, not cosmetic. Keep a recovery section that reports RTO and RPO attainment per critical function, and a programme section that reports coverage, ownership, exercise completion, and remediation. Readers can then see the difference between a process that recovers quickly and a programme that is actually maintained.
The board wants decisions, not a data dump
Executives do not need every plan's review date. They need to know where the organisation is exposed, what it would cost, and what decision you are asking them to make. The most common reporting failure is not missing data, it is too much of it with no recommendation attached.
A useful board pack answers three questions in the first page: are we more or less resilient than last quarter, where are the material gaps, and what are we asking the board to approve or fund. Everything else is appendix.
Language matters here too. A line that says 92% plan coverage invites a nod and ends the discussion. A line that says eight of our twelve most critical functions have no tested recovery plan, and two of those are customer facing, invites a decision. The same underlying data can inform or bury a message depending on whether it is framed as a score or as an exposure. Write the board pack for the decision you want, and let the metrics carry the evidence.
The 12 business continuity metrics that matter
You do not need a metric for everything. You need a small, stable set that covers the four areas a board actually cares about: whether the programme reaches the right things, whether it is ready, whether it can recover, and whether it depends on someone else. The twelve below are a strong default. Adapt the thresholds to your organisation, but keep the structure.
| Metric | What it answers | Where the data comes from | Cadence |
|---|---|---|---|
| Plan coverage rate | What share of critical business functions have a current, approved plan | Continuity platform | Monthly |
| BIA completion rate | What share of in scope functions have an approved impact analysis | Continuity platform | Monthly |
| Plan ownership coverage | What share of plans have a named owner and a deputy | Continuity platform / HR | Quarterly |
| Exercise completion rate | What share of scheduled exercises ran on time | Exercise module or tracker | Quarterly |
| Exercise action closure rate | What share of post exercise actions were closed by their due date | Continuity platform | Quarterly |
| RTO attainment | What share of critical functions can meet their recovery time objective | BIA and recovery plans | Quarterly |
| Recovery test success rate | What share of recovery tests passed without a critical finding | Testing records | Quarterly |
| Dependency mapping coverage | What share of critical functions have mapped people, technology, vendor, and facility dependencies | Continuity platform / CMDB | Quarterly |
| Critical supplier coverage | What share of critical suppliers have a tested continuity arrangement | Procurement / continuity platform | Quarterly |
| Plan currency | What share of plans were reviewed within the defined cycle | Continuity platform | Monthly |
| Incident readiness | Median time to activate the crisis team, and notification coverage | Incident module | Per incident |
| Remediation closure rate | What share of agreed gaps were closed within target | Continuity platform | Quarterly |
Two of these deserve a note. Plan currency is the metric that catches quiet decay: a plan can be approved and still be wrong, and the only defence is a review cycle that actually runs. Dependency mapping coverage is the one most often missing, because dependencies rarely sit in the same system as the plan. Without it, you cannot see the cascading impact of a single failure, and the board cannot see it either.
Thresholds matter as much as the metrics themselves. A coverage rate of 85% means very different things for plan ownership than it does for critical supplier testing. Set an explicit target for each metric, agree it with the risk committee, and report the gap to target rather than the raw number. That single change turns a status report into a decision tool, because the reader can see where the organisation sits below the line it agreed to hold, and how that gap is trending. A metric that only ever goes up is usually measuring activity rather than readiness.
Dependency visibility is its own topic, and it is worth understanding single points of failure before you commit to a metric for it.
What to look for in business continuity reporting
Once you know which metrics you want, the next question is how to produce and present them without rebuilding the pack from scratch every cycle. Five criteria separate reporting that lasts from reporting that lapses.
Reports that build themselves from live data
If a metric has to be calculated by hand, it will eventually stop being calculated. The strongest reporting setups pull plan status, exercise results, and ownership directly from the system of record, so the pack is a view rather than a project. This is the single biggest difference between teams that report every quarter and teams that report when someone remembers.
A clear split between lead and lag indicators
Look for a report that separates what is likely to happen from what already happened. Lead indicators such as ownership coverage and dependency coverage tell the board where future risk is building. Lag indicators such as incidents survived tell them how the programme performed. Presenting both, in that order, changes the conversation from status update to risk management.
Drill down from board summary to the underlying plan
A summary is only trustworthy if it can be opened up. The report should let a reader move from a headline number to the specific business functions driving it, and from there to the plan, the owner, and the last test. Without drill down, every question becomes a follow up request and the pack never stands on its own.
Ownership and remediation tracking in the same place
Metrics that describe a gap are only useful if the gap is assigned and tracked. Reporting should connect each finding to a named owner and a due date, so the next cycle shows movement rather than the same amber cell. Remediation closure rate is the proof that the programme is closing gaps, not just cataloguing them.
Audit ready evidence and version history
Under frameworks such as ISO 22301 and regimes such as DORA, the question is not only what your metrics say today but what they said, and who signed off, and when. Reporting should keep an immutable history of approvals and changes so a regulator or auditor can trace the programme back through time without a scavenger hunt.
Set against those five criteria, the difference between spreadsheet reporting and platform reporting is stark.
| Dimension | Spreadsheet reporting | Platform reporting |
|---|---|---|
| Data source | Manually pulled from several systems | Live from the system of record |
| Time to produce | Days, every cycle | Minutes, on demand |
| Consistency | Varies by who builds it | Same numbers for everyone |
| Drill down | Separate requests and files | Click through to the plan |
| Audit history | Email threads and file versions | Immutable approval trail |
| Board narrative | Hand written each time | Drafted from the data, approved by a human |
Moving away from spreadsheet reporting
The fear with any change of tooling is migration, and it is a fair fear. The reassuring part is that continuity data is unusually portable: BIAs are structured, plans are documents with owners, and dependencies are relationships. Importing them is a mapping exercise, not a rebuild.
For a typical team, weeks one and two are about importing existing BIAs and plans and confirming the core set of critical functions. Weeks three and four configure the metric definitions and thresholds against your existing cycle, so the first report reflects the programme you already run. By the second month you are producing a live board pack rather than assembling one, and the manual reconciliation that used to fill the week before the meeting is gone. No one is asked to throw away years of work, and nothing is lost: it is the same programme, finally reporting itself.
Within a quarter, most teams stop treating the board pack as a separate deliverable. The numbers are already assembled, the narrative is drafted, and the conversation moves from what happened to what we are doing about it. That shift, from producing reports to acting on them, is the real return on automating continuity reporting.
Related articles
