The Other DORA: Europe Just Turned Your Development Partner Into a Supervised Dependency

Two DORAs, and Only One of Them Is About Deployment Frequency

There is an unfortunate naming collision in engineering leadership vocabulary. One DORA is the DevOps Research and Assessment programme — deployment frequency, lead time for changes, change failure rate, time to restore. Every engineering leader has an opinion about it, and we have written about why those four metrics have stopped telling the truth in an AI-assisted delivery pipeline.

The other DORA is Regulation (EU) 2022/2554, the Digital Operational Resilience Act, which has applied to European financial entities since 17 January 2025. It has nothing to do with deployment frequency and everything to do with who you buy technology from, what your contract with them says, who they quietly subcontract to, and how fast you could leave if they failed. In 2026 it stopped being a compliance project and became an enforcement reality.

The shift is documented and specific. National competent authorities and the European Supervisory Authorities have moved from supervisory dialogue to formal compliance assessment: cross-checking regulatory filings, issuing remediation orders where gaps are found, and setting deadlines with consequences attached. Incomplete filings have drawn formal supervisory letters requiring remediation inside 60 days. The tolerance period that most institutions were quietly relying on is over.

Here is why this belongs in an engineering leader's inbox rather than a legal department's. DORA does not primarily regulate ICT providers. It regulates financial entities, and then requires them to push a defined set of obligations down through contracts into their suppliers. Which means that if you sell software development services into European banking, insurance, payments, asset management or crypto-asset services — or if you are a fintech buying those services — the regulation reaches you through a procurement document, not a statute. And it reaches you whether or not anyone on your side has read it.

The Register of Information Is a Supplier Exam, and Suppliers Are Why Firms Fail It

The most concrete artefact DORA produces is the Register of Information: a structured, machine-readable inventory of every contractual arrangement a financial entity has for ICT services. Fifteen linked tables covering provider identity and Legal Entity Identifier, the services supplied, the functions those services support, criticality classification, data processing and storage locations, contract dates and notice periods, and — the field that causes most of the damage — the full subcontracting chain with rank assignments.

National authorities collect these registers and consolidate them to the ESAs by 31 March each year. The 2026 cycle ran on national windows through February and March: Luxembourg's CSSF opened its eDesk portal on 11 February 2026 with a 31 March cut-off, Germany's BaFin ran 9–30 March, Ireland's Central Bank 2–31 March, and the reported position had to reflect the state of the world on 31 December 2025. The ESAs then ran their own quality and consistency checks in April, with power to reject a register and trigger a remediation cycle.

The failure rate on this exercise is the number worth internalising. In the ESAs' 2024 dry run, only 6.5% of approximately 1,000 participating firms passed all 116 data quality checks. Not 65%. Six and a half percent. And the failures were overwhelmingly mechanical rather than conceptual: submissions in the wrong format, free text where a controlled code was required, duplicated contract reference numbers and function identifiers, broken links between provider and service records, and — repeatedly — blank subcontractor details and missing rank assignments.

Read that last category again, because it is the one that implicates vendors directly. A financial entity cannot invent its supplier's subcontracting chain. If your development partner cannot tell you, in a structured format, which entities touch the service, where they are legally established, what their LEI is and where data is processed, then your register has a hole in it that a supervisor will find. EY's practitioners make the point bluntly: quality checks do not stop at submission, and the register is now a live supervisory dataset rather than an annual filing you forget about in April.

The practical consequence for anyone selling development services is that a request for register-grade data has become a standard part of the procurement conversation, and the ability to answer it in days rather than quarters is now a differentiator. The vendors who lose deals in 2026 are not losing them on rate cards. They are losing them because a procurement team asked for a subcontractor inventory with legal entity names and jurisdictions attached, and the answer came back as a marketing PDF.

Article 30 Turns Your Master Services Agreement Into a Supervised Document

DORA Article 30 sets out a mandatory clause list for every ICT contract a financial entity holds, and a substantially heavier one for contracts supporting what the regulation calls a critical or important function — defined in Article 3(22) as any function whose disruption would materially impair financial performance, regulatory compliance or service continuity.

