What can DLP protect if nothing has been classified?

Very little. A DLP policy is only as good as the sensitive information types and labels behind it. If Contoso has never defined what its sensitive data looks like, DLP has nothing to look for.

Out of the box, Purview DLP recognises what Microsoft has already classified for every tenant: credit card numbers, PPSNs, IBANs, passport numbers, credentials. Useful, but none of it is Contoso’s. Not one built-in SIT knows what a Contoso project code, design specification, customer list or product roadmap looks like. Without classification, a DLP policy is left with two options:

• Match on Microsoft’s built-in types only. Personal and financial data is protected; Contoso’s intellectual property walks straight past every rule.
• Fall back on context alone. Block every attachment to an external domain, every upload to an AI app, every file copied to USB. That stops IP, and it stops the business with it. Users find a workaround within a week, and the policy is rolled back to audit within a month.

Blind or blunt: the policy either misses what matters or blocks everything. Classification is what gives it a third option – block what is sensitive and let everything else through.

The same applies to every control I have written about this month. I have blocked unsanctioned MCP servers, inspected traffic to AI apps, governed agents in Agent 365 and stopped credentials leaking from Exchange and Teams. Each of those posts answers the question where is this data allowed to go? None of them can answer the question that has to come first: what is this data? A network indicator blocks a destination whatever is sent to it. A Copilot policy can only exclude content that carries a label. Inline DLP can only block a prompt that matches a SIT.

The credentials post came closest to saying this. It works because Microsoft has already done the classification for you: the All Credential Types SIT ships ready-made, so the policy simply has to be switched on. Intellectual property gets no such head start.

The post that should have come first. This is the seventh post in the run, but it is the foundation the other six stand on. If you are new to the series, start here, then read the AI agent runtime protection series, Entra Internet Access inline DLP and Stopping leaked credentials with Purview DLP.

This post covers the classification methods Microsoft Purview offers, the different types of DLP that act on them, where you can find sensitive data already sitting at rest, and how to put it all together around the asset that is hardest to protect and most damaging to lose: Contoso’s intellectual property.

Key terms

If you are new to Purview, these are the terms the rest of the post relies on:

• DLP (data loss prevention) – policies that detect sensitive content and audit, warn or block when someone tries to move it.
• SIT (sensitive information type) – a pattern Purview recognises, such as a credit card number: usually a regular expression (regex) plus supporting keywords.
• Confidence level – how sure Purview is that a SIT match is real: Low (65), Medium (75) or High (85). More supporting evidence means higher confidence.
• Proximity – how close, in characters, a supporting keyword must be to the pattern to count as evidence.
• Sensitivity label – a tag such as Highly Confidential written into a file or email, which can also encrypt it.
• EDM (exact data match) – matching on the actual values in your own data, such as real customer account numbers, rather than on a pattern.
• Document fingerprint – a SIT built from a blank form or template, which matches any document written on it.
• Trainable classifier – a machine learning model that recognises a type of document, such as source code or a patent.
• Inline DLP – DLP applied to web traffic as it leaves, either inside Edge for Business or at the network through Global Secure Access (GSA), Microsoft’s cloud network security service.
• MCP server – a service an AI agent connects to for extra tools or data.

Why the earlier controls worked

It is worth looking back at why the earlier posts produced clean blocks, because the answer is classification every time.

The pattern is clear. Destination controls are binary: a server is allowed or it is not. Once a destination is approved, whether that is a sanctioned MCP server, Copilot or an external partner, the only thing that can stop the wrong content reaching it is a control that knows what the content is.

Why intellectual property is the hard case

Most DLP deployments start with personal and financial data because it is easy. A credit card number has a checksum. A PPSN has a fixed format. Microsoft ships hundreds of SITs for these, and a policy can be live in an afternoon.

Intellectual property has none of that. There is no built-in SIT for Contoso’s product roadmap, a formulation, a tender response or the code behind Contoso’s custom-developed pricing application. IP is defined by what a document is and who it belongs to, not by a pattern inside it. That makes it the case where classification matters most, and the one most organisations never get to.

Contoso’s crown jewels

Before choosing a classification method, list what actually needs protecting. For Contoso, whose flagship R&D programme – codename Project Halcyon – is the running example in this post:

No single method covers the list. That is the point of this post: IP protection is built from several classification methods layered together, then enforced by several types of DLP.

