Quick Answer
Yes. When (not if) you have a security incident, you need to know who does what, how to contain damage, and how to communicate. Making it up during a crisis leads to mistakes, delays, and worse outcomes. A plan doesn't prevent incidents—it reduces their impact.
Quick answer: Yes. When (not if) you have a security incident, you need to know who does what, how to contain damage, and how to communicate. Making it up during a crisis leads to mistakes, delays, and worse outcomes. A plan doesn't prevent incidents—it reduces their impact.
Why You Need One
Incidents are inevitable
No security is perfect. Even well-protected organisations experience incidents. The question isn't whether, but when.Chaos costs money
Without a plan:- Delays in response (damage increases)
- Wrong decisions under pressure
- Communication failures
- Evidence destroyed accidentally
- Regulatory timelines missed
- Recovery takes longer
Regulators expect it
- ICO expects documented incident response
- ISO 27001 requires incident management
- NIS2/CAF mandate incident procedures
- Cyber insurance often requires it
It's required for compliance
Many frameworks specifically require incident response capability:- ISO 27001: A.16 Information security incident management
- Cyber Essentials: Incident response questions in Plus
- NIS2: Incident handling requirements
- GDPR: 72-hour breach notification
What a Plan Should Include
1. Incident classification
Define what's an incident:- Severity levels (critical, high, medium, low)
- Examples of each level
- Escalation triggers
- Critical: Ransomware, active breach, data exfiltration
- High: Malware detected, suspected compromise
- Medium: Phishing click (no confirmed compromise)
- Low: Blocked attack, policy violation
2. Roles and responsibilities
Who does what:- Incident commander: Overall coordination
- Technical lead: Technical investigation and containment
- Communications lead: Internal and external communications
- Legal/compliance: Regulatory obligations
- Business lead: Business impact decisions
3. Response procedures
Phase 1: Detection and analysis- How to identify incidents
- Initial triage
- Evidence preservation
- Scope assessment
- Isolate affected systems
- Prevent spread
- Preserve evidence
- Remove threat
- Identify root cause
- Patch vulnerabilities
- Restore systems
- Verify clean state
- Return to normal operations
- Post-incident review
- Documentation
- Improvements identified
4. Communication templates
Pre-drafted communications:- Internal notification
- Customer notification
- Regulatory notification
- Press statement (if needed)
- Partner/supplier notification
5. External contacts
Who you might need:- Cyber insurance claims line
- Legal counsel
- Forensics provider
- PR/crisis communications
- Law enforcement
- ICO (if breach)
- Industry regulator
6. Technical procedures
Specific runbooks:- Ransomware response
- Business email compromise
- Data breach
- Malware outbreak
- Account compromise
How to Create One
Start simple
A basic plan is better than no plan. You can improve it over time.Base on frameworks
NIST Incident Response, ISO 27035, SANS provide proven structures.Involve stakeholders
IT can't create this alone. Legal, HR, communications, business units need input.Test it
Plans untested are assumptions. Tabletop exercises reveal gaps.Keep it updated
Contacts change. Systems change. Review at least annually.What We Provide
We help clients develop and test incident response:
Plan development:
- Templated framework customised to your organisation
- Roles and responsibilities defined
- Communication templates created
- Runbooks for common scenarios
- Tabletop exercises
- Findings and improvements
- Regular review and updates
- When incidents occur, we're there
- Technical investigation
- Containment and recovery
- Coordination with external parties
---
about preparation and response.
---