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
Translating Technical Events into Business Impact
From technical to business
Decision-makers act on business impact, not technical severity.
Impact categories
Who knows the impact
| Question | Best source |
|---|---|
| What stops if this system fails? | Business process owner |
| What would the regulator do? | Compliance and legal |
| How would customers react? | Sales, customer service |
| How long would it take to restore? | IT operations |
Time changes impact
Most impacts grow with duration. A one-hour outage of online sales may cost little; a three-day outage may lose customers for good. Ask owners how impact changes over an hour, a day and a week.
Example. An IT report rated a database flaw “critical”. Reframed by the practitioner as “possible exposure of 400,000 patient records, mandatory notification and a likely regulatory fine”, it reached the executive committee the same week.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| BEST way to communicate technical risk to executives | Express it as business impact |
| Best source for impact estimates | Business process owners |
| Impact category often overlooked | Regulatory, reputational or safety impact |
| Why consider duration | Impact grows over time |
In short
- Decision-makers act on business impact, not technical severity.
- Trace each technical event to the process it affects, how impact grows over time and the resulting business outcome.
- Use agreed impact categories: financial, customers, legal and regulatory, reputation, operations, safety and strategy.
- Business owners are the best source of impact estimates; IT supplies the technical facts.
- Impact often grows with time; a one-hour outage and a one-week outage are different risks.
Exam traps
- Reporting a risk as 'critical CVE' instead of what it means for the business.
- Asking IT to estimate business impact.
- Counting only financial impact and ignoring regulatory, safety or reputational effects.
- Ignoring how impact changes with duration.
Slides
Click the slide and use the arrow keys. F toggles full screen.
From technical to business
Impact categories
1 / 8