Data Classification vs Data Discovery: Which to Run First and Why

Most classification programmes stall because they try to label data nobody has found yet, while most discovery projects stall because they find millions of sensitive items and have no scheme to say which ones matter. Data discovery answers where data is and what it contains; data classification answers how much it matters and what must happen to it. The two are often sold in one tool and confused in one project plan, yet they have different owners, different accuracy problems and different outputs. This guide sets out the order of operations, how each fails, where the tooling overlaps (DSPM, cloud discovery services, Microsoft Purview) and when one pass can do both. It is for data security, privacy and cloud teams. For scheme design, labelling methods and handling rules, see the Data Classification Guide.

Key takeaways

• Short answer: discover first, then classify, then loop. A first discovery pass sizes the estate and shows where sensitive data concentrates; classification then assigns levels and handling rules; continuous discovery keeps both honest.
• Discovery is a scanning problem, classification is a decision problem. Discovery is run by platform and security teams with connectors and detectors; classification needs a data owner to decide the level and accept the handling rule.
• A detector match is not a classification. A credit card pattern in a file tells you a data type is present; whether that file is Confidential or Restricted depends on volume, context and purpose, which a scheme and an owner decide.
• One pass can do both only where rules are already written. Once a scheme maps detector results to levels, an auto-labelling or DSPM policy can find and label in one motion; before that, automation just labels guesses at scale.
• AI training data makes the order non-negotiable. Copies made for model training and evaluation are the shadow data discovery exists to find, and the EU AI Act expects documented origin and preparation for high-risk systems.

What each one is, in practice

Data discovery is the continuous process of finding data stores and the sensitive content inside them: buckets, databases, warehouses, file shares, SaaS repositories, endpoints and backups. Its output is an inventory: locations, data types detected, volumes, owners where known, and exposure such as public links or broad access. The NCSC's asset management guidance puts the principle plainly: know what data you manage and what business need it supports, including less obvious locations such as backups, local caches and downloads.

Data classification assigns each data set or item a level from a scheme (for example Public, Internal, Confidential, Restricted) and, through that level, a set of handling rules: who can access it, whether it can be shared externally, whether it must be encrypted, how long it is kept. Its output is a label that a control reads.

The confusion comes from the detection layer both share. Sensitive information types, regular expressions with checksums, exact data match, named entity models and trainable classifiers are used by discovery to say "this contains passport numbers" and by classification to say "therefore apply Restricted". Microsoft Purview, for example, groups sensitive information types, named entities, exact data match, trainable classifiers, fingerprinting and OCR under one Classifiers page, and the same classifiers drive both its Data Explorer view of where matching items sit and its auto-labelling policies.

Side-by-side comparison

Discovery in depth: threat model, architecture and failure modes

Threat model: discovery exists because attackers find data you have forgotten. Collection techniques in MITRE ATT&CK such as Data from Cloud Storage (T1530), Data from Information Repositories (T1213) and Data from Network Shared Drive (T1039) work best against stores with nobody watching them: the test copy of production, the analyst's export, the old share.

Architecture in words: a discovery layer connects read-only to each platform, enumerates stores, samples or scans content with detectors, and writes findings to an inventory with a sensitivity estimate and exposure context. Cloud native services show the pattern clearly. Platforms are listed alphabetically:

• Amazon Macie: automated sensitive data discovery continually evaluates the S3 bucket inventory and uses sampling to select representative objects, producing findings and a sensitivity score per bucket each day; targeted sensitive data discovery jobs are then run for deeper analysis of a specific location.
• Google Cloud Sensitive Data Protection: discovery produces data profiles at project, table, column or bucket level with predicted infoTypes and calculated data risk and sensitivity levels, covering BigQuery, Cloud SQL, Cloud Storage and Vertex AI training data, and can profile Amazon S3 and Azure Blob Storage; a BigQuery profile can be followed by a deep inspection.
• Microsoft Purview: on-demand classification scans files at rest, including files never classified, and Data Explorer shows items with classification matches and where they are; Purview DSPM adds an Asset explorer view of labelled and unlabelled sensitive data by workload and data risk assessments for oversharing.

The common design choice is sampling for breadth, then deep scans where sampling points. That is the right default for estates measured in petabytes, but it has a cost: a sample tells you a bucket probably holds personal data, not which objects, so it is a basis for prioritising, not for scoping a breach notification.

Failure modes:

• Coverage gaps: connectors exist for the main cloud and SaaS platforms, but on-premises databases, laptops, collaboration exports and backups are often outside scope.
• Detector noise: pattern detectors without checksums or supporting evidence flag order numbers as card numbers and test data as live data. Tune with confidence levels and proximity rules before anyone acts.
• Ownerless findings: a finding that says "47,000 records with national insurance numbers in an unowned bucket" needs a route to someone who can delete, move or justify it. Without that route, discovery produces a growing backlog.

