Topics in this domain
- IT Risk Events, Loss Types and Business Outcomes
- Threat Sources, Actors and Motivations
- The Changing Threat Landscape and Threat Modelling
- Vulnerabilities, Control Deficiencies and Risk Conditions
- Identifying Internal and External Risk Factors
- Building IT Risk Scenarios
- Evaluating Scenarios for Completeness and Relevance
- Common Risk Scenario Errors
- Risk Assessment Concepts and Standards
- Qualitative, Semi-Quantitative and Quantitative Analysis
- Quantitative Methods: ALE, FAIR and Monte Carlo
- Risk Analysis Techniques: Bow-Tie, Fault Tree, Event Tree and Delphi
- Choosing a Consistent Assessment Methodology
- Translating Technical Events into Business Impact
- Business Impact Analysis for Risk Prioritisation
- Inherent and Residual Risk
- Evaluating Risk Against Business Objectives and Appetite
- Creating and Maintaining the IT Risk Register
- Using the Risk Register to Support Decisions
Business Impact Analysis for Risk Prioritisation
What a BIA does
A business impact analysis asks one question: if this process stops, how much harm does that cause, and how fast? It sets recovery priorities and objectives. It doesn’t ask how likely disruption is; that’s the risk assessment’s job.
The BIA steps
BIA and risk assessment together
| BIA | Risk assessment | |
|---|---|---|
| Main question | Impact of disruption over time | Likelihood and impact of scenarios |
| Focus | Processes and recovery | Threats, vulnerabilities, controls |
| Outputs | MTD, RTO, RPO, priorities | Risk ratings, register |
Using BIA results
- Rate the impact of scenarios that affect critical processes.
- Prioritise risks on the assets critical processes depend on.
- Set recovery objectives that responses must meet.
- Spot dependencies that technical inventories miss.
Example. The BIA shows payroll has a 3-day MTD, but it depends on a supplier with no recovery commitment. The practitioner raises the supplier risk’s impact and recommends the owner add recovery terms to the contract.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| PRIMARY purpose of a BIA | Identify critical processes and the impact of disruption over time |
| Who provides BIA information | Business process owners |
| What a BIA doesn’t measure | Likelihood |
| How the BIA helps risk management | It prioritises risks by business criticality |
In short
- A BIA measures the impact of disrupting business processes over time; it doesn't assess likelihood.
- It sets maximum tolerable downtime, recovery time objectives and recovery point objectives.
- Process owners, not IT, provide the impact information.
- BIA results show which assets and dependencies matter most, which sharpens risk prioritisation.
- Risk assessment adds likelihood; together they give a complete picture.
Exam traps
- Thinking a BIA estimates threat likelihood.
- Letting IT complete the BIA alone.
- Treating every process as critical.
- Forgetting dependencies such as suppliers, data and key staff.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The BIA steps
1 / 8