Organisations should centralise the policy decision while preserving clear operational guardrails for revocation. If remediation lives only with platform admins, the response path is usually too slow for frequent oversharing. The better model is one where security can identify and remove offending identities quickly, with logging and approval boundaries in place.
Why centralising the policy decision is usually better
The practical split is between policy and execution. Security should own the remediation policy, meaning who is allowed to approve, prioritise, and trigger removal of access, while platform teams keep the operational hooks that actually remove access in Microsoft 365. That separation gives faster response without turning every case into an ad hoc admin judgment, which is important when oversharing or excessive access is discovered repeatedly.
Centralising policy also improves consistency. If each Microsoft 365 admin decides independently, you get uneven thresholds for what counts as acceptable exposure, different handling of exceptions, and weaker auditability. A central model makes it easier to align remediation with CISA Known Exploited Vulnerabilities Catalog style urgency, where high-confidence exposure should be handled quickly rather than queued behind normal platform work.
That does not mean central security should become a bottleneck. The decision should be central, but the removal path should be pre-authorised for defined cases so that repeated oversharing, stale permissions, or obvious misuse can be remediated without waiting for a long approval chain.
Where Microsoft 365 admins should retain control
Microsoft 365 admins still need operational authority over tenant-specific actions, because they understand service dependencies, mailbox behaviour, delegated settings, and downstream breakage risks. If remediation involves shared mailboxes, app registrations, transport rules, or conditional access side effects, the person making the change needs enough platform context to avoid creating a larger outage while fixing the exposure.
The better model is not “security versus admins”, it is role clarity. Security should be able to identify the offending identity, classify the exposure, and initiate revocation, while admins execute the technical change and validate that the access path is actually closed. This is especially important for access mechanisms where hidden dependencies can make a simple revocation unsafe without coordination.
For recurring access issues, the most useful control is a standardised remediation pattern: detect the issue, confirm blast radius, revoke or restrict access, and record the exception path. That pattern is stronger than relying on a single team’s judgement each time, and it fits broader account and access governance practices described in Mimecast certificate compromise 2021, where access-bearing material was abused against Microsoft 365 tenants.
What a workable operating model looks like
A workable model is central governance with delegated execution. Security sets the rules for what must be remediated, what evidence is required, who can approve exceptions, and what logging must exist. Microsoft 365 admins keep the tools and runbooks for executing the action. This avoids a pure ticket queue while still preserving control over changes that affect tenant stability.
In practice, the best division of labour is usually:
- security identifies the risky identity or permission pattern;
- platform admins execute the change in Microsoft 365;
- both teams verify that the permission or sharing path is gone;
- exceptions are time-bound and logged.
That model becomes more compelling as identity sprawl grows. It also lines up with access control and audit expectations in CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls, both of which treat access control and auditability as operational disciplines, not one-off help desk tasks.
Risk and Threat Considerations
When remediation is left only with platform admins, the main risk is speed. Overshared files, excessive mailbox permissions, and risky delegated access can remain active long enough for abuse, especially when the issue is discovered by monitoring rather than by a user report. Slow response also increases the chance that teams normalise exceptions instead of removing them.
Failure mechanism: The organisation creates a single operational choke point, so high-volume access cleanup depends on admin availability, ticket backlog, and informal prioritisation rather than a defined security response path.
Impact: Exposure lasts longer, incident response becomes less predictable, and the organisation is more likely to miss the window for quick revocation before data is copied, forwarded, or shared further.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Access remediation hinges on managing accounts and removing excess access quickly. |
| Recommendation — Standardise account remediation workflows and revoke excess access promptly. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The question is about who governs and executes account access remediation. |
| AU-2 — Event Logging | Centralised remediation needs logging to prove who changed access and when. | |
| Recommendation — Assign clear account ownership and revoke unnecessary access under defined authority. Log remediation actions and review them for timeliness and completeness. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The answer is fundamentally about controlling and remediating access decisions. |
| A.8.2 — Privileged access rights | Microsoft 365 admin actions rely on tightly governed privileged access. | |
| Recommendation — Define access control rules centrally and enforce them consistently across admins. Restrict privileged access so only authorised admins can execute remediation. | ||
Practitioner Guidance
Decision rule: If the issue is a routine revocation of excess access, centralise the approval and risk decision, then let trained Microsoft 365 admins execute the change under a pre-approved runbook. If the action could break a critical workflow, require joint approval before removal.
What to verify: The team should be able to show who approved the remediation, what exactly was removed, when the change took effect, and how the tenant was checked afterward. If you cannot prove the access path was actually closed, the control is incomplete.
Common mistake: Treating microsoft 365 remediation as a platform support queue. That approach optimises for admin convenience, not for containment, and it usually fails when the same oversharing pattern recurs across many users or sites.
Practitioner takeaway: Centralise the decision and evidence, decentralise the technical click-path only where speed and safety both improve. The goal is fast, accountable removal of access, not a larger admin committee.
Related resources from NHI Mgmt Group
- Should organisations keep legacy SEG controls if they already use Microsoft 365?
- How should organisations use Microsoft 365 security assessments to prioritise remediation when resources are limited?
- Why do manual access reviews often fail to keep Microsoft 365 permissions under control?
- How should organisations govern Microsoft 365 Copilot when it can surface sensitive content the user already has access to?