DORA Compliance Without Concentrating Your Risk: The Self-Hosted Case

The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — has applied since 17 January 2025, and the supervisory posture is now visible in a way the drafting period never was. In November 2025 the European Supervisory Authorities published the first list of designated Critical ICT Third-Party Providers: roughly nineteen names, including AWS, Microsoft, Google Cloud, and IBM. In early 2026 entities submitted their Registers of Information against a 31 December reference date. What was an abstract compliance programme in 2024 is now a supervised, annually-recurring obligation with named providers under direct EU oversight.

That sequence makes DORA's actual subject legible. The regulation was not written because financial firms were careless with their own data centres. It was written because the sector's critical ICT had consolidated into a small number of external providers whose simultaneous failure would be a systemic event — and because supervisors had no line of sight into, or authority over, those providers. DORA's answer was to take that authority: designate the critical ones, supervise them directly, and require every financial entity to prove it can survive their bad day.

Which produces the contradiction this article is about. A large share of DORA programmes are being executed by moving more of the estate into a provider now designated critical, reasoning that a supervised provider is a compliant one. That is backwards: designation says a provider has become systemically important — a hazard flag, not a certification. What follows walks the five pillars in order, maps each to controls you can operate and evidence, and makes the structural argument: almost every DORA obligation is a demand for evidence, and evidence is a property of systems you control.

The Five Pillars, and What Each One Actually Demands

DORA's structure is five pillars: ICT risk management (Articles 5–16), ICT incident management and reporting (17–23), digital operational resilience testing (24–27), ICT third-party risk management (28–30), and information-sharing arrangements (Article 45). Scope is broad — banks, insurers, investment firms, payment institutions, crypto-asset service providers — and it reaches through to providers: if you supply ICT services to an EU-regulated financial entity, DORA's third-party provisions land in your contracts regardless of where you are headquartered.

Read the five pillars not as policy chapters but as five evidence obligations. Each terminates in an artifact carrying a date, a measured number, or a signature. The compliance question then stops being "do we have a policy" and becomes "which system produces this artifact, and do we operate it?"

Click to zoom

Pillar 1: ICT Risk Management as a Testable Property

Articles 5–16 require a documented ICT risk-management framework: identified assets and dependencies, protection and prevention, detection, response and recovery, and a governance line terminating at the management body. Most of this is unremarkable to a competent platform team. What separates a real framework from a binder is the requirement that the asset and dependency inventory be complete and current — including the ICT functions supporting critical or important functions, and their upstream dependencies.

On self-hosted infrastructure that inventory is derivable rather than declared, which is the whole difference: "what runs, on what, with what privileges" becomes a query rather than an interview. A Talos-style immutable node OS removes the undocumented host drift that makes inventories go stale. Policy as code with Kyverno turns a control statement into an admission decision plus a machine-readable policy report — a control that enforces and evidences itself in one action. SPIFFE/SPIRE workload identity replaces long-lived shared credentials with short-lived attested ones, which is what Article 9 reaches for when it asks for strong authentication and least privilege between components.

Article 9 also requires protection of data at rest and in transit commensurate with criticality. Self-hosted, that decomposes into checkable settings: etcd encryption behind a KMS provider rather than base64-in-a-database, mutual TLS with automated rotation from an internal certificate authority you operate, and dynamic short-lived credentials instead of distributed static ones. Each is auditable by reading configuration you own — cheaper than reconstructing a provider's shared-responsibility boundary from a compliance portal.

Pillar 2: The Incident Clock Runs Whether or Not You Can See

Articles 17–23 impose the obligation with the least tolerance for improvisation. Once an incident is classified as major, the entity must submit an initial notification to its competent authority within 4 hours of that classification and no later than 24 hours from becoming aware of the incident; an intermediate report within 72 hours of the initial notification; and a final report within one month of the intermediate. The classification criteria come from the ESAs' regulatory technical standards: clients and counterparties affected, data losses, service downtime, economic impact, geographical spread, and criticality of the services affected.

Read as engineering requirements rather than reporting requirements, those deadlines get demanding. The four-hour clock starts at classification — but classification itself requires you to already know which clients are affected, how much data is at risk, and which critical functions are degraded. That is not a form. That is a service dependency map, criticality tiering decided in advance, and a telemetry pipeline that answers impact questions under pressure.

Click to zoom

This is where custody of telemetry stops being an architectural preference and becomes a deadline risk. If your logs and metrics live in a provider's tenancy under a retention policy you did not set, reconstructing a timeline means a request to someone whose support SLA is not bound by your four-hour clock. If they live in an observability stack you operate, writing to object storage with object-lock retention under your keys, the timeline is a query. The same logic drives CERT-In's six-hour window and 180-day retention in India: short regulatory clocks are requirements on where your evidence lives.

