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

Source: https://www.cyadviso.com/dora-vs-pci-dss-eu-digital-resilience-act-and-global-card-data-standard
Last reviewed: 2026-04-29
Tags: DORA, PCI DSS

DORA vs PCI DSS 4.0.1 for EU fintechs in 2026: scope, enforcement, incident reporting, cardholder data, ICT risk and a build-once evidence approach in 2026.

---

**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.

## 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.

## Related reading

- [DORA Incident Reporting 2026: Initial Notification, Intermediate Report and Final Report Timeline](/dora-incident-reporting)
- [DORA Register of Information: 2026 Guide for ICT Third-Party Risk](/dora-register-of-information)
- [DORA vs PSD2/PSD3: 2026 Guide for EU Payment Institutions and EMIs](/dora-vs-psd2-psd3)
- [DORA vs MiCA: 2026 Compliance Guide for EU Fintechs and CASPs](/dora-vs-mica)
- [vCISO for EU Fintechs: 2026 Guide to Scope, Evidence and Retainers](/vciso-everything-you-need-to-know)

## Primary sources

- [Regulation (EU) 2022/2554 — DORA, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [EBA — Digital Operational Resilience Act](https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act)
- [EBA — Joint Technical Standards on major incident reporting](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-technical-standards-major-incident-reporting)
- [PCI Security Standards Council — PCI Data Security Standard](https://www.pcisecuritystandards.org/standards/pci-dss/)
- [PCI Security Standards Council — Document Library](https://www.pcisecuritystandards.org/document_library/)
- [PCI SSC — PCI DSS v4.0 press release and transition timeline](https://www.pcisecuritystandards.org/about_us/press_releases/securing-the-future-of-payments-pci-ssc-publishes-pci-data-security-standard-v4-0/)

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/dora-vs-pci-dss-eu-digital-resilience-act-and-global-card-data-standard