Incident Response Plan Development
Assessment of your current plan or development of a new one — with procedures someone can execute at 3 a.m., not a document written for an audit.
- Who it is for
- Organizations with no formal plan, with an inherited plan nobody has tested, or that need to satisfy a requirement from their insurer, a regulator, or a corporate customer.
- Typical duration
- 3 to 6 weeks
- Frameworks
- NIST SP 800-61r3ISO/IEC 27035SANS PICERL
There are two kinds of incident response plan: the one written to pass an audit, and the one someone can open at three in the morning on a Sunday and know what to do with. We write the second kind.
How to recognize a plan that does not work
- It runs past sixty pages and contains no actionable checklist.
- It says “notify stakeholders” with no names, no phone numbers, and no deadlines.
- It assumes corporate email and internal chat will be working during the incident.
- It does not define who has authority to disconnect production without asking permission.
- It has never been tested.
- It is stored on the file server that ransomware also encrypts.
What a plan that does work includes
Scenario playbooks. Ransomware, business email compromise, data exfiltration, denial of service, compromised privileged credentials, malicious insider. Each with its first steps already defined.
Explicit decision authority. A serious incident produces expensive decisions under time pressure. Who can make them is settled beforehand, not during.
Pre-approved communications. Templates for customers, staff, press, and regulators, reviewed by your legal counsel in advance. Drafting the first statement during the crisis reliably produces the worst possible statement.
Regulatory triggers. When notification is required and within what window, according to the regulations that apply to you — including personal data protection in Costa Rica and the foreign regimes that reach your customers.
Out-of-band operation. Printed copies, contacts on personal phones, an agreed alternate communication channel. If the plan exists only inside the compromised network, it does not exist.
The plan and the exercise go together
A new, untested plan is a well-formatted hypothesis. That is why we close development with a tabletop exercise: it is where the wrong assumptions surface, while correcting them is still cheap.
How we run it
- 01
Diagnosis
If you already have a plan, we assess it against real scenarios. The question is not whether the document exists, but whether anyone could execute it under pressure.
- 02
Scenario modeling
We identify the incidents most likely for your sector and technology. A generic plan fails precisely on the details that matter.
- 03
Procedure drafting
Actionable playbooks per scenario, with concrete steps and pre-made decisions, not general principles.
- 04
Role definition
Who decides to take production offline. Who speaks to the press. Who notifies the regulator and within what deadline. With alternates, because incidents do not respect vacation schedules.
- 05
Validation
We test the plan in a tabletop exercise before calling it finished. An untested plan is a hypothesis.
What you receive
- Incident response plan adapted to your structure, size, and technology
- Playbooks for the scenarios most likely in your context
- Escalation matrix with roles, owners, and named alternates
- Out-of-band contact tree and pre-approved communication templates
- Severity classification criteria and regulatory notification triggers