DORA vs PCI DSS 4.0.1

In this article ↓

DORA vs PCI DSS in one table
The short answer for fintechs
Scope: entity-driven vs data-driven
Enforcement difference
Incident reporting: one incident intake, two legal paths
PCI DSS 4.0.1 points that matter for DORA teams
Third-party risk: DORA is wider
Testing: do not confuse a CDE test with a DORA test programme
Build-once evidence model
Example control mapping
Common mistakes
Treating PCI DSS as enough for DORA
Treating DORA as enough for PCI DSS
Splitting ownership
Using the PCI service-provider list as the DORA Register of Information
Ignoring payment page JavaScript and embedded providers
2026 operating checklist
Bottom line
FAQ
Does PCI DSS compliance make an EU fintech DORA compliant?
Does DORA replace PCI DSS for card payments?
Can one incident trigger both DORA and PCI response work?
Should the DORA Register of Information include PCI service providers?
Is a PCI penetration test enough for DORA resilience testing?
Who should own the combined DORA and PCI evidence model?
Related reading
Primary sources

Last reviewed: 29 April 2026

Key takeaways

DORA and PCI DSS solve different problems: operational resilience for financial entities vs card-data security controls.
A card-processing fintech may need both sets of evidence, with different owners and review cycles.
Partners ask how ICT risk, incidents, outsourcing and card-data controls connect without duplicate work.
Fastest path: map shared controls -> separate evidence requirements -> close gaps by regime.

DORA and PCI DSS often meet inside the same fintech, but they do not solve the same problem.

DORA is the EU digital operational resilience regime for financial entities. It asks whether the regulated firm can identify ICT risk, withstand disruption, report major ICT-related incidents, test resilience and govern ICT third-party dependencies.

PCI DSS 4.0.1 is the payment-card data security standard. It asks whether cardholder data and sensitive authentication data are protected across the cardholder data environment (CDE). PCI DSS is not EU law; compliance and validation are driven by payment brands, acquirers and card-processing contracts.

For an EU payment institution, EMI, acquirer, processor, CASP with card products or embedded-finance platform, the practical answer is:

DORA governs the resilience of the regulated financial entity. PCI DSS governs the protection of cardholder data. If both apply, operate one control system with two evidence views.

DORA vs PCI DSS in one table

Question	DORA	PCI DSS 4.0.1
Legal nature	EU regulation, directly applicable	Industry standard enforced through card-brand/acquirer programmes
Core purpose	Digital operational resilience of financial entities	Protection of payment account data
Scope trigger	Being a financial entity in DORA scope	Storing, processing, transmitting cardholder data or affecting CDE security
Main owner	Regulated financial entity	Merchant, service provider, processor or other card-data environment owner
Main systems	ICT systems supporting financial services, especially critical or important functions	Cardholder Data Environment and connected systems
Main evidence	ICT risk framework, incident reporting, testing, Register of Information, supplier oversight	RoC/SAQ, AOC, CDE scope, ASV scans, pen tests, policies and control evidence
Enforcement	National competent authority under DORA and national law	Payment brands/acquirers under contract and programme rules
Status in 2026	Applies since 17 January 2025	PCI DSS v4.0.1 is the operative v4.x standard; future-dated v4 requirements became mandatory after 31 March 2025

The short answer for fintechs

Scenario	DORA relevance	PCI DSS relevance
Payment institution accepting cards directly	Directly relevant if the entity is in DORA scope	Relevant if cardholder data is stored, processed or transmitted
EMI using a hosted payment page	DORA covers the EMI's ICT risk and third-party dependency	PCI scope may be reduced, but the hosted payment provider and integration still matter
Card processor or gateway	DORA may apply if the entity is a financial entity or ICT provider to financial entities	Usually highly relevant as a service provider
Marketplace fintech with tokenised card payments	DORA may cover the regulated financial service and operational dependencies	PCI scope depends on whether PAN is touched or whether validated tokenisation/offload is used
SaaS vendor serving financial firms	DORA may appear through customer contract and ICT third-party due diligence	PCI applies only if the vendor handles cardholder data or affects the CDE

