Docs

Appearance

Microsoft Purview DLP Operations Guide ​

Overview ​

Day-to-day operations for Microsoft Purview Data Loss Prevention policies at Cirius Group. DLP protects PHI (Protected Health Information) across Exchange Online, SharePoint Online, OneDrive for Business, and Microsoft Teams in the ciriusgroup.com tenant (d477c9f8).

Current deployment: policies are in Test mode (report-only with policy tips). Enforce mode transition is gated on the criteria in purview-dlp-enforce-mode-criteria.md.

DLP is a compensating control for HIPAA §164.312(e)(2)(ii) (encryption in transit) and §164.312(a)(1) (access controls). Evidence gathered here feeds HIPAA audits, HITRUST assessments, and SOC 2 reviews.

For identity and Conditional Access see Entra Identity Operations. For how DLP findings appear in SecOps see SecOps Findings Triage.

1. Navigating the Purview Compliance Portal ​

Getting There ​

DestinationURL
Purview compliance portal (root)https://compliance.microsoft.com
DLP policies listhttps://compliance.microsoft.com/datalossprevention
DLP alertshttps://compliance.microsoft.com/datalossprevention/alerts
Activity Explorerhttps://compliance.microsoft.com/dataclassification/activityexplorer
DLP reportshttps://compliance.microsoft.com/reports/dlpreports
Content Explorerhttps://compliance.microsoft.com/dataclassification/contentexplorer

Log in with your @ciriusgroup.com admin account. You need the Compliance Administrator or Security Administrator Entra role. Rory holds both. Kobe has read-only access via Compliance Data Administrator (view alerts and reports, no policy changes).

Portal Structure ​

The left nav in compliance.microsoft.com groups everything under Data loss prevention:

  • Overview — policy tip count, alert count, DLP matches over time (14-day default view)
  • Policies — all DLP policies, their mode, and the workloads they cover
  • Alerts — DLP alerts requiring triage (separate from the full activity stream)
  • Activity explorer — granular per-event view of every DLP match
  • Reports — aggregate trend charts (not for per-event investigation)

Alert severity: Purview uses Low / Medium / High. Set threshold under each policy's alert rule. PHI-matching policies should fire at High.

2. Understanding Current Policies ​

Policy Inventory ​

All policies are in Test mode with policy tips (report-only). No user action is blocked. Policy tips surface in Outlook, Teams, and web apps to notify the user a sensitive item was detected.

Policy NameWorkloadsSensitive Info TypesMode
HIPAA PHI — EmailExchange OnlineSSN, MRN, DOB combos, health plan IDsTest
HIPAA PHI — SharePoint/OneDriveSharePoint Online, OneDriveSSN, MRN, DOB combos, health plan IDs, patient intake fieldsTest
HIPAA PHI — TeamsTeams chat and channel messagesSSN, MRN, DOB combosTest
Financial Data — All WorkloadsExchange, SPO, OD, TeamsCredit card, bank account, ABA routing numbersTest

Custom SIT: Cirius-PatientIntake — matches patient intake form field patterns specific to Cirius workflows. Defined under Data classification → Sensitive info types in the portal.

What Policies Protect ​

PHI-specific sensitive information types in scope:

  • U.S. Social Security Number (SSN) — standalone
  • U.S. / UK passport number when co-located with diagnosis codes
  • Medical Record Number (MRN) — custom pattern
  • Date of birth (DOB) in combination with name + any medical identifier
  • U.S. Health Insurance Beneficiary Number
  • U.S. Health Plan Identifier (HPID)
  • ICD-9/ICD-10 diagnosis codes appearing near patient-name patterns
  • Cirius-PatientIntake custom SIT

File types in scope for SharePoint/OneDrive:

  • Office documents (.docx, .xlsx, .pptx, .pdf)
  • Plain text and CSV files matching PHI patterns
  • Email with attachments (Exchange policy captures both the body and attachments)

File types excluded by design:

  • .zip archives (content is not inspected — risk accepted, documented in risk-acceptance-register.md)
  • Encrypted PDFs where content cannot be extracted

Policy Scope Details ​

Exchange Online: covers outbound email from ciriusgroup.com. Internal-only traffic (sender and all recipients @ciriusgroup.com) still matches — DLP logs it even though it stays inside the tenant. Policy tips appear in Outlook desktop and OWA.

