pci-dss-readiness-auditor

by charlie-morrison

Install this Skill

curl -fsSL -o pci-dss-readiness-auditor.zip https://skill.seembox.com/api/v1/skills/pci-dss-readiness-auditor/download && unzip pci-dss-readiness-auditor.zip

Download pci-dss-readiness-auditor.zip

SKILL.md About

---
name: pci-dss-readiness-auditor
description: Audit a payment stack for PCI DSS v4.0 / v4.0.1 readiness — determine cardholder data environment (CDE) scope from data flows (storage, processing, transmission), pick the right validation path (ROC vs SAQ-A vs SAQ-A-EP vs SAQ-D-Merchant vs SAQ-D-SP), evaluate tokenization vs encryption vs P2PE choices (Stripe Elements / Adyen Hosted / Braintree Drop-in / in-house HSM), check segmentation between CDE and corporate networks, and walk every one of the 12 requirements with evidence-needed and common-gaps annotations. Covers ASV scan vendor selection, QSA selection, the v4.0 customised approach for novel controls, continuous compliance evidence pipelines, log retention (1 year online + 3 months immediate), tokenized refund flows, and the new v4.0.1 dates that bite. Triggers on "pci dss", "pci compliance", "pci v4", "pci v4.0.1", "pci scope", "cardholder data environment", "cde", "saq-a", "saq-a-ep", "saq-d", "roc", "tokenization", "p2pe", "stripe pci", "adyen pci", "asv scan", "qsa", "pci audit", "pci readiness", "pci report on compliance".
metadata:
  tags: ["pci-dss", "compliance", "payments", "security", "tokenization", "audit", "fintech", "stripe", "adyen", "braintree"]
---

# 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

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

_meta.json Metadata

{
  "ownerId": "kn7d5eszdfwftk153ymhdm4qhs83qsqy",
  "publishedAt": 1777860685344,
  "slug": "pci-dss-readiness-auditor",
  "version": "1.0.0"
}