The DORA gap analysis landed in April. Forty pages, a RAG-coloured table per article. The datacentre got six pages, the core banking platform nine, the hyperscaler contract an annex of its own. Microsoft 365 got one row: "SaaS productivity suite, vendor-managed, covered by Microsoft's contractual commitments." Green.
Then the supervisory visit came, and the first three requests were an inventory of ICT assets with their third-party dependencies, the policy limiting logical access to approved functions plus evidence it's applied, and the record of ICT-related incidents for the year. The answers weren't in the annex. They were in Entra ID, in a SharePoint tenant carrying eleven years of permissions, and in an app-registration blade nobody had opened since the migration.
Financial entities read Regulation (EU) 2022/2554 as an infrastructure regulation because its vocabulary sounds like racks and contracts. For a mid-sized bank or insurer, though, the ICT assets, the identities and most third-party dependencies live in one tenant. DORA has applied since 17 January 2025 and hasn't been amended, so the text quoted below is the text your auditor is holding.
One clause first, because it reframes the rest. Article 9(4)(d) doesn't just ask for encryption. It asks for "protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes." In Microsoft 365, the approved data classification is your sensitivity label taxonomy, and "encrypted based on" it means the encrypting labels have to actually sit on the files the classification calls sensitive. So the share of sensitive files carrying an encrypting label is a DORA number. Most teams file label coverage under Purview housekeeping; the Regulation files it under Article 9.
Articles 5 and 6: who owns this, and is it written down
Article 5(2): "The management body of the financial entity shall define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework." The board, not the CISO.
Article 6(1) wants "a sound, comprehensive and well-documented ICT risk management framework", 6(5) says it's "documented and reviewed at least once a year", and 6(8) wants a strategy with "key performance indicators and key risk metrics."
The tenant test: the framework names Microsoft 365 as an ICT system in scope, says who owns it, and carries metrics for access, sharing and third-party consent, not only availability.
Article 8: the inventory you don't have
Microsoft 365 creates ICT assets faster than anyone registers them, which is why this article breaks tenants.
Article 8(1): "identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk." Article 8(4) extends it to assets "including those on remote sites, network resources and hardware equipment" and asks you to "map the configuration" and interdependencies of those assets; 8(6) wants the inventories kept up to date. And 8(5), the one gap analyses skip: "identify and document all processes that are dependent on ICT third-party service providers, and shall identify interconnections with ICT third-party service providers."
Read against the definitions, that covers more than servers. An ICT third-party service provider under Article 3(19) and 3(21) is any undertaking providing digital and data services through ICT systems on an ongoing basis, so a SaaS app holding Microsoft Graph consent is one, whether or not procurement saw it. A Copilot Studio agent reading a SharePoint library is an ICT asset with a configuration, and an unmanaged laptop with a cached mailbox is hardware on a remote site.
So the inventory an auditor will accept has three lists most financial entities have never produced: every application with an OAuth consent and what it can reach, every AI agent with an owner and its configuration, and every device signing in and whether it's managed. The OAuth apps audit walks through the first one; DORA makes it mandatory.
Article 8(7) attaches a gate: a specific ICT risk assessment "before and after connecting technologies, applications or systems." Every admin consent to a new app is a connection of an application. If nobody wrote an assessment before clicking accept, that's an 8(7) finding, found by sorting enterprise applications by creation date.
Article 9: protection, in the words the Regulation uses
Article 9(1): "continuously monitor and control the security and functioning of ICT systems and tools." Article 9(2) wants "high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit", and 9(3)(a) asks you to "ensure the security of the means of transfer of data." In a tenant, the means of transfer are sharing links, guest access and external domains, so a sensitive file open to anyone with the link is a 9(3)(a) problem before it's anything else.
Then 9(4), where the letters matter because people cite the wrong one.
9(4)(a): "develop and document an information security policy." A document, and the auditor checks it mentions the tenant specifically.
9(4)(c): "limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only", with "policies, procedures and controls that address access rights and ensure a sound administration thereof." This is the access-rights point, routinely confused with MFA. In tenant terms it's three populations: enabled accounts that haven't signed in for months, devices that sign in unmanaged, and applications whose consented permissions exceed what the process needs. "Sound administration" means someone reviews them on a cadence and can show the review.
9(4)(d): "policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems", plus the classification-based encryption quoted at the top. The dedicated control system for strong authentication in Microsoft 365 is Conditional Access, and the evidence is the share of sign-ins a policy actually evaluated, which the sign-in log carries per event (how coverage is measured). Licensing footnote: Conditional Access and its sign-in detail need Entra ID P1, and manual sensitivity labels need Business Premium or Office 365 E3 and up. A Business Basic tenant can't evidence 9(4)(d) from tenant data at all, and the framework should say so.
Article 10: would you notice
Article 10(1): "mechanisms to promptly detect anomalous activities." Article 10(2): "define alert thresholds and criteria to trigger and initiate ICT-related incident response processes, including automatic alert mechanisms." Article 10(3): "monitor user activity, the occurrence of ICT anomalies and ICT-related incidents, in particular cyber-attacks."
Three things an auditor can test rather than read. Is the unified audit log ingested continuously, without gaps? Are thresholds written with numbers (mass download, consent to a new app, a credential added to an existing app), each naming its response? And does "user activity" include service principals and agents? 10(3) doesn't exempt them.
Articles 17 to 19: the incident record, and the word "all"
Second fact worth forwarding. Article 17(2) says entities "shall record all ICT-related incidents and significant cyber threats", with procedures "to ensure that root causes are identified, documented and addressed." All of them. Only the reporting duty in Article 19 is limited to major incidents, and Article 3(8) defines an incident widely: an unplanned event that compromises security and has "an adverse impact on the availability, authenticity, integrity or confidentiality of data."
A phished account that forwarded mail for a day meets that definition; so does an over-consented app that read a mailbox. If your register has eleven entries for the year, all outages, an auditor who has seen your sign-in risk detections will ask where the rest went.
Article 17(3) wants "early warning indicators" and the duty to "identify, track, log, categorise and classify" incidents by the Article 18(1) criteria: clients affected, duration, geographical spread, "the data losses that the ICT-related incident entails", criticality of services and economic impact. For a tenant incident, data losses means knowing what the compromised identity or app could reach and touched. A password reset proves nothing about that.
Article 19(1) requires reporting major incidents to the competent authority, and 19(4) shapes it: "(a) an initial notification; (b) an intermediate report ...; (c) a final report, when the root cause analysis has been completed." Article 19(3) adds informing clients. One caution: the hours-and-days clocks for those reports aren't in Article 19; they sit in the technical standards adopted under Article 20. Cite them as Article 19 and an auditor who knows the text will mark it.
Article 28: what the consent list does and doesn't prove
Article 28(1): manage ICT third-party risk "as an integral component of ICT risk within their ICT risk management framework." Article 28(2): "adopt, and regularly review, a strategy on ICT third-party risk."
The October 2026 ConnectWise case shows 8(5) and 28(1) meeting inside a tenant. Huntress reported on 16 October that a Microsoft 365 credential belonging to ConnectWise Cloud Backup (formerly SkyKick) had been compromised and used to obtain Microsoft Graph tokens in customer tenants with the application's existing permissions. App-only access: no user signed in, no MFA prompt fired. Huntress counted unauthorised sign-ins in 162 tenants by 19:00 UTC that day. In roughly fifty tenants it monitored, the vendor's service principals assigned themselves directory roles, mostly Exchange Administrator; in one, an app added itself to Global Administrator and then added client secrets expiring in 2028 to two other applications. Huntress warned that disabling the apps "will not remove credentials that were already added." That vendor is the dependency 8(5) wants documented, and credential changes on your own applications are the interconnection you're meant to be watching.
Now the limit, and the third fact. Article 28(3) requires "a register of information in relation to all contractual arrangements on the use of ICT services." That register is about contracts: who the provider is, which functions it supports, what was signed. An inventory of consented applications doesn't satisfy it, because the tenant doesn't know what you signed; what it does is show which providers belong in the register and aren't there. In practice the two lists disagree both ways: apps with consent and no contract, and contracts with no app. Both deltas are findings. The contractual duties in 28(4) to 28(8) are legal work; the tenant's job is to keep the list of counterparties honest.
The retention number DORA doesn't give you
People ask how long DORA says to keep logs and expect "five years." The Regulation contains no such number: 17(2) is about recording incidents, 11(8) about records during a disruption, and neither sets a log retention period. The detailed logging rules sit in the technical standards on the ICT risk-management framework, Delegated Regulation (EU) 2024/1774, where the period is a decision your framework makes and justifies.
That matters because the platform's own retention is shorter than most incident timelines: Audit (Standard) keeps 180 days, one year needs Audit (Premium). If your framework says incidents are investigated back twelve months and the tenant can answer for six, it describes a capability you don't have, and the 6(5) yearly review is where that surfaces. Write the period down, keep the logs somewhere that honours it, and check the ingestion hasn't stopped.
Pulling it together
Mapped onto tenant facts, DORA comes down to a short list: application consent and reach, agent inventory with owners, dormant enabled accounts, unmanaged devices, Conditional Access coverage, label coverage on sensitive files, audit-log freshness and depth, plus four documents (framework, information security policy, incident procedure with 18(1) classification, third-party strategy). The compliance screen in 1Security reads each DORA article from those requirements and exports the mapping as an evidence pack.
Tool or spreadsheet, the order is the same: inventory (Article 8), then access (9(4)(c) and (d)), then detection (10), then the documents, because documents written before the inventory describe the organisation you wish you had. The auditor opens the inventory first. Start there.
