DORA and Your Payment Stack: Concentration Risk, Testing and Evidence in Practice

Note: this is an implementation-focused overview, not legal advice. Scope questions and interpretation belong with your compliance team and counsel.

Where DORA came from, in one paragraph

DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025, harmonizing operational-resilience rules across roughly twenty types of financial entities. Banks, payment institutions, e-money institutions, investment firms, insurers and more, plus the critical ICT providers that serve them. Its premise is blunt: the financial sector runs on third-party technology, so a localized provider failure can propagate system-wide unless firms manage ICT risk with the same rigor as financial risk. Supervisory activity since has focused on exactly the areas this article covers: registers, concentration, testing and evidence.

The five pillars, mapped to a payment stack

1. ICT risk management. DORA expects you to know your critical ICT dependencies. For payments, that means an inventory that goes deeper than "we use [PSP]": processors, acquirers, billing platforms, token vaults, webhook infrastructure, reconciliation systems, and the dependencies between them. A payment architecture map is, functionally, the payments chapter of your ICT risk framework. (This is the mapping discipline we describe in What is PRPM.)

2. Incident reporting, and Article 23 specifically. DORA's incident regime explicitly extends to operational or security payment-related incidents for credit institutions, payment institutions, account information service providers and e-money institutions (Article 23). Practically: you need to detect payment incidents fast enough to classify and report within supervisory timelines, which is hard if your only view of a provider's health is that provider's own status page. Independent detection of payment-flow degradation stops being nice-to-have.

3. Resilience testing (Articles 24-27). DORA requires a proportionate testing program for ICT tools and systems, up to threat-led penetration testing (TLPT) for significant entities. Applied to payments, the often-missed implication: your recovery paths are in scope. A documented failover to a secondary provider that has never been exercised is precisely the "documentation exercise" supervisors have signaled they'll probe. A scheduled failover-validation program, we've published the methodology. Doubles as DORA testing evidence for the payment domain.

4. Third-party risk (Articles 28-30). The heart of it for payments. Four concrete obligations:

• Register of information (Art. 28(3)): a maintained register of all ICT third-party arrangements, reportable to your competent authority. Your PSPs, billing platform and vault provider belong in it, classified by criticality.
• Concentration-risk assessment (Art. 29): a preliminary assessment of ICT concentration risk at entity level. For payment stacks this is unusually quantifiable. The share of revenue flow dependent on one provider, one merchant account, one vault. We've published the measurement approach; under DORA it stops being optional analysis and becomes the evidence behind your assessment.
• Contractual provisions (Art. 30): required clauses in ICT contracts. Audit and access rights, incident notification, subcontracting conditions, termination. Worth checking against your actual PSP agreements, which were rarely drafted with DORA in mind.
• Exit strategies: a documented, credible plan for leaving a critical provider. For payments, credibility hinges on the unglamorous details: token portability, webhook re-pointing, reconciliation continuity. An exit strategy that ignores where stored credentials live is fiction.

Supervisory guidance extends the lens to subcontractors: your providers' providers. If your PSP and your billing platform share an underlying dependency, that's concentration you're expected to identify, and it's invisible without mapping.

5. Information sharing. Voluntary threat-intelligence sharing; the least payment-specific pillar, included for completeness.

What supervisors reward: evidence over assertion

The consistent signal from early DORA supervision is that assertions don't survive examination. Evidence does. For the payment domain, an evidence base looks like: a current architecture map with criticality classification; a concentration assessment with actual revenue numbers and dates; test records for recovery paths with pass criteria and results; a register that matches reality; and contract gap-analyses against Article 30. Assembled manually, this is a quarterly scramble. Generated continuously from the live stack, it's a report. That continuous evidence layer (map, score, test, prove) is the "Prove" stage of the PRPM lifecycle and a core function of the PayRes platform.

If you're not in scope, read it anyway

DORA's logic is traveling: UK operational-resilience rules rhyme with it, and enterprise procurement teams increasingly ask vendors DORA-shaped questions regardless of jurisdiction. "We maintain a payment-provider register, quantify concentration, and test our recovery paths on a schedule" is becoming a due-diligence answer that wins deals. Regulation or not.