Microsoft 365 security audit work has a reputation for being either a compliance chore or a vendor sales exercise, and it deserves neither. Done properly it is the cheapest hour-for-hour risk reduction available to a business running on Microsoft’s cloud, because almost every serious incident in a Microsoft tenant traces back to a setting somebody could have found and changed in an afternoon. Attackers rarely break Microsoft. They log in.

The reason this keeps happening is that a tenant is not a static thing. It was configured once, probably by a partner, probably in a hurry, and it has been drifting ever since — new staff, new apps, new sharing links, a temporary exclusion that became permanent. A Microsoft 365 security audit is simply the act of stopping and looking at what your tenant has actually become, rather than what you believe you set up three years ago.

This Microsoft 365 security audit checklist is written for UK businesses of roughly ten to three hundred staff on Business Premium, E3 or E5. It covers scoping, identity, Conditional Access, email, data sharing, application consent, logging, and how to turn what you find into a ranked list somebody will actually fix. It is written to be run by a competent IT person or provider, not by a specialist penetration tester.

One warning before you start. The point of a Microsoft 365 security audit is not to score well. The point is to find the three or four things that would genuinely matter if somebody phished a finance user tomorrow morning, and to fix those first. A checklist worked through mechanically produces a long report and no change. Treat every finding as a question about what would actually happen.

Table of contents

Why a Microsoft 365 security audit matters more than a licence upgrade

microsoft 365 security audit tenant checklist b key inside translucent ring

Businesses reliably spend money on tooling before they spend attention on configuration, and it is almost always the wrong order.

The default tenant is not a secure tenant

Microsoft ships defaults that prioritise getting people working. Sharing is permissive, users can consent to applications, and many protective controls are available but not switched on. None of this is negligence on Microsoft’s part — it is a reasonable starting position for millions of very different organisations. It does mean the out-of-the-box state is a starting point rather than a destination, and a Microsoft 365 security audit is how you find out how far you have moved from it.

Configuration drift is the real enemy

Every urgent exception leaves a trace. A user excluded from a policy for a fortnight in 2024. A mail flow rule added to fix a delivery problem. A guest invited for a project that ended. Individually harmless, collectively an attack surface nobody has ever seen as a whole. Drift is invisible precisely because each step was reasonable, and a Microsoft 365 security audit is the only routine that makes the accumulated total visible again.

What an audit is, and what it is not

A Microsoft 365 security audit is a configuration review against a known-good baseline. It is not a penetration test, not a vulnerability scan and not a compliance certification. It answers one question — is this tenant configured the way a competent person would configure it — and that question turns out to cover most of the realistic risk.

Why more licence does not mean more security

Higher tiers unlock better tooling, but tooling that is unconfigured protects nothing. Plenty of E5 tenants are less secure than well-run Business Premium ones because nobody turned the features on. If you are weighing an upgrade, read our guide to choosing a Microsoft 365 licence first — then audit what you already own.

Who should own it

Somebody named, with the authority to change settings and the standing to say no. If your provider runs the Microsoft 365 security audit for you, insist on seeing the raw findings rather than a summary. Good managed IT services partners share the whole list, including the items that reflect badly on their own past configuration choices.

How to scope a Microsoft 365 security audit before you start

microsoft 365 security audit tenant checklist c padlock with concentric rings

Scoping is the step people skip, and skipping it is why so many audits produce a spreadsheet nobody reads. Half an hour of scoping decides whether the rest of the Microsoft 365 security audit is useful.

Decide which tenant and which workloads

Confirm you have one tenant and not three — acquisitions and rogue sign-ups produce more of these than you would expect. Then list the workloads in scope: Entra ID, Exchange Online, SharePoint, OneDrive, Teams, Intune and Purview. Anything you exclude should be excluded deliberately and written down.

The roles you need to read everything

Read-only is enough for most of a Microsoft 365 security audit, and read-only is what you should use. Global Reader plus Security Reader will show you the overwhelming majority of what you need. Reserve write access for the remediation phase, and do the two phases on different days so nothing gets changed mid-assessment.

Set up a findings register before you look at anything

