# PCI compliance documentation and policies documented

- **Pattern:** `ab-001185` (`ecommerce-pci.access-control.pci-documentation`)
- **Severity:** high
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001185
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001185)

## Why it matters

PCI-DSS 4.0 Req 12.1 requires that an overall information security policy exists and is reviewed at least annually; Req 12.3 mandates a targeted risk analysis process documented for each requirement. Without a compliance documentation file that states your SAQ type and CDE scope, you cannot demonstrate PCI compliance to an auditor, a payment processor, or an enterprise customer requesting your AOC. ISO 27001:2022 A.5.1 and SOC 2 CC2.2 both require written policies before any technical controls are assessed. A project with good technical controls but no documentation fails a PCI audit regardless of its actual security posture.

## Severity rationale

High because the absence of a documented SAQ type and CDE scope means no audit trail exists for your compliance posture — you cannot satisfy a QSA assessment or payment processor inquiry regardless of your technical controls.

## Remediation

Create `docs/pci-compliance.md` that explicitly states your SAQ type, CDE scope, and covers at minimum: network segmentation approach, encryption method, access controls, logging retention, incident response reference, and vendor compliance. This is the document a QSA will ask for first.

```markdown
# PCI DSS Compliance Documentation
## SAQ Type: SAQ A — Fully outsourced to Stripe (Level 1 PCI DSS)
## CDE Scope: Minimal — no direct card data. Tokens only.
## Assessment Date: 2026-02-15  Next: 2027-02-15

### Data Protection
All PANs handled by Stripe. App stores payment method IDs (pm_*) only.

### Access Control
Admin access requires MFA (TOTP via Supabase). RBAC documented in docs/rbac.md.
```

Link this file from your README and reference it in your incident response and vendor compliance docs so the compliance picture is navigable from a single entry point.

## Detection

- **ID:** `pci-documentation`
- **Severity:** `high`
- **What to look for:** List all compliance-related documentation files in the project (search for files containing "pci", "compliance", "security-policy", "cde" in `docs/` or project root). For each file found, check whether it covers at least 5 of these topics: (1) SAQ type, (2) CDE scope, (3) network segmentation, (4) encryption approach, (5) access controls, (6) logging/monitoring, (7) incident response, (8) vendor compliance. Before evaluating, quote the SAQ type statement if present.
- **Pass criteria:** At least 1 documentation file exists that explicitly states the SAQ type (e.g., "SAQ A", "SAQ A-EP", "SAQ D") and covers at least 5 of the 8 compliance topics listed above. Documentation contains at least 50 words of substantive compliance content (not just headings). Report even on pass: state the count of compliance topics covered and the SAQ type found.
- **Fail criteria:** No compliance documentation found, or documentation covers fewer than 5 topics, or SAQ type is not stated. Does not count as pass when documentation exists but contains only placeholder text or TODO items.
- **Skip (N/A) when:** The project does not handle cardholder data (no payment provider dependency, no payment routes, fully third-party processing with no card storage or transmission).
- **Detail on fail:** Specify what documentation is missing. Example: `"No PCI compliance documentation found in docs/ directory. 0 files reference PCI DSS or SAQ."` or `"docs/security-policy.md exists but covers only 2 of 8 topics (encryption, access controls). No SAQ type stated."`
- **Cross-reference:** See `ecommerce-pci.cardholder-data.cde-isolated` (CDE architecture), `ecommerce-pci.monitoring-compliance.incident-response-plan` (incident response), `ecommerce-pci.monitoring-compliance.vendor-compliance` (vendor management).
- **Remediation:** Create a PCI compliance documentation file. Create `docs/pci-compliance.md`:

  ```markdown
  # PCI DSS Compliance Documentation

  ## Compliance Overview
  - **SAQ Type:** SAQ A (Fully outsourced, tokenized payments via Stripe)
  - **CDE Scope:** Minimal — no direct card data handling
  - **Assessment Date:** 2026-02-15
  - **Next Assessment:** 2027-02-15

  ## Compliance Measures

  ### Network Segmentation
  - Payment webhook receivers isolated in DMZ
  - Internal app tier separated from CDE via security groups

  ### Data Protection
  - All cardholder data delegated to Stripe (Level 1 PCI compliant)
  - Tokens only stored in app database, never raw card data

  ### Access Control
  - Admin access requires MFA
  - RBAC enforces least privilege
  - Service accounts use minimal-scope credentials

  ### Audit & Logging
  - 365-day log retention (CloudWatch)
  - Centralized logging to immutable S3 archive
  - Annual risk assessment completed

  ### Incident Response
  - Documented incident response plan exists
  - Breach notification procedures documented
  - Legal and PR contacts identified

  ## Applicable Standards
  - ISO 27001 (Information Security Management)
  - SOC 2 Type II (controls and procedures)
  - Industry best practices (NIST, OWASP)

  ## Annual Risk Assessment
  - See `docs/annual-risk-assessment-2026.md`

  ## Vendor Compliance
  - See `docs/vendor-compliance.md` for third-party service verification
  ```

  Reference this documentation in your security and operations runbooks.

---

## External references

- pci-dss Req 12.1
- pci-dss Req 12.3
- iso-27001 A.5.1
- soc2 CC2.2

Taxons: regulatory-conformance

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