DORA came into application for financial entities on 17 January 2025, but the work it created lands hardest on the people it does not name: non-bank financial entities and the ICT suppliers behind them. If you run software, cloud, or managed services for an insurer, a payment institution, or an investment firm, DORA is now in your contracts. Here is the operational-resilience work that rarely gets scoped.
Does DORA apply to you if you are not a bank?
DORA (Regulation (EU) 2022/2554) applies to around twenty categories of financial entity, most of them not banks: insurers and reinsurers, investment firms, payment and electronic-money institutions, crypto-asset service providers, crowdfunding platforms, fund managers, and more. It also reaches ICT third-party service providers through mandatory contract clauses and, for the largest, direct EU oversight.
Proportionality matters. Microenterprises and some small entities follow a simplified ICT risk-management framework under Article 16, while larger firms carry the full weight. Pure ICT suppliers are not directly regulated unless the European Supervisory Authorities designate them critical, but they inherit obligations the moment they serve an in-scope client.
The practical test is not your label but your dependency graph. If a regulated financial entity depends on your service to run a function it cannot easily replace, DORA follows the dependency into your organization, regardless of your size or whether financial services is your core market.
What are DORA's five pillars in engineering terms?
DORA has five pillars: ICT risk management, ICT incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. In engineering terms that is a controls framework, an incident pipeline with reporting deadlines, a testing program, a supplier register with tightened contracts, and a threat-intelligence exchange.
Mapped to the regulation:
- ▸ICT risk management (Chapter II, Articles 5 to 16): governance, asset mapping, protection, detection, response, and recovery.
- ▸Incident management (Chapter III, Articles 17 to 23): classification, thresholds, and staged reporting.
- ▸Resilience testing (Chapter IV, Articles 24 to 27): scans, penetration tests, and threat-led penetration testing.
- ▸Third-party risk (Chapter V, Articles 28 to 44): the register, contract clauses, and oversight of critical providers.
- ▸Information sharing (Article 45): voluntary cyber-threat intelligence exchange.
The stack-level view sits in NIS2, DORA, and the Cyber Resilience Act: Cloud Compliance in 2026.
What goes in the ICT third-party register (and who owns it)?
The register of information catalogs every ICT third-party arrangement supporting the financial entity, following the European Supervisory Authorities' implementing technical standards. It records contracts, the ICT services provided, whether they support critical or important functions, subcontracting chains, and identifiers such as the provider's Legal Entity Identifier. Financial entities submit it to their competent authority.
What the register expects you, as a supplier, to furnish:
- ▸Your legal name and LEI, and the entities in your subcontracting chain.
- ▸The specific ICT services provided and whether they underpin a critical or important function.
- ▸Data-processing and storage locations, including any outside the EU.
- ▸Contract references, start and end dates, and termination terms.
Financial entities filed their first registers with authorities during 2025, so requests for this data from your clients are now routine, not exceptional. Missing or inconsistent supplier data is one of the most common register defects.
Which DORA contract clauses do suppliers have to sign?
Article 30 sets mandatory contractual provisions for ICT arrangements: clear service descriptions and service levels, data location and processing terms, audit and access rights, incident-assistance duties, subcontracting conditions, and exit strategies. For services supporting critical or important functions, contracts add resilience-testing participation, ongoing monitoring, and defined termination triggers.
What each clause obliges a supplier to deliver:
- ▸Service levels: measurable SLAs with reporting, not aspirational uptime language.
- ▸Audit and access rights: the financial entity, its auditors, and its competent authority can inspect you, including on-site.
- ▸Incident support: agreed assistance and notification duties during ICT incidents.
- ▸Subcontracting: prior information and conditions before you chain material subcontractors.
- ▸Exit strategy: data portability, transition support, and deletion on termination without service disruption.
The supply-chain diligence pattern behind these clauses is covered in The 2026 SME Cybersecurity Checklist for GDPR, NIS2 and DORA.
What resilience testing does DORA actually require?
Articles 24 to 27 require a testing program proportionate to size and risk: vulnerability assessments, network security and penetration tests, scenario-based testing, and, for significant entities, threat-led penetration testing at least every three years, based on the TIBER-EU framework. Suppliers whose services are in scope may be required to take part in the financial entity's tests.
What this means in practice:
- ▸Baseline testing (vulnerability scans, configuration reviews) runs on a regular cadence with tracked remediation.
- ▸TLPT emulates real attacker tactics against live production systems, coordinated with authorities and red-team providers.
- ▸Suppliers to significant entities should expect to be named as targets or asked to allow controlled testing of their services.
The common trap is treating testing as an annual event rather than a program. DORA expects results to feed remediation, remediation to feed the next test, and lessons to reach the ICT risk framework, so a scan report that nobody actioned is evidence of a gap, not of compliance.
See what resilience really demands in DORA in Practice: What Resilience Really Asks of Your Stack, and pressure-test decision-making with Designing Tabletop Exercises That Expose Real Gaps.
How do ICT incident classification and reporting work?
Under Articles 17 to 19, financial entities classify ICT-related incidents against criteria such as clients and transactions affected, duration, geographic spread, data losses, and economic impact, then report major incidents to authorities in stages: an initial notification, an intermediate report, and a final report once root cause and remediation are known.
Supplier obligations inside that pipeline:
- ▸Detect and triage incidents affecting the services you provide.
- ▸Notify the financial entity fast enough that it can still meet its own regulatory deadlines.
- ▸Preserve logs and forensic evidence, and support root-cause analysis for the final report.
- ▸Feed accurate timestamps into the timeline the financial entity must file.
A supplier that alerts a client slowly can single-handedly blow a regulatory reporting window, which is why notification speed is now a contract term, not a courtesy.
What must ICT suppliers deliver even though DORA does not name them?
Suppliers to financial entities inherit DORA through contract flow-down: register data, audit and on-site access rights, security and subcontracting controls, incident notification within tight windows, participation in resilience testing, and a documented exit and data-portability plan. Delivering these before a client asks is now a competitive advantage in financial-services procurement.
A practical supplier readiness checklist:
- ▸Maintain the register fields your clients need, including LEI and subcontractor list, ready to hand over.
- ▸Accept the Article 30 clauses without renegotiating away audit and exit rights.
- ▸Run a security program you can evidence, not just describe.
- ▸Wire incident notification to your clients into your on-call runbook.
- ▸Prepare a tested exit and data-return plan so a client can leave without downtime.
The broader dependency-risk case is in Supply Chain Attacks: Why Your Dependencies Are Your Biggest Risk.
How TuniCyberLabs helps
We help non-bank financial entities and their ICT suppliers scope the DORA work that procurement and legal usually miss: an ICT risk-management framework proportionate to your size, register-ready third-party data, Article 30 contract readiness, an incident pipeline that meets the reporting clock, and a resilience-testing program that will not surprise you at TLPT time. We build the artifacts, not just the advice.
Need a DORA readiness review for your entity or your supplier contracts? Get in touch with our team.