What the list is for
A dirty word list does one job: it tells the system which content deserves a closer look. The list is harmless on its own. Its value comes from the channel it guards, such as outgoing email or file uploads, where a hit can trigger an alert, a quarantine or a block. In a data loss prevention program, it is the quickest way to describe what counts as sensitive information.
The idea is older than any product. Security teams have always named what must not leave the building, from project code names to unreleased prices. A dictionary turns that knowledge into a rule the system can apply to every message at once.
What goes on the list
Lists are usually organized as topical dictionaries, not one flat file. A policy can then call “payment data” or “HR records” instead of thousands of loose terms. Markings from data classification are a common starting point, because a label the team already applies is a reliable signal.
| Category | What it covers |
|---|---|
| Classification markings | Confidential, Restricted, Internal Use Only, and handling caveats |
| Project and client code names | Identifiers that reveal a confidential initiative on their own |
| Regulated data indicators | Terms from personal, health, or payment records, such as IBAN |
| Technical secrets | Private keys, BEGIN RSA, passwords, connection strings, api_key |
| Business-sensitive vocabulary | M&A language, pre-release pricing, unpublished results, litigation terms |
Why keyword dictionaries still matter
Keyword dictionaries need no prior registration of documents. That lets them flag unstructured data that nobody had registered or even knew existed.
They are transparent: an analyst can read the rule and see exactly why it fired. They are also cheap to run at scale, and they are the natural way to encode knowledge that belongs to one organization. A code name means nothing to a general-purpose model and everything to the company that uses it.
How matching is refined
Raw keyword matching alone produces unusable volumes of alerts. Practical implementations add the mechanisms below, and each one narrows what counts as a hit.
| Mechanism | Effect on alerts |
|---|---|
| ProximityTerms must appear near each other to count | Drops mentions scattered across a long document |
| ThresholdsA minimum number of distinct matches is required | Ignores a single stray word |
| WeightingStrong indicators fire alone, weak ones need support | Keeps weak hits from raising an alert by themselves |
| MorphologyStems and inflections for highly inflected languages | Catches word forms the list does not spell out |
| ExclusionsMatches in published material or known templates | Stops alerts on public or boilerplate text |
| Pattern rulesRegular expressions and checksums | Confirms that a number is a real identifier, not just a matching string |
Where the method falls short
The technique is imprecise by nature. A term can appear in genuine records, training material, policy discussions, or unrelated text that shares the same vocabulary. Each of those cases is a false positive, and false positives teach reviewers to dismiss alerts.
False negatives come from paraphrasing, abbreviation, deliberate misspelling, translation, and content that has been turned into an image. Lists also decay. Code names change, new products appear, and a dictionary nobody maintains slowly protects last year's secrets.
How the thesauruses look in Anexet
Anexet ships these thesauruses as ready-made categories that policies can reference by name. The list shows each category with its word count and search count, so noisy sets are easy to spot before a policy goes live. The same categories are used in Anexet DLP.
Where it fits today
Dictionary matching is one layer, not a strategy. It is usually paired with exact-match hashes for known files, digital fingerprints for the most important documents, and statistical or model-based classifiers for categories that resist enumeration.
The dictionary layer earns its place because it catches what the other methods cannot see: unregistered content and terms specific to the organization. Anexet covers the three approaches together, as described in digital fingerprinting.
| Capability | Keyword dictionary | Digital fingerprint | Hash bank |
|---|---|---|---|
| Works without registering documents first | |||
| Finds unregistered organization-specific terms | |||
| Matches registered documents and templates | |||
| Matches exact copies of known files |
Where to start
Start with the words that would hurt most if they leaked, then check the channels where they actually travel. A policy written for every term at once blocks ordinary work, and people find their way around it.
Further reading: DLP Systems — what it is and how it works.
A leak rarely starts with a sophisticated attack. It starts with an ordinary word in an ordinary message.
Anexet TeamHow Anexet handles this
Dictionary matching is delivered in Anexet as security thesauri, maintained as a ready-made layer rather than a blank list to fill in:
170 pre-built dictionaries
curated thesauri covering regulated data categories, technical secrets, and business-sensitive vocabulary, extensible with organization-specific terms and code names.
Refined matching
rules combine dictionary hits with proximity, thresholds, and pattern validation for structured identifiers, so policies fire on records rather than on passing mentions.
Layered with other methods
hash banks for exact file matches, digital-fingerprint libraries for documents and templates, and sensitivity-label integration cover what dictionaries cannot.
All monitored channels
the same inspection applies to email, web, cloud storage, messengers, removable devices, printing, and clipboard, with actions from log and alert to quarantine and block.
Audit trail and on-premise architecture
matches are recorded with user, timestamp, channel, matched rule, and action, and dictionaries, inspected content, and logs stay inside the organization's own infrastructure.
Anexet DLP
Learn more