A phased rollout model that builds signal before enforcement so Microsoft Purview DLP reduces real risk without creating alert fatigue.
I have worked with three customers in the last month who were struggling with getting Purview Data Loss Prevention off the ground in their organizations, and in every case, it was their approach that doomed their initial efforts. (Not the technology, but it was getting plenty of the blame.)
In each case, they turned on all the features they thought they needed at the same time and got blasted with thousands of alerts, succeeding in creating a bunch of useless noise and very little data security.
Someone once told me that you need to start slow to move fast, and it turns out that certainly applies to DLP as well, using a Crawl-Walk-Run model.
Why DLP Fails Without Phasing
Before getting into the model, let’s look at the common reasons the failure occurs in the first place:
- Data classifiers are not properly tuned and have a high error rate
- Policies are written before anyone really understands the data
- Alerts are generated without a plan to respond to them
- User-facing messages or blocking are enabled before DLP policies are tuned and vetted with the stakeholders, and users are trained to expect them.
A crawl–walk–run model addresses this by aligning technology configuration, staff expectations and duties, and business processes at each stage, applying controls and automation only after the organization is ready.
The Goals of the Crawl–Walk–Run Phases
| Phase | Primary Goal | Question To Answer |
| Crawl | Visibility and risk awareness | What data do we actually have, and where does real risk exist? |
| Walk | Behavioral guidance | How should users handle sensitive data? |
| Run | Targeted enforcement | When should the system step in automatically? |
Crawl: Understand the Risk and Impact Without Disruption
This phase is about learning, not enforcement. Start with only a single department or group:
| Function | Crawl Configuration |
| DLP policies | Simulation mode only |
| Locations | Exchange, SharePoint, & OneDrive |
| Conditions | Purview Sensitive Information Type classifiers for PII, PCI & ePHI, as applicable to your environment) |
| Actions | Logging and reporting only |
| Notifications & Alerts | None (or adminonly) |
What You Are Not Doing:
- Blocking
- User notification
- Automatic encryption
- Alert Response
What You Are Going to Learn
| Risk | Evidence |
| Risky usage | Who is sharing sensitive data and how, and where it clusters. (Is the Benefits team sending lots of unencrypted emails with Social Security numbers in them?) |
| False positives & negatives | Which SITs need to be tuned or replaced with a custom version. For example, is non-sensitive OneDrive sharing flagged as containing sensitive data? |
| Business processes & context | Legitimate workflows vs. real risk, (or risky legitimate workflows). Does the finance team share a bunch of contractor payments to a vendor at the end of every month with unredacted bank account numbers? |
Key Outputs of Crawl
- A factbased view of the risks and detection velocity.
- A (hopefully) short list of highvalue scenarios worth addressing now.
- Evidence you can use to align your DLP policies with user behavior and requirements.
Take these outputs and review if SITs need to be tuned, if data owners need to be informed and engaged to reduce risky behaviors, and prepare your initial communications and training for the group of end users moving to Walk.
Walk: Encourage Proper Data Usage Before You Enforce It
Objective
Introduce real-time guidance so users can correct behavior before enforcement becomes necessary.
This is where DLP starts acting like a teaching mechanism, not a control, by introducing real-time guidance so users can correct behavior before enforcement becomes necessary.
What Changes in Walk
| Area | Walk Configuration |
| DLP mode | Active, but still mostly nonblocking. Consider using a policy threshold to start blocking or requiring an override of egregious sensitive data sharing. |
| User experience | Policy tips and warnings. Consider using a policy threshold to start blocking or requiring an override of egregious sensitive data sharing. |
| Scope | Still a limited group or department |
| Label integration | If sensitive labeling is in place, require overrides if a labelbased blocking policy is triggered. |
| Alert thresholds | Set a Low rating on alerts that involve small amounts of data and High on large amounts of sharing. Investigate the High-rated alerts to validate and gently triage actual high-risk activity. |
Policy Configurations:
- Policy tips: Provide real time education and reminders that their action would violate policy.
- Override and justification prompts: Capture business intent and feedback from users. Having thresholds in place can start to help catch real risks.
- Label awareness: Reinforce proper usage and/or relabeling of labeled files.
- Scoped policies: Keep the group small and targeted. Document all lessons learned so modifications can be made before Run.
What Success Looks Like
| Outcome | Indicator |
| Fewer alerts | Users selfcorrect. |
| Staff feedback | Review override or relabeling reasons in the audit log to see what users may not have told you and address accordingly. |
| SIT tuning reinforcement | You will know if more tuning is necessary or if you are ready to Run. |
Crawl is about understanding data and behaviors, and Walk is about shaping behavior without breaking anything and gathering real feedback from users.
Run: Enforce the Rules and Actively Reduce Risk
Objective
Automatically prevent data loss or leakage with confidence. (But still scoped to a small group.) Run does not mean “turn everything on.” Run means intentional and clearly defined enforcement of written policies.
What Changes in Run
| Area | Run Configuration |
| DLP mode | Policy tips and blocking as needed. Override capabilities for a selected few with a business reason. Consider forcing the encryption of email with detected sensitive data or attachments. Be sure to have support staff ready to triage any business-disrupting impacts. |
| User experience | Policy tips and blocking as needed. Override capabilities for a selected few with a business reason. Consider forcing the encryption of email with detected sensitive data or attachments. Be sure to have support staff ready to triage any business disrupting impacts. |
| Scope | Still a limited group or department. Consider moving other teams to Crawl or Walk. |
| Label integration | Blocking per policy. Track relabeling reasons and consider using the label as a primary DLP trigger and SITs as a secondary to discourage people trying to work around a legitimate block. |
| Alerting | Adjust Low and High DLP alert settings to correspond with risk and be ready to investigate as needed. Consider sending these alerts to your SOC for initial triage. |
Now, be ready to rinse and repeat this process with an expanded group or department until you have full coverage. Be sure to communicate and train, train, train!
DLP is most effective when it’s progressive, defensible, and grounded in how people actually work. This process takes time, but you often only get one shot at DLP success before the organization pushes back.
Most organizations will be able to accelerate the pace as they roll out DLP phases to additional areas in the organization, especially as SITs become more accurate and data governance policies become part of the “new normal.”
Alert response needs to merge into your regular security incident response processes so that DLP becomes another signal that provides clarity on possible threats and identifies risky behaviors.
Make Purview DLP Actionable, Not Noisy
We help you tune Sensitive Information Types, pilot in simulation, and move to user guidance and enforcement with clear stakeholder alignment.
