---
# === IDENTITY ===
id: business/retail-transformation/retail-cybersecurity-pci-compliance/2026
canonical_question: "How do I actually implement PCI DSS 4.0.1 compliance for a retail or e-commerce business — gap assessment, script controls, MFA, continuous monitoring, and passing validation?"
aliases:
  - "PCI DSS 4.0 retail compliance implementation"
  - "how to pass PCI DSS 4.0.1 assessment"
  - "e-commerce payment page security implementation"
  - "Magecart protection and PCI compliance steps"
  - "PCI requirement 6.4.3 and 11.6.1 implementation"
  - "retail payment security compliance execution"
entity_type: execution_recipe
domain: business > retail-transformation > Retail Cybersecurity & PCI Compliance
region: global
jurisdiction: global
temporal_scope: 2025-2026

# === VERIFICATION ===
last_verified: 2026-03-11
confidence: 0.92
version: 2.0
first_published: 2026-03-09

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: evolving
  last_breaking_change: "PCI DSS v4.0.1 future-dated requirements became mandatory March 31, 2025 — 51 requirements including Req 6.4.3 (script inventory) and 11.6.1 (tamper detection) now enforced"
  next_review: 2026-09-07
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "All 51 PCI DSS v4.0 future-dated requirements became mandatory March 31, 2025 — no further extensions"
  - "Level 1 merchants (6M+ transactions/year) must engage a Qualified Security Assessor (QSA) — self-assessment is not permitted"
  - "Quarterly ASV scans are mandatory for all merchant levels — no vulnerability with CVSS >= 4.0 may be present in passing scan"
  - "Requirements 6.4.3 and 11.6.1 apply to ALL merchants with e-commerce payment pages, including SAQ-A merchants using hosted checkout"
  - "Non-compliance fines range from $5,000 to $100,000 per month, plus potential bank relationship termination"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User needs general enterprise cybersecurity framework, not retail/PCI-specific"
    use_instead: "compliance/cybersecurity-frameworks/2026"
  - condition: "User needs payment processor vendor selection, not compliance implementation"
    use_instead: "Search knowledgelib.io for payment processor selection — no dedicated unit yet"
  - condition: "User needs data privacy regulation compliance (GDPR, CCPA), not payment security"
    use_instead: "compliance/data-privacy-regulations/2026"
  - condition: "User already has full PCI DSS v4.0.1 compliance and just needs monitoring guidance"
    use_instead: "compliance/continuous-compliance-monitoring/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: merchant_level
    question: "What is the retailer's PCI merchant level?"
    type: choice
    options:
      - "Level 1 (over 6M transactions/year — requires annual ROC by QSA)"
      - "Level 2 (1M-6M transactions/year — annual SAQ)"
      - "Level 3 (20K-1M e-commerce transactions/year)"
      - "Level 4 (under 20K e-commerce or under 1M other transactions/year)"
  - key: payment_architecture
    question: "How does the retailer handle payment data?"
    type: choice
    options:
      - "Direct payment processing (cardholder data in merchant systems)"
      - "Redirect/iframe (Stripe, Adyen hosted checkout)"
      - "Third-party hosted payment page (no card data touches merchant servers)"
      - "Mixed — some direct, some hosted"
  - key: compliance_status
    question: "What is the current PCI DSS compliance status?"
    type: choice
    options:
      - "Not currently PCI DSS compliant"
      - "PCI DSS v3.2.1 compliant, not yet migrated to v4.0"
      - "PCI DSS v4.0 partially compliant, future-dated items pending"
      - "PCI DSS v4.0 fully compliant including future-dated requirements"
  - key: budget_for_tools
    question: "What is the annual compliance budget?"
    type: choice
    options:
      - "Minimal (under $25K — Level 4 self-managed)"
      - "Standard ($25K-$100K — Level 3-4 with external help)"
      - "Enterprise ($100K-$500K — Level 1-2 full program)"
      - "No limit"