Scope: entity-driven vs data-driven

DORA is entity-driven. It starts with the regulated financial entity and the ICT systems that support the services it provides. Card data may be irrelevant to a DORA control if the system supports a critical or important function.

PCI DSS is data-driven. It starts with account data and the environment that stores, processes or transmits it. Systems can be outside PCI scope if cardholder data is properly segmented or outsourced through validated payment flows, but those same systems may still be in DORA scope.

System or process	DORA view	PCI DSS view
Core ledger	Likely in scope if it supports critical financial services	Only in PCI scope if it stores, processes or transmits cardholder data or is connected to the CDE
Payment page scripts	Relevant if they affect service continuity or incident risk	Highly relevant under PCI DSS v4.x payment page security expectations
Cloud hosting provider	ICT third-party dependency; may need Register of Information entry	PCI responsibility depends on CDE role and shared responsibility matrix
Tokenisation provider	ICT third-party dependency	PCI-critical if it affects PAN/tokenisation controls
Fraud monitoring platform	ICT risk and third-party risk if important to service	PCI scope depends on card data access
Customer support tool	DORA relevant if used in critical service workflows	PCI scope if support staff can view or process PAN

Enforcement difference

DORA is public-law supervision. The competent financial authority can examine the financial entity's ICT risk management, incident reporting, testing and third-party risk arrangements.

PCI DSS is industry programme enforcement. The PCI Security Standards Council develops the standards and qualification programmes, but validation and compliance obligations are normally imposed through payment brands, acquirers and contracts.

Issue	DORA consequence	PCI DSS consequence
Weak ICT risk framework	Supervisory findings, remediation requirements, potential national-law penalties	Not necessarily a PCI issue unless CDE controls are affected
Cardholder data breach	May be a DORA incident if it affects ICT services, data integrity/confidentiality or critical functions	Forensic investigation, card-brand/acquirer process, possible fines or processing restrictions
Missing Register of Information	DORA evidence gap	Not a PCI artefact
Missing ASV scans for internet-facing CDE	May support a wider DORA finding if vulnerability management is weak	Direct PCI compliance issue
Weak supplier contract	DORA Article 30 issue for ICT arrangements supporting critical or important functions	PCI issue if the service provider's CDE responsibilities are not documented

Incident reporting: one incident intake, two legal paths

The same event can trigger both DORA and PCI response obligations.

Example: a compromised payment page script exposes PAN and also disrupts the fintech's ability to process payments. The security team should not open separate incident timelines that later contradict each other. Use one incident intake and evidence record, then classify it under each regime.

Reporting question	DORA	PCI DSS / card-programme path
Trigger	Major ICT-related incident under DORA classification criteria	Suspected or confirmed cardholder data compromise or programme-defined event
Reporting route	Competent financial authority / national DORA process	Acquirer, payment brand, processor and possibly PCI forensic process
Timing	Staged reporting under DORA technical standards: initial, intermediate and final report	Contractual and brand/acquirer rules; not one universal PCI DSS clock
Evidence	Classification rationale, impact, timeline, root cause, remediation	Forensic facts, CDE scope, affected accounts, containment and validation evidence
Owner	Financial entity	Merchant/service provider/processor under card acceptance or service contract

Safe operating rule: one incident record, two notification decision trees.

For DORA timing, use the current DORA incident-reporting technical standards and the local competent authority's submission channel. For PCI/card data events, check the acquirer contract, payment-brand rules and forensic investigation requirements.

Need one control model for DORA and PCI DSS without mixing them?

A 15-minute call can identify shared controls, separate evidence and the gaps that still need owners.

Book a free 15-min call →

PCI DSS 4.0.1 points that matter for DORA teams

PCI DSS v4.x increased the emphasis on continuous security, targeted risk analysis, payment page security, MFA and clearer responsibility. These themes are useful for DORA teams because they create evidence that also supports ICT risk management.