The baseline list is already more prescriptive than most development agreements: a clear description of the functions and services supplied including anything subcontracted, the locations where data is processed and stored plus the conditions under which those locations may change, provisions on data accessibility, integrity and recovery, an obligation to assist during ICT incidents at no additional cost or at pre-agreed pricing, cooperation duties toward competent and resolution authorities, and termination rights with notice periods that meet supervisory expectations.

For services supporting a critical or important function, the escalation is significant: service levels with quantitative and qualitative performance targets, an obligation to implement and test business contingency plans, unrestricted audit and inspection rights for the financial entity, its external auditors and the competent authority, participation in threat-led penetration testing where the provider's systems fall in scope, and a documented exit strategy with a defined transition period.

Sit with the audit clause for a moment, because it is where the theory becomes uncomfortable. A supervisor's right to inspect flows through to your development partner's premises, systems and processes. Not a questionnaire — inspection. If your delivery model involves engineers working from unmanaged personal devices, credentials shared through chat, source code on machines nobody can inventory, or a subcontractor two countries away who has never heard of your client, that clause is unsignable in practice even if somebody signed it on paper.

The other quiet landmine is the incident assistance provision. At no additional cost or at pre-agreed pricing means the commercial negotiation about who pays for a 3am investigation has to happen at contract time, not during the incident. Development shops that price everything as time and materials and treat production emergencies as change requests discover this the first time a client's operational resilience team asks what the contractual response commitment is and the honest answer is that there isn't one.

The Subcontracting Rule That Quietly Breaks the Agency Staffing Model

On 2 July 2025 the Official Journal published Commission Delegated Regulation (EU) 2025/532, the regulatory technical standard specifying what a financial entity must determine and assess when ICT services supporting critical or important functions are subcontracted. It entered into force on 22 July 2025 and applies directly in every member state — no national transposition, no local variation.

The RTS covers due diligence and risk assessment obligations that extend down the subcontracting chain, the conditions under which such services may be subcontracted at all, and the contractual terms that must sit between the financial entity and the ICT provider to make that chain governable. Jones Day's read of it is that the effect is a uniform standard where firms previously had considerable discretion. In operational terms: prior written authorisation before a material portion of the service is subcontracted, advance notice of changes to the subcontractor stack with enough lead time for the client to assess and object, and visibility into the chain rather than into the first link only.

This is the provision that reshapes how a lot of development vendors actually staff work, and it deserves plain language. A very common agency model is to win an engagement with a named senior team, then fill the delivery roster with contractors, freelancers, partner shops in a cheaper jurisdiction, or a second-tier vendor the client will never meet. In most industries that is a quality risk. In a DORA-exposed engagement it is a regulatory defect, because each of those entities is a link in a chain the client is legally required to declare and govern — and swapping one in mid-sprint without notice is not a staffing decision any more, it is a notifiable change.

There is a second-order effect worth naming. Because the register requires jurisdiction and data-location detail at every rank, a subcontracting chain that crosses into a jurisdiction the client has not assessed creates a problem that no amount of contractual language fixes retroactively. The vendor who says yes to a request and quietly resolves the capacity question through a partner in an unassessed country has not solved a delivery problem; they have created a supervisory one, and it will surface in April when the ESAs run consistency checks against a register the client filed in March.

The vendors positioned well here are the ones with a boring answer: the people doing the work are our employees, here are their names, here is the single legal entity that employs them, here is the jurisdiction, and if that changes you will hear about it before it happens rather than after.

Concentration Risk, Nineteen Names, and the End of the Single-Vendor Default

Article 29 requires financial entities to assess concentration risk across their ICT estate: how many entities depend on the same provider, how critical the supported functions are, how substitutable the provider actually is, and whether the geography of the supply base is dangerously narrow. It is the provision that turns a procurement preference into a supervised judgement.

The teeth arrived on 18 November 2025, when the ESAs published the first list of designated critical ICT third-party providers — 19 of them, dominated by the large cloud and platform vendors including AWS, Microsoft, Google Cloud, Oracle, SAP and Deutsche Telekom. Designation moves a provider out of the national supervisory system and into direct ESA oversight: annual risk analyses, reporting obligations, on-site inspections, and Joint Examination Teams staffed jointly by the ESAs and national authorities. DLA Piper's analysis notes that operational supervision was expected to ramp through 2026 with roughly 30 dedicated supervisors, and that further designation rounds will follow.