# === EXECUTION METADATA ===
execution:
  required_inputs:
    - name: "Current PCI DSS compliance status"
      source: "Internal compliance team or prior QSA report"
      format: "document"
    - name: "Payment architecture diagram"
      source: "IT/engineering team"
      format: "document"
    - name: "Cardholder data environment (CDE) inventory"
      source: "IT security team"
      format: "structured data"
    - name: "Third-party service provider list"
      source: "Vendor management / procurement"
      format: "spreadsheet"
  outputs:
    - name: "PCI DSS v4.0.1 gap assessment report"
      format: "document"
      description: "Requirement-by-requirement gap analysis with remediation priorities, timelines, and cost estimates"
    - name: "Payment page script inventory"
      format: "spreadsheet"
      description: "Complete inventory of all client-side scripts on payment pages with authorization status, SRI hashes, and business justification"
    - name: "Compliance evidence package"
      format: "document collection"
      description: "SAQ or ROC documentation, ASV scan results, penetration test report, CSP configuration, MFA deployment evidence"
    - name: "Continuous monitoring dashboard"
      format: "configured platform"
      description: "Real-time script monitoring, CSP violation alerts, and compliance status tracking"
  tools_required:
    - name: "ASV scanning service"
      purpose: "Quarterly external vulnerability scanning"
      tier: "paid"
      cost: "$100-$200/IP/quarter ($1,200-$4,800/year for typical retail)"
      alternatives: ["Qualys", "Tenable", "Trustwave", "SecurityMetrics"]
    - name: "Client-side script monitoring"
      purpose: "Req 6.4.3 script inventory and Req 11.6.1 tamper detection"
      tier: "paid"
      cost: "$5,000-$50,000/year depending on page volume"
      alternatives: ["Feroot PageGuard", "Imperva Client-Side Protection", "Akamai Page Integrity Manager", "c/side"]
    - name: "WAF (Web Application Firewall)"
      purpose: "Req 6.4.2 protection for public-facing web applications"
      tier: "paid"
      cost: "$3,000-$50,000/year"
      alternatives: ["Cloudflare WAF", "AWS WAF", "Akamai", "Imperva"]
    - name: "Penetration testing service"
      purpose: "Annual penetration test (Req 11.4)"
      tier: "paid"
      cost: "$5,000-$30,000 per engagement"
      alternatives: ["Bishop Fox", "Rapid7", "CrowdStrike", "any PCI-qualified pen test firm"]
    - name: "SIEM / log management"
      purpose: "Req 10 logging and monitoring"
      tier: "paid"
      cost: "$10,000-$100,000/year"
      alternatives: ["Splunk", "Microsoft Sentinel", "Elastic SIEM", "Sumo Logic"]
  credentials_needed:
    - service: "ASV scanning provider"
      type: "Account + API key"
      where_to_get: "https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors"
      free_tier_limits: "No free tier — paid service required"
    - service: "QSA firm (Level 1 merchants)"
      type: "Engagement contract"
      where_to_get: "https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors"
      free_tier_limits: "N/A — engagement required"
  estimated_duration: "3-9 months (gap assessment through passing validation)"
  estimated_cost: "$3,000-$25,000 (Level 4) to $290,000-$3,200,000+ (Level 1 enterprise)"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/retail-transformation/retail-cybersecurity-pci-compliance/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-11)"

# === RELATED UNITS ===
related_kos:
  depends_on: []
  feeds_into:
    - id: "business/retail-transformation/cdp-selection-for-retail/2026"
      label: "CDP selection must account for PCI data handling requirements"
  related_to:
    - id: "business/retail-transformation/supply-chain-digitization-roadmap/2026"
      label: "Supply chain systems may fall within CDE scope"
  alternative_to: []

