DORA has applied since 17 January 2025. If your cloud architecture has not been independently checked against ICT third-party risk (Arts. 28-30), concentration risk (Art. 29), tested exit strategies (Art. 28(8)), and resilience testing (Arts. 24-27), the next supervisory cycle will surface the gaps you would rather find first.
Ænix runs a DORA-aligned platform readiness engagement for financial entities and the ICT third parties serving them.
Pairs with: Ænix Private Cloud Platform — DORA-aligned by design (customer-controlled keys at every layer, audit-ready logging via VictoriaLogs, multi-tenant Tenant CRD aligned with ICT risk classification, tested exit-readiness mechanics, supplier transparency to second hop). Free DORA Compliance Checklist →.
Who this is for
The measured evidence behind these controls — full CIS Kubernetes Benchmark results, Kubernetes conformance listings, and a plain statement of what Aenix does and does not claim — lives on the compliance evidence pages. Nothing there is a certification; it is the run output and the reasoning, published so an assessor can check it.
DORA applies, directly or indirectly, to almost every organization in the EU’s financial supply chain. We work most often with:
- Banks and credit institutions facing supervisor-level scrutiny on Article 28 ICT third-party arrangements.
- Insurers and reinsurers with multi-jurisdiction data flows and cross-border DR.
- Investment firms, payment institutions, and crypto-asset service providers in scope as financial entities under DORA Article 2.
- ICT third-party service providers that supply critical functions to in-scope entities — including hosting providers, SaaS vendors, and managed-service operators.
If your cloud setup supports a critical or important function under DORA, the requirements below apply substantively, not just procedurally.
What DORA requires of your cloud architecture
1. ICT third-party risk transparency (Articles 28-30) Every ICT supplier in your stack — hyperscaler, SaaS, managed service — has Article 28 obligations attached. The financial entity must map the supply chain, including sub-contractors, with documented concentration-risk position.
2. Tested exit strategies (Article 28(8)) Article 28(8) requires exit strategies for every ICT arrangement supporting a critical or important function, and requires the plans to be comprehensive, documented and adequately tested. Article 30(3)(f) puts the corresponding exit terms in the contract. An untested plan does not satisfy the article.
3. Digital operational-resilience testing (Articles 24-27) At least annual testing of ICT tools and systems for all in-scope entities (Art. 24-25), plus threat-led penetration testing at least every three years for entities identified by their competent authority (Arts. 26-27). Both run against live architecture, not against documentation.
4. Demonstrable ICT risk management (Articles 5-16) and incident reporting (Articles 17-19) Data residency at every layer — production, backup, observability, CI/CD artifacts — with keys under the financial entity’s control and audit trails exportable in regulator-consumable formats. Detection and classification must be fast enough for the reporting windows set by Delegated Regulation (EU) 2025/301.
For a control-level checklist with operational language for each of these, see the DORA compliance checklist.
Where most cloud setups fall short
Observability data quietly leaves the regulator’s perimeter The production database may be compliant. The SaaS observability stack collecting application logs probably is not. DORA Article 28 applies to the entire ICT third-party arrangement.
The exit plan exists on paper but has never been tested Article 28(8) requires the exit plan to be adequately tested, not merely written. Without a rehearsal, the stated time-to-exit is a guess.
Concentration risk is treated as a procurement question, not an architecture question Article 29 requires the entity to assess concentration at ICT-arrangement level. Contractual diversity language without architectural diversity does not answer it.
Sub-contractor risk is invisible past the first hop Article 30(2)(a) requires the financial entity to know the chain. Most do not, beyond the first hop.
How Ænix helps
Our DORA engagement is built into the Platform Readiness Assessment, with the sovereignty-and-regulator-gap workstream emphasized for DORA-specific scope. The 14- or 28-day engagement produces:
- DORA control-level map — a control-by-control table showing what you can demonstrate today, what is partially met, and where the architectural gaps are.
- Concentration-risk picture — supplier-chain mapping (to the second hop), with quantified concentration position per critical function.
- Exit-feasibility analysis — calibrated time-to-exit estimates, exit-drill scoping, and sequencing aligned with commitment expirations.
- Resilience-testing readiness — whether your architecture supports the scenario-based testing supervisors expect.
- Architecture-level remediation plan — what to fix, in what sequence, with effort estimates.
Delivered by Ænix engineers — the team behind Cozystack — not management consultants.
Why Ænix specifically
Most DORA advisory work comes from Big-4 consultancies that hand off to a hyperscaler partner whose incentives shape the recommendation.
We are different in three concrete ways:
- No hyperscaler bias. Our recommendations are not commercially tied to AWS, Azure, GCP, or any single provider. When the answer is hyperscaler-with-better-controls, we say so. When the answer is on-prem or hybrid, we say that.
- Engineers not consultants. The same Ænix engineers who run the readiness engagement build the production platforms afterwards. The implementation effort estimates in the report are calibrated against work we have actually shipped.
- Open-source platform foundation. We are the company behind Cozystack — a CNCF Project, Kubernetes Certified Distribution, OpenSSF Best Practices badge. Where a Cozystack-based architecture serves DORA’s substantive requirements better than the alternative, the report explains why with named controls.
What the engagement looks like
Day 0 is a free 30-minute discovery call that fixes the scope. Days 1-13 (or 1-27) run four parallel workstreams with the sovereignty-and-regulator-gap workstream emphasized, on daily async updates and three sponsor checkpoints. Day 14 (or 28) is a 60-90 minute executive readout against the written report — DORA control map, concentration analysis, exit-feasibility, resilience-testing readiness and remediation plan. Full day-by-day methodology: Platform Readiness Assessment.
Who’s done this with us
We have run DORA-aligned readiness engagements for banks, insurers, telecom operators, and ICT third-party service providers across the EU and DACH. Mutual NDA at kickoff; named case studies available on the discovery call where customer permissions allow.
Pricing and engagement scope
14-day (focused DORA scope)
DORA-emphasized workstream depth, single business unit / domain. Full control map, concentration analysis, exit-feasibility, remediation plan. On request
28-day (full DORA + adjacent)
DORA + adjacent NIS2 / GDPR / sectoral overlap mapping. Multi-BU stakeholder interviews. Vendor shortlisting where applicable. Phase 2 implementation roadmap. On request
Fixed-price. Single invoice. Mutual NDA at kickoff. If a Phase 2 implementation engagement follows, the assessment cost is credited against it (subject to scope).
We accept RFI / RFP through standard procurement channels in EU member states and Kazakhstan; the discovery call covers procedural fit.
Start with a 30-minute discovery call
We confirm fit, narrow the scope to the articles that actually bind you, and recommend the 14-day or 28-day variant.
Or read more:
- DORA compliance checklist for cloud architecture — the control-level guide
- Platform Readiness Assessment — the engagement that includes the DORA workstream
- Data sovereignty in 2026 — adjacent regulatory trigger
- Cozystack — the platform we typically recommend for sovereign architectures
Ænix is the company behind Cozystack — a CNCF Project, Kubernetes Certified Distribution, OpenSSF Best Practices. We run DORA-aligned platform readiness engagements and platform engineering programs for financial-services organizations across the EU and DACH.