The penalty architecture behind all of this is not decorative. Reported ranges put financial entities at risk of fines up to 2% of total annual worldwide turnover, individuals up to €1 million, and designated critical providers facing periodic penalty payments calculated as a percentage of average daily worldwide turnover for each day of continued non-compliance. Beyond the money sit the sanctions that actually change behaviour: public censure, restrictions on business activity, and prohibition of individuals from holding management functions.

For a mid-sized development partner, none of this means you will be designated critical — that regime is aimed squarely at hyperscale infrastructure. What it means is that your clients are now being asked, in writing, to justify their dependency on you. Substitutability is an explicit assessment criterion. A partner whose knowledge lives in three people's heads, whose deployment process is undocumented, and whose codebase nobody else could pick up scores badly on exactly the axis a supervisor is now looking at. Being indispensable in the wrong way has become a liability.

Your AI Coding Stack Is Now Part of the Supply Chain You Have to Declare

Here is where the regulation collides with how software is actually built in 2026. Every AI tool in your development pipeline that processes client code or data is, structurally, an ICT dependency. Model providers, coding agents, code review bots, test generation services, agent orchestration platforms, vector databases holding indexed source. Under DORA's framing, an AI vendor supporting a critical or important function is an ICT third-party service provider like any other — which means contractual arrangements, register entries, concentration assessment and an exit strategy.

Most development partners have not mapped this. The Info-Tech Research Group study published in July 2026, based on 578 responses from applications, engineering and product leaders, found 94% of developers reporting productivity gains and 83% reporting meaningful defect reduction — alongside the finding that among developers using AI at the build stage, only 37.4% describe their AI maturity as formal or better. Adoption at 94%, formal governance at 37%. That gap is precisely the space where an undeclared subprocessor lives.

The regulatory picture is about to get denser rather than simpler. The EU AI Act's high-risk obligations landed on 2 August 2026, and the two regimes overlap operationally on ICT risk, third-party risk and incident reporting without substituting for each other — each keeps its own trigger, authority and remedy. The one genuinely helpful provision is Article 9(10) of the AI Act, which explicitly permits integrating AI risk management into existing DORA ICT risk procedures rather than running two parallel governance stacks. Teams that build one register and one control set instead of two will spend materially less time on this.

The practical instruction for a development partner is unglamorous and takes about a day: enumerate every AI service that touches client code or data, record what leaves the boundary and where it is processed, record whether the vendor trains on submitted content, and hold that list where a client's third-party risk team can read it. Then keep it current, because the tool stack in an AI-assisted engineering org changes faster than any annual filing cycle anticipates. A partner who can produce that list on request is answering a question their competitors have not thought to ask themselves.

Exit Plans Have to Be Real, and Most Development Exits Are Fiction

Article 28 requires documented exit strategies for ICT arrangements, with a materially higher bar for those supporting critical or important functions: identified alternatives, transition timelines, resource estimates, data portability and migration provisions, a contractually defined transition period, and — the part that separates the compliant from the merely documented — tested procedures. The consensus among practitioners is direct: an untested exit is not a credible exit, and a desktop exercise on your most critical provider is the minimum defensible position.

Apply that standard to a typical development engagement and the picture is not flattering. Ask most companies what happens if their development partner disappears on 90 days' notice and the answer involves a repository they can access, a deployment pipeline configured with credentials nobody has audited, infrastructure provisioned under an account someone at the vendor owns, tribal knowledge that exists only in standups, and documentation last updated during the pitch. That is not an exit plan. That is a hope.

The uncomfortable follow-up is that a real exit plan has to be built during delivery, not written at the end of it. The artefacts that make transition survivable — architecture decision records explaining why things are the way they are, runbooks that a stranger can execute, infrastructure defined as code in a repository the client controls, credentials in a client-owned vault, onboarding documentation that has actually been used to onboard someone — are by-products of a particular way of working. They cannot be retrofitted in the notice period, which is exactly when everyone tries.