# === SOURCES ===
sources:
  - id: src1
    title: "How to Comply with PCI DSS 4.0.1 (2026 Guide)"
    author: UpGuard
    url: https://www.upguard.com/blog/pci-compliance
    type: technical_blog
    published: 2026-01-15
    reliability: high
  - id: src2
    title: "Now is the Time to Adopt Future-Dated Requirements of PCI DSS v4.x"
    author: PCI Security Standards Council
    url: https://blog.pcisecuritystandards.org/now-is-the-time-for-organizations-to-adopt-the-future-dated-requirements-of-pci-dss-v4-x
    type: official_docs
    published: 2025-02-01
    reliability: authoritative
  - id: src3
    title: "The Ultimate PCI DSS 4.0.1 Compliance Checklist for 2026"
    author: Feroot Security
    url: https://www.feroot.com/blog/pci-compliance-checklist-for-cisos/
    type: technical_blog
    published: 2026-01-10
    reliability: high
  - id: src4
    title: "How to Comply with PCI DSS 4.0 Requirements 6.4.3 and 11.6.1"
    author: Imperva
    url: https://www.imperva.com/blog/how-to-comply-with-pci-dss-4-0-requirements-6-4-3-and-11-6-1/
    type: technical_blog
    published: 2025-06-01
    reliability: high
  - id: src5
    title: "Enterprise PCI Compliance: The Cost of Getting It Right in 2026"
    author: Feroot Security
    url: https://www.feroot.com/blog/enterprise-pci-compliance-cost-2026/
    type: industry_report
    published: 2026-02-01
    reliability: high
  - id: src6
    title: "E-Skimming Prevention Guide: Magecart Defense & PCI Compliance"
    author: Feroot Security
    url: https://www.feroot.com/blog/e-skimming-prevention-guide-magecart-defense-and-pci/
    type: technical_blog
    published: 2025-09-01
    reliability: high
  - id: src7
    title: "PCI DSS ASV Scans Explained: Costs, Requirements, Passing Criteria (2026)"
    author: RedSec Labs
    url: https://www.redseclabs.com/blog/pci-dss-asv-scans-explained-costs-requirements-passing-criteria-real-world-limitations-2026/
    type: technical_blog
    published: 2026-01-20
    reliability: high
  - id: src8
    title: "PCI DSS v4.0 Vulnerability Scanning and Penetration Testing Requirements"
    author: CompliancePoint
    url: https://www.compliancepoint.com/assurance/pci-dss-v4-0-vuln-pen-requirements/
    type: technical_blog
    published: 2025-03-01
    reliability: high
---

# Retail PCI DSS 4.0.1 Compliance: Gap Assessment to Passing Validation

## Purpose

This recipe produces a fully compliant PCI DSS v4.0.1 posture for a retail or e-commerce business — including a gap assessment report, remediated payment page script controls (Req 6.4.3 + 11.6.1), deployed MFA across the cardholder data environment, passing ASV scan results, penetration test report, and continuous monitoring dashboard — ready for SAQ submission or QSA-led ROC validation. All 51 future-dated requirements that became mandatory on March 31, 2025 are covered. [src2]

## Prerequisites
<!-- Agents: verify ALL prerequisites before executing. Missing prerequisites = failed execution. -->

- [ ] **Payment architecture diagram** — document all systems that touch, process, store, or transmit cardholder data
- [ ] **Current compliance status** — prior SAQ/ROC, last QSA report, or acknowledgment of non-compliance
- [ ] **Third-party service provider inventory** — every vendor with access to cardholder data or payment page scripts
- [ ] **CDE network diagram** — segmentation boundaries, firewall rules, data flows between systems
- [ ] **ASV scanning provider account** — select from [PCI SSC approved list](https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors)
- [ ] **QSA engagement** (Level 1 only) — contract with [qualified assessor](https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors)
- [ ] **Cross-departmental stakeholder buy-in** — IT security, legal, compliance, procurement, and engineering must be aligned

## Constraints
<!-- Hard rules. Agents: enforce throughout execution. Violating these = failed assessment or legal exposure. -->

- All 51 future-dated PCI DSS v4.0 requirements became mandatory March 31, 2025. There are no further extensions. Retailers not yet compliant face immediate assessment failure and fines of $5,000-$100,000/month. [src2]
- Level 1 merchants (6M+ transactions/year) must have a QSA conduct the assessment — self-assessment is prohibited. [src1]
- Requirements 6.4.3 (script inventory) and 11.6.1 (tamper detection) apply even to SAQ-A merchants using hosted checkout (Stripe, Adyen iframe). v4.0.1 clarified that merchants own scripts outside provider iframes. [src3]
- ASV scans must pass with no vulnerabilities at CVSS 4.0 or higher. SSL 2.0, 3.0, TLS 1.0, TLS 1.1, DES, 3DES, and RC4 are automatic failures. [src7]
- Penetration testing must be performed annually and after any significant infrastructure change — results must show all exploitable vulnerabilities remediated and verified. [src8]
- Third-party vendor compliance adds 3-6 months to timelines. Do not underestimate vendor remediation dependencies. [src1]

