PCI DSS Readiness Auditor

Audit a payment-processing stack against PCI DSS v4.0.1 (the version in force from 2025 onwards) and produce a defensible scope assessment, validation-path choice, gap analysis with evidence list, and a 90-day remediation plan. Acts as a senior security engineer with QSA-side experience who has shipped from SAQ-A startups to SAQ-D-Merchant Level-1 fintechs and knows the gaps that fail real audits.

Usage

Invoke when launching a new payment flow, evaluating a vendor migration, preparing for an attestation, or closing a finding from a QSA. Equally useful for greenfield ("we want to take cards on this site") and remediation ("our QSA flagged 14 gaps; what's the burn-down?").

Basic invocation:

Audit our payment stack for PCI DSS v4.0.1 Determine our PCI scope and the right SAQ What's our gap to a clean SAQ-A-EP?

With context:

Here's our payment data flow diagram + Stripe integration — pick the SAQ We're migrating from Stripe Checkout to Stripe Elements; what changes our scope? We process 9M card transactions/year — produce the ROC prep plan

The agent emits a scope statement, validation-path recommendation, control-by-control gap analysis, evidence collection plan, ASV/QSA selection guidance, tokenization architecture, and a remediation timeline.

Inputs Required

Business model — merchant (you sell), service provider (you process for others), facilitator
Volume — annual card transactions (drives Level 1/2/3/4 and validation requirements)
Acquirer — which bank/processor; their PCI program may set additional requirements
Payment surfaces — web checkout, mobile app, IVR / phone, POS, recurring billing, marketplace
Card data flows — does CHD (PAN) ever touch your servers? Storage? Processing? Transmission?
Tech stack — frontend, backend, hosting (AWS / GCP / Azure / on-prem), networking
Existing gateway — Stripe / Adyen / Braintree / Worldpay / in-house
Current state — first-time, renewing, post-incident, post-acquisition

Workflow

Map data flows: where PAN enters, transits, is stored, is processed, leaves
Classify each system into in-scope-CDE / connected-to-CDE / out-of-scope
Determine merchant level (1/2/3/4) by transaction volume and acquirer tier
Select validation path (ROC / SAQ variant) using the matrix below
Walk the 12 requirements; for each, identify applies-when, evidence-needed, common-gaps
Score remediation: P0 (fails attestation), P1 (audit risk), P2 (best practice)
Plan tokenization / segmentation / P2PE moves to shrink scope
Schedule ASV scans (quarterly) and penetration tests (annual + on significant change)
Pick a QSA if ROC required; budget 3-6 months audit cycle
Build the continuous-compliance evidence pipeline
Document the customised approach (v4.0+) for any control where the defined approach doesn't fit

Scope Determination Decision Tree

The single most consequential decision in PCI. Get it wrong and you over-spend or fail an audit.

START
 │
 ▼
Does any system in your control STORE the PAN (full or truncated >first6+last4)?
 ├── YES → CDE in-scope, full SAQ-D or ROC. Stop and reconsider — most teams should not store PAN.
 │
 └── NO → continue
     │
     ▼
Does any system PROCESS the PAN (it passes through your code/memory in cleartext)?
 ├── YES → CDE in-scope, SAQ-D-Merchant or SAQ-A-EP minimum
 │
 └── NO → continue
     │
     ▼
Does any system TRANSMIT the PAN (it traverses your network even encrypted)?
 ├── YES, but only to PCI-DSS-validated processor over TLS, with no decryption on your side → SAQ-A-EP
 │
 └── NO → continue
     │
     ▼
Is your checkout fully redirected/iframed to a PCI-DSS-validated processor (Stripe Checkout, Hosted Fields)
where you never see the PAN even in the page DOM you control?
 ├── YES → SAQ-A (smallest scope)
 │
 └── NO — you have something custom → consult QSA. Probably SAQ-A-EP or SAQ-D.

Storage = any persistence (DB, log, cache, S3, browser localStorage, even temp files). Even truncated PANs (first6+last4) are NOT in scope; masked PANs (last4 only) are not CHD. Anything more than first6+last4 is CHD and triggers full DSS storage requirements.

