Part 6 of 7 · Governance Debt
There’s a single question that collapses most Microsoft 365 governance programs, and an auditor can ask it in eight words: who approved this access, and when?
Pick anything from the previous five parts of this series. The site shared with “Everyone except external users.” The document library nobody has opened since 2021. The Copilot Studio agent a departed maker built in a personal environment. For each one, the auditor’s question has a right answer somewhere in principle — a person who granted the access, a date, a business reason. In practice, the answer is a shrug. Not because anyone hid it. Because nobody was ever asked to record it, and nobody has been asked since to confirm it still holds.
That missing loop — the recurring act of a named human confirming that a thing is still needed, still correctly owned, and still appropriately shared — is attestation. Its absence is the quiet reason the whole estate drifts.
Ownership: the orphans Microsoft expects you to have
Start with the simplest form of accountability: does this thing have an owner who still works here?
For an enormous amount of the estate, the answer is no — and Microsoft knows it, because it ships tooling that assumes it. When you delete a departed employee’s account, every Microsoft 365 group and Team they solely owned becomes ownerless, and Microsoft provides an ownerless group policy whose entire job is to email active members and beg one of them to adopt the group. On the SharePoint side, site ownership policies let you set a minimum owner count and flag every site that falls below it — and the hard enforcement actions, locking a site read-only or archiving it, are reserved specifically for “ownerless (zero owner) sites, where there’s no accountable party and the governance risk is highest.” Those are Microsoft’s words.
You don’t build a “minimum owner count” control and a “find the ownerless groups” audit search unless abandonment at scale is the expected condition, not the exception. It is. And it’s not limited to sites and groups — the agents from part five orphan the same way, the moment the maker who built one changes teams or leaves. An asset with no owner has no one to answer the auditor’s question, no one to receive the access review, no one accountable when it’s the thing that leaks.
Recertification: access that was granted once and never revisited
Ownership is who’s responsible for the container. Recertification is whether the people inside it still belong there.
Most access in a mature tenant was granted once, for a reason that made sense that week, and never looked at again. The contractor added to a site for a two-month project. The whole-team grant that made onboarding easy. The guest invited for one workshop in 2022. None of it expires on its own. Microsoft’s answer is access reviews in Entra ID Governance, and the questions the docs use to justify the feature are exactly the ones a CISO can’t currently answer: “As people move teams or leave the company, how do you make sure that their old access is removed?” and the blunt observation that “excessive access rights can also lead to audit findings as they indicate a lack of control over access.”
Recertification is the discipline of periodically re-confirming access instead of assuming it. Set as a recurring review, it turns “everyone who was ever granted access still has it” — the default state — into “access someone deliberately reconfirmed this quarter.” Without it, every grant from every prior part of this series simply accumulates, permanently, with no expiry and no record of a decision.
Attestation: the loop that was never closed
Ownership and recertification are two instances of the same missing habit, and Microsoft has now named the general form of it directly. Alongside inactive-site detection, SharePoint’s site lifecycle management includes site attestation policies, which “request periodic confirmation that a site is still needed and meets organizational requirements” — and, pointedly, exist to “validate ownership and accountability” on a schedule. Unlike an activity check that infers a site is fine because someone touched it, attestation demands an explicit review from a designated owner. Someone has to look, and say yes, this is still ours and still correct.
That’s the loop. Governance isn’t a one-time cleanup; it’s a cycle that closes when a named person periodically re-affirms the state of what they own. Grant, then re-confirm. Create, then re-justify. Own, then re-attest. Every debt this series has described — the oversharing, the ROT, the invisible agents — persists precisely because that loop was never running. The access was granted and the loop stopped there.
What “who approved this” actually requires
To answer the auditor’s eight-word question across the estate, you need three things that most tenants have never assembled together:
- An owner for every asset — site, group, and agent — who currently works here, so there’s a party accountable to ask. Orphans aren’t a tidiness problem; they’re a hole where accountability should be.
- A recertification cadence for access, not a one-time grant, so “who can reach this” reflects a recent deliberate decision rather than a decade of accretion.
- An attestation trail — a durable record of who confirmed what, and when — so the answer to “who approved this access?” is a name and a date, not a shrug.
None of this is exotic; the native building blocks exist and are worth turning on. What’s missing in most estates is the loop itself — the recurring, owned, recorded act of confirmation — running consistently across sites, access, and agents at once.
And here’s the trap that makes it urgent: this problem doesn’t sit still. Every new site, every new maker environment, every new agent arrives already owning its own future orphan, its own un-recertified access, its own missing attestation — and the estate only ever gets bigger. Which is where this series ends: not with the size of the mess today, but with the interest it charges tomorrow.