What does PCI DSS v4.0.1 require?
DigitalXForce wrote this page.
PCI DSS, the Payment Card Industry Data Security Standard, is a baseline of technical and operational requirements for anyone who stores, processes or transmits cardholder data. Since v4.0 retired on 31 December 2024, v4.0.1 is the active version, and its future-dated requirements took effect on 31 March 2025. DigitalXForce evidences the controls, and a QSA or your acquirer judges compliance.
PCI DSS is written to be assessed, and an assessor reads evidence for each requirement. An organization that collects that evidence by hand spends the run-up to each assessment rebuilding what its systems could have shown all along.
What PCI DSS v4.0.1 requires
PCI SSC, the council that American Express, Discover, JCB International, Mastercard and Visa founded in 2006, maintains the standard. Each founding member builds PCI DSS into the technical requirements of its own data security compliance program. The standard applies to every entity involved in payment card processing, including merchants, processors, acquirers, issuers and service providers, and to any entity that could affect the security of the cardholder data environment.
The versions
PCI DSS v4.0 was published in March 2022, and v3.2.1 retired on 31 March 2024. In June 2024 PCI SSC published v4.0.1, a limited revision that corrects errors and clarifies intent, with no added or deleted requirements. Among its clarifications, the 30 day patching rule applies to critical vulnerabilities, and multi-factor authentication for non-administrative access into the cardholder data environment does not apply to accounts that use phishing-resistant authentication. PCI DSS v4.0 retired on 31 December 2024.
v4.0 brought new requirements, and most were future-dated, which means they were recommended until 31 March 2025 and have been required since. A QSA interviewed on PCI SSC’s blog put the count at 51 future-dated requirements out of 64 new ones. Two examples show their character. Requirement 12.5.2 asks for a scope confirmation every year, and SAQ A merchants are now expected to run external vulnerability scans through an Approved Scanning Vendor at least once every 3 months under Requirement 11.3.2.
The 12 requirements
The standard is organized into 12 principal requirements, from network security controls to organizational policy. The mapping table below lists each one with what DigitalXForce does for it and what stays with the entity. Version 4.x also lets an entity meet a requirement’s objective through a customized approach, and PCI SSC publishes templates for the targeted risk analyses that some requirements call for, including one for setting how often an activity is performed.
Validation and scope
Qualified Security Assessor companies are independent security organizations that PCI SSC qualifies to validate an entity’s adherence to PCI DSS, and Internal Security Assessors perform internal assessments for their own organization. Whether an entity must validate compliance, and how, is decided by the payment brands and acquirers that run compliance programs. Scope follows the data. PCI SSC says that encrypting cardholder data with strong cryptography renders it unreadable under Requirement 3.5.1, yet encryption alone is generally not enough to take an environment out of scope.
How does Continuous Control Assurance (CCA) support PCI DSS compliance?
Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected. Continuous Control Monitoring (CCM) monitors conditions, evidence and signals associated with controls. CCM is a capability within CCA. For PCI DSS, CCM watches the evidence behind each requirement between assessments, and CCA decides whether each control still works.
PCI DSS v4.x makes frequency part of the design. For some requirements it lets the entity set how often an activity runs through a targeted risk analysis, and PCI SSC publishes a template for that analysis. A control tested on the schedule the analysis sets, with each dated result kept, gives the assessor the history behind each answer.
The table shows example controls, how DigitalXForce reads the evidence for each and how often. The frequencies come from DigitalXForce’s example evidence plan, and each organization sets its own, since each control is tested on a schedule set by how quickly its evidence can change.
| PCI DSS requirement | What is tested | How DigitalXForce reads the evidence | How often, in the example plan |
|---|---|---|---|
| Requirement 8 | Multi-factor authentication is enforced. | The platform reads MFA status from the identity tool that enforces it. | It is read daily. |
| Requirement 7 | Privileged accounts are known and limited. | The platform reads the privileged account inventory from the identity tools. | It is read daily. |
| Requirement 7 | Access rights are reviewed. | The platform reads the access review logs from the identity tools. | They are read weekly. |
| Requirements 3 and 4 | Data is encrypted. | The platform reads encryption status from the systems that enforce it. | It is read continuously. |
| Requirement 2 | Systems are configured to the organization’s standard. | ESRPM runs configuration checks across network security, cloud and identity tools. | Configuration hygiene is read continuously. |
| Requirement 6 | Software is patched, and critical vulnerabilities are fixed. | Patch currency and critical CVE status come from scanners such as Qualys and Tenable. | They are read daily. |
| Requirement 10 | Logs are kept and reach the SIEM. | The platform checks log retention and the health of the SIEM feed. | They are read hourly. |
| Requirement 12 | Staff acknowledge the current security policy. | The platform reads the policy version and each acknowledgment. | They are read monthly. |
A test result does not define the cardholder data environment or perform the targeted risk analysis. An Approved Scanning Vendor runs the external scans, qualified testers run the penetration tests, and a QSA writes the Report on Compliance where one is required.
What DigitalXForce does for PCI DSS
DigitalXForce reads evidence through 250+ technology integrations across cloud, identity, endpoint, SIEM, vulnerability management, ITSM and enterprise applications. Each piece of evidence tests a control from a normalized control library, and each control is mapped once to every requirement it satisfies across 50+ compliance frameworks, PCI DSS among them. An entity that also holds SOC 2 or ISO/IEC 27001 reuses the same results.
For the technical requirements, the platform reads each control’s state from the tool that enforces it. In DigitalXForce’s example evidence plan, MFA status and the privileged account inventory are read daily, access review logs weekly, encryption status and configuration hygiene continuously, patch currency and critical CVE status daily, and log retention and SIEM feed health hourly. Each control has its own test frequency. The ESRPM module runs configuration checks across network security, cloud and identity tools, endpoint agents such as CrowdStrike, SentinelOne and Microsoft Defender report malware protection, and vulnerability findings arrive from scanners such as Qualys and Tenable.
Every result is stored with the evidence it read and a timestamp, and the compliance dashboards show evidence age. A failed test becomes a finding with an owner and a due date in the team’s own tools, such as ServiceNow or Jira, and the control is tested again when the fix is marked done. An accepted exception is recorded as a named person’s decision with a reason and an expiry date.
Attack Surface Manager discovers and inventories assets without agents, which gives the annual scope confirmation a current list to start from. The third-party risk management module assesses the third-party service providers that touch cardholder data, and AI JedAI reads their SOC 2 and ISO reports for an analyst to approve. The policy library holds 20+ security policies, 15+ standards and 5 plan templates, linked to the controls each policy governs. Controls with no machine-readable evidence, such as physical access and security awareness training, run through the C-Assess, X-Assess and A-Assess assessments with a reviewer’s approval.
DigitalXForce maps PCI DSS requirements to tested controls once and reuses the same evidence for every other framework the control belongs to.
What stays with the entity and its assessor
PCI DSS compliance is judged by people the payment brands recognize, and the entity owns its scope.
- Your team defines the cardholder data environment, designs its segmentation and confirms the scope every year.
- An Approved Scanning Vendor runs the external vulnerability scans that Requirement 11.3.2 calls for, and qualified testers run the penetration tests.
- Your team performs the targeted risk analyses and documents any customized approach.
- Your acquirer or payment brand decides how you validate, and a QSA writes the Report on Compliance where one is required.
- Your teams operate the controls and decide each remediation and each accepted exception.
How PCI DSS maps to the platform
| PCI DSS requirement, in plain words | What DigitalXForce does | What the entity still does |
|---|---|---|
| 1, network security controls | ESRPM configuration checks read firewall and cloud network settings. | The entity designs the network security controls and segmentation. |
| 2, secure configurations | Configuration hygiene is read continuously in the example plan. | The entity sets its configuration standards. |
| 3, protection of stored account data | Encryption status is read continuously in the example plan. | The entity decides what account data it keeps and where. |
| 4, strong cryptography in transmission | Encryption settings are read from the systems that enforce them. | The entity chooses the protocols and keys. |
| 5, protection from malicious software | Endpoint agent coverage is read from EDR tools such as CrowdStrike, SentinelOne and Microsoft Defender. | The entity runs the anti-malware program. |
| 6, secure systems and software | Patch currency and critical CVE status are read daily in the example plan, and application scanners such as Veracode and Snyk feed findings. | Development teams write and fix the software. |
| 7, access by business need to know | Privileged account inventory and access review logs are read from identity tools. | Managers approve access. |
| 8, identification and authentication | MFA status is read daily in the example plan. | The entity sets its authentication policy. |
| 9, physical access | Physical controls run through assessments with a reviewer’s approval. | Facilities teams control physical access. |
| 10, logging and monitoring | Log retention and SIEM feed health are read hourly in the example plan. | The security team reviews the logs and acts on events. |
| 11, regular security testing | Vulnerability findings from scanners such as Qualys and Tenable are worked and retested. | An ASV runs the external scans, and qualified testers run the penetration tests. |
| 12, policies and programs | The policy library links policies to controls, and the TPRM module assesses third-party service providers. | The entity confirms scope each year and manages its service provider relationships. |
Where DigitalXForce is not the answer
DigitalXForce is not a QSA or an Approved Scanning Vendor, and it does not write a Report on Compliance. A merchant that has outsourced its payment page and completes SAQ A has a narrow scope, and its payment provider and quarterly ASV scans carry much of the work. DigitalXForce fits a merchant or service provider with a large cardholder data environment across many tools, where gathering evidence by hand for each assessment is a project of its own.
What is tested from live data and what still needs a person
Which controls DigitalXForce tests directly from live tool data depends on the tools you connect through X-Connect and E-Connect. Controls that rest on a document, such as a signed policy, are reviewed by AI JedAI against the requirement and kept with their evidence. The demo shows that split for your own stack.
The evidence the auditor receives
For each control, the auditor receives the test result, the evidence it read, the time it was read and the history of earlier results. A-Assess prepares the evidence and findings in the form auditors review.
Other frameworks the same controls report to
A PCI DSS requirement such as access control, logging or vulnerability management often also answers requirements in ISO/IEC 27001, SOC 2 and NIST CSF 2.0. DigitalXForce maps such a control once, so one test result reports to each framework it belongs to. The article on the common control framework explains the method.
Payment card data matters most to the organizations on the financial services page and the higher education page.
DigitalXForce is not a certification, assessment or authorization body for PCI DSS. It tests and documents the controls the framework requires.
Questions about PCI DSS
How does Continuous Control Assurance (CCA) support PCI DSS compliance?
It tests the controls behind the 12 requirements against live evidence between assessments and keeps each result with a timestamp for the assessor. Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected. A QSA, an acquirer or a payment brand still judges compliance.
How can PCI DSS evidence be continuously collected?
Read each control’s state from the tool that enforces it on a set schedule. In DigitalXForce’s example evidence plan, MFA status is read daily, encryption status and configuration hygiene continuously, and log retention and SIEM feed health hourly. Physical access and awareness training still need a person, so they run through assessments with a reviewer’s approval.
Which version of PCI DSS is current?
PCI DSS v4.0.1 is the active version. PCI SSC published it in June 2024 as a limited revision with no added or deleted requirements, and v4.0 retired on 31 December 2024.
When did the PCI DSS v4 future-dated requirements take effect?
They took effect on 31 March 2025 and were recommended until then. A QSA interviewed on PCI SSC’s blog put the count at 51 of the 64 new requirements in v4.0.
Who validates PCI DSS compliance?
Qualified Security Assessor companies, which PCI SSC qualifies, validate an entity’s adherence, and Internal Security Assessors perform internal assessments. The payment brands and acquirers decide whether and how each entity validates.
Does encrypting cardholder data take a system out of PCI DSS scope?
Generally it does not. PCI SSC accepts strong encryption as a way to render cardholder data unreadable under Requirement 3.5.1, and it says encryption alone is generally not enough to take the environment out of scope.
Does DigitalXForce make an organization PCI DSS compliant?
It does not. Compliance is judged by a QSA, an acquirer or a payment brand. DigitalXForce tests the controls behind the 12 requirements and keeps timestamped evidence of every result for the assessor.
DigitalXForce terms used on this page
DigitalXForce gives each of its terms one definition and uses it everywhere, including in its glossary.
- Enterprise Security Risk and Posture Management (ESRPM) is the DigitalXForce module that runs configuration checks, operational insights and deployment benchmarking across IAM, SIEM, cloud, OT and IoT, SecOps and enterprise systems through 250+ technology integrations.
- AI JedAI is the DigitalXForce AI engine that analyzes: it reasons over control evidence and live telemetry, maps documents to controls and frameworks, scores and prioritizes risk, and recommends remediation mapped to framework requirements.
Related pages
- What Is Continuous Control Assurance (CCA)? explains the strategic level of control assurance, which validates whether controls continue to operate as expected.
- What Is Continuous Control Monitoring (CCM)? explains the capability within Continuous Control Assurance that monitors the evidence behind each control between tests.
- The Automated GRC module maps each control once across 50+ compliance frameworks.
- The ESRPM module runs the configuration checks behind requirements 1 and 2.
- Attack Surface Manager keeps the asset inventory that the annual scope confirmation starts from.
- Third-party risk management covers third-party service providers.
- What is a common control framework? explains how one control, written and tested once, serves every framework it maps to.
- How automated control testing decides whether a control still works explains the test behind each result.
- How to continuously maintain audit readiness covers keeping the evidence for every in-scope control current between audits.
- The frameworks page lists the most requested frameworks.
Sources
- PCI SSC’s PCI DSS page describes the standard, who it applies to, QSAs, ASVs and ISAs, and who decides on validation, at https://www.pcisecuritystandards.org/standards/pci-dss/.
- PCI SSC’s blog post “Just Published: PCI DSS v4.0.1” describes the limited revision and the retirement of v4.0 on 31 December 2024, at https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1.
- PCI SSC’s blog post “Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x” gives the 31 March 2025 date, the count of future-dated requirements and the examples of Requirements 12.5.2 and 11.3.2, at https://blog.pcisecuritystandards.org/now-is-the-time-for-organizations-to-adopt-the-future-dated-requirements-of-pci-dss-v4-x.
- PCI SSC’s merchant page names the 12 PCI requirements and explains why encryption alone does not remove scope, at https://www.pcisecuritystandards.org/merchants/.
- PCI SSC’s page about the council names its founding members, at https://www.pcisecuritystandards.org/about_us/.
- PCI SSC’s PCI DSS resource hub lists the customized approach and targeted risk analysis templates, at https://blog.pcisecuritystandards.org/pci-dss-v4-0-resource-hub.
- PCI SSC’s FAQ 1328 on the current version, with FAQ 1564 on future-dated requirements, is at https://www.pcisecuritystandards.org/faqs/1328/.
- Every source above was read on 25 September 2026.
Do this once instead of every audit.
Every step above can be done by hand. DigitalXForce does them continuously, maps the result to 50+ frameworks once, and keeps the evidence current between audits. A 30 minute walkthrough on your own framework set shows what that removes from your calendar.
