Boards should see a short set of cybersecurity metrics that answer the board’s own questions. Those questions are how much exposure the organization carries in business terms, whether the controls behind its biggest risks work on current evidence, how quickly failures are fixed, how much supplier and AI risk is measured and not assumed, how resilient critical services are and which way each number is moving. Every metric should show its trend and open onto the evidence behind it.
Directors want better reporting. In the NACD’s 2025 board practices surveys, 43% of public company directors and 57% of private company directors said that improving the quality of management’s cyber-risk reporting was very or extremely important for the coming year, and the NACD’s Director’s Handbook on Cyber-Risk Oversight gives a full principle to measurement and reporting. For a US public company the question also has a legal edge, because SEC Regulation S-K Item 106 requires the annual report to describe the board’s oversight of cybersecurity risk and the processes by which the board is informed about it.
Which cybersecurity metrics should a board see?
A board needs metrics in 9 families. Each one answers a board question in business terms, and each rests on evidence someone outside the security team can check.
| Metric family | What it measures | The board question it answers | The evidence behind it |
|---|---|---|---|
| Exposure in business terms | It measures the likely loss from the top risk scenarios as a range, with the likelihood behind it. | It answers how much cyber risk the organization carries and whether that is within appetite. | It rests on a documented quantification model, the scenarios the board has agreed and the current state of the controls that treat each scenario. |
| Control effectiveness | It measures the share of the controls behind each top scenario that passed their latest test on current evidence. | It answers whether the defenses the organization relies on are working now. | It rests on tested results read from the systems that enforce each control, each with the date its evidence was read. |
| Assurance coverage | It measures the share of in-scope controls with no current evidence, because the evidence is missing, stale or was never collected. | It answers how much of the picture is known and how much is assumed. | It rests on the age of each result and on a comparison of each control’s tested population with the asset inventory. |
| Remediation speed | It measures the median time from a failed test to a passing retest for critical controls, and the findings open past their due date. | It answers how quickly the organization fixes what it finds. | It rests on finding records with owners, due dates and retest results. |
| Third-party risk | It measures the share of critical suppliers assessed on current evidence, their open findings and how much the organization depends on any single supplier. | It answers which suppliers could hurt the organization and how much of that risk is measured. | It rests on supplier control evidence, outside-in observation and contract records. |
| AI risk | It measures the share of AI systems in use that have an owner, a classification, an approval and monitoring, and the AI exceptions still open. | It answers whether the AI the organization runs is governed or only listed. | It rests on the AI inventory, approval records and monitoring results. |
| Resilience | It measures whether critical services were recovered within their targets in the latest tests, and when each recovery plan was last exercised. | It answers whether the organization can keep its critical services running through an incident. | It rests on recovery test records and on the backup and failover controls behind each service. |
| Incidents and response | It measures incidents by severity over time and the time taken to detect and contain them. | It answers what went wrong and how well the organization responded. | It rests on incident records and post-incident reviews tracked to completion. |
| Compliance and exceptions | It measures compliance status by framework, outstanding audit findings and accepted risk exceptions with their expiry dates. | It answers which obligations are at risk and which risks the organization chose to carry, and until when. | It rests on audit reports, the finding register and the exception register. |
Three rules apply to every row. Each metric shows its trend since the last meeting and over the year, each percentage shows its denominator, and each number can be opened to the records behind it. The NACD’s common key risk indicators, which include quantified exposure by business unit, incidents by number and severity, time to detect and contain, patch compliance for critical systems, third-party concentration and training completion, fit inside these families. Formulas for 6 metrics drawn from these families are set out in How Boards Get Real-Time Visibility Into Security Posture.
How should cyber risk be reported to a board?
Report cyber risk the way the board receives every other material risk, in the same language, on the same cadence and with the same kind of metrics. That is the NACD’s advice in Principle 5 of its 2026 handbook, which also encourages standard risk quantification models that express technical measures as probable financial loss and likelihood. NIST CSF 2.0 asks for the same connection in outcome GV.RM-03, where cybersecurity risk management activities and outcomes are included in enterprise risk management processes.
The NACD suggests that board and committee reports typically cover 6 things.
- The report opens with a summary of the current posture and its trends.
- It names the top risk scenarios with their quantified potential financial impact.
- It shows exposure across common areas, including third parties, the supply chain, data, legacy infrastructure and operational technology.
- It gives incident response and resilience metrics.
- It states the status of regulatory compliance.
- It covers key investment and staffing indicators.
On timing, the NACD advises reporting at least quarterly, and again immediately after a material incident or a significant change in exposure, with escalation criteria agreed in advance. A public company should also make sure the reporting matches what its annual report says. Item 106(c) asks the company to describe the board’s oversight, any committee responsible for it and the processes by which the board or committee is informed about cybersecurity risks.
How should boards understand control assurance?
Control assurance tells the board whether the defenses behind its biggest risks still work. Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected. It is the difference between a policy that says multifactor authentication is required and a result, read last Tuesday from the identity provider, showing that every administrator account uses it.
A board does not need to see every control. It needs 3 answers for the controls behind its top scenarios: which of them were tested on current evidence since the last meeting, which failed and whether the fix was tested again, and which still rest on attestation or documents alone. The Continuous Control Assurance page sets out the full chain, and How Can a CISO Prove Security Controls Are Working? shows how a CISO presents it. Controls that have no current evidence at all are covered in What Is an Assurance Gap, and How Do You Measure It?
How can boards tell compliance status from actual security assurance?
Compliance status is an assessor’s conclusion about a framework, true as of a date or for a period that has closed. Security assurance is a tested answer about each control, true as of the last time its evidence was read. An organization can hold a clean compliance report while a control inside it has since failed, because the report describes the past and the control has kept changing.
A board can tell the two apart by asking for both side by side. For each framework it reports against, it can ask when the compliance conclusion was reached and which of the controls behind it were tested since. The two views are compared in full in Compliance Status vs Control Effectiveness, and how to keep the audit side current all year is covered in How to Continuously Maintain Audit Readiness.
How should boards understand Digital Trust?
Digital Trust translates connected assurance and risk evidence into an enterprise-level view for decision-makers. For a board, it is the point where tested control results, open risks and supplier and AI evidence become a view directors can act on. What Is Digital Trust? explains the idea in full.
DigitalXForce expresses that view as a score. The Digital Trust Score is DigitalXForce’s composite score from 300 to 850, computed continuously from live control evidence across seven sub-postures: security, compliance, audit, resilience, third-party, AI and risk. A board reads it well when it follows 3 rules.
- The board follows the trend and the sub-postures, and it asks which events moved the score, because a composite can hide where the movement came from.
- The board treats the score as a measure of control evidence, and it does not read it as a money figure, a prediction of a breach or a statement that the organization is compliant with any framework.
- The board keeps the quantified exposure beside the score, since the two answer different questions.
The Digital Trust Score methodology explains the scale and the bands. The weighting behind the score is not published, and DigitalXForce never publishes a customer’s score.
What should a board know about third-party cyber risk?
A board should know which suppliers could cause it the most harm, how much of that risk is measured on current evidence and where it depends too heavily on a single supplier. SEC Regulation S-K Item 106(b) asks a public company to say whether it has processes to oversee and identify cybersecurity risks associated with its use of third-party service providers. NIST CSF 2.0 outcome GV.SC-07 asks that supplier risks are understood, recorded, prioritized, assessed, responded to and monitored over the course of the relationship.
The NACD’s board-level metrics tool gives supply chain exposure its own category of questions for directors. Those questions cover which vendors present the greatest cyber risk, how likely and how damaging a breach involving them would be, how resilient the organization is to a third-party incident, and whether a single vendor creates a concentration risk.
Four measures go a long way toward answering those questions: the share of critical suppliers assessed on current evidence, the open findings at critical suppliers, the time those findings have been open, and the services that depend on a single supplier with no alternative. Which metrics measure third-party risk, and which give early warning? sets out the supplier measures in detail, and How to Continuously Validate Third-Party Controls shows how the evidence behind them is kept current.
What should a board know about AI risk, and which AI metrics should it see?
A board should know which AI systems the organization runs, which of them could cause serious harm, who oversees them and whether their controls are working. The NIST AI Risk Management Framework asks for an inventory of AI systems (GOVERN 1.6), for documented human oversight (MAP 3.5) and for monitoring in production (MEASURE 2.4), and those 3 outcomes give the board its first AI metrics.
- The first is the share of AI systems in use that are in the inventory with an owner and a classification.
- The second is the share of production AI systems with an approval, named overseers and live monitoring.
- The third is the number of AI exceptions open, with who accepted each one and when it expires.
- The fourth is the readiness of the systems that fall under the EU AI Act, where the rules for high-risk systems in the Annex III areas apply from 2 December 2027, according to the dates the European Commission gives after the AI Omnibus.
AI risk should reach the board through the same report as every other risk, with its trend and its evidence. What Is AI Governance, and How Do You Run It Continuously? sets out the lifecycle those metrics come from.
What GRC metrics should boards see?
Boards should see where the organization stands against its obligations and what it is doing about the gaps. The NACD’s Principle 5 suggests that reports on regulatory compliance cover the current compliance status, outstanding audit findings or deficiencies, and the plans, budgets and timelines for remediation.
Two more measures make the GRC view complete. The first is the list of accepted risk exceptions, with the person who accepted each one and its expiry date, because an exception that never expires has quietly become policy. The second is the share of findings that closed on a retest, because a finding closed on a promise has not been shown to be fixed.
Which metrics should stay with management?
Operational metrics stay with management unless they explain a change in a strategic one. The NACD’s metrics tool says operational metrics can be valuable while the board’s focus stays on strategic indicators, and that translating technical data into business terms is management’s job.
NIST’s measurement guide, SP 800-55 Volume 1, gives a useful way to sort them. Implementation measures, such as the share of servers with a standard configuration, show that controls exist and belong mostly with management. Effectiveness, efficiency and impact measures show whether controls work, how quickly problems are fixed and what that means for the organization, and those are the measures a board needs. A patch count, an alert volume or a list of vulnerabilities goes to the board only as the explanation behind a movement in one of the 9 families.
An illustration: one page for a quarterly board meeting
This example is an illustration. The organization is invented, and the example uses no figures.
A publicly traded logistics company agrees with its board that the quarterly cyber page will follow the 9 families. The page opens with the top 3 scenarios, a ransomware outage of the dispatch system, a breach of customer data and the failure of a critical cloud provider, each with its exposure range and its trend. Under each scenario sit the controls that treat it, with the share passing on current evidence and the share undecided.
This quarter, the resilience family shows that the dispatch system’s recovery test met its target. The third-party family shows that one critical supplier’s evidence is out of date because its contract carries no right to audit, and management asks the board to support that clause in the renewal. The AI family shows that a routing model went into production with an approval and named overseers. Each line opens onto its records, so when a director asks why control effectiveness fell for the customer data scenario, the answer is a specific failed control, its owner and the date of the retest.
How DigitalXForce supplies board metrics
KPI and KRI Management builds a configurable indicator matrix by business domain, risk category and risk type, with thresholds and Level 1 and Level 2 posture tracking. Indicators are approved before they are published, and an executive dashboard shows the trend, as the glossary entry describes. The Automated Board Level Metrics and Report Generator turns those indicators into board reports.
A risk operations center is an operating model for continuously measuring, prioritizing and reducing risk, in the way a security operations center handles threats; DigitalXForce’s implementation is X-ROC, the XForce Risk Operations Center. In X-ROC, dashboards and KPIs for the CISO, the CIO and the board are generated from live data rather than assembled for the meeting, and X-ROC shows which events raised the Digital Trust Score, which lowered it and what is outstanding. The Digital Trust Portal is the external-facing part of the platform, where boards, regulators and customers read shareable posture dashboards, including the Digital Trust Score and its seven sub-postures.
AI JedAI is the DigitalXForce AI engine that analyzes: it reasons over control evidence and live telemetry, maps documents to controls and frameworks, scores and prioritizes risk, and recommends remediation mapped to framework requirements. XForce GPT is the DigitalXForce generative AI engine that writes: it produces the plain-language risk narratives and board-ready reports, generates policies, standards and plans, and runs the embedded assistant. Business continuity evidence for the resilience family comes from Business Continuity and Operational Resilience (X-BCOR), which ties continuity and recovery plans to live control coverage.
These modules share one platform. TRiSCM™, or Trust, Risk, Security and Compliance Management, is a category of enterprise software defined by DigitalXForce that converges automated governance, risk and compliance with security posture management into a single real-time system, replacing periodic control validation with continuous control assurance. What is TRiSCM explains the category.
Where DigitalXForce is not the answer
A board that wants an independent opinion on its security program needs its internal audit function or an independent assessor, since DigitalXForce supplies the evidence, the metrics and the reports and does not issue an opinion on them. A company that has not yet connected its tools will get little from live metrics, and a quarterly written report may serve its board better until the integrations are in place. A startup or small company preparing its first SOC 2 report does not need board metrics at this depth, and DigitalXForce Lite serves that case, since it runs the same platform in the cloud with the same functionality and a faster deployment.
Questions about cybersecurity metrics for boards
What cybersecurity metrics should boards see?
Boards should see metrics in 9 families: exposure in business terms, control effectiveness, assurance coverage, remediation speed, third-party risk, AI risk, resilience, incidents and response, and compliance and exceptions. Each metric should show its trend and its denominator and open onto the evidence behind it.
How should cyber risk be reported to a board?
Report it in the same language, cadence and metrics as the board’s other material risks, as the NACD recommends, at least quarterly and immediately after a material incident or a significant change in exposure. The report should cover posture and trends, the top scenarios with quantified impact, exposure across areas such as third parties, incident and resilience metrics, compliance status, and investment and staffing.
How should boards understand Continuous Control Assurance (CCA)?
Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected. For a board, it answers whether the defenses behind the top risks work today, which failed and were fixed and tested again, and which still rest on attestation alone.
How can boards tell compliance status from actual security assurance?
Compliance status is an assessor’s conclusion about a framework as of a past date or period, while security assurance is a tested answer about each control as of its latest evidence. A board should ask for both side by side, including when each compliance conclusion was reached and which controls behind it were tested since.
How should boards understand Digital Trust?
Digital Trust translates connected assurance and risk evidence into an enterprise-level view for decision-makers. A board should follow its trend and its parts, ask what moved it, and read it beside quantified exposure, because a trust measure is neither a money figure nor a prediction of a breach.
What should a board know about third-party cyber risk?
A board should know which suppliers could cause the most harm, how much of that risk is measured on current evidence, and where the organization depends on a single supplier. SEC Item 106 asks public companies whether they have processes to oversee risks from third-party service providers.
What AI risk metrics should boards see?
Boards should see the share of AI systems in the inventory with an owner and a classification, the share of production systems with an approval, named overseers and monitoring, the open AI exceptions, and readiness for rules such as the EU AI Act’s high-risk obligations. Each should show its trend like any other risk metric.
Sources
- The NACD published Principle Five: Guide Cybersecurity Risk Measurement and Reporting, from its 2026 Director’s Handbook on Cyber-Risk Oversight, on 15 April 2026, at https://www.nacdonline.org/all-governance/governance-resources/governance-research/director-handbooks/2026-cyber-risk-oversight/cyber-risk-handbook-principles-2026/principle-5-guide-cybersecurity-risk-measurement-reporting. The survey figures on that page come from the 2025 NACD Public Company Board Practices and Oversight Survey (n=158) and the 2025 NACD Private Company Board Practices and Oversight Survey (n=85).
- The NACD published its Board-Level Cybersecurity Metrics tool, featured in the fifth edition of the NACD-ISA Director’s Handbook on Cyber-Risk Oversight, on 15 April 2026, at https://www.nacdonline.org/all-governance/governance-resources/governance-research/director-handbooks/2026-cyber-risk-oversight/cyber-risk-handbook-toolkit-2026/board-level-cybersecurity-metrics.
- Regulation S-K Item 106, 17 CFR 229.106, was read in the eCFR at https://www.ecfr.gov/current/title-17/chapter-II/part-229/subpart-229.100/section-229.106, and the SEC announced the rules in press release 2023-139 of 26 July 2023, at https://www.sec.gov/news/press-release/2023-139.
- NIST published The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, on 26 February 2024, at https://doi.org/10.6028/NIST.CSWP.29, and outcomes GV.RM-03 and GV.SC-07 are in its Core.
- NIST published SP 800-55 Volume 1, Measurement Guide for Information Security: Identifying and Selecting Measures, in December 2024, at https://csrc.nist.gov/pubs/sp/800/55/v1/final.
- NIST released the AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1, on 26 January 2023, at https://doi.org/10.6028/NIST.AI.100-1.
- The European Commission states the EU AI Act’s application dates after the AI Omnibus at https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai, last updated on 3 August 2026.
- Every source above was read on 26 September 2026.
What this looks like in practice.
Reading about continuous evidence is one thing. Watching a control get tested against live data from your own stack is another. A 30 minute walkthrough on your frameworks shows the difference.
