What time to contain measures, and where the clock starts and stops

Time to contain is the elapsed time from the first detection signal on an incident to the first action that stops the attacker spreading or acting. That means a host isolated, a session revoked, an account disabled, a message pulled, a key rotated or an address blocked. It does not mean the ticket is closed. It does not mean the incident is resolved. Closing and resolving come later and depend on people, change windows and legal review.

This site is organised around that definition because it is the step automation can shorten most, and the step where a wrong action costs the most. Every criterion in the published rubric is a reason a platform's time to contain is fast and safe, fast and unsafe, or slow.

Three start events are in common use, and they give different numbers for the same incident.

• The first malicious event. The attacker ran something at 02:10. Nobody knows this at the time. You only learn it in the post-incident review.
• The first detection signal. A rule fired or a vendor alert arrived at 02:14. This is the start used here, because it is the first moment a defender could have acted.
• The first analyst touch. Someone opened the case at 02:41. This hides queue time, which is often the largest part of the delay.

Pick the second. It is the earliest start that is always recorded. If your tooling cannot give you a timestamp for the first signal, fix that before you buy anything. Without it you are measuring your queue, not your response.

The stop event is the first containing action that took effect, not the first action that was requested. A request to isolate a host that sat in an approval queue for 40 minutes has not contained anything. A request that the agent on the host rejected has not contained anything either.

Record three timestamps for each action: requested, approved (or auto-approved) and confirmed effective. Time to contain uses the last one. The gap between requested and confirmed is your platform's execution latency. The gap between requested and approved is your human latency. Both are worth knowing, and they have different owners.

Partial containment needs a rule. If an attacker holds three accounts and you disable one, the clock has not stopped. Decide in advance that the clock stops when the last known foothold is closed, or when the incident commander declares containment. Write the rule down. Apply it the same way to every incident.

A mean time to contain is dragged around by one bad weekend. Report the median and the 90th percentile by severity. The median tells you how the platform behaves on a normal day. The tail tells you what the on-call engineer lives through.

Segment by action type as well. Revoking a session and isolating a server do not take the same time, and they should not be averaged together. A platform that is fast at email purges and slow at cloud credentials will look average in a blended figure and be dangerous in practice.

Vendors publish timing figures, and almost none states the start and stop events. Here is what the pages read on 2026-11-03 actually contain.

• Swimlane's customers page carries a testimonial from Thetabyte claiming threats contained in under 5 minutes (read 2026-11-03), a customer claim (a testimonial published by the vendor) with no period or method.
• ServiceNow's product page headlines a customer story with 1 minute from threat detection to response (read 2026-11-03), an unmethodised vendor claim; the page itself returned an error to our reader that day, so treat the claim as unconfirmed.
• D3 Security claims about 90 seconds end to end on a typical alert (d3security.com/llms-full.txt, read 2026-11-03). That is a triage pipeline figure, not a containment time, and it is a vendor claim.
• Prophet Security published a post on 2026-10-28 titled Mean Time to Contain versus MTTR in an AI-driven SOC (read 2026-11-03). The title shows the vendor sees the distinction. We did not find a published containment figure with a method on its pages.
• Google's Response Agent documentation (read 2026-11-03) describes approval thresholds and publishes no time-to-contain figure.
• Exabeam's press release of 2026-10-01 says its own team measured an average case triaged in about 10 minutes against about five hours for a human analyst (press release, read 2026-11-05). That is a triage time measured by the vendor with no sample size, not a containment time.

Notice the pattern. Some numbers measure triage. Some measure response in general. Some are customer testimonials with no baseline. None gives a start event, a stop event, a sample size and a period together. That is why the rubric scores a published figure with a method higher than a bare number, and scores a bare number as partial at best.

You do not need a vendor's number if you hold the timestamps. For every incident where a containing action ran, store:

1. The detection signal time, from the source tool, not from the platform that ingested it.
2. The case creation time.
3. The action request time, approval time and confirmed-effective time.
4. The action type and the product it ran against.
5. Whether a human approved it or the platform ran it alone.
6. The rollback time, if the action was undone.

Six fields, one row per action. A spreadsheet will do for a pilot. A platform that cannot export these is telling you something about its audit trail, which is the subject of a separate guide here.

First, do not let detection quality leak into the metric. If a rule fires late because the log source is slow, that delay belongs to detection engineering. Track it, but report it separately so the response team is not blamed for it.

Second, do not count automated closures. A platform that auto-closes false positives in seconds is useful, and it says nothing about containment. Keep the populations apart.

Third, do not compare a pilot window to a baseline from a different season, a different alert mix or a different staffing level. Run the old process and the new one on comparable incidents, or replay the same incidents through both.

• The start event is the first detection signal, taken from the source tool.
• The stop event is the first containing action confirmed effective.
• The rule for partial containment is written down.
• Requested, approved and effective timestamps are stored for every action.
• Reports show the median and the 90th percentile, by severity and by action type.
• Auto-closed false positives are excluded from the containment population.
• Every vendor figure is filed as a vendor claim with its page, its read date and its stated method, or the words "none published".