Purview DLP — Enforce Mode Criteria

Story: PURVIEW-010 — DLP enforce mode criteria Owner: Rory (approver) / Kobe (documentation) Status: Completed 2026-04-16 Related: HIPAA Controls, Logging Architecture, Annual Review Checklist

Purpose

Define the objective criteria that must be met before Microsoft Purview Data Loss Prevention (DLP) policies at Cirius Group transition from Test mode (with policy tips) to Enforce mode (blocking). Enforce mode actually blocks or quarantines user actions; getting there prematurely creates productivity incidents and erodes trust in the control. Getting there too slowly leaves PHI at risk.

This document is the gate. A policy cannot be flipped to Enforce until every criterion below is satisfied in writing and Rory signs off.

Background: what the DLP policies cover

Cirius Group's DLP policies protect PHI (Protected Health Information) across:

• Exchange Online (email in transit)
• SharePoint Online and OneDrive for Business
• Microsoft Teams chat and channel messages
• Windows endpoints (Endpoint DLP) for local file operations and external drive writes

Sensitive information types (SITs) in scope include: U.S. health plan identifiers, U.S. medical record numbers, patient names in combination with diagnosis/procedure codes, and the Cirius-specific custom SIT for patient intake form fields.

Enforce Mode Criteria (all must be true)

1. Minimum 30-day observation window in Test mode

• [ ] Policy has been running in Test mode with policy tips enabled for at least 30 consecutive days.
• [ ] Observation period covers at least one full end-of-month close cycle (patient billing batches, insurance submission cycles).
• [ ] Observation window documented with start date, end date, and total match count captured from the Purview DLP activity explorer.

Rationale: less than 30 days misses cyclical workflows (month-end, quarter-end). Rushing to enforce before seeing a full cycle is how we'd block a genuine billing workflow at the worst possible time.

2. False-positive rate below 2%

• [ ] Total matches in the observation window: N
• [ ] Reviewed matches classified as false positives: FP
• [ ] FP / N must be less than 0.02 (2%).
• [ ] Sample size ≥ 100 matches OR 100% of matches reviewed if total < 100.
• [ ] False-positive classification performed by Rory (not self-service by end users).
• [ ] Top-3 false-positive patterns identified and addressed via SIT refinement or policy exclusion before enforce.

Rationale: 2% is the ceiling at which end users retain trust in the policy. Above 2%, every block feels arbitrary, users route around the control, and the policy becomes theater.

3. User training complete

• [ ] DLP training session delivered to all staff whose workflows touch in-scope sensitive information types.
• [ ] Training covers: what the policy does, what Enforce mode means, how to request an exception, how to report a false positive.
• [ ] Training attendance recorded in the compliance register.
• [ ] Training deck checked into bedrock-docs/compliance/training/ (or linked external location) so the content is auditable.
• [ ] New-hire onboarding checklist updated to include DLP training for any role with PHI access.

Rationale: Enforce mode is only legitimate if users understand what they are about to encounter. Without training, the first block looks like a system failure, not a control working.

4. Policy tip copy reviewed and approved

• [ ] Policy tip wording is plain English, not technical jargon.
• [ ] Policy tip tells the user what to do next (request exception via the documented path, reclassify the content, or cancel the action).
• [ ] Rory approves the final policy tip copy in writing.

Rationale: the policy tip is the user's only in-line explanation of what happened. Bad copy turns every block into a help-desk ticket.

5. Exception process documented and tested

• [ ] Exception request path documented (who to contact, what evidence to provide, expected turnaround).
• [ ] At least one end-to-end test of the exception workflow performed in the observation window.
• [ ] Exception decisions captured in an auditable log (Purview override reason field + ticket in SecOps platform).
• [ ] Time-to-decision target defined (e.g., 1 business hour for active blocks).

Rationale: Enforce mode without a working exception path is an outage waiting to happen. Users with legitimate needs must have a fast path.

6. Telemetry wired end-to-end

• [ ] Purview DLP events flowing into Log Analytics Workspace via the connector described in logging-architecture.md.
• [ ] Alert configured: policy block rate spikes above the observation-window baseline by more than 2x in any 1-hour window.
• [ ] Alert configured: user override rate exceeds 10% of blocks in any 24-hour window.
• [ ] Dashboard tile showing block rate, top violating users, and top violating policies.

Rationale: once Enforce is on, we need to see it working (or failing) in real time. If telemetry isn't wired before we flip the switch, we'll only hear about problems through help-desk tickets.

7. Rollback plan documented

• [ ] Documented procedure to revert a policy from Enforce to Test mode, including who can authorize the rollback, how to communicate it, and how long it takes.
• [ ] Rollback tested at least once in Test mode by executing the configuration change end-to-end.

Rationale: if Enforce mode causes a genuine production issue, we need a rehearsed rollback, not improvisation under pressure.

8. Rory formal approval

• [ ] Rory reviews evidence for all criteria above.
• [ ] Rory signs off in writing (email or Teams) naming the specific policy and the go-live date.
• [ ] Sign-off archived with the policy change record.

Rationale: Enforce mode is a state change with user impact. A formal, named approver prevents drift into "it just happened".

Q3 2026 Review

Scheduled review date: 2026-07-15 (mid-Q3).

Scope of review:

• Re-evaluate each in-Enforce policy against the original criteria. Has anything drifted?
• Re-calculate false-positive rate over the last 90 days. Still under 2%?
• Re-check override rate. Are users routing around the policy?
• Re-check whether any new sensitive information types should be added to scope.
• Update this criteria document if we've learned anything that changes the thresholds.

Responsible: Rory (review), Kobe (evidence gathering and document updates). The review outcome feeds the annual review checklist.

Policy-by-policy status tracking

Track each DLP policy against these criteria in a table kept in the SecOps platform compliance register (not duplicated here to avoid drift). The table columns: policy name, mode, Test-start date, observation window end, current FP rate, training complete (Y/N), exception process tested (Y/N), Rory signoff date, Q3 review date.

References

• HIPAA Controls — §164.312(c)(1) integrity, §164.312(e)(1) transmission security
• Logging Architecture — Purview → LAW connector
• Annual Review Checklist
• Microsoft docs — DLP policy modes: learn.microsoft.com/purview/dlp-learn-about-dlp
• Microsoft docs — DLP activity explorer: learn.microsoft.com/purview/dlp-activity-explorer