Rencore
NIS2 reaches 18 months: why governance evidence still trips audits
Eighteen months past the NIS2 transposition deadline, regulators in essential and important sectors are issuing their first round of findings. The pattern in Microsoft 365 environments is consistent: the technology is fine, the evidence trail is not.
The EU's NIS2 Directive set a national transposition deadline of 17 October 2024 and applies to essential and important entities across 18 sectors, including energy, transport, banking, health, digital infrastructure, and public administration. Eighteen months on, the first wave of supervisory inspections has produced a recognizable failure pattern: not gaps in the technical controls themselves, but gaps in the evidence trail that connects Microsoft 365 configuration to NIS2's governance, risk management, and incident reporting obligations.
NIS2 has now been transposable national law for 18 months. The directive’s two big buckets, governance and management obligations (Article 20) and cybersecurity risk-management measures (Article 21), are clear enough on paper. The friction in actual inspections, in the conversations we hear from regulated entities, is not at the policy or technology level. It is at the evidence level.
Three failure patterns keep recurring in Microsoft 365 environments.
Failure pattern one: governance accountability is documented, but not operational
Article 20 puts personal accountability on management bodies. The board signs the cybersecurity policy. The named officer is responsible. The training is delivered. The paperwork exists.
Then the regulator asks, “show me the operational trail.” Who approved the change that loosened external-sharing on this Teams workspace last September? Who signed off on the policy exception that left this SharePoint site with broad permissions? Who owns the AI agent that was deployed into the operations function in March?
The answers tend to live in email threads, ticketing systems, and the memory of the people involved. NIS2 supervisory inspections are increasingly asking for that trail in a queryable form, attached to the resource the change affected. A board-approved policy that is not enforced and evidenced at the resource level does not satisfy Article 20.
Failure pattern two: risk management measures are configured, but not versioned
Article 21 lists ten cybersecurity risk-management measures, from incident handling to supply-chain security to encryption. In an M365 environment, most of those measures translate to platform configuration: conditional access, sensitivity labels, retention policies, DLP rules, sharing controls, access reviews.
The configuration is usually fine. The historical record of the configuration is often not.
When an inspector asks “what was the sensitivity-label posture on this site on the date the incident occurred,” current state is not an answer. NIS2 expects an entity to reconstruct the control state at a specific point in time. Microsoft’s native logs do part of this, with retention windows that vary by service and licence tier. The gap between “Microsoft retained this for 90 days” and “the regulator is asking about 14 months ago” is where the finding lands.
Failure pattern three: incident reporting timelines do not survive the M365 surface
Article 23 sets the now-familiar 24-hour early warning, 72-hour notification, and one-month final report cadence for significant incidents. The technology to detect an incident is rarely the problem. The technology to characterize it under regulatory pressure is.
In M365 incidents we have helped reconstruct, the 24-hour window goes to triage. The 72-hour window goes to scope: who had access, what data was touched, what external recipients received what, which AI assistants surfaced affected content. If the answer to those questions requires hand-correlating logs across Defender, Purview, Entra, and the SharePoint admin centre, 72 hours is tight. If the affected service involves Copilot or third-party agents, it is tighter.
The regulators understand that incident reconstruction is hard. What they do not accept is “we will get back to you when we figure it out.” The mitigation is a continuously maintained inventory and audit trail across the full M365 surface, queryable at the point an incident happens.
What works for Article 20 and Article 21
The organizations passing NIS2 supervisory inspections without major findings share three operational characteristics.
Service inventory is automated and current. Every M365 service in scope, every Copilot deployment, every agent, every connector, is enumerated by the governance platform. The inventory is the basis of the risk register, the configuration baseline, and the incident-scope query.
Configuration history is versioned. Sensitivity labels, sharing posture, retention policy, DLP rule, access-review outcome, lifecycle policy. Every change is captured with timestamp, actor, prior state, and the policy that triggered the alert. Auditors get point-in-time queries.
Resource ownership is enforced. Every governed resource has a named owner. The owner is responsible for the resource’s state and is automatically notified when policy violations occur. Ownership is the operational link between Article 20 management accountability and Article 21 control measures.
The technology to meet these obligations is not exotic. It is just not something Microsoft alone provides in audit-grade form across the full M365 surface. NIS2’s first 18 months have made that clear in the only way that matters: in the findings letters.
See how Rencore generates audit-grade evidence for NIS2 across M365, or book a NIS2-readiness conversation.
