Risk Register Template: The Nine Columns That Survive Audit
A risk register template is the one document every framework asks for and none of them define. NIS-2 Article 21(2)(a), ISO 27001 clauses 6.1.2 and 8.2, ISO 42001’s own risk process — all point to the same underlying register. None of them tell you what columns it needs. That gap gets filled by whatever spreadsheet a consultant last reused, which is how so many risk registers end up with forty columns nobody updates and no column an auditor can actually use.
This is a risk register template built the other way: from what an auditor samples backward to what a column has to record to survive that sampling. Nine columns, not forty. A worked example with real rows, not placeholder text. And the one design decision — asset-based or scenario-based — that matters more than any column you choose.
What a risk register actually has to prove
A risk register is not a list of things that could go wrong. It’s evidence of a chain: something was identified, it was assessed against stated criteria, a decision was made about it, and — if treated — the treatment reduced the risk to a level someone with authority accepted. Break that chain anywhere and the register stops being evidence and becomes a list.
ISO 27001 makes the chain explicit across three clauses: 6.1.2 requires the assessment process and its criteria, 8.2 requires the results — the register itself — and 8.3 requires the treatment plan that follows from it. NIS-2 Article 21(2)(a) asks for risk analysis and information system security policies as the first of the ten measures, and Commission Implementing Regulation (EU) 2024/2690 expects the same underlying discipline for the entities it covers directly. Neither standard specifies columns. Both expect you to be able to show, for any risk, why it’s scored the way it is and what happened to it since.
Qualitative, quantitative, or somewhere between
Most risk registers use qualitative scoring — the 1–5 scales in the section above — because it’s fast to apply consistently across a wide range of risk types with limited data. It has a real weakness: a residual risk of 6 doesn’t tell a board member how much money is at stake, which is increasingly what NIS-2 enforcement and cyber-insurance underwriters both want to see.
Quantitative methods — Factor Analysis of Information Risk (FAIR) is the most established — express risk as a monetary range: this scenario has an estimated annual loss exposure of €80,000 to €420,000. They demand more data than most organisations have on day one: loss event frequency, historical incident costs, asset valuations. Building a quantitative model from scratch delays the register by months for a benefit that mainly matters once the qualitative register already works.
The practical path for most organisations is qualitative first, with a small number of highest-residual-risk rows converted to a rough quantitative estimate once the register has been running long enough to have real data behind it — a hybrid that satisfies both the auditor asking for a defensible methodology and the board asking what a risk actually costs.
A risk register template needs a stated methodology before it needs columns
Clause 6.1.2 requires the risk assessment process itself to be documented — criteria for likelihood, criteria for impact, criteria for risk acceptance, and who owns the acceptance decision — separately from the register that records the results. A register full of numbers with no methodology document behind it invites exactly the question that sinks most first-time audits: “how did you get from a 3 and a 4 to a 12, and who decided 12 was too high to accept?” If the answer isn’t written down before the audit, it gets improvised during it, and improvised answers rarely land the same way twice when two different auditors sample the same row.
The nine columns a risk register template actually needs
Registers with thirty or forty columns usually have nine that get read and twenty-one that get filled in once and never touched again. Here are the nine.
| # | Column | What it proves |
|---|---|---|
| 1 | Risk ID | Traceability — this exact risk, referenced from the SoA, from an incident report, from a management review minute |
| 2 | Description | What could happen, to what, with what consequence — not a threat name alone |
| 3 | Asset / process affected | Links the risk to something in your asset inventory, not a vague business area |
| 4 | Likelihood | Scored against a stated scale, not a gut feeling with a number attached |
| 5 | Impact | Same — scored against criteria that existed before the risk did |
| 6 | Inherent risk (likelihood × impact) | The risk before any control is credited |
| 7 | Existing controls | What’s already in place, mapped to Annex A or Article 21 measures where relevant |
| 8 | Residual risk | The risk after controls are credited — the number that actually drives the decision |
| 9 | Owner, treatment decision, target date, status | Who is accountable, what’s being done, by when, and where it stands now |
Everything else — a risk category taxonomy, a heat-map colour, a cross-reference to a business unit code — is optional structure that helps you organise the register. None of it is what an auditor asks for first. What they ask for first is: pick a residual risk score, show me the inherent score behind it, and show me the control that closed the gap.
Likelihood and impact: the scale has to exist before the score does
The single most common finding in a risk register review is a set of numbers with no stated scale behind them. A 4 for likelihood means nothing until someone can point to what a 4 represents versus a 3.
A workable 1–5 scale states, in one line per level, what evidence puts a risk at that level — not adjectives alone. “Likelihood 4: has occurred in the organisation or a comparable peer within the last 12 months” is testable. “Likelihood 4: likely” is not, because two people will disagree about what likely means and neither is wrong.
The same discipline applies to impact, and impact should be scored across more than one dimension where the frameworks require it — confidentiality, integrity and availability separately for ISO 27001, plus the operational and reputational impact NIS-2 assessors expect for essential and important entities. Score the worst applicable dimension, and record which dimension drove the score; an auditor who asks “why is this a 5” needs an answer more specific than “it felt serious.”
Asset-based versus scenario-based — the decision that matters more than any column
Before the columns, one structural choice shapes everything else: do rows represent assets (asset X faces risks A, B, C) or scenarios (scenario A affects assets X, Y, Z)?
Asset-based registers are easier to build from an existing asset inventory and map cleanly to control 5.9. They tend to undercount risks that cross multiple assets at once — a supply chain compromise, a coordinated phishing campaign — because no single asset row captures the scenario.
Scenario-based registers start from what could actually happen and trace it across whatever it touches. They capture cross-cutting risks naturally and map more directly to how NIS-2’s significant-incident test in Article 23(3) actually thinks about events. They’re harder to build from scratch because there’s no existing list to start from — you have to generate scenarios, usually through workshops or threat intelligence, rather than walk down an inventory.
Neither is wrong, and the frameworks don’t mandate one. What breaks in an audit is inconsistency — half the register asset rows, half scenario rows, with no way to tell which convention applies where. Pick one as your primary structure, and if you need the other view, build it as a second sheet derived from the same underlying rows rather than mixing the two inside one column set.
The four treatment options, and why “mitigate” isn’t the only honest answer
Column 9’s treatment decision has exactly four legitimate values, and a register where every row says “mitigate” is as suspicious as one where every row says “accept.”
Mitigate — reduce likelihood or impact through a control. The default instinct, and often right, but not automatically the cheapest or most effective option for every risk.
Transfer — shift the financial consequence, typically through cyber insurance or a contractual indemnity from a supplier. Doesn’t reduce the risk of the event; reduces the organisation’s exposure to its cost. Increasingly relevant as NIS-2 penalties and breach-related liability both grow.
Avoid — stop doing the thing that creates the risk. Decommission the legacy system, drop the feature, exit the market. Rare in practice because it usually has a larger business cost than the risk being avoided, but real, and an auditor who never sees it on a register may reasonably ask whether it was genuinely considered.
Accept — do nothing further, because the residual risk sits within stated appetite. The most misused of the four when it’s used as a synonym for “haven’t gotten to it yet” rather than a documented decision by someone with the authority to make it.
A register worth auditing shows a mix across these four, with the reasoning for each visible — not necessarily in the register itself, but traceable to a decision record it can point to.
A worked example
Six representative rows from a mid-size SaaS company’s register, asset-based, showing the full chain from inherent to residual risk.
| Risk ID | Description | Asset | Likelihood | Impact | Inherent | Existing controls | Residual | Owner / status |
|---|---|---|---|---|---|---|---|---|
| R-014 | Ransomware encrypts production database via compromised admin credentials | Production DB cluster | 3 | 5 | 15 | MFA on admin accounts, offline backups, EDR | 6 | IT Manager — treated, closed |
| R-021 | Departed employee retains access due to delayed offboarding | Identity provider | 4 | 3 | 12 | Automated deprovisioning (partial coverage) | 8 | HR/IT joint — treatment in progress, target Q4 |
| R-033 | Critical SaaS subprocessor suffers a breach affecting customer data | Third-party payment processor | 2 | 5 | 10 | Contractual security clauses, annual review | 6 | Procurement — accepted at residual level |
| R-041 | Unpatched internet-facing service exploited before patch window | Public API gateway | 3 | 4 | 12 | Patch SLA 14 days, WAF | 6 | Platform team — treated, monitored |
| R-052 | Insider misuses privileged access for data exfiltration | Customer database | 2 | 5 | 10 | Access logging, least privilege, DLP | 6 | CISO — accepted, reviewed annually |
| R-058 | Phishing leads to business email compromise and fraudulent payment | Finance email accounts | 4 | 4 | 16 | Security awareness training, no MFA on finance mailbox | 12 | Finance/IT — treatment open, target next month |
Notice that R-058 is the only row still above the organisation’s stated risk appetite (assume a threshold of 9). That’s what a register is for: not zero risk everywhere, but a visible, current list of exactly which risks sit where relative to what the organisation has said it will tolerate — and, for the ones that don’t, who is doing what about it and by when.
The same risk, written scenario-based
For comparison, here’s R-058 from the table above rewritten as a scenario-based row instead of asset-based — the structural choice covered earlier made concrete on one example.
| Field | Asset-based version | Scenario-based version |
|---|---|---|
| Row subject | Finance email accounts | ”Business email compromise leading to fraudulent payment” |
| Assets affected | Finance email accounts (single row) | Finance email, vendor payment system, banking portal (one row, three assets listed) |
| Description | Tied to the asset; consequence follows from what that asset does | Tied to the attack path; naturally captures assets a pure asset inventory walk would miss |
| Scoring basis | Likelihood/impact scored against the mailbox in isolation | Likelihood/impact scored against the full chain from phishing to fraudulent transfer |
Neither table is more correct. The scenario-based version is the one that would have caught a risk spanning three unrelated asset rows in the asset-based structure — which is the exact gap that structural choice creates, and why some organisations run a small number of scenario-based rows alongside a primarily asset-based register rather than choosing one exclusively.
Where NIS-2 asks for more than a generic register
Commission Implementing Regulation (EU) 2024/2690, which sets binding detail for digital infrastructure and digital service providers in scope for NIS-2, expects the risk analysis behind Article 21(2)(a) to feed directly into the other nine measures rather than sit as a standalone exercise. In practice this means two things a purely ISO 27001-driven register sometimes misses: an explicit link from each risk to which of the ten Article 21(2) measures its treatment falls under, and visibility of risks tied to the security of network and information systems specifically, not just information assets generally — the distinction matters for essential entities whose core service depends on operational technology alongside IT. A domain column that tags each row against the relevant Article 21 measure, alongside any ISO 27001 Annex A control, closes this gap without a second register.
Linking the register to the Statement of Applicability
A risk register that doesn’t connect to the Statement of Applicability is the single most common gap auditors find, because the two documents are supposed to tell one continuous story: risk drives treatment, treatment drives control selection, the SoA records the selection.
The practical fix is a column — often skipped — that lists which Annex A controls or NIS-2 measures a given risk’s treatment maps to. R-014 above should show a line back to controls 8.24 (cryptography), 8.13 (backup) and 5.15 (access control); an auditor tracing that control in the SoA back to the risk register should find R-014 waiting for them. If the trace breaks in either direction — a control with no risk behind it, or a risk with no control closing it — that’s the finding.
Keeping a multi-framework register from becoming three registers
Organisations pursuing NIS-2 and ISO 27001 together, or adding ISO 42001 for AI systems, often end up maintaining separate risk registers per framework — which triples the maintenance burden and guarantees the three drift apart within a year.
The workable alternative is one register with a domain column: NIS-2, ISO 27001, ISO 42001, or a combination, next to each risk. A ransomware risk against the production database is relevant to both NIS-2 Article 21(2)(a) and ISO 27001 6.1.2 — one row, two domain tags, not two rows in two files that inevitably get scored differently by two different people. An AI-specific risk — a training data poisoning scenario, a model performance degradation risk — gets a domain tag of its own without needing a parallel structure.
This isn’t a stylistic preference. It’s the same principle behind treating a single risk register as one of the core documents shared across every compliance suite rather than duplicated per framework: the register is the same underlying activity regardless of which regulation is asking about it, and duplicating it multiplies the chance the copies disagree.
Where ISO 42001 adds risk categories the other two frameworks don’t ask about
Organisations building or deploying AI systems and pursuing ISO 42001 alongside NIS-2 or ISO 27001 need the same register to hold risk types the security frameworks don’t anticipate: a model’s performance degrading below an acceptable threshold in production, training data quality issues that bias outputs, a system’s classification under the EU AI Act changing because of how it’s actually used rather than how it was designed. These aren’t security risks in the ISO 27001 sense, and forcing them into a likelihood/impact scale built for confidentiality-integrity-availability breaks down — a biased hiring model doesn’t have a “confidentiality impact,” but it has a very real one.
The practical accommodation is an impact dimension specific to the AI domain tag — regulatory/fairness impact alongside the security dimensions — scored on the same 1–5 scale so residual risk numbers stay comparable across the whole register, even though what drives a high score differs by domain. The ISO 42001 AI impact assessment covers where that assessment starts and where the general risk register takes over; the short version is that AI-specific impact assessment feeds into the same register as everything else, tagged rather than isolated.
Review cadence: what “kept current” actually means
ISO 27001 doesn’t state a frequency for reviewing the risk register, and NIS-2 doesn’t either — which is exactly the ambiguity that produces a register updated once a year, right before the audit, and stale for the other eleven months.
A workable cadence has three triggers, not one calendar date:
- Scheduled review — at minimum annually, ideally tied to the management review cycle so risk register outputs are a documented input to it
- Event-triggered review — after any significant incident, new system, new supplier, or organisational change that plausibly creates or alters a risk
- Treatment-triggered review — whenever a treatment action closes, the residual risk score is re-assessed, not assumed
An auditor who finds a register with a single “last reviewed” date and no evidence of review between incidents has found the same underlying problem the ISO 27001 internal audit article covers from the audit-programme side: a document that looks current because nobody checked whether it actually is.
What fails a review, beyond missing columns
- Risk descriptions that are just threat names. “Ransomware” is not a risk description; it names a threat with no asset, no scenario and no consequence attached. “Ransomware encrypts the production database via a compromised admin account, halting order processing” is a risk.
- Inherent risk scored after controls were already in mind. If the person scoring likelihood already knows about the MFA that’s in place, the inherent score quietly becomes a residual score wearing the wrong label, and the register loses the ability to show what the controls actually achieved.
- Residual risk that never changes when a treatment closes. A treatment plan with a “closed” status next to a residual score identical to six months ago tells the auditor nobody went back and re-scored.
- No stated risk appetite or acceptance threshold. Without one, “accepted” is not a decision — it’s an absence of one, and there’s no way to tell whether an accepted risk was actually authorised by someone with the standing to accept it.
- Owners who are teams, not people. “IT” is not accountable for anything; a named person, even if the role rotates, is what makes the owner column mean something in a sampling interview.
FAQ
Does ISO 27001 require a specific risk register format? No. Clause 8.2 requires the results of risk assessments to be retained as documented information; it doesn’t mandate columns or software. What auditors check is whether the results are traceable back to the methodology in 6.1.2 and forward to the treatment in 8.3, not the spreadsheet layout.
How many risks should a risk register have? There’s no target number, and a very large register is often a sign the entries were generated per-control rather than per-actual-risk. A mid-size organisation’s first register commonly lands between 30 and 80 meaningful entries; growth from there should track new systems and threats, not a quota.
Should the risk register include third-party and supply chain risks? Yes — NIS-2 Article 21(2)(d) requires supply chain security explicitly, and ISO 27001’s supplier controls (5.19–5.22) expect the same visibility. These can live in the same register with an asset value of “supplier: [name]” rather than a separate supplier risk register that inevitably falls out of sync.
What’s the difference between a risk register and a risk treatment plan? The register records identification, assessment and current status. The treatment plan — often a filtered view of the same rows, sometimes a separate document — details the specific actions, resources, and timeline for risks above the acceptance threshold. Clause 6.1.3 and 8.3 treat them as related but distinct outputs.
Who should own the risk register? One named person accountable for the register’s currency — typically the ISMS manager or CISO — even though individual risk rows have their own owners. Without a single accountable owner for the document itself, review cadence and consistency both degrade first.
Can a spreadsheet really satisfy this, or do we need dedicated software? A spreadsheet is entirely sufficient for the standard’s requirements at small-to-mid scale; nothing in ISO 27001 or NIS-2 requires GRC software. The practical limit is usually collaborative access and version control once more than a handful of people update it — at that point a tool becomes a convenience, not a compliance requirement.
Should inherent and residual risk use the same 1–5 scale? Yes — using the same scale for both is what makes the gap between them meaningful. Switching scales partway (a 1–5 inherent score against a High/Medium/Low residual rating, for instance) makes it impossible to show the actual reduction a control achieved, which is the entire point of tracking both.
How is a risk register different from an incident log? The register is forward-looking — risks that haven’t necessarily happened, scored and treated in advance. The incident log is a record of what did happen. They connect in one direction: a realised incident should prompt a review of the risk register entry that predicted it, or the creation of a new one if nothing did.
The register earns its place in an audit the same way every other record does: not by existing, but by being traceable — from what could happen, to how it was scored, to what was done about it, to who is accountable now. Nine columns get you there. The other thirty-one are usually decoration.