Your Incident Has Two Clocks. You Only Report One.

Detection engineering has genuinely improved. Telemetry that used to sit in four consoles now lands in one. Correlation that used to take an analyst an afternoon runs in seconds. Mean time to detect and mean time to respond are the right instinct, because they force a security team to be honest about speed instead of coverage. Nobody should give that back.

But the two numbers you report describe one clock, and your organisation is living on a different one.

Every incident runs two. The first starts when your tooling notices something and stops when the threat is contained. Security owns it, security measures it, and it is the number that reaches leadership and the board. The second starts when the business first feels impact, often earlier than detection. It stops when the business is genuinely operating normally again. Nobody owns that one. It appears on no dashboard.

Call it the second clock. The gap between the two is not a delay in your response. It is a hole in your measurement.

Why the second clock has no owner

Look at where the responsibility boundary sits. Security's mandate ends at containment, and reasonably so. The threat is neutralised, the account is disabled, the host is isolated, the incident is declared handled. Every playbook in the industry treats that moment as the finish line, because for the security function it is.

What happens next belongs to other people. Identity re-issues credentials. Platform rebuilds hosts. Finance re-verifies controls. Legal decides on notification. Operations decides when to trust the system again. Each of those teams is competent and each is working, but none of them is running a clock, and no single person is watching the interval end to end.

So the organisation produces a precise number for the half that has an owner and no number at all for the half that has the business impact. The first clock is measured because it is measurable. The second is unmeasured because measuring it would require someone to hold the seam, and the seam belongs to nobody.

The Tuesday this shows up

An executive assistant's mailbox is compromised through a session token, not a password. The attacker sits quietly for a week reading correspondence, then sends three payment instruction changes to accounts payable using a real thread on a real invoice.

Detection works. An anomalous forwarding rule fires an alert at 09:14. The analyst confirms at 09:40. The session is revoked and the account is disabled by 11:20. Two hours and six minutes from alert to containment. It is a good number and the team earned it.

Now follow the other clock. Accounts payable stops all outbound payments at 11:30 because nobody yet knows how many instructions were touched. Every vendor bank detail changed in the last thirty days has to be re-verified by voice. The number has to come from an independent record, not the email thread. There are sixty of them. The finance team is four people. Procurement is fielding calls from vendors asking why they were not paid. Legal wants to know whether the correspondence read during that quiet week triggers a notification obligation. Somebody has to read a week of a senior executive's mail and make a judgement.

The organisation resumed normal payment operations on day four.

Security's number was two hours and six minutes. The business experienced a four day outage in a core function. Both are true. Only one went into the incident report, and it was the one that made the security team look effective, which is exactly why nobody questioned it.

The evidence for a gap this wide

The industry's headline figure is a first-clock figure. IBM and the Ponemon Institute put the mean time to identify and contain a breach at 247 days in the 2026 Cost of a Data Breach report, drawn from more than 600 organisations breached between March 2025 and February 2026. That number rose after five consecutive years of improvement.

The second-clock figure in the same study is the one worth sitting with. About four in ten organisations reported complete recovery from their breach. Fewer than one in twenty reached it inside seven weeks.

Read that again as a measurement problem rather than a performance problem. Six in ten had not finished recovering at all, and the vast majority of those who had took longer than seven weeks to get there. None of that appears in a mean time to respond. Your response metric can improve every quarter while the interval that actually costs the business money stays exactly where it was. Your reporting will show progress the entire time.

Where the objection lands

The strongest counterargument is that recovery already has a discipline, a set of metrics and an owner. Business continuity and disaster recovery. Recovery time objectives are defined per system, agreed with the business and tested annually. The same executives who see the security metrics sign them off. Restoration is somebody's job and there are numbers attached to it. The seam I am describing, the objection goes, is covered by a function that predates the security team.

It is a serious objection and BCDR does real work. But look at what a recovery time objective assumes. It assumes the system is unavailable. A server is down, a datacentre is offline, a database is corrupted, and the objective describes how quickly a working copy replaces a broken one. Every part of that discipline is built around restoring availability.

The incidents that generate the longest second clocks do not look like that. The mailbox was available the whole time. The payment system never went down. Accounts payable stopped because the data inside a working system could no longer be trusted. There is no recovery time objective anywhere in your plan for a system that runs perfectly and cannot be believed. Re-establishing trust is a different problem from restoring service, it takes longer, and it is the one nobody has an objective for.

What changes when you accept it

An incident is no longer over when it is contained. It is over when the last function that changed its behaviour changes it back.

Your response metric is no longer a measure of organisational resilience. It is a measure of one team's segment of a longer interval.

A post-incident review is no longer complete when the root cause is documented. It is complete when someone has written down both clocks and the distance between them.

Four questions worth carrying into your own organisation this week, and none of them needs a project. For your last three incidents, what time did security stop its clock. What date did the affected business function resume normal operation. Who, by name, owned the interval between those two moments. Which of your recovery time objectives covers a system that is fully available and no longer trusted. And when the response time went to leadership and the board, did anyone in the room understand which of the two clocks it described.

Find your own shape

Organisations meet this in different places. Some find it in identity, where containment took an hour and re-issuing credentials across a partner ecosystem took a fortnight. Some find it in finance, where controls froze the moment trust broke and thawed only at the speed of manual verification. Some find it in operations technology, where the plant kept running but engineering held every change until the environment was re-validated. Some find it in customer support, where the systems were fine within hours and the inbound calls ran for three weeks. The mechanism is identical. Where it surfaces depends on which function depends most on trusting its own data.

The uncomfortable part is that the better your detection gets, the wider this gap grows in percentage terms. Compress containment from six hours to two and you have improved the reported number by two thirds while the four day recovery is untouched. The metric improves, the executive summary improves, and the experience of the business does not move at all.

Start with your last real incident, not a tabletop. Put two timestamps on one page. The moment security declared containment, and the moment the most affected business function confirmed it was operating normally again. Then write one name beside the interval. Most organisations cannot fill in that name today, and finding out that you cannot is worth more than any dashboard you could buy this quarter. Take both numbers to leadership and the board together, because a response time presented alone is not a resilience metric, it is a fragment of one.

You have been reporting how fast you stopped the attacker. Nobody has been reporting how long you stayed hurt.