Microsoft 365 Security Posture Assessment: The Half of Compliance Your Azure Review Misses
A Microsoft 365 security posture assessment covers the mail, collaboration and data surfaces Azure config scanners ignore — mapped to NIS2. For CISOs.
Marc Dekeyser |
Microsoft 365 Security Posture Assessment: The Half of Compliance Your Azure Review Misses
Most Azure assessments stop at the wrong boundary. They read the infrastructure and declare the estate covered, when the mail flow, collaboration, sharing and data-governance controls that carry most of the actual risk live outside Azure Resource Manager entirely. NIS2 and DORA scope the whole estate. A review that stops at Azure resources has documented roughly half of what a regulator will ask about.
Look at what the typical tool reads: Azure Resource Manager (ARM). Subscriptions, resource groups, network security groups, storage accounts, key vaults. Real surface, useful surface. Just not where a regulated organisation runs its day-to-day risk. Email, file sharing, chat, and the data moving through all three sit in Microsoft 365 instead: a separate control plane, its own admin centres, its own configuration drift.
Why this matters for NIS2 and DORA
Both regulations define scope as the whole information system. Not the cloud infrastructure, the whole thing. And for most organisations the sensitive data does not live in Azure infrastructure at all. It moves through Microsoft 365. NIS2 Article 21(2) lists incident handling, access control, and security in network and information systems acquisition and maintenance. None of that is satisfied by inspecting Azure resources.
Follow the data. Contracts arrive as attachments in Exchange Online. Project files sit in SharePoint and OneDrive. Decisions get made in Teams chats. A scanner that reads only ARM sees the storage account behind a virtual machine, reports a clean bill of health, and never notices the finance team sharing a folder of personal data with “Anyone with the link” switched on. The Azure posture is fine. The compliance posture is not.
Two control planes, two sets of admin surfaces. Cover one, call the job done, and you have answered half the question.
What an Azure config scanner can’t see
The problem is not depth. A scanner can read ARM resources in exhaustive detail and still miss every Microsoft 365 control, because those settings are not expressed as ARM resources and are not reachable through the resource APIs the scanner talks to. Entire admin surfaces are simply invisible to it. That is a coverage gap, and coverage gaps do not show up as findings. They show up as silence.
Here is what a Microsoft 365 posture assessment actually adds:
| Microsoft 365 surface | What it governs | Example exposure a config scanner misses |
|---|---|---|
| Exchange Online | Mail flow, anti-phishing, anti-spoofing | Anti-phishing policy disabled; SPF/DKIM/DMARC not enforced; auto-forwarding to external domains allowed |
| SharePoint and OneDrive | File storage, external sharing | Tenant-wide sharing set to “Anyone”; no expiry on anonymous links |
| Microsoft Teams | Chat, meetings, guest access | Unrestricted guest access; external federation open to all domains |
| Microsoft Purview | DLP, retention, audit logging | No DLP policy on personal data; unified audit log disabled |
| Microsoft Entra ID | Identity, Conditional Access | Legacy authentication still permitted; no phishing-resistant MFA |
Not one of those rows reads out of ARM. Exchange Online configuration lives in the Exchange admin center and the Exchange Online PowerShell module. External sharing lives in the SharePoint admin center. Purview policies live in the Microsoft Purview compliance portal. An assessment that never enumerates these surfaces has not assessed them. It has assumed them.
The identity layer is its own conversation. I covered it separately in Conditional Access and PIM as compliance evidence.
Mapping the controls to NIS2 Article 21
Four domains do most of the work: access control, incident detection, external exposure, and data governance. Each one comes down to a named setting, and a named setting is what produces evidence.
Access control sits under Article 21(2)(i) and (j). In practice that means Conditional Access policies in Microsoft Entra ID blocking legacy authentication and requiring phishing-resistant MFA. Your evidence is the policy export plus the sign-in logs that prove it was actually enforced, not just configured.
Incident handling and detection is Article 21(2)(b). Turn on the Purview unified audit log tenant-wide, or accept that a post-incident investigation will have no record to work from. Microsoft Defender for Office 365 anti-phishing and Safe Links catch the most common initial-access vector. The artifact here is the audit-log retention configuration and the Defender policy set.
External exposure maps to Article 21(2)(d), the supply-chain clause. SharePoint and OneDrive sharing scope, Teams guest and federation settings. This is who outside the organisation can reach inside it. The artifact is the sharing-policy export carrying the configured link-expiry and domain-allowlist values.
Data governance falls under Article 21(2)(a), general risk management. Purview DLP policies and retention labels over personal and regulated data categories. The artifact is the DLP policy inventory and the sensitive-information types it actually covers.
A word on Secure Score. The Microsoft Secure Score for Microsoft 365 scores roughly 40 improvement actions across identity, data, device, and apps, and it is a fine place to start reading the temperature. It is not a compliance report. It tells you a control is off. It will not map that control to an Article, and it will not hand you the dated evidence an auditor accepts. For the infrastructure side of the estate, the Microsoft Azure Well-Architected Framework security pillar walkthrough covers those controls.
Turning the review into audit evidence
A screenshot is not evidence. Evidence is each control’s configuration exported as a dated, attributable record that ties the setting to the framework clause it satisfies. Traceability is the whole difference between a posture review and a compliance artifact.
For one tenant, a usable package pulls together: the Conditional Access policy export with enforcement logs; the Exchange Online anti-phishing and DMARC configuration; the SharePoint and OneDrive external-sharing settings with link-expiry values; the Teams guest and federation policy; the Purview DLP inventory and unified-audit-log status. Every row carries the framework clause, the observed value, the target value, and the date observed.
That last column is the one auditors actually read. A control compliant in March and drifted by June is a finding. Undated, it isn’t evidence at all.
FAQ
Does Microsoft Secure Score cover NIS2 compliance? No. It scores configuration strength across identity, data, devices, and apps, but it does not map controls to NIS2 articles or produce dated audit evidence. Use it as a baseline indicator, then map each control to the specific regulatory clause separately.
Can an Azure config scanner read Exchange Online settings? No. Exchange Online configuration lives in a separate control plane reached through the Exchange admin center or the Exchange Online PowerShell module, not Azure Resource Manager. A scanner that reads only ARM resources cannot see anti-phishing policies, mail-flow rules, or external auto-forwarding settings.
What is the most common Microsoft 365 exposure in a mid-market tenant? Unrestricted external sharing in SharePoint and OneDrive. Set tenant-wide sharing to “Anyone” with no link expiry and internal files become reachable through anonymous links that never die. An infrastructure-only assessment rarely surfaces it, and it is a direct NIS2 Article 21(2)(d) concern.
Is OneDrive in scope for DORA? Yes, where it stores or transmits data relevant to financial operations. DORA scopes the entire information and communication technology estate of a financial entity. OneDrive content, its sharing configuration, and its retention settings are all in scope, the same as any Azure infrastructure component.
Where this leaves the assessment
Platform Architecture Authority reads both control planes: Azure infrastructure through Resource Manager, and the Microsoft 365 surface through its own admin APIs. Each finding maps to the NIS2 and DORA clause it answers, and it produces the dated artifact described above. Read-only. It generates remediation code you review before you apply it, and a senior architect still decides which exposures matter most for your risk profile.
The point is coverage. Name Azure storage encryption, never open the SharePoint admin center, and you have documented the easy half while the regulated half sits unexamined.
The estate is the scope. So assess the estate.
