← Back to Security

Incident Response Plan: How to Respond to a Cyberattack

A cyberattack happens every 39 seconds globally. Without a documented incident response plan, organizations waste critical hours deciding what to do next. An effective plan reduces breach damage by 73%, contains threats faster, and preserves evidence for forensic investigation. Here's how to build and execute one.

What Is an Incident Response Plan?

An incident response plan (IRP) is a documented, step-by-step process for detecting, analyzing, containing, and recovering from security incidents. It's not optional—it's a control requirement under NIST Cybersecurity Framework, ISO 27035, and regulations like HIPAA, PCI-DSS, and GDPR.

The plan should cover everyone from the security team to C-level executives. It defines roles, communication protocols, decision trees, and tools needed when an attack occurs. Most attacks succeed because organizations don't know who to contact or what to do in the first 60 minutes.

The Five Phases of Incident Response

1. Preparation

Before an attack happens, you need infrastructure and people in place. This phase includes:

• Deploying EDR (Endpoint Detection and Response) and SIEM tools for continuous monitoring
• Creating an incident response team with defined roles: IR lead, forensics analyst, communications officer, legal counsel, and system administrators
• Documenting contact lists for internal teams and external vendors (forensics firms, law enforcement, ISPs)
• Setting up isolated lab environments to test malware safely
• Backing up critical systems and maintaining offline copies
• Conducting tabletop exercises quarterly to test the plan

Preparation also means hardening your systems before an attack occurs. Implement network segmentation, multi-factor authentication, and principle of least privilege. The fewer paths an attacker has through your network, the faster containment becomes.

2. Detection and Analysis

This is where speed matters most. Detection tools can identify suspicious activity, but analysis determines severity. Common detection signals include:

• Alerts from antivirus, EDR, or SIEM systems
• Unusual network traffic patterns (data exfiltration, lateral movement)
• Failed login attempts or privilege escalation attempts
• User reports of unusual behavior
• Ransomware notes appearing on systems

When an alert fires, the on-call analyst must confirm it's a real incident, not a false positive. Document everything: what was detected, when, on which systems, and what triggered it. Create an incident ticket with a unique ID and severity rating (Critical, High, Medium, Low). This ticket becomes your investigation log.

Severity classification guides your response speed. A critical incident (active data theft, ransomware encryption) requires immediate escalation. A medium severity incident (suspicious login from new IP) might warrant closer monitoring before full IR activation.

3. Containment

Containment stops the attack from spreading. It happens in two stages:

Short-term containment (within 1 hour): Isolate affected systems from the network immediately. For ransomware, disconnecting infected machines before encryption spreads is critical. For data breaches, stopping data exfiltration takes priority.

# Example: Isolate a compromised host
# Windows
netsh interface set interface "Ethernet" disabled

# Linux
sudo ip link set eth0 down

# macOS
networksetup -setairportpower en0 off

Long-term containment (within hours to days): Patch vulnerabilities the attacker exploited, reset credentials (especially for compromised accounts), revoke API keys, and update firewall rules to block known attacker infrastructure. Preserve evidence before making changes—a forensic image taken before patches might reveal attack details.

Containment is where communication matters. Notify stakeholders: IT leadership, affected department heads, legal, and PR teams. Never announce a breach to customers until you understand its scope—premature disclosure causes panic.

4. Eradication and Recovery

Once contained, you remove the attacker and restore systems. This includes:

• Wiping infected systems clean with fresh OS installations or forensic restoration
• Patching all vulnerabilities the attacker used
• Forcing password resets for all users, especially administrators
• Restoring from clean backups (verified to be malware-free)
• Monitoring systems closely for 2-4 weeks for re-infection
• Updating network access controls to prevent re-entry

Test systems in isolation before bringing them back online. If you restore a backup that's still infected, you've just re-infected your network. Verify clean backups exist from before the compromise—date them carefully.

For ransomware, eradication means removing all malware variants, not just decrypting files. Attackers often hide persistence mechanisms (backdoors, web shells) designed to re-encrypt if you only pay and restore.

5. Post-Incident Activities

This phase happens after systems are recovered. It's critical for preventing repeat attacks:

• Conduct a full forensic investigation: Determine how the attacker got in, what systems they touched, how long they were present, and what data they accessed
• Create an incident report: Document timeline, attack vectors, impact, remediation steps, and lessons learned
• Notify affected parties: Under GDPR, CCPA, and other laws, you must notify users if their personal data was exposed within 30-72 hours
• Report to authorities: Some regulations require notification to law enforcement or regulators
• Hold a blameless postmortem: Team meeting to discuss what failed, what worked, and what to improve—without assigning blame
• Update the IRP based on findings: If the attacker got in through an unmonitored port, add monitoring. If they escalated via a forgotten admin account, enforce better account hygiene

