Incident Response Plan Template for SaaS Companies

When a security incident hits, having a documented incident response (IR) plan is the difference between a controlled response and chaos. SOC 2, ISO 27001, HIPAA, and PCI-DSS all require documented IR procedures. More importantly, organizations with IR plans recover faster and suffer less damage.

This guide provides a practical IR plan template you can adapt for your organization.

The 6 Phases of Incident Response

The NIST Cybersecurity Framework and SANS Institute both define incident response in 6 phases:

1. Preparation     → Build capability before incidents happen
2. Identification  → Detect and validate the incident
3. Containment     → Stop the damage from spreading
4. Eradication     → Remove the threat
5. Recovery        → Restore systems and verify
6. Lessons Learned → Improve to prevent recurrence

Phase 1: Preparation

Preparation happens before any incident. You cannot effectively respond to something you haven't planned for.

IR Team Roles

Role	Responsibilities
Incident Commander	Coordinates the response; owns communication decisions
Technical Lead	Investigates, contains, and remediates
Communications Lead	Handles internal communication, customer comms, PR
Legal Counsel	Advises on breach notification requirements, liability
Security Analyst(s)	Log analysis, forensics, threat hunting

For small teams, one person may wear multiple hats.

Contact Lists

Maintain an up-to-date list of:

• IR team members (personal mobile, not just work email)
• External IR retainer (Mandiant, CrowdStrike, etc.) if applicable
• Legal counsel
• Cyber insurance provider and claim contact
• Key customer contacts (for major incidents)
• Relevant supervisory authorities (ICO, State AG, etc.)
• Cloud provider security/abuse contacts (AWS: aws-security@amazon.com)

Pre-Built Runbooks

Document specific response procedures for your most likely incident types:

• Compromised user credentials
• Data exposure (public S3 bucket, misconfigured database)
• Ransomware
• API key leak
• DDoS attack
• Insider threat

Tabletop Exercises

Run a scenario-based tabletop exercise at least quarterly. Walk through a realistic scenario (e.g., "an attacker has had access to our production database for 48 hours — go") and identify gaps in your response.

Phase 2: Identification

Goal: Determine whether an event is a confirmed incident and assess initial severity.

Detection Sources

• SIEM alerts
• Intrusion Detection System (IDS) alerts
• User reports ("I got a weird email from our CEO asking for gift cards")
• External reports (bug bounty researcher, customer complaint)
• Threat intelligence feed matches
• Anomalous billing (cloud, SMS)

Severity Classification

Level	Description	Example	Response Time
P1 - Critical	Active breach, data exposure, service down	Ransomware, confirmed data breach	Immediate (24/7)
P2 - High	Potential breach, significant risk	Compromised admin account, suspicious lateral movement	Within 1 hour
P3 - Medium	Suspicious activity, no confirmed impact	Failed brute force, malware on endpoint	Within 4 hours
P4 - Low	Policy violation, no immediate risk	Employee clicked phishing link (no payload)	Within 24 hours

Initial Assessment Questions

When an alert fires, immediately determine:

1. What happened? (What is the indicator? What system?)
2. When did it happen? (Timestamp of first indicator)
3. How wide is the scope? (One endpoint? One region? All environments?)
4. Is it still ongoing? (Active attack vs past event?)
5. What data is affected? (Does it include personal data, payment data, credentials?)
6. Is it a true positive? (Could this be a false alarm?)

Phase 3: Containment

Goal: Prevent further damage. Act fast, but document everything.

Short-Term Containment (Immediate)

□ Isolate affected systems (remove from network without powering off)
□ Revoke compromised credentials immediately
□ Block attacker IPs/domains at firewall/WAF
□ Disable affected user accounts
□ Enable enhanced logging on adjacent systems
□ Preserve forensic evidence (snapshots, memory dumps) BEFORE taking action
□ Do NOT clean systems yet — preserve evidence

Evidence Preservation

Before making any changes:

# AWS: Take a snapshot of affected EC2 instance
aws ec2 create-snapshot \
  --volume-id vol-xxxxxxxxx \
  --description "IR evidence - incident-2025-01-15 - DO NOT DELETE"

# Capture running processes and network connections
ps aux > /tmp/ir-processes-$(date +%Y%m%d-%H%M%S).txt
ss -tnp > /tmp/ir-connections-$(date +%Y%m%d-%H%M%S).txt
netstat -rn > /tmp/ir-routing-$(date +%Y%m%d-%H%M%S).txt

# Export CloudTrail logs for the relevant time window
aws cloudtrail lookup-events \
  --start-time 2025-01-14T00:00:00Z \
  --end-time 2025-01-15T23:59:59Z \
  --output json > cloudtrail-events.json

Long-Term Containment

After immediate actions, establish a stable containment state that allows investigation to continue:

• Deploy WAF rules blocking attack vectors
• Implement additional monitoring on affected systems
• Consider moving users to secondary authentication methods while investigating compromised IdP

Phase 4: Eradication

Goal: Remove the threat completely.

□ Identify and remove malware/backdoors
□ Patch the vulnerability that was exploited
□ Remove unauthorized accounts/credentials the attacker created
□ Audit for persistence mechanisms (cron jobs, startup scripts, Lambda backdoors)
□ Reset all credentials that may have been exposed
□ Rotate API keys, tokens, certificates in affected scope
□ Scan for indicators of compromise (IOCs) on adjacent systems
□ Confirm the attack path is fully closed

For ransomware: do not pay until you've exhausted recovery options and consulted legal counsel on the specific jurisdiction's regulations.

Phase 5: Recovery

Goal: Restore systems to normal operation safely.

□ Restore from known-good backups (confirm backup integrity first)
□ Rebuild affected systems from scratch (don't just restore — attacker may have modified the backup)
□ Deploy to production incrementally with enhanced monitoring
□ Monitor for 24–72 hours post-recovery for signs of re-compromise
□ Verify all services are operating correctly
□ Confirm customer data integrity

Recovery Communication Template

Subject: Service Restoration Update — [Date/Time]

Status: RESOLVED

Timeline:
- [Time]: Incident detected
- [Time]: Containment measures implemented
- [Time]: Root cause identified
- [Time]: Systems restored

What happened: [Brief technical summary appropriate for the audience]
What we did: [Containment and remediation actions]
What data was affected: [Scope of any data exposure]
What we're doing to prevent recurrence: [Remediation steps]

If you have questions, contact: security@yourcompany.com

Phase 6: Lessons Learned

Goal: Prevent recurrence and improve future response.

Hold a post-incident review within 5–7 days while details are fresh:

1. Timeline reconstruction: Build a complete chronology from first indicator to resolution
2. Root cause analysis: What vulnerability/misconfiguration enabled the incident?
3. Detection gap analysis: Why wasn't it detected earlier? What would have helped?
4. Response gap analysis: What slowed the response? What was unclear?
5. Action items: Specific tasks with owners and deadlines

Document everything in a post-incident report. This is required by SOC 2, ISO 27001, and most cyber insurance policies.

Data Breach Notification Requirements

If personal data was involved, check notification obligations:

Regulation	Notification to authority	Notification to individuals
GDPR	72 hours	Without undue delay (if high risk)
HIPAA	60 days	60 days
PCI-DSS	Immediately (to card brands)	Per state laws
US State laws	Varies (24–90 days)	Varies

Consult legal counsel immediately when personal data is confirmed involved.