Table of Contents Link to heading
- Risk Terminology
- Risk Identification Methods
- Threat Modelling
- Risk Assessment: Likelihood and Impact
- Risk Scoring Matrix
- Risk Registers
- Risk Treatment Strategies
Risk Terminology Link to heading
Consistent terminology is foundational to risk management — ambiguous language leads to inconsistent assessments and poor prioritisation decisions.
| Term | Definition |
|---|---|
| Asset | Anything of value to the organisation — data, systems, processes, people, reputation |
| Threat | A potential cause of an unwanted incident that could harm assets |
| Threat actor | The entity that may exploit a vulnerability (insider, external attacker, nation-state, natural event) |
| Vulnerability | A weakness in a system, process, or control that a threat could exploit |
| Exposure | The degree to which an asset is open to a threat |
| Risk | The likelihood that a threat will exploit a vulnerability and the resulting impact |
| Control | A measure that reduces likelihood or impact (also called a safeguard or countermeasure) |
| Residual risk | The risk that remains after controls have been applied |
The relationship: Risk = Threat × Vulnerability × Impact. Reducing any one factor reduces the overall risk.
Risk Identification Methods Link to heading
Comprehensive risk identification requires multiple approaches — no single method surfaces all risks:
-
Asset inventory review: Start with a complete catalogue of information assets, their classification, and their owners. Risks that are not tied to an identified asset are often missed.
-
Process and data flow analysis: Map how data moves through systems and between people. Data crossing system or organisational boundaries creates exposure points.
-
Previous incident review: Historical incidents are reliable indicators of actual (not theoretical) risk. Near-misses are equally valuable.
-
Threat intelligence: External sources (ISACs, vendor advisories, government cyber centres) identify current and emerging threats relevant to the organisation’s sector.
-
Interviews and workshops: Subject matter experts often have visibility into risks that are not documented anywhere. Structured workshops with IT, legal, HR, and business units surface risk knowledge distributed across the organisation.
-
Vulnerability scanning: Technical scanning identifies known weaknesses in systems and applications. Tools like Nessus, Qualys, and OpenVAS catalogue CVEs present in the environment.
-
Penetration testing: Simulated attacks reveal exploitation chains that vulnerability scanning alone does not — particularly for logic flaws and misconfiguration risks.
Threat Modelling Link to heading
Threat modelling structures the thinking about who might attack, what they want, and how they might proceed. The most widely used framework is STRIDE:
| Threat Category | Description | Example |
|---|---|---|
| Spoofing | Pretending to be someone or something else | ARP spoofing, phishing, credential theft |
| Tampering | Unauthorised modification of data or systems | SQL injection, log tampering, config changes |
| Repudiation | Denying having performed an action | Deleting audit logs, claiming not to have sent a message |
| Information Disclosure | Exposing information to unauthorised parties | Data exfiltration, misconfigured S3 buckets |
| Denial of Service | Preventing legitimate access to a system | DDoS, ransomware encrypting files, resource exhaustion |
| Elevation of Privilege | Gaining more rights than authorised | Privilege escalation exploits, misuse of sudo |
Apply STRIDE systematically to each component in a system’s data flow diagram to ensure comprehensive coverage.
A complementary framework is PASTA (Process for Attack Simulation and Threat Analysis), which aligns threat modelling with business objectives and performs attack simulation to prioritise technically validated risks.
Risk Assessment: Likelihood and Impact Link to heading
Once risks are identified, each requires an assessment of two factors: likelihood (how probable is the threat occurring?) and impact (what is the consequence if it does?).
Qualitative Assessment Link to heading
Qualitative methods use descriptive scales — faster to apply, more accessible to non-technical stakeholders, but less precise.
Likelihood scale:
| Level | Description | Example |
|---|---|---|
| Rare (1) | May occur only in exceptional circumstances | Physical theft of server room hardware |
| Unlikely (2) | Could occur but not expected | Targeted nation-state attack on SME |
| Possible (3) | Might occur at some point | Phishing email successfully deceiving a user |
| Likely (4) | Will probably occur in most circumstances | Automated scanning of internet-exposed services |
| Almost certain (5) | Expected to occur in most circumstances | Spam to publicly listed email addresses |
Impact scale:
| Level | Description | Business Impact |
|---|---|---|
| Negligible (1) | Minimal effect | Minor inconvenience, no operational disruption |
| Minor (2) | Some disruption | Limited impact, resolved quickly |
| Moderate (3) | Significant disruption | Measurable financial or operational impact |
| Major (4) | Severe disruption | Significant financial loss, regulatory breach |
| Catastrophic (5) | Business-threatening | Existential risk, major regulatory penalties |
Quantitative Assessment Link to heading
Quantitative methods assign monetary values to risk — more rigorous but requires reliable data.
Key metrics:
| Metric | Definition | Calculation |
|---|---|---|
| Asset Value (AV) | Replacement or business value of the asset | Determined per asset |
| Exposure Factor (EF) | Percentage of asset value lost if threat occurs | 0.0–1.0 |
| Single Loss Expectancy (SLE) | Expected financial loss per incident | SLE = AV × EF |
| Annualised Rate of Occurrence (ARO) | Expected frequency per year | Historical data or expert estimate |
| Annualised Loss Expectancy (ALE) | Expected annual loss from this risk | ALE = SLE × ARO |
Example:
- Database server: AV = $500,000
- Ransomware encrypts all data: EF = 0.9 (90% loss if backups also compromised)
- SLE = $500,000 × 0.9 = $450,000
- ARO = 0.3 (assessed as occurring roughly once every 3 years)
- ALE = $450,000 × 0.3 = $135,000/year
This ALE provides a rational budget ceiling for controls targeting this risk — spending more than $135,000/year on ransomware protection has negative ROI.
Risk Scoring Matrix Link to heading
The risk score combines likelihood and impact into a single number for prioritisation:
Risk Score = Likelihood × Impact
| Likelihood \ Impact | Negligible (1) | Minor (2) | Moderate (3) | Major (4) | Catastrophic (5) |
|---|---|---|---|---|---|
| Almost Certain (5) | 5 | 10 | 15 | 20 | 25 |
| Likely (4) | 4 | 8 | 12 | 16 | 20 |
| Possible (3) | 3 | 6 | 9 | 12 | 15 |
| Unlikely (2) | 2 | 4 | 6 | 8 | 10 |
| Rare (1) | 1 | 2 | 3 | 4 | 5 |
Risk priority bands:
- Critical (15–25): Immediate action required; treat before next review cycle
- High (10–14): Address within 30–90 days; senior management attention
- Medium (6–9): Address within 6 months; active monitoring
- Low (1–5): Accept and monitor; address as resources permit
Risk Registers Link to heading
A risk register is the central repository documenting all identified risks, their assessments, treatment decisions, and owners. It is the primary artefact for risk governance and audit.
Minimum fields for each entry:
| Field | Description |
|---|---|
| Risk ID | Unique identifier for tracking |
| Risk Description | Clear statement of what could happen and why |
| Asset(s) Affected | Which assets are exposed |
| Threat Source | Who or what could cause this |
| Vulnerability | What weakness is being exploited |
| Likelihood | Score (1–5) with rationale |
| Impact | Score (1–5) with rationale |
| Risk Score | Likelihood × Impact |
| Risk Priority | Critical / High / Medium / Low |
| Current Controls | Existing controls already in place |
| Residual Risk | Score after current controls |
| Treatment Plan | Accepted / Mitigated / Transferred / Avoided |
| Risk Owner | Accountable person for treatment |
| Target Date | When treatment must be completed |
| Review Date | Next scheduled reassessment |
Risk Treatment Strategies Link to heading
Once a risk is assessed and prioritised, four treatment strategies are available:
1. Mitigate (Reduce) Implement controls to reduce likelihood, impact, or both. The most common treatment. Examples: patching vulnerabilities, adding MFA, network segmentation, backup systems.
2. Transfer (Share) Shift the financial consequence to a third party. Examples: cyber insurance, outsourcing the function to a managed service provider with contractual liability. Transfers the financial risk but not operational or reputational consequences.
3. Avoid (Eliminate) Discontinue the activity that creates the risk. If the risk comes from operating a particular service or collecting certain data, stopping that activity eliminates the risk. This is only viable when the activity is not core to business objectives.
4. Accept (Tolerate) Acknowledge the risk and choose not to apply additional controls — typically for low-priority risks where treatment costs exceed the expected loss. Acceptance must be a documented, conscious decision made by an accountable risk owner, not an implicit default.
The treatment strategy produces a treatment plan with specific actions, owners, costs, and timelines. Treatment plans feed into the organisation’s security roadmap and budget cycle.