Topics in this domain
- Event vs Incident vs Breach
- Developing the Incident Response Plan
- Incident Response Team Roles and Authority
- Incident Classification and Severity Levels
- Incident Response Playbooks and Decision Trees
- Escalation and Communication Plans
- Business Impact Analysis
- RTO, RPO, MTD and Recovery Prioritisation
- Business Continuity Planning and Strategies
- Crisis Management and Continuity Governance
- Disaster Recovery Planning
- Recovery Sites: Hot, Warm and Cold
- Backup Strategies and Cloud DR
- Incident Response Training
- Testing Plans: Tabletop, Functional and Full Interruption
- Evaluating Exercises and Improving Readiness
- Security Event Detection and Monitoring Methods
- SIEM, the SOC and Event Correlation
- Threat Intelligence and Indicators of Compromise
- Incident Triage and Initial Investigation
- Evidence Preservation, Forensics and Chain of Custody
- Containment Strategies: Short-Term and Long-Term
- Making Containment Decisions
- Breach Notification and Regulatory Reporting
- External Communications: Customers, Media and Law Enforcement
- Eradication, Recovery and Return to Normal Operations
- Post-Incident Review and Root Cause Analysis
- Lessons Learned and Incident Trend Analysis
Business Impact Analysis
What would hurt most, and how fast?
If everything stopped tomorrow, what would you restore first? The business impact analysis (BIA) answers that question with evidence. It looks at each business process, asks how the damage grows the longer it’s down, and turns the answers into recovery priorities everyone agrees on. The BIA is a named topic in CISM’s incident management readiness, because recovery objectives drive incident response, the BCP and the DRP.
The BIA steps
- List processes and their owners.
- Gather information through interviews, questionnaires and workshops with process owners.
- Assess impact over time: after an hour, a day, a week. Financial, regulatory, customer, reputational, safety.
- Set objectives: maximum tolerable downtime (MTD), recovery time objective (RTO) and recovery point objective (RPO) for each process.
- Find dependencies: systems, data, people, suppliers, sites.
- Prioritise and approve, with senior management validating the results.
Impact grows over time
| Process | 4 hours | 1 day | 1 week |
|---|---|---|---|
| Online payments | Lost sales 200k | Lost sales 1.2m; complaints | Regulator involvement; customers leave |
| Payroll | None | Minor | Staff unpaid; legal breach |
| Marketing website | None | Minor | Moderate reputational impact |
Impact over time shows which processes need fast recovery and which can wait.
Criticality and dependencies
Processes are often grouped as critical, vital, sensitive or non-critical, depending on how long they can be down and whether manual workarounds exist. IT systems inherit their recovery priority from the processes they support.
Example. The BIA shows order processing is critical, with an MTD of 8 hours. Mapping dependencies reveals it relies on a payment gateway, the identity service, two key staff who know the batch jobs, and a single label-printer supplier. All four go into the recovery plan.
Who provides what
- Process owners: impact, timings, workarounds and dependencies. They’re the main source of BIA information.
- IT: system dependencies and current recovery capability.
- The security manager: facilitates, and links the BIA to risk and incident plans.
- Senior management: validates the priorities and objectives.
The BIA is about impact, not threats; identifying threats is the risk assessment’s job. Review it periodically and after major business change.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Primary purpose of a BIA | Identify critical processes and their impact, to set recovery priorities |
| Main source of BIA information | Business process owners |
| Outputs used to plan recovery | MTD, RTO and RPO for each process |
| BIA vs risk assessment | BIA: impact. Risk assessment: threats and likelihood |
| When to update the BIA | Periodically, and after major business change |
In short
- The business impact analysis (BIA) identifies critical processes, the impact of disruption over time, and the resources they depend on.
- It produces recovery priorities and objectives (MTD, RTO, RPO) that drive incident response, BCP and DRP.
- Impact includes financial loss, regulatory penalties, customer harm, reputation and safety, assessed at intervals (hours, days, weeks).
- Information comes from business process owners, through interviews, questionnaires and workshops; senior management validates the results.
- Dependencies (systems, data, people, suppliers, sites) must be mapped, or recovery stalls.
- The BIA is reviewed periodically and after major business change.
Exam traps
- The BIA is about business impact, not threats; identifying threats is the risk assessment.
- Process owners, not IT, are the main source of BIA information.
- IT systems inherit their recovery priority from the processes they support.
- A BIA that ignores suppliers and key people produces plans that can't be executed.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The BIA steps
Criticality and dependencies