What DORA Wants From Your Azure Environment, and Why Most of It Isn’t Written Down

Here’s the thing nobody in your DORA programme has said out loud yet: Microsoft is almost certainly on your Article 28 critical third-party list.

Not as a technicality. As a genuine concentration risk. If your institution runs payment processing, core banking, or customer data on Azure, you’re materially dependent on a single ICT provider in exactly the way DORA was written to address. And the documentation that follows from that dependency? The contract review, the exit strategy, the concentration-risk assessment. Most Dutch institutions haven’t produced it. Not because they’re negligent. Because every piece of DORA content they’ve read talks about policy and process, not about what the De Nederlandsche Bank supervisor will actually ask to see.

This post is about what they’ll ask to see.

Article 11 is where it starts. It requires a sound, well-documented ICT risk-management framework that reflects your Azure environment in near-real-time: a current asset register, per-workload recovery objectives, and Microsoft named as a critical third party on your Article 28 register. Most institutions have the policies. What they lack is documentation that maps to what’s actually running in the tenant.

The documentation problem no one is talking about

DORA compliance programmes at Dutch financial institutions follow a recognisable pattern. Legal reviews the regulation. Risk produces a gap analysis. IT gets a list of things to document. The result is a collection of updated policies, revised risk registers, and architecture diagrams that were current sometime last year.

None of that is the problem DORA is trying to solve.

Article 11(1) requires a “sound, comprehensive and well-documented ICT risk management framework.” Article 11(5) requires that framework to be reviewed and updated at least annually and “following major ICT-related incidents.” Article 11(6) extends the obligation to all ICT systems, including third-party arrangements.

That’s not a documentation project. It’s a continuous operational requirement. And it runs straight into a basic fact about Azure: your environment changes daily. Resource additions, configuration modifications, network topology changes, new service-principal registrations: none of these appear in the Confluence diagram someone updated eight months ago.

A risk-management framework that can’t reflect those changes in near-real-time is not the framework Article 11 describes. It’s a description of a framework that used to exist.

The ISACA State of Cybersecurity 2024 report found that 58% of financial-services organisations rated their ICT asset documentation as “partially accurate” or worse. That’s the organisations that have documentation. For Azure-dependent institutions, the gap between what’s documented and what’s running is structural. Not because the teams are careless, but because the tools they’re using (spreadsheets, Confluence pages, SharePoint docs) have no connection to the live environment.

The asset register Article 11(1)(b) demands

Article 11(1)(b) requires financial entities to “identify, classify and document all ICT-supported business functions, roles, responsibilities, information assets and ICT assets.” In plain terms: a current, accurate ICT asset register.

The word “current” is doing real work there.

Azure Resource Graph is the native way to produce one. It’s a queryable API that returns the live state of every Azure resource across all subscriptions: resource types, SKUs, locations, tags, network configuration, identity assignments, diagnostic settings, at the moment of execution. Not what was deployed six months ago. What exists now.

A risk architect at a mid-sized Dutch payment processor put it this way at a cloud security event in Amsterdam in late 2024: “We had a Confluence page with our asset inventory. When we ran a Resource Graph query for the first time, we found 340 resources that weren’t on it. Not shadow IT — just resources deployed through change management that never made it into the doc. That’s the gap you’re trying to close with DORA.”

Three properties separate a Resource Graph register from a maintained spreadsheet. It’s current by definition: the query reflects the live environment. It’s complete: Resource Graph covers every resource type, including things deployed outside normal change management. And it’s auditable: results can be timestamped and stored, creating a verifiable record of infrastructure state at a specific point in time.

The classification requirement in Article 11(1)(b) (distinguishing assets that support critical or important functions from those that don’t) comes down to tagging discipline. Resource Graph returns everything, but it can only classify what’s been tagged. Azure Policy can enforce mandatory tags on all new resources, and a remediation task can backfill existing ones where defaults apply. Without consistent tagging you get an inventory. With it, you get a classified asset register that satisfies Article 11.

A DORA-baseline query pulls the resources, resourcecontainers, advisorresources, and policyResources tables and joins them. That gives you the compliance posture of each asset alongside its current configuration. That’s the starting point for the risk classification Article 11 requires.

