The plan that only exists on paper
Almost every organisation has an incident response plan. Far fewer have one that would survive contact with a real incident. The document exists, it was written to satisfy an auditor or a policy requirement, and it has sat untouched in a shared drive ever since. When something actually happens, people either cannot find it or discover that it does not answer the questions that suddenly matter.
Incident response is one of the few areas of security where the gap between "we have a plan" and "we can respond" is enormous. Closing that gap is less about the document and more about the decisions and practice behind it.
Five ways IR plans fail
1. It has never been tested
A plan that has not been exercised is a hypothesis. The first time anyone runs it should not be during a live incident. Untested plans routinely fall apart on contact with reality: a step assumes access someone does not have, a contact has left, a system named in the plan was decommissioned a year ago.
2. Roles are unclear
In the pressure of an incident, ambiguity is expensive. If it is not explicit who declares an incident, who leads the response, who talks to the business, and who has authority to take systems offline, those decisions get made slowly or not at all. Clear roles, named in advance, are worth more than pages of procedure.
3. It assumes the tools will be available
Plans that depend on email, a wiki, or a chat platform quietly assume those systems are still working. In a ransomware event they may not be. A plan needs to account for how the team communicates and where it finds the plan itself when primary systems are down.
4. It stops at containment
Many plans cover detection and containment and go quiet on eradication, recovery, and the lessons afterwards. Getting the attacker out, restoring cleanly without reinfection, and learning from what happened are where much of the real work lives.
5. It ignores the non-technical response
A significant incident is not only a technical event. There are legal obligations, regulatory reporting timelines, customer communications, and often insurer involvement. A plan that only addresses the technical response leaves the organisation exposed on everything else.
"The measure of an incident response plan is not how thorough the document is. It is how quickly a stressed team can make good decisions at two in the morning. Everything in the plan should serve that."
Edge7 Networks, Security PracticeWhat a working plan contains
A plan that actually helps tends to be shorter and sharper than the ones that do not. The essentials:
- A clear definition of what counts as an incident, and who can declare one.
- Named roles and an escalation path, with deputies for when people are unavailable.
- Severity levels that map to defined response actions, so the reaction matches the event.
- Out-of-band communications: how the team coordinates if primary systems are down.
- Contact details that are kept current: internal, provider, legal, insurer, and regulator.
- The full lifecycle: detection, containment, eradication, recovery, and post-incident review.
Know your clock before the incident, not during it
Regulatory regimes increasingly impose short notification windows. NIS2, for example, expects an early warning within 24 hours of awareness of a significant incident. If the first time your team reads that requirement is mid-incident, the clock is already working against you. Build the relevant timelines into the plan itself.
Why testing is the whole point
The single highest-value activity in incident response is the tabletop exercise: walking the team through a realistic scenario and watching where the plan holds and where it breaks. Every exercise surfaces gaps that were invisible on paper, and each one builds the muscle memory that makes a real response faster and calmer. A plan tested twice a year is worth more than a far longer document that has never been opened.
A plan needs detection behind it
Response only begins once you know something is wrong. A well-written plan attached to poor detection means you are ready to act on incidents you cannot see. This is where response planning and detection and response meet: the plan defines what happens after an alert, and the monitoring determines whether that alert ever arrives. The two are halves of the same capability, and investing in one without the other leaves a predictable gap.
Where to start
If your plan has not been tested in the last year, that is the place to begin, not a rewrite. Run a tabletop against a realistic scenario, note where it struggles, and fix those specific weaknesses. A short, current, exercised plan beats a comprehensive one nobody has read.
Edge7 Networks works with IT teams across Ireland and the UK on incident response planning, tabletop exercises, and the detection that makes a plan usable. If you want to know whether yours would hold up, a tabletop is the most revealing first step.