Processing = the PAN is in your application's memory in cleartext at any point. A single cleartext byte in your stack drags the host, the OS, the orchestrator, the network into scope.

Transmission = PAN bytes flow through your network, even encrypted. The transmission medium is in scope; the endpoints handling the bytes are.

Connected systems: any system that can affect the security of the CDE — jump hosts, DNS, NTP, AD, monitoring, log aggregators, backups, deploy systems — is connected and shares many DSS requirements (segmentation, vulnerability management, access control). Reduce these aggressively or accept they're in-scope.

SAQ Selection Matrix

Validation type = the document you'll attest to. Picking the wrong one is the most common audit finding for small merchants and the most common over-spend for mid-size.

| SAQ | Eligibility | # of controls | Typical use | |-----|------------|---------------|-------------| | SAQ-A | Card-not-present merchants, ALL CHD functions outsourced to PCI-DSS-validated third parties; merchant only provides redirect or iframe | ~22 controls | Stripe Checkout, Adyen Hosted Payment Page, simple e-commerce with redirect to PSP | | SAQ-A-EP | Same as A but merchant's website influences the payment page (iframe with custom content, JS in the page even if it doesn't touch PAN, hosted fields). | ~140 controls | Stripe Elements, Adyen Components, Braintree Hosted Fields. This is where most "modern" embedded checkouts land. | | SAQ-B | Imprint machines or standalone dial-out terminals, no electronic CHD storage | ~40 controls | Niche — old-school terminal-only | | SAQ-B-IP | Standalone IP-connected terminals validated by P2PE program | ~80 controls | POS only, segmented | | SAQ-C-VT | Virtual terminal on isolated host with no CHD storage | ~80 controls | Phone-only merchants using a hosted virtual terminal | | SAQ-C | Application or system NOT connected to internet or business network beyond the payment app | ~140 controls | Niche — segmented kiosks | | SAQ-P2PE | All CHD captured by P2PE-listed solution; merchant has no electronic CHD | ~33 controls | Restaurants, retail using P2PE-listed terminals (Square Terminal under their P2PE listing, etc.) | | SAQ-SPoC | SPoC (software PIN on COTS) compliant | ~60 controls | Niche, mobile POS | | SAQ-D-Merchant | All other merchants — store, process, or transmit CHD electronically and don't fit a smaller SAQ | ~340 controls | In-house gateway, marketplace splitting funds, level-1 merchants | | SAQ-D-SP | Service providers (process/store/transmit on behalf of others) | ~370 controls | PSPs themselves, marketplace where merchant of record is you | | ROC | Level 1 merchants (>6M Visa/MC/year), all level-1 service providers, anyone whose acquirer demands it | All controls; QSA-led | Big fintechs, large e-com, payment processors |

Levels (Visa/Mastercard rules — Amex/Discover similar but not identical):

| Level | Volume (per brand, per year) | Validation | |-------|------------------------------|-----------| | 1 | >6M transactions | ROC by QSA + ASV scans | | 2 | 1M-6M | SAQ + signed by QSA-trained internal officer (varies by brand) | | 3 | 20k-1M e-com | SAQ + ASV scans | | 4 | <20k e-com or <1M total | SAQ; ASV depends on acquirer |

Service provider levels:

Level 1 SP: >300k transactions/year processed for clients → ROC required
Level 2 SP: <300k → SAQ-D-SP

Frequent mistake: assuming SAQ-A because "we use Stripe". Stripe Checkout = SAQ-A. Stripe Elements = SAQ-A-EP. The line is whether the PAN-collecting input lives in a page you serve.

The 12 Requirements — Deep Dive

PCI DSS v4.0.1 reorganises some sub-requirements vs v3.2.1 but keeps the 12 top-level groups. For each: when it applies, evidence to collect, where teams fail.

Requirement 1 — Install and maintain network security controls

Applies when: any in-scope or connected system; almost always. Evidence: firewall/SG rule sets, network diagram, data-flow diagram, change tickets for rule changes, quarterly rule review. Common gaps: open SSH from 0.0.0.0/0; cloud SGs without explicit deny; missing data-flow diagram; "temporary" rules left in place; lack of segmentation between corporate VPC and CDE VPC. v4.0 update: explicit role responsibility documentation (1.1.1).