SharePoint Online: covers all sites. Adriana uploads BAA, vendor, and risk docs to SharePoint — these are the primary PHI-adjacent files in scope. Her uploads are the most common match source during the observation window.

OneDrive for Business: covers all user OneDrive folders. Includes synced desktop folders.

Microsoft Teams: covers chat messages and channel messages. Does not inspect files shared in Teams — those are stored in SharePoint and covered by the SPO policy.

Endpoint DLP: not yet deployed. Covered in the Q3 2026 roadmap.

Viewing a Policy in the Portal ​

  1. compliance.microsoft.com → Data loss prevention → Policies
  2. Click the policy name
  3. Policy settings tab: shows mode, locations (workloads), and whether policy tips are enabled
  4. Rules tab: shows each rule within the policy, the SITs it detects, the confidence level threshold, and the action (currently: generate alert + show policy tip)
  5. Conditions tab inside a rule: shows exact SIT combinations and instance count thresholds (e.g., "content contains SSN with high confidence AND at least 1 instance")

3. Investigating a DLP Alert ​

Finding Alerts ​

compliance.microsoft.com → Data loss prevention → Alerts

Alerts are listed newest-first. Each row shows: alert name, severity, status (New / Investigating / Dismissed / Resolved), the policy that fired, and the time.

What an Alert Contains ​

Open an alert to see:

FieldWhat It Tells You
UserWho triggered the policy (the sender or the file owner)
ActivityThe action: email sent, file shared, file uploaded, chat message sent
LocationWhere it happened (Exchange, SharePoint site URL, OneDrive path, Teams channel)
PolicyWhich DLP policy matched
RuleWhich rule within the policy matched
Action takenIn Test mode: Generate alert + Policy tip. In Enforce: Block or Restrict.
Sensitive info typeWhich SIT(s) matched and at what confidence level
Instance countHow many instances of the SIT were detected in this item
TimestampUTC. Convert to Pacific for user conversations.

Getting Full Content Match Context ​

The alert shows that a match occurred but does not show the actual content by default. To see the matched text:

  1. Open the alert → click View details
  2. Scroll to Sensitive info detected section
  3. Click Show evidence — this shows a snippet of the matched text with the sensitive value partially masked (e.g., SSN: ***-**-1234)
  4. For the full unmasked content: you must have the Compliance Data Administrator or Compliance Administrator role AND the policy must have Evidence collection enabled

Evidence collection is configured per-policy under Incident reports. If it is not enabled, you only see the SIT type and count, not the matched text. Enable it for PHI policies:

Policy → Rules → (rule name) → Incident reports → Collect evidence of matching content

Check this is enabled before the next observation window. Without it, HIPAA audit evidence is incomplete.

PowerShell — Pull Alert Details ​

powershell
# Connect (run once per session)
Connect-IPPSSession -UserPrincipalName admin@ciriusgroup.com

# List recent DLP alerts (last 7 days)
Get-DlpCompliancePolicy | Select-Object Name, Mode, Enabled

# Get DLP incidents from the audit log
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
  -RecordType DlpRuleMatch -ResultSize 100 | Select-Object -ExpandProperty AuditData | `
  ConvertFrom-Json | Select-Object CreationTime, UserId, Operation, PolicyName, RuleName, `
  Workload, SensitiveInfoTypeName, Count | Format-Table -AutoSize
