PCI DSS v4.0.1
The v4.0.1 requirements for organizations in scope for cardholder data.
What PCI DSS v4.0.1 is
The Payment Card Industry Data Security Standard is a contractual requirement imposed by the card brands on everyone who stores, processes or transmits cardholder data. It is not law, which misleads people into underrating it — the enforcement mechanism is your acquirer and your merchant agreement, and it is considerably faster than a regulator.
Version 4.0 restructured the standard around twelve principal requirements and introduced the customised approach, which allows an entity to meet a requirement's stated objective by a different means, subject to a documented targeted risk analysis and validation by a QSA. It also brought a substantial set of future-dated requirements that became mandatory on 31 March 2025, covering areas like authenticated internal scanning, automated log review, phishing-resistant controls and client-side script integrity.
What determines the cost of a PCI programme is scope, not the standard. Every system that stores, processes or transmits cardholder data, and every system connected to or affecting the security of those, is in scope. Segmentation is the single highest-leverage decision in the whole exercise.
Who it applies to
- Merchants at any level who accept card payments, with validation requirements scaling by transaction volume.
- Service providers who handle cardholder data on behalf of merchants, or who can affect the security of a merchant's cardholder data environment.
- SaaS platforms that touch payment flows even indirectly — the connected-to rule catches far more infrastructure than teams expect.
- Organisations that have outsourced payments and believe they are therefore out of scope, who usually still owe a self-assessment questionnaire.
How it is structured in CMDash
CMDash seeds PCI DSS v4.0.1 at the Report on Compliance line-item level, grouped under the twelve principal requirements. That is the level a QSA works through in a ROC; it is deliberately not the full sub-sub-requirement tree.
| Network Security Controls | 5 |
| Secure Configurations | 3 |
| Stored Data Protection | 7 |
| Transmission Encryption | 2 |
| Malware Protection | 4 |
| Secure Development | 5 |
| Access Restriction | 3 |
| User Identification | 6 |
| Physical Access | 5 |
| Logging & Monitoring | 7 |
| Security Testing | 6 |
| Organizational Policies | 10 |
These counts are the control rows CMDash actually seeds, checked against the seed files by a test on every build.
Scope: ROC line-item level rather than the full sub-requirement tree.
The control text
The PCI SSC publishes the standard at no cost under a click-through licence that does not permit redistribution, so the requirement text cannot be embedded here.
CMDash ships the control identifiers, the titles, and its own evidence-requirement guidance. If you hold a licence, you can import the official text yourself through the framework CSV import, which records it as customer-provided.
Download free from the PCI SSC Document Library →Free to download, but not redistributable
What CMDash does for PCI DSS v4.0.1
- Requirements tracked at ROC line-item level with owners, statuses, evidence requirements and dated evidence.
- Seeded crosswalks to ISO 27001:2022 and NIST CSF, which is where most of the reuse lives for an organisation running PCI alongside a security certification.
- A time-boxed, read-only seat scoped to PCI for the QSA, with a record of what was accessed.
- Evidence package export as a ZIP with manifest for the assessment itself.
- Every control is a tracked row with an owner, a status (not started, in progress, implemented, not applicable, at risk, failing), reviewer notes, and its own evidence requirements — not a checkbox on a spreadsheet.
- Evidence is uploaded against a specific control, dated, and kept on that control, so an assessor can see what was true when.
- Gaps export to a POA&M CSV — every control that is not implemented and not marked out of scope, with owner, status and evidence requirements.
- Policies you author in CMDash link to the controls they govern, so each control row shows which living policies stand behind it.
- A time-boxed, read-only external assessor seat can be scoped to just this framework, with an expiry date you set and a record of every page they opened.
What it shares with your other frameworks
CMDash seeds control-to-control crosswalk mappings, each with a confidence score. They are what stops the same artefact being gathered twice, and they are how a second framework costs a fraction of the first.
Where the evidence comes from
CMDash reads from the security tools you already run and turns what they report into control evidence. These are the integrations whose data lands closest to PCI DSS v4.0.1’s control groups — you decide which control each signal evidences, and CMDash keeps it current from then on.
Where CMDash stops
Published on purpose. A buyer who discovers a limit after signing is a support ticket and a refund conversation; a buyer who reads it here is making an informed decision.
- ROC line-item level, not the full sub-requirement tree — the complete tree runs to several hundred testing procedures and is not seeded. If your QSA works from the full tree, this control set is coarser than their workpapers.
- The PCI Security Standards Council licenses the standard's text. CMDash ships requirement identifiers, titles and its own evidence guidance rather than reproducing it.
- Scoping and segmentation are not modelled. CMDash does not determine your cardholder data environment, and that determination drives everything else.
- The customised approach — with its targeted risk analyses and QSA-validated alternative controls — is not modelled as a distinct object.
- CMDash is not a QSA and cannot validate compliance or complete an Attestation of Compliance.
Common questions
We use a payment processor. Are we out of scope?
Almost certainly not entirely. Outsourcing reduces scope, sometimes dramatically, but you generally still owe a self-assessment questionnaire, and any system that can affect the security of the payment flow — your website serving the payment page, your DNS, your CDN — is in scope. The v4.0 client-side script requirements were added precisely because of this pattern.
What is the customised approach?
v4.0 allows you to meet a requirement's objective by a different means than the defined approach, provided you document a targeted risk analysis and your QSA validates the alternative. It is genuinely useful for mature organisations with compensating architecture, and it is more work, not less. CMDash does not model it as a distinct object today.
Why line-item level rather than every sub-requirement?
Because the ROC line item is where evidence is assigned and status is meaningful, and the full tree runs to several hundred testing procedures that are mostly QSA workpaper structure. It is a real limitation and it is stated rather than hidden — if you need the full tree, this is not it.
Also in Privacy & Sector Regulation
Paid plans cap how many frameworks you run at once, never which ones — PCI DSS v4.0.1 is available on every paid plan.
View pricingReady to see your posture?
Start a 30-day free trial of any paid plan — a card is required, and it converts unless you cancel — or sign up for Free with no card at all.