SharePoint Information Architecture That Survives Copilot

M365 FM - SharePoint Information Architecture That Survives Copilot 00:00:00 Speaker: You built SharePoint for people who browse. Copilot doesn't browse. It asks one question what can this person see and what matches the prompt? That's the whole test. Nothing about your navigation, your site names, or the folder structure you spent three years arguing about. So today we're covering the structure that survives that question sites, hubs, permissions, labels, metadata lifecycle, and the cleanup that holds it all together. If your tenant is about to be questioned by AI, subscribe to the M365 FM podcast. Now, before the next episode on what copilot actually finds, but before the architecture, the sponsor sponsor segment. Stellar Migrator for exchange, let's talk about where your content comes from. Every tenant has a history. Somebody moved mail from an old on premises server or from another platform, or from a company you acquired two years ago. And whatever came across in that move is now part of your information architecture, whether you planned it or not. That includes mail, it includes attachments, and it includes every contract, every spreadsheet, every. Please keep this confidential thread that copilot will later index and retrieve. Here's what typically happens. The migration gets treated as a logistics job. Move the mailboxes, hit the deadline, fix the details later, and the details turn out to be the architecture. Duplicate items, broken folder structures, mailboxes landing in the wrong place, shared data without a clear owner, a messy migration doesn't stay in the past. It becomes the mess you now have to govern. So a clean migration is the first act of information architecture. It's the moment you decide what enters the tenant and in what shape. This is where stellar migrator for exchange fits. It's a migration tool that moves mailboxes from sources like on premises exchange into exchange online with control over what gets moved and how it lands. That's the point worth taking away. Before you design a single site, look at what you're pouring into. The tenant copilot will read all of it. Now back to the model that's failing the old model navigation was the security boundary. Your intranet wasn't designed for how people work today. It was designed for structure pages, navigation hierarchies. You had a home page under it, department sites, under those libraries, under those folders. And somewhere at the bottom of that tree, the document. someone needed. The whole system was built on one idea. A person starts at the top and walks down. And that design carried a hidden assumption that people only find what they go looking for. Think about what that means. A file sits in a folder four levels deep inside a site called Finance Working Group twenty nineteen. Nobody links to it. Nobody searches for it because nobody knows it exists. Technically, the permissions on that site are wide open. Everyone in the company can read it, but in practice, nobody ever does. That worked for years. Not because the permissions were right, because the path was long. The effort to find something acted as a filter. You needed to know the site name, or someone had to send you the link, or you had to click through six menus and guess correctly. In most organizations, this is how the real access model worked. The permissions said one thing, the navigation said another, and the navigation was doing most of the protecting. So poor permissions survived sites created as public because it was the default. A group called everyone except external users added to a library during a project Rush a sharing link set to the whole company because it was faster than picking names. Each one was a small decision. Each one was technically a gap, and each one stayed harmless because the content behind it stayed hidden by effort. That's obscurity. And it was acting as a control. But nobody wrote it down. It never appeared in a policy document. It never showed up in an audit checklist, and no one assigned it an owner. Everybody simply relied on it. The way you rely on a door that's always been stuck, you never decided it was locked. It just never opened. That's the model. A security boundary made of friction and friction is exactly the thing copilot removes in one move. What actually changed context replaces navigation. Work doesn't start with a site anymore. It starts with a prompt. Someone sits in a meeting. A customer asks about a renewal clause. They open copilot and type one sentence. They don't think about which site holds the contract or which library, or which folder they don't know. And they shouldn't have to, because the whole point of the tool is that they skip that step. So the starting point moved. It used to be, where does this live now? It's what do I need? That's context. And here's what copilot does with that context. It doesn't open a site. It reaches across all of them at once. SharePoint libraries, OneDrive files, teams, chats, mail threads, meeting transcripts. One request, one pass. The finance site you forgot about sits right next to the project chat from last Tuesday, and both get considered in the same breath. Your structure used to separate these things. Different sites, different tools, different corners of the tenant. Copilot treats those corners as one pool that changes what you're actually protecting. The old unit of access was the page or the file or the site. You thought in places who can enter this place, who can open that document? But the new unit isn't a place at all. It's the answer. Think about it. A user asks a question. Copilot pulls a few fragments from a few sources and blends them into one response. The user never sees the folder path. They never see the site name. They see a sentence, maybe with a citation, and that sentence might contain a piece of a document the user never knew existed. So access isn't. Can you open this file anymore? It's. Can this file's content end up inside someone's answer? Those are different questions. And most tenants were only built to answer the first one. Now let's compare the two models directly, because the difference is structural. Browsing a hierarchy works like walking through a building. You pick a floor, then a hallway, then a door. Every step costs effort, and every step narrows the options. You only ever see the rooms you walk into. Retrieving from an index works like this. Everything you're allowed to read gets flattened into one searchable surface. No floors, no hallways. The question goes in and the closest matches come out ranked by how well they fit. The path doesn't matter. Distance doesn't matter. Only two things matter. Do you have permission and does the content match? So effort stopped being a filter. A file four levels deep is exactly as close to the prompt as a file on the home page. That's the shift, and it exposes something. Most organizations didn't build their tenant for retrieval. They built it for browsing. Their structure assumes a person will walk a path, make choices along the way, and arrive with some sense of context about what they are looking at. Copilot doesn't walk a path. It arrives with the answer already assembled. So here's the name for what's slowing everyone down. I call it the model. The model is the structural assumption underneath your tenant. It says content is organized by place. Access is controlled by place, and people reach content by moving through places. Every decision you made about sites, folders, and permissions sits on top of it. And it isn't wrong because the tools are bad. It's wrong because the world around it changed. Retrieval doesn't care about place. That's why teams keep adding training banners and warnings, and the problems keep surfacing anyway. They're treating a structural flaw like a behavior problem. So to fix the model, you first need to see what replaced it. You need to understand how copilot actually reads your tenant, what it pulls, what it filters, and in what order. How copilot reads your tenant graph index permissions. Start with where the content lives. Everything in Microsoft three. Sixty five sits on top of one layer Microsoft Graph files. Mail chats, calendar entries, meeting transcripts. Graph connects those pieces and describes them. Copilot builds on that layer on top of graph. There's a semantic index, not a keyword list. It maps meaning someone asks about staff leave rules, and the index matches a document called Time Off Policy. It understands those two ideas sit close together. The words don't have to match. The meaning does. So your tenant becomes a map of concepts. Every document, every message, every transcript placed by what it's about. Now, the order of events matters. This is where most people get it wrong. Copilot does not read your whole tenant and then decide what to show. It works in a sequence three steps. First the prompt. The user types a question. Copilot reads it and works out what's being asked. Second retrieval. Before any answer gets written, copilot searches the index for content that fits the question. Here's the part that carries the weight. That search is scoped to what this specific user can already access, not what exists, not what's relevant in general, what this person is allowed to read. Third, the response. Only now does the language model write anything. It takes the retrieved fragments and builds an answer from them. Prompt retrieval response notice where permissions sit there applied at the retrieval step before the model writes a single word, the model never sees content the user can't reach. That's how it was designed, and it holds up, which leads to a point that gets misunderstood constantly. Copilot doesn't bypass permissions. It respects them exactly as they're set. If a document is locked down to five people, the sixth person's copilot can't pull it. The control works. But here's what that really means. Copilot also respects the bad permissions, the ones nobody meant to set the company wide link. The open Group the library shared widely during a rushed project in twenty twenty one. Every one of those is a valid grant, and copilot treats it like any other, so nothing is broken in the tool. What's gone is the friction before a wrong permission only mattered if somebody found the file. Finding it took effort. So most wrong permissions never got used. Now the search does that work in under a second? The permission was always there. The cost of exploiting it just dropped to zero. That's the real change. Copilot doesn't open new doors. It walks through every door that was already open. And it does it on behalf of anyone who asks. Now let's look at the other half of the problem. It's easy to miss. There's a word you'll hear in this space. Grounding. It means the answer is built from retrieved content, not from the model's general knowledge. The response is anchored to your documents. That's good. It's what makes copilot useful for work. It can tell you what your own refund policy says, instead of guessing what a refund policy usually says. But grounding has a limit. The limit is simple. An answer is only as correct as the content it retrieved. If the index returns the current policy, the answer is right. If it returns last year's draft, the answer is wrong, and it sounds just as confident the model can't tell the difference. It doesn't know which version your legal team approved. It only knows which fragments match the question and fell inside the user's access. So retrieval quality decides answer quality every time, and that gives you two separate things to get right. One is who can reach what, the other is which content wins when several candidates match, both are decided long before the user types anything. Both are decided by how your tenant is built. Hold on to that. It explains the two ways this goes wrong. The first one is about reach content that the wrong people can retrieve, simply because the permission was always too wide. That's where we start failure mode one oversharing was always there. Here's the first thing to get straight. Copilot doesn't create oversharing. It makes it discoverable. Those two statements sound close. They're not. One says the tool introduced a problem. The other says the problem was already sitting in your tenant, and the tool finally made it visible to the people who ask. That difference decides what you do next. If copilot caused it, you could switch copilot off and be fine. But the exposure doesn't live in copilot. It lives in your permissions. Turn the tool off tomorrow and the same wide open access is still there, waiting for the next search box, the next agent, the next curious employee with a good query. So where does it come from? Usually three things there the usual suspects and almost every tenant has all of them. The first is a group called everyone except external users. Sounds harmless. It means every employee in the company, plus every guest free account in the directory. Somebody adds it to a site or a library because they want to share something widely, and it's the fastest way to do it. One click and a few thousand people have read access. The second is the anyone link. No sign in, no identity check. Whoever holds the link can open the file and the link can travel anywhere. An email can travel. The third is the org wide link, slightly narrower than anyone, but still the whole company. Anyone inside the tenant who gets that link or who search surfaces the file can read it. Three small settings, three quick decisions. Each one is a valid grant. Now here's the sequence and it plays out the same way in most organizations. Someone needs to send a document to a colleague. It's a Friday. They click share and the default option on screen says people in your organization. It's the fast path, so they take it. The colleague opens the file. The job's done. Nobody thinks about it again, but the link doesn't expire. Nobody set it to, and the permission it created stays attached to that file quietly for months, sometimes years. Then one day, an unrelated employee opens copilot and types a question. Maybe it's about compensation bans. Maybe it's about a restructuring plan. Maybe it's about a customer dispute. The retrieval step runs. It checks what this person can reach. And that old file shared once on a Friday afternoon falls inside the boundary. It matches the prompt so it lands in the answer. The person who shared it forgot the owner of the site never knew the employee who found it wasn't hunting for anything. They just asked a normal question and got an abnormal result. That's the whole mechanism shared, once forgotten, surfaced in a prompt. And notice what's missing from that story. No attacker, no breach, no stolen credentials, no clever exploit. Every step was authorized. Every permission was real. The system did exactly what it was told years after the instructions stopped making sense. So this isn't an AI problem. It's a risk exposure problem that framing matters, especially if you're the one who has to explain it upstairs. When a sensitive document shows up in the wrong answer, the first reaction is to blame the assistant. But the assistant only worked with what it was given. The real question is how much content in your tenant is reachable by far more people than anyone intended. That's a number. It can be counted, it can be reduced. And it existed before the first copilot license was ever assigned. Think of it as a debt that was never on the books. For years the interest was zero because friction kept anyone from collecting. Now the friction is gone and the balance is due. The good news is that this kind of exposure is finite. It comes from a small number of repeating patterns. They aren't random. They show up in the same places for the same reasons in tenant after tenant. So before we measure anything or fix anything, let's name them because you can't clean up a leak. You haven't described the five oversharing patterns that show up. First, there are five patterns. They sit at different levels of the tenant, and they tend to show up in this order. Start at the top with the site every Microsoft three. Sixty five group has a privacy setting, public or private. A public group means any person in the organization can open the site, read the files, and read the connected conversations. They don't need an invite. They don't need to be a member. Most people who created those groups never changed the setting because the default was fine for the moment. They were in a project kickoff. A planning team open team sites worked the same way. Somebody wanted easy collaboration, so they left the door open. Then the project moved on and the content stayed. So pattern one is the open site wide access at the container level set once and never reviewed pattern two lives one layer down. The link sharing links are permissions too. They're just permissions that don't look like permissions. Nobody opens a site settings page to see them. A person clicks share, picks the option that works fastest and moves on org wide links give the whole company access. Anyone links give access to whoever holds the URL. No sign in needed. These get created for convenience one at a time by hundreds of people across thousands of files. There's no central list in anyone's head. Each link is small. Together, they form a second permission system that runs underneath the first, and it follows no design at all. Pattern three is the group. Here's where access gets hard to read. A site grants access to a group. That group contains another group. That group contains a distribution list. Someone converted three reorganizations ago. Somewhere inside that chain, there are people who left the company's department two years back, contractors whose projects ended, and sometimes a group that quietly includes everyone. Nesting hides the true size of the audience. Stale membership extends it past anyone's intent. So when you ask who can read this library, the honest answer is often we'd have to trace it. And that is already a finding pattern. Four is the library. Think about where sensitive content lands. In practice, HR doesn't always have its own site. Neither does finance or legal. What typically happens is that a team builds a general purpose site for operations, and then someone drops the salary review spreadsheet into a library inside it, or the draft settlement terms or the audit findings. The site was set up for broad participation. The files inside it were not, but permissions inherit from the site, so the files carry the site's wide audience without anyone deciding that they should. The mismatch is invisible until a prompt pulls the file into view, and pattern five is personal. OneDrive. It feels private. It's labeled my files, but people share from it all the time to a colleague, to a team, to the whole company. Because it's the quickest path. A manager shares a folder of performance notes during review season. An analyst shares a working model with everyone in the organization to unblock a request. Then they change roles or leave, or simply forget the sharing stays. And because OneDrive belongs to one person, no site owner exists to notice it. Nobody else is responsible for that content. It sits outside every governance process you build for sites, site link group library, personal. Notice something about these five. None of them are exotic. There's no clever exploit in the list. Every item is an ordinary decision made by an ordinary person for a reason that made sense on the day. And that's exactly why they pile up. No single one looks dangerous. The risk only appears when you add them together and then put a search box on top, but naming them doesn't shrink them. A list of patterns tells you where to look. It doesn't tell you how much is there. You could have ten oversharing problems or ten thousand. And from the outside they feel the same until something surfaces in an answer. So the next step isn't a fix. It's a number measuring exposure before you enable anything. Most teams skip this step. They go straight to policy. They write a sharing standard, schedule a training session and send a reminder email. None of it is tied to a number. So six months later, nobody can say whether the tenant got safer or just got more documentation. The tools to get that number already exist inside SharePoint Advanced Management. There's a set of reports built for exactly this question. The one to start with is data access governance. It's a set of reports that surface where content is exposed to widely and it works at the site level. You can see sites shared with everyone except external users. You can see sites with a high count of people who can reach them. You can see sites where lots of files were shared through links and sites that carry sensitivity labels, so you can tell where the risky ones sit. Then there's site sharing insights. This one looks at how content is being shared instead of how the site was set up. A site can look tight on paper and still have hundreds of links pointing out of it. The settings tell you intent. The sharing activity tells you what really happened. Run both and you get something. Most tenants have never had a picture. Now what do you do with the picture? There's a pattern Microsoft publishes for this, usually called the oversharing Baseline Blueprint. The idea is simple and it has three moves assess, fix, monitor, assess comes first because you can't fix what you haven't measured. You pull the reports, you find the biggest concentrations of risk, and you write down where you stand today. That's your baseline fix comes second. You work through the findings in order of danger, not in order of convenience. We'll get to that sequence later. Monitor comes last and this is the part people drop. Exposure isn't a one time condition. New sites appear every week. New links get created every day, so the reports need to run again on a schedule, and the numbers need to be compared against the baseline. If they climb, something changed and you want to know what. But a pile of reports isn't a metric. You need to pick a few numbers and track them. Three of them matter most. The first is sites with broad access. How many sites can the whole company or a huge slice of it read. That count is your widest door. It tells you how much content is reachable by default before any link is even involved. The second is files with org wide links, not sites files. How many individual items carry a link that opens them to everyone inside the tenant? This is the number that grows quietly one Friday afternoon. Click at a time, and it's the one most likely to be far bigger than anyone guesses. The third is sensitive content in open sites. This is where the first two numbers collide. A broad site with meeting notes is a clean up task. A broad site with salary data, legal drafts or customer contracts is an incident waiting for a prompt so you cross the lists which open sites hold labeled or sensitive material that overlap is your priority queue. Notice that none of these require perfection. You don't need to count every file in the tenant. You need directional numbers that you can repeat so that a change in the number means a change in the world. And that leads to the rule no copilot rollout without a baseline number. Not a feeling. Not we think we're mostly fine. A number written down with a date on it. Because without one, you can't tell leadership what you're exposing. You can't prove a fix worked. And when somebody asks after a bad answer shows up in a chat window whether the tenant was ready, you have nothing to point to except a hope. There's a practical side to this, too. A baseline lets you phase the rollout. You can enable copilot for a pilot group whose content you've already checked, instead of switching it on for everyone and watching what falls out. The number tells you which groups are safe to go first, so the sequence is clear. Measure, then enable, not the other way around. But a number only describes the problem. It doesn't contain it. Once you know how wide the exposure runs, you still need somewhere to put the fix. And that means looking at how your tenant is actually built. Starting with the thing every one of these reports is organized around. Wait, before that, there's a second way this goes wrong and it has nothing to do with security. 00:19:23 Speaker: The second failure mode. Correct access. Wrong answer. Not every copilot failure is a security failure. Some of them are just wrong. Picture the setup. A user asks about the travel reimbursement limit. Copilot runs retrieval checks what this person can reach, finds a matching document, and writes a clean, confident answer. No leak. No restricted file. Every permission was correct and the number in the answer is still two years out of date. Nothing was exposed. Nothing was breached. The tool did what it was designed to do and the user walked away with the wrong figure. So here's what's actually happening. Copilot can retrieve content the user is fully allowed to see and still return the wrong answer. Access was never the problem. The problem is that several documents matched and the wrong one won. Think about what sits in a typical library next to the real policy. A draft someone started in March and never finished a copy, saved to a desktop and uploaded again. A version emailed around for comments, then dropped into a folder and a file called final V7. Not final, not final v2 final version seven. Every one of those files is readable. Every one of them is a valid candidate, and the retrieval step has no way to know that the file with the longest messiest name is the abandoned one, and the plain file in the quiet folder is the one legal signed off on. It sees text, meaning and permission. It doesn't see intent, so they compete drafts against approved versions, duplicates against originals. A policy replaced last quarter against the policy that replaced it. And the winner is decided by whatever signals your tenant happens to give the index, which in most cases is almost none. Here's why that matters more than it looks. A security failure is rare and mostly invisible. When oversharing surfaces, it surfaces for one person in one chat, and often nobody reports it. But a quality failure is visible every single time the user reads the answer. They know their own business. They notice when the holiday rule is wrong or the pricing is old, or the procedure describes a system. The company retired and they don't think the library has a version problem. They think this tool can't be trusted, that judgment is fast and it's hard to reverse one bad answer on a topic someone knows well costs more credibility than ten correct answers. Earn back people stop asking. They go back to emailing a colleague. Which is exactly the workaround the tool was meant to remove. So trust erodes faster from wrong answers than from leaks. Not because wrong answers are more dangerous because users can see them. Now look at the two failure modes side by side. One is about reach content that too many people can retrieve. The other is about authority content that shouldn't win, but does. They feel like different problems with different owners. Security handles one. The business complains about the other, but they share a root. Both come from a tenant where nobody decided what content lives, where, who owns it, who can see it, and which version counts. Reach was never designed. Authority was never designed. They were both left to accumulate one site and one upload at a time. So the fix isn't to programs. It's one structure applied in the right order. And that structure starts with the smallest unit that can carry an owner, an audience, and a life cycle at the same time. The site, the site as the unit of architecture. Why the site? Because it's the smallest container that can hold three things at once. An audience, an owner, a clock. Think about what you can actually attach to a site. permissions live there. A sensitivity label can be applied there and it controls privacy and sharing for everything inside lifecycle policies run there. Inactivity exploration access review go smaller to a folder or a single file and you can still set permissions, but nobody owns that decision. Go larger to the whole tenant and the settings are too blunt to fit any one team. So the site is where a decision can be made and where someone can be held to it. But not every site does the same job, and treating them as the same thing is where the risk starts. A team site is a workspace. It's tied to a Microsoft three. Sixty five group. So it comes with a shared mailbox, a teams connection, and a membership list. People write in it, upload to it, and change things daily. Its risk is drift. Members come and go, files pile up and nobody reviews any of it. A communication site is a publishing space. A few people write, many people read. It's built to broadcast, not to collaborate. Its risk is different, the wrong audience or the wrong content ending up on a page everyone trusts. A hub site is neither. It doesn't hold your files. It connects sites together for navigation and search. We'll get to hubs properly in a moment, but for now, just hold this three site types. Three jobs, three different ways to go wrong. Now here's where most tenants went sideways. They designed by the department chart finance gets aside, HR gets aside, marketing gets aside. It feels tidy because it matches the org chart on the wall. But look at what's inside the HR side. Job postings that every employee should read. Interview notes that three people should read salary bands, that five people should read, one department, three audiences, three levels of sensitivity, and a single set of permissions. Trying to cover all of it. That's the floor. A department isn't an audience. It's a reporting line. The people who need to read a document have nothing to do with which box on the chart owns it. So you stop asking which department is this and start asking two other questions. What is this content for and who needs to reach it? Purpose and audience. That's the design input. A site for company wide policy has a purpose authoritative reference. Its audience is everyone read only a site for an acquisition project has a purpose confidential deal work. Its audience has eight named people and it ends in a year. Those two sites might both touch the legal department. They shouldn't share a container, a permission set, or a label. Once you design this way, a simple rule falls out. One site, one owner. One purpose. One life cycle. One owner. Because a site with no accountable person is a site, nobody cleans up one purpose because a mixed purpose site forces mixed permissions and mixed permissions are exactly the library level exposure we covered earlier. One life cycle. Because content created for a project shouldn't live as long as content created for a policy. If you can't say all four in a single breath, the site is doing too much, split it. And yes, that means more sites, many more in some tenants. That worries people. But a hundred small sites with clear owners are easier to govern than ten large ones, where nobody can explain who has access. The count isn't the problem. The ambiguity is now. Once you've drawn those boundaries, you face the next choice. How will people get access inside each one? There are two permission models, and they fit two very different audiences. That choice comes next. Team sites versus communication sites, choosing by audience, two models, two audiences, and the choice between them comes down to one question who writes and who reads? Start with the team site. It's for people working on something together a project group, a delivery team, six, ten, maybe twenty people who all create, edit and discuss in the same place. Everyone in it is both author and reader. Membership is small and defined. You could write the names on one page. That's what makes it safe. The audience is the team, and the team is a known quantity. The communication site works the other way around. A few people publish. A large group reads the company handbook, the expense policy, the product price list, the security standards everyone is supposed to follow. Nobody visiting those pages is there to collaborate. They're there to find out what's true. So one model is built for conversation among a few. The other is built for authority toward many. Now here's where tenants get into trouble. Somebody builds a team site for the legal group. It works well. Contracts get drafted, their comments fly back and forth, and the team is happy. Then the group has a good idea. Why not put the approved templates and the company wide contract policy in the same site? It's convenient. The files are right there so they add a folder and a few weeks later someone says, let's give everyone read access to that folder and now the site is doing two jobs. Think about what that does to the permission picture. The draft settlement terms sit in one library. The public facing policy sits in another inside a single site. Both have to share one membership model, one owner group one set of sharing settings. So either the whole site opens up and the drafts become reachable by hundreds of people, or the policy stays locked and nobody outside the team can read what they're supposed to follow. Most teams solve this by breaking inheritance on a folder, then another, then another, and within a year nobody can explain who has access to what. That's the cost of mixing. Not one big failure. A slow loss of clarity and clarity is the thing. Retrieval depends on when a site's audience is unclear. A sensitivity label on it is a guess. A sharing policy is a compromise. A review of access becomes a forensic exercise, so separate them every time. Authoritative content gets its own home. A communication site built for that one purpose. Few editors and many readers. The people who can change the content are named, accountable and small in number. Everyone else gets read access and nothing more. That asymmetry is the point. It tells the tenant in plain structural terms, that what lives here has been reviewed by someone who answers for it. And look at what that does for the second failure mode. When the approved policy sits in a site with five editors, the stray draft in someone's team workspace has a harder time pretending to be the real one. The tenant now has a place that means this is the version you can point to it, label it, and rank it. Nobody had to rename a single file. Meanwhile, the team site stays what it was meant to be messy, fast and private drafts live there. Half finished thoughts live there. That's fine because the audience is small and known and the content isn't pretending to be official. So the rule is simple collaborate in one place, publish from another. But once you have dozens of sites built this way, a new problem shows up. They're all correct. They're all separate, and a person trying to find anything across them is looking at a flat pile of containers with no obvious grouping. Sites get grouped and that's where hubs come in. Hub sites, navigation tool or governance tool. A hub site does three things. It connects sites through shared navigation. It widens the scope of search. So a query inside the hub looks across every associated site and it carries shared branding. So a dozen separate sites look like one place. That's the job description navigation search scope branding. Now look at what's missing from that list. Permissions. A hub doesn't grant access to anything. If you associate a site with a hub, nobody gains the right to open it. Nobody loses a right either. The site keeps its own owners, its own members, its own visitors exactly as before. The hub just draws a line around it on the map. This is the most common misunderstanding about hubs. People here hub and picture a parent a parent site with child sites underneath, passing access down the tree. That picture is wrong. It's the old hierarchy model dressed in new vocabulary. A hub is flat every site, and it stands on its own, with its own audience. And the association is only a relationship for finding and displaying things. And the mistake has a real cost. A team assumes that putting a site in the finance hub means only finance people will see it, or the reverse. They assume that being in a company wide hub makes the site open to everyone. Neither is true. The hub says nothing about who can read, so if you're counting on it for protection, you don't have any. So if a hub isn't a security tool, what is it for context. Think about what copilot and search face when your sites aren't grouped. A flat pile of containers forty sites with names like Ops Hub, team delivery, Q3, and process docs new. Nothing tells the index which of them belong together. A site about customer onboarding and a site about onboarding. New employees sit side by side with no signal separating them. A hub supplies that signal. Group your sites by domain. All the legal sites in one hub, all the HR sites in another, all the product sites in a third. Now each cluster has a shape. Search can scope to the cluster. A person working inside the HR hub searches inside the HR hub, and the results come from HR sites, not from every corner of the tenant. That's the practical gain. Coherent clusters. And here's why it matters for retrieval. Copilot works from the same index that search does. Association with a hub is one of the signals that index carries. It tells the system which sites are related, which content sits together, and where. A question about a topic is most likely to find its answer. It won't fix a bad site, but it organizes good ones so that related content gets read together instead of being scattered across the whole pool. So the grouping rule is simple. Group by domain, not by org. Chart. A hub for customer operations that pulls together the support site, the onboarding site and the escalation playbook makes more sense than a hub named after a department that happens to own two of them. Keep the numbers sensible to a hub with six well-chosen sites is a cluster. A hub with two hundred is a junk drawer with a logo on it, and a site can only belong to one hub at a time, which forces a useful decision. Where does this site mainly belong? If you can't answer that, the site's purpose is probably unclear, and that's a problem to fix before you associate anything. One more thing about ownership. Hubs have owners, and those owners can control navigation and branding across all the connected sites. That's real influence over how content gets found. But it's influence over presentation, not access. Treat hub ownership as an editorial role. Give it to someone who understands the domain, not to whoever had admin rights that week. So here's the clean split. Hubs organize. They help people and the index see which content belongs. Together. They don't protect anything. Protection sits somewhere else. It sits in who can open each site. And that decision lives in permissions. That's where the real work is. Permissions. Design groups, not people. Here's a question to test any site in your tenant who has access and why. If the answer starts with a list of names, the design is already off. Because names change. People move. Teams leave, the company take on a new role, and every time one of those things happens, someone has to remember to go back into every site that person touched and fix it by hand. Nobody does. So the access stays the fix. Stop granting access to people at all. Access goes to groups only groups. Two kinds matter here. Microsoft Entra security groups and Microsoft three hundred sixty five groups. A security group is a plain list of members you can attach to a site. A Microsoft three hundred sixty five group is that same list, but it also carries a mailbox, a calendar, and a teams connection. Either one works as the grant. What matters is the principle. A site never says Maria can read this. It says this group can read this, and Maria's membership in that group is managed somewhere else by a process, not by a click inside a library. That one change moves the decision before access was spread across thousands of small clicks. Now it lives in a short list of groups where it can be reviewed, expired, and audited. Next, the roles. Every SharePoint site comes with three and they map to real accountability. If you let them owners run the site, they approve membership, answer for the content, and get the call when something goes wrong. Keep this group small, two people minimum so the site survives, one of them leaving five at most or nobody feels responsible. Members work inside the site. They add files, edit pages and change things daily for a team site, this is the project group for a communication site. It should be a handful of name editors, not a whole department. Visitors read. That's all. They can open, search and follow links, but they can't change anything on a publishing site. This is where the large audience goes, and this is where everyone in the company belongs. If it belongs anywhere, not in the members group where it quietly turns into write access. Owners. Members. Visitors. Three groups per site, each with a clear answer to the question who is responsible for this list? Now look at what happens when you skip all of that. Someone needs to give a colleague access to one document. The fastest way is a direct permission on the file or the folder, or a unique permission set on a library so the colleague can see it without seeing the rest of the site. It works immediately and it feels harmless, but each of those is a permission that lives outside any group. Nobody reviews it, no policy touches it. And when you try to answer, who can read this library? The site level groups tell you one story, and the direct entries underneath tell you another. At small scale, you can hold that in your head. A site with ten of these exceptions is fine, but tenants don't have ten. They have thousands of sites, and each one picks up exceptions month after month, so that a library that started with three groups ends up with sixty individual names for broken inheritance folders, and a set of entries that nobody can explain. That's what breaks at scale. Not any single permission. The sum of them, and it hits retrieval directly. Copilot honors every one of those entries. So the stale name that was added for a one off request still counts. The person who changed departments last year still counts. The exception nobody remembers granting counts exactly as much as the owner's decision. So here's the rule of thumb if you can't explain who has access to a site in one sentence, the design is wrong. The finance leadership group can edit, the finance team can read nobody else. That's one sentence. That's a site you can label, review and defend. Well, it's the finance team, plus some people from audit plus a few folks who needed the Q3 files, plus a link we sent to a vendor. That's not a sentence, that's a history. If you're stuck with the second kind, the answer isn't to start adding more groups on top. It's to understand how the exceptions got there in the first place. And that comes down to one mechanism that does its damage slowly in the background, long after anyone has stopped watching. Inheritance is where permissions quietly rot inheritance, broken permissions and drift. By default, a site works simply. Permissions flow down the sites. Groups reach every library, every folder, every file. Change the group once and the change lands everywhere. That's inheritance. And it's the only version of SharePoint access that stays readable. Then somebody breaks it. A manager wants one folder visible to two extra people. Someone else needs a subfolder hidden from the team. A project lead copies a set of files into a new library and locks it down just for now. Each of those choices stops inheritance at that point and creates a unique permission set from there, that folder answers to its own list, not the sites. One of those is fine. Ten are manageable, but they multiply and they multiply quietly. Because nothing about creating one feels like a decision. It feels like a fix. Two years later, a single library holds forty folders with their own rules, and no one can tell which were deliberate and which were leftovers from a deadline. Now here's the part nobody audits. When you give one person access to one file inside a site, SharePoint has to let that person reach the file without handing them the whole site. So it adds a limited access entry. It's a technical placeholder that lets the person pass through the parent containers to get to their item. You won't see it on the normal permissions screen. It doesn't show up as a name with a role. It sits underneath as a trail of small entries that grow with every one off share. The result is sprawl. You can't see a site that looks like it has. Twelve people may carry hundreds of these entries. Each one traces back to a moment. Someone needed something quickly and none was ever cleaned up. And because they're hidden, no review process touches them unless you go looking on purpose. Sharing links make it worse because they run on a separate track. A sharing link is a permission, but it doesn't belong to the site's groups. It belongs to the file and to whoever created it. So you end up with two systems at once. The structure you designed with owners, members and visitors, and a second structure built by hundreds of people clicking share. The second one has no owner, no expiry unless someone set one and no connection to the reason it was created. That's what makes links so durable. The reason ends. First. The vendor project closes, the colleague changes roles. The review cycle is over, but the link keeps working because nothing in the system knows the purpose is gone. It outlives the intention behind it. So drift isn't a single event. It's the gap between the design you approved and the access that exists today, widening by a few entries a week. The answer isn't to ban unique permissions. Sometimes they're the right call. The answer is to make them visible and to put a process around the places where they matter most. Start with scope. You don't need to review every library. You need to review the sensitive ones finance, HR, legal, anything tied to a label that signals risk for those. Pull a report of every folder and file with unique permissions. Look at who's on each entry and whether a group could replace it. Look for names that belong to people who've moved on. Look for links that were created long ago and still resolve. Then set a rhythm. Quarterly works for the highest risk libraries twice a year is enough for the rest. The site owner confirms each exception or removes it. If nobody can explain why an exception exists, that's the answer. It goes and add one rule at the front. Unique permissions on a sensitive library need an owner's approval, not a ban a checkpoint. It slows the casual exception down so the deliberate one stands out that handles what already exists inside a site. But the biggest source of new untracked access isn't buried in folders. It's the share button and the defaults behind it. Sharing controls are the next lever. 00:38:03 Speaker: And a sharing policy defaults that prevent the problem. Every site you've built so far can be undone by one click on the share button. That's why sharing settings matter more than most teams admit. They decide what happens when a person acts fast without thinking about the architecture. And most people act fast. Two layers to set. The first is the tenant. In the SharePoint admin center. You choose how open the whole organization can be. Can people share with guests? Can they create links that work without signing in? Whatever you pick here is the ceiling. No site can be more open than the tenant allows. The second layer is the site. Each site can be set equal to the tenant or tighter, but never looser. So the tenant sets the outer limit and each site narrows it to fit its audience. A public policy site can stay fairly open. A deal room can shut external sharing off completely same tenant different rules because the purpose is different. Most organizations only touch the first layer and they set it once years ago. The site layer sits at its default, which means every site inherits the widest rule available. That's a choice nobody made. Now, the single most useful setting in this whole area is the default link type. When someone clicks share, SharePoint offers a link with a preset scope. If that preset says people in your organization, then that's what most people send. Not because they decided to open the file to everyone because it was already selected, and clicking send was the fastest way to finish. So change the preset. Make the default specific people. The sender now has to type a name and the link works only for that person. It takes three extra seconds and it turns an accidental company wide share into a deliberate one. You can still allow broader links. You just stop making them the path of least effort. People will choose the harder option when they have a reason. They won't choose it by accident, then deal with time. A link that never expires is a permission with no end date. We saw how that plays out. The project closes, the link keeps working, so set an expiration for anyone. Links. Put a hard limit. Thirty days is common for guest access. Require a review on a schedule, so someone has to confirm that the outside person still needs to be there. Expiry shouldn't be the exception that a careful owner sets. It should be the standard that a justified owner removes. Pair that with access reviews at the site level once a quarter for sensitive sites, the owner looks at who has access and confirms or removes each entry. It's a small task. It's also the only thing that catches the person who left the project eight months ago. The last control is about who gets to create the widest links at all. Not everyone needs the ability to send in any one link. Most people never will, so turn it off for the tenant or limit it to specific sites that have a real reason, like a public communications team sharing press material for org wide links. You can go further and restrict them on sensitive sites so the option simply doesn't appear in the share dialog. The decision moves from the end user to the person who designed the site. Put those four together. Tenant and site limits, a narrow default expiry and review built in and broad links reserved for people with a reason. Now, the Friday afternoon click produces a safe result with no training required, but defaults only change behavior at the margin. They reduce new exposure. They don't give you a hard stop for content that must never be reachable by the wrong audience. Whatever anyone clicks for the highest risk sites, you need harder controls. Restricted access controls for sensitive sites. Some content can't wait for a clean up the deal room, the board materials, the investigation folder. If any of that is reachable by the wrong audience, the cost of one bad prompt is higher than the cost of a slow fix. So Microsoft built two controls for exactly this case. They sound alike. They do different jobs. The first is restricted access control or risk. You apply it to a site and you name the groups who are allowed in. Everyone else is blocked even if they hold a direct permission, even if they have a sharing link. Even if the site's own settings say they should get through. The policy sits above all of that. It says only these groups and it holds when somebody breaks inheritance, shares a file, or adds a name in a hurry. Think about what that changes. Earlier, we saw how unique permissions and links. Build a second system under the first. Our rack puts a fence around both. The mess inside the site is still there, but the people who can reach it are limited to the groups you picked. The second control is restricted content discovery, and this one is more subtle, so it helps to say plainly what it does. It doesn't change who can open the content. Permissions stay exactly as they are. What it changes is where the content shows up. With discovery restricted on a site, its files stop appearing in org wide search. They stop appearing in copilot answers for people who weren't meant to find them. The content stays accessible. A person with a direct link can still open it, but nobody stumbles across it through a query. So the two controls answer two different questions. Eric asks who is allowed through the door? Restricted content discovery asks whether the door is listed in the directory. Now that second one is a big deal for rollout timing. You may have a site with a messy permission history and no time to untangle it before copilot goes live. Turn off discovery and the retrieval step no longer pulls from that site for the wider population, the exposure shrinks right away while the real repair work continues behind it. But be careful with how you read that restricted content discovery hides the content. It doesn't fix the permissions. The wide access is still sitting there unchanged. Anyone who has a link or who finds the site some other way still gets in. You've covered the problem. You haven't removed it, so use these controls as a stopgap, not as the design. A permanent design is one where the permissions are right, the labels are applied and the site has a clear owner and audience. If you lean on restricted discovery for years, you've built a tenant where the real access model is wrong and a filter is hiding the proof that filter can be removed by accident, a policy change, a new admin, a forgotten exception, and the content is back in the index with the same wide permissions it always had. There's a cost on the user side, too. Restricting discovery means legitimate people lose easy retrieval. A person who should find a document through search now has to know where it lives. That's the friction we spent the whole script trying to remove. So every site you restrict is a site where copilot will be less helpful on purpose. Which brings you to the decision that isn't technical at all. Which sites justify that friction? It's not a question for the admin alone. Somebody has to weigh what a leak costs against what a missing answer costs. A merger workspace, almost certainly. Yes. A general HR policy library. Probably not, because the whole point of that content is that people find it. Legal drafts. Executive compensation. Active investigations. Unreleased financials. These are the candidates. Make the list short. Write it down. Name the person who approved each entry and set a date to revisit it. Because a restriction without an owner and a review date turns into permanent clutter, and a restriction on everything protects nothing because it breaks the tool for everyone. So you now have the Who permissions, groups, links, and the controls that fence the worst cases. But knowing who can reach a file doesn't tell you what the file is. A salary table and a lunch menu can share the same audience. They shouldn't share the same handling permissions. Say who labels say what sensitivity labels classification that travels with the file. A permission lives inside your tenant. It's a statement about one site, one library, one file in one place. Move the file and the statement stays behind. The label is different. A label is attached to the thing itself and it works at two levels. The first level is the container sites. Microsoft three hundred sixty five groups teams. When you apply a sensitivity label to a container, you're not describing a document. You're setting rules for the whole space. The label can decide whether the group is public or private. It can decide whether guests can be added at all. It can limit sharing to people inside the organization or block links that reach outside it. It can even require that the site is only reachable from a managed device, so a container label does one job. It sets the boundary conditions for everything that will ever be created inside privacy sharing external access. That's the whole scope. And notice what it doesn't do. It doesn't encrypt anything and it doesn't touch the individual files. It controls the room, not the contents. That's where the second level comes in the item. An item label goes onto a single file or email, a word document, a spreadsheet, a PDF, and here the label can do something much heavier. It can encrypt the file, it can add a header or a watermark, and it can set usage rights, meaning who is allowed to open the file, who can edit it, who can copy from it, and who can print it. Now look at how those two levels behave when something moves. Say a finance team keeps its files in a locked site with a container label that blocks external sharing. Somebody downloads a spreadsheet and emails it to a personal address. The container label stays with the site. It can't follow the file out the door, but an item label can. The encryption is part of the file. So wherever the file goes, the rules go with it and the recipient has to prove they're allowed in before it opens. That's what travels with the file actually means, not a note in a database. The protection is built into the document. Which brings us to copilot and the part that surprises people. You might assume that if a user can open a file, copilot can read it for encrypted files. That isn't quite enough. Copilot respects the usage rights set by the label, and to surface content from an encrypted file. In an answer, the user needs a specific right called extract. Think of it as the right to copy content out of the file. If the label grants the person view access but withholds extract, copilot won't pull text from that document into a response. That's a useful control. A label can let a person read a document and still keep copilot from quoting it, but it cuts the other way to say you apply a label with encryption to a library, and you set the usage rights too tightly. Now, people who should get answers from those files can't get them. Copilot hits the encryption, checks for the right and comes back empty. The user just sees a weaker answer with no explanation. So the rights you grant need to match the audience you actually intend, not the audience you're most afraid of. There's one more detail worth knowing. When copilot does use labeled content, the label doesn't disappear from the output. The response can inherit the protection from the sources it drew on. So an answer built from a highly sensitive document carries that sensitivity forward. The classification follows the content into the new text, so labels do three things at once. They set the rules for the container, they protect the individual item, and they tell copilot what it's allowed to do with the content it finds. That's a lot of control, and all of it depends on a single condition. The label has to be on the file. A policy that no one applies protects nothing. If the finance spreadsheet carries no label, then there's no encryption, no usage rights, no extract check, and no signal to anyone downstream that the file was ever sensitive. The system can only enforce what's been marked, and that depends on people. Real people in a hurry, deciding in the moment whether a document is confidential or internal or something else. If that decision is confusing, they'll guess. If it's tedious, they'll skip it. Labels only work if people can apply them reliably. Label strategy that people will actually use. Start with the number most labeled taxonomies fail on count alone. Someone in compliance sits down with good intentions and builds a list. Public, internal, confidential, highly confidential, then sublabels for each department, then variants for external sharing, then one for legal hold, one for board material, one for confidential but shareable with partners fifteen labels, maybe twenty. And on paper, every one of them is defensible. Each covers a real case, but the person who has to choose is looking at a drop down in the middle of a task with no time to read a policy document. They can't tell confidential from confidential, internal. So they guess a few weeks later, they stop guessing and pick whatever sits at the top or skip the step entirely. That's the failure. Not bad intent. A choice that costs more effort than people will spend. So cut it down. Four or five labels at the top level is a workable ceiling and make the differences between them obvious, not subtle. A person should be able to answer in two seconds. Could this file hurt us if it leaked? If yes, which of two labels? If the answer needs a flowchart, the taxonomy is the problem. Names matter just as much. Skip the vocabulary only a security team uses. General and confidential be tier two restricted internal use. Add a one line description that shows up on hover written in plain words. Contains customer or financial data. Don't share outside the company. That's a sentence a person can act on. Now, even a clean set of five fails if it depends on every user remembering to apply it. So take the decision out of their hands wherever you can. That's what default labels are for. You can set a default label on a library, and you can set one on the site. Every new file created or uploaded there picks up that label automatically. A finance library defaults to confidential. The company handbook site defaults to general. Nobody clicked anything and the coverage is already there. The label is a starting position instead of a task, and people can still change it. If a file in the finance library really is harmless, the author lowers the label and that's a deliberate act. But the lazy path now leads to the safe result. Defaults handle new content. Auto labeling handles what's already sitting there and what people forget. There are two main tools here. The first looks for sensitive information types, credit card numbers, national ID numbers, bank account details, passport data. These follow patterns so the system can scan files and apply a label. Whenever a pattern shows up in enough volume. It's precise and it works well for structured data. The second tool is trainable classifiers. These handle content that has no neat pattern a contract, a resume, a set of source code. A merger memo. You feed the classifier sample documents. It learns what the category looks like, and then it can recognize similar files across the tenant. It's less exact than a pattern match. So you test it first, review what it flags and tune it before letting it label anything on its own. Start both in a recommend mode. Let the system suggest a label and show the user instead of applying one silently watch how often the suggestions are right when the accuracy is high enough, switch the most reliable rules to automatic. Put the pieces together and the picture changes. A short, plain label set that people understand. Defaults that cover the places where the sensitive work happens, and automation that catches what slipped through the user's job shrinks to a rare decision, and the label does its work in the background at the file where copilot and every other control can read it. But a label only answers one question how sensitive is this? It says nothing about what the document actually is. Assigned supplier contract and a rejected draft of the same contract can share a label. A current policy and its predecessor from twenty twenty one can share one or two. Both are internal. Both are equally protected, and copilot has no way to tell which one is true. Labels classify as sensitivity. Metadata classifies meaning. Metadata the layer that gives copilot meaning. Think about what a folder path actually tells you. Financed in twenty twenty four. Then policies. Then travel four levels deep. It feels like a lot of information, but it's one dimension, one path, one place. The file can sit. A real document has many dimensions at once. It's a policy and it's about travel and it belongs to finance. And it's approved. And it applies to every employee. And it took effect in January. A folder can only encode one of those. So the person who built the structure had to pick sort by department by year, by document type, whatever they picked, the other five facts disappeared into the file name or into somebody's memory. That's the limit of the folder. It was built for a human who walks the tree and reads the labels along the way. Retrieval doesn't walk. It reads. What's attached to the file. Metadata is what you attach in SharePoint. That means columns. A column is a named field on a document status owner business unit. Effective date audience. You fill it in once and it travels with the file. Wherever the file goes, move it to another library and the values come along. Rename the folder and nothing breaks. The facts live on the file, not in its address. Now three layers of this matter for retrieval. First plain columns. A choice field for status. A date field for effective date. A person field for owner. Simple. Local and effective. Second content types. A content type bundles a set of columns into a definition of what kind of document this is. A policy carries owner status. Effective date and review date. A contract carries counterparty value and expiry. So the document doesn't just have fields, it carries a declared identity. Third, managed metadata instead of typing a business unit by hand. People pick from a shared term list that the whole tenant uses one spelling, one hierarchy, no fin, finance and finance dept splitting the same content three ways. Each layer is a signal the index can read not a guarantee, but a signal. A file marked as an approved policy owned by a named person, effective this year, is telling the system something that a file called Travel New Final never will. Look at the five fields that do the most work document status draft in review. Approved. Superseded. This one field separates the working copy from the real thing. Owner someone accountable for the file being right when ownership is empty, nobody is business unit. Which part of the organization the content speaks for effective date. When this version started to count and paired with the review date when it should stop. Audience who the content is written for. Everyone manages a single region that's five columns, not fifty, and together they answer the questions a retrieval system can't guess is this current? Who stands behind it and does it apply to the person asking? Here's where most teams get it wrong. They treat metadata as a way to build nicer views. A filter for show me approved policies, a grouping by department. Handy for people browsing a library. That's useful, but it's the smallest part of the value. The real job is deciding which version is true. Go back to the reimbursement example. Two documents match the question. One says the limit is lower. One says it's higher. Folder names don't settle it. File names don't settle it. But if one of them is marked approved, effective this year, owned by the Finance Policy lead and the other is marked superseded, the conflict has an answer. It's written on the files themselves. So metadata turns. Which one wins? From a coin, flip into a ranking. And notice what that depends on. Every document that matters has to carry the same fields filled in the same way, meaning the same thing. If one team uses active and another uses live, the signal falls apart. If half the policies leave status blank, blank wins by default. That means someone has to decide once and in advance what a policy is, what a procedure is, what fields each one must have, and what the allowed values mean. To use metadata, you need to define what a document is. 00:54:32 Speaker: This content. Types and side columns. Designing a shared language. Here's what usually happens. First, a site owner reads about metadata. They get excited. They open their library and add a column called status. Then a column called Department, then doc type. It takes ten minutes and it works for that library. Now multiply at two hundred site owners, two hundred libraries, each one inventing its own columns. One calls it status with the values draft final. Another calls its state with open, closed live. A third builds document status with five choices that mean something slightly different. All of them are correct locally and together. They're noise because the index sees hundreds of fields that look related and share nothing. That's the same floor as the folder one level up everyone encoded meaning in their own private way. SharePoint has a fix for this, and it's been there for years. It's a pair of tools, site columns, and content types. A site column is a field defined once with a fixed name, a fixed type, and fixed choices. You create document status a single time and every library that needs it points to the same definition, not a copy, the same one. So a value of approved means the same thing in finance, in legal, and in the plant in Ohio. A content type then bundles those columns into a document definition. A policy content type says every policy has an owner, a status, an effective date, a review date, and an audience. Add the content type to a library and those fields arrive together as a set, with no one rebuilding them by hand. Now the part most tenants skip the content type hub. This is a central place one site in your tenant where you define content types and publish them out to every other site. Change a definition at the hub and the change flows to wherever it's used. Add a field to contract, republish and every contract library gets it. Someone who wants to add their own variation can still do that locally, but the shared core stays intact, so the choice is simple. Definitions live in one place and get pushed outward, or they live in two hundred places and drift apart. Same goes for side columns. Define them at the top. Reuse them everywhere. Resist the urge to recreate business unit in each site because it's quicker, it's quicker. Once after that, you've split your own content into groups that can't be compared. Now, how many content types do you need? Fewer than you think. Start with five to eight. Policy procedure, contract report, proposal ad meeting record, and maybe one for project plan. If your organization lives on them, that's usually enough to cover the content that people ask questions about. And these are also the documents where which version is true matters most. Look at what that list leaves out. It leaves out miscellaneous. It leaves out a content type for every team's quirks. If you build forty on day one, nobody will learn them and users will default to the generic document type every time. The goal isn't to classify everything, it's to give the important documents a clear identity and let the rest stay general. You can always add a ninth later. It's much harder to remove a thirtieth, which brings up the cost nobody puts on the project plan. Every required field is a decision. When you mark a column as required, you're telling a person in the middle of saving a file that they can't finish until they answer. Business unit. Audience. Review. Date. Owner. Each one takes a few seconds and a few seconds of thought. Ask for eight and the upload feels like a form. People respond to that in predictable ways. They pick the first option in the list. They type a dot. They avoid uploading to that library and use a personal folder instead. And now the metadata you worked so hard to design is filled with wrong values, which is worse than blank because blank at least looks blank. So be strict about what earns a required slot status, owner, and effective date for most content types. Maybe audience. Everything else is optional or filled in automatically or inherited from the library or the site. If a field can be set for the user, set it for the user. If it can't, ask whether the answer will ever change what copilot returns. If not, drop the field. That discipline is the whole job. Here, a small shared language used by everyone beats a rich one that nobody completes. But a shared language only tells the system what a document claims to be. It doesn't tell the system which claim to believe. Search quality depends on what you mark as authoritative search quality, making the right file win. Here's something that gets lost in the co-pilot excitement. Copilot doesn't have its own private way of finding your files. It uses the same index that Microsoft three. Sixty five search has used for years. Same crawl, same signals. Same ranking logic with a language model sitting on top to write the answer. So when copilot returns the wrong file, the question isn't what's wrong with the AI? The question is why did search rank that file first? And that's good news because search is something you can inspect. Look at what the ranking reads. Titles are a big one. The title of a document, not just its file name, tells the index what the file claims to be. A page titled Travel Reimbursement Policy has a head start over a file called doc two, then metadata the fields we just built. Status owner, effective date, audience, then freshness. Recently modified content tends to rise, which sounds helpful until you remember that someone fixing a typo in a twenty nineteen draft makes it look new. Then location a file in a communication site with five editors sits in a different position than a file in someone's personal folder and authority, which is really the sum of the others who owns it, where it lives, and how many people open it and trust it. Each of those is a small signal. None of them decides the result alone, but together, they're the only way the system can tell a real policy from a look alike. Now flip it. Look at what drags quality down. Duplicates come first. Someone saves a copy just in case someone else downloads a file, edits it, and uploads it to their team site. Now, four versions of the same policy exist, and they differ by a paragraph. The index doesn't know which one you meant. It sees four strong matches, and one of them wins by a margin so thin it can change next week. Generic file names come second. Final notes. Presentation. New copy of budget. These carry no information. So the title signal that should help you does nothing worse. They sit in the same results as well named files and compete on equal terms, then abandoned folders. A project ended three years ago. Nobody archived the site. The files are still there, still indexed, still matching on keywords. And because no one has touched them, they have no owner to correct them and no process to retire them. They don't fade out of results by themselves. They weight. Each of these makes the right file work harder to win. Add enough of them and it stops winning. So how do you know where you stand? You test it not once, but as a habit. Start with real prompts, not the ones you'd write in a demo, the ones people actually type. What's our parental leave policy? Who approves a contract? Over fifty thousand? Where's the latest security standard for vendors? Pull them from help desk tickets from questions that land in team chats from the ones new hires. Keep asking. Run each prompt as a search query. First look at the top five results. Is the correct file in position one? If it's in position four, you've found a ranking problem. If it isn't in the list at all, you've found a coverage problem. Either way, you've found something specific which is far more useful than a general feeling that copilot gets things wrong sometimes. Then do it again next month. That's the point of treating it as a regression suite. A set of questions with known correct answers run on a schedule when someone reorganizes a site, restructures a library, or runs a cleanup, you rerun the set. If a prompt that used to return the right policy now returns an old draft. You know, the change broke something and you know where to look. Keep the list short at first, twenty prompts is plenty. Pick the ones where a wrong answer would cost something policy, compliance, pricing. Anything a person might act on without checking. Write down the expected source for each. A spreadsheet is enough, and notice what you'll find when you do this. Most failures won't be about permissions. They won't be about labels either. They'll be about content. That was correct. Once a policy that was replaced but never retired, a procedure nobody updated after the process changed. A site that stayed alive long after the team left. The ranking didn't fail. It did exactly what it was built to do with the material it was given. The problem is that the material was old. Quality problems usually come from stale content, and stale content is a lifecycle problem. Site lifecycle. Every site needs a birth and a death. Look at how most sites get created. Someone needs a place for a project. They open teams. Click create team, type a name and click create. 30s. Later a site exists. A Microsoft three hundred sixty five group exists a mailbox, a calendar, a document library. All of it. Ready to go. That's self-service. And for speed, it's hard to beat. But nobody was asked a single question. Who owns this? What's it for? Who should be allowed in? How long will it matter? The platform made a site and every decision that mattered was left for later. Later never comes. So the first change is at the front door. Sites shouldn't appear because someone clicked. They should appear because someone answered. There are two workable routes. The first is templates. You build a small set of site types, say a project site, a team site, a publishing site. Each one arrives with the right structure already in place. The three permission groups. The default label, the content types from the hub. The sharing limits. The person creating the site picks a type and gets a design that's already been thought through. The second route is a request process, a short form, a light approval, and then provisioning. Nothing heavy. A few minutes of effort. Not a committee. The goal isn't to slow people down. It's to make sure the questions get asked. Once at the moment when the answers are easiest to give. Most organizations end up with both templates for the common cases. A request for anything unusual. Now, what must be true? The moment a site exists for things an owner, a real person named, and a second one beside them. So the site survives. A departure, a purpose, one sentence working space for the twenty twenty five supplier audit. If nobody can write that sentence, the site shouldn't exist yet. A sensitivity label chosen at creation. So the container rules for privacy and sharing apply from the first minute, not after the first leak and an end date either an expiration or a review date when the owner must confirm the site is still needed. A site without one is a site with no planned future, which in practice means a site that lives forever. Four fields. That's the entire cost. And with them every site starts live with an answer to who, why, how sensitive and until when? Then comes the part. Almost nobody builds. What happens afterward? A site shouldn't have two states alive and deleted. It should move through stages and each stage should have a trigger. Active is where it starts. People work, files change. The owner pays attention. Review is the checkpoint. When the review date arrives, the owner gets a prompt. Is this still needed? Is the membership still right? A yes extends the clock. Silence moves the site forward. Read only comes next. The site is still there, content still readable, but nobody can add or change anything. This stage matters more than it looks. It stops the quiet growth of new files in a space that's supposed to be winding down. And it tells people. Clearly this is a record now, not a workspace. Archived is where cold content goes retained because you may need it, but pulled out of the working set so it stops competing in search and stops feeding answers and deleted the end. After the retention period you've set, the site goes away and so does everything that could have been wrongly surfaced from it. Active review read only archived deleted five stages, each one smaller than the last. Without that sequence. Here's what you get. You get the picture in most tenants, thousands of sites, many created for a single project or a single quarter, and a large share of them with no living owner. The person who made the site left. The second owner was never added. The group still exists, still has members, still shows up in the index, still gets read by copilot as if it were current. Nobody's responsible for it, so nobody retires it. And every one of those sites carries old permissions, old drafts, and old claims that compete with the content people actually maintain. That's the cost of a lifecycle with only a beginning. But a lifecycle on paper changes nothing. Somebody has to enforce the review dates, find the owner list sites, and move the stale ones along across thousands of sites without doing it by hand. The lifecycle needs a mechanism, so let's get specific ownership in active sites and automated policies. Start with the owner, because every other control depends on one or two owners per site minimum. One owner is a single point of failure, and it fails the day that person changes jobs or leaves. The site keeps running, the files keep getting indexed, and nobody answers for any of it. A second owner turns that day from a problem into a handover. So make it a rule at creation, not a request. The template adds two owners or doesn't finish, but rules at creation only cover new sites. The ones that already exist drifted and owner left. The second was never added and now the site has a group with members and nobody at the top. SharePoint can find those for you and owner list site policy checks for Microsoft three hundred sixty five groups that have lost every owner. When it finds one, it emails the active members and asks someone to step up. If nobody does, you get a report you can act on, and you can decide what happens to the orphan, assign it, move it into review, or start it toward archive. That's the first automated policy, and it answers a question most tenants can't. Who is responsible for this site today? The second one targets time instead of people. SharePoint Advanced Management includes an inactive site policy. You set a window, say one hundred and eighty days, and the policy looks for sites with no meaningful activity inside it. Then it contacts the owners. Is this site still needed? The owner can confirm it and the clock resets, or the owner says no or says nothing and the site is flagged for the next stage. Notice what that does for the life cycle we just built. The review stage no longer depends on someone remembering the policy, raises the question, collects the answer, and records it at the scale of thousands of sites. That's the only version of review that happens. Silence is the signal here. A site that nobody opens and nobody defends isn't asking to stay. It's waiting to be retired. Then there's membership, which is a different kind of staleness. A site can be active and still have the wrong people in it. Someone moved to another department. A contractor's engagement ended. A guest was invited for a two week task and stayed for two years. Activity doesn't tell you any of that. Only a person who knows the team can. So run site access reviews on a schedule. The owner receives the list of everyone with access and confirms or removes each name for sensitive sites quarterly. For standard ones. Twice a year, the review lands in the owner's inbox, takes a few minutes, and produces a record of who decided what. And because we built access around groups, the review is short. You're checking a handful of group memberships, not hundreds of scattered individual entries. Skip the review and the permissions. We spent so long designing slowly stop matching reality. Now what happens when a site passes through review? And the answer is we don't need this daily, but we can't delete it. That's cold content contracts from a finished project. Records you must keep for audit material with legal value, but no working value. It shouldn't sit in the active set where it competes in search and feeds copilot answers, and it shouldn't be deleted because someone may need it in three years. That's the job of Microsoft three. Sixty five archive. You move the site into archive and it stays in your tenant with all its content, permissions and metadata intact. But it comes out of the working set. It costs less to hold than active storage, and it no longer shows up as a live source. If someone needs it, the owner or an admin can reactivate it. A reactivated site takes a short while to return, so this isn't for content. People open weekly so the pieces connect and owner policy keeps someone accountable. An inactive policy raises the question. An access review keeps membership honest and archive. Gives retired content a place to rest. Retained but silent. Each of those is a control you can switch on. What you still need is the order to switch them on in. Now let's turn all of this into a clean up sequence. Cleanup strategy. Order of operations. You now have the controls. The question is where you start. Most teams start in the wrong place. They begin with whatever feels most visible. Usually labels because a label is something you can show in a slide. Meanwhile, a site with an org wide link on the merger folder sits untouched. Sequence matters here because each step shrinks the problem for the next one. Step one is a baseline before you change anything. Measure run the data, access governance reports and the site sharing insights. Count the sites open to the whole organization. Count the files with org wide or anyone links. Count the sensitive items sitting in sites that anyone can reach. You end up with three or four numbers and they're ugly and that's fine. They're your starting line. Without them, every later claim of progress is just a feeling. Write the numbers down with a date next to each. You'll want to show the change in ninety days. Step two is the highest risk sites and only those. You won't fix everything at once, so don't try. Take the baseline and sort it by. What a leak would cost finance, HR, legal, executive, anything tied to a deal or an investigation for each of those sites. Remove the broad groups. Replace direct entries with the owner member and visitor groups, and delete the links that no longer have a purpose. If a site holds a few hundred broken inheritance folders. Review them now, not later. Twenty sites handled properly will cut more exposure than two thousand sites touched lightly. Step three is labels. Now that access on the worst sites is under control, classify what's inside them. Set the default label on each sensitive library and site so every new file arrives marked. Then run auto labeling in recommend mode against the content that already exists. Check the suggestions, tune them, and switch the accurate rules to automatic labels come third on purpose. Applied to a site that's still wide open, a label gives you a good description of a bad situation. Step four is retirement. Here the lifecycle work pays off. Pull the list of sites with no living owner and the list that tripped the inactive policy. Add the obvious duplicates the three copies of the same project site. The old team space that was rebuilt under a new name for each one. Ask the owner or the members. If there's no owner, keep it, archive it or delete it. Most will go to archive or deletion, and everyone that leaves is a source that can no longer compete with the real answer. This step is also the cheapest quality fix you have. Because it needs no new design, you're simply removing the old material from the pool. Step five is the safety net. After four steps, some sites will still be unresolved. The owner can't be found or the content is tangled, or the fix needs a decision that's two months away. For those turn on restricted content discovery. The content stays where it is and it drops out of org wide search and copilot while the repair continues. Put every one of those sites on a short list with an owner and a review date. Because as we covered, this hides the problem. It doesn't solve it. The list is how you make sure it gets solved. Run those five in order and the shape of the work becomes clear. Measure. Contain the worst. Classify. Remove the dead weight. Cover the gaps. Each step is small enough to finish, and each one makes the next step easier. But notice what you've just described a start, a middle, and a finish line with a team and a deadline. That's exactly how it will fail because tenants don't hold still. The week after you finish, someone creates a site, someone shares a folder, someone leaves and the baseline starts to move again. A cleanup that ends is a cleanup that the drift catches up with. Clean up stops working when it's treated as a project. 01:11:58 Speaker: That governance as operations, not a project. A project has an end date. Operations don't. That's the shift. Governance isn't something you finish and hand over. It runs every week, like patching or backups with people assigned to it and numbers that show whether it's working. Start with who. Three roles carry most of the weight. The first is the site owner, who we already covered the answer for one site who's in it, what's in it, whether it's still needed. The second is the data steward. This person sits in each business area, usually in a department, not in it, and knows what the content means. They decide which library holds policies, which label fits payroll data, which documents count as authoritative. It can build the controls, but I can't tell you whether a contract template is current. The steward can. The third is a small council. Five to seven people. Someone from it, someone from security, someone from legal or compliance, and a few stewards from the business. They don't review sites. They make a short list of decisions that nobody else is allowed to make, what the label set looks like, what the tenant sharing ceiling is, which sites get restricted, discovery, and who approves an exception. Notice how narrow that is. A council that tries to approve every site request turns into a queue and people route around it. A council with four defined decisions can meet for thirty minutes and still matter. Now the rhythm. Once a month the same group looks at the same three or four numbers, not twenty four is the limit. Most people will actually read. Pick them from the baseline you built in. Clean up sites open to the whole organization files with org wide, or anyone links sites with no living owner and the share of sensitive libraries with a default label. Each month the trend goes up or down and someone explains why that explanation is the point. A number that moves with no one asking why is decoration a number that moves and triggers a question? Who created these forty open sites last week? Is control. Then there's change control, which is where tenants quietly fall apart. The tenant sharing settings. The default link type, the label policy, the auto labeling rules. These are a handful of switches that affect every user at once. One admin loosens external sharing for a project on a Tuesday, and nobody tightens it again six months later. The ceiling is wider than anyone approved, so treat those settings like production changes. Someone proposes it, the council approves it. The change is logged with a reason and a date and temporary changes. Get an expiry. It's not heavy. It's a short written trail and it stops the settings from drifting one favor at a time. So why do governance programs die? Usually for the same three reasons. And they stack no operational owner. The program belongs to a committee, which means it belongs to nobody, and nobody's calendar has a recurring slot for it. No metric without a number, there's no way to tell a working program from a quiet one. So the budget conversation turns into opinion and no consequence. The review email goes out, the owner ignores it, and nothing happens. Not a reminder, not an escalation, not a site moving to read. Only people learn fast that the process is optional. Fix those three and the rest holds a named person who runs it. A few numbers that get read and a stage that follows silence so that ignoring the prompt is itself a decision, with the result that gives you a structure that keeps running after the cleanup ends. But a structure that runs is not the same as a structure that works. You've built controls, labels, metadata, lifecycle, and a rhythm to maintain them. What you haven't done yet is ask copilot to prove it works. You test it. Testing copilot against your architecture. Until now, everything has been designed. Controls, policies, a rhythm. None of it has been questioned yet. So question it. Start by building a prompt set. Not a long one. Thirty prompts is enough and they fall into three groups. The first group is sensitive data probes. These are prompts that should return nothing. What is the CEO's salary? Show me the list of employees on performance plans. Summarize the merger documents. You already know the answer. You want no content or a clear refusal. If copilot hands back a single line of real data, you found a leak with a name on it. The second group is version truth checks. These are questions with one correct answer where wrong answers exist in your tenant. What's the travel reimbursement limit? What's the current approval threshold for contracts for each one, write down the file that should be the source, not just the answer the file, because a correct answer from the wrong source is luck, and luck doesn't hold. The third group is cross site queries questions that need content from more than one place. What does our security standard say about vendor access and which contracts have exceptions? These tests, whether hubs, shared metadata and clean sites, actually let copilot assemble a coherent answer, or whether it stitches together fragments that don't belong together. Now, who asks matters as much as what they ask. Run the whole set twice, once with a low privilege account. A regular employee in a regular department with no special group memberships. Once with a high privilege account, someone senior or an admin, or a person with access to finance or HR. The low privilege run tells you about leaks, whatever that account can retrieve. A thousand other people can retrieve, too. The high privilege run tells you about coverage. Can the people who should get answers actually get them? A label with usage rights set too tightly or a site hidden by restricted discovery shows up here as an answer that's weaker than it should be. Compare the two side by side. The gap between them is your access design made visible. A small gap in the right places is a good sign. No gap at all means everybody sees everything. A huge gap in a place you didn't expect means someone restricted something and forgot to say so. Next, record everything for each prompt. Capture the answer the sources copilot cited and whether it passed a spreadsheet works four columns. Prompt answer source result. Don't summarize. Paste the actual text because the exact wording is often the clue. Then comes the discipline that separates a test from a chore fixed by cause, not by symptom. Say copilot returns an old policy. The symptom fix is to delete that file. Done. The prompt passes. But why was the old policy there at all? Maybe the site has no review date. Maybe the status column was blank. Maybe a duplicate was uploaded to a team site because the central library was hard to find. Delete the file and the same thing happens again next quarter with a different file. So for every failure, ask which layer broke a permission that was too wide, a label that was missing, a metadata field left empty. A site that should have retired. A duplicate that nobody owned. Right. The cause next to the failure. After a few rounds, patents show up and the patents tell you where to spend. Effort. If half your failures trace back to missing status values, you don't need a cleanup. You need a required field and a default. Finally, make it recurring. Run the set every quarter and run it again after anything big a site reorganization, a label policy change, a migration, a new hub structure, a clean up sprint. Those are the moments when something quietly stops working. A prompt that passed in March and fails in June is a regression, and you'll know which change caused it because you ran the set before and after. Add to the set. Over time, every real complaint from a user becomes a new prompt. Every incident becomes a probe, the list grows with your tenant, and it becomes the closest thing you have to a standing exam for your own architecture. Run it, fix by cause and run it again. That's the loop. And when the loop starts passing, you'll have something worth describing in full. Everything so far comes together in a target state. The target state what a surviving architecture looks like. Picture the tenant after the work is done. Not perfect, just legible. Every site has a reason to exist and you can read it. A project site was built from a template, so it arrived with two owners a stated purpose, a label, and an end date. A publishing site holds the approved policies with a handful of editors and the whole company as readers. A team space lives for as long as the team does. None of them is anonymous. Pick one at random and ask who's responsible. There's a name. Ask when it stops mattering and there's a date. That's the first layer. Purpose built sites with owners and expiry. One site, one job, one clock. Above them. Sit the hubs finance sites cluster under a finance hub. Legal under legal operations HR engineering each grouped by domain so search and copilot meet coherent neighborhoods instead of a flat pile of two thousand unrelated spaces. And remember what the hub is for. It organizes its scopes. It carries navigation and branding. It does not grant a single permission. Access comes from somewhere else. Groups, owners, members, visitors, each one mapped to a real person who can explain why they're in it. When someone asks who can see the payroll library, the answer fits in one sentence no scattered individual entries, no folder level exceptions that nobody remembers creating. No org wide link sitting in a forgotten email on top of access the labels. The container carries one, so the room has rules for privacy sharing and guests. The sensitive libraries default to the right label, so files arrive already marked. Auto labeling catches what slipped through, and the label set is short enough that a person in a hurry gets it right. Now look inside the libraries here. Metadata does the work folders never could. A policy is a policy from the shared content type with status owner. Effective date and audience filled in. Approved means approved everywhere. Superseded means the file has lost its claim. When two documents match a question, the system doesn't flip a coin, the fields settle it, and the answer comes from the file that someone stands behind, and the lifecycle keeps all of it honest. Sites move from active to review, to read only to archived on triggers, not on memory. The inactive policy asks the question. The access review checks the names. Owner list sites surface in a report called content rests in archive retained but out of the working set. The stale material doesn't pile up because something is always carrying it out. Put those together and copilot meets a different tenant. It still asks the same question what can this person see and what matches the prompt? But now the first half of that question has a narrow, defensible answer, and the second half has real signals to rank on titles that mean something, status that settles conflicts, fresh content from living sites tested with the prompt set and the pattern shows the probes come back empty. The version checks site the right file. The cross site questions pull from sources that belong together, and when something fails, you can trace it to one layer and fix that layer. So what actually changed? Go back to where this started. The old model was structure pages, navigation hierarchies, and the assumption that people find what they go looking for. Everything was built to be walked and obscurity quietly did the security work. The new model starts somewhere else. It starts with context. A person has a question and the tenant has to answer it from whatever the person is allowed to reach. So every piece you've built exists to make that answer. Correct access defines the pool. Labels mark the sensitive part of it. Metadata ranks what's inside lifecycle drains what's dead, not a taller hierarchy, a tenant that can explain itself one file at a time. But a design this clean doesn't hold itself up. Somebody has to own the information risk. Somebody has to decide how much exposure is acceptable and how fast to get there. And somebody has to fund the weekly work after the clean up team goes home. None of those are technical decisions. What leadership must decide to make this stick is where it lives or dies. The executive layer decisions only leadership can make. Start with the question that sounds simple and never is who owns information risk? Ask it and they'll say security does. Ask security and they'll point at the business because the business created the content. Ask the business and they'll say that's why they pay for it. Three groups, each holding a piece and each one assuming another is holding the rest. So in most organizations, nobody owns it, not on paper. And a risk with no owner doesn't get managed. It gets discovered usually by an auditor or by an employee who just read something they shouldn't have. Here's a split that works. The business owns the content and the decision about who needs it. Security owns the rules and the measurement. It owns the controls and keeps them running. But one executive has to hold the outcome one name with the authority to say yes to a fix and no to an exception. Without that person. The council we described has nobody to escalate to, and every hard call turns into a meeting about the meeting. That's decision one. Put a name on the risk. Decision two is a number. How much exposure is acceptable? Nobody likes this question because the honest answer feels wrong. Zero sounds right. It's also not real. Some content will be shared too widely this quarter, however good the design is. So the question becomes how many sites open to the whole organization? How many org wide links, how many unlabeled sensitive libraries can you live with, and for how long? Take the baseline from the cleanup. Set a target for each metric, then set a date ninety days to bring broad access on the highest risk sites to zero. Six months to get default labels on every sensitive library a year to retire the ownerless sites. Those are choices, and they trade speed against disruption, move fast and people lose access to things they were quietly using. Move slowly and the exposure sits there while copilot keeps answering. Only leadership can make that trade. It can recommend a pace, but it can't absorb the complaints that come with it. Decision three is money, and it's the one that quietly kills everything. Cleanup gets funded. It has a start date, a team, a budget line, and a finish line. You can put on a slide. Governance doesn't. It has no finish, so it has no line. And the week after the project closes, the people who ran it moved to the next initiative and the monthly review loses its owner. You've seen what follows. The numbers stay flat for a quarter. Then they start to climb new sites, new links, new departures, and nobody watching the trend. Eighteen months later, someone proposes a second cleanup project and the cycle starts again. So funded as operations, a named person with real hours. Not a spare afternoon. Time for the stewards in each business area, a budget for the licensing that makes the reports and policies possible, and for the testing that proves they work. It's a small recurring cost, and it's much cheaper than the repeated rescue. Now tie it to what leadership actually cares about. Audit readiness. When a regulator or a customer asks who can access a given set of records, you answer with a report, not a scramble. Owners are named, reviews are logged and changes have a trail. Trust in AI answers. Adoption of copilot doesn't fail on features. It fails the first time a respected manager gets a wrong answer from an old document and tells their team not to bother. Clean structure is what keeps that story from spreading and reduced incident risk. Fewer open sites, fewer forgotten links. Fewer places where a mistake turns into a headline. Three decisions an owner, a number, and a budget that doesn't end. Conclusion. Context is the new starting point. Copilot finds whatever your structure allows, not what you intended, what the structure allows. If this changed how you look at your tenant, leave a review. It helps more people find the show. And if you want to keep going, connect with me, Mirko Peters on LinkedIn and tell me which topic should come next. The tenant will answer for you whether or not you built it to.