powershell
# Get details for a specific user's DLP matches in the last 30 days
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
  -RecordType DlpRuleMatch -UserIds "adriana@ciriusgroup.com" -ResultSize 500 | `
  Select-Object -ExpandProperty AuditData | ConvertFrom-Json | `
  Select-Object CreationTime, PolicyName, RuleName, Workload, SensitiveInfoTypeName, `
  Count, ObjectId | Format-Table -AutoSize

4. Triage Workflow ​

Step 1 — Identify the Match Source ​

When an alert fires, answer these questions before deciding anything:

  1. Who is the user? Is this someone who legitimately handles PHI (Adriana, billing staff, clinical coordinators) or an unexpected user (IT, external contractor)?
  2. What workload? Email leaving the org is higher risk than a SharePoint upload to an internal site.
  3. What SIT matched? SSN or MRN is higher fidelity than DOB alone (DOB has high false-positive rate — many documents contain birthdates that are not patient records).
  4. What confidence level? High confidence (85%+) is more likely real. Low confidence (65%–85%) generates more false positives.
  5. Instance count? A single instance in an internal SharePoint doc is lower priority than 50 instances in an outbound email.

Step 2 — Classify: Real Violation or False Positive? ​

Indicators of a real policy violation (PHI at risk):

  • Outbound email to a non-ciriusgroup.com domain containing SSN + name + DOB
  • SharePoint file shared externally (Guest sharing link) with high-confidence PHI matches
  • Teams message to a guest user containing MRN or health plan ID
  • Any match from a user with no clinical role (IT admin, developer, finance)

Indicators of a false positive:

  • DOB matches in a document that is clearly not patient data (e.g., a meeting agenda containing someone's birthday)
  • SSN match on a document that is an internal HR form (SSN of an employee, not a patient)
  • MRN match where the "MRN" pattern collides with a product SKU or invoice number (check the evidence snippet)
  • Adriana uploading a vendor contract to SharePoint — BAA documents may contain boilerplate language that pattern-matches SITs without containing actual patient data
  • High-frequency matches from a single user on a known workflow (e.g., billing batch files uploaded at month-end — these are legitimate and expected)

HIPAA-specific guidance:

PHI is individually identifiable health information. A document containing a patient name AND a medical identifier (SSN, MRN, diagnosis code) is PHI regardless of intent. If the SIT match is high confidence and the document type is plausibly clinical, treat it as real until proven otherwise. The burden of proof for "this is fine" should be explicit confirmation that the content is not patient data — not just an assumption.

Step 3 — Decide and Act ​

FindingAction
Real violation, data was not exposed (internal, no external share)Log in alert notes. No immediate remediation needed. Document for monthly review.
Real violation, data was shared externallyEscalate to Rory immediately. Follow Incident Response.
Real violation, repeat offenderEscalate to Rory. Consider targeted user training.
False positive, low confidence match, internal docDismiss the alert with a note. Document the FP pattern.
False positive, known workflow (month-end billing)Dismiss with note. Propose a policy exclusion for that workflow.
Unclear — cannot tell from alert contextPull full evidence (see section 3). If still unclear, escalate to Rory.

When to Escalate to Rory ​

  • Any outbound email to an external domain with high-confidence PHI match
  • Any externally accessible SharePoint/OneDrive link containing PHI
  • Any match from a break-glass account or a service principal
  • False-positive rate for any policy exceeds 2% in a rolling 7-day window
  • A pattern of matches from the same user over multiple days with no clear legitimate explanation
  • Any match that could indicate a data exfiltration attempt (large volume, unusual time of day, destination outside normal workflow)

5. Managing False Positives ​

In Test Mode (Current State) ​

In Test mode, no user is blocked. False positives only generate alerts and policy tips. Actions available:

Dismiss the alert: Portal → Alerts → open alert → Dismiss → select reason → add a note.

Reason options:

  • Not a policy violation — the content is not actually PHI
  • Expected business activity — a known workflow that legitimately uses this data
  • True positive, accepted risk — the content is PHI but the risk is accepted (document why in the note field)

Override in the alert record: If a user saw a policy tip and confirmed the override in the app (Outlook, Teams), the audit log records their override reason. You can view this in Activity Explorer.

In Enforce Mode (After Transition) ​

When a policy is in Enforce mode, a block is a real user impact. Three levels of exception:

1. User self-override (business justification): The user sees the policy tip and can click "Override" with a business justification reason. This is logged in the audit trail. It does not require admin action. Appropriate for one-off exceptions where the user can confirm the content is not PHI.

Configure allowed user overrides under: Policy → Rules → User notifications → Allow override

Set to: "Require a business justification" (not "Allow without justification") so every override is logged with a reason string.

2. Admin override (incident exception): If a user is blocked and needs immediate unblock and cannot self-override, Rory can release the item:

  • For email: Exchange Admin Center → Mail flow → Message trace → locate the held message → Release
  • For SharePoint/OneDrive: Purview portal → Content Explorer → locate the file → release the hold

Always document admin overrides in SecOps as a finding with justification.

3. Policy exception (permanent exclusion): For a recurring false-positive pattern that would generate repeated blocks, create a policy exception rather than repeatedly dismissing alerts:

Policy → Rules → (rule name) → Conditions → Add exception

Exception types:

  • Exclude a specific user or group (e.g., exclude the billing service account from the SSN rule because it only processes internal payroll)
  • Exclude a specific SharePoint site (e.g., a dedicated archive site with controlled access)
  • Exclude a specific sender domain in Exchange
  • Narrow the SIT confidence threshold (raise the minimum confidence level to reduce low-confidence noise)

HIPAA documentation requirement: Any policy exception in a HIPAA environment must be documented. Required fields:

  • Date of exception
  • Rule and policy affected
  • Justification (why the exception does not create PHI exposure risk)
  • Approver (Rory)
  • Review date (no exception is permanent — review at least annually)

Log exceptions in the SecOps compliance register under DLP Exceptions. The exception record is audit evidence.

Tracking False-Positive Rate ​

Keep a running FP count per policy in the SecOps compliance register. The enforce-mode criteria gate requires FP rate < 2% over the observation window.

powershell
# Pull all DLP rule matches for a policy over the last 30 days
# Use this as the denominator (total matches = N)
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
  -RecordType DlpRuleMatch -ResultSize 5000 | `
  Select-Object -ExpandProperty AuditData | ConvertFrom-Json | `
  Where-Object { $_.PolicyName -eq "HIPAA PHI - Email" } | `
  Measure-Object | Select-Object Count

