Microsoft Purview Endpoint DLP High CPU Usage: Why Microsoft Split MpDlpService From Defender

Endpoint DLP is not a passive policy sitting on the device waiting to be consulted. To enforce a rule against copying sensitive content to a USB drive, printing a document with credit card numbers, or pasting regulated data into an unsanctioned browser tab, the agent has to classify file and clipboard content against sensitive information types, exact data match tables, or trainable classifiers in close to real time, for every relevant file operation on every onboarded device the policy applies to. The more file types a policy inspects, the more sensitive information types and exact data match tables it evaluates per file, and the more endpoints and applications it is scoped to, the more classification work MpDlpService.exe has to do continuously, independent of anything Defender Antivirus is doing on the same machine. A device that feels slow immediately after a broad new DLP policy is deployed, rather than after an agent update, is very often reflecting genuine inspection load rather than a bug, which matters because the fix in that case is policy scoping, not an exclusion or a version update.

Before the process split, a single process, MsMpEng.exe, carried both antivirus real-time protection and DLP inspection, which meant heavy DLP scanning and heavy antivirus scanning were structurally impossible to tell apart by looking at Task Manager, and any exclusion, firewall rule, or application-control allowlist entry written for Defender automatically covered DLP as well because there was only one process to list. After the split, that is no longer true: firewalls, non-Microsoft antimalware, and application control solutions that previously allowlisted MsMpEng.exe do not automatically extend that allowlist to MpDlpService.exe, and Microsoft has been explicit that organizations relying on those controls need to add the new process separately. A device where MpDlpService.exe is itself being scanned, throttled, or intermittently blocked by a firewall or third-party security tool that only knows about MsMpEng.exe will show CPU and latency symptoms that look identical to a DLP policy being too broad, but the actual cause is a missing allowlist entry left over from before the split, and no amount of policy tuning fixes that.

Before assuming either explanation, confirm the device is actually running a Defender platform version at or after 4.18.24060.0, since a device on an older platform does not have the split at all and will show DLP and antivirus load combined in MsMpEng.exe exactly as it always did; check the running version through the Windows Security app or with Get-MpComputerStatus in PowerShell. On a device that does have the split, open Task Manager, Resource Monitor, or Process Explorer during the complaint and identify specifically whether MpDlpService.exe or MsMpEng.exe is the process consuming CPU, since the two processes now represent genuinely different workloads with different fixes. If MsMpEng.exe is the one spiking, this is a Defender Antivirus performance problem, not a DLP one, and the standard antivirus triage path, unsigned binaries, obfuscated scripts, VDI image sealing before cache completes, or misspelled exclusions verified with MpCmdRun.exe -CheckExclusion, is the correct next step rather than anything covered here.

Once MpDlpService.exe is confirmed as the process under load, use Microsoft Purview's device onboarding health dashboard to check whether the affected device is receiving an unusually large or complex set of policies compared to similar devices, since a device syncing significantly more DLP policy content than its peers is a strong signal that scope, not a bug, is driving the CPU cost. Purview's Always-on Diagnostics feature for endpoint DLP automatically records trace logs on the device and lets an admin request a diagnostic upload directly from Alerts, Activity Explorer, or the Device Policy Status Page, which is built specifically to help distinguish whether a device-level DLP problem stems from policy logic, device state, application configuration, or endpoint health, without needing to reproduce the issue manually with a separate trace tool. Cross-check for a conflicting security product by reviewing whether any third-party antivirus, EDR, or firewall logs show activity against MpDlpService.exe specifically, which points back toward the exclusion gap covered above rather than a policy scoping problem.

Where the diagnosis points to a missing allowlist entry, add MpDlpService.exe to every firewall rule, third-party antimalware exclusion list, and application control policy that already references MsMpEng.exe, rather than assuming an existing Defender exclusion covers it. Confirm platform version 4.18.24060.0 or later is actually installed first, since applying this fix to a device still on an older platform accomplishes nothing because the separate process does not exist there yet; a fleet-wide rollout of endpoint DLP is very often a mix of updated and not-yet-updated devices, and treating the fleet as uniform is a common source of inconsistent results. Verify path and process exclusions were actually applied, not just configured, using the same MpCmdRun.exe -CheckExclusion validation Microsoft recommends for Defender Antivirus exclusions generally, since a misspelled or mistyped exclusion silently does nothing.

Where the diagnosis points to genuine inspection load rather than a conflict, the correct fix is narrowing what the policy actually inspects, not adding broad exclusions that quietly disable DLP protection to relieve CPU pressure. Reduce the file types and locations a policy scans to what is actually relevant to the data it is meant to protect, limit sensitive information type and exact data match evaluation to the types genuinely in scope for that policy rather than enabling every available type by default, and scope enforcement to the users, groups, or device groups that actually handle the regulated data rather than applying the heaviest policy fleet-wide. Our data loss prevention implementation guide covers policy scoping in more depth for teams building this out; the point specific to a performance complaint is that any scoping change here is a security-relevant decision, not a cosmetic one, and should be made with whoever owns the DLP policy, not unilaterally by whoever is trying to make a CPU alert stop firing.

Re-check MpDlpService.exe CPU consumption in Task Manager or Resource Monitor under the device's normal daily workload, not immediately after a reboot or agent update when file activity is artificially low, since a measurement taken minutes after a change will look fine regardless of whether the underlying issue was actually resolved. If the fix was an exclusion, confirm with MpCmdRun.exe -CheckExclusion that it is actually in effect and, separately, confirm through the device onboarding health dashboard that policy sync and enforcement status for that device are still healthy, since an exclusion aimed at a conflicting security product should not have touched DLP enforcement at all. If the fix was policy scoping, confirm with the DLP policy owner, using Activity Explorer or a controlled test file, that the narrowed policy still fires on the content it is supposed to catch, because a fix that reduces CPU by silently reducing what the policy actually inspects has not really been resolved.

Adding MpDlpService.exe to a third-party antimalware exclusion list while leaving the older firewall rule unchanged leaves an intermittent, harder-to-reproduce version of the same symptom, since the process is now unblocked at the antimalware layer but can still be throttled at the network layer during specific operations. Applying the platform update and exclusion fix to only the devices where users happened to complain, rather than fleet-wide, means the same issue resurfaces on every other device that crosses the same platform version threshold later, since the exclusion gap is a property of the agent version and the third-party tool's configuration, not of any individual device. Narrowing DLP policy scope to solve a CPU complaint without looping in the policy owner can resolve the performance ticket while quietly creating a compliance gap that is not discovered until an unrelated audit or a data loss event checks whether the policy still covers what it was supposed to.

Escalate to whoever owns DLP policy before narrowing inspection scope on any policy tied to a regulatory or contractual requirement, since a performance-motivated scoping change is a coverage decision, not a unilateral technical fix, even when it is the fastest way to make the CPU issue go away. Escalate to Microsoft support with an Always-on Diagnostics upload attached, requested from the Alerts, Activity Explorer, or Device Policy Status Page entry points, when MpDlpService.exe is confirmed as the source of sustained high CPU and the platform is current, exclusions are verified as applied, and policy scope is already reasonable for the device population, since at that point the cause may be a defect Microsoft needs to investigate rather than a configuration issue an admin can resolve alone. Escalate to whoever manages endpoint security tooling generally, not just DLP, when the root cause turns out to be a third-party antimalware or firewall product still enforcing rules against MsMpEng.exe without an equivalent MpDlpService.exe entry, since that gap likely exists across every device the same tool manages, not just the one that happened to generate a complaint.