A business impact analysis that people actually use

Almost every organisation with a continuity programme has a business impact analysis. Far fewer use it. In many cases the BIA is a large workbook completed once a year, signed off and filed, and consulted again only when the auditor asks for it. When a real disruption happens, people work from memory and phone calls.

That is a waste of a valuable exercise. A good BIA answers the questions that matter most in a crisis: what must come back first, how quickly, and what it depends on. This article sets out how to build one that people actually open.

Start from services and processes, not systems

The most common mistake is to start with an inventory of applications and ask how long each can be down. That produces a list of IT recovery targets with no connection to what the organisation actually delivers.

Start instead from what the organisation does for its customers, citizens or patients: the services it provides and the processes that deliver them. For each one, ask the business owner what happens over time if it stops. Impact rarely grows evenly; it tends to jump at certain points, such as the end of a business day, a payment cut-off or a regulatory deadline.

Assess impact across a small number of consistent categories, for example:

• financial loss,
• harm to customers or other people,
• regulatory and legal consequences,
• reputation,
• operational knock-on effects on other processes.

Use the same scale for every process so results are comparable. The aim is a ranking that the management team recognises and can defend.

Set recovery objectives that mean something

From the impact assessment, derive the recovery objectives:

• Maximum tolerable period of disruption (MTPD): the point after which the impact becomes unacceptable.
• Recovery time objective (RTO): the target time to resume the process at an acceptable level, which must be shorter than the MTPD.
• Recovery point objective (RPO): how much data loss, measured in time, the process can tolerate.

It also helps to state the minimum level of service you would accept during recovery. Resuming at 40 per cent capacity within four hours may be more realistic, and more useful, than a full recovery target nobody can meet.

Be honest about the difference between what the business needs and what the current set-up can deliver. That difference is not a failure of the BIA; it is one of its most important outputs.

Map the dependencies

A process depends on more than an application. For each prioritised process, record what it needs to run:

• People: key roles, minimum staffing and scarce skills.
• IT: applications, infrastructure and data, ideally linked to your asset inventory or CMDB rather than retyped.
• Suppliers: third parties and outsourced services, including the contracts that govern them.
• Sites: offices, data centres and other facilities, and whether work can move elsewhere.
• Other processes: upstream inputs and downstream consumers.

Dependencies are where the BIA earns its keep. They show when a process with a four-hour RTO relies on an application with a recovery capability of two days, or on a single supplier with no tested alternative. These recovery gaps are what management should see first.

Keep it live

A BIA goes stale for the same reasons any register does: organisations reorganise, systems are replaced, suppliers change and nobody updates the file. A few habits keep it current:

• Assign an owner per process who is accountable for its impact assessment and dependencies.
• Review on change, not only annually: new systems, new suppliers, mergers and incidents should all prompt a review of the processes they touch.
• Link instead of copying. When the BIA refers to assets and suppliers that are maintained elsewhere, changes flow through automatically.
• Keep it short enough to maintain. A focused set of well-understood processes is better than hundreds of rows that nobody checks.

Connect it to recovery plans and exercises

A BIA that stands alone remains a document. Its value comes from what it drives.

Recovery plans. Disaster recovery and business continuity plans should be built for the processes and dependencies the BIA prioritises, and should state recovery targets that match its RTO and RPO. When the BIA changes a target, the plan owner should know.

Exercises. Testing should prioritise the most critical processes and the riskiest dependencies. An exercise is also the best way to check whether the recovery objectives are realistic. If a test shows that recovery takes twelve hours against an RTO of four, either the plan or the objective must change, and that decision belongs to the business.

Incidents. During a real disruption, the BIA tells the crisis team what to restore first. After the incident, the review should feed back into the BIA: was the impact as expected, were the dependencies complete?

Reporting. Executives do not need the workbook. They need to know which critical services have recovery gaps, which plans are out of date and which exercises found problems that are still open.

A practical starting point

If your current BIA is a workbook nobody opens, you do not need to start again. Pick the five to ten services that matter most, confirm their owners, validate the impact and recovery objectives with them, and map their dependencies properly. Connect those to the recovery plans and the next exercise. Then extend the scope.

Tools can help by holding processes, assets, suppliers, plans and exercises as linked records, so a recovery gap is visible as soon as a dependency's capability falls short of a process's RTO. But the conversations with process owners are what make the analysis credible.

This article is general information, not legal advice.