Your BIA Is a Shelf Document

Category: Operational Resilience Author: Cody Swidler Tags: BIA, business impact analysis, RTO, RPO, criticality, recovery gaps, resilience

I once watched an organization spend six months on a business impact analysis. Forty processes assessed, sixty interviews conducted, a beautifully formatted deliverable with an executive summary and a glossary. Eight months later they had a real outage — a core platform down across a settlement window. Nobody opened the BIA. Not once, not during the incident, not in the postmortem. The recovery order was improvised by whoever was loudest on the bridge call, and the process everyone scrambled to save first turned out to be one the BIA had rated Tier 3.

That BIA wasn't unusual. It was typical. Most business impact analyses are produced to satisfy a framework requirement — ISO 22301 says have one, the examiners ask for one, so one gets made. And a document produced to be had rather than used reliably ends up on the shelf, aging quietly while the organization it describes keeps changing.

How BIAs Go Wrong

The failure pattern is consistent enough that I can usually predict it from the project kickoff. The assessment is framed as an interview campaign, which means the outputs are opinions — every process owner rates their own process as critical, because nobody volunteers to be Tier 3. There's no written scale behind the ratings, so "high impact" means whatever each interviewee felt that afternoon. Recovery objectives get set by asking "how fast do you need this back?" — a question whose answer is always "immediately" — instead of deriving them from impact. And the finished document has no owner, no refresh trigger, and no connection to any decision anyone actually makes.

The result is a BIA that can't be challenged and can't be used. When everything is critical, nothing is. When the RTO is aspiration rather than analysis, the disaster recovery team quietly ignores it. And when the document isn't wired into any operating rhythm, it's stale within two quarters — the exact failure mode I described in operational resilience is an ownership problem: the artifact exists, but nobody owns what it's for.

What a Working BIA Actually Does

A BIA that earns its keep is not a document. It's a scoring model with three jobs: rank the processes, derive the recovery objectives, and expose the gaps between what you've promised and what you can prove.

The ranking comes from scoring each process on defined impact dimensions — I use five: financial, operational, customer, regulatory, and reputational — against written thresholds, the same discipline that makes a risk assessment data-driven instead of a feelings survey. The peak criticality is the maximum across dimensions, not the average, and that's deliberate: a process that would trigger a regulatory breach at hour four doesn't get to look moderate because its financial impact is mild. From peak criticality falls the tier, and the tier — not the process owner's enthusiasm — sets the recovery expectation. A Tier 1 process carries a demanding MTD, RTO, and RPO because its impact profile demands one; a Tier 4 process is explicitly allowed to wait, which is just as important, because recovery capacity spent on deferrable processes is capacity stolen from critical ones.

The Column That Matters Most

Here's the part almost every BIA omits, and it's the part that turns the exercise into a decision tool: next to the stated RTO, record the proven recovery time — as tested, not as hoped. The last DR exercise restored this platform in eleven hours. The stated RTO is four. That's not a detail; that's a seven-hour gap between what leadership believes and what the evidence shows, sitting in plain sight on one row.

When you put stated objectives and proven capability side by side across the whole inventory, the BIA stops being descriptive and starts being confrontational — in the productive sense. The gaps become a ranked remediation list. The remediation list becomes a budget conversation with actual numbers in it. And the next tabletop or DR test has an obvious agenda: attack the gaps, not the processes you already know recover cleanly. Suddenly the document is load-bearing, because three real decisions — recovery investment, test scheduling, and incident prioritization — read from it.

One Assessment, Many Consumers

A BIA built this way also stops being just a continuity artifact. The criticality tiers feed vendor risk — a vendor supporting a Tier 1 process is a critical vendor, by inheritance rather than by debate. The dependency columns feed your concentration analysis. The impact scores feed the enterprise risk register on the same 1-to-5 scale. That's the integration argument I made in integrating risk assessments: assess once, on shared scales, and let resilience, third-party risk, and ERM all consume the same answers. The BIA is usually the best place to start that integration, because it's the assessment with the most natural downstream consumers.

And when the incident actually comes, the tiers become the recovery order and the gaps become the known weak points — which is exactly what the incident commander needs in minute five, as I argued in incident command is the backbone of resilience. The BIA the organization I mentioned never opened? It failed precisely because there was nothing in it an incident commander could use. No ranking anyone trusted, no objectives anyone had tested, no gaps anyone had surfaced.

Keeping It Off the Shelf

The maintenance answer is boring and effective: give the BIA an owner, a refresh cadence tied to change rather than the calendar alone, and a standing slot in your governance rhythm. New Tier 1 process, material vendor change, failed recovery test — each triggers a row-level update, not a six-month re-interview campaign. Quarterly, the gap list goes to the same forum that reviews your top risks. A BIA maintained in rows survives; a BIA maintained in projects dies between projects.

Score the impacts against written thresholds. Let the maximum set the tier, the tier set the objectives, and the evidence expose the gaps. Then wire the output into the three decisions it should own. That's the difference between a shelf document and the operating spine of your resilience program — and it's less work than the interview campaign, not more.

Cody Swidler is the founder of PivotRisk and a Principal Program Manager, Enterprise Resiliency at Apex Clearing. He has built and scaled GRC, resilience, and risk programs across Microsoft, Twilio, Box, Zayo, and Miro.