DORA Compliance for Fintech: Third-Party ICT Risk in 2026

A Lithuanian e-money institution got a supervisory letter from the Bank of Lithuania in March 2026. The letter asked for three things: the register of information in the EBA dry-run format, a documented exit plan for a non-EU cloud provider, and evidence that a threat-led penetration test had been scoped for 2026 or 2027. The fintech had none of the three.

This is what DORA looks like now that it is no longer a project. Regulation (EU) 2022/2554, the Digital Operational Resilience Act, has been enforceable since 17 January 2025. For more than a year, EU competent authorities (national central banks, the EBA, ESMA, EIOPA, plus the joint Lead Overseer construct for critical third-party providers) have been calibrating what compliance actually means in practice. Fintechs that treated DORA as a 2024 paperwork exercise are now finding out what the supervisors expected.

This post is for fintech CTOs, heads of risk, and platform leads scoping a remediation in 2026. It focuses on the parts of DORA where the practical bar moved most: ICT third-party risk, threat-led penetration testing, and the incident reporting clock. It does not retread the high-level overview that was already covered in our fintech development guide and the embedded finance build piece.

Where DORA actually bites in 2026

The 2024 effort for most fintechs went into governance language: an ICT risk management policy signed by the board, an updated information security framework, a refreshed business continuity plan. That work was necessary but it is not what supervisors are testing in 2026.

Supervisory exams now focus on four operational areas:

1. Register of information completeness. Article 28(3) requires every financial entity to keep a register of all contractual arrangements on the use of ICT services. The EBA dry-run format (Commission Implementing Regulation (EU) 2024/2956) is the binding template. The first formal submission window closed 30 April 2025; updates and new contractual arrangements must be reflected on an ongoing basis.
2. Subcontracting RTS adherence. Commission Delegated Regulation (EU) 2024/1773 sets the rules for subcontracting of critical or important functions. Most pre-2024 vendor contracts allow open-ended subcontracting without notification, which is no longer compliant.
3. TLPT readiness. Significant financial entities must complete a threat-led penetration test at least every three years under the TIBER-EU based RTS. National authorities are now drawing up scoping lists.
4. Incident reporting timeliness. The 4-hour, 72-hour, and 1-month notification clocks under Commission Delegated Regulation (EU) 2025/295 are tested every time something goes wrong. Most fintechs miss the 4-hour initial notification because the classification step takes too long.

Two of these (register and incident reporting) are continuous obligations, not one-off projects. They show up in every supervisory dialogue from now on.

The register of information: format, scope, common gaps

The register is not a vendor list. It is a structured dataset with 15 tables, joined by stable identifiers, covering every contractual arrangement that supplies an ICT service. The EBA dry-run in 2024 surfaced four recurring failure modes:

• Hosting and platform providers logged under one row when in practice they support multiple critical functions with different criticality ratings.
• LEI codes missing for non-EU subcontractors, particularly US SaaS vendors that have never registered with GLEIF.
• “Critical or important function” flags applied to fewer than 10% of contracts. Supervisors generally expect 25 to 60% in a typical fintech, depending on business model.
• Concentration risk fields left blank, even though Article 29 explicitly requires fintechs to assess concentration before entering new agreements.

The data model is rigid. Five-character function codes, ISO 4217 currency codes for contractual values, GLEIF LEI codes for entities, two-letter ISO country codes for locations of data processing. Building this once in a spreadsheet works in year one. By year three, it should be sourced from your procurement system, your IAM directory, and your data inventory, with automated reconciliation against your CMDB.

The pragmatic build pattern is a contract intelligence layer. Procurement loads each new ICT contract into a structured record (vendor LEI, contract type, function supported, criticality, data categories, subcontracting permissions, exit terms). A scheduled job emits the register in the EBA XBRL or CSV format on demand. When supervisors ask for the register, you produce it in hours, not weeks.

Contractual rewrites under Article 30 and the subcontracting RTS

Article 30 lists the mandatory clauses that every ICT services contract must contain when the service supports a critical or important function: service descriptions, locations of data, access and audit rights, security and information confidentiality, support of incident management, exit strategy, and termination rights. The subcontracting RTS layers a further requirement: the financial entity must approve in advance any subcontracting of an entire critical service.

Most pre-DORA SaaS contracts fail on five of those points: they allow assignment without consent, they limit audit to SOC 2 reports only, they cap liability below what is reasonable for an outage of a critical function, they do not enumerate exit assistance, and they treat subprocessors as a notification-only list. Rewriting these contracts is a 12 to 24 month exercise. Most large vendors (AWS, Microsoft, Google, Stripe, Adyen, Plaid) shipped DORA addenda in 2024 and 2025, but local vendors often have not.

