Security Incident Response SOP Template for IT Teams

When a security incident hits, the last thing you want is people scrambling to figure out what to do. A documented incident response plan means the difference between a contained breach and a catastrophic data loss.

The average cost of a data breach in 2025 was $4.88 million. Organizations with a tested incident response plan saved an average of $2.66 million compared to those without one.

Phase 1: Detection and Identification

Goal: Confirm the incident is real and classify its severity

1. Receive alert from monitoring system, user report, or third-party notification
2. Verify the alert is not a false positive
   • Check monitoring dashboard for corroborating indicators
   • Review relevant logs (firewall, IDS/IPS, endpoint, authentication)
   • Determine if the behavior matches known attack patterns
3. If confirmed: classify severity
   • Critical: Active data exfiltration, ransomware deployment, compromised admin credentials
   • High: Unauthorized access to sensitive systems, malware on production server
   • Medium: Phishing success with credential reset, unauthorized access attempt (blocked)
   • Low: Suspicious activity without confirmed compromise, policy violation
4. Record in incident tracking system: timestamp, reporter, affected systems, initial classification
5. Assign incident commander based on severity (Critical/High = CISO, Medium/Low = Security Lead)

Phase 2: Containment

Goal: Stop the incident from spreading while preserving evidence

Short-Term Containment (First 30 Minutes)

1. Isolate affected systems from the network (do NOT power off — preserve memory)
2. Block identified malicious IPs/domains at firewall
3. Disable compromised user accounts
4. Change credentials for any accounts that interacted with compromised systems
5. Redirect DNS for affected services if needed
6. Communicate containment status to incident commander

Long-Term Containment (First 4 Hours)

1. Set up clean replacement systems if production services are affected
2. Apply emergency patches to vulnerable systems
3. Increase monitoring on all related systems
4. Ensure backups are intact and not compromised
5. If ransomware: verify backup integrity before any restoration
6. Document every action taken with timestamps

Phase 3: Investigation

Goal: Determine root cause, scope, and impact

1. Preserve forensic evidence:
   • Memory dumps of affected systems
   • Full disk images (before any remediation)
   • Network capture logs
   • Authentication logs for 30 days pre-incident
2. Determine attack vector: how did the attacker get in?
3. Determine lateral movement: what systems did they access after initial compromise?
4. Determine data impact: was data accessed, exfiltrated, or modified?
5. Identify all affected systems, accounts, and data
6. Timeline reconstruction: map every attacker action from initial access to detection
7. Identify indicators of compromise (IOCs) for monitoring

Phase 4: Eradication

Goal: Remove the threat completely

1. Remove malware from all affected systems
2. Close the attack vector (patch vulnerability, fix misconfiguration)
3. Reset all potentially compromised credentials
4. Revoke and reissue certificates if needed
5. Verify removal with scanning and monitoring
6. Confirm no persistence mechanisms remain (scheduled tasks, startup items, new accounts)

Phase 5: Recovery

Goal: Restore normal operations safely

1. Restore systems from known-clean backups or rebuild from images
2. Restore data from verified backups
3. Reconnect systems to network in stages (not all at once)
4. Monitor restored systems intensively for 72 hours
5. Verify all services are functioning correctly
6. Gradually restore user access
7. Confirm no reinfection after 48 hours

Phase 6: Post-Incident

Goal: Learn and improve

1. Conduct post-incident review within 5 business days
2. Document: timeline, root cause, impact, response effectiveness, lessons learned
3. Identify gaps in detection, response, or prevention
4. Update incident response plan based on lessons learned
5. Implement preventive measures to address root cause
6. Communicate findings to relevant stakeholders
7. If breach notification required: coordinate with legal for regulatory compliance (GDPR: 72 hours, HIPAA: 60 days, state laws vary)

Communication Templates

Internal Notification (Critical/High)

Subject: SECURITY INCIDENT - [Classification] - [Brief Description]

A security incident has been detected affecting [systems/data]. The incident response team has been activated. [Brief description of containment actions taken.] Do not discuss this incident outside approved channels. Further updates will follow every [30 min / 1 hour].

Customer Notification (If Required)

Subject: Important Security Notice

We are writing to inform you of a security incident that may have affected your data. [Brief factual description.] We have taken the following actions: [containment and remediation steps]. [What the customer should do.] [Contact information for questions.]

Documenting Your Incident Response SOP

For the software-based portions of incident response, like navigating your SIEM dashboard, running forensic tools, or configuring firewall rules, record your screen while demonstrating the process. ProcessReel generates step-by-step SOPs with screenshots specific to your tools.

This is critical for after-hours incidents when junior staff may need to perform initial containment without senior team members available.

FAQ

How often should we test the incident response plan?

At minimum annually through tabletop exercises. Quarterly is ideal. Simulate different scenarios: ransomware, data breach, insider threat, DDoS.

Who should be on the incident response team?

Minimum: IT security lead, system administrator, network administrator, legal counsel, communications lead. For regulated industries: compliance officer and privacy officer.

Do we need a separate plan for ransomware?

Yes. Ransomware has unique considerations: backup verification, payment decision framework, law enforcement notification, and decryption tool availability.

How do we handle incidents outside business hours?

Define an on-call rotation with clear escalation paths. The on-call person should be able to perform Phase 1 and short-term Phase 2 independently.

Should we involve law enforcement?

For critical incidents involving criminal activity, yes. The FBI, CISA, and local law enforcement have resources to assist. Reporting also helps protect other organizations from the same threat.

Document your incident response procedures. Try ProcessReel free — 3 recordings/month, no credit card required.