For the chapter of DORA that decides most platform conversations — dependence on a single ICT provider — the Ænix platforms are about as good an answer as infrastructure gets. The engine is open-source software under Apache 2.0, it runs on your own hardware, and leaving it means moving standard Kubernetes objects and virtual machines rather than unwinding a proprietary format. An exit strategy you can rehearse beats a clause promising cooperation.
What this page is, and what it is not
This is the platform-side half. It describes what the infrastructure provides against DORA and how that was observed. The organisational half — the gap analysis, the control-level map of what your entity can demonstrate today, concentration risk mapped to the second supplier hop, exit-feasibility with time-to-exit estimates, a remediation plan — is a fixed-price engagement described on the DORA compliance page. Start there if what you need is the programme; stay here if what you need is the evidence underneath it.
On provenance. The observations below were made against Cozystack v1.6 on a reference cluster. Cozystack is the open-source, Apache 2.0, CNCF-hosted engine that Ænix creates and maintains, and the Ænix Public Cloud Platform, Private Cloud Platform and AI Platform are distributions of it. There is no separate closed build. That matters twice over here: it is why the evidence transfers, and it is the substance of the Chapter V argument below.
And what the platform cannot do is hold the obligation. DORA — Regulation (EU) 2022/2554 — has applied since 17 January 2025 and binds the categories of financial entity listed in Article 2: banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and others. ICT third-party service providers are not in scope directly; a small number are designated critical by the European Supervisory Authorities under Article 31 and placed under an EU Oversight Framework with a Lead Overseer, which is a different regime from the competent-authority supervision financial entities face.
ICT third-party risk: the part that depends on the platform
DORA devotes a whole chapter to ICT third-party risk: register of information, contractual requirements, concentration risk, exit strategies, and the right to audit. Regulators care about it because a financial entity that cannot leave a provider has no real control over its own resilience.
Three properties matter here. None is a feature you enable; each follows from how the platform is built and licensed.
The source is open, under Apache 2.0. Contractual continuity does not depend on one vendor’s survival, and the code can be audited by you or by a third party without asking permission.
It runs on your own hardware. No control plane in someone else’s account, no vendor with standing access required for the platform to function, no dependency on an external service being up. What you host, you control.
Exit is possible in practice, not only on paper. Workloads are Kubernetes objects and virtual machines in standard formats; there is no proprietary encapsulation to unwind. An exit plan you can rehearse is worth more to a regulator than a clause promising cooperation.
None of this exempts you from maintaining the register of information required by Article 28(3), from holding an exit strategy under Article 28(8), or from contracts carrying the key provisions of Article 30 of DORA — a different Article 30 from the GDPR one. It makes those documents easier to write truthfully.
One honest qualifier. If you buy support, hosting or operations from Ænix, Ænix becomes an ICT third-party service provider under Article 3(19) and belongs in your register with the function it supports. The open-source engine creates no contractual arrangement; a commercial relationship around it does.
Resilience: what the platform provides
DORA expects ICT systems to withstand and recover from disruption, and to be tested against that expectation rather than assumed to meet it.
Replicated storage, where the StorageClass asks for it. LINSTOR places volumes with DRBD replication across nodes, so a replicated volume survives the loss of a node holding one of its copies. Replication is a property of the StorageClass rather than of the platform — local, non-replicated classes exist and are the right choice for some workloads — so check which class each critical or important function actually uses. No separate storage array is required either way.
Live migration. Virtual machines move between nodes without shutdown, which turns planned maintenance from an outage into an operation.
Declared state, continuously reconciled. Machines and services are described as manifests, and the platform works to keep reality matching the description. Kill a workload directly and it comes back, because the description did not change.
Stretched clusters across locations. Multi-datacenter topologies are a normal deployment shape rather than an exotic one, which matters when your resilience requirements name geographic separation.
Be precise about what is not provided. There is no automated virtual machine failover after unplanned node loss of the kind a dedicated HA product gives you. Node health handling and restart policies exist and can be combined into a failover procedure, but that is configuration and rehearsal work, not a switch. See disaster recovery for how that is usually built out.
Backup, restore and the evidence that they work
Velero ships with the platform for scheduled backups, volume snapshots, virtual machine backups and cluster state, and backup data is encrypted in object storage by default through the kopia uploader.
Where those backups land needs a decision before an assessment, not after. Platform-managed backups default to a shared cozy-backups bucket in tenant-root, separated between tenants by object path. Article 12(3) requires that, when restoring backup data using its own systems, a financial entity uses ICT systems physically and logically segregated from the source system — and a bucket inside the cluster being protected is hard to argue as segregated from it. Article 12(2) adds that activating a backup system must not itself jeopardise the security, availability, authenticity, integrity or confidentiality of the data, and that the procedures be tested periodically. Point the BackupClass at storage outside the cluster, with its own credentials and its own key, and say so in the backup policy Article 12(1) asks you to write.
The regulation’s emphasis is not on having backups but on being able to restore. Rehearse the restore against a defined recovery time and recovery point objective, record what you actually achieved, and keep that record. A restore time you measured is evidence; an estimate is not.
Detection, logging and incident evidence
DORA requires incidents to be detected, classified and — for major ones — reported to the competent authority on a short clock. That works only if the underlying record exists.
The platform ships metrics collection, log aggregation, alerting and dashboards, and the Kubernetes API server writes an audit log under a policy you supply. Set two things deliberately:
Retention. The default on the cluster examined here is thirty days, shorter than a financial supervisor will expect for records touching critical or important functions.
The audit policy, resource by resource. Do not raise everything to full request and response capture: it writes secrets and personal data into the log and buys a GDPR problem to settle a DORA one. The GDPR page sets out why, and the CIS Benchmark page gives the workable split.
Security advisories for the engine are published openly, including assessments of vulnerabilities that turn out not to affect it. That public record is directly usable in the threat-intelligence and vulnerability-management parts of an ICT risk framework.
Testing resilience without touching production
DORA expects a programme of digital operational resilience testing under Chapter IV, and threat-led penetration testing under Article 26 for those entities their competent authority identifies as in scope for it — a designation based on risk profile and systemic importance, not a category you can read off your own balance sheet.
Two properties of the platform help the general programme. A tenant gives you an isolated place to run destructive tests against a realistic copy. And because environments are described as manifests, the environment under test can be recreated exactly, which is what makes a test result meaningful the second time.
TLPT is a different exercise, and the distinction matters: Article 26 tests run against live production systems supporting critical or important functions, so a tenant copy does not substitute for one. Where the platform is operated for you, or supports a critical or important function, the ICT third-party service providers involved are drawn into the scope of that test and have to be arranged with in advance.
The CIS Benchmark page shows one such test executed against a live cluster, together with the reasoning that turns a raw report into something an assessor can use.
What stays with you
Governance sits with the management body and cannot be delegated to a supplier: the ICT risk framework, the register of information, incident classification and reporting within the regulation’s deadlines, the digital operational resilience testing programme, contractual arrangements with providers, and the exit strategy itself.
A platform can make each of those cheaper to satisfy. It cannot hold them. Where you want help producing them, that is the DORA readiness engagement, and the free DORA compliance checklist is the short version of what it looks at.
Notes
This page describes Cozystack v1.6 — the engine the Ænix platforms are built from — as observed on a reference cluster in August 2026, and is informational. It is not legal advice, not an assessment, and not a statement that any configuration satisfies a competent authority. Regulation (EU) 2022/2554 applies to defined categories of financial entity and their critical ICT providers; whether it applies to you, and in what capacity, is a question for your own counsel.