Incident Response Plan

The worst time to figure out your incident response process is during an actual incident. An incident response plan establishes roles, communication channels, and procedures before anything goes wrong. Teams with rehearsed plans contain breaches faster, reduce damage, and recover more predictably than those improvising under pressure.

Why You Need a Plan

When a security incident occurs, adrenaline is high and thinking is impaired. People make mistakes under pressure — they wipe evidence, notify the wrong people, or freeze entirely. A documented plan removes decision-making from the moment of crisis and replaces it with practiced procedures.

The 2017 Equifax breach exposed 147 million records. Post-incident analysis revealed that the company had no clear incident response procedures, no designated response team, and no practiced communication plan. The result was a chaotic response that compounded the damage through delayed notification, contradictory public statements, and a remediation website that itself had security flaws.

The Incident Lifecycle

Every security incident follows a predictable lifecycle. Your plan should address each phase.

Detect

Something triggers awareness. It might be an automated alert, a user report, a third-party notification, or a news article about a vulnerability affecting your stack. Detection speed varies dramatically — the industry average for breach detection is still measured in months.

Contain

Stop the bleeding. The goal is to limit the incident's scope without destroying evidence. Containment actions include isolating affected systems, revoking compromised credentials, and blocking attacker IP addresses.

Eradicate

Remove the threat completely. This means finding and closing the vulnerability that allowed the breach, removing any backdoors the attacker installed, and verifying that no persistence mechanisms remain.

Recover

Restore systems to normal operation. This includes rebuilding compromised systems from known-good images, restoring data from backups, and gradually returning services to production with enhanced monitoring.

Learn

Conduct a post-incident review. Document what happened, what went well, what went poorly, and what changes will prevent recurrence. Update the incident response plan based on lessons learned.

Severity Classification

Not every security event is a crisis. A clear severity system prevents overreaction to minor issues and underreaction to major ones.

P1 - Critical

Active data breach, widespread system compromise, ransomware, or any incident involving customer data exposure. All hands on deck. Leadership notified immediately. External communications prepared.

Examples:
- Database with customer PII accessed by unauthorized party
- Ransomware encrypting production systems
- Attacker with persistent access to production environment
- Compromised authentication system allowing account takeover

P2 - High

Confirmed vulnerability being actively exploited, compromise of internal systems without customer data exposure, or significant service degradation due to security incident.

Examples:
- Internal admin panel compromised
- Cryptominer deployed on production servers
- Successful phishing attack against employee with elevated access
- API key leaked publicly, no confirmed abuse yet

P3 - Medium

Vulnerability discovered but not yet exploited, suspicious activity under investigation, or minor security policy violation.

Examples:
- Critical CVE affecting a production dependency
- Unusual login patterns from a service account
- Employee accessing systems outside their role
- Failed brute-force attempt against admin login

P4 - Low

Informational findings, minor policy deviations, or security improvements identified during routine review.

Examples:
- Missing security headers on non-sensitive page
- Outdated SSL certificate on internal test system
- Security scan finding with no practical exploit path
- Employee using weak password on non-critical system

The Incident Response Team

Incident Commander (IC)

The IC owns the incident from detection to resolution. They coordinate all activities, make decisions about containment and communication, and are the single point of authority during the incident. The IC does not need to be the most senior person — they need to be calm, organized, and decisive.

Technical Lead

The most knowledgeable engineer for the affected system. They lead the technical investigation, propose containment actions, and execute remediation. The Technical Lead advises the IC on technical decisions but does not make unilateral calls.

Communications Lead

Manages all stakeholder communication: internal updates, customer notifications, press responses, and regulatory filings. Having a dedicated communications person prevents the technical team from being interrupted by status requests.

Scribe

Documents everything in real time. Every action taken, every decision made, every finding discovered. The scribe's notes become the foundation of the post-incident review and may be needed for legal or regulatory purposes.

Subject Matter Experts

Pulled in as needed based on the incident type. Database administrators for data breach investigation, network engineers for infrastructure compromise, legal counsel for regulatory obligations.

Communication Channels

Establish dedicated channels before an incident occurs.