Continuity architecture: RTO, RPO, and tested failover

Article 12 is where DORA gets specific about backup and recovery. Article 12(1) requires “dedicated and comprehensive ICT business continuity policies and plans.” Article 12(4) requires that backup systems “can be activated without undue delay” and that “periodic testing” is conducted.

The architecture patterns that satisfy this are well understood. Knowing them isn’t the problem. Whether they’re correctly configured, and whether that configuration is documented in a form that connects to the regulatory requirement, is.

Start with recovery objectives, documented per workload. DORA doesn’t set numeric thresholds; it requires you to determine objectives appropriate to each function’s criticality. For payment processing or core banking, an RTO measured in hours won’t satisfy a supervisor. For internal collaboration tools, it might. The obligation is to have made that call per workload, recorded it, and configured infrastructure to meet it. A single RTO/RPO figure for the whole Azure environment is not DORA-compliant documentation.

Azure Site Recovery supports configurable RPO thresholds down to 30 seconds for supported VM types. Azure Backup covers VMs, SQL databases, Azure Files, and blob storage. The specific configuration of each (backup frequency, retention period, geographic redundancy, restore-testing schedule) is the technical implementation of Article 12. And it has to be documented in a way that maps back to the workloads it covers and the obligation it satisfies.

Then failover has to be tested, not assumed. An Azure Site Recovery test failover, run quarterly and documented, is your Article 12(4) evidence. If your last test failover was at initial deployment and you’ve shipped three major releases since, that evidence is stale.

And access has to be controlled during incidents. Article 11(1)(d) requires policies limiting physical and logical access to ICT assets. On Azure that’s Hub-and-Spoke topology with Azure Firewall in deny-by-default, NSGs with explicit allow rules per subnet, and Private Endpoints for PaaS services. Firewall diagnostic logs exported to a Log Analytics workspace give you the ongoing enforcement evidence. They also show an auditor exactly when your firewall is sitting in Alert mode instead of Deny mode. That’s a common misconfiguration, and a direct gap against this requirement.

The piece most Dutch institutions haven’t done: connecting these components into a documented continuity architecture that maps each one to the DORA article it satisfies. The components exist. The documentation that ties them to the obligation doesn’t.

Microsoft on your Article 28 register

Article 28 is where most DORA compliance programmes have their largest gap. And it’s specific.

Article 28(1) requires financial entities to manage ICT third-party risk as an integral part of ICT risk management. Article 28(2) requires arrangements with providers supporting critical or important functions to be documented and assessed. Article 28(8) requires a register covering all ICT third-party arrangements, maintained and updated continuously.

For any institution running material workloads on Azure, Microsoft qualifies as a critical ICT third party. This isn’t a judgment call. Article 28(3) sets out the criteria: the third party supports functions the entity considers critical or important, substitutability is low, and the institution depends significantly on the provider’s continuous availability. Run payment processing, core banking, or customer data on Azure and you meet all three with respect to Microsoft.

First, the contract review. The Microsoft Products and Services Agreement, the Data Processing Addendum, the Online Services Terms and the SLAs all need reviewing against the contractual requirements in Article 28(3)(a): description of services and where they’re provided from, sub-processor arrangements, data-processing locations, incident-notification timelines, audit rights. Most institutions signed these agreements without ever reading them against DORA. That’s the review that has to happen.

Second, the concentration-risk assessment. Article 28(3)(b) wants it documented, and it isn’t abstract. Azure West Europe has had availability incidents, including a multi-hour outage in September 2023 that hit European customers across several services at once. The question 28(3)(b) forces is blunt: if that happens again, what’s the recovery path, and is the concentration risk acceptable given the answer? The conclusion can be that it is. It just has to be written down.

Third, the exit strategy. Article 28(3)(e) requires a viable exit plan for each critical third-party arrangement. For Azure, that means judging whether workloads are portable to another cloud or back on-premises, estimating the timeline and cost, and defining what would trigger an exit. For most Azure-dependent institutions, an honest assessment lands on “technically feasible, operationally prohibitive within any realistic timeframe.” That’s an acceptable answer. DORA doesn’t demand cloud-agnosticism. It demands the assessment was made, documented, and the residual risk explicitly accepted.

