ArticlesDetecting Sensitive Information Beyond Fixed Patterns

A tax ID is easy to catch. It has a shape, and a rule can match the shape. Next year’s strategy, sitting in a document somewhere, has no shape at all. That is the problem in one line: some of the content most worth protecting is the content hardest to detect.

Content detection runs on a spectrum, and one end is far easier to cover than the other. It is not the only end where serious consequences live.

At one end is deterministic content: a pattern a sensitive information type (SIT) can recognize with rules, regular expressions, or a checksum. A social security number, a physical address, a known document fingerprint. A match is not, by itself, proof of sensitivity, accuracy, or low noise: sensitive information types combine patterns with supporting elements, proximity, and confidence levels, and they have to be tested in the workloads where they run. Still, this is the content detection most programs are best at, because it is the easiest to build and to demonstrate.

At the other end is opaque content: a strategy document, source code, a pre-release design, an internal memo that would matter if it left. Sensitive not because of its structure but because of its meaning and its context. There is no regular expression for “acquisition plan.” There is no checksum for the deck that sets next year’s roadmap. The content may carry no signature a deterministic matcher can catch, although an unstructured document can contain recognizable elements.

Between the two ends sits a wide grey zone: semi-structured content, files that sometimes carry markers and sometimes do not. Most real content lives in that middle, and most of the interesting design decisions live there too. It is tempting to treat detection as binary, matched or unmatched, when the real work is the gradient.

The part that should bother you#

The difficulty of matching content and the cost of losing it are different properties, and a program that measures only the first can mistake it for the second.

Some sensitive content is structured, and structure is matchable: personal data, account numbers, formatted records. Other sensitive content is unstructured and harder to read: strategy, intellectual property, source code, design. Structure does not determine value: an exposure of structured personal data can do serious harm to the people concerned and to the organization. But what gives an organization its edge is often unique, contextual, and irreducible to a pattern, which is exactly what makes it hard to fingerprint.

The same logic runs along the org chart, not just across content types. The further up you go, the less structured trace the work leaves behind, because the work itself changes shape. There is a meme that captures it better than any diagram: the junior analyst runs three monitors, and the person at the top can barely be bothered with a phone. It reads as a joke about seniority, but it is really a description of the job. Operational work is instrumented by nature, every step a logged action. Decisional work is not. A choice that reroutes a strategy does not pass through a SIT, and the more senior the role, the more its output is judgment rather than artifact. The most consequential work in the building tends to leave the least to match against.

This is a tendency, not a law. Structured data can be extremely valuable, and plenty of opaque content is worth nothing. But for the content that carries an organization’s edge, the absence of a deterministic signature is common enough to matter, and a program that counts only what it can match will not see it.

Why investment flows to the easy end#

Programs gravitate toward the deterministic end, and the reasons are rational, which is what makes them hard to correct.

Deterministic detection produces clean metrics. The SIT catches a passport number and the count is defensible, although a match and a count do not, by themselves, show that the control is adequate. It generates alerts you can stand behind, because the match is unambiguous. Opaque detection produces the opposite: messy precision, false positives, and the unwelcome truth that you cannot easily measure what you are not catching. Faced with a choice between a number that looks good and a problem that resists measurement, organizations drift toward the number.

So coverage accumulates where it is comfortable to demonstrate, not where the loss would hurt most. A program can report excellent content detection and still be blind to the exfiltration that would actually damage it, because the damaging content was never the matchable kind.

I have watched this happen. A program presenting strong content-detection numbers, every one of them real, while the thing that would have actually mattered moved in a form no rule was ever going to catch. Not negligence. Just attention pointed at the half of the problem that answers back.

Three honest directions#

There is no clean fix, but there are three directions worth thinking through, and each is a trade-off rather than a solution.

The first is to move detection from content to context. If you cannot match what the file is, read where it came from, who normally touches it, and where it is going. Provenance and movement become a proxy for sensitivity when the content itself is silent. The trade-off is precision. Context tells you a file is probably sensitive, not that it certainly is, and it asks the program to reason about behavior rather than strings.

The second is to move the problem upstream, to classification at the source. Labeling at the moment of creation gives opaque content a deterministic handle it would not otherwise have, because the file carries its own label from then on. The trade-off is dependence. You have shifted the cost onto process and user discipline, and the detection downstream is only as good as the classification upstream. Where labeling is skipped or wrong, you are blind again, and you may not know it.

The third is to accept the residual. Some content is irreducibly semantic and will not be matched by any rule, and for that fraction the answer is not a better expression. It is behavioral analysis and human judgment. Models that read meaning can extend detection, but they do not remove the questions of purpose, error, context, and validation; the residual remains a matter of judgment. This does not scale the way a rule does, and it is the part of the program that resists automation, but it is the only thing that covers content whose sensitivity lives entirely in meaning. Better to design for that residual on purpose than to assume a strong enough ruleset will eventually absorb it.

If I had to weight them, I lean on the first. Classification at the source is the most elegant and the most fragile, because it rests on discipline you do not control. The residual is real and worth designing for, but it is the last line, not the first. Context is the one you can build now, on signals you already hold. When it is wrong it can still produce improper blocks or suspicion, so it needs testing and limits on automatic consequences. It is the least satisfying of the three, and usually the right place to start.

The question worth asking#

Some sensitive information has recognizable patterns; other material depends more heavily on meaning and business context. Neither structure nor detection difficulty determines its value. Effective protection combines appropriate classification methods, contextual signals, and validation against representative data.

None of this argues against deterministic detection. The SIT that catches structured sensitive data is necessary and worth having. The argument is about where a program points its attention when it decides it is doing well.

The useful question is not how much sensitive content you can match. It is how much of your real risk lives in the content you cannot match, and what you are doing about that part specifically. A program that measures only its coverage of the matchable is measuring the easy half of the problem. The harder half is where the content worth stealing tends to live.