PCI Incident Response Plan Template

Standard Operating Procedure: PCI-DSS Incident Response Plan (IRP) Execution

1. Document Control Block

• Document ID: SOP-SEC-PCI-042
• Effective Date: October 24, 2023
• Version: 3.4.1
• Review Cadence: Annual (or immediately following any critical security incident)
• Classification: RESTRICTED - INTERNAL USE ONLY

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the operational directives for detecting, containing, eradicating, and recovering from security incidents affecting the Cardholder Data Environment (CDE), in compliance with Payment Card Industry Data Security Standard (PCI-DSS) Requirement 12.10. The objective is to minimize business disruption, preserve forensic integrity, ensure regulatory notification compliance, and restore secure operations systematically.

---

3. Scope & Prerequisites

3.1 Scope

• Applies to all systems, networks, personnel, and third-party vendors touching, processing, storing, or transmitting Account Data (Primary Account Number [PAN], Cardholder Name, Service Code, Expiration Date) and Sensitive Authentication Data (SAD).

3.2 Prerequisites & Tooling

• Access Control: Multi-Factor Authentication (MFA) with Role-Based Access Control (RBAC) to SIEM, SOAR, and EDR platforms.
• Software Suite: Splunk/Datadog (SIEM), CrowdStrike Falcon (EDR), Wireshark/Tcpdump (Network Capture), PagerDuty (Alerting), Jira Service Management (Incident Ticketing).
• Physical/Hardware: Out-of-band management console access, air-gapped forensic acquisition drives, secure hardware cryptographic tokens.

---

4. Roles & Responsibilities (RACI Matrix)

---

5. Step-by-Step Procedure

Phase 1: Identification & Triage

• 1.1 Receive anomaly alert from SIEM, EDR, internal reporting, or external notification.
• 1.2 Open an emergency Incident Ticket in the designated ticketing platform, assigning the severity level (Sev-1 for verified CDE compromise).
• 1.3 Convene the Incident Response Bridge via PagerDuty within 15 minutes of a confirmed Sev-1 event.
• 1.4 Designate the Incident Commander (IC) and establish an isolated communications channel (e.g., encrypted out-of-band chat).

Phase 2: Containment (Short-Term & Long-Term)

• 2.1 Isolate Impacted Assets: Issue host containment commands via EDR to sever network access while preserving RAM state for forensics.
• 2.2 Network Segmentation: Implement emergency firewall rule blocks or drop routes at the network edge to sever connectivity to/from compromised CDE segments.
• 2.3 Credential Revocation: Immediately invalidate all active sessions, API keys, and IAM credentials associated with compromised accounts or systems.
• 2.4 Verify that containment measures do not inadvertently destroy volatile evidence required for forensic analysis.

Phase 3: Eradication & Forensic Analysis

• 3.1 Capture volatile memory (RAM) and disk images from impacted hosts using forensically sound tools (e.g., LiME, FTK Imager) maintaining strict Chain of Custody.
• 3.2 Perform root-cause analysis (RCA) to identify the vector of entry, lateral movement, and extent of data exposure (specifically verifying if PAN/SAD was accessed or exfiltrated).
• 3.3 Patch vulnerabilities, remove unauthorized artifacts, backdoors, and malicious binaries identified during the analysis.
• 3.4 Rotate all underlying cryptographic keys, database credentials, and service account passwords touched by the compromised environment.

Phase 4: Recovery & Validation

• 4.1 Rebuild compromised hosts from known-good, immutable golden images rather than patching in place.
• 4.2 Re-integrate systems into the CDE network topology under strict change-management controls.
• 4.3 Execute full vulnerability scans and penetration testing validation on restored assets.
• 4.4 Lift network containment iteratively while monitoring SIEM logs for anomalous traffic patterns over a mandatory 72-hour observation window.

Phase 5: Post-Incident Activities & Compliance Reporting

• 5.1 Compile the final Incident Report, detailing timeline, root cause, impact assessment, and remediation actions within 5 business days.
• 5.2 Notify acquiring banks, payment brands (Visa, Mastercard, etc.), and affected cardholders as mandated by PCI-DSS 12.10.5 (typically within 24 hours of confirmation).
• 5.3 Conduct a mandatory post-incident "blameless" retro within 14 days to update detection rules, hardening guides, and this SOP.

---

6. Quality Assurance & Pro-Tips

6.1 Best Practices

• Preserve Evidence First: Never power down a live compromised system before capturing memory; valuable artifacts residing exclusively in RAM will be lost.
• Maintain Chain of Custody: Document every action, transfer, and analysis of digital evidence with cryptographic hashes (SHA-256).

6.2 Common Pitfalls

• Pitfall: Notifying internal or external stakeholders prematurely without verified facts, leading to misinformation.
• Correction: Restrict dissemination strictly to the Incident Response Team and legal counsel until technical scope is verified by the IC.

6.3 Metric Thresholds

• Mean Time to Detect (MTTD): < 15 minutes for CDE anomalies.
• Mean Time to Respond (MTTR): < 30 minutes for Sev-1 containment.
• Post-Incident Review Completion: Within 14 calendar days of incident closure.

---

7. Frequently Asked Questions (FAQ)

Q1: When must the acquiring bank and payment brands be officially notified?

A: Under PCI-DSS mandates and card brand rules, notification must occur immediately (typically within 24 hours) upon confirming that cardholder data has been compromised or accessed without authorization. Do not wait for a complete forensic report to issue initial notifications.

Q2: Who is authorized to communicate with external media or law enforcement?

A: Only the designated Public Relations lead, Legal Counsel, or CISO may interface with external entities, regulatory bodies, or media. Internal personnel must direct all external inquiries to the legal department without making speculative statements.