Purview Insider Risk Management: Setting It Up Without Alienating Employees

M365 FM - Purview Insider Risk Management - Setting It Up Without Alienating Employees 00:00:00 Speaker: Most insider risk programs don't fail because of the tool. They fail because of trust. The licensing works. The policies deploy, the alerts show up in the queue, and then employees find out, usually by rumor, usually wrong, and the program is dead before it ever catches anything. If you want the human side of purview, not just the toggles, subscribe. That's what this show is for. Today we're covering policy templates, indicators, Pseudonymisation, the works council, triage, communication to staff, and tuning noise. But first the old model monitor everyone investigate later. That model is the problem before we fix it. One quick sponsor note. Then we define what we're actually building. Sponsor segment stellar Migrator for exchange. This episode is supported by stellar Migrator for exchange. Here's why it belongs in this conversation. A migration is often the first time an organization really touches mailbox data at scale. Somebody has to move years of email, somebody sees folder names, sizes, shared mailboxes, old archives. And that's the moment the trust questions start. Who can see this? Who's allowed to? What happens to it afterward? Those are the same questions insider risk management asks later, just with higher stakes. So there's a practical link. A messy tenant produces messy signals, orphaned mailboxes, duplicate data, half finished moves, bulk copy jobs that look like exfiltration. All of that lands in your risk queue as noise. A clean tenant gives you cleaner signals, and cleaner signals mean fewer employees flagged for things they never did. Stellar Migrator for exchange is a tool for moving mailboxes between exchange environments, including on premises, hosted and Microsoft three hundred sixty five targets. The point is simple if you control the migration, you control the data trail it leaves behind. That's the whole note. If you're planning a move before you roll out purview, it's worth a look. Details are in the description. Now back to the core problem. The core assumption that breaks insider risk programs. Every insider risk program starts with a model. Not a policy, not a license, a model, an idea about what the program is for. And in most organizations, that idea is simple detect bad people. It sounds reasonable. It sounds like security. Somewhere inside the company, there are people who will steal data, leak plans, or sabotage systems. Find them, stop them. But in reality, that model does the opposite of what you want because. Detect bad people. Assumes you can know who's bad before they act. You can't. What you can see is activity. A file copied, a document. Printed a mailbox forwarded. Activity is not character. It's not intent. It's a pattern sitting in a log waiting for context. So the better model is different. Detect risky activity in context. That's a small change in wording. It's a huge change in structure. The first model starts with a person and hunts for evidence. The second starts with an event and asks what surrounds it. Is this person leaving? Is this data sensitive? Is this normal for their job? One signal alone means almost nothing. Several signals in the right order with the right context mean something worth a human look. Now, here's where programs break surveillance. Framing poisons adoption before a single policy exists. Think about how this usually unfolds it, or security gets the license. Somebody enables the feature. Nobody tells the staff because the thinking is if people know, they'll hide it. So the program runs quietly. Then a manager mentions it in a hallway or a works council member asks a question nobody can answer, or an employee sees a notification and posts it in a chat and suddenly the story isn't. We protect company data. The story is they're watching us and didn't say so. That story is very hard to reverse. It doesn't matter that the policies were reasonable. It doesn't matter that the data was protected. The damage is already done because people judge a monitoring program by how it was introduced, not by how it was configured. Secrecy reads as intent. Silence reads as guilt on the company's side. Now look at it from the executive view. What does a program staff don't trust actually cost? First, it costs cooperation. People root around it. They move files to personal tools where nothing can see them, which is the exact risk you were trying to reduce. Second, it costs legal exposure. A program built without consultation can be challenged, paused or forced to shut down. Third, it costs talent. Good people leave workplaces where they feel watched without explanation. And fourth, it costs the program itself. Once trust is gone, every alert looks like an accusation, and every investigation looks like retaliation. You paid for the license, you spent months on setup, and the result is a tool nobody will let you use. That's the executive math. A program without trust isn't a cheaper program. It's a more expensive failure. So let's reset the frame with one line. From the technical side, insider risk management is a signal correlation engine, not a spy tool. It takes many small events, weighs them against context, and raises a flag when the combination crosses a line you chose. It doesn't read minds. It doesn't judge people. It connects dots and then asks a human to look. That distinction matters because everything else in this episode depends on it the privacy settings, the legal steps, the works council conversation, the way you talk to staff. So before we touch any of that, we need to look at the product itself, what it actually is, where it sits and how it works structurally, what insider risk management actually is in purview. Start with where it lives inside a risk management sits inside the Microsoft Purview portal in the same family as a few other tools, and people mix them up constantly. So let's separate them by the question each one asks. Data loss prevention asks should this action be allowed right now? It's a gate. Someone tries to share a file with a credit card number in it, and DLP can warn, block or let it through. It acts in the moment. Communication compliance asks what was said. It looks at message content in email teams and other channels for things like harassment or regulated language. It reads words. E-Discovery asks what do we have and can we hold it? It's a legal tool. You search, you preserve, you export. Somebody already has a reason to look. Defender asks, is something attacking us? It watches for threats, mostly from outside and often at the device or identity level. Insider Risk Management asks something different. Is this pattern of activity unusual, and does the context make it worth a human look? Notice what that means. It doesn't block. It doesn't read message content the way communication compliance does. It doesn't search on demand like e-discovery. It watches behavior over time and connects it to context. In practice, these tools feed each other. A DLP event can become a signal. A defender alert can raise a user's risk. A case in insider risk can lead to an e-discovery hold, but each one has its own job, and your staff will care a lot about which one is doing what. Now, structurally, how does the product work? Five steps signals in policy logic. Risk score alert. Case signals are the raw material. Small events from across Microsoft three hundred sixty five and connected sources. A file downloaded a document shared outside the company, a USB device plugged in on their own. Most of these are completely ordinary policy logic is where you decide which signals matter, for which people under which conditions. This is the part you configure. It's a set of rules you chose, not something the product invented. Then comes the risk score. The engine weighs the signals that match your policy, looks at how unusual they are for that user, and gives the activity a score and a severity level low, medium or high. If that score crosses the line, you set the product raises an alert. An alert is not a finding. It's a flag that says a human should look at this. And only if that human agrees does an alert become a case. A case is a structured record. Notes, evidence, a timeline, an outcome. Here's the same flow in the way I'd say it out loud if you were listening on a walk event reasoning action, an event happens. Someone copies a large set of files to a USB drive by itself. That's just an event. Then, reasoning, the system asks, is this person leaving? Are those files sensitive? Is this normal for their role? Has it happened before? Reasoning turns a single event into a pattern or tells you it's nothing, and then action, not action against a person. Action by a person. An analyst reviews it. Maybe it gets dismissed. Maybe it becomes a case. Maybe the right answer is a quiet conversation with a manager. The tool handles the first two people handle the third. That split is the whole design, and it's the part you'll want to protect later. Now, what does this product not do? It doesn't judge intent. It can't tell you whether someone copied files to steal them or because they're working from home on a deadline. It can't tell you if a bulk download was a plan to leave with a client list, or a tired person finishing a project at midnight, it sees the pattern. It doesn't see the reason. That's not a weakness to apologize for. It's the honest limit of the technology. And it's exactly why the human steps matter. Anyone who treats a risk score as proof of bad intent is using the product for something it was never built to do. What it does well is surface patterns that no person would ever spot by hand, across thousands of users and millions of events. That's the real value. Not catching villains, narrowing a huge pile of activity down to the few things worth a careful, fair look. But none of this works if the foundation isn't there. The product has requirements, licenses, roles, logging connectors, boring things, the things nobody wants to talk about in a kickoff meeting. And they're where the first privacy decisions actually get made. Licensing roles and prerequisites before you touch a policy, let's start with the part that sounds like procurement. Licensing. Insider risk management isn't in the basic Microsoft three. Sixty five plans you need E5 or E5 compliance add on, or the standalone Insider Risk Management add on that sits on top of E3. For organizations that don't want the full bundle, that's the plain version. Check what your tenant actually holds before anyone promises the program to a steering group. Licenses also decide which features you get. Some newer capabilities like adaptive protection. Need specific entitlements? Read the fine print early. A feature you designed around and can't turn on is a bad day in a works Council meeting now rolls. This is where most teams rush, and it's the first place privacy gets decided. Not in a setting called privacy in who gets in the door. Purview uses role groups for this five matter here. Inside a risk management is the broad group the all access one. It can create policies, see alerts, open cases and change settings. Treat it like a master key. Insider risk management analysts handle the alert queue. They do first pass review. They can look at alerts and decide whether something deserves a closer look. Inside a risk management investigators go further. They work cases, they can see more content and more history because investigation needs depth. Insider risk management auditors can read the audit trail. They see who did what inside the program, but they don't work. Alerts or cases and insider risk management admins configure the system policies, settings, connectors, indicators. They shape what gets watched. They don't need to read individual cases to do that. So why split them? Because separation isn't paperwork. It's a privacy control. Think about what happens without it. One person builds the policy, watches the alerts, investigates the cases, and reviews their own work. That person holds every piece of the process. No one checks them. And if that person is curious or angry or just careless, nothing in the structure stops them. With separation. No single person holds the whole chain. The admin decides what's watched but doesn't see the people. The analyst sees alerts but can't change the rules. The investigator sees depth, but only on cases that were escalated and the auditor checks all of them. That's the real design. Each role gets only what its job needs. That's data minimization applied to your own staff. And here's the point. Teams miss the works. Council will ask for exactly this. Not in those words. They'll ask who can see my colleague's data? A clean role model is your answer, and it's much stronger when it already exists on a diagram than when you're improvising it in the meeting. Two more prerequisites and then we move on. First, audit logging must be on insider risk management reads its signals from the unified audit log. If auditing is off, the product has nothing to work with, no log, no signals, and the same log records what your own program staff do. So turning it on isn't only a technical step, it's what makes the program accountable. Check it before anything else. A surprising number of tenants have never confirmed it. Second, the HR connector. Some policies depend on facts that live outside Microsoft three hundred sixty five. The best example is the departing user policy. It needs to know who is leaving and when that information sits in your HR system. A connector brings it into purview, usually as a scheduled file or feed, with fields like resignation date and termination date. Without that connector. The policy has no trigger. It can't tell a normal employee from someone on the way out, so the policy either stays silent or has to monitor far more broadly than it should. We'll come back to this in detail later, because the quality of that data matters a lot. But for now, just note the dependency. Your HR team becomes part of the program before the first alert ever fires. Which brings us to the first real design decision. Not which policy, not which template, who sees what. Every role, every connector, every log answers that question, whether you planned it or not. So it needs to be planned. And that means getting the right people into the room. The stakeholder map who must be in the room. Most insider risk projects start with a meeting of one someone in IT or security, a license, and a plan to figure out the rest later. But a program that watches how people work touches almost every part of the company. So seven groups need a seat security, HR, legal, privacy, usually the data protection officer, the works council where one exists, internal audit and communications. Each of them walks in carrying a different fear, and each needs something specific before they'll back the program. Start with security. Their fear is simple a breach they could have seen coming. Someone leaves with the customer list and the log showed it for weeks. What they need is signal quality alerts they can act on. Not a cue so loud that real events drown in it. HR fears two things at once first, being dragged into investigations without warning, second, being blamed when a case goes wrong, they need clear rules for when they are pulled in, and a promise that this isn't a back door into performance reviews, legal fears, exposure, a monitoring program that breaks employment law, or a case that falls apart because the evidence was collected the wrong way. They need a documented basis for every decision and a say in how evidence is handled before a case exists. The data protection officer fears the quiet version of the same thing collection that grows because it can. They need limits written down what's collected, why, for how long and who can see it. The Works Council fears something more personal that colleagues will be watched, judged and disciplined, and nobody will have agreed to it. They need real influence over scope and access, not a briefing after the decisions are made. Internal audit fears a blind spot, a powerful tool with no one checking the people who use it. They need access to the trail and independence from the people running the program and communications fears the hallway rumor, the one we talked about earlier. They need to know what's true early enough to tell it first. Notice how many of those needs conflict. Security wants more signal. The works council wants less collection. HR wants a wall. Legal wants a record. That's not a problem to hide. That's the reason the room exists. Those tensions get settled in a meeting on paper before go live, or they get settled later in a grievance in public. So why can't it just own this? Because it can configure everything and decide almost nothing that matters. It can turn on an indicator. I can't decide whether monitoring it is proportionate. It can build the role model. I can't decide what counts as a fair outcome for a person. Those are questions about law, about employment, about trust. They don't have technical answers. And there's a structural problem too. If it owns the program, it also runs the tool, sees the data and judges the results. We just spent a whole section splitting those jobs apart. Putting them all back into one team at the organizational level undoes the design so it builds it doesn't own ownership. Belongs to a steering group with a named sponsor, usually from security or risk, and every function above holding a defined seat. Now what does that group actually produce? First one document the charter. It's short two or three pages and it answers four questions in plain language purpose. Why does this program exist? Protecting sensitive data and reducing harm from risky activity. Not measuring productivity, not finding out who's unhappy. Scope which users, which data, which signals which parts of the business. And just as important, what's left out limits what the program will never be used for performance management, union activity, anything outside the stated purpose written as commitments because that's what the Works council will read them as and escalation. When does an alert become a case? Who is told? Who decides who can step in if something looks wrong? Everything later builds on this page the legal assessment, the works agreement, the policy settings, even the message to staff. If a decision can't be traced back to the charter, it probably shouldn't be made. But a charter isn't just a good idea. In most of Europe, it's the starting point for something with legal force, because the rules around employee data don't come from your preferences, they come from law, and that's the ground we need to cover next. Legal foundations, lawful basis, proportionality and purpose limitation. The charter gives you intent. The law decides whether that intent is allowed, and in Europe that law is the GDPR. Nobody wants a regulation lecture. So here are the ideas that matter in plain speech. Three of them carry most of the weight. Necessity proportionality. Transparency. Necessity asks do you actually need this? Not. Would it be nice? Not. Could it help? Is there a real risk and is monitoring a needed answer to it? If a simpler control would solve the same problem, the heavier one is hard to defend. Proportionality asks is the response the right size? You can have a real risk and still overreach. Watching every employees, every file action to catch the rare person who steals data. That's a big net for a small fish. Narrow triggered role based monitoring is a smaller net. Regulators and works councils look at that gap closely. Transparency asks do people know? Not in a footnote, in words, they can read and understand that one connects straight back to the hallway. Rumor problem hiding the program isn't just bad politics. In most cases, it's illegal failure. Now the question every project hits. Next, what's your lawful basis? GDPR requires one for processing personal data for employee monitoring. People usually reach for consent first. It feels clean. Just ask staff to agree. But in an employment relationship, consent is shaky. Think about it. Can an employee really say no to their employer? The power gap is built in a yes given under that pressure isn't freely given and regulators know it. So consent tends to fail as a basis and it can be withdrawn anyway, which would leave your program with holes. The more common basis is legitimate interest. The company has a real interest in protecting its data, its customers and its people. That's valid, but it comes with a test. You have to show the interest is real, show the processing is needed for it, and then balance it against the rights of the employees. If their privacy outweighs your interest, the basis doesn't hold. So legitimate. Interest isn't a free pass, it's a claim you have to prove on paper with the balancing done honestly, some countries also lay a national employment law on top, which can narrow what's allowed further. That's one more reason legal has a seat in the room. Next idea. Purpose limitation. You collect data for a stated purpose, you use it for that purpose. Nothing else. In this program, the stated purpose is risk. Data theft leaks, sabotage, harm to the company or its people. That's it. 00:17:25 Speaker: And here's where programs quietly drift. A manager sees that the tool shows activity by person and asks, can we check who's actually working? Or HR asks, can we pull this for a performance review? Each request sounds small. Each one pulls the program away from its purpose, and each one is a breach of the promise you made when you wrote the charter. Inside a risk management is for risk. It isn't a productivity dashboard. It isn't an evidence locker for performance management. If data collected for one purpose gets used for another, you've lost your legal footing and your credibility in the same moment. So how do you prove all of this with a document called a Data Protection Impact Assessment? A dpia is required when processing is likely to create a high risk for people's rights. Systematic monitoring of employees is a textbook case. So for this program, the question isn't whether you need one. You do. What goes into it? The nature of the processing, what data from which systems about whom, the purpose and the lawful basis. An honest test of necessity and proportionality. The risks to employees like wrongful suspicion, chilling effects on normal work or misuse of access and the measures you'll take to reduce those risks. Pseudonymisation role separation retention limits access controls treat it as a working document, not a form the Data Protection officer should shape it, and legal should review it, and it should get revisited when the programme changes. Done well, the Dpia does two jobs. It protects employees and it hands you the exact material you need for the next conversation. Because in many countries, legal approval isn't the last gate. There's another one, and it's run by employees own elected representatives working with the Works Council from day one. In Germany, you don't get to decide this alone. That's not a courtesy. It's the law. Under the Works Constitution Act, the Works Council has a right of co-determination over any technical system that can monitor employee behaviour or performance. And the word that matters there is can. It doesn't matter whether you plan to use it that way. If the system is capable of it, the council has a say. Insider risk management is capable of it. So the council has a say. Germany is the strongest example, but it isn't the only one. Across the EU, employee representatives hold information and consultation rights over workplace changes. The details differ by country. Some require agreement, others require consultation. A few sits somewhere between, but the direction is the same. Employees get a voice before monitoring starts, not after. So the first practical point is timing. Most teams bring the council in once the design is finished. They show up with a configured tenant and ask for a signature. And that's the wrong order. At that stage, every objection sounds like an attack on work already done. People dig in positions, Harden, bring them in at the start before the first policy exists. Then they're helping shape the program, not reviewing a decision you already made. Now what do you bring to that first meeting? Four things and you already have most of them. The charter purpose scope limits escalation. This is the council's first read. So make sure the limits are written as commitments, not as hopes. The Dpia don't hand it over as a compliance exhibit. Hand it over as shared homework. The risks you named in it are the same risks the council cares about, and showing that you've already thought about them changes the tone of the room. The data flow a simple diagram which system sends signals where they land, who touches them, where they end up? Not a screenshot of the portal. A picture a non-technical person can follow in two minutes. And the role model who sees alerts, who sees cases, who sees nothing. This is the one the council will study hardest because it answers their central question. Who can see? My colleagues? If you can answer that question on one page, you're already ahead of most programs. From there, the conversation usually leads to a works agreement, a written document signed by both sides that sets the rules in a form that can be enforced. What goes into it? Scope first, which groups are covered, which signals are collected, and which policies are active. Name them. Vague scope is how programs grow without anyone agreeing to it. Retention. Next, how long alert data and case data are kept and when they're deleted. A number. Not a phrase like as long as necessary, then access which roles can see what and who approves changes to that list. Then escalation when an alert may become a case, and when HR or legal may be told, plus a clear statement of what the data can never be used for and finally appeal. If an employee is affected by a case, what can they do? Who do they ask? Who reviews it? A process with no way to challenge it isn't a process, it's a verdict. One more clause matters more than people expect. Any change to scope, indicators or access comes back to the council before it goes live. That's what stops the silent drift. We'll cover later. Now you'll hear objections. Expect them. And the useful move is to answer with structure, not with reassurance. This is surveillance. The structural answer monitoring is triggered by context, scope to define groups and pseudonymized until a human has a reason to look. Show them the settings, not the slogan. You'll use it for performance reviews. The structural answer. The agreement forbids it in writing, and. The audit trail shows who accessed what. Misuse becomes visible, and breaching the agreement has consequences. Managers will see everything. The structural answer. Managers don't hold any program role. They never see alerts or cases. We don't trust it. Fair. So the auditor role sits outside it and the council can request the audit trail on the schedule. Notice the pattern. Every answer points to something the product enforces, not something the company promises. That matters because a promise depends on who's in charge next year. A setting doesn't, so the agreement is only half the job. Paper says what should happen now? The product has to make it happen, starting with the one feature that hides your colleagues names. Privacy by design Pseudonymization in purview. Here's what an analyst sees first when they open an alert. Not a name, not an email address. Something like anonymized user for F two A. That's pseudonymization. In insider risk management. It does one job. It replaces the real username with a generated identifier. Everywhere an analyst looks the alert queue the user activity view, the case timeline. The person behind the activity stays hidden. The activity itself stays fully visible. Why does that matter? Because most first pass reviews don't need to know who someone is. They need to know what happened, which files, how many, how unusual, and what else was going on around it. A person reading that pattern without a name attached is far less likely to be swayed by the one thing that shouldn't matter yet, whether they like the person or have an opinion about them. It also changes the feel of the work. Nobody in the queue is looking at a colleague. They're looking at a pattern. That distance is a safeguard and it's built in rather than promised. Now the obvious question can anyone ever see the real name? Yes. And that's by design. A pattern that looks serious has to be tied to a person eventually, or no one could act on it. So the product let certain roles reveal the identity. The key is who and under what trail. The reveal sits behind role permissions. Analysts working the queue can stay anonymous when a case needs the real identity. Someone in a higher role, usually an investigator, can resolve it, and every reveal is written to the audit log who looked, which user and when. That audit entry is the point, auditors can check it. The works council can ask for it. If someone unmasked a colleague out of curiosity, the record shows it so the reveal isn't blocked. It's visible and in practice, visible access behaves very differently from invisible access. One design choice is worth making deliberately decide who may reveal and write it into the work's agreement. Don't leave it as a default. A short list of named roles is easy to defend. Whoever has the permission is not. Now, where do you turn this on? At the tenant level. It lives in the insider risk management settings under privacy. There's a single choice there. Show users with their real names or show them anonymized. It applies across the whole program not per policy. So this is a tenant wide decision. And it should be made once early with privacy and the council in the room. And my view is simple start with it on turning it off later is easy if you have a justified reason, turning it on after months of analysts working with real names is harder because by then people have seen things they can't unsee. The default direction should favor privacy, and anything else needs an argument. What changes for the analyst? Less than you'd expect. And that's good news. The Q works the same. Severity levels, activity charts, sequences, and content details all appear as before. What's missing is the label. If the analyst needs to move a case forward, they request the reveal through the proper role. That adds one step, and that step is the checkpoint. Some teams push back, saying it slows them down a little. Yes, but it slows them down exactly. At the moment, someone is deciding whether a specific person deserves scrutiny. A small pause. There is the feature working now. A point where people get loose with language and precision matters here, especially in front of a works council or a regulator. Pseudonymisation is not anonymization. Anonymization means the link to the person is gone for good. Nobody including you can trace the data back. Once it's truly anonymous, it falls outside data protection law because it no longer describes an identifiable person. Pseudonymisation is different. The name is swapped for a code, but the key still exists somewhere. The system can map that code back to a real person, and that's exactly what lets the reveal work. So under GDPR, if Pseudonymized data is still personal data, all the rules still apply. Purpose, limitation. Retention. Access control everything. So never describe this feature as anonymous monitoring. It isn't. And the first sharp eyed council member will say, so call it what it is a protective layer that limits who sees identities and when. A strong safeguard, not a loophole. And names are only one piece of what an analyst sees who is in scope, which groups are excluded, how long records are kept, and who can query the underlying logs or shape what the program knows about people. Those are the next settings to get right. Privacy settings. Scoping and data minimization. Hiding names is one layer. The next layer is deciding whose activity enters the program at all. By default, a policy can cover everyone in the tenant that's convenient. It's also the broadest net you can cast, and it's rarely the one you can defend. So purview gives you a tool to narrow it. Administrative units an administrative unit is a container. You group users by region, by department, or by legal entity. Then you assign program roles to that container instead of to the whole company. An analyst for the German subsidiary sees alerts for German staff, nobody else's. An investigator in one business unit can't open a case in another. Why does this matter? Because scope is a promise you made in the works agreement, and a promise like only these groups are covered is much stronger when the product enforces the boundary. If the council in one country negotiated tighter limits than another, administrative units let you honor both same tenant, different rules, no exceptions made by hand. It also cuts risk from your own side. A person who can only see their own region can only misuse their own region. That's data minimization again applied to the people holding the keys. Now the harder question who should be left out entirely? Some groups are protected by law or by agreement. Members of the Works Council itself in many countries can't be monitored in ways that reveal their representative work. Data protection officers and company doctors often sit in the same category. Legal counsel may handle privileged material, and a program that pulls that into an alert queue creates a problem on day one, so you exclude them. Purview lets you remove specific users or groups from policy scope. You build the exclusion list with legal and privacy, and you write the reasoning down, not because those people are above suspicion, because the law says the monitoring itself would be improper, and a case built on improperly collected evidence falls apart. Keep that list short, though. Every exclusion is also a blind spot if the list grows because people ask nicely, you've traded one problem for another. Each name needs a reason you can state out loud. Next. Setting retention, alert data and case data are different things, and they deserve different clocks and alert. That was dismissed after a quick review. Holds personal data about someone who did nothing wrong. Keeping it for years makes no sense. A confirmed case tied to a formal process may need to stay longer because the outcome could be challenged. Purview lets you configure how long this data stays. And here's the trap. The default is not a decision. It's just whatever the product shipped with. So you set it on purpose. Pick a number for alerts. Pick a number for cases, take those numbers from the Dpia and from the works agreement, and make sure all three documents say the same thing. If the agreement promises deletion after a set period and the tenant keeps data longer, you've broken a signed commitment without anyone noticing. Then check that deletion actually happens. Ask for evidence, not assurance. One more place data hides ordered data. Everything people do inside the program. Every alert opened, every identity revealed, every case note lands in the audit log. That log is how you prove the program behaves. It's also a pile of sensitive records about both employees and your own staff. So decide who can search it. Auditors? Yes, that's their job program administrators. Probably not, since they'd be reading the record of their own actions and decide how often ordered extracts go to the works council or the steering group, and in what form. A scheduled report with fixed fields is easier to trust than an open door. Treat the audit log like any other sensitive system named access, a stated purpose, and a retention period that someone chose. Scope. Exclusions. Retention. Audit. Access those four settings. Decide how much the program knows and about whom, which leaves the engine itself, the part that decides what counts as risky in the first place. Policies. Policy templates. Explained. The full catalog. A policy in insider risk Management starts from a template. A template isn't a finished rule. It's a starting shape. It preselects the indicators, sets a sensible scope and frames the question the policy is meant to answer. You then adjust it. Microsoft ships a growing list of them. Let's walk through the ones that matter by what each one is actually asking. Start with data theft by departing users. This is the one most programs begin with and for good reason. The risk is easy to explain when people leave. Some of them take things. Customer lists, designs, contracts. The template watches for unusual activity in a window around the departure files copied to USB, large downloads, documents sent to personal email and it only starts watching after a triggering event, usually from your HR connector. No resignation date. No monitoring. We'll get into that trigger in detail soon, but notice the design context switches the policy on, not a blanket rule. Next data leaks. This template asks a wider question. Not is someone leaving, but is sensitive information moving somewhere it shouldn't? It looks at sharing outside the company, copying to cloud storage and similar activity with no departure needed. That makes it broader and so noisier. It also pairs with sensitivity labels and DLP signals so the product knows which files are worth caring about. Then there's data leaks by priority users. Same question. Narrower group. You pointed at people with elevated access or elevated risk like administrators or executives, and the policy applies closer attention to them. That's a heavier tool and a heavier tool needs heavier governance. We'll come back to that now. Security policy violations. This family looks at behavior that weakens your defenses, not at data, leaving someone disabling anti malware on their device, someone tampering with security controls. Someone installing risky software. There's also a variant for risky browser usage, which watches for visits to sites flagged as dangerous, like malware hosts or phishing pages, and for downloads from them. The question here isn't is this person stealing? It's is this person knowingly or not, opening a door? And honestly, most hits on this one are accidents, which tells you what outcome to expect education, not discipline. Then come the newer and more specialized templates. Patient data misuse is built for healthcare. It watches for inappropriate access to patient records, like someone opening files for people they have no care relationship with. If you run a hospital or a clinic, that question matters a lot if you don't ignore it. Risky AI usage is the one many teams ask about. Now it looks at how people use AI tools, including prompts that contain sensitive material and attempts to get around safeguards. It's a response to a new kind of exposure an employee paste a client contract into a chat bot? Nobody meant harm, but the data left. You'll also find templates for things like risky agents, and the list keeps shifting as the product evolves, so don't memorize it. Check what's currently available in your tenant before you plan around a specific one, which raises the real selection problem. How do you pick? Most teams scroll the list and choose by feature. That sounds thorough, but it backfires. You end up enabling five policies because they all looked useful and your queue fills with overlapping alerts. Nobody asked for. Choose by question. Instead, write down the single worry you're trying to address. We're afraid departing sales staff take client data that points to one template. We're afraid administrators could weaken our security. That points to another. We're afraid people paste sensitive data into AI tools. Another. Again, each question gets one policy. If you can't state the question in a sentence, you aren't ready to enable the template and start with one or two, not the whole catalog. Because a template on its own does nothing. It's a shape with nothing inside. It only works when the right signals flow into it, and what gets observed from which systems is the next thing to get right Indicators and signals. What gets observed. A policy is a question. Indicators are what it can see. Without them, the template has nothing to read. And this is the point where the program stops being an idea and starts touching real activity. So it's worth knowing exactly where the signals come from for families first. Microsoft three. Sixty five activity. This is the everyday work trail. Someone opens a file, edits it, shares it, deletes it. All of that is already recorded in the audit log we talked about earlier. Insider risk management reads from it. Second endpoint signals. These come from the device itself, not from the cloud. What happened on the laptop? A file copied to a USB drive. A document sent to a printer. Something uploaded through a browser to a site outside your control. To see any of this, devices have to be onboarded to purview, usually through defender for endpoint or Intune. No onboarding, no endpoint view third defender signals if defender raises an alert about risky behavior on a device or an account that can feed into the risk picture as well, it's one tool hand in context to another, and fourth signals from connected sources, the HR connector, which we'll get to properly in a moment, is the main one. But there are others, including physical access data and some third party feeds. Now let's get concrete about what that looks like in practice in office and SharePoint. The indicators cover things like downloading files, sharing them with people outside the company, and changing or removing sensitivity labels in teams. It's sharing files in chats and channels, especially with external guests. In exchange, it's sending attachments to outside addresses or to personal email accounts for cloud storage. The question is whether files are being copied to services like personal drives or file sharing sites, than the device side USB copies printing network sharing browser uploads. These matter because they're the exits that leave the cloud altogether. A file that never touches the SharePoint share link can still walk out on a thumb drive. Notice what's not on that list. Message content the indicators here watch actions, not words. Who sent a file and where it went, not what the email said. That distinction is one to say out loud to your staff, because it's one of the facts that makes this program different from the content reading tools we separated earlier. Now here's where people get stuck. There are two places to switch indicators on, and they're not the same thing. 00:35:01 Speaker: The first is global settings. This is the tenant wide menu. Here you decide which indicators exist for the program at all. If an indicator isn't turned on here, no policy can use it. Think of it as the pool of what's available. The second is the policy itself. When you build a policy from a template, you choose which of those available indicators it actually listens to. So a departing user policy might use file downloads and USB copies, but ignore printing. A security violation policy might use none of the file indicators at all. So the structure is two filters. Global settings set the outer boundary policy selection narrows it for each question you're asking that layering is a privacy feature. Your dpia can say in specific terms which indicators are enabled and which policies use them, and the works council can read that list and know exactly what's observed, not activity on devices. A named list. Which brings us to the most common mistake in the whole setup turning everything on. It feels responsible. More signal, more coverage, fewer blind spots. The wizard even offers to select all of them for you. But think about what that does to the queue. Every indicator adds events. Every event can contribute to a score. An ordinary employee who prints a document, copies a file to a USB stick for a presentation, and shares a folder with a client has just touched three indicators in one afternoon. Multiply that by thousands of people. Now your analysts are reading alerts about normal Tuesday work, and the real patterns are buried underneath. That's the fastest way to flood your queue. And a flooded queue hurts people in two ways. Analysts burn out and start dismissing alerts quickly, and employees get flagged for things that were never a concern, which is exactly how trust erodes. So match each indicator to a question you can state. If you can't explain why an indicator is on, switch it off. But even a carefully chosen list isn't enough on its own, because an indicator only tells the engine that something happened. It doesn't say how much of it counts as unusual. Ten files or ten thousand. That's the threshold. Question thresholds, sequences and risk scoring logic. An indicator says something happened. A threshold says how much of it matters. Purview gives you two ways to set that default thresholds and custom ones. The default is the product's own judgment. Microsoft sets the line using typical activity patterns and flags. What stands out against them for a first pilot? That's a reasonable place to start because you don't yet know what normal looks like in your company. But typical is a guess about everyone else's tenant. Your sales team might move large files all day, your design team might live on USB drives, your finance team might share outside the company every week because that's the job. So you move to custom thresholds. For each indicator, you decide how many events count as a trigger, or you let the engine compare each person against their own history. Ten file downloads is nothing for one role. For another, it's a spike, and the choice sits at the indicator level, not just the policy level. So you can be strict where the risk is real and relaxed where it isn't. Write the numbers down though a threshold nobody recorded as a threshold nobody can defend later. Now single events are weak evidence order is stronger. That's what sequence detection does. It doesn't just count actions. It watches for a chain that tells a story. Someone downloads a set of sensitive files from SharePoint. Then they rename those files, maybe to something dull, or change the extensions. Then they copy them to a USB drive or send them to a personal email address. Any one of those steps is ordinary people download files, people rename files, people use USB drives, but download, then disguise, then move out in that order within a short window. That pattern is rare in honest work. The engine gives sequences extra weight because the order itself is the context. And notice what you can say to a skeptical employee here. The product isn't flagging people for having a USB drive. It's looking for a specific shape of behavior that lines up with taking data out the door. Next, a different problem. Slow leaks. Someone who knows they might be watched won't move a thousand files in one hour. They'll move twenty a day for two months. No single day crosses a threshold. The total, though, is enormous. That's where cumulative exfiltration comes in. The engine adds activity up over time and compares the total against what's normal for that user and for their peers and the activity over time. View lets an analyst see it as a chart, a flat line, then a slow climb, then a jump. You read the shape, not the single event. It cuts the other way to a spike that looks scary in isolation can sit right on a person's usual rhythm. Once you see the full timeline. A quarterly report that always means a big download at the end of the quarter. The chart shows the habit the alert alone doesn't. So how does a score actually get assigned for things? Feed it. Which indicators fired How unusual. Each one was for this user. Whether the data involved was sensitive, which depends on labels and sensitive information types, and whether any sequence or cumulative pattern showed up. The engine combines those into a risk score for the user inside that policy. Then it maps the score to a severity level low, medium or high, and you can tune where those lines sit. Some teams find that default high severity is too loose for their size and move the bar. The point to hold on to. Is this. The score is a ranking. It tells analysts what to read first. It doesn't say what happened and it doesn't say why. A high score means the pattern is loud. It doesn't mean the person is guilty. Treat severity as a queue order and you'll use it the way it was built. But all of this logic has a blind spot. It sees what people do with files, devices, and mailboxes. It can't see why a person might suddenly be a bigger risk. Some of the strongest accelerators of risk never show up in a log at all. A resignation letter, a failed review, a termination date. They live in the HR system, outside purview. And that's the data. The next part depends on HR connector and triggering events. Think about the departing user policy for a second. What is it really asking? What does this person download? A lot of files. Plenty of people do it. Asks whether someone who is about to leave is taking things with them. That question only makes sense for a small group of people in a short window of time. For everyone else, it's the wrong question. So the policy needs a trigger. Without one, you have two bad choices. Watch every employee all the time just in case. Or watch no one. The first is surveillance with a thin excuse. The second is a policy that does nothing. A trigger gives you a third option stay quiet until something in the person's situation changes. That something comes from your HR system. The HR connector is how it gets into purview. You export data from your HR platform, usually as a scheduled file or an API feed, and the connector imports it. The data is simple an employee identifier, an event type, and a date purview matches that identifier to the person's account, and the policy wakes up. Four kinds of data matter. Most resignation date when someone hands a notice, monitoring can begin and it can run through their last day termination date. Same logic, but the timeline is usually shorter and the situation is more tense. Performance information. Some policies can use signals like a performance improvement plan or a poor review, because stress and grievance can raise the chance of risky behavior. And this is the sensitive one. It's also the one where purpose limitation matters most. The data goes into raise a risk score not to start a performance file inside the security team, decide with HR and the council whether you want this feed at all. Many programs leave it out and that's a defensible choice. And job level changes, demotions, role changes, anything that shifts access or standing. Same caution applies. Here's the part that gets ignored. The trigger is only as good as the data behind it. Say your HR system updates once a week in a batch. An employee resigns on Monday and leaves on Friday. The feed runs Sunday night. By then, the person is gone. The alert comes after the files left the building, and the policy did its job a week too late. Now flip it. A manager enters a termination date by mistake, then corrects it. Three days later, the policy fired on bad data. An analyst reviews. A perfectly ordinary person flags normal behavior as suspicious, and nobody ever tells that person a thing or the identifier doesn't match. HR uses an employee number, entry, uses an email address, and the mapping has gaps. Some people get monitored who shouldn't. Others slip through. So treat the HR feed like any other control. Check how often it runs. Check how fast changes arrive. Check the match rate between HR records and purview accounts, and decide who owns fixing it when it breaks. That's usually an HR systems person, and they need to know that data now drives a security program. Late feeds cause late alerts, wrong feeds cause false ones, and a false alert about a real person is how a tool starts to hurt someone. Now step back because there's a bigger point here. The trigger isn't only a technical convenience, it's one of the strongest privacy features in the product. Consider what it means. A departing user policy doesn't watch you while you're a happy, stable employee. It doesn't read your activity for years in advance. It switches on when a documented event says the risk picture has changed. Monitoring starts only when context justifies it. That's proportionality built into the logic, and it gives you a clean sentence for the work's agreement and for staff monitoring for departure risk begins only after a resignation or termination is recorded, and it ends when the person leaves. Everything outside that window stays unwatched by that policy. Compare that with the old model where everyone is monitored all the time and the review happens later. The trigger turns that around. The question comes first. The watching follows, but not every risk waits for an HR event. Some people carry more potential for harm simply because of what they can reach. An administrator with access to every mailbox. An executive with the full acquisition plan. For them, a resignation letter isn't the only moment that matters. That's a different kind of policy and a heavier one. Priority user groups and sensitive role handling. Some people carry more risk by design, not because of who they are, because of what they can reach. Purview calls the answer a priority user group. You pick a set of people. The policies treat them with closer attention. The activity gets weighted more heavily. Their patterns get read with a tighter eye. That's the whole idea. So who belongs in one? Start with administrators, a global admin, or someone who can read every mailbox can undo almost any control you've built if their account is misused by them or by an attacker holding their credentials, the damage is wide. Next come executives. They hold the acquisition plan, the board papers, the pricing strategy, and then a third group. That's easy to miss. Anyone with regular access to what you'd call the Crown jewels, source code formulas, customer databases, the files that would hurt most if they left. Notice what ties those three together. It isn't seniority. It isn't attitude. It's blast radius. The more a single person can expose, the more the program cares about that one account. But here's the cost. Elevated monitoring is a heavier intrusion. That means it needs heavier rules around it. Think about what a priority group really does. It says to a specific set of colleagues you get more attention than everyone else. If that list is vague or grows quietly or is maintained by one person's judgment, you've built a tool for singling people out. So write down the criteria name who approves additions, name who approves removals. Review the list on the schedule. Put it in front of the works Council like any other scope decision, and tighten access to the results. Alerts about priority users should go to fewer people. Not the same pool. Pseudonymization stays on, reveals need a stronger reason and a second approver on top of the audit entry. More watching, fewer watchers. That's the trade. Now the awkward part. Some of the people who handle your most sensitive information are the very people who run the programs sensitive processes. HR staff see salaries, medical notes, disciplinary files, legal staff see privileged advice, litigation strategy, merger plans their daily work moves exactly the kind of data these policies are built to notice. So they light up a lawyer sending a large, privileged document set to outside counsel looks to the engine like a leak. You have two problems at once noise because their normal work trips, the indicators and sensitivity. Because if one of them is flagged, the people reviewing the alert may be their own colleagues or the person who sits across the hall. So handle them. Deliberately tune thresholds to their real working patterns using the sanctioned workflows they depend on, route their alerts away from anyone in their own reporting line. In small organizations, that may mean an external reviewer or a second function entirely, and decide up front with legal which activities privileged and must never surface in an investigator's view. Settle this before the first alert. It's miserable to solve with a real person's name on the screen. Which leads to the fairness question. Underneath all of this is the criterion about the role or about the person. A role based criterion says. Anyone who holds this access gets this level of attention. It's consistent. You can explain it to anyone in that role. It doesn't depend on whether someone seems trustworthy. That's defensible. A person based criterion says, we've decided this individual deserves a closer look. Now you need evidence, a documented reason, and a different process altogether. It starts to look like suspicion. It should be treated as an investigation rather than a policy setting. Keep the two apart. Priority groups are for roles. If a name goes on the list because someone has a bad feeling, the program has stopped being a control and started being a grudge. So the shape is clear. Narrow criteria written down, tied to access with extra governance. Wherever the monitoring gets heavier. None of this should go live on day one, though not for priority users, not for anyone. Before you switch on enforcement, you need a way to learn what normal looks like and to be wrong cheaply. That's what a pilot is for. The pilot strategy starts small. Start quiet. Most programs fail in the first month, not because the design was wrong because they went live too wide. Someone switches on three policies for the whole company. By Friday, the queue holds four thousand alerts. Analysts open the first fifty. Find nothing and start closing the rest without reading. Somewhere in that pile sits one real event that nobody sees. So the first rule of a pilot is simple start small. Start quiet. Small means a limited group. Pick a few hundred people or fewer drawn from one or two departments. You understand. Use an administrative unit so the boundary is enforced by the product and not by good intentions. Choose a group where you can explain the behavior. If you don't know why the finance team shares files outside the company every week, you can't tell a real signal from a normal one. Quiet means test mode. Purview lets you run policies and watch what they would flag without pushing anything toward enforcement or into anyone's inbox. Alerts form analysts review them, but nobody is contacted. No case reaches HR, no employee finds out they were flagged for something that turned out to be a Tuesday afternoon that matters for the council to a pilot is something you can describe in the works agreement as a defined phase, with a start date and end date and a named group. Better than asking for permission to go everywhere and then finding out you were wrong. Now, before you switch anything on, write down what success looks like. Not after before. If you wait until the pilot ends, you'll judge it by whatever the numbers happen to say. Twelve alerts a day will feel fine or terrible, depending on your mood. So set the targets in advance with the steering group. How many alerts per analyst per day can the team actually review? What share of alerts should turn out to be worth a second look? How quickly should a high severity alert be read? What's the line where you say this policy is too loud and we change it before it spreads? Put the numbers on one page. Then the pilot has an exit condition. Nobody argues about whether it worked during the pilot. Three things need watching. First alert volume. How many per day per policy, per indicator. Volume tells you where the noise lives. If one indicator produces most of the alerts, that's your first tuning target. Second alert quality of the alerts your analysts read. How many were real concerns, how many were ordinary work and how many they couldn't decide? Have analysts tag each one even roughly? A simple label like worth a look or normal work gives you a rate. Without it, you're guessing. Third analyst time. This is the cost people forget. Each alert takes minutes, sometimes much longer. Multiply by the q and you get hours per week. If the pilot group of two hundred people already eats a day of one analyst's time, scaling to ten thousand isn't a configuration step. It's a staffing problem. Find that out now. While it's cheap together, those three numbers tell you whether the program can survive at full size. And while you watch them collect something else, a baseline. Before you enforce anything, you need to know what normal looks like in your company. How many files does a typical salesperson download in a week? How often do designers use USB drives? When does the finance team share externally and with whom the pilot produces that picture? Every alert and every dismissed alert is a data point about ordinary behavior. Without a baseline, every threshold is a guess. With one, you can say a spike here is rare, and a spike there happens every quarter. That's the difference between a program that finds patterns and one that finds people having a busy week. So the pilot isn't a delay. It's the part that makes the rest defensible. But here's what it will also expose. Usually within days, alerts are easy to generate. Deciding what to do with them is the hard part. Who reads the first one? Who decides whether it matters and what happens next. That workflow decides whether the program survives, and that's where we go next. The triage workflow, from alert to decision and alert is not a case. That's the first thing to hold on to. An alert is a flag. The engine saw a pattern and dropped it in a queue. A case is a decision a human made after looking. This deserves a closer look. Between those two sits. Triage and triage is where most of the fairness in this program gets won or lost. Here's how it flows. Alerts land in the queue, sorted by severity. A first pass reviewer opens one and asks a narrow question is there anything here worth a closer look? The answer is one of two things dismiss or confirm. If it's dismissed, the reviewer records why and the alert closes. If it's confirmed, the reviewer creates a case and the work moves to someone else. Notice how small that decision actually is. The first pass reviewer isn't judging a person. They're judging whether a pattern earns another pair of eyes. Which brings us to who does what. Because three different jobs get blurred together in most programs, and they shouldn't be. The first pass reviewer is an analyst. They work the queue, they see Pseudonymized identities and they make the dismiss or confirm call. They don't see more than they need. The investigator takes the case. They dig into the evidence. They can request a reveal of identity through the proper role, and they build the picture of what happened, but they don't decide what to do about it. And the decision on action sits with someone else again, usually HR or legal or a defined committee, depending on what the works agreement says. The person who finds the evidence is not the person who chooses the outcome. That separation is deliberate. It stops one person from being detective, judge and enforcer in the same afternoon. Now, what does a reviewer actually look at? Three tools carry most of the weight. The Activity Explorer shows the raw events behind the alert, which files were touched, which indicators fired in what order. It's the evidence list. The reviewer can filter it, sort it, and check whether the sequence the engine flagged really looks the way it claims. The user timeline puts those events on a calendar, and that matters more than it sounds. Because context lives in time. A burst of downloads looks alarming alone next to a quarter end deadline or a project handover. It looks like work. The timeline is where innocent explanations tend to show up first. 00:52:13 Speaker: The Content Explorer shows the files themselves, or at least what's known about them. Their sensitivity labels, their types, where they live. This answers the question of how much the activity actually mattered. Fifty. Downloads of public brochures and fifty downloads of the customer database are not the same event, even though the count is identical. Read together. Those three give you the shape, the timing, and the stakes. If anyone is missing, the call gets weaker. Then there's the clock. How fast should an alert be read? Faster than most teams plan for. A high severity alert that sits for two weeks can mean data that's already gone and a response that arrives after the damage. That's the safety argument for speed. But there's a fairness argument too, and it gets less attention. An alert that sits unreviewed is a cloud over someone's name, even if they never know. Worse, old alerts get read with less context because nobody remembers what the project was. Slow triage produces worse decisions about innocent people, so set service levels and write them down. A target for reading high severity alerts measured in hours or a day. A target for medium, a longer window for low. Measure them every week and show the numbers to the steering group. If the targets slip. That's a staffing problem to fix, not a number to hide a quick dismissal, recorded and explained, is a good outcome. It means the system worked. Someone looked and a normal person went back to being normal. But some alerts do get confirmed and when one does, the work changes character. A case opens and with it comes a new set of rules about who sees what, how notes are kept, and what the investigator may never assume. Case management and investigation. Discipline. A case is a file with someone's life in it. Treated that way from the first minute. Because the moment an alert becomes a case, the program stops dealing in patterns and starts dealing in a person. And every habit you build here either protects that person or exposes them. Start with the notes. Every case in purview has a place for notes, and the rule is simple if it matters, write it down at the time in the case what you looked at, what you found, what you ruled out, why you moved forward or stopped. Not a summary written three weeks later from memory, a running record. Evidence goes the same way. Attach it to the case. The activity events, the timeline views. The content details. Don't copy screenshots into a private folder or paste excerpts into email. The moment evidence lives outside the case, it lives outside the audit trail, and then nobody can prove who saw it or what happened to it afterwards. And that trail is the real protection. Every case action is logged. Who opened it? Who added a note? Who requested a reveal? Who changed the status? It works in two directions. If the case ends in a formal process and the employee challenges it, you can show exactly how the evidence was handled. And if someone pokes around where they had no reason to. The record shows that too. Now, who gets to open the case at all? Fewer people than you think. Case access is need to know and in purview, you can control it by role and by case. The investigator assigned to it may be a supervisor, not the whole analyst team, and certainly not anyone who just heard something was going on. Curiosity is not a business reason. Write that into the agreement if you have to. For sensitive cases, add a second pair of eyes. The four eyes principle before an identity is revealed, before a case is escalated. Before anything leaves the investigation team, a second qualified person reviews the reasoning and signs off. Think of cases involving priority users, senior staff, or anyone in HR or legal. One person can make a mistake or carry a bias they don't know about. Two people have to agree on the story. It also protects the investigator. A decision that two people approved is much harder to attack later as personal. Some cases don't stay inside the program, and when they leave, the handoff needs to be deliberate. If the evidence points to a policy breach by an employee, the case goes to HR because they own the people process. If it touches contracts, privileged material or possible legal claims. Legal needs to be in the room before anyone acts, and if the activity looks like an active attack, say a compromised account, moving data out. Right now it goes to security incident response because that's a different clock entirely. Agree these paths in advance. Who gets told in what order and what they receive. A handoff should carry the facts and the evidence, not the investigator's guess about motive. And it should leave a record so you can show later who knew what and when. Now, the hardest discipline, the one the tooling can't give you avoid confirmation bias. Here's how it happens. An alert says high severity. The investigator opens the case already half convinced. Every event on the timeline now reads as support. The late night download becomes sneaky, the personal email becomes suspicious. Nothing has changed except the lens, so reverse the order. Look for the innocent explanation. First, was there a project deadline, a handover to a new team, a sanctioned workflow that the engine doesn't know about? Did the person's manager ask for exactly this? Check the boring answers before you build the dramatic one. A useful habit write down the best innocent explanation in the case notes before you write anything else, then test it. If the evidence kills it. Good. You've earned the next step. If it survives, you may have just saved a colleague from a very bad month and keep one fact in view. The engine saw a pattern. It can't see intent. Only a careful human can weigh that, and only if they're willing to be wrong, because the case doesn't end with evidence. It ends with a person on the receiving end of a decision. And what that decision looks like is the next question. Outcomes, coaching escalation and proportional response. Guess a number before you look at your own data of all the cases that reach a conclusion, how many end with someone being disciplined? Fewer than most executives expect way fewer. Because the response to a confirmed case isn't one decision, it's a ladder, and each rung carries more weight than the one before it. The first rung is no action. The investigator looked, tested the innocent explanation, and it held the person did their job. The pattern had a reason. The case closes with a note that says so. That's not a failure of the program. That's the program working. The second rung is a nudge. The activity was real and slightly off, but not harmful. Someone shared a file with a client through a personal link instead of the approved route. A short, friendly message explains the right way. That's the end of it. The third rung is a manager conversation. The pattern repeats or the data was more sensitive than the person realized. Now the manager steps in with facts from the case, but not the case itself. They talk about how work should flow, what the approved path is, and what to ask before moving something outside the company. The fourth rung is a formal process. HR and legal take over. There's evidence of deliberate misuse or a clear breach of contract or policy. The employee gets the procedures, the law and the work agreement. Guarantee hearings, representation, the right to respond. Most cases never reach that last rung. In many programs, the large majority end in education. That's what the evidence supports. Because most risky activity isn't malicious. It's someone in a hurry working around a clumsy tool or never told the rule existed. So build the ladder before you need it. Write down which findings, map to which rung. Who decides and who may skip a rung and why. Skipping upwards should need a second approver. Skipping downward. Should need a note. Put the ladder in the work agreement so nobody invents a harsher response on a bad Thursday. Now, a pure detective model has a flaw. It only acts after the data has moved. Every case on that ladder is, by definition something that already happened. That's where data loss prevention comes in. DLP is the preventive layer. It's the policy that stops a labelled file from going to an outside address, or warns someone before they paste it somewhere risky. Insider risk management watches patterns over time. DLP acts in the moment at the edge of a single action used together, they cover different parts of the same problem. The link is practical when cases keep showing the same behaviour, that's a signal for a control. If five nudges this quarter were about the same unapproved sharing route, don't write a sixth nudge. Block that route or put a warning in front of it. Fix the cause instead of the symptom. Cases become the evidence that tells you where a preventive rule is missing. One more rule and teams skip it constantly. Every case needs a recorded outcome not resolved. A real entry which rung of the ladder? Who decided on what date. The reason in a sentence or two. A case that simply closes leaves a hole in your data. You can't measure how many alerts end in education if nobody wrote down that they did, you can't show the council that most cases were proportionate. And if an employee later asks what happened, you can't answer. Recorded outcomes also feed the tuning work. If a policy produces dozens of confirmed cases that all end in no action, the policy is too loud. If it produces few cases that all end in a formal process, you may have a very tight policy or a very blind one. The outcomes tell you which. So close every loop in writing, every time. But think about where we've been. Everything so far the alert, the triage, the case, even the nudge happens after someone has already done the thing. The better question is whether you can catch the risky moment while the person is still making the choice before any alert exists at all. Adaptive protection and policy nudges most security controls are static. You write a rule that applies to everyone, and it stays that way until somebody changes it. Adaptive protection breaks that pattern. Here's how it works. Inside a risk management already scores people by their activity. Adaptive protection takes that risk level elevated, moderate or minor, and passes it to data loss prevention. DLP then changes how strict it is for that person. Automatically think about two employees touching the same file. One has acquired history. DLP lets the action through, maybe with a light reminder, the other has just triggered a pattern that looks like data theft for that person. The same action gets blocked or needs a written reason first. Same rule on paper. Different outcome because the context is different. That's the shift from fixed rules to context. It also means most people never feel the heavy controls at all. They only apply to the small group whose behavior moved the score. Risk levels also age out. When the activity calms down, the level drops and the stricter treatment goes away on its own. Nobody has to remember to undo it, but you still decide what each level does. Adaptive protection doesn't choose your response. You set it in your DLP policies, and you should agree those settings with the same people who signed off on the rest of the program. Now, the soft end of the toolbox notifications. DLP can show a policy tip, right where someone is working a short banner in outlook, a message in a file, a pop up on the device. You write the text build notification templates so the wording stays consistent and can be reviewed once instead of rewritten for every policy. Pay attention to the writing because it's the whole point. A tip that says policy violation detected feels like an accusation. A tip that says this file is labeled confidential. Sharing it outside the company needs approval. Here's how to ask. Feels like a colleague pointing at the right door. Say what happened, say why and say what to do next. Keep it short enough to read in five seconds. Some policies let people override with a reason. That's useful because it records a real explanation and lets honest work continue. It also gives you data if everyone overrides the same tip for the same reason, the rule is wrong, not the people. So when do you nudge and when do you block nudge? When the harm is small and the person probably doesn't know better. A confidential file going to a known partner. A shared link with broader access than needed. The cost of a mistake is low and a prompt fixes most of it. Block when the data is the kind you can't take back. Regulated records. Source code. Customer databases leaving for a personal account. One careless click does permanent damage, so friction should win over convenience block with a way out. Tell people who to contact and how fast they'll hear back. A hard stop with no path forward. Just train staff to find a workaround and. Workarounds are exactly what this program is trying to catch. Think about why this matters for trust. Retroactive discipline says we watched you. We found it, and now we're talking. Preventive friction says we noticed you were about to make a mistake and we stepped in before it counted. The first feels like being caught. The second feels like being helped. People forgive a speed bump much faster than they forgive a file in their HR record. The guardrails teach. Every tip is a small lesson delivered at the exact moment it applies, which beats any annual training slide. But there's a catch. Employees only experience those prompts as help if they know why they exist. A banner that appears out of nowhere from a program nobody announced looks a lot like the thing everyone feared, so the technical work isn't finished. The next part is the one most programs skip, and it's telling people, communicating to staff what to say before you switch it on. Here's a question when did your staff find out the program exists? If the honest answer is when the first alert fired, you've already lost something. Not legally maybe, but in the way that counts. So treat transparency as a control, not a courtesy, a control the same as pseudonymisation or role separation. It limits how the program can be misread, and it limits how the program can drift. Once you've told five thousand people what you watch and what you don't, you've also told yourself what you're not allowed to start doing next year. Announce it before go live. Not during the pilot's quiet phase and not after the first incident before. Say what the program is, say how far it reaches and say where it stops. Now, what exactly do you tell people for things every time? What is monitored? Be specific. File activity in Microsoft three hundred sixty five copies to USB drives. Printing, sharing outside the company. Name the categories because your activity sounds like everything and nobody should be left to imagine the worst version. What isn't? This is the part staff listened for. The program looks at actions, not message content. It doesn't read your emails. It doesn't listen to calls. It doesn't track your location, and it doesn't score you on how productive you are. If any of that is true in your tenant, say it plainly. If one of those isn't true, don't say it and go fix the gap before you speak. Who sees it. Not authorized personnel describe the roles. Analysts. See Pseudonymized alerts. A small investigation team can reveal an identity with a recorded reason. HR and legal get involved only if a case reaches them. People relax a little when they can picture who is actually looking and how long. How long alert data stays, how long case data stays, and what happens when it's deleted. A number in months beats any reassuring sentence. Then the format because the best facts buried in a legal notice don't land. Write it like a person would say it across a desk. A good structure runs in five short beats. Why we're doing this. What we look at, what we don't, who sees it, and for how long. What you can do if you have a question or a concern. Take the first beat. We hold customer data, contracts and designs that would cause real harm if they left the company by mistake or on purpose. This program helps us spot unusual patterns early so we can fix problems before they grow. No threat in that. No jargon either. Then the last beat matters. Most give a real contact, a real mailbox, and a promise of a real answer within a set number of days. A program that says ask us anything and then goes silent has turned an open door into a painted wall. Keep the whole message short enough to read in two minutes. Leave the legal language to the works agreement and the privacy notice and link to both. Staff don't need the clause numbers. They need to know they were told straight. Now where do you say it? One place isn't enough. People miss emails, skip intranet pages and forget all hands announcements within a week. Use the all hands for the headline. A few sentences from a leader. Ideally the same leader who signed off on the charter with the Works Council visible alongside that pairing carries weight. It says this wasn't done to you. It was agreed with your representatives. Put the full explanation on the intranet in a page people can find again and that you keep current date it. When something changes, update the page and note what changed. Add it to onboarding. New joiners should hear this in their first week from a person, not just a PDF. Anything you tell them later will feel like a surprise and build it into your policy updates. When the acceptable use policy changes, the program description changes with it. If those two documents drift apart, staff will notice and they'll assume the gap is on purpose. But notice something about all of these channels they broadcast. They reach everyone once in the same way, and then they go quiet. The questions don't go quiet. They show up a week later in a corridor in a one to one over a coffee. Hey, is this thing watching me? And the person who gets that question isn't the communications team. It's a manager standing there with no script. That's where the message either holds or falls apart. Training managers and HR for hard conversations. Think about what a manager knows on the day the program goes live. Probably what the all hands said. Maybe a bit more. They don't know which indicators are on or who reads the alerts, and the questions that land on their desk will be exactly the ones that need those answers. So prepare them before the announcement, not after a short briefing, thirty minutes at most with the charter summary, the five beat message, and a one page set of answers. Then give them a number to call when they're stuck. A manager who can say, let me check and come back to you is fine. A manager who guesses is a problem. Let's take the two questions that will come first. Are you watching me? A good answer is short and true. Something like, no, nobody's watching you personally. The program looks for unusual patterns in file activity, and it only looks at what the company announced. Alerts show a code instead of a name. Here's the page that explains it, and here's who to ask if you want more. Notice what that answer does. It says what the program is. It points to a source. It offers a next step, and it doesn't promise anything the program can't back up. If your setup has an exception, a priority group, say, or a departing user trigger, the script needs to cover it honestly. A reassurance that turns out to be false is worse than no reassurance at all. The second one is harder. Why was I flagged? Now the manager is talking to someone who may have been through a case. And here's the rule the manager usually doesn't know and shouldn't. Alerts and case details stay inside the investigation team. So the answer is I don't have access to that information, and I won't guess. If you've been contacted about something, you have the right to understand it. Let me connect you to HR who can tell you what the process is. That sounds cold on paper, but it's the honest answer and it protects the person. Asking. A manager who improvises tends to say, I think it was that USB thing. And now a half remembered guess is circulating as fact, which leads to what managers must never do. Three things never speculate. Not in a one to one. Not at the coffee machine, not in a message to a peer I heard Sam was flagged is a sentence that can end a career, even if it's wrong, and especially if it's wrong. Never disclose if a manager learns that a case exists. Perhaps because HR needs input, that knowledge stays with them. Not with the team, not with other managers, not with the person's friends. Put a confidentiality duty in writing and make sure managers sign it and never retaliate. A flag isn't a finding. Someone who is flagged and cleared must see no change in how they're treated. No cooler tone, no missed project, no quiet note in a review. If an employee later believes that happened, they need a way to say so, and the manager needs to know that behavior will be investigated like any other breach. So that's the other half of the training. Where do worried people go? Build the paths before the first complaint, an employee with a concern about the program or about how a case was handled should have at least two routes, one inside HR to a named role and one outside the reporting line, usually the data protection officer or the works counsel, because some people won't raise a concern with the same function that handled their case. 01:09:31 Speaker: Write down how fast each route answers. Five working days is reasonable for a first reply. Log every concern and report counts and themes to the steering group. If three people ask the same question in a month, your communication has a gap and that's worth knowing. Train HR for the same moments with more depth. They'll hear the difficult conversations. Give them a case handling guide, a way to involve legal early, and a clear line on what they can share with the employee and when. But even with every script in place, there's a problem none of this touches the best conversation in the world falls apart if the person says, I only copied a file for a client, and the alert behind it was never worth raising. Communication can't fix bad signal, only tuning can tuning noise. Why alert fatigue kills trust. Every false positive costs twice the first cost is easy to see. An analyst opens the alert, reads the timeline, checks the files, and finds a person doing their job. That's fifteen minutes gone. Multiply it by a few hundred alerts a week and you've burned a full salary on reading ordinary work. The second cost is slower and it's worse, analysts learn. After the fortieth empty alert in a row, they stop reading closely, they skim, they dismiss, and they trust the cue less each day. Then the one real event arrives, sitting between two harmless ones, and it gets the same half second look as everything around it. And there's a third party in all this. The employee, even when nobody tells them a false positive, still means someone pulled their activity, studied their week, and decided whether they looked suspicious. When it does reach them through a clumsy manager question or a nudge, that makes no sense. The damage is real. They hear you are watched and the watching was wrong. That's a hard thing to take back. So noise isn't a tuning detail. It's the thing that quietly turns a fair program into an unfair one. Now, the first two weeks of alerts, how should you read them? Not as a verdict on your people, as a diagnostic of your setup. Think about what a flood of alerts in week one actually tells you. It almost never tells you that your company is full of thieves. It tells you that your thresholds don't match how your business really works, and that your indicators are catching normal habits. If forty percent of the alerts come from one department, you haven't found forty percent of a department's worth of bad behavior. You found a workflow the engine doesn't understand. So sort the first batch before you judge any of it. Group alerts by indicator, by team and by the file locations involved, look for clusters. A cluster means a cause, and a cause means a fix. A scattered handful of odd alerts across many teams is a different picture, and it's the one worth reading closely. Then you act on what the clusters show you. There are three levers. Adjust thresholds. If an indicator fires on ordinary volumes, raise the line or switch it to compare each person against their own history. Then watch the next week and see whether the cluster shrinks. Exclude sanctioned workflows. Some activity is approved, expected, and repeated. A finance team sending reports to the auditor. A design team pushing files to a print vendor. Tell the policy about it through domain exclusions, trusted locations or scoped groups. So approved work stops looking like leakage and write down who approved each exclusion because an exclusion is also a hole and holes need owners. Trim indicators. If an indicator produces mostly noise and almost no confirmed cases, turn it off for that policy. Fewer indicators with clear purpose be the full set that nobody can explain. You can always switch one back on, but you can't unread a thousand pointless alerts. Now, where does the noise usually come from? Four sources show up again and again. Bulk sync clients OneDrive sync or a third party tool copying thousands of files to a laptop in one go to the engine that looks like a mass download to the person. It was a Tuesday and a new device. Backups scheduled jobs that read huge amounts of data on a fixed rhythm. They're predictable, they're boring, and they trip volume indicators every time unless you exclude them. Migrations, a mailbox move, a SharePoint, restructure a file, share, cleanup. The activity is enormous and entirely legitimate. If a migration runs during your pilot, your numbers will lie to you for weeks and sanctioned file shares, partner portals, shared project spaces with outside suppliers agency folders. The sharing is real and so is the business need. Each of those is a pattern you can name, scope out and document. None of them should ever reach a human investigator as a suspicious person. But notice what we've just done. We've fixed noise by hand in a burst during a pilot that works. Once the business keeps changing, though, new tools arrive, teams reorganize, projects start and end, and last months clean queue drifts back toward chaos without anyone touching a setting. So tuning can't be a project you finish. It needs a method you can repeat on a schedule with numbers and a record of every change, a tuning cadence, and metrics that matter. Set a rhythm and put it in the calendar in the first weeks. Review every week. Not as a favor to yourself, but because the setup is still wrong in ways you can't see yet. Thresholds are guesses, exclusions are missing, and the cue is teaching you something new every few days a weekly session, one hour with the analysts and one person from the privacy side keeps those lessons from piling up. Then, once the numbers settle, move to monthly. How do you know they've settled? Alert volume stops swinging. The confirmed rate holds steady for a few cycles, and the analysts stop saying that's new every Monday. At that point, a monthly review is enough with a quick check. After any big business change like a merger, a migration, or a new tool rollout. But don't drop the rhythm entirely. Programs that stop reviewing don't stay stable. They drift. Now, what do you actually look at for numbers carry most of the weight. Alert volume. How many alerts per policy? Per indicator per week. This is your noise map. A sudden jump almost always has a cause outside the people. A new sync client, a project launch, a change in the HR feed. A slow climb over months usually means a threshold that no longer fits the business. Confirmed rate of the alerts, analysts read. What share earned a case? This one tells you whether the policy is worth its cost. A rate near zero means you're paying analysts to read ordinary work. A rate that's very high deserves a different kind of suspicion. Either the policy is tight and well aimed, or your analysts have started confirming things to justify the queue. Look at both possibilities. Time to triage. How long from alert creation to a first decision split by severity. This is where the service levels we set earlier get tested. If high severity alerts wait three days, that's not a data point to note and move past. It's a staffing or workflow problem with someone's name on it and cases by outcome. How many ended in no action? A nudge, a manager conversation, a formal process. This is the proportionality number. It shows whether the ladder works the way the agreement says it should. If formal processes start climbing quarter after quarter, ask why before anyone celebrates how effective the program is for numbers one page. Resist the urge to build a dashboard with forty tiles because nobody reads those and the ones they do read get quoted out of context. Who sees that page? More people than the analysts reporting to the Works Council and the steering group isn't a one time handover at go live. It's an ongoing duty and it should be written that way in the works agreement. A quarterly report works for most organisations. Aggregate figures only volumes, rates, outcomes, response times and a short list of what changed and why. No names. No case details. Nothing that could identify a person. That report does two jobs. It lets the council confirm the programme still looks like the one they agreed to, and it gives the steering group a reason to ask a hard question while it's still cheap to answer. If the council first hears about a change from an employee in the corridor, the damage is already done and it won't matter how good the reasoning was. Which brings us to the record that holds all of this together. The policy change log. Every tweak goes in a threshold raised from one value to another. An indicator switched off, a domain added to an exclusion list. A new group added to a policy scope for each entry for fields were changed when? Who approved it and why? One sentence for the why is enough as long as it's honest. Race download threshold for design team after cluster of sixty alerts traced to sanctioned print vendor workflow is a good entry. Tuning is not the log matters for three reasons. It makes tuning repeatable because the next person can see what was tried and what happened. It protects you in an audit or a dispute, because you can show that every change had a reason and it exposes drift. If you read the log after a year and see fifteen exclusions, but no one can say who asked for them, you found a problem worth fixing. A log also makes quiet changes impossible to defend. That sounds like a burden, but it's a gift. Now suppose you've done all of it. The weekly rhythm, the four numbers, the council reports, the log. The program is configured well, the noise is down and the queue looks healthy. That's still not where programs usually break. The tool rarely fails. What fails is everything around it. Slowly, as the people running it change, ask for more and start to treat the output as something it was never meant to be. Failure modes how good programs go. Bad programs rarely fail on day one. They fail in year two. Quietly, every individual step looking reasonable. Take the first one scope creep into performance management. It starts with a fair question from a department head. You already see who's active in the files. Can we use that to see who's actually working? Sounds practical. The data exists. The tool is paid for. The request comes from someone senior. But look at what changed. The program was agreed for one purpose. Spotting risky handling of sensitive data. Now it's being asked to rank people by output. Different question. Different harm. Different legal basis. Purpose limitation doesn't bend just because the dashboard is already open. And once staff learn that file activity ended up in a review conversation, they won't separate the two users. They'll assume the whole program was always about that. So the answer to that request has to be written down before anyone asks. Not a case by case judgment call. A line in the charter repeated in the works agreement. This data is never used for performance, attendance, or productivity, and a named person who says no with the authority to say it. The second failure is access creep. Nobody grants one hundred permissions at once. It's one extra reader for a sensitive case because a director wants to stay informed. Then an analyst role for a security engineer who'd find it useful, then a manager who just needs a quick look at one alert. Each request is small and has a story behind it, and each one gets approved in about a minute. Add it up after eighteen months and the model you showed the works Council. A handful of people with narrow roles no longer exists. Thirty people can see things now and nobody can say why. Most of them still can. The fix is dull and it works. Every role assignment gets an owner, a reason, and an expiry date. Anyone asking for visibility answers one question what decision can't you make without it? And once a quarter, the list gets compared against the one in the agreement. If they don't match, one of them is wrong and it had better not be the agreement. Third, silent policy changes. This one does the most damage and it rarely looks like wrongdoing. An analyst turns on a new indicator because it seemed sensible. Someone adds a group to a policy scope. During a reorganization, a threshold drops because the queue looked too quiet. Every change is made in good faith by someone competent, but the Works Council agreed to a specific setup. If the live configuration differs from what they signed, you're operating outside the agreement, even if no one meant to. And when it surfaces, usually through an employee's complaint, the issue won't be the indicator. It'll be that you change the rules and didn't say so. Trust takes a long time to build and about one email to break. So the change log we talked about isn't only a tuning tool, it's the thing that stops silent, changes from staying silent. Define which changes need council notice before they happen and which need only a line in the quarterly report. Then hold that line even when the change feels minor. The fourth failure sits with the people reading the output, treating the tools score as a verdict. A risk score is a ranking of patterns. It says this activity resembles the activity of people who later caused harm. It doesn't say this person did anything wrong, but numbers carry a strange authority. A high score in a case file starts to read like a finding, and by the time it reaches a meeting, elevated risk has become suspect. Watch for it in the language. When someone says the system flagged him as a leaker. The pattern has been mistaken for the person. The cure is to keep the score out of the decision record entirely. Cases should rest on evidence. A human reviewed the events, the context, the innocent explanations that were tested. If the only reason for an action is the number. The action doesn't have a reason for failures and notice what they share. None needs a bad actor. They need time, convenience, and nobody whose job is to notice. So the question isn't how to stop good people from making mistakes. It's what structure catches those mistakes before an employee, an auditor, or a court does. That's what governance is for, and it's what keeps a program credible long after the people who built it have moved on. Governance, audit and sustaining trust over time. Who watches the people who watch everyone else? If the answer is nobody, you haven't built a risk program. You've built a very quiet surveillance office. So start with the auditors in purview. The people running Insider risk Management leave their own trail. Every alert opened, every case viewed, every identity reveal, every note added. That log exists. And the question is whether anyone ever reads it. Make someone read it. Not the analysts themselves and not their manager. Internal audit or the privacy officer on a fixed schedule. Once a quarter is a fair rhythm, they pull the list of who looked at what and they check it against one test. Did this person have a reason? A reason means a case, an alert in their queue, or a documented request. Looking at a colleague's file because you were curious is not a reason. Looking at your neighbor's case because you heard a rumor is not a reason either. And when the review finds one, the response needs to be written down in advance, not invented on the day access removed, HR informed the counsel told in the next report. Here's the part that surprises people. Announce this check to the program staff themselves. Tell the analysts on day one that their activity is reviewed to. It sounds harsh, but it works as protection. The analyst who knows the trail exists never has to wonder whether a temptation is worth it. Now the documents, a Dpia written at launch, describes the program at launch. A works agreement signed at launch covers the tools and the people at launch. Neither stays true on its own, so set an annual review with a date in the calendar and an owner. Not when we get around to it. The privacy officer takes the live configuration, the current role list, and the last four quarterly reports and asks one question does the program we run still match the program we described? Look for drift new indicators that weren't in the original assessment. A bigger group in scope. A new Microsoft feature that changes what data flows, where purview ships new capabilities often, and some of them quietly widen what the product can see. Each one deserves a check against the DPI before anyone switches it on, then take the findings to the council. If something changed, amend the agreement properly. If nothing changed, sign a short note saying so. That note is worth having. It proves the review happened, and it shows the council that checking isn't something that only happens when there's a problem. Next, the employee in front of you. Sooner or later, someone asks a direct question what data do you hold about me in this program under GDPR? That's a legitimate request and it needs a real process, not an awkward hallway conversation. Decide who receives it. Usually, the privacy officer decide who gathers the data with a recorded reason for each lookup, and decide what gets shared and what stays back because some material may be protected while an investigation is still open, Council should set those limits before the first request arrives, not during it. Then the appeal. If a case led to an outcome that the person disputes, they need somewhere to go. A review by someone who wasn't involved, a chance to see the evidence used against them, to respond and to be accompanied by a representative. Put a deadline on each step and track the numbers. If appeals rarely succeed, ask whether that's because decisions are sound or because the process is hard to use. Last, the program's own people staff in these roles change jobs, leave and get promoted, and the positions they hold don't follow them out the door unless somebody removes them. So tie role removal to the onboarding checklist the same day, no exceptions, and add recertification every six months. Each role holder confirms they still need the access and their line manager confirms it too. If nobody can explain why someone still has the investigator role, that's your answer. Remove it and restore it only on a documented request. Notice how far we've come from the tool roles, reviews, appeals, and recertification. None of it is a purview setting. It's all structure around the settings, and it's what separates a program people tolerate from one they can trust. Now let's put the whole model in one place. The new model context led. Proportional. Transparent. Let's put the two models next to each other. The old model starts with a person. Monitor everyone. Collect everything. Investigate later when something looks wrong. The structure is simple wide collection, narrow accountability. Plenty of data goes in, very little explanation comes out, and nobody outside the security team knows the rules. The new model starts with context. Monitor a defined set of risky actions. Switch on stricter attention only when something justifies it, and show your work to the people affected. The structure flips. Collection is narrow. Accountability is wide. A trigger event starts the. Watching a role model limits. Who sees names. A ladder limits what happens next, and a report to the council shows what the program actually did. Same product, different assumption underneath it. So what do you decide before go live? Five things. One. The purpose in writing. What the program is for, what it will never be used for. Performance reviews go on the never list. A named person holds the power to say no. Two. The legal footing a dpia that describes the real configuration. A lawful basis someone has actually tested. Not assumed. Three. The works. Agreement. Scope. Retention. Access. Escalation. Appeal signed before the first alert with a rule about which changes need. Notice. Four. The role model, who reads alerts, who investigates, who decides who audits them with owners reasons and expiry dates. Five. The message what staff hear from whom? Where they take a question. Managers briefed before the announcement, not after. If any of those five is missing, don't switch it on. A gap you leave open on day one will be filled by someone's improvisation on day ninety. Now the order. It matters more than most teams admit legal first because it sets the limits, then the council because they need to shape the design, not approve it afterwards. Then design templates, indicators, pseudonymization scoping, then the pilot, small and quiet, then communication before the wider rollout, then tuning on a schedule and review every year with the agreement on the table. Teams get this wrong in a predictable way. They start at design because that's where the toggles are. It feels like progress, but every setting you choose before the legal and council work is a setting you may have to undo in front of the very people whose trust you need. And that brings us to the last diagnosis. Everything in this program can be configured thresholds. Roles. retention scope. Even the wording of a nudge, there's a setting for almost all of it. Trust isn't one of them. Nobody can toggle it on at Go live. It builds from the sum of small, checkable things. A message that was true. An alert that was fair. A case that ended in a conversation instead of a file. A change that was reported before anyone had to ask. Staff. Don't judge the program by its design documents. They judge it by what happens to the colleague who got flagged build for that person. The rest follows. That's the model. Now let's wrap this up. Outro. Review. LinkedIn and next topics. If this helped you think about building a fairer program, leave a review. It helps more people find this podcast and it tells me which topics are worth the time. If you want to keep the conversation going. Connect with me on LinkedIn. I read the messages. Tell me what you'd like covered next. Which part of Purview or Microsoft three hundred sixty five keeps getting stuck in your organization? That's usually the next episode. One more word on migrations. Stellar Migrator for exchange is worth a look. If mailbox moves are on your roadmap. Clean data gives you cleaner signals later. And remember this the alert queue is never the real risk. The missing conversation is.