What is a risk register?
A risk register is a structured, up-to-date overview of all risks an organisation has identified, recording for each risk the assessed likelihood and impact, the chosen controls, the accountable owner and the current status. The register is the output of risk assessment and the working document of risk management: it shows which risks exist, who manages them and whether the agreed controls are delivered on time. In IT/OT environments a single register brings cyber risk, process safety and production availability together.
A risk register is a living document. It makes risks visible, manageable and demonstrable to the board, auditors and regulators, for example under ISO 27001, NIS2, GMP and IEC 62443.
🎯 What do you use a risk register for?
- Insight - one place for threats, vulnerabilities and their consequences
- Prioritisation - scoring risks on likelihood and impact so that budget goes to the biggest risks
- Planning and tracking controls - every control has an owner and a deadline
- Evidence for audits and Compliance - an auditor can see which risks you know about, how you treat them and who accepted the residual risk
- Continuous improvement - the register drives the PDCA cycle: every control is followed by a reassessment
The US National Institute of Standards and Technology describes the register in NIST IR 8286 (October 2020, revised as Rev. 1 in December 2025) as the central document for tracking and communicating risk information throughout the organisation. Registers for individual systems or departments are rolled up there into one enterprise risk register for the board.
📄 What goes in a risk register?
There is no legally prescribed format, but the columns are similar in almost every method. The example template in the first edition of NIST IR 8286 includes an ID, priority, risk description, category, likelihood, impact, exposure rating, risk response type, cost, owner and status.
| Column | Description |
|---|---|
| Risk ID | Unique identifier (e.g. RISK-001) |
| Description / scenario | What could happen, to which asset or zone? |
| Cause | The threat and vulnerability behind the risk |
| Consequence | Impact on safety, production, quality, data or reputation |
| Likelihood | How likely is it to occur? |
| Impact | How severe is the consequence? |
| Risk score | Likelihood × impact (e.g. 3 × 4 = 12) |
| Classification | High / medium / low / acceptable |
| Risk response | Avoid, mitigate, transfer or accept |
| Controls | Which controls or actions are planned or in place? |
| Residual risk | Score after the controls, plus who accepts that residual risk |
| Owner | Who is accountable for this risk? |
| Status / deadline | When is the control due and when is the next review? |
The difference between inherent risk (without controls) and residual risk (after controls) is the most important thing a register shows. Without those two columns you cannot demonstrate what a control has achieved.
📊 How does the risk matrix work?
A risk matrix (heatmap) is often used to classify scores:
| Likelihood ↓ / Impact → | Low (1) | Medium (2) | High (3) | Critical (4) |
|---|---|---|---|---|
| Very low (1) | 1 | 2 | 3 | 4 |
| Low (2) | 2 | 4 | 6 | 8 |
| Medium (3) | 3 | 6 | 9 | 12 |
| High (4) | 4 | 8 | 12 | 16 |
The score determines whether action is required. One possible split for a 4×4 matrix is 1–3 acceptable, 4–6 low, 8–9 medium and 12–16 high, but you set the thresholds yourself in your risk acceptance criteria. A 5×5 matrix is also widely used. Bear in mind that likelihood and impact are rankings here, not real numbers. ISO 31000 and ISO 27005 do not prescribe a fixed matrix, and a score of 4 is not “half as bad” as 8. Define what each step of the impact scale means, for example in hours of lost production, injury or euros.
🔐 Which risks appear in an OT risk register?
In industrial and hybrid environments the register often contains risks such as:
- Failure of a PLC, SCADA server or Historian without a working backup
- Ransomware via suppliers’ remote access or the update process
- Unauthorised access to the production network, for example because of a flat network without zones
- Loss of batch data or tracking and tracing information, affecting quality and product recalls
- Breaches of requirements from GMP, SIL assessments or ISO 27001
- Supplier risk - dependence on a single system integrator, assessed through third-party risk management
OT adds two things to a classic IT register. The impact scale must also cover human safety and the environment, not just confidentiality. And many controls cannot be applied straight away in OT: patching often has to wait for a planned shutdown. In that case, record a compensating control and the reason, and tie the deadline to the maintenance window. Process safety methods such as HAZOP and BOW-TIE provide good scenarios and impact estimates.
🧱 Which standards and laws call for a risk register?
None of the major frameworks literally prescribes a document called a “risk register”. They do require documented results of risk assessment and risk treatment, and a register is the usual way to provide them.
| Framework | What it requires | Role of the register |
|---|---|---|
| ISO 27001:2022 | Risk assessment (6.1.2) with risk owners, risk treatment and a Statement of Applicability (6.1.3), documented results (8.2, 8.3) | Overview of risks, owners and approved residual risk |
| ISO 27005 / ISO 31000 | Method for assessing, treating, recording and reporting risk | Guidance on structure and upkeep |
| IEC 62443-3-2 | Initial risk assessment of the system and detailed risk assessment per zone and conduit; residual risk compared with tolerable risk; results documented (ZCR 5.13); asset owner approval (ZCR 7) | Record per zone and conduit, basis for the security level |
| NIS2 / Dutch Cybersecurity Act | Appropriate risk management measures; Article 7 of the Cybersecurity Decree requires a risk method, acceptance criteria and a risk inventory | Evidence of the duty of care for the regulator |
| Implementing Regulation (EU) 2024/2690 | For digital providers such as cloud and managed service providers: a risk treatment plan and justified acceptance of residual risk, reviewed at least yearly | Record of the treatment plan and acceptance |
| GMP / GxP | Quality risk management according to ICH Q9(R1) | Risks to product quality and patient safety |
The Dutch Cybersecurity Act (Cyberbeveiligingswet) and Cybersecurity Decree have applied since 15 August 2026. ISO 9001 only requires you to address risks and opportunities (6.1); a register is useful there but not mandatory.
🔧 How do you set up a risk register in practice?
- Define the scope - which sites, installations and processes are included? Start from an up-to-date asset inventory, because a risk without an asset cannot be managed.
- Set the criteria - likelihood and impact scales, the matrix and the threshold for acceptable risk. Have the board approve that threshold.
- Identify scenarios - through workshops, threat modelling, a business impact analysis and input from vulnerability management. Write scenarios concretely: “ransomware via the supplier’s VPN stops the packaging line”, not “cyber attack”.
- Assess inherent risk - using one consistent method, for example NIST SP 800-30 or the steps in IEC 62443-3-2.
- Choose the response and controls - avoid, mitigate, transfer (e.g. insurance) or accept. Give every control an owner and a deadline.
- Assess and accept residual risk - the risk owner signs off on what remains, with a date and a name.
- Keep it current - review at least once a year and with every major change through change management, after incidents and when new threats emerge.
An example row from an OT register:
| ID | Scenario | Inherent (L×I) | Control | Residual (L×I) | Owner |
|---|---|---|---|---|---|
| OT-014 | Ransomware via the machine builder’s always-on VPN stops line 3 | 3 × 4 = 12 | Remote access on request only, with MFA and session recording | 1 × 4 = 4 | Engineering manager |
The impact stays at 4: the control lowers the likelihood, not the consequences. To reduce the impact as well, you need offline backups and a tested recovery procedure.
🛠 Which tools do you use for a risk register?
- Excel or a spreadsheet - simple and quick, suitable for small organisations; weak on version control and action tracking
- GRC platforms (such as ServiceNow, Riskonnect or LogicGate) - workflows, reminders and reporting, linked to audits and policies
- ISMS tools with built-in risk logic linked to the Statement of Applicability
- OT monitoring platforms (such as Claroty or Tenable OT Security) - supply asset and vulnerability data as input; assessing and accepting risk remains human work
Alongside NIST IR 8286 Rev. 1, NIST also publishes a spreadsheet template and JSON schemas for risk registers, which helps when you want to merge registers from different tools.
❓ Frequently asked questions
Is a risk register mandatory under ISO 27001?
ISO 27001 does not require a document called a risk register, but it does require documented results of risk assessment and risk treatment, with risk owners and approved residual risk. In practice a risk register is the usual way to provide that evidence. Auditors almost always ask for one.
What is the difference between a risk register and a risk assessment?
A risk assessment is the process in which you identify, analyse and evaluate risks. The risk register records the outcome, together with controls, owners and status. The assessment is carried out periodically; the register is maintained continuously.
How often should you update a risk register?
You should fully review a risk register at least once a year, and in between after major changes to the installation, after incidents and when new threats or vulnerabilities emerge. The status and deadlines of controls are updated continuously. A register that has not been touched for a year counts as weak evidence in an audit.
Who owns a risk in the risk register?
The risk owner is the person with the authority and budget to control the risk, which in OT is often a production or engineering manager rather than the security team. The owner decides on the controls and accepts the residual risk. The security team facilitates the process and maintains the register.
Can IT and OT risks be in one risk register?
Yes, a single risk register for IT and OT avoids duplicate work and makes dependencies visible, such as a shared Active Directory. The impact scale must then weigh safety, the environment and production alongside confidentiality. Many organisations use one register with a field showing whether a risk concerns IT, OT or both.
What is residual risk in a risk register?
Residual risk is the risk that remains after the controls have been implemented, scored again on likelihood and impact. If the residual risk is below the acceptance threshold, the risk owner formally accepts it. If it is above, additional controls are needed or the board must consciously agree to it.
📌 In summary
A risk register records the scenario, likelihood, impact, controls, residual risk and owner for each risk. Standards such as ISO 27001, IEC 62443-3-2 and the Dutch Cybersecurity Act do not literally prescribe the register, but they do require exactly that documented information. In OT, safety belongs on the impact scale and deadlines have to fit maintenance windows.
A risk register maps threats, vulnerabilities and their consequences and shows who does what for each risk, so that you manage risks in your IT/OT environment systematically and can prove it.