Which cyber security metrics should a provider report to business leaders?

Cyber security metrics for business leaders should connect technical activity with business risk, control effectiveness and operational resilience. A useful provider report does not simply list alerts or vulnerabilities; it explains what has changed, which assets or processes are affected, whether safeguards are working, and what decisions or actions are required.

The most useful reports combine outcome measures, which show whether the organisation is becoming safer and more resilient, with activity measures, which show whether agreed security processes are being completed. Each metric should include its definition, reporting period, scope, data source, trend and owner. Without this context, a figure can be technically accurate but difficult to interpret.

Risk exposure and treatment

• Open risks by business impact: show the number and nature of unresolved risks affecting important systems, sensitive information or essential operations. Grouping risks by severity alone is less informative than explaining their potential operational, financial, legal or reputational effect.
• Risk age: indicate how long significant risks have remained open. An ageing risk may require escalation even if its severity has not changed.
• Risk treatment progress: report whether each agreed action is complete, in progress, deferred or formally accepted. Accepted risks should identify the accountable owner, reason for acceptance and review date.
• Exceptions: record where a security standard or control cannot be applied, including the affected scope, compensating measures and expiry or review arrangements.

This allows leaders to distinguish between a low number of recorded risks because controls are effective and a low number because assessment activity is incomplete. It also makes clear where management decisions, funding or acceptance of residual risk are needed.

Control coverage and effectiveness

Providers should report whether important controls cover the assets and users that they are intended to protect. Examples include the proportion of relevant accounts protected by multi-factor authentication, the proportion of supported devices receiving endpoint security controls, the status of secure configuration checks, and the completion of access reviews. These figures should identify exclusions rather than presenting coverage as universal when particular systems cannot support a control.

Coverage alone does not prove that a control works. Reports should therefore include evidence such as the results of control testing, failed checks, overdue reviews, backup restoration tests, or repeated policy exceptions. A control that is deployed but misconfigured, bypassed or not monitored should not be treated as fully effective.

Vulnerability and remediation measures

A meaningful vulnerability section should show more than the total number of findings. It should distinguish exploitable or business-critical weaknesses from lower-priority findings and show the assets affected, the age of each issue, the remediation status and any compensating control. Useful measures include:

• the number of critical and high-priority vulnerabilities still open;
• the proportion of assessed assets with current vulnerability data;
• the age of the oldest unresolved significant finding;
• the proportion of remediation actions completed within the organisation’s agreed timescales; and
• the number of recurring findings that indicate a weakness in patching, configuration or change management.

The report should clarify whether figures come from all relevant assets or only from systems included in a particular scan. Otherwise, a reduction in findings could simply reflect a change in scanning scope.

Detection and monitoring quality

Security monitoring metrics should help leaders understand whether suspicious activity can be identified and investigated. Appropriate measures may include the volume of alerts by severity, the proportion escalated for investigation, the number assessed as genuine security events, and the age of unresolved investigations.

Alert volume should not be used as a success measure by itself. A high volume may reflect noisy rules, duplicated telemetry or a temporary event, while a low volume may indicate gaps in logging. Reports should state which systems and data sources are monitored, whether important log sources are missing, and whether detection rules have been tested. Where appropriate, providers should also report the time taken to identify and triage significant events, using consistent definitions for when measurement starts and ends.

Incident handling and recovery

Incident metrics should show how effectively the organisation limits disruption and learns from events. Relevant measures include the number of incidents by severity and type, the systems or business services affected, the time taken to contain and eradicate the cause, and the time required to restore normal operation. These measures need an agreed definition of an incident, containment and recovery; otherwise comparisons between reporting periods can be misleading.

Post-incident reporting should also show whether root-cause actions have been completed, whether similar weaknesses remain elsewhere, and whether an exercise or real event resulted in changes to controls, procedures or training. A falling incident count is not automatically evidence of improvement if reporting criteria have changed or detection coverage has reduced.

Identity and access indicators

Identity metrics are particularly relevant because excessive or poorly managed access can increase the impact of a compromised account. A provider may report privileged accounts, dormant accounts, accounts without appropriate authentication safeguards, overdue access reviews and the removal of access for leavers or changed roles. Where unusual sign-in activity is detected, the report should explain the number of investigations and their outcome rather than presenting every alert as a confirmed compromise.

Leaders should be able to see whether access is based on current business need, whether administrative activity is attributable to an individual, and whether exceptions are documented and reviewed.

Human and third-party risk

Staff security measures can include completion of required training, reporting of suspected phishing or other concerns, and the outcome of awareness exercises where these are used. Completion rates should be separated from evidence that people understand and apply the required behaviour.

Where suppliers, cloud services or other third parties support important processes, reporting may also cover the status of supplier assessments, overdue reviews, unresolved third-party risks and the availability of contractual or assurance evidence. This helps leaders see risks that may not be visible within the organisation’s own network.

How the provider should present the report

A board-level summary should begin with the most significant changes since the previous report: new risks, deteriorating controls, completed improvements and decisions requiring attention. A concise dashboard can be supported by a technical appendix containing asset lists, event records, vulnerability details and test evidence.

Every metric should have a clear calculation method and a named owner. The report should show the current position alongside previous periods, but trends must be interpreted carefully when the asset estate, monitoring scope, risk criteria or data collection method changes. Thresholds should be agreed in advance where possible, with escalation routes for results outside tolerance.

The strongest reporting links each material metric to an action: accept, remediate, investigate, test, fund or review. It should also distinguish measured facts from estimates, incomplete data and management judgement. This gives business leaders a reliable basis for prioritising cyber security work instead of encouraging them to judge performance by isolated figures.