For 2026, the supervisory expectation is that all contracts supporting critical or important functions are either DORA-compliant or have a documented remediation plan. Documented means logged in the register, not in an email thread.

Incident classification and the 4 / 72 / 1-month reporting clock

The reporting RTS (Commission Delegated Regulation (EU) 2025/295) makes the clock mechanical. From the moment a major ICT-related incident is classified as such, the financial entity has:

• 4 hours to submit an initial notification to the competent authority (and no later than 24 hours after detection, even if classification took longer).
• 72 hours to submit an intermediate notification once root cause analysis has matured.
• 1 month to submit a final notification including impact, remediation, and lessons learned.

Classification uses seven criteria: clients impacted, reputational impact, duration, geographic spread, data loss, economic impact, criticality of services affected. A weighted scoring tool is the only way to make the 4-hour clock reachable. Building one is a four-week sprint: a decision tree, an on-call notification path, a structured incident record, and a one-page submission template per competent authority.

The number that catches teams out is the 24-hour cap from detection. If your SOC takes 20 hours to escalate something from “alert” to “potential major incident”, you have 4 hours to file. Many fintechs in 2025 found that their L2 escalation paths regularly took 30 to 60 hours. That gap is closing now, but it requires the SOC playbook to include a DORA classification step at the alert level, not after triage.

Threat-Led Penetration Testing: who is in scope, how to scope

TLPT applies to financial entities that meet thresholds set by competent authorities and to certain Critical ICT Third-Party Providers. The thresholds are calibrated nationally. In practice, a fintech with EUR 5 billion or more in assets under custody, or a payment institution processing more than EUR 2 billion in annual volume, can expect to be in scope.

TLPT is not a normal red team. It uses the TIBER-EU methodology: real-world threat intelligence specific to the entity, a controlled engagement that targets production systems, and supervision by a TIBER cyber team at the national authority. A test typically takes six to nine months, costs EUR 250,000 to EUR 800,000 in external fees, and requires senior internal headcount through the full window.

For 2026, the right posture is to assume you will be in scope by 2027 or 2028, and to start scoping the threat intelligence input, the white team composition (internal control function blind to test details), and the budget. Waiting for the regulator letter to arrive cuts your prep time to weeks instead of quarters.

Critical ICT Third-Party Provider designation: what it changes

The European Supervisory Authorities published the first list of designated Critical ICT Third-Party Providers (CTPPs) in 2025 under Regulation (EU) 2024/1505. AWS, Microsoft, and Google are on it. Several payment infrastructure providers and core banking SaaS vendors are on it. The list grows annually.

For fintechs, CTPP designation has three practical consequences:

1. The CTPP is supervised directly by the Lead Overseer (ECB, EBA, ESMA, or EIOPA, depending on sector mix). If the Lead Overseer issues a recommendation, financial entities depending on the CTPP must consider it in their own risk assessments.
2. Exit plans become non-optional. Article 28(8) requires every financial entity using a CTPP for a critical or important function to have a tested exit strategy. Tested means a documented dry run, not a paragraph in a policy.
3. Concentration risk reviews must happen at the portfolio level. If 70% of your critical functions ride on one cloud, the supervisor will ask for a multi-cloud plan even if the cloud itself is compliant.

A practical exit plan is not “we will migrate everything to another cloud in six months”. It is a documented inventory of what runs where, an alternative vendor identified per function, an estimate of cost and timeline, and a list of dependencies that would block migration (custom services, vendor-specific data formats, IAM patterns). Building this once forces useful clarity even if the migration never happens.

A 2026 punch list for fintech ICT third-party risk

If the register, the contracts, the incident clock, the TLPT plan, and the exit plan are not yet operational, here is the order to fix them:

1. Register first. It is the artifact every supervisor will ask for. Two weeks to bootstrap from procurement records, then a continuous ownership model.
2. Incident clock second. A scoring tool, a 4-hour submission template per competent authority, and an on-call playbook update. Four weeks.
3. Contract remediation third. Sort by criticality. Top 20 critical-function vendors first, addenda or new contracts within two quarters.
4. Exit plans for top three concentrations. One quarter each. Document, test, archive.
5. TLPT scoping. Threat intel, white team, budget. Six months ahead of expected test window.

DORA is now an operational discipline, not a compliance project. The fintechs that ship faster product through 2026 are the ones who treated the register and the incident clock as platform infrastructure, not paperwork. The supervisor letter is going to land. The question is whether the answer takes 14 months or 14 days.