PCI DSS theme	Why DORA teams should care
Defined CDE scope	Helps separate card-data risk from wider ICT resilience risk
Targeted risk analysis	Supports risk-based control frequency decisions
Payment page script controls	Important for fraud, data compromise and third-party script risk
MFA and access controls	Strong evidence for identity and access management
Vulnerability scanning and penetration testing	Feeds DORA resilience testing and vulnerability management evidence
Service provider management	Supports DORA ICT third-party risk oversight

Third-party risk: DORA is wider

PCI DSS asks whether service providers that affect the CDE meet their PCI responsibilities. DORA asks whether the financial entity understands, governs and can exit ICT third-party dependencies, especially for critical or important functions.

Capability	PCI DSS 4.0.1 view	DORA view
Service provider list	Identify providers that store, process, transmit cardholder data or affect CDE security	Maintain ICT third-party arrangements in the Register of Information
Responsibility matrix	Clarify which PCI controls sit with the entity and which sit with the provider	Clarify operational, security, audit, access, termination and cooperation obligations
Contract review	Confirm applicable PCI responsibilities and acknowledgement	Include Article 30 provisions where arrangement supports critical or important functions
Ongoing monitoring	Review PCI status and service provider evidence	Monitor performance, risk, concentration, subcontracting and exit risk
Exit planning	Not the primary PCI control lens	Required for certain ICT arrangements, especially those supporting critical or important functions

If the DORA Register of Information is maintained well, the PCI service-provider list can often be derived as a filtered CDE view. The reverse is usually not true because PCI will not capture every ICT dependency relevant to operational resilience.

Testing: do not confuse a CDE test with a DORA test programme

PCI DSS testing is scoped to the CDE and PCI control objectives. DORA testing is broader and risk-based across ICT systems and services supporting the financial entity.

Testing activity	PCI DSS contribution	DORA contribution
External ASV scans	Required for applicable internet-facing CDE scope	Evidence for vulnerability management, but not enough alone
Internal vulnerability scans	Supports CDE security assurance	Feeds ICT risk and remediation tracking
CDE penetration test	Tests segmentation, network and application risks in PCI scope	Useful evidence, but only one component of resilience testing
Tabletop exercise	Supports incident response maturity	Strong DORA evidence if it includes classification, escalation and reporting
BCDR / recovery test	Not the core PCI DSS purpose	Central to DORA operational resilience evidence
TLPT	Not a PCI DSS requirement	Required for selected financial entities under DORA Article 26

Build-once evidence model

The goal is not to merge DORA and PCI DSS. The goal is to avoid creating duplicate evidence for related controls.

Operating artefact	DORA evidence view	PCI DSS evidence view
ICT asset inventory	Systems supporting critical or important functions	CDE systems and connected-to/security-impacting systems
Risk register	ICT risks, owners, treatment and residual risk	Card-data risks and targeted risk analysis inputs
Incident playbook	Major ICT incident classification and reporting	Cardholder data compromise escalation
Supplier register	Register of Information and Article 30 oversight	PCI service provider list and AOC tracking
Testing calendar	DORA Article 25 testing programme	ASV scans, CDE pen test and PCI control testing
Board report	ICT risk, incidents, third-party concentration and resilience posture	PCI compliance status and card-data risk section
Evidence index	DORA pillar evidence	RoC/SAQ/AOC artefact references

Example control mapping

Control	DORA reason	PCI DSS reason	Practical implementation
MFA for privileged access	Reduces ICT access and operational risk	Supports PCI access-control requirements	One IAM standard, with CDE-specific enforcement evidence
Payment page script inventory	Manages third-party and integrity risk	Supports PCI DSS v4.x payment page script controls	Maintain script inventory, authorisation and change evidence
Vendor due diligence	ICT third-party risk management	Service provider PCI responsibility	One supplier review template with PCI and DORA sections
Vulnerability remediation SLA	ICT risk treatment and resilience	Vulnerability management	Severity-based SLA tied to asset criticality and CDE status
Incident tabletop	Tests escalation and management reporting	Tests card-data compromise response	One exercise with DORA and PCI notification injects