Key risks of losing Contoso’s intellectual property

The last row deserves attention. Under the EU Trade Secrets Directive, transposed in Ireland by the European Union (Protection of Trade Secrets) Regulations 2018, information is protected only where its holder took reasonable steps to keep it secret. Classification and DLP are not legal advice, but they are evidence of exactly those steps. Discuss the specifics with your legal team.

Methods of classification

Microsoft Purview classifies content in three ways: manually, by automated pattern matching, and with trainable classifiers. In practice those break down into the methods below.

Rule of thumb: if the IP carries an identifier, use a custom SIT. If it lives in a table, use EDM. If it is written on a standard template, use a fingerprint. If it is none of those, use a trainable classifier. And label anything only a person can judge.

One place to manage all of this. MC1486289 introduces a unified Classification Management experience in the Purview portal. It brings sensitive information types, Exact Data Match, trainable classifiers and document fingerprinting into one view, with search, filters and guidance in the creation flow on which method suits your scenario – the same decision the table above walks through. Public preview began in October 2026, with general availability scheduled from mid to late November 2026. Portal paths in this post may change as it rolls out.

Sensitivity labels: manual, default and automatic

A sensitivity label is the only classification that travels with the file. Every other method detects content each time it is evaluated; a label is written into the file’s metadata, stays with it wherever it goes, and can apply encryption that keeps working outside Contoso entirely.

• Manual. The author chooses. Best where only a person can judge sensitivity, such as a board paper or an acquisition target.
• Default. A label applied by policy or by a SharePoint document library. Everything saved to the Contoso R&D library is Highly Confidential – Contoso IP unless someone changes it.
• Automatic. Client-side auto-labelling recommends or applies a label in the Office apps as a user works. Service-side auto-labelling applies labels to content already at rest in SharePoint, OneDrive and Exchange. Both use the SITs, fingerprints and classifiers described below as conditions.

Labels matter most once content is encrypted. Trainable classifiers only work on items that are not encrypted, so once a label encrypts a file, content-based detection can no longer read it. From that point on, the label is the only thing downstream controls can recognise, which is why label-based DLP conditions are not optional.

Sensitive information types

A SIT is a pattern, usually a regular expression, supported by keywords, checksums and a proximity window, with confidence levels for how much evidence was found. Microsoft ships several hundred. The credentials post used the bundled All Credential Types SIT, and it belongs in any IP policy too: source code and configuration files are where secrets hide.

For Contoso’s own identifiers you write a custom SIT. The project reference SIT used in the inline DLP post is a good model:

\bCONTOSO-[A-Z]{3}-\d{6}-[A-Z]\b

• High confidence (85) – the pattern plus a keyword such as “project reference” or “confidential project” within 300 characters.
• Medium confidence (75) – the pattern on its own.

The fixed CONTOSO- prefix means it cannot collide with any built-in type, and the next two sections explain why that matters. The New-ContosoSIT.ps1 script in the inline DLP repository builds and imports the rule package in one run, and takes -Prefix and -DisplayName parameters so it can be reused for any client.

A regex is not a SIT

regex101.com is the best place to build the pattern. Paste a candidate regex and a block of sample text and it highlights every match as you type, explains each token in plain English, and lets you keep a set of test strings that should and should not match. For Contoso, that is where you prove \bCONTOSO-[A-Z]{3}-\d{6}-[A-Z]\b matches CONTOSO-FIN-204815-K and rejects a five-digit number, a missing prefix or a reference glued to another word – before it goes anywhere near Purview.

What regex101 cannot tell you is everything else the pattern will match across Exchange, SharePoint, OneDrive and Teams. Purview’s regex engine is not one of regex101’s flavours either, so a pattern that works there still has to be proved in Purview. regex101 proves the pattern; it does not prove the SIT.

A loose pattern such as \d{6} or [A-Z]{3}-\d{6} will happily match phone numbers, dates, order numbers, postcodes and invoice references, and it will overlap with a large share of Microsoft’s built-in SITs, most of which are numeric identifiers. Deploy it in a blocking DLP rule and the service desk will know about it within the hour.

To see how many built-in SITs your tenant has for a new pattern to collide with, run:

Get-DlpSensitiveInformationType | Where-Object Publisher -eq 'Microsoft Corporation' | Measure-Object

