The quick answer is: Yes, a capable Microsoft 365 admin can build a SharePoint audit with Graph, PnP PowerShell, and Purview data, and for a small, stable tenant that may be all you need. The catch is what comes after the build. An audit is a snapshot that ages fast, and once Copilot is reading across your tenant, a three-month-old audit can be technically correct and still miss your real exposure. The question isn't whether you can build an audit. It's whether you want to own the machine that keeps it current.
Go Commercial or DIY?
It's not too often I read online community forum discussions, but recently I came across a Reddit thread where a Microsoft 365 admin asked a question that stopped me in my tracks:
What's stopping me from building my own SharePoint audit app instead of paying for the commercial tools?
Then one commenter went further and described what he had already built: SharePoint feeding Azure Functions, queued into SQL, permissions expanded and snapshotted over time, surfaced in Power BI with row-level security.
That's definitely not a weekend script project. It looks more like a working governance pipeline. So this whole conversation got me thinking, and instead of adding my comment to the thread, I ended up writing this article.
Can You Build Your Own SharePoint Audit?
Building your own SharePoint audit tool is absolutely possible. With an Entra app registration granted Sites.FullControl.All, certificate-based auth, and the PnP PowerShell module, you can enumerate every site collection, walk lists and libraries, and flag broken inheritance and direct grants. Public scripts on GitHub already do exactly this, and the official PnP script-samples gallery ships a permission-audit sample maintained by the community. The capability is there and the barrier to entry is low.
So the starting point is agreement, not argument. If you're a capable admin, you can build this. The interesting question isn't whether you can. It's what happens when you do.
What Can a DIY SharePoint Audit Actually Do?
A homegrown audit can surface most of the core signals a commercial tool reports. With the APIs and a few scheduled jobs, you can pull:
- External sharing across sites and the links that created it
- Inactive sites and workspaces
- Permission inheritance and where it breaks
- Owners and members per workspace
- Sharing links, including anonymous ones
- Activity signals over time
- Historical snapshots, if you store and compare each run
That list covers the questions most audits are built to answer. For a tenant that's small, stable, and run by someone who knows it well, a homegrown audit against these signals is a legitimate solution.
Why Does a Homemade Audit Get Expensive to Keep?
While the build is totally doable, keeping it accurate and running is where the real cost hides. From a technical perspective, the problem isn't building a script that can audit SharePoint. We can all do that. The challenge is making it reliable when the tenant grows.
Once you move beyond a few hundred sites, the number of API calls grows very quickly. A simple audit can turn into thousands of requests when you start looking at permissions, sharing, owners, activity, storage, lists and libraries. At that point, throttling becomes a real engineering concern.
You need controlled concurrency, retry and backoff, pagination, failure handling, and the ability to resume a scan without starting everything again. And some of the hardest parts stay invisible until you hit them:
- Effective access buried inside nested Entra groups
- Unique permissions that fan out as they break from inheritance
- The least-privilege problem of the audit app itself, which now holds tenant-wide read access
An audit is also rarely a one-time exercise. Microsoft 365 changes continuously, tenants change continuously, and your audit logic has to change with them. APIs evolve, permissions change, new workloads appear, and what looked like a governance problem six months ago may not be the right signal today.
So building the first version might take days or weeks. Keeping it reliable becomes an ongoing engineering responsibility. You're not maintaining a script. You're maintaining a small product, with monitoring, error handling, API changes, security, data storage, reporting and support.
My question as a CTO isn't "Can we build our own SharePoint audit?" Sure we can. The question is: "Is maintaining that infrastructure really where we want our engineering time to go?"
| Building it yourself | A governance platform |
|---|---|
| You define exactly what you need | Pre-built controls out of the box |
| You maintain every Microsoft 365 API change | The vendor absorbs those changes |
| You build reporting and history | Dashboards and history are included |
| You build remediation later, if ever | Remediation and actions are built in |
Is Native Microsoft 365 Governance Enough?
For many tenants, native Microsoft 365 governance is enough, and I want to be transparent about it.
SharePoint Admin Center, Purview, Entra ID access reviews, and SharePoint Advanced Management cover more ground than most buyers realize, and the more common reason organizations start shopping is that capability is fragmented across four consoles rather than missing. Native tooling is sufficient when your site count is manageable, provisioning volume is low, and Purview labels and retention meet your compliance needs.
The tipping point, for me, is when the requirement changes from "I need to answer a question" to "I need continuous visibility of my tenant." Once you need recurring scans, historical comparison, governance scoring, actionable findings, remediation, and confidence that the results are complete across a growing environment, you're no longer solving a reporting problem.
You're operating an audit platform. That's the point where I'd stop recommending that an internal team build it themselves.
Is Audit > Visibility > Governance > Remediation the Whole Story?
The common way to frame this, and the way I framed it myself at first, is as a progression: audit, then visibility, then governance, then remediation.
A capable SharePoint administrator can perform an audit. They run reports, inspect permissions, identify inactive sites, build scripts to collect information. That gives you data.
Visibility is the next step: turning that data into a picture of what's actually happening across the tenant. Which sites are risky? Which problems are growing? Where are the biggest governance gaps?
Then comes governance, where you move from "we found 200 issues" to "these are the standards we expect the environment to follow, and these are the exceptions."
And finally, remediation. This is where even very capable administrators often stop one step too early. They identify the problem, document it, maybe send someone an email, and then the issue goes back into a spreadsheet or a ticket queue. For me, the real value is closing that loop: find the issue, understand its impact, decide what should happen, and take action.
But this progression assumes the audit at the bottom is solid ground you build on once. And in 2026, that assumption is exactly where it breaks.
Why Does a Clean Audit Expire?
A clean audit expires because it captures a single point in time, and in an AI-enabled tenant the ground underneath it keeps moving. A three-month-old audit can be technically correct and still tell you very little about your current risk.
Imagine an administrator runs a thorough SharePoint audit in January. Permissions look good, external sharing is under control, inactive sites are identified, and the tenant gets a clean bill of health.
Now move forward three months. Copilot and other AI experiences are operating across the tenant, users are retrieving information in natural language from content they can access, and in the meantime new sites have been created, permissions have changed, documents have been shared, and content nobody thought was important has become discoverable through AI. Nothing necessarily broke. The audit simply captured one moment.
That's the difference I think we need to understand in 2026. The question is no longer only "Who can access this site?" It's "What can AI discover and surface based on the access that exists today?"
Microsoft's own deployment blueprint now puts remediating oversharing first, before a Copilot rollout, because Copilot grounds its answers in whatever content a user already has permission to reach. A traditional audit might tell you a user has access to a site. What it won't tell you is that the combination of that access, the content inside the site, and today's AI experiences creates a completely different level of exposure than the administrator was considering three months ago.
That's why I don't see tenant auditing as a once-a-year compliance exercise anymore. In an AI-enabled Microsoft 365 environment, visibility has to be continuous. The environment changes. The way people access information changes. And now, the way machines can reason over that information changes too.
So, Do You Really Need a Tool?
Maybe not. If your tenant is small and stable and you're happy owning the machine that keeps the audit current, building it yourself is a legitimate choice.
But once visibility has to stay continuous, the question stops being "how mature is our governance" and becomes "who keeps this current, and is that how we want to spend our time." That's a different decision, and it's the one the Reddit thread was really circling.
It also changes what you need from the output. An audit report tells you a site has 37 users with access, which is useful. A governance view tells you that 37 users have access, 12 of them haven't opened the site in 180 days, 4 are external, 2 hold direct permissions outside any group, the site has no owner, and its sharing configuration breaks your policy. Then it tells you what to do about each one.
That's the gap that Pulse365 can close. It reads those signals together, scores their impact on the tenant's Integrity Score, prioritizes them by severity, recommends the specific actions to take, and lets an administrator remediate from the same place, continuously rather than once a quarter. The audit produces the facts, but Pulse365 turns them into a decision and an action.
If you build it yourself, that's fine. Just make sure you understand that the real challenge isn't running the audit. It's keeping visibility, governance, and remediation continuous as your tenant changes.
FAQ
Can you audit SharePoint permissions without a third-party tool?
Yes. Using an Entra app registration, the Microsoft Graph API, and the PnP PowerShell module, an admin can report on site permissions, external sharing, inheritance breaks, and ownership across a tenant. The homegrown approach works well for smaller, stable environments, and its main cost is the ongoing maintenance of the scripts as Microsoft changes its APIs.
What permissions does a SharePoint audit script need?
A tenant-wide audit typically requires an Entra app registration with SharePoint Sites.FullControl.All and Graph read permissions such as Sites.Read.All and Directory.Read.All, authenticated with a certificate so it can run unattended under conditional access. These are high-privilege grants, so the audit app itself becomes something to secure and monitor.
How often should you audit SharePoint permissions?
A single audit is a snapshot that ages quickly, because sharing links, group membership, and permissions change continuously. In a tenant where Copilot is active, effective access can change what AI tools can read from one day to the next, which pushes most organizations toward continuous monitoring rather than a periodic scan.
Does Microsoft Purview replace a governance platform?
Microsoft Purview governs the content inside SharePoint through classification, sensitivity labels, and retention, and it covers a real range of compliance needs. Purview does not, on its own, unify permissions visibility, workspace lifecycle, and remediation into a single operating view, which is the gap a dedicated governance platform fills.
What is the difference between a SharePoint audit and SharePoint governance?
A SharePoint audit reports the current state of access, sharing, and activity at a point in time. SharePoint governance keeps that state correct over time by monitoring continuously, flagging what needs attention, and remediating issues before they become exposures.