## Tool Selection Decision

```
Which SAQ type?
├── All cardholder data outsourced to third-party hosted payment page?
│   └── SAQ A — but still must implement Req 6.4.3 + 11.6.1 on checkout pages
├── E-commerce with third-party payment processing but merchant website controls payment flow?
│   └── SAQ A-EP — full script inventory + CSP + tamper detection required
├── Payment terminals only (no e-commerce)?
│   ├── Imprint machines or standalone dial-out terminals?
│   │   └── SAQ B — minimal scope
│   └── IP-connected terminals?
│       └── SAQ B-IP or SAQ C
├── Payment application connected to internet (no e-commerce card storage)?
│   └── SAQ C — network segmentation + access controls required
├── P2PE hardware terminal with validated encryption?
│   └── SAQ P2PE — reduced scope through validated encryption
└── Does not fit any above OR stores cardholder data?
    └── SAQ D — full 12 requirement families, all controls required
```

| Path | Applicable Merchants | Est. Annual Cost | Timeline | Complexity |
|------|---------------------|-----------------|----------|------------|
| SAQ A | Hosted checkout only (Stripe/Adyen iframe) | $3K-$15K | 1-3 months | Low — but Req 6.4.3/11.6.1 still required |
| SAQ A-EP | E-commerce with redirect to processor | $10K-$50K | 2-4 months | Medium — script controls + CSP |
| SAQ C | IP-connected payment apps, no e-commerce storage | $10K-$40K | 2-4 months | Medium — network segmentation focus |
| SAQ D / ROC | Direct processing or stores cardholder data | $50K-$500K+ | 4-9 months | High — all 12 requirement families |

## Execution Flow

### Step 1: Define PCI DSS Scope and Conduct Gap Assessment

**Duration**: 2-4 weeks
**Tool**: Spreadsheet + network scanning tools (Nmap, Qualys)

Map every system component that stores, processes, or transmits cardholder data. Include all connected systems, network segments, and personnel with access. Document data flows from card entry to settlement. Review this scope against all 12 PCI DSS requirement families and the 51 future-dated requirements. [src1]

```
Scoping checklist:
1. Identify all payment channels (e-commerce, POS, MOTO, mobile)
2. Map cardholder data flows for each channel
3. List all systems in the CDE (servers, databases, applications)
4. List all systems connected to the CDE (jump hosts, log servers, DNS)
5. Inventory all third-party service providers with CDE access
6. Document network segmentation boundaries
7. Determine SAQ type based on payment architecture
8. Compare current controls against each of the 12 requirement families
9. Flag all 51 future-dated requirements — mark compliant/non-compliant
10. Prioritize gaps by risk: Req 6.4.3, 11.6.1, MFA, encryption first
```

**Verify**: Gap assessment document lists every non-compliant requirement with specific remediation action; CDE scope diagram reviewed and signed off by IT security lead
**If failed**: If scope cannot be determined, engage a QSA for a scoping consultation ($5,000-$15,000) before proceeding — incorrect scope invalidates the entire assessment

### Step 2: Implement Payment Page Script Controls (Req 6.4.3 + 11.6.1)

**Duration**: 2-6 weeks
**Tool**: Client-side monitoring tool (Feroot, Imperva, Akamai, c/side) + CSP headers

This is the highest-risk requirement for e-commerce retailers. Inventory every script executing on payment pages, authorize each one, and deploy tamper detection. Most retailers discover 15-40 scripts they did not know existed on their payment pages — analytics, chat widgets, A/B testing, tracking pixels. [src3]