Two details are unfixable during an incident, so get them right early. First, clock discipline: a timeline assembled from hosts with drifting clocks is not evidence, it is a narrative — enforce NTP estate-wide and monitor offset as a first-class signal. Second, log integrity: a supervisor asking whether an audit trail could have been altered wants a structural answer, not an assurance. Object-lock retention plus append-only write paths gives one.

# S3-compatible object lock on the bucket receiving the log pipeline's
# output. Retention exceeds the DORA final-report horizon with margin.
apiVersion: v1
kind: ConfigMap
metadata:
  name: evidence-retention-policy
  namespace: observability
data:
  bucket: incident-evidence
  objectLockMode: GOVERNANCE      # COMPLIANCE if no one may shorten it
  retainDays: "400"               # > 1 month final report + audit tail
  versioning: Enabled             # overwrite creates a version, not a loss
---
# Verify, do not trust:
#   mc retention info myminio/incident-evidence
#   mc ls --versions myminio/incident-evidence/2026/07/
# A control you have not queried this quarter is not a control.

Pillar 3: Testing, Including Live Fire Against Production

Articles 24–27 require a resilience testing programme — and for entities identified against the ESAs' criteria, threat-led penetration testing at least every three years. TLPT is the advanced tier, aligned to the Eurosystem's TIBER-EU framework, updated in February 2025 to match DORA's regulatory technical standards. It runs against live production systems, driven by real threat intelligence about how adversaries target the financial sector, with a scope that may extend to critical ICT infrastructure operated by third parties.

Two structural problems appear immediately when critical functions run on someone else's infrastructure. First, permission: testing production you do not own needs the provider's cooperation, bounded by rules of engagement written for their whole customer base, not your threat scenario. Second, scope truncation: the most interesting attack paths run through the control plane, the identity layer, and the supply chain. If those belong to a provider, the honest scope of your test stops at a boundary you cannot cross — and the report says so.

The routine testing tier holds most of the ongoing value, and it is within reach of any team that owns its platform. Scheduled restore drills convert a backup strategy into a measured RPO and RTO with a date attached — the difference between disaster recovery you can prove and a green dashboard. Fault injection with LitmusChaos or Chaos Mesh yields scenario-based evidence with experiment identifiers you can correlate against traces — precisely the artifact Article 25 asks for. Neither requires anyone's permission when the substrate is yours.

Pillar 4: The Register, the Contract, and the Exit

Articles 28–30 are DORA's centre of gravity and the reason it exists. Article 28 requires a complete Register of Information covering every ICT third-party arrangement, submitted to competent authorities annually. Article 29 requires an explicit assessment of ICT concentration risk before a new arrangement — single-provider and, notably, sector-wide. Article 30 specifies the contract: service levels, data processing and storage locations, unrestricted access, inspection and audit rights for the entity and the competent authority, incident notification, continuity guarantees, sub-outsourcing conditions, termination rights, and — most often skipped — exit strategies with a transition period during which the provider keeps delivering while you migrate or bring the function in-house.

Notice the shape of that list. Nearly every clause reconstructs contractually a property that self-operation gives you structurally. Audit rights recreate the ability to look at the system. Data-location clauses recreate knowing where the data is. Incident notification recreates seeing your own incidents. Continuity guarantees recreate controlling your own availability. Exit provisions recreate the ability to leave. Article 30 is a precise description of what you lose when someone else runs your critical ICT — written as a list of things you must buy back with lawyers.

The Register is a useful forcing function regardless of architecture. Compiling it honestly surfaces arrangements nobody had classified as ICT — the observability SaaS holding production telemetry, the CI provider with deploy credentials, the managed registry in the release path. Each is a dependency in the critical path, which is where signed artifacts, SBOMs and SLSA provenance stop being hygiene and become third-party risk controls with a register entry behind them.

Concentration Risk: Why the Obvious Answer Is Self-Defeating

Here is the argument in full. DORA exists because ICT concentration in finance reached a level supervisors judged systemic. Article 29 makes assessing that concentration a per-arrangement obligation, and the oversight framework supervises the most significant providers directly — the November 2025 list being essentially the largest hyperscalers plus some market-data and outsourcing firms. An entity responding to DORA by consolidating further into a designated provider has increased the exposure Article 29 asks it to reduce, while acquiring a compliance narrative that says the opposite.

The counter-argument deserves stating: a designated CTPP is under direct EU supervisory oversight, a genuine improvement over an unsupervised one. But oversight of a provider is not resilience for you. Supervision reduces the probability that the provider is negligent; it does nothing about your correlation with every other entity depending on that same provider — and correlation is what turns a provider outage into a sector event. An entity running its critical function on infrastructure it operates is, by construction, uncorrelated with that failure mode.