Dismissed alerts with reason Not a policy violation are your FP count (numerator). FP rate = (dismissed as FP) / (total matches).

6. Switching a Policy from Test to Enforce ​

Prerequisites ​

All eight criteria in purview-dlp-enforce-mode-criteria.md must be satisfied and signed off by Rory. Summary:

  1. 30-day observation window complete (covers at least one billing cycle)
  2. FP rate < 2% over the observation window
  3. DLP training delivered to all PHI-handling staff
  4. Policy tip copy reviewed and approved by Rory
  5. Exception process documented and end-to-end tested
  6. Telemetry wired: Purview events → LAW, block-rate alert configured
  7. Rollback procedure documented and tested
  8. Rory formal written approval naming the specific policy and go-live date

The Change Process ​

Option A — Portal change (for one-off flips):

  1. Open a CM ticket in SecOps (POST /api/changes) before making the change
  2. compliance.microsoft.com → Data loss prevention → Policies
  3. Click the policy → Edit policy
  4. Navigate to Policy mode page
  5. Select Turn it on right away (Enforce mode)
  6. Review the summary — confirm the rule actions now say "Block" (not "Audit")
  7. Click Submit
  8. Screenshot the confirmation and attach to the CM ticket

Option B — Terraform (if the policy is Terraform-managed):

Check azure-infra repo: modules/purview-dlp/ — if the policy exists there, use Terraform.

hcl
# In the policy resource, change:
mode = "TestWithNotifications"
# to:
mode = "Enable"

Open a PR, include the CM ticket number in the PR description. CI runs plan. Rory reviews. Merge deploys. The GitHub Actions CM integration auto-links the PR to the CM ticket.

Monitoring After Enforcement ​

The first 72 hours after flipping a policy to Enforce are the highest-risk window for false-positive blocks. Monitor:

Alert volume: Expected to be consistent with Test mode. A spike > 2x the Test-mode baseline in the first 24 hours indicates a workflow was missed during observation.

Help desk tickets: Any "I can't send this email" or "SharePoint blocked my upload" ticket should be treated as a potential DLP false positive first. Check the DLP alert queue.

Override rate: If > 10% of blocks are being user-overridden, the SIT confidence threshold is too low or a workflow was not excluded. Pull the data:

compliance.microsoft.com → Activity explorer → filter: Activity = User override

  • Date range = last 24 hours

Rollback trigger: If block rate spikes > 2x baseline AND verified false positives are being created for a known legitimate workflow, initiate rollback immediately without waiting for root cause. Rollback first, investigate second.

Rollback Procedure ​

  1. Open a CM ticket documenting the reason
  2. compliance.microsoft.com → Data loss prevention → Policies → select policy
  3. Edit policy → Policy mode → Test it out first (with policy tips)
  4. Submit — the policy returns to Test mode immediately
  5. Notify affected users that the block has been lifted (Rory coordinates this)
  6. Document the rollback in the CM ticket and in the SecOps compliance register
  7. Conduct a post-rollback review: what workflow was missed, what SIT refinement or exclusion is needed before the next enforce attempt

7. Creating a New DLP Policy ​

