We are not licensed, we just sell to banks. Does DORA bind us?

Not directly, unless the authorities designate your company as critical. It binds your customer instead. The customer has to put specific terms in the contract and can only work with a supplier that meets them. In practice, that makes DORA a condition of the deal. I recommend preparing the terms once and reusing them.

Does hosting on a hyperscaler solve it?

It solves part of the supply chain question. The major clouds publish DORA addenda, and the authorities are onboarding them as critical providers. It doesn't solve the company's own inventory, incident process, testing, or exit plan. Those stay with the team.

How does DORA relate to NIS2?

DORA is the specific law for finance and takes precedence over NIS2 for financial entities. The measures overlap heavily: inventory, incident handling, backups, supply chain, testing. A platform built for DORA answers a large share of NIS2 questionnaires.

Where do you start on a DORA engagement?

With the register of information, which forces the inventory. Then a dry run of an exit: can the customer get their data and run without the supplier? Those two expose every gap the rest of the regulation cares about. How long would that dry run take on your platform today?

All guides

Guide

DORA for fintech teams and their suppliers

What the Digital Operational Resilience Act asks of a fintech's cloud platform, and what its contract rules mean for suppliers to banks and insurers.

DORA is an EU regulation, so it applies directly in every member state without a national version. It has applied since 17 January 2025 to financial entities: banks, payment and e-money institutions, investment firms, crypto-asset service providers, insurers, pension funds, and more. It's about the technology under the finance. That covers how a company manages ICT risk, classifies and reports incidents, tests its resilience, and controls the third parties it depends on.

A startup meets DORA in one of two ways. Either it's a financial entity itself, with obligations scaled to its size, or it sells technology to one and inherits its contract and oversight rules. I see the second case far more often. With a bank as a customer, DORA is already in the contract or about to be.

This is an engineer's reading of the rules. I wrote it to help teams decide whether the rules touch their platform. It isn't legal advice. I recommend checking the current text with your own counsel before planning around a date or a threshold.

Does it apply to you?

If one of these lines describes your company, the rest of this guide applies. If none does, the rule probably sits outside your company. A thirty-minute call confirms that faster than the text can.

We hold a financial licence in the EU: payment institution, e-money institution, investment firm, crypto-asset service provider, insurer, or similar. That makes us a financial entity, and the regulation applies to us, scaled to our size.
We sell software, hosting, data, or managed services to a financial entity. That makes us an ICT third-party service provider, and our customer has to meet DORA's contract and register requirements through us.
Our service supports a critical or important function at the customer, such as payments, ledgers, customer onboarding, or fraud checks. The contract and exit requirements get stricter.
A financial customer asks for our sub-processors, data locations, audit or access rights, exit plans, or incident notification terms. Those are Article 30 contract clauses arriving.
We're a very large cloud or software provider to many financial entities. The European supervisory authorities can designate us as critical and oversee us directly. Startups aren't there yet, but their cloud providers are.

What it asks of your platform

ICT risk management in writing

Financial entities need a documented framework: an inventory of systems and dependencies, protection and detection, response and recovery, backup and restore policies, and learning from incidents. The board carries the responsibility. On a cloud platform, the hard part is the inventory. Without a list of what runs where and what it depends on, nothing above it holds.

Incidents classified and reported

Major ICT incidents go to the national competent authority on a timetable that technical standards set: an initial notification within hours, an intermediate report, and a final report. Classification uses criteria such as clients affected, duration, geography, and data loss. The alerting, logging, and runbook work is the same as for NIS2. That's why I treat them as one project.

Testing, including threat-led tests

Every financial entity has to test its resilience each year with vulnerability scans, scenario tests, and the like. Larger entities also face threat-led penetration testing every three years. For a supplier, that means readiness to join a customer's test. It also means fixing what the test finds on the customer's timeline.

Article 30 contracts and exit plans

Contracts with an ICT provider have to state the service levels and where the provider processes and stores data. They also cover security and incident notification duties, audit and access rights for the entity and its supervisor, subcontracting rules, and an exit strategy that keeps the function running. Financial entities keep a register of every ICT contract. For a supplier, I highly recommend a standard addendum and a data export path the team has actually run.

How I help

The engineering behind the guide. Each one starts with a map of the platform as it runs today.

Book a call

Cloud security hardening

I find the gaps in your cloud accounts, identity, network, and data, rank them by what an attacker reaches first, and close them with your team.

Fractional cloud leadership

A senior cloud lead for 10 to 20 hours a week, long before a full-time cloud team makes sense.

NIS2

What the NIS2 directive asks of a startup's cloud platform, how to tell whether a company is in scope or a supplier to one that is, and what to fix first.

EU AI Act

How the EU AI Act sorts AI systems into risk tiers, which tier your product is likely in, when the rules apply, and what they mean for the way a team builds.

GDPR

What the GDPR asks of a startup's cloud platform in engineering terms: controller or processor, the records to keep, and the controls that prove it.

EU data residency on AWS, Azure, and Google Cloud

How to keep customer data in EU regions on AWS, Azure, and Google Cloud, what still leaves, and the controls that prove it to a customer or auditor.

We are not licensed, we just sell to banks. Does DORA bind us?: Not directly, unless the authorities designate your company as critical. It binds your customer instead. The customer has to put specific terms in the contract and can only work with a supplier that meets them. In practice, that makes DORA a condition of the deal. I recommend preparing the terms once and reusing them.
Does hosting on a hyperscaler solve it?: It solves part of the supply chain question. The major clouds publish DORA addenda, and the authorities are onboarding them as critical providers. It doesn't solve the company's own inventory, incident process, testing, or exit plan. Those stay with the team.
How does DORA relate to NIS2?: DORA is the specific law for finance and takes precedence over NIS2 for financial entities. The measures overlap heavily: inventory, incident handling, backups, supply chain, testing. A platform built for DORA answers a large share of NIS2 questionnaires.
Where do you start on a DORA engagement?: With the register of information, which forces the inventory. Then a dry run of an exit: can the customer get their data and run without the supplier? Those two expose every gap the rest of the regulation cares about. How long would that dry run take on your platform today?

Let's talk.

A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?

Book a call See pricing

Prefer email or phone? hello@netninjas.eu or +31 6 45984313