Business Impact Analysis

[COMPANY NAME]

Effective date: [DATE] · Owner: [NAME, TITLE] · Review: annually, or after any material change

Purpose

A continuity plan answers the question “what do we do”. This document answers the one that has to come first: what actually matters, and how long have we got.

It works through each thing [COMPANY NAME] does, asks what it costs when that thing stops, and turns the answer into two numbers a recovery plan can be built on: how long it can be down, and how much data it can afford to lose.

Most of the value here is in the rows that come back boring. Everyone starts a continuity project convinced that everything is critical, and most processes turn out to be survivable on paper for a week with nobody outside noticing. Every one of those is money that does not have to be spent on fast recovery. The handful that come back genuinely urgent are where the budget belongs.

If every row reads Tier 1, the analysis has not been done. That is a wish list.

Scope

Covers every business process [COMPANY NAME] depends on to earn money, meet an obligation or keep a commitment — not only the ones that run on computers. Order intake, dispatch, invoicing, payroll, client communication, regulatory filing, and anything a customer would notice stopping.

Excluded from this analysis: [LIST ANYTHING EXCLUDED, AND WHY]. An exclusion is a decision, so it is recorded with the name of whoever made it.

How to use this

Three passes. Do not attempt them at once.

1. List the processes. Every distinct thing the business does. Aim for 10 to 25 rows. More than 40 and you are listing tasks, not processes.
2. Score the impact. For each one, what happens at 24 hours, 72 hours, a week. Score it before thinking about IT at all.
3. Set the numbers, then the dependencies. Downtime and data-loss targets fall out of the impact scores. Dependencies come last, because what a process depends on only matters once you know the process matters.

Do this with the people who run the work, not with IT. IT knows what the systems do. The bookkeeper knows what happens when invoicing stops on the 30th.

Process inventory

A process has a start, an end and an owner — “issue customer invoices”, not “accounting”. If two things always break together and always recover together, they are one row.

Impact over time

Impact is not linear. Most processes are survivable for a while and then fall off a cliff. The point of this table is to find the cliff.

Score each process at each interval: None · Minor · Serious · Severe

Then record why it hurts, in the categories that actually cost something.

Regulatory deadlines do not care that you had an outage. Where a filing, a payroll run or a breach notification has a statutory clock, that clock is the maximum downtime whatever the revenue math says.

When it hurts most

A process can be trivial on the 3rd and existential on the 14th. A plan built on the average will fail on the worst day.

Downtime and data-loss targets

Three different numbers, and they are confused constantly.

Recovery time is downtime. Recovery point is data loss. They are set independently and they cost different things — a one-hour recovery point means nightly backups are not enough, whatever the recovery time says.

Tiering. Tier 1 is a maximum tolerable downtime under 24 hours. Tier 2 is one to three days. Tier 3 is more than three days. If more than about a quarter of the rows land in Tier 1, go back and re-score — something is being called critical that is merely annoying.

Any recovery time shorter than what the current backup and restore arrangement can actually deliver is a gap, not a target. Record it in section 10 rather than leaving it in this table looking true.

Dependencies

For each Tier 1 and Tier 2 process, what has to be working for it to run.

This is where the surprises are. Count how many processes name the same vendor, the same system or the same person. Anything appearing under three or more is a concentration, and it is usually not the thing anyone was worried about.

Manual workarounds

For every Tier 1 and Tier 2 process: what do people actually do while it is down?

“We would figure it out” is not a workaround. Where the answer needs a printed list, a phone number or a login somebody has to reach without the network, that is a requirement — it belongs in the Business Continuity Plan.

Findings and gaps

The part most firms skip. The analysis is worth nothing until it produces a list somebody owns.

Where a recovery time cannot currently be met, say so plainly here and put a date on it. An analysis recording a four-hour recovery time the business cannot achieve is worse than no analysis, because the continuity plan will be built on it.

What this feeds

This document is an input, not an end.

The Business Continuity Plan takes its critical functions, its maximum tolerable downtime column and its recovery order from sections 5 and 7. The Backup and Recovery Policy takes its recovery objectives from section 7 — and the recovery point column is what decides backup frequency. The Incident Response Plan takes dependency owners and contacts from section 8.

Change a number here and change it there too. Three documents holding three different recovery times for the same system is the normal failure.

Responsibilities

[POLICY OWNER] maintains this analysis and keeps it true.

Process owners score their own rows honestly, including the ones that turn out not to matter.

Business owner signs off the tiering and the spend it implies.

IT support or provider confirms which recovery times and recovery points are currently achievable, and says so when they are not.

Review

Reviewed at least annually by [POLICY OWNER], and after any of: a new line of business, a system migration, a change of premises, an acquisition, the loss of a key person or vendor, or any actual disruption.

A real outage is the only honest test this document ever gets. After one, correct the numbers to what actually happened.

Template provided free by Cybertitans LLC, Woodbury, Minnesota. It is a starting point, not legal advice, and it has not been reviewed against your contracts, your industry’s regulations or your retention obligations. Have counsel review it before you adopt it. Downloading or using this template does not create a client relationship with Cybertitans, and Cybertitans makes no representation that adopting it satisfies any insurer, regulator, auditor or customer requirement.