Pci Audit

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:

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:

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 paths writing card data: pan, cardNumber, regex ^4[0-9]{12,15}$ (Visa), ^5[1-5][0-9]{14}$ (Mastercard), ^3[47][0-9]{13}$ (Amex), ^6(?:011|5[0-9]{2})[0-9]{12}$ (Discover)
• Logs: console\.log.*cardNumber, logger\..*\.pan, log\..*card
• Error reporting: confirm Sentry / Datadog / Bugsnag scrubbing rules redact card patterns (Luhn-valid 13-19 digit sequences)
• Backups: confirm backup retention does not include unencrypted CHD

If a Luhn-valid PAN appears anywhere in source, lock files, or logs — that is a finding regardless of intent.

Req 4 — Protect transmission across open networks

• TLS 1.2 or higher, modern cipher suites only (see crypto-audit for the configuration detail)
• No PAN transmitted via end-user messaging tech (email, SMS, chat) — and reject any flow that does
• Internal-only networks transmitting PAN should still encrypt (defense in depth — Req 4.2.1.1 in v4.0)

Req 6 — Develop and maintain secure systems and software

This is where the security audit family meets PCI. Most of this requirement is satisfied by running the existing skills:

• 6.2 Custom software developed securely — see owasp-audit, api-audit
• 6.3 Vulnerabilities identified and addressed — see vuln-research, dependency-audit, finding-triage
• 6.4 Public-facing web applications protected from attacks — WAF or annual code review + post-release manual review
• 6.5 Changes to all system components managed securely — change management, separation of duties between dev and prod, sanitization of pre-production data before lower-environment use

Audit grep patterns:

• Lower-environment configs containing real PANs (the common failure: staging seeded from a prod DB dump that included card data)
• Code paths that bypass the secure SDLC (direct prod hotfix patterns, --no-verify on commits to prod-impacting branches)

Req 7 — Restrict access to cardholder data by business need to know

• Role-based access — only personnel needing CHD for their job have access
• Default-deny — access is granted explicitly, never inherited
• Privileged user IDs documented and reviewed

See iam-audit for the full identity-and-access deep dive.