Board-Level Cyber Risk Reporting Framework: A CISO Guide

Cyber risk has sat below board level for most of the past decade, delegated to audit committees or handled entirely within the security function. That's changing because the regulatory and governance landscape is changing around it. The DSIT Cyber Security Breaches Survey 2025 found that only 27% of UK businesses have a board member with explicit cyber security responsibility, a figure that has fallen significantly since 2021 and one that regulators and governance bodies are now actively targeting.

The governance pressure is coming from two directions. UK-listed companies face new obligations under the revised Corporate Governance Code. EU-regulated financial entities face direct management body accountability under DORA. Both frameworks treat cyber risk as a board-level responsibility, not a security function responsibility.

And there's an operational reality sitting behind the governance change. When a major incident occurs, boards that have been receiving regular, substantive cyber risk reports are far better positioned to make the rapid decisions that incident response demands: mobilise resources, notify regulators, communicate with customers, manage reputational exposure. Boards that have been receiving quarterly compliance status updates are not.

UK Corporate Governance Code 2024: Provision 29

The UK Corporate Governance Code 2024, published by the Financial Reporting Council and effective from 1 January 2026, introduced a significant change to how boards must report on internal controls. Provision 29 requires the board to monitor and carry out at least an annual review of its risk management and internal controls framework, and to make a formal declaration of effectiveness over material controls, covering financial, operational, reporting, and compliance controls.

The first declarations are due in annual reports published in early 2027 for calendar-year-end companies, making 2026 the year to build the evidence and the monitoring processes that will support those declarations. For FTSE-listed companies, cyber security controls will qualify as material controls under this framework. A board that can't demonstrate active monitoring of its cyber risk posture will struggle to make that declaration credibly.

What Provision 29 creates, in practice, is a formal need for a board-level cyber risk reporting process: a structured, documented, regular reporting framework that produces evidence the board can rely on for its effectiveness declaration.

DORA Article 5: Management Body Accountability

For financial entities in scope of the Digital Operational Resilience Act, the DORA Regulation (EU) 2022/2554 places ultimate ICT risk responsibility at management body level through Article 5. The management body must define, approve, and oversee the ICT risk management framework; bear ultimate responsibility for managing ICT risk; and ensure that members maintain sufficient knowledge and skills to understand and assess ICT risk and its impact on operations.

Article 19 of DORA sets out the requirements for reporting major ICT-related incidents to competent authorities, including notification obligations to clients. The incident reporting framework under DORA Article 19 requires financial entities to notify their clients about major incidents and the measures taken to mitigate adverse effects. For a management body to authorise those notifications in the timeframes DORA expects, it needs a reporting process that gives it real situational awareness before an incident occurs, not a first briefing after one.

The practical implication for CISOs at DORA-regulated entities is that the DORA board reporting requirements under Article 5 aren't satisfied by a quarterly risk update. They require a reporting framework that the management body genuinely uses to govern ICT risk across the year.

ISO 27001:2022 Clause 9.3: Management Review

For organisations holding or pursuing ISO 27001:2022 certification, Clause 9.3 requires a management review of the information security management system at planned intervals. This review must cover the status of actions from previous reviews, changes in internal and external issues relevant to the ISMS, feedback on information security performance, and opportunities for continual improvement. Board-level cyber risk reporting, structured to cover these elements, doubles as the documented evidence base for ISO 27001 management review. The ISO 27001 risk management obligations and the board reporting framework described here are designed to work together; structured board reporting satisfies both at once.

The most common failure in board cyber risk reporting is reporting on the wrong things. Control-layer metrics, vulnerability counts, and patch rates are security operations information. They tell the security team whether the controls are working. They don't tell the board whether the organisation is operating within its approved risk appetite, whether the security programme is delivering on its investment, or whether there are material risks requiring board-level decisions.

A board report needs three categories of information. The tables below set out what belongs in each category and what each metric actually tells the board.

Risk Posture Metrics

Programme Performance Metrics

Incident and Event Metrics