Controls that discovery feeds: deletion of stale copies, removal of public links and broad grants, encryption of unprotected stores, ROPA updates and the risk register. See the Data Security Posture Management (DSPM) guide for the posture remediation side.

Classification in depth: threat model, architecture and failure modes

Threat model: classification addresses misuse of data you do know about: the confidential file shared to a personal account, the restricted data set copied to a less protected environment, the record kept long after its purpose ended. It does this indirectly, by giving controls a signal to act on. DLP blocks on a label, encryption follows a label, retention deletes on a label.

Architecture in words: a scheme defines levels and handling rules; a labelling system attaches the level to items (document metadata, email headers, catalogue tags, column tags) through default labels, recommended labels, automatic policies or manual choice; enforcement points read the label. In Microsoft 365, client-side auto-labelling runs in Office apps as content is edited and can recommend a label for the user to accept, while service-side auto-labelling policies label files at rest in SharePoint and OneDrive and email in transit through Exchange. Service-side policies must run in simulation at least once before they can label, and a simulation takes about 12 hours and reports matches without applying labels. Manually applied labels are not replaced by default.

Failure modes:

• Detector equals level: mapping "contains one email address" straight to Confidential floods the estate with high labels, users stop trusting them and override rates climb.
• Labels without enforcement: a label is only worth the controls that read it. The DSPM vs DLP guide covers how DLP rules should consume the same scheme.
• Structured data left out: documents get labels, while warehouses and databases, where bulk personal data actually sits, get none. Column level tags in the catalogue are the structured equivalent.

The order of operations

The practical sequence is discovery, scheme, classification, enforcement, then continuous discovery to catch drift. The reason to discover first is sizing: without a first inventory you do not know whether the problem is 40 stores or 4,000, whether personal data sits mainly in SaaS or in a warehouse, or which business units need data owners appointed. The reason not to wait for perfect discovery is that the scheme and owners take months to agree, and discovery findings without a scheme cannot be prioritised.

1. Scope and connect (weeks 1 to 4): list platforms from cloud account inventories, SaaS admin consoles and procurement records. Connect discovery read-only to the largest stores first. Record what is not covered.
2. Baseline discovery pass (weeks 2 to 8): run sampling-based discovery with a small set of high-confidence detectors: national identifiers, payment card numbers with checksum, health terms with supporting evidence, credentials and keys. Do not label anything yet.
3. Size and triage: rank stores by sensitive volume and exposure (public, external sharing, broad internal groups). Delete or lock down the obvious stale copies now; this is often the quickest risk reduction of the whole programme.
4. Agree the scheme and owners: using the baseline, agree three or four levels and the handling rule for each. Appoint a data owner for each top store. The Data Classification Policy Template gives the policy wording.
5. Write the mapping rules: express which detector results, volumes and contexts map to which level, for example "more than 100 national identifiers in one item, or any in a column, maps to Restricted". This is the step that lets later automation do both jobs in one pass.
6. Classify in simulation: run auto-labelling or catalogue tagging in simulation or audit mode, sample results with data owners, and tune. Set a default label for unlabelled new content.
7. Enforce in rings: enable labelling for one business unit or store type, then expand. Keep a rollback: label removal policies or tag reversion, and remember that removing a label which applied encryption also removes the encryption.
8. Run discovery continuously: new stores, unlabelled sensitive data and label drift become recurring findings with owners and due dates.

When one pass can do both

Tooling decides less than people think. DSPM products, cloud native services and labelling platforms all combine detection with some form of tagging. Purview DSPM, for instance, highlights sensitive content that lacks labels and can recommend applying labels as remediation, which is discovery handing over to classification inside one console. The question to ask a vendor is not "do you discover and classify" but "can I run discovery without labelling, review results, and then switch labelling on per store". See the Data Classification Tools buyer's guide for evaluation criteria.

Decision guidance by organisation and data shape

• Small organisation, mostly one productivity suite: run the suite's native discovery and simulation, agree three levels, set a default label, and auto-label two or three data types. A separate DSPM is rarely justified.
• Cloud-heavy, many accounts and data platforms: lead with discovery across accounts (cloud native services or DSPM). Classification of structured data usually lives in the data catalogue as column tags rather than in a document labelling tool.
• Regulated with existing scheme but low coverage: the scheme exists, so focus on the mapping rules and auto-labelling for well-defined types, then use discovery to measure unlabelled sensitive data as the gap.
• Large, federated estate: run discovery centrally and classification federated: a central team owns detectors and the scheme, business data owners own levels and exceptions.

AI training data: why discovery must lead

Training, fine-tuning and evaluation create copies: exports from production into object storage, feature tables, vector stores built from document libraries, prompt and response logs. They are created by data scientists and pipelines, often outside the stores the classification programme already covers, and labels on the source documents do not travel into embeddings or training tables. Discovery is how you find them; Google Cloud's discovery, for example, profiles Vertex AI training data as file store or table profiles depending on where it is held.

