Most engineering teams believe their incident response capability is adequate. The data says otherwise — consistently, across company sizes, industries, and geographies. The median time from initial compromise to detection is measured in months, not hours. The median time from detection to containment is measured in days, not minutes. These are not edge cases. They are the norm.
I have managed security incidents at organisations in financial services, energy, and insurance — sectors with compliance mandates, dedicated security teams, and boards that take the topic seriously. The gap between what those organisations believe their response capability to be and what it actually is, under pressure, is the most reliable finding in my work. Not because these are bad organisations. Because incident response is one of the most consistently under-tested disciplines in enterprise technology.
Why the Numbers Are This Bad
The intuitive assumption is that long detection times are caused by sophisticated attackers using novel techniques. That is almost never the primary cause. In the incidents I have worked on and studied, the dominant causes of long dwell times are structural, not adversarial.
Alerts without owners. Security tooling generates enormous volumes of signals. In organisations without clear escalation paths and named incident owners, those signals sit in queues that are reviewed intermittently, triaged inconsistently, and escalated based on individual judgment rather than defined criteria. An alert that would trigger a response in a mature organisation gets reviewed, considered low-priority, and closed — because the responder doesn't have the context or the authority to escalate it differently.
Logging gaps. You cannot detect what you cannot see. In every post-incident forensic engagement I have run, there are logging gaps — services that were never instrumented, log retention windows that expired before the investigation started, audit trails that covered the application layer but not the infrastructure layer. Attackers know this. Dwell time is often, in practice, limited by log retention rather than by detection capability.
No practiced playbook. Most organisations have an incident response plan. Very few have practised it. A plan that lives in a Confluence wiki and has not been executed in a live drill is not a response capability — it is a document. The difference between a team that contains a breach in 48 hours and one that takes three weeks is almost always the existence and quality of their practice, not the sophistication of their tooling.
The "this isn't a real incident" problem. The hardest call in incident response is the declaration call — deciding that something anomalous is, in fact, a security incident and not just a bug, a network hiccup, or an unusual usage pattern. In organisations without a clear declaration threshold and a named person with the authority to make that call, anomalies get explained away. Every hour spent explaining away a real incident is an hour of additional dwell time.
Benchmarks by Maturity Band
These are ranges I use as reference points when assessing client organisations. They draw on published industry studies (IBM, Mandiant, Verizon DBIR) combined with my direct observations. They are not guarantees — they are calibration points.
| Maturity Level | Mean Time to Detect (MTTD) | Mean Time to Respond (MTTR) | Mean Time to Contain (MTTC) | What Defines This Band |
|---|---|---|---|---|
| Reactive (no formal IR) | 120–200+ days | 5–20 days post-detection | 30–90 days | No IR plan, alerts unowned, forensics outsourced from scratch |
| Defined (plan exists, untested) | 60–120 days | 3–10 days | 15–45 days | Written plan, SIEM in place, escalation path informal |
| Tested (quarterly drills) | 15–45 days | 24–72 hours | 5–15 days | Practised playbooks, named IR team, detection tuned |
| Optimised (continuous improvement) | 1–7 days | 2–12 hours | 24–72 hours | Threat hunting, automated containment, post-incident feedback loop |
The jump from Defined to Tested is the most impactful step most organisations can take. The tooling delta between those two bands is often small. The process and practice delta is large.
The compliance trap
A SOC2 Type II certification, an ISO 27001 badge, or a DORA compliance attestation does not tell you how your team will actually perform under a live incident. Compliance frameworks assess the existence of controls, not the operational maturity of the people executing them. I have managed incidents at organisations that held all three certifications and took eleven days to contain a breach that should have been contained in forty-eight hours. The certification is a floor, not a ceiling.
What the Fastest-Responding Organisations Do
The organisations I have worked with that consistently sit in the Tested and Optimised bands do not necessarily have more security engineers or larger budgets. The differences are operational and cultural.
They declare incidents early and revise later
The Optimised organisations I know have a low threshold for incident declaration. If something is anomalous and the cause is not immediately understood, they declare an incident, spin up the response process, and downgrade it if the investigation shows it was benign. The cost of a false positive is a few hours of engineer time. The cost of a false negative — treating a real incident as a non-event — is measured in weeks of additional dwell time.
Reactive organisations do the opposite. They investigate until they are certain before declaring. By the time certainty arrives, the incident has been running for days.
They assign a named incident commander immediately
The lifecycle of a well-run incident response looks like this:
In every major incident, there is a moment when the response fractures — too many people, too many parallel investigations, too many Slack threads, no one synthesising. The Optimised organisations prevent this by assigning a named incident commander at the moment of declaration. Not a role anyone can volunteer into. A named rotation of people who have practised the role and have the authority to make containment decisions without seeking approval.
The incident commander's job is not to investigate. It is to coordinate — to hold the overall picture, direct the investigation threads, make the go/no-go calls on containment actions, and communicate status to stakeholders. In organisations without this role, those functions all happen informally, slowly, and with significant duplication.
They run tabletop exercises — on realistic scenarios
The tabletop exercise that most organisations run is a polite walkthrough of the incident response plan, conducted with the people who wrote it, using a scenario that doesn't stress-test the assumptions in the plan. It produces a comfortable sense of readiness.
The tabletop exercises that actually build capability are adversarial. They use realistic scenarios — ransomware at 11 PM on a Friday, a credential compromise discovered by a third-party notification rather than internal detection, a cloud misconfiguration that has been live for six months. They include people who are not deeply familiar with the plan. They surface the moments where the plan says "escalate to the security team" and nobody in the room knows who that is, or where the plan assumes log retention that doesn't exist.
I run these as part of engagement work, and the most common output is a prioritised list of gaps in the plan, the tooling, and the team's capability that was invisible before the exercise.
Their runbooks are specific, not generic
The generic incident response plan says "identify the scope of the compromise." The specific runbook for a cloud credential compromise says: pull CloudTrail logs for the last 72 hours for this credential, check for IAM role assumption events, check for resource creation in non-standard regions, disable the credential in Secrets Manager using this command, rotate the underlying service account using this procedure.
Specificity is what makes a runbook executable under pressure by someone who is not the person who wrote it. Generic plans require the responder to improvise the specifics while already under pressure. That improvisation is where time is lost.
The Self-Assessment That Reveals the Gap
If you want a quick calibration of where your organisation sits, answer these ten questions honestly.
| Question | Yes / No |
|---|---|
| Do you have a named incident commander rotation, with backups? | |
| Has your incident response plan been tested in a live drill in the last 12 months? | |
| Do you have a defined incident declaration threshold — criteria for when something becomes an incident? | |
| Are all production systems logging to a centralised SIEM with at least 12 months of retention? | |
| Do you have runbooks for your three most likely incident types, specific enough for an on-call engineer to execute? | |
| Can you identify all externally exposed services and their credential dependencies in under 30 minutes? | |
| Do you have an automated alerting policy that pages a named person within 15 minutes of a high-severity detection? | |
| Do you have a communication template for notifying affected customers within 72 hours of a confirmed breach? | |
| Have you run a post-incident review in the last 12 months that produced written, actionable findings? | |
| Do you know your current mean time to detect and mean time to contain from historical incidents? |
If you answered yes to fewer than six of those, you are operating with a response capability that is lower than you probably assume. That is not a character flaw — it is an extremely common position, and it is addressable. But it requires treating incident response as an operational discipline, not a compliance exercise.
The organisations that respond fastest are not the ones with the most security tooling
In every engagement where I have assessed incident response capability, the strongest predictor of response speed is not the sophistication of the security stack — it is the existence of a practised process with named owners. An organisation with a SIEM, an EDR, a CSPM, and an untested plan will consistently be outperformed by an organisation with moderate tooling and a response process that the team has drilled four times this year.
Where to Start
The highest-leverage investments in incident response capability, roughly in order:
First: Name your incident commander rotation. Three to five people, with a defined rotation, who have the authority to declare an incident and direct the response. This costs nothing except the time to have the conversation and write it down.
Second: Define your declaration threshold. Write down the criteria that turn "something anomalous" into "a declared incident." Be specific. Include examples.
Third: Run a realistic tabletop exercise. Use a scenario that stresses your actual assumptions. Invite someone external who does not already know how the plan is supposed to work. Document the gaps.
Fourth: Audit your logging coverage. Can you reconstruct a 90-day timeline of access for every production system? If not, where are the gaps?
Fifth: Write specific runbooks for your three most likely scenarios. Credential compromise, ransomware, data exfiltration. Specific enough for execution by someone who did not write them.
The investment in these five steps is measured in weeks, not quarters. The difference in response capability — and therefore in breach cost if an incident occurs — is measured in days of dwell time and hundreds of thousands of euros in containment and remediation costs.
The median breach-to-detection time of 194 days is not someone else's problem. It is the baseline your organisation is probably performing around, unless you have direct evidence otherwise. The gap between where most organisations are and where operationally mature ones are is not a tooling gap. It is a process and practice gap — and that is the more tractable problem.
If you want to understand where your incident response capability actually sits — not where you believe it sits — let's talk. I run structured incident response assessments and tabletop exercises as part of engagement work. Book a 30-minute discovery call and I can tell you within the first conversation what the most likely gaps are for your organisation type and size.