The Qualified Security Assessor industry runs on two assumptions: that PCI DSS is complicated enough to require them, and that merchants can’t figure out the SAQ-vs-ROC question without a consulting engagement. Both are partially true. Neither is true enough to justify the volume of marketing content that conflates PCI assessment with PCI implementation.
This article is the implementation side — the nine-month programme plan for a merchant or payments-adjacent fintech running the work that sits in front of a QSA engagement or a self-assessment. Vendor-neutral. Specific about durations. Explicit about the SAQ-vs-ROC decision. And written on the assumption that you already know what a CDE is and don’t need the 101.
PCI DSS 4.0 in 2026: what’s now fully in force
PCI DSS v4.0 published in March 2022. Version 4.0.1 — a limited revision correcting typographical and formatting issues without adding or removing any requirements — published in June 2024 and is now the only active version; v4.0 was retired at the end of 2024. Fifty-one of the 64 new requirements introduced in v4.0 were designated “future-dated,” meaning they were best practice until a defined deadline and mandatory after. That deadline was 31 March 2025. In April 2026, the future-dated requirements have been mandatory for over a year.
What this means concretely for a 2026 programme: the “we’re still transitioning from 3.2.1” narrative is no longer credible. Every applicable requirement in v4.0.1, including every future-dated one, is in force and being assessed against. The QSA industry is consistently reporting that merchants who planned to use 2025 as their transition year are now behind, and that acquirers and card brands are less patient than they were two years ago.
The requirements that routinely catch merchants out in 2026 are the ones that changed character most between 3.2.1 and 4.0:
- Requirement 8.4.2 — Multi-factor authentication for all access into the cardholder data environment. Not just remote access. Not just administrator access. All access.
- Requirement 6.4.3 — Inventory, authorisation, and integrity verification of all scripts loaded on payment pages. E-skimming defence made concrete.
- Requirement 11.6.1 — Change- and tamper-detection on payment pages, assessed at least weekly.
- Requirement 11.3.2 — Authenticated internal vulnerability scanning, quarterly, with high-risk findings remediated.
- Requirement 12.6.2 — Security awareness training that specifically addresses phishing, social engineering, and acceptable use, refreshed annually.
If your programme is failing in 2026, it’s failing on one or more of these, plus scoping — which is discussed below.
The 9-month programme at a glance
Nine months is realistic for a merchant or service provider implementing PCI DSS 4.0.1 from a starting position of moderate security maturity and a reasonably well-understood cardholder data environment. Organisations with complex or undocumented CDEs regularly run twelve to fifteen.
Phase 1: Scoping and CDE mapping Months 1–2
Phase 2: Gap assessment Months 2–3
Phase 3: Control remediation Months 3–7
Phase 4: Evidence consolidation Months 7–8
Phase 5: SAQ completion or QSA engage Month 8–9The heaviest risk in this plan is Phase 1. Programmes that get scoping wrong spend the next seven months solving the wrong problem. Programmes that get scoping right find Phase 3 roughly the effort they expected.
Phase 1: Scoping and CDE mapping (months 1–2)
Two months to produce a defensible scope statement and CDE boundary.
The cardholder data environment is the set of systems that store, process, or transmit cardholder data (CHD), plus any systems that could affect the security of those systems. The second clause is where scoping goes wrong. A system that doesn’t touch cardholder data but can affect the security of a system that does — a domain controller, a jump host, a logging server, a shared SaaS tool — is in scope.
Data flow mapping. Start by mapping cardholder data flows through every channel your organisation accepts card payments: e-commerce checkout, point-of-sale, mail order/telephone order, back-office operations. For each flow, document the systems through which data passes, where it’s stored, how long it’s retained, and where it crosses trust boundaries. Most merchants doing this exercise for the first time discover at least one data flow they didn’t know existed — usually a reporting pipeline, a backup process, or a customer service tool.
CDE boundary. From the data flow mapping, draw the CDE boundary. Systems inside are in scope for every applicable requirement; systems outside but “connected to or that could impact” the CDE are in scope for a subset of requirements; systems neither inside nor connected are out of scope. The second category — “connected to or that could impact” — is where merchants routinely underscope, and where QSAs and assessors routinely challenge scope during assessment.
Segmentation validation. If you’re using network segmentation to keep systems out of scope, document how segmentation is implemented and how it’s tested. Requirement 11.4.5 requires annual penetration testing to validate segmentation. Undocumented segmentation is unreliable segmentation.
Third-party service providers. Every TPSP that processes, stores, transmits, or affects the security of CHD is your responsibility. Inventory them. Collect their Attestation of Compliance. Document the shared responsibility boundary — which requirements they satisfy on your behalf, which you satisfy for them.
The position worth taking: scope as narrowly as the evidence genuinely supports, and not a millimetre narrower. Aggressive narrow scoping (the “we only touch cardholder data in the checkout widget, and the widget is entirely handled by our payment processor”) is tempting because it reduces the implementation burden. It is also the single most common reason for scope disputes during assessment. If your scope relies on a specific interpretation of what constitutes “impact,” get that interpretation in writing from a QSA before you commit to it.
Phase 2: Gap assessment (months 2–3)
One month to measure where you are against where you need to be.
The gap assessment evaluates each applicable v4.0.1 requirement against current implementation. Output: a requirement-by-requirement evaluation with evidence, gaps, remediation effort, and priority.
Two pragmatic notes. First, gap assessments benefit from being done by someone who hasn’t built the existing control environment. Fresh eyes find gaps that operators are blind to. External QSA-adjacent gap assessments typically cost less than the remediation time saved. Second, the v4.0 customised approach — the option to implement controls differently from the defined approach if supported by a Targeted Risk Analysis — is a legitimate mechanism that’s rarely appropriate for first-time programmes or smaller merchants. Use the defined approach unless there’s a specific reason not to.
Phase 3: Control remediation (months 3–7)
Four months of delivery against the gap register. For a 2026 programme, the remediation work concentrates in a predictable set of areas.
Multi-factor authentication expansion. Requirement 8.4.2 expanded MFA from “remote access to the CDE” to “all access into the CDE.” For merchants with internal network access to the CDE that previously used single-factor authentication, this is substantial engineering work. MFA must be implemented for all non-console administrative access and all access into the CDE, with phishing-resistant mechanisms encouraged. Passkeys satisfy 8.4.2 where properly implemented.
Payment page security. Requirements 6.4.3 and 11.6.1 represent the most concrete additions for e-commerce merchants. You need an inventory of every script loaded on your payment pages, documented authorisation for each, integrity verification (typically subresource integrity or equivalent), and an active change/tamper-detection mechanism assessed at least weekly. The mechanism usually involves a third-party monitoring service or a custom integrity check; neither is trivial to stand up.
Authenticated vulnerability scanning. Requirement 11.3.2 now requires internal vulnerability scans performed with authenticated access — the scanner logs into systems rather than just probing externally. This catches configuration issues unauthenticated scans miss and generates significantly more volume of findings. Plan for the finding-triage workload, not just the scanning tool cost.
Cryptographic inventory. Requirement 12.3.3 requires an inventory of cryptographic suites and protocols in use, reviewed annually with active monitoring of industry cryptography trends. This is a new artefact for many merchants — existing programmes tend to track certificates, not cryptographic algorithms and their lifecycle status.
Script and technology inventories. Requirement 12.3.4 requires an inventory of all hardware and software in use, reviewed annually to identify end-of-life or end-of-support components. Requirement 6.3.2 requires an inventory of bespoke and custom software components, including third-party dependencies. Neither is theoretical — both need to be maintained artefacts with documented review cadences.
Roles and responsibilities. A theme running through v4.0: roles and responsibilities must be formally documented for each set of requirements. This is mostly a documentation exercise, but it’s an exercise most merchants underestimate because it has to be done across every requirement category.
Phase 4: Evidence consolidation (months 7–8)
One month to pull together the artefacts an assessor will ask for. Evidence is organised by requirement; every requirement has at least one expected evidence type and usually more.
Evidence categories: policies and procedures (what you say you do), configuration standards (how systems are configured), operational artefacts (logs, tickets, screenshots, reports showing controls running), inventories (CDE systems, TPSPs, software, cryptographic suites), and attestation records (training completion, access reviews, management approvals).
The programme that consolidates evidence in Phase 4 is the programme that finished Phase 3 on time. The programme that scrambles to consolidate in Phase 5 — while simultaneously trying to complete SAQ or prepare for QSA fieldwork — is the programme whose evidence has gaps.
Phase 5: SAQ completion or QSA engagement (month 8–9)
One month to validate.
Self-assessment merchants: complete the appropriate SAQ, have an authorised officer sign the Attestation of Compliance, submit to the acquirer. The v4.0.1 SAQs were published in October 2024, with further revisions to SAQ A and SAQ D – Service Provider in January 2025. Use the current version.
QSA-assessed entities: QSA fieldwork begins in Phase 5, typically running two to four weeks depending on scope, followed by Report on Compliance drafting and review. Plan for two to four weeks of evidence requests, clarifications, and exception responses. The Report on Compliance is typically finalised four to six weeks after fieldwork closes.
SAQ vs ROC: choosing the right path
The question of whether you qualify for self-assessment or require a Report on Compliance is the most commonly asked and most confusingly answered question in PCI DSS. Here is the honest framework.
You must have a ROC if: you are a Level 1 merchant (more than 6 million Visa/Mastercard transactions annually, or categorised as Level 1 by a card brand for other reasons), or you are a Level 1 service provider, or your acquirer or a card brand has specifically required a ROC for your business.
You may self-assess via SAQ if: your transaction volume puts you in Level 2, 3, or 4 merchant tiers, your acquirer accepts SAQ-based compliance, and the scope of your environment matches one of the defined SAQ types (A, A-EP, B, B-IP, C, C-VT, D-Merchant, D-Service Provider, P2PE, or SPoC).
The SAQ type matters more than most merchants realise. SAQ A applies only to merchants who have fully outsourced payment page hosting to a PCI-compliant provider, with no CHD processed, stored, or transmitted by their own systems, and whose website does not directly receive or transmit CHD or send it to another site. SAQ A-EP applies to merchants with a website that redirects or iframes the payment page but can affect its security — which catches most modern e-commerce checkout patterns and is much more rigorous than SAQ A.
The most common merchant error in 2026 is claiming SAQ A eligibility when the e-commerce architecture actually requires SAQ A-EP. The PCI SSC has tightened the applicability criteria for SAQ A specifically to address this pattern. If you’re an e-commerce merchant running an integrated checkout (not a fully-hosted redirect), assume A-EP until a QSA tells you otherwise.
The commercial honesty: a QSA engagement for a small merchant is expensive relative to SAQ self-assessment, but a wrongly-claimed SAQ A that turns into an acquirer dispute or — worse — a breach with post-event scrutiny is expensive in ways that dwarf the QSA fee. If your scope is ambiguous, pay for a scoping opinion from a QSA before committing to the SAQ path.
Where PCI programmes commonly slip
Four failure patterns account for most 2026 programme delays.
CDE scope defined by wishful thinking. The team defines a scope that assumes a specific interpretation of “connected to or could impact,” the QSA disagrees during assessment, scope expands by 40%, and the remediation timeline adds two to four months. Mitigation: get scope validated — ideally by the same QSA who will later assess — before Phase 3 starts.
Payment page script inventory treated as a one-time deliverable. A merchant produces the inventory in Phase 3, never updates it, and by the time of assessment there are three new scripts that aren’t in the inventory. Mitigation: build the inventory as a living artefact with an automated feed from deployment pipelines or tag managers.
MFA implementation scoped to “new access paths.” The team rolls out MFA to new systems but grandfathers existing access patterns that don’t have MFA today. The QSA finds the grandfathered paths during assessment. Mitigation: inventory all access paths to the CDE at the start of Phase 3 and plan MFA rollout as a single project covering all of them.
SAQ vs ROC decided by cost rather than fit. A merchant chooses SAQ A because it’s cheapest, without checking applicability criteria, and the acquirer rejects the AOC. Mitigation: decide eligibility before deciding cost. The SAQ determination is a matter of architecture, not preference.
FAQ
Is PCI DSS 4.0 the current version?
PCI DSS 4.0.1 is the current version. Version 4.0 was retired at the end of 2024. Version 4.0.1 is a limited revision of 4.0 with no substantive changes, only clarifications and formatting corrections.
When did the future-dated requirements become mandatory?
31 March 2025. All 51 future-dated requirements from v4.0/v4.0.1 have been mandatory since that date.
What’s the difference between SAQ and ROC?
SAQ (Self-Assessment Questionnaire) is a self-attestation appropriate for merchants in Levels 2–4 and some service providers. ROC (Report on Compliance) is required for Level 1 merchants and Level 1 service providers and involves a Qualified Security Assessor. Both produce an Attestation of Compliance.
How much does PCI DSS compliance cost?
Highly variable. A small SAQ-eligible merchant can achieve compliance for a few thousand dollars of tooling and internal time. A Level 1 merchant running a ROC engagement typically spends $50,000–$250,000 on QSA fees alone, with remediation costs running much higher for complex environments.
Can I use the customised approach?
Yes, but rarely should in first-time programmes. The customised approach requires a Targeted Risk Analysis, QSA buy-in, and more documentation than the defined approach — it’s designed for large organisations with mature risk management practices that have a specific reason to implement a control differently.
Do I need PCI DSS compliance if I don’t store card data?
Yes, if you process or transmit cardholder data — and your scope may be narrower than a merchant that stores CHD, but you still have applicable requirements. “Don’t store it” materially reduces scope but does not eliminate it.
How often do I need to assess PCI DSS compliance?
Annually. Quarterly ASV scans, annual penetration testing (internal and external), semi-annual segmentation validation for scope reduction, and continuous monitoring for a growing list of requirements.
What happens if I fail an assessment?
For SAQ merchants, the acquirer will typically require a remediation plan and re-attestation. For ROC entities, the QSA will document compensating controls where acceptable and remediation plans where not. Sustained non-compliance can lead to increased transaction fees, card brand fines levied through the acquirer, and ultimately loss of card processing privileges.
Is PCI DSS the same as PCI compliance?
PCI DSS is the data security standard. “PCI compliance” is commonly used to mean compliance with PCI DSS, but the PCI Security Standards Council also maintains related standards (PA-DSS for payment applications, P2PE for point-to-point encryption, PIN security requirements, and others). For most merchants, “PCI compliance” means PCI DSS compliance.
Does a breach automatically mean I was non-compliant?
Not automatically — compliance and security are related but not identical. A compliant organisation can still be breached by a novel attack or an insider. That said, post-breach forensic analysis frequently finds compliance gaps that contributed to the incident, and card brand assessments following a breach are significantly more intrusive than routine ones.