Cyber Resilience
Incident Response Metrics That Show Readiness, Not Just Speed
MTTD and MTTR are table stakes. These ten metrics track decision speed, notification readiness, recovery, rehearsal and actions closed.
Key takeaways
Incident response metrics measure how quickly and how well a firm detects, decides, contains, notifies, recovers and learns from security incidents. Time to detect and time to resolve are the baseline. For a UK B2B supplier, the measures that track outcomes are decision speed, notification readiness, restores within agreed times, exercise depth and actions that close, reported as medians by severity.
- Cyber Governance Code
- Principle D of the UK Cyber Governance Code of Practice asks boards for assurance of an incident response and recovery plan, at least annual exercising with lessons fed back, and post-incident reviews.
- 72-hour clock
- Under UK GDPR Article 33, a controller reports a qualifying personal data breach to the ICO within 72 hours of becoming aware, where feasible; a processor tells its controller without undue delay.
- Board reporting
- The Cyber Governance Code of Practice asks boards to require formal cyber reporting at least quarterly, with suitable metrics to track and agreed tolerances for each.
- Incident response plans
- The UK Cyber Security Breaches Survey 2025 found that 43% of businesses in the information or communication sector had an incident response plan, a lower share than in finance or health.
A financial services customer's due diligence questionnaire asks how fast you detect, contain and notify a security incident. Your team can quote an average time to resolve tickets, but it cannot say whether it is ready for a serious incident. This list of incident response metrics is for CTOs, heads of security and founders of UK B2B technology firms selling into regulated customers, and it covers the 10 measures that answer that question.
How we chose them. Each metric tracks whether a serious incident would cost you customers, contracts or regulatory standing. Each comes from records you already keep: tickets, the incident log, exercise reports or backup tooling. And each has a target, so a miss triggers an action.
What are incident response metrics?
Incident response metrics are measures of how quickly and how well a firm detects, decides, contains, notifies, recovers and learns from security incidents. Time to detect and time to resolve are the baseline. For a supplier, the metrics that track outcomes are decision speed, notification readiness, recovery against agreed times, exercise depth and actions closed.
The wider set of security measures, such as vulnerability age, MFA coverage and incident counts, sits in our list of security metrics to report to your board. This page goes deep on the incident itself.
NIST's SP 800-61 Rev. 3 (April 2025) aims to improve "the efficiency and effectiveness" of incident detection, response and recovery. The ten metrics below measure those three, plus the learning that follows.
Which incident response metrics should a UK supplier track?
A UK supplier should track ten incident response metrics: detection time, decision time and containment time by severity; notification decisions against the clock; restores within agreed recovery times; exercise cadence and coverage; exercise findings closed; post-incident actions closed; repeat incidents; and the share of incidents your own controls find. The table sets out each one.
| Metric | What it tells you | Data source | Who asks for it | Target to set |
|---|---|---|---|---|
| 1. Median time to detect, by severity | How long an attacker or fault goes unseen | Incident log, security monitoring alerts | Customers, board | Falling trend per severity tier |
| 2. Time from detection to first containment decision | Whether someone with authority acts fast | Incident log decision entries | Board | A maximum per severity tier |
| 3. Time to contain, by severity | How fast the damage stops spreading | Incident log, ticketing | Customers, board | A maximum per severity tier |
| 4. Time to the notification decision, against the clock | Whether you decide in time to tell people | Incident log, notification map | Customers, regulators | Always inside the shortest applicable clock |
| 5. Restores achieved within the agreed recovery time | Whether recovery promises hold | Backup tooling, restore test records | Customers | Every test and real restore inside the agreed time |
| 6. Exercise cadence and scenario coverage, last 12 months | Whether the plan has been rehearsed against real threats | Exercise reports | Board, customers | At least one exercise a year; ransomware and supplier outage covered |
| 7. Exercise findings closed | Whether rehearsals change anything | Action tracker | Board | All findings closed by their due date |
| 8. Post-incident review actions closed within an agreed period | Whether incidents change anything | Post-incident review form, action tracker | Board, auditors | All actions closed within the agreed period |
| 9. Repeat incidents from the same root cause | Whether fixes address causes | Incident log root-cause field | Board | Zero |
| 10. Share of incidents found by your own controls | Whether you find problems before customers do | Incident log source field | Customers, board | Rising trend |
Why do medians and severity splits beat a single mean?
A single mean blends every incident into one figure, so a long incident either vanishes among many short ones or distorts the whole quarter. A median shows the typical case, and splitting by severity stops a stream of minor events from hiding how you handle the serious ones. Report the median and the longest case for each tier.
Twenty phishing reports closed in minutes can sit beside one ransomware incident that ran for days. The mean looks healthy. The affected customer does not care about the other twenty.
What does each incident response metric measure?
Each metric below has the same three parts: what it is, when it matters and what to do about it. Metrics 1 to 4 cover the response itself, metric 5 covers recovery, metrics 6 and 7 cover rehearsal, and metrics 8 to 10 cover learning. Record them from the same timestamps on every incident.
1. Median time to detect, by severity
What it is. The time from when an incident started to when your team knew about it, as a median for each severity tier.
When it matters. Always, but most for serious incidents, where every hour unseen widens what an attacker can reach.
What to do. Add a "first evidence" timestamp to the incident log, set during investigation, beside the "detected" timestamp. Without both, the figure is a guess.
2. Time from detection to the first containment decision
What it is. The time from detection to the moment someone with authority decides how to contain the incident: isolate a system, disable an account or take a service offline.
When it matters. In serious incidents, where the right call costs revenue. The Cyber Governance Code of Practice expects boards to support critical decision making during an incident.
What to do. Name who can make each containment decision, with deputies, and log the time and the decision maker for every one. The NCSC's 10 Steps guidance on incident management advises keeping a careful record of decisions made and actions taken.
A plan that names no one with authority to switch a service off is a plan to wait.
3. Time to contain, by severity
What it is. The time from detection to the point where the incident stops spreading, as a median and longest case for each severity tier.
When it matters. When a customer asks how long their data or service was exposed. Containment, not resolution, answers that question.
What to do. Define "contained" for each scenario in your plan, so the clock stops at the same point every time. Our incident response plan template sets out severity tiers and response phases you can adapt.
4. Time to the notification decision, against the applicable clock
What it is. The time from becoming aware of an incident to a recorded decision on whether to notify, measured against the shortest clock that applies.
When it matters. Whenever personal data or a customer contract is involved. Under UK GDPR Article 33, a controller must report a qualifying breach to the ICO, where feasible, within 72 hours of becoming aware of it, and a processor must tell its controller without undue delay. Customer contracts may set their own, shorter clocks.
What to do. List every clock that applies to you, from the law and from your contracts, in one notification map. Measure only whether the decision was made in time; what you say is a separate job.
5. Restores achieved within the agreed recovery time
What it is. The share of restores, in tests and in real incidents, completed within the recovery time you have agreed with customers or set in your continuity plan.
When it matters. When ransomware or a cloud failure takes a service down. The 10 Steps guidance advises practising restores from backups.
What to do. Time every restore test from start to a working service, not to "backup restored". Report misses with their cause.
6. Exercise cadence and scenario coverage over the last 12 months
What it is. How many incident exercises you ran in the last 12 months, and which scenarios they covered.
When it matters. Before a customer or board asks. The Code expects boards to gain assurance of at least annual exercising of the incident plan.
What to do. Run at least one ransomware scenario and one key-supplier or cloud outage scenario each year. The NCSC's Exercise in a Box is free and includes ransomware and supply chain exercises.
7. Exercise findings closed
What it is. The share of findings from exercises that were closed by their due date.
When it matters. At the next exercise, when the same gap appears again. The Code asks that lessons from exercises are reflected in the incident plan.
What to do. Log every exercise finding in the same tracker as audit findings, with an owner and a date.
8. Post-incident review actions closed within an agreed period
What it is. The share of actions from post-incident reviews closed within the period you agreed, with a set number of days for each severity tier.
When it matters. After every significant incident. The Code expects a post-incident review process that feeds lessons into risk assessments, plans and exercises.
What to do. Hold a review for every high-severity incident and record actions in the tracker. Our guide to Annex A 5.27, learning from incidents covers what the review should capture.
9. Repeat incidents from the same root cause
What it is. The number of incidents in a period whose root cause matches an earlier incident.
When it matters. When a customer sees the same failure twice. A repeat signals that the fix treated a symptom.
What to do. Add a root-cause category to the incident log, and check new incidents against past ones at each review. The 10 Steps guidance asks you to understand how each incident happened and what could have prevented it.
10. Share of incidents found by your own controls
What it is. The share of incidents first detected by your monitoring, staff or processes, rather than reported by a customer, supplier or other third party.
When it matters. In every customer conversation after an incident. Learning about your own breach from a customer is the worst way to start that conversation.
What to do. Record the detection source on every incident. The 10 Steps guidance notes that staff, suppliers, partners and third parties may all report incidents.
How to use this list of incident response metrics
Start with four metrics: time to detect, time to the first containment decision, time to the notification decision and exercise findings closed. Record the same timestamps on every incident, set a target for each metric, then report the trend to the board each quarter and use the same figures in customer service reviews.
Add the rest as your incident log matures.
We recommend one owner per metric and one source of truth: the incident log. If the board and a customer see different numbers, both will trust neither.
What do UK boards ask about incident response?
The Cyber Governance Code of Practice asks boards to gain assurance of a response and recovery plan, of at least annual exercising with lessons fed back, and of a post-incident review process. In an incident, it asks them to take responsibility for regulatory reporting and support critical decisions. It also asks for reporting at least quarterly against agreed metrics.
The NCSC's Board Toolkit on planning your response to cyber incidents poses similar questions: whether the plan is exercised regularly, whether board members understand enough to make decisions out of hours and under time pressure, and whether improvements were made after a significant incident. It says boards should expect reporting on exercises and lessons learned.
Many firms are not there yet. The government's Cyber Security Breaches Survey 2025 found that 53% of medium businesses and 75% of large businesses had an incident response plan, and 43% in the information or communication sector.
How do incident response metrics evidence ISO 27001 and SOC 2?
Incident response metrics double as audit evidence. In ISO 27001, they show the incident controls in Annex A 5.24 to 5.27 operating, and they feed the monitoring and measurement that clause 9.1 requires. In SOC 2, they evidence the CC7 criteria on evaluating security events, responding to incidents and recovering from them.
Mapped to Annex A: exercise metrics show the planning and preparation in Annex A 5.24; decision and notification times show the assessment and decision in 5.25; containment and notification times show the response in Annex A 5.26; and review actions and repeat incidents show the learning in 5.27.
For SOC 2, the same timestamps show how events were evaluated (CC7.3), incidents handled (CC7.4) and recovery achieved (CC7.5). One well-kept incident log serves both.
What are the common mistakes with incident response metrics?
The common mistakes are averages that hide the one long incident, counting tickets as incidents, exercises with no tracked findings, and a time to resolve that stops the clock before customers are told. Each makes the figures look better than the response would be on a bad day.
- Averages that hide the long one. Report medians and the longest case by severity.
- Counting tickets as incidents. A password reset is not a security incident. Use your plan's definition and severity tiers.
- Exercises with no tracked findings. If nothing was logged, the exercise was a meeting.
- Stopping the clock too early. A time to resolve that stops before the customer is told measures your comfort, not their exposure.
Frequently asked questions
MTTD, mean time to detect, measures how long an incident goes unnoticed. MTTR usually means mean time to respond or resolve, and measures how long it takes to fix. Both are useful baselines, but medians split by severity tell you more than either mean.
Four is enough to start, because those four need only timestamps and an action tracker. A small firm may have too few serious incidents in a year to show a trend, so its exercise metrics carry more of the weight until real data builds up.
No. Most of these metrics come from a well-kept incident log and your ticketing system. What matters is recording the same timestamps, decisions and root causes every time.
Quarterly, as part of the formal cyber reporting the Cyber Governance Code of Practice asks boards to require. Agree a tolerance for each metric, and show the trend and the longest case per severity tier rather than a list of incidents, so the board can see which metrics need a decision.