A common objection at this point is that financial risk exposure figures require quantitative risk assessment capability that many organisations haven't built yet. That's a fair starting point, not a permanent constraint. Organisations can begin with directional risk ratings and build towards quantified financial exposure as their data matures. What matters is that the board report tracks direction of travel, not just current status.

Format and structure determine whether a board engages with a report or receives it. The most substantive cyber risk analysis can fail to generate governance engagement if it's presented in the wrong format at the wrong point in the board cycle.

Length and Format

A board cyber risk report should be two to three pages maximum. Boards don't read long security reports; they receive them. The executive summary, the top risks, the key metrics, and the decisions required should all be visible on the first page. Supporting detail (incident timelines, control test results, programme milestone tracking) belongs in an appendix that non-executive directors can review between meetings if they choose to.

Visualise directional change. A table showing risk posture metrics is less effective than a table showing those same metrics with a direction arrow and a comparison to last quarter. The board needs to see whether things are getting better or worse, not just where they stand today.

Reporting Cadence

Quarterly reporting is the minimum for most organisations. It gives the board enough frequency to track trend data meaningfully and enough interval for the metrics to actually change between reports. Bi-annual reporting doesn't allow the board to monitor direction of travel; monthly reporting risks turning the board into an operational oversight body rather than a governance body.

In addition to the regular reporting cycle, the board needs an agreed escalation protocol for material incidents: what constitutes an escalation, how quickly they'll be informed, and what decisions they may need to make. This protocol should be agreed in advance and tested at least annually.

Board Risk Appetite as the Reference Point

Every metric in the board report should be presented against the board-approved risk appetite. If the board hasn't defined a cyber risk appetite, that's the first governance problem to solve: without it, there's no basis for the board to determine whether the organisation's risk posture is acceptable or requires action.

Risk appetite statements for cyber risk don't need to be complex. A statement that defines the maximum acceptable financial exposure from a single cyber incident, the maximum acceptable downtime for critical systems, and the regulatory compliance thresholds the organisation won't breach gives the CISO the reference points needed to structure meaningful board reporting. Everything in the report then speaks to whether the organisation is inside or outside those parameters.

Technically accurate reports that board members can't interpret don't produce governance. Three factors consistently determine whether a board actually engages with cyber risk reporting rather than simply receiving it.

Language comes first. Directors think in terms of financial exposure, legal liability, reputational impact, and strategic risk. A report written in those terms gets read. A report that leads with CVSS scores, patch rates, and mean time to detect gets filed. That doesn't mean hiding the technical detail: it means leading with the board-level consequence and supporting it with the technical evidence.

A clear "decisions required" section makes the difference between a report the board acts on and one they receive. Boards are governance bodies. If the report doesn't tell them what they're being asked to decide, they'll treat it as an information item and move on. Decisions required might include: approving an increased budget for a control that's shown to be failing under test, formally accepting a risk that exceeds appetite because the treatment cost is disproportionate, or authorising a regulatory notification following a significant incident.

Consistency of format matters more than most CISOs expect. Boards that receive a different report structure each quarter spend cognitive energy navigating the format rather than engaging with the content. Pick a structure, document it in your reporting policy, and stick to it. The board should be able to find the risk posture summary, the key incidents, and the decisions required in the same place every time.

Board reports that are assembled manually carry a structural problem: by the time the data has been collected, formatted, reviewed, and approved, some of it is already out of date. For organisations with complex control environments and multiple regulatory obligations, the gap between data collection and report publication can run to weeks. That's a meaningful accuracy problem for a report that's supposed to represent current risk posture.

Gracie AI Agents with Personas and Skills connects live control monitoring data directly to the reporting layer, so the metrics in the board report reflect current control status rather than a snapshot from the start of the evidence collection cycle. Boards at organisations using Gracie AI Agents with Personas and Skills report decisions made 40% faster, a direct result of receiving risk information that's accurate at the point of the board meeting rather than three weeks before it.

The audit trail that a GRC platform provides also matters for Provision 29 compliance. The board's effectiveness declaration isn't just a statement: it's an assertion that requires documented evidence. A GRC platform that logs control test results, risk assessments, and monitoring activities creates the evidence base the board needs to make that declaration with confidence. Spreadsheets and shared folders don't.