What You Need to Know about AI Security
July 27, 2026
Getting the Sequence Right: Discovery, Categorization, Classification and Tagging in Data Protection
BLOG
5 min.
TL;DR: Data discovery and classification are often treated as a single capability, but effective data protection depends on four distinct, sequential activities: discovery, categorization, classification and tagging.
Key takeaways:
- Each activity serves a different purpose and must be completed in sequence to produce reliable enforcement
- Conflating these activities leads to inconsistent classifications, ineffective tagging and poor (Data Loss Prevention) DLP outcomes
- Before tuning policies or deploying more labels, ensure your foundational data capabilities are in place
The Conflation Problem
The rapid adoption of AI has pushed data discovery and classification back to the top of many security agendas. Board of Directors want to know what sensitive data the organization holds. Regulators want evidence of control. The market has responded. Vendors across the industry are racing to deliver discovery and classification capabilities at scale, with levels of accuracy and precision that were not achievable even a few years ago.
Yet the phrase “discovery and classification” has become a catch-all that collapses four distinct activities into two words, and in doing so, obscures the sequence those activities must follow to produce any enforceable result.
Those four activities are discovery, categorization, classification and tagging. They are not synonyms. They are not interchangeable. And they cannot be executed out of order. Because active controls like Data Loss Prevention (DLP) sit at the end of this chain, a break anywhere upstream means the controls either do not fire, fire incorrectly or generate so much noise that teams disable them.
Let me break each activity down, explain why sequence is crucial and show where programs most commonly fall apart.
The Four Activities
1. Discovery: Finding What You Have
Discovery is the process of locating data across your environment. Where does it live? What systems hold it? What formats is it in (structured, unstructured, semi-structured)? Is it stored on premises, in cloud storage, within SaaS applications, or on endpoints? Before you can protect or govern data, you need a clear understanding of where it resides.
Discovery is not a one-time project, it is a continuous operational capability. Data moves. New systems are provisioned. Shadow IT emerges. A one-time scan tells you where your data was on any given day, not where it is today and certainly not where it will be tomorrow.
The goal of discovery is simple: to establish a comprehensive inventory of your data and the visibility needed to understand your environment. Nothing more. At this stage, you are not classifying, prioritizing or making decisions about the data. You are identifying what exists and where it can be found.
Common mistake: Treating a single scan as “done.” Discovery is an ongoing process because your data environment is constantly changing.
2. Categorization: Making Sense of What You Found
Once you know where data lives, you need to understand what kind of data it is. Categorization is the process of grouping data by its nature, content or business purpose. Common categories include:
- Personally Identifiable Information (PII)
- Protected Health Information (PHI)
- Payment Card Data (PCI)
- Intellectual Property (IP)
- Financial Records
- Legal or Privileged Communications
Categorization is descriptive, not evaluative. At this stage, you are not yet deciding how sensitive the data is or what protections it requires. You are simply answering the question: what is this?
This step is often glossed over because organizations jump directly from discovery to classification. But categorization is the essential bridge between finding data and determining its sensitivity. A consistent categorization framework establishes a common vocabulary for describing data, making classification more objective, repeatable and scalable. Without that shared foundation, two analysts who are independently evaluating the same dataset without a shared categorization framework, may reach different conclusions about the same data because they started from different assumptions about what the data is.
Common mistake: Conflating a data category (what the data is) with data categorization (how sensitive the data is). These are distinct determinations and serve different purposes.
3. Classification: Assigning Sensitivity and Policy Intent
Classification is where you apply a judgment about the data’s sensitivity level and the policy treatment it requires, based on its categorization – content, context and intended use. Unlike categorization, which describes what the data is, classification determines how it should be handled. A typical classification scheme includes levels such as:
- Public: Approved for unrestricted external sharing
- Internal: Intended for use within the organization only
- Confidential: Restricted to specific individuals, roles, or teams
- Restricted | Highly Confidential: Subject to the organizations most stringent controls and access requirements
Classification answers a simple but critical question: how should this data be handled?
This is the step most organizations fixate on: Publishing a classification policy, deploying sensitivity labels across their productivity suite and declaring victory. But classification is only as effective as the information that informs it. Without comprehensive and continual discovery, as well as categorization, much of your data is never evaluated. The problem is that classification without categorization produces inconsistent results and classification without prior discovery means large volumes of your data are never classified at all. So, the same type of data may be assigned different sensitivity levels by different people or systems.
Effective classification also requires governance including clearly defined policies and consistent decision criteria. Organizations should be asking:
- Who has the authority to classify data?
- What happens when data falls into more than one category?
- What triggers reclassification?
These are program design questions, not tool configuration questions. The same data should be classified the same way regardless of who encounters it or where it resides. When classification decisions vary from team to team, the result is inconsistent protection, increased risk and reduced trust in the program.
Common mistake: Treating classification as a technology problem. It is first a governance problem, then a technology problem.
4. Tagging: Making it Usable
Tagging is the act of applying a persistent, machine-readable marker to data that carries the classification forward so it can be recognized and enforced by downstream systems. A tag may take the form of a metadata label embedded in a file, a property applied by a DLP platform or a sensitivity label baked into a document at creation time.
Tagging answers the question: How do security tools know how this data should be handled?
A classification decision has little practical value unless it can be consumed by security technologies, tags provide that signal. DLP, Cloud Access Security Brokers (CASBs) and rights management tools rely on tags to determine which controls to apply. Without a tag, a policy engine has weakened or incomplete signals to act on. It must rely entirely on real-time content inspection, which is slower, less accurate and does not scale.
Tags also need to be durable. A classification decision made at discovery time should travel with the data as it moves across systems and workflows; when someone emails a file, copies it to a USB drive, uploads it to a cloud storage service or shares it with an external party. When the tag travels with the data, security policies can travel with it. If the tag is lost, the connection between the data and its intended protections is lost as well.
Common mistake: Assuming classification alone drives enforcement. Security tools enforce policies based on signals they can read and tagging provides that signal.
Microsoft Sensitivity Labels as a Tagging Example
One of the most widely deployed tagging implementations today is Microsoft Sensitivity Labels, available through the Microsoft Purview compliance platform. When a user opens a Word document, Excel spreadsheet or email in Microsoft 365 and applies a sensitivity label, such as “Confidential”, they are performing a tagging action. That label is embedded as metadata in the content itself. This allows Microsoft services and supporting security tools to recognize and act on it as the data move across Microsoft 365.
This is a meaningful capability because the label becomes a machine-readable signal for downstream controls. Microsoft 365 DLP policies, Conditional Access rules and Azure Information Protection can all read that label and determine how the content should be handled, for example, blocking unauthorized sharing, requiring additional authentication or applying encryption automatically.
However, this is also where organizations frequently overestimate what they have achieved. In reality, applying sensitivity labels to documents is a tagging mechanism. It is not, by itself, classification and it is not a data protection program. The label is only as reliable as the classification decision behind it. If users are self-labeling without training, without a clear categorization framework and without automated enforcement to catch mislabeled or unlabeled content, the tag population will be inconsistent and incomplete, and the downstream controls will reflect that inconsistency.
Sensitivity Labels are a powerful implementation of tagging, but they only deliver value when they are supported by upstream activities (discovery, categorization and classification) and downstream controls. The quality of the tag depends on the quality of the process that produced it. The value of the tag depends on how effectively controls can make use of it.
Common mistake: Assuming that because a user has applied a Sensitivity Label in a document, the tag is being enforced downstream. Tags must be integrated into the control plane, they are not self-enforcing.
Why the Sequence is Crucial
Think of it this way: imagine you are responsible for organizing a large, disorganized archive. Before you can put a restricted-access sticker on a folder, you need to know:
Skip any step and the sticker either never gets applied, gets applied to the wrong things or means nothing to the system enforcing access. The sequence is not a methodology preference, it is a logical and critical dependency chain.
Where DLP Fits in and Why it Fails
DLP platforms sit at the enforcement layer. They consume the output of the entire chain above. When a DLP policy is configured to block transmission of “Restricted” data, it is looking for the tag that was applied when the data was classified as Restricted. It should have been based on its categorization and that should have been informed by discovery.
When DLP programs fail to deliver value, the cause is almost always upstream:
- Data was never fully discovered, so significant volumes carry no classification or tag
- Categorization was skipped, leading to inconsistent classification decisions
- Classification was performed inconsistently or without governance, producing unreliable tags
- Tags were applied in one tool but are not recognized by the DLP platform in use
The result is either under-blocking (sensitive data leaves undetected) or over-blocking (legitimate business activity is flagged). Both of these erode confidence in the program and lead to scope reduction or abandonment.
Where is Your Program in the Sequence?
Before investing in additional DLP tuning, policy refinement or classification label schemes, first determine where your organization is in maturing its data security program. Advanced controls are only as effective as the processes that support them. Understanding your current capabilities helps maximize the value of the investments you have already made before expanding to new ones.
Reach out if you need help maturing your data security program and strategy.
Terry Cordes, Attack Simulation Architect at GuidePoint Security, began his information security career in 2012 after 18 years developing complex software systems for the logistics and financial industries. Since moving into security full time, he has focused on vulnerability management with emphasis on penetration testing and attack simulations. He has experience running a vulnerability management program for a financial services company as well as performing and managing security assessments for a global life sciences company.
