The Breach Will Not Wait for You to Find the Playbook

It was 11:47pm on a Wednesday

The message came from the on call engineer, not through the alerting system, not through the SIEM, or through any of the monitoring infrastructure that was supposed to catch exactly this kind of thing. It came through WhatsApp. A six word message that nobody in leadership wanted to receive.

Something is wrong with the production database.

What followed was four hours that the CTO would later describe, with the exhausted clarity of someone who has been through something they will never forget, as the most expensive education of his professional life. Not because the incident was sophisticated. Not because the attacker was particularly skilled. But because the organisation was not ready, and not ready, it turned out, looked nothing like what anyone had imagined.

Nobody could find the incident response plan. Not because it did not exist. Because it existed as a Google Doc that three people had bookmarks for and none of them were online. The engineer who managed the cloud infrastructure was on annual leave. The contact list for the legal team was in a spreadsheet on the Head of Security's work laptop, which was at home. The communication template for customer notification, the one that had been drafted six months ago specifically for this scenario had never been approved and nobody remembered who was supposed to approve it.

They improvised, kept the lights on, contained the incident by 3am and restored service by 5am. They sent a customer notification that was written in a moving car, reviewed by one person, and sent at 6:15am by someone who had not slept. The technical response was adequate. Everything around it was chaos, and in the forensic review that followed, the one every organisation should do after an incident and most do not do rigorously enough, the finding that mattered most was not about the vulnerability that was exploited. It was about the organisation's complete lack of readiness to respond.

The breach, when it came, did not wait for them to find the playbook and yours will not wait either.

The Incident Response Plan That Lives in a Drawer

Let me ask you a direct question, If your organisation experienced a significant security incident tonight not a theoretical future incident, but a real one, right now, at midnight, what would happen in the first thirty minutes?

Who would be notified, and through what channel? Who would make the decision to convene the response team? Who has the authority to take systems offline if containment requires it? Who owns the communication to affected customers, and what does that communication say? Who notifies your legal team, your insurers, and the regulators who require notification within seventy-two hours under GDPR?

Most growing startups have answers to some of these questions. Very few have answers to all of them. And the ones who have answers to all of them, but have not tested those answers under pressure, often discover in the moment that the answer they had on paper is not the answer that functions at midnight when the adrenaline is high and the information is incomplete and three people are talking at once in a Zoom call that nobody remembered to record.

Incident response plans are one of the most common documents in the enterprise security toolkit and one of the most consistently inadequate ones. Not because organisations do not write them. But because there is a specific kind of readiness that no document produces and that specific kind of readiness is the only thing that matters when the incident is real.

What an Incident Actually Looks Like From the Inside

There is a version of a security incident that exists in training materials and tabletop exercise scenarios. It is orderly, the detection happens cleanly. The scope is clear, the right people are available. The decisions are made logically and in sequence. The playbook is followed and the incident is resolved.

Then there is what actually happens.

Detection is almost never clean. The first signal is usually ambiguous, a performance anomaly, a failed login pattern, an alert that fires so regularly it has been partially tuned out, an engineer who notices something that does not look quite right but is not certain enough to escalate immediately. The time between the initial signal and the recognition that something is actually wrong is, in most real incidents, measured in hours, sometimes days.

Scope is almost never clear at the start. You know something is wrong. You do not know how wrong, how widely, or for how long. The decisions you need to make in the first hour, containment actions that may preserve evidence or destroy it, communication decisions that may be premature or dangerously delayed, escalation decisions that will define the response structure, all of them must be made with incomplete information, under time pressure, by people whose judgment is being asked to function under conditions it was not designed for.

The right people are almost never all available. Incidents happen at midnight, on public holidays, during annual leave, during the week the Head of Security is at a conference. The backup contact for the cloud infrastructure engineer may never have been tested. The legal team contact may be the main partner's direct line, which goes to voicemail at night and is checked the following morning.

The playbook, if it exists and can be found, describes a scenario that the actual incident does not quite match. Because incidents do not follow playbooks. They follow their own logic, which is shaped by your specific architecture, your specific threat actor, your specific data exposure, and a hundred variables that no generic playbook accounts for. And the people in the room or on the call, or in the WhatsApp group that was formed because nobody had established the proper communication channel, are doing their best under conditions that most of them have never trained for.

This is what an incident looks like from the inside and the organisations that navigate it well are not the ones with the best playbook. They are the ones who have trained for the chaos, not just the scenario.

The Four Gaps That Make Incident Response Fail

After studying how organisations respond to security incidents, what goes well, what breaks down, and what the forensic reviews consistently identify as the preventable failures, four gaps appear more consistently than any others.

The detection gap: The average time between initial compromise and detection in a data breach is, according to most industry benchmarks, measured in weeks, not hours, weeks. The attacker is inside the environment, moving laterally, identifying valuable data, establishing persistence, and preparing for exfiltration while the organisation's monitoring systems either do not detect the activity or generate alerts that are not actioned promptly.