What turns a regex into a usable SIT is the evidence around it:

• A distinctive primary element. The fixed CONTOSO- prefix rules out almost every accidental match before anything else is checked.
• Supporting keywords within a proximity window. “Project reference”, “codename” or “confidential project” within 300 characters is what lifts a match to High confidence. A string that merely looks like a reference stays at Medium.
• Confidence levels in the policy. Block on High; use Medium for audit or a policy tip while you tune.
• Testing against real content. The Test option on the SIT, fed with samples that should and should not match, is where false positives show up. regex101 proves the pattern; the Test option proves the SIT.

Inside the Contoso SIT: how proximity decides

A custom SIT is defined in an XML rule package and imported into Purview. This is the core of the Contoso Project Reference SIT used in the inline DLP post. Three parts of it do the work:

<Entity id="b6ebde7d-..." patternsProximity="300" recommendedConfidence="85">
  <!-- High confidence: pattern + supporting keyword within 300 characters -->
  <Pattern confidenceLevel="85">
    <IdMatch idRef="Regex_contoso_project_ref"/>
    <Match idRef="Keyword_contoso_project_ref"/>
  </Pattern>
  <!-- Medium confidence: pattern alone -->
  <Pattern confidenceLevel="75">
    <IdMatch idRef="Regex_contoso_project_ref"/>
  </Pattern>
</Entity>

<Regex id="Regex_contoso_project_ref">\bCONTOSO-[A-Z]{3}-\d{6}-[A-Z]\b</Regex>

<Keyword id="Keyword_contoso_project_ref">
  <Group matchStyle="word">
    <Term>project reference</Term>
    <Term>project ref</Term>
    <Term>project code</Term>
    <Term>codename</Term>
    <Term>confidential project</Term>
    <Term>Contoso project</Term>
  </Group>
</Keyword>

• The regex is the primary element. Nothing is evaluated unless the text contains CONTOSO-, three letters, six digits and a check letter, bounded by word breaks. Purview matches it without regard to case.
• The keywords are supporting evidence. On their own they match nothing. They only matter when they appear near a project reference, and matchStyle="word" means they must be whole words: “codename” counts, “codenames” does not.
• The proximity window is 300 characters. patternsProximity="300" sets it: A keyword counts only if it falls within 300 characters of the reference. Inside the window, the match is High confidence (85). Outside it, or with no keyword at all, the match drops to Medium (75).

The DLP rule in the inline DLP post blocks at High confidence only. That one setting is what keeps false positives down: a reference has to look like a Contoso project code and be described as one before anything is blocked. A Medium match is still recorded, so it can drive an audit rule or a policy tip while you tune.

Here is how that plays out for prompts typed into an AI app, with the policy blocking at High confidence:

The last row is the important one. The keyword list contains everyday phrases that appear in thousands of emails and chats. On their own they do nothing; they only raise the confidence of a real project reference. That is the difference between a SIT and a keyword list, and it is why this SIT can block at High confidence without flooding the alert queue.

Prove it before you block. Paste these examples into a text file and run them through the Test option on the SIT. The results should match the table: six High, three Medium, five with no match. Purview lists a High match under Medium and Low as well, so seeing a value more than once is expected.

Custom SITs only find IP that carries an identifier. A design document that never mentions its project code passes straight through, which is why the next methods exist.

Exact data match

Exact data match (EDM) detects the actual values in your own data rather than a pattern that looks like them. You export a table, for example Contoso’s customer list with account numbers and contact names, hash it and upload the hashes. Purview then matches on those exact values, so a twelve-digit number only fires if it is a real Contoso customer account.

EDM gives the lowest false-positive rate of any method and suits structured IP: customer and supplier lists, a bill of materials, a product price book. The original data never leaves Contoso in clear text. The cost is operational: the source table has to be refreshed on a schedule as the data changes.

Document fingerprinting

Document fingerprinting is the most underused method for IP, and the best fit for any organisation that writes its IP on standard forms. You upload a blank template, such as Contoso’s patent disclosure form or design specification, and Purview converts its word pattern into a SIT. Any document written on that template then matches, whatever has been filled in.

Only a hash is stored; the original template cannot be reconstructed from it. Partial matching lets you set what percentage of the template text must be present for low, medium and high confidence, or select Exact to match only identical text.

