Before you can test a plan, you need one
What an incident response plan actually needs to contain.
Most companies write an incident response plan because a customer asked for it. That is a legitimate reason. The problem is that a plan written to answer a question, and never opened again, does not survive the first real incident or the first serious reviewer.
This page is what the plan needs, what you will be asked about it, and what to do once you have one. ControlDrill does not write your plan. We test it, and hand you the evidence that you did.
The questions you will actually be asked
These are verbatim from the questionnaires vendors get sent. They are worth reading before you write anything, because they tell you what the plan is for.
-
Do you have a formal incident response plan?
-
Do you either have an internal incident response team or retain an external team?
-
Do you have the capability to respond to incidents on a 24 x 7 x 365 basis?
-
Are these processes and procedures reviewed, updated, and tested at least annually?
What the plan has to contain
A plan that answers the questions above needs, at minimum:
-
Roles, by name
Who declares an incident, who runs it, who talks to customers, who talks to counsel. A plan that says "the security team" does not tell anyone what to do at 3am.
-
Severity levels with triggers
What makes something a Sev 1 rather than a Sev 3, written so two people would classify the same event the same way.
-
Contact and escalation paths
Including out of hours, and including the vendors you would need to reach.
-
Notification obligations and their clocks
Your contracts and your regulators both impose deadlines. The plan should state them, because nobody looks them up mid-incident.
-
Evidence and record keeping
What gets written down during an incident, and where it lives afterwards.
-
A review and test cadence
Annual is the common expectation. This is the clause most plans include and then do not honour.
Where to start if you have nothing
We do not sell you a template, and you do not need to buy one. The two most widely recognised public starting points are free:
-
NIST SP 800-61
The Computer Security Incident Handling Guide. Free from NIST, and the document most frameworks trace back to.
-
Your framework's own control text
If you are working toward SOC 2 or ISO 27001, the control wording tells you what the assessor expects the plan to address.
Adapt whichever you start from. A downloaded plan that names systems you do not run is worse than no plan, because it asserts a control you do not operate.
The part most plans fail
Having a plan and having tested it are two different questions, and you get asked both. An untested plan is a document. A tested plan is a capability, and the difference shows up the first time someone has to use it.
Testing is also where the evidence comes from. A reviewer asking whether you test annually is asking you to show them something: when it happened, who took part, what was decided. That artifact only exists if you actually ran the exercise.
You get the facts of the exercise; your auditor decides what they are worth. Running one is not by itself the control.
Once you have a plan, test it
ControlDrill runs a live tabletop grounded in your systems, people, and plan, and hands back an attributed evidence packet for $199.