What the Regulations Actually Require

"Compliance requires DLP" is a common justification and mostly inaccurate. Few frameworks mandate the technology; several mandate outcomes that it can help achieve.

Knowing the difference improves both the business case and the design.

General description. Requirements vary by jurisdiction and sector, and this is not legal advice.

What frameworks generally require

Appropriate technical and organisational measures, proportionate to risk. This is the formulation in most data protection law. It does not name a technology; it requires that you can justify what you chose and why.

Breach notification within a defined period, running from awareness. Typically 72 hours in several regimes. This has a practical implication that is rarely drawn: you need to be able to determine what was exposed, quickly. That capability is an inventory and a log, not a blocking rule.

Records of processing. Knowing what personal data you hold, where, and why. This is the data inventory under another name, and it is required whether or not you deploy anything.

Access control and least privilege. Present in essentially every framework. Reducing who can reach sensitive data is a compliance measure and an insider risk measure simultaneously, and it is cheaper than detection.

Ability to demonstrate. Documented reasoning, not just working controls. Auditors ask why you concluded these measures were appropriate.

Sector-specific requirements

Payment card standards require protecting stored cardholder data and restricting where it can go. The controls are prescriptive about scope and encryption more than about detection.

Healthcare regimes require audit controls and integrity monitoring over health records, and access logging is generally explicit.

Financial services frequently carry communications retention and supervision obligations — which is a monitoring requirement, though for a different purpose than data loss.

Defence and government supply chain requirements are the closest to mandating insider threat programmes explicitly, with specified elements.

What is not required

A DLP product. No mainstream framework names one.

Blocking. Monitoring and response satisfy most requirements.

Comprehensive monitoring of all employees. Several frameworks push the other way, requiring proportionality and data minimisation.

Indefinite retention of monitoring data. Generally the opposite.

The tension nobody mentions

Employee monitoring deployed for compliance creates its own compliance obligations.

The monitoring system processes personal data about employees. That requires a lawful basis, transparency, proportionality, an impact assessment in several regimes, retention limits, and the ability to answer subject access requests about the monitoring records themselves.

A programme deployed to satisfy one obligation and creating breaches of another is not unusual. It is what happens when security procures without legal involvement.

Building the business case honestly

Do not claim a mandate that does not exist. Someone will check, and the credibility loss extends to the parts of the case that were true.

Do claim the capability. Breach assessment within 72 hours is a genuine requirement that most organisations cannot currently meet. The inventory and logging that enable it are defensible on that basis alone.

Include the cost of the obligations you are creating. Impact assessment, consultation where required, retention management, subject access handling. These are real and they are usually omitted from the business case.

Frame proportionality as design, not constraint. A narrow programme covering the categories that matter is both more defensible and more effective than a broad one, which means the compliance requirement and the operational advice point the same way.

That alignment is worth using. It is not often that the lawyers and the engineers want the same design.