Microsoft Purview NIS2 Compliance: Article 21(2)(h) Coverage and the 3 CIR Section 9 Gaps It Leaves

Microsoft Purview delivers roughly half of what NIS2 Article 21(2)(h) asks for, and not the half most vendor mappings claim. Sensitivity labels and label-applied encryption are real controls producing real audit evidence. But the operative detail behind Article 21(2)(h) lives in Commission Implementing Regulation (EU) 2024/2690, Annex Section 9 — and Section 9 is mostly a document-and-key-lifecycle requirement, not a tooling requirement. No Purview surface writes that document, and the default Microsoft-managed encryption key cannot perform three of the lifecycle operations Section 9.2 names.

This guide separates what Purview genuinely evidences from what you still have to build, using Microsoft’s own documentation for the product claims and the regulation text for the obligations.

Does this apply to you? Scope before tooling

In plain language: every essential and important entity owes Article 21(2)(h), but only about eleven categories of digital provider are legally bound by the CIR’s detailed sub-requirements. Everyone else should treat the CIR as the benchmark supervisors will reach for anyway.

Article 21(2)(h) of Directive (EU) 2022/2555 requires "policies and procedures regarding the use of cryptography and, where appropriate, encryption" [1] — one sentence binding every entity in scope. Commission Implementing Regulation (EU) 2024/2690 expands it into Annex Section 9, but the CIR’s legal reach is narrow.

Your entity type	Article 21(2)(h)	CIR 2024/2690 Section 9	What this means for a Purview deployment
DNS providers, TLD registries, cloud and data centre providers, CDNs, MSPs, MSSPs, online marketplaces, search engines, social platforms, trust service providers	Binding	Directly binding	Section 9.2 sub-points are testable requirements. Purview gaps are compliance gaps.
All other essential and important entities (energy, health, transport, water, manufacturing, public administration)	Binding	Not directly binding — interpretive benchmark	National law sets your detail, but the CIR remains the most concrete statement of what "adequate" cryptography means.

ENISA published its Technical Implementation Guidance for the CIR on 26 June 2025, with evidence examples for all thirteen requirement areas including cryptography — and states plainly that it "is not a legally binding document and it is not intended to replace the frameworks, guidance or tools provided by Member States at national level" [9]. Check your national competent authority first. MSPs and MSSPs reading this on a client’s behalf sit in the directly-bound row themselves; see our guidance for MSPs and MSSPs.

What Article 21(2)(h) actually requires: CIR Section 9, line by line

Section 9.1 sets the obligation. Verbatim: "The relevant entities shall establish, implement and apply a policy and procedures related to cryptography, with a view to ensuring adequate and effective use of cryptography to protect the confidentiality, authenticity and integrity of data in line with the relevant entities’ asset classification and the results of the risk assessment carried out pursuant to point 2.1" [2].

Read the last clause twice. Section 9.1 does not ask you to classify assets — it assumes you already have, and requires your cryptography choices to follow that classification. Asset classification is a separate obligation under Annex Section 12, mapping to Article 21(2)(i), not (h) [3]. The classification work Purview does best is therefore an asset-management deliverable that Section 9 consumes as an input.

Section 9.2 then specifies what the policy must establish:

Sub-point	Requirement (CIR 2024/2690 Annex)	Evidence an auditor can test
9.2(a)	"the type, strength and quality of the cryptographic measures required to protect the relevant entities’ assets, including data at rest and data in transit"	A table linking each classification tier to a required protection level, covering both states.
9.2(b)	"the protocols or families of protocols to be adopted, as well as cryptographic algorithms, cipher strength, cryptographic solutions and usage practices to be approved and required for use"	A dated register of approved algorithms and minimum key lengths, naming the standard it follows.
9.2(c)	Key management across the lifecycle: generation, distribution, storage, rotation, compromise handling, revocation, recovery, backup, destruction and audit	A key inventory plus procedures and logs for each named operation.

Only 9.2(a) is a tooling question. The other two are documents backed by demonstrable capability — and capability is where the default Microsoft 365 configuration runs into trouble. Our full CIR 2024/2690 breakdown covers the other twelve sections.

What Microsoft Purview genuinely delivers

Here is an honest mapping. "Input" means Purview produces something Section 9 depends on but does not itself satisfy. For the wider tenant picture, see our assessment of whether a Microsoft 365 setup satisfies Article 21(2) as a whole.

