Does Your Microsoft 365 Setup Actually Satisfy NIS2 Article 21(2)? The Complete Feature Mapping

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Three roles typically read a mapping like this for different reasons: the IT security manager wants to know exactly which control covers which measure, the compliance officer wants the documentation trail an auditor will actually ask for, and the board wants to know what its own exposure looks like if neither job gets finished. This article addresses all three — the table below is for the first, the documentation-gap section is for the second, and the closing section on Articles 34 and 20 is for the third.

Does NIS2 Apply If Your Organisation Just Runs Microsoft 365?

Running Microsoft 365 doesn’t exempt you from anything, and it doesn’t automatically bring you into scope either. NIS2 Article 21 obliges “essential” and “important” entities in specific Annex I/II sectors to take “appropriate and proportionate” cybersecurity risk-management measures [1] — the trigger is your sector and size, not your choice of productivity suite. A 40-person manufacturing supplier running entirely on Microsoft 365 Business Premium is in scope if manufacturing puts it in Annex II and it clears the size threshold; a 40-person marketing agency on the identical stack is not.

Question	Why it matters
Is your sector listed in NIS2 Annex I or II?	Energy, health, digital infrastructure, manufacturing, and over a dozen other Annex I/II sectors are in scope by default — unrelated to your software stack. Check our scope test if you’re unsure.
Do you clear the medium/large enterprise threshold?	Broadly ≥50 staff or >€10M turnover+balance sheet (important); ≥250 staff or >€50M turnover (essential) — exact figures vary by national transposition.
Are you a direct supplier to an in-scope entity?	Article 21(2)(d) supply chain obligations flow downstream even if you’re never directly regulated — your customer’s auditor will ask about your M365 tenant configuration regardless.

If either of the first two is yes, Article 21(2) applies to your organisation directly, and Microsoft 365 is almost certainly carrying a meaningful share of your “network and information systems.” Everything below assumes that’s the case — or that you’re the supplier answering someone else’s questionnaire.

Microsoft 365 Gives You Controls. NIS2 Asks For Something Else.

Microsoft’s own documentation for Secure Score — the single most-cited M365 “compliance” metric — states plainly that it “isn’t an absolute measurement of how likely your system or data could be breached” and “shouldn’t be interpreted as a guarantee against security breach in any manner” [5]. That’s not corporate caution; it’s an accurate description of what a configuration score can and can’t do. Article 21(2) doesn’t ask whether your tenant is configured well. Six of its ten lettered measures explicitly say “policies,” “policies and procedures,” or both [1]. A policy is a document with a scope, an owner, a review date, and a version history — not a toggle in the Defender portal.

The Microsoft 365 Feature-to-Article 21(2) Map

This mapping is our own analysis, checked directly against Article 21(2)’s verbatim text [1] rather than repeated from a vendor blog — Microsoft’s own security blog on NIS2 explicitly avoids naming which product satisfies which lettered measure, saying only that its tools “can help provide” alignment [10]. That caution is deliberate: a tool-to-article mapping is inherently an interpretation, not a certified fact, and the table below should be read as a starting point for your own documented risk assessment, not a substitute for it.

Article 21(2) measure	Microsoft 365 feature	What it actually gives you
(a) Risk analysis & information system security policy	Microsoft Secure Score + Purview Compliance Manager	A posture score and a NIS2 assessment template for tracking configuration evidence — not the risk register itself [5][9]
(b) Incident handling	Microsoft Defender for Office 365	Detection, automated investigation (Plan 2), and an incident queue in the Defender portal [7]
(c) Business continuity	Purview Data Lifecycle Management + Exchange/SharePoint retention	Retention and recovery of mailbox/file data — not a documented crisis-management or disaster-recovery plan
(d) Supply chain security	Conditional Access for guest/B2B access + Defender for Cloud Apps	Enforced conditions on third-party account access into your tenant — not a supplier risk classification or contract clause
(e) Acquisition, development & maintenance (incl. vulnerability handling)	Microsoft Defender Vulnerability Management	Continuous device/asset vulnerability scoring — core capability requires Defender for Endpoint Plan 2
(f) Effectiveness assessment	Secure Score history + Compliance Manager improvement actions	Trend tracking over time — useful evidence, but the assessment methodology document still has to be written
(g) Cyber hygiene & training	Attack Simulation Training (Defender for Office 365 Plan 2)	Phishing simulations and per-user reporting — requires E5 or a standalone P2 licence for every included user [8]
(h) Cryptography & encryption	Purview Message Encryption + sensitivity labels, BitLocker via Intune	The actual cryptographic mechanism. Note: Purview DLP alone doesn’t encrypt anything — it detects and blocks; the encryption sits in sensitivity labels, a related but separate Purview capability
(i) HR security, access control & asset management	Entra Conditional Access + Purview DLP data classification	Access-policy enforcement and sensitive-data classification — the asset register and HR onboarding/offboarding procedure remain separate documents [6]
(j) MFA / secured communications	Entra multifactor authentication + Teams encryption	Microsoft’s own research puts MFA at blocking more than 99.2% of account-compromise attacks [3] — the strongest single control on this table

Read the (h) row again if you came here specifically for a data-loss-prevention answer: DLP is frequently marketed as a NIS2 “data security” checkbox, but its actual job is monitoring and blocking risky data movement, not applying cryptography [6]. If your auditor asks about encryption specifically, the evidence trail runs through sensitivity labels and Purview Message Encryption, not the DLP policy itself — a distinction most feature-mapping articles skip past. For the equivalent exercise on Azure infrastructure rather than the M365 productivity suite, see our companion Azure NIS2 compliance mapping.

Where E3 Stops and E5 Starts

