What Is Business Impact Analysis?

A business impact analysis establishes what the organisation actually cannot do without, and for how long. It is the input that makes business continuity and disaster recovery planning proportionate rather than guessed.

Without it, recovery investment is allocated by whoever argues most persuasively, which reliably overprotects some systems and leaves genuinely critical ones unaddressed.

The two numbers it produces

Recovery time objective — how long a process can be unavailable before the consequences become unacceptable. Recovery point objective — how much recent data can be lost, which sets backup frequency.

These are business decisions expressed in technical terms. They should come from the people who own the process and bear the consequence, not from the technology team estimating what is achievable.

Everything is critical until it is costed

Ask any department whether their system is critical and the answer is yes. Ask what the first four hours of an outage actually costs, what the manual workaround is, and what happens after a week, and the answers differentiate sharply.

That is the purpose of the exercise: converting a list where everything is essential into an ordering that can guide investment.

Dependencies are where analyses fail

A process assessed as recoverable in four hours may depend on a system assessed as recoverable in two days. Applications depend on directories, databases, name resolution, network, and increasingly on third-party services outside your control.

Mapping those dependencies is the difficult and valuable part. Recovery sequencing depends on it entirely, and the discovery that a critical application cannot start until something nobody classified as critical is running is a standard finding.

Third-party dependencies count

Where a critical process depends on an external service, your recovery objective cannot be shorter than theirs. That constraint is frequently discovered during an incident rather than during planning.

Which makes the provider's own commitments, and what happens if they are unavailable for a day, part of the analysis rather than a procurement detail.

Keeping it current

An analysis ages as systems, processes and dependencies change. One performed three years ago describes an environment that has moved on, and recovery plans built on it protect the wrong things.

Annual review of the objectives, with a fuller refresh when a major system changes, is a reasonable commitment. It is considerably less work than the original exercise.

Who should answer the questions

The analysis is only as good as its sources, and the right sources are the people who perform the process rather than the managers who own it. Managers describe how the process is supposed to work; the people doing it know which step actually stops everything.

That also surfaces the undocumented workarounds and the spreadsheet on somebody’s desktop that the whole process quietly depends on — which is usually the single most valuable finding the exercise produces.

Where to start

Pick your most important business process and ask its owner what the first four hours of an outage costs and what the manual fallback is. Their answer will be more informative than any technical assessment.

See a 72-hour downtime plan. GuardsArm runs security risk assessments.