How to Build and Maintain a Risk Register

A risk register is the central repository where an organisation records, tracks, and manages its identified risks. It is not a spreadsheet that sits in a shared drive until audit time — or at least, it should not be. A well-maintained risk register is a living management tool that drives investment decisions, informs board discussions, supports regulatory examinations, and provides the evidence trail that connects risk identification through to treatment and residual risk acceptance.

EU regulations do not use the term 'risk register' explicitly, but they mandate its substance. NIS2 Article 21(2)(a) requires risk analysis and information system security policies — which implies a structured record of identified risks, their assessment, and the policies addressing them. DORA Article 6(1) requires a comprehensive, documented, and continuously updated ICT risk management framework — which cannot exist without a central risk record. ISO 27001:2022 Clause 6.1.2 requires organisations to apply a risk assessment process that identifies information security risks, analyses and evaluates them, and retains documented information about the process and its results. The risk register is the artefact that satisfies all three requirements simultaneously.

The form of the risk register matters less than its content and governance. A spreadsheet can be adequate for a small organisation with fewer than fifty risks. A GRC platform is necessary for large enterprises managing hundreds of risks across multiple business units and jurisdictions. What matters is that the register contains all required fields (discussed in the next section), is accessible to all risk owners, is subject to a defined review cadence, and has clear ownership and governance. A beautifully designed register that nobody updates is worth less than a plain spreadsheet that is reviewed monthly.

For organisations operating under multiple EU frameworks, the risk register should be unified — not fragmented into separate registers for NIS2 risks, DORA risks, GDPR risks, and ISO 27001 risks. A single risk may be relevant to multiple frameworks (a data breach scenario is simultaneously a NIS2 incident, a DORA ICT disruption, a GDPR personal data breach, and an ISO 27001 information security event). Recording it four times in four registers creates maintenance overhead, inconsistency, and the risk of conflicting treatment plans. Record each risk once, with framework mapping fields that indicate which regulations it relates to.

The risk scoring methodology determines how consistently and meaningfully your register ranks risks. A methodology that produces scores everyone agrees on is more valuable than a sophisticated methodology that produces scores nobody trusts. The most widely adopted approach for cybersecurity risk is a matrix-based qualitative method: impact and likelihood are each assessed on a defined scale, and the risk score is the product (or a weighted combination) of the two.

Define your impact scale with specific, measurable criteria tied to your organisation's context. A five-level scale might look like: Level 1 (Negligible) — financial impact below EUR 50,000, no regulatory notification required, no service disruption; Level 2 (Minor) — financial impact EUR 50,000-500,000, internal reporting only, service degradation under 4 hours; Level 3 (Moderate) — financial impact EUR 500,000-2 million, regulatory notification potentially required, service disruption 4-24 hours; Level 4 (Major) — financial impact EUR 2-10 million, regulatory notification required, service disruption 1-7 days, media attention likely; Level 5 (Critical) — financial impact exceeding EUR 10 million, regulatory enforcement action, service disruption exceeding 7 days, systemic impact on sector. These thresholds should be calibrated to your organisation's size, revenue, and risk appetite — the EUR 50,000 lower bound that is negligible for a large bank is significant for a 100-person technology company.

Likelihood assessment should incorporate both historical data and forward-looking threat intelligence. A five-level scale: Level 1 (Rare) — unlikely to occur in the next 3 years; Level 2 (Unlikely) — may occur once in 3 years; Level 3 (Possible) — may occur once per year; Level 4 (Likely) — expected to occur multiple times per year; Level 5 (Almost Certain) — expected to occur monthly or more frequently. Calibrate these levels with reference to industry data — ENISA's annual statistics, sector-specific incident data from financial sector ISACs or national CSIRTs, and your own historical incident records.

The distinction between inherent risk (before controls) and residual risk (after controls) is essential for demonstrating control effectiveness and justifying investment. For each risk, first score the inherent risk assuming no controls exist, then document the controls in place and their assessed effectiveness, and finally score the residual risk. The gap between inherent and residual risk is the control effectiveness — the value your security programme is delivering. If inherent and residual risk scores are similar, your controls are not adequately mitigating the risk and either the controls or the risk treatment plan needs to be revised. This inherent-to-residual progression is particularly valuable for board reporting: it quantifies what the security programme is achieving and identifies where further investment would have the greatest impact.

A risk register that is updated once a year for audit purposes is a compliance artefact, not a management tool. Converting it into a living document requires three structural changes: defined trigger events for updates, assigned ownership with accountability, and integration into operational workflows.

Trigger events should include: discovery of new threats or vulnerabilities (from threat intelligence feeds, vulnerability scans, or incident reports), significant changes to the IT environment (new systems, decommissioned systems, major configuration changes, cloud migrations), organisational changes (new business lines, geographic expansion, mergers or divestitures), regulatory changes (new requirements, supervisory guidance, enforcement decisions), security incidents (whether at your organisation or at comparable entities in your sector), and the results of audits, penetration tests, or compliance assessments. Each trigger should prompt a review of affected risk register entries and potentially the identification of new risks.

Risk ownership is the single most important factor in register maintenance. Each risk must have a named owner — not a team, not a department, not a role, but a specific individual who is accountable for monitoring the risk, maintaining the register entry, progressing the treatment plan, and escalating when the risk exceeds tolerance. Risk owners should be the people with the operational authority to influence the risk — typically business function leaders or system owners, not the risk management team. The risk management team facilitates, challenges, and aggregates — they do not own the risks themselves.

Integrate the register into operational workflows. New project proposals should include a risk register impact assessment: does this project introduce new risks or change existing ones? Change management processes should include a risk register checkpoint: does this change affect the residual risk score of any registered risk? Incident response playbooks should include a risk register update step: does this incident reveal a new risk or change the assessment of an existing one? Vendor onboarding should include a risk register entry for any significant third-party dependency. The more touch points the register has with daily operations, the more current and accurate it remains.

Conduct formal risk register reviews at a defined cadence. Monthly reviews by the risk management team should verify that all entries are current, all treatment plans are on track, and no trigger events have been missed. Quarterly reviews by senior leadership should evaluate the top risks, review risk appetite alignment, and make treatment priority decisions. Annual reviews should reassess the entire register from scratch — not just updating existing entries but re-evaluating whether the risk landscape has fundamentally shifted in ways that the incremental updates may have missed. Document these reviews with attendees, decisions made, and actions assigned.