Data Loss Prevention in Microsoft 365: Policies That Actually Work

M365 FM - Data Loss Prevention in Microsoft 365 - Policies That Actually Work

00:00:00 Speaker: Monday morning, a new DLP policy goes live. It blocks every email with a number in it nine digits. Sixteen digits. Doesn't matter. By Friday, half the finance team is sending files from their personal gmail. Someone's photographing a spreadsheet with their phone. And the policy? It's still running, still blocking, still reporting a huge number of protected events. That's not a security win. That's a policy. People have already walked around and it's failing for one reason. Not the tools, the model behind it. Policies built to block lose to policies built to guide. If you want the episodes that keep your policies from becoming shelfware, subscribe to the M365 FM podcast because this topic doesn't end today. Here's the path. The old model, the new model. Then we build, test, tune, and measure. But before any design, one assumption has to go. Sponsor segment stellar Migrator for exchange. Quick word from today's sponsor stellar Migrator for exchange and I'll keep it educational. Here's why it belongs in a DLP conversation. Every migration changes where your data lives and where your data lives. Decides where DLP has to apply. Think about a mailbox moving from an on premises server into Exchange online. On day one, your policy scope shifts Content that's set behind your own firewall now sits in a cloud service. Rules written for the old location don't follow it automatically. So a mailbox that was covered yesterday can be a blind spot today. That's worth planning for before the cutover, not after map which mailboxes move when they move and which policies need to cover them the moment they land. Stellar migrator for exchange is one tool built for that kind of move. If you're planning a migration, it's worth a look. Now back to why most DLP programs store the old model block first. Ask later. In most organizations, DLP starts as a compliance checkbox. Nobody wakes up excited about it. It starts with an audit. An auditor reviews the environment and writes a. Finding no controls in place to prevent exfiltration of sensitive data. Short sentence. Big consequence because now somebody owns a deadline, so the work gets rushed. Someone opens the purview, portal, finds a template, picks one that sounds close enough, and clicks through the wizard credit card numbers, social security numbers, maybe a health identifier or two. The goal isn't good design. The goal is to close the finding, and underneath that rush sits an assumption, one that almost nobody says out loud. If you can name the data, you can stop it from leaving. That's the model. Name it, detect it, block it. It sounds clean. It sounds logical. It even sounds responsible. And honestly, it fits how compliance teams are trained to think. Data is a thing. Things can be fenced, fences stop things, but data doesn't behave like that. A credit card number in an email to a payment processor is business. The same number in an email to a personal address is a problem. The pattern is identical, the risk is completely different, and a model that only sees the pattern can't tell the two apart. So what does the rushed policy do? It treats them the same. And because nobody wants to be the person who allowed a leak, the action gets set to block, not ordered, not warn block. Often in week one, often ten and wide, often without a single day of testing because testing feels like delay and the deadline doesn't care. Now picture how that plays out. The policy goes live for a few days. Nothing happens. The compliance team feels good. A dashboard shows blocked events and blocked events look like proof of work. Then comes the moment this breaks. It's a Thursday. A sales manager is trying to send a signed contract to a customer before end of quarter. The contract includes a bank account number because the customer asked for payment instructions. The policy sees the patent. The policy blocks the message. No explanation, no next step. Just a bounce. She tries again. Same result. She tries a different attachment format. Same result. The clock is running. The deal is real and the control that was supposed to protect the company is now the thing standing between her and revenue. So she calls it. It doesn't know why it was blocked. It calls compliance. Compliance says the policy is working as designed, and that's the part that matters. It was working as designed. That's the flaw. The design assumed every match was a threat. It had no way to ask who she was, who the recipient was, or whether this was a normal part of her job. It couldn't ask because the model never included questions. It only included rules. This is the first false positive on a deadline, and it's the point where the whole program starts to lose, not because one email got blocked because of what happens next. Someone senior hears about it, a manager escalates and the fastest fix is rarely a careful one. It's an exception, a broad one, then another, or the policy gets quietly switched to audit mode, where it stays for two years doing nothing while the checkbox stays checked. Either way, the policy has lost. It just hasn't been told yet. But the real damage doesn't show up in the policy settings. It shows up in what people do next. And here's what that failure looks like from the users side. What users actually experience start with the message itself. A user hits send, the email comes back. Maybe there's a bounce in the inbox with a code that reads like a server error. Maybe there's a line about company policy. Nothing says which part of the message tripped it. Nothing says what to change, and nothing says who to ask. So the user guesses was it the attachment, the number in the second paragraph? The recipient. They remove one thing, try again, fail again, and start treating the system like a locked door with no handle. That's the first cost. The control gave an answer, but it didn't give a reason. And people don't follow rules they can't understand. They root around them. Now watch the roots. The quickest one is personal email. It takes 10s. Open a browser tab, paste the text, attach the file, send. No policy sees it because your policy lives in your tenant and gmail doesn't live there. Next is the phone. Someone opens the spreadsheet, holds up their device, and takes a photo of the screen or a screenshot, goes into a chat app. No file leaves the building, just the information inside it. Then there's the USB drive. Old, boring and still everywhere. Copy the file, walk out, plug it in somewhere else. And here's what matters about all four. None of them are malicious. These are people trying to finish a task that your control interrupted. They're not stealing. They're working. But the data still leaves. And this time, nobody's watching. That's the part the dashboard can't show you. The blocked events count goes up and it looks like protection. But each block that ends in a workaround moves the data from a channel you can see to a channel you can't. You didn't stop the loss. You relocated it. This is how shadow. It becomes the real data loss channel. Not because users love breaking rules, but because the sanctioned path got slower than the unsanctioned one. Every unmanaged app, every personal account, every messaging tool on a phone, each one exists because someone needed to get something done and the approved route said no without saying why. So the risk didn't fall. It just stopped being measurable and trust that moves in the other direction and it moves fast. One bad block costs a user a few minutes. Three bad blocks change how they think about the whole program. They stop reading the warnings. They stop calling it tea. They share the workaround with their team because that's what helpful coworkers do. Within weeks, the workaround is the culture, and the policy is just something that happens to other people. Here's the asymmetry. Trust erodes faster than risk falls. A policy can take months to reduce real exposure. It takes about a week to lose the people it depends on. Because DLP isn't a wall, it only works when users cooperate with it even a little. They're the ones who see the tip, pick the right recipient and report the odd case. Lose that and you've got a detection engine with no one on the other side of it. So the question changes. It's no longer how tightly you can block. It's what makes people tolerate a control at all. The new model context. Not content alone. Here's the shift. Data alone doesn't mean risk data plus context does. A nine digit number in a file tells you almost nothing. It could be a Social Security number. It could be an order ID or a phone extension in the sloppy spreadsheet. Even when the pattern is right, it only answers one question what is this? But risk lives in a different question. What is happening to it? That's the gap. The old model never closed. It's dead at the content and ignored everything around it. The new model starts from the opposite direction. Content is one input context is the rest of the picture. So what counts as context? Five things mostly who is sending it a payroll specialist handling employee records is doing her job. A developer with no reason to touch payroll data is a different story. Where it sits, a file in a locked HR site is one thing. The same file in a team site with two hundred members is another. How much of it there is one record in a message is routine. Five hundred records in a single export is a pattern worth a look to whom it's going. A partner under contract, a customer on the invoice or an address. Nobody at your company has ever written to before and through which channel email, a teams chat, a cloud upload, a USB drive, a print job. The same file carries different weight depending on the door it walks through. Notice what that list does. It lets the policy ask the questions the sales managers blocked email never got asked. Is she a normal sender for this data? Is the recipient a known customer? Is this one contract or a bulk dump? The answers decide the response, not the pattern alone. And once a policy can ask questions, it can behave differently for different answers. That leads to the second change order of operations. The old model enforced first and explained later, if ever. The new model flips it, educate first and force later because most of the people who trigger a policy aren't attackers. They're people who didn't know or didn't think or knew the rule existed, but forgot it at four in the afternoon. A quiet note at the right moment fixes that. This message contains bank account numbers. Is the recipient approved to receive them? That takes five seconds to read. It costs nothing and it turns a would be incident into a decision the user makes on purpose. Enforcement still has a place, but it comes after you've learned what normal looks like and after you've given people a fair chance to do the right thing. Block belongs at the end of that path, reserved for the cases where the evidence is strong and the stakes are real, which means DLP stops being a filter and becomes something else. A filter is static. It looks at an item, compares it to a rule, and passes or stops it. It has no memory, no judgment, and no relationship with the people it affects. A behavior system works differently. It watches patterns over time. It nudges people toward better choices. It collects the reasons they give. When they push back, it tells you where your own rules are wrong, and it gets quieter and sharper as it learns instead of louder and cruder. That's the real definition of a policy people tolerate, not one that blocks less, one that makes sense often enough that people trust it when it does say no. So the design question changes. You're no longer asking how to fence the data. You're asking how to shape what people do with it, using what you know about the situation. But there's a prerequisite. A policy can't weigh context around data. It can't recognize in the first place. Before any rule, any tip, any test, you have to know what you're protecting, where purview DLP actually lives. Start with a simple question where does a DLP policy actually run? Not in one place. And that's the first thing people get wrong. Purview. DLP reaches across a long list of locations exchange email, SharePoint sites, OneDrive accounts, teams, chat and channel messages, windows and Mac OS devices through endpoint DLP, Microsoft three hundred sixty five copilot, PowerBI workspaces. And beyond those, there's on premises file shares through the Scanner, plus cloud apps outside Microsoft through defender. For cloud apps, each location is a different door, same data, different exits. So a policy only protects the doors you tell it to watch. Now look at how a policy is built. It has four parts and they always come in the same order. Locations where the policy applies. Conditions what the policy looks for. That could be a sensitive information type, a label or a set of context checks like recipient domain or number of matches. Actions. What happens when the conditions are met? Audit it. Show a tip. Allow an override. Block it. Send an alert and exceptions. The case is where the rule steps aside. That's the whole skeleton. Every policy you ever write is a variation on those four parts, and once you see it, bad policies get easy to spot. They have a location list that's too wide, a condition that's too loose, and an action that's too harsh. All three at once, usually. But here's a change that trips up a lot of long time admins. The old way was per workload. You built mail flow rules. In exchange, you set up a separate DLP policy for SharePoint. Teams had its own corner. Each one had its own wizard, its own wording, and its own quirks. So the same business rule, say protect bank account numbers had to be built three or four times and then kept in sync by hand. That's where drift starts. One copy gets tuned. the others don't. Unified DLP in the purview portal fixes much of that. You create one policy. Pick the locations it covers and define the rule. Once the same condition and the same actions apply across exchange, SharePoint, OneDrive, and teams endpoint gets its own set of options inside the same policy. One place to build, one place to review. One place to report from. It's not perfect. Some actions only make sense in certain locations. A policy tip means something in outlook and nothing in a power BI data set. Some older exchange transport rules still exist in tenants and keep running next to the new policies. So part of the job is knowing what's already there before you add anything. Then comes the part nobody wants to talk about. Licensing. What you can build depends on what you've bought. Basic DLP for exchange, SharePoint and OneDrive comes with the lower tiers teams chat protection endpoint, DLP, and advanced options like adaptive scopes and more. Detailed context conditions sit higher up, mostly in the Microsoft three hundred sixty five E5 and compliance add on tiers. Features like Exact data match and trainable classifiers follow similar lines. So before you design anything fancy, check your license. A policy design that needs endpoint DLP is just a diagram. If half your users don't have the license for it and licensing shapes, who gets covered too? If only some users are licensed, only those users get the protection. That's a quiet gap, one worth finding on purpose, not by accident. So now you've got the map, locations, conditions, actions, exceptions, and a budget. Everything in that map starts with one building block. The condition and the first condition most policies lean on is the sensitive information type. Sensitive information types. The foundation. A sensitive information type, is a detector. That's all it is. It reads content and answers one question. Does this text look like something? I was built to find? Microsoft ships a large library of them, over three hundred credit card numbers, US Social Security numbers. Ibans for bank accounts across Europe, passport numbers by country, driver's license numbers, tax IDs, and for health data, things like the US National Provider identifier, the UK NHS number and medical terms tied to diagnoses and drugs. Nobody has to build these. You pick one, drop it into a rule and it works. That's why most first policies start here. But the part worth understanding is how a type decides it found something. Because it's not just a pattern. There are five pieces at work. First, the pattern. The shape of the data. Sixteen digits grouped in fours, starting with certain prefixes. That's the pattern for a card number. Second keywords words that sit near the pattern and make it more believable. Visa expiry CVV card number. A sixteen digit string next to those words is far more likely to be real. Third, a checksum. Many identifiers carry a built in math check card numbers. Use the Loon algorithm. The type runs the numbers and throws out anything that fails. So a random sixteen digit order ID gets dropped before it ever becomes a match. Fourth proximity how close the supporting evidence sits to the pattern. The keyword has to be within a set number of characters. A word in the footer doesn't count for a number in the first paragraph and fifth, the confidence level. This one decides almost everything. Each type has several patterns inside it, and each pattern carries a confidence score low, medium, or high. Roughly. They map to sixty five, seventy five, and eighty five. Here's how it plays out. A sixteen digit number that passes the checksum might land at low confidence at a keyword nearby and it moves up. Add more evidence and it moves higher. So confidence isn't a guess about the data. It's a measure of how much proof the type found. And that's the lever that sets your false positive rate. Think about what you're really choosing when you pick a confidence level in a rule, set it low and the rule fires on anything that has the right shape. Invoice numbers, tracking codes, a phone list with extra digits, your alerts fill up, your users get interrupted, and the policy starts to look like the one from Monday morning. Set it high and the rule only fires when the evidence is strong. Fewer matches. Cleaner signal. But you'll also miss the sloppy cases like a card number pasted with no label anywhere near it. There's no free setting. It's a trade, and the right answer depends on the action. For audit only low confidence is fine because you want to see everything, and nobody's being blocked. For a policy that stops a message you want high. Wrong blocks cost trust missed audit events cost nothing but a longer log. Most bad policies skip this choice entirely. They take the default and move on, and the default is often broader than the situation calls for. Now the second lever instance count. A rule can fire on one match or it can wait for ten. That sounds like a small setting. It isn't. One credit card number in an email is usually a customer asking about a payment routine. Ten credit card numbers in one file is a different animal. That's a list. That's an export. That's something a person built on purpose or pulled from a system they shouldn't have access to. So a common pattern is two rules on the same type one match medium confidence gets a tip ten matches high confidence gets a block. Same detector, different thresholds, completely different user experience count is context sneaking into the content check. It's the cheapest way to separate everyday work from bulk movement together. Confidence and count. Turn a blunt detector into something you can tune, but there's a limit to what the library can do. It covers data that looks the same in every company card numbers, passports, bank accounts, built ins cover the generic. Your business isn't generic custom sensitive information types. Think about what your company has that no vendor ever heard of. Employee IDs, project codes, contract numbers, customer account references, internal ticket formats. Nobody at Microsoft built a detector for those because only you use them, but they're often the exact data you care about most. So you build your own. And the main tool is a regular expression. A regex is a pattern written in a compact code. It describes the shape of a string, not the content. Say your contact numbers look like this. The letter C, n a dash a four digit year, a dash, then six digits. One line of regex captures that every string that fits gets flagged. Every string that doesn't gets ignored. Project codes work the same way. Maybe they start with p, R, and end in five digits. Employee IDs might be an E followed by seven numbers. If the format is consistent, the pattern can find it, and the consistency matters because a regex is only as good as the structure behind it. But a pattern alone has the same problem we saw earlier. Shape is not meaning. Take that employee id and e and seven digits. Now think about how many other things look like that. Part numbers, shipping references, a product SKU from a supplier. The pattern will find all of them, and it can't tell which is which. That's where supporting evidence comes in. Same idea as the built in types, but you control it. You add keywords, words that tend to sit near a real match for the contract number. That might be agreement contract on signed or counterparty for the employee ID may be employee, staff number or HR record. When the patent shows up near those words, confidence goes up. When it shows up alone, confidence stays low. You can also set up keyword dictionaries. A dictionary is just a larger list of terms kept in one place and reused. Product code names. Internal system names. A list of customers under NDA. Instead of typing fifty words into every rule, you load them once and point at them and you set the proximity. How many characters apart? The pattern and the evidence can be too tight and you miss real cases. Too wide and a keyword three paragraphs away starts counting. Now here's the step most teams skip testing before a custom type goes into any policy. Run it against real samples not made up examples you wrote to prove it works. Actual documents and emails from the business purview lets you upload sample files and see what the type catches and what it misses. Do that with a mix. Documents that should match, documents that should not, and a few that sit right on the border. Then read the results with a skeptical eye. Did it catch every real contract number? Did it flag anything that was only an order reference? If it grabbed something, it shouldn't find out why. Usually the answer is the pattern, the proximity, or a keyword that's too common. Fix it. Test again. This loop is cheap. Skipping it is expensive because a bad type deployed into a live policy produces noise. You'll spend weeks cleaning up. Two pitfalls show up over and over. The first is a pattern that's too loose. Someone writes a regex that matches any seven digits because it was quick and it works on the sample they had. Then it goes live and flags, phone numbers, zip codes with extensions, and half the spreadsheets in finance. A loose pattern with no supporting evidence is just a random number detector. The second is a dictionary that's too long. Someone dumps in two thousand terms, including common words like plan, summary, and review. Now every document matches something. A dictionary only helps when each term is specific. If a word shows up in normal writing all day, it doesn't belong in there. Both mistakes come from the same instinct. Catch everything. But a detector that catches everything has stopped telling you anything. Narrow beats, broad specific beats, clever and even a well-built pattern. Has a ceiling. Regex finds structure. It needs something repeatable to hold on to. Some content has none.

