DORA vs NIS2: Obligations for Dual-Scope Entities
PCI DSS v4.0.1 is the current Payment Card Industry Data Security Standard. It sets 12 main requirement groups for protecting payment account data and the systems, people, and processes that can affect its security. The standard applies to entities that store, process, or transmit cardholder data or sensitive authentication data, and it can also apply to service providers that can affect the security of a cardholder data environment.
The 12 requirements are only one part of the compliance question. An organization also has to define the correct scope, determine which requirements are applicable to that scope, implement and maintain the controls, and follow the validation method required by its payment brand, acquirer, or other compliance-accepting entity.
As of 31 March 2025, the future-dated requirements introduced with PCI DSS v4.x are no longer optional best practices. Applicable requirements must now be fully considered during a PCI DSS assessment. PCI DSS v4.0.1 is the version organizations should use for current assessment and implementation work.
PCI DSS v4.0.1 at a glance
The quickest way to understand PCI DSS is to separate the standard itself from the scope and validation process around it.
| Question | Current answer |
| Current standard | PCI DSS v4.0.1, published in June 2024. PCI DSS v4.0 was retired on 31 December 2024. |
| Future-dated requirements | The 51 future-dated requirements became effective on 31 March 2025 and must be considered when applicable. |
| Core structure | 12 requirement groups organized under six broad security goals. |
| Who it applies to | Entities that store, process, or transmit cardholder data and/or sensitive authentication data, plus service providers that can affect the security of payment account data or the CDE. |
| What defines scope | Payment account data flows, the cardholder data environment, connected or security-impacting systems, people, processes, and third-party services. |
| How compliance is validated | Through the reporting method required by the relevant compliance program, commonly an SAQ or ROC with the appropriate AOC and other required evidence. |
| Who manages compliance programs | Payment brands, acquirers, and other compliance-accepting entities. PCI SSC publishes the standard but does not run every entity's compliance program. |
| Is there a PCI DSS certificate? | No general PCI DSS compliance certificate is recognized by PCI SSC. Official validation uses PCI SSC forms and templates. |
Official source: the PCI SSC Document Library lists PCI DSS v4.0.1 as the current standard and provides the official assessment documents and supporting material.
Who does PCI DSS apply to?
PCI DSS is intended for organizations involved in payment account processing and for service providers that can affect payment account data security. That can include merchants, processors, acquirers, issuers, gateways, hosting and cloud providers, managed security providers, and other third parties, depending on what they do and what access or influence they have.
PCI SSC specifically states that a service provider can be in scope even when it does not directly store, process, or transmit payment account data if its service can affect the security of a customer's cardholder data environment. PCI SSC FAQ 1579 gives examples such as access to the CDE, providing controls that meet PCI DSS requirements, or facilitating the storage, processing, or transmission of account data.
Outsourcing payment processing does not automatically remove PCI DSS responsibilities. A merchant that fully outsources payment handling may have a much smaller technical scope, but it still needs to understand its payment flow, manage relevant third parties, and follow the validation method required by its compliance program.
This is why "does PCI DSS apply?" and "which validation method do we need?" are separate questions. Payment brands and acquirers manage their own compliance programs and determine reporting requirements, merchant or service-provider levels, due dates, and whether an SAQ or ROC is expected. PCI SSC FAQ 1473 explains this split between compliance-accepting entities and assessors.
PCI DSS is global rather than an EU-specific regulation. A European fintech, e-commerce company, SaaS provider, or payment processor may therefore manage PCI DSS alongside GDPR, DORA, NIS2, or national requirements without those frameworks becoming interchangeable.
What is in PCI DSS scope?
The PCI DSS scope starts with payment account data and the environment that stores, processes, transmits, or can affect its security. A correct scope is not simply a list of servers that contain card numbers. It follows the data flow and the systems and services that can reach, administer, protect, or change the cardholder data environment.
The cardholder data environment, or CDE, includes the people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. Systems outside the core CDE can still matter when they connect to it or can affect its security. Third-party services can also create scope and responsibility questions.
Segmentation can reduce PCI DSS scope only when the separation is real and can be demonstrated. Labeling a network or cloud account "out of scope" is not enough if it can still reach the CDE or influence a security control that protects it.
PCI SSC also makes clear that organizations cannot choose to ignore an applicable requirement because they consider the risk low. A requirement can be treated as not applicable only when that conclusion is verified and supported. PCI SSC FAQ 1252 explains how applicability should be established for individual systems and controls.
For most teams, the practical order is to map payment account data first, define the CDE and connected dependencies second, and only then decide which systems and controls belong in the assessment. That order prevents a common failure: implementing controls against an incomplete scope.
For a deeper look at system boundaries, connected-to systems, segmentation, and security-impacting dependencies, see our guide to the PCI DSS cardholder data environment (CDE).
What are the 12 PCI DSS requirements?
PCI DSS v4.0.1 keeps the familiar 12-requirement structure. The requirement titles below are the control domains that an organization uses to organize implementation and assessment work. The exact sub-requirements that apply depend on the entity, environment, and assessment scope.
| Goal | Req. | Official requirement | What it means in practice |
| Build and maintain a secure network and systems | 1 | Install and Maintain Network Security Controls | Control traffic into, out of, and within relevant network boundaries. Maintain network diagrams, data-flow understanding, ruleset governance, and segmentation controls. |
| Build and maintain a secure network and systems | 2 | Apply Secure Configurations to All System Components | Replace insecure defaults, maintain configuration standards, remove unnecessary services and functions, and manage wireless settings securely. |
| Protect account data | 3 | Protect Stored Account Data | Minimize data storage, prohibit storage of sensitive authentication data after authorization, protect stored PAN, and manage cryptographic keys and retention. |
| Protect account data | 4 | Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | Protect cardholder data in transit across open, public networks and prevent insecure transmission methods from exposing account data. |
| Maintain a vulnerability management program | 5 | Protect All Systems and Networks from Malicious Software | Deploy and maintain controls against malware, address systems not commonly affected by malware, and reduce phishing-related risk. |
| Maintain a vulnerability management program | 6 | Develop and Maintain Secure Systems and Software | Manage vulnerabilities and patches, use secure development practices, protect public-facing web applications, and control changes to systems and software. |
| Implement strong access control measures | 7 | Restrict Access to System Components and Cardholder Data by Business Need to Know | Limit access according to job need, least privilege, approved roles, and defined access-control models. |
| Implement strong access control measures | 8 | Identify Users and Authenticate Access to System Components | Use unique identities, manage accounts and authentication factors, enforce multi-factor authentication where required, and protect authentication information. |
| Implement strong access control measures | 9 | Restrict Physical Access to Cardholder Data | Control physical access to systems, media, facilities, and point-of-interaction devices that can expose payment account data. |
| Regularly monitor and test networks | 10 | Log and Monitor All Access to System Components and Cardholder Data | Generate, protect, review, and retain audit logs so security-relevant activity can be detected, investigated, and traced. |
| Regularly monitor and test networks | 11 | Test Security Systems and Processes Regularly | Run vulnerability scans, penetration tests, segmentation tests, wireless checks, intrusion detection or prevention, and change-detection controls as applicable. |
| Maintain an information security policy | 12 | Support Information Security with Organizational Policies and Programs | Maintain governance, responsibilities, risk analyses, awareness, third-party management, scope confirmation, incident response, and compliance program controls. |
The table is a map, not a substitute for the standard. Each requirement contains detailed controls, applicability notes, testing procedures, and guidance. An assessment has to work at that level of detail rather than treating each requirement as a single checkbox.
What changed with PCI DSS v4.0.1?
PCI DSS v4.0.1 is a limited revision of PCI DSS v4.0. PCI SSC published it in June 2024 to correct formatting and typographical issues and clarify the intent and guidance around existing requirements. The revision did not add or remove requirements.
PCI DSS v4.0 was retired on 31 December 2024, after which v4.0.1 became the only active version supported by PCI SSC. PCI SSC's v4.0.1 publication notice explains the transition and the scope of the revision.
The larger operational change happened on 31 March 2025. PCI DSS v4.x introduced 64 new requirements, and 51 of them were future-dated. Those 51 requirements are now effective and must be fully considered when they apply.
The now-effective areas include controls that many teams spent the 2023–2025 transition period preparing for, such as expanded multi-factor authentication, stronger e-commerce payment-page protections, targeted risk analyses for selected control frequencies, and more formalized scope and security-process requirements.
For e-commerce environments, Requirements 6.4.3 and 11.6.1 are especially important because they address payment-page scripts and unauthorized changes. PCI SSC also revised SAQ A eligibility and reporting in 2025, so teams using SAQ A should work from the current questionnaire rather than an older copy.
How is PCI DSS compliance validated?
PCI DSS validation documents the result of an assessment. The required route is not chosen only by the organization being assessed. Payment brands, acquirers, and other compliance-accepting entities determine which reporting method they require and what evidence must be submitted.
This distinction matters because "PCI DSS compliant" is often used as if every organization passes through the same audit and receives the same certificate. That is not how the PCI program works.
| Document or evidence | Role |
| Self-Assessment Questionnaire (SAQ) | A PCI SSC assessment form used by eligible entities to document their own PCI DSS assessment for a defined use case. Different SAQs have different eligibility criteria and requirement sets. |
| Report on Compliance (ROC) | A detailed record of assessment results used when the applicable compliance program requires a full assessment and formal reporting at that level. |
| Attestation of Compliance (AOC) | The official attestation that accompanies the relevant SAQ or ROC and records the entity's attestation to the assessment result. |
| ASV scan documentation | Where external vulnerability scanning is required, an Approved Scanning Vendor performs the applicable scans and provides the official scan-compliance reporting. |
| Other technical evidence | Penetration-test reports, internal scan results, logs, configurations, policies, access records, risk analyses, change records, and other evidence support the assessment but do not replace the required validation forms. |
PCI SSC does not recognize a general compliance certificate as evidence of PCI DSS validation. PCI SSC FAQ 1220 states that official PCI SSC forms such as the ROC, SAQ, AOC, and ASV scan attestation are the recognized validation documents.
For that reason, the practical question is not "How do we get PCI certified?" It is "Which PCI DSS assessment and validation route applies to us, and what evidence do we need to support it?"
Our PCI DSS audit and assessment guide explains how SAQs, ROCs, AOCs, assessor roles, evidence, remediation, and formal validation fit together.
What should a PCI DSS program do first?
A good PCI DSS program begins with scope and validation expectations before it begins producing evidence. The following sequence is intentionally high level; each stage becomes its own workstream once the environment is understood.
- Confirm the compliance program and validation route. Identify the acquirer, payment brand, customer, or other compliance-accepting entity that sets the reporting expectation. Confirm whether an SAQ, ROC, AOC, ASV scans, or other submissions are required.
- Map payment account data and define the CDE. Document where cardholder data and sensitive authentication data enter, move, are stored, and leave the environment. Include connected systems and services that can affect CDE security.
- Determine requirement applicability. Map the in-scope environment to PCI DSS v4.0.1. Where a requirement is not applicable, document and support that conclusion rather than relying on an informal risk judgment.
- Implement and operate the controls. Policies, configurations, access controls, monitoring, vulnerability management, testing, incident response, and third-party controls have to work continuously, not only during assessment month.
- Collect assessment-ready evidence. Keep records that show the control exists, operates as required, has an owner, and can be traced to the relevant PCI DSS requirement and period.
- Assess, remediate, and complete validation. Test the environment, document findings, remediate gaps, complete any required retesting, and submit the official validation documents required by the compliance program.
PCI DSS is therefore a continuous operating requirement even when the formal validation event is periodic. Systems change, vendors change, access changes, applications change, and the CDE can expand without anyone deliberately deciding to expand it.
How do targeted risk analyses fit into PCI DSS v4.0.1?
PCI DSS v4.0.1 uses targeted risk analyses in specific places where the standard allows or requires an organization to determine a control frequency or support a defined implementation decision. A targeted risk analysis is tied to a particular PCI DSS requirement rather than serving as a general substitute for the standard.
This matters because risk analysis cannot be used to decide that an applicable PCI DSS requirement is unnecessary. Where a requirement permits a frequency based on risk, the analysis supports that frequency. Where the requirement specifies a fixed frequency or control, the organization still has to meet it.
Teams should therefore track each targeted risk analysis together with the requirement it supports, the factors considered, the decision reached, the owner, and the review trigger. That gives an assessor a clear chain from the requirement to the operating decision without turning the risk register into a substitute for technical evidence.
For the practical process, documentation, and relationship between targeted risk analyses and broader PCI DSS risk work, see our PCI DSS risk assessment guide.
How does Requirement 10 fit into the wider PCI DSS program?
Requirement 10 covers logging and monitoring of access to system components and cardholder data. It is one of the strongest connections between PCI DSS and day-to-day security operations because evidence has to be generated, protected, reviewed, and retained in a form that supports both detection and investigation.
A SIEM or managed monitoring service can help collect and analyze logs, but using a security platform does not make an environment PCI DSS compliant by itself. The organization still needs the correct sources, time synchronization, access controls, review processes, alert handling, retention, ownership, and evidence for the in-scope systems.
Requirement 10 should therefore be treated as an operating process, not a request to "turn on logging." The detailed logging and monitoring requirements need to be mapped to the actual CDE and the systems that can affect its security.
How does Requirement 11 differ from vulnerability management?
Requirement 11 focuses on regularly testing security systems and processes. That includes vulnerability scanning, penetration testing, segmentation testing where segmentation is used, intrusion-detection or prevention coverage, and other security-testing activities defined by the standard.
Scanning and penetration testing are related but not interchangeable. Vulnerability scans identify known weaknesses at defined intervals and after relevant changes. Penetration testing uses a documented methodology to test whether attack paths and weaknesses can be exploited and whether segmentation and other controls hold under active testing.
For the penetration-testing side of Requirement 11, see our PCI DSS penetration testing requirements guide for scope, testing expectations, segmentation testing, and assessment evidence.
Our PCI DSS Requirement 10 guide breaks down logging, log review, monitoring, retention, alert handling, and the evidence teams need to maintain for in-scope systems.
Prepare for Requirement 11.4 testing
Use the playbook to define PCI DSS penetration-testing scope, prepare the environment, understand segmentation testing, and plan the engagement before testing begins.
Get the PCI DSS Penetration Testing PlaybookWhat happens if an organization is not PCI DSS compliant?
PCI SSC does not impose a universal fine schedule for PCI DSS non-compliance. The Council publishes the standard and supporting programs, while payment brands and acquirers manage compliance programs and can define financial or operational consequences.
PCI SSC's FAQ on non-compliance consequences states that the Council itself does not impose consequences. Individual payment brands may have their own compliance initiatives and consequences for businesses that do not meet their requirements.
The practical risk can extend beyond a contractual penalty. A non-compliant environment can face additional remediation work, increased scrutiny, restrictions from payment partners, incident costs, and separate legal or regulatory consequences when a card-data compromise also triggers privacy, financial-sector, or cybersecurity obligations.
For that reason, a fixed statement such as "PCI DSS fines are $X per month" is usually misleading without naming the payment brand, acquirer, contract, jurisdiction, and circumstances.
How does PCI DSS fit with DORA, NIS2, and GDPR in Europe?
PCI DSS is a global payment-security standard, while DORA, NIS2, and GDPR are European legal frameworks with different scopes and enforcement models. An organization can be subject to more than one at the same time, but one framework does not replace the others.
The overlap is mainly operational. Access control, incident response, vulnerability management, monitoring, third-party oversight, secure configuration, and testing can produce evidence that supports several programs. The obligation, reporting route, assessor or regulator, and required documentation still need to be mapped separately.
A fintech can therefore design one security process that supports multiple requirements while keeping the evidence trail explicit. For example, the same logging platform may support PCI DSS Requirement 10 and DORA monitoring objectives, but the PCI DSS assessment still needs PCI-specific scope, applicability, testing, and validation evidence.
Scope, validation route, remediation work, testing, and outside assessor support can all change the final budget. Our PCI DSS compliance cost guide explains which parts usually drive the price and why two PCI projects can cost very different amounts.
What should you carry forward from the 12 requirements?
The 12 PCI DSS requirements are the control structure, not the complete compliance plan. A workable program connects four things: the correct CDE scope, the applicable v4.0.1 requirements, evidence that the controls operate, and the validation method required by the relevant payment program.
If any one of those pieces is wrong, the organization can spend months hardening systems that are not in scope, miss systems that are, collect evidence in the wrong form, or arrive at assessment with controls that exist but cannot be proven.
Start with scope and validation. Then build the control and evidence work around the real payment environment rather than around a generic 12-item checklist.
Move from PCI DSS scope to assessment-ready evidence
Q-Sec supports PCI DSS scoping, gap assessment, remediation, penetration testing, and coordination with an independent QSA partner for formal validation.
Explore PCI DSS Compliance ServicesFrequently asked questions about PCI DSS requirements
What is the current version of PCI DSS?
PCI DSS v4.0.1 is the current version. PCI DSS v4.0 was retired on 31 December 2024, and the future-dated v4.x requirements became effective on 31 March 2025.
What are the 12 PCI DSS requirements?
They cover network security, secure configuration, stored and transmitted data, malware, secure development, access control, authentication, physical security, logging, security testing, and governance.
Does PCI DSS apply if all payment processing is outsourced?
It can. Outsourcing may reduce technical scope, but merchants still need to manage relevant providers and follow the validation requirements set by their acquirer or payment brand.
Is PCI DSS a law?
PCI DSS is an industry security standard, not a statute. Payment brands and acquirers manage compliance programs, while separate laws or regulations may apply to the same organization and incident.
Is there an official PCI DSS certificate?
No. PCI SSC recognizes its official validation forms, including SAQs, ROCs, AOCs, and ASV scan attestations. A general "PCI DSS certificate" is not an official PCI SSC validation document.
Do all 12 requirements apply to every system?
Applicable PCI DSS requirements apply to in-scope systems. A specific requirement may be not applicable only when that conclusion is verified and supported; perceived low risk is not enough.
How often does PCI DSS need to be validated?
The exact validation frequency and reporting method are set by the applicable payment brand, acquirer, or other compliance-accepting entity. Organizations should confirm the requirements of their own compliance program.
Are the PCI DSS v4.x future-dated requirements mandatory now?
Yes. Since 31 March 2025, applicable future-dated requirements must be fully considered as part of PCI DSS assessments.
Author: Q-Sec Security Operations Center
Sep 8, 2026, 2:53:00 PM
Sep 8, 2026, 2:53:00 PM
