A business impact analysis establishes what breaks first, how fast it hurts, and what it depends on. Every continuity and disaster recovery decision downstream is either grounded in that analysis or based on assumption - and the assumptions are usually wrong in the same direction: everything feels critical to the person who owns it.
The four numbers
- MTPD / MTO - maximum tolerable period of disruption. How long the activity can be down before the damage becomes unacceptable. This is a business judgement about consequence, and it is the number that constrains everything else.
- RTO - recovery time objective. The target time to restore the activity. It must be shorter than the MTPD; if RTO equals MTPD there is no margin for anything going wrong during recovery.
- RPO - recovery point objective. How much data you can afford to lose, expressed as time. An RPO of four hours means backups or replication at least every four hours.
- MBCO - minimum business continuing objective. The reduced level of service that is acceptable during disruption. Usually the most useful output, because full restoration is rarely the first goal.
RTO and RPO are independent. A system can tolerate a day of downtime but no data loss at all, or tolerate losing an hour of data but must be back within minutes. Treating them as one number produces either wasted spend or a nasty surprise.
Running the analysis
- Identify activities, not systems. "Process payroll", "onboard a customer", "respond to security alerts". Systems come later, through dependency mapping - starting from systems produces an IT recovery plan rather than a business one.
- Assess impact over time for each activity: at 1 hour, 4 hours, 1 day, 3 days, 1 week. Impact is rarely linear - many processes are tolerable for a day and catastrophic by day three, particularly where regulatory or contractual deadlines exist.
- Use multiple impact types - financial, regulatory, contractual, safety, reputational. A process with trivial financial impact can carry a hard regulatory reporting deadline.
- Derive MTPD from where impact crosses into unacceptable, then set RTO inside it.
- Map dependencies - applications, data, infrastructure, third parties, key people, facilities. This is where the real findings are.
- Reconcile. A dependency must have an RTO at least as aggressive as the most demanding activity that relies on it.
Connect continuity to the rest of your programme
GRC Copilot links critical activities, their dependencies and the controls protecting them - so recovery objectives sit alongside the risks and evidence that justify them.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
The dependency findings nobody expects
Dependency mapping routinely surfaces the same problems:
- The tier-one activity resting on a tier-three system. A critical process depends on a spreadsheet, an internal tool, or a service with no recovery commitment at all.
- Third parties with weaker objectives than yours. Your four-hour RTO is meaningless if the SaaS platform underneath it commits to next business day. This is a contractual gap disguised as a technical one.
- Single points of knowledge. One person who can perform the recovery, currently on annual leave in your scenario.
- Circular dependencies. Recovery of A requires B, which requires A - most often authentication and network services.
- Shared infrastructure that cannot meet the aggregate demand if several activities recover at once.
Why everyone claims to be critical
Ask any owner whether their process is critical and the answer is yes. Three techniques cut through it:
- Force-rank rather than rate. Ask which of two activities you would recover first. Ranking is harder to inflate than scoring.
- Attach cost to tiers. When a four-hour RTO carries a visible infrastructure and testing bill, requests moderate immediately.
- Cap the top tier. Decide in advance that no more than a stated share of activities can be tier one, and make the business trade them off against each other.
Impact assessed against evidence - actual revenue per hour, actual contractual penalties, actual regulatory deadlines - settles most arguments faster than any workshop.
Turning the BIA into decisions
The output should drive: continuity and recovery strategies per tier, backup frequency set by RPO rather than convention, infrastructure investment where current capability cannot meet the objective, contract requirements for third parties, and the scenarios you exercise. A BIA that does not change any of these was an information-gathering exercise, not an analysis.
Refresh it annually and after significant change - new products, new systems, acquisitions. It ages faster than most compliance artefacts because it tracks how the business actually operates.
Frequently asked questions
How is a BIA different from a risk assessment?
A risk assessment asks what might happen and how likely it is. A BIA assumes the disruption has occurred and asks how quickly the consequences become unacceptable. They complement each other; neither substitutes.
Can we set RTO equal to MTPD?
Technically yes, practically no - it leaves zero margin for a recovery that runs long, which recoveries routinely do. Set RTO meaningfully inside MTPD.
How many tiers should we use?
Three or four. More produces distinctions nobody can apply under pressure.
Do we need a BIA without ISO 22301?
Yes if you have any recovery commitment at all. Without one, backup frequencies and recovery investment are set by habit rather than by need - usually too low where it matters and too high where it does not.
Key takeaways
- Start from business activities; systems arrive through dependency mapping.
- RTO and RPO are independent objectives - do not collapse them into one.
- Dependencies with weaker objectives than the activity are the most common finding.
- Cap the top tier and attach cost to it, or everything becomes critical.