00:19:13 Speaker: The exact data match and document fingerprinting. Regex asks one question does this string look right? Exact data match asks a harder one. Is this string actually ours? That's the whole idea behind EDM. You hand purview the data itself a real table. Customer account numbers, patient IDs, employee records, whatever you need to protect. Each row is a real value from a real system. The detector doesn't guess. It checks when a message goes out with a nine digit number. Purview compares that number against your table. If it's in there, it's a match. If it's not, it's just a number. Think about what that does to false positives. The loose pattern problem from a minute ago mostly disappears because the pattern no longer has to carry the decision. The table does. A phone extension that looks like a patient ID gets ignored because no patient has that ID, and you can add context from the same row. A match can require the account number and the last name together. Now it isn't one value that fires the rule. It's a combination only a real record would have. So where does this beat regex? Anywhere. The structure is common, but the values are specific account numbers that look like a dozen other numbers. Medical record IDs. Customer references data where the shape is a weak clue and the list is the real evidence. But that power has a cost and it's mostly operational. Start with the schema. You define the columns of your table, which ones are searchable, and how purview should treat each one. Get that wrong and you're rebuilding it later. Then the upload. And this part is worth knowing because it answers the question every security team asks you. Don't send your raw data to Microsoft in plain text. You run a tool on your site that hashes each value with a salt, and only the hashed version gets uploaded. The sensitive source stays with you. What the cloud holds is a set of fingerprints it can compare against. Then comes the refresh. Customers join employees leave accounts close. A table that was right in March is stale by June. So somebody has to own the export, the hash and the upload on a schedule. That's a real job. It needs a person, a process, and a source system that someone trusts. Plenty of EDM projects start strong and decay because the refresh was nobody's task. Now, the second tool document, fingerprinting EDM, is for values. Fingerprinting is for documents with a fixed layout picture, a standard form, a patient intake sheet, a tax form, a loan application. Every copy has the same wording, the same fields, the same structure. Only the filled in details change. You can't write a regex for that because there's no single string to find. The sensitive part is the whole document type. So you give purview a blank template. It builds a fingerprint from the wording and structure. After that, any document that matches that pattern gets caught, even when it's partly filled in, partly rewritten, or pasted into a different file. You can set how similar a document has to be before it counts, so a copy with edits still triggers the rule. That's useful for things like contract templates, internal forms, and standard disclosures. Content that has no number to detect but is clearly the thing you care about. Fingerprinting costs less to maintain than EDM since a template changes slowly, but it only fits content that looks like the template free form writing slips right past it. So here's how the three fit together. Regex for structure. You can describe EDM for values. You can list fingerprints for documents, you can template, and all three share one limit. They find data. They don't tell you what that data means to the business. Finding data is half the work, knowing its label is the other half. Trainable classifiers and sensitivity labels. Some content has no pattern at all. Think about a contract. No fixed number. No standard layout. No keyword that always shows up. A lawyer in London writes one way. A vendor in Texas writes another, and both are still contracts. You can't describe that with a regex and you can't list it in a table. But a person can look at it and know in two seconds. That's what a trainable classifier does. Instead of matching a pattern, it learns what a kind of document looks like. Language structure the way the sentences sit together. Contracts are. The classic case source code is another. Since code has its own rhythm of syntax and keywords that. No single string captures resumes work too. So do financial statements, legal filings, and medical referrals. Microsoft ships a set of these already. Some are pre-built for common categories, and you can use them right away. But the real value shows up when you build your own. For the document types, only your business has. So how does that work? There's a cycle and it has four steps. First, seed data. You give the system a set of examples, real documents of the type you wanted to find. Microsoft asks for a minimum of fifty positive samples and more is better up to around five hundred. Quality matters more than volume here. If your seed set is a mix of contracts and random legal emails, the classifier learns the wrong lesson. Second, training purview reads the samples and builds a model. This takes a little time, usually hours, not minutes. Third test you feed it a fresh batch. It hasn't seen a mix of documents that should match and ones that shouldn't. Then you review what it predicted and mark each result, right or wrong. That feedback tightens the model, and this step is where most of the accuracy comes from. So don't rush it. Fourth, publish. Once the results look steady, you release the classifier. Now it can be used as a condition in a policy just like any sensitive information type. And one thing to plan for a trained model isn't a finished product. If your document formats change or the business starts producing a new kind of contract, the classifier can drift. Somebody has to check it from time to time. But here's where it gets interesting. Detection is only one way to tell a policy. What matters. The other way is to let people tell it. That's what sensitivity labels do. A sensitivity label is a tag on a file or email. Public. Internal. Confidential. Highly confidential. Your company picks the names and the rules and the label travels with the content. It sits in the file's metadata, so it follows the document from a laptop to SharePoint to an email attachment. Now, here's why that matters for DLP. A label can be a condition in a policy, not a pattern, not a count. Just does this item carry the highly confidential label? If yes, apply the rule. Think about what that replaces without labels. Protecting your financial planning documents might take twelve conditions. A pattern for account codes. Two dictionaries for project names. A classifier for forecasts. Keywords for board materials, each one with its own confidence level, its own threshold, and its own chance to produce noise with labels. It's one condition the document is labeled the rule fires. That's a big simplification. Fewer moving parts means fewer places to go wrong, and far easier tuning. When something misfires, you're not hunting through a dozen detectors to find the guilty one. Labels can also be applied automatically. Auto labeling policies use the same sensitive information types and classifiers we just covered, and stamp the label on matching content without anyone lifting a finger. So the detection work you did earlier isn't wasted. It feeds the label and the label feeds the policy, which turns the whole detection layer into a chain. Types and classifiers find the data labels. Name it. DLP rules act on the name. That's the foundation. The detection layer is set. And now the next problem comes into view. Not what the policy sees, but what the person on the other side of it sees. Policy tips. The quiet teacher. Timing is the whole point of a policy tip. A tip appears while the person is still writing before the send button, not after the bounce. Not in an email three hours later. Not in a report that lands on a manager's desk next week. The user is still holding the message in their hands. They can still change it. That moment is the only one where education actually works. Once the message is blocked, the user is annoyed. Once it's sent, it's too late. But in the half second before they click, they're open. A short note can turn a reflex into a decision. So what does a tip look like in outlook? It's a banner. It sits above the message right where the eyes already go. It shows up as soon as the content matches a rule while the user is still typing, or after they've added the recipient. No pop up, no separate window, just a line of text that says something worth reading. And that's the next problem. Most of them don't look at the default wording. Something like this item contains sensitive information that is protected by your organization's policy. Technically true. Completely useless. It doesn't say which information. It doesn't say what to do. It reads like a legal footer and people treat it like one. They scroll past it. By the third time, they don't even see it. A tip people actually read follows three rules short, specific, and it ends with the next step. Short means one or two sentences. If it takes more than five seconds to read, it's already lost. Nobody studies a banner while trying to answer a customer specific means. It names the thing, not sensitive information. Say this message includes bank account numbers. The user can check that in a heartbeat. They know exactly what the system saw, so they can judge whether it's right. And the next step means the tip tells them what to do. Remove the numbers. Confirm the recipient is on the approved list. Use the secure sharing option instead. Without that, a tip is just a warning, and a warning with no exit feels like an accusation. Compare two versions. First policy violation detected. Contact your administrator. Second, this email includes customer card numbers only. Send them to approved payment partners. Not sure? Use the secure portal. The second one takes the same five seconds and it tells the person everything. Tone matters too, right? Like a coworker, not like a regulator. Skip the word violation. Skip capital letters. The goal is a nudge, not a threat. People forgive a helpful note. They resent a scolding one. Now give them somewhere to go. A policy tip can link to a help page and you should always use that. Build one simple page. What the rule protects, why it exists and what the approved alternatives are. Keep it to one screen. A tip can only hold two sentences, so the page carries the rest of the explanation for anyone who wants it and add a reporting path. That's the part most teams forget. If the tip is wrong, the user needs a way to say so. A mailbox, a short form, a link that opens a prefilled message to the DLP team. Because every this is wrong report is free tuning data, and a user who can report a bad match is far less likely to quietly work around it. Where do tips actually show up? More places than people expect. Outlook on the desktop, on the web, and on mobile. In supported versions. OneDrive and SharePoint, where a small icon appears next to a flagged file and a longer note opens when you click it. And the office apps themselves, word, Excel, and PowerPoint can show a tip as a bar at the top of the document right inside the file the person is editing. Same idea. Different door. One caution support varies by app and by version, and some clients show less than others. So test the tip in the clients your people really use before you assume it's visible. But even a well written tip has a weakness. It only works if people believe it. A tip that nobody believes is just noise. User overrides and justification. So how do you earn belief? You start by deciding what happens when a user disagrees with the policy, and in purview, you get two basic choices. One is a hard block. The rule says no and that's the end of it. The other is an override. The rule says this looks risky and the user can proceed, but only after they pick a reason. Something like this is part of a business process. My manager approved it or the policy is wrong here. They can also type their own explanation. Most teams treat that second option as a weakness, a loophole. Why give people a way past the rule? But think about what the hard block assumed. It assumed the policy knew better than the person. And in the sales managers case, we already saw how that went. An override flips the relationship. The policy raises its hand and says, I might be wrong. So you tell me. That's a very different kind of control. It still interrupts. It still makes the person stop and think, but it trusts them enough to let the work continue when the work is legitimate. Now here's the part that changes how you see the whole feature. Justification isn't friction, it's data. Every time someone overrides, they hand you a small piece of information you couldn't get any other way. What they were doing in their own words at the exact moment the rule fired. A hard block gives you a count. An override gives you a reason, and a reason tells you whether the policy is catching real risk or just catching Tuesday. So read them, actually read them. Pull the override reasons for a policy after two weeks and sort them. You'll usually see clusters. Forty people picked part of a business process, and when you check, thirty of them are in finance sending remittance files to the same bank. That's not forty risks. That's one missing exception. And it's sitting in plain sight. Or you'll see a pile of free text answers that say the same thing in different words. Customer asked for it. Standard invoice. Vendor onboarding. Each phrase points at a workflow the policy never knew about. Now you can fix the rule instead of blaming the people. And sometimes the reasons are the opposite. Vague blank, just the word. Okay, that tells you something too. It means the prompt is so routine that people stop thinking about it, which is a different kind of broken and a warning that your tip text needs work. Then there's the number itself. The override rate is the share of matches where the user chose to go ahead, and it works like an early warning light. If it's near zero, you've got one of two situations. Either the policy is catching real problems and users are backing off, which is great, or the override option is so buried nobody finds it, which is not. The reasons will tell you which. If it's very high, say most matches end in an override. The policy is wrong, not the users. Something about the scope, the threshold or the confidence level is flagging normal work. People aren't being careless, they're being accurate and watch the direction. A rate that climbs week over week usually means the business changed and the policy didn't. A new partner, a new process, a team that moved into scope. The rate moves before anyone files a complaint, which makes it one of the cheapest signals you'll ever get. So the override isn't where discipline ends. It's where the policy starts listening. But all of this assumes the policy is live and people are feeling it. And that brings up the part most teams skip how to switch it on without hurting anyone. Test modes and simulation. Every DLP policy should start in a mode where nobody can feel it. That's simulation mode. You build the policy exactly as you plan to run it locations, conditions, actions, exceptions. Then you switch it on in a state where it watches but doesn't touch anything. No blocks, no tips, no bounced mail users carry on working, and the policy quietly records every item it would have caught. Think about what that gives you. For the first time, you're looking at real data from your own tenant. Instead of guessing how many matches does this rule produce on a normal Tuesday. Which locations make the most noise? Which teams trigger it the hardest? You get those answers before a single person has a bad afternoon and it fixes the thing. The old model got backwards. The rushed policy learned what normal looked like after it went live on the users time. Simulation learns first. Purview also gives you a middle step, and it's easy to overlook. Run the policy with policy tips turned on. But with enforcement still off, now the policy is visible. Users see the banner in outlook. They see the note on a flagged file. They read what the rule noticed and what it suggests, but nothing is stopped. The message still goes out, so why bother? Because this stage answers a different question. Simulation tells you what the policy matches. This stage tells you how people react to being told. Do they read the tip? Do they remove the data? Do they ignore it and send anyway? Do they email the help desk asking what it means? Each reaction is feedback on your wording, your thresholds, and your scope. A tip that confuses people shows up here in the form of tickets and questions, instead of in the form of a blocked contract on the last day of the quarter. It's also the cheapest time to find out the tip text is wrong. Rewriting a sentence costs nothing. Rebuilding trust costs weeks. Only after both of those stages do you turn enforcement on. And even then, you don't flip it everywhere at once. Staged enforcement means you widen the circle slowly. One pilot group first, a single department that has volunteered, or one that's low risk and has a friendly manager. Watch what happens for a couple of weeks. If the alerts look right and the complaints stay quiet. Add the next group, then the next. You can stage the actions to start with the tip and the override. Let that run later for the highest confidence matches only move to a block. The strictest action arrives last and it arrives narrow. Each step has a clear rollback. If something goes wrong in the pilot, you drop back to the previous mode, fix the rule and try again. Nobody outside the pilot ever saw the problem. That's what makes this safe, and it's why it feels so different from the week one block. Now. How long should all of this take? Here's where teams get impatient. They run simulation for three days, see a lot of matches, and call it done. But three days isn't a sample. It's a snapshot of one slice of the week. Business has rhythm. Finance does heavy work at month end sales, pushes contracts at quarter end. HR runs payroll on a schedule. Legal gets busy around filings. If your simulation window misses those peaks, your policy will meet them for the first time in production with enforcement on. So think in weeks two. At the very least, four is better. And if the data you're protecting follows a monthly or quarterly cycle, the window should cover at least one full cycle. That feels slow. It feels like delay, which is exactly what the audit deadline taught everyone to fear. But a few extra weeks in simulation costs almost nothing. A broken policy and production costs far more, and it's much harder to repair once people have learned to work around it. Patients here isn't cautioned for its own sake. It's the part that buys you a policy people can live with, and when the window closes, you'll have something you didn't have before. A pile of data, match counts, locations, users, trends, simulation produces. Numbers and numbers don't explain themselves. Reading simulation results open the results and resist the urge to look at the total. A big number feels like a finding forty thousand matches in two weeks. It sounds alarming and it tells you almost nothing because a total hides where the matches came from. So break it apart. Three cuts in this order. First, by rule, a policy with four rules rarely produces matches evenly. Usually one rule makes up most of the volume, and that's the one to read first. If the low confidence rule is generating ninety percent of the hits, you've found your noise before you've opened a single item. Second, by location exchange, SharePoint, OneDrive teams. Endpoints. Same rule, different door, and the numbers rarely match. A rule that's quiet in email. Might be loud in OneDrive because people sync old spreadsheets there that nobody has opened in years. That's not a user problem. That's a clean up problem. And it belongs in a different conversation. Third by user group. Finance HR sales, engineering volume that makes sense for payroll staff would be strange for a design team when one group is far louder than the rest, ask whether the policy is catching their job or catching a mistake. Now the part people enjoy the top ten noisiest users pull the list ten names, ten sets of numbers, and before anyone reaches for a conclusion, open each one. Look at what they were actually doing. What you'll usually find is dull. One person runs month end reports and sends the same file to the same auditor every time another handles customer onboarding. So card numbers pass through their mailbox all day. A third has a script that exports a table every night. None of that is misconduct. It's a job and the policy is seeing it for the first time. But sometimes one name stands out for the wrong reason. Bulk copies to a personal folder. Files sent to an address that appears nowhere else in the data activity at odd hours in odd places. Those are the cases worth a closer look, and you'll only spot them because you've stripped away the routine ones first. So this is the real work of reading results sorting real risk from normal business flow. Here's a practical test for each cluster of matches. Ask three questions. Is the sender expected to handle this data? Is the recipient known? Does the volume match the role? If all three answers are yes, you've found a business process and the policy should learn to leave it alone. If any answer is no, you've found something to investigate. Notice what that does. It turns a pile of matches into two piles. One pile needs an exception or a narrower rule. The other needs a person to look, and the first pile is almost always bigger. That's not a failure of the policy. It's the whole reason you ran simulation instead of switching on a block. Now comes the loop. Tuning is a cycle and the order of the steps matters. Start with thresholds. If a rule fires on one match and most of those are routine, raise the instance count. If low confidence hits dominate, move to medium or high. These are the cheapest changes, and they often cut volume by half without losing a single real case. Then scope. If the noise is concentrated in one department or one location, narrow the rule so it stops applying where the business flow is normal, or split it with a lighter rule for the loud group and a stricter one for everyone else. Then retest. Run simulation again with the changes in place and compare the numbers against the last run. Did volume drop? Did the real cases survive? If a case you wanted vanished, you tuned too far. So back up. One step, one change at a time. If you can manage it, change three settings at once and you won't know which one did the work. Repeat until the match is left over. Are mostly the ones you'd want a human to see and notice the direction. This loop always runs higher thresholds, fewer locations, smaller groups. Almost every adjustment makes the policy narrower. Tuning usually means narrowing. Here's how.

