A Business Impact Analysis (BIA) is the foundation of business continuity planning. It answers: Which processes are critical? How long can we be down? How much data loss can we accept? Without a BIA, your continuity plan is guesswork. This guide walks you through how to conduct a BIA and use RTO/RPO effectively.
What a BIA Delivers
- Critical processes ranked by importance to the organization (revenue, safety, regulation, reputation).
- Recovery Time Objective (RTO): Maximum acceptable downtime before the impact becomes unacceptable.
- Recovery Point Objective (RPO): Maximum acceptable data loss (how far back you can recover from backups or logs).
- Dependencies: People, systems, data, and third parties each process relies on.
- Identify critical processes & owners
- Define RTO (recovery time) & RPO (data loss)
- Map dependencies (people, systems, vendors)
- Prioritize recovery order
- Document in BIA report & link to recovery plans
How to Conduct a BIA
1. Identify Critical Processes and Owners
List the main business processes (e.g. order-to-cash, payroll, customer support, manufacturing). Involve process owners to define what "critical" means: revenue impact, regulatory requirement, safety, or strategic. Rank them so you know recovery order.
2. Define RTO and RPO
For each critical process:
- RTO: "We must resume within X hours/days." This drives your recovery strategy (e.g. failover, manual workarounds).
- RPO: "We can lose at most X hours of data." This drives backup and replication frequency.
Be realistic: aggressive RTO/RPO cost money. Align with business owners and risk appetite.
3. Map Dependencies
For each process, document:
- People: Who must be available? Skills, locations, succession.
- Systems: Applications, infrastructure, data. Which are single points of failure?
- Vendors: Critical suppliers and outsourcers. Do you have alternate sources or contracts?
This dependency map feeds both your BIA report and your recovery and incident plans.
4. Prioritize Recovery Order
Use RTO and criticality to decide what you recover first. Document this in your BIA and in recovery runbooks. When an incident happens, you follow the same order—no debate in the moment.
5. Document and Maintain
The BIA should be a living document. When you add a new system, change a process, or onboard a critical vendor, update the BIA. When it sits in the same platform as your recovery plans and incident management (e.g. ActiveERM), you keep one source of truth and your BCP stays aligned with reality.
For more on business continuity and risk, see our Business Continuity and Risk OS pages.