PCI DSS vs DORA

How PCI DSS and DORA differ on scope, enforcement and proof

This table compares who owns each framework, who it applies to, who enforces it and what proof it produces. Read it first to see which obligations come from payment brands and which come from EU supervisors, because the two regimes rarely produce the same evidence.

Which EU entities fall under each framework

How testing cycles differ: yearly PCI tests versus DORA resilience testing and TLPT

PCI DSS fixes a penetration testing cadence for the cardholder data environment, while DORA sets a broader resilience testing duty across the financial entity and a threat-led test on a longer cycle for identified entities. The cards below separate these tracks so teams can see which test produces which evidence, and why a threat-led result does not close PCI scope testing.

How incident reporting timelines stack up

Under DORA, a major ICT incident triggers a fixed sequence of notifications to the competent authority, while PCI DSS sets no regulator clock and card brand incident processes run on their own terms. Teams that map both before an incident know which clock starts first and who must be told.

1. Classify the event as an ICT-related incident

   The financial entity's incident response team records the event in its ICT incident process and decides whether it is an ICT-related incident under DORA. This step is owned by the operational resilience or security function, with compliance involved from the start. It is done when the incident has a log entry, a timestamp of first awareness and a named owner. Under DORA, that awareness timestamp is what starts the reporting clock, so it should be recorded precisely.

2. Classify the incident as major

   The entity applies the classification criteria in its DORA incident process, including the materiality thresholds set in the delegated regulation, to decide whether the incident is major. This is a decision the entity must document, not one the card brand makes. It is done when a signed classification record exists, stating the criteria applied and the date of the decision. The 4-hour initial notification clock in the next step runs from this classification.

3. Send the initial notification to the authority

   Under Article 5 of Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after the entity became aware of it. The incident lead, with compliance sign-off, files it through the competent authority's channel. It is done when the authority's acknowledgment or the filing record is held with the incident file. Confirm the submission channel and template with your national competent authority before you need them.

4. File the intermediate report

   The entity sends an intermediate report within 72 hours of the initial notification, updating the authority on the incident's status, impact and the response taken so far. Operations, security and the data owners contribute facts, and compliance checks the content against the incident record. It is done when the report is filed and the incident log shows the update. Any change to the incident's classification or impact should be reflected here, since the authority will compare reports over time.

5. Submit the final report

   The final report is due no later than one month after the latest intermediate report. It sets out the root cause, the remediation completed, and the impact figures the entity can now confirm. The incident lead drafts it, and the accountable management body or its delegate approves it. It is done when the final report is filed and lessons learned feed back into the ICT risk register and testing plan.

6. Run the card brand and acquirer process separately

   PCI DSS sets no regulator notification clock, and the PCI SSC does not enforce compliance. Where a cardholder data environment is affected, the entity's acquirer or the relevant payment brand may impose its own incident response and reporting obligations, run under brand rules. This is a parallel track with its own owner, usually the merchant or acquiring relationship lead. It is done when the entity has written confirmation from its acquirer or brand of which notifications apply and by when.

7. Reconcile the two timelines in one incident record

   Because the DORA sequence and the card brand process run on different clocks, the entity keeps one incident record that logs every notification, its timestamp and its recipient. Compliance checks that the statements sent to the authority and to the acquirer or brand are consistent. It is done when a reviewer can trace each external statement back to the same facts and the same first-awareness time. Illustrative: a payment incident affecting both a card environment and an ICT service may generate several filings, and one record prevents them from contradicting each other.

What DORA's third-party rules add to PCI service provider obligations

Where the work overlaps, and where it does not

PCI DSS and DORA share many technical control themes, and some third-party tools map them side by side. Those mappings reduce design work, but they do not reduce the evidence each regulator or assessor expects, so the overlap is in the controls rather than in the paperwork.

Which to do first and how to share evidence

This sequence gives a payment institution that must meet both regimes one ordered path, so that a single ICT inventory and risk record feeds PCI DSS assessments and DORA supervision without duplicated work. The order depends on the card program and the supervisory timetable, so confirm both before committing dates.

