# Incident response plan includes cardholder data breach procedures

- **Pattern:** `ab-001193` (`ecommerce-pci.monitoring-compliance.incident-response-plan`)
- **Severity:** medium
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001193
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001193)

## Why it matters

PCI-DSS 4.0 Req 12.10.1 requires that an incident response plan is implemented and ready to be activated immediately upon a suspected or confirmed breach; Req 12.10 requires annual testing of the plan. Without a written plan that explicitly addresses cardholder data, a breach response becomes ad-hoc: notifications are delayed, containment steps are missed, and regulatory timelines (Stripe requires notification within 24 hours) are violated. ISO 27001:2022 A.5.26 and NIST IR-8 both require documented, tested procedures for responding to information security incidents.

## Severity rationale

Medium because an undocumented or incomplete incident response plan delays breach containment and regulatory notification, converting a manageable incident into a reportable PCI-DSS violation with potential fines.

## Remediation

Create `docs/incident-response-plan.md` that explicitly covers cardholder data breach scenarios — not just generic incidents. The plan must include specific notification timelines: payment processors (Stripe) within 24 hours, affected cardholders per applicable state breach notification law (typically 30–72 days).

```markdown
## Notification Timeline (per PCI-DSS 4.0 Req 12.10)
- Hour 0: Isolate affected systems, preserve logs
- Hour 2: Notify incident commander and activate response team
- Hour 24: Notify Stripe and acquiring bank
- Day 30: Notify affected cardholders per state breach law
- Day 30: File with applicable regulatory authority
```

Include named role contacts (security lead, legal, PR) with out-of-band contact methods, since email and Slack may be compromised during an active incident. Review and test the plan annually per Req 12.10.

## Detection

- **ID:** `incident-response-plan`
- **Severity:** `medium`
- **What to look for:** Search for incident response documentation files (look for "incident", "response", "breach" in `docs/` and project root). For each file found, count the number of required sections present: (1) discovery/detection phase, (2) investigation phase, (3) containment phase, (4) notification procedures with timeline, (5) recovery phase, (6) post-incident review, (7) contact list/roles. Check that the plan specifically mentions cardholder data breaches, not just generic incidents.
- **Pass criteria:** At least 1 incident response plan document exists with at least 5 of the 7 required sections listed above. The plan explicitly addresses cardholder data breach scenarios (mentions "cardholder", "card data", or "payment data" breach). At least 1 notification timeline is specified (e.g., "notify payment processor within 24 hours"). Report: "X of 7 required sections present, cardholder-specific: yes/no."
- **Fail criteria:** No incident response plan found (0 files), or plan covers fewer than 5 sections, or plan does not specifically address cardholder data breaches.
- **Skip (N/A) when:** Payment processing fully delegated to third-party (no local CDE, no cardholder data exposure risk from your infrastructure).
- **Detail on fail:** Specify the gap. Example: `"No incident response plan documented. 0 files found matching incident/response/breach in docs/ directory."` or `"docs/incident-response.md exists with 3 of 7 sections. No mention of cardholder data breach procedures."`
- **Remediation:** Create an incident response plan. Create `docs/incident-response-plan.md`:

  ```markdown
  # Incident Response Plan for Cardholder Data Breaches

  ## Overview
  This plan outlines procedures for responding to suspected or confirmed compromises of cardholder data.

  ## Discovery Phase (0-2 hours)
  1. Isolate affected systems immediately
  2. Preserve forensic evidence (logs, memory dumps)
  3. Notify incident commander (on-call security lead)
  4. Activate incident response team

  ## Investigation Phase (0-24 hours)
  1. Determine scope: how many cards? which merchants?
  2. Identify root cause (SQL injection, compromised credentials, etc.)
  3. Assess attacker access: what systems were accessed?
  4. Document all findings in incident log

  ## Containment Phase (immediate-48 hours)
  1. Revoke compromised credentials
  2. Patch exploited vulnerability
  3. Reset cardholder tokens for affected cards
  4. Monitor for further unauthorized access

  ## Notification Phase (per PCI DSS timeline)
  1. PCI DSS requires notification within specific timeframe
  2. Notify affected customers (per state laws: 30 days typical)
  3. Report to payment processors (Stripe, etc.)
  4. File with regulatory authorities if required

  ## Recovery Phase (ongoing)
  1. Restore systems from clean backups
  2. Reapply patches and security hardening
  3. Re-enable monitoring
  4. Resume normal operations

  ## Post-Incident Phase (after recovery)
  1. Conduct root cause analysis
  2. Document lessons learned
  3. Update security policies and controls
  4. Schedule follow-up penetration testing

  ## Contacts
  - Incident Commander: security-lead@company.com
  - PCI Compliance Officer: compliance@company.com
  - Legal: legal@company.com
  - PR: pr@company.com

  ## Regulatory Notification Requirements
  - PCI DSS: Within 30 days of discovery
  - Payment Processor (Stripe, etc.): Within 24 hours
  - Affected customers: Within state-mandated timeframe
  ```

## External references

- pci-dss Req 12.10
- pci-dss Req 12.10.1
- nist IR-8
- iso-27001 A.5.26

Taxons: regulatory-conformance

HTML version: https://auditbuffet.com/patterns/ab-001193