Opening Framing
Identifying risks is only the first step. Risk analysis transforms raw risk data into meaningful information that supports decision-making. Should we spend $500,000 on a new security control? The answer depends on whether the risk it addresses is worth $50,000 or $5,000,000. Executives and boards make decisions in financial terms—security professionals must learn to speak that language.
Risk analysis comes in two forms: qualitative (using categories like High/Medium/Low) and quantitative (using numbers like dollars and probabilities). Most organizations use both— qualitative for initial screening and communication, quantitative for major investment decisions and executive reporting. The FAIR (Factor Analysis of Information Risk) methodology provides a structured approach to quantifying cyber risk in financial terms.
This week covers qualitative and quantitative risk analysis methods, the FAIR methodology, business impact analysis, risk scoring and prioritization, and building risk registers. You'll learn to analyze risks in ways that enable informed business decisions.
Key insight: Risk analysis isn't about precision—it's about being less wrong than guessing.
1) Qualitative Risk Analysis
Qualitative analysis uses categorical ratings to assess and prioritize risks:
Qualitative Risk Analysis:
LIKELIHOOD SCALE:
┌─────────────────────────────────────────────────────────────┐
│ Rating │ Description │ Frequency │
├────────┼──────────────────────────┼─────────────────────────┤
│ 5-Very │ Expected to occur │ Multiple times per year │
│ High │ regularly │ │
├────────┼──────────────────────────┼─────────────────────────┤
│ 4-High │ Will probably occur │ Once per year │
│ │ │ │
├────────┼──────────────────────────┼─────────────────────────┤
│ 3-Med │ Could occur at some │ Once every 2-3 years │
│ │ point │ │
├────────┼──────────────────────────┼─────────────────────────┤
│ 2-Low │ Unlikely but possible │ Once every 5-10 years │
│ │ │ │
├────────┼──────────────────────────┼─────────────────────────┤
│ 1-Very │ Rare, exceptional │ Less than once per │
│ Low │ circumstances │ 10 years │
└────────┴──────────────────────────┴─────────────────────────┘
IMPACT SCALE:
┌─────────────────────────────────────────────────────────────┐
│ Rating │ Financial │ Operational │ Reputational │
├────────┼──────────────────┼──────────────────┼──────────────┤
│ 5-Crit │ >$10M or │ Complete business│ National │
│ │ existential │ shutdown >1 week │ news, major │
│ │ │ │ customer loss│
├────────┼──────────────────┼──────────────────┼──────────────┤
│ 4-High │ $1M - $10M │ Major disruption │ Industry │
│ │ │ 1-7 days │ news, some │
│ │ │ │ customer loss│
├────────┼──────────────────┼──────────────────┼──────────────┤
│ 3-Med │ $100K - $1M │ Significant │ Local news, │
│ │ │ impact 1-24 hrs │ complaints │
├────────┼──────────────────┼──────────────────┼──────────────┤
│ 2-Low │ $10K - $100K │ Minor disruption │ Social media │
│ │ │ <1 hour │ mentions │
├────────┼──────────────────┼──────────────────┼──────────────┤
│ 1-Min │ <$10K │ Minimal or no │ No external │
│ │ │ impact │ awareness │
└────────┴──────────────────┴──────────────────┴──────────────┘
Note: Scale thresholds should be customized for organization size
A $1M impact is critical for a startup, moderate for a Fortune 500Risk Matrix:
Risk Heat Map (Likelihood x Impact):
IMPACT
│ 1 │ 2 │ 3 │ 4 │ 5 │
│ Min │ Low │ Med │ High │ Crit │
──────────┼───────┼───────┼───────┼───────┼───────┤
L 5 V.High │ 5 │ 10 │ 15 │ 20 │ 25 │
I │ Med │ Med │ High │ Crit │ Crit │
K ──────────┼───────┼───────┼───────┼───────┼───────┤
E 4 High │ 4 │ 8 │ 12 │ 16 │ 20 │
L │ Low │ Med │ High │ High │ Crit │
I ──────────┼───────┼───────┼───────┼───────┼───────┤
H 3 Med │ 3 │ 6 │ 9 │ 12 │ 15 │
O │ Low │ Med │ Med │ High │ High │
O ──────────┼───────┼───────┼───────┼───────┼───────┤
D 2 Low │ 2 │ 4 │ 6 │ 8 │ 10 │
│ Low │ Low │ Med │ Med │ Med │
──────────┼───────┼───────┼───────┼───────┼───────┤
1 V.Low │ 1 │ 2 │ 3 │ 4 │ 5 │
│ Low │ Low │ Low │ Low │ Med │
──────────┴───────┴───────┴───────┴───────┴───────┘
RISK RATING THRESHOLDS:
┌─────────────────────────────────────────────────────────────┐
│ Critical (20-25): │
│ - Immediate executive attention required │
│ - Treatment plan within 24-48 hours │
│ - Consider business continuity implications │
│ │
│ High (12-19): │
│ - Senior management attention required │
│ - Treatment plan within 1-2 weeks │
│ - Regular monitoring │
│ │
│ Medium (6-11): │
│ - Management attention │
│ - Treatment plan within 30-90 days │
│ - Periodic review │
│ │
│ Low (1-5): │
│ - Accept or address during normal operations │
│ - Annual review │
│ - Document acceptance │
└─────────────────────────────────────────────────────────────┘Qualitative Analysis Strengths and Limitations:
Qualitative Analysis Pros and Cons:
STRENGTHS:
┌─────────────────────────────────────────────────────────────┐
│ ✓ Easy to understand and communicate │
│ ✓ Quick to perform │
│ ✓ Doesn't require extensive data │
│ ✓ Works well for initial screening │
│ ✓ Enables comparison across different risk types │
│ ✓ Facilitates stakeholder discussions │
└─────────────────────────────────────────────────────────────┘
LIMITATIONS:
┌─────────────────────────────────────────────────────────────┐
│ ✗ Subjective - different people rate differently │
│ ✗ Can't justify specific investments │
│ ✗ "High" risk doesn't tell you how much to spend │
│ ✗ Difficult to aggregate │
│ ✗ May mask significant differences (all "High" not equal) │
│ ✗ Prone to anchoring and recency bias │
└─────────────────────────────────────────────────────────────┘
WHEN TO USE QUALITATIVE:
┌─────────────────────────────────────────────────────────────┐
│ - Initial risk identification and screening │
│ - Communicating with non-technical stakeholders │
│ - When data for quantification isn't available │
│ - For lower-stakes decisions │
│ - When speed is more important than precision │
│ - For regulatory compliance (often expects qualitative) │
└─────────────────────────────────────────────────────────────┘Key insight: Qualitative analysis is better than nothing, but "High risk" doesn't tell an executive whether to spend $10,000 or $10,000,000.
2) Quantitative Risk Analysis
Quantitative analysis expresses risk in numerical terms, typically financial:
Quantitative Risk Fundamentals:
BASIC FORMULA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Annualized Loss Expectancy (ALE) = │
│ │
│ Single Loss Expectancy (SLE) × Annual Rate of │
│ Occurrence (ARO) │
│ │
│ Where: │
│ SLE = Asset Value × Exposure Factor │
│ │
│ Example: │
│ - Database contains customer data worth $5M if breached │
│ - Exposure factor: 100% (full compromise) │
│ - SLE = $5M × 1.0 = $5M │
│ - Estimated ARO: 0.1 (10% chance per year, or once/10yrs) │
│ - ALE = $5M × 0.1 = $500,000/year expected loss │
│ │
│ This means: Spending up to $500K/year on controls that │
│ prevent this risk is economically justified │
│ │
└─────────────────────────────────────────────────────────────┘
RETURN ON SECURITY INVESTMENT (ROSI):
┌─────────────────────────────────────────────────────────────┐
│ │
│ ROSI = (Risk Reduction - Cost of Control) / Cost of Control│
│ │
│ Where Risk Reduction = ALE(before) - ALE(after) │
│ │
│ Example: │
│ - ALE before control: $500,000 │
│ - Control cost: $100,000/year │
│ - Control reduces risk by 80% │
│ - ALE after control: $500,000 × 0.2 = $100,000 │
│ - Risk reduction: $500,000 - $100,000 = $400,000 │
│ - ROSI = ($400,000 - $100,000) / $100,000 = 300% │
│ │
│ Interpretation: For every $1 spent, $3 in risk reduced │
│ │
└─────────────────────────────────────────────────────────────┘
CHALLENGES WITH BASIC QUANTIFICATION:
┌─────────────────────────────────────────────────────────────┐
│ - Where do the numbers come from? │
│ - What's the "asset value" of reputation? │
│ - How do you estimate probability of breach? │
│ - False precision (saying $1,234,567 when you're guessing) │
│ - Doesn't capture ranges of uncertainty │
│ - Single point estimates hide variability │
│ │
│ These challenges led to development of FAIR methodology │
└─────────────────────────────────────────────────────────────┘Key insight: Even rough quantification is more useful than qualitative alone for investment decisions.
3) FAIR Risk Quantification
FAIR (Factor Analysis of Information Risk) provides a structured methodology for quantifying cyber risk:
FAIR Taxonomy:
RISK DECOMPOSITION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RISK │
│ │ │
│ ┌─────────────┴─────────────┐ │
│ │ │ │
│ Loss Event Loss │
│ Frequency Magnitude │
│ │ │ │
│ ┌──────┴──────┐ ┌───────┴───────┐ │
│ │ │ │ │ │
│ Threat Vulner- Primary Secondary │
│ Event ability Loss Loss │
│ Frequency │ │ │
│ │ │ │ │ │
│ ┌──┴──┐ ┌───┴───┐ ┌───┴───┐ ┌────┴────┐ │
│ │ │ │ │ │ │ │ │ │
│Contact Prob. Threat Control Asset Response Fines/ │
│Freq Action Cap. Strength Loss Costs Judgments │
│ Reputation etc. │
│ │
└─────────────────────────────────────────────────────────────┘
FAIR COMPONENTS EXPLAINED:
LOSS EVENT FREQUENCY:
┌─────────────────────────────────────────────────────────────┐
│ Threat Event Frequency (TEF): │
│ - How often does a threat actor attempt an attack? │
│ - Factors: Contact frequency × Probability of action │
│ - Example: Phishing emails received × click rate │
│ │
│ Vulnerability (VULN): │
│ - Probability that an attempt succeeds │
│ - Factors: Threat capability vs. Control strength │
│ - Example: 40% of phishing attempts succeed │
│ │
│ LEF = TEF × VULN │
│ Example: 100 attempts/year × 0.4 = 40 events/year │
└─────────────────────────────────────────────────────────────┘
LOSS MAGNITUDE:
┌─────────────────────────────────────────────────────────────┐
│ Primary Loss: │
│ - Direct costs from the event │
│ - Productivity loss │
│ - Response costs │
│ - Replacement costs │
│ │
│ Secondary Loss: │
│ - Costs that MAY occur (probabilistic) │
│ - Regulatory fines (if reported/caught) │
│ - Legal judgments (if sued) │
│ - Reputation damage (if publicized) │
│ - Competitive loss │
│ │
│ Secondary Loss = Probability × Magnitude │
│ Example: 30% chance of lawsuit × $2M judgment = $600K │
└─────────────────────────────────────────────────────────────┘FAIR Analysis Process:
Conducting a FAIR Analysis:
STEP 1: SCOPE THE SCENARIO
┌─────────────────────────────────────────────────────────────┐
│ Define: │
│ - Asset at risk (what could be harmed) │
│ - Threat community (who/what could cause harm) │
│ - Threat type (how they might cause harm) │
│ - Effect (what would happen - C, I, or A impact) │
│ │
│ Example Scenario: │
│ "External attackers using ransomware to encrypt │
│ production database, causing availability loss" │
└─────────────────────────────────────────────────────────────┘
STEP 2: ESTIMATE FREQUENCY FACTORS
┌─────────────────────────────────────────────────────────────┐
│ Use ranges, not point estimates: │
│ │
│ Threat Event Frequency: │
│ - How often are we targeted by ransomware? │
│ - Minimum: 10/year, Most Likely: 50/year, Maximum: 200/year │
│ │
│ Vulnerability: │
│ - What % of attempts would succeed? │
│ - Minimum: 1%, Most Likely: 5%, Maximum: 15% │
│ │
│ Loss Event Frequency: │
│ - Min: 10 × 1% = 0.1/year (once per 10 years) │
│ - ML: 50 × 5% = 2.5/year │
│ - Max: 200 × 15% = 30/year │
└─────────────────────────────────────────────────────────────┘
STEP 3: ESTIMATE LOSS MAGNITUDE
┌─────────────────────────────────────────────────────────────┐
│ Primary Loss: │
│ - Productivity: $50K-$200K (downtime costs) │
│ - Response: $100K-$500K (IR, forensics, recovery) │
│ - Replacement: $20K-$100K (data restoration) │
│ - Ransom: $0-$1M (if paid) │
│ │
│ Secondary Loss: │
│ - Regulatory fine: 20% probability × $500K = $100K │
│ - Reputation: 40% probability × $300K = $120K │
│ - Customer loss: 30% probability × $200K = $60K │
│ │
│ Total Loss Range: $350K - $2.2M per event │
└─────────────────────────────────────────────────────────────┘
STEP 4: CALCULATE RISK (typically using Monte Carlo)
┌─────────────────────────────────────────────────────────────┐
│ Run thousands of simulations using the ranges │
│ │
│ Results (example): │
│ - 10th percentile: $50K/year │
│ - 50th percentile (median): $800K/year │
│ - 90th percentile: $3.2M/year │
│ - Average: $1.1M/year │
│ │
│ Communicate: "We estimate annual ransomware risk between │
│ $50K and $3.2M, with a most likely value around $800K" │
└─────────────────────────────────────────────────────────────┘
STEP 5: COMPARE TO CONTROL COSTS
┌─────────────────────────────────────────────────────────────┐
│ Proposed control: EDR solution ($150K/year) │
│ Estimated risk reduction: 60% │
│ │
│ New risk: $800K × 0.4 = $320K/year │
│ Risk reduction: $800K - $320K = $480K/year │
│ Net benefit: $480K - $150K = $330K/year │
│ │
│ Recommendation: Investment is justified │
└─────────────────────────────────────────────────────────────┘Key insight: FAIR doesn't require perfect data—it requires structured thinking about factors that drive risk.
4) Business Impact Analysis
Business Impact Analysis (BIA) identifies critical processes and the impact of their disruption:
Business Impact Analysis:
BIA PURPOSE:
┌─────────────────────────────────────────────────────────────┐
│ BIA answers: │
│ - What business processes are most critical? │
│ - What happens if they're disrupted? │
│ - How long can we survive without them? │
│ - What resources do they depend on? │
│ │
│ Used for: │
│ - Business continuity planning │
│ - Disaster recovery prioritization │
│ - Risk assessment context │
│ - Resource allocation decisions │
└─────────────────────────────────────────────────────────────┘
BIA COMPONENTS:
IMPACT CATEGORIES:
┌─────────────────────────────────────────────────────────────┐
│ Financial Impact: │
│ - Lost revenue │
│ - Increased costs │
│ - Contractual penalties │
│ - Regulatory fines │
│ │
│ Operational Impact: │
│ - Productivity loss │
│ - Service delivery failure │
│ - Supply chain disruption │
│ - Backlog accumulation │
│ │
│ Legal/Regulatory Impact: │
│ - Compliance violations │
│ - License revocation │
│ - Legal liability │
│ │
│ Reputational Impact: │
│ - Customer confidence │
│ - Brand damage │
│ - Competitive position │
│ - Employee morale │
└─────────────────────────────────────────────────────────────┘
TIME-BASED IMPACT ASSESSMENT:
┌─────────────────────────────────────────────────────────────┐
│ Process: Online Payment Processing │
│ │
│ Outage Duration │ Financial │ Operational │ Reputation │
│ ─────────────────┼──────────────┼──────────────┼────────────│
│ 0-1 hours │ $10K │ Minor │ Minimal │
│ 1-4 hours │ $50K │ Moderate │ Complaints │
│ 4-8 hours │ $200K │ Significant │ Social buzz│
│ 8-24 hours │ $500K │ Severe │ News │
│ 1-3 days │ $2M │ Critical │ Major news │
│ 3+ days │ $5M+ │ Existential │ Brand dmg │
│ │
│ Recovery Time Objective (RTO): Maximum 4 hours │
│ Recovery Point Objective (RPO): Maximum 15 minutes │
└─────────────────────────────────────────────────────────────┘
CRITICAL PROCESS IDENTIFICATION:
┌─────────────────────────────────────────────────────────────┐
│ Criteria for criticality: │
│ │
│ - Revenue generation (direct impact on income) │
│ - Customer-facing (affects customer experience) │
│ - Regulatory requirement (compliance mandated) │
│ - Dependencies (many other processes depend on it) │
│ - Recovery difficulty (hard to restore quickly) │
│ │
│ Example Prioritization: │
│ │
│ Tier 1 (Critical): RTO < 4 hours │
│ - Payment processing │
│ - Customer authentication │
│ - Core database │
│ │
│ Tier 2 (Important): RTO < 24 hours │
│ - Email systems │
│ - Reporting systems │
│ - Internal applications │
│ │
│ Tier 3 (Standard): RTO < 72 hours │
│ - Development environments │
│ - Archives │
│ - Non-essential services │
└─────────────────────────────────────────────────────────────┘Key insight: BIA connects technical systems to business value, enabling risk prioritization based on actual business impact.
5) Risk Registers and Prioritization
Risk registers document and track risks throughout their lifecycle:
Risk Register Structure:
RISK REGISTER FIELDS:
┌─────────────────────────────────────────────────────────────┐
│ Identification: │
│ - Risk ID (unique identifier) │
│ - Risk name/title │
│ - Description (detailed scenario) │
│ - Risk category │
│ - Date identified │
│ - Identified by │
│ │
│ Assessment: │
│ - Likelihood rating (qualitative) │
│ - Impact rating (qualitative) │
│ - Risk score (L × I) │
│ - Quantified loss (if FAIR analysis done) │
│ - Inherent risk level │
│ - Current controls │
│ - Residual risk level │
│ │
│ Treatment: │
│ - Treatment strategy (mitigate/accept/transfer/avoid) │
│ - Planned controls │
│ - Target risk level │
│ - Treatment status │
│ - Due date │
│ │
│ Ownership: │
│ - Risk owner (business owner accountable) │
│ - Control owner (implements controls) │
│ │
│ Tracking: │
│ - Last review date │
│ - Next review date │
│ - Status (open/in treatment/accepted/closed) │
│ - Trend (increasing/stable/decreasing) │
│ - Comments/notes │
└─────────────────────────────────────────────────────────────┘Sample Risk Register:
Sample Risk Register Entries:
┌────────────────────────────────────────────────────────────────────────────┐
│ ID │ Risk Title │ L │ I │Score│ Owner │ Treatment │ Status │
├───────┼─────────────────────┼───┼───┼─────┼──────────┼───────────┼─────────┤
│R-001 │ Ransomware encrypts │ 4 │ 5 │ 20 │ CIO │ Mitigate │ In Prog │
│ │ production systems │ │ │Crit │ │ │ │
├───────┼─────────────────────┼───┼───┼─────┼──────────┼───────────┼─────────┤
│R-002 │ Customer data breach│ 3 │ 5 │ 15 │ CPO │ Mitigate │ In Prog │
│ │ via web app vuln │ │ │High │ │ │ │
├───────┼─────────────────────┼───┼───┼─────┼──────────┼───────────┼─────────┤
│R-003 │ Insider steals │ 2 │ 4 │ 8 │ CHRO │ Mitigate │ Open │
│ │ intellectual prop │ │ │Med │ │ │ │
├───────┼─────────────────────┼───┼───┼─────┼──────────┼───────────┼─────────┤
│R-004 │ Vendor breach │ 3 │ 4 │ 12 │ VP Ops │ Transfer │ Complete│
│ │ exposes our data │ │ │High │ │ │ │
├───────┼─────────────────────┼───┼───┼─────┼──────────┼───────────┼─────────┤
│R-005 │ DDoS disrupts │ 4 │ 3 │ 12 │ CTO │ Mitigate │ Complete│
│ │ customer portal │ │ │High │ │ │ │
├───────┼─────────────────────┼───┼───┼─────┼──────────┼───────────┼─────────┤
│R-006 │ Employee falls for │ 5 │ 3 │ 15 │ CISO │ Mitigate │ Ongoing │
│ │ phishing attack │ │ │High │ │ │ │
├───────┼─────────────────────┼───┼───┼─────┼──────────┼───────────┼─────────┤
│R-007 │ Cloud misconfigurat-│ 4 │ 4 │ 16 │ Cloud Mgr│ Mitigate │ In Prog │
│ │ ion exposes data │ │ │High │ │ │ │
├───────┼─────────────────────┼───┼───┼─────┼──────────┼───────────┼─────────┤
│R-008 │ Legacy system vuln │ 3 │ 3 │ 9 │ App Owner│ Accept │ Accepted│
│ │ (compensating ctrl) │ │ │Med │ │ │ │
└───────┴─────────────────────┴───┴───┴─────┴──────────┴───────────┴─────────┘
RISK PRIORITIZATION BEYOND SCORES:
┌─────────────────────────────────────────────────────────────┐
│ Score alone doesn't determine priority. Also consider: │
│ │
│ - Velocity: How quickly could this risk materialize? │
│ - Trend: Is likelihood/impact increasing? │
│ - Control difficulty: How hard to implement controls? │
│ - Dependencies: Are other risks dependent on this? │
│ - Regulatory: Is this compliance-related? │
│ - Strategic: Does this affect key business initiatives? │
│ - Quick wins: Can we reduce quickly with little effort? │
│ │
│ Two "High" risks aren't equally urgent if one is │
│ increasing rapidly and the other is stable │
└─────────────────────────────────────────────────────────────┘Risk Register Maintenance:
Maintaining the Risk Register:
REVIEW CADENCE:
┌─────────────────────────────────────────────────────────────┐
│ Critical risks: Weekly review │
│ High risks: Monthly review │
│ Medium risks: Quarterly review │
│ Low risks: Annual review │
│ │
│ Full register review: Quarterly (at minimum) │
│ Board reporting: Quarterly summary │
└─────────────────────────────────────────────────────────────┘
TRIGGERS FOR RE-ASSESSMENT:
┌─────────────────────────────────────────────────────────────┐
│ - New threat intelligence │
│ - Significant business change │
│ - New system or application │
│ - Merger or acquisition │
│ - Regulatory change │
│ - Security incident (internal or industry) │
│ - Control implementation complete │
│ - Audit findings │
│ - Vendor change │
└─────────────────────────────────────────────────────────────┘
COMMON MISTAKES:
┌─────────────────────────────────────────────────────────────┐
│ ✗ Creating register once, never updating │
│ ✗ No clear ownership │
│ ✗ Too many risks (100+ becomes unmanageable) │
│ ✗ Too vague ("cyber attack" vs specific scenario) │
│ ✗ No treatment plans │
│ ✗ Treating it as compliance checkbox vs. management tool │
│ ✗ Security owns all risks (business should own) │
└─────────────────────────────────────────────────────────────┘Key insight: The risk register is a living document, not a one-time deliverable. It's only useful if maintained.
Real-World Context
Case Study: Quantifying Ransomware Risk
A manufacturing company needed to justify a $2M investment in security controls. Using FAIR methodology, they analyzed their ransomware risk: estimated 50 targeted attacks per year with 5% success rate (2.5 events/year), average loss per event of $3M (downtime, recovery, potential ransom). Annual loss expectancy: $7.5M. The proposed controls would reduce success rate to 1%, dropping ALE to $1.5M—a $6M annual risk reduction for $2M investment. The board approved immediately because the analysis was in terms they understood: dollars.
Case Study: BIA Reveals Hidden Dependencies
A financial services firm conducted BIA and discovered their "Tier 3" internal communication system was actually critical— the trading floor couldn't function without it, and it had no redundancy. Previous risk assessments rated it low priority because it wasn't customer-facing. The BIA revealed $50M/hour in trading volume depended on this system. It was immediately re-prioritized and redundancy implemented.
Risk Analysis Quick Reference:
Risk Analysis Checklist:
QUALITATIVE ANALYSIS:
□ Likelihood scale defined and calibrated
□ Impact scale customized to organization
□ Risk matrix created
□ Threshold levels established
□ Stakeholders aligned on definitions
QUANTITATIVE ANALYSIS:
□ Key scenarios identified for quantification
□ Data sources identified
□ FAIR factors estimated with ranges
□ Monte Carlo simulation run
□ Results communicated with uncertainty
BUSINESS IMPACT ANALYSIS:
□ Critical processes identified
□ Dependencies mapped
□ RTO/RPO defined
□ Impact over time documented
□ Tiering completed
RISK REGISTER:
□ All identified risks documented
□ Owners assigned
□ Treatment strategies defined
□ Review schedule established
□ Reporting process definedRisk analysis that doesn't inform decisions is wasted effort. The goal is actionable insight, not perfect precision.
Guided Lab: Risk Analysis
In this lab, you'll perform both qualitative and quantitative risk analysis on identified risks.
Lab Scenario:
- Continue with e-commerce company from Week 2
- 10 risk scenarios identified
- Need to prioritize and justify security budget
- Board presentation required
Exercise Steps:
- Define likelihood and impact scales
- Rate all risks qualitatively
- Create risk heat map
- Select top risk for FAIR analysis
- Estimate FAIR factors
- Calculate annualized loss expectancy
- Conduct BIA for critical processes
- Create risk register
- Develop board summary
Reflection Questions:
- How did quantification change your view of risk priorities?
- What data would improve your analysis accuracy?
- How would you present uncertainty to executives?
Week Outcome Check
By the end of this week, you should be able to:
- Create and apply qualitative likelihood and impact scales
- Use risk matrices to prioritize risks
- Calculate Annualized Loss Expectancy (ALE)
- Apply the FAIR methodology to quantify cyber risk
- Conduct Business Impact Analysis for critical processes
- Define Recovery Time and Recovery Point Objectives
- Build and maintain risk registers
- Communicate risk in business terms to executives
🎯 Hands-On Labs (Free & Essential)
Quantify cybersecurity risk with practical financial analysis and business impact calculations.
💰 FAIR Risk Analysis Lab
What you'll do: Apply FAIR (Factor Analysis of Information Risk)
methodology—calculate Loss Event Frequency and Loss Magnitude.
Why it matters: FAIR translates cyber risk into financial terms that
executives understand.
Time estimate: 3-4 hours
📊 Business Impact Analysis Exercise
What you'll do: Conduct BIA for critical business processes—identify
dependencies, calculate RTOs/RPOs, estimate financial impacts.
Why it matters: BIA connects security incidents to business outcomes.
Time estimate: 2-3 hours
📈 Risk Quantification Scenarios
What you'll do: Practice quantitative risk analysis—calculate ALE, SLE, ARO,
and cost-benefit analysis for controls.
Why it matters: Quantification enables data-driven security investment
decisions.
Time estimate: 2-3 hours
💡 Lab Strategy: Start with qualitative, then add quantitative—most organizations need both approaches for effective risk management.
Resources
Lab
Complete the following lab exercises to practice risk analysis concepts.