When a lawyer sits down with a client to draft a privacy policy—whether for internal governance or external disclosure—the first question is deceptively simple: “Are you collecting any personal data?” Or its more formal cousin: “Are you collecting personally identifiable information (PII)?”

The answer, almost invariably, is immediate, confident, and wrong.

The typical response—“No”—is rarely a deliberate misrepresentation. It is instead the product of definitional ambiguity, technical opacity, and, occasionally, willful blindness. Clients tend to think of “personal data” in narrow, almost antiquated terms: Social Security numbers, credit card numbers, perhaps medical records. Counsel, unless deeply versed in modern data architectures, may fail to expand that definition to include device identifiers, behavioral telemetry, inferred preferences, geolocation metadata, and the countless exhaust streams generated by contemporary digital systems.

The result is a fundamental disconnect between what organizations believe they collect and what they actually collect.

That disconnect matters because virtually every modern privacy regime—whether under the General Data Protection Regulation, the California Consumer Privacy Act, or sectoral U.S. frameworks like the Health Insurance Portability and Accountability Act—imposes obligations not merely on intentional collection, but on processing, storage, dissemination, and protection of personal data in all its forms. These regimes are agnostic to whether the data was consciously “collected” or passively “generated.” If the organization touches it, it owns the risk.

And that is where the problem becomes more insidious. Even when companies are not experiencing what would traditionally be classified as a “breach”—an unauthorized intrusion or exfiltration—they are nevertheless leaking data constantly. Not in a single catastrophic event, but incrementally. Quietly. Persistently. Drip by drip. It’s not a broken tap. It’s just a leaky one.

Consider the modern enterprise environment. Employees operate within a dense ecosystem of applications—email, messaging, collaboration, project management—each of which collects and processes user data as a matter of course. Empirical analysis shows that workplace applications collect, on average, approximately nineteen distinct categories of data and routinely share multiple data types with third parties. This is not an aberration; it is the business model.

Applications such as Microsoft Teams, Zoom and Slack routinely collect not just communications content, but metadata—who spoke to whom, when, from where, using what device. Some collect precise geolocation data. Others harvest behavioral patterns: Keystroke cadence, interaction frequency, and even inferred productivity metrics. Still others share identifiers—email addresses, device IDs, user profiles—with advertising networks or analytics providers.

Each of these transmissions may be authorized under a privacy policy – assuming their use and disclosure were explained to counsel writing the policy, or that anyone thought of the fact that these ordinary business applications were collecting or processing privacy-related information. Each may be “disclosed.” Each may be technically compliant.

But collectively, they constitute a continuous exposure surface.

This phenomenon is not well captured by traditional breach notification statutes, which are typically triggered by discrete events—unauthorized acquisition, access, or disclosure. See, e.g., Cal. Civ. Code § 1798.82 (West 2024) (requiring notification following unauthorized acquisition of personal information). The law is structured around punctuated equilibrium: a breach happens, notification follows.

What it does not adequately address is the steady-state leakage that occurs in the ordinary course of business operations. This leakage is multidimensional.

First, there is intra-platform dissemination—data shared within a vendor’s ecosystem. A message sent through a collaboration tool may be analyzed by integrated AI systems, indexed for search, used to train models, or correlated with other enterprise data streams.

Second, there is inter-platform sharing—data transmitted to third-party service providers, analytics firms, and advertising networks. Even where anonymization or pseudonymization is claimed, re-identification risks persist, particularly when datasets are combined.

Third, there is user-side exfiltration—data harvested by malware, browser extensions, or compromised credentials. A striking example involved the exposure of tens of millions of email credentials derived not from a breach of the service provider itself, but from infostealer malware operating on end-user devices.

Fourth, there is administrative access—the often-overlooked reality that system administrators, and sometimes the platform providers themselves, retain the technical capability to access user communications. In some environments, this access extends to purportedly “private” messages, raising both privacy and evidentiary implications.

From a legal perspective, this raises a critical question: when does a “leak” become a “breach”?

Courts have struggled with analogous definitional issues in other contexts. In TransUnion LLC v. Ramirez, 594 U.S. 413 (2021), the Supreme Court emphasized that statutory violations alone are insufficient for Article III standing absent concrete harm. The mere existence of inaccurate data, without dissemination, did not create injury. Conversely, in cases involving actual disclosure, courts have been more willing to find cognizable harm. But what of incremental disclosures—authorized individually, but cumulatively invasive?

Regulators, however, are beginning to recognize the issue. The European Data Protection Board has signaled increasing concern with secondary uses of data, particularly in the context of AI-driven processing and third-party sharing. The emphasis is shifting from discrete breach events to lifecycle governance—how data moves, evolves, and proliferates over time. For practitioners, this has immediate implications.

First, the initial client interview must be reframed. The question is not “Are you collecting personal data?” but rather “What data is generated, observed, inferred, or transmitted by your systems—intentionally or otherwise?” This requires technical fluency and, often, collaboration with engineering teams. How does data flow through your system? Who uses it and how? Does the data subject know this?

Second, privacy policies must move beyond static disclosures to dynamic mapping. Boilerplate language about “reasonable security measures” and “trusted partners” is increasingly insufficient. Regulators and litigants alike are demanding specificity.

Third, risk assessments must account for aggregation effects. A single data point—a device ID, a timestamp—may be innocuous. Combined with other data, it becomes identifiable and, therefore, regulated.

Finally, organizations must confront an uncomfortable reality: Compliance is not synonymous with containment. A company may fully comply with disclosure requirements, obtain user consent, and implement industry-standard security controls—and still be hemorrhaging data in ways that create legal, reputational, and operational risk.

The law, like the technology it seeks to regulate, is evolving. But for now, the dominant paradigm remains event-driven, while the risk environment is continuous. In that gap lies the modern privacy challenge. Not the catastrophic breach that makes headlines. Not the ransomware attack that triggers regulatory scrutiny. But the quiet, persistent, legally ambiguous seepage of data—one packet, one identifier, one API call at a time.

Drip. Drip. Drip.