DORA-Ready in Practice: What Auditors Actually Ask of Your Virtualization Stack
DORA has applied since 17 January 2025. Most of what has been written about it is written by lawyers, for lawyers, about a regulation that operates at the contract layer. That is one half of the picture. The other half, the half that lands on the EUC architect, the platform lead, and the head of infrastructure, is operational, and it is narrower than the legal commentary suggests.
An auditor’s job is not to read your cloud strategy. It is to ask for evidence that four artefacts exist, are current, and are connected to a tested operational pattern. This post translates the regulation into those four artefacts and the technical decisions that make them defensible.
A note before you read on: I am not a lawyer, and this is not legal advice. What follows is the infrastructure view, based on what I have seen of DORA work in practice. For how the regulation applies to your firm, your legal and compliance teams have the final word.
On this page
The four artefacts the auditor will ask for
DORA’s operational requirements run across several articles. For the infrastructure team, four documents carry most of the technical evidence an auditor will ask for. They sit next to the ICT third-party risk strategy and policy that Article 28(2) requires and the pre-contract risk assessment under Article 28(4), which other teams usually own:
- The ICT register (ITS on the register of information). A structured record of all contractual arrangements on ICT services from third-party providers, with the ones supporting critical or important functions flagged.
- The exit plan. A documented strategy for leaving each ICT service that supports a critical or important function without disruption to the business.
- Exit-test evidence. Proof that the exit plan has been tested, with the outcomes recorded. DORA says exit plans “shall be sufficiently tested and reviewed periodically”; how much testing is sufficient is where the real work is.
- The sub-outsourcer map. Visibility into the provider’s own ICT supply chain, including the fourth parties supporting your provider.
Each of those has a technical reality behind it that managed VM tiers actively make harder, and that a portable virtualization layer running on bare metal makes simpler. That is the operational case for the architectural pattern from Stop Renting Their VM Layer, restated in compliance terms.
Artefact 1: The ICT register
The register is a structured list. The fields are prescribed by the regulator and include, among others, the service description, the provider, the criticality classification, the contract reference, the data location, and the ICT service supply chain, where each provider in the chain gets a rank. The format, set by Commission Implementing Regulation (EU) 2024/2956, is the easy part. The hard part is keeping it accurate.
An estate that runs across managed VM SKUs has dozens of implicit dependencies that do not show up on the contract list: the storage backend, the load balancer, the DNS zone, the identity tenant, the recovery service. Each of those is technically a provider-specific service and arguably belongs in the register. The first audit cycle is the one that surfaces how many of those an organisation has not declared.
The architectural pattern that simplifies the register is the one with fewer contractual arrangements and fewer ICT services under each. A unified virtualization layer running on bare metal moves the storage, networking and management services into your own stack, so they stop appearing as separate provider-managed ICT services. It does not make the hyperscaler disappear: the bare-metal hosts and the data centre still sit with that provider, and usually the identity tenant and DNS do too. The virtualization software vendor also becomes an ICT third-party provider in its own right, with its own entry and supply chain. The result is a shorter, more stable register, not a single line.
Artefact 2: The exit plan
The exit plan is the document that says, for each ICT service supporting a critical or important function, how the firm would move off it without disruption to their business activities, without limiting compliance with regulatory requirements and without detriment to the continuity and quality of services provided to clients, which is how DORA puts it. In practice, the plan needs to identify the destination, the dataset that has to move, the runbook for moving it, the dependencies that have to be re-established, and the test cadence.
An exit plan that relies on provider-native migration tooling is the most common failure mode. Azure Site Recovery and AWS DRS both work, and both can fail workloads back to on-premises. But they are services of the provider you are planning to leave, so an exit plan built on them inherits the provider’s availability and terms at exactly the moment you are ending the relationship. In my view they belong in the plan as one route, not as the only one.
The plan that survives audit is the one where the destination is independent of the source. A workload running on a portable virtualization stack on bare metal in one cloud can be relocated to bare metal in another cloud or on-premises, because the environment is the same. That is the technical realisation of “independent exit.” DORA does not ask you to exit without the provider: for critical or important functions it requires the contract to include “a mandatory adequate transition period” during which the provider “will continue providing the respective functions”, plus the return of your data on termination. What a portable stack buys you is how little you need that transition period to do.
Artefact 3: Exit-test evidence
A plan that has never been tested is not a plan. DORA sets no frequency: exit plans “shall be sufficiently tested and reviewed periodically”, proportionate to the firm’s size, risk profile and the complexity of its services. My working baseline is annually for a critical service, and more often for the most critical ones.
What “test” means in practice is the line that most exit programmes have not yet drawn. There are three credible interpretations, in increasing order of rigour:
- Paper exercise. The runbook is walked through with the team. The outcome is documentation. A reasonable first step, and enough for services outside the critical or important scope where you keep an exit plan voluntarily. For anything critical I would not rely on it alone.
- Partial restore. A representative subset of the workload is restored at the destination. Service is not put live; the outcome is “the system came up.” More rigorous, still incomplete.
- Full failover. The workload is moved to the destination, brought into service, and operated for an agreed window. This is the strongest evidence you can put in front of an auditor.
The egress cost line from the egress lock-in piece lives here. A full-failover exit test on an EUC estate is not a free exercise. It is a budgeted, repeatable operation, and the cost belongs in the test plan, not on a separate change request submitted in panic when the audit notice arrives.
Artefact 4: The sub-outsourcer map
DORA’s sub-outsourcing requirements (Article 30(2)(a), Article 29(2) and RTS 2025/532) extend the visibility requirement past the firm’s direct providers and into the subcontractors supporting those providers. The focus is on the subcontractors that “effectively underpin” a service supporting a critical or important function: the provider’s own ICT subcontractors, where they run, and where the data is processed. The register template already records this supply chain, so the map and the register are two views of the same data.
Microsoft’s Service Trust Portal and the AWS and GCP compliance pages carry the provider-side material, but how much subcontractor detail they hold varies by service. The contractual right to sub-outsourcer information sits in the DORA addendum or updated terms each provider offers financial-sector customers. How you get them differs per provider, from a self-service agreement portal to a request through the account team; the operational reality is that pulling that information at the level the regulator expects is a recurring exercise, not a one-off.
The pattern that simplifies the map is, again, narrowing the contract surface. Fewer provider-managed services means fewer service-specific subcontractor chains to trace. The chain under the bare metal itself stays: data centre, hardware and support subcontractors still underpin it, and the virtualization vendor adds its own. The auditor still receives a smaller map, with fewer branches to chase.
One change since DORA went live: in November 2025 the European Supervisory Authorities designated 19 critical ICT third-party providers, including AWS, Google Cloud and Microsoft. They now sit under direct EU oversight. That does not move any of the work in this post to them. Article 28(1) keeps you fully responsible for compliance, so the register, the exit plan and the map are still yours to produce. Use the list as a quick check on your criticality flags: if a designated provider supports a critical or important function and your register does not flag it, fix that first.
A sample exit-test runbook
A runbook that survives audit reads as a sequence the team has actually run, with the evidence to show it. The structure that works in practice:
- Scope. Which environment, which user population, which workloads. Critical or important functions only.
- Destination. Named, contracted, capacity verified. Identity provider failover plan attached.
- Data movement. Volumetrics from the egress piece. Tariff and route documented. Movement window scheduled.
- Service activation. Sequence of services to bring up at the destination. Dependency tree explicit.
- Validation. Synthetic transactions, user-journey tests, performance baseline.
- Run window. Duration the workload operates at the destination. In my experience, two to four weeks makes a meaningful test.
- Wind-down. Either fold into BCDR or decommission, with criteria for which path applies.
- Evidence. Logs, screenshots, performance dashboards, sign-offs. All retained for the audit cycle.
Where the technical pattern shows through
Pull the four artefacts together and a single technical theme runs through all of them: the simpler the dependency surface, the smaller every artefact gets. The ICT register has fewer entries. The exit plan has a shorter dataset. The exit-test runbook has fewer dependencies to re-establish. The sub-outsourcer map has fewer chains to follow.
The architectural decision that produces a small dependency surface is the one the Stop Renting piece described: a portable virtualization layer running on bare metal, with the storage and networking stack owned by the customer rather than the provider.
The decisions that produce a large dependency surface, building on managed VM tiers, leaning on provider-native DR, accepting proprietary storage backends, are the ones that produce thick artefacts. The auditor’s questions get harder, not because the regulation got tougher, but because there is more to ask about.
The Bottom Line
DORA is operational as much as it is contractual.
The auditor is looking for four artefacts: an ICT register, an exit plan, exit-test evidence, and a sub-outsourcer map. Each of those is a document, and behind each document is a technical reality the legal team cannot produce on its own.
DORA makes the provider’s help with your exit contractual, through a mandatory transition period, so the question is how much of your plan depends on it. Paper exercises are weak evidence for anything critical, because they never show the workload running somewhere else. For services supporting critical or important functions, registers that count only direct providers are incomplete, because the regulator’s scope reaches through to the subcontractors that underpin them.
The architectural pattern that makes the four artefacts defensible is the one that produces the smallest dependency surface: a portable virtualization layer running on bare metal, with the customer owning the operational stack rather than the provider. That decision is not a compliance posture, it is an operational pattern that happens to map cleanly onto what the regulator is asking for.
DORA has you report on new ICT arrangements to your competent authority at least once a year. The four artefacts are either current and defensible, or they are not. Start with the inventory; everything else flows from it.
If you have been through a DORA-aligned audit cycle, which of the four artefacts took the most time to close out? Drop a comment below or find me on X at @kbaggerman.
Kees Baggerman
Latest posts by Kees Baggerman (see all)
- DORA-Ready in Practice: What Auditors Actually Ask of Your Virtualization Stack - November 11, 2026
- Cloud Desktop Density: Where the Maths Breaks Down - November 5, 2026
- Egress Is the Second Lock-In: Modeling the Real Cost of Leaving Your Cloud Provider - November 4, 2026
- Stop Renting Their VM Layer: The Case for Hybrid Multicloud Infrastructure - October 28, 2026
- The Cloud Desktop CPU Lottery, AMD Edition: Which Zen Are You Actually Running On? - October 23, 2026