```
Step 2a — Script discovery and inventory:
1. Use browser DevTools (Network tab) on every payment page variant
2. Record: script URL, source domain, purpose, owner, load method
3. Deploy automated script discovery tool for continuous inventory
4. Document each script with business justification

Step 2b — Authorization and integrity:
1. Create authorization whitelist: script URL + SHA-256 hash + purpose
2. Implement Content Security Policy (CSP) headers:
   Content-Security-Policy:
     default-src 'self';
     script-src 'self' https://js.stripe.com https://www.googletagmanager.com;
     frame-src 'self' https://js.stripe.com;
     connect-src 'self' https://api.stripe.com;
     style-src 'self' 'unsafe-inline';
     img-src 'self' data: https:;
     report-uri /csp-violations
3. Implement Subresource Integrity (SRI) for all static scripts:
   <script src="https://cdn.example.com/lib.js"
     integrity="sha384-{hash}"
     crossorigin="anonymous"></script>
4. Remove any script without documented business justification

Step 2c — Tamper detection (Req 11.6.1):
1. Deploy change detection monitoring on all payment pages
2. Configure alerts for: new scripts, modified scripts, new domains,
   changed HTTP headers (CSP, X-Frame-Options, Strict-Transport-Security)
3. Set monitoring frequency: at minimum weekly, recommend daily or real-time
4. Establish incident response procedure for unauthorized changes
```

**Verify**: Script inventory is complete (compare automated tool results against manual DevTools audit); CSP deployed and reporting violations; tamper detection active with test alert confirmed; no unauthorized scripts remain on payment pages
**If failed**: If script count exceeds 30, prioritize removal before authorization. Every unnecessary script is an attack surface. If CSP breaks page functionality, use report-only mode first (`Content-Security-Policy-Report-Only`) to identify issues before enforcement. [src6]

### Step 3: Deploy Multi-Factor Authentication Across CDE

**Duration**: 1-3 weeks
**Tool**: MFA provider (Duo, Okta, Microsoft Entra, Google Workspace)

PCI DSS v4.0 expanded MFA requirements from remote-access-only to all access into the cardholder data environment — including local/console access, application access, and network device management. This catches retailers with legacy POS management systems that previously only required passwords. [src1]

```
MFA deployment checklist:
1. Inventory all access paths to CDE (remote VPN, local console, SSH,
   RDP, application logins, network device management interfaces)
2. Deploy MFA on every access path — no exceptions
3. Enforce 12-character minimum passwords (8 if system cannot support 12)
4. Implement account lockout after 10 failed attempts
5. Require password changes every 90 days (or use dynamic analysis
   per Req 8.3.9 customized approach)
6. Review all service/system accounts — document, restrict, monitor
7. Remove shared/group accounts or implement individual accountability
```

**Verify**: MFA active on 100% of CDE access paths; test each path to confirm MFA challenge triggers; password policy enforced in directory services; no shared accounts in CDE
**If failed**: If legacy POS systems cannot support MFA, implement compensating controls (documented in SAQ/ROC) — network segmentation + enhanced monitoring + restricted access hours. This is permissible under PCI DSS customized approach but requires QSA approval for Level 1 merchants.

### Step 4: Harden Network Segmentation and Encryption

**Duration**: 2-4 weeks
**Tool**: Firewall management, encryption tools, network scanning

Ensure the CDE is properly segmented from non-CDE networks. Encrypt cardholder data at rest and in transit. Deploy tokenization where possible to reduce scope. [src1]

```
Network hardening checklist:
1. Verify firewall rules restrict CDE traffic to documented, authorized flows
2. Disable all unnecessary services, protocols, and ports in CDE
3. Encrypt cardholder data at rest (AES-256 or equivalent)
4. Enforce TLS 1.2+ for all data in transit — disable TLS 1.0, 1.1, SSL
5. Implement tokenization for stored card data where possible
6. Deploy 3DS2 (3D Secure 2) for CNP transactions — reduces fraud liability
7. Verify anti-malware is active on all CDE systems
8. Configure host-based intrusion detection on critical CDE servers
```

