A March 2026 report from France's national cybersecurity agency (ANSSI) reveals that 67% of European board members say they do not understand the cyber reports submitted to them. At the same time, NIS2 and DORA place a personal responsibility for information security governance on management bodies. This contradiction is not sustainable.
The problem does not come from board members' incompetence: it comes from a structural misalignment between the language of security (CVE, CVSS, patch rate, number of SIEM alerts) and the language of governance (value at risk, probability of material impact, sector benchmark, return on security investment).
In this article, you will find five indicators that turn a technical report into a strategic decision tool, and the common mistakes to avoid in this exercise.
The regulatory context forcing this change
NIS2 and DORA leave no room for choice. Article 20 of NIS2 requires management bodies to approve cyber risk management measures and oversee their implementation. Article 5 of DORA places an explicit responsibility for digital operational resilience on the boards of financial entities. Oversight can no longer be delegated to a technical subcommittee.
This regulatory change has a direct consequence for the form of cyber reports: a document understandable only by technicians no longer meets the legal obligation. If your board cannot make an informed decision on the basis of your report, you are not compliant, even if every line of the document is technically accurate.
The first compliance reviews conducted by national authorities in the first half of 2026 show that this point is systematically raised. Several organisations received formal recommendations to change their reporting format before their next audit. The reflex of submitting the CISO report to the board without adapting the format to the recipient is a practice that authorities regard as a sign of immature governance.
The mistake of the technical report
The typical cyber report of a French organisation in 2026 contains: the number of vulnerabilities detected, the average CVSS score of the estate, the 30-day patch rate, the number of SIEM alerts, and the number of incidents handled. These metrics are useful for SOC teams. They are incomprehensible, and therefore unusable, for a general management team.
The central problem: these indicators measure the activity of the security team, not the organisation's level of risk. A board member who sees "1,247 vulnerabilities detected, 89% patched at D+30" cannot answer the questions that matter to them: do the 11% not yet patched represent a material risk? Are we better or worse than our sector peers? What happens if we do not fund the additional budget requested?
The mistake is not presenting technical data: it is stopping there. This data must be translated, contextualised and linked to business consequences to become decision-useful. It is the CISO's role to make this translation, not the board's to learn it.
The 5 decision indicators
1. Residual financial exposure
Express cyber risk as the value of the assets at risk. Not as a number of vulnerable systems, but as a potential impact on revenue, data assets or regulatory obligations. Example: "Our payment processing systems, which handle EUR 340 million of annual volume, carry an estimated residual exposure of EUR 12 million in the event of a compromise of privileged access." A figure in euros is a decision waiting to be made. A CVSS score is information without context.
2. Detection and response time (MTTD/MTTR)
The mean time to detect an intrusion (MTTD) and the mean time to recover (MTTR) are the only operational indicators that boards need to know. They measure the real capacity to limit the impact of an incident. An MTTD of 14 days, the median observed in France according to ANSSI 2025 data, means the attacker has been in your systems for two weeks before you know it. Presented this way, the indicator becomes immediately intelligible to any board member.
3. Sector positioning
Board members make relative decisions, not absolute ones. "Our maturity level is higher than 68% of organisations of our sector and size" is a decision indicator. "We have 3,400 assets in our scope" is not. Use ENISA benchmarks, the CIS Controls Maturity Models, or data from sector consortia. Sector comparison is the only context a board member can interpret without technical expertise.
4. Regulatory obligation coverage rate
NIS2, DORA, EU AI Act: each text imposes verifiable controls. Present a coverage percentage for each text, with the documented gaps and remediation timelines. This format speaks immediately to board members who know that their personal responsibility is engaged on these obligations. A three-column table (regulatory text, current coverage rate, action plan) is more effective than a 40-page report.
5. Marginal efficiency of the security budget
This is the hardest indicator to build, and the most decision-useful. How much does a reduction of X% in residual risk cost? What would be the impact of a 20% budget cut on the security posture? This marginal reasoning is the one boards use to allocate resources. Your report must follow the same logic. Even a reasoned estimate, explicitly qualified as such, is far more useful than a list of projects with no link to the level of risk being addressed.
How to operationalise this transformation
The best practice is to organise the cyber report on two distinct levels. The first level, intended for the board, contains the five indicators presented above, on two pages at most. The second level, in an annex, contains the technical data for board members who wish to go deeper, or for documentary review during an audit.
This structure meets two potentially conflicting objectives: enabling effective oversight by non-technicians, while documenting the technical rigour required by the frameworks. DORA makes this explicit in its technical standards (RTS): governance documentation must be understandable "by a reasonably informed person who is not an expert in information security".
The other best practice, too often overlooked: present these indicators over time, not as a snapshot. A 12-month chart shows the trajectory, which is the information genuinely useful to the board. The absolute level says little; the direction of the curve says everything.
Assessing your current format
To assess the maturity of your cyber reporting, start with a simple test: submit your last report to a member of your senior management with no technical background. Ask them what they would retain to justify or reject a budget request. Their answer will tell you everything you need to know about your current format.
Presidio natively integrates the five indicators presented in this article into its governance dashboard, with visualisations calibrated for executive committees. For a demonstration tailored to your sector, contact our team: we reserve 30-minute sessions for security and compliance directors. Also read: The silent error in the design of your Risk Dashboard.
Conclusion
Cyber reporting to the board has become a regulatory imperative, not a strategic option. NIS2 and DORA have shifted security responsibility towards management bodies: this shift requires a transformation of the reporting format, not only of its content.
Three takeaways: the financial translation of technical risk is essential, SOC activity metrics are not governance indicators, and sector comparison is the only context board members can interpret without technical expertise.
Organisations that master this reporting format obtain faster budget decisions, better calibrated approvals of security projects, and a more robust demonstration of compliance in the eyes of auditors. And in your context: what is the main obstacle preventing you from making this shift today?