Incident Response Plan

Security incidents arrive at inconvenient hours. A customer writes on a Friday night to say one of their staff accounts shows a strange login, and a look at the admin console turns up an unfamiliar session. At a company with no plan, the first thing that happens is not investigation. It's a phone tree.

The scene runs like this. Whoever noticed tells a manager, the manager asks the founder, and the founder asks back whether the service should be taken down. Nobody ever decided who holds the authority to take it down, so nobody can answer. One person argues for telling customers immediately, another for finishing the investigation first. Three hours pass, the attacker is still inside, and the legal clock keeps running — for personal data breaches, many jurisdictions count that deadline in hours rather than days.

An incident response plan moves that argument to a calm day. Write down who decides, who notifies, and by when, and the day of the breach becomes a matter of opening the document and working through it. Not having to decide in the moment is how the plan buys time. The hours it saves are the hours the attacker would otherwise have spent inside the system unopposed, and they are also the hours that separate a notification sent on schedule from one that arrives late enough to become its own problem.

A usable plan covers at least six things, and every one of them is written as a name or a number. Phrases like "promptly" or "the relevant team" don't survive contact with a real incident.

1. Declaration criteria. What counts as a security incident, and at what level. One compromised staff account and a full customer database export are not the same event, and the level drives everything below.
2. Roles and names. The person who runs the response, the person authorized to take the service offline, the person who notifies customers and regulators, the person who handles press. Job titles alone stall the plan on the day that seat is empty, so each role gets a named backup.
3. The response procedure. Detect, contain, preserve evidence, recover, prevent recurrence — split into stages with tasks under each. Evidence preservation sits between containment and recovery for a reason: wipe the server and rebuild it in a hurry and you lose any way of knowing how it was breached.
4. Notification targets and deadlines. Customers, regulators, and enterprise accounts with contractual clauses, each with a stated number of hours. Draft wording belongs here too. Written from scratch on the day, a customer notice takes half a day just to get reviewed.
5. Contact lists. Responders, the external security firm, outside counsel. Keep a copy somewhere that survives internal systems being locked — on paper or in a separate location.
6. Testing and maintenance. How often the plan is rehearsed, and who updates it when the organization changes.

The early stages lean on an asset inventory. Unless the systems and data worth protecting are already listed in one table, there's no way to count what was affected on the day. A system missing from the list is also missing from the investigation. The gaps are rarely servers; they are the tools individual teams signed up for on a company card, each holding some slice of customer data nobody has catalogued.

The author is whoever owns security. At a company of a few dozen people there's often no dedicated owner, so the head of engineering carries it. It isn't written alone. Notification deadlines and wording get reviewed by counsel, and anything with business consequences — taking the service offline, for instance — gets approved by the founder. Where a security policy sets the rules for ordinary days, this document covers the day those rules fail.

Readers fall into four groups. First, the responders. Someone woken at 3 a.m. has to find the next action on one screen, which is why contacts and the first thirty minutes go at the front. Second, executives, because the irreversible calls — downtime, customer notification — are written here and need agreement before the incident, not during it. Third, enterprise customers, who routinely ask for the plan during security review before signing. Fourth, auditors for a security certification, who check not only that the document exists but that it was updated recently and that rehearsal records exist. A plan with no rehearsal log reads to an auditor as a plan nobody has tested, which is the same as a plan nobody can rely on.

"The plan says we notify within 24 hours and we're eighteen hours in."

Six hours remain to make the notification call.

"Let's run the plan once this quarter. Start by checking the contact list."

A proposal to rehearse the document against a realistic scenario and find what's gone stale.

"Their security review asked us to submit our incident response plan."

The deal needs this document, and its contents will be read.

At Pagedeck, Sofia was the first to be asked for one, during a deal with an enterprise account. There was no plan at the time, so Grace and Theo spent two days on a draft. Most of what slowed them down was authority. Nobody had settled who decides to take the service offline, or whether customers get told before the cause is understood.

Six months later an access review turned up repository access still open for a contractor who had finished months earlier. Nothing had leaked, but the team ran the plan end to end anyway. Two of the phone numbers on the contact list had already changed.

The most common mistake is treating the document as the response. Audits ask for the file, so producing it starts to feel like the goal. But a plan is only useful on the day if the contacts are current and the authority it describes matches the organization that exists. Write one and leave it for two years and half the named people have left. That's why rehearsal — the same habit behind a phishing drill — belongs in the plan itself.

Treating it as a security team document is the other common miss. The title says security, which makes the assumption natural. Yet the first decisions the plan needs aren't technical: whether to take the service down, and when to tell customers. Both are business calls, and a line written without that approval simply won't be followed at 3 a.m. The practical fix is to walk the founder and the sales lead through the two or three irreversible decisions once, while nothing is on fire, and record their agreement in the document itself.