Incident Response Plan

Company:	[COMPANY NAME]
Version:	1.0
Effective Date:	[DATE]
Last Tested:	[DATE]
Plan Owner:	[CEO/CTO NAME]

1. Purpose and Scope

This Incident Response Plan establishes procedures for [COMPANY NAME] to detect, respond to, and recover from security incidents. The goal is to minimize impact, preserve evidence, and prevent recurrence.

This plan applies to:

All security incidents affecting company systems or data
All employees, contractors, and third parties
All environments (production, staging, development)

2. Incident Classification

Severity	Description	Response Time	Examples
Critical (P1)	Active data breach, system compromise, or major service outage	Immediate (within 15 min)	Ransomware, confirmed data breach, production down
High (P2)	Potential breach, compromised credentials, or significant risk	Within 1-4 hours	Compromised account, malware detected, unauthorized access attempt
Medium (P3)	Security policy violation or suspicious activity	Within 24 hours	Phishing attempt, policy violation, failed intrusion
Low (P4)	Minor security issue with limited impact	Within 72 hours	Vulnerability scan findings, minor policy exceptions

3. Incident Response Team

3.1 Core Team Roles

Role	Responsibilities	Primary Contact
Incident Commander	Overall incident coordination Decision-making authority Escalation decisions	[NAME, PHONE, EMAIL]
Technical Lead	Technical investigation Containment actions System recovery	[NAME, PHONE, EMAIL]
Communications Lead	Internal communications Customer notifications External communications	[NAME, PHONE, EMAIL]

4. Incident Response Phases

4.1 Phase 1: Detection and Reporting

How incidents are detected:

Automated monitoring and alerting systems
Employee reports via [SECURITY EMAIL/CHANNEL]
Customer reports
Third-party notifications

Immediate actions upon detection:

Document initial observations (time, symptoms, affected systems)
Classify severity using the table in Section 2
Notify Incident Commander immediately for P1/P2 incidents
Create incident ticket in [TICKETING SYSTEM]

For Critical (P1) incidents: Call [EMERGENCY PHONE NUMBER] immediately. Do not wait to document — call first, document second.

4.2 Phase 2: Containment

Short-term containment (stop the bleeding):

Isolate affected systems from the network
Disable compromised accounts
Block malicious IPs or domains
Preserve evidence before making changes

Long-term containment (stabilize):

Apply temporary fixes to allow business continuity
Implement additional monitoring on affected systems
Prepare for eradication phase

Evidence Preservation: Before making system changes, capture:

System logs and timestamps
Memory dumps (for malware analysis)
Network traffic captures
Screenshots of anomalies

4.3 Phase 3: Eradication

Identify and remove root cause (malware, vulnerabilities, unauthorized access)
Apply security patches and updates
Reset compromised credentials
Scan for additional indicators of compromise
Verify threat has been eliminated before proceeding to recovery

4.4 Phase 4: Recovery

Restore systems from clean backups if necessary
Gradually return systems to production
Monitor closely for signs of re-infection
Verify system integrity and functionality
Confirm with stakeholders that services are restored

5. Communication Plan

5.1 Internal Communication

Severity	Who to Notify	When
Critical	CEO, all executives, legal counsel, all employees	Immediately
High	CEO, relevant executives, affected teams	Within 1 hour
Medium	Direct manager, security team	Within 24 hours
Low	Security team	Next business day

5.2 External Communication

Customer notification triggers:

Confirmed breach of customer data
Service outage affecting customers
Regulatory notification requirements

Notification timeline:

GDPR: Within 72 hours of becoming aware of breach
Contractual obligations: Per customer agreements
State breach notification laws: Varies by jurisdiction

Legal Review Required: All external communications about security incidents must be reviewed by [LEGAL CONTACT] before sending.

6. Post-Incident Activities

6.1 Post-Incident Review

Within 5 business days of incident closure, conduct a review covering:

What happened and when?
How was it detected?
What was the impact?
What worked well in the response?
What could be improved?
What actions will prevent recurrence?

6.2 Documentation Requirements

Maintain records of:

Incident timeline and actions taken
Evidence collected
Communications sent
Post-incident review findings
Remediation actions and status

Retain incident records for [X YEARS] per retention policy.

7. Emergency Contact List

Role / Service	Contact Information
Incident Commander (Primary)	[NAME, PHONE, EMAIL]
Incident Commander (Backup)	[NAME, PHONE, EMAIL]
Technical Lead	[NAME, PHONE, EMAIL]
CEO	[NAME, PHONE, EMAIL]
Legal Counsel	[NAME, PHONE, EMAIL]
Cloud Provider Support	[AWS/GCP/AZURE SUPPORT]
Cyber Insurance	[CARRIER, POLICY #, PHONE]
External Forensics (if needed)	[FIRM NAME, PHONE]

8. Plan Maintenance

This plan is reviewed annually and updated as needed
Contact information is verified quarterly
Tabletop exercises are conducted at least annually
Plan updates require approval from [APPROVER]

9. Quick Reference: Incident Response Checklist

First 15 Minutes (Critical Incidents):

□ Call Incident Commander: [PHONE]
□ Document what you observed (time, symptoms, affected systems)
□ Do NOT power off systems (preserves memory evidence)
□ Isolate affected systems if directed
□ Join incident response channel: [CHANNEL]

Disclaimer: This template is provided by Compliance Copilot for informational purposes only and does not constitute legal advice. Organizations should test their incident response procedures regularly and consult with security professionals for their specific needs.