Boards are expected to oversee enterprise risk, yet the information they receive is often split across separate registers, scales and reporting cycles. A shared enterprise risk management (ERM) methodology turns those separate risk registers into one view the board can act on.
In a nutshell. Boards do not need another risk report. They require one shared view that uses the same scoring methodology across domains, shows gross and residual risk, and makes the next decision clear.
Board risk oversight without a shared view
NIS2 places responsibility for risk management explicitly with the management body. Article 20 requires directors to approve the risk-management measures, to oversee their implementation, and to follow training themselves. It also provides that they can be held liable for shortcomings. Article 21 sets out what those measures must cover as a minimum. DORA does the same for the financial sector: the management body remains ultimately accountable for the ICT risk framework. ISO 27001, in its leadership clause, asks that top management owns the risk process rather than merely being informed about it.
The rules are clear about who has to steer. In practice, management often lacks the overview it needs to do so. An executive committee receives an audit report, a cyber dashboard, a compliance overview, and a financial risk statement. Four documents, none of which answers the question actually on the table: where do we stand as an organisation, and what do we need to decide now?
Why enterprise risk management stays in silos
The cause is rarely unwillingness. It is structural. IT risk sits with the CIO, cyber risk with the CISO, operational and financial risk with the CRO, and data protection risk with the DPO. Each role works correctly within their framework, but each uses a different scale, vocabulary, and time horizon.
- CIO IT risk
- CISO Cyber risk
- CRO Operational & financial risk
- DPO Data protection risk
One common language Shared methodology
- Likelihood 1–5
- Impact 1–5
- Gross & residual risk
One board view Comparable risks
- Clear owners
- Clear decisions
The consequence is that the numbers cannot be added up. A “high” cyber risk on a three-point scale and a “risk class 4” from an operational model cannot be meaningfully compared. Without a shared scale, the board cannot weigh them against each other. The discussion then falls back on whichever risk is reported most loudly or linked to the most recent incident.
When I set up a risk register, I always start with the methodology, not with the risks. Without one agreed-upon scale, every consolidation is false precision.
What a usable enterprise risk register looks like
The model I have found most useful in large organisations is deliberately straightforward. Consider an environment organised in different domains.
The core business: shared data services, payment and financial services, customer services, enterprise IT support services and corporate support services.
Two cross-cutting domains cover information security and data protection.
The final domain covers buildings and facilities management.
| Risk ID | Description | Category | L | I | Gross | Mitigating measures | Res. L | Res. I | Residual | Owner |
|---|---|---|---|---|---|---|---|---|---|---|
| ENT-01 | Core processes depend on ageing legacy components, maintained by a shrinking group of people. | Technology and continuity | 4 | 4 | 16 · Critical | Phased decommissioning programme; architecture roadmap; knowledge capture. | 3 | 3 | 9 · Moderate | [Named person] |
| SDS-01 | Data quality errors corrupt the calculation base of a core process. | Data and information quality | 4 | 5 | 20 · Critical | Validation rules at point of entry; reconciliation against source records. | 2 | 5 | 10 · High | [Named person] |
That table carries the same columns for every risk: risk ID, description, category, likelihood (1–5), impact (1–5), gross score, mitigating measures, residual likelihood, residual impact, residual risk, and a named owner. Four elements make the difference.
One taxonomy. Likelihood is anchored to frequency, from “less than once every five years” to “monthly or more often.” Impact is scored across multiple dimensions at once. For example: financial impact in euro bands; operational impact in terms of service delivery and compliance; and reputational impact, with the most significant dimension setting the score.
Four levels summarise the result: Low (1–4), Moderate (5–9), High (10–14), Critical (15–25).
Gross versus residual as evidence. Gross is the exposure without measures. A residual is what remains once the measures are in place. The difference between the two is the only evidence that an investment in control had any effect.
Financial translation. Because the impact scale is tied to euro thresholds, a technical risk becomes discussable in the language an executive committee already uses.
A named owner. Not a department. A person.
Above that sits a single summary tab: per domain, the number of risks, the highest gross and residual score, and a heat map placing every risk ID in the likelihood × impact grid. That is the view the board needs. One sheet, all domains, outliers visible straight away.
The last piece is the decision tree, and it hangs deliberately on the residual risk rather than the gross. The required response becomes explicit:
- Residual 1–4: the ExCo notes the risk, and it moves into periodic monitoring.
- Residual 5–9: the owner follows up, with a half-yearly review and reporting without a decision.
- Residual 10–14: the ExCo validates the mitigation plan, assigns an owner and a deadline, and releases resources.
- Residual 15–25: immediate escalation, with a decision on budget or external support.
Gross and residual risk: one example
Take a risk every large organisation recognises: core processes that depend on ageing legacy components, maintained by a shrinking group of people. Likelihood 4 — disruptions occur several times a year. Impact 4 — an outage hits a core process and is financially serious. Gross 16, so Critical.
The measures are well known: a phased decommissioning programme, an architecture roadmap, and knowledge capture so that dependence on individuals falls. Reassessment gives residual likelihood 3 and residual impact 3, so a residual risk of 9, Moderate. For the ExCo that is a clear decision. No escalation, but an owner with a deadline and a half-yearly review.
The case where impact does not move is just as instructive. For data quality errors that corrupt the calculation base of a core process, validation rules and reconciliation bring likelihood down from 4 to 2. Impact stays at 5: the consequences remain just as severe. Gross 20 becomes residual 10 — still High, so still an ExCo matter. The difference between lowering likelihood and lowering impact is precisely the conversation a board should be having.
Why enterprise risk registers outgrow spreadsheets
I build registers like this in Excel first, on purpose. It enforces discipline, it costs nothing, and it makes the methodology visible to everyone working on it. But the moment the register has to stay alive, it stalls.
Versions multiply, and it stops being obvious which one is authoritative. The spreadsheet has no workflow or reminders, so follow-up depends on one person’s calendar. Measures do not reference the controls they implement, nor the evidence that those controls work. The register is a point-in-time picture: it shows no trend, no aggregation over time and no audit trail of who changed what and when. The same risks and measures have to be reused by hand across NIS2, CyFun, DORA and GDPR, work that starts again with every change.
What a GRC platform changes
That is what we are building with Euraika GRC: the same logic — domains, taxonomy, gross and residual risk, owners, decision tree — kept alive. Risks are linked to the controls that address them, and to the frameworks those controls appear in, so one measure serves several obligations. Owners receive follow-up tasks instead of an email. Evidence sits with the measure, not in a separate folder. Residual risk is recalculated when the underlying assessment or measure changes. ExCo reporting is ready rather than assembled by hand each quarter. The scoring judgement itself stays where it belongs: AI assists; people decide.
What CIOs, CISOs and CROs need from risk reporting
CIO: make technical debt and chain dependencies visible in euros. A legacy case marked as a High residual risk on the heat map leads to a different conversation from the same case buried in an architecture note.
CISO: translate cyber risk into business language and board-level reporting. Not because the board cannot handle the technology, but because it has to make budget decisions using the same scale it applies to operational and financial risk.
CRO: establish one methodology that allows risks to be compared across domains. That is the precondition for everything that comes after it.
Building an enterprise risk register or trying to bring an existing spreadsheet back to life? In one hour, we can walk you through Euraika GRC or discuss the methodology behind a usable enterprise risk view. Either will take you further than another version of the same file.
Thomas Baeck is a security specialist with hands-on experience in security architecture and as a CISO. Across public and private organisations, he builds risk registers, ISMSs and NIS2 programmes that reach the executive committee and works on Euraika GRC, the platform that turns compliance from a periodic effort into a continuous operation.