The Change Healthcare breach of 2024 exposed the records of 192 million individuals – the largest healthcare data breach in U.S. history, per HHS OCR. The organization had a DLP policy.
A global bank with enterprise-grade DLP tooling watched sensitive client data flow quietly into employee personal cloud apps, week after week, undetected.
The U.S. Department of Justice and Pentagon had 632,000 email addresses compromised in the MOVEit breach – through a file transfer system their DLP policies did not govern.
This is not a technology failure. It is a policy design failure.
Most regulated organizations have a data loss prevention policy. Very few have one that works under the conditions their data now lives in: fragmented cloud environments, cross-border analytics pipelines, AI training workflows, and multi-party collaborations where sensitive data needs to be used, not just locked away.
This article examines exactly where DLP policies break down in healthcare, financial services, and government, and what a modern, privacy-first approach looks like instead.
Quick Take:
- Traditional DLP was built to stop data from leaving a perimeter that no longer exists.
- Legacy tools miss insider threats, have near-zero AI pipeline coverage, and generate high false-positive rates.
- Privacy-enhancing technologies extend DLP from a blocking mechanism to an enabling framework.
- Regulated industries now need policies that address data in use – not just in motion or at rest.
What are the primary considerations when designing a data loss prevention policy for a global organization?
A data loss prevention policy is a formal framework that defines how sensitive data is classified, who can access it, how it can be used and shared, and what controls enforce those rules across every environment where that data lives.
For global organizations – hospital networks spanning jurisdictions, financial institutions subject to GDPR and GLBA simultaneously, government contractors handling classified data, five considerations are foundational.
- Data classification establishes the foundation. Effective DLP policies define four tiers: public, internal, confidential, and restricted. PHI under HIPAA, personal data under GDPR, and classified government data each demand different technical controls even when they share a classification tier.
- Scope of enforcement must cover endpoints, cloud platforms, SaaS applications, API traffic, AI tooling, and third-party processors. A 2025 Netskope analysis found 88% of enterprise employees use personal cloud apps monthly, and 26% upload corporate data to those apps. A policy governing only managed devices leaves most of the risk surface untouched.
- Regulatory alignment requires mapping to each applicable framework at the control level. GDPR restricts cross-border transfers. HIPAA requires documented administrative and technical safeguards for PHI. FedRAMP, CJIS, and CMMC 2.0 add further layers. General alignment is not the same as control-level compliance.
- Insider risk is statistically the most likely loss vector. The Ponemon Institute’s 2025 report found organizations spend an average of $17.4 million annually on insider incidents, and 55% involve negligent, not malicious, employees.
- Operability determines whether the policy actually holds. A policy that blocks legitimate work gets circumvented. It must define what data can do with the same precision as what it cannot.
Key Tip
Before writing a single rule, map your data flows. A policy built without this map generates false positives and missed controls in equal measure.
What are the trade-offs between traditional perimeter-based DLP and modern privacy-first data governance strategies?
Traditional DLP was designed for a world where data lived inside a defined corporate boundary, monitoring what leaves the perimeter and blocking what should not move.
It worked when collaboration meant attaching a file to an email. That world no longer exists for most regulated enterprises.
| Dimension | Traditional perimeter-based DLP | Modern privacy-first governance |
|---|---|---|
| Core assumption | Data risk = data movement | Data risk = unauthorized access, regardless of location |
| Enforcement point | Network egress, endpoint agents | The data itself – policy travels with it |
| Cloud coverage | Partial; blind to most SaaS API traffic | Native multi-cloud across SaaS, IaaS, PaaS |
| Insider threat | Limited; struggles with authorized-user activity | Behavioral analytics + computation-layer controls |
| Cross-border capability | Blocks transfer; cannot enable compliant collaboration | Enables computation on data without moving it |
| AI pipeline coverage | None in most legacy deployments | Governs training data, inference inputs, model outputs |
The fundamental shift is that the goal is no longer exclusively prevention – it is controlled enablement.
Regulated industries hold enormous analytical potential locked inside sensitive datasets: patient records that could train diagnostic AI, transaction data that could detect cross-border money laundering, government intelligence that could improve national security outcomes. Legacy DLP blocks all of it indiscriminately.
Modern privacy-first strategies use attribute-based access control and privacy-enhancing technologies to let regulated data be used for legitimate purposes, without exposing the underlying records.
Did you know? IBM’s 2025 Cost of a Data Breach Report puts the average U.S. breach cost at a record $10.22 million. Organizations with AI-powered security automation reduced their breach costs by an average of $2.22 million compared to those without it
How does zero-trust architecture impact the evolution of enterprise data loss prevention strategies?
Here is the problem zero-trust exposes about traditional DLP: most policies treat an authenticated user as a trusted one.
Once you have valid credentials and are inside the network, the system assumes your access is legitimate. That assumption is exactly what insider threats exploit, and why 70% of healthcare breach threat actors in the Verizon 2024 DBIR were internal.
Zero-trust removes that assumption. No user, device, or system is trusted by default. Every access request is evaluated in context: who is requesting, what they are requesting, from where, and whether the request matches expected behavior. For DLP, enforcement moves from the network layer to the data layer itself.
The failure mode of DLP without zero-trust is concrete: a data scientist with legitimate credentials queries a sensitive dataset at 2am from an unmanaged device, exports a large file, and transfers it to a personal cloud account.
At each step, the action falls within what their access level technically permits. Standard DLP rules, built around content inspection and egress monitoring, log nothing unusual. The exfiltration completes without a single alert.
Zero-trust DLP closes this through three controls (continuous verification, least-privilege access, and encryption in use). Continuous verification re-authenticates every access event against current context – time, location, device posture, behavioral baseline, not just at login.
Least-privilege access limits what any user can reach to the minimum necessary for their current task.
Encryption in use extends DLP protection to data during computation – the gap PETs address directly.
The NSA’s April 2024 “Advancing Zero Trust Maturity Throughout the Data Pillar” maps these controls to federal compliance requirements under FedRAMP High, CMMC 2.0, and OMB M-22-09, making zero-trust data pillar alignment a compliance requirement, not just best practice.
Key Tip
The most reliable test of whether your DLP policy meets zero-trust standards: can a legitimate user with valid credentials exfiltrate sensitive data without triggering a control? If yes, the policy is governed by perimeter logic – and zero-trust maturity requires rebuilding from the data layer up.
How do modern privacy-enhancing technologies improve the reliability of data loss prevention compared to legacy systems?
Privacy-enhancing technologies PETs are cryptographic and computational techniques that allow sensitive data to be analyzed and used without the underlying records ever being exposed.
They include homomorphic encryption, secure multi-party computation (SMPC), federated learning, differential privacy, and trusted execution environments (TEEs).
Where legacy DLP controls data movement, PETs make the data itself unusable to unauthorized parties even when physically accessible.
Legacy DLP’s failure modes are structural: false positives generate alert fatigue that leads to missed genuine incidents, and network-layer tools cannot inspect encrypted traffic without SSL inspection complications.
Authorized insiders can exfiltrate through legitimate access channels that content rules cannot distinguish from normal activity, and AI pipelines are invisible to tools built before enterprise AI existed.
IBM’s 2025 report found 20% of breaches involved shadow AI, with 97% occurring in organizations lacking AI access controls.
PETs address these gaps architecturally:
| Failure mode | PET solution |
|---|---|
| Cross-border collaboration needed | Federated analytics – computation runs locally; only results move |
| Multi-organization sensitive data analysis | SMPC – each party contributes without seeing others’ raw data |
| AI training on PHI or financial records | Federated learning + differential privacy – no centralization of records |
| Data must stay encrypted during processing | Homomorphic encryption – computation runs on ciphertext |
| Foreign cloud processing of sensitive data | TEEs – hardware-level isolation from host infrastructure |
Gartner projected that by 2025, 60% of large organizations would use at least one privacy-enhancing computation technique in analytics or cloud computing.
The Royal Society’s 2023 report “From Privacy to Partnership” identified PETs as the primary technical pathway for unlocking cross-sector data collaboration in healthcare, finance, and government – while maintaining the compliance guarantees those sectors require.
The sector-specific failure patterns are distinct enough to name directly.
- Healthcare. The 2024 Montefiore HIPAA settlement ($4.75 million) arose from a malicious insider with authorized access selling ePHI of 12,517 patients, standard DLP rules did not flag the activity.
Change Healthcare’s breach exploited a Citrix portal without MFA. IBM’s 2025 report puts the average healthcare breach at $7.42 million – highest of any sector, for the 15th consecutive year.
- Financial services face a structurally different problem. The DLP challenge here is not primarily data leaving the organization , it is data that cannot be legally shared between institutions for legitimate fraud detection and AML purposes.
Under FinCEN 314(b), the legal permission to share exists. The technical mechanism to do so without exposing customer records to counterparties does not.
That gap is exactly what SMPC and federated analytics close. The average financial services breach costs $5.56 million but the greater cost is fraud that goes undetected because institutions cannot safely collaborate on the signals that would catch it.
- Government and defense operates under the strictest classification requirements of any sector. The MOVEit breach compromised 632,000 DOJ and Pentagon email addresses through a file transfer utility outside existing DLP rules.
CMMC 2.0 now requires DoD contractors to demonstrate DLP compliance at the data layer, not the network layer.
Federal agencies under FedRAMP High and CJIS face the same question: how do you enable inter-agency data sharing and AI workflows without creating the exposure DLP is supposed to prevent?
Worth noting
The healthcare cost figure above reflects breaches where data moved – it was stolen, exposed, or exfiltrated. PETs reframe the risk calculus entirely: if sensitive data never moves, the category of breach that produces a $7.42 million liability simply cannot occur. The relevant question for security teams is not just “how do we detect exfiltration faster?” – it is “how do we architect systems where exfiltration is technically impossible?” Those are different questions with very different answers.
How does homomorphic encryption integrate within existing data loss prevention workflows?
Homomorphic encryption (HE) allows computation on encrypted data, producing results that, when decrypted by an authorized party, are identical to running the same computation on plaintext. Data never needs to be decrypted to be used.
The practical meaning for DLP is significant. An analyst querying encrypted patient records gets the correct aggregate result without a single individual record being exposed.
A financial institution running fraud detection on a partner’s data runs the full model without either party seeing the other’s underlying records. A government agency runs signals analysis across classified datasets from multiple agencies without centralizing raw data.
HE fits into existing DLP workflows at three layers: storage, collaboration, and AI training. Data is encrypted before storage and stays encrypted during use, external parties can work on encrypted data without seeing the raw information, and even AI training happens on encrypted data, closing gaps that legacy DLP cannot address.
Performance was historically the primary constraint. Duality’s implementation using the OpenFHE library – developed with Intel, Samsung, MIT, and UCSD – achieves up to 30x performance improvements on large-scale healthcare datasets compared to earlier implementations, making enterprise-grade HE operationally viable.
Key Tip
Homomorphic encryption extends DLP coverage to data during computation – the one gap legacy tools cannot address. Layer it on top of existing controls, not instead of them.
If I need to secure cross-border data flows, which privacy-enhancing techniques should I prioritize in my DLP policy?
Cross-border data flows are where DLP policy and regulatory compliance collide most visibly. GDPR Chapter V restricts transfers of EU personal data to third countries without an adequacy decision or approved safeguards.
The Irish DPC’s €1.2 billion fine against Meta in May 2023 – the largest GDPR fine on record – arose specifically from inadequate cross-border transfer protections. LinkedIn’s €310 million fine from the same regulator in October 2024 confirmed enforcement is active, not theoretical.
Standard DLP handles this by blocking transfers. That is technically compliant but analytically paralyzing – a pharmaceutical company cannot run a global clinical trial if patient data from five jurisdictions cannot be analyzed together.
The PETs to prioritize, in order of applicability:
- Federated analytics for most collaboration scenarios. Data stays in its country of origin; queries run locally; only aggregate, de-identified results cross borders. Satisfies GDPR data minimization and transfer restriction requirements without sacrificing analytical value.
- Secure multi-party computation when insights require combining data across jurisdictions. Each party contributes to a joint computation without seeing another’s raw records. No personal data transfer occurs – sidestepping the transfer restriction framework entirely.
- Differential privacy for analytical outputs shared across borders. Statistical noise calibrated to prevent re-identification makes outputs safe to transfer without exposing underlying records.
- Confidential computing / TEEs when a foreign cloud environment must process sensitive data. Hardware-level isolation addresses sovereignty concerns without requiring on-premise infrastructure in every jurisdiction.
Important
Standard Contractual Clauses are legal instruments – they do not replace technical controls. The Schrems II ruling established that legal mechanisms alone are insufficient when destination-country surveillance laws conflict with EU standards. Technical safeguards are the supplementary measures regulators now expect.
What are the best practices for implementing a DLP policy that balances security with operational agility?
A DLP policy that only restricts will be worked around. One that only enables will fail compliance obligations. The balance comes from building in layers – each adding coverage without creating friction for legitimate work.
What your DLP policy must include
- Data inventory and classification – a documented map of where sensitive data lives, how it is classified, and who owns each tier. Without this, every rule that follows is guesswork.
- Scope definition – explicit coverage of endpoints, cloud platforms, SaaS applications, API traffic, AI tooling, and third-party processors. If it is not in scope, it is not governed.
- Regulatory mapping – for each applicable framework (HIPAA, GDPR, GLBA, FedRAMP, CJIS, CMMC 2.0), a control-level mapping of which policy controls satisfy which requirements.
- Access controls – role-based and attribute-based enforcement of least-privilege. Authorized access is not the same as appropriate access.
- Insider risk controls – behavioral monitoring for anomalous access patterns by authorized users, not just external threat detection.
- AI and LLM governance – explicit rules covering what data enters model training, what prompts employees to send to external AI tools, and how AI-generated outputs involving sensitive data are classified.
- Cross-border transfer policy – documented approved transfer mechanisms for each jurisdiction, with technical safeguards not just legal instruments supporting each.
- Incident response integration – escalation paths, notification timelines, and evidence preservation procedures aligned to each applicable framework’s breach notification requirements.
- Policy exception process – a documented, auditable path for exceptions. A policy with no exception process creates shadow workarounds harder to audit than formal exceptions.
- Review cadence – defined triggers beyond annual review: new regulatory developments, new cloud or AI systems, security incidents, or significant changes to data-sharing partnerships.
Practitioner decision framework: which control to reach for first
When a DLP gap is identified, the instinct is to add another rule. The more useful question is: what kind of gap is this?
| Gap type | Symptom | Right control |
|---|---|---|
| Data movement to unsanctioned destinations | Sensitive data reaching personal cloud apps, unmanaged devices, or unsanctioned APIs | Scope expansion + CASB integration; behavioral DLP rules |
| Insider threat from authorized users | Authorized access that is anomalous in volume, time, or destination | Zero-trust continuous verification + behavioral analytics |
| Cross-border collaboration blocked | Teams cannot share or analyze data across jurisdictions without violating transfer restrictions | Federated analytics or SMPC |
| AI pipeline exposure | Sensitive data entering model training or LLM prompts without governance | Federated learning + differential privacy; prompt governance rules |
| Computation on data that cannot be centralized | Analysis required on legally or contractually untouchable data | Homomorphic encryption |
| Third-party processing risk | Partner must process your data in their or a foreign cloud environment | Confidential computing / TEEs |
| Regulatory audit gap | Controls exist but cannot be demonstrated to auditors | Audit trail completeness + log review cadence |
Key Tip
Before adding a new DLP rule, ask: is this gap about data moving somewhere it shouldn’t, or data being used in a way it shouldn’t? Movement gaps call for detection and blocking. Usage gaps – AI training, authorized-user exfiltration, cross-border analytics – call for architectural controls that PETs provide. Applying the wrong control to the wrong gap produces alerts, not protection.
From Data Blocking to Data Enablement: The New DLP Standard
Most DLP policies today are built to stop data movement, not enable data use. That’s no longer enough in environments driven by AI, cross-border collaboration, and multi-party analytics.
Modern data risk is not just about where data goes – it’s about how it’s used. And legacy tools were never designed for that.
Duality helps organizations move beyond blocking and into secure data enablement.
It allows teams to analyze, share, and train AI models on sensitive data without ever exposing it. Data stays encrypted throughout its lifecycle – at rest, in use, and in collaboration, so organizations can unlock value without increasing risk.
For regulated industries where traditional DLP breaks down under AI workloads, insider risk, and cross-border constraints, Duality provides the missing layer: secure computation on sensitive data.
Secure the data. Use the data. Prove it’s safe.