When You Need a New Policy ​

  • A new business workflow begins handling a sensitive data type not covered by existing policies (e.g., a new financial integration that processes bank account numbers)
  • A workload comes online that is not currently in scope (e.g., Endpoint DLP for Windows devices when that rollout happens)
  • A regulatory requirement identifies a gap in current policy coverage
  • A red team or pentest finding demonstrates that data can be exfiltrated through a path the current policies do not watch

Never create a new policy without a defined observation window and Rory approval. New policies always start in Test mode.

Policy Creation Walkthrough ​

compliance.microsoft.com → Data loss prevention → Policies → + Create policy

Step 1 — Start with a template or custom:

  • HIPAA: use Medical and health → U.S. Health Insurance Act (HIPAA) template as the starting point. The template pre-selects relevant SITs.
  • Custom: select Custom → Custom policy if you need a SIT combination not in a template.

Step 2 — Name and description: Follow the naming convention: [Framework] [Data Type] — [Workload] Example: HIPAA PHI — Endpoint

Step 3 — Choose locations (workloads): Select only the workloads this policy needs to cover. Do not enable all workloads by default — scope precisely to reduce noise.

WorkloadTurn on when
Exchange emailPolicy covers email in transit
SharePoint sitesPolicy covers document storage
OneDrive accountsPolicy covers user file sync
Teams chat and channel messagesPolicy covers real-time messaging
Devices (Endpoint DLP)Endpoint DLP agent deployed on managed devices

Step 4 — Define the policy settings (rules):

Each rule within a policy defines:

  • Conditions: which SITs, at what confidence level, with what instance count
  • Actions: what happens when the rule matches
  • User notifications: whether to show a policy tip
  • User overrides: whether users can override the block with a business justification
  • Incident reports: severity level, who gets notified (compliance officer), whether evidence is collected