One row per finding: what you observed, where, why it matters, the risk rating and the owner. Starting the register first stops you fixing things ad hoc as you find them, which feels productive and destroys your evidence trail. The discipline is the same one used in an ISO 27001 gap analysis, and for the same reason.

Agree a risk rating scale up front

Three levels is plenty: fix this week, fix this quarter, accept and record. Agreeing the scale before you find anything prevents the argument where a finding gets downgraded because fixing it would be inconvenient.

Book the remediation time now

Audits produce work. If the remediation window is not in a diary before the audit starts, the findings register becomes a museum. Half a day per fortnight for six weeks fixes most of what a first Microsoft 365 security audit uncovers in a mid-sized tenant.

Identity and access: the first section of any Microsoft 365 security audit

microsoft 365 security audit tenant checklist d envelope with small shield

Identity is where the incidents happen. If you only have time for one section of the Microsoft 365 security audit, make it this one.

Enumerate every privileged role

List every account holding Global Administrator, and every account holding the other high-privilege roles — Exchange, SharePoint, User, Security and Billing administrator. Microsoft’s own guidance is to keep Global Admins to a small handful. Most tenants that have never been audited have several times that number, usually including a departed consultant and a shared account nobody will admit to using.

Check multi-factor authentication coverage properly

Do not check whether multi-factor authentication is “on”. Check the per-user coverage report and find the accounts that are exempt. The exempt list is where the risk lives: service accounts, executives who complained, and the shared mailbox somebody converted to a user account. Every exception needs a name and a reason.

Review legacy and app-based authentication

Microsoft has disabled basic authentication for most Exchange Online protocols, but SMTP AUTH commonly survives for scanners, line-of-business apps and copiers. Enumerate what is still using it and what it is used for. Each survivor is a password-only path into your tenant, which is exactly what multi-factor authentication was meant to close.

Break-glass accounts

You need emergency access accounts that are excluded from Conditional Access, protected by very long credentials stored offline, and monitored for any sign-in at all. Microsoft’s guidance on emergency access accounts is specific and worth following exactly. A tenant with no break-glass account is one bad policy away from locking everybody out, including you.

Guest and external identities

Export the guest list and read it. Guests accumulate silently through Teams and SharePoint invitations, they rarely get removed when a project ends, and they usually retain access to more than the person who invited them realised. Any guest who has not signed in for six months is a finding.

Stale accounts and orphaned mailboxes

Find accounts with no sign-in activity for ninety days, licensed accounts belonging to leavers, and shared mailboxes with sign-in still enabled. Disabled-but-licensed accounts are both a security exposure and a monthly invoice, which makes them one of the easiest findings from a Microsoft 365 security audit to get approved for remediation.

Conditional Access and device posture

microsoft 365 security audit tenant checklist e radar dish emitting waves

Conditional Access is the control plane that turns identity policy into something enforced rather than aspirational, and it is the section of a Microsoft 365 security audit where findings most often become projects.

Baseline policies every tenant should have

At minimum: multi-factor authentication for all users, multi-factor authentication for administrators with no exclusions beyond break-glass, a block on legacy authentication, and a policy requiring compliant or hybrid-joined devices for access to company data. Microsoft’s Conditional Access documentation sets out the templates, and starting from those is far safer than inventing your own.

Security defaults versus Conditional Access

Smaller tenants may still be running Security Defaults, which is a reasonable baseline and much better than nothing. If you hold Entra ID P1 — included in Business Premium — you can do considerably better with Conditional Access. Note which you are on before going further, because running a Microsoft 365 security audit against the wrong model produces nonsense findings.

Policy gaps that hide in exclusions

Read every exclusion on every policy. This is tedious and it is where the real findings are. A policy that requires multi-factor authentication for everyone except a group called “MFA Exceptions” containing eleven people is not the policy you think you have. Document each exclusion’s business justification or remove it.

Device compliance and Intune enrolment

Compare your enrolled device count against your licensed user count. The gap is unmanaged devices touching company data. Set a compliance policy covering encryption, operating system version, and screen lock, and check how many devices actually meet it. Public NCSC device security guidance is a sensible reference for what to require.

