Boards do not need another dashboard full of alerts. They need evidence that important systems can withstand an incident, that suspicious activity is detected promptly and that recovery works within an agreed business window.
That evidence can be organised around three questions: how well do we Protect, how quickly do we Detect, and how reliably can we Recover?
Start with business services, not tool totals
An organisation may patch thousands of endpoints and still leave one revenue-critical server exposed. It may close alerts quickly while missing an attacker that remains active for days. It may report successful backups without ever restoring an application.
Define the services that matter first: payroll, customer support, finance, production, identity and collaboration. Then measure the controls that protect those services.
Protect: measure exposure and control coverage
Useful protection metrics include:
- percentage of supported endpoints reporting healthy security controls;
- critical patches deployed within the approved risk window;
- privileged accounts protected with phishing-resistant authentication;
- unsupported systems with an approved treatment plan; and
- exceptions that are open beyond their agreed expiry date.
Coverage should be paired with quality. “EDR installed” is less meaningful than “EDR healthy, current and reporting on every in-scope endpoint”.
Detect: measure time and signal quality
Mean time to detect (MTTD) is the interval between the start of an event and the moment the organisation identifies it. Mean time to acknowledge shows how quickly the right responder sees the alert. Neither metric should be averaged across every low-value notification.
Report by severity and service. A critical identity compromise deserves a tighter objective than a routine device-health warning. Add:
- percentage of high-severity alerts investigated within the target;
- false-positive rate for rules that consume analyst time;
- dwell time for incidents discovered after the fact; and
- detection coverage for the techniques in the organisation's threat model.
The goal is not a flattering number. It is a trend that shows whether detection is becoming faster and more dependable.
Recover: prove the outcome
Recovery time objective (RTO) is the target time to restore a service. Recovery point objective (RPO) is the maximum acceptable data loss measured in time. Actual recovery results should be compared with both.
Track the proportion of priority systems restored successfully, the age of the restored data, the time taken, dependencies that failed and corrective actions that remain open. A green backup job is an input; a successful, timed restore is evidence.
Combine the metrics into one operating rhythm
The OAS Three Pillar managed security service combines SentinelOne endpoint protection, N-able N-central monitoring and Cove Data Protection. That technical stack maps naturally to a monthly resilience review:
- confirm endpoint, patch and identity-control coverage;
- review significant alerts and detection times;
- inspect backup health and the latest recovery-test results;
- record exceptions, owners and due dates; and
- choose one improvement to validate in the next exercise.
Avoid turning the scorecard into a single percentage. A composite score can hide a failed recovery test behind excellent patch compliance. Keep Protect, Detect and Recover visible as separate outcomes.
A concise executive view
A useful one-page report can show six numbers: critical exposure, control coverage, high-severity MTTD, high-severity response time, tested RTO and tested RPO. Add a short narrative explaining what changed, why it changed and what decision is required.
Cyber resilience becomes credible when the numbers are based on tested services rather than vendor claims. Measure less, verify more and make every metric lead to an owner or action.
Sources
- N-able: Security Incident Response Metrics, published 1 August 2026 and accessed 20 August 2026.
- N-able: Disaster Recovery Test—Methods, Steps and Cadence, published 30 July 2026 and accessed 20 August 2026.
Build a measurable Protect, Detect, Recover programme with the OAS Three Pillar service.