A risk register is a central record of an organization’s risks together with their assessment, owners, existing controls and action plans. It should contain at least: an identifier, a risk description (event, cause and consequence), an owner, likelihood and impact, existing controls, residual risk, actions and a deadline. It is maintained as a living document: built from risk analysis, reviewed cyclically and after every significant incident, with one named person accountable for each entry.
In this article we explain what a risk register is, which fields it should contain, how to build it and how often to update it, who is accountable for entries, when Excel is enough and when it is worth moving to a GRC system. We also show a risk register example with three records. The broader context – the process, the matrix and KRIs – is covered in our guide to risk management.
What Is a Risk Register?
A risk register is an organized record of all the risks an organization has identified. The former ISO risk vocabulary (Guide 73:2009) defined it as a record of information about identified risks, and that definition is still widely used. In practice it is a table or database in which every risk has one place, one named owner and a current assessment.
The register is the output of risk analysis and, at the same time, a day-to-day working tool: priority lists, the risk matrix and board reports are produced from it. It is not a one-off document – it loses its value the moment it stops being updated.
What a Risk Register Is Not
A risk register is often confused with other documents an organization keeps:
Why Does an Organization Need a Risk Register?
A risk register gives an organization six concrete benefits:
- One source of information – instead of risks scattered across departmental spreadsheets and people’s heads.
- Priorities – it is visible which risks to address first and which exceed the acceptance threshold.
- Accountability – every risk has an owner, a plan and a deadline, so it doesn’t get lost between departments.
- Continuity – successive reviews compare the state with the previous one, so it is visible whether a risk is growing or shrinking.
- Reporting – the board gets a consistent picture instead of several conflicting summaries.
- Evidence – a documented analysis result that can be shown to an auditor or supervisory authority.
Standards and regulations usually describe the requirement as documented risk analysis and its results rather than as a specific document format. A risk register is the most common form of such documentation. ISO/IEC 27001 requires retaining documented information about the results of risk assessment and risk treatment. The NIS2 directive lists risk analysis among the required measures in Article 21, and Article 20 obliges management bodies to approve those measures and oversee them – the details are in our article on NIS2 requirements. In the financial sector, an ICT risk management framework is required by DORA.
What Should a Risk Register Contain?
A minimum set of fields answers a few questions: what could happen, why, with what consequence, who is accountable, how large the risk is, what already limits it and what we will still do, by when.
Beyond these fields, it is worth considering additional ones: risk category, related process or asset, inherent risk level (before controls) alongside residual, target risk, strategy (avoid, reduce, transfer, accept), status (open, in treatment, accepted, closed), related KRIs, risk source (audit, incident, workshop) and justification of the assessment. The more fields there are, the harder it is to keep the register current, so mandatory fields should always be filled in and the rest only where they add value.
Risk Register Example – Three Records
Below is a risk register example for a fictional services company. The data is illustrative, and the scales and thresholds match the examples in our articles: scales 1-5, risk level = likelihood × impact, thresholds: 1-4 low, 5-9 medium, 10-16 high, 17-25 critical.
How to read this register. In R-021 and R-024, controls bring the risk down to medium, so the owner can accept them within their authority, and the planned actions will reduce them further. R-027 still has a high level (10) after controls, which means it needs a board decision or more urgent action – it should be at the top of the priority list even though it does not have the highest inherent level.
How to Build a Risk Register
A register is best built in several steps, in this order:
- Define scope and methodology – likelihood and impact scales with described levels, risk level thresholds, risk appetite and acceptance rules (who accepts which risks).
- Design the structure – mandatory and additional fields, pick lists (categories, statuses, strategies) and filling-in rules shared by all units.
- Collect the risks – workshops with process owners, business impact analysis (BIA) results, incident history, audit and test results, the list of critical vendors, regulatory changes. Each risk is described by event, cause and consequence.
- Assess the risks – likelihood and impact, existing controls with evidence of effectiveness, inherent and residual risk.
- Assign owners and actions – one named person per risk, a treatment plan with a deadline, an acceptance decision in line with the thresholds.
- Approve the register – the board or a risk committee approves the methodology and thresholds, and designated people receive access in line with their role.
- Set the review and reporting rhythm – who updates entries, when and in what form, and to whom results are reported.
BCMLogic expert commentary: to start, a dozen or so risks for the most important processes, well described, are enough – not several hundred entered in a hurry. A register is easier to expand than to repair: weak descriptions and non-comparable ratings from the first version stay with the organization for years.
How Often Should a Risk Register Be Updated?
Updating has four rhythms that complement one another:
ISO 31000 doesn’t prescribe a frequency – it speaks of monitoring and review throughout the process – so the frequency is set by the organization’s policy and should be written down there. The NIS2 directive expects regular assessment of the effectiveness of implemented measures (Article 21(2)(f)), so a register updated only before an audit does not fulfill that role. It is worth keeping the date of the last and planned review in every entry.
Who Should Be Accountable for the Risks in the Register?
Each risk is the responsibility of one named person – the risk owner. It should be someone who genuinely influences the process or asset the risk relates to (usually the director or manager of that area), not automatically the security or risk department. The risk department provides methodology and tools. We describe the full division of roles in our guide to risk management, and assigning owners is easier with an organizational structure in which every process, risk and control has a named person. In the context of the register, the division of activities looks like this:
The register contains sensitive information, including descriptions of security gaps, so access to it should follow roles: owners see their own risks, the coordinator sees everything, the board sees a consolidated view.
Risk Register in Excel – When Is It Enough?
Excel is enough at the start and at a small scale. It works when:
- there are a dozen or a few dozen risks,
- the register is kept by one person or a small team,
- the risks concern one unit or one area,
- there is no requirement for a detailed change trail and formal approvals,
- board reports are simple and infrequent.
To make a spreadsheet last longer, a few things are worth doing: drop-down lists instead of free typing, risk level formulas in locked columns, a single version of the file in a repository with access control (not copies in emails), a review date column and a separate sheet with scales and thresholds. The limits of a spreadsheet are shown well by a comparison:
When Is It Worth Moving to a GRC System?
It is worth considering a move when at least several of the following situations apply to the organization:
- the register is kept by several people or units and version conflicts appear,
- formal approvals and an audit trail are needed (audit, certification, regulator),
- risks need to be linked to processes, assets, vendors and incidents, not just described in text,
- likelihood should come from data, e.g. incident history, rather than from estimates alone,
- the board expects a current picture of risk, and preparing a report takes days,
- the organization is subject to requirements such as NIS2/KSC or DORA and has to show that it manages risk cyclically.
Taking the BCMLogic platform as an example, according to the description of its risk management module, a register in the system includes, among other things: linking risks to processes and assets (IT systems, infrastructure, vendors), existing safeguards, strategy and treatment plans; a risk level derived from a matrix that takes likelihood and multiple types of impact into account; workflow with dynamically assigned permissions; a KRI library; role-based dashboards (board, supervisory board, directors of areas) with export to MS Excel; and a distinction between existing and planned safeguards.
A system doesn’t replace decisions – it is still the risk owner who chooses the strategy – but it organizes data and process. The move itself is worth using to tidy up risk descriptions and scales, instead of carrying old gaps into the system.
Common Mistakes in Maintaining a Risk Register
- Risks described as gaps – “no backup” instead of an event, cause and consequence.
- A register without owners – or with “IT” as the owner, which means nobody specific.
- Actions without deadlines – “implement a safeguard” with no date and no person.
- Ratings without justification – a bare result with no data sources, which can’t be defended.
- Mixing risks with incidents and tasks – events that have already happened and ordinary to-dos end up in the risk register.
- Too many fields and entries – a register that nobody is able to keep updated.
- No history – it is unclear how a rating changed over time or who approved it.
- A register “for the audit” – built once a year and not alive between reviews.
FAQ
What is the difference between a risk register and a risk analysis?
Risk analysis is the process that establishes likelihood, impact and the level of risk. A risk register is the record of the results of that analysis and a day-to-day working tool: with controls, owners, actions and deadlines.
Is a risk register mandatory?
Standards and regulations such as ISO/IEC 27001, NIS2 or DORA usually require documented risk analysis and its results, not a specific document format. A risk register is the most common form of such documentation, and in practice it is hard to demonstrate cyclical risk management without one.
How many risks should a register contain?
The number depends on the size and complexity of the organization. To start, a dozen or so risks for the most important processes, well described and assessed, are enough, and the register grows over time. What counts is the quality of entries and the ability to keep them updated, not the number of rows.
Is a risk register the same as the DORA register of information?
No. The DORA register of information (Article 28(3)) concerns contracts with ICT service providers. A risk register covers the organization’s risks in all areas. Data from the register of information can, however, feed the assessment of vendor risk.
Who should have access to the risk register?
Access should follow roles: owners see their own risks, the risk coordinator sees the whole register, the board sees a consolidated view. The register contains sensitive information, including security gaps, so it should not be open to everyone.
Can a risk register be kept in Excel?
Yes, at the start and at a small scale – with a dozen or a few dozen risks and one team. As the number of risks, owners and audit-trail requirements grows, a spreadsheet stops being enough.
Summary
A risk register is worth as much as it is current: well-described risks (event, cause, consequence), a named owner on every entry, controls with evidence of effectiveness, and deadlines for actions. Two things make the biggest difference and are the ones organizations most often skip: a review rhythm written into the policy and an update after every significant incident.
Read Also
- Risk Management in Organizations – A Complete Guide
- GRC – What Is Governance, Risk & Compliance and How Does It Work in Practice?
- NIS2 – Requirements and Obligations for Organizations. What Must Be Implemented?
See What This Could Look Like for Your Organization
If your organization keeps its risk register in spreadsheets and is looking for a single, consistent register with owners, KRIs, approvals and board reports, it’s worth seeing what this looks like on a GRC platform. BCMLogic Solutions helps financial and technology companies manage operational risk, business continuity and regulatory compliance – in line with ISO 22301, ISO 27001 and requirements such as DORA and NIS2/KSC.
