Leadership has approved Microsoft 365 Copilot. Licenses are assigned. And then someone asks IT the question nobody’s prepared for: “Is our content ready?”
Most admins don’t have a clean answer. Not because they haven’t thought about it, but because “ready” is a bigger word than it looks. Microsoft Copilot governance starts before deployment. It starts with whatever your tenant already looks like.
Here’s the thing about Copilot: it doesn’t create new access problems. It inherits the ones you already have. It works with the search index, which is the register of everything in the tenant that users have access to. That includes the five-year-old project site nobody’s touched; the document library with “anyone with the link” still enabled; the OneDrive of someone who left two years ago, full of files still shared with the wider team; and 800 versions of a marketing deck that nobody can explain.
Copilot amplifies whatever signal your content already contains. A well-governed tenant produces accurate, useful AI responses. A sprawling, overshared, version-bloated tenant produces noise, and sometimes surfaces content that should never have been broadly accessible in the first place.
This post maps the three governance gaps that most directly block Copilot readiness. If you’ve been following our series on M365 storage, you already know the problems. What’s new is the urgency.
Before we get into the gaps, it’s worth being precise about the mechanics. Microsoft’s documentation is clear: Copilot accesses content through Microsoft Graph and respects your existing Microsoft 365 permissions. It doesn’t have its own access model. If a user has read access to a file, Copilot can surface that file to them. If a file is shared with “anyone with the link,” Copilot treats it the same way.
Your existing governance posture is your Copilot posture. Every permission gap, every overshared site, every stale library with no active owner is now part of the dataset Copilot is working with.
The scale of that problem is significant. Varonis’ 2025 State of Data Security Report, based on analysis of over 1,000 real customer environments, found that 99% of organizations have sensitive data exposed to AI tools, including Copilot. The same report found that the average M365 tenant has over 27,000 sharing links, with roughly half open to all employees.
One more thing to flag upfront: content in Microsoft 365 Archive is currently excluded from Copilot’s index. That matters more than most people realize, and it’s covered in detail below.
Microsoft’s own guidance on getting ready for Copilot with SharePoint Advanced Management identifies three readiness pillars: manage content sprawl, prevent oversharing, and manage content lifecycle. That’s a useful frame.
But most tenants have all three gaps running at once, and they’re connected. Here’s what each one actually looks like.
Content sprawl isn’t just a storage problem. It’s a signal quality problem.
Here's what that looks like in the SharePoint Admin Center. Every row in this list is a site consuming active storage and sitting in Copilot's index, whether anyone's used it in the last month or the last three years.
Sprawl looks like this:
None of that content is being actively managed. But Copilot is indexing all of it.
When an employee asks Copilot to summarize recent work on a topic, the response draws from current, relevant files and from years of outdated drafts, superseded documents, and context-free legacy content simultaneously.
The result is less precise responses, and in some cases, surfacing of sensitive content from old projects that’s technically accessible but practically irrelevant or confidential. This is Microsoft 365 content sprawl reframed as an AI risk. They’re the same underlying issue.
The scale is real. Varonis research consistently finds that the majority of files in enterprise environments are stale or never accessed after creation. On average, 70% of sensitive files in financial services organizations are stale, and similar patterns hold across industries. The majority of what Copilot is indexing in most tenants is probably outdated.
If you’ve been following this series, you already know that stale sites and version bloat are the biggest drivers of M365 storage costs. The same content that’s inflating your storage bill is also degrading your Copilot results. These aren’t separate problems.
See why version history quietly dominates your storage and how to build a sustainable storage strategy for the mechanics.
Oversharing is the governance gap that gets the most attention in Copilot conversations, and for good reason.
The risk is direct: Copilot doesn’t evaluate whether a file should be accessible to a user. It checks whether the user currently has access. If your sharing permissions are broader than intended, because of “anyone with the link” shares that were never revoked, organization-wide sharing links on sensitive libraries, broken permission inheritance, or orphaned external shares from past projects, Copilot will surface that content to users who probably shouldn’t see it.
A Gartner survey of 132 IT leaders found that oversharing concerns caused 40% of organizations to delay Copilot rollouts by three or more months, while 64% said information governance and security risks required significant time and resources to address during deployment.
The scope of the problem becomes concrete fast. Here's a single workspace in Orchestry: 323 sharing links, 44 of them anonymous, 382 open to anyone in the organization. Multiply that across hundreds of workspaces and you start to understand why 40% of IT teams hit pause on Copilot rollout.
One piece that’s often underestimated: sensitivity labels. Labels are the primary mechanism for controlling how content is classified, accessed, and handled by Copilot.
Microsoft’s guidance on configuring data security for Copilot makes sensitivity labels the first recommendation. But Varonis found that only 1 in 10 organizations has any sensitivity labels applied to their files at all. Unlabeled content is unclassified content, and Copilot has no way to treat it differently.
The process of fixing oversharing is a longer conversation than this post has room for. We’ve covered the full remediation approach previously, starting with what oversharing actually is in Microsoft 365. The short version: audit your sharing links, apply least-privilege access principles, and get sensitivity labels onto your most sensitive content before expanding Copilot access.
OneDrive is worth naming as a separate risk surface. Files in personal drives often bypass the governance processes that apply to Teams and SharePoint, and overshared OneDrive content can surface through Copilot when it's been shared with or accessed by other users.
If you haven't audited sharing in OneDrive, that's a significant blind spot. More on that in the OneDrive storage blind spot.
The third gap is less visible than the first two, but it makes both of them worse.
Content with no lifecycle strategy accumulates indefinitely. Sites created for a project that ended two years ago. Document libraries with no activity, no active owner, and no governance metadata.
Copilot indexes all of it. There’s no automatic mechanism in M365 that removes content from the Copilot index when it goes stale. That requires a governance decision. Without lifecycle policies in place, those decisions never get made, and the content keeps accumulating.
The practical challenge is that without lifecycle rules, IT can’t distinguish between content that’s inactive-but-needed, like archived project records or compliance documentation, and content that’s inactive-and-abandoned. Copilot can’t make that distinction either. So both stay in the active index, surfaced on equal terms with your current, relevant content.
Fixing this requires establishing site lifecycle policies, assigning owners to workspaces that currently have none, and routing inactive content through a review process.
Here’s something most Copilot readiness conversations miss entirely: archiving inactive content doesn’t just save money. It actively improves what Copilot returns.
When a site moves to M365 Archive, it drops out of Copilot's index entirely. The SharePoint Admin Center's archived sites view shows exactly what's been removed from the active dataset.
Microsoft’s documentation on Microsoft 365 Archive states this directly: “Copilot is not trained on archived content, maximizing response relevancy.” When you move an inactive site to M365 Archive, you’re not just shifting it to cheaper storage at $0.05/GB/month instead of the $0.20/GB/month rate for active storage. You’re removing it from the dataset Copilot draws from.
That reframes the archiving conversation. Admins who’ve been treating archive purely as a cost lever now have a second reason to act: every inactive site you archive is one fewer source of stale, context-free content that Copilot has to work through. Better archive hygiene directly translates to better AI signal quality.
The sites most worth archiving for Copilot purposes are exactly the ones this series has been covering: completed project spaces, legacy department sites, migration remnants with no active ownership. Moving them to archive cuts your storage bill and tightens the Copilot index at the same time.
One nuance: this applies to site-level archiving with M365 Archive. File-level archiving is currently in preview as of the time of writing. For the full picture of how archive fits alongside retention and backup, see Microsoft 365 Archive, backup, and retention: What each one does.
On the roadmap: Microsoft has indicated that archive searchability may evolve, but don’t plan your Copilot governance strategy around undated future changes. The behavior described here reflects current confirmed functionality. See Microsoft’s archive overview for the authoritative current state.
Before expanding Copilot access, you should be able to answer these five questions.
This isn’t a pass/fail test. It’s a diagnostic. If you can’t answer them confidently, you’ve found your starting point.
If the honest answer to any of these is “I’m not sure,” that’s where to start. Copilot will find all of it.
The three gaps above are solvable. The challenge is doing it at the scale of a real enterprise tenant.
Native M365 tools will get you started. The SharePoint Admin Center shows you site activity and storage consumption. PowerShell can pull sharing link reports. But working through hundreds or thousands of sites, making lifecycle decisions, routing cleanup to the right owners, tracking what got resolved, and keeping it from drifting back over the next six months is an operational problem, not just a visibility one.
This is what that looks like in practice.
Orchestry's Copilot readiness tab scores each workspace against the governance signals that directly affect Copilot quality: sharing links, links without expiry dates, sensitivity label coverage, broken inheritance. You can see at a glance where the risk is, and the Usage Markers section shows which documents are actually being queried by Copilot and how often.
Orchestry gives IT teams the visibility and automation layer that makes this workable at scale. Specifically:
Microsoft gives you Copilot and the governance tools to make it work. Orchestry makes those tools actionable at the scale of your real environment. When you expand Copilot, you’re expanding on a clean foundation, not on years of accumulated governance debt.
For a fuller picture of what that looks like in practice, see how to prepare your M365 content for Copilot and the SharePoint governance guide for Copilot readiness.
Copilot doesn’t transform how well-governed your content is. It reflects it.
Organizations with clean, actively managed tenants will get proportionally better AI outputs. Organizations with sprawl, broken permissions, and no lifecycle strategy will get that reflected in their results too, and in some cases, in the form of content surfaced to people who shouldn’t be seeing it.
The good news is that Copilot readiness isn’t a new category of work. It’s the same work this series has been covering all along: clean up stale content, tighten sharing permissions, build lifecycle policies, archive what no longer needs to be in the active index. These tasks have always been worth doing. They’re just more urgent now.
If you want to see what Copilot is actually working with in your tenant today, start with a governance review. See where your tenant stands and what to fix first.