Every row above assumes the right licence, and that’s where feature-mapping articles usually go quiet. Microsoft 365 E3 includes Defender for Office 365 Plan 1 (Safe Links, Safe Attachments, anti-phishing) and Entra ID P1 (Conditional Access, standard MFA), plus Purview DLP for Exchange, SharePoint, and OneDrive [7]. E5 is what actually unlocks measures (e), (f), and (g) at meaningful depth: Defender for Office 365 Plan 2 (automated investigation, Attack Simulation Training), Defender Vulnerability Management’s core capabilities, Purview Audit (Premium) with one-year default log retention instead of Standard’s 180 days [4], and Entra ID P2’s access reviews and Privileged Identity Management.

The practical consequence for a compliance officer building an Article 21(2) evidence file: if your organisation is on E3, rows (e), (g), and the Premium-retention half of (b) are gaps you need to either close with add-on licences or cover through a documented compensating control — not gaps you can wish away by pointing at the Secure Score dashboard everyone already has. For an SME owner weighing the cost, the E3-to-E5 upgrade is the one licensing decision on this list with a direct compliance payoff; the remaining gaps are documentation work your existing licence already supports, not additional spend.

Who Owns What: A Role-Responsibility Snapshot

Role	Owns	Hands off to
IT / Security Manager	Conditional Access, Secure Score remediation, Defender/Purview configuration	Passes configuration evidence to Compliance for the policy write-up
Compliance Officer	Risk analysis policy, incident handling procedure, Article 23 notification templates, audit trail	Escalates unresolved licensing gaps (E3 vs E5) to budget owner
Board / Management Body	Approval and oversight of the risk-management measures under Article 20, budget sign-off	Delegates day-to-day implementation back to IT and Compliance

A Rollout Sequence, Not a Shopping List

Step	Effort	What it closes
Enforce Conditional Access MFA for all users, including admins and break-glass accounts	Low	(j) — highest-leverage single control, no additional licence for baseline MFA
Turn on Purview Audit and confirm retention duration against your incident-review window	Low	Evidence trail for (b) and (f); confirm whether 180-day Standard retention is enough or E5 Premium’s 1-year default is needed [4]
Write the risk analysis, information security, and incident handling policy documents	Medium	(a) and (b) — the actual policy artifact Article 21(2) names explicitly [1]
Classify direct suppliers with tenant access and apply Conditional Access accordingly	Medium	(d) — pairs the technical control with the classification document
Deploy Attack Simulation Training and log completion per employee (if E5-licensed)	Medium	(g) — training and the record of who completed it
Draft the Article 23 incident notification templates (24h / 72h / 1 month)	Low	Bridges (b) into your actual regulatory reporting obligation — see our Article 23 notification guide

None of this requires ripping out Microsoft 365. It requires treating the technical layer and the documentation layer as two separate deliverables — because Article 21(2) does. For the full ten-measure breakdown outside the M365 context, see our complete Article 21 walkthrough, and for the access-control and encryption specifics referenced in the table above, see access control and cryptography & encryption.

What Happens If You Don’t Close the Documentation Gap

Article 34 sets penalties at up to EUR 10,000,000 or 2% of worldwide annual turnover for essential entities, and up to EUR 7,000,000 or 1.4% for important entities — whichever figure is higher in each case [2]. Those numbers apply to failures under Article 21 or 23 generally; a well-configured tenant with no documented risk assessment behind it is still a compliance gap in the eyes of a supervisory authority conducting an audit, regardless of how high the Secure Score reads. Article 21(2) compliance also isn’t purely an IT-department deliverable: NIS2 Article 20 requires the management body to approve and oversee the entity’s cybersecurity risk-management measures, which is the board-level reason a Secure Score printout can’t stand in for a signed-off policy set.

The cryptography row in that map deserves its own treatment. For a line-by-line look at what Purview actually evidences under Article 21(2)(h) — and the three CIR 2024/2690 Section 9 requirements it leaves to you, starting with key lifecycle control — see Microsoft Purview and NIS2 Article 21(2)(h).

FAQ

Does buying Microsoft 365 E5 make us NIS2 compliant?
No single product purchase satisfies Article 21(2) — E5 unlocks more of the technical capability referenced in the mapping above, but the policies, risk assessments, and training records the article requires still have to be authored and maintained separately.

Is Microsoft itself NIS2-regulated for the Microsoft 365 service?
Microsoft, as a cloud service provider, falls under Commission Implementing Regulation (EU) 2024/2690 for its own infrastructure obligations. Your organisation’s Article 21(2) obligations as an NIS2-scoped entity are separate and don’t transfer to Microsoft by virtue of outsourcing your IT to their cloud.

Which Article 21(2) measure is hardest to cover with Microsoft 365 alone?
(e) acquisition, development, and maintenance — including vulnerability handling and disclosure. M365’s own vulnerability tooling (Defender Vulnerability Management) covers devices and endpoints well but says nothing about how your organisation acquires, develops, or maintains the software and systems it builds on top of the platform.

Sources

• NIS2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com
• NIS2 Directive (EU) 2022/2555, Article 34 — nis-2-directive.com
• “Plan for mandatory Microsoft Entra multifactor authentication” — Microsoft Learn
• “Manage audit log retention policies” — Microsoft Learn / Purview
• “Microsoft Secure Score” — Microsoft Learn / Defender XDR
• “Learn about data loss prevention” — Microsoft Learn / Purview
• “Microsoft Defender service description” — Microsoft Learn
• “Get started using Attack simulation training” — Microsoft Learn / Defender for Office 365
• “NIS2 Compliance & Cybersecurity Solutions” — Microsoft Trust Center
• “Navigating NIS2 requirements with Microsoft Security solutions” — Microsoft Security Blog