Auditing Microsoft 365 well is less about running one magic tool and more about working through the same checklist in the same order, every time, so nothing gets missed and your findings are comparable from one tenant to the next. For MSPs managing dozens of tenants, that consistency is the whole game.
This guide walks through how to audit Microsoft 365 the way a methodical security reviewer would: identity first, then admin access, then the services that actually move data — email, SharePoint, Teams. It assumes you have at least a Global Reader role (or Security Reader) in the tenant you're reviewing. You don't need Global Admin to audit, and you shouldn't ask for it.
Start With What You're Actually Auditing
Before touching a setting, write down the scope. A Microsoft 365 audit usually covers five areas, and conflating them is how reports end up vague:
- Identity and authentication — how users prove who they are (MFA, Conditional Access, legacy auth).
- Privileged access — who holds admin roles and whether that's justified.
- Email security — anti-phishing, spoofing protection, mail flow rules, forwarding.
- Data and collaboration — SharePoint, OneDrive, and Teams sharing settings.
- Logging and licensing — whether you can actually see what happened, and whether the tenant is paying for capabilities it isn't using.
Note the client's license tier too. Business Premium, E3, and E5 unlock very different controls. Recommending a feature the tenant can't license without an upgrade is a credibility hit, so record this up front.
Step 1: Audit Identity and Authentication
Identity is where the overwhelming majority of real-world Microsoft 365 compromises start, so it comes first.
Check multi-factor authentication coverage across all users, not just admins. In practice you want to know three things: how many users have no MFA method registered, whether MFA is enforced through Conditional Access or still relying on per-user settings or Security Defaults, and whether any accounts are explicitly excluded.
Then look at legacy authentication. Protocols like IMAP, POP, and basic auth SMTP bypass MFA entirely. Microsoft has disabled most legacy auth by default, but it still appears in older tenants and via app-specific exceptions. Pull sign-in logs filtered to legacy clients — if you see successful legacy auth sign-ins, that's a finding worth flagging as high severity.
Review Conditional Access policies as a set, not individually. Common gaps: a policy that requires MFA but excludes a "break-glass" group that has grown beyond two emergency accounts, or a policy in report-only mode that everyone assumes is enforcing. Confirm there's at least one policy requiring MFA for all users on all cloud apps, and that device or location conditions aren't quietly letting risky sign-ins through.
Finally, check password and self-service reset settings, and whether risk-based policies (Identity Protection) are available and enabled on the licenses the client holds.
Step 2: Review Privileged Roles and Admin Access
Over-provisioned admin accounts are the second most common serious finding. Pull the full list of directory role assignments and ask, for each one, whether that person needs it permanently.
Watch for these patterns:
- Too many Global Admins. Microsoft recommends keeping this under five. Many small tenants have ten or more because every past technician got added "temporarily."
- Standing access instead of just-in-time. If the tenant has Entra ID P2, Privileged Identity Management (PIM) lets admins activate roles only when needed. Standing Global Admin rights that could be PIM-eligible are a finding.
- Admin accounts without their own MFA, or admin roles assigned to accounts that are also used for daily email and browsing.
- Guest accounts with elevated roles, which are easy to overlook.
Document who holds what, when it was last used if you can see it, and whether break-glass accounts are properly excluded from Conditional Access and monitored.
Step 3: Audit Email Security
Exchange Online is where phishing and business email compromise play out, so this section carries weight in any report.
Check the anti-phishing and anti-spoofing posture. Confirm SPF, DKIM, and DMARC are configured for every sending domain. A missing or p=none DMARC record is extremely common and worth explaining in plain terms: it means the domain can be spoofed with no enforcement.
Review mail flow rules and forwarding. Auto-forwarding to external addresses is a classic data-exfiltration and BEC indicator. List every mailbox with external forwarding and every transport rule that redirects or allows mail — these should be justified individually.
Look at the Microsoft Defender for Office 365 configuration if licensed: Safe Links, Safe Attachments, and anti-phishing impersonation protection. If the tenant pays for Defender but the policies are left at defaults or disabled, that's lost value and a finding worth surfacing.
Step 4: Review Data Sharing in SharePoint, OneDrive, and Teams
Collaboration settings quietly control how far data can travel. Check the external sharing level for SharePoint and OneDrive — "Anyone" links that don't expire are the setting most likely to surprise a client. Confirm whether link expiration and default permissions (view vs. edit) are set conservatively.
For Teams, review guest access and which external domains are allowed. Anonymous meeting join and unmanaged file sharing in channels both deserve a look. Note any shared mailboxes with sign-in enabled, since those are sometimes left with weak or no authentication.
Step 5: Confirm Logging, Retention, and Licensing
An audit is only as good as the evidence available. Verify that unified audit logging is enabled — it is by default in newer tenants, but confirm it. Check mailbox audit logging and the retention period the license allows, because a 90-day window versus a one-year window changes what you can investigate after an incident.
Close by reconciling licensing against usage: unused security features the client already pays