Purview capability	Nearest CIR requirement	Evidence artefact	Verdict
Information Protection: sensitivity labels, auto-labelling, trainable classifiers	Section 12.1 asset classification (Art. 21(2)(i))	Label taxonomy, auto-labelling policy, coverage reports	Strong — but it is the input to 9.1, not 9.1 itself
Label-applied encryption via Azure Rights Management	Section 9.2(a), data at rest, Microsoft 365 content only	Label config showing which tiers carry encryption and usage rights	Partial — one enforcement channel, one data estate
Data Loss Prevention	Section 12.2 handling of assets	DLP policy set, match and override reports	Supporting evidence; not a cryptographic control
Purview Audit	Section 3.2 monitoring and logging	Unified audit records of label and key activity	Partial — retention defaults are the constraint
Compliance Manager	Sections 1 and 7 — evidence and effectiveness	Exported assessment with control status and test dates	Register, not a control

Compliance Manager needs one caveat. It does export a defensible artefact — a snapshot Excel report containing "the details for controls managed by both you and Microsoft, including implementation status, test date, and test results" [6]. But a template maps controls; it does not write your cryptography policy, and a Compliance Manager score is not a compliance finding. Note too that the Data Protection Baseline is the only template available at every subscription level, with all other regulations in the premium tier [5].

The audit-retention numbers are worth committing to memory. Audit (Standard) retains logs for 180 days for records generated on or after 17 October 2023 [7]. Audit (Premium) retains Exchange Online, SharePoint, OneDrive and Microsoft Entra records for one year — but "audit records for all other activities are retained for 180 days by default", and that one-year default covers only users holding E5 or an equivalent add-on. For non-E5 and guest users, "their corresponding audit records are retained for 180 days" [7]. If your logging and monitoring evidence assumes a year of tenant-wide history, check the licence mix of the accounts generating those records — or move the retention burden to a SIEM, as in our guide to Sentinel logging for CIR 2024/2690.

Gap 1: the default tenant key you cannot revoke, back up, or replace

This is the largest and least-discussed gap, and Microsoft documents it openly.

Every sensitivity label that applies encryption chains back to your Azure Rights Management tenant root key, which is Microsoft-managed by default. Microsoft’s own lifecycle table shows the limits: revoking the tenant key is not a customer operation (it happens automatically when the last subscription lapses), and customer backup and recovery is unavailable, because "Microsoft is responsible for backing up your Azure Rights Management tenant key and no action is required from you" [4].

The sharpest line is on rotation. Rekeying is supported, but: "To rekey, you can select a different Microsoft-managed key to become your Azure Rights Management tenant key, but you can’t create a new Microsoft-managed key. To create a new key, you must change your key topology to be customer-managed (BYOK)" [4]. Most tenants hold exactly one Microsoft-managed key; multiple keys generally exist only after an AD RMS migration. A default-configuration tenant therefore has no key to rotate to.

Set that against Section 9.2(c), which names rotation, revocation, recovery and backup among the operations your key-management procedures must cover [2]. A default tenant can document exactly one of them credibly.

Option	Key lifecycle control, and what it costs	When it is the right call
Microsoft-managed (default)	Rekey only in limited circumstances; no customer revoke, no customer backup; export via a chargeable support case that Microsoft says "can take up to three weeks" [4]. No deployment cost.	Lower-classification data, where you document the residual risk as a formal risk-acceptance decision
BYOK in Azure Key Vault	Revoke, rekey and backup all available; export is not — "The copy in Azure Key Vault is non-recoverable" [4]. Needs an Azure subscription, Key Vault or managed HSM, and real key-custody procedures.	The realistic answer for any entity that must evidence 9.2(c) end to end
Double Key Encryption	Two root keys, one held by you on-premises, so Microsoft "and other third parties never have access to encrypted data on their own" [4]. Highest cost: the option cannot be added later — "After the label is configured and saved, you won’t be able to edit it" [8] — Office for the web cannot open DKE content, and co-authoring is constrained.	A small, genuinely top-tier subset of content — never the default tier

One trap on rotation, whichever topology you choose: "After you rekey, the old key remains available for decrypting existing content encrypted with that key. If you later revoke or delete the old key from Azure Key Vault, any content encrypted with that key becomes inaccessible" [4]. Key destruction and data availability are the same decision. Your procedure has to say so. If key lifecycle across a mixed estate is the real problem, a purpose-built secrets platform answers Section 9.2(c) more directly than a labelling tool — see our mapping of HashiCorp Vault to CIR Annex 9.

Gap 2: Purview has no approved-algorithm register

Section 9.2(b) demands a governance artefact with a named owner and a review date, not a setting. No Purview screen produces it, by design: Azure Rights Management does not expose algorithm selection to administrators. You configure who can do what with labelled content; the cryptography underneath is Microsoft’s implementation decision. That is a reasonable engineering trade-off and a genuine evidence gap at once. Your register must name the approved algorithms and minimum key lengths across the whole estate, cite the standard it follows, and record that the Microsoft 365 layer inherits Microsoft’s implementation — with the assurance basis for that inheritance.