The detection gap exists for several reasons. Logging is not configured comprehensively enough to capture the signals that matter. Alerts are tuned for performance rather than security, creating noise that trains responders to deprioritise them. There is no baseline of normal behaviour against which anomalous behaviour can be compared. The people responsible for monitoring do not have the context to distinguish a genuine threat signal from operational noise. Closing the detection gap requires investment in logging architecture, alert tuning, and the human capacity to investigate signals before they become incidents.

The decision gap: In the first hour of an incident, decisions need to be made by someone with the authority to make them. Who that someone is, what decisions fall within their authority, and what decisions require escalation, these questions need to have answers before the incident happens, because during the incident there is no time to establish the answer and no consensus process that functions under pressure.

The decision gap manifests as paralysis: the response team knows what action probably needs to be taken but cannot take it without approval from someone who cannot be reached. Or it manifests as conflict, two people with overlapping authority make contradictory decisions and the response team does not know which one to follow.

Closing the decision gap requires a clear, documented, tested incident command structure, with named individuals, their backup contacts, their defined authority, and the escalation path that governs decisions they cannot make alone.

The communication gap: Incident communication is one of the most consequential and most consistently underprepared aspects of incident response. Three separate communication streams need to be managed simultaneously: internal communication within the response team, executive and board communication that keeps leadership informed and enables resource decisions and external communication to customers, partners, regulators, and potentially the public.

Each of these streams has different requirements, different audiences, different timing pressures, and different risks of getting it wrong. Internal communication that is too broad creates panic and leaks. Executive communication that is too sparse leaves leadership making decisions without adequate information. Customer communication that is delayed, vague, or defensive damages trust in ways that the incident itself may not have. Regulatory notification that misses the seventy-two hour window under GDPR creates a compliance violation on top of the security incident.

Closing the communication gap requires pre-approved templates, defined communication owners for each stream, and a clear decision framework for when each type of communication is triggered.

The evidence gap: Security incidents produce evidence. Log files, network traffic captures, memory dumps, forensic images of compromised systems, the data that will be essential for understanding what happened, how it happened, who was responsible, and what needs to change to prevent recurrence.

Most organisations do not preserve this evidence adequately. In the rush to restore service, compromised systems are rebuilt rather than imaged. Logs are not captured before retention windows expire. Actions taken during the response, the commands run, the configurations changed, the access granted and revoked are not documented in real time. By the time the forensic review begins, the evidence needed to answer the most important questions is gone.

Closing the evidence gap requires a forensic first policy, the explicit understanding that evidence preservation is the first priority of incident response, before service restoration, and that service restoration happens from clean systems, not rebuilt compromised ones.

What Incident Response Readiness Actually Looks Like

I want to be specific about what it means to be ready because readiness is not a document and it is not a checkbox.

A tested incident command structure: Names, backup contacts, defined authority, escalation paths. Tested by running an actual tabletop exercise in which the team works through a realistic scenario, discovers the gaps in the structure, and closes them. Not read, not discussed, but tested.

Logging and monitoring architecture that supports detection: Comprehensive logging across your cloud environment, your identity systems, your network, and your endpoints. Retention periods that support investigation. Alerting that is tuned for security signals, with a clear owner for each alert category and a documented response procedure for each alert type.

Pre-approved communication template:. Customer notification, regulatory notification, media statement, internal announcement drafted in advance, reviewed by legal, approved by leadership. The incident is not the time to write these. It is the time to fill in the specific details and send them.

An evidence preservation protocol: The explicit, documented first step of incident response is: preserve evidence before taking any other action. This means capturing logs, imaging affected systems, and documenting every action taken before anything is changed, rebuilt, or restored.

A retainer with an external incident response firm: For most growing startups, an external incident response capability is more practical than a fully staffed internal one. A retainer agreement means that when an incident happens, you have access to experienced responders who know your environment because the retainer includes an initial assessment and who can be engaged immediately rather than discovered through a Google search at midnight.

Regular testing: Tabletop exercises at least annually. Purple team exercises if your maturity supports them. Lessons learned reviews after every significant alert, not just after confirmed incidents. The capability degrades without exercise, and the gaps that the last exercise did not reveal are exactly the ones the next incident will expose.

The Conversation That Needs to Happen Before the Incident

I want to close with the conversation that most leadership teams have not had, and that has a different quality when it happens before the incident than when it happens during it.

The conversation is about what the organisation is willing to do in the first hour. Whether the Head of Security has the authority to take systems offline without board approval. Whether the organisation's first priority is service restoration or evidence preservation when the two are in tension. Whether the legal team has been briefed on the organisation's incident response posture and is prepared to move quickly when called. Whether cyber insurance has been reviewed for what it covers, what it excludes, and what notification requirements it imposes.

These are not comfortable conversations. They involve imagining scenarios that leadership would prefer not to imagine, making decisions that feel premature, and committing resources to a capability that, if the organisation is lucky, it will never need to deploy at full scale.

They are also the conversations that determine whether the incident that comes, and in most organisations, an incident of some significance is a question of when, not if , is managed as a crisis or navigated as a challenge.

The organisations that navigate it as a challenge had the conversation before the breach.

The ones that experienced it as a crisis had not.