1. Confirm which entity types and card roles apply

   Start by confirming whether your legal entity is one of the financial entity types listed in DORA Article 2(1), and whether your national competent authority treats you as in scope. Separately, confirm your role under PCI DSS (merchant, processor, acquirer, issuer or service provider) and the validation level each payment brand requires, since the brands, not the PCI SSC, decide who must validate. The output is a written scope note that names the DORA supervisor and the brands or acquirers that set your PCI validation duties. Done when both owners have signed off on that note.

2. Build the shared ICT asset and risk inventory

   Create one inventory of systems, applications, data flows, hosting locations and ICT third-party providers, tagging each asset for whether it stores, processes or transmits cardholder data or could affect the cardholder data environment. Add the criticality and business function fields that DORA's ICT risk management work will need. Assign an owner to every asset and every third-party service. The output is a single register that both the PCI scoping exercise and the DORA risk framework reference. Done when the register is reconciled against network diagrams and cloud account listings.

3. Close cardholder data environment gaps first

   Use the inventory to confirm the cardholder data environment boundary, then assess each in-scope requirement against the current defined or customized approach. Where a control is missing, record the remediation owner and the evidence that will prove it. Run the internal and external penetration tests required at least every 12 months and after significant changes (requirements 11.4.2 and 11.4.3), and confirm scan and access evidence is current. The output is a gap register tied to specific PCI DSS requirements. Done when a QSA or internal assessor has reviewed the boundary and the gaps are either closed or documented with an agreed plan.

4. Extend to DORA ICT risk management

   Map the same assets and controls to DORA's ICT risk management chapter, covering the governance, risk identification, protection, detection, response and recovery elements that apply to your entity. Where a PCI control already produces evidence, such as access reviews or logging, reference it rather than creating a parallel record, but confirm that the evidence meets DORA's wording and sampling expectations. Document the ICT risk management framework and its approval by the management body. The output is a DORA risk framework that points to PCI evidence where it is sufficient. Done when management has approved it and each gap is assigned.

5. Build the incident process for both regimes

   Design one incident workflow that classifies events against DORA criteria and against PCI incident response expectations, including the card brand and acquirer notification paths. Under Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it, with intermediate and final reports on the schedule the Regulation sets. Test the workflow with a tabletop exercise and confirm the contact lists for the competent authority and brands. The output is a runbook and a tested notification record. Done when the exercise has produced recorded actions with owners.

6. Run resilience testing and TLPT readiness

   Establish the DORA digital operational resilience testing programme, including the basic testing of ICT tools and systems and, if your competent authority identifies you for threat-led penetration testing, readiness for TLPT at least every 3 years or at the frequency the authority sets. Align the scope of penetration tests so that one test can support PCI requirements 11.4.2 and 11.4.3 where the scope and methodology allow, and confirm with the authority whether they will accept it. The output is a test plan, a findings log and, for TLPT, a provider and scope agreed with the authority. Done when test results feed the DORA risk register.

7. Share evidence across the two outputs

   Keep one evidence library indexed by control, asset and date, then produce different outputs from it. The PCI DSS output is a ROC or SAQ with an Attestation of Compliance on official PCI SSC templates, and certificates are not recognized as validation. The DORA output is supervisory: the competent authority uses its Article 50 powers and information requests, and the only authority-issued attestation the Regulation provides for concerns a threat-led penetration test that met the requirements. Confirm with your QSA which SOC 2 or other audit evidence they may reuse after independent review. The output is an index that shows which artifact answers which obligation. Done when both the QSA and the DORA supervisory contact have reviewed the index.

8. Review the sequence against the supervisory and card timetable

   Re-run the sequence whenever the card program, acquirer requirements or supervisory timetable changes, and when PCI SSC announces the next version of the standard, since v4.0.1 is the only active version and no release date for a new version had been announced as of October 2026. Also track the European Commission's DORA review due by 17 January 2028 and any Digital Omnibus changes still in the legislative process. Ask your QSA, competent authority and acquirers to confirm their expectations in writing before fixing dates. The output is a dated review record. Done when the owners have agreed the next review trigger.

What does it cost and take to meet both PCI DSS and DORA?