.png){kind=logo}
DORA is in force and directly applicable across the EU — encryption that reaches data in use, exit strategies that must be more than a clause, audit rights you must be able to exercise. enclaive makes those enforceable rather than documented.
Built and operated in Germany. Trusted in EU public-sector and critical-infrastructure programs.
DORA (Regulation (EU) 2022/2554) is the EU's operational-resilience rulebook for the financial sector: banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, trading venues, fund managers and more — plus the critical ICT providers they depend on. As a regulation it applies directly, without national transposition, and it has been in force for supervised entities since January 2025.
Three features decide how hard your program is:
Registers, contracts and reporting are heavy but tractable. Three requirements are structurally hard, because they demand realities your stack can document but not deliver.
The DORA areas where enclaive adds technical enforcement, and the evidence each produces for your supervisor.
Encryption at rest, in transit and in use: workloads run in hardware-sealed environments with memory encrypted during processing.
Attestation records showing which workloads run encrypted-in-use, continuously.
Customer-held keys, cloud-agnostic baseline, deployment into your own accounts — the exit is architectural, not aspirational.
A documented, rehearsable exit path; key-custody coverage per workload.
The same protections run on hyperscalers, European clouds and on-prem, so multi-provider setups share one security baseline instead of multiplying it.
Multi-provider deployment evidence for the concentration-risk assessment.
Remote attestation makes provider trust independently verifiable — you and your supervisor can check workload integrity cryptographically, not by questionnaire.
Integrity reports any authorized party can verify, on demand.
Attested workload identity with least-privilege access; infrastructure operators — including cloud admins — technically excluded from workload data.
Access-path inventory before/after; key-release logs bound to verified identities.
Evidence packs generated from live operations: attestation status, key custody coverage, policy enforcement — on demand.
A current audit file whenever the supervisor, the tester or the board asks.
Article references are indicative pointers, not legal advice; DORA's technical standards add detail per requirement.
What enclaive does is narrower and more valuable: for the requirements above, it replaces policy-based assurance with technical enforcement, and periodic evidence-gathering with continuous proof. Your resilience program keeps its scope — but its hardest technical claims become demonstrable instead of asserted, and the management body oversees a framework standing on enforcement rather than trust.
What resilience owners ask
Does deploying enclaive make us DORA compliant?
No — and be suspicious of any vendor who says yes. DORA compliance is an organizational state: the ICT risk framework, incident processes, testing, the register and contracts alongside technical controls. enclaive makes specific technical requirements enforceable and provable; the box above states the boundary plainly.
How does this make our exit strategy real rather than theoretical?
Three properties: your keys stay in your custody (not a provider's KMS), the security baseline is cloud-agnostic (the same controls deploy on the next provider), and workloads run in your own cloud accounts. Leaving a provider becomes a migration project with a known shape — which is what a supervisor testing your exit plan wants to see, and what a paper plan can't show.
We're in scope of both DORA and NIS2. Which applies?
For financial entities DORA generally takes precedence as the sector-specific regime, though group structures can face both. The technical controls overlap heavily; the mappings differ. See the NIS2 page for the cross-sector view, and let your legal team draw the applicability line.
Does this help with threat-led penetration testing (TLPT)?
It changes what the testers find. Operator exclusion and attestation-gated keys remove entire attack paths — a red team that lands on the host still can't read sealed workloads or extract keys. And attestation records give the test report a verifiable baseline of what was running. The testing obligation itself remains yours to organize.
enclaive becomes one of our ICT third-party providers. What about Article 30?
Correct — and we're built to be an easy entry in your register: contractual provisions aligned to Art. 30 expectations, audit and access rights you can technically exercise through attestation rather than questionnaires, and an architecture where the cost of exiting us stays low by design. [PLACEHOLDER — confirm standard contract terms and Art. 30 readiness with legal before launch.]
Our cloud provider is overseen as a critical ICT provider. Doesn't that cover us?
Oversight of the provider doesn't transfer your obligations — your entity still owns its ICT risk framework, its register, its concentration analysis and its exit strategy. What technical operator exclusion adds is a way to bound the dependency: the provider's compliance status matters less when the provider can't read your workloads.
Bring your register, your gap analysis, or your exit-plan problem
Tell us where your DORA program stands — the RTS requirement still open, the concentration-risk finding, or the exit strategy your supervisor won't accept as written. We'll show you which controls close the technical gaps and what the evidence looks like.
