3.1 Microsoft Purview for Security Operations

Microsoft Purview for Security Operations

Introduction

Microsoft Purview is a large platform. It includes data governance, data catalog, information protection, data lifecycle management, records management, communication compliance, and a dozen other capabilities aimed at compliance officers, data stewards, and privacy teams. As a SOC analyst, you use approximately 10% of Purview’s surface area — but that 10% is critical to your investigations.

When an attacker compromises a user’s account, you use Defender XDR to detect the compromise and Entra ID to trace the authentication. But when you need to answer the question “what data did the attacker access?” — that answer lives in Purview. The unified audit log records every file opened, every email read, every SharePoint document downloaded, every Teams message sent. DLP policies detect when sensitive data crosses a boundary it should not cross. Insider risk management detects when a user’s data access pattern deviates from their historical baseline in ways that suggest theft, sabotage, or carelessness.

This subsection maps the four Purview components you will use as a SOC analyst, explains how Purview data flows into your existing investigation tools (the Defender XDR portal and Sentinel), clarifies the licensing that determines which investigation capabilities are available, and defines the role boundaries between security operations and compliance teams.

The four Purview components for SOC analysts

Purview is a broad platform, but for security operations, you interact with four components:

Data Loss Prevention (DLP) monitors data in motion — emails being sent, files being shared, content being uploaded to cloud services, data being copied to USB devices. DLP policies define what “sensitive data” means (credit card numbers, social security numbers, proprietary document labels, healthcare records) and what constitutes a policy violation (sending sensitive data to an external recipient, uploading it to an unauthorized cloud service, copying it to a removable drive). When a violation is detected, DLP generates an alert that appears in the Defender XDR incident queue alongside endpoint and identity alerts. DLP alerts tell you that sensitive data crossed a boundary — your investigation determines whether it was an attacker exfiltrating stolen data, an insider intentionally leaking information, or an employee accidentally sending the wrong attachment.

DLP operates across multiple workloads: Exchange Online (email), SharePoint Online and OneDrive (file storage), Microsoft Teams (messages and shared files), endpoint devices (file copy, print, clipboard operations), Power BI (report sharing), and third-party cloud apps through Defender for Cloud Apps integration. Each workload has its own policy configuration and its own alert characteristics, but all DLP alerts converge in the same investigation queue.

Insider Risk Management (IRM) monitors data access patterns over time. Unlike DLP, which looks at individual events (this email contains a credit card number), IRM looks at sequences of behavior (this user downloaded 500 files in the last 2 hours, then connected a USB drive, then visited a personal cloud storage site — and they submitted their resignation last week). IRM builds a risk profile for each user based on triggering events (resignation, performance improvement plan, impending termination), sequence indicators (increasing data access volume, new external sharing, USB device usage), and cumulative risk scores that escalate as more indicators fire.

IRM is uniquely sensitive because it monitors employee behavior. Investigations are handled through a separate case management system in the Purview portal, with restricted access, privacy controls, and mandatory coordination with HR and legal teams. As a SOC analyst, you may be involved in IRM investigations — particularly when an insider risk alert overlaps with a security incident (a compromised account that also shows data exfiltration patterns) — but IRM investigations have procedural requirements that differ from standard security incident response.

Unified Audit Log is the forensic backbone of every Purview investigation and many Defender XDR investigations. The audit log captures every user and administrator action in Microsoft 365: every file opened in SharePoint, every email read in Outlook, every Teams message sent, every admin configuration change, every PowerShell command executed against Exchange Online. For a SOC analyst, the audit log answers the post-compromise question: “The account was compromised at 09:14 — what did the attacker do between 09:14 and the time we contained it at 11:30?” The audit log provides a minute-by-minute record of every action.

The audit log exists in two tiers — Audit (Standard) and Audit (Premium) — with significantly different capabilities. The tier distinction is one of the most important licensing decisions for security operations and is covered in depth in subsection 3.6.