Report-only mode and how to use it

Every new Conditional Access policy should run in report-only mode first, then be reviewed against real sign-in data before enforcement. A Microsoft 365 security audit that recommends new policies should recommend this sequence too, because a well-intentioned policy enforced on a Friday is how businesses lock out their own sales team.

Email security: the highest-value part of a Microsoft 365 security audit

microsoft 365 security audit tenant checklist f clipboard with blank checkboxes

Email remains the entry point for most successful attacks, so this part of a Microsoft 365 security audit repays attention out of all proportion to the time it takes.

SPF, DKIM and DMARC

Check all three exist and are correctly configured for every sending domain, including the ones you only use for marketing. DMARC in particular is often present but set to a monitoring-only policy that enforces nothing. Moving to quarantine or reject after a monitoring period is one of the highest-value changes most tenants can make.

Anti-phishing and impersonation protection

Confirm anti-phishing policies exist and that impersonation protection lists your senior staff and your domain. The default policies are a floor, not a configuration. Named-user impersonation protection is what catches the message purporting to come from your managing director asking for an urgent payment.

Mail flow rules nobody remembers creating

Export every transport rule and read them all. Look for rules that bypass spam filtering for particular senders, rules that forward copies elsewhere, and rules created during a long-forgotten migration. Attackers create these too, and a rule quietly copying finance mail offsite is exactly the sort of thing only a Microsoft 365 security audit ever finds.

Auto-forwarding to external addresses

Check the outbound spam filter policy’s automatic forwarding setting and then check for existing forwards at the mailbox level. External auto-forwarding is a classic post-compromise persistence technique, and it is also a data protection problem in its own right when staff forward work mail to personal accounts.

Mailbox delegation and full-access permissions

Report on who has full access, send-as and send-on-behalf rights across every mailbox. Delegation accumulates through maternity cover, holidays and reorganisations, and is almost never revoked. Every delegation is a second route into that mailbox.

Data protection: SharePoint, OneDrive and Teams sharing

This is where a tenant leaks slowly rather than dramatically, which is why a Microsoft 365 security audit that stops at identity and email misses it entirely.

Default external sharing settings

Check the organisation-level sharing setting for SharePoint and OneDrive, then check the per-site overrides, which frequently differ. A tenant set to “Anyone” at organisation level is publishing to the internet by default, and most administrators who inherited such a tenant have no idea.

Anonymous links and their expiry

If anonymous links are permitted, confirm they expire and that the default permission is view rather than edit. Then run a report of existing anonymous links. Links created three years ago for a one-off share are still live unless somebody set an expiry, and they need no credential at all.

Sensitivity labels and data loss prevention

Check whether labels exist, whether anybody applies them, and whether data loss prevention policies are in enforce mode or merely testing. Policies in test mode are extremely common and give a false sense of coverage. If you handle regulated data, this section connects directly to your wider compliance obligations.

Guest access in Teams

Review which teams allow guests, which guests are in which teams, and whether any team containing sensitive material has external members. Teams membership is the mechanism by which most unintended external access is actually granted, because it is the one users control themselves.

Oversharing through site permissions

Look for sites shared with “Everyone except external users”, which is a very large audience in most organisations. Look also for permissions granted to individuals rather than groups, since those never get cleaned up when someone changes role.

Every tenant accumulates applications nobody approved, and this is the section of a Microsoft 365 security audit that surprises people most.

Enterprise applications and OAuth consent

List every enterprise application and service principal with permissions in your tenant, and check what each was granted. Illicit consent grants — where a user is tricked into approving a malicious application — bypass passwords and multi-factor authentication entirely, because the user genuinely authorised the access.

User consent settings

Check whether users can consent to applications themselves. In most businesses they should not be able to, or should be limited to verified publishers and low-impact permissions, with an admin consent workflow for everything else. This single setting closes a whole category of attack.

Service principals, secrets and expiry

Find application secrets and certificates, note their expiry dates, and identify any that never expire. Long-lived secrets held by applications nobody maintains are a genuine risk and a genuine operational hazard, since their eventual expiry breaks something at an unpredictable moment.

