The DLP Policy Has Been in Audit Mode for a Year

The policy is deployed and every file it matched still left

The rollout was careful and the sequencing was right. A data loss prevention policy went in without enforcement so the team could watch what it would catch before it caught anything. That is how the capability is meant to be used, and skipping it is how you block a payroll transfer in week one.

Microsoft Purview will run a policy in that state: it evaluates every message and file against the rule, records what it would have done, and lets the traffic through. Microsoft's word for the state is simulation mode, previously test mode, and audit only is the related action on endpoints. The shorthand used here is audit mode. It is open ended by design, because judging when an observation period has run long enough is a judgment about the particular business being watched, and that judgment sits with the organization. The policy stays where it was put until somebody sets a date.

So the anniversary arrives quietly. The policy sits in the control register. An auditor opens it, sees a configured object with a long run of matches behind it, and moves on. Every line of the quarterly report is true, and the files it described all reached where they were going.

Three things are running at once by that point.

• A policy that matches accurately and takes no action on anything it matches
• A body of logged matches describing how the business really moves data, waiting on somebody with a week free to work through them
• A control recorded as implemented, correct in that it exists and misleading to anyone who reads the register expecting it to do something

Two things are true at the anniversary. The register says the control is implemented, and the policy is still configured to watch.

The log describes how the business moves data

The audit output gets framed as a backlog of violations, which is what makes it unreadable. A policy watching real traffic matches people doing their jobs, over and over. Finance sends the same report to the same external auditor every month. An engineer moves a test file carrying a string shaped like a card number that has never been one.

Read as a description of the estate's daily traffic, the same log sorts quickly. The repeated high-volume matches are business processes, and each one needs a decision about whether it is sanctioned. A sanctioned process gets an exemption written against sender, recipient, site or label and stops generating alerts. What survives that pass is small enough to enforce against.

Check what evidence you actually still hold before planning around a year of it. Purview keeps data loss prevention activity in Activity explorer for about thirty days, and the unified audit log runs to a hundred and eighty days on default licensing. A full year exists where the tenant carries the longer retention that comes with the higher licensing tier, or where the events were exported to a SIEM as they landed. Otherwise the readable window is the last ninety days, which is the same window the enforcement forecast below runs on.

Budget a week of one analyst's time for the sort, somebody who can query the log and get four business units on the phone. It gets postponed because the register wants a policy and the board pack has a line for one. The exemption inventory that would let the policy graduate is invisible to both.

The evidence separates into four piles.

• Repeated traffic a business unit will confirm as sanctioned, which becomes an exemption with an owner and a review date
• Repeated traffic that stays unclaimed when the business units are asked, which is the first thing to enforce against because there is no process behind it to break
• One-off matches carrying real consequence: the leaver's export, the board pack sent to a personal address
• Matches where the rule watches for a general pattern and this company's records read differently, a tuning task with a definite end

A log of matches is a description of how the business moves data, and it stays a description until somebody sorts it.

The question reaches the executive in a shape that can only be answered later

Ask the team what is blocking enforcement and the answer comes back as a worry with no shape to it: something will break, someone will complain, and nobody knows what depends on this. Every part of that is a question about the business, and the configuration work is already done.

The worry is well founded. Enforcement will interrupt something, and the person it interrupts will escalate the same afternoon. The security lead can configure the policy and cannot absorb that escalation. When a regional director calls the CIO to say security broke a customer deliverable, that conversation happens a level above whoever made the change. An engineer who has sat in it once learns to leave the policy in audit mode.

Underneath the worry is a decision still waiting to be put to somebody. The question that reaches the executive is whether the company is ready to turn on data loss prevention, and everything needed to answer it is missing from the ask: the count of people affected, the size of the downside, the date it gets reviewed. Answered honestly, later is correct, and it stays correct every time it is asked in that shape.

Audit mode is a feature. A year of audit mode is a decision nobody made, and the cost of it shows up in the second year: a detection set that goes untuned because tuning only pays off once the policy acts, a business that has learned the control does not apply to them, and evidence of exposure the company demonstrably held and left alone.

Both platforms enforce what they are configured to enforce, on the day they are told to start, each on the surface it covers. Stopping a message on its way out of the tenant is the Purview surface. Securiti's enforcement sits on access to the data, on masking what a query returns, and on the prompts and responses that reach a model. The decision to interrupt somebody's Tuesday is made by a named person inside your organization, in advance and in writing.

Scope the first enforcement until the blast radius fits in a sentence

The graduation path runs on narrowing. One rule, one channel, one population, one class of record, chosen so the audit evidence can say what will happen before it happens.

The log already holds the answer the executive needs: over the last ninety days this rule on this channel for this group would have blocked this many actions, taken by these named people. That is a blast radius somebody can approve, and it is the one thing the observation period bought that is still unspent.

Concretely: the rule running at its highest detection confidence, on external email, for one business unit, against one class of record. It covers a fraction of the total matches, and it is the first time the control does the thing it was bought to do. The affected population is small enough for the security team to call every one of them personally in the first week. Widen any of the four and the forecast turns to guesswork, which returns the conversation to the worry it started from.

The proposal that gets signed has five things in it.

• One named rule, with the detection confidence it will run at
• One channel, external email, where the boundary is unambiguous and the traffic is already logged
• One population, small enough to contact individually
• The count of actions the rule would have blocked in the last ninety days, drawn from the audit log, with the affected people named
• The date it starts enforcing and the date its effect gets reviewed

Arrange the cover before the change window opens

The rest is procedural and it costs about an hour of the right person's time. Somebody senior enough to absorb the complaint agrees in advance, in writing, that the interruption is intended.

That is a short note from the sponsor: this rule starts enforcing for this group on this date, it should block about this many actions a week, here is how a user proceeds when they have a legitimate reason, and complaints come to me. The value is in the timing. The note exists before the first complaint, so the complaint reaches somebody who has already decided.

The override path carries as much weight as the approval. Let the user proceed with a written business justification and the block becomes a checkpoint the business can pass through, with a record of who passed and why. Settle the rollback condition in the same meeting, so one angry email stops reopening the whole program.

Three data security posture engagements sit behind this, delivered by CWS on Microsoft Purview and Securiti. Where a Purview policy was told to start enforcing on a date, it enforced on that date. The open question each time was who had agreed, before that date, to own the interruption. Where that agreement existed in writing, the policy graduated on the date in the plan.

Enforcement scoping, sponsorship and rollback criteria are CWS recommendations. Microsoft documents how to run a policy in simulation and how to permit a user override with a business justification. Who signs for the first interruption gets settled inside your organization.

The first enforcement is the expensive one. After it the argument has a precedent: this rule ran, it blocked this much, the business absorbed it, and the sponsor's note is on file.

Five things to settle before the change window.

• A named sponsor who has agreed in writing that the interruption is intended and that complaints route to them
• A one-line forecast of weekly blocks, taken from the audit log
• An override path with a written business justification, logged and reviewed
• A notice to the affected population, sent by the sponsor, ahead of the day
• A written rollback condition and the date the rule gets reviewed against it

Somebody has to be willing to interrupt a workflow on purpose, and the cover for that gets arranged before the change window opens.