Risk Assessment and Treatment Methodology - Template
An editable ISO 27001 risk methodology. Replace the bracketed placeholders with your own details.
This document sets out how [Organization] identifies, analyses, evaluates and treats information security risk. It exists so that two people assessing the same risk reach a comparable answer, and so that the reasoning behind every treatment decision can be shown to an auditor a year later.
1. Purpose
This methodology defines the repeatable process [Organization] uses to assess and treat information security risk, as required by ISO/IEC 27001:2022 clauses 6.1.2 and 6.1.3. It is the method; the decisions it produces are recorded in the Information Security Risk Register, and the commitment to run it sits in the Risk Management Policy.
Consistency is the point. A method that produces a different answer depending on who ran it cannot support a defensible treatment decision.
2. Scope
This methodology applies to every risk that could affect the confidentiality, integrity or availability of information within the scope of [Organization]'s information security management system, including information held by suppliers on its behalf.
It applies to scheduled assessments and to assessments triggered by change. It does not cover financial, safety or strategic risk except where those risks act through information security.
3. Roles and responsibilities
This methodology is owned by [role], who runs the assessment process and maintains the risk register. Risk owners are the individuals accountable for the system, process or data a risk affects; they supply the facts, agree the treatment and carry it out by its due date.
Approval of this methodology and of the risk acceptance criteria below rests with [approver role], who also formally accepts any residual risk that remains above appetite. Approval sits with a role senior enough to accept the consequence, and not with the person who performed the assessment.
4. Risk criteria: the likelihood scale
Every risk is rated on the same five-point likelihood scale. Rate the likelihood over the next 12 months, given the controls actually in place today rather than the controls intended.
| Level | Rating | What it means |
|---|---|---|
| 1 | Rare | Almost never happens. No realistic path to it under current conditions. |
| 2 | Unlikely | Could happen but is not expected. No known instances in this environment. |
| 3 | Possible | May happen. Has occurred elsewhere in similar organizations, or the conditions exist. |
| 4 | Likely | Probably will happen at some point if nothing changes. |
| 5 | Almost certain | Will almost certainly happen, or is already happening. |
5. Risk criteria: the consequence scale
Consequence is rated on the same five-point scale. Rate the most likely serious outcome, not the worst imaginable one. Where a risk has several kinds of consequence, use the highest.
| Level | Rating | What it means |
|---|---|---|
| 1 | Negligible | Minor inconvenience, quickly fixed. No harm to any individual and no reportable effect. |
| 2 | Minor | Short-lived disruption to one team. Limited effect on a small number of people. |
| 3 | Moderate | Noticeable harm and some cost to fix. A group of customers or staff is affected. |
| 4 | Major | Significant damage and substantial cost. A privacy breach, a contractual failure, or lost trust affecting many people. |
| 5 | Critical | Severe damage. Business continuity at risk, regulatory action, or widespread harm to individuals. |
5.1 Working out the risk level
Multiply likelihood by consequence, both rated 1 to 5. Read the band off the matrix below. The same matrix is used for the inherent risk, before any control, and again for the residual risk after the chosen treatment is in place.
| Likelihood \ Consequence | Negligible (1) | Minor (2) | Moderate (3) | Major (4) | Critical (5) |
|---|---|---|---|---|---|
| Almost certain (5) | Medium (5) | High (10) | High (15) | Critical (20) | Critical (25) |
| Likely (4) | Low (4) | Medium (8) | High (12) | High (16) | Critical (20) |
| Possible (3) | Low (3) | Medium (6) | Medium (9) | High (12) | High (15) |
| Unlikely (2) | Low (2) | Low (4) | Medium (6) | Medium (8) | High (10) |
| Rare (1) | Low (1) | Low (2) | Low (3) | Low (4) | Medium (5) |
5.2 Risk acceptance criteria
The band decides what has to happen next. These are the criteria required by clause 6.1.2 a), and they are approved by [approver role].
| Band | Score | What must happen |
|---|---|---|
| Low | 1 to 4 | Accepted as it stands. Record it; no treatment is required. |
| Medium | 5 to 9 | Monitored, and treated where a control is cost-effective. Record the decision either way. |
| High | 10 to 16 | Must be treated. Cannot be left untreated. |
| Critical | 17 to 25 | Must be treated, and reported to [approver role] at the next management review or sooner. |
6. Risk identification
Risks are identified against the information assets, systems, suppliers and processes in scope. Each risk is written as a cause, an event and an effect, so that it can be assessed and treated rather than merely named. "Phishing" is not a risk; "an employee is deceived by a phishing email, exposing customer records held in [system], leading to a notifiable breach" is.
- Asset and system inventories, including systems held by suppliers
- Incidents, near misses and audit findings since the last assessment
- Changes to the business: new products, new markets, new suppliers, acquisitions
- Legal, regulatory and contractual obligations
- Threat information relevant to [Organization]'s sector and technology
7. Risk analysis
Each identified risk is assigned a risk owner, then rated for likelihood and consequence using the scales above, first as the inherent risk before any control is considered.
The rating and the reasoning behind it are both recorded. A score with no reasoning cannot be reviewed, and cannot be defended when the assessor has left.
8. Risk evaluation
Risks are compared against the acceptance criteria in section 5.2 and placed in priority order by score. Where two risks score the same, the one with the higher consequence is treated first.
The output of this step is a list of risks that require treatment and a list of risks accepted as they stand, each with the reason recorded.
9. Risk treatment options
For each risk requiring treatment, the risk owner and [role] select one of the four options below and record why. The option chosen is recorded in the risk register against the risk.
- Modify: apply controls that reduce the likelihood, the consequence, or both
- Avoid: stop or change the activity that gives rise to the risk
- Share: transfer part of the consequence, through insurance or a contractual term, noting that accountability for the information itself is never transferred
- Retain: accept the risk as it stands, within the acceptance criteria, with the acceptance recorded and approved
10. Determining controls and the Statement of Applicability
Controls are chosen because they treat an identified risk, not because they appear on a list. Once the necessary controls are determined, they are compared against Annex A of ISO/IEC 27001:2022 to confirm that nothing necessary has been left out, as clause 6.1.3 c) requires.
That comparison produces the Statement of Applicability: every Annex A control, whether it applies, the justification for including or excluding it, and where an included control is implemented. An exclusion states the fact about [Organization] that makes it inapplicable; "not applicable" on its own is the most common finding raised against a Statement of Applicability.
11. Residual risk and approval
After the chosen treatment is in place, the risk is rated again using the same scales and matrix. That residual rating is recorded alongside the inherent one, so the effect of the treatment is visible.
The risk owner approves the treatment plan and [approver role] accepts the residual risk. Clause 6.1.3 f) requires both, and the risk register records who approved what and when.
12. The risk register
Every risk, treated or accepted, is recorded in the Information Security Risk Register, one row per risk carrying its whole lifecycle: identifier, date raised, description, owner, inherent rating, treatment option, the controls applied with their Annex A references, due date, residual rating, approvals and current status.
The register is the record required by clauses 8.2 and 8.3. This methodology is the method behind every entry in it.
13. When the assessment is repeated
[Organization] performs a full risk assessment at least [annually]. Between full assessments, individual risks are reassessed whenever one of the triggers below occurs, and the register is updated rather than left until the next cycle.
- A security incident, or a near miss that revealed a gap
- A new system, product, supplier or material change to an existing one
- A change to the scope of the management system
- A new or changed legal, regulatory or contractual obligation
- An audit finding, internal or external
14. Records and review
Records produced by this methodology - the register, the Statement of Applicability, treatment approvals and residual risk acceptances - are retained for [period] and are available to internal and external auditors.
This methodology is reviewed [annually] and whenever the scales, the acceptance criteria or the scope change. Changes to the criteria are approved by [approver role] before they are used, and the reason for the change is recorded.
This template is a starting point, not legal or audit advice. Replace every bracketed placeholder, delete what does not apply, and have it approved before you rely on it. Check that every matrix cell still agrees with your score bands if you change the scales.
