Microsoft Purview and Intune Hardening: What CIS Benchmark Sections 3 and 4 Check (7 Controls)

The CIS Microsoft 365 Foundations Benchmark v7.0.0 defines 160 controls across 9 sections. Sections 3 and 4 — Microsoft Purview and Microsoft Intune — hold 7 of them between them: 5 in Section 3 and 2 in Section 4. They are the two smallest sections in the benchmark, and they are the two most likely to be treated as rounding error in a remediation plan.

That reading gets the dependency backwards. Most of the benchmark tells you how to configure a surface. These 7 controls establish the two things the rest of the benchmark quietly assumes are already true: that tenant activity is being recorded, and that a device has to prove something before it is trusted. Fix a finding in any other section and you still cannot demonstrate when it was fixed, or by whom, unless Section 3 was already in place.

For an overview of all 9 sections and their control counts, see the CIS Microsoft 365 Foundations Benchmark guide.

How Sections 3 and 4 are structured

Section 3 covers Microsoft Purview and splits its 5 controls across three subsections: 3.1 holds 1 control (audit log search), 3.2 holds 3 (Data Loss Prevention), and 3.3 holds 1 (Information Protection). Section 4 covers Microsoft Intune and has no subsection split at all — its 2 controls are numbered simply 4.1 and 4.2.

The profile and assessment breakdown is the most uniform in the benchmark. All 7 controls are Level 1, and all 7 are automated to assess. By licensing, 5 carry an E3 profile and 2 carry an E5 profile — both of the E5 controls sit in Section 3.2.

Two consequences follow. First, Level 1 in the benchmark means minimal impact on functionality, so there is no trade-off here to negotiate with the business the way there is for the Level 2 controls scattered through Sections 5, 6 and 7. Second, because nothing in either section is a manual control, no reviewer judgement is involved — every one of the 7 either matches the recommended state or it does not.

Sections 3 and 4 are in fact the only two sections in the whole benchmark that are entirely Level 1 and entirely automated. Every other section contains at least one Level 2 control, a manual control, or both. Their usual failure mode is therefore not difficulty. It is that they belong to a different console than the one whoever is driving the assessment has open.

Section 3.1 — Audit log search (1 control)

• 3.1.1 — Ensure Microsoft 365 audit log search is Enabled (E3 Level 1, Automated).

One control, and arguably the highest-leverage single item in the benchmark. Audit log search is what makes tenant activity queryable after the fact — sign-ins, mailbox access, permission changes, sharing events, admin actions.

What makes this control structurally different from every other control in the benchmark is that it is retroactive in one direction only. Disable Safe Links and you are exposed until you re-enable it; re-enable it and you are protected again. Leave audit log search off and you are not merely exposed during that window — you permanently lose the record of it. Turning it on today does not reconstruct last quarter. Any incident investigation, and any audit question that begins with the words when did, is answerable only for the period after this control was satisfied.

How to check: Microsoft Purview compliance portal → Audit. If the portal offers to turn on auditing rather than presenting a search form, the control is failing. See our walkthrough on enabling the unified audit log for the specifics.

Check this one before you start remediating anything else. Every other fix you make is easier to evidence if the log was already running when you made it.

Section 3.2 — Data Loss Prevention (3 controls)

Three controls, and the only place in Sections 3 and 4 where E5 licensing enters the picture.

• 3.2.1 — Ensure DLP policies are enabled (E3 Level 1, Automated). The baseline: at least one Data Loss Prevention policy is in force. DLP inspects content against rules and acts on matches, which is a different mechanism from the labelling in 3.3.1 — DLP responds to what a file or message contains, labelling responds to what someone has declared it to be.
• 3.2.2 — Ensure DLP policies are enabled for Microsoft Teams (E5 Level 1, Automated). Teams is a separate DLP location, not an inherited one. A tenant can satisfy 3.2.1 with policies scoped to Exchange and SharePoint and still fail this control — an easy state to end up in when the original policy was written while email was the assumed channel for anything sensitive. The Section 8 controls govern how Teams shares files; this one governs what those shares are inspected for.
• 3.2.3 — Ensure DLP policies are published for Copilot users (E5 Level 1, Automated). The newest concern in the section. Copilot has no permission model of its own — it surfaces content the requesting user could already reach, which means it can assemble scattered material into a single answer far faster than anyone would have found it by browsing. DLP scoped to Copilot is what keeps that summarisation inside the same boundary as the rest of the tenant.

How to check: Microsoft Purview compliance portal → Data loss prevention → Policies. For 3.2.2 and 3.2.3, the thing to inspect is not whether policies exist but which locations each one is scoped to.

Section 3.3 — Information Protection (1 control)

