DORA Article 28: Documenting Microsoft as a Critical ICT Third Party on Azure
How to register Microsoft as a critical ICT third party under DORA Article 28, run the criticality test, and review Azure contracts against Article 30. For ICT risk leads.
Marc Dekeyser |
DORA Article 28 and Microsoft: Building the Critical ICT Third-Party Register for Azure
Microsoft is on your DORA Article 28 register whether you put it there or not. The only question is what your entry says.
For a Dutch financial entity running on Azure, Article 28 wants three things: Microsoft recorded in your register of ICT third-party arrangements, a judgement on whether the services under your critical functions could be moved elsewhere, and contract terms that meet Article 30. None of it is hard to write down. Microsoft is rarely the hardest vendor to document. It’s almost always the one that matters most.
Most DORA programmes record Microsoft as a vendor. Few record it as what Article 28 actually treats it as: a third party whose services sit underneath the institution’s critical functions, carrying a criticality assessment and a concentration-risk analysis a supervisor expects to see. The register either reflects that, or it doesn’t.
This is the register-builder companion to the DORA Article 11 architecture post. Article 11 governs the ICT risk-management framework. Article 28 governs the third parties inside it. Read them together.
The register is not a vendor list
Third-party risk isn’t a procurement footnote under DORA. Article 28(1) puts it on the board. And Article 28(8) turns it into an artefact you have to keep current: a register of information on every contractual arrangement for the use of ICT services.
That register is a structured record keyed to function, to provider, and to the specific services consumed. For a financial entity on Azure, a single “Microsoft Corporation” row won’t do. You record the arrangement at the level of the services that support identified functions: Azure Kubernetes Service hosting a payments engine, Azure SQL Database holding transaction records, Microsoft Entra ID providing identity for the whole estate.
The European Supervisory Authorities published implementing technical standards specifying the register’s templates and fields. Those templates want entity identifiers (LEI codes), the function supported, the criticality rating, the data sensitivity, the storage location, and the substitutability assessment. DNB consumes a defined subset of these arrangements directly.
Running the 28(3) criticality test on Microsoft
Three factors decide it: how critical the supported function is, how substitutable the provider is, and how much you depend on the one arrangement. Microsoft fails the substitutability leg for most identity and platform services. That failure is the whole point of the exercise.
Start with the function. DORA calls a function critical or important where its disruption would materially impair your financial performance, the soundness of your services, or your authorisation conditions. Microsoft Entra ID authenticates every employee and every customer-facing application. If it’s down, nothing else authenticates. That’s critical by definition, not by debate.
Then substitutability. Could you move the function to another provider inside a tolerable window? For commodity compute, maybe. For Entra ID (the conditional-access policies, the federated trust, the dependency graph of every application wired into it) substitution is a multi-quarter programme, not a failover. Low substitutability pushes criticality up.
Then dependence. How much of the function rests on this single arrangement? An entity running identity, productivity, and core platform on one Microsoft tenancy is concentrated across three planes at once, all resting on one commercial relationship.
| Microsoft service | Function supported | Substitutability | Criticality rating |
|---|---|---|---|
| Microsoft Entra ID | Identity and access for the estate | Very low | Critical |
| Azure Kubernetes Service | Core transaction processing | Low–moderate | Critical |
| Azure SQL Database | System-of-record data | Low | Critical |
| Microsoft 365 (Exchange Online) | Internal communication | Moderate | Important |
| Azure Blob Storage | Document archive | Moderate | Important |
The register records the rating and the reasoning. A supervisor reading “Critical — low substitutability, identity dependency across all applications” understands the position. “Critical — important vendor” tells them nothing.
Checking the Microsoft contracts against Article 30
Four documents carry the terms: the Microsoft Product Terms, your Microsoft Customer Agreement (or the older MPSA), the Data Protection Addendum, and the published SLAs. Article 30 tells you what has to be in them.
Article 30(2) covers every ICT arrangement: a clear description of services, where data gets processed, service-level descriptions, and incident assistance. Article 30(3) adds the harder list for arrangements behind critical or important functions: quantitative SLA targets, notice periods and reporting duties, your right to monitor, cooperation with competent authorities, and a documented exit.
Microsoft publishes DORA-specific contractual commitments that map onto Article 30: audit and access rights, sub-processor transparency, incident assistance, termination. Your job isn’t to admire the list. It’s to confirm those commitments are incorporated into your specific agreement, note where each one lives, and record any residual gap.
The access and audit rights in 30(3) are the ones people panic about. You are not going to send an auditor into a hyperscaler’s datacentre. You don’t have to. The right is satisfied through Microsoft’s pooled-audit mechanism and third-party attestations (ISO 27001, SOC 2), and you write down which mechanism satisfies which right. Proportionate, documented, done.
The exit-strategy requirement in 30(3) is its own piece of work. See Building a DORA exit strategy for Azure for what a viable, documented plan contains.
Concentration risk is the part everyone skips
Article 28(4) makes you assess whether leaning on one provider tips into over-reliance. A single hyperscaler running your identity, your platform, and your productivity stack is the textbook case. There’s a worked example, and it’s recent.
September 2023: a cooling-system failure in Azure West Europe, the region most Dutch entities default to, degraded multiple services for hours. Estates with everything in one region, on one provider, watched systems they’d treated as independent fail together. Identity, compute, storage. They don’t fail independently when they share a region and a vendor.
Article 28(4) wants that quantified. The assessment records what share of your critical functions depends on Microsoft, what share sits in a single Azure region, and what the correlated-failure scenario looks like. The fix isn’t automatically a second cloud. Multi-cloud brings its own cost and its own new failure modes. Often the answer is multi-region inside Azure: paired regions, West Europe with North Europe, and a documented, risk-accepted position on whatever concentration is left. DNB expects to see that you assessed it. Not that you made it disappear.
What DNB expects to see
De Nederlandsche Bank supervises DORA for most Dutch financial entities and collects the reportable subset on a set schedule. What lands well is a register that’s current, machine-readable, and reconcilable against the live estate.
List Microsoft once, with no service breakdown, no criticality reasoning, no concentration analysis, and you’ve told the supervisor your third-party programme is immature. Reconcile the register against your actual subscriptions (every critical Azure SQL Database in the deployment showing up as an entry, every entry mapping to a real resource) and you’ve shown control. Reconciliation is the hard part. Azure estates drift. Resources get stood up outside the register’s knowledge, and the gap between documented and deployed is the audit’s favourite finding. See Azure configuration drift for why.
How PAA supports the Article 28 register
Platform Architecture Authority reads your Azure environment and lists what’s actually deployed (every Azure SQL Database, every AKS cluster, every Entra ID configuration) then maps each to the function it supports and the DORA articles it touches. What comes out is a reconciliation: what your register claims, against what your subscriptions contain, with the criticality and substitutability fields pre-filled for your architect to review and correct.
PAA is read-only. It doesn’t file your register, and it doesn’t replace the person who owns ICT third-party risk. It removes the manual reconciliation that makes the register go stale between annual updates. Crimson Owl Technologies built it out of roughly a thousand Azure architecture reviews, and the Article 28 reconciliation gap was present in nearly all of them.
Frequently asked questions
Is Microsoft automatically a “critical ICT third-party service provider” under DORA? No. That specific label is a Union-level designation the European Supervisory Authorities apply under Articles 31–44, and you don’t control it. It’s a different thing from Microsoft providing services that sit under your critical functions under Article 28. The first is done to you. The second you have to assess and document yourself.
Do we need separate register entries for Microsoft 365 and Azure? In practice, yes. They support different functions, hold different data, and have different substitutability, and Article 28(8) keys the register to arrangements and the functions they support. Exchange Online and a payments workload on AKS are separate entries even under one Microsoft commercial agreement.
How do we satisfy Article 30 audit rights against a hyperscaler we can’t physically audit? Through the mechanisms in the contract: pooled audits, third-party attestations like ISO 27001 and SOC 2, and the right to be told about incidents. Document which mechanism satisfies each 30(3) right. The right lives in the contract; the way you exercise it is proportionate to a hyperscaler.
How often does the register need updating? DORA says keep it current, and DNB takes the reportable subset at least annually. But a register touched once a year drifts away from a live Azure estate in weeks. Continuous reconciliation against the deployment is the defensible answer.
The short version
- Microsoft belongs in your Article 28(8) register at the service level, not as one “Microsoft Corporation” row.
- The 28(3) test is three factors (criticality, substitutability, dependence), and Microsoft fails substitutability for identity and platform.
- Check the Product Terms, Customer Agreement, DPA and SLAs against Article 30. Microsoft’s DORA commitments cover most of 30(3), but you record where.
- Concentration risk under 28(4) is the part most registers skip. West Europe, September 2023, is why it isn’t theoretical.
- The register only holds if it reconciles against the live estate. Once a year isn’t current.
The register is not a compliance artifact you produce once and file. It is the running record of where your critical functions actually live, and on Azure, most of them live with one provider. Document that plainly, assess the concentration honestly, and the register will hold under examination.