Common mistakes

Treating PCI DSS as enough for DORA

PCI DSS protects cardholder data. DORA requires operational resilience across the financial entity's ICT risk environment. A strong PCI programme can still leave DORA gaps in BCDR, Register of Information, management-body reporting or non-card ICT dependencies.

Treating DORA as enough for PCI DSS

DORA does not replace PCI DSS requirements for cardholder data. It does not create a PCI AOC, SAQ, RoC, ASV scan result or card-brand validation evidence.

Splitting ownership

If payment operations owns PCI, compliance owns DORA and engineering owns incidents, nobody owns the combined operational reality. Assign one security or ICT risk owner for the shared evidence model.

Using the PCI service-provider list as the DORA Register of Information

The PCI list is too narrow. It usually misses non-CDE ICT providers that still support critical or important financial functions.

Ignoring payment page JavaScript and embedded providers

Hosted and embedded payment flows reduce some PCI burden, but they do not remove supplier, change, monitoring and incident risks. DORA will still care about the operational dependency.

2026 operating checklist

Task	Owner	Output
Confirm whether the entity is in DORA scope	Compliance / legal	Scope memo
Confirm PCI role: merchant, service provider, processor or out-of-scope	Payment operations / QSA	PCI scope statement
Map CDE systems to ICT asset inventory	Security / engineering	Combined asset view
Mark CDE providers in the DORA Register of Information	Vendor risk / compliance	Filtered supplier view
Add card-data notification path to incident playbook	Security / legal / payment ops	Dual-path incident procedure
Align test calendar	Security	DORA and PCI testing plan
Build board reporting section for card-data risk	vCISO / risk owner	Management pack

Bottom line

DORA vs PCI DSS is not a choice. For EU fintechs that handle card data, the two regimes sit over different parts of the same operating environment.

DORA asks whether the financial entity can operate resiliently under ICT disruption and third-party dependency.

PCI DSS asks whether payment account data is protected in the cardholder data environment.

The practical approach is one ICT risk framework, one supplier inventory, one incident intake, one testing calendar and one evidence index, with a PCI-specific CDE view and a DORA-specific supervisory view.

FAQ

Does PCI DSS compliance make an EU fintech DORA compliant?

No. PCI DSS is focused on protecting payment account data in the cardholder data environment. DORA is wider: it covers ICT risk management, incident reporting, resilience testing, ICT third-party risk, business continuity and management-body oversight for financial entities in scope.

Does DORA replace PCI DSS for card payments?

No. DORA does not create PCI validation evidence such as an AOC, SAQ, RoC, ASV scan or CDE scoping record. A fintech that stores, processes or transmits cardholder data still needs to manage PCI obligations through the relevant card, acquirer or processor route.

Can one incident trigger both DORA and PCI response work?

Yes. A payment-page compromise, card-data exposure or processor disruption may need one factual incident record with two decision paths: DORA major ICT incident classification and the relevant card-programme or acquirer notification process.

Should the DORA Register of Information include PCI service providers?

Usually yes, where those providers deliver ICT services to the financial entity. The PCI service-provider list can often be treated as a filtered view of the wider DORA ICT third-party inventory, but it is usually too narrow to replace the Register of Information.

Is a PCI penetration test enough for DORA resilience testing?

No. A PCI penetration test can support DORA evidence, especially for CDE-related systems, but DORA testing is broader. It should also cover ICT services, recovery, incident escalation, supplier failure scenarios, remediation tracking and, for selected entities, TLPT.

Who should own the combined DORA and PCI evidence model?

Ownership should sit with a named ICT risk, security or vCISO lead who can coordinate compliance, payment operations, legal, engineering and supplier management. Splitting PCI and DORA into disconnected workstreams creates duplicated evidence and inconsistent incident timelines.

DORA vs PCI DSS 4.0.1: 2026 Guide for EU Fintechs Handling Card Data