• 3.3.1 — Ensure Information Protection sensitivity label policies are published (E3 Level 1, Automated).

The distinction the benchmark draws here is between labels that have been created and labels that have been published. An unpublished label exists in the admin portal and nowhere else — it is invisible to users, cannot be applied, and satisfies nothing. Publishing is what pushes labels into a label policy that reaches actual people.

This is the control that makes labelling elsewhere in the tenant meaningful. Section 9 contains a Fabric setting that permits sensitivity labels on analytics content; that setting has nothing to inherit until 3.3.1 is satisfied. The same holds for label-aware behaviour in SharePoint and Teams.

How to check: Microsoft Purview compliance portal → Information protection → Label policies. A populated Labels tab alongside an empty Label policies tab is the failure state this control is written for.

Section 4 — Microsoft Intune (2 controls)

The smallest section in the benchmark. Two controls, both E3 Level 1, both automated, and both about defaults rather than about any individual device.

• 4.1 — Ensure devices without a compliance policy are marked ‘not compliant’ (E3 Level 1, Automated). This inverts a fail-open default. Where the setting is left permissive, a device that no compliance policy happens to target is reported as compliant — not because it was evaluated and passed, but because it was never evaluated. That is the distinction the control exists to close: absence of a verdict should not read as a pass.
• 4.2 — Ensure device enrollment for personally owned devices is blocked by default (E3 Level 1, Automated). Personal devices enrol by default unless the tenant declares otherwise, which means the population of devices holding tenant data grows without any decision being made. Blocking by default does not prohibit personal devices; it makes admitting them an explicit act.

How to check: Microsoft Intune admin center → Devices → Compliance policies → Compliance policy settings for 4.1, and Devices → Enrollment restrictions for 4.2.

Why 7 controls carry more weight than their count suggests

Both sections sit upstream of work you have probably already done elsewhere.

Control 4.1 is the clearest case. Conditional Access policies that require a compliant device are a significant part of Section 5, and they are only as strong as the definition of compliant they consume. With 4.1 failing, a Conditional Access rule that grants access to compliant devices will admit any device no policy targets. The rule is configured correctly, it evaluates correctly, and it lets the device through — because the input it trusted was wrong. Nothing in Section 5 can detect that; the fault is not in Section 5.

Control 3.1.1 is the other case. It prevents nothing. It determines whether you can answer questions later — which is the entire basis of an evidence-driven audit, and the one capability you cannot acquire retroactively.

The practical failure pattern for both sections is organisational rather than technical. Purview and Intune have their own consoles and often their own owners — a compliance or records team for Purview, an endpoint or device team for Intune. Someone working through the benchmark from the Microsoft 365 admin center reaches Section 3, finds it belongs to another team, and moves on to Section 5 where there is more to do. Seven controls, all Level 1, all automated, get deferred indefinitely — not because anyone judged them low priority, but because nobody in the room could action them.

How ConfigCobra assesses Sections 3 and 4

ConfigCobra evaluates all 7 Section 3 and Section 4 controls as part of a full CIS Microsoft 365 Foundations Benchmark v7.0.0 assessment. The scan connects to your tenant using read-only Microsoft Graph permissions — no agents, no admin password sharing — and returns results for all 160 controls across all 9 sections in 20–25 minutes.

Each finding comes back with its status against the recommended state, the evidence behind it, the severity tagged from the benchmark itself, and a copy-paste remediation script or admin portal steps. Results export to a CIS-certified PDF report with a timestamped tenant snapshot.

For these two sections in particular, that cross-console coverage is the point: a single scan reports on Purview and Intune alongside the rest of the tenant, so a control does not go unassessed because its console was never opened. And because DLP and label policies are edited far more often than tenant toggles are, continuous scanning and drift detection is what catches a Section 3 control regressing after a policy is rescoped — you are alerted when it happens, rather than discovering it at the next audit.

Run it against your own tenant

Start a free trial, 14 days with full access, to find out whether audit log search is currently enabled in your own tenant — and how far back your evidence actually goes.

The rest of the series

• Section 1 — Microsoft 365 admin center (15 controls)
• Section 2 — Microsoft Defender for Office 365 (21 controls)
• Section 5 — Microsoft Entra (Identity) (63 controls)
• Section 6 — Exchange Online (13 controls)
• Section 7 — SharePoint Online and OneDrive (12 controls)
• Section 8 — Microsoft Teams (17 controls)
• Section 9 — Microsoft Fabric and Power BI (12 controls)

With Sections 3 and 4 covered, the series now spans all 9 sections and all 160 controls of the benchmark. For the full overview including every section control count, see the CIS Microsoft 365 Foundations Benchmark page.