00:37:53 Speaker: Scoping policies by audience and risk. Tuning narrows the rule. Scope narrows the audience and. The first scoping decision is smaller than most people expect. Pick one department, one data type, one channel. Not all sensitive data everywhere for everyone. That's how you end up with a policy. Nobody can read. Say you start with finance, card numbers and outbound emails. Three choices, and each one removes a whole category of noise. When the results come in, you know where to look. If something is off, there's only one place it could be coming from. That's the real value of starting small. Cause and effect. Stay visible. Change five things across the whole tenant and every alert has five possible explanations. Once that first slice is steady, you widen it. Another department, another data type, another channel. Each edition gets its own simulation window, and each one inherits what you learned from the last. Now how do you define who's in scope? You've got two ways. The first is static groups. You pick a security group or a distribution list, and the policy applies to its members. It's simple and everyone understands it, but it depends on someone keeping the group right. People change roles, contractors arrive and leave. A group that was accurate in January has drifted by summer and nobody noticed because nothing broke loudly. The policy just quietly covers the wrong people. The second is adaptive scopes. Instead of a list, you write a query. Everyone in the finance department, everyone in a given country, everyone with a certain job title. The membership comes from directory attributes, so it updates itself. A new hire lands in finance and the policy already covers them. On day one, someone transfers out and the policy. Let's go. That sounds like an easy win. And mostly it is, but it has a catch. An adaptive scope is only as good as the attributes behind it. If department fields are blank or job titles are inconsistent, the query returns the wrong people. So before you trust one, check the data. It reads clean attributes make adaptive scopes work. Messy ones just hide the mess behind a nicer interface. Also note that adaptive scopes sit in the higher license tiers. So this is another place where the budget decides the design. Now think about who you're scoping for because different teams carry different risk and they handle sensitive data in different ways. HR lives with employee records, health information and salary details. Their data is personal and the damage from a leak is personal to finance handles, card numbers, bank details, and unreleased results. Legal works with privileged material and contracts where one wrong recipient can create real exposure. Engineering holds source code, designs and credentials. Each of those groups sends different data to different people through different channels, so the rules should differ to HR might need tight control on anything leaving the company. Finance needs card and account protection, but with a clear path for payments to approved partners. Legal needs labels respected, not pattern matches engineering needs endpoint and cloud upload controls since code rarely travels by email. Give all four the same rule and it will be wrong for at least three of them. Which brings us to the most common mistake one policy applied tenant wide. It feels efficient. One rule, one place to manage. Nothing missed. But that rule has to be loose enough to tolerate every team's normal work, which means it's too loose to protect anyone properly, or it's tight enough to protect. And it buries the people whose jobs involve that data. Either way, someone loses a tenant. Wide policy isn't a safety net, it's a compromise nobody asked for. So the answer is layers. A light baseline for everyone, then stricter rules for the groups and data that carry real risk scope settles who rule design settles how rule design tiered responses scope is set. Now the rule itself. And the biggest mistake here is writing one action for every match. One rule, one response. No matter what the evidence looks like, a single stray card number gets the same treatment as a spreadsheet full of them. That's like using the same alarm for a burnt toast and a house fire. It's the model that fails, not the detector. The fixes tears several rules inside the same policy, each with its own threshold and its own response. The detector stays the same. What changes is how much proof it needs before it acts and how hard it acts. Start at the bottom. Low volume, low confidence. One match, maybe two. The evidence is thin, a number with the right shape and no key word nearby. Here the action is ordered only. Log it. Raise no alert. Show nothing to the user that might feel like doing nothing. It isn't audit only rules. Build your baseline. They tell you what ordinary traffic looks like, and they catch the slow patterns that no single event would reveal fifty quiet matches from one account over a month tell a story, even if each one alone was harmless. The cost to the user is zero and the data you collect is real. Next year medium more evidence. Now medium confidence or a handful of matches or sensitive content heading to an address outside the company. This is where the policy tip and the override come in. The user sees the banner, it names the data, suggests a safer route, and lets them continue if they have a reason. We covered how both of those work. So the point here is where they sit in the middle. Enough risk to interrupt, not enough to refuse. This tier will carry most of your human facing traffic, so it's the one where tip wording and override reasons matter most. Then the top high volume, high confidence ten card numbers with matching keywords going to a personal address. A file with a highly confidential label headed for a domain you've never seen. The evidence is strong and so is the likely damage this tier blocks. But a block without an exit is where trust goes to die. So the block carries a reporting path, a clear message saying what was stopped and why. A link to report, a wrong call, a named contact who answers, and ideally a route for the legitimate case. Like a secure sharing option, the user can reach in one click. The goal isn't to make blocks painless, it's to make them rare, correct, and recoverable. If the block fires and the user can fix the problem or flag a mistake in under a minute, the policy still reads as help. If they hit a wall with no door, they start looking for a window. Put those three together and the policy reads like a ladder. Watch nudge stop. Each rung needs more evidence than the one below, and each rung asks more of the user only when the data justifies it. Now add a second dimension. Who's receiving the message? Internal and external recipients are different situations, and one rule shouldn't treat them the same. A customer record sent to a colleague in the same tenant is usually work. The same record sent to a stranger at a free email provider is a different matter entirely. So build separate rules for internal recipients. Keep the response light. Audit. Maybe a tip at high counts, the data is staying inside where your other controls still apply for external recipients. Tighten the whole ladder. Lower the count that triggers a tip. Move the block threshold down the same content one step further from your control earns one step more. Caution. You can go finer than that. External to a known partner. Domain can sit lower on the ladder than external to anyone at all. Recipient context is one of the cheapest ways to cut noise without losing coverage, because the same content means different things depending on where it lands. The result is a policy with shape quiet where the business is normal, loud only where the evidence says it should be. Tears help. Exceptions decide whether you survive. Exceptions that don't break the model. Every policy hits a wall in the first week. A real business process shows up that the rule can't tell apart from a risk. That wall is where exceptions come in. An exception is a. Carve out a condition that says if this is true, skip the rule and used well. It's what lets a strict policy live next to normal work. Start with the easy ones. Trusted domains, your bank, your payroll provider, your law firm, your auditor finance sends them card data, account numbers, and signed contracts every week and always has a rule that interrupts that flow isn't protecting anything, it's just in the way. So you add an exception for those recipient domains. And the rule steps aside, partner allow lists work the same way, only wider. A list of organizations you've signed an agreement with where sharing is expected and covered by a contract. You keep the list in one place. Point the rule at it and every approved partner is handled in one move, then approved apps. On the endpoint side, you'll name the tools. People are allowed to move sensitive files through the company's own document system, the sanctioned file transfer client. Anything on that list gets a pass and everything else still gets checked. Now, the shape of the exception matters because you can cut it in several directions by group finance staff are exempt from the card number rule when sending to approve payment partners. Not everyone. Just them. And just for that case by label, anything marked internal can go to a partner domain, but anything marked highly confidential still can't. The label does the sorting, so you don't have to list every file by recipient. A single named address, like a regulator's intake mailbox, gets an exception that nobody else shares, and the best exceptions combine two of these group plus recipient label plus domain. The more specific the carve out, the less it lets through an exception that says finance to this one bank. For this one data type is tight. An exception that says skip this rule for the whole company when the recipient ends in US. Com isn't an exception at all. It's a whole. So here's what actually goes wrong. Exceptions don't fail on the day you create them. They fail slowly. Someone adds one. During a rough week, a VP complained a deal was at risk and the fix took 30s. The ticket closes, the exception stays and nobody wrote down why it exists, who asked for it or when it should end. Six months later, there are forty of them. The partner on that allow list was dropped last spring. The domain belongs to a company that was acquired. The group that got a pass now includes three hundred people who joined after the original request. Each exception made sense. Once together, they form a second policy that nobody designed and nobody can read. That's exception rot, and it comes from two gaps. Nobody owns them and nobody reviews them. The fix is boring and it works. Every exception gets an owner, a named person, not a team mailbox. Every exception gets a written reason and every exception gets an expiry date. Expiry is the one that changes behavior. Set it for six or twelve months out. When the date arrives, the exception either gets renewed on purpose or it disappears. Renewal needs the owner to say yes. This still applies. Silence means it lapses. That flips the default instead of exceptions living forever. Unless someone removes them, they die unless someone defends them. Then once a quarter, sit down and read the whole list. Who owns it, why it exists, what it let through. Check the allow lists against current contracts. Check the groups against current stuff. Remove what's dead. An hour of review every three months. Keeps the policy honest. And look at the override reasons from earlier. They tell you which exceptions to add and which existing ones are no longer needed. Handle exceptions that way and the model holds. Neglect them and it erodes from the inside. But all of this has been about mail and files that move through the cloud. Mail is the easy channel. The hard one is the device endpoint DLP, where data actually leaves cloud rules. Watch what sits in Microsoft three hundred sixty five. But a file doesn't have to stay there. Someone opens a spreadsheet, plugs in a drive, and drags it across. Someone else uploads it to a personal storage site. In a browser tab, a third person prints it and walks out with the pages. None of that touches exchange. None of it touches SharePoint, and a policy that only lives in the cloud never sees any of it. That's the gap endpoint. DLP closes it puts the policy on the device itself. So the rule travels with the file even when the file leaves the building. So what does it actually cover? A short list of activities, and each one is a door copy to a USB drive. The classic one. A file goes from the laptop onto removable storage, and the policy can see the file, its label, and its content at the moment of the copy upload to a cloud service. A person opens a website in a browser and sends a file to it. Personal storage, a file transfer site, a consumer email service. The endpoint sees the upload and checks what's inside. Print. Yes, still, paper is a real channel, and the policy can watch what gets sent to a printer, including network and USB printers. Copy to the clipboard. This one surprises people. Someone selects a block of text from a label document and pastes it somewhere else. The endpoint can see that paste and act on it and copy it to a network share. A file moves from the device to a shared folder somewhere on the network, and the policy can decide whether that's fine. There's a wider set to like copying to a remote desktop session or using the share feature in windows, but those five are where most real leaks happen. Now, a device can't enforce a policy it doesn't know about, so first it has to be onboarded on windows. The supported versions include windows ten and windows eleven. You bring the device in through the purview portal, and you can do it with the usual management tools. Intune Group Policy Configuration Manager a local script for small batches. Pick the one your team already runs. Because onboarding is a deployment, and deployments go faster on familiar rails on Mac OS. The same idea applies with a few supported versions and a slightly different path. You'll use a management tool to push the onboarding configuration, and then grant the device a few permissions so the agent can see file activity. And then there's Microsoft Defender. This is the part worth understanding. Endpoint DLP rides on the same sensor that defender for endpoint uses. So if your devices are already onboarded to defender, a lot of the work is done. The device reports in, it shows up in the purview device list, and the DLP capability turns on from there. No second agent, no extra install one onboarding two users. If you don't run defender endpoint, DLP can still onboard on its own, but the shared path is usually cleaner, and it keeps your security and compliance teams looking at the same device inventory. Once devices are in, the next question is what the policy does with each activity. And here's the distinction that matters. There's a difference between monitoring and activity and blocking it. Monitoring means the endpoint records the event. Someone copied a labeled file to a USB drive. The log shows who, what, when and where nothing is stopped. It feeds your alerts and your reports and it costs the user nothing. Blocking means the endpoint stops the action. The copy fails, a message appears and you can soften that the same way we did with mail block with an override. So the user can proceed after giving a reason or warn only or block outright. You set this per activity and you should audit everything first. Then choose which doors deserve a stronger response based on what the logs show. Maybe USB copies of confidential files get an override prompt while clipboard activity stays. Audit only because the volume is huge and the risk is low. That's the same ladder we used for rules applied to devices, but devices bring problems that mail never had. Performance browsers nobody planned for personal laptops apps that behave strangely under inspection endpoint rules bring their own set of problems. Endpoint DLP design choices start with the browser because that's where most uploads happen. Endpoint DLP can only watch uploads in browsers. It understands Microsoft Edge has the support built in. Chrome and Firefox need an extension, which you push out through your management tools. Any other browser is a blind spot. Someone installs a lesser known one, opens a personal storage site, and the endpoint never sees the upload, so you get a setting for that Unallowed browsers. You list, the browsers you don't support, and the policy blocks sensitive files from being opened or uploaded through them. The user gets a message saying to switch to a supported browser. That's a clean fix, but it only works if the message is clear and the supported browser really works for their job. Otherwise, you've just created a new complaint. A related setting covers which websites are in play. You can list sensitive service domains like personal email and consumer storage, and apply stricter rules there. Uploads to your own SharePoint. Stay quiet. Uploads to a random file sharing site. Get checked. Same activity, different destination. Different response. Now apps. The endpoint can tell which application is touching a file and you can sort apps into groups. Allowed apps are the ones you trust with sensitive files. Your document tools, your approved transfer client. Restricted apps are the opposite programs where you want a different response when they open protected content. a third party compression tool, a file syncing client you didn't sanction. You pick the action per group audit block with override or block outright. And then there's the quiet cost. Every rule you stack on an app adds a thing to inspect, a thing to test, and the thing that can break someone's workflow. So don't restrict apps you haven't seen in your logs. Look at what's actually in use first, then decide. File path exclusions work the same way. Some folders hold files that will never matter. Build output temp directories, a backup location that a scanning tool writes to ten thousand times a night, excluding those paths, cuts noise, and saves resources. But keep the list short and write down why each path. Is there. An exclusion on a path that users can write to is a hiding place, so choose paths carefully. That brings up performance because inspection isn't free, just in time. Protection is the feature to understand here. Without it, the endpoint has to scan files ahead of time so it knows what's sensitive before anyone tries to move it. With just in time protection, the device scans a file when someone acts on it and holds the action until the check finishes. That means less background work. It also means a short delay at the moment of the copy or upload. While the scan runs. For most files, that delay is small. For large files or for devices that are already struggling, it can be noticeable. A person dragging a big video to a share and waiting several seconds will feel it and they'll tell you. So pilot it on the older hardware in your fleet, not just the new laptops your IT team carries. If the slowest machine copes, the rest will you also get a say in what happens while the scan runs? You can let the action wait, or you can let it through and decide afterward. Waiting is safer. Letting it through is smoother. Pick based on how sensitive the data is. Last the question. Teams like to dodge personal devices. Be honest about this one. Endpoint DLP works on devices you've onboarded. A personal laptop or phone that isn't enrolled is simply outside it. The policy can't inspect what it can't reach. If someone emails a file to themselves and opens it at home, the endpoint rule never fires. So for Byod, you have a few real options require enrollment before access to sensitive data, which gives you coverage but costs you goodwill. Use app protection on phones so the data stays inside managed apps, or limit what personal devices can reach at all using conditional access. So sensitive content simply doesn't land there. What you shouldn't do is pretend the gap is closed because a policy exists. Write down which devices are covered, which aren't, and what the compensating control is for each. That list is more honest than any dashboard endpoint. C files, cloud apps, C sessions, DLP beyond mail and files, email and files were the first channels. They're no longer where most conversations happen. Look at where people actually talk. A quick question goes into a team's chat. A customer detail gets pasted into a channel. A spreadsheet number appears in a meeting thread. None of that is mail and none of it is a file sitting in a library. It's a message and messages move fast. Purview DLP covers this. You can add the teams chat and channel messages location to a policy, and the same sensitive information types you've already built. Apply there. If someone posts a card number in the chat, the rule can see it. What the rule does next is where teams differs. In a chat, a block means the message is stopped before delivery and the sender gets a notice. Other people in the conversation never see the content. A tip works too, but it shows up after the sender hits enter, so you get less time to teach than you do in outlook. That's why teams rules deserve their own wording, short and plain, written for someone who's mid-conversation, there are limits. Coverage depends on the type of message and who's in the chat. Chats that include external users and guests behave differently from internal ones, and not every message type is inspected in every case. So test the scenarios your people actually use. Don't assume that a rule covering mail covers chat the same way. Now the newer channel, Microsoft three hundred sixty five copilot. Copilot takes a prompt, reaches into your tenant for content, and writes a response that creates two places where sensitive data can show up in the prompt. When someone types or pastes something they shouldn't. And in the response when copilot draws on a file that carries protected content, purview has a location for this. A DLP policy aimed at Microsoft three hundred sixty five copilot can stop copilot from processing prompts that contain certain sensitive information types. It can also keep copilot from using files and emails that carry a specific sensitivity label. When it builds an answer, the label does the sorting. Again, a document marked highly confidential stays out of the response, even if the person asking could technically open it. This is where your earlier work pays off. Twice the types and labels you spent weeks refining don't need to be rebuilt for copilot. They're the same conditions pointed at a new door. Still, cloud apps need something else. A DLP policy sees content. It doesn't see a session, meaning who connected from which device to which app, and what they did there. That's the job of defender for cloud apps. It's session policies sit between the user and the app, and they can watch or limit actions live, block a download from an unmanaged device, require a label before an upload goes through. Stop a copy paste in a browser session. It's the companion layer. DLP knows what the data is. Session controls know the situation around it. Together, they cover cases that neither handles alone. So where do the gaps still sit? Be honest about them. Content in apps outside Microsoft's reach need separate tooling messages in unmanaged chat tools. Never touch your policies. Screenshots and phone photos slip past almost everything, and any new feature that ships without a matching DLP location starts life uncovered until the policy catches up. Write that list down. A known gap with a compensating control is manageable and unknown. One is where the next incident comes from. Now, every one of these policies is live in every channel you've covered, and that means something new begins to arrive. Alerts.

