· Guide · 4 min read
ISO 27001 Risk Matrix: How to Define Likelihood, Impact and Risk Levels
Build a repeatable ISO 27001 risk matrix with defined likelihood, impact and acceptance criteria, practical examples and calibration guidance.

A risk matrix is useful only when people can apply it consistently. Multiplying likelihood by impact is the easy part. The difficult work is deciding what likelihood and impact mean for your organization, what evidence supports a rating and which scores require treatment or acceptance. ISO describes ISO/IEC 27001 as a risk-based information security management system standard. NIST SP 800-30 likewise treats likelihood and adverse impact as central risk factors while emphasizing assumptions, rationale and uncertainty. Use the practical guide on building an information security risk register to test the method as you define it.
Start with a clear risk scenario
Avoid register entries such as “cyberattack” or “data breach.” They are too broad to assess consistently. A useful scenario connects:
- an asset or business process;
- a threat event;
- a vulnerability or predisposing condition; and
- a plausible consequence. Example: An attacker exploits an unpatched internet-facing application, gains access to customer records and causes confidentiality, contractual and operational impacts. The extra detail makes likelihood, impact and treatment easier to discuss.
Define likelihood before assigning numbers
A five-point likelihood scale might combine frequency and evidence:
- Rare — exceptional conditions; no known occurrence; strong barriers.
- Unlikely — plausible but not expected during the assessment period.
- Possible — credible and may occur under normal conditions.
- Likely — expected or supported by repeated relevant events.
- Almost certain — frequent, imminent or already occurring. These are examples, not universal ISO definitions. Tailor the assessment period and evidence to your business. A startup, hospital and industrial operator may need different thresholds. For adversarial risks, consider threat capability, intent and targeting as well as vulnerabilities and safeguards. For non-adversarial events, consider expected frequency and environmental conditions.
Define impact across meaningful dimensions
Impact should reflect what the organization is trying to protect. Dimensions may include:
- customer harm;
- confidentiality, integrity and availability;
- legal or regulatory consequences;
- contractual breach;
- operational disruption;
- financial loss;
- safety;
- reputation; and
- strategic objectives. Decide how multiple dimensions combine. Some organizations take the highest credible impact. Others use a defined aggregation method. Document the approach so assessors do not invent a rule case by case.
Build the matrix
For a simple 5×5 model: Risk score = likelihood × impact The result ranges from 1 to 25. Then define bands, for example:
- 1–4: low;
- 5–9: moderate;
- 10–16: high;
- 17–25: critical. These bands are illustrative. Your organization should choose and approve its own thresholds.
Use the free ISO 27001 Risk Score Calculator to test a configurable 5×5 matrix, compare inherent and residual scores and export a session risk register. Treat its output as a working aid; your approved criteria remain authoritative. Test boundary cases. Is a likelihood of 1 and impact of 5 really “moderate”? Does a catastrophic but rare risk need escalation regardless of the product? Exceptions should be explicit.
Distinguish inherent and residual risk
Inherent risk estimates exposure before selected controls are considered. Residual risk estimates what remains after relevant controls operate. Do not reduce residual scores merely because a control exists on paper. Use evidence of design and operation. A backup procedure does not prove recoverability; completed restore tests provide stronger support.
Define treatment and acceptance rules
A score needs a decision path. For each band, define:
- who can accept the risk;
- whether treatment is mandatory;
- escalation thresholds;
- review frequency;
- evidence requirements; and
- overdue-action rules. Document the rationale, not just the number. Two scenarios can share a score but require different responses.
Calibrate the method
Give the same three scenarios to several assessors. Compare results and discuss differences. If scores vary widely, improve scenario wording, scale definitions or guidance examples. Recalibrate when the business, threat environment, technology or obligations change. Use the risk register guide for workshop preparation, then explore the risk-assessment requirement with the Clause Explainer and check relevant safeguards in the Annex A Control Lookup. Sources: NIST SP 800-30 Rev. 1 — NIST SP 800-30 Rev. 1 Official ISO/IEC 27001 overview — ISO overview of ISO/IEC 27001:2022