Create it in the Purview portal under Information Protection > Classifiers > Sensitive info types > Create Fingerprint based SIT, or in Security & Compliance PowerShell:

$template = [System.IO.File]::ReadAllBytes('C:\Demo\Contoso-Design-Specification.docx')

New-DlpSensitiveInformationType -Name 'Contoso Design Specification' `
    -FileData $template `
    -ThresholdConfig @{ low = 40; medium = 60; high = 80 } `
    -IsExact $false `
    -Description 'Documents written on the Contoso design specification template'

Limits worth knowing before you promise it to anyone:

• The template needs at least 256 characters of extracted text, and embedded documents in it are ignored.
• It does not detect password-protected files, image-only files, files larger than 4 MB, or documents missing some of the template text.
• Fingerprints share a 300 KB rule pack, which allows roughly 100 per tenant.
• On devices, Advanced classification scanning and protection must be turned on in Endpoint DLP settings.

Trainable classifiers

Trainable classifiers identify an item by what it is rather than what it contains. For IP that is the only method that works on free-form documents with no identifiers and no template.

Pretrained classifiers are ready to use. Several map directly onto IP, including Source Code, Intellectual Property, Patents, Mergers and Acquisitions, and business and marketing plans. Check the current list in your tenant under Information Protection > Classifiers > Trainable classifiers, as it grows.

Custom trainable classifiers are trained on Contoso’s own documents. You provide a set of samples that definitely are the category, such as past tender responses, and a set that definitely are not. Purview trains on them, you review its predictions, and publish when the accuracy is acceptable.

• Classifiers only work on items that are not encrypted.
• Custom classifiers support English only.
• Published custom classifiers cannot be retrained. To improve one, remove it and start again with larger sample sets.
• The Source Code classifier fires when the bulk of the text is code, not on snippets pasted into a document or chat.
• If you create a new SharePoint site for seed data, allow at least an hour for it to be indexed before training.

Precision versus coverage: EDM and exact fingerprints rarely misfire but only catch what they were built from. Classifiers catch far more but will produce false positives. Use the precise methods to block, and the broad ones to label, audit and warn while you tune.

The types of DLP

Classification decides what is sensitive. DLP decides what happens when that content moves. Purview DLP is not one control but a family, split into two policy scopes in the portal: Enterprise applications & devices and Inline web traffic. Each location sees a different part of the journey and offers different actions.

There are a lot of locations, and the table below lists them all for completeness. For the purposes of this post, the next sections focus on the route keeping most security teams awake: Contoso’s IP finding its way into generative AI.

Protecting generative AI: where each type of DLP helps

AI reaches Contoso’s IP through several routes: a user pastes it into a prompt, uploads a file, asks Copilot a question that grounds on it, or lets an agent read it. No single DLP location covers all of them. Together they do:

Defender for Cloud Apps adds visibility of how Copilot is used and alerts on risky interactions, and DSPM for AI shows which AI apps are in use and what sensitive data reaches them. Neither blocks on its own; both tell you where to point the controls above.

Where Endpoint DLP protects

Endpoint DLP runs on Windows and macOS devices onboarded to Purview, and it is the control closest to the user. It acts on the actions people take with a file, wherever the file came from:

Each activity can be set to audit, block with override or block. Two settings matter for IP: Advanced classification scanning and protection must be on for fingerprint SITs to work on devices, and sensitive service domain groups let you treat AI websites differently from the rest of the internet.

Not every location understands every classifier

This is where classification and DLP design meet, and where most policies quietly fail. Locations support different conditions, and when you combine locations in one policy you keep only the conditions they all share.

• Copilot acts on sensitivity labels for grounding content. Its location is only available in the Custom template and cannot be combined with any other location in the same policy. No label, no protection.
• Fabric and Power BI support sensitivity labels and only a subset of SITs.
• Inline web traffic classifies what it can parse. As the inline DLP post showed, a prompt sent in a binary format passes without a verdict, however good the classifier.
• Encrypted content cannot be read by classifiers anywhere, so the label condition has to carry it.

The practical rule: build separate policies per location, and make sure every critical IP category is recognisable by a label as well as by content. Labels are the one classification every DLP location understands.

Where Global Secure Access prompt injection protection fits

