CyphrQ
Menu

PCI DSS 4.0 Requirements Explained (v4.0.1): Scope and Assessments

PCI DSS v4.0.1 in plain terms: who it applies to, the 12 requirements, the 31 March 2025 deadline, and how SAQs, ROCs and merchant levels fit together.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

10 min read

PCI DSS is the payment card industry's security standard, and the current version is v4.0.1. It applies to any organisation that stores, processes or transmits card data, or that can affect the security of the systems that do. The future-dated PCI DSS 4.0 requirements became mandatory on 31 March 2025. Whether and how you must prove compliance is set by your card brands and acquirer, not by the standard itself.

What is PCI DSS and who publishes it?

The Payment Card Industry Data Security Standard (PCI DSS) is published by the PCI Security Standards Council (PCI SSC). The Council's PCI DSS page says it was developed to encourage and enhance payment account data security, and that it provides a baseline of technical and operational requirements to protect that data.

The version to know is v4.0.1. The Council's document library features PCI DSS v4.0.1, alongside a summary of changes from v4.0 to v4.0.1. The Council's announcement dated 11 June 2024 calls it a limited revision. It fixes formatting and typographical errors and clarifies the intent of some requirements, with no additional or deleted requirements. The same post says v4.0 was retired on 31 December 2024, which leaves v4.0.1 as the only supported version.

The standard text is the Council's copyrighted document, so this article describes it in my own words. Download the real thing from the library before you plan any work.

Who does PCI DSS apply to?

The Council's page lists entities that store, process or transmit cardholder data, and entities that could affect the security of the cardholder data environment. That includes merchants, processors, acquirers, issuers and service providers.

Two practical points follow:

  • Outsourcing does not remove you. If a payment provider handles the card form, your website can still affect how that form is delivered. That is why the e-commerce requirements below matter to small online shops.
  • The Council does not enforce it. The page says that whether an entity must comply is at the discretion of the organisations that manage compliance programmes, such as a payment brand or an acquirer. Visa's compliance page says the same thing from the other side: Visa manages compliance enforcement and validation, and acquirers must make sure their merchants validate at the right level.

In other words, PCI DSS is a contractual obligation passed down through your merchant agreement. It is not a law, although some laws and regulators point to it.

What are the 12 PCI DSS 4.0 requirements?

The 12 requirements are grouped into six goals. I describe them in my own words here. The exact titles and sub-requirements are in the standard itself.

Goal Requirements, in plain terms
Build and maintain a secure network and systems 1. Control network traffic with firewalls and similar controls. 2. Change vendor defaults and harden configurations.
Protect account data 3. Keep stored card data to a minimum and protect what you keep. 4. Encrypt card data when it crosses open, public networks.
Maintain a vulnerability management programme 5. Defend against malware. 6. Build and maintain secure systems and software, including patching.
Implement strong access control 7. Give people access only to what the job needs. 8. Identify users and authenticate them properly. 9. Restrict physical access to card data and systems.
Monitor and test networks 10. Log and monitor access to systems and card data. 11. Test security regularly with scans, penetration tests and change detection.
Maintain an information security policy 12. Run security through policy, risk assessment, awareness, vendor management and incident response.

The Council's PCI DSS v4.0 highlights document is the official overview. It is a PDF that my fetcher could not read, so the table above is my own summary of the well-known structure. Check it against the standard.

Requirements 7 and 8 lean heavily on one habit: reviewing who has access. If you do not have a routine for that yet, start with how to run a user access review.

What changed on 31 March 2025?

When v4.0 was released, many new requirements were marked as best practice only until a later date. That date was 31 March 2025. After it, they had to be fully considered in an assessment.

The Council's own podcast transcript, posted on 26 March 2025, says 64 new requirements were released in PCI DSS and 51 of them were future-dated. It also confirms that the v4.0.1 revision did not move the date: the Council's v4.0.1 announcement says the limited revision does not affect the effective date of the new requirements.

The two the Council singled out are for e-commerce. In its words, requirements 6.4.3 and 11.6.1 are about ensuring that payment page scripts are authorised, checked for integrity and monitored for tampering. It added that stakeholders found them challenging, especially smaller merchants.

Those dates have passed. If your assessment is due now, assume every one of these requirements is in scope.

What is the difference between merchant levels, SAQs and ROCs?

These three terms get mixed up, so here they are separately.

Term What it is Who decides
Merchant level A tier, usually based on card transaction volume, that determines how you must validate Card brands and acquirers
SAQ (Self-Assessment Questionnaire) A questionnaire you complete yourself to attest compliance, where your level allows it Your acquirer or brand says whether it is accepted
ROC (Report on Compliance) The detailed report from a full assessment, usually by an external assessor Required at the highest level or where your acquirer asks