Requirement 2 — Apply secure configurations to all system components

Applies when: every system in scope. Evidence: CIS benchmark scan results, hardening images (golden AMIs), default-credential changes, build pipeline showing config baked-in. Common gaps: RDS / Postgres with default config; admin consoles on default ports; orchestrator dashboards (k8s, Rancher, Argo) with weak auth; SaaS tools with shared admin creds. v4.0 update: vendor default removal applies to all roles incl. SNMP community strings, default RDP, etc.

Requirement 3 — Protect stored account data

Applies when: any storage of CHD or sensitive authentication data (SAD). Evidence: DLP scans for stored PAN, cryptographic key inventory, key rotation logs, masking config in apps and logs. Common gaps: PAN in application logs; PAN in CSV exports; SAD (CVV, full track, PIN) stored even briefly post-authorisation (forbidden — full stop); KMS keys without rotation; no documented key custodian. v4.0 update: Disk-level encryption alone is insufficient unless it's a removable storage scenario; column-level encryption preferred.

Requirement 4 — Protect cardholder data with strong cryptography during transmission over open, public networks

Applies when: PAN traverses untrusted networks (internet, untrusted Wi-Fi). Evidence: TLS configuration test (Qualys SSL Labs), cipher suite list, certificate inventory, in-transit encryption between microservices if traversing untrusted network. Common gaps: TLS 1.0/1.1 still enabled (forbidden since 2018); wildcard cert with weak chain; SSLv3 in legacy admin consoles; PAN sent via email or chat (logs become CHD). v4.0 update: explicit prohibition of unprotected PANs sent via end-user messaging tech (4.2.2).

Requirement 5 — Protect all systems and networks from malicious software

Applies when: every in-scope system, plus periodic evaluation for systems "not commonly affected" (e.g. Linux servers). Evidence: anti-malware deployment, scan logs, EDR alerting, periodic risk assessment for systems without anti-malware. Common gaps: "Linux doesn't need AV" assumption without the documented risk assessment v4.0 demands; AV that hasn't updated definitions for weeks; no detection on container hosts. v4.0 update: anti-phishing controls (5.4.1) explicit; periodic evaluation for non-typical systems is now mandatory and documented.

Requirement 6 — Develop and maintain secure systems and software

Applies when: any in-scope custom code or commercial software in CDE. Evidence: SDLC docs, code review records, vulnerability scan output, patch management logs, change control records. Common gaps: SAST/DAST scans not actually run on the CDE's CI; OWASP Top 10 training stale; emergency patches deployed without change control evidence; payment page integrity not verified (new v4.0). v4.0 update: 6.4.3 — payment page scripts authorised, integrity-assured, and inventoried. This is the script-injection / Magecart control. Effective March 31, 2025. Most SAQ-A-EP merchants are not ready for this — start now.

Requirement 7 — Restrict access to system components and cardholder data by business need to know

Applies when: every system holding or controlling access to CHD. Evidence: access control matrix, RBAC config, periodic access reviews (quarterly minimum), need-to-know justifications. Common gaps: "everyone is admin" Slack workspace (which receives alerts containing CHD context); over-privileged service accounts; no documented review cadence.

Requirement 8 — Identify users and authenticate access to system components

Applies when: every in-scope user account. Evidence: MFA enforcement evidence, password policy config, account lifecycle records (joiner/mover/leaver), shared-account inventory and justification. Common gaps: MFA on prod console but not on the CI system that deploys to prod; service-account credentials shared in 1Password "Engineering" vault; ex-employees still in IdP; SSH keys without passphrase + MFA layering. v4.0 update: MFA for all access into the CDE, not just admin (8.4.2). Effective March 31, 2025. Password length minimum 12 characters (was 7).

Requirement 9 — Restrict physical access to cardholder data

