Reference blue
#3575D3Buttons and CTA band
PCI DSS v4.0.1 compliance checklist: scope, evidence, and validation
A practical guide for merchants and service providers preparing for their next PCI DSS assessment. Practitioner: Srini Kolathur, Director, Databrackets. Source check: September 24, 2026.
PCI DSS readiness starts with a map of how a payment happens. If you cannot show where account data travels, which systems can affect that path, and who owns each control, it is too early to choose a questionnaire or assemble an audit binder.
The short version: confirm your payment flows and assessment scope; ask your acquirer or payment brand which validation method it expects; test the controls that apply to your environment; and keep evidence that shows those controls worked throughout the year. A completed form is the result of that work, not a substitute for it. PCI SSC's current standard and supporting documents are the authority for the requirements.
Which PCI DSS version applies now?
PCI DSS v4.0.1 is the current version listed by the PCI Security Standards Council (PCI SSC). It is a limited revision of v4.0: PCI SSC says it did not add or remove requirements. PCI DSS v4.0 was retired on December 31, 2024, and the new requirements that had been marked as future-dated became effective on March 31, 2025. A 2026 assessment should therefore use the current v4.0.1 documents and the reporting forms requested by the organization accepting your compliance results. PCI SSC: v4.0.1 announcement and current-version FAQ.
The 12 requirements still sit under six goals, but several labels changed from older versions. For example, Requirement 1 now refers to network security controls, Requirement 3 to stored account data, and Requirement 5 to malicious software. Use the current PCI SSC requirement list when writing policies or briefing staff; an old 12-item summary is not a reliable assessment checklist.
Who needs to consider PCI DSS?
Merchants, processors, acquirers, issuers, and service providers may be in scope when they store, process, or transmit payment account data, or can affect the security of the cardholder data environment (CDE). A business that sends customers to a hosted checkout can still have obligations. Its own website may control the redirect or host an embedded payment form, and it still needs to manage its payment provider relationship. PCI SSC: applicability and outsourced payments.
Start with how you accept payment, which systems and people can affect that flow, and who owns each control. A retailer with hosted checkout, a call center taking card details, and a software provider with access to a merchant's CDE will have different scopes. PCI SSC explains that even a provider that does not directly handle account data may have an in-scope service if it can affect CDE security. PCI SSC: service-provider scope.
Start with the payment flow, then define scope
- List every payment channel. Include web checkout, phone, in-person terminals, invoices, recurring billing, and any channel used only by one team or location.
- Trace account data. Record where it is entered, transmitted, stored, displayed, backed up, logged, or passed to a provider. Check test systems and support workflows as well as production.
- Identify connected and security-impacting systems. A server that does not store a card number can still be relevant if it can change a payment page, redirect, authentication system, or CDE security control.
- Document boundaries and owners. Keep a network diagram, data-flow diagram, system inventory, provider list, and a clear owner for each control. If a provider operates a control, record the shared responsibility and the evidence you will obtain from it.
- Validate any scope reduction. Segmentation can reduce assessment scope only when it effectively isolates the CDE; a separate VLAN or a diagram alone does not prove that. PCI SSC: scoping and segmentation.
Repeat this exercise when the environment changes. PCI SSC identifies changes to CDE boundaries, account-data flows, supporting infrastructure, and relevant service providers as examples that may be significant. PCI SSC: significant change.
Which validation route applies: SAQ, ROC, or AOC?
PCI SSC publishes the reporting forms, but the organization accepting your results, usually an acquirer or payment brand, determines which validation and reporting method you must use. Do not pick an SAQ because it looks shortest. Each SAQ has eligibility criteria tied to a specific payment environment. PCI SSC: who determines the method and SAQ eligibility.
| Document or role | What it does | Decision to confirm |
|---|---|---|
| Self-Assessment Questionnaire (SAQ) | Documents a self-assessment against the requirements in an eligible SAQ type. | Is this payment environment eligible for that SAQ, and will the accepting entity accept it? |
| Report on Compliance (ROC) | Records the results of a PCI DSS assessment against the applicable requirements. | Is a ROC required, and who must perform or sign the assessment? |
| Attestation of Compliance (AOC) | Summarizes and attests to the assessment result using a PCI SSC form. | Which AOC and supporting documents must be submitted? |
| Qualified Security Assessor (QSA) | A PCI SSC-qualified assessor who can assess and document compliance where engaged or required. | Does your program require a QSA-led assessment or review? |
| Approved Scanning Vendor (ASV) | Performs external vulnerability scans for applicable PCI DSS scanning requirements. | Which internet-facing systems must be scanned and when? |
A passing ASV scan is evidence for a scanning requirement; it is not a certificate that the entire organization complies with PCI DSS. PCI SSC also does not recognize third-party "PCI compliant certificates" as substitutes for its official reporting forms. PCI SSC: ASV scan limits and recognized forms.
The evidence checklist: what should you be able to show?
This is a preparation checklist, not a replacement for the standard or the instructions from your assessor and accepting entity. Which items apply depends on your scope and validation method. The point is to find missing evidence while there is still time to fix the control and show that it operates.
| Workstream | Evidence to assemble | Question to ask before assessment |
|---|---|---|
| Scope and ownership (cross-cutting) | Current payment-flow and network diagrams; system and provider inventories; responsibility matrix; scope review record. | Can we explain why each system and provider is in or out of scope? |
| Network and configuration (Requirements 1-2) | Network security control rules, approval records, secure configuration standards, and change records. | Do the documented rules match what is deployed? |
| Account data protection (Requirements 3-4) | Data retention and disposal policy, storage locations, protection methods, key-management records where applicable. | Are we storing only what we need, and can we prove prohibited data is not retained? |
| Software and vulnerability management (Requirements 5-6) | Asset and patch records, vulnerability results, remediation tickets, secure development/testing records where applicable. | Are findings closed and retested, rather than just listed? |
| Access and authentication (Requirements 7-9) | User/access inventory, approvals and reviews, privileged access records, MFA configuration evidence, physical-access records where applicable. | Can we show who can reach the CDE and why? |
| Logging and testing (Requirements 10-11) | Log review evidence, alert handling, external ASV scan results where required, penetration-test reports and retests where applicable. | Can we show the control worked across the assessment period? |
| Third parties and governance (Requirement 12) | Provider agreements, applicable AOCs or other evidence, annual compliance-status reviews, incident-response exercises, training records, policies. | Which controls belong to us, which belong to a provider, and where is the proof? |
PCI SSC's current requirement list is a useful index for this exercise. Keep the detailed testing procedures beside your evidence inventory. A neatly named folder is useful, but it cannot compensate for a missing control.
Test the evidence before you rely on it
An ASV report for the wrong hostname, an old access review, or a provider AOC covering a different service can look reassuring in a folder. Before calling an item ready, ask four questions: Does it cover the right systems and service? Does it show the control operating during the period being assessed? Is the owner or qualified provider identifiable? If it found a problem, is the fix documented and retested? Use these questions as an internal preparation check, alongside the PCI DSS testing procedures.
For example, a passing scan of a company's main website would not, by itself, show that the actual checkout or redirect page was included. Compare the scan's listed targets with the current payment-flow diagram and the scan scope required by the applicable SAQ. If they do not match, resolve the gap before treating the report as assessment evidence. This is an illustrative evidence check, not a claim about a Databrackets client. PCI SSC: SAQ A scan scope.
Four issues that deserve extra attention in v4.0.1
1. Payment-page scripts and tampering
For e-commerce environments where the requirements apply, Requirement 6.4.3 addresses authorization, integrity, and inventory of scripts loaded and executed on payment pages. Requirement 11.6.1 addresses detection of unauthorized changes to payment-page content and relevant HTTP headers as received by the customer's browser. A checkout page can be affected by a script added through a tag manager or vendor, even if a payment processor receives the card number. Start with an inventory of the scripts and parties able to change the page, then confirm which controls apply to your assessment. PCI SSC: payment-page guidance.
There is an important SAQ A distinction. PCI SSC removed 6.4.3 and 11.6.1 as direct items from the current SAQ A, while adding an eligibility criterion for merchants whose webpage embeds a provider's payment form: they must confirm that the site is not susceptible to script attacks affecting the e-commerce system. PCI SSC says this can be supported by suitable protection techniques or confirmation from the compliant payment provider about its solution when implemented as instructed. This specific eligibility criterion does not apply to redirect-only pages, although other SAQ A obligations can. PCI SSC: SAQ A update and FAQ 1588.
2. External scans, including some outsourced checkouts
Where Requirement 11.3.2 applies, external vulnerability scans must be performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV), with passing results and rescans as required. Requirement 11.3.2.1 covers external scans after significant changes; qualified personnel with organizational independence may perform those scans and are not required to be a QSA or ASV. PCI SSC clarified in June 2026 that SAQ A e-commerce merchants with merchant-hosted redirect pages or embedded third-party iframes still have scanning obligations for the relevant merchant webpages, even though processing is outsourced. Check the exact SAQ and scan scope with your acquirer. PCI SSC: SAQ A clarification and ASV resource guide. The current standard and SAQ remain authoritative.
3. Targeted risk analyses
PCI DSS v4.x uses targeted risk analyses in specific circumstances, including requirements that allow an entity to define an activity's frequency and controls implemented through the customized approach. A targeted risk analysis is not permission to skip an applicable requirement. Keep the documented rationale, chosen frequency or control objective, approval, and review evidence with the related requirement. PCI SSC: targeted risk analysis guidance and applicability FAQ.
4. Sensitive authentication data
Do not assume encryption makes every kind of payment data safe to keep. PCI DSS distinguishes cardholder data from sensitive authentication data. For merchants, data such as card verification codes and PIN/PIN block data must not be stored after authorization, even if encrypted. Check logs, recordings, support tickets, and backups as well as databases. PCI SSC: sensitive authentication data.
An example: a merchant using an embedded payment form
Imagine a merchant whose checkout page loads an iframe from a payment provider. The provider receives the card number; the merchant does not deliberately store it. The merchant still controls its checkout page and may run analytics or marketing scripts around the iframe.
The first useful artifact is a simple diagram showing the browser, merchant page, iframe, provider, and confirmation path. Next, list who can modify the merchant page, which scripts execute there, and what evidence the provider supplies for its share of the controls. For an embedded form, check how the site meets SAQ A's script-attack eligibility condition. Then confirm SAQ eligibility and ASV scan scope with the acquirer. This example does not establish SAQ A eligibility: iframe design and every other eligibility condition still matter. PCI SSC: iframe eligibility, script-attack criterion, and SAQ A scanning.
How Databrackets can help
Databrackets' PCI DSS services cover assessment reports, policies and procedures, remediation tracking, templates, vulnerability scans, and penetration testing, with DIY, hybrid, and governance engagement options. Bring the payment channels you use and the result your acquirer expects. That gives the team a concrete basis for scoping gaps, evidence collection, remediation, and testing. The acquirer or payment brand remains the source for your validation and reporting obligations; an ASV scan or a consultant's report does not replace that decision.
If you are preparing for an assessment, talk with Databrackets about your PCI DSS scope. Bring your payment-flow diagram if you have one. If you do not, identifying those flows is the first useful task.
Frequently asked questions
Does PCI DSS apply if we outsource all payment processing?
Usually, yes. Outsourcing can reduce the requirements that apply directly to your systems, but you still need to manage the provider relationship and confirm your own obligations. Ask your acquirer or payment brand which validation method applies. PCI SSC: outsourced payment processing.
Can we choose SAQ A because our processor hosts the payment form?
No automatic shortcut exists. SAQ A has detailed eligibility criteria, including how payment-page elements are delivered. An embedded iframe can be eligible in some designs, but a merchant-controlled payment element may change the answer. The current SAQ A also has a script-attack eligibility condition for embedded forms. Confirm the payment flow and eligibility with your acquirer or payment brand. PCI SSC: SAQ A iframe criteria and FAQ 1588.
Is a vulnerability scan the same as a penetration test?
No. An ASV external scan checks for identified vulnerabilities under the applicable scanning requirement. Penetration testing examines whether weaknesses can be exploited and has its own methodology and timing requirements where applicable. Neither one alone proves full PCI DSS compliance. PCI SSC: ASV scans and PCI SSC: penetration-testing guidance. The latter is a general information supplement, not a replacement for the current standard. For practical procurement questions, see Databrackets' guide to selecting a pen-testing vendor.
Does network segmentation automatically reduce PCI DSS scope?
No. Segmentation may reduce scope when it effectively isolates the CDE and that isolation is verified. Connected systems or security services can still be in scope. PCI SSC: segmentation.
What happens if we fail to comply?
Consequences depend on the applicable payment brand program and agreements with your acquirer. They may include remediation requirements, financial consequences, or restrictions on card acceptance. PCI SSC does not set one universal monthly fine schedule, so a fixed amount without a named program is misleading. PCI SSC: penalties.