Section 9.2(b) also has a review dimension. Post-quantum migration planning now sits on most national cyber authorities’ roadmaps, and a register with no review trigger is a weak answer to an Article 21(1) proportionality question that explicitly turns on "the state of the art" [1]. Our cryptography and encryption requirements guide covers the policy structure in detail.

Gap 3: everything outside the tenant

Section 9.2(a) covers "data at rest and data in transit" across the entity’s assets [2]. Purview’s enforcement boundary is narrower than that phrase in four directions:

• Non-Microsoft SaaS. A label travels with a file inside the Microsoft ecosystem. Once content reaches an application that does not honour the label, enforcement stops even though the classification survives.
• Mixed endpoint fleets. Endpoint DLP and labelling are strongest on Windows; Linux and macOS coverage is materially thinner. Verify against current Microsoft documentation for your exact OS mix rather than assuming parity.
• On-premises and OT. File shares can be brought in with the on-premises scanner, but industrial systems, legacy databases and OT protocols sit entirely outside Purview — which, for most industrial entities, is where the bulk of the risk lives.
• Data in transit. TLS configuration, certificate management and mail transport security are Exchange, network, PKI and Entra ID responsibilities, yet 9.2(a) names data in transit as squarely in scope.

None of this makes Purview the wrong tool. It makes Purview one control domain inside a Section 9 policy that spans the whole estate — and outsourcing the tooling does not outsource the obligation. Recital 83 of the Directive states that the risk-management obligations apply regardless of whether an entity maintains its systems internally or outsources them.

Who does what: a role-by-role close-out plan

Role	Action	Effort
CISO / IT security manager	Decide the key topology per classification tier and document it. Any tier needing evidenced revocation or customer-held backup requires BYOK — the default key cannot support it.	Medium
CISO / IT security manager	Inventory data in transit and at rest outside Microsoft 365, and assign each location a named cryptographic control owner.	High
Compliance officer	Write the Section 9.1 policy and the 9.2(b) algorithm register as standalone documents with owners, review dates, and a trigger tied to changing state of the art. Nothing in the tenant produces these.	Medium
Compliance officer	Export the Compliance Manager assessment on a fixed cadence and store it outside the tenant. Deleting an assessment is permanent [6], and a live dashboard is not an audit record.	Low
IT operations	Check the licence mix of accounts generating your evidence against the 180-day and one-year retention rules [7], and add a custom retention policy where the default is short.	Low
Board / management body	Approve the residual-risk position on Microsoft-managed keys. Under Article 20 this is a management-body decision, not an IT one.	Low

Sequence matters: classification first, because Section 9.1 keys off it; then the written policy; then the key topology the policy commits you to. Teams that buy tooling first usually end up rewriting the policy to match what the tool happens to do. Our audit preparation guide covers what supervisors typically ask to see.

Frequently asked questions

Does deploying Microsoft Purview make us compliant with Article 21(2)(h)?
No. Purview supplies classification, one encryption enforcement channel for Microsoft 365 content, and an evidence register. Article 21(2)(h) requires a policy and procedures covering the whole estate. The policy is a document you write.

Is the Microsoft-managed key acceptable under NIS2?
It can be, for appropriately classified data, if you record it as a deliberate risk-acceptance decision with the reasoning. What is not defensible is a key-management procedure claiming rotation and revocation capability the tenant does not have.

Does the Compliance Manager NIS2 template count as audit evidence?
An exported assessment is a dated snapshot of control status and test results [6], which is useful supporting evidence. It is not a substitute for the underlying policies, key inventory and logs that a supervisor will ask to see.

The productive way to use Purview is as the classification and evidence engine underneath a Section 9 policy that names controls Purview does not own. Start with the policy, and the tooling decisions fall out of it.

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.

Sources

1. NIS 2 Directive, Article 21 — Directive (EU) 2022/2555
2. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex, Annex Section 9
3. CIR 2024/2690: NIS2 Technical Measures — nisd2.eu
4. Manage the root key for your tenant’s Azure Rights Management service — Microsoft Learn
5. Regulations in Microsoft Purview Compliance Manager — Microsoft Learn
6. Build and manage assessments in Compliance Manager — Microsoft Learn
7. Manage audit log retention policies — Microsoft Learn
8. Apply encryption using sensitivity labels — Microsoft Learn
9. Supporting NIS2 implementation through actionable guidance — ENISA, 26 June 2025
10. NIS2 Compliance and Cybersecurity Solutions — Microsoft Trust Center