/pci-audit

name: pci-audit
description: "Audit applications and infrastructure handling payment card data against PCI DSS v4.0. Heavy emphasis on scope determination (the single most-leveraged variable) plus the engineering-relevant requirements — Req 3 (storage of CHD), Req 4 (transmission), Req 6 (secure SDLC), Req 7-8 (access), Req 10 (logging), Req 11 (testing), Req 12 (program). Use when the user mentions 'PCI,' 'PCI DSS,' 'PCI DSS 4.0,' 'payment card,' 'cardholder data,' 'CHD,' 'PAN,' 'PCI scope,' 'PCI compliance,' 'SAQ,' 'AoC,' 'attestation of compliance,' 'tokenization,' 'P2PE,' 'network segmentation for PCI,' or audits any system that stores, processes, or transmits payment card data."
allowed-tools: Read, Grep, Glob, Bash, Write, WebSearch

PCI Audit — Payment Card Industry Data Security Standard

PCI DSS v4.0 (effective March 2025) is the security standard for any environment that stores, processes, or transmits payment card data. Twelve high-level requirements; hundreds of sub-requirements. Most organizations pass or fail on a single decision: **scope**.

This skill emphasizes scope determination first, then the engineering-relevant requirements. Final compliance attestation (SAQ self-assessment or QSA audit producing an Attestation of Compliance) is a process this skill prepares for — it is not the attestation itself.

Cross-references: `crypto-audit` for Req 3 / 4 cryptographic detail; `iam-audit` for Req 7-8; `siem-detection` for Req 10 logging; `dependency-audit` and `owasp-audit` for Req 6 (secure SDLC); `incident-triage` for Req 12.10 (incident response).

The scope question (do this first)

"Scope" in PCI DSS means: the systems that store, process, or transmit cardholder data (CHD), plus systems that can affect the security of those systems (connected-to and security-impacting systems). Everything in scope is subject to all 12 requirements. Everything out of scope is not.

**Most PCI failures are scope failures.** A system pulled into scope by accident creates years of compliance debt; a system kept out of scope via good architecture saves substantial cost.

Determine scope

For every system in the environment, classify:

| Type | Definition | In scope? | |---|---|---| | **CDE** (Cardholder Data Environment) | Stores, processes, or transmits PAN, expiration, service code, name when paired with PAN, or sensitive authentication data | **Yes — full PCI DSS** | | **Connected-to** | Has direct connectivity to the CDE without compensating segmentation | **Yes** | | **Security-impacting** | Provides security services to the CDE (auth, logging, monitoring, time sync, DNS) | **Yes** | | **Segmented** | No direct connectivity; segmentation validated annually | **No** | | **Cardholder data flow only as masked / tokenized** | The system handles tokens or masked PANs that cannot be reversed without out-of-band access | Usually **No**, but verify the token type — surrogate tokens reversible by the merchant are still in scope |

**Audit step:** trace every payment flow end-to-end. Where does the PAN enter the environment, where does it go, where does it stop. Every system the PAN touches is in scope; every system that touches *that* system without segmentation is also in scope.

Reduce scope (the leveraged engineering work)

The highest-ROI PCI work is usually scope reduction:

• **Use a hosted payment page** — let Stripe / Adyen / Braintree / Worldpay host the input form. The PAN never reaches your servers. The browser communicates directly with the processor. Your scope shrinks to "iframe integration."
• **Use tokenization** — payment processor converts PAN into a token your systems store instead. The token is meaningless without processor-side access. Your systems handle tokens, not PANs.
• **Use P2PE** (Point-to-Point Encryption) — for terminal-present commerce, encrypt at the swipe so plaintext never traverses your network.
• **Network segmentation** — for retained CDE, ensure firewall / VLAN / namespace separation between CDE and the rest. Default-deny at the CDE perimeter.

A merchant doing 1M transactions/year via Stripe Checkout with no PAN on their servers is *radically* less in scope than the same merchant taking PANs into their own form and proxying to Stripe. Same merchant; very different audit.

Merchant levels and assessment types (compliance posture, not engineering)

Briefly, because it sets the audit cadence and rigor:

| Level | Volume (Visa) | Validation requirement | |---|---|---| | **1** | > 6M transactions/year, or breached merchant of any volume | Annual on-site QSA assessment → AoC | | **2** | 1M-6M transactions/year | Annual SAQ (self) or QSA assessment (Visa requires QSA from 2024) | | **3** | 20K-1M e-commerce transactions/year | Annual SAQ | | **4** | All other | Annual SAQ |

**SAQ types** (Self-Assessment Questionnaire) match the merchant's CDE shape — SAQ A (fully outsourced e-commerce), SAQ A-EP (e-commerce that does some redirection), SAQ B (terminal only, dial / IP without electronic storage), SAQ C-VT (web-based virtual terminal), SAQ D (everything else, the longest). The right SAQ is the one whose conditions all match your environment.

Engineering-relevant requirements (the subset this skill audits)

Req 3 — Protect stored cardholder data

**The default position: do not store PAN.** If you must, encrypt at rest and minimize the data retained.

• PAN at rest must be unreadable: strong cryptography (AES-256), key management per Req 3.6 (see `crypto-audit`), key rotation, separation of duties on key custody
• Sensitive authentication data (CVV / CVV2, full magnetic stripe, PIN / PIN block) **must not be stored** after authorization — period, regardless of encryption
• Mask PAN on display by default — typically first 6 + last 4
• Render PAN unreadable in any other form (backups, logs, debug output)

**Audit grep patterns:**

• Database schemas: columns named `pan`, `card_number`, `cc_number`, `cardnum`, `account_number`
• Code pat