What is an Incident Response Plan

SOP-IR-001: Incident Response Framework (IRF)

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional framework for identifying, containing, eradicating, and recovering from security and system-critical incidents. The purpose is to minimize service degradation, ensure data integrity, and maintain business continuity through a standardized, repeatable response lifecycle.

2. Scope & Prerequisites

• Scope: All production infrastructure, cloud environments, and internal data registries managed by Template Registry.
• Prerequisites:
  • Communication: Slack (Incident-specific channel), PagerDuty (On-call rotations).
  • Documentation: Confluence/Notion Incident Post-Mortem template.
  • Tooling: SIEM (Splunk/Datadog), Forensic storage bucket (Read-only), SSH Bastion (MFA-gated).

3. Roles & Responsibilities (RACI)

4. Step-by-Step Procedure

Phase 1: Detection & Analysis

• Verify alert validity via SIEM log correlation.
• Determine incident severity (SEV1: Critical/Down; SEV2: Impaired; SEV3: Minor).
• Initialize dedicated incident Slack channel (#inc-YYYYMMDD-ID).

Phase 2: Containment (Short-term)

• Isolate affected network segments or rotate compromised API keys.
• Snapshot volatile memory and disk states for forensic analysis.
• Implement egress/ingress rate-limiting if DDoS is suspected.

Phase 3: Eradication

• Identify root cause (e.g., misconfiguration, exploit vector).
• Patch vulnerabilities or rollback to the last known-good state.
• Validate remediation via automated unit/integration test suites.

Phase 4: Recovery

• Perform phased service restoration to ensure stability.
• Monitor performance metrics to confirm service level objectives (SLOs) are met.
• Transition from Incident mode to Normal Operations (Handover).

Phase 5: Post-Incident Activity

• Schedule a "Blameless Post-Mortem" meeting within 72 hours.
• Document lessons learned and update SOPs.
• Close incident ticket in JIRA/ServiceNow.

5. Quality Assurance & Pro-Tips

• The Golden Rule: Never modify a system in a state of panic without a secondary peer review.
• Pitfall: "Hero Complex." If the IC is performing technical fixes, the coordination fails. Delegate execution, manage communication.
• Thresholds: Any downtime exceeding 300 seconds requires an automated PagerDuty escalation to the secondary on-call engineer.
• Pro-Tip: Pre-provision read-only forensic accounts to avoid credential-sharing during an active incident.

6. Frequently Asked Questions (FAQ)

Q: At what point do I escalate a SEV2 to SEV1? A: Escalate immediately if the incident impacts customer data security, results in total system unavailability, or persists for >60 minutes without a identified mitigation path.

Q: Should I delete logs or evidence once the incident is over? A: Never. All incident-related logs must be archived in a locked S3 bucket with a 7-year retention policy for audit and compliance requirements.

Q: What is the primary priority during the "Containment" phase? A: Preventing lateral movement. Stop the bleeding, even if it requires taking a service offline entirely. Availability is secondary to Integrity during an active exploit.