Business impact analysis and continuity planning
A business impact analysis (BIA) identifies the processes your organization cannot do without, what each one depends on, and how long each can be down before the damage becomes unacceptable. Those answers become recovery targets, and the targets decide how you back up, where you recover and what you rehearse. The BIA sets those targets from the business side; checking whether backups and restores can meet them is ransomware readiness and resilience.
What a business impact analysis measures
We work process by process, not system by system. Payroll, order intake, dispatch, patient scheduling. For each one we ask what stops, who notices first, and how the harm grows over an hour, a day and a week. The answers are in terms the business already uses, such as lost revenue, missed deadlines or safety exposure.
Then come the dependencies. A process fails because the identity service is down, a supplier’s portal is unreachable, or the only colleague who knows the month-end routine is on leave. The BIA maps those links so a recovery plan restores things in the right order.
MTD, RTO and RPO in plain terms
- Maximum tolerable downtime (MTD) is the point at which an outage stops being painful and starts being lasting damage.
- Recovery time objective (RTO) is how quickly the process must be running again. It sits inside the MTD, with room for things going wrong.
- Recovery point objective (RPO) is how much data the business can afford to lose, measured as time: fifteen minutes of transactions, or a full day.
Process owners set these numbers. We make sure they stay consistent across processes that share a system, and that each target’s cost is visible.
How the results drive backup and recovery decisions
An RPO of fifteen minutes rules out a nightly backup. An RTO of four hours rules out an offsite copy that takes a day to retrieve. Vague expectations become requirements an engineer can test.
It also shows where you are overspending on systems with generous tolerances. Ransomware changes the picture further, because backups must survive an intruder with admin rights; the controls and restore drills for that are on ransomware readiness and resilience.
From the BIA to a continuity plan
The continuity plan says who does what when a critical process stops: the manual workaround, the decision-maker, the order of recovery. We write it with the people who will use it, keep it short, and test it in a tabletop exercise before anyone relies on it.
Unrecoverable gaps go into your cyber risk register with a named owner, so accepting them is a decision someone made rather than an accident.
For federally regulated financial institutions, OSFI’s expectations on operational resilience cover similar ground. We are not lawyers; we work alongside your counsel on what a regulator requires of you.
What you receive
| Deliverable | What it is for |
|---|---|
| Critical process inventory | Ranked by impact over time |
| Dependency map | Systems, suppliers and people behind each process |
| MTD, RTO and RPO table | Agreed by process owners, checked for conflicts |
| Gap analysis | Where current backup and recovery miss the targets |
| Continuity plan | Roles, workarounds and recovery order |
If you want the difference between this and a risk assessment first, read business impact analysis vs risk assessment.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
What is a business impact analysis?
A business impact analysis is a structured look at what happens to each critical process when it stops: the harm over time, the dependencies behind it, and the recovery time and data loss the business can tolerate.
How long does a BIA take?
For a single business unit, a few weeks of elapsed time, most of it waiting for interviews. Larger organizations start with the processes that carry revenue or safety.
Who owns the recovery targets?
The business does. Process owners set the tolerances because they carry the consequences; IT and security confirm whether the current systems can meet them and what closing the gap would take.
How often should a BIA be updated?
Once a year, and again whenever a critical system, supplier or process changes. A BIA written before a move to a new ERP or a new cloud provider describes a business that no longer exists.
Set recovery targets you can defend
Tell us which processes worry you most and roughly how your backups work today. The reply outlines what a BIA would cover. Related work sits under cyber risk management and governance.