← Back to Concept Contrast

Concept Contrast Fable

Data exfiltration and data loss prevention: one is an incident that has already happened, the other is a wall that prevents incidents

Conclusion first:A data breach is a realized event in which data leaves a controllable scope without authorization. Data loss prevention is a set of policies, tools, and processes used to stop, detect, and respond to data breaches. Treating a tool name as an incident type leads to expressions like "deployed a data breach" in security reports, which auditors cannot understand and regulators understand even less.

A data breach is a realized event in which data leaves a controllable scope without authorization. Data loss prevention is a set of policies, tools, and processes used to stop, detect, and respond to data breaches. Treating a tool name as an incident type leads to expressions like "deployed a data breach" in security reports, which auditors cannot understand and regulators understand even less.

Fable

The granary had two ledgers: one recorded how much was missed, the other recorded how much wall was repaired

The prefectural granary in the northern border kept 300,000 shi of military grain year-round, a heavy responsibility. The granary had four walls: the outer wall kept idlers out, the inner wall separated different batches of grain, the third wall was a daily inventory system, and the fourth was an inspection team. The old supervisor in charge of the granary called these four together the "granary leak-prevention system" and reported its status once a year.

In the autumn of the third year, something happened. The patrol team discovered a strange carriage parked on the east side of the granary at midnight, carrying two hundred shi of military grain, and the two people pulling the cart had already fled. The old supervisor wrote two documents overnight: the first was called "Granary Leak Incident Report," detailing the time, quantity and exit location of the loss. The second was called "Granary Leak Prevention System Rectification Plan," analyzing what vulnerabilities each of the four walls had—the east side corner gate of the outer wall was unlocked, and the inventory system had missed the inbound record for that batch of grain.

The prefecture forwarded the documents to the capital. A bureau official in the Ministry of War read them and sent back a letter with just two lines: the first said the leak incident had been reported promptly; the second said that in your remediation plan you still put "leak" and "leak-prevention system" in the same column. If the next audit looks only at that column, how can they tell whether you mean the incident itself or the protective tool?

The old supervising secretary spread the letters on the table and thought for half an hour, then pulled out all the security documents from the past five years. He found that the last page of every annual report had only one column called "Security Status"—sometimes it read "no leaks," sometimes "leak-prevention system upgraded," sometimes even "leak risk controllable." The term "security status" was like a big pot into which everything was dumped.

He redesigned the report format into two columns. The left column was called "Security Incidents" and recorded only breaches that had already occurred, each with time, quantity, and characterization. The right column was called "Protective Measures" and recorded only status changes to policies, tools, and processes. He took the new format to the prefecture to request budget — "deployed a new wall" could no longer be mixed together with "no breach occurred"; they cost different money and were reported to different people.

After reviewing the new ledger, the prefecture quickly discovered a fact: last year the "safety status" column said "protective measures updated," and because it was mixed into the same column, no one asked whether a breach had occurred. After the split, the left side was blank but the right side recorded a change — budget was spent on prevention, with no incident; in years where the left side had a record but the right side had no update — an accident occurred but the protection system stood still.

Later, the capital copied the old deputy supervisor's two-column format into the annual report template for every granary nationwide. The same logic applies in data security: DLP is the protection system you build—monitoring, blocking, auditing, encryption—while a data exfiltration event is one that this system could not stop or did not stop. You cannot say "we deployed data exfiltration"; you can only say "we deployed DLP and report whether data exfiltration events exist."

Data exfiltration

An incident that has already occurred in which data was transferred without authorization from an internally controllable scope to the outside. It is an outcome and requires reporting and response. Key attributes include time, outflow path, data type, and volume.

Data loss prevention

A set of policies, tools and processes for detecting, blocking and responding to potential data leakage. It is a protective capability, not the incident itself. Common measures include network traffic monitoring, endpoint control and content identification.

Story Mapping

  • The granary's four walls: DLP's multi-layered protection system (physical, process, technical, personnel)
  • Two hundred shi of military grain hauled away by cart: data exfiltration incident—a fact that has already occurred
  • Two documents (leak report and remediation plan): separating incident response from security system improvement
  • The Ministry of War official's criticism: mixing concepts makes audit impossible to judge
  • How to write a section of a five-year security document: the real-world consequences of not distinguishing between incidents and protections
  • The new ledger has two columns: event records on the left, protective measures on the right—the correct format for security governance
  • Granaries nationwide adopt a two-column template: industry standardization drives concept separation

Down to security reports and compliance filings

When writing security reports, filling out customer security questionnaires, or reporting to regulators, put "data breach incidents" and "DLP controls" in different sections or fields. "We deployed DLP and it runs well" and "we have not had a data breach incident" are two statements and cannot be compressed into one. "Deployed a data breach" is itself a logical error. Auditors and regulators will check the logical consistency of your report: if you mention a DLP policy but cannot distinguish its boundary from incidents that have occurred, they may judge that your security management framework lacks effective classification.

京ICP备2026014272号