Microsoft 365 Security Posture Assessment: The Half of Compliance Your Azure Review Misses
What a Microsoft 365 security posture assessment covers that an Azure config scanner cannot reach: mail flow, external sharing, Teams and Purview, mapped to NIS2 Article 21 evidence.
Marc Dekeyser |
Microsoft 365 Security Posture Assessment: The Half of Compliance Your Azure Review Misses
Half of the estate a regulator will ask about does not live in Azure Resource Manager.
Say that in a room and everyone nods. Then the assessment lands, it enumerates subscriptions, resource groups, network security groups, storage accounts and key vaults, everyone reads the summary, and the estate gets filed as covered. Real surface. Useful surface.
Just not the surface carrying the risk.
Email, file sharing, chat, and the data moving through all three sit in Microsoft 365. Separate control plane. Its own admin centres, its own APIs, its own drift. A scanner pointed at ARM cannot reach any of it, and it will not tell you so, because a tool does not report on what it never looked at.
NIS2 and DORA scope the estate, not the subscription
Both regulations define scope as the whole information system. Not the cloud infrastructure. The whole thing. NIS2 Article 21(2) lists incident handling, access control, and security in the acquisition and maintenance of network and information systems. None of those are satisfied by reading Azure resources.
Follow your own data for a minute. The signed contract arrived as an attachment in Exchange Online. The project files sit in SharePoint and OneDrive. The decision that mattered was made in a Teams chat and never written down anywhere else. 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.
That is the claim I will defend, and a competent peer can argue with it: for most mid-market organisations, more regulated data is exposed through Microsoft 365 configuration than through Azure infrastructure configuration. Not more vulnerabilities. More exposure.
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 ARM resources and are not reachable through the APIs it talks to. Entire admin surfaces are simply invisible.
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; audit retention shorter than the investigation window |
| 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 Purview portal. An assessment that never enumerates these surfaces has not assessed them.
It has assumed them.
The identity layer is its own conversation, and I covered it separately in Conditional Access and PIM as compliance evidence. If you want the repeatable way to check the settings themselves rather than the argument for checking them, that is the SCuBA baseline.
Four domains do most of the work
Access control, incident detection, external exposure, 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: 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 proving it was enforced, not merely configured. Those are two different claims and auditors have learned to ask for the second one.
Incident handling and detection is Article 21(2)(b). Confirm the unified audit log is on tenant-wide and retained long enough to be useful, or accept that a post-incident investigation will have nothing to work from. Defender for Office 365 anti-phishing and Safe Links cover the most common initial-access vector. The artifact is the audit 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 the question of 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. The artifact is the DLP policy inventory and the sensitive-information types it genuinely covers, which is usually a shorter list than anyone expects.
“Our Secure Score is fine, though. Isn’t that the same thing?”
No.
Secure Score reads the temperature across identity, data, device and apps, and it is a perfectly good place to start. It tells you a control is off. It will not tell you which Article that control answers, it will not date the observation, and it will not survive contact with an auditor who wants to know what the value was in March. A score going up is a direction of travel. Evidence is a record.
For the infrastructure side of the estate, the Well-Architected Framework security pillar walkthrough covers the equivalent ground.
Turning the review into audit evidence
A screenshot is not evidence.
Evidence is each control’s configuration exported as a dated, attributable record tied to the framework clause it satisfies. Traceability is the entire 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, and the Purview DLP inventory with audit-log status. Every row carries the 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 is not evidence at all.
Collecting it by hand is where I lost my patience. Five admin centres and two PowerShell modules to assemble the same dozen settings, per tenant, and then the exports came out with no dates and no clause on them, so I wrote the mapping down in a spreadsheet anyway. I did that on more Sundays than I will admit to in writing. Platform Architecture Authority is where that stopped being a Sunday: it reads both control planes and hands back the settings already dated and already mapped, and I still decide which exposures matter.
Where this leaves the assessment
The point is coverage, not cleverness. Name Azure storage encryption, never open the SharePoint admin center, and you have documented the easy half of the estate while the regulated half sits unexamined and unmentioned.
So if you are signing off an assessment this quarter, ask one question of whoever produced it: which admin centres did you actually open? The answer tells you what the report is worth.
The estate is the scope. Assess the estate.
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 ICT 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.
