I was in the room when a DR program that had taken three years to build got cut in an afternoon.

At Land O’Lakes, a budget meeting turned into a postmortem for a program that was still running. The CISO couldn’t point to a number. The VP of IT shrugged. No one challenged the cut because no one could articulate what the program had actually delivered. The program was real. It was working. And it was invisible.

That’s a visibility problem, not a program problem, and metrics are how you fix it.

The Mistake Most Programs Make

The people doing BC/DR work know exactly how much effort goes into it. Leadership usually doesn’t. When budgets get tight, invisible programs get cut, not because they’re failing, but because nobody has made a credible case for what they’re doing.

The typical response is to produce more reporting; longer dashboards, more detail, more data. That’s the wrong direction. The problem isn’t volume, it’s translation.

Most BC/DR programs make two related errors with metrics:

• They build one report and send it to every stakeholder. Executives, IT leads, and divisional managers all care about fundamentally different things. A single report engages nobody.
• They report on activity rather than outcomes. Plan completion percentages and exercise counts describe what the program is doing, not what it’s protecting.

Know Who You’re Measuring For

Before you build a single dashboard, answer this question; who is this for, and what decision do they need to make?

In practice, most executives want one fact, overall program health, with a clear red/yellow/green status. That’s it. Anything more and you’ve lost them before the second slide. Your divisional IT/department leaders, on the other hand, want granular detail about their own plans and nothing about anyone else’s.

Build your reporting architecture around those two different audiences, not around what’s easiest to produce.

Build a Scoring Framework That Forces Honesty

Here’s an uncomfortable truth; most BC/DR plans in large organizations exist somewhere between incomplete and fictional. They satisfy an audit checkbox. Then nobody looks at them until something goes wrong.

A structured scoring framework forces honesty across three dimensions:

• Completion – Have the fundamental plan components actually been built? Scope definition, recovery team assignment, loss scenarios, plan approvals. This gives you a concrete progress indicator that’s hard to argue with.
• Quality – A plan that exists isn’t the same as a plan that works. Score quality across recovery task detail, RTO/RPO validation, team technical competency, and training completion. This is where most programs fall apart; completion looks fine, quality tells a different story.
• Currency – Is the program staying current? Time since last exercise, after-action report completion, and plan review cadence keep the program from going stale. An unexercised plan is a hypothesis, not a recovery strategy.

Combine these into a single weighted score with red/yellow/green thresholds. Every stakeholder gets an immediate read on program health without needing to interpret raw data.

What This Looks Like in Practice: Jabil

When I led the development of the global disaster recovery and crisis management program at Jabil, the program had real capability but almost no leadership visibility. Two executives engaged with it regularly; the CISO and one divisional CIO. That was it.

We built a unified executive dashboard anchored around a single program health score with red/yellow/green status. Supporting that number were two additional views; a trend chart showing program trajectory over time, and a breakdown by division and site so regional leaders could see their own standing clearly.

The design principle was deliberate; one number for the executive who needs to decide whether the program deserves attention, trend data for the leader who wants to see whether it’s moving in the right direction, and divisional detail for the leader who manages the team doing the work.

Within two quarters, participation had grown from two executives to five divisional CIOs and their direct reports, CTOs and VPs of IT who hadn’t previously engaged with the program at all. The dashboard hadn’t changed the program. It had made the program legible to the people who needed to act on it.

Connect Metrics to Business Outcomes, Not Program Activity

If you walk into a leadership meeting talking about plan completion percentages, you’ll get polite nods and no action. Walk in talking about revenue exposure during an unplanned outage, regulatory risk from an audit failure, or customer trust implications of a major incident, and you’ll get a different conversation.

The metric hasn’t changed. The translation has.

Four business outcomes consistently unlock leadership attention in BC/DR:

• Revenue protection – what does an hour of downtime cost, and how does the program reduce that exposure?
• Regulatory compliance – what audit or exam risk does an immature program create?
• Data security – how does recovery capability connect to breach response and data integrity?
• Customer trust – what’s the reputational exposure of a visible failure?

Anchor every metric you report to at least one of these four. That’s the shift — from reporting what the program does to explaining what the organization loses without it.

Report Consistently, Before Anyone Asks

The single biggest credibility killer for a BC/DR program is inconsistent reporting. If leadership only hears from you when something goes wrong or when you need budget, you’ve already lost the narrative.

Monthly reporting with quarterly live reviews isn’t just good practice, it’s how you build the institutional trust that protects your program when priorities shift. At Jabil, moving to a fixed monthly cadence changed the dynamic from “the BC/DR team needs something” to “the program update is on the calendar.” That sounds small. It isn’t. When your GRC platform can automate exception flags and status notifications, use it — anything that removes manual follow-up removes the inconsistency that kills credibility.

Practical Dos and Don’ts

Do

• Build separate views for separate audiences, executives need one number, IT leads need their own detail
• Score programs across completion, quality, and currency, completion alone masks real risk
• Tie every metric to a business outcome; revenue, regulatory, security, or customer trust
• Report on a fixed cadence regardless of whether there’s news to share
• Use trend data to show direction, not just current state

Don’t

• Send the same report to every stakeholder
• Report on activity (exercises run, plans updated) without connecting it to outcome
• Wait for a budget cycle or an incident to make your program visible
• Let reporting become a manual burden that creates inconsistency
• Mistake a complete plan for a capable one, they’re different things

The Bigger Point

The Land O’Lakes program that got cut in that budget meeting wasn’t a bad program. It was an invisible one. Nobody in the room had the numbers to defend it, so nobody did. That’s the real risk metrics protect against, not audit findings or regulatory gaps, but the budget conversation where your program can’t speak for itself.

Metrics aren’t just a reporting tool. They’re a political tool. They give your stakeholders something to defend when someone asks why the program exists.

Pick three metrics that connect directly to outcomes leadership cares about. Build the simplest dashboard that makes program health legible at a glance. Report on a fixed cadence before anyone asks. The programs that hold up under budget pressure are the ones that have already made the case before the room gets quiet.