Global Secure Access has a second AI control that is easy to confuse with inline DLP: prompt injection protection, configured as a prompt policy under Global Secure Access > Secure > Prompt policies and linked to the same security profile and Conditional Access policy as the content policy. It sits on the same TLS-inspected traffic path, but it answers a different question. Inline DLP asks is Contoso data leaving? Prompt injection protection asks is this prompt an attack on the model?

The two controls are complementary, not alternatives. Prompt injection protection stops someone attacking the model through Contoso’s network; inline DLP stops Contoso’s IP reaching the model in the first place. Only the second depends on classification, which is why this post exists. Deploy both on the same security profile, and do not present prompt injection protection to a customer as a data protection control.

Test each app yourself. Claude is in the preconfigured list, yet in the inline DLP lab Claude sent typed prompts as binary Protocol Buffers rather than JSON. Check the request content type in the traffic logs before claiming coverage for any app, exactly as the inline DLP validation method describes.

Data at rest versus data in motion: eDiscovery and DLP

DLP stops sensitive content moving from now on. It does not tidy up what is already there. The credentials post made the same point: the connection string emailed eight months ago is still sitting in a mailbox. Finding IP that is already at rest is a separate job, and the tools behave differently by workload.

Two consequences matter for Contoso:

• Create custom SITs early. A Contoso Project Reference SIT published today will not find project codes in mail indexed last year until those items are reindexed. Every week of delay is a week of email that a search will miss.
• Search before you enforce. Run an eDiscovery search for the custom SIT, the fingerprint SITs and All Credential Types across all workloads first. It tells you how much IP is already exposed and gives the DLP policy a realistic baseline.

DLP is the opposite side of the same coin. It reads SITs, labels, fingerprints and classifiers in every location it covers – Exchange, SharePoint, OneDrive and Teams, plus devices, Copilot, inline web traffic, Defender for Cloud Apps instances, on-premises repositories and Fabric – and it is the only control that acts at the moment content leaves.

Putting it together for Contoso

Here is how everything above combines around one asset: Project Halcyon, Contoso’s flagship R&D programme.

Layer 1 – Classify

Layer 2 – Enforce

Layer 3 – Control the destinations

The Defender and Agent 365 controls from the series sit on top: unsanctioned MCP servers blocked by indicators, agents approved before use, runtime protection inspecting what agents read, and GSA prompt injection protection blocking attacks on browser AI apps. They decide which doors exist; the first two layers decide what is allowed through them.

Now replay the risks. The departing engineer’s USB copy is blocked by Endpoint DLP because the files carry the label or match the Source Code classifier. The roadmap pasted into ChatGPT is blocked inline. Copilot will not ground answers on Halcyon documents. A patent draft emailed to a partner is stopped at Exchange. Every one of those outcomes depends on Layer 1.

Handling the alerts: the Triage Agent in DLP

Layering classifiers has a cost: alerts. A Source Code classifier and a broad fingerprint will produce far more matches than a credential SIT, and a security team that cannot keep up with the queue will eventually stop reading it. The Triage Agent in DLP, a Security Copilot agent in the Purview portal, is Microsoft’s answer to that problem.

What it does

• Sorts the queue. Each alert is placed in Needs attention, Less urgent or Not categorized (alerts it could not triage).
• Weighs the risk. Its verdict is driven mainly by content risk – the SITs, trainable classifiers and default sensitivity labels that matched – plus exfiltration risk (was the data shared externally?), policy risk (the rule’s mode and actions) and label removal or downgrade.
• Explains itself. Every triaged alert carries a summary and the risk factors behind the verdict, in both the Purview and Defender portals.
• Learns from analysts. An analyst can move an alert between categories and add properties such as SITs, file paths or target domains. The feedback applies to that policy, or to all policies.
• Takes custom instructions (preview). Plain-language guidance raises or lowers priority.
• Nudges the user (preview). For SharePoint and OneDrive alerts in Needs attention, it can message the person who last changed the file in Teams, asking them to remove the sensitive content. Reminders go out once a day and bundle up to 10 files.

How it benefits Contoso