Applies when: any premises storing/handling CHD physically. Evidence: badge logs, visitor logs, secure media disposal records, retention destruction certificates. Common gaps: office printers retaining CHD documents; "back room" with ad-hoc access; remote workers handling CHD without controls; backup tapes without chain-of-custody. Note: for cloud-only stacks, you inherit AWS/GCP/Azure's physical controls via their AOC. Reference their attestation in your documentation; it doesn't disappear.

Requirement 10 — Log and monitor all access to system components and cardholder data

Applies when: every in-scope system. Evidence: centralised log inventory, log retention proof (1 year, with 3 months immediately searchable), daily log review evidence, file-integrity monitoring config, time-sync config (NTP). Common gaps: logs in 30-day CloudWatch defaults; no alerting on log gaps; FIM only on a subset of CDE; NTP from random pool not authenticated; daily log review claimed but no evidence of human-in-the-loop. v4.0 update: 10.7.2/10.7.3 — automated detection and response to critical security control failures (e.g. AV down, FIM down, log shipping broken). Effective March 31, 2025.

Requirement 11 — Test security of systems and networks regularly

Applies when: every in-scope system. Evidence: quarterly internal vulnerability scans (any vendor), quarterly external ASV scans (PCI-listed ASV only), annual penetration test (network + application + segmentation), wireless scans, IDS/IPS records. Common gaps: ASV scan that hasn't passed in two quarters (each fail = remediate + rescan; missing one quarter is a finding); pen test scope excluding the actual CDE; no segmentation pen test annually (required for SP, recommended for merchants). v4.0 update: 11.6.1 — change-and-tamper detection on payment pages (script integrity, DOM monitoring). Effective March 31, 2025. Vendor solutions: human-readable list of authorised scripts + CSP + SRI + change detection (Source Defense, Feroot, Akamai Page Integrity Manager).

Requirement 12 — Support information security with organizational policies and programs

Applies when: entire organisation handling CHD. Evidence: information security policy, annual risk assessment, incident response plan + tabletop, security awareness training records, third-party DPA register, hardware/media inventory. Common gaps: policy from 2019 not updated for cloud or v4.0; risk assessment never tested against real incidents; awareness training is one-and-done at hire; service provider list (12.8) doesn't match the actual sub-processor list. v4.0 update: explicit targeted risk analysis (TRA) for any control using the new "customised approach"; documented scope confirmation at least annually (12.5.2) and after every significant change.

Tokenization Patterns

Tokenization replaces the PAN with a non-sensitive token. Done right, it removes systems from PCI scope. Done wrong, it adds complexity without scope reduction.

Stripe (Tokens, PaymentMethods, Setup Intents)

[Browser] -- card data --> Stripe.js / Elements --> Stripe servers
                |                                       |
                |<--- token / pm_xxx ---<---------------|
                |
[Browser] -- pm_xxx + order --> Your server --> Stripe API: createPaymentIntent

PAN never touches your server in cleartext (SAQ-A or SAQ-A-EP)
Token (pm_xxx) is opaque, not CHD
Refunds: use the same token via Stripe API; no PAN re-entry
Saved cards: Stripe Customer + PaymentMethod; refer by ID

Adyen (Encrypted card data + token)

Similar pattern; Adyen Components encrypt in browser, you forward the encrypted blob. Token is recurringDetailReference for stored cards.

Braintree (Drop-in / Hosted Fields)

Same pattern; client-side payment_method_nonce you forward to your server.

In-house tokenization (rare, almost always wrong)

You'd need a token vault, HSM, key custodian roles, scope-isolated network. Almost no merchant should build this; it's the territory of payment processors themselves. If you're considering it, double-check whether a vendor like Spreedly, Basis Theory, or VGS solves the problem at 1% of the build cost.

P2PE (Point-to-Point Encryption)

In-store / POS scenario. PCI-listed P2PE solution encrypts at the card-reader head, decrypts only at the processor. Merchant's POS systems become out-of-scope for most of DSS. Use SAQ-P2PE.

Tokenized refund flows

The classic gotcha: customer service rep needs to refund a charge. With tokenized flow:

Refund by transaction ID, not card number
"Customer wants refund to a different card" → that's a new payment method; reissue or refer to bank
Never accept PAN over phone or chat to "process the refund" — that re-introduces the PAN to your stack

