The operating principle
Ownership and execution are different jobs
A managed administrator can carry out approved changes. The company must still appoint someone to decide retention, access, procurement and exceptions. Without that distinction, apparently simple work becomes high-risk privileged action.
Begin with a tenant and responsibility inventory
List Microsoft 365 tenants, verified domains, user groups, licensing plans, workload owners and existing support providers. Include hybrid directory dependencies, automated accounts, shared mailboxes and the applications that rely on the tenant. A single admin-console screenshot is not a useful inventory.
Then identify who can approve security policies, invite external collaborators, decide whether a departing employee's mailbox is retained and buy additional licences. A provider should not invent internal authority simply because it has administrator access.
| Recurring task | Provider could perform | Customer must decide |
|---|---|---|
| Create or change user | Provision account and approved roles | Role, start date and permitted access |
| Grant SharePoint access | Apply the approved membership | Who may see the documents |
| Adjust licences | Identify utilisation and implement approval | Commercial terms and feature requirements |
| Change authentication policy | Stage, test and implement change | Risk tolerance, emergency access and exceptions |
| Retire account | Disable access and complete runbook | Retention, handover and legal hold |
Use least privilege rather than permanent global access
Microsoft provides role-specific administration through Entra and Microsoft 365 services. Assign access by actual task and scope; retain emergency access under the organisation's control. Privileged changes should have a request, approver and record.
This is both a security and a continuity decision. When the support relationship ends, the customer should still own the tenant, know which permissions were granted and be able to revoke delegated access without losing service.
Build the support cadence around real activity
Separate routine joiners/leavers, delegated mailbox changes, shared-access requests and ordinary incidents from specialist projects such as migrations and tenant redesign. Use monthly reviews to surface decisions rather than simply counting tickets.
Define how requests arrive, the hours they are covered and what happens when a problem lies with an internet connection, local device or another cloud supplier. A narrow, well-delivered scope is more credible than promising every IT service.
Documented administration controls
- Named tenant owner and change approvers
- Current admin roles and emergency access procedure
- Covered workloads and number of supported users
- Ticket intake, hours and escalation boundaries
- Change record, monthly review and exit handover
The monthly operating record a business should actually receive
A Microsoft 365 administrator can be busy without improving the tenant. Insist on a short monthly record that links requests to approved changes, unresolved risks and the next decisions requiring business ownership. Include privileged-role changes, newly exposed sharing, dormant accounts, failed or delayed offboarding, licence exceptions and a sample of completed user requests. The point is not to produce an impressive graph of tickets but to show whether the tenant remains governable.
Separate provider execution from customer approval in every entry. Removing a leaver's licence may be a routine step; deciding how long their mailbox or OneDrive should remain accessible is a retention and governance decision. Similarly, an external guest request may be technically trivial yet commercially sensitive. Evidence should name who authorised the change, what was done and whether the actual requester could use the result.
| Operational record | Minimum evidence | Accountable party |
|---|---|---|
| Privileged access change | Who approved, scope, time and audit event | Tenant owner and administrator |
| Joiner / mover / leaver | Ticket, identity actions and handover result | Manager and service owner |
| External sharing change | Site, recipient and permitted duration | Data owner |
| Licence exception | Usage, feature dependency and invoice assumption | Budget owner |
Define work that is not automatically part of administration
Ongoing tenant administration is not a blanket promise to deliver security incident response, Azure infrastructure engineering, device repair, compliance legal advice or a migration project. Each has different specialist skills, risk and staffing requirements. An effective proposal should list covered workloads, support windows, request channels, escalation paths and the change process for specialist tasks.
The client should retain independent control of its tenant, break-glass access and billing decisions. For service-provider departure, document privileged-access removal, transfer of runbooks, asset registers and unresolved tickets. Avoid retaining perpetual Global Administrator roles merely because they are convenient.
Documented administration controls
- Name approved requesters and tenant stakeholders
- Define included products, channels and support windows
- Set authority and change-control boundaries
- Require a repeatable monthly evidence report
- Record exit and administrator access revocation procedures
The aim is predictable administration with visible accountability, not to remove all technical decisions from the business.
Primary technical references
Check current feature and licence requirements before changing a tenant. A service description is not evidence that a customer has purchased or activated an option.
Commercial next step
Map your administration responsibilities
Share the number of tenants, users, products and recurring requests. We can help define an initial service boundary before discussing a retainer.
Request an administration assessment