What belongs in the analysis
A practical scenario
Consider a simple scenario: a compromised administrator account creates unauthorized changes, service outage, investigation cost, and customer communication.
Use the scenario to answer two concrete questions: What conditions must be true for the scenario to develop? Where could the chain be interrupted? The record becomes useful when those answers are supported by evidence and tied to a named decision owner.
Evidence worth gathering
Evidence should be proportionate to the importance of the decision. The following records commonly make the discussion more reliable:
- Process and dependency maps
- Historical incidents and near misses
- Recovery and tabletop exercise findings
- Supplier service and notification commitments
- Ranges and assumptions for cost or duration
A practical review sequence
- Clarify starting conditions: Assets, dependencies, access, business context, and assumptions.
- Describe initiating event: The trigger, such as compromised credentials, supplier outage, malicious change, or data exposure.
- Evaluate event path: How the situation develops, including detection, spread, decision delays, and dependencies.
- Test consequences: Operational, financial, customer, legal, safety, and strategic effects over time.
- Confirm response variables: Safeguards, workarounds, recovery capacity, communication, and treatment choices.
- Close the review by answering: What uncertainty matters most?
Common failure modes
- Writing scenarios so vague that every control appears relevant
- Assuming the worst case is always the most useful case
- Ignoring detection and decision timing
- Using precise numbers without showing assumptions
Questions for management
- What conditions must be true for the scenario to develop?
- Where could the chain be interrupted?
- Which consequence drives the decision?
- What uncertainty matters most?
Frequently asked questions
What should be documented first for cyber risk scenario analysis?
Start with starting conditions: Assets, dependencies, access, business context, and assumptions.
Which evidence should receive early attention?
Begin with process and dependency maps and historical incidents and near misses. The right evidence is the evidence capable of changing confidence or the treatment decision.
What commonly weakens this analysis?
One frequent problem is writing scenarios so vague that every control appears relevant. The review should make that weakness visible instead of hiding it behind a score or dashboard.
When should it be revisited?
Review it on the scheduled date and whenever the conditions behind this question change: What conditions must be true for the scenario to develop?