On levels: Visa's page says a merchant's level is based on its total Visa transaction volume over a 12-month period. The page I could open does not list the tier thresholds, and I could not open Mastercard's page (it returned an access block). I am deliberately not quoting volume cut-offs from third-party blogs, because card brands can change them and they are not identical across brands. Ask your acquirer which level you are, and get it in writing.

On SAQs and ROCs: the Council's pages that I could open did not describe them in detail. The usual arrangement is that the highest level needs an external assessment and a ROC, and lower levels may complete an SAQ. Which SAQ applies depends on how card data flows through your business, for example whether you fully outsource card entry. Treat that as the common pattern, and confirm it with your acquirer.

Visa also describes a Technology Innovation Program under which merchants that process at least 75% of annual transactions through EMV chip-enabled terminals, or that use validated point-to-point encryption or qualifying tokenisation, do not have to verify PCI DSS compliance. Programmes like this vary by brand and region, so ask whether yours applies.

How does a PCI DSS assessment work in practice?

Whatever the route, the sequence is similar:

  1. Find out your level and validation route from your acquirer.
  2. Define scope. Map where card data is stored, processed or transmitted, and which systems connect to those.
  3. Close gaps against each requirement, with owners.
  4. Gather evidence for the assessment period.
  5. Validate. Either complete the SAQ or work with an assessor on a ROC.
  6. Submit the documents to your acquirer or brand as they direct.

The Council's training and qualification page shows who does what. A Qualified Security Assessor (QSA) performs PCI DSS assessments of merchants and service providers. An Internal Security Assessor (ISA) lets your own staff perform internal assessments. An Approved Scanning Vendor (ASV) validates adherence to the external scanning requirement.

How does PCI DSS relate to SOC 2 and ISO 27001?

PCI DSS is prescriptive about card data. It tells you what to implement and how often. By contrast, SOC 2 and ISO/IEC 27001 are broader assurance frameworks. A SOC 2 report or ISO certificate does not make you PCI compliant, though much of the underlying evidence overlaps. For a wider view of how frameworks and standards bodies fit together, see the Frameworks and Bodies section.

Going deeper: for security and IT teams

Scope is the main cost driver. Everything that stores, processes or transmits card data is in scope, as are systems that connect to or can affect them. Draw the data-flow diagram first, then segment. Reducing scope, for example by letting a validated provider capture card data so that it never touches your systems, usually saves more effort than any single control. Write down why each system is in or out of scope, because an assessor will ask.

Payment page scripts (6.4.3 and 11.6.1). These two requirements target the browser side of checkout. Per the Council, the aim is that scripts on payment pages are authorised, integrity-checked and monitored for tampering. A workable approach is to start with an inventory of every script loaded on each payment page, including third-party tags. Record who approved each one and why it is needed. Then add a mechanism that alerts you when a script changes or a new one appears. Browser features such as Content Security Policy and Subresource Integrity can support this, but check with your assessor whether your approach satisfies the requirement as written. I have not tested any particular tool here.

Identity and access (Requirements 7 and 8). Expect to show a list of accounts with access to the cardholder data environment, who approved each, and evidence of periodic review. Service accounts and vendor accounts are where reviews usually fall down, so include them. The user access review guide gives a workable method.

Logging and testing (Requirements 10 and 11). Show that logs from in-scope systems are collected centrally, protected from alteration, and actually reviewed. For testing, keep the scan and penetration test reports, the remediation tickets, and re-test results. External scans must come from an ASV, per the Council's training page. Keep scan dates and fix dates together, since assessors look at the gap between them.

Evidence an assessor typically asks for. Network and data-flow diagrams, configuration standards, a system inventory, access lists and review records, change records, scan and test reports, policies with approval dates, vendor lists with each provider's compliance status, and the incident response plan. If you do not have these on the day, expect a delay.

Common findings, described generally. Scope drawn too narrowly; undocumented third-party connections; shared or generic accounts; reviews performed but not recorded; scripts on payment pages with no owner.

Questions to ask.

  • Which version and which validation route does our acquirer require?
  • Which of our service providers handle card data, and can they show current compliance evidence?
  • Which payment pages load third-party scripts, and who approves them?
  • Are we sure that our payment provider's responsibilities and ours are written down?

Learn more

Key takeaways

  • PCI DSS v4.0.1 is the current version. It is a limited revision of v4.0 with no added or removed requirements.
  • The future-dated requirements took effect on 31 March 2025, including the payment page script requirements 6.4.3 and 11.6.1.
  • The Council publishes the standard. Card brands and acquirers decide who must validate and how.
  • Merchant level decides the route: external assessment and ROC, or a self-assessment. Get your level in writing from your acquirer.
  • Scope drives effort. Know where card data flows before you buy anything.

Sources