The business impact analysis is the step at which it is decided whether a continuity concept will hold. Causes belong to the risk analysis. The BIA answers what the outage costs, from when it becomes intolerable, and which resources have to be available again for the process to keep running. Everything downstream, from the continuity strategy to the emergency plan, builds on its results.
How does a business impact analysis work?
- Record and delimit the business processes, starting from the services owed to customers, regulators and the supply chain.
- Assess how damage develops for each process along a time axis, not as a single figure but staged by duration of the outage.
- Derive the time objectives and agree them with the process owners.
- Gather the resources required and the dependencies.
- Consolidate the results, resolve contradictions and have them approved by the management body.
The last step is often skipped. It matters most, because a BIA contains commitments whose fulfilment costs money.
Which damage categories does a BIA consider?
| Category | Example |
|---|---|
| Financial | lost revenue, contractual penalties, the extra cost of degraded operation |
| Legal and regulatory | breach of reporting or retention duties, supervisory consequences |
| Service delivery | delivery and service commitments not met |
| Reputation | loss of confidence among customers, regulators and the public |
| People and environment | risk to health, safety or the environment |
Each category is assessed along a time axis: after a few hours, after a day, after several days, after a week. Only that progression shows where the damage rises abruptly, and that is where the limit of tolerability lies.
Which metrics does a business impact analysis produce?
Four metrics carry the analysis. A German BIA sheet will name them in English and put the official German terms of BSI-Standard 200-4 alongside, so both are worth having.
| Metric | German term in BSI-Standard 200-4 | What it fixes |
|---|---|---|
| MTPD | Maximal tolerierbare Ausfallzeit (MTA) | how long a business process may be down at most before intolerable consequences follow |
| RTO | Geforderte Wiederanlaufzeit (WAZ) | the span from declaring the emergency to the required start of the continuity solution |
| RPO | Maximal zulässiger Datenverlust | how old the available data may be and still support useful work in degraded operation |
| MBCO | Notbetriebsniveau | how capable degraded operation has to be, per process |
Alongside these, German continuity documents sometimes also distinguish a Wiederherstellungszeit (WVZ), the target for the return to normal operation as opposed to degraded operation. It sits beside the four above rather than among them, so it is worth checking what a particular document means by it before comparing figures.
There are no normative target values for any of these. What decides instead is an arithmetic point missing from many BIAs: the recovery time objective starts only when the emergency is declared, not when the damaging event occurs. Before it lies the response time for detection, alerting, constituting the crisis organisation and taking the decision. BSI-Standard 200-4 draws the consequence in mandatory terms: the recovery time objective has to be shorter than the maximum tolerable period of disruption, because the response time is subtracted from it. Set the two equal and the commitment is already missed arithmetically, before any measure takes effect.
The second test is technical: backup frequency, redundancy, replacement lead times and staff availability have to support the value. Numbers nobody has underpinned show up at the latest in the exercise.
Which resources and dependencies does a BIA capture?
For each time-critical process, record what it needs: staff with particular qualifications, applications and the infrastructure beneath them, buildings and workplaces, equipment, and internal and external service providers. The chains are what matters. Supporting processes and shared base services inherit the requirement of the most critical process that sits on top of them. An application with a short recovery time objective is worthless if the directory service its sign-in depends on takes considerably longer.
How it differs from the risk analysis
The BIA asks about the effect of an outage, irrespective of cause and likelihood. The risk analysis asks about causes, probabilities and preventive measures. Both are needed: without the BIA there is no prioritisation, without the risk analysis no justification for which scenarios are provided against.
Methodological basis
The BIA has a standards document of its own: ISO/TS 22317:2021, "Guidelines for business impact analysis", a technical specification that builds the terse requirement in ISO 22301 out into a complete procedure. The second edition of 2021 supersedes the 2015 edition and is aligned with ISO 22301:2019. In the German-speaking world BSI-Standard 200-4 describes the same procedure and additionally makes document templates available free of charge, which is the pragmatic route when buying the ISO document is not worth it.
Against the most common failure (every process declaring itself time-critical), the BSI standard has a step of its own, the BIA pre-filter (BIA-Vorfilter). It narrows down, before the detailed survey begins, which processes go into detailed consideration at all, and so keeps the effort where it changes something.
Why do business impact analyses fail?
- The survey is filled in by IT rather than by the process owners.
- Every process is deemed time-critical, at which point the analysis loses its purpose.
- Dependencies stop at the application boundary; shared base services stay invisible.
- The results are not updated after the first survey, although processes and service providers change.
Two measures that are not the same
A BIA measures impact over time; a protection-need assessment measures the requirement against a protection goal. The two are regularly conflated because both work with a scale. In Rizzqo they stay apart, which helps for availability: the confidentiality, integrity and availability rating sits on the primary asset and is inherited by the supporting objects carrying it.
The time dimension, meaning from when an outage causes what harm, remains BIA work and is set there. What Rizzqo supplies for it is the resource side: for a process, the applications, systems, sites, providers and people-functions carrying it are findable, across several steps and each with a named owner. That list therefore does not have to be re-surveyed annually but is read.