What DORA covers, in engineering terms
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies to financial entities in the EU and has applied since 17 January 2025. It sets requirements for ICT risk management, incident handling and reporting, digital operational resilience testing, and the management of ICT third-party risk, including a register of information about your ICT providers. It also creates oversight of ICT providers that the European authorities designate as critical.
Which obligations apply to you, and how proportionately, depends on your entity type and size. That is a legal question. Check it with your legal or compliance adviser before you scope technical work.
The engineering question is simpler: can you show that your cloud and Kubernetes estate stays up, recovers, and can be explained to a supervisor? Most of the answer sits in six areas: supplier visibility, ICT risk controls, resilience testing, incident readiness, concentration and exit planning, and evidence. This page covers how we help with each. It is not legal advice, and we do not certify anything. See the compliance hub for the wider set of frameworks.
Where a DevOps provider appears in your third-party risk
If we have privileged access to your AWS or Azure accounts, your clusters or your pipelines, we are an ICT third-party service provider to you. Your register of information and your contract should reflect that. Do not treat “a few contractors with admin rights” as outside the framework.
What we can give your compliance team, as facts to verify rather than assurances:
- The services we perform and the systems and accounts we can reach.
- How access is granted (named identities, SSO, time-bound roles) and where it is logged.
- Where work is performed, and which tools or subcontractors touch your data or configuration.
- That we usually work inside your cloud accounts, you choose the regions, and we do not copy production data to our systems.
- Exit steps: what we hand back, what we revoke, and how fast.
We sign a data processing agreement where we may process personal data. Our standards are published on the Trust Center. You maintain the register, set the contractual terms with your legal team, and decide how important each function is.
ICT risk management in cloud and Kubernetes
Supervisors tend to look for the same engineering basics. Here is how we map them to controls and evidence.
| Requirement area | Technical control we implement | Evidence it produces |
|---|---|---|
| Access control and least privilege | SSO, short-lived roles, separate accounts or subscriptions per environment, Kubernetes RBAC with namespaces | Role and binding exports, access review records, break-glass usage logs |
| Change management | All infrastructure and manifest changes via pull request, required reviews, plan output attached | Merge history, approvals, pipeline run logs |
| Logging and monitoring | Cloud audit logs to a write-restricted account, cluster audit logs, centralised application logs | Log retention settings, sample queries, alert history |
| Encryption | Customer-managed keys where required, TLS in transit, encrypted volumes and backups | Key policies, configuration scans, drift reports |
| Backup and recovery | Policy-driven backups, cross-account or cross-region copies, scheduled restore tests | Restore test reports with timings and integrity checks |
| Vulnerability management | Image and IaC scanning in CI, patch cadence for nodes and base images | Scan reports, exception register, remediation tickets |
| Incident handling | Severity matrix, on-call routing, runbooks, timeline capture | Incident timelines, post-mortems, drill records |
| Supplier visibility | Inventory of managed services, regions, dependencies | Architecture diagrams and dependency inventory generated from code |
Most of this is delivered as code. With Terraform on AWS or Azure, the configuration is both the control and its own audit trail. On Kubernetes, admission policies, network policies and RBAC live in Git, so drift is visible and reversible. Checkov and Trivy run in the pipeline so misconfiguration is caught before merge. If you need a baseline first, a Cloud DevOps Health Check or a Kubernetes EKS Production Readiness Review produces the gap list.
Resilience testing: restores, failover and game days
A backup policy is a claim. A restore test is evidence. DORA’s testing expectations are proportionate to your entity, and some entities face advanced testing requirements. Your compliance team decides which apply. We build the technical programme underneath.
Restore tests
We schedule restores into an isolated environment, then verify the data, not just the job status. A minimal check for a Postgres restore might look like this:
# Restore latest snapshot into a scratch instance, then verify
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier restore-test-$(date +%Y%m%d) \
--db-snapshot-identifier "$LATEST_SNAPSHOT"
psql "$RESTORE_TEST_URL" -c "SELECT count(*) FROM ledger_entries;"
# Compare to the expected range, record elapsed time, then delete the instance
The record that matters is the dated result: time to restore, integrity outcome, and who reviewed it. Our automated restore testing work covers the pipeline, and the backup and disaster recovery service covers strategy and recovery objectives.
Failover and game days
Failover that has never been triggered tends not to work. We run planned drills to a second region or account, with a written scenario, a rollback plan and a named observer. Game days go further by injecting failures, such as a lost node pool, a failed dependency or an expired certificate, and watching whether alerts, runbooks and people respond. See chaos engineering and game days for the method. We do not run destructive tests in production without your written agreement.
Incident classification and reporting readiness
DORA includes classification of ICT-related incidents and reporting of major ones to the competent authority. The classification criteria, timelines and report content are set in regulatory technical standards and may be supervised nationally. Your compliance team owns the decision to classify and to notify. We do not submit regulator notifications.
What we do make ready:
- A severity classification matrix aligned with your own criteria, so engineers can raise the right flag fast.
- Alerting through Prometheus and Alertmanager, with routing that reaches a human at any hour.
- Timeline capture from the first alert, so impact, duration, affected services and root cause are recorded while they are fresh.
- A hand-off template with the technical facts your compliance team will need for a report.
The test of readiness is a drill: raise a simulated incident and measure how long it takes to produce a fact-checked technical summary. The SRE and incident response service builds the process and roles.
Concentration and exit planning
Concentration risk means too much depends on one provider, region or service. DORA expects you to assess that, and to plan exits for important providers. This is where engineering choices matter most.
Practical measures we implement:
- Infrastructure as code for everything. A rebuild from Git in a new account is the foundation of any exit plan.
- Portable data. Standard formats and engines where practical, and exports that are tested, not assumed.
- Cross-account and cross-region copies. Backups held under separate credentials, see cross-region and cross-account backup.
- Containerised workloads. Kubernetes helps portability of compute, but managed databases, queues and identity services still create lock-in that needs an honest assessment.
- Documented dependencies. A generated inventory of managed services per workload, with a note on the alternative and the effort to switch.
We do not promise zero lock-in. Using a managed service is often the right trade-off; the point is to know the cost of leaving and to have tested the first steps. We also design our own engagement to be exitable: runbooks in your repositories, no proprietary tooling in the critical path, and access we can revoke in minutes. See the Landing Zone Sprint if your account structure needs to be rebuilt to make this possible.
Logging and evidence
Auditors and supervisors ask for dated, tamper-resistant records. We configure audit logging in a separate account or subscription with write-restricted access, set retention to the period your compliance team specifies, and keep dashboards and queries that answer the usual questions. Observability and on-call setup covers the monitoring side.
We then assemble an evidence set: exports of configuration, test reports, access reviews and incident records, each with a date and an owner. Evidence collection is scheduled so it is refreshed, not rebuilt before each review. Data residency questions that overlap with GDPR are covered in GDPR and EU data residency, and the operational overlap with security directives in NIS2 technical controls.
What we do not do
- We do not interpret DORA or classify your functions as important or critical.
- We do not act as your compliance officer, DPO or risk function.
- We do not submit notifications to regulators or negotiate your contracts.
- We do not give an audit opinion or certify compliance. We hold no company-level certification.
- We do not perform regulated threat-led penetration testing; specialist testers do.
Common misunderstandings
- “Using a major cloud provider means we are covered.” Shared responsibility still leaves configuration, access, backup and exit with you.
- “Backups exist, so we are resilient.” Only restore evidence shows that.
- “Kubernetes makes us portable.” Compute, yes. Data and managed services, not automatically.
- “A consultant’s tooling is out of scope.” If it has access to your systems, it is in your third-party picture.
When to hire a specialist instead
Hire a regulatory law firm or compliance consultancy for entity classification, contract clauses, governance design and regulator engagement. Hire a specialist testing firm for threat-led penetration tests. Bring us in when those answers need to become running infrastructure, tested recovery and clean evidence. If you want continuing support, managed DevOps plans keep tests and evidence on a schedule.