If you are reviewing a Microsoft 365 tenant yourself — or want to understand what a consultant should be doing — this is the sequence we use and the reasoning behind it.
The order matters more than the completeness. Working through the admin centre menu by menu produces a long list with no sense of priority. Working outward from identity produces a picture of how an incident would actually unfold.
Before you start
Get read-only access first: Global Reader, plus Security Reader and Reports Reader. Everything in the assessment phase should be non-intrusive. Resist the urge to fix things as you find them — you will lose track of what you changed, and some fixes are user-visible and need planning.
Keep a single findings register from the first minute, recording what you observed, where, and why it matters. The reasoning is the part you will not remember in three weeks.
1. Identity — start here, always
Everything else depends on it. If identity is compromised, no other control saves you.
Administrative roles. List every holder of every privileged role, starting with Global Administrator. For each: is this a named individual, is the account human or a service, is MFA enforced, when was it last used, and is permanent assignment justified? Include the roles people forget — Exchange Administrator, User Administrator, Application Administrator, Privileged Role Administrator.
MFA coverage. Not “is MFA enabled” but “which accounts can authenticate without it”. Check registration status per user, security defaults or Conditional Access enforcement, and every exclusion group. Then check what is in those exclusion groups, because that is where the finding usually is.
Conditional Access. Read every policy including disabled and report-only ones. For each, establish what it actually enforces, who is excluded, and whether the exclusions still make sense. Look for policies created in report-only mode as a test and never enabled, and for overlapping policies whose combined effect nobody has worked out.
Legacy authentication. Confirm it is blocked. If not, use sign-in logs to identify what is still using it before blocking, or you will break something at an inconvenient moment.
Guest accounts. How many, from which organisations, invited when, last active when, and with access to what.
Application registrations and consents. Every application with delegated or application permissions to your tenant. Look particularly for anything holding Mail.Read, Files.ReadWrite.All or similar broad scopes. Ask who approved it and whether it is still in use.
2. Email
Authentication records. SPF, DKIM and DMARC for every domain you own, including ones you do not send from — unused domains are attractive precisely because nobody protects them. Check whether DMARC is at p=none and has been for two years.
Transport rules. Read them all. Rules that bypass filtering for particular senders are common, usually created to solve a false positive, and rarely revisited.
Mailbox forwarding. Every mailbox with external forwarding configured, and whether each is legitimate. Then check whether forwarding is restricted by policy.
Delegate and shared mailbox permissions. Who has full access to whose mailbox, and whether that is still appropriate.
Anti-phishing configuration. Impersonation protection for senior staff and your own domains, and whether the policies are actually applied to all users.
3. Data and sharing
This section takes the longest and produces the findings clients find most uncomfortable.
External sharing settings. Tenant-level and per-site. Whether anonymous links are permitted, whether they expire, and the default link type when a user clicks Share.
Existing anonymous links. Enumerate them. In a tenant several years old there may be thousands. Sort by age and look at what the oldest ones point at.
SharePoint site inventory. Every site, its owner, its sharing setting, and whether the owner still works there. Sites with no owner are a recurring finding.
Broken inheritance. Where item-level permissions diverge from the library, usually because someone shared a single file and the platform accommodated them.
OneDrive. How much business data sits in personal drives, and what happens to it at offboarding.
Teams. Guest membership, private channels, third-party apps installed by users, and where meeting recordings are stored and for how long.
4. Devices
Enrolment. Which devices are managed, and — the more useful question — whether unmanaged devices can reach company data.
Compliance policies. What they require, and how many devices are non-compliant right now. A compliance policy nobody remediates against is documentation, not control.
Conditional Access device requirements. Whether access to company data actually requires a compliant device, or whether that policy excludes a group.
5. Logging and monitoring
Unified audit log. Enabled, and retained for how long under your licence. Compare that retention against how long it typically takes to detect an intrusion.
Alert policies. Which are configured, where alerts go, and whether anyone reads that mailbox. Test one.
Sign-in logs. Look at the last thirty days for impossible travel, sign-ins from countries you do not operate in, and repeated failures against particular accounts.
6. Licensing reality check
Before recommending anything, establish what the current licences already permit. A significant proportion of typical findings are fixed by switching on something already paid for. Business Premium includes Conditional Access, Intune, Defender for Office 365 Plan 1 and Entra ID Plan 1 — capability many organisations hold and never configure.
Only after that exercise is it reasonable to discuss whether an upgrade is justified, and for which specific control.
Writing it up
Two audiences, one document.
The body is for directors: what the risk is, what it would mean commercially, and what you recommend. Plain language, ranked by exposure, with an effort estimate against each item. Include the findings you recommend accepting — a review that presents everything as urgent gets ignored entirely.
The appendix is for whoever implements it: specific settings, specific accounts, specific sites, and the order to change them in.
What to fix first
Roughly, in this order:
- MFA gaps and excluded accounts
- Excess administrative access
- Anything with external exposure — anonymous links, over-broad app consents
- Legacy authentication
- Audit log retention, so the next investigation has something to work with
- Everything else
Do the user-visible changes with a pilot group and prior communication. The technical work in a Microsoft 365 remediation is rarely difficult. The sequencing, so that nothing breaks on a Monday morning, is what determines whether the changes survive.