ISO 27001 Incident Response Plan Template

Standard Operating Procedure: ISO 27001 Information Security Incident Response Plan (ISIRP)

1. Document Control Block

• Document ID: SOP-SEC-ISO27001-042
• Effective Date: October 24, 2023
• Version: 3.2.0
• Review Cadence: Annual (Next Review: October 2024)
• Classification: Internal / Restricted

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the operational lifecycle for detecting, containing, eradicating, recovering from, and learning from information security incidents. Designed to align strictly with ISO/IEC 27001:2022 (Control A.5.24 through A.5.28) and NIST SP 800-61 Rev. 2, this document ensures systemic consistency, minimal operational downtime, and strict adherence to regulatory notification mandates.

---

3. Scope & Prerequisites

Scope

This procedure applies to all digital assets, physical infrastructure, cloud environments, third-party integrations, and personnel (employees, contractors, and managed service providers) operating within the organizational perimeter of Template Registry.

Prerequisites & Required Tooling

• SIEM / Log Management: Splunk Enterprise / Datadog Security Monitoring.
• EDR (Endpoint Detection & Response): CrowdStrike Falcon / Microsoft Defender for Endpoint.
• Ticketing & Incident Tracking: Jira Service Management (Security Project).
• Out-of-Band Communication: Signal / PagerDuty Enterprise (Encrypted, non-corp infrastructure for crisis comms).
• Forensic Capture Tools: Volatility, FTK Imager, Wireshark.

---

4. Roles & Responsibilities (RACI Matrix)

• R - Responsible (The doer)
• A - Accountable (The decider)
• C - Consulted (The advisor)
• I - Informed (The kept-in-the-loop)

---

5. Step-by-Step Procedure

Phase 1: Preparation

• Ensure all logging agents, EDR sensors, and network taps are operational across production and corporate environments.
• Validate that the PagerDuty on-call rotation is staffed and escalations are functioning.
• Conduct quarterly tabletop exercises simulating ransomware and data exfiltration scenarios.

Phase 2: Detection & Analysis

• Triage Alert: Acknowledge security alerts within 15 minutes of SIEM/EDR generation.
• Classify Incident Severity: Assign a severity level based on the following matrix:
  • Sev-1 (Critical): Active data breach, ransomware deployment, core infrastructure compromise.
  • Sev-2 (High): Isolated malware infection, unauthorized privilege escalation, non-public data exposure.
  • Sev-3 (Medium): Policy violation, targeted phishing with no successful payload execution.
  • Sev-4 (Low): Scans, probes, false positives.
• Open a dedicated Jira Security ticket, tag it with the Incident ID, and set the priority level.
• Initiate the secure Incident Response bridge (Zoom/Signal) if Sev-1 or Sev-2 is declared.

Phase 3: Containment

• Short-Term Containment: Isolate affected endpoints from the network via EDR isolation commands (crowdstrike containment or equivalent).
• Credential Revocation: Force global password resets and revoke active OAuth tokens/session cookies for compromised user accounts.
• Network Segmentation: Implement emergency firewall block rules or security group updates to quarantine compromised subnets.
• Preserve volatile memory and storage state (RAM dump, disk image) for forensics prior to rebooting or patching systems.

Phase 4: Eradication & Recovery

• Identify and neutralize the root cause (e.g., patch vulnerable CVEs, remove malicious persistence mechanisms, purge backdoors).
• Restore systems from verified, uncompromised, immutable backups.
• Validate system integrity using file integrity monitoring (FIM) and cryptographic hashes.
• Reintroduce assets to the production environment under enhanced monitoring (72-hour observation window).

Phase 5: Post-Incident Activity (Lessons Learned)

• Conduct a mandatory Post-Incident Review (PIR) meeting within 5 business days of incident closure.
• Draft a comprehensive Root Cause Analysis (RCA) report documenting the timeline, impact, and vector.
• Create preventative Jira tickets with hard due dates to address architectural or operational gaps identified during the incident.
• Archive all forensic logs, communication transcripts, and ticketing artifacts in secure, read-only S3 storage with a 7-year retention policy.

---

6. Quality Assurance & Pro-Tips

Key Performance Indicators (KPIs) & Thresholds

• MTTD (Mean Time to Detect): $\le 15 \text{ minutes}$ for Sev-1 alerts.
• MTTR (Mean Time to Respond/Contain): $\le 60 \text{ minutes}$ for Sev-1 incidents.
• Regulatory Notification Window: $\le 72 \text{ hours}$ for GDPR/HIPAA-qualifying breaches (managed by Legal/CISO).

Pro-Tips & Common Pitfalls

• Pro-Tip: Never shut down a compromised virtual machine or physical server immediately; always capture RAM first. Shutting down destroys critical volatile artifacts (e.g., encryption keys, active network connections, injected shellcode).
• Pitfall: Prematurely communicating status externally. All external communications must route exclusively through the PR Lead and Legal Counsel to prevent liability exposure.

---

7. Frequently Asked Questions (FAQ)

Q1: Who has the authority to declare a Sev-1 incident and mandate network-wide isolation?

A1: The Incident Response Lead (IRL) and the Chief Information Security Officer (CISO) possess unilateral authority to order network isolation or system shutdowns to protect organizational assets.

Q2: How should sensitive evidence be handled to ensure chain of custody?

A2: All forensic artifacts must be hashed (SHA-256) upon acquisition, logged in the evidence register, and stored in an access-restricted S3 bucket with strict IAM controls. Modifying raw evidence files is strictly prohibited.