00:57:10 Speaker: Alert. Triage. Designing for humans. Here's the number nobody puts on the slide. An analyst opens the queue on Monday morning and sees hundreds of alerts. By Friday, they've acted on maybe ten. The other ninety some percent get a glance, a shrug, and a click on dismiss. Not because the analyst is lazy, because a person can only read so many alerts before reading stops. After the fortieth, someone emailed an invoice. Attention drops to zero, and the one real case sits in the pile looking exactly like the other thirty nine. That's the volume problem. And it isn't a staffing problem. You can't hire your way past it because the alerts were never designed for a human to read. So design them for one three settings. Do most of the work first. Severity every rule in a DLP policy gets a level low, medium, or high. Most teams set everything to high because that feels safe. But if everything is high, the word means nothing. Tie severity to the tiers we built earlier. The audit only rule produces no alert at all. The tip and override rule produces a low or medium one. The block rule produces a high one. Now when someone sorts by severity, the top of the list is the part worth reading. Second thresholds. You can tell a rule to alert only when the match count passes a number, or when the volume crosses a line inside a time window. Ten card numbers in an hour is a different story from one card number on a Tuesday. A rule that waits for the pattern raises fewer alerts, and the ones it raises carry more weight. Third, aggregation. Without it, one person sending fifty flagged emails creates fifty alerts. With it, you can group matches over a time period into a single alert with the whole story attached. One alert says this user triggered the rule fifty one times since Monday. That's one decision for an analyst instead of fifty clicks. It also reads better because the repetition is the finding, and there's a cost knob you can adjust to. You can set a policy to send alerts only for the cases that matter, and keep everything else as plain audit records you can search later. The data is still there. It just doesn't demand a reaction. Now, where do these alerts live? Two places and they don't behave the same. The Purview Portal has its own DLP alerts page. It's built around the policy. You see the rule that fired the matched content, the user, the location, and the actions taken. It's the right view for the person who owns the policy and wants to know whether the rule is working. Then there's the defender XDR portal here. DLP alerts land in the same incident queue as everything else. The security team watches phishing, malware, identity attacks. DLP alerts can be correlated with those signals and grouped into incidents. That matters because a data leak rarely arrives alone. A sudden bulk download that follows a suspicious sign in tells a very different story than the download by itself, so the two views serve two jobs. Purview shows how the policy behaves. Defender shows how the alert fits the wider picture. Pick one as the working queue and make sure everyone knows which two teams watching two screens, each assuming the other has it is how alerts age out untouched, which raises the question that decides everything else who owns the first look? Compliance is one candidate. They know the regulations, the policies, and the reasons behind the rules, but they don't usually work a queue all day and they may not read network context. Well, the security operations team is another. They live in queues and they're fast, but they may not know that the finance team sends remittance files every Thursday, so they'll flag the routine ones as threats, and the data owner is the third. The person who runs the business process knows instantly whether this transfer is normal, but they have a day job and an alert that waits for their calendar, waits for weeks. There's no single right answer. A common split works well. The SoC or a compliance analyst takes the first pass and routes anything business specific to the data owner for a quick yes or no. What matters is that the first look has one named owner, a response time, and a backup when that person is out because an alert nobody owns isn't a signal, it's a log entry with a notification attached. And ownership alone isn't enough. A named person staring at a queue still has to know what to do with each alert, in what order, and when to stop. Triage works only if the steps are written down. The triage workflow three steps. Same order. Every alert. Step one is classification. Before anyone reads a single detail, the alert gets one of three labels true, false, or business valid. True means the rule caught what it was built to catch real sensitive data going somewhere it shouldn't. False means the rule misfired, the pattern matched, but the content was never sensitive. Like an order number that happens to look like a card and business valid is the middle one. The one teams forget to name? The data is real, the recipient is real, and the transfer is legitimate. The policy just doesn't know that yet. Why does that third label matter? Because without it, analysts shove those cases into false positive and the record lies. The rule worked. The data was sensitive. What failed was the policy's picture of the business. That's a different repair, and you'll want to count it separately later. Step two is context for things read in a fixed order so nobody skips one when the queue gets long. The user. Who is this? What's their role and should they touch this data at all? A payroll analyst sending payroll data is a different story from a marketing intern doing the same. The destination. Where did it go? A known partner domain, a personal mailbox, a consumer storage site, a USB drive. The same file means something different at each one. The volume one file or four hundred. A single match is a moment. A bulk transfer is a decision someone made, and the history. Has this user triggered the rule before? Is this the first time or the ninth this month? History is what turns an isolated event into a pattern and patterns are where real risk hides. Now notice what's missing. Nobody opens the file. First, most of the time those four facts answer the question in under a minute. The content only matters once the context leaves doubt. Step three is the decision for exits and you pick one. Dismiss. The alert was false or business valid. Nothing more is needed and you record. Why educate the user made a mistake but a harmless one. Send a short friendly note naming the rule and the safer route. No ticket, no escalation. Most true alerts from honest people end here, and it works better than any block ever did. Escalate something doesn't fit and it needs a person with more authority or more context. The data owner, a manager, the security team or open a case. The evidence suggests deliberate or serious exposure, and it needs a formal record and investigation and possibly legal or HR involvement. Four exits written on one page with the criteria for each. That's the entire workflow. It's short on purpose because a long procedure doesn't get followed at ten past four on a Friday. Now, one connection worth making the history check in. Step two has a limit. A single analyst working a single cue can't see everything one person does over months. That's where insider risk management comes in. It watches behavior over time, across many signals, and DLP alerts can feed into it as one of those signals. When the same user keeps tripping, rules or a sequence of small events adds up to something larger. That's the system's job to spot. The triage analyst's job is to notice repeats and pass them along. The repeat offender isn't solved by dismissing the ninth alert the same way as the first. It's handed to the tool built to see the long view. So three steps and four exits, plus a path for repeats. But here's the part that decides whether any of this improves. Every dismissal teaches the system. If you let it. Feeding triage back into policy. Most teams treat a dismissed alert as a closed alert. Click. Done. Next, the queue shrinks and everyone feels productive. But look at what just happened. The policy made a wrong call. A person corrected it and the correction went nowhere. Tomorrow, the same rule fires on the same kind of file and someone dismisses it again. Multiply that by a few hundred a week, and you've built a machine that pays people to repeat the same fix. So change the question. When an alert turns out false, don't ask what the user did wrong. Ask what the policy got wrong. Every false positive is a policy defect. The threshold was too low, the scope was too wide. The pattern was too loose. The exception was missing. Somebody designed that rule and the rule produced noise, which makes the noise a design flaw. Blaming the user for triggering it is like blaming a smoke alarm for going off near a toaster. That framing matters in practice because it changes who acts. If false positives are user problems, you send reminders and write training slides. If their policy defects, you open the rule and fix it, which needs a rhythm. A weekly tuning loop with one named owner, not a committee, a person. Once a week they open the alert data and ask three things which rules produce the most dismissals? What do those dismissals have in common, and what's the smallest change that removes them? Raise account, narrow a scope. Add one scoped exception with an owner and an expiry date. Then that change goes back through simulation before it touches production. Same as any other edit. Thirty to sixty minutes is usually enough. The meeting isn't the point. The point is that every week the policy gets slightly more accurate than it was the week before, and somebody's name is attached to making that happen. Without the name, the loop runs twice and then quietly dies. Now the loop needs fuel, and the fuel is the reason behind each dismissal. A bare dismiss tells you nothing. So make the reason structured. A short fixed list in a drop down, not a free text box. Something like not sensitive data. Known partner approved business process test data user error corrected every dismissal picks one and it gets recorded with the rule. The user group and the location. Why structured? Because free text can't be counted. Fifty analysts typing fifty phrasings give you a pile of sentences. A fixed list gives you a table and a table. Answers questions fast. If known, partner is the top reason on one rule, you need an allow list. If not sensitive data leads the pattern needs tighter evidence. If approved, business process dominates. Talk to that department because there's a workflow the policy never learned about. Each reason points at a different repair. That's the whole value of capturing it. And the table tells you something harder to hear. Some rules never earn their place. Look at a the rules. History over a quarter, one thousand five hundred years and not one true positive. Every case dismissed, educated away or marked business valid. That rule isn't protecting anything. It's generating work. Maybe the data it targets never leaves the company. Maybe a better rule now covers the same ground. Either way, keep it only if someone can name the risk it still addresses. Otherwise, retire it. Move it to audit only for a month, first as a safety check, then switch it off. Fewer rules means a policy people can read, and a cue where the remaining alerts mean something. Retiring a rule feels risky because nobody gets credit for deleting protection. But a rule with no true positives has been giving you the feeling of coverage without the substance. All of this tuning rests on a claim. The policy is getting better, and a claim like that needs numbers behind it. Feedback needs measurement behind it. Measuring effectiveness the right metrics. Ask most teams how their DLP program is doing and you'll hear a number blocks. We stopped twelve thousand emails last quarter. It sounds like proof. Big number, clear direction, easy to put on a slide, but look at what it actually measures. Activity. A block count goes up when the policy fires more, it goes up. When people send more mail, it goes up when a rule is too loose and catches every order number in the company, and it goes up when the policy is working perfectly. So the same number can mean success or failure, and the number itself can't tell you which block count measures how busy the policy was. It says nothing about whether data is safer. So what should you track instead for measures? Do most of the work. Each one answers a question that block count can't. The first is true positive rate. Of all the alerts raised, what share were real? You already have the data. It's the classification from triage true, false or business valid. Take the true ones. Divide by the total and you've got a direct reading of rule quality. If it sits at five percent, ninety five of every one hundred alerts are wasted attention if it climbs after each tuning cycle, the loop is working. Track it per rule, not just overall, because one bad rule hides inside a decent average. The second is override rate. Out of all the times a user saw a tip with an override option, how often did they click through? We talked about this as a warning signal and here it becomes a number. You can chart a high rate on. One rule says the rule is wrong or the wording is a rate near zero on a block with override rule might mean users have given up and stopped trying. Context decides which. But either way, the number tells you where to look. The third is time to triage. How long does an alert sit before a human classifies it? Measure from the moment it's raised to the moment it gets a label. Look at the median and also the long tail. Because the slow ones are where real incidents hide. If the median is two hours. But the worst case is take nine days. You don't have a speed problem. You have an ownership gap on certain alert types or certain shifts. That's a different fix. The fourth is repeat offender rate of the users who triggered a rule this month. How many triggered it last month? Two. Education should make this number fall. If a short note in a policy tip actually teach people the same names shouldn't keep reappearing. If they do, the guidance isn't landing or the person has a workflow the policy never understood. Either way, you've learned something a raw count would bury, and a small group of repeat names is also your best input for insider risk management. Those four tell you how the policy behaves. But there's a fifth question, and it sits underneath all of them. How much of your sensitive data is covered at all. That's coverage. The share of sensitive data that sits under a policy in a location where a rule can act on it. Here's why it matters a beautifully tuned policy that watches one mailbox group is a success story about a tiny slice. Meanwhile, labeled files sit in a SharePoint site. No rule touches and card numbers live in a OneDrive that was never in scope. Your true positive rate looks great because you only measured the part you were watching, so work it out in pieces. How many sensitive items does classification find? How many of those sit in locations covered by an active policy? How many are covered by a rule that enforces, instead of one that only audits? Each answer is a percentage, and the gaps between them are your roadmap. Low coverage doesn't mean failure. It means you know where the work is. One more habit changes how all of this reads. Look at direction, not just position. A true positive rate of thirty percent sounds poor, but if it was eight percent two months ago, the program is improving fast and an override rate of ten percent sounds healthy until you notice it was two percent last quarter and has climbed every week since. The absolute number is a snapshot. The trend is the story, so chart each measure weekly and read the slope before you read the level. Is it moving the right way? Is it flattening? Did it jump after a specific change? A jump often points straight at the edit that caused it. That also protects you from a trap. Early numbers are almost always ugly because the policy hasn't been tuned yet. Judge those numbers on their own and the program looks like a failure. Judge the direction and it looks like what it is a system that's learning. But none of this helps if the numbers stay trapped in raw logs. A metric nobody can see is a metric nobody acts on. Metrics only help if the tooling shows them dashboards, reports, and activity Explorer. Purview already collects most of what you need. The trick is knowing which screen answers which question. Start with Activity Explorer. This one surprises people because it's less a report and more a magnifying glass. It shows a timeline of individual events across your tenant. A label, applied a label, changed a file, copied to USB. A document shared a rule matched. You can filter by activity type by user, by location. By label. By policy. Pick one rule, one week, one user group and you see exactly what happened one row at a time. That makes it the best tool for the question, why did this number move when your override rate jumped on Tuesday? You don't guess you filter to that rule, sort by date and read. The course is usually sitting in the first twenty rows. A new team started sending a file type nobody planned for. It also covers labels, not just DLP, so you can check whether the labels your rules depend on are being applied at all. A rule built on a label does nothing if nobody labels anything. Next, the DLP alerts dashboard where Activity Explorer shows events. This shows alerts the ones that crossed your thresholds and earned attention. You get counts by severity, by policy, by user, and by status. So you can see how many sit untouched and how many have been classified. That status view is where time to triage lives. If open alerts pile up in one corner, you found an ownership gap without running a single query. Then the policy reports. These are built around the rule and they answer the design questions. How many matches did each rule produce? How many were overridden? How many were false positives? How does one policy compare to another? This is the view the weekly tuning owner lives in, because it points straight at the rules worth editing, so the three screens split cleanly. Activity explorer explains the alerts dashboard prioritizes the policy reports, tell you which rule to fix. But here's where it stops. These views are built for the people who run DLP. Your CFO won't open Activity Explorer and shouldn't have to. For leadership, you export. Two routes work well. The first is Microsoft Sentinel. If your security team already runs it, DLP alerts and audit data can flow in through connectors. Then data protection sits next to every other risk signal, and you can build workbooks that show trends across all of it. A spike in DLP matches after an unusual sign in is a story only a joined up view can tell. The second is power BI pull the audit and alert data into a dataset, shape it around the four measures from earlier, and build one clean page. True positive rate override rate time to triage repeat offenders. Add coverage as a fifth tile executives read charts, not logs, and a trend line with a sentence underneath beats a spreadsheet every time. A caution though, don't build the dashboard first and hope meaning follows. Decide which questions leadership needs answered, then build only the tiles that answer them. Twelve charts that nobody reads is the same noise problem, just in a prettier wrapper. Then give those numbers a home. A quarterly review one hour same format each time. Open with the trend on each core measure and say plainly whether it moved the right way. Then coverage. What share of sensitive data sits under an enforcing rule, and what changed since last quarter? Then two or three real cases anonymized that show the policy catching something or getting something wrong. Then the decisions needed budget, ownership and new data type to bring into scope and with the plan for next quarter. Same shape every time. So leaders learn to read it quickly and notice when something shifts. That review has a hidden benefit. It forces the program to have a next step. And that next step needs a plan. With phases, owners and a sequence you can defend. Measurement leads to a rollout plan, a phased rollout plan. So here's the sequence four phases in order. And the order is the whole point. Phase one is discover and classify. Before any rule exists. You find out what you have, where the sensitive data lives, which types show up, which labels are actually in use? Run Content explorer turn on your sensitive information types in audit mode, check where labels are applied and where they aren't. You're not protecting anything yet. You're building a map and the map has a second job. It tells you which data deserves attention first. Not everything does. A few data types in a few locations carry most of the real risk. Pick those. Write them down. That list is your scope for everything that follows. Phase two is simulate and tune. Now the first policies appear and none of them enforce anything. Simulation mode. As we covered you let it run for weeks. Read the results by rule, by location and by user group and adjust thresholds. Go up scopes. Narrow exceptions. Get owners. Then you retest. This phase usually takes longer than anyone budgets for. And that's fine because every hour spent here is an alert you'll never have to dismiss later. Phase three is educate with tips. Here the user sees the policy for the first time. Tips on enforcement off people get the banner, the plain wording, and the link to help. Nothing gets stopped. What you're buying is information. How people react, which tips they ignore, which ones they trust and where. The override reasons point to a broken rule. Also, people start learning the rules before the rules have teeth. That matters more than it sounds, because a block that lands on someone who already knows the policy feels fair. A block that lands on a stranger feels like an ambush. Phase four is in force. On the top. Risks only. Not everything. The shortlist from phase one. The two or three combinations where the evidence is strong, the tuning is clean and the damage from a leak is real. High confidence, high volume, external destination. Those go to block with the reporting path attached. Everything else stays on tips or ordered and resist the urge to widen quickly. Enforce a little. Watch the numbers for a few weeks and only then add the next risk. Each addition is its own small rollout with the same four steps. The program grows by repetition, not by a big switch. Now none of this runs itself. Someone has to own it. Start with a governance owner, one named person accountable for the DLP program as a whole. Not a team alias, not security and compliance. A person who can say yes, who can say not yet, and who gets the call when a rule blocks the wrong thing at the wrong moment. Without that person, decisions drift and every tuning change waits on a meeting that never gets scheduled around them a small steering group, compliance, security, IT, and a few people from the business, HR, finance, legal, engineering, whoever owns the data you're protecting, they meet on a regular rhythm, review the metrics and decide what moves to the next phase. Their real value isn't oversight, it's that the business sits at the table when a rule is designed. So the rule reflects how work actually happens. Then comes the part that gets forgotten. Change communication. People should hear about a policy before they run into it. A short note explaining what's coming, why and what to do when a tip appears, a page that stays current, a contact who answers, send it before phase three starts, and again before phase four. Say plainly which data is covered and which isn't. And what happens when someone gets it wrong. Surprise is what turns a reasonable control into a complaint. That's the plan. Discover, simulate, educate, enforce with an owner, a group, and a message. It sounds simple, and on paper it is. But plans like this fail in very predictable ways.

