Most DORA material is written for the compliance function. This is written for the people who have to change a system because of it. Each obligation below carries the article that imposes it and what it turns into in a build.

DORA is Regulation (EU) 2022/2554. It entered into force on 16 January 2023 and has applied since 17 January 2025, so the date a team is working towards has already passed.

Who it covers

DORA covers financial entities in the EU and the ICT providers they depend on. The second half is the part that surprises people. If you sell software into a European bank, the regulation reaches you through your customer's obligations: under Article 28(4) a financial entity must, before signing for an ICT service supporting a critical or important function, assess the risks including concentration, complete due diligence on you, and identify conflicts of interest. Those clauses are your sales cycle now, and a supplier with no exit documentation may be one the buyer is not permitted to contract with at all.

Since 18 November 2025 the supervisors have named the concentration directly. On that date the European Supervisory Authorities published the first list of designated critical ICT third-party providers under Article 31(9), with Amazon Web Services, Google Cloud and Microsoft among them. Every model API and hosted service in a critical path is a line in somebody's register.

The five chapters, and what each one asks of a build

DORA is usually summarised as five pillars. They are its Chapters II to VI, and four of them land directly on engineering work.

ICT risk management: know what you are running

Article 8 requires a financial entity to identify and document its ICT-supported business functions and the dependencies between them. The EBA's ICT and security risk management guidelines (EBA/GL/2019/04) already asked for this, so for most banks it is a sharpening rather than a new duty.

In a microservice estate, each service boundary is also an audit boundary: the bank has to be able to show which service processed a transaction, which version was running, and what its configuration was at the time. Distributed tracing is what makes that answerable, and it is paid for once at platform level. In a half-migrated estate the map decays first, so it has to be maintained through the parallel run.

Incident reporting: the clock starts before you understand the incident

Article 19 sets a three-stage report for a major ICT-related incident, and Commission Delegated Regulation (EU) 2025/301 puts the clocks on it:

  • an initial notification within four hours of classifying the incident as major, and no later than 24 hours from becoming aware of it;
  • an intermediate report within 72 hours of that initial notification, submitted even if nothing has changed;
  • a final report no later than one month after the intermediate report.

What used to be an internal scramble is a set of externally visible deadlines. The four-hour clock is the one that changes engineering practice, because it starts from classification, and classification depends on whether your telemetry can tell you the blast radius while the incident is still running.

Resilience testing: the programme has to leave evidence

Articles 24 to 26 require a documented digital operational resilience testing programme. For the entities in scope, Article 26(1) adds advanced testing by means of threat-led penetration testing at least every three years, and Article 26(2) requires that test to run on live production systems supporting critical or important functions. A test that passes and leaves no evidence has done half the job.

Article 26(3) reaches the supplier. Where an ICT third-party provider falls inside the scope of a threat-led penetration test, the financial entity has to secure that provider's participation, and it keeps full responsibility for compliance either way. For a vendor selling into a bank this is a procurement condition that rarely appears in the pitch: at some point somebody else's red team will be testing the thing you built.

ICT third-party risk: the chapter with the most edges

This is Chapter V, Articles 28 to 44, and it is where most of the engineering consequences sit.

  • Article 28(3) requires a register of information covering every contractual arrangement for ICT services. Each hosted dependency in a critical path is a line in it.
  • Article 28(4) puts the risk assessment, the due diligence and the conflicts check before signature, which moves them into the procurement timeline rather than the onboarding one.
  • Article 28(8) requires exit plans that are, in the regulation's own words, "comprehensive, documented" and "sufficiently tested", reviewed periodically, with alternative solutions and transition plans identified.
  • Article 29 requires a preliminary assessment of whether an arrangement reinforces concentration risk.
  • Article 30 sets out what the written contract has to contain: service descriptions, the locations where data is processed, the return of data and termination rights, with Article 30(3) adding access and audit rights and exit strategies where the service supports a critical or important function.

The word that does the work in 28(8) is "tested". An exit plan that has never been exercised does not meet the standard, however well it reads.

Information sharing

Chapter VI, Article 45, covers voluntary arrangements for exchanging cyber threat information between financial entities. We have not done work under it, so this article says nothing more about it than that it exists.

What this turns into in a system

Four things recur across the work we have actually done inside these constraints.

A dependency map the system produces about itself. Article 8 asks for the map. Maintained by hand it is wrong within a quarter. Distributed tracing, a versioned interface inventory and lineage from every data movement back to the core record produce the same map as a side effect of running the system.

Kill switches and feature flags at the level of a single feature. Anything in a critical path should be deployable and retractable on its own, so a malfunctioning component can be isolated and disabled without taking the system down. Under DORA that isolation is a resilience requirement.

