Risk Assessment Methodology & Scoring Model
Establishes the risk criteria, scales and scoring rules that make assessments comparable between assessors and defensible to an auditor.
Available soon
- Format
- Word
- Size
- 70 KB
- Length
- 24 pages
- Version
- 1.1
- Updated
What's inside
- Purpose
- The rules
- Principles
- Inputs
- Writing a risk
- Scales and criteria
- Calculation
- Appetite, tolerance and position
- Treatment
- Review, reassessment and reporting
- Worked examples
- How this method connects to exceptions and board reporting
- How to defend the method to an auditor
- Limitations
- Calibration and review
- Related documents
- Adapting this template
- Framework references
- Definitions
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This methodology is how [[Organisation Name]] turns "what could go wrong, and how much does it matter?" into a rating that two assessors reach independently, and that decides something. Every information security risk is written the same way, scored on the same scale, compared with the same appetite and taken to the same level of management for a decision.
It sets the risk criteria: the rules RM-01 to RM-12 below, the impact and likelihood scales, the matrix and its four bands, and the position of each risk against appetite and tolerance. Every other document in the Information Security Risk Management pack applies these rules and cites them by number.
It uses the same 4 × 4 impact and likelihood scale and the same four bands as the Exception Risk Scoring & Expiry Model, which applies the scale to security exceptions, and the same position rule as the board measure BM-01 (Risks outside appetite) in the Board Reporting Narrative Model. A risk, an exception and a board report therefore describe the same exposure in the same words.
Guidance — delete before approval
If your organisation already has an enterprise risk scale, keep one scale, not two. Either adopt this one for all risks or replace the anchors here with your enterprise scale's, keeping four levels of impact and likelihood so the bands, the exception model and the board measure still work.
Replace every amount in [[double brackets]] with your own thresholds before approval. They must match the thresholds your finance or enterprise risk function uses, or the board will see two different meanings of 'Severe'.
The rules
These twelve rules are the method. The sections that follow explain each one; the rest of the pack quotes them by number.
RM-01 Every risk is written as a scenario: a threat, the weakness it uses, the asset or service affected, and the consequence.
RM-02 Every risk has one named owner: the executive accountable for the service or asset it would hurt, not the security team.
RM-03 Risk is scored on the 4 × 4 scale: impact on the worst consequence, likelihood over the next 12 months, before and after existing controls.
RM-04 The residual score's band decides who must know and who may accept (ACCEPTANCE).
RM-05 Each risk's residual band is compared with its category's appetite and tolerance, giving its position in words.
RM-06 A risk first assessed outside appetite gets a treatment decision within [[30]] calendar days of that assessment: reduce, avoid, transfer or accept. Later reviews do not restart the window.
RM-07 Treatment actions have an owner, a due date, a cost and the residual score expected when they are done.
RM-08 Accepting a residual risk is recorded on the Risk Acceptance Form, approved at the band's level, and reviewed by its date; outside tolerance only the board or its equivalent may accept.
RM-09 Owners review each risk every quarter; the whole register is reassessed once a year and on any trigger.
RM-10 A trigger forces reassessment of the risks it touches within [[10]] working days.
RM-11 The register is the single record of assessed risks; assessments and scenarios become register entries, not separate lists.
RM-12 The risk position against appetite, its movement and treatment progress are reported to executive management every quarter.
Guidance — delete before approval
RM-06 and RM-10 carry template defaults in [[double brackets]]: [[30]] calendar days for a treatment decision, [[10]] working days for a triggered reassessment. You may change them; change them here and in the Risk Identification & Assessment Operating Procedure together.
Principles
Most questions about why a risk received the rating it did are answered by one of these.
- A risk is a story, not a topic. 'Ransomware' is a topic. 'Ransomware takes online ordering offline for more than 2 days' is a risk someone can own, score and treat (RM-01).
- The business owns the risk. The executive who would feel the harm owns it and decides what to do about it. The security team assesses, advises and reports (RM-02).
- Score the worst credible consequence, not the worst imaginable one. Impact is the worst outcome that a reasonable person, knowing the facts, would say could happen, not the worst anyone can invent.
- Only working controls count. A control lowers the residual score only if it is in place and there is evidence it works. A planned control is a treatment action, not a reason for a lower score (RM-03, RM-07).
- The rating decides; nobody negotiates it. Once scored, who must know and who may accept follow from one table (RM-04). A manager may disagree with a rating and give a reason; they may not choose a band.
- When unsure, round up. Between two levels, use the higher. Missing information raises the rating, so the people who can supply the facts have a reason to.
Inputs
The assessor gathers these before scoring. The Risk Identification & Assessment Operating Procedure says where each comes from and who supplies it.
Input | Question it answers | Where it comes from | If it is not known |
|---|---|---|---|
Asset or service affected | What would be hurt, and how important is it to the business? | [[Asset and service inventory]], with criticality | Assume the most important service the scenario could reach |
Threat | Who or what could cause it, and are they active against organisations like ours? | Threat intelligence; incident history; the Cyber Risk Scenario Library | Treat the threat as active |
Weakness | What gap or condition would the threat use? | Vulnerability scans, audits, tests, exceptions (Security Exception & Waiver Standard) | Assume the gap exists |
Existing controls | What reduces the likelihood or impact today, and what shows it works? | Control owners, with evidence: test results, configuration, logs | No control counts until shown to work |
Consequence | What would it cost, stop or breach? | Risk owner; finance; legal; the impact areas below | Use the higher of the two levels in doubt |
Category | Which appetite applies? | Cyber Risk Appetite Statement Template | Use the category with the lower appetite |
Guidance — delete before approval
An open security exception is a known weakness. When a risk depends on a control that is under exception, score the risk as if that control were missing, and note the exception reference.
Writing a risk
A risk is a scenario
RM-01: Every risk is written as a scenario: a threat, the weakness it uses, the asset or service affected, and the consequence. A title of one sentence names the event and the harm; the four parts behind it make it scoreable.
Part | Question | EXAMPLE — R-02 |
|---|---|---|
Threat | Who or what causes it? | A fraudster who has taken over a supplier's email account |
Weakness | What gap does it use? | Changes to supplier bank details are accepted by email without a call-back |
Asset or service | What is hurt? | Supplier payments |
Consequence | What does it cost, stop or breach? | Single losses of €50k to €400k; not recoverable once paid |
Titles that fail RM-01, and how to fix them:
Not a risk | Why it fails | Written as a scenario |
|---|---|---|
Cyber attack | No threat, weakness, asset or consequence: it cannot be scored or owned. | Ransomware takes online ordering offline for more than 2 days |
Phishing | A threat only. It says nothing about what would be hurt. | Staff account taken over through phishing |
No multi-factor sign-in on the payments portal | A weakness only. It is a finding for the treatment plan, not a risk. | [[Payments diverted by a fraudster who signs in to the payments portal with a stolen password]] |
GDPR non-compliance | A consequence with no cause. Every data risk ends here. | Cloud storage misconfigured and customer files exposed |
Legacy IT | A condition, too broad to score. | Critical weaknesses on internet-facing systems exploited before they are fixed |
The Cyber Risk Scenario Library gives scenarios already written this way. Adapt one rather than starting from a topic, and record the result in the Information Security Risk Register, not in a separate list (RM-11).
Every risk has one owner
RM-02: Every risk has one named owner: the executive accountable for the service or asset it would hurt, not the security team.
EXAMPLE risk | Owner | Why this owner |
|---|---|---|
R-01 Ransomware takes online ordering offline for more than 2 days | Chief Operating Officer | Runs the service that would stop and answers to customers for it. |
R-02 Payment fraud through a compromised supplier email account | Chief Financial Officer | Owns the payment process and the money that would be lost. |
R-08 Significant incident not reported to the authority on time (NIS2) | Head of Information Security | The duty to report is the security function's own obligation. |
R-12 Customer data on an unencrypted laptop at the smaller warehouse site is lost or stolen | Head of Logistics | Runs the site and decides how its laptops are used. |
- One owner, by role, not a committee or a department. Where two executives share a service, the one who would answer for the harm owns the risk.
- The security function owns a risk only where the harm falls on its own duties, as with R-08. Otherwise it is the assessor, not the owner.
- The owner decides the treatment and signs the acceptance; they may delegate the work, not the decision.
Scales and criteria
Impact and likelihood each have four levels. The anchors decide the level; where a risk sits between two levels, use the higher.
Impact
Impact is the worst credible consequence if the scenario happens, judged on whichever of the five areas below is worst. It is rated once for the risk, not averaged across the areas.
Area | 1 Minor | 2 Moderate | 3 Major | 4 Severe |
|---|---|---|---|---|
Financial | less than [[€50,000]] | [[€50,000]] to [[€250,000]] | [[€250,000]] to [[€1,000,000]] | more than [[€1,000,000]] |
Service | an internal service degraded for hours | a customer service degraded, or an internal service stopped, for up to [[1]] day | a core customer service stopped for up to [[2]] days | a core customer service stopped for more than [[2]] days |
Data | internal, non-personal data | internal confidential data, or personal data of a few people | personal or customer data of [[hundreds]] of people, or commercially sensitive data | personal or customer data at scale |
Legal and regulatory | no notification or breach | a minor breach of contract or policy, put right without penalty | a formal enquiry by a regulator or customer, or a contract breach with penalties | a notifiable breach, enforcement or contract termination |
Reputation | not noticed outside the team | noticed by some customers or suppliers | complaints from several major customers, or regional or trade press | national press, or loss of a major customer |
Personal data. When a scenario involves personal data, impact is judged on the worse of two harms: the harm to the organisation and the harm to the people whose data it is — distress, fraud, discrimination or loss of control over their information. A breach that costs the organisation little can still be Major or Severe for the people concerned (GDPR Article 32(1): security appropriate to the likelihood and severity of the risk to their rights and freedoms).
In terms of systems and data, the four levels read as follows. These are the anchors the exception model uses, so a gap under exception and a risk in the register are rated alike.
Level | Anchor |
|---|---|
1 Minor | Affects one system of Standard criticality or non-sensitive data; no customer or regulatory effect. |
2 Moderate | Affects a High criticality system or internal confidential data; limited, recoverable disruption. |
3 Major | Affects a Critical system, personal or customer data, or a regulated service; notifiable if it went wrong. |
4 Severe | Could stop a core business service, expose sensitive data at scale, or breach a legal obligation. |
Guidance — delete before approval
The Financial row must match your enterprise risk scale. A useful check: level 4 should be an amount the board would want to hear about the same week. Amounts in the examples are in euros (€); use your own currency.
Likelihood
Likelihood is the chance that the scenario happens, with the consequence scored, in the next 12 months (RM-03).
Level | Chance in the next 12 months | What it usually looks like | Exposure anchor (as in the exception model) |
|---|---|---|---|
1 Unlikely | less than [[20]]% in the next 12 months | Not seen at organisations like ours in recent years, or only with rare skill or access. | Not reachable from the internet or by ordinary users; no known exploitation; strong compensating control in place. |
2 Possible | [[20]]% to [[50]]% in the next 12 months | Happens regularly to organisations like ours; our controls make it harder but not rare. | Reachable internally; exploitation needs skill or insider access. |
3 Likely | [[50]]% to [[90]]% in the next 12 months | Happening now to organisations like ours, or has happened to us, and the gap is still open. | Reachable by many users or from partner networks; exploitation techniques are public. |
4 Almost certain | more than [[90]]% in the next 12 months, or already happening | Being attempted against us now, with little in the way. | Internet-facing or known to be actively exploited, with no effective compensating control. |
Use the chance where you have data — your own incidents, sector reports, threat intelligence — and the description or exposure anchor where you do not. Where they disagree, use the higher level.
Guidance — delete before approval
The percentages are template defaults; set your own. They are chosen so that the words mean the same in the board report: the Board Reporting Narrative Model uses 'Unlikely', 'Possible' and 'Likely' for the same ranges, and folds levels 3 and 4 into 'Likely'.
The exposure anchors at levels 1 and 4 mention compensating controls because the exception model uses them for gaps. For a risk, all existing controls are counted in the residual score; do not count a control twice.
Calculation
Inherent and residual scores
RM-03: Risk is scored on the 4 × 4 scale: impact on the worst consequence, likelihood over the next 12 months, before and after existing controls.
Score | What it assumes | What it is for |
|---|---|---|
Inherent | No specific controls for this scenario: only what any organisation of the same kind would have by default. | Shows how much the controls are doing, and what would happen if they failed. |
Residual | Existing controls that are in place and shown to work. Planned controls do not count. | The score that decides who must know, who may accept and the position against appetite. |
Expected | The treatment actions are complete and working. | The target for the treatment actions (RM-07); it becomes the residual score only when the actions are done and shown to work. |
For a risk, a working control may lower impact as well as likelihood: an isolated backup restored in a day reduces how long a service stays down, not only how likely an outage is. This is the main difference from the exception model, where a tested compensating control lowers likelihood by one step and never touches impact (EX-07 in the Security Exception & Waiver Standard). An exception is a gap for a limited time; a risk is scored with everything that is actually in place.
The steps
- Write the scenario (RM-01) and name the owner (RM-02). Choose the category, which sets the appetite (Cyber Risk Appetite Statement Template).
- Rate inherent impact and likelihood, 1 to 4 each, with the anchors. Record one sentence of reason for each rating.
- List the existing controls and the evidence that each works. Leave out any without evidence.
- Rate residual impact and likelihood with those controls. Record the reason for each change from the inherent rating.
- Score = impact × likelihood, for inherent and residual. Read the band from the matrix.
- Read what the residual band decides: who must know and who may accept (RM-04).
- Compare with appetite and tolerance for the category, giving the position in words (RM-05).
- If outside appetite, decide the treatment within [[30]] calendar days of the risk first being assessed outside appetite; later reviews do not restart the window (RM-06), and record the expected score of each action (RM-07).
The matrix
Impact runs down the side, likelihood across the top. Only nine scores are possible: 1, 2, 3, 4, 6, 8, 9, 12, 16. The same matrix is used for inherent, residual and expected scores.
Impact ↓ / Likelihood → | 1 Unlikely | 2 Possible | 3 Likely | 4 Almost certain |
|---|---|---|---|---|
4 Severe | 4 Medium | 8 High | 12 Critical | 16 Critical |
3 Major | 3 Low | 6 Medium | 9 High | 12 Critical |
2 Moderate | 2 Low | 4 Medium | 6 Medium | 8 High |
1 Minor | 1 Low | 2 Low | 3 Low | 4 Medium |
Bands: Low 1–3; Medium 4–6; High 8–9; Critical 12–16. There are no scores of 5, 7, 10, 11, 13, 14 or 15, so the bands have no gaps.
What the band decides
RM-04: The residual score's band decides who must know and who may accept (ACCEPTANCE). The review period is in calendar months from the date of acceptance.
Residual band | Score | Who must know | Who may accept | Acceptance reviewed within |
|---|---|---|---|---|
Low | 1–3 | Risk owner; recorded in the register | Risk owner | 12 months |
Medium | 4–6 | Risk owner and Head of Information Security | Risk owner and Head of Information Security | 12 months |
High | 8–9 | Accountable executive and Head of Information Security; named to executive management in the quarterly report | Accountable executive and Head of Information Security | 6 months |
Critical | 12–16 | Executive management at once; the board chair out of cycle, within [[5]] working days (Critical is always outside tolerance) | The board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management | 3 months |
The position adds to the band's approvers; it never replaces them (RM-08):
Position | Who signs the acceptance | EXAMPLE: a High residual risk |
|---|---|---|
Within appetite | The band's approvers | Accountable executive and Head of Information Security |
Outside appetite, within tolerance | The band's approvers, and executive management as well: in addition, never instead | Accountable executive and Head of Information Security, and executive management as well |
Outside tolerance | The band's approvers recommend; only the board or its equivalent may accept | Accountable executive and Head of Information Security recommend; only the board or its equivalent may accept |
Guidance — delete before approval
Critical is never within anyone's tolerance, so a Critical residual risk can only be accepted by the board or its equivalent, and it is reported out of cycle. Who that is depends on how the organisation is governed: the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management. That is deliberate: a Critical risk is one the organisation should decide to fix, stop or knowingly carry at the top, not in a register.
Appetite, tolerance and position
RM-05: Each risk's residual band is compared with its category's appetite and tolerance, giving its position in words. Each category of risk has an appetite level, set in the Cyber Risk Appetite Statement Template and approved by the board.
Appetite level | Appetite: highest residual band accepted without escalation | Tolerance: highest band tolerated while a plan brings it back | Meaning |
|---|---|---|---|
Averse | Low | Medium | We avoid this risk and act on anything above Low. |
Cautious | Medium | High | We accept some risk for a clear business benefit, with controls. |
Open | High | High | We accept higher risk to pursue opportunity; Critical is never within tolerance. |
The position rule
A risk's position is one of three phrases, always in words:
- Outside tolerance — the residual band is above the category's tolerance.
- Outside appetite, within tolerance — above the appetite, not above the tolerance.
- Within appetite — at or below the appetite.
Every combination, so nobody works it out afresh:
Residual band | Averse category | Cautious category | Open category |
|---|---|---|---|
Low | Within appetite | Within appetite | Within appetite |
Medium | Outside appetite, within tolerance | Within appetite | Within appetite |
High | Outside tolerance | Outside appetite, within tolerance | Within appetite |
Critical | Outside tolerance | Outside tolerance | Outside tolerance |
This is the rule the board measure uses. For the organisation as a whole, BM-01 in the Board Reporting Narrative Model applies it across the top risks: "Outside tolerance if any top risk is past its own tolerance limit; otherwise Outside appetite, within tolerance if any top risk is above appetite; otherwise Within appetite." The pack's measure RMM-01 (Risks outside appetite and past tolerance) is the same count.
Categories
The EXAMPLE firm's categories and appetite levels. Yours are set in the Cyber Risk Appetite Statement Template.
Category | EXAMPLE appetite level | Appetite | Tolerance |
|---|---|---|---|
RC-01 Service availability | Cautious | Medium | High |
RC-02 Customer and personal data | Cautious | Medium | High |
RC-03 Financial fraud | Cautious | Medium | High |
RC-04 Regulatory compliance | Averse | Low | Medium |
RC-05 Third-party dependency | Cautious | Medium | High |
RC-06 People and insider | Cautious | Medium | High |
Treatment
RM-06: A risk first assessed outside appetite gets a treatment decision within [[30]] calendar days of that assessment: reduce, avoid, transfer or accept. Later reviews do not restart the window.
Option | What it means | Residual score afterwards |
|---|---|---|
Reduce | Change the likelihood or the impact with controls. | The expected score, once the actions are done and shown to work. |
Avoid | Stop the activity that creates the risk. | The risk is closed once the activity has stopped. |
Transfer | Share the impact with a third party, for example by insurance or contract; the risk owner still owns the risk. | Usually lower impact for the organisation; likelihood unchanged. Check what the insurance or contract actually covers. |
Accept | Keep the residual risk knowingly, recorded and approved at the right level (Risk Acceptance Form). | Unchanged. Recorded, approved at the right level and reviewed by a date (RM-08). |
- RM-07: Treatment actions have an owner, a due date, a cost and the residual score expected when they are done.
- RM-08: Accepting a residual risk is recorded on the Risk Acceptance Form, approved at the band's level, and reviewed by its date; outside tolerance only the board or its equivalent may accept.
- A risk within appetite needs no new decision. The owner may still choose to reduce it where it is cheap to do so.
- A risk kept outside appetite for more than one quarter without a treatment decision is reported by name to executive management (RM-12).
Treatment actions are recorded in the Risk Treatment Plan; acceptances on the Risk Acceptance Form & Approval Record.
Review, reassessment and reporting
RM-09 Owners review each risk every quarter; the whole register is reassessed once a year and on any trigger.
RM-10 A trigger forces reassessment of the risks it touches within [[10]] working days.
RM-11 The register is the single record of assessed risks; assessments and scenarios become register entries, not separate lists.
RM-12 The risk position against appetite, its movement and treatment progress are reported to executive management every quarter.
A reassessment is triggered by any of these:
- A major incident, or a near miss that shows a risk was underrated
- A major change to systems, processes, suppliers or the organisation
- A new or changed threat relevant to our services (threat intelligence)
- An audit, test or assessment finding
- A change in law, regulation or a key contract
The quarterly report to executive management carries the four headline measures:
Measure | Definition | Target |
|---|---|---|
RMM-01 Risks outside appetite and past tolerance | Top risks whose residual band is above their category's appetite; and of those, above its tolerance. | Zero past tolerance; outside appetite each with a treatment decision |
RMM-02 Treatment actions overdue | Open treatment actions past their due date. | Zero older than 30 days |
RMM-03 Acceptances past review | Accepted risks whose acceptance review date has passed. | Zero |
RMM-04 Risks not reviewed this quarter | Register entries with no owner review in the last quarter (RM-09). | Zero |
Worked examples
The three examples are from the EXAMPLE firm used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. Figures are as at 30 September 2026 (EXAMPLE; replace with your own assessment date). Every score and position is worked out by the rules above. Amounts in the examples are in euros (€); use your own currency.
Example 1 — R-01, High and outside appetite
Step | R-01 Ransomware takes online ordering offline for more than 2 days |
|---|---|
Scenario (RM-01) | Threat: Criminal ransomware group. Weakness: The ordering platform cannot be restored from backup in less than 4 days. Asset or service: The online ordering service (60% of orders). Consequence: Loss of about €1.2m of orders per week; customer contracts breached. |
Owner (RM-02) | Chief Operating Officer |
Inherent (RM-03) | Impact 4 Severe: an outage of more than 2 days stops ordering, the Service and Financial areas are both Severe. Likelihood 3 Likely: ransomware against distributors is common and the platform is internet-facing. → 4 × 3 = 12, Critical. |
Existing controls | Endpoint protection on servers, multi-factor sign-in for remote access, and nightly backups restored in a test in the last quarter. The restore took 4 days, so backups do not bring the outage under 2 days. |
Residual (RM-03) | Impact stays 4 Severe: if it happens, the restore still takes longer than 2 days. Likelihood falls to 2 Possible: the controls make a successful attack harder. → 4 × 2 = 8, High. |
Band (RM-04) | Who must know: Accountable executive and Head of Information Security; named to executive management in the quarterly report. Who may accept, by band: Accountable executive and Head of Information Security. |
Position (RM-05) | Service availability (RC-01) is Cautious: appetite Medium, tolerance High. Residual High → Outside appetite, within tolerance (RM-05). |
Who may accept now (RM-08) | Accountable executive and Head of Information Security, and executive management as well: the band's approvers sign, and because the position is outside appetite, executive management signs too. |
Treatment (RM-06, RM-07) | Reduce. TA-01: Rebuild the ordering platform's recovery so it can be restored within 24 hours. Owner Head of IT; due 15 December 2026; cost €180,000; expected 4 × 1 = 4, Medium → Within appetite. Status: Awaiting board approval. |
Reported (RM-12) | One of the 2 risks counted in RMM-01. The money needs the board: this is the decision the Board Reporting Narrative Model worked example puts to the board on 29 October 2026. |
Example 2 — R-02, a likely loss that controls have only partly reduced
Step | R-02 Payment fraud through a compromised supplier email account |
|---|---|
Scenario (RM-01) | Threat: A fraudster who has taken over a supplier's email account. Weakness: Changes to supplier bank details are accepted by email without a call-back. Asset or service: Supplier payments. Consequence: Single losses of €50k to €400k; not recoverable once paid. |
Owner (RM-02) | Chief Financial Officer |
Inherent (RM-03) | Impact 3 Major: a single payment of up to €400,000 falls in the Financial row's Major range. Likelihood 4 Almost certain: attempts arrive every month. → 3 × 4 = 12, Critical. |
Existing controls | Two people approve each payment run; finance staff have had training on invoice fraud. Neither checks that a changed bank account is genuine. |
Residual (RM-03) | Impact unchanged at 3 Major. Likelihood 3 Likely: the second approver catches some attempts. → 3 × 3 = 9, High. |
Position (RM-05) | Financial fraud (RC-03) is Cautious: appetite Medium, tolerance High. Residual High → Outside appetite, within tolerance (RM-05). |
Treatment (RM-06, RM-07) | Reduce. TA-02: Call-back verification of every change to supplier bank details, and a payment verification service. Owner Chief Financial Officer; due 30 November 2026; cost €15,000; expected 3 × 2 = 6, Medium → Within appetite. Status: In progress. |
What it shows | Two controls moved the inherent Critical score only one band, because neither addressed the weakness in the scenario. The action that does — checking the bank details by phone — is the one that brings it within appetite. |
Example 3 — R-12, a Medium risk accepted
Step | R-12 Customer data on an unencrypted laptop at the smaller warehouse site is lost or stolen |
|---|---|
Scenario (RM-01) | Threat: Theft or loss of a laptop. Weakness: Six older laptops at the smaller warehouse site are not encrypted: encrypting the old models before their March 2027 refresh would cost more than the risk. Asset or service: Customer delivery lists held on those laptops. Consequence: Business customers' contact names and delivery addresses exposed; a data incident to assess for notification. |
Owner (RM-02) | Head of Logistics |
Inherent and residual (RM-03) | Impact 2 Moderate: delivery lists for business customers, not personal data at scale. Likelihood 2 Possible: laptops are lost from time to time. No specific control exists, so inherent and residual are the same: 2 × 2 = 4, Medium. |
Position (RM-05) | Customer and personal data (RC-02) is Cautious: appetite Medium, tolerance High. Residual Medium → Within appetite (RM-05). |
Treatment | Accept. The six laptops concerned are replaced in the March 2027 refresh; encrypting the old models would cost more than the risk, and they hold customer delivery lists only. |
Who may accept (RM-08) | Medium band, within appetite: Risk owner and Head of Information Security. Approved by Head of Logistics (risk owner) and Head of Information Security on 15 June 2026; to be reviewed by 15 June 2027 (12 months). |
Conditions | Laptops stay on site, are locked away overnight and are not used for customer data exports. |
What it shows | Acceptance is a decision, not a default. It is recorded on the Risk Acceptance Form & Approval Record with a reason, conditions and a review date, and RMM-03 reports it if the review date passes. |
How this method connects to exceptions and board reporting
Three packs describe the same exposure. The table shows where each concept lives.
Concept | This methodology (P05) | Exceptions (P02, Exception Risk Scoring & Expiry Model) | Board reporting (P03, Board Reporting Narrative Model) |
|---|---|---|---|
Scale | 4 × 4 impact × likelihood | The same scale, applied to a gap for as long as the exception is open | Likelihood words that match levels 1 to 3 |
Bands | Low 1–3; Medium 4–6; High 8–9; Critical 12–16 | The same bands | Not shown; the board sees positions |
What a control does | Any working control may lower impact or likelihood | A tested compensating control lowers likelihood by one step only (EX-07) | — |
Who decides | Band sets who may accept; the position adds signatures (RM-04, RM-08) | Band sets who approves the exception and for how long | The board decides past tolerance |
A broken rule | Not a risk acceptance. Where the exception leaves a risk outside appetite or Critical, this pack's approver for that position also signs the exception | A broken rule is a P02 exception, not a risk acceptance. Where the exception leaves a risk outside appetite, or scored Critical, the approver this pack requires for that position also signs the exception: the stricter of the two always applies. | — |
Position | Per risk, against its category (RM-05) | — | Across the top risks: BM-01, Risks outside appetite |
Measure | RMM-01 Risks outside appetite and past tolerance | Exceptions by band, expired and chronic | BM-01 = RMM-01 |
- An exception feeds a risk. An open exception is a weakness; the risks that depend on the excepted control are scored without it (see Inputs). A High or Critical exception should be named in the register entry of the risk it raises.
- The board sees the register's count. RMM-01 counts the top risks outside appetite and past tolerance. In the EXAMPLE, 2 of 12 top risks are outside appetite and 0 past tolerance, so the board is told "Outside appetite, within tolerance", with "Better (was 3)" because R-04 returned within appetite this quarter.
How to defend the method to an auditor
An auditor will usually test that the risk criteria are defined, including the criteria for accepting risk; that repeated assessments give consistent, valid and comparable results; that each risk has an owner; and that owners approved the treatment and accepted the residual risk (ISO/IEC 27001 clauses 6.1.2 and 6.1.3). Regulated entities will also be asked to show an approved tolerance and a documented assessment method (Delegated Regulation (EU) 2024/1774 Article 3(a) and (b)).
Evidence to have ready
- This methodology, approved, and the appetite statement it refers to, approved by the board.
- The Information Security Risk Register: every risk with its scenario, owner, category, inherent and residual ratings with reasons, band, position and treatment.
- For each control that lowered a residual score, the evidence that it works.
- Treatment decisions for every risk outside appetite, dated within [[30]] calendar days of the risk first being assessed outside appetite (RM-06); acceptances approved at the right level (RM-08).
- The calibration record (see 'Calibration and review').
- The last four quarterly reports to executive management with RMM-01, RMM-02, RMM-03, RMM-04 (RM-12).
The re-derivation test
Invite the auditor to pick [[10]] risks from the register. For each, take the recorded ratings and read the band from the matrix and the position from the position table. Each result should match the register, and each acceptance should be signed at the level the band and position require. Run this test yourself each quarter, so the first time is not in front of the auditor.
Questions auditors commonly ask
Question | Answer the method gives |
|---|---|
How do you make sure two assessors reach the same result? | Written anchors for every level, a reason recorded for each rating, 'round up' when unsure, and a calibration exercise before first use and every year (see 'Calibration and review'). |
Where are the risk acceptance criteria? | In 'What the band decides': the band's approvers always sign; outside appetite executive management signs as well; outside tolerance only the board may accept (RM-04, RM-08). |
Why score before and after controls? | The inherent score shows what the controls are worth and which ones matter most if they fail; the residual score is what decisions are based on (RM-03). |
How do you know risks are current? | Owners review quarterly, the whole register is reassessed yearly, and any of 5 triggers forces a reassessment within [[10]] working days (RM-09, RM-10). RMM-04 reports any risk not reviewed. |
Is the 4 × 4 scale fine enough? | It is deliberately coarse. It decides who must know, who may accept and whether a risk is within appetite, where consistency matters more than precision. The ratings behind each score are recorded. |
How does this relate to your exception process? | Exceptions are scored on the same scale by the Exception Risk Scoring & Expiry Model; their weaknesses feed the risks they raise (see 'How this method connects'). |
Limitations
No scoring method is complete. These are this one's known weaknesses, and how they are managed.
Limitation | Effect | How it is managed |
|---|---|---|
Ratings are judgements. | Two assessors can differ by a level, which can change the band and the position. | Anchors; reasons recorded; round up; yearly calibration; quarterly re-derivation. |
Multiplying ordinal numbers is a convention, not arithmetic. | A 2 × 4 and a 4 × 2 both score 8, though a moderate near-certain risk and a severe possible one are different. | Both are High and treated alike, which is the only use the score is put to. The two ratings are kept, and the treatment is chosen from them, not from the product. |
Risks are scored one at a time. | Several Medium risks on one service can add up to more than any one shows. | The quarterly review looks for clusters by service and owner; a cluster is rewritten as one scenario at its worst consequence. |
Probability is hard to estimate for rare events. | Severe, rare events can look Medium and slip below attention. | List every risk with Severe impact in the quarterly report, whatever its band, so it is seen. |
Money thresholds age. | A fixed amount means less as the organisation grows. | The thresholds are reviewed with this methodology every year. |
Evidence of controls ages. | A control shown to work last year may not work now. | Residual scores are checked at the quarterly review; a failed control is a trigger (RM-10). |
Calibration and review
Calibration between assessors
- Before first use, and every year after, two assessors score the same [[5]] risks independently: inherent and residual, with reasons.
- Compare. A difference of one level on one rating is normal; discuss it and agree. A difference that changes the band or the position shows an anchor that needs clearer wording or a better example.
- Change the anchor or add an example in this document, not in the assessors' heads, and record the change below.
- Run the test cases below on any spreadsheet or tool that applies the method, including the register. Each must give the expected band and position.
Calibration test cases
Case | Impact | Likelihood | Score | Band | Category level | Position | What it tests |
|---|---|---|---|---|---|---|---|
1 | 1 | 3 | 3 | Low | Cautious | Within appetite | Minor impact, likely: still Low |
2 | 2 | 2 | 4 | Medium | Averse | Outside appetite, within tolerance | Medium is above an Averse appetite, not above its tolerance |
3 | 2 | 4 | 8 | High | Averse | Outside tolerance | The same impact, almost certain: past an Averse tolerance |
4 | 4 | 1 | 4 | Medium | Cautious | Within appetite | Severe but unlikely: Medium, within appetite |
5 | 3 | 3 | 9 | High | Cautious | Outside appetite, within tolerance | Major and likely: High, above a Cautious appetite |
6 | 2 | 3 | 6 | Medium | Averse | Outside appetite, within tolerance | Six is Medium: outside an Averse appetite, within its tolerance |
7 | 4 | 2 | 8 | High | Open | Within appetite | High is within an Open appetite |
8 | 3 | 4 | 12 | Critical | Open | Outside tolerance | Critical is past every tolerance |
Every quarter
Head of Information Security checks the following alongside the quarterly report (RM-12) and records the result. The signals are prompts to investigate, not targets.
Check | Signal that the method needs attention |
|---|---|
Re-derivation test | Any register entry whose band or position cannot be reproduced from its ratings. |
Distribution of residual bands | More than [[a quarter]] of risks High or Critical, or none above Low: the anchors are probably miscalibrated. |
Disputed ratings | The same kind of dispute recurring, or more than [[1 in 10]] ratings challenged. |
Incidents | An incident on a scenario rated Low likelihood, or with a larger consequence than its impact rating. |
Headline measures | Any of RMM-01, RMM-02, RMM-03, RMM-04 off target for two quarters running. |
Review
This methodology is reviewed at least every 12 months, and also when the enterprise risk scale or appetite statement changes, after a major incident, when the quarterly checks show the same signal twice, or when a regulator's expectations change. The review is approved by executive management; a change to appetite or tolerance goes to the board.
Calibration record
Date | Assessors | Risks scored | Band or position differences | Change made | Approved by |
|---|---|---|---|---|---|
[[YYYY-MM-DD]] | [[Names]] | [[n]] | [[n]] | [[None / description]] | [[Name]] |
Related documents
Document | Relationship |
|---|---|
Risk Identification & Assessment Operating Procedure | The steps in which risks are identified, assessed with this method, recorded, reviewed and reassessed |
Cyber Risk Appetite Statement Template | Sets each category's appetite and tolerance, which RM-05 compares against |
Information Security Risk Register | Records every risk's scenario, owner, ratings, band, position and treatment (RM-11) |
Risk Assessment Workbook | Applies this method to one assessment, step by step |
Risk Treatment Plan | Records treatment actions with owner, date, cost and expected score (RM-07) |
Risk Acceptance Form & Approval Record | Records acceptances at the level RM-08 requires |
Cyber Risk Scenario Library | Scenarios already written to RM-01 |
Risk Reporting Dashboard | Reports the four headline measures (RM-12) |
Exception Risk Scoring & Expiry Model | The same scale and bands, applied to security exceptions |
Board Reporting Narrative Model | The board position rule and BM-01, which RMM-01 feeds |
Adapting this template
Guidance — delete before approval
Small organisation: keep the four levels, the matrix, the bands and the position rule; they are what an auditor tests. Name real people: in a firm of [[20]], the Head of Information Security role may be the IT manager or an external adviser, and executive management may be the owners or partners. Keep the register to the [[10]] to [[15]] risks that matter and calibrate once a year with an outside reviewer if there is no second assessor.
Regulated entity (NIS2, DORA): approve this methodology as part of your ICT risk management framework (DORA Article 6(1); NIS2 Article 21(1) and 21(2)(a) — policies on risk analysis). Delegated Regulation (EU) 2024/1774 Article 3 expects the risk management policy to show that the management body approved the risk tolerance (3(a)) and to set out the assessment methodology with indicators of impact and likelihood (3(b)); this document and the Cyber Risk Appetite Statement Template provide both. Consider rating any risk to a critical or important function, or to an essential or important service, at impact 3 or above.
Personal data: where a scenario involves personal data, rate impact on the worse of the harm to the organisation and the harm to the people (see 'Impact'), and record that the controls chosen are appropriate to that risk (GDPR Article 32(1)).
IT run by a service provider: the provider supplies threat, vulnerability and control evidence and may help assess, but the owner and the Head of Information Security role stay in your organisation. Ask the provider to report its own risks that affect your services on this scale, so they can enter your register without rescoring.
If your organisation already has a risk matrix, keep one: map this method onto it or replace it, and record which.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); Delegated Regulation (EU) 2024/1774; Regulation (EU) 2016/679 (GDPR).
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Clause 6.1.2 — Information security risk assessment | The rules; scales and criteria; calculation; calibration and review |
ISO/IEC 27001:2022 | Clause 6.1.3 — Information security risk treatment | Treatment; who may accept (RM-04, RM-06 to RM-08) |
ISO/IEC 27001:2022 | Annex A 5.7 — Threat intelligence | Inputs: threat information used to rate likelihood |
NIST CSF 2.0 | GV.RM-06 — “A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated” | Whole methodology: a standard way to calculate, document, categorise and prioritise risk |
NIST CSF 2.0 | ID.RA-04 — “Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded” | Scales and criteria: impact and likelihood recorded for each scenario |
NIST CSF 2.0 | ID.RA-05 — “Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization” | Inherent and residual scores; position against appetite |
NIS2 — Directive (EU) 2022/2555 | Article 21(1) — appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems | Whole methodology: measures proportionate to the risk |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(a) — “policies on risk analysis and information system security” | Whole methodology, as a policy on risk analysis |
DORA — Regulation (EU) 2022/2554 | Article 6(1) — a sound, comprehensive and well-documented ICT risk management framework as part of the overall risk management system | Whole methodology, within the ICT risk management framework |
DORA — Delegated Regulation (EU) 2024/1774 | Article 3(a) — an indication of the approval of the risk tolerance level for ICT risk | Appetite, tolerance and position; acceptance outside tolerance |
DORA — Delegated Regulation (EU) 2024/1774 | Article 3(b) — a procedure and methodology for ICT risk assessment, with indicators to measure impact and likelihood | Scales and criteria; calculation |
GDPR — Regulation (EU) 2016/679 | Article 32(1) — appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the likelihood and severity of risk to people's rights and freedoms | Impact: the worse of the harm to the organisation and to the people, where personal data is involved |
Definitions
Term | Meaning in this methodology |
|---|---|
Appetite | The highest residual band a category of risk may have without escalation. |
Band | One of four ranges of score — Low (1–3), Medium (4–6), High (8–9), Critical (12–16) — that sets who must know and who may accept. |
Category | A group of risks sharing one appetite level, for example service availability. |
Existing control | A measure in place now, with evidence that it works. Planned measures are treatment actions. |
Expected score | The residual score a treatment action should give when it is done (RM-07). |
Impact | The worst credible consequence if the scenario happens, rated 1 to 4 on the worst of the five impact areas. |
Inherent score | Impact × likelihood without the specific controls for the scenario. |
Likelihood | The chance of the scenario happening in the next 12 months, rated 1 to 4. |
Position | Where a risk sits against its category's appetite and tolerance: Within appetite; Outside appetite, within tolerance; or Outside tolerance. |
Residual score | Impact × likelihood with the existing controls. |
Risk owner | The one executive accountable for the service or asset the risk would hurt (RM-02). |
Scenario | A risk written as a threat, the weakness it uses, the asset or service affected and the consequence (RM-01). |
Tolerance | The highest residual band a category may have while a plan brings it back within appetite. Critical is never within tolerance. |
Top risks | The risks reported to the board, whose position gives the organisation's position (BM-01). |
Treatment | Reduce, avoid, transfer or accept. |
Trigger | An event that forces reassessment before the scheduled one (RM-10). |