Unused and unmanaged applications

Any application with no sign-in activity in six months should be justified or removed. Reducing the number of things holding permissions in your tenant is one of the few Microsoft 365 security audit outcomes that also reduces running cost and support burden.

Logging and alerting: what your Microsoft 365 security audit must prove

A Microsoft 365 security audit that cannot demonstrate you would detect an incident has only assessed half the problem.

Unified audit log

Confirm unified audit logging is enabled and has been for some time. It is on by default in newer tenants, but plenty of older ones have it disabled, and it cannot retrospectively record what it was not capturing. This is the single check most likely to matter during an actual investigation.

Log retention by licence tier

Retention varies by licence and has changed more than once, so read your tenant rather than relying on a number you remember. Understand how far back you can actually look, because that window defines the worst-case investigation you are able to perform.

Alert policies worth enabling

At minimum: privileged role assignment, creation of mail forwarding rules, suspicious sign-in patterns, unusual volumes of file deletion or download, and elevation of administrative privilege. Each maps to an early stage of a real attack rather than to its aftermath.

Where the alerts actually go

Find out which mailbox receives the alerts and whether anybody reads it. An unmonitored alert inbox is the most common finding in this section and the most quietly serious. Strong IT security depends far more on somebody reading the alert than on the alert existing.

Backup is not logging, and logging is not backup

Detection tells you something happened; recovery gets you back. They are separate controls with separate failure modes, and a Microsoft 365 security audit should confirm both. Our guide on Microsoft 365 backup covers the recovery half in detail.

Scoring and reporting: turning a Microsoft 365 security audit into decisions

A findings list is not a result. The result of a Microsoft 365 security audit is a small number of changes that actually get made.

Turning findings into a ranked list

Rank by exploitability and business impact, not by how easy each item is to fix. Then take the top five and schedule them. A Microsoft 365 security audit that produces sixty findings and no sequence will produce no change at all, because nobody knows where to start.

Microsoft Secure Score, used properly

Microsoft Secure Score is a useful prompt and a poor target. It rewards actions that suit a generic organisation and cannot know your context. Use it to spot things you have not considered; do not let it dictate the order of work, and never report the number to your board as though it were a risk measure.

Writing the report your board will read

Two pages. What we checked, what we found, what we recommend, what it costs and what happens if we do nothing. Put the detailed Microsoft 365 security audit register in an appendix. Directors need enough to make a funding decision, and the technical detail belongs where the people doing the work will find it.

Quick wins versus structural fixes

Separate the changes that take an hour from those that need a project. Removing an unused Global Admin is a quick win. Rolling out device compliance is a project. Mixing them in one list makes the whole thing look daunting and stalls the easy improvements.

Making a Microsoft 365 security audit a routine, not an event

The value comes from repetition. A single Microsoft 365 security audit fixes a moment; a cycle keeps the tenant from drifting back.

The ninety-day cycle

Run a full Microsoft 365 security audit quarterly. Quarterly is frequent enough to catch drift while it is still small, and rare enough that it does not become a burden. Keep the same checklist each time so you can compare results rather than starting fresh.

What to re-check monthly

Privileged role membership, new enterprise applications, new guests and any change to Conditional Access exclusions. These four move fastest and cause the most damage when they move unnoticed. A monthly fifteen-minute check covers them.

Change control so drift does not return

Require that any exclusion, any new transport rule and any sharing change is recorded with a reason and a review date. Drift is not caused by carelessness so much as by undocumented urgency, and a one-line record at the moment of change removes most of it.

Building the checklist into onboarding and offboarding

Most identity findings originate in joiner and leaver processes. Tightening those at source means the next Microsoft 365 security audit finds less, which is the only sustainable way to reduce audit workload over time.

When to bring in outside help

Bring in help for the Microsoft 365 security audit if you have had an incident, if you are pursuing certification, if you have inherited a tenant nobody documented, or if nobody internally has the time to do it properly rather than quickly. Reviewing published support plans tells you whether a tested security review is included as standard or sold as an extra — and on a topic where cybersecurity failures are this expensive, the difference matters.