ISO 27001 does not prescribe a risk register, but clauses 6.1.2, 6.1.3 and 8.2 require records that amount to one: each risk, its owner, its consequences and likelihood, its level against your criteria, the treatment chosen, and the owner’s approval of the plan and acceptance of the residual risk. Auditors test it against your own method and its dates.
This guide covers what the standard requires, the columns a register needs, a copyable template, scoring, residual risk, what auditors check, why registers fail, how NIS2 fits, and a checklist.
| Requirement | Clause | Where it shows in the register |
|---|---|---|
| Risk criteria, including acceptance criteria; consistent, comparable results | 6.1.2 a), b) | A one-page method with defined scales and an acceptance line |
| Risks to confidentiality, integrity and availability, and their owners | 6.1.2 c) | Scenario, CIA and owner columns |
| Consequences, likelihood, level, priority | 6.1.2 d), e) | Scores against the acceptance line |
| Treatment, controls checked against Annex A, Statement of Applicability | 6.1.3 a) to d) | Control references that match the SoA |
| Risk treatment plan | 6.1.3 e) | Actions, owners, due dates |
| Owner approval of the plan and of residual risk | 6.1.3 f) | Residual level, name, date, reason |
| Reassessment at planned intervals or on significant change | 8.2 | Review dates and change history |
| Implementation of the plan | 8.3 | Status and evidence |
What does ISO 27001 require for a risk register?
The requirements sit in two planning clauses and two operational ones. In paraphrase:
- Clause 6.1.2, risk assessment. Set risk criteria, including criteria for accepting risk and for performing assessments. Ensure repeated assessments give consistent, valid and comparable results. Identify risks to the confidentiality, integrity and availability of information in scope, and their owners. Assess potential consequences and realistic likelihood, and determine levels of risk. Compare them with your criteria and prioritise.
- Clause 6.1.3, risk treatment. Choose treatment options. Determine the controls needed, compare them with Annex A so nothing necessary is missed, and produce the Statement of Applicability (SoA). Write a risk treatment plan. Obtain the risk owners’ approval of the plan and their acceptance of the residual risks.
- Clause 8.2. Assess risks at planned intervals or when significant changes are proposed or occur, using the 6.1.2 criteria. Keep the results.
- Clause 8.3. Implement the treatment plan. Keep the results.
All four clauses also require documented information: records, not a format. A spreadsheet or a GRC tool both work. It does not require an asset-based method; ISO/IEC 27005:2022, the guidance standard, contrasts event-based and asset-based approaches. And the register is not self-contained. Its controls must reconcile with your scope and Statement of Applicability, and clause 9.3.2 makes risk results and treatment status an input to management review.
What should an ISO 27001 risk register contain?
The clauses set the minimum. Practice adds fields that make the register usable; the layout marks which is which.
ISO 27001 risk register template
ISO 27001 RISK REGISTER: ONE ROW PER RISK
Column What goes in it Basis
------------------ ------------------------------------------- ----------
ID R-01, R-02 and so on, never reused practice
Risk scenario Cause, event and consequence, one sentence 6.1.2 c)
CIA affected Confidentiality, integrity, availability 6.1.2 c)
Assets, services Systems, data or processes involved practice
Risk owner Role with authority to accept the risk 6.1.2 c)
Existing controls What already reduces the risk practice
Likelihood 1 to 5, from the method page 6.1.2 d)
Consequence 1 to 5, from the method page 6.1.2 d)
Risk level Likelihood x consequence 6.1.2 d)
Priority Level compared with the acceptance line 6.1.2 e)
Treatment option Mitigate, avoid, transfer or accept 6.1.3 a)
Controls Annex A references, as listed in the SoA 6.1.3 b) to d)
Actions What will be done 6.1.3 e)
Action owner, due Who, and by when 6.1.3 e)
Effectiveness test How you will know the control works practice
Residual level Likelihood x consequence after treatment 6.1.3 f)
Acceptance Owner name, date and reason 6.1.3 f)
Status, evidence Open, done or re-planned, link to proof 8.3
Last reviewed Date of the last real review or change 8.2
METHOD PAGE (EXAMPLE, ADAPT THE NUMBERS)
Score Likelihood Consequence
----- -------------------------- --------------------------------------
1 Less than once in 10 years Under €10k, no customer notices
2 Once in 3 to 10 years €10k to €50k, hours of disruption
3 Once in 1 to 3 years €50k to €250k, or a day of downtime
4 About once a year €250k to €1m, customers affected
5 Several times a year Over €1m, or a regulator involved
Acceptance line: a level of 8 or below may be accepted by the risk owner.
Above 8: treat it, or accept only with top management approval and a
written reason.
EXAMPLE ROW
ID R-07
Risk scenario A password leaked elsewhere is reused on the finance
mailbox, which has no second factor, and a supplier
payment is redirected.
CIA affected Confidentiality, integrity
Risk owner CFO
Existing controls Call-back to the supplier before bank details change
Level Likelihood 3 x consequence 4 = 12, above the line
Treatment Mitigate
Controls A.5.17, A.8.5
Actions MFA on every mailbox, block legacy sign-in
Action owner, due IT lead, 30 June 2026
Effectiveness test Monthly report: mailboxes without MFA = 0
Residual level 2 x 4 = 8
Acceptance CFO, 14 July 2026. What remains is phishing that
defeats MFA, and the call-back check still applies.
Further controls cost more than the exposure.
Review in Q1 2027 or when the bank changes.
Status, evidence Done, MFA report attached
Last reviewed 14 July 2026Copy the columns into a spreadsheet and keep the method page separate. The scales and acceptance line are examples: set your own, but write them down.
How do you score likelihood and consequence?
Any scale works if it is defined. The most common register we see has about forty rows, each with a likelihood from one to five, an impact from one to five, a product and a colour. The colours are mostly amber.
A five by five matrix is fine. What fails is that in nine cases out of ten nothing says what the numbers mean. What separates a likelihood of two from a three? What is the impact threshold in euros, hours of downtime or records exposed? Without that, two people score the same risk differently, and the process does not give the consistent and comparable results clause 6.1.2 asks for.
The fix is the method page: written once, defining each scale point and the criteria for accepting risk. It takes an afternoon, and it is the first thing a competent auditor asks to see after the register itself.
How do you record residual risk and its acceptance?
Clause 6.1.3 requires the risk owners to accept the residual risks. In our experience this is the requirement that fails most often.
Registers usually handle it one of three ways. Some stop at the treatment. Some record a lower score after treatment with no explanation. Some write “risk accepted by management” with no name and no reasoning.
None of those survive scrutiny. What survives reads like a decision. This risk remains at this level after these measures. We accept it because further mitigation costs more than the exposure. This named person accepted it on this date. We will review it then. Four sentences per accepted risk turn the weakest part of the register into the part that shows governance is real. Accepted risks should come back at management review, not be quietly inherited.
What do auditors check in an ISO 27001 risk register?
At Stage 1 the auditor reads the method, register, SoA and treatment plan. At Stage 2 they test whether the process runs, as described in Stage 1 and Stage 2 audits. In practice, expect:
- The method: scales, acceptance criteria, who may accept which level.
- Consistency: a few risks re-scored against your own definitions.
- Ownership: every risk has an owner who can explain it in interview.
- Traceability: a sampled risk followed to its controls, the SoA and evidence the controls operate.
- Approval: owners’ approval of the plan and acceptance of residual risk, with names and dates.
- Change: reassessment after significant changes such as a new system or supplier, as clause 8.2 requires, and in practice after incidents.
- Progress: actions done, or re-planned with a reason, as clause 8.3 requires.
Dates are the tell
An auditor can judge a register in about ninety seconds, and the field they use is not the scores. It is the dates.
A register where every row was modified in the same week, three weeks before the audit, tells a complete story. So does one where forty rows share a review date, or where no risk has moved, closed or been added since the file was created.
A register that has been used looks messy in a specific way: risks added at different times, some closed with a reason, treatment dates that slipped and were re-planned, rows revised after an incident or a new supplier. That texture cannot be manufactured the week before, which is exactly why it is trusted.
Why do risk registers fail an audit?
Almost every company we assess has a risk register. Almost none has one that does the job. What it lacks is the part that makes it a record of decisions rather than a list of worries.
It lists gaps, not risks
Rows read “no multi-factor authentication”, “backups not tested”, “no asset inventory”. Those are gaps. A gap list is useful, but it is a different artefact.
A risk is a scenario. ISO/IEC 27005 defines a risk scenario as a sequence or combination of events leading from the initial cause to the unwanted consequence. In the example row, the missing second factor is the cause and the redirected payment is the consequence. The scenario is the risk.
You cannot accept “no MFA”: it makes no sense as a sentence. You can accept a scenario at a stated level and explain why. Coverage depends on it too: ten controls might address one scenario, and one control might address six. The Annex A controls, grouped for real work, are the treatment vocabulary, not the risk vocabulary.
Three columns are missing
In our experience, most SME registers have the risk, the treatment and the measures. They lack what the risk touches, who owns it, and how anyone would know the treatment works. Without the first, the auditor cannot tell whether the controls in your SoA cover the systems at risk. Without an owner, nobody can approve treatment or accept residual risk. Without an effectiveness test, you have written down an intention, not a control.
It has too many rows
We regularly see 120-row registers in companies of forty people, and they are always the ones nobody reads. A company that size has perhaps fifteen to twenty-five real scenarios: credential compromise, ransomware on shared storage, a supplier with access to production, loss of a key person, payment fraud by impersonation. A short register reviewed quarterly beats a long one reviewed annually.
Does NIS2 require a risk register?
Not by that name. Article 21(2)(a) of NIS2 requires, as a minimum, “policies on risk analysis and information system security”.
For the digital providers covered by Implementing Regulation (EU) 2024/2690, point 2.1 of the annex is specific. They must perform and document risk assessments and establish, implement and monitor a risk treatment plan. They must identify who implements each measure and by when, and record the reasons for accepting residual risks “in a comprehensible manner”. Results and plan must be reviewed at planned intervals, at least annually, and after significant changes or significant incidents.
ENISA’s June 2025 technical implementation guidance is advisory. It lists seven items a treatment plan should at least include: the risk and its impact, the treatment option, the assets, the measures, how effectiveness is assessed, timelines and responsible roles. The template carries all seven, so one register can serve both. More in the ten NIS2 measures in Article 21.
The technical reality: a register records decisions, it does not detect anything
Everything above makes the register defensible. None of it makes the company safer.
A register records decisions about conditions assumed to be true. It says internet-facing services are patched within thirty days. It does not tell you that one is ninety days behind, that a supplier kept access after the contract ended, or that the “tested” backup last restored in March.
The standard leaves that open. Clause 8.3 asks you to implement the plan and keep the results; it does not say how you know the controls still run when the auditor is not there. Closing the gap means checking the register’s assumptions continuously: the asset list drawn from what is running, patch state measured rather than declared, supplier access reconciled against contracts, restores verified rather than scheduled. The effectiveness column then fills itself.
That is how the CloudSoul platform works: automated checks against your systems, with a person reviewing the exceptions. An independent security audit produces the scenario list and the current state together, and the full programme is on the ISO 27001 page.
ISO 27001 risk register checklist
Do not rewrite the register. Work through the one you have.
- Write one page defining the scales and the risk acceptance criteria.
- Rewrite gap rows as scenarios with a cause and a consequence.
- Give every risk an owner with the authority to accept it.
- Reference Annex A controls for each treatment and check they match the SoA.
- Add an effectiveness test to every treatment, even “the quarterly access review shows no orphaned accounts”.
- Record every residual risk acceptance with a name, a date and a reason.
- Reassess at planned intervals and after significant changes.
- Take results and treatment status to management review.
Sources
- ISO/IEC 27001:2022, Information security management systems: Requirements, clauses 6.1.2, 6.1.3, 8.2, 8.3 and 9.3.2, ISO.
- ISO/IEC 27005:2022, Guidance on managing information security risks, clause 3.1.4, ISO.
- Directive (EU) 2022/2555 (NIS2), Article 21(2)(a), EUR-Lex.
- Commission Implementing Regulation (EU) 2024/2690, Annex, points 2.1.1 to 2.1.4, EUR-Lex.
- ENISA, NIS2 Technical Implementation Guidance, version 1.0, June 2025, ENISA.
Frequently asked questions
What should an ISO 27001 risk register include?
Each risk, its owner, its likely consequences and likelihood, its level compared with your risk criteria, the treatment chosen, and the risk owner's approval of the treatment plan and acceptance of the residual risk. In practice, add the Annex A controls used, action dates, an effectiveness test and a review date.
Is a risk register mandatory for ISO 27001?
ISO 27001 does not prescribe a document called a risk register. It requires documented information about the risk assessment and treatment processes and their results, and a register is the usual way to keep it.
Who accepts residual risk in ISO 27001?
The risk owner. Clause 6.1.3 requires the organisation to obtain the risk owners' approval of the risk treatment plan and their acceptance of the residual information security risks.
How often must the ISO 27001 risk assessment be updated?
Clause 8.2 requires risk assessments at planned intervals or when significant changes are proposed or occur. A sensible approach is a quarterly review of the register and a full reassessment at least once a year.
What do auditors check in a risk register?
In practice: whether the scores follow your written criteria, whether every risk has an owner who approved its treatment and accepted the residual risk, whether the controls match the Statement of Applicability, and whether the dates show the register is actually used.
