Business impact analysis example (BIA, RTO and RPO)
A business impact analysis (BIA) shows what it costs you when a process fails. For each process you determine how quickly it must be restored (RTO) and how much data you can afford to lose (RPO). Within ISO 22301 , the BIA is the foundation under every continuity decision, with practical explanation in ISO 22313 . Assessment is carried out by bodies supervised by the RvA (Dutch Accreditation Council). Below you will find a worked example, plus a step-by-step guide to make your own.
A BIA is not a risk assessment. A risk assessment looks at causes (what could go wrong). A BIA looks at consequences (what an outage costs us).
What is a business impact analysis?
A BIA is an overview of your processes, ranked by how serious it is when they stop. You estimate the impact at several points in time: after 1 hour, 4 hours, 1 day and 1 week. The faster the impact grows, the higher the recovery priority.
Three terms come up again and again. We list them briefly before you look at the example.
| Term | Full name | Meaning in plain language |
|---|---|---|
| MTPD | Maximum Tolerable Period of Disruption | How long an outage can last at most before it becomes truly damaging |
| RTO | Recovery Time Objective | How quickly you want the process back (shorter than the MTPD) |
| RPO | Recovery Point Objective | The maximum amount of data you can afford to lose |
Business impact analysis example: an online shop
Suppose you carry out a BIA for a medium-sized online shop. Below you see five core processes, how the impact grows over time, and the recovery objectives that go with them. This is a completed example table that you can use as a basis.
| Process | Dependencies | Impact after 1h | Impact after 4h | Impact after 1 day | Impact after 1 week | MTPD | RTO | RPO | Priority |
|---|---|---|---|---|---|---|---|---|---|
| Order process (checkout) | Web server, payment provider, stock database | Low | Medium | High | Critical | 8h | 4h | 15 min | 1 |
| Payment processing | Payment provider, bank API | Low | High | Critical | Critical | 8h | 4h | 5 min | 1 |
| Warehouse/order picking | WMS, scanners, carrier integration | None | Low | Medium | High | 24h | 12h | 4h | 2 |
| Customer service | Telephony, CRM, email | None | Low | Medium | High | 24h | 8h | 1h | 2 |
| Financial administration | Accounting system, bank | None | None | Low | Medium | 1 week | 72h | 24h | 3 |
What stands out? The order process and payment processing are priority 1: without those two, the shop earns no money. Administration can wait a few days without customers noticing. This shows at a glance where your recovery budget should go.
Pay attention to the difference between MTPD and RTO. You always set the RTO well below the MTPD, so that you have a safety margin. An RTO equal to the MTPD means you cannot make a single mistake during recovery.
You can read more about the RPO, with a table per system and an example, in RPO explained.
How do you read the impact columns?
Impact often does not grow in a straight line. Nobody notices an hour without customer service, but after a day complaints and cancellations pile up. That is why you estimate the impact at several moments, not as a single number.
Use a fixed scale so that you can compare processes with each other:
| Level | Meaning | Online shop example |
|---|---|---|
| None | No noticeable damage | Administration is down for 1 hour |
| Low | Inconvenience, no loss of revenue | Warehouse falls slightly behind |
| Medium | Revenue or reputation damage begins | Customers wait for an answer |
| High | Serious damage, customers leave | Checkout is down for a day |
| Critical | Threat to the survival of the business | No payments possible, for days |
Making your own business impact analysis: step by step
A BIA does not have to be a months-long project. With the right people at the table, you can get far in a few sessions. Follow these steps.
Step 1: Define your scope and processes
List all business processes you want to assess. Keep it concrete: “order process”, not “sales”. Ask process owners to complete the list, as they know the details.
Step 2: Map dependencies
For each process, note what it depends on: systems, people, suppliers, locations. A process is never restored faster than its slowest dependency.
Step 3: Estimate the impact over time
Go through the 1h, 4h, 1 day and 1 week points with process owners. Use the fixed impact scale above, so that the estimates stay comparable.
Step 4: Determine MTPD, RTO and RPO
The MTPD follows from the moment the impact becomes “critical”. You set the RTO well below that. You determine the RPO based on how often you make backups and how much loss is acceptable.
Step 5: Establish a priority order
Rank processes by recovery priority. Have management formally approve this order, because your whole continuity strategy is based on it.
Common mistakes in a BIA
A BIA only becomes valuable when the numbers are correct and supported. Auditors often come across these mistakes.
| Mistake | Consequence | Better alternative |
|---|---|---|
| Estimating impact as one number | Wrong priorities | Estimate impact per point in time |
| Setting RTO equal to MTPD | No margin during recovery | Set the RTO well below the MTPD |
| Choosing an RPO without checking backups | The target is technically unachievable | Align the RPO with your backup frequency |
| No management agreement | Priorities are challenged later | Have the order formally confirmed |
How the BIA comes back in the ISO 22301 audit
Auditors check not only whether you have a BIA, but whether it is correct and used. They want to see:
- a traceable method and justification;
- documented and approved RTO/RPO per process;
- a logical link between recovery objectives and your continuity measures;
- test results that show the objectives are achievable.
You can read how this is assessed on the page about the audit process.