Business impact analysis (BIA)

A business impact analysis does not measure threats or probabilities. That is risk analysis, a different exercise answering a different question. A BIA takes the interruption as given and measures its consequences: what stops, who it affects, how long that can be tolerated and what each passing hour costs.

The distinction matters because it changes who has to be in the room. A risk analysis can be carried almost entirely by the technical team. A BIA cannot: the person who knows what twelve hours of stopped invoicing costs sits in finance, and the person who knows which customers leave when the portal is down sits in the business. A BIA run only by IT ends up ranking servers by how much they cost to buy.

And its output is not a report to file. It is an ordered list. When everything is down at once, somebody has to decide what comes back first, and that decision is made far better in the cold than at three in the morning.

Identify critical activities. Not systems, activities: taking payment, serving a customer, manufacturing, running payroll. Systems come later, when you ask what each activity depends on. Starting from the technical inventory is the most common mistake and it produces a list of machines with no priority attached.

Map the dependencies. What each activity needs in order to run: applications, data, suppliers, named individuals, a communications line. This is where the surprises appear, because there is almost always a shared component half the company hangs off that nobody had on their list. A current asset inventory saves half of this step.

Estimate how long it can be tolerated. Every activity has a point where the damage stops growing gradually and jumps: a legal deadline is missed, the customer is lost, the production line stops. That point is what you are looking for, and it is not the same for two activities in the same organisation.

Quantify the loss. Revenue that does not arrive, recovery costs, contractual penalties, fines, reputational damage. Reputational damage cannot honestly be reduced to a number, so it is declared separately rather than given an invented figure.

Prioritise with that in front of you. The output is the recovery order and the budget it justifies: what deserves a hot standby, what deserves an immutable backup and what can wait two days without anything serious happening.

The RTO, or recovery time objective, is how long an activity can stay down before the damage becomes unacceptable. The RPO, or recovery point objective, is how much data can be lost, measured in time: an RPO of one hour means it is acceptable to return to the state of one hour ago.

Both are business decisions, not technical capabilities. It is common for a BIA to reveal that the RTO the board assumes is measured in minutes while the architecture that was actually bought delivers hours. That gap is the finding, and discovering it in a meeting is immeasurably cheaper than discovering it during an incident.

The RPO also determines what the backups have to look like: how often they run, where they live and what restores them. A backup taken every night cannot meet a one-hour RPO however confidently a slide says otherwise.

It was written with fires, floods and power cuts in mind. What moved it to the centre of security is ransomware, because it produces exactly the scenario a BIA models: everything stopped at once, no return date, and the backup as the only way out.

It also adds a condition no natural disaster has: the attacker was inside first, so the backups may be encrypted or deleted too. That is why a modern BIA asks not only how long a restore takes, but where the restore comes from if the attacker held the administrative credentials.

A distributed denial of service poses the same question on a smaller scale: nothing is broken, but nothing responds. If the BIA has not put a number on that hour of unavailability, the conversation about how much to spend protecting it has nothing to weigh against.

The link to incident response is direct: the BIA decides what is recovered first and the playbook says how. Without the first, the second gets improvised in order of who shouts loudest.

ISO 27001 handles it under business continuity: an organisation has to determine its requirements for continuity of information security, and determining them without having measured impact does not survive an auditor’s questions.

DORA is more explicit for financial entities: it requires business impact analysis against severe disruption scenarios, and continuity testing carried out against those scenarios. NIS2 points the same way for the entities it covers, and Spain’s ENS requires it in the operational framework for high-category systems.

The uncomfortable part is worth saying: a BIA written to pass an audit rather than to be used shows immediately, because every activity comes out critical with the same deadline. If everything is a priority, there is no priority, and the document no longer does the one thing it was for.

A financial firm runs a BIA against a total unavailability scenario. It identifies three critical activities: transaction processing, online customer services and the risk management systems.

The team’s instinct was that online banking came first, because it is what customers see. The analysis says otherwise: transaction processing has a far shorter recovery deadline, because stopping it breaks commitments to third parties that do not follow opening hours. Online banking tolerates more than expected, and risk management, which nobody had put on the list, turns out to be what blocks a return to normal operation.

The result is not a number. It is that the recovery order changes, and so does the spending, because only the first activity justifies the cost of keeping a hot recovery capability. The figures in this example are illustrative and come from no client.

The BIA says which systems cannot be allowed to stop. Pentesting aimed at ISO 27001 answers the question next to it, which the BIA does not ask: whether those systems can be reached, from where, and with how much effort.

Together the two answers are what let you decide. A critical system that cannot be reached and a secondary one exposed to the internet do not warrant the same investment, and without both measurements that comparison is made by eye.