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 — built to support DORA work: opt-in volume encryption with key handling designed with you, audit logs with configurable retention that can be shipped to your own immutable store, tenant isolation that maps to ICT risk classification, an open-source stack that makes exit plans testable, and supplier transparency to the 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 Ænix does and does not claim — lives on the compliance evidence pages, including the DORA evidence page. Those pages are run output and reasoning, published so an assessor can check it. AENIX s.r.o. itself holds ISO/IEC 27001:2022 certification for its own ISMS.
Reading as a CISO? The CISO guide summarises what the platform does and does not provide.
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-23) Data residency for production, backup, observability and CI/CD artifacts; restores onto systems segregated from the source (Article 12(3)); key custody the financial entity can explain; and audit trails exportable in regulator-consumable formats. Major incidents are reported under Article 19. 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 contract to state whether ICT services supporting critical or important functions may be subcontracted, and on what conditions. Most entities cannot describe the chain 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 that created 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 created Cozystack and co-maintain it with maintainers from other companies — a CNCF Sandbox project, CNCF Certified Kubernetes 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.
Related case studies
Bank and financial-group work is published in anonymised form:
- Private cloud in a bank — developer self-service on the bank’s own infrastructure.
- Unified cloud portal for a financial group — one self-service portal over existing estates.
All nine published case studies are on the case studies page. Reference calls are arranged under NDA where the customer agrees.
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; EU contracts are with AENIX s.r.o. (Czech Republic). 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 — the control-level checklist
- DORA ICT requirements for cloud architecture — the long-form explainer
- 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 created Cozystack — a CNCF Sandbox project, CNCF Certified Kubernetes distribution, OpenSSF Best Practices — and co-maintains it. We run DORA-aligned platform readiness engagements and platform engineering programmes for financial-services organisations. AENIX s.r.o. holds ISO/IEC 27001:2022 certification.