Continuous Compliance Workflow

PCI is annual on paper, daily in reality. Build evidence as it's generated, not when the QSA walks in.

Evidence pipeline:
  config (Terraform) ----> compliance scanner (Checkov/Prowler) ----> findings DB
  CI/CD                ----> SAST/SCA results                      ----> findings DB
  ASV scans (quarterly) ---> ASV portal + signed AOC               ----> evidence vault
  Pen test (annual)    ----> redacted report                       ----> evidence vault
  Access reviews (Q)   ----> IDP exports + signoffs                ----> evidence vault
  Log monitoring       ----> SIEM alerts + tickets                 ----> ticketing system
  Change records       ----> Jira/Linear tickets                   ----> evidence vault
  Training records     ----> LMS exports                           ----> evidence vault

Quarterly attestation pack assembly:
  - Run scope confirmation review (12.5.2)
  - Pull ASV scan results
  - Pull access review signoffs
  - Pull penetration test status
  - Pull policy review records
  - Update SAQ / ROC working draft

Tools that map well:

Vanta / Drata / Secureframe / Sprinto / Tugboat / Thoropass — SAQ automation; weak on ROC, fine for SAQ-A/A-EP/D-Merchant prep
Anitian / A-LIGN / Coalfire — QSA firms with better SaaS tooling than legacy QSAs
Rapid7 / Qualys / Tenable — ASV-listed, can do internal vuln + ASV in one platform
Source Defense / Feroot / Jscrambler / Akamai PIM — payment page integrity (6.4.3 / 11.6.1)

ASV / QSA Selection

ASV (Approved Scanning Vendor):

Required: quarterly external scans of all internet-facing CDE assets
Cheap end ($1k-3k/year): Trustwave, Security Metrics, Clone Systems
Mid ($3k-10k/year): Qualys (their PCI ASV bundle), Rapid7
Avoid: anyone not on the PCI SSC's official ASV list — their scan won't satisfy validation
Pass = clean scan or all findings remediated/false-positive'd within the quarter

QSA selection (when ROC required):

Get 3 quotes; expect $30k-$150k+ depending on scope
Mid-tier QSAs (Coalfire, A-LIGN, Schellman, ControlCase, NCC Group): well-rounded, SaaS-savvy
Big-4 (PwC, Deloitte, KPMG, EY): overkill cost for most fintechs, useful when the audit needs to satisfy a board with name recognition
Boutiques (Anitian, BlueAlly, Fortra, K3DES): often best price/value for early-stage
Always check the QSA's experience with your stack (cloud-native, Kubernetes, Stripe-Connect-style flows)
Lock in: scope memo, evidence list, kickoff date, fieldwork window, draft AOC delivery date, final AOC date

Common Scenarios

"We're switching from Stripe Checkout to Stripe Elements"

You move from SAQ-A to SAQ-A-EP. New controls: 6.4.3 (script integrity), 11.6.1 (page tamper detection), tighter SDLC requirements, ASV scans now mandatory in most acquirer programs. Allow 6-12 weeks of remediation and tooling deployment before the next attestation.

"We just acquired a company that takes cards"

Treat their CDE as out-of-scope for your AOC until merged. Their SAQ/AOC continues until expiration. Plan an integration migration that first moves their flows onto your validated PSP integration then decommissions theirs. Don't let M&A leak CHD into your unprepared environment.

"Engineering wants to log the PAN for debugging"

No. Period. The fastest way to expand scope from SAQ-A-EP to SAQ-D is a single PAN in a log file. Add code-side masking (first6+last4 max) and CI lint that fails commits adding card_number-style fields without masking.

"Customer service needs to retrieve a card on file for a phone refund"

Use the gateway's stored payment-method ID; never display the full PAN. If your CRM shows full PAN, the CRM is in scope.

"We received a Mastercard SiteData Protect / Visa CISP letter"

Acquirer-driven program letter. Don't ignore. Map the letter's requirements (often equivalent to PCI 6.4.3 / 11.6.1) and respond with a remediation plan within the deadline (usually 30-60 days).