The institutions without this documentation share one thing: nobody owns the Article 28 register. Legal owns contracts. IT owns infrastructure. Risk owns the risk register. Nobody owns the document that connects them in the form DORA requires.

This is the register-side companion to the DORA Article 28 post on documenting Microsoft, which walks the criticality test and the Article 30 contract review in full.

The package a supervisor asks for

For a supervisor visit, or a self-assessment before one, a DORA-compliant Azure documentation package has six parts:

• ICT asset register — built from Resource Graph queries, timestamped and tagged by criticality, refreshed continuously or on a dated cadence.
• Workload RTO/RPO matrix — the objective for each workload, the Azure services implementing it, the settings that meet it, and the last tested recovery date.
• Business continuity architecture map — each component (ASR, Azure Backup, paired-region deployment, firewall config, Private Endpoints) tied to the DORA article it satisfies.
• Article 28 register — all ICT third-party arrangements, with Microsoft documented as a critical third party: contract-review outcomes, concentration-risk assessment, exit strategy.
• Sentinel and Defender for Cloud evidence — analytic rules active, incident log, Secure Score time-series, regulatory-compliance dashboard export.
• Change and access audit trail — Azure Activity Log and Entra ID PIM audit logs across the review period.

Assembled by hand, across a real Azure environment, this package takes weeks and starts going stale the month after. Configurations change; last month’s evidence doesn’t reflect today’s tenant. Built from the environment outward (a Resource Graph read of what Azure actually contains, mapped to the article each component satisfies) it takes hours and updates itself. That’s the difference between the institutions that find DORA supervision manageable and the ones who discover, when a supervisor asks for the Article 28 register, that no one owns it and it doesn’t exist.

The short version

• Article 11(1) wants a continuous framework, not a once-a-year document. A static Confluence diagram can’t satisfy it when the tenant changes daily.
• Article 11(1)(b) wants a current, classified asset register. Azure Resource Graph reads one from the live tenant; a maintained spreadsheet drifts from day one.
• Article 12 wants per-workload RTO and RPO with tested failover. One recovery figure for the whole environment isn’t compliant documentation. See the Well-Architected reliability pillar and DORA Article 12 on Azure.
• Article 28 is the biggest gap. Microsoft is a critical ICT third party, which means a documented contract review, concentration-risk assessment and exit strategy. Usually no one owns that register.

FAQ

Is Microsoft a critical third party under DORA Article 28? For any institution running material workloads on Azure, yes. Article 28(3) sets three criteria: the provider supports critical or important functions, substitutability is low, and the institution depends on its continuous availability. Payment processing, core banking, or customer data on Azure meets all three, which is why Microsoft belongs on the Article 28 register.

What does DORA Article 11 require that a policy document does not deliver? Article 11(1) requires a framework that stays continuously accurate, and Article 11(5) requires review at least annually and after major incidents. An Azure tenant changes daily, so a framework built on static documents describes an environment that no longer exists. Article 11 needs a register tied to live state.

Does DORA require leaving Microsoft Azure for a second cloud? No. Article 28(3)(e) requires a viable exit strategy, but for most Azure-dependent institutions an honest assessment concludes that exit is technically feasible yet operationally prohibitive. That conclusion is acceptable. DORA does not mandate cloud-agnosticism. It requires the assessment to be made, documented, and the residual risk explicitly accepted.

Where does Azure Resource Graph fit in DORA documentation? Azure Resource Graph returns the live state of every resource across all subscriptions at query time, producing the current, complete, auditable asset register Article 11(1)(b) requires. With Azure Policy enforcing mandatory tags, that inventory becomes a classified register distinguishing critical functions from the rest.

So the question worth sitting with before DNB asks it: who in your organisation owns the Article 28 register today, and when did it last reflect what’s actually running in your Azure tenant?

The article-by-article mapping behind this post is what PAA does: a read of your live Azure estate against each DORA article. The question above matters whether or not you ever run it.