eDiscovery is primarily a legal and compliance tool, but SOC analysts use it when an investigation requires locating specific content — a particular email, a specific document, a Teams conversation. During a BEC investigation, you might need to find all emails the compromised account sent to external recipients during the compromise window. During a data exfiltration investigation, you might need to identify exactly which documents were in a SharePoint folder that was downloaded. Content Search (the search component of eDiscovery) lets you search across all M365 content stores — mailboxes, SharePoint sites, OneDrive accounts, and Teams channels — using keywords, date ranges, sender/recipient filters, and content type filters.

eDiscovery also provides legal hold capabilities. When a security investigation may lead to legal proceedings (insider threat, regulatory violation, litigation), placing content on legal hold preserves it from deletion — even if the user attempts to delete emails or files. SOC analysts need to understand when to request a legal hold (typically through coordination with legal counsel) and how hold status affects the investigation workflow.

How Purview data flows into your investigation tools

Purview data does not live in an isolated silo — it flows into the same investigation tools you already use.

DLP alerts → Defender XDR incident queue. When a DLP policy fires, the alert appears in the unified incident queue in the Defender portal (security.microsoft.com). DLP alerts are correlated with other alert types — if a compromised account triggers both an identity alert (anomalous sign-in) and a DLP alert (sensitive data sent to external recipient), the correlation engine groups them into a single incident. You triage DLP alerts using the same workflow you learned in Module 1.2.

Audit data → Sentinel tables. When the Microsoft 365 data connector is configured in Sentinel (Module 7/8), audit log data flows into the OfficeActivity table and the CloudAppEvents table (via the Defender XDR connector). This means you can query audit data using the same KQL you write for sign-in logs and endpoint telemetry. The integration is seamless — a single union query can combine sign-in events, endpoint process events, and audit log entries into one investigation timeline.

Insider risk alerts → Purview portal + optional Sentinel integration. IRM alerts appear in the Purview portal’s insider risk management section, not in the Defender XDR queue (due to the sensitivity and access controls around insider risk investigations). However, IRM can be configured to send alert signals to Sentinel via the Microsoft Purview Insider Risk Management connector, enabling SOC teams to correlate insider risk indicators with other security signals.

eDiscovery results → export for evidence. eDiscovery search results can be exported as PST files (for email), individual files (for documents), or summary reports. These exports become evidence artifacts in your incident report (Module 14) and may be provided to legal counsel, HR, or regulatory authorities.

The Purview portal vs the Defender portal

Purview capabilities are accessible through two portals, and the distinction matters for your workflow.

The Microsoft Purview portal (purview.microsoft.com) is where compliance teams configure DLP policies, create insider risk policies, manage audit log settings, and run eDiscovery cases. As a SOC analyst, you access the Purview portal for insider risk case management (the IRM case workflow runs here, not in Defender), audit log search (the dedicated search interface lives here, though the data is also available in Sentinel), and eDiscovery case creation and content search.

The Microsoft Defender portal (security.microsoft.com) is where DLP alerts appear in the incident queue. DLP alert investigation, triage, and remediation happen here — using the same investigation workflow as endpoint and identity alerts. The Defender portal also provides access to Advanced Hunting, where you can query Purview-related tables (CloudAppEvents, OfficeActivity) using KQL.

The practical implication: your daily triage workflow stays in the Defender portal. You only switch to the Purview portal when an investigation requires insider risk case management, a dedicated audit log search, or an eDiscovery content search. For DLP alerts, you never need to leave the Defender portal.

Licensing: what investigation capabilities are available at each tier

Purview licensing directly affects your investigation capabilities. The most critical distinction is between Audit (Standard) and Audit (Premium), but DLP and IRM also have licensing-dependent features.

MailItemsAccessed: the event that changes everything

MailItemsAccessed deserves special attention because it fundamentally changes what you can investigate during a compromised mailbox incident.

Without MailItemsAccessed (E3 and below), you know that a compromised account existed and you know what emails were sent (from the MessageTrace/EmailEvents logs). But you do not know which emails the attacker read. An attacker who compromises a mailbox, reads 200 emails containing financial data, and sends none of them has zero visibility in E3 audit logs. You can prove the account was compromised. You cannot prove which data the attacker accessed. This creates a notification problem — when you report the incident to your CISO, the answer to “what data was exposed?” is “we don’t know.”