**Verify**: Network scan shows no unauthorized traffic crossing CDE boundary; SSL/TLS test confirms only TLS 1.2+ accepted; encryption key management documented; tokenization operational for card storage
**If failed**: If legacy systems require TLS 1.0, document compensating controls and plan migration — TLS 1.0/1.1 is an automatic ASV scan failure. [src7]

### Step 5: Conduct Vulnerability Scanning and Penetration Testing

**Duration**: 2-4 weeks (scheduling + testing + remediation)
**Tool**: ASV provider (quarterly scan) + penetration testing firm (annual)

Run quarterly external ASV scans and internal vulnerability scans. Conduct annual penetration testing of both the external perimeter and internal CDE segmentation. Remediate all findings and re-test. [src8]

```
Scanning and testing sequence:
1. Run ASV external scan on all public-facing IPs/domains in scope
2. Run internal vulnerability scan (authenticated) on all CDE systems
3. Remediate all vulnerabilities CVSS >= 4.0 (ASV pass requirement)
4. Re-scan to confirm remediation
5. Schedule penetration test — external + internal + segmentation
6. Pen test must cover: network layer, application layer, CDE segmentation
7. Remediate all exploitable findings
8. Re-test to verify remediation
9. Document all results in evidence package

ASV scan pass criteria:
- No vulnerability with CVSS base score >= 4.0
- No SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 in use
- No DES, 3DES, RC4 ciphers
- Low-severity findings (CVSS < 4.0) are permitted
```

**Verify**: ASV scan report shows "Pass" status; penetration test report shows all exploitable vulnerabilities remediated; internal scan shows no critical/high findings unresolved
**If failed**: If ASV scan fails, remediate flagged vulnerabilities and re-scan within the same quarter. If penetration test reveals critical findings, remediate and schedule re-test before submitting for validation. Budget an extra 2-4 weeks for remediation cycles. [src7]

### Step 6: Establish Continuous Compliance Monitoring

**Duration**: 2-4 weeks setup + ongoing
**Tool**: SIEM, automated script monitoring, dashboard

PCI DSS v4.0 shifted from point-in-time compliance to continuous monitoring. Deploy automated tools that maintain compliance evidence as a byproduct of daily operations, not annual audit sprints. [src3]

```
Continuous monitoring program:
1. Payment page script monitoring — daily automated scans minimum
2. CSP violation reporting — real-time alerts to security team
3. ASV external scanning — quarterly (schedule recurring)
4. Internal vulnerability scanning — quarterly minimum (monthly recommended)
5. Penetration testing — annually + after significant changes
6. Log review — automated daily review of CDE access logs (Req 10)
7. User access review — quarterly review of CDE access privileges
8. Third-party vendor compliance — annual re-assessment of all providers
9. Incident response testing — annual tabletop exercise minimum
10. Policy review — annual review and update of all security policies
```

**Verify**: All monitoring tools operational and generating alerts; dashboard shows current compliance status across all 12 requirement families; first automated scan cycle completed successfully; alert routing confirmed to responsible personnel
**If failed**: If SIEM integration is delayed, implement interim manual log review (daily) while automation is deployed. Do not skip logging — Req 10 is a common assessment failure point.

### Step 7: Complete Validation and Submit Documentation

**Duration**: 2-4 weeks
**Tool**: SAQ form or QSA engagement

Compile all evidence, complete the appropriate SAQ (or undergo QSA assessment for Level 1), and submit to the acquiring bank or payment brand. [src2]

```
Validation documentation package:
1. Completed SAQ (type A, A-EP, B, C, or D) — or ROC for Level 1
2. Attestation of Compliance (AOC) signed by authorized officer
3. Passing ASV scan report (most recent quarter)
4. Penetration test report with remediation evidence
5. Script inventory with authorization records (Req 6.4.3)
6. Tamper detection configuration and alert evidence (Req 11.6.1)
7. MFA deployment evidence for all CDE access paths
8. Network diagram with segmentation boundaries
9. Third-party service provider compliance attestations
10. Incident response plan (tested within last 12 months)
```

**Verify**: All SAQ/ROC questions answered with supporting evidence; AOC signed; all scan reports current (within 90 days); no open critical/high findings
**If failed**: If QSA identifies gaps during ROC assessment, remediate and request re-assessment of specific requirements. Most QSAs allow targeted re-assessment without restarting the full engagement.

