A cyber security incident is not a matter of “if” but “when.” Having a documented incident response plan means the difference between a contained event and a catastrophic breach. An incident response plan (IRP) is a structured approach to detecting, containing, eradicating, and recovering from security incidents.
Why You Need an Incident Response Plan
Without a plan, teams panic during incidents. Decisions are made hastily, evidence is accidentally destroyed, communications are inconsistent, and recovery takes far longer than necessary. A well-rehearsed IRP reduces response time, minimises damage, preserves forensic evidence, meets regulatory requirements (the DPDP Act requires prompt breach notification), and protects your reputation.
Phase 1: Preparation
Preparation is the foundation. Assemble your incident response team — define who is responsible for detection, analysis, containment, communication, and recovery. This typically includes IT/security staff, legal counsel, communications/PR, and senior management. Document contact information including personal phone numbers for out-of-hours incidents.
Equip your team with the tools they need: security monitoring (SIEM), endpoint detection and response (EDR), forensic imaging tools, and a secure communication channel that does not depend on your primary infrastructure (since that might be compromised).
Phase 2: Detection and Analysis
Define what constitutes an incident. Not every alert is an incident — establish clear criteria. Categorise incidents by severity: Level 1 (minor — single compromised account), Level 2 (moderate — malware on multiple systems), Level 3 (critical — data breach or ransomware). Each level should trigger a different response intensity.
Document your detection sources: firewall logs, antivirus alerts, user reports, SIEM correlations, cloud security alerts, and external notifications (such as a security researcher or law enforcement contact). Create runbooks for common scenarios — what to check first when you suspect phishing, ransomware, or data exfiltration.
Phase 3: Containment
Containment prevents the incident from spreading. Short-term containment isolates affected systems immediately — disconnect from the network, disable compromised accounts, block malicious IP addresses. Long-term containment applies temporary fixes that let business operations continue while you prepare for eradication — patching vulnerable services, applying firewall rules, rotating credentials.
Critical rule: do not wipe or rebuild systems before preserving forensic evidence. Take disk images and memory dumps before any cleanup. This evidence is essential for understanding the attack, meeting legal obligations, and preventing recurrence.
Phase 4: Eradication
Remove the root cause. This might mean removing malware, closing the vulnerability that was exploited, revoking compromised credentials, rebuilding affected systems from clean backups, or patching the software flaw. Simply removing the malware is insufficient if the entry point remains open — the attacker will return.
Phase 5: Recovery
Restore systems to normal operations. Rebuild from known-good backups or clean installations. Monitor restored systems closely for signs of persistent compromise. Gradually restore access and services, testing each component before bringing it back online. Define clear criteria for what “recovered” means — all systems patched, all credentials rotated, monitoring enhanced, and no signs of ongoing compromise for a defined observation period.
Phase 6: Lessons Learned
Within two weeks of resolving every significant incident, conduct a post-incident review. What happened? When and how was it detected? What worked well in the response? What did not? How can you prevent similar incidents? Update your IRP, detection rules, and security controls based on these findings. This phase is where your security posture actually improves — do not skip it.
Testing Your Plan
An untested plan is unreliable. Conduct tabletop exercises quarterly — walk through a scenario verbally with your response team. Run a simulated incident annually — inject a realistic scenario and measure response time, decision quality, and communication effectiveness. Update your plan after every test and every real incident.
