Rencore
DORA's first enforcement year: lessons from financial services M365 audits
DORA went enforceable on 17 January 2025. Fourteen months in, the pattern from financial-services audits is clear: the gaps are not in technology choices, they are in the evidence trail that connects M365 configuration to DORA's ICT risk and resilience requirements.
The Digital Operational Resilience Act, DORA, became enforceable on 17 January 2025 and applies to roughly 22,000 EU financial entities and their critical ICT third-party providers. Fourteen months in, the audit findings keep clustering around the same Microsoft 365 evidence gaps: incomplete ICT registers, weak third-party concentration analysis, and incident-response trails that cannot reconstruct who had access to what data when a control failed.
The Digital Operational Resilience Act has now had a full enforcement year plus change. National supervisory authorities have run their first round of thematic reviews, the European Supervisory Authorities have published their first set of common findings, and a meaningful number of regulated entities have been through a DORA-specific examination.
The pattern in those examinations, especially for the parts that touch Microsoft 365, is consistent enough to talk about openly.
What the regulators are actually looking for
DORA’s five operative pillars matter at different depths for different entities, but four ICT-related obligations show up in every M365-relevant audit:
Article 8 ICT risk management framework. Documented, board-approved, with controls mapped to actual systems and services.
Article 28 third-party ICT register. A complete and current inventory of ICT third-party providers, the services they deliver, the data they process, and the criticality classification.
Article 17 ICT incident classification and reporting. Reconstruction of an incident, who did what, when, and what data was touched, with the audit trail to back it up.
Article 24 to 27 threat-led penetration testing and digital operational resilience testing. For significant entities, with documented scope, conduct, and remediation tracking.
For a financial services organization running Microsoft 365 as a core productivity and collaboration platform, all four obligations land partly on the M365 estate. Three audit gaps appear repeatedly.
Gap one: the ICT register is missing the Microsoft sub-stack
Most financial-services ICT registers we see list “Microsoft 365” as a single entry. That is not what Article 28 asks for. The register needs to cover the specific services in use, the data categories they process, the criticality classification per service, and the geographies the data is processed in. SharePoint, Exchange Online, Teams, OneDrive, Power Platform, Copilot, and any third-party Copilot connectors are separately material services. The register has to reflect that.
The fix is mechanical but unglamorous: build the service inventory from the platform, attach data categories, attach criticality, attach geography, and keep it current. Without an automated inventory feed, the register goes stale within a quarter.
Gap two: third-party concentration analysis is hand-waved
Article 28 also requires entities to analyse and document concentration risk. For most regulated firms, the M365 footprint is itself a concentration risk: the platform runs identity, collaboration, document storage, and AI in one vendor.
The audit pattern is that organizations have not formally documented their concentration analysis, their mitigation strategy, or their exit plan. The mitigation conversation is changing in 2026 because Copilot adds an AI processing layer on top of the existing collaboration concentration. Regulators are asking specifically about Copilot’s data residency and processing arrangements.
Gap three: incident-evidence trails do not survive cross-examination
When an incident happens, ICT incident classification under Article 17 requires a reconstructable timeline. For an M365 incident, “who had access to the data at the time the control failed” is the bar. That requires:
- Permission state at the time of the incident, not the current state
- Sharing-link history, including external recipients
- Sensitivity-label propagation and Copilot retrieval scope at that point
- Change history for any policy or configuration touching the affected resource
Most organizations cannot reconstruct this from Microsoft’s native logs alone, particularly once retention windows roll. The auditor question that catches teams is “show me the access state on day X for resource Y,” and “we have current state” is not an answer that closes the finding.
What works
The organizations passing DORA examinations without major findings on the M365 estate share three patterns:
A continuously refreshed service inventory tied to the ICT register. Not a spreadsheet. A platform-driven inventory that pushes service, data-category, and criticality information into the firm’s risk register on a defined cadence.
Versioned policy state. Every policy change, sharing change, label change, and lifecycle action is captured with timestamp, actor, and prior state. Auditors get point-in-time queries, not current-state snapshots.
Owner-attached evidence. Every governed resource has a business owner. When an auditor asks who is responsible for the control on a specific Teams workspace, the answer is in the platform, not in an email thread.
The good news, for organizations that are not yet there, is that the regulators want evidence of a credible programme, not perfection. The findings that close quickly are the ones backed by an automated, ongoing capability. The findings that linger are the ones backed by spreadsheets and best intentions.
See how Rencore produces audit-ready evidence across the M365 estate, or book a DORA-readiness conversation.