A rehearsed swap path for every hosted dependency. Concentration risk is the part that tends to surprise product teams. If your core runs on a single cloud provider, or a critical payment flow depends on one SaaS vendor, that dependency has to be documented, tested and mitigated. A clean interface with a fallback and a documented swap path turns a provider change into a configuration change. Build it because you will be asked to evidence it.

An audit trail produced by normal operation. Article 30(3)(e) gives your compliance function access and audit rights where the service supports a critical or important function. If those rights ever have to be exercised as a surprise, the delivery was not transparent to begin with.

Building the layer between your channels and your core?

Our free practitioner guide sets out the orchestration-layer pattern we use for core banking integration: one middle-tier orchestrator, one wrapper per legacy system, and a build checklist.

Get the free guide

A checklist for an engineering team

  • Every ICT-supported business function is identified, with its dependencies, and the map is refreshed by the system rather than by a person (Article 8).
  • Incident classification can be done inside four hours, which means telemetry that shows blast radius during the incident (Article 19, Regulation 2025/301).
  • The resilience testing programme is documented, and TLPT is scheduled for the entities in scope (Articles 24 to 26).
  • Every hosted dependency in a critical path has a register line, a named alternative and a swap path that somebody has actually run (Articles 28(3), 28(8), 29).
  • Contracts carry service descriptions and processing locations, and for critical or important functions access and audit rights and exit strategies (Article 30(2) and (3)).
  • Any feature in a critical path can be disabled on its own.
  • The exit drill has a date in the calendar and a named owner.

Where we sit in this

WislaCode is an ICT third-party provider to regulated buyers, which means we are on the register side of these articles rather than the consulting side. WislaCode Solutions PSA is the contracting EU entity, and engineering is delivered through a documented sub-outsourcing chain in line with the EBA outsourcing guidelines and DORA.

In practice we supply the outsourcing register entry, the audit and exit clauses, and support for the exit drills your auditor will run. Where we build a payment, core or integration layer, the dependency map, the audit trail and the reconciliation evidence stay current through the work rather than being assembled before a review.

Related reading: core banking transformation, microservices architecture in banking, fintech software outsourcing, banking app trends.

Need a supplier that fits your ICT register?

WislaCode builds payment, core and integration software for regulated buyers, and supplies the outsourcing register entry, the audit and exit clauses and support for the exit drills that go with it.

Talk to our engineers
Frequently asked questions
What is DORA and when did it start applying?

DORA is Regulation (EU) 2022/2554. It entered into force on 16 January 2023 and has applied since 17 January 2025. It governs ICT risk for financial entities in the EU, including the suppliers they depend on.

Who needs to comply with DORA?

Financial entities in the EU, and through them their ICT third-party providers. The obligations sit on the buyer. They reach the supplier through the contract, the register entry and the exit plan required by Articles 28 to 30.

What are the five pillars of DORA?

They are the regulation's Chapters II to VI: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, management of ICT third-party risk, and information-sharing arrangements.

What does operational resilience mean in practice under DORA?

That a firm can keep delivering critical services through disruption and can prove it with tested plans. DORA requires an initial incident report within four hours of classifying an incident as major, exit plans that are comprehensive, documented and sufficiently tested, and a register of every ICT arrangement. A plan that has never been exercised does not meet the standard.

How does DORA affect technology procurement decisions?

It turns them into compliance decisions. Before contracting for an ICT service supporting a critical or important function, a firm must assess concentration risk under Article 29 and hold a tested exit plan under Article 28(8). Reaching go-live without a rehearsed transition route is a potential breach of a specific obligation.

Do EU regulators have specific requirements for banks using microservices?

No regulator mandates or prohibits the architecture, and the obligations apply regardless. Article 8 requires firms to identify and document ICT-supported business functions and dependencies, and Articles 28 to 30 govern third-party ICT risk. Each service boundary therefore has to be traceable, which means centralised logging and distributed tracing.

What does DORA require from a banking app's architecture?

Documented ICT dependencies, threat-led penetration testing for the entities in scope, and contractual resilience standards for every critical third-party provider. In practice that means kill switches for significant features and a clear map of concentration risk across cloud and SaaS vendors. DORA prescribes no particular technology. What it asks for is evidence that the system can fail safely.

Does a fintech company need a vendor exit plan before the engagement begins?

Yes. DORA requires a documented exit plan for each relevant ICT contract, and the PRA expects firms to estimate timing, cost and resourcing during the pre-outsourcing phase. Designing the exit before kickoff protects knowledge, code ownership and operational continuity if the relationship needs to change.

Sources