• Halcyon alerts first. A custom instruction such as “Prioritise alerts involving Contoso Project Reference, the design specification fingerprint or the Highly Confidential – Contoso IP label” puts IP at the top of the queue, above the noise from built-in PII types.
• Tuning without rewriting policies. When the Source Code classifier fires on a harmless script, analyst feedback teaches the agent to rank it lower, rather than someone weakening the rule.
• Oversharing fixed at the source. The Teams reminder asks the engineer who left a design file in an open site to clean it up, without a ticket.
• Evidence for the board. The Needs attention count is a cleaner measure of real IP risk than raw alert volume.

What to know before you switch it on

• It only triages alerts from policies scoped to Exchange, Teams, OneDrive, SharePoint and devices. Alerts from the Copilot and inline web traffic policies – the AI routes above – are not triaged.
• It ignores policies in simulation mode, so it adds nothing until a policy is turned on.
• It analyses files up to 2 MB, and for alerts with 10 or more files it looks at the top 10 only. Device alerts need evidence collection for file activities turned on.
• It looks back at most 30 days from the day it is enabled. Allow up to two hours for the first pass.
• It runs on Security Copilot and consumes SCUs (Security Compute Units) in proportion to alert volume, so provision capacity and watch usage. It also needs Purview pay-as-you-go billing alongside per-seat DLP licensing.
• Several capabilities are in preview. Confirm the current status in your tenant.

A practical sequence

1. Find what you have. Data explorer and Activity explorer show where existing SITs and labels already occur and how content moves, before any policy exists. DSPM shows the same through a risk lens, and an eDiscovery search for your custom SITs shows what is already sitting in mailboxes and sites.
2. Agree the crown jewels with the business. R&D, Legal and Product decide what counts as IP. Security cannot classify what nobody has defined.
3. Keep the label taxonomy short. Four or five labels people understand beat twelve they ignore.
4. Build classifiers per asset type, using the crown jewels table: custom SITs for identifiers, fingerprints for templates, EDM for structured lists, classifiers for the rest.
5. Test before you trust. Use the Test option on each SIT with samples that should and should not match, and check classifier predictions before publishing.
6. Auto-label in simulation first. Review what service-side auto-labelling would label before letting it apply encryption at scale.
7. Run DLP in simulation, then with policy tips, then block. Tips teach users what is sensitive; blocks without them generate tickets.
8. Switch on the Triage Agent once policies are live, with a custom instruction that puts Contoso IP first.
9. Review regularly. New projects need new codes, templates change, and classifiers drift as the business does.

Limits to know

• Classification is never complete. Some IP will always be unlabelled and undetectable. Destination controls remain the backstop.
• Encryption and detection pull in opposite directions. Encrypt too early and content classifiers go blind; rely on the label from that point.
• Machine learning makes mistakes. Start classifier-based rules in audit or warn mode.
• Licensing varies by method and location. Several capabilities in this post need E5, E5 Compliance or pay-as-you-go billing. Confirm against your own licence position before designing around them.
• Features move quickly. Copilot and inline web traffic locations have changed repeatedly in 2026. Verify current behaviour in your tenant.

Wrapping up

Every control in this series is only as good as its ability to recognise what it is protecting. Destination controls decide where data can go; classification decides what the data is; DLP joins the two at every point data moves. For credentials and personal data Microsoft has done most of the classification work for you. For intellectual property, you have to do it yourself, with labels, custom SITs, fingerprints, EDM and classifiers layered together. Do that first, and every other control you have deployed starts to mean something.

Related posts

• Stopping leaked credentials with Microsoft Purview DLP
• Entra Internet Access inline DLP: stopping sensitive data before it reaches AI apps
• Microsoft Defender AI agent runtime protection: the series guide

References

• Learn about data classification
• Learn about Microsoft Purview Data Loss Prevention
• Document fingerprinting
• Learn about trainable classifiers
• Specify DLP requirements across Microsoft 365 locations
• Get started with DLP policies for Fabric and Power BI
• Learn about sensitive information types
• Finding content in mailboxes in eDiscovery
• Find sensitive data stored on sites with eDiscovery
• Protect enterprise generative AI apps with prompt injection protection
• Troubleshoot prompt injection protection
• MC1234661 – DLP blocking Copilot processing of labelled files in all storage locations
• MC1486289 – Unified Classification Management experience
• Get started with the Microsoft Purview Triage Agent in Data Loss Prevention
• Data Loss Prevention policy reference
• Block sensitive data going to AI apps – Prevent data leak to shadow AI

Seán O’Farrell | cloud-secure.ai