The DORA conversation at most financial-services organisations split into two halves in 2024-2025. The first half — governance, policy, ICT risk management documentation — went to legal, compliance, and CISO teams. By the time DORA went into force on 17 January 2025, most regulated entities had that documentation in reasonable shape.
The second half — making the cloud architecture demonstrably DORA-compliant when a real TLPT cycle hits — has been quieter. That silence is starting to break in 2026. Supervisor TLPT exercises are reaching architectures that were assumed compliant when DORA went live but had never been tested under realistic regulator scrutiny.
What TLPT means and why it matters now
Threat-Led Penetration Testing (TLPT) is required for significant financial entities under DORA. Every three years a structured red- team exercise is run against the live production environment by an external test provider, with the financial entity’s CSIRT / SOC treated as a real defender.
The point is not to find vulnerabilities (any pen test does that). The point is to demonstrate operational resilience under realistic attack scenarios — that the entity’s people, processes, and infrastructure can detect, respond, and recover within DORA’s expected windows.
For platform engineers, three TLPT-readiness questions matter:
- Detection on the reporting clock. DORA Articles 17-19 put an initial notification of a major ICT-related incident on a short fuse, and NIS2 Article 23 fixes a 24-hour early warning for entities in scope for both. If your detection telemetry is tuned for performance and not security, either window is fictional.
- Audit-trail completeness. DORA Article 6 requires a documented ICT risk management framework you can demonstrate to a supervisor with evidence — what controls were in place at the time of the incident. Documentation isn’t enough; running-system evidence is the bar.
- Containment and recovery. TLPT exercises injection of real- world attack patterns. The platform’s network policies, identity model, and isolation boundaries must survive realistic lateral movement and persistence attempts.
What “DORA-ready architecture” actually looks like
A defensible cloud architecture for financial services has six properties supervisors care about:
1. Detection telemetry tuned for security
Most banks we engage with have rich performance telemetry and alert-fatigued security telemetry. The alert ratio is wrong: too many performance noise alerts, not enough signal-to-noise on the security events that map to a reportable-incident trigger under DORA Articles 18-19 (and NIS2 Article 23 where both apply).
Fix patterns:
- Curated alert rules tuned to MITRE ATT&CK techniques relevant to cloud infrastructure
- Logs flowing from VictoriaLogs / VictoriaMetrics (self-hosted, in jurisdiction) to a SIEM the SOC actually monitors
- 24×7 detection coverage with documented escalation
- Alert hygiene as a recurring task
Ænix Private Cloud Platform ships VictoriaMetrics + VictoriaLogs configured for security-grade telemetry by default, plus security- focused alert rules. The customer SIEM integration is engagement work.
2. Workload identity that’s not a wide-open service account
Default Kubernetes service accounts are wide-open. For DORA-aligned architecture, every workload has an identity, every identity is narrowly scoped, every service-to-service call is authenticated and authorised.
Pattern: SPIFFE/SPIRE for workload identity, External Secrets Operator backed by customer HSM, Pod Security Standards enforced as policy. Ænix engagement covers the integration; the customer’s IdP / workforce identity remains customer-controlled.
3. Tenant CRD isolation as the structural answer to concentration risk
Article 29 assesses concentration risk on the substantive condition of resilience, not on contractual diversity. The Tenant CRD model provides namespace-level isolation per business function, per data class, per criticality tier — with per-tenant quotas, RBAC scope, observability scope, audit-trail scope.
This is not “soft multi-tenancy with hope.” Tenant CRD is a Kubernetes- native object reconciled by cozystack-controller; the running state matches the spec or the operator surfaces the drift.
4. Audit-isolated environments
Critical workloads run in tenants that are explicitly audit-isolated: separate clusters from non-production workloads, tamper-evident logging that the customer’s audit team can replay independently, no shared infrastructure between audit-relevant and audit-irrelevant workloads.
This costs more in infrastructure. The cost is the price of defensible audit evidence.
5. Exit-readiness with tested exit drills
Article 28(8) requires a tested exit plan for critical-function arrangements. Supervisors increasingly expect a partial exit drill within the past 24 months.
The Cozystack-based architecture makes exit drills mechanically simpler: workloads are standard KubeVirt VMs and Kubernetes resources. The exit destination can be “the same Kubernetes API on different hardware or provider.” Ænix’s engagement model includes a documented exit-drill playbook that customers run annually.
6. Supplier-chain transparency to second hop
Article 30(2)(a) demands visibility into the ICT supply chain at least to the second hop. For the platform vendor relationship, Ænix is on the hook — we provide an attested supplier-disclosure document that maps upstream open-source components, security disclosure channels, and operational dependencies.
Beyond the platform vendor, the customer is responsible for mapping their own supplier chain. Ænix engagements include tooling to inventory it but the inventory itself is customer-side work.
Where most financial-services cloud architectures still fall short
Four recurring patterns in our 2025-2026 assessments:
Gap 1: observability quietly leaving the regulator perimeter
The production database is in an EU region matching the regulatory mandate. The application running on top sends logs to a SaaS observability vendor whose data-processing region defaults to US. Every minute the application runs, application logs containing transaction details, customer identifiers, protected data move to non-compliant jurisdiction.
Most banks catch this only after a supervisor flag. By then, the remediation involves either replacing the SaaS vendor (multi-quarter project) or negotiating a regional data-processing arrangement (possible with some vendors, slow with others).
The Cozystack-based architectural answer: self-hosted VictoriaMetrics + VictoriaLogs running on the same infrastructure as the workloads. Eliminates the residency leak.
Gap 2: exit plan exists on paper, never tested
The exit plan was written for the supervisor; nobody has rehearsed it. Time-to-exit estimates are tabletop, not calibrated against a drill. When the supervisor asks “when did you last test the exit plan?” the answer is silence.
Fix: annual exit-drill rehearsal with documented outcome. Ænix engagement provides the playbook; the customer runs the rehearsal.
Gap 3: concentration risk treated as procurement question
“We use AWS in two regions; we have a contract clause requiring geographic diversification of our backup.” Both true. Neither addresses what Article 29 actually assesses — substantive architectural resilience against single-provider failure.
Substantive answer: workloads use platform abstractions (Kubernetes, KubeVirt, S3-compatible storage, standard relational databases) that exist on multiple substrates. The exit destination is named at the architecture level, not the legal level.
Gap 4: sub-contractor risk invisible past first hop
The contracted hyperscaler is documented. Its data-centre operators, network connectivity providers, shared platform services beneath are not. Article 30(2)(a) requires visibility to second hop.
For Cozystack-based architecture, the platform vendor (Ænix) discloses upstream component sourcing. The hardware vendor is the next hop; beyond that, customer responsibility.
The Ænix engagement model for financial services
We approach the financial-services engagement differently from other verticals, because the regulator-driver and audit-readiness drivers shape the work.
Phase 0 — Discovery and DORA scoping
Confirm regulatory scope (DORA + national overlays + sectoral rules). Confirm criticality classification of workloads. Sponsor and supervisor-engagement contacts on customer side. Engagement model (typical: Ænix runs advisory + Tier-3 SLA; customer runs production operations).
Phase 1 — Platform Readiness Assessment with DORA workstream
14- or 28-day fixed-price assessment. Control-by-control architecture review against DORA Article 6 and Articles 28-30 expectations. Output: 30-50 page report with gap analysis, prioritised remediation, timing.
Phase 2 — Pilot deployment of Private Cloud Platform
3-6 months. Defined slice of critical-function workloads migrated to Cozystack-based Private Cloud Platform. Supervisor evidence catalogue partially built. TLPT-readiness validated against the pilot scope.
Phase 3 — Full Private Cloud Platform build
12-30 months depending on workload scope, multi-DC structure, TLPT cycle. Production-grade deployment with full compliance documentation deliverables. Ænix participates in TLPT preparation; the test itself is run by accredited red-team providers.
Phase 4 — Managed retainer
Ænix advisory + Tier-3 under SLA. No kubectl access to customer production cluster — operates via GitOps PR review only. Critical for bank governance.
When this engagement model fits
Strong fit:
- Tier-1 or tier-2 European bank with active DORA programme
- Insurance carrier with multi-jurisdictional regulatory exposure
- Payment institution under DORA + PSD2/PSD3 overlap
- Market infrastructure (CSDs, CCPs) under DORA + CSDR
- Existing TLPT cycle that needs architecture readiness work
Marginal fit:
- Smaller banks where the budget envelope for a multi-year programme isn’t yet sized for it; Public Cloud Platform with sovereignty-focused architecture may bridge
Poor fit:
- Banks that have already committed to a multi-year hyperscaler programme and aren’t reopening that decision — Ænix can advise on specific DORA architecture gaps within the hyperscaler context, but the full Private Cloud Platform isn’t a fit
Where to dig deeper
- Financial-services industry page — the trigger-led commercial landing
- DORA compliance services — buyer-trigger DORA landing
- Private Cloud Platform product page — the product for regulated enterprises
- A DORA compliance checklist for cloud infrastructure — architecture-level DORA walkthrough
- DORA compliance evidence checklist — what demonstrable means in practice
- Private Cloud Platform — DORA and NIS2 obligations mapped to architecture — product-level architectural detail
- DORA compliance checklist resource — downloadable controls checklist
Test yourself: TLPT readiness for financial services
5 questions · ~2 min