A jurisdictional dimension compounds it. The Schrems II line of cases and the challenges to the EU-US Data Privacy Framework mean a provider's exposure to foreign access demands is a live variable, not a settled one. DORA does not regulate that directly, but Article 30's data-location and audit clauses sit uneasily beside a provider subject to extraterritorial process. Whether a sovereign cloud offering resolves that or merely relabels it is a decision worth making explicitly rather than inheriting from a procurement default.

None of this argues for maximalism. Self-hosting every workload is not the conclusion; deliberate placement is. What belongs on infrastructure you operate are the workloads supporting critical or important functions as DORA defines them — the ones whose failure you must survive, test against, and report on within four hours. For the rest, a provider arrangement with a real Article 30 contract is a rational answer.

The Exit Ramp Is an Article, Not a Philosophy

Optionality is usually argued commercially — leverage in renewals, protection against price changes. Under DORA it is a legal obligation with a named article. Article 30 requires exit strategies and transition periods, and supervisors infer from the documentation whether an entity could actually execute one. An exit plan never rehearsed is a document about a capability, not a capability — exactly the distinction DORA's testing pillar exists to police.

The engineering test is simple to state and uncomfortable to run: pick a critical ICT dependency and measure how long it takes to stand the function up elsewhere with data intact. The measurement is the deliverable. Most of the difficulty is not compute — it is data gravity, proprietary control-plane semantics, and identity. Exit-readiness is therefore won years early, through choices that look like ordinary architecture: portable formats and open protocols, a state layer that runs anywhere, an identity plane you can carry with you. Teams that have done a structured repatriation already hold the numbers Article 30 asks for; teams that have not are estimating.

# Exit rehearsal for one critical function. Output: a duration and a
# data-integrity verdict, both dated. File with the Register entry.

START=$(date -u +%s)

# 1. Stand the function up on the alternative substrate, from source of truth.
kubectl --context standby apply -k platform/overlays/standby

# 2. Rehydrate state from the object store you control.
velero --kubecontext standby restore create exit-rehearsal-2026-07 \
  --from-backup ledger-daily-20260728 --wait

# 3. Integrity gate — row counts and checksums, NOT pod readiness.
./scripts/verify-ledger-integrity.sh --context standby || echo 'FAILED GATE'

END=$(date -u +%s)
echo "measured cutover: $(( (END - START) / 60 )) minutes"
# Record the result whether or not it met target — the failed rehearsal
# is the one that improves the architecture.

What Owning the Substrate Does Not Buy You

Intellectual honesty requires the other column. Self-hosting discharges several DORA obligations structurally and creates others. Article 5's governance requirements do not soften because you run your own hardware — the management body still carries final responsibility, and a platform team without a documented reporting line into it fails the same finding a cloud-based one would. Physical and environmental controls a provider absorbs become yours: power, cooling, access control, and facility resilience now sit in your risk framework.

Capability concentration is the honest counterweight to provider concentration. An estate only three engineers understand is a resilience risk with a human failure mode, and supervisors ask about it. The mitigation is not headcount but the discipline the framework demands elsewhere: documented runbooks, rehearsed procedures, drills run by someone other than the system's author. If your restore drill only works when its author is available, you have measured that author, not the system.

Nor does self-hosting eliminate third-party risk; it relocates and shrinks it. You still depend on hardware vendors, upstream projects, connectivity, and a facility. The difference is substitutability: a hardware vendor is replaceable within a procurement cycle, an upstream project can be forked and audited in the open, a facility exited on contract terms. A deeply integrated managed control plane with proprietary semantics is none of these. Risk you can substitute is a different class from risk you can only escalate about — and Article 29 is a question about which class you hold.

The Long Game: Resilience as a Standing Property

The most useful reframe is that a DORA programme is not a project. TLPT recurs at least every three years, the Register is submitted annually, resilience testing runs on a standing schedule, and the incident clock is live daily. Treat DORA as a remediation project and you re-run it indefinitely, because the artifacts expire. Build evidence generation into the platform — policy reports from admission control, restore metrics from scheduled drills, timelines assembled from logs already under object lock — and the annual submission becomes mostly an export.

That is also the honest commercial case, and not the one usually made. Self-hosting does not always cost less line-by-line. What it changes is the cost curve of proof: on owned infrastructure the marginal cost of the next piece of DORA evidence approaches the cost of a query. Outsourced, it includes contract negotiation, provider cooperation, and attestations you accept rather than verify. Across a regulation still generating obligations in 2035, those curves diverge sharply.

Read plainly, DORA is a regulation about who can answer questions about your systems. Every pillar reduces to it: can you inventory what you run, see and time your own incidents, test your own recovery, leave your own providers. Answering yes to all four is what engineering sovereignty means in practice — and why the regulation and the architecture point the same direction, once you read DORA as an evidence specification rather than a procurement checklist.