01:16:53 Speaker: Common failure patterns. The first failure is the oldest one block on week one, it happens under pressure. An audit finding lands. A deadline gets set and someone decides enforcement is the only proof of progress. So the rule goes live with a block action. No simulation, no tips, no warning. By Wednesday, a finance lead can't send a signed contract to a customer by Friday. There's an exception for her and another for her team, and the policy is already full of holes before it has caught a single real leak. You can't win that back. Once people learn the rule is wrong, they stop believing it's ever right. The second failure looks like diligence. Copying a template. Microsoft ships policy templates, and so do consultants and blog posts. They're a fine place to start reading, but a template reflects someone else's data, someone else's partners, and someone else's tolerance for noise. Deploy it untouched and you inherit their assumptions. A card number rule tuned for a retailer will bury a software company in order IDs. The template isn't wrong. It's untested against you, and testing is the one step that can't be borrowed. Third, the alerts that nobody owns the policy is live, the alerts are firing and they flow into a queue whose queue? Ask three people and you'll get three answers. Security assumes compliance is watching. Compliance assumes security is. Meanwhile, the oldest alert is six weeks old and it was a real one. Ownership isn't a detail you settle after launch. It's a launch requirement with a name, a response time, and a backup. Then there's exception sprawl. We covered how it starts one quick carve out at a time. What matters here is how it ends. A policy with eighty exceptions isn't a strict policy with a few allowances. It's a weak policy. Wearing a strict policy name. Nobody can explain what it actually enforces, so nobody can defend it in an audit. And nobody dares remove anything because they can't tell what depends on it. And the failure underneath all for treating DLP as a project. A project has a start date, a finish line, and a closing meeting. The team deploys the policies, writes a summary, and moves on to the next initiative. Then the business keeps changing. New partners arrive, new apps get adopted, new data types appear, and copilot opens a channel nobody planned for. The policy that fit in. March is a poor fit by October, and nobody's job is to notice. DLP is an operating practice. It has a weekly tuning loop, a quarterly review, a named owner, and a budget that doesn't expire when the rollout ends. Those aren't extras around the program. They are the program. Without them, you've built a snapshot of last year's risk and called it protection. Notice that all five failures share a root. Each one skips a feedback step. No simulation means no feedback before launch. No testing means no feedback on fit. No owner means no feedback from alerts. No review means no feedback on exceptions, and no operating rhythm means no feedback at all. So the fix is in five separate repairs. It's one connected system where every stage feeds the next. Let's put the whole model in one view. The whole model in one pass. Start with detection. Everything downstream depends on whether the policy can recognize what matters. Built in types for the generic data. Custom types for your internal IDs. Exact data match where you hold a real list of values. Trainable classifiers for content with no pattern at all, and sensitivity labels sitting on top. So one condition does the work of twelve set the confidence levels and the counts on purpose, because they decide how noisy everything else becomes. Then guide. A tip appears before the send button in plain words with the next step. When you add an override, you ask for a reason and that reason becomes data. The user isn't being stopped. They're being told something. At the moment. It's useful. That's the difference between a rule people learn from and a rule people root around. Then test simulation first, then tips with enforcement off, then enforcement on the short list of risks where the evidence is strong weeks, not days. Narrow the scope until the noise is gone and only then let the policy act. Then triage. Every alert gets classified as true, false or business valid. Then four facts in a fixed order. User destination volume history. Then one of four exits. Dismiss, educate, escalate or open a case. It sits on one page with a named owner and a backup, and then measure true positive rate override rate. Time to triage, repeat offender rate plus coverage. So you know what the policy never saw. Read the direction before the level. Then feed what you learned back into detection and the loop starts again. Notice that it is a loop. Detection. Feeds. Tips. Tips. Feed. Overrides. Overrides and dismissals. Feed. Tuning. Tuning feeds. The next simulation. No stage works alone and skipping one starves the next. That's the whole model. But there's one last shift and it isn't a setting. Conclusion and outro. The shift is about what you think a policy is for the old model treated DLP as a wall. Name the data block the exit and the problem is solved. The new model treats it as a conversation. The same data can be found in one context and a problem in another, and the policy's job is to tell the difference, then teach the person standing in front of it. So the question changes. It was how do we stop this file from leaving? Now it's what is this person trying to do and what's the safest way to let them do it? Because here's the consequence. A policy people work around protects nothing. If the block is loud and unexplained, the file goes out by phone photo. If the rule is wrong twice, it gets an exception, then ten. If the alerts bury the team, the real one sits there for six weeks. On paper, the control exists. In practice, the data walks out through the door. You forgot to watch. Blocking was never the goal. Behavior was so shaped the behavior with context, with tips. People believe with numbers that tell you whether it's working. If this episode helped leave a review of the podcast. It's a small thing and it matters. A review helps more IT leaders find episodes like this one, the ones that help policies stick instead of becoming shelfware. And if you want to keep the conversation going, connect with me on LinkedIn. Tell me what you're fighting with. Which part of DLP is still giving you trouble? Suggest the next topics and I'll build them around your problems. And one more thing. Share this with the person who owns your DLP policies, especially if they're about to turn on a block. Now, the one thing to do this week don't redesign anything. Don't rewrite your policy set. Pick one data type one, the one that worries you most. Put it in a policy, set it to simulation and let it run. Then read what comes back.