There is an inversion here that is worth stating explicitly, because it runs against most vendors' commercial instincts. A partner who makes themselves genuinely replaceable scores better on the assessment their client is now required to perform. Documented, transferable, exit-tested delivery is not a threat to the relationship — under Article 28 it is a precondition for being allowed to hold it. The lock-in strategy that quietly served a lot of agencies for twenty years is now a supervisory finding waiting to happen.

What to Ask Before You Sign in a DORA-Exposed Programme

If you are buying software development and your organisation is a financial entity — or you sell into one, which increasingly means the same diligence lands on you — there is a short list of questions that separates partners who have done this work from partners who will learn it on your programme.

Who exactly will do the work, and who employs them? Named engineers, single legal entity, jurisdiction stated. If the answer involves partner firms or a contractor pool, ask for the entity list and the LEI for each, and ask what the notification process is when it changes. You need this for your register whether or not anyone volunteers it.

Can you produce register-grade data on request? Provider identity, LEI, services supplied, functions supported, data processing and storage locations, subcontractor ranks. A partner who has prepared an information pack against these fields will hand it over in a day. A partner who has not will take a quarter and get it wrong, which becomes your remediation letter, not theirs.

Will you sign Article 30 clauses as they are written? Audit and inspection rights extending to competent authorities, contingency plan testing, TLPT participation where in scope, incident assistance at pre-agreed pricing, quantitative service levels. Watch specifically for attempts to dilute the audit right into a questionnaire or an annual certification.

What does exit actually look like? Ask for the transition plan, the estimated duration, who holds credentials and infrastructure ownership today, and whether any part of it has ever been rehearsed. Then ask to see the documentation a replacement team would rely on. The quality of that answer tells you more about the partner than any case study.

What AI services touch our code? The list, the data flows, the processing locations, the training posture, and the review gate applied to generated code. A partner who has never been asked this will improvise. A partner who has thought about it has a document.

Where a Dedicated Nearshore Team Changes the Economics

The shape of this problem favours a particular kind of partner, and it is worth being specific about why rather than gesturing at compliance readiness.

The first factor is structural: a dedicated team, employed by one entity, working only on your product. Every requirement above — declaring the chain, authorising subcontractors, naming who does the work, producing jurisdiction and data-location detail — is trivially satisfiable when there is no chain to declare. The complexity in DORA third-party risk comes almost entirely from opacity, and a model with no subcontracting layer removes it at the source rather than documenting around it. This is how we structure engagements at StepTo: our engineers are our employees, the client knows their names, and if the roster changes the client hears about it before it happens.

The second is that the artefacts DORA asks for are the artefacts of disciplined delivery, and they only exist if they were built in from the first sprint. Architecture decision records, runbooks a stranger can execute, infrastructure as code in a client-owned repository, credentials in a client-owned vault, onboarding documentation that has been used to onboard a real person. We treat these as delivery infrastructure rather than compliance overhead, for the straightforward reason that a team which cannot hand its work over cannot scale, rotate people, or take a holiday — and the same properties that make an engagement healthy are the ones that make an exit plan credible.

The third is jurisdiction and proximity, and this is where nearshore is genuinely different from offshore rather than just marginally closer. Serbia sits inside European working hours and inside the European regulatory conversation. When a client's third-party risk function needs a data-flow answer during a March filing window, or legal needs a contract schedule redrafted before a supervisory response is due, that is a same-morning exchange rather than a 24-hour round trip per clarification on a process measured in weeks. Our engineers already work under GDPR, already sit with clients navigating NIS2 and the Cyber Resilience Act, and are not learning the compliance environment from the outside while your deadline runs.

The fourth is the AI question, which is now inseparable from the vendor question. AI-assisted development is normal on our teams. What we insist on is that the gate sits at the merge, not at the prompt: generated code passes the same scanning and the same substantive human review on security-relevant paths, and a named engineer can explain what was merged. The AI services touching client code are inventoried, with data flows and processing locations recorded, because a client filing a register cannot declare what their supplier has not mapped.

None of this is exotic. It is what a serious engineering partnership looked like before anyone wrote it into a regulation. What DORA changed is that the informal version — trust us, we're good — stopped being sufficient, and the partners who were already working this way now have a document to point at while everyone else builds one under deadline.