Information Security Risk Management Pack — Guide
- Version 1.3
- Updated
- 9 documents
- Word, Excel
Information Security Risk Management Pack
Most risk registers are a list of vague worries such as “cyber attack”, owned by IT and scored once in a workshop. Nothing is decided, so nothing changes before the next audit. This pack helps you run a process that produces decisions: who owns each risk, whether it is acceptable, and what happens next.
Is this for you?
This pack is for you if:
- you have a risk register, but nobody outside security reads it;
- you cannot say which of your risks the business has agreed to carry;
- an auditor asked how you treat risk, and you had only a spreadsheet.
How the method works
Every risk is scored before and after existing controls:
| Step | What it means |
|---|---|
| Impact, 1 to 4 | Minor to Severe, on the worst consequence: money, service, data, legal or reputation. |
| Likelihood, 1 to 4 | Unlikely to Almost certain, over the next 12 months. |
| Score and band | Impact × likelihood: Low 1–3, Medium 4–6, High 8–9, Critical 12–16. The band after controls sets who may accept. |
| Severe impact | A Severe impact is also judged by its chance. At 5% a year or more, executive management must accept it. At Possible or above, only the board or its equivalent may, whatever the score (RM-13). |
| Appetite | The highest band you accept without escalating. |
| Tolerance | The highest band you will carry while a plan brings it back. Never Critical. |
A risk above appetite needs a decision; only the board or its equivalent may accept one above tolerance. 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. The exceptions pack uses the same four level names and bands, but measures likelihood by how exposed one gap is, not by the chance of a loss. An exception is a time-limited approval not to meet a specific rule. Accepting a risk is a different decision, recorded on a different form, and the same gap cannot move from one record to the other to avoid ageing.
Where small programmes go wrong
- Risks owned by IT. The owner is the executive whose service would be hurt (RM-02).
- Vague risks. Write each as a scenario: threat, weakness, what it affects, consequence (RM-01).
- No appetite. Nobody can say whether a High risk is acceptable (RM-05).
- Scores nobody can defend. Use the defined scales and record why (RM-03).
- Acceptance by default. Decide each risk outside appetite within 30 days; record acceptances at the right level (RM-06, RM-08). A Severe impact at 5% a year or more needs more than the score says (RM-13).
- No review. Owners review quarterly; a major incident or change forces reassessment within 10 working days (RM-09, RM-10).
Start with these three
- Risk Assessment Methodology & Scoring Model — the scales and the thirteen rules every other document follows.
- Cyber Risk Appetite Statement Template — appetite and tolerance for each risk category, each with a measurable limit.
- Information Security Risk Register — the single record of every assessed risk.
Your first month
| When | What to do | You’re done when |
|---|---|---|
| Week 1 | Draft the Methodology’s money thresholds, name who accepts each band, and set the Severe-impact rule (RM-13). | A draft that management can read. |
| Week 2 | Draft an appetite level and one measurable limit for each risk category, with the category owners. | Each owner has agreed their line. |
| Week 3 | Executive management approves the Methodology and the draft appetite for interim use. Score your top risks with their owners, using the scenario library. | Management has approved; each owner agrees their scores. |
| Week 4 | Enter the risks in the register; decide each risk outside appetite. Put the appetite statement on the agenda of the board’s next meeting. | Each has a decision: reduce, avoid, transfer or accept. The board, or its equivalent as set out above, approves the statement at that meeting, which may fall after the month ends. In a DORA financial entity the management body sets the tolerance for ICT risk (Article 5(2)(d)). |
Four numbers to report
Report these to executive management quarterly.
| Number | Target |
|---|---|
| Risks outside appetite, and of those, past tolerance | Zero past tolerance; each outside appetite with a treatment decision |
| Treatment actions overdue | None older than 30 days |
| Acceptances past their review date | Zero |
| Risks not reviewed by their owner this quarter | Zero |
The first is the same figure a board report opens with, so register and board paper agree.
Everything in the pack
- Word
Risk Assessment Methodology & Scoring Model
The rules management approves; in a DORA entity, the management body
- Word
Risk Identification & Assessment Operating Procedure
How risks are found, assessed and reviewed
- Word
Cyber Risk Appetite Statement Template
How much risk you accept, by category
- Excel
Information Security Risk Register
Every risk, its owner, score and position
- Excel
Risk Assessment Workbook
One assessment, from scenario to score
- Excel
Risk Treatment Plan
Who does what, by when, at what cost
- Word
Risk Acceptance Form & Approval Record
Who accepted which risk, why, and until when
- Excel
Cyber Risk Scenario Library
Ready-written scenarios to start from
- Excel
Risk Reporting Dashboard
The four numbers, quarter by quarter
No document matches those words.
Adapting it
- Small organisation: start with a dozen top risks. One person may run every assessment, but executives still own the risks.
- Regulated entity (NIS2, DORA): NIS2 Article 21(1) expects proportionate measures, and 21(2)(a) a risk analysis policy. DORA Article 6(1) requires a documented framework; Article 8, yearly scenario reviews and an assessment on each major change. Delegated Regulation (EU) 2024/1774, Article 3, adds an approved tolerance, a methodology, and a list of accepted residual risks reviewed at least yearly. For personal data, GDPR Article 32 asks for security appropriate to the risk to the people concerned, so score that harm too.
- IT run by an outside provider: the provider can assess risks and deliver actions, but ownership stays with your executives, and acceptance follows the band (RM-08, RM-13). Its own failure belongs in your register.
Where it maps
- ISO/IEC 27001:2022 — Clauses 6.1.1, 6.1.2 and 6.1.3.
- NIST CSF 2.0 — GV.RM-01, GV.RM-02 and ID.RA-05.
- NIS2 — Article 21(1) and 21(2)(a).
- DORA — Articles 6(1) and 8; Delegated Regulation (EU) 2024/1774, Article 3.
- GDPR — Article 32.