With MailItemsAccessed (E5), every email access event is recorded: which message was accessed, the access method (Bind = opened/read, Sync = synced to a client), the client application, the IP address, and the timestamp. After an account compromise, you can reconstruct exactly which emails the attacker read, when they read them, and from which IP address. The investigation goes from “the account was compromised” to “the attacker read 47 emails between 09:14 and 11:30, including 12 emails containing financial forecasts and 3 emails containing customer PII.”

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// MailItemsAccessed — reconstruct what a compromised account read
// REQUIRES: E5 or E5 Compliance add-on
CloudAppEvents
| where Timestamp > ago(48h)
| where AccountId =~ "j.morrison@northgateeng.com"
| where ActionType == "MailItemsAccessed"
| extend OperationType = tostring(RawEventData.OperationProperties[0].Value)
| extend ClientApp = tostring(RawEventData.ClientAppId)
| extend MailboxOwner = tostring(RawEventData.MailboxOwnerUPN)
| where OperationType == "Bind"  // Bind = actually opened/read
| summarize EmailsAccessed = count(),
    FirstAccess = min(Timestamp),
    LastAccess = max(Timestamp),
    ClientApps = make_set(ClientApp, 5)
    by bin(Timestamp, 1h), IPAddress
| order by Timestamp asc

This query — and this investigation capability — is only possible with MailItemsAccessed, which requires E5. In subsection 3.7, you will build on this query to reconstruct complete compromised mailbox access timelines.

Role boundaries: security operations vs compliance

Purview serves two distinct teams with overlapping but different responsibilities. Understanding the boundary matters because it affects your access, your authority, and the procedures you follow.

SOC analysts investigate specific incidents. You receive a DLP alert, determine whether data was exfiltrated, and remediate. You search the audit log to reconstruct what a compromised account did. You run eDiscovery searches to locate specific evidence. Your focus is reactive: something happened, and you determine what, how, and how bad.

Compliance officers manage the policy framework. They create DLP policies, configure insider risk indicators, define sensitivity labels, and review compliance reports. Their focus is proactive: they build the detection and classification infrastructure that generates the alerts you investigate.

The practical implication for RBAC: SOC analysts typically need the Security Reader and Security Operator roles in the Defender portal (for DLP alert investigation) plus the Reviewer or Investigator role in the Purview portal (for audit search and eDiscovery). They do not need the Compliance Administrator role (which controls policy creation). If your organization has not configured these role assignments, you may find yourself unable to access audit log search or eDiscovery — raise this with your security operations manager as a Day 1 setup item.

Insider risk is different. IRM investigations are gated behind the Insider Risk Management Analyst and Insider Risk Management Investigator roles, which are separate from the standard security roles. Access to IRM data is deliberately restricted because it contains sensitive employee behavioral information. Even if you have full security administrator access, you cannot see IRM cases unless you are explicitly assigned an IRM role. This is by design — IRM investigations involve HR and legal considerations that require controlled access.

The investigation question Purview answers

In every investigation module from Module 11 onward, you will reach a point where the question shifts from “what happened to the system?” to “what happened to the data?” Module 1 teaches you to investigate what the attacker did. Module 2 teaches you to investigate how the attacker operated on the endpoint. This module teaches you to investigate what the attacker accessed.

The investigation flow follows a consistent pattern across all Purview-related investigations:

Detection occurs through a DLP alert (sensitive data crossed a boundary), an insider risk alert (anomalous user behavior detected), or a security investigation extending into data access questions (you already know the account is compromised from Modules 1 and 2, and now you need to assess data exposure).

Investigation uses audit log search to reconstruct the timeline of data access, eDiscovery to locate the specific content that was accessed, and KQL queries against CloudAppEvents and OfficeActivity to correlate data access events with the broader incident timeline.

Assessment determines the scope and severity of data exposure — how many documents were accessed, how many contained sensitive data, whether the data was downloaded or only viewed, and whether the data left the organization’s control.

Remediation includes revoking access (handled through Defender XDR containment), preserving evidence (eDiscovery legal hold), notifying affected parties (if personal data was exposed, GDPR/regulatory notification may be required), and updating policies to prevent recurrence (DLP policy tuning, sensitivity label enforcement).

Knowledge check