# Incident communication setup
Primary channel:  #incident-active (Slack/Teams)
War room:         Video bridge (always-on during P1/P2)
Status updates:   #incident-updates (read-only, IC posts only)
Documentation:    Shared document (Google Doc or Notion page)
Escalation:       PagerDuty / on-call rotation
External:         Designated spokesperson only

Keep incident channels private. Only the response team and leadership should have access during an active incident. Information shared publicly or broadly can cause panic, tip off attackers, or create legal liability.

Regular status updates. The IC posts updates at defined intervals — every 30 minutes for P1, every 2 hours for P2. Even "no new information" updates prevent people from interrupting the technical team for status checks.

Runbooks

Runbooks provide step-by-step procedures for common incident types. They reduce response time by eliminating the need to figure out each step during a crisis.

# Runbook: Compromised User Credentials
1. Disable the compromised account immediately
2. Revoke all active sessions for the account
3. Reset credentials (password, API keys, tokens)
4. Review account activity logs for the past 30 days
5. Check for unauthorized changes to account permissions
6. Scan for data exfiltration indicators
7. Check if credentials were reused on other systems
8. Notify the account owner through verified channel
9. Enable enhanced monitoring on the account
10. Document findings in incident record

Maintain runbooks for your most likely incident types: compromised credentials, malware detection, data breach, DDoS attack, insider threat, and supply chain compromise.

Notification Requirements

Legal Counsel

Notify legal immediately for P1 and P2 incidents. Legal advises on regulatory obligations, evidence preservation, and liability. Do not make public statements before consulting legal.

Customers

Affected customers must be notified, but timing and content require care. Premature notification without confirmed details causes confusion. Delayed notification erodes trust and may violate regulations.

Regulators

GDPR 72-hour rule. Under the EU's General Data Protection Regulation, you must notify the relevant supervisory authority within 72 hours of becoming aware of a personal data breach. The clock starts when you have a reasonable degree of certainty that a breach has occurred.

Other regulations. HIPAA requires notification within 60 days. Various US state breach notification laws have their own timelines. PCI DSS requires notification to the payment card brands.

# Notification checklist for P1 data breach
Within 1 hour:   Legal counsel, CISO, CEO
Within 4 hours:   Board of directors (if public company)
Within 24 hours:  Customer notification draft prepared
Within 72 hours:  Regulatory notification (GDPR)
Within 30 days:   Customer notification sent (varies by regulation)

Testing the Plan

An untested plan is a wish list. Regular exercises ensure the plan works and the team is prepared.

Tabletop exercises. Walk through a scenario verbally. "It is Monday morning. An employee reports their credentials were used to access a customer database over the weekend. What do you do?" These are low-cost and reveal gaps in procedures.

Simulation drills. Create a realistic incident in a test environment and have the team respond as if it were real. Time the response and evaluate against defined metrics.

Red team exercises. An internal or external team actually attempts to breach systems. The response team detects and responds without knowing it is a drill. This is the most realistic test.

Run tabletop exercises quarterly. Run simulation drills twice a year. Run red team exercises annually.

Common Pitfalls

• No designated Incident Commander. Without clear authority, people work in parallel on conflicting approaches, or everyone waits for someone else to act.
• Skipping the scribe role. Without real-time documentation, the post-incident review relies on faulty memory. Critical details are lost.
• Communicating through informal channels. Side conversations in DMs fragment information. Everything goes through the incident channel.
• Not involving legal early enough. Actions taken during response can have legal implications. Evidence preservation, notification timelines, and public statements all need legal input.
• Never testing the plan. Plans that look good on paper fail under pressure. Regular exercises reveal gaps before real incidents do.

Key Takeaways

• Build your incident response plan before you need it — roles, channels, and runbooks must be established in advance.
• The incident lifecycle is: detect, contain, eradicate, recover, learn.
• Classify incidents by severity (P1-P4) to ensure appropriate response levels.
• The incident response team needs an IC, technical lead, communications lead, and scribe at minimum.
• Notification requirements vary by regulation — GDPR requires 72-hour notification for data breaches.
• Test your plan with tabletop exercises, simulation drills, and red team exercises.
• An untested plan is no plan at all.