Who should read this: anyone at a company under three hundred people who maintains a spreadsheet called Risk Register, and who has been told it will need to hold up in front of an auditor or a regulator.
Almost every company we assess has a risk register. Almost none of them have one that does the job. The file exists, it has rows, somebody updated it before the last audit. What it usually lacks is the part that makes it a decision record rather than a list of worries, and that is the part an examiner reads first.
What the rules actually require
Two texts matter here and they say close to the same thing.
ISO 27001 Clause 6.1.2 requires an information security risk assessment process that produces consistent, valid and comparable results, and Clause 6.1.3 requires a risk treatment process that ends in a documented risk treatment plan with the approval of risk owners.
On the NIS2 side, Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 sets out the detail for digital infrastructure, ICT service management and digital providers, and ENISA published its Technical Implementation Guidance on 26 June 2025 explaining what evidence satisfies it. Section 2.1.1 requires a documented risk management framework. Section 2.1.2 requires the process to document the chosen treatment measures in a risk treatment plan, and to record the reasons for accepting residual risk in a comprehensible manner.
That last phrase is where most registers fall over, and we will come back to it.
The seven fields, and the three you have
ENISA sets out what a risk treatment entry should carry. In plain language:
- A description of the risk, and which security objective it threatens.
- The treatment option chosen: avoid, mitigate, transfer or accept.
- The assets the risk attaches to.
- The mitigating measures.
- How the effectiveness of those measures will be assessed.
- Implementation timelines.
- The role responsible.
Now open your own register. In most SME files, fields one, two and four are present. Sometimes six. Fields three, five and seven are usually missing, and field five is missing almost universally.
The consequence is not a paperwork finding. A register without assets cannot be reconciled against your Statement of Applicability, so the auditor cannot check that the controls you declared applicable are the ones actually treating your risks. A register without a named role means no risk has an owner, which contradicts the approval requirement in Clause 6.1.3. A register without an effectiveness test means you have written down an intention, not a control.
The scoring theatre problem
The most common register we see is a table of 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.
There is nothing wrong with a five by five matrix. What is wrong is that in nine cases out of ten there is no accompanying statement of what the numbers mean. What separates a likelihood of two from a likelihood of three? What is the impact threshold in euros, in hours of downtime, in records exposed? Without that, two people scoring the same risk produce different numbers, which means the process does not produce the consistent and comparable results the standard asks for.
The fix is a single page, written once, that defines each scale point and the criteria for risk acceptance. It takes an afternoon. It converts a subjective table into a repeatable method, and it is the first thing a competent auditor asks to see after looking at the register itself.
Residual risk, in a comprehensible manner
Here is the requirement that fails most often, and it is worth quoting the intent precisely: the reasons justifying the acceptance of residual risks must be recorded so that a reader can understand them.
In practice, registers handle residual risk in one of three ways. Some ignore it entirely and stop at the treatment. Some record a lower score after treatment with no explanation of why it is lower. Some write “risk accepted by management” with no name and no reasoning.
None of those survive scrutiny. What does survive reads like a decision: this risk remains at this level after these measures, we accept it because the cost of further mitigation exceeds the exposure, this named person accepted it on this date, and we will review it at this point. That is four extra sentences per accepted risk, and it converts the weakest part of the register into the part that demonstrates governance is real.
It is also the natural connection to the management review, where accepted risks are supposed to be revisited rather than quietly inherited.
The register that is actually a control list
A second failure mode is subtler. The register describes controls instead of risks. Rows read “no multi-factor authentication”, “backups not tested”, “no asset inventory”.
Those are gaps, not risks. A gap list is useful, and any honest assessment produces one, but it is a different artefact. A risk is a scenario with a cause and a consequence: an attacker reuses a credential exposed in a third-party breach and reaches the finance mailbox, because access to that mailbox does not require a second factor, and the consequence is payment redirection. The missing factor is the cause. The scenario is the risk.
This matters because treatment decisions differ. You cannot accept “no MFA” as a risk, it makes no sense as a sentence. You can accept a scenario at a stated likelihood and impact, and you can explain why. It also matters for coverage: ten controls might address one scenario, and one control might address six. A register built from controls cannot show you either relationship. The 93 Annex A controls grouped for real work are the treatment vocabulary, not the risk vocabulary.
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 last modified in the same week, three weeks before the audit, tells a complete story on its own. So does a register where the review date on forty rows is identical. So does one where no risk has ever 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, a handful of rows revised after an incident or a new supplier. That texture is not something you can manufacture the week before, which is exactly why it is trusted. The same logic runs through evidence that assembles itself: timing is the part of evidence that cannot be back-filled.
How many rows
Fewer than you think. We regularly see registers of one hundred and twenty rows in companies of forty people, and they are always the ones nobody reads.
A company of 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, a misconfigured cloud bucket, an unpatched internet-facing service, payment fraud by impersonation, device loss, data exposure through a test environment. The list is not long because the business is not complicated.
A short register that is reviewed quarterly beats a long one that is reviewed annually, every time. The point of the ten NIS2 measures in Article 21 is that they are proportionate to your exposure, and a register is the instrument that shows what your exposure actually is. The broader map of how the obligations fit together is in the NIS2 compliance guide.
What to do this month
Do not rewrite the register. Do four things to the one you have.
Write the one-page scale and acceptance criteria. Add an owner role to every row. Add an effectiveness test to every treatment, even if the test is “the quarterly access review shows no orphaned accounts”. Write four real sentences for every accepted risk.
That is a day of work and it addresses the three fields most likely to be missing plus the requirement most likely to be failed.
The technical reality: a register records decisions, it does not detect anything
Here is the part that is easy to lose. Everything above makes the register defensible. None of it makes the company safer.
A risk register is a record of decisions taken at a point in time about conditions assumed to be true. It says you decided that internet-facing services would be patched within thirty days. It does not tell you that one of them is currently ninety days behind, that a supplier’s access was never revoked when the contract ended, or that the backup which the register says is tested quarterly last restored successfully in March.
That is the gap between a register and a security posture, and it is where a well-run compliance exercise still leaves you exposed. Closing it means the conditions the register assumes are checked continuously rather than asserted annually: the asset list populated from what is actually running, patch state and exposure measured rather than declared, supplier access reconciled against contracts, backup restores verified rather than scheduled. When that runs, the register stops being a document you defend and becomes a description of a state you can see, which is also the point at which certification stops being the same thing as security.
If you want that measured rather than estimated, an independent security audit produces the scenario list and the current state together, and the CloudSoul platform keeps both current afterwards rather than in the month before the audit.