Building Your Incident Response Plan Template

Here's what your documented plan should contain:

INCIDENT RESPONSE PLAN - TEMPLATE

1. INCIDENT RESPONSE TEAM
   - IR Lead: [Name, Phone, Email]
   - Forensics Lead: [Name, Phone, Email]
   - Communications Lead: [Name, Phone, Email]
   - Legal Counsel: [Name, Phone, Email]
   - IT Operations: [Team contact]
   - Executive Sponsor: [Name, Title]

2. SEVERITY CLASSIFICATIONS
   CRITICAL: Active breach, data exfiltration, ransomware
   → Response time: 15 minutes
   → Escalation: CEO, Board, Law Enforcement
   → Decision: Possible public disclosure within 72 hours

   HIGH: System compromise, unauthorized access
   → Response time: 1 hour
   → Escalation: CTO, Chief Risk Officer

   MEDIUM: Suspicious activity, failed attacks
   → Response time: 4 hours
   → Escalation: Security Manager

   LOW: Policy violations, minor anomalies
   → Response time: Next business day
   → Escalation: Department Manager

3. EXTERNAL CONTACTS
   - Law Enforcement: [FBI Field Office, Local PD]
   - Forensics Firm: [Company, 24/7 number]
   - ISP/Cloud Provider: [Emergency contact]
   - Insurance Broker: [Contact]
   - Public Relations: [Spokesperson, Media contacts]

4. EVIDENCE PRESERVATION
   - Capture volatile memory (RAM) before shutdown
   - Collect logs: firewall, DNS, proxy, SIEM, EDR
   - Create forensic images of compromised systems
   - Chain of custody: Document who handled evidence, when

5. COMMUNICATION PROTOCOL
   - Internal: Slack #incident-response channel (monitored 24/7)
   - Escalation: Phone tree for critical incidents
   - External: Legal counsel approves all customer/press statements
   - Documentation: All decisions logged in incident ticket

6. RECOVERY PROCEDURES
   - Clean OS installations from verified media
   - Restore from clean backups (> 1 week old)
   - Re-credential all accounts
   - Network re-segmentation
   - 30-day enhanced monitoring

Common Mistakes in Incident Response

Not activating the plan early enough: Teams wait until damage is obvious, wasting hours. If there's even a 30% chance it's a real incident, activate the plan. False alarms are cheaper than breaches.

Not preserving evidence: Once you touch a system, you change it. Take forensic images before doing anything. You might need evidence for law enforcement or litigation later.

Delaying notifications: Legal worry causes delays. Work with counsel beforehand to draft notification templates so you can notify promptly under regulations.

Assuming backups are clean: Verify backups regularly. Test restoration quarterly. If you've been compromised for 3 months undetected, your backups are infected.

Not updating the plan: If your plan references systems you decommissioned 2 years ago, it's worthless. Review it annually. Update it whenever your infrastructure changes.

Tools You'll Need

Preparation requires tooling. You need:

• SIEM (Security Information and Event Management): Splunk, Datadog, Microsoft Sentinel—centralizes all logs and alerts
• EDR (Endpoint Detection and Response): CrowdStrike, Microsoft Defender for Endpoint, SentinelOne—detects malware and lateral movement
• Network monitoring: Zeek, Suricata—captures and alerts on suspicious traffic
• Forensics tools: EnCase, FTK, Volatility—analyzes compromised systems and memory
• Incident ticketing: Jira, ServiceNow—tracks investigation progress

You don't need everything on day one. Start with a SIEM or log aggregation, add EDR, then expand. The key is having centralized logging so you can reconstruct what happened during an incident.

Testing Your Plan

A plan that hasn't been tested doesn't work. Run tabletop exercises every quarter where you walk through a scenario without touching production systems. Ask: "If ransomware encrypted our database servers right now, who calls who? What do we restore from? How long until we're back online?"

Once yearly, run a simulated incident in your lab. Inject a fake malware alert, activate the team, and measure response time. Did someone forget which tool to use? Did a key contact not answer? Fix it now, not during a real incident.

Schedule a full IR tabletop with executives included. C-level decisions (like notifying the board or paying ransom) need rehearsal. When a real breach happens at 2 AM, you won't have time to explain the incident response plan to the CEO.

Legal and Compliance Considerations

Your incident response plan must account for regulations in your industry and jurisdiction:

• GDPR (EU): Notify authorities and affected individuals within 72 hours of discovering a personal data breach
• CCPA (California): Notify California residents of breaches without unreasonable delay, but no specific timeline specified
• HIPAA (Healthcare): Notify affected individuals and HHS within 60 days of discovering a breach of unsecured protected health information