5.1.2. Business Impact Analysis
💡 First Principle: Recovery priorities set once, based on business conditions from years ago, will misallocate response effort for the system that matters most today — a Business Impact Analysis has to be refreshed as often as the business itself changes.
A Business Impact Analysis (BIA) identifies critical business processes and quantifies how disruption to each one grows over time, producing two key figures per process: Recovery Time Objective (RTO) — the maximum acceptable downtime — and Recovery Point Objective (RPO) — the maximum acceptable data loss, measured in time since the last good backup or replication point. These figures directly drive recovery investment: a process with a four-hour RTO needs a fundamentally different (and more expensive) recovery architecture than one with a 72-hour RTO.
| Business Process | RTO | RPO | Recovery Investment Implied |
|---|---|---|---|
| Customer payment processing | 1 hour | 5 minutes | Real-time replication, hot standby |
| Internal HR portal | 24 hours | 24 hours | Nightly backup, warm standby |
| Archived reporting system | 1 week | 1 week | Cold backup, manual restore |
A BIA produced once at initial BCP creation and never refreshed will misprioritize recovery resources the moment the business adds a new critical process or retires an old one — the dependency map underlying RTO/RPO figures needs periodic revalidation, not a single snapshot treated as permanent.
RTO isn't chosen in a vacuum — it has to stay within Maximum Tolerable Downtime (MTD), also called Maximum Acceptable Outage (MAO): the absolute longest a process can be down before the business itself suffers unacceptable or unrecoverable harm. The golden rule is RTO ≤ MTD. If a process's MTD is 24 hours, an RTO of 30 hours isn't a looser recovery target — it's a plan that fails the business even if the recovery itself succeeds.
⚠️ Exam Trap: A BIA is sometimes treated as a one-time exercise completed at BCP creation. The correct answer requires refreshing the BIA as business processes, dependencies, and RTO/RPO requirements change — a stale BIA misprioritizes recovery resources.
⚠️ Exam Trap: RTO is sometimes set based on what recovery architecture is affordable, without checking it against the process's actual MTD. The correct answer treats MTD as the hard business constraint — if the affordable RTO exceeds MTD, the organization needs to invest in faster recovery, not accept an RTO the business can't actually survive.
Reflection Question: Your organization's BIA was completed four years ago and hasn't been updated since a major new product line launched. What's the risk of relying on that BIA's RTO/RPO figures today?