## Output Schema

```json
{
  "output_type": "pci_dss_compliance_package",
  "format": "document collection",
  "columns": [
    {"name": "compliance_status", "type": "string", "description": "Compliant, Non-Compliant, or In Progress with specific gap list", "required": true},
    {"name": "saq_type", "type": "string", "description": "SAQ A, A-EP, B, B-IP, C, C-VT, D, or P2PE — or ROC for Level 1", "required": true},
    {"name": "merchant_level", "type": "number", "description": "PCI merchant level 1-4 based on annual transaction volume", "required": true},
    {"name": "gap_count", "type": "number", "description": "Number of non-compliant requirements identified in gap assessment", "required": true},
    {"name": "script_inventory_count", "type": "number", "description": "Total scripts on payment pages — authorized and inventoried", "required": true},
    {"name": "asv_scan_status", "type": "string", "description": "Pass or Fail with date of most recent quarterly scan", "required": true},
    {"name": "pen_test_status", "type": "string", "description": "Complete with all findings remediated, or open findings count", "required": true},
    {"name": "mfa_coverage", "type": "number", "description": "Percentage of CDE access paths with MFA active", "required": true},
    {"name": "open_remediation_items", "type": "number", "description": "Outstanding gaps requiring remediation before passing validation", "required": false}
  ],
  "expected_row_count": "1 (single compliance status record)",
  "sort_order": "N/A",
  "deduplication_key": "merchant_id + assessment_date"
}
```

## Quality Benchmarks

| Quality Metric | Minimum Acceptable | Good | Excellent |
|---------------|-------------------|------|-----------|
| CDE scope accuracy | All systems identified | Verified by independent scan | QSA-validated scope |
| Script inventory completeness | 90% of scripts inventoried | 100% inventoried + authorized | 100% + SRI hashes + CSP enforced |
| MFA coverage | 100% remote access | 100% all CDE access | 100% + hardware tokens for admin |
| ASV scan result | Pass (no CVSS >= 4.0) | Pass with < 5 low findings | Pass with 0 findings |
| Penetration test findings | All critical/high remediated | All findings remediated | Zero exploitable findings |
| Time to detect script change | < 7 days (weekly scan) | < 24 hours | Real-time (< 1 hour) |
| Vendor compliance attestations | All Level 1 vendors attested | All vendors attested | All vendors attested + monitored |

**If below minimum**: Halt validation submission. Re-run the relevant execution step. Submitting for assessment with known gaps wastes QSA fees and risks formal non-compliance findings on record. [src5]

## Error Handling

| Error | Likely Cause | Recovery Action |
|-------|-------------|----------------|
| ASV scan fails with high-severity findings | Unpatched systems, outdated TLS, exposed services | Patch/update flagged systems; disable TLS 1.0/1.1; re-scan within same quarter |
| CSP breaks payment page functionality | Overly restrictive policy blocking legitimate scripts | Switch to `Content-Security-Policy-Report-Only` first; analyze violations; whitelist legitimate sources; re-enforce |
| Script inventory misses dynamically loaded scripts | Tag managers (GTM) loading scripts not visible in static analysis | Use runtime monitoring tools; capture all scripts loaded during actual checkout flow including async/deferred |
| MFA breaks legacy POS management | Older systems lack MFA support | Document compensating controls (enhanced monitoring + restricted access); plan system upgrade; QSA approval required for Level 1 |
| Third-party vendor refuses compliance attestation | Vendor lacks PCI compliance or refuses to share evidence | Escalate contractually; switch vendors if no attestation within 60 days; document risk acceptance if no alternative exists |
| QSA rejects compensating controls | Controls insufficient to mitigate risk | Work with QSA to redesign controls; implement the original requirement if feasible; consider architecture change to reduce scope |
| Penetration test reveals critical RCE vulnerability | Unpatched application or framework | Emergency patch; restrict access; re-test; do not proceed to validation until remediated |

## Cost Breakdown

