DORA ICT Third-Party Risk: Controls FinTech SaaS Can Ship This Quarter

The Digital Operational Resilience Act has been enforceable since January 17, 2025, and DORA compliance fintech teams scramble toward is not just a matter of ticking boxes. Article 28 to 44 of DORA introduce a structured ICT third-party risk management framework that touches every SaaS vendor selling into the EU financial sector. If your product processes payments, hosts investment data, or connects to a bank's core system, the financial entity on the other end of your contract is now required to impose DORA-aligned obligations on you.

This post translates three specific requirements into engineering tasks: building a provider register, writing exit plans that satisfy regulators, and running resilience tests your team can complete before year-end.

Why ICT Third-Party Risk Is the DORA Requirement Most SaaS Teams Are Ignoring

The provisions that draw the most attention - incident reporting timelines, DSTI threat-led penetration testing - require significant preparation, so teams focus on those first. Third-party risk management feels like a procurement problem, not a software problem. That framing is wrong.

Financial entities under DORA must maintain a complete register of all ICT third-party service providers they use (Article 28(3)). When your customer is audited, they hand over that register. If your product sits in it and you cannot demonstrate your own third-party controls, you put your customer's compliance posture at risk. More practically, a growing number of RFP questionnaires for financial sector contracts now ask vendors to describe their ICT provider register and exit planning practices directly.

The secondary pressure is concentration risk. DORA (Article 29) requires financial entities to identify situations where critical functions depend on a small number of third-party providers. Cloud providers, CDNs, DNS resolvers, payment processors - if your SaaS application is materially dependent on a single vendor for a critical capability and you have no documented exit strategy, that is a concentration risk your customer must disclose to their supervisor.

Getting ahead of this is straightforward. None of the three controls below require months of work.

Control 1: Build a Provider Register in a Week

The register itself does not need to be sophisticated. What it needs is completeness and structured data. For each ICT provider you rely on, capture:

• Provider name and legal entity - the entity in the contract, not just the product name
• Service category - cloud infrastructure, payment processing, identity/auth, monitoring, CDN, DNS, data storage, sub-processors
• Criticality classification - whether the service supports a function that, if disrupted, would prevent your product from operating (critical) or would degrade it without causing full outage (important)
• Data classification - whether the service handles personal data, financial data, or neither
• Country of data processing - relevant for GDPR overlap and for supervisory reporting
• Contract reference and review date - the contract that governs your use of the service
• Concentration flag - whether you have no practical alternative to this provider within 30 days

A spreadsheet works. A table in your internal documentation wiki works. The goal is that any engineer on the team can find it, any compliance officer at your customer can read it, and it stays accurate when you add or remove a provider.

The easiest way to bootstrap the register is to export all active services from your cloud billing account, then add SaaS tools that touch production systems or production data. Payment processors, error tracking tools that ingest stack traces with customer IDs, analytics platforms that receive events, email delivery services - all of these belong in the register. Tools used only by internal staff for internal processes generally do not.

Plan a quarterly review into your engineering calendar. A register that is accurate on day one but not maintained gives a false sense of control.

Control 2: Write Exit Plans That Regulators Will Accept

An exit plan is not a runbook for shutting down a service. It is a documented answer to the question: if this provider became unavailable or unsuitable tomorrow, what would we do, and how long would it take?

DORA does not require exit plans for every provider, only for those supporting critical or important functions. For most FinTech SaaS products, that typically means the primary cloud provider, the payment processor, and any identity or authentication service embedded in the product flow.

A workable exit plan covers four things:

Trigger conditions. What would cause you to invoke the exit? Regulatory action against the provider, a sustained service outage exceeding your RTO, a contractual change that is incompatible with your customer's DORA obligations, a pricing increase that exceeds a defined threshold. Being specific about triggers avoids ambiguity about when the plan becomes relevant.

Alternative provider assessment. Name at least one alternative. For most cloud workloads this is a competitor region or a competing cloud. For payment processors, it may be a secondary acquirer relationship you maintain in standby. For identity providers, it may be a self-hosted option or a secondary vendor. The assessment does not need to be fully costed, but it needs to exist.

Migration steps at a high level. A bullet-point list of the major technical steps required to move to the alternative. Data export format, API compatibility gaps, configuration differences, DNS cutover steps. The level of detail should be enough that a competent engineer not currently familiar with the system could follow it under pressure.

Time estimate. How long would a full migration take under best-case conditions? Under realistic conditions? If your realistic estimate for migrating off your primary cloud provider is eighteen months, your customer needs to know that, because it changes how they assess concentration risk.

Exit plans do not need to be validated by actually migrating - though for critical providers, running a partial migration drill annually is worth doing. What they need to be is honest. A plan that describes a 72-hour migration that would actually take six months is worse than no plan, because it creates a false assurance that will surface badly during an actual disruption.

If you offer professional services engagement around compliance topics, a tech stack strategy review is a reasonable way to assess which of your dependencies carry the highest exit complexity before you write the plans.

Control 3: Resilience Tests You Can Complete This Quarter

DORA Article 25 requires digital operational resilience testing. The most demanding form - threat-led penetration testing (TLPT) - applies only to significant financial entities and their critical ICT providers, with a three-year cycle. For most FinTech SaaS vendors, what matters is demonstrating a functioning testing programme to customers who ask for it.

A credible testing programme for this quarter includes three components:

Scenario-based availability testing. Pick the three failure scenarios most likely to affect your customers: primary database unavailability, primary cloud region outage, third-party authentication provider outage. For each, confirm that your runbook exists, that the team has practiced it within the last twelve months, and that your recovery time objective is documented and realistic. If you have never actually failed over to a read replica or backup region in a production environment, schedule a maintenance window and do it.

Dependency failure injection. Use your staging environment to simulate the failure of one external dependency at a time - not your own infrastructure, but the third-party services in your provider register. What happens when your payment processor returns 503 for two minutes? What happens when your CDN becomes unreachable? If the answer is an unhandled exception that breaks the user session, that is a finding worth fixing before a customer's auditor asks about it. A focused code quality consulting engagement can surface these integration failure patterns quickly if your team does not have the time for a thorough internal review.

Backup and recovery verification. DORA's ICT-related incident reporting requirements (Article 17) assume you can restore systems and data. If you have not verified a full restore from backup in a production-equivalent environment within the last quarter, that is the single most impactful thing you can do this week. Document the restore time. Document the data loss window. Those numbers belong in the exit plans above.

None of these tests require specialized tooling. They require scheduling, discipline, and documentation. The output - a testing log with dates, scenarios, outcomes, and any remediation actions - is exactly what a financial entity's compliance team will ask for when they conduct third-party due diligence.

Making the Controls Stick

The challenge with DORA third-party risk controls is not building them once. It is keeping them current as your product evolves. Services get added and removed. Contracts renew with changed terms. Engineers onboard new tools without updating the register.

The smallest sustainable process is a quarterly review meeting: update the provider register, confirm exit plans are still accurate, review the testing log. Block two hours in the calendar, assign an owner, and treat it like any other recurring compliance obligation. If you are selling into the financial sector, the time investment is small relative to the cost of losing a customer because their audit found gaps in your third-party risk programme.

If you are building out this compliance foundation and want a second perspective on your current architecture, technical dependencies, or testing approach, reach out at hello@wolf-tech.io or visit wolf-tech.io. We work with FinTech SaaS teams on exactly this kind of structured engineering work.