Key points
• PCI DSS 4.0.1 added and removed no requirements; it is a limited revision and became the only active version after 31 December 2024.
• Readiness starts with data flows and scope, not with filling in a questionnaire.
• The SAQ is selected from payment architecture and every eligibility criterion, not transaction volume alone.
• Cartelta supports a narrow payment-page control scope; the product and advisory track do not replace a full PCI DSS assessment or an assessor's conclusion.
Quick answer: what PCI DSS 4.0.1 is and which version is active
PCI DSS defines baseline technical and organizational requirements for entities that store, process, or transmit payment account data, or can affect the security of that environment. PCI SSC published version 4.0.1 as a limited revision: it corrects errors and clarifies intent without adding or deleting requirements.
PCI DSS v4.0 retired on 31 December 2024. Future-dated requirements kept their 31 March 2025 effective date and must now be assessed where applicable. A 2026 project should use the current standard and the current SAQ, ROC, or AOC documents from the PCI SSC document library.
Important
This guide helps organize readiness but cannot determine a specific entity's obligations. Confirm the validation method and questionnaire with the acquirer, payment brand, customer, or QSA that accepts the compliance result.
Who PCI DSS applies to and how to define scope
Start with a data-flow diagram: where a customer enters account data, who creates the payment form, where the data goes, which systems store or transmit it, and which components can affect the security of that path. Scope can include connected systems, administrative access, network segments, service providers, and e-commerce pages, not only servers that hold card data.
Redirects, iframes, tokenization, segmentation, and P2PE can reduce scope, but none is an automatic exemption. Retain the architecture, decision basis, owner, TPSP responsibility boundaries, and evidence that the implementation meets the criteria being claimed.
- Assets: applications, networks, cloud services, endpoints, CI/CD, and administrative paths that store, process, transmit, or affect the CDE.
- Providers: payment processors, hosting, CDN, WAF, service accounts, and other TPSPs with shared responsibilities.
- People and processes: access, changes, incidents, training, risk management, and periodic reviews.
- E-commerce: merchant page, iframe or redirect, tag manager, third-party scripts, and systems that can alter the payment journey.
All 12 PCI DSS requirements: a working map
The twelve groups operate as one system. Compliance cannot be established with scanning, policies, or payment-page controls alone. The table translates the official group names into an operating question; use the current PCI DSS 4.0.1 document for exact testing procedures and guidance.
| No. | Requirement area | What must be governed |
|---|---|---|
| 1 | Network security controls | Traffic rules, configurations, changes, and verification of network boundaries. |
| 2 | Secure configurations | Configuration standards, component inventory, and removal of insecure defaults and services. |
| 3 | Stored account data | Data minimization, PAN protection, cryptographic keys, and defensible retention and deletion. |
| 4 | Data in transit | Strong cryptography, trusted certificates, and prevention of insecure PAN transmission. |
| 5 | Malware protection | Prevention, detection, updates, evaluation of atypical systems, removable media, and phishing. |
| 6 | Secure systems and software | Vulnerabilities, patches, secure development, changes, web protection, and payment-page scripts. |
| 7 | Need-to-know access | Roles, least privilege, regular review, and system and application account governance. |
| 8 | Identity and authentication | Unique identities, MFA, authentication factors, and user and application account lifecycle. |
| 9 | Physical access | Areas, visitors, media, devices, and physical protection of account data. |
| 10 | Logging and monitoring | Complete logs, time synchronization, log protection, event review, and failure detection. |
| 11 | Regular security testing | Scanning, penetration testing, segmentation, attack detection, and payment-page change detection. |
| 12 | Security policies and programs | Ownership, risk, TPSPs, awareness, incidents, annual confirmations, and program governance. |
What changed from PCI DSS 4.0 to 4.0.1
The update did not create a new set of obligations. It clarified wording and applicability, so migration work should review changed applicability notes, guidance, and reporting templates rather than compare requirement numbers only.
| Area | v4.0.1 clarification | Practical action |
|---|---|---|
| Requirement 3 | Issuer applicability and keyed cryptographic hashes were clarified. | Verify the PAN-protection basis and applicability to issuing services. |
| Requirement 6 | The 30-day patch language applies to critical vulnerabilities; payment-page script notes were clarified. | Update patch SLAs and interpret 6.4.3 against the actual architecture. |
| Requirement 8 | An MFA note was added for access that uses only phishing-resistant factors. | Verify the method and retain the basis for any applicability conclusion. |
| Requirement 12 | Customer and TPSP relationships and responsibilities were clarified. | Review responsibility matrices, provider AOCs, and ongoing status monitoring. |
| Appendices | Customized-approach samples moved online and definitions were added. | Use current PCI SSC templates and glossary terms. |
SAQ, ROC, and AOC: choosing the validation path
An SAQ is not a lighter security standard. It is a self-assessment route for an environment that meets every eligibility criterion of the selected questionnaire. A ROC is a detailed assessment report, while the required assessment route is determined by payment-brand and compliance-accepting entity rules. An AOC attests the result of the corresponding assessment.
For e-commerce, classify the architecture before opening a questionnaire. If one SAQ A or A-EP eligibility criterion is not met, the organization cannot keep that questionnaire by marking the inconvenient criterion not applicable.
- Detailed decision guide: SAQ A, A-EP, or D: choosing a PCI DSS 4.0.1 questionnaire
- SAQ A, iframe, and redirect analysis: Payment page security after PCI DSS 4.0.1: SAQ A, iframe, and evidence
Do not select an SAQ from transaction volume
Merchant and service-provider levels and accepted validation routes come from payment-brand and accepting-entity rules. Architecture drives questionnaire eligibility, while volume may affect the required reporting method.
What matters most for e-commerce in 2026
The customer browser combines merchant code, payment components, tag managers, analytics, consent managers, CDNs, and third-party widgets. Repository monitoring therefore does not prove what the live page delivered, and an iframe alone does not prove that the surrounding page is protected.
Requirement 6.4.3 governs authorization, integrity, and business justification for payment-page scripts. Requirement 11.6.1 requires detection of unauthorized changes to pages and security-impacting HTTP headers at the defined frequency or through a mechanism that continuously detects changes.
- Script control under 6.4.3: PCI DSS 6.4.3: controlling client-side scripts on payment pages
- Change detection under 11.6.1: PCI DSS 11.6.1: payment page change detection
- Implementation checklist: PCI DSS implementation checklist
A 30, 60, and 90-day readiness plan
Duration depends on scope and current maturity, but the sequence remains stable: establish boundaries, assign owners, address high-risk gaps, verify controls in operation, and only then assemble the final package. The plan is a starting backlog, not a promise of compliance in 90 days.
| Period | Primary work | Reviewable outcome |
|---|---|---|
| Days 1–30 | Data flows, CDE, TPSPs, SAQ or ROC path, owners, gap register, and critical risks. | Approved architecture and decision register with owners and dates. |
| Days 31–60 | Configurations, access, patches, logs, scanning, SDLC, browser scripts, and procedures. | Operating controls and initial records, not draft policies alone. |
| Days 61–90 | Control tests, remediation, evidence samples, independent review, and assessment readiness. | A reproducible package with conclusions, exceptions, and remaining actions. |
Evidence to collect and how to use the tracker
For every applicable requirement, connect the control to an owner, system, test procedure, assessment period, source artifact, and test result. A screenshot without source context becomes stale quickly; logs, approved configurations, change tickets, access samples, and reproducible events are stronger records.
The CSV below is a starting tracker, not an official reporting template. Add the exact requirement IDs, applicability decisions, evidence links, owners, dates, gaps, and reviewer conclusions for the real environment.
PCI DSS 4.0.1 readiness tracker
CSV fields for requirement, scope, owner, status, evidence, test, gap, and target date.
CSV · example with no sensitive data
The Cartelta boundary: what the product and advisory track cover
Cartelta focuses on the client side of payment pages: observed script inventory, approved-state governance, change detection, and technical evidence for 6.4.3 and 11.6.1. The advisory track helps define that scope, its owners, gaps, and implementation plan.
Cartelta is not a certification claim, does not issue a ROC or AOC, and does not automatically cover the other requirement groups. A full program needs expertise across networking, IAM, cryptography, SDLC, logging, vulnerability management, physical security, risk, and TPSP governance, with the final validation method confirmed by the accepting entity.
- Payment-page technical readiness: /PCIDSSConsultingPage
- Cartelta JSIR capabilities: /JSIRPage
Practical steps
1
Document payment flows, the CDE, connected systems, and third-party service providers.
2
Confirm the accepted SAQ, ROC, and AOC route with the compliance-accepting entity.
3
Map every applicable requirement to controls, owners, and systems.
4
Create a gap register and remediate critical technical and process weaknesses first.
5
Test control operation with samples and safe test scenarios.
6
Assemble reproducible evidence and run an independent readiness review before formal assessment.
Questions on this topic
Does PCI DSS 4.0.1 introduce new requirements?
No. PCI SSC describes 4.0.1 as a limited revision that corrects errors and clarifies wording without adding or deleting requirements.
Can an organization select SAQ A on its own?
The environment must meet every eligibility criterion. PCI SSC recommends confirming SAQ eligibility and the selected questionnaire with the acquirer, payment brand, or other compliance-accepting entity.
Does an iframe fully remove the merchant site from PCI DSS scope?
No. It can reduce data-handling scope, but the merchant page and systems that can alter the payment journey still require analysis. SAQ A also has script-attack protection and ASV considerations.
Can one product make an organization PCI DSS compliant?
No. PCI DSS spans twelve technical and organizational requirement groups. A product can support specific controls but cannot replace scope decisions, processes, testing, and final assessment.
Does the 90-day plan guarantee compliance?
No. It provides a manageable sequence. Duration depends on scope, architecture, existing gaps, providers, and the required assessment route.