Microsoft 365 Security Posture: The Half of Compliance Your Azure Assessment 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
A Microsoft 365 security posture assessment examines the mail flow, collaboration, sharing and data-governance controls that live outside Azure Resource Manager — the surfaces a Microsoft Azure infrastructure scan never touches. NIS2 and DORA scope the whole estate, so a posture review that stops at Azure resources documents roughly half of what a regulator will ask about.
Most assessment tools read Azure Resource Manager (ARM): subscriptions, resource groups, network security groups, storage accounts, key vaults. That is a real and useful surface. It is also not where most regulated organisations actually run their day-to-day risk. Email, file sharing, chat, and the data flowing through them sit in Microsoft 365 — a separate control plane, governed by separate admin centres, with its own configuration drift.
Key takeaways
- NIS2 Article 21 and DORA scope an organisation’s entire information system, not only its cloud infrastructure — Microsoft 365 is in scope by default.
- Azure Resource Manager scanners cannot see Exchange Online, SharePoint, Microsoft Teams, or Microsoft Purview settings; those live in different control planes.
- The Microsoft Secure Score for Microsoft 365 is a first-party baseline, but it scores configuration, not architecture or evidence.
- External sharing in SharePoint and OneDrive is the single most common quiet exposure in a mid-market tenant.
- A complete posture assessment maps each Microsoft 365 control to a named NIS2 Article 21 domain and produces a dated artifact.
Why does a Microsoft 365 security posture assessment matter for NIS2 and DORA?
A Microsoft 365 security posture assessment matters because NIS2 and DORA define scope as the whole information system, and for most organisations the majority of sensitive data moves through Microsoft 365, not through Azure infrastructure. NIS2 Article 21(2) lists incident handling, access control, and security in network and information systems acquisition and maintenance — none of which is satisfied by inspecting Azure resources alone.
Consider where the data actually is. Contracts arrive as email attachments in Exchange Online. Project files live in SharePoint and OneDrive. Decisions get made in Microsoft Teams chats. A scanner that reads only ARM sees the storage account behind a virtual machine and reports a clean bill of health, while a finance team is sharing a folder of personal data with “Anyone with the link” enabled. The Azure posture is fine. The compliance posture is not.
This is the structural blind spot. Azure infrastructure and Microsoft 365 are two control planes with two sets of admin surfaces. An assessment that covers one and calls itself complete is, at best, half an answer.
What does an Azure config scanner miss in Microsoft 365?
An Azure config scanner misses every Microsoft 365 control plane, because those settings are not expressed as Azure Resource Manager resources and are not reachable through the Azure resource APIs a typical scanner reads. The gap is not a depth problem. It is a coverage problem — entire admin surfaces are invisible.
Here is the concrete surface a Microsoft 365 posture assessment 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 |
None of these read out of ARM. Exchange Online configuration lives in the Exchange admin center and the Exchange Online PowerShell module. SharePoint external sharing lives in the SharePoint admin center. Microsoft Purview policies live in the Microsoft Purview compliance portal. A posture assessment that does not enumerate these surfaces has not assessed them — it has assumed them.
For the identity layer specifically, see the companion piece on Conditional Access and PIM as compliance evidence.
Which Microsoft 365 controls map to NIS2 Article 21?
The Microsoft 365 controls that map to NIS2 Article 21 cluster around four domains: access control, incident detection, supply-chain and external exposure, and data governance. Each maps to a named setting that produces evidence.
Access control — Article 21(2)(i) and (j). Conditional Access policies in Microsoft Entra ID that block legacy authentication and require phishing-resistant multifactor authentication. The evidence artifact is the policy export plus the sign-in logs showing enforcement.
Incident handling and detection — Article 21(2)(b). The Microsoft Purview unified audit log must be enabled tenant-wide; without it, post-incident investigation has no record. Microsoft Defender for Office 365 anti-phishing and Safe Links policies detect the most common initial-access vector. The artifact is the audit-log retention configuration and the Defender policy set.
Supply chain and external exposure — Article 21(2)(d). SharePoint and OneDrive external sharing scope, Microsoft Teams guest and federation settings. These define who outside the organisation can reach internal data. The artifact is the sharing-policy export with the configured link-expiry and domain-allowlist values.
Data governance — Article 21(2)(a) general risk management. Microsoft Purview data loss prevention policies and retention labels covering personal and regulated data categories. The artifact is the DLP policy inventory with the sensitive-information types it covers.
The Microsoft Secure Score for Microsoft 365 is a reasonable starting index — it scores roughly 40 improvement actions across identity, data, device, and apps. Treat it as a thermometer, not a compliance report. Secure Score tells you a control is off. It does not map that control to an Article, and it does not produce the dated evidence an auditor accepts. For the Azure-side equivalent, the Microsoft Azure Well-Architected Framework security pillar walkthrough covers the infrastructure controls.
How do you produce audit evidence from a Microsoft 365 posture review?
You produce audit evidence by exporting each control’s configuration as a dated, attributable artifact — not a screenshot, but a structured record tying the setting to the framework clause it satisfies. The difference between a posture review and a compliance artifact is traceability.
A usable evidence package for one tenant includes: 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 Microsoft Teams guest and federation policy; the Microsoft Purview DLP policy inventory and unified-audit-log status. Each row carries the framework clause, the observed value, the target value, and the date observed.
That last column is what auditors actually check. A control that was compliant in March and drifted in June is a finding. Evidence has to be dated to be evidence.
FAQ
Does Microsoft Secure Score cover NIS2 compliance? No. The Microsoft Secure Score for Microsoft 365 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. When tenant-wide sharing is set to “Anyone” with no link expiry, internal files become reachable by anonymous links that never expire. It is rarely visible in an infrastructure-only assessment and 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 assesses both control planes — Azure infrastructure through Resource Manager and the Microsoft 365 surface through its own admin APIs — and maps each finding to the NIS2 and DORA clause it answers, producing the dated artifact described above. It is read-only; it generates remediation code you review and apply, and a senior architect still brings the judgment about which exposures matter most for your risk profile. The point is coverage. An assessment that names Azure storage encryption but never opens the SharePoint admin center has documented the easy half and left the regulated half unexamined.
The estate is the scope. Assess the estate.