| Component | Level 4 (Self-Managed) | Level 2-3 (Guided) | Level 1 (Enterprise) |
|-----------|----------------------|--------------------|--------------------|
| QSA / SAQ assessment | $1K-$5K (self + consultant) | $10K-$50K (SAQ + external help) | $25K-$100K+ (full QSA ROC) |
| ASV quarterly scans | $400-$1,200/year | $1,200-$4,800/year | $2,400-$10K/year |
| Penetration testing | $5K-$10K/year | $10K-$30K/year | $20K-$100K+/year |
| Script monitoring tool | $5K-$10K/year | $10K-$25K/year | $25K-$50K+/year |
| WAF | $3K-$10K/year | $10K-$25K/year | $25K-$50K+/year |
| SIEM / logging | $5K-$15K/year | $15K-$50K/year | $50K-$100K+/year |
| MFA deployment | $1K-$5K | $5K-$15K | $15K-$50K |
| Remediation / hardening | $2K-$15K | $15K-$100K | $50K-$500K+ |
| Personnel (FTE allocation) | 0.25 FTE | 0.5-1 FTE | 1-3 FTE dedicated |
| **Year 1 Total** | **$15K-$50K** | **$50K-$250K** | **$290K-$3.2M+** |
| **Annual Ongoing** | **$10K-$35K** | **$40K-$175K** | **$265K-$2.7M+** |

Source: Enterprise cost ranges from Feroot Security 2026 analysis. [src5]

## Anti-Patterns

### Wrong: Treating PCI DSS compliance as an annual checkbox
Retailers achieve compliance at assessment time but let controls degrade between assessments. Scripts are added to payment pages without authorization, MFA exceptions accumulate, and vendor attestations lapse. The next Magecart attack exploits a control that was compliant 10 months ago but has since degraded. Magecart attacks are attempted once every 16 minutes. [src6]

### Correct: Implement continuous compliance with automated monitoring
Deploy automated script monitoring that scans payment pages daily. Use CSP headers with violation reporting to an active dashboard. Integrate compliance status into security operations. Compliance is a continuous program, not an annual project. [src2]

### Wrong: Assuming hosted checkout (Stripe/Adyen iframe) eliminates PCI obligations
Retailers using Stripe or Adyen hosted checkout assume they have zero PCI DSS responsibilities. Under v4.0.1, even SAQ-A merchants must verify their payment pages do not contain vulnerable scripts and must implement tamper detection (Req 11.6.1). Attackers can redirect customers to fake payment pages via scripts outside the iframe. [src3]

### Correct: Verify scope reduction actually applies under v4.0.1 eligibility criteria
SAQ-A eligibility criteria were updated in v4.0.1. Confirm all eligibility requirements are met. Still implement Req 6.4.3 (script inventory) and Req 11.6.1 (tamper detection) on checkout pages — the iframe protects the payment form, not the page surrounding it. [src4]

### Wrong: Ignoring third-party script supply chain risk on payment pages
Retailers focus on their own code while ignoring the 15-40 third-party scripts loaded on payment pages. A compromised analytics, chat, or A/B testing script can harvest payment data just as effectively as a direct server breach. The 2024-2025 Magecart surge (103% increase) exploited exactly this vector. [src6]

### Correct: Treat every third-party script as part of the attack surface
Maintain a complete script inventory with SRI hashes. Use CSP to restrict script sources to an explicit whitelist. Monitor for script changes in real-time. Remove any script from payment pages that does not have a documented business justification — each unnecessary script is an attack vector. [src4]

## When This Matters

Use when a retailer or e-commerce business needs to actually execute PCI DSS v4.0.1 compliance — conduct the gap assessment, implement the technical controls, pass the scans, and submit validation documentation. Not a conceptual overview of what PCI DSS is, but the step-by-step execution from current state to passing validation. Requires payment architecture diagram and current compliance status as inputs; produces a validated compliance package as output.

## Related Units

- [CDP Selection for Retail](/business/retail-transformation/cdp-selection-for-retail/2026) — CDP must account for PCI data handling requirements
- [Supply Chain Digitization Roadmap](/business/retail-transformation/supply-chain-digitization-roadmap/2026) — supply chain systems may fall within CDE scope