A Microsoft 365 audit comes up more and more often: the insurer asks for one, the board asks for one because of NIS2, and when an IT partner changes or a company is acquired, someone wants to know what has actually been bought. Very often the request also comes from a new CEO or IT manager who wants to understand what kind of environment they have inherited and what they are now responsible for. The word is still vague. For one person it means an automated Secure Score report, for another a week of consultancy. In this post I go through what a proper Microsoft 365 security audit covers, what the auditor needs, what the report must contain and how often it is worth doing. I also explain why I call my own version a health check rather than an audit.

What a Microsoft 365 audit means

A Microsoft 365 audit is an outside review of how the environment is configured, who has access to what and what is being paid for. The outcome is a report that says what is in order, what is not and in which order the gaps should be fixed. The same thing goes by other names too: security audit, security assessment, security review. In practice they mean the same, and the difference is mostly in how broadly the environment is covered and how well the findings are prioritised.

Two things separate a real audit from a click test. The first is context: Secure Score or any automated tool tells you that a setting deviates from the recommendation, but not whether it matters in your environment. An admin account without MFA is critical; an old test account without MFA and without any permissions is not. The second is independence: if the audit is done by the same party that runs the environment or sells the licences for it, the report is also assessing the author’s own work or own invoice. Even a good partner has a blind spot for its own work.

My own service, the Microsoft 365 Health Check, is this audit packaged: fixed scope, fixed price, results within a week of access being granted, and a usefulness guarantee. The guarantee means you decide whether the report was useful, and if it was not, you do not pay for it. I chose the name health check because audit sounds like someone is coming to find the guilty. A health check assesses the environment, not people. If you have been looking for a Microsoft 365 audit, it is the same thing.

What a Microsoft 365 security audit goes through

Microsoft 365 security is made up of five areas, and a proper audit covers all of them. If an offer covers only one, it is a partial review, which can be perfectly justified, but it is worth knowing in advance.

Identity and access. Entra ID is the front door, and almost every attack on a Microsoft 365 environment starts with a user account. The audit looks at the coverage and quality of multi-factor authentication (plain MFA is no longer enough), Conditional Access policies and their gaps, the number and protection of admin accounts, legacy authentication, and the permissions granted to partners and applications. The last one is where surprises are found most often: a former IT partner’s delegated permissions, or an application approved years ago that still has read access to every mailbox.

Devices. Which devices company data ends up on and whether there are any requirements for them. Intune coverage, device compliance policies, the state of Defender, and whether an unmanaged home computer can sign in without any restrictions.

Email. Domain authentication, meaning SPF, DKIM and DMARC, which tell recipients which messages are really from you. A common finding is that the records exist but do not yet actually protect against messages forged in your name. On top of that, Exchange Online filtering, automatic forwarding to external addresses and the state of shared mailboxes.

Data and sharing. SharePoint and OneDrive sharing settings, “anyone with the link” links, guest access and oversharing. This area has become important because of Copilot: Copilot shows the user everything they have access to, including the things they should never have had access to. I wrote about it separately: Before Copilot: who can see what?

Licensing. This is missing from most security audits, but in my view it belongs in the same review, because licences decide which protections are available in the first place. Each user’s actual usage is compared with their licence. In a typical mixed-licence environment, a significant share of licences are either unused or oversized, while somewhere else a capability that would fix a security finding is missing. The licence bill keeps growing, and nobody asks why explains how this usually happens.

There are hundreds of checks, and they are made against known baselines, above all the CIS Microsoft 365 Benchmark and Microsoft’s Zero Trust guidance. The baseline matters because without it the findings are the author’s opinions.

What access the auditor needs

This varies by auditor, so ask in advance what access is requested and why. One principle applies to everyone: an audit reads, it does not change. If the auditor wants to change settings during the audit, it is something other than an audit.

In my own work, most of the review is done with applications that read the environment’s settings and usage data, and part of it by hand in the admin portals. There are two ways to handle access: either I get sufficient rights to create the review applications myself, which is the fastest way, or the customer creates them following my instructions, in which case read permissions are enough for me. Which one suits you depends on how strict your rules on external access are, and it is agreed in the kick-off call.

The content of emails and files is not the subject of the audit. The review covers settings, permissions and usage data, not what the messages or documents say. Once the audit is done, the temporary permissions and applications should be removed, unless the work continues into remediation. It is worth agreeing this and assigning it to someone at the start, because both sides forget it easily.

In the Health Check, users notice nothing, and it takes you about fifteen minutes to grant access and an hour to go through the results. If an audit requires days of your time, it is worth asking why.

What the audit report must contain

The report is the audit’s only product, so its quality decides whether the whole exercise was worth it. Three things separate a usable report from a list of findings.

The first is prioritisation. A hundred-row list where everything is red helps no one. Each finding needs a severity based on your environment rather than a generic table, and the report must show at a glance which three or five things get fixed first.

The second is a concrete fix. Each finding comes with a description of what is done and whether it can be done with the licences you already have. Most typical findings, such as MFA for admins, Conditional Access gaps, stale partner permissions and email authentication, are fixed without new purchases. If something requires a licence you do not have, that should be said directly, but the report must not be a sales list.

The third is readability for management. The report must answer the question “what shape are we in and what does it cost” so that the CEO or CFO understands it without a technical background. The licence analysis is best presented in euros, because it is the only part of the report that pays for itself before a single security finding has been fixed. A good report is one the IT lead can take to management as their own achievement.

In the Health Check these are a fixed part of the delivery: prioritised findings, a remediation path, a licence savings estimate in euros and a one-hour debrief where the report is walked through together.

How often a Microsoft 365 environment should be audited

There is no single answer, and I am suspicious of anyone who says “annually” or “once is enough” without thinking. Both are probably wrong. In my view it splits into three parts.

Licensing is worth checking once a year, timed to the renewal date of your annual agreement. Almost everyone has one, and until then the licence counts and tiers are still open. Do the check well before the renewal so that you actually have time to decide and make the changes, not the week before. Microsoft adds features and changes prices every year, so last year’s sizing is not necessarily right any more.

For security, an interval of one to two years is sensible for most, but changes matter more than the calendar: an acquisition, a change of IT partner, a Copilot rollout, a major staff change or a new person in charge can all be reasons to go through the environment regardless of when the last audit was done.

And if the environment is developed continuously and its state is tracked with monthly metrics, a separate audit is not needed in the same way. Then the audit’s role is mainly to confirm, through an outsider’s eyes, that the tracking actually covers what matters.

After the audit

The report does not fix anything. The decision on who does the fixes is yours: your own IT or your current partner based on the report, or someone else. A good report works in every case, because it gives everyone the same prioritised list. Not all auditors do remediation; I do, if you want. That is a separate decision, though, not a condition. If the audit comes with the condition that the fixes are bought from the same supplier, it is not an independent audit.

If you want to know what shape your Microsoft 365 environment is in, the Health Check is the audit described here, ready packaged. It starts with a free 30-minute call that tells you whether it is worth doing for you at all.

What a Microsoft 365 security audit covers and what the report must contain