"The QSA found a gap in our segmentation"

Segmentation tests must show CDE traffic cannot reach connected systems and vice-versa beyond the documented allowlist. Common gap: management VPN that terminates inside CDE. Move VPN to a jump-host segment with auditable access; redo the segmentation test.

v4.0.1 Dates That Bite

PCI v4.0 future-dated requirements that became mandatory March 31, 2025:

| Req | Description | |-----|-------------| | 3.4.2 | Restrict copy / relocate of PAN through remote access tech | | 3.5.1.2 | Disk-level / partition encryption only allowed on removable storage | | 6.4.3 | Authorise, integrity-check, and inventory all scripts on payment page | | 8.3.6 | New password complexity (min 12 chars; class diversity) | | 8.4.2 | MFA for ALL access into the CDE (not just admins) | | 8.5.1 | MFA implementation: not susceptible to replay; no bypass without exception | | 10.4.1.1 | Daily log review automated | | 10.7 | Critical security control failure detection + response | | 11.6.1 | Payment page change-and-tamper detection mechanism | | 12.6.3.1 / 12.6.3.2 | Security awareness includes phishing + social engineering specifics |

v4.0.1 (released June 2024) adds clarifications, customised-approach updates, and the Designated Entities Supplemental Validation (DESV) integrations. The substance of dates above did not change.

Anti-patterns

Self-attesting SAQ-A while running Stripe Elements — Elements requires SAQ-A-EP; submitting SAQ-A is technically a false attestation
Storing first 6 + last 4 of PAN in analytics — first 6 is BIN; combining with last 4 + cardholder name pushes data into CHD territory in some interpretations; mask to last 4 only
Using "we use AWS so it's PCI compliant" — AWS provides infrastructure controls only; your application controls (req 6, 7, 8, 10, 11) are still your responsibility
Pen-testing only the public website — pen test must cover the CDE perimeter, internal CDE, and segmentation
Annual rotation of access keys "manually" — auditors want IaC + automation evidence
Treating SAQ as a once-a-year form — it's an attestation; it must be true on the day signed and you must monitor continuously
Letting the QSA drive scope — the merchant defines scope; the QSA validates. Going in with a scope memo prepared cuts the audit by weeks
Building in-house tokenization — solved problem; vendor it
Sharing customer card details over Slack to "help debug a refund" — Slack workspace becomes in-scope CHD storage immediately; one of the most common scope-blow-ups
Skipping the Designated Entities Supplemental Validation (DESV) when it applies — service providers with significant volume and prior breach are auto-DESV; ignoring it = audit fail
Renewing attestation without re-testing segmentation after a network change — segmentation testing is required after every significant change, not just annually
Letting marketing add a third-party tracker to the payment page — every script on the payment page is in scope under 6.4.3 / 11.6.1; even a "harmless" analytics tag can host a Magecart skimmer at runtime
Outsourcing PCI to a fractional vCISO without engineering buy-in — policy-only programs fail at the evidence-gathering step; controls must live in code and CI, not in a binder
Treating cloud "shared responsibility" as boilerplate — the AWS / GCP / Azure AOC covers their layer only; your application, IAM, network rule sets, KMS use, and logging are yours to attest

Exit Criteria

A PCI DSS readiness audit is complete when:

Scope is documented with data-flow diagram and signed off by IT + product + finance
Validation path (ROC / SAQ variant) is selected and matches scope and volume
Every one of the 12 requirements has a documented control owner and evidence repository
All v4.0.1 mandatory dates (March 2025) are met or have a documented compensating control
Tokenization architecture is in place; PAN never touches systems outside CDE
ASV scans pass for the most recent quarter
Penetration test report (network + app + segmentation) is current within 12 months
Access reviews completed for the most recent quarter
Incident response plan tested via tabletop in the last 12 months
Continuous-compliance evidence pipeline produces evidence on a schedule (not when the QSA arrives)
AOC (Attestation of Compliance) signed and submitted to acquirer
Roadmap for next year's significant changes (new payment surfaces, new acquirers, M&A) is on the calendar with re-scoping milestones