Sample Incident Response Plan Template

Standard Operating Procedure: Incident Response (IR)

Template Registry | Engineering Division

---

1. Document Control Block

---

2. Executive Summary & Purpose

This SOP establishes the systematic framework for identifying, containing, eradicating, and recovering from cybersecurity or infrastructure incidents. The purpose is to minimize service disruption, protect data integrity, and ensure organizational resilience through standardized, repeatable engineering responses.

---

3. Scope & Prerequisites

• Scope: Applies to all production infrastructure, cloud environments, and internal systems managed by Template Registry.
• Required Tools: PagerDuty (Alerting), Jira (Ticketing), Slack (Incident Channels), GitHub (Code/Config), Datadog/Splunk (Observability), Terraform (IaC).
• Prerequisites: Validated system backups, active VPN access, authorized IAM roles for production environment remediation.

---

4. Roles & Responsibilities (RACI Matrix)

---

5. Step-by-Step Procedure

Phase 1: Identification & Triage

• Verify alert validity via observability dashboard metrics.
• Initialize dedicated #incident-[YYYYMMDD] Slack channel.
• Create incident tracking ticket in Jira.
• Declare incident severity (SEV1: Critical/Down; SEV2: Impaired; SEV3: Minor).

Phase 2: Containment

• Isolate compromised instances or segregate network segments.
• Implement temporary WAF rules or ACL blocks to stop data egress.
• Snapshot affected volumes for forensic analysis.
• Rotate compromised credentials/API keys.

Phase 3: Eradication & Recovery

• Identify root cause via log correlation and differential analysis.
• Deploy patched code/configuration via CI/CD pipeline.
• Validate system integrity through synthetic transaction monitoring.
• Gradually restore production traffic (Canary deployment recommended).

Phase 4: Post-Incident Activity

• Conduct Blameless Post-Mortem within 48 hours.
• Update documentation and runbooks based on lessons learned.
• Close Jira incident ticket.

---

6. Quality Assurance & Pro-Tips

• Best Practice: Always assume the environment is compromised until proven otherwise. Never use primary production credentials for incident remediation.
• Common Pitfall: Attempting to "fix forward" without taking a forensic snapshot first. Always capture state before making modifications.
• Metric Thresholds:
  • MTTD (Mean Time to Detect): < 15 minutes.
  • MTTR (Mean Time to Resolve): < 4 hours for SEV1.
  • Incident Documentation Completeness: 100% of tickets must have a linked root-cause analysis (RCA).

---

7. Frequently Asked Questions

Q: When should I escalate an incident? A: Escalate to the Chief Architect if remediation steps exceed 60 minutes without visible progress or if the breach involves unauthorized PII/PCI data access.

Q: Should I delete logs to clear space during an incident? A: Never. Log files are the primary evidence for forensic reconstruction. If space is an issue, move logs to a cold storage bucket (e.g., S3 Glacier) rather than purging them.

Q: What if the Incident Commander is unavailable? A: Follow the on-call rotation hierarchy. If no formal IC is identified in the rotation, the Senior Lead Engineer on shift assumes the role by default.

---

Authorized by: Julian Vance, Chief Architect, Template Registry