For providers of high-risk AI systems, Article 10(2) of the EU AI Act requires data governance practices for training, validation and testing data covering, among other things, data collection processes and origin (and for personal data, the original purpose of collection) and preparation operations such as annotation, labelling, cleaning and aggregation. That is a record of what data went in and where it came from, which is a discovery and lineage output first and a classification output second. Article 10(5) allows exceptional processing of special categories of personal data for bias detection only under strict conditions, including deletion once the bias is corrected or the retention period ends. Practical steps:

• Scan training and vector stores: include them in discovery scope explicitly, with detectors for personal data and secrets.
• Inherit the highest level: a training set or index built from mixed sources takes the highest level of its inputs until reviewed.
• Record lineage: keep source, purpose and preparation steps with the data set. See the AI Training Data Provenance and Copyright Exposure Guide.

The Microsoft SAS Token Exposure 2023 shows the shape of the problem: a link shared for AI research data covered a whole storage account holding 38TB, including workstation backups with secrets and internal messages, far beyond what the research data set needed.

Worked scenario

A retailer with three cloud accounts, a warehouse, a CRM and a collaboration suite has a four-level policy and labels on about 5% of documents. The board asks for a classification push.

1. Discovery first: a sampling pass across buckets, the warehouse and the suite finds 1,900 stores; 60 hold most of the payment and identity data; 14 buckets hold unmanaged exports of the customer table made for analytics and a recommendation model.
2. Quick wins: nine of the 14 exports are older than a year with no owner; they are deleted after a two-week notice. Two have public links, which are removed the same day.
3. Scheme fit: the existing four levels hold, but the policy gains a mapping rule set: card data and national identifiers in any volume to Restricted; customer contact data over 1,000 records to Confidential.
4. Classification: warehouse columns are tagged in the catalogue; documents are auto-labelled in simulation, sampled by owners, then enforced for finance and customer service first.
5. Loop: discovery now reports unlabelled sensitive items weekly. The labelled share of sensitive documents, not of all documents, becomes the board metric.

Where identity fits

Discovery and auto-labelling run as service identities with read access across the estate, and labelling identities also need write access to metadata. That makes them some of the most privileged non-human identities in the organisation. Use separate identities per platform, read-only where the product allows, managed or federated credentials instead of long-lived keys, and log their data access like any privileged account. Restrict who can see discovery results: an inventory of where sensitive data sits is itself sensitive. See the Service Account Security Guide.

Detection and measurement

• Discovery coverage: stores connected divided by stores known from account and SaaS inventories, by platform.
• Unowned sensitive stores: count and trend of stores with sensitive findings and no data owner.
• Labelled share of sensitive content: items with sensitive detector matches that carry a label, by store type.
• Classification accuracy: agreement rate from owner sampling of auto-labelled items, and override rate for recommended labels.
• Time to remediate exposure: median days from discovery finding (public link, broad grant, stale copy) to fix.
• Shadow copy rate: new unmanaged copies of tier-one data sets found per month, including AI training and vector stores.

Framework mapping

Common failure patterns

• Classification-first in the office suite only: user labelling launched with training, while warehouses, buckets and SaaS stores with the bulk of personal data are never scanned.
• Discovery as a one-off audit: a consultant-led scan produces a report; six months later the estate has changed and nobody reruns it.
• Auto-labelling before mapping rules: detectors switched straight to labelling apply Restricted to anything with a phone number, and owners ask for the whole thing to be turned off.
• Scanner findings dismissed as false positives: in the Microsoft SAS case the internal scanner had flagged the URL and it was marked a false positive. Sample dismissed findings, not just open ones.
• AI copies outside scope: training exports and vector indexes are created in project accounts the discovery connectors never reach.

Practitioner checklist

• Inventory platforms from account, SaaS and procurement records and record what discovery does not yet cover.
• Run a baseline discovery pass with a small set of high-confidence detectors before any labelling.
• Delete or lock down stale and publicly exposed copies found in the baseline.
• Agree a three or four level scheme and appoint owners for the top stores using baseline results.
• Write mapping rules from detector results, volume and context to levels.
• Run auto-labelling and catalogue tagging in simulation, sample with owners, then enforce in rings with a rollback plan.
• Bring AI training data, feature tables and vector stores into discovery scope explicitly.
• Run discovery and labelling under separate, least-privilege service identities and restrict access to results.
• Report coverage, unowned sensitive stores and labelled share of sensitive content monthly.

Standards and references

• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• EUR-Lex: Regulation (EU) 2024/1689, Artificial Intelligence Act
• NCSC: 10 Steps to Cyber Security, Asset management
• CIS: Control 3, Data Protection
• AWS: Amazon Macie automated sensitive data discovery
• Google Cloud: Sensitive Data Protection data profiles
• Microsoft: Apply a sensitivity label to content automatically

Related NHI Mgmt Group resources: Data Classification Guide, Data Security Posture Management (DSPM), Data Classification Tools, Microsoft Purview Information Protection Guide, Data Loss vs Data Breach vs Data Leak.