The organizations that have been through a serious M365 security incident share a common experience afterward. There's a response. Access gets tightened. Ownership gets assigned. A review cadence gets built and committed to. The work is real, the intentions are good, and it holds, for a while. Then someone key leaves. A new workload rolls out. A feature ships with permissive defaults nobody caught in time. And twelve months later, the same categories of problems are back, slightly different shape, same root cause.
The issue isn't execution. Most governance programs execute fine. The issue is that they're designed to reach a destination rather than maintain a state. Once the project closes, the pressure that was keeping everything aligned disappears, and the platform quietly resumes doing what it always does: creating resources, accumulating exceptions, and preserving whatever access state it finds itself in.
The only way out of that loop is building governance into how the organization runs M365 day to day, not as a periodic project that corrects for drift, but as a continuous model where drift can't accumulate past a certain threshold before something forces a decision.
That model rests on four things. Not frameworks, not checklists. Four operational requirements that have to be true continuously, not just at the moment a project closes: ownership, lifecycle, enforcement, and transparency. Get all four working and governance maintains itself. Miss any one of them and the others eventually compensate until they can't.
Before getting to the operating model, there's a simpler diagnostic. A governed M365 tenant should be able to answer three questions on demand. Not eventually, not after a week of exporting CSVs, but in response to a real-time request from an auditor, an incident responder, or an executive.
If any of these questions can't be answered on demand, the tenant has a governance gap. Not a process gap, not a tooling gap: a structural gap in accountability. The operating model exists to close these gaps and keep them closed.
This distinction is the most important one in the series. It determines whether governance survives or degrades after the initial deployment.
- There's a defined scope, a deliverable, and an end date
- Settings deployed and signed off as complete
- Access reviews configured and handed to IT to run
- Training delivered, documentation posted somewhere
- Project closes, everyone moves to the next thing
- No process to evaluate new features as they ship
- Exceptions build up with no expiration dates
- Owners leave and their groups quietly become ownerless
- Six months later you're scoping another cleanup
- No close date. It runs continuously or it degrades.
- New features get evaluated against the existing model before users see them
- Exceptions require an owner and an expiration date before they're approved
- Offboarding triggers an ownership check on every group the departing user owns
- Reviews are designed to produce decisions, not approvals
- Drift gets detected and remediated automatically, not surfaced in a quarterly report
- The three questions are answerable on demand, not after a week of exports
- Turnover, new features, and AI deployment don't break the model
- No cleanup campaign needed because nothing accumulates past its threshold
The four operational requirements below aren't features to enable or boxes to check. They're conditions that have to stay true in the background, maintained by process and automation, regardless of who's paying attention to governance that week. Each one supports the others. When ownership is verified, lifecycle reviews have someone to send to. When lifecycle is enforced, enforcement actions have a clear trigger. When enforcement runs automatically, transparency becomes the proof that it worked.
| Primitive | What It Means | How It Fails Without Design | Operating Requirement |
|---|---|---|---|
| Ownership | Every resource in the tenant has a named, accountable individual who can make decisions about it | Owners leave. Resources persist. Nobody inherits the accountability because nobody designed the handoff. | Enforced minimum owners, verified ownership (not just assigned), offboarding triggers resource audit, escalation path when ownership gaps surface |
| Lifecycle | Every resource has a start date, a use phase, a review trigger, and an end-of-life event | Resources accumulate indefinitely. No defined end state. Quiet workspaces stay accessible with stale guests and expired-but-never-removed sharing links. | Expiration policies with enforced renewal, non-response defaults to archive not extension, guest expiration tied to account lifecycle not just group membership |
| Enforcement | Controls use the real enforcement verbs: block, force, expire, escalate, remediate. Not just report. | People approve things they don't understand. Reviews become a formality. The system treats every unchallenged approval as deliberate authorization. | Every control mapped to an enforcement verb. Reviews with consequence. Drift detection connected to automatic remediation or escalation with SLA. |
| Transparency | The three questions can be answered on demand: what exists, who owns it, why is access allowed | Governance is tribal knowledge. Audits require weeks of CSV exports. Incidents can't be scoped quickly because nobody knows what exists. | Cross-workload inventory updated continuously. Ownership records current. Access decisions traceable to a named approver with a documented reason and review date. |
The four requirements above don't maintain themselves through intention. They need a cadence: a set of recurring actions at different frequencies that match each type of problem to the rate at which it tends to develop. Daily issues need daily triggers. Slower accumulation needs a monthly or quarterly window. The cadence is what separates a model that's actually running from one that's just written down.
- Offboarding workflow triggers ownership audit for departing employee's groups
- New resource creation requires owner assignment before provisioning completes
- Sharing link expiration enforced at tenant level — no indefinite links without review
- DLP and CA policy alerts routed to named owners with response SLAs, not just IT queue
- Ownerless group report reviewed and actioned — any group hitting zero owners triggers immediate escalation
- New M365 feature releases reviewed against governance model — defaults assessed before features reach users
- Guest accounts approaching expiration flagged to sponsors for renewal decision
- CA policy exclusion group membership reviewed — every exception group audited for continued validity
- SharePoint oversharing report reviewed — sites with anyone-with-link files prioritized for remediation
- Stale guest accounts (90+ days inactive) reviewed and disabled pending sponsor confirmation
- Power Platform default environment reviewed for ungoverned flows and connectors
- Full access review cycle for guest accounts — removal as no-response outcome
- Dynamic group rule audit — all rules reviewed against current attribute schema
- Privileged role review — all PIM-eligible and active assignments confirmed
- Sensitivity label coverage report — % of sensitive content labeled tracked as KPI
- Governance model review — exceptions, bypasses, and new features logged and assessed
- Full tenant inventory reconciliation — all groups, sites, automations, and agents inventoried against documented ownership
- Governance model fitness review — does the current model cover new workloads, new roles, new external relationship types?
- CA policy architecture review — does the current policy set still reflect the organization's actual risk posture?
- Copilot/AI surface review — authorization model reviewed against expanded AI surface as new capabilities deploy
Every cadence item above is designed to produce decisions, not approvals. The failure mode is when the cadence becomes a ritual. Reviewers approve everything quickly because declining creates work, because they don't recognize the resource, because the owner left and they inherited the responsibility without the context. Approving because you don't know is worse than not reviewing at all. It converts uncertainty into permanent authorization and gives the organization false confidence that the review process is working.
Design reviews to be answerable. Context needs to be visible in the review interface: what the resource is, what it controls access to, when it was last active, who is in it. A reviewer who can't answer the three questions shouldn't be able to click approve.
This series started with a guest account that nobody offboarded and ended here. Along the way, it built the case for why governance fails the way it does, and it's not because of bad intentions or missing tools. but because the place where settings are managed and the place where work actually happens are two different places, and the gap between them accumulates silently until something forces it to the surface.
The thread running through both this series and the Identity Foundations series before it is the same idea at different layers. You can lock down authentication perfectly and still have a governance problem. You can have great CA policies and still have guests in groups that nobody owns, connecting to SharePoint sites that nobody is monitoring, with Copilot querying all of it on behalf of users who had no idea the access existed.
Security investments protect the entry point. Governance is what determines whether everything behind the entry point is in the state you think it's in. The two have to work together, and governance has to run continuously, not because anything went wrong, but because the platform keeps changing and people keep creating resources and the default for anything that doesn't get actively managed is that it persists.
Verify the ownership. Close the lifecycle. Connect every finding to an action. Keep the three questions answerable. That's the model. When it's working, you don't need a cleanup campaign because there's nothing left to accumulate.
Want More?
Follow along for more writing on M365 security, identity, and the real-world thinking behind modern cyber defense.
Read More on Medium