Designing for DORA

Most DORA compliance content is written for risk and legal teams, and reads that way — obligations, deadlines, templates. That's fine for the register of information. It's not much use when you're the engineer who has to make a live production system survive a red team, or make a vendor integration exit-able on paper actually be exit-able in code. This one's for that engineer. 

DORA has been in force since January 2025, but two of its provisions land differently than the rest of the regulation: threat-led penetration testing (TLPT) under Article 26, and ICT third-party risk management under Articles 28–30. Most of DORA is a documentation and governance exercise — policies, registers, board reporting. TLPT and third-party risk are not. They test whether your system actually behaves the way your documentation says it does, under conditions you don't control the timing of. That's an architecture problem before it's a compliance problem, and it's worth working through what these provisions actually require of the systems you build, not just the paperwork around them. 

TLPT tests your architecture, not your checklist 

TLPT, built on the TIBER-EU methodology, applies to designated entities — G-SIIs and O-SIIs, large payment institutions, major trading venues, and others your national competent authority selects — on a minimum three-year cycle. The mechanics matter more than the schedule: a threat intelligence provider profiles realistic attackers for your specific risk profile, then an accredited red team executes a covert attack against your live production systems, not a staging environment carved out for the occasion. Your SOC doesn't know it's happening. If they notice and respond, that's the point being measured. If they don't, that's also the point being measured. 

That last detail is the one worth sitting with as an architect. A test environment tells you whether your code passes a spec. A live-production, undisclosed red team engagement tells you whether your actual blast-radius containment, actual detection pipeline, and actual incident response hold up when nobody's expecting them to be tested. You can't retrofit that confidence in the eight weeks between scoping and test execution. It has to already be built in. 

A few patterns fall directly out of this: 

Bounded contexts that match your critical-function map, not your team structure. DORA requires you to classify business services as critical or important and scope TLPT around them. If your "critical function" spans a monolith that also holds unrelated batch jobs and internal tooling, your test scope — and your actual blast radius during a real incident — is the whole system by default. Domain boundaries that map to the regulatory classification of the function they support aren't just cleaner design; they're what lets you draw an honest, defensible scope line and contain a compromise to the side of it where it happened. 

Circuit breakers and bulkheads you can prove work, not just ones you've implemented. Resilience4j, service-mesh-level circuit breaking, connection pool isolation per downstream — these are common enough in banking backends. The gap is usually that nobody has verified they trip correctly under an adversarial load pattern rather than a well-behaved failure. Chaos engineering practice (fault injection in pre-production, ideally extended into shadow production traffic) is the closest thing to a dress rehearsal for what TLPT will actually probe. 

Abort criteria that are technically real, not just written in the rules of engagement. The TIBER-EU rules of engagement define conditions under which a test must stop — discovery of an unrelated live incident, system instability, a genuine zero-day. Whether that abort is executable in under a minute depends on whether you can actually revoke a credential, drop a connection pool, or isolate a service at the mesh layer on demand, rather than through a change ticket. mTLS with short-lived certificates, centralized token revocation, and network segmentation that doesn't depend on a human editing a firewall rule are what make "we can abort" true rather than aspirational. 

Detection has to be provable, and provable to a party that isn't you 

The purple-team phase at the end of a TLPT engagement compares what the red team actually did against what your SOC actually saw. This is where architecture and observability meet compliance directly: if your logging, tracing, and SIEM correlation don't produce an evidentiary trail independent of the systems under test, you can't demonstrate detection even when detection happened. 

In practice this means structured logging and distributed tracing (OpenTelemetry is the sane default in a Java stack now) that survive the compromise of any single service — logs shipped to storage the attacker's foothold can't reach or rewrite, correlation IDs that thread through service calls and through third-party API calls, and a SIEM pipeline that's genuinely decoupled from the production plane it's watching. An immutable, append-only audit trail — event-sourced through Kafka into WORM-compliant object storage is a common pattern — isn't just good practice; it's what turns "we believe we detected this" into "here is the timestamped record." 

The third-party boundary has to be a real boundary, not just a contractual one 

Article 30 requires a set of mandatory contract clauses for any vendor supporting a critical or important function: audit rights, defined SLAs, incident notification obligations, sub-outsourcing approval, and — the one with the most architectural weight — exit strategies built around a "mandatory adequate transition period." The text deliberately doesn't pin that period to a fixed number of months; what counts as adequate is judged against the complexity of the service, which means the burden of proof shifts to you to show the transition is actually executable in whatever time you've committed to. The Register of Information under Article 28 then requires you to map every one of those contracts to the ICT assets and business functions they support, kept current within thirty days of any change. 

None of that is enforceable by a legal clause alone if your codebase has quietly built the vendor's data model, API shape, and failure modes into your domain layer. The pattern that actually makes an exit clause executable is the one Java developers already know: ports and adapters. A well-defined internal interface for "core banking ledger," "payment rail," or "KYC provider," with the vendor-specific implementation living entirely behind it, is what makes a Register-of-Information exit strategy something you could actually run rather than something you'd have to write from scratch under regulatory pressure. It also means your canonical data model isn't the vendor's schema, which matters directly for the data-portability and secure-deletion obligations in the same article. 

Two more implications worth building for deliberately: 

Contract testing at the integration boundary. Tools like Pact let you pin the behavioral contract between your service and a third-party API independently of whether that provider's staging environment is available or representative. This matters more than usual under DORA because your due diligence and ongoing monitoring obligations require you to know when a provider's actual behavior drifts from what you contracted for — not just when it errors. 

Incident correlation that closes the loop with the provider, not just with your own systems. DORA's incident reporting timelines don't pause because the root cause was in a vendor's infrastructure. A webhook or API feed from critical providers into your own incident management pipeline, with SLA timers that start from provider notification, is what keeps your regulatory reporting clock accurate instead of dependent on someone manually checking a status page. 

Concentration risk is a dependency graph, not a spreadsheet 

Nineteen providers — cloud hyperscalers, core banking platforms, and market infrastructure among them — were designated as Critical ICT Third-Party Providers (CTPPs) in November 2025, putting them under direct EBA/ESMA/EIOPA oversight. If any of them sit underneath more than one of your critical functions, or underneath a sub-processor your other vendors also depend on, that's exactly the concentration risk DORA requires you to assess annually. 

The honest way to answer that question is to generate it from infrastructure, not to maintain it by memory. A live service-dependency graph — built from API gateway telemetry, infrastructure-as-code manifests, and service mesh configuration rather than reconstructed manually for an annual filing — will surface a shared sub-processor or a single-region dependency long before an audit does. For functions sitting on a CTPP-designated provider, that same graph is what tells you honestly whether you have a tested failover path to a second provider or region, or whether your resilience plan for that dependency is still theoretical. 

What this adds up to 

None of this is exotic. Bounded contexts, circuit breakers, ports and adapters, contract testing, immutable audit logs, dependency graphs generated from real infrastructure — these are patterns most senior backend engineers already reach for. What DORA changes is the cost of skipping them. A missing bulkhead used to show up as an incident postmortem; now it shows up as an unscoped TLPT finding with a named remediation owner and a board-level report attached. A tightly coupled vendor integration used to be a refactoring backlog item; now it's an exit strategy you have to prove works, on a filing deadline. 

That's the shift worth internalizing: DORA doesn't introduce new architectural principles so much as it removes the option of treating them as optional. We've built payment and core banking systems inside exactly these constraints for long enough to know where the gap between a documented control and an executable one usually shows up — and it's rarely where the compliance checklist is looking.