Does DORA apply when you outsource software development?
DORA applies to you if you are an EU financial entity, and it reaches your development vendor through the contract you sign with them. The Digital Operational Resilience Act — Regulation (EU) 2022/2554, applicable since 17 January 2025 — does not regulate software houses directly unless they are designated as critical ICT third-party providers. It regulates banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and others, and it requires them to impose specific terms on every ICT third-party arrangement they hold.
In practice that means the compliance burden lands on you as the buyer, and your vendor either signs up to the terms or does not get the work. The firms that handle this well decide early which parts of their estate are "critical or important" and treat the contract as a resilience document rather than a procurement formality.
Is custom software development a "critical or important function"?
Not automatically. The test is whether a defect or failure in the function would materially impair your financial performance, the soundness or continuity of your services, or your ability to meet regulatory conditions. A team building an internal analytics dashboard almost certainly falls outside that. A team maintaining your core payments flow, your customer-facing banking app or your KYC pipeline almost certainly falls inside it.
The distinction matters because DORA imposes a heavier contractual regime on arrangements supporting critical or important functions. Be deliberate about the classification and write down the reasoning — supervisors are more interested in whether you assessed it than in which answer you reached.
What must the contract contain?
Article 30 sets a baseline for every ICT contract and an extended set for arrangements supporting critical or important functions. The table below summarises the practical difference for a development engagement.
| Requirement | Every ICT contract | Critical or important function |
|---|---|---|
| Clear description of services and locations of delivery and data processing | Required | Required |
| Notice of material changes to where or how services are delivered | Required | Required |
| Data availability, integrity and confidentiality provisions | Required | Required |
| Assistance on ICT incidents, at no extra cost or at a pre-agreed cost | Required | Required |
| Termination rights and minimum notice periods | Required | Required |
| Full service level descriptions with precise quantitative targets | Recommended | Required |
| Unrestricted audit, access and inspection rights for you and your supervisor | Limited | Required |
| Conditions on subcontracting the function | Disclosure | Required and constrained |
| Participation in your security awareness and resilience training | Not required | Required |
| Documented exit strategy with transition assistance | Good practice | Required |
Two of these routinely stall negotiations with offshore vendors. The first is unrestricted audit and inspection rights extending to your competent authority — a vendor that has never worked with regulated European clients often resists it. The second is the subcontracting condition: if your vendor quietly subcontracts part of the delivery, or uses a sister entity in another jurisdiction, that has to be visible and controlled in the contract, not discovered later.
What is the register of information and why does it bite?
You must maintain a register of information covering all contractual arrangements for the use of ICT services, at entity, sub-consolidated and consolidated level, and provide it to your competent authority on request. It records the provider, the service, the function it supports, whether that function is critical or important, the countries where the service is delivered and where data is stored, and the subcontracting chain for critical arrangements.
The practical consequence for development outsourcing is that vague arrangements become expensive. If you cannot say which legal entity employs the engineers, which country they sit in, or which sub-processors touch your data, you cannot complete the register. Ask for those facts during procurement, not during the first supervisory request.
How does DORA change offshore delivery specifically?
It does not prohibit it. DORA is location-neutral: nothing in the regulation says development must happen inside the EU. What it does is make the offshore arrangement legible and controllable, which raises the bar on vendor maturity rather than on geography.
- Named delivery locations. "Our global delivery network" is not an answer. You need countries, entities and, for critical functions, the ability to be told before they change.
- Access controls you can evidence. Who can reach production, under what approval, with what logging. Most offshore development can be run with no production access at all, which simplifies the whole conversation.
- Incident cooperation. Your reporting deadlines under DORA are tight, so the vendor's obligation to notify and assist has to be contractual and time-bound.
- Concentration risk. If one vendor holds your core platform, your mobile app and your data pipeline, that is a concentration you have to assess and, often, deliberately break up.
Much of this overlaps with the supply-chain due diligence European buyers are already doing under other regimes; our guide to NIS2 and offshore development covers the equivalent obligations for companies outside financial services, and the evidence pack you assemble serves both.
How do exit plans work for a development team?
An exit plan for a hosting provider is a migration plan. An exit plan for a development team is a knowledge and continuity plan, and it is easier to get right if you build it in from day one rather than writing it at renewal.
The elements that actually matter: source code and infrastructure definitions in repositories you own, not the vendor's; documentation kept current as a delivery obligation rather than a project phase; at least one internal engineer who can explain every service; a named transition period with the vendor obliged to assist; and a tested ability to build and deploy without vendor-held credentials. If you ever have to use it, the sequencing we describe in switching outsourcing vendors without losing a quarter maps closely to what a supervisor expects to see documented.
What should you ask a vendor before signing?
- Which legal entity contracts with us, and which entities employ the people doing the work?
- In which countries will services be delivered and data be processed or stored?
- Will you accept audit, access and inspection rights extending to our competent authority?
- What is your subcontracting position, and will you commit to prior notification and our right to object?
- What are your incident notification timelines to us, and who is the named contact out of hours?
- Can you deliver without any access to production personal data?
- What transition assistance will you provide on termination, for how long, and at what rate?
A vendor that answers all seven crisply has done this before. A vendor that treats the questions as unusual will make your compliance function do the work instead. The same discipline pays off with data protection: our note on GDPR, IP and contracts when outsourcing to India covers the processor terms that sit alongside the DORA clauses in the same contract.
How does DORA sit alongside GDPR and outsourcing guidance you already follow?
It layers on top rather than replacing anything. If you are a regulated financial entity you were already applying outsourcing guidance from your supervisor and running processor agreements under the GDPR, and DORA adds a resilience-specific set of obligations with its own register, its own contractual minimums and its own incident reporting timetable.
The overlaps are useful, because one evidence pack can serve several purposes. The vendor's security documentation supports the GDPR Article 28 assessment, the DORA risk assessment and, if you are also in scope for network security rules, the supply-chain review. The same is true of delivery-location data: you need it for the register of information, for the transfer impact assessment and for your own concentration analysis.
Where they genuinely differ is emphasis. Data protection asks whether personal data is adequately protected. DORA asks whether your services keep running when the provider fails, and whether you could move if you had to. A vendor can be perfectly acceptable on the first question and weak on the second — for instance one that holds all your deployment knowledge and has never documented a handover. Test both, and do not assume a clean data protection review answers the resilience question.
ILMTEC works with European companies that need senior engineers inside a controlled, contractually clean delivery model — named entities, named locations, no production data access by default. See our engineering talent solution for how the arrangement is structured.
This article is general information about a regulation, not legal advice. Classification decisions and contract wording should be confirmed with your own counsel and compliance function.
