Incident response plan includes cardholder data breach procedures

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.

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).

## 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.

• ID: ecommerce-pci.monitoring-compliance.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:

  # 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