Security Incident Response

Security Incident Response Playbook

Type: {{ incident_type }} Description: {{ incident_description }} Affected Systems: {{ affected_systems }}

CRITICAL: Security Incident Differs from Operational Incident

• Preserve evidence — do not destroy logs, do not reimage systems without forensic capture
• Limit communication — use secure channels, need-to-know basis only
• Legal involvement — notify legal counsel early for breach/data exposure events
• Regulatory obligations — data breaches may have mandatory notification timelines

Phase 1 — Detection and Triage (0-15 min)

Immediate Actions

• Confirm the security event is real (not a false positive)
• Classify the incident type:
  • Unauthorized access
  • Compromised credentials
  • Data exfiltration/exposure
  • Malware/ransomware
  • Insider threat
  • DDoS attack
  • Supply chain compromise
• Assign severity based on data sensitivity and blast radius
• Open a PRIVATE incident channel (not public)
• Notify Security team lead and CISO

Triage Questions

1. What data or systems are potentially compromised?
2. Is the attack still active or historical?
3. What is the blast radius (users, data, systems)?
4. Is there evidence of data exfiltration?
5. Are any regulatory requirements triggered (PII, PHI, PCI)?

Phase 2 — Containment (15-60 min)

Short-Term Containment (stop the bleeding)

• Revoke compromised credentials/API keys/tokens
• Block malicious IP addresses or user accounts
• Isolate affected systems (network segmentation, not shutdown)
• Disable compromised integrations or webhooks
• Enable enhanced logging on affected systems

Evidence Preservation

• Capture system memory dumps before any changes
• Snapshot affected disk volumes
• Export relevant logs to secure, immutable storage
• Record network flow data
• Screenshot active sessions or dashboards
• Document chain of custody for all evidence

WARNING: Do NOT reimage, wipe, or restart systems before evidence is captured.

Compromised Credentials Response

If credentials are compromised:

• Rotate ALL credentials for affected accounts immediately
• Rotate API keys, tokens, and secrets that may have been exposed
• Force password reset for affected user accounts
• Revoke all active sessions for compromised accounts
• Review access logs for unauthorized actions during exposure window
• Check if compromised credentials were used to access other systems

Phase 3 — Investigation

Forensic Investigation

• Establish timeline of attacker activity
• Identify initial access vector (how did they get in?)
• Map lateral movement (what else did they access?)
• Determine data accessed or exfiltrated
• Identify persistence mechanisms (backdoors, new accounts)
• Check for indicators of compromise (IoCs) across other systems

Key Log Sources to Review

Phase 4 — Eradication and Recovery

Eradication

• Remove attacker access (all identified access vectors)
• Remove any persistence mechanisms (backdoors, cron jobs, new accounts)
• Patch the vulnerability that allowed initial access
• Verify no remaining unauthorized access
• Scan for IoCs across the environment

Recovery

• Restore affected systems from known-good backups (if needed)
• Validate data integrity
• Re-enable services in a controlled manner
• Implement additional monitoring for the affected area
• Verify clean operation for 24-48 hours

Phase 5 — Notification and Reporting

Internal Notification

Regulatory Notification (if applicable)

Customer Notification

• Determine which customers are affected
• Draft notification with legal review
• Include: what happened, what data was affected, what we are doing, what they should do
• Provide identity monitoring if PII was exposed

Post-Incident

• Conduct security post-incident review (separate from ops postmortem)
• Update threat model based on findings
• Implement additional security controls
• Update incident response playbook with lessons learned
• Schedule penetration test to validate fixes
• Review and update security monitoring rules

Counter-Rationalizations