Last updated: 26 September 2026
Quick answer: An enterprise risk register template should capture, for every risk, a unique ID, a cause-event-consequence description, a category, a named owner, inherent likelihood and impact, existing controls, residual rating, the agreed response, actions with due dates, key risk indicators and a review date. Keep scoring criteria defined once and applied consistently across the organisation.
Every organisation has a risk register somewhere. Often it is several: one in finance, one in IT security, one in the privacy team and one for the board. The trouble starts when they use different scales, different categories and different owners for the same risk, and nobody can see the full picture.
This guide gives you an enterprise risk register template you can adopt directly, explains each field, shows a scoring matrix and worked examples, and covers how to connect cyber, privacy and operational risks into one view. It draws on ISO 31000, NIST guidance and common regulatory expectations in the EU, UK and US.
What is an enterprise risk register template?
An enterprise risk register template is a standard structure for recording, rating and tracking risks across the whole organisation. It makes sure every team describes risk the same way, so risks can be compared, aggregated and reported to leadership.
ISO 31000:2018 describes risk management as a process of identifying, analysing, evaluating, treating, monitoring and communicating risks, and it applies to organisations of any sector or size. A risk register is the working record of that process. It is not certifiable on its own, but it is the evidence auditors and regulators ask for first.
NIST treats the register as the link between technical and enterprise risk. NIST IR 8286 Rev. 1, published in December 2025, focuses on using risk registers to record cybersecurity risk and roll it up from system and organisational levels to the enterprise level, and NIST provides register templates and schemas alongside it.
The enterprise risk register template: fields explained
The template below works for strategic, operational, financial, compliance, cyber and privacy risks. Copy the columns into a spreadsheet or GRC tool and keep the definitions with it.
| Field | What to record | Tip |
|---|---|---|
| Risk ID | Unique reference, for example R-042 | Never reuse IDs, even for closed risks |
| Risk title | Short name | Five to eight words |
| Description | Cause, event and consequence | “Because of X, Y may happen, leading to Z” |
| Category | Strategic, operational, financial, compliance, cyber, privacy, third party | Use a fixed list |
| Risk owner | Named individual accountable for the risk | A person, not a team |
| Inherent likelihood | Score 1 to 5 before controls | Use defined criteria |
| Inherent impact | Score 1 to 5 before controls | Consider financial, legal, operational, reputational and people impact |
| Inherent rating | Likelihood x impact | Calculated, not typed |
| Existing controls | Controls in place today | Link to control IDs where possible |
| Residual likelihood and impact | Scores after existing controls | Be honest about control effectiveness |
| Residual rating | Likelihood x impact after controls | Compare with risk appetite |
| Risk appetite or tolerance | Acceptable level for this category | Set by the board |
| Response | Accept, avoid, mitigate, transfer or share | Record who approved it |
| Action plan | Planned treatments | Each action with an owner |
| Target rating and date | Expected rating once actions complete | Makes progress measurable |
| Key risk indicators | Metrics that signal the risk is changing | Two or three per key risk |
| Linked obligations | Frameworks, laws or contracts affected | For example NIS2, GDPR, ISO 27001 |
| Status and last review | Open, in treatment, accepted, closed; review date | Flag overdue reviews automatically |
Common mistake: writing risks as vague topics, such as “cyber attack” or “GDPR”. A useful risk description names the cause, the event and the consequence, so the owner knows what to manage.
How should you score risks?
Use a simple, defined scale and apply it everywhere. A 5 x 5 likelihood and impact matrix is common because it is easy to explain to leadership, but the definitions matter more than the grid.
| Score | Likelihood | Impact (example criteria) |
|---|---|---|
| 1 | Rare: not expected in the next five years | Negligible: no noticeable effect on services or obligations |
| 2 | Unlikely: could occur once in five years | Minor: short disruption, handled within normal operations |
| 3 | Possible: could occur once in two to three years | Moderate: service disruption or a reportable compliance issue |
| 4 | Likely: expected about once a year | Major: significant disruption, regulatory action or customer loss |
| 5 | Almost certain: expected several times a year | Severe: threat to strategy, licence to operate or financial viability |
The criteria above are examples only. Calibrate the impact levels to your own financial thresholds, service levels and regulatory exposure, and have them approved as part of your risk management policy.
NIST’s SP 800-30 Rev. 1 guide for conducting risk assessments is a useful reference for structuring threat, vulnerability, likelihood and impact analysis for information security risks. For a step-by-step method aligned to ISO 27001, see our ISO 27005 risk assessment guide.
In practice: score inherent and residual risk separately. If the two scores are always identical, your controls are either not working or not being assessed.
Worked example: three completed entries
These illustrative entries show how the template reads when filled in. They are examples, not benchmarks.
| Field | R-011 Ransomware | R-024 Supplier failure | R-037 DSAR backlog |
|---|---|---|---|
| Description | Because some servers are unpatched, ransomware may encrypt core systems, leading to extended outage and data loss | Because payroll depends on one provider, its failure may stop salary payments, leading to staff and legal impact | Because data is spread across many systems, access requests may miss legal deadlines, leading to complaints and regulatory action |
| Category | Cyber | Third party | Privacy |
| Owner | Head of IT Operations | HR Director | DPO |
| Inherent (L x I) | 4 x 5 = 20 | 3 x 4 = 12 | 4 x 3 = 12 |
| Existing controls | EDR, offline backups | Contract SLA | Manual request log |
| Residual (L x I) | 3 x 4 = 12 | 3 x 4 = 12 | 3 x 3 = 9 |
| Response | Mitigate | Mitigate | Mitigate |
| Actions | Patch SLA, MFA on admin accounts, restore test | Exit plan, secondary provider assessment | Data map, request workflow with deadline alerts |
| Target | 2 x 4 = 8 by Q2 | 2 x 3 = 6 by Q3 | 2 x 2 = 4 by Q2 |
| KRIs | Critical patches overdue; backup test failures | Provider SLA breaches | Requests near deadline |
| Linked obligations | NIS2, ISO 27001 | NIS2 supply chain, contracts | GDPR Article 12 |
What do regulators expect from risk registers in the EU, UK and US?
No major regime prescribes one template, but all expect documented, current risk assessment that leadership can see and act on.
| Region | Driver | What it means for your register |
|---|---|---|
| EU | NIS2 Article 21(2)(a) requires policies on risk analysis and information system security, approved by the management body under Article 20 | Cyber risks must be assessed, owned and reported to management |
| UK | Provision 29 of the UK Corporate Governance Code 2024 now applies to financial years beginning on or after 1 January 2026, requiring boards of companies applying the Code to declare the effectiveness of material internal controls | Registers must link risks to material controls and evidence of their effectiveness |
| US | SEC cybersecurity disclosure rules require public companies to describe annually their processes for assessing, identifying and managing material cybersecurity risks | Registers need to support board-level disclosure on cyber risk management |
If you are building one register to serve all three, start your 14-day free trial and see how risks, controls and obligations link together in one place.
How do you connect cyber, privacy and enterprise risk?
Keep one register structure and one scoring method, then let specialist teams maintain detailed registers that roll up to the enterprise view. That is the model NIST IR 8286 Rev. 1 describes for cybersecurity risk.
- Agree common categories and scales across finance, operations, IT security and privacy.
- Link risks to controls, so one control supporting several frameworks is only assessed once. Cross-framework control mapping helps here.
- Bring in third parties, since many operational risks sit with suppliers. Feed results from vendor and third-party risk management into the register, and see our article on why vendor risk is now an executive liability.
- Aggregate for leadership: show the top risks, trends and risks outside appetite, not the full register.
Frameworks such as COSO’s Enterprise Risk Management: Integrating with Strategy and Performance can help you link the register to strategy and performance objectives, not just compliance.
How often should the register be reviewed?
Review high and critical risks at least monthly, the full register at least quarterly, and any risk immediately after a significant incident, change or audit finding. Set review dates per risk rather than relying on a single annual exercise.
- Monthly: top risks, overdue actions and KRIs breaching thresholds.
- Quarterly: full register review by owners and a summary to leadership.
- Annually: review scoring criteria, categories and risk appetite.
- Event-driven: incidents, new regulations, major projects, acquisitions or supplier changes.
Key takeaways
- An enterprise risk register template needs clear fields, a named owner per risk and defined scoring criteria.
- Describe risks as cause, event and consequence, and score inherent and residual risk separately.
- Use one structure across cyber, privacy, operational and financial risk so risks can be aggregated.
- NIS2, the UK Corporate Governance Code and SEC rules all expect current, board-visible risk information.
- Review top risks monthly and the full register at least quarterly.
Frequently asked questions
What should be included in a risk register?
At minimum: a unique ID, a clear description, category, named owner, likelihood and impact scores before and after controls, existing controls, the chosen response, actions with owners and due dates, and a review date. Adding key risk indicators, risk appetite and linked obligations makes the register far more useful for leadership reporting and audits.
What is the difference between inherent and residual risk?
Inherent risk is the level of risk before you account for existing controls. Residual risk is the level that remains after those controls. Recording both shows how much your controls actually reduce exposure, and helps you decide whether the remaining risk sits within appetite or needs further treatment.
Who should own risks in the register?
Each risk should have a single named owner with the authority and budget to manage it, usually a business or functional leader rather than the risk or security team. The risk function sets the method and challenges the ratings, but owners are accountable for treatment decisions and for keeping their entries current.
Is a spreadsheet good enough for an enterprise risk register?
A spreadsheet can work for a small organisation with a handful of owners. As the number of risks, owners, controls and frameworks grows, spreadsheets make version control, reminders, evidence links and aggregation difficult. A GRC platform keeps one source of truth and an audit trail of changes.
How many risks should an enterprise risk register contain?
There is no correct number. The enterprise register should hold the risks that matter at leadership level, with detailed operational or technical risks maintained in supporting registers that roll up to it. If leadership cannot review the top risks in one meeting, the enterprise view is probably too detailed.
Conclusion: one register, one language for risk
A good enterprise risk register template is less about the spreadsheet and more about consistency: the same fields, the same scales and the same ownership rules across every team. Get that right and the register becomes a management tool rather than a compliance artefact, giving leadership a clear view of what could go wrong and what is being done about it. Enactia’s AI-powered GRC platform supports this with enterprise risk management linked to controls, vendors and frameworks.
To discuss your risk register, contact us or book a demo or start your 14-day free trial.