Key settings for PHI policies:

  • Confidence level: High (85%+) for blocking rules. Use Medium (75%+) for audit-only rules that feed the observation window.
  • Instance count: minimum 1 for outbound email rules (one SSN in an external email is a violation). Minimum 5 for SharePoint rules where a batch document with multiple records is the expected format.
  • Evidence collection: ON — required for HIPAA audit trail.
  • Incident reports: High severity — ensures alerts land in the Alerts queue.
  • Send email notifications to: compliance admin (Rory's admin account).

Step 5 — Policy mode: Always select Test mode with policy tips for new policies.

Step 6 — Review and submit.

After creation, confirm the policy appears in the policy list and that the mode shows "Test". Wait 24 hours for the policy to propagate fully across all workloads before treating the observation window as started.

PowerShell — Create or Modify Rules ​

For programmatic changes to existing rule settings (threshold, SIT list) without a full portal walkthrough:

powershell
Connect-IPPSSession -UserPrincipalName admin@ciriusgroup.com

# View existing rules for a policy
Get-DlpComplianceRule -Policy "HIPAA PHI - Email" | Select-Object Name, Disabled, `
  BlockAccess, GenerateAlert, GenerateIncidentReport | Format-Table -AutoSize

# Modify the confidence threshold on a rule
Set-DlpComplianceRule -Identity "HIPAA PHI - Email - Rule 1" `
  -ContentContainsSensitiveInformation @{Name="U.S. Social Security Number (SSN)"; `
  minCount="1"; minConfidence="85"}

# Switch a policy to Enforce mode (production change — requires CM ticket first)
Set-DlpCompliancePolicy -Identity "HIPAA PHI - Email" -Mode Enable

# Switch back to Test mode (rollback)
Set-DlpCompliancePolicy -Identity "HIPAA PHI - Email" -Mode TestWithNotifications

8. Activity Explorer ​

Activity Explorer is the primary investigation tool for data movement events. It shows every DLP match event with user, item, rule, action, and (where evidence collection is enabled) content snippet. Use it for detailed triage and HIPAA audit evidence export.

compliance.microsoft.com → Data classification → Activity explorer

Or direct: https://compliance.microsoft.com/dataclassification/activityexplorer

Default view is the last 30 days. The chart at the top shows event volume over time. The table below shows individual events.

Key Filters for PHI Investigation ​

FilterValueUse
ActivityDLP rule matchedAll DLP matches
ActivityDLP policy overrideAll user overrides
Sensitive info typeU.S. Social Security Number / Medical Record Number / etc.Filter to specific SIT
LocationExchange / SharePoint / OneDrive / TeamsFilter by workload
Useradriana@ciriusgroup.comSingle-user investigation
Date rangeCustomObservation window, incident window
Policy nameHIPAA PHI - EmailSingle-policy review

Combine filters: e.g., Activity = DLP rule matched + Location = Exchange + Date range = last 30 days gives you all email DLP matches for the month.

Investigating Data Movement ​

For a specific incident (e.g., "did user X send PHI externally last Tuesday?"):

  1. Filter: User = x@ciriusgroup.com + Date = [incident date] + Activity = DLP rule matched
  2. Review the result rows — each row is one matched item
  3. Click a row to expand: shows the policy, rule, SIT, instance count, and the item path (SharePoint URL, email message ID, Teams message ID)
  4. For email: the ObjectId in the detail is the Exchange message ID — use it in Message Trace if you need to confirm delivery or pull the message

Exporting Evidence for HIPAA Audits ​

Activity Explorer supports CSV export. For HIPAA audit evidence:

  1. Set filters to the relevant date range and policy/SIT
  2. Click Export (top right of the event table)
  3. The export is queued — download from the notification when ready
  4. The CSV includes: Timestamp, User, Activity, Location, Policy, Rule, SIT, InstanceCount, ObjectId (file/message identifier)

Store the export in the SecOps compliance register evidence store (POST /api/evidence with framework=HIPAA and control=164.312.e.2.ii).

powershell
# Equivalent via audit log — export DLP matches to CSV for a date range
$startDate = "2026-04-01"
$endDate = "2026-04-30"
$results = Search-UnifiedAuditLog -StartDate $startDate -EndDate $endDate `
  -RecordType DlpRuleMatch -ResultSize 5000
$results | Select-Object -ExpandProperty AuditData | ConvertFrom-Json | `
  Select-Object CreationTime, UserId, Operation, PolicyName, RuleName, Workload, `
  SensitiveInfoTypeName, Count, ObjectId | `
  Export-Csv -Path "dlp-evidence-$startDate-to-$endDate.csv" -NoTypeInformation

9. Integration with SecOps ​

How DLP Alerts Feed SecOps ​

Currently: DLP alerts are manually reviewed in the Purview portal and findings are manually entered into SecOps when a real violation is identified.

Planned: Purview → webhook → SecOps ingest endpoint (POST /api/ingest/findings). This is not yet wired. Track in the SecOps backlog.

When manually creating a SecOps finding for a DLP event, use this payload structure:

json
{
  "source_system": "PROD",
  "severity": "HIGH",
  "title": "DLP: PHI detected in outbound email",
  "description": "User X sent email to external@domain.com. HIPAA PHI - Email policy matched SSN (high confidence, 1 instance). Alert ID: [Purview alert ID].",
  "framework_control": "HIPAA-164.312.e.2.ii",
  "ioc_key": "PROD-DLP-[PurviewAlertId]",
  "evidence": {
    "purview_alert_id": "[alert ID from portal]",
    "user": "x@ciriusgroup.com",
    "workload": "Exchange",
    "policy": "HIPAA PHI - Email",
    "sit": "U.S. Social Security Number",
    "confidence": "High",
    "instance_count": 1,
    "timestamp_utc": "2026-05-25T14:32:00Z"
  }
}

Correlating a DLP Alert with Other Security Events ​

A DLP alert alone tells you what was detected. It does not tell you whether it was accidental or deliberate. To correlate:

Check sign-in activity around the event time:

https://entra.microsoft.com → Users → [user] → Sign-in logs — look for:

  • Unusual sign-in location (outside Livermore/CA, outside business hours)
  • Sign-in from unmanaged device (Conditional Access compliance status)
  • Failed sign-in attempts shortly before the DLP event (credential compromise indicator)

Check file activity in SharePoint/OneDrive:

Activity Explorer → filter by user + date → look at the sequence of events before the DLP match. Did they download the file, view it, then share it externally? That pattern is more concerning than a single upload match.

Check Arctic Wolf:

Arctic Wolf has full M365 visibility via their connector. If a DLP event is potentially part of a larger attack pattern (exfiltration stage), check the Arctic Wolf console for correlated alerts. Arctic Wolf can act without approval — if you see a DLP alert concurrent with Arctic Wolf detections on the same user, call Rory immediately.

KQL — Correlate DLP with sign-in anomalies in LAW:

kql
// DLP matches for a user in the last 7 days correlated with sign-in risk
let user = "x@ciriusgroup.com";
let lookback = 7d;
let dlpEvents = search in (OfficeActivity)
    TimeGenerated > ago(lookback)
    and UserId == user
    and Operation == "DLPRuleMatch"
    | project TimeGenerated, UserId, Operation, OfficeObjectId,
              PolicyName = tostring(parse_json(tostring(parse_json(ExtraData).PolicyDetails))[0].PolicyName);
let signInRisk = SigninLogs
    | where TimeGenerated > ago(lookback)
    and UserPrincipalName == user
    and RiskLevelDuringSignIn != "none"
    | project TimeGenerated, UserPrincipalName, RiskLevelDuringSignIn, Location, DeviceDetail;
dlpEvents
| join kind=leftouter (signInRisk) on $left.TimeGenerated == $right.TimeGenerated
| project TimeGenerated, UserId, PolicyName, OfficeObjectId, RiskLevelDuringSignIn,
          Location, DeviceDetail
| order by TimeGenerated desc

10. Monthly Review ​

Run this review at the start of each month (add to the monthly security review checklist in monthly-security-review.md).

What to Review ​

1. Alert volume trends

compliance.microsoft.com → Data loss prevention → Overview — check the last 30 days match count vs the prior 30 days.

  • Volume up > 20%: investigate whether a new workflow started or a SIT is overfiring
  • Volume down > 20%: check that telemetry is still flowing (policy may have been accidentally disabled)
  • Zero matches for a policy: verify the policy is enabled and the workload is active

2. False-positive rate

For each policy: (alerts dismissed as Not a policy violation) / (total alerts). Must stay below 2% for any policy approaching enforce mode. Above 2%: stop the enforce mode clock and investigate the top FP pattern before proceeding.

3. Override rate (Enforce mode policies only)

Activity Explorer → filter Activity = DLP policy override + date = last 30 days. If override rate > 10% of blocks for any policy: the policy is too aggressive or a legitimate workflow is not excluded. Pull the top override justification strings to identify the pattern.

4. Policy coverage gaps

Review the policy inventory. Questions to ask:

  • Any new M365 workloads added this month that are not in a policy's scope?
  • Any new contractors or guest users with access to PHI-adjacent SharePoint sites?
  • Any new sensitive information types identified in a pentest, audit finding, or business process change?
  • Are all users with PHI access covered by a DLP policy? Check for unlicensed users or accounts without Purview DLP coverage (requires M365 E3 or E5 — check license assignments).

5. License coverage check

DLP policy tips require E3 minimum. Endpoint DLP requires E5. Run this monthly to confirm all users in PHI-touching roles have the right license:

powershell
Connect-MgGraph -Scopes "User.Read.All", "Directory.Read.All"

# Users with E3 or E5 license (Purview DLP included)
Get-MgUser -Filter "assignedLicenses/any()" -All | ForEach-Object {
  $user = $_
  $licenses = Get-MgUserLicenseDetail -UserId $user.Id
  $hasE3 = $licenses | Where-Object { $_.SkuPartNumber -match "ENTERPRISEPACK|ENTERPRISE" }
  $hasE5 = $licenses | Where-Object { $_.SkuPartNumber -match "SPE_E5|ENTERPRISEPREMIUM" }
  [PSCustomObject]@{
    UPN = $user.UserPrincipalName
    DisplayName = $user.DisplayName
    HasE3 = [bool]$hasE3
    HasE5 = [bool]$hasE5
    CoveredByDLP = [bool]($hasE3 -or $hasE5)
  }
} | Where-Object { -not $_.CoveredByDLP } | Format-Table -AutoSize

Any user returned by this query who has access to PHI is a compliance gap. Either assign the appropriate license or confirm they have no path to PHI-scoped workloads.

6. Q3 enforce-mode review (due 2026-07-15)

Per purview-dlp-enforce-mode-criteria.md: re-evaluate each in-Enforce policy against the original criteria by 2026-07-15. Evidence gathering is Kobe's responsibility; review and sign-off is Rory's.

Monthly Review Output ​

Document the review in SecOps (POST /api/evidence with framework=HIPAA, control=164.312.e.2.ii, review_period=[month]). Minimum required evidence:

  • Alert volume trend (screenshot or CSV)
  • FP rate per policy
  • Override rate (Enforce policies)
  • Any coverage gaps identified and whether they were remediated or risk-accepted
  • Rory sign-off (Teams message or email confirming review complete)

References ​

Internal use only — Cirius Group