Microsoft 365 Security Audit Checklist: 12 Areas to Review in Your Tenant

The short version: A Microsoft 365 security audit checklist covers twelve areas of the tenant: MFA coverage, Conditional Access, privileged roles and break-glass accounts, legacy authentication and SMTP AUTH, app consent, guests and external sharing, mail forwarding, SPF/DKIM/DMARC, Defender for Office 365 policies, the audit log, DLP and labels, and device and app protection. This page tells you where each setting lives and what good looks like, in the same order as Brocent's published sample report.

If you are looking for a Microsoft 365 security audit checklist, you probably want two things: a list you can work through yourself in an afternoon, and a way to tell whether the result means anything. This page gives you the first and is honest about the second.

The twelve areas below follow the structure of the sample Microsoft 365 security audit report that Brocent publishes for a fictitious client, which is organised by domain: identity and access, email, Defender, SharePoint and OneDrive, Teams, tenant hygiene and logging, and devices. The sample measures a 14-person tenant against the CIS Microsoft 365 Foundations Benchmark at Level 1 and Level 2, and the findings it contains are the ones that turn up most often in small and mid-sized tenants. So the list is not theoretical: each area is a place where real tenants are usually found wanting.

Two notes before you start. First, everything here can be read with Global Reader or a similar read-only role, so you do not need to change anything to complete the checklist. Second, this is an on-page checklist, not a form. There is nothing to download and nothing to sign up for.

How to audit a Microsoft 365 tenant: the method before the list

A tenant audit answers one question twelve times: is this setting configured the way a recognised baseline says it should be, and if not, does the gap matter for this organisation? The baseline matters because "secure" is not a feeling. The CIS Microsoft 365 Foundations Benchmark publishes recommendations at two levels, Level 1 for settings every organisation should apply and Level 2 for stricter settings that may affect usability. Microsoft Secure Score measures a related but narrower set of actions. The two are compared in Brocent's post on Secure Score, the CIS Benchmark and ScubaGear.

For each area, work in this order:

1. Open the admin centre named in the area and read the current setting.
2. Write down what you saw, with the date, in a spreadsheet. A screenshot or export is better than a note.
3. Compare it with "what good looks like" and mark the row pass, fail or not applicable.
4. If it fails, write one line on why it matters for your business, not in general.

The last step is what turns a list of settings into an audit. A finding is a setting plus a consequence.

Area 1: MFA coverage. Does every enabled account have a second factor?

What to check: the registration status of every enabled user, the methods they registered, and whether MFA is actually enforced rather than merely available. In the sample report, the critical finding is two accounts that can still sign in without MFA, one of them a Global Administrator excluded from the policy through a group nobody reviews.

Where it lives: Microsoft Entra admin centre, Protection, Authentication methods, User registration details. The report shows who is registered and with which method. Enforcement is in Conditional Access (next area) or, for tenants without Entra ID P1, in security defaults under Entra ID, Overview, Properties.

What good looks like: every enabled account has at least one strong method, administrators use a phishing-resistant method such as a passkey, SMS and voice are disabled as methods, and the enforcement policy has no exclusion group that contains real people. The step-by-step for turning MFA on is in how to enable MFA in Microsoft 365.

CIS mapping: identity and access, Level 1 for MFA on all users and administrators, Level 2 for phishing-resistant methods.

Area 2: Conditional Access. Are the baseline policies on, or stuck in report-only?

What to check: the list of policies, their state, who they apply to, and above all who they exclude. The second critical finding in the sample is a "Block legacy auth" policy that has sat in report-only mode since February, which means it blocks nothing.

Where it lives: Entra admin centre, Protection, Conditional Access, Policies. Open each policy and read the exclusions, the grant control and whether it is On, Off or Report-only.

What good looks like: a small set of named policies that require MFA for all users and for administrators, block legacy authentication, protect security information registration, and require compliant or protected devices where you have Intune. Exclusions limited to the two emergency access accounts and documented service accounts. Nothing left in report-only after its test period. The six policies to build first are in Conditional Access baseline policies.

CIS mapping: identity and access, Level 1 for the core policies, Level 2 for device-based and sign-in frequency controls.

Area 3: Privileged roles and break-glass accounts. Who is a Global Administrator, and from which account?

What to check: how many accounts hold Global Administrator and other privileged roles, whether those are the same accounts people use for mail and Teams, whether assignments are permanent or activated when needed, and whether two emergency access accounts exist and are protected.

Where it lives: Entra admin centre, Roles and administrators, then each role's assignments. Privileged Identity Management, if licensed, shows eligible versus active assignments. In the sample, three people hold Global Administrator permanently and two of them use that account every day.

What good looks like: between two and four Global Administrators, each on a separate administrative account used only for administration, eligible rather than permanent where PIM is available, and two cloud-only break-glass accounts with a phishing-resistant method, excluded from Conditional Access and monitored for any sign-in. The identity side is explained further in Microsoft 365 and Entra ID security audits.

CIS mapping: identity and access, Level 1 for limiting Global Administrators and separate admin accounts, Level 2 for PIM.

Area 4: Legacy authentication and SMTP AUTH. What can still sign in without modern authentication?

What to check: whether legacy protocols (IMAP, POP, SMTP AUTH, older Office clients) are blocked, and whether anything is still using them. The sample tenant showed 214 legacy sign-ins in 30 days from a scanner account and one user's old mail client.

Where it lives: the Conditional Access policy that blocks legacy authentication (Area 2), the sign-in logs filtered by client app (Entra admin centre, Monitoring, Sign-in logs), and Exchange admin centre, Settings, Mail flow, for the tenant-wide SMTP AUTH switch, plus each mailbox's authentication settings.

What good looks like: the blocking policy is On, the 30-day sign-in log shows zero legacy sign-ins, SMTP AUTH is disabled tenant-wide and enabled only on the specific mailbox a printer or application genuinely needs, with a plan to move that device to modern authentication.

CIS mapping: identity and access and Exchange Online, Level 1.

Area 5: App consent and enterprise applications. What have users granted access to your mail and files?

What to check: whether users can consent to third-party applications on their own, and which enterprise applications currently hold delegated or application permissions such as Mail.ReadWrite or Files.ReadWrite.All. The sample finds three apps with broad mail and file permissions, one of them unused for months.

Where it lives: Entra admin centre, Identity, Applications, Enterprise applications, Consent and permissions, for the user consent setting and the admin consent workflow; then the Enterprise applications list, sorted by permission, for what is already granted.

What good looks like: user consent disabled or limited to low-impact permissions from verified publishers, an admin consent request workflow so staff have a route to ask, and a quarterly review that removes applications nobody uses. Device code flow blocked in Conditional Access.

CIS mapping: identity and access, Level 1 for user consent, Level 2 for the consent workflow.

Area 6: Guests and external sharing. Who outside the company can reach what?

What to check: guest accounts and their last sign-in, the tenant-level sharing setting for SharePoint and OneDrive, site-level defaults, and whether "Anyone" links exist. The third critical finding in the sample is a client-onboarding site holding identity documents whose default link type is "Anyone with the link".

Where it lives: Entra admin centre, Users, filtered by user type Guest; SharePoint admin centre, Policies, Sharing, for the tenant slider and link defaults; each site's sharing settings; the SharePoint sharing report for existing links.

What good looks like: tenant sharing set no more open than "New and existing guests", Anyone links disabled or expiring, default link type "Specific people", guests reviewed and removed when a project ends, and guest access requiring MFA through Conditional Access. If you use Copilot, the oversharing angle is covered in Copilot oversharing readiness.

CIS mapping: SharePoint and OneDrive, Level 1 for anonymous links and defaults, Level 2 for stricter external sharing.

Area 7: Mail flow and forwarding. Is anything sending your mail somewhere else?

What to check: inbox rules and mailbox-level forwarding to external addresses, transport rules that redirect or copy mail, and whether the outbound spam policy permits automatic forwarding. The sample finds a partner's mailbox forwarding everything to a personal address through an inbox rule created in June.

Where it lives: Exchange admin centre, Mail flow, Rules, for transport rules; Exchange admin centre, Reports, or PowerShell, for mailbox forwarding and inbox rules; Microsoft Defender portal, Email and collaboration, Policies, Anti-spam, Outbound, for the automatic forwarding setting.

What good looks like: automatic forwarding set to Off or controlled at the outbound spam policy, no external forwarding except documented exceptions, an alert policy that notifies an administrator when a forwarding rule is created, and a periodic export of all inbox rules. The business-email-compromise pattern this prevents is told in a Hong Kong supplier payment fraud case.

CIS mapping: Exchange Online, Level 1.

Area 8: SPF, DKIM and DMARC. Can someone send as your domain, and would you know?

What to check: for every domain in the tenant, including parked ones, whether SPF exists and ends in a hard or soft fail, whether DKIM is enabled and signing, and what the DMARC policy is and where the reports go. The sample domain publishes DMARC with p=none and sends reports to a mailbox nobody reads; its parked domain has no records at all.

Where it lives: Microsoft 365 admin centre, Settings, Domains, for the DNS records Microsoft expects; Defender portal, Email and collaboration, Policies, Email authentication settings, for DKIM; your DNS provider for what is actually published.

What good looks like: SPF with a single include and a hard fail, DKIM signing on every sending domain with keys rotated, DMARC at p=quarantine or p=reject once reports show legitimate mail is aligned, and aggregate reports going somewhere that is actually reviewed. Parked domains get a null SPF and a reject DMARC so they cannot be used for spoofing.

CIS mapping: Exchange Online, Level 1 for SPF and DKIM, Level 1 for DMARC publication.

Area 9: Defender for Office 365 policies. Are the presets applied, or still on defaults?

What to check: whether the Standard or Strict preset security policies are applied to all users, whether Safe Links and Safe Attachments are on for mail, Teams and Office files, whether anti-phishing impersonation protection names your executives and domains, and whether zero-hour auto purge is on.

Where it lives: Defender portal, Email and collaboration, Policies and rules, Threat policies. Preset security policies are the first entry; anti-phishing, anti-spam, anti-malware, Safe Attachments and Safe Links follow.

What good looks like: Standard preset applied tenant-wide as a minimum, Strict for finance and executives, impersonation protection listing the people whose names are most likely to be spoofed, Safe Attachments extended to SharePoint, OneDrive and Teams, and a review of quarantine release permissions. Which licences include these features varies by plan, so check what your plan entitles you to before marking a row as failed.

CIS mapping: Defender for Office 365 section, Level 1 for presets and Safe Links, Level 2 for stricter settings.

Area 10: Audit log and alerts. Is the unified audit log on, and would anyone hear an alarm?

What to check: whether unified audit logging is enabled, how long events are retained under your licence, whether mailbox auditing is on, and which alert policies exist and who receives them.

Where it lives: Microsoft Purview portal, Audit, where a banner says if auditing is not turned on; Defender portal, Alert policies, for who is notified of what; Exchange admin centre or PowerShell for mailbox audit status.

What good looks like: audit logging on with retention understood and, if needed, extended; alert policies for new forwarding rules, elevation of privilege, mass file downloads and unusual sign-ins routed to a mailbox that is read; a quarterly check that the log actually contains events for the tenant's domains.

CIS mapping: tenant hygiene and logging, Level 1 for audit log enablement and mailbox auditing.

Area 11: DLP and sensitivity labels. Does anything stop regulated data leaving?

What to check: whether any data loss prevention policy exists, which sensitive information types it watches, whether it covers Exchange, SharePoint, OneDrive and Teams, and whether sensitivity labels are published and in use. In the sample, the built-in types for identity documents match almost 2,000 files and no policy exists.

Where it lives: Purview portal, Data loss prevention, Policies; Purview, Information protection, Labels and Label policies; the Content explorer for what the classifiers already find.

What good looks like: at least one DLP policy in test mode with notifications, covering the sensitive information types relevant to your market and industry, moved to enforcement after a month of tuning; a small label set (Public, Internal, Confidential) published to all users; the default label applied to new documents. Keep the policy proportionate to the data you actually hold.

CIS mapping: Purview section, Level 1 for DLP on sensitive types, Level 2 for labels and stricter enforcement.

Area 12: Device and app protection. What happens on the phones and laptops that open your data?

What to check: whether personal phones access mail and files without an app protection policy, whether Conditional Access requires a compliant device or protected app, how many devices are unmanaged, and whether company laptops are encrypted and running endpoint protection. The sample finds seven personal phones signing in with no app protection at all.

Where it lives: Intune admin centre, Apps, App protection policies, for mobile application management; Devices, Compliance, for what compliant means; Entra admin centre, Devices, for the device list and join state; Conditional Access for the grant controls that tie them together.

What good looks like: an app protection policy for iOS and Android requiring a PIN, encryption and the ability to wipe company data, a compliance policy for Windows and macOS requiring encryption and endpoint protection, and Conditional Access that enforces one or the other. Device checks go deeper than a tenant audit; Brocent covers them in the separate Intune device audit, which has its own sample report.

CIS mapping: Intune and device sections, Level 1 for app protection and compliance, Level 2 for stricter device requirements.

What the checklist cannot tell you

Working through the twelve areas will find the obvious gaps, and in most small tenants it will find several. It will not tell you three things.

It will not grade the gaps against each other. A report-only legacy auth policy and a p=none DMARC record are both failures, but one gives an attacker a way in today and the other mostly affects deliverability. A finding needs a severity and a fix order, and that takes judgement about your organisation.

It will not check the manual controls. Several benchmark recommendations cannot be read from a single setting: whether break-glass accounts are actually monitored, whether administrators really use separate accounts, whether the exception group in a policy is justified. A person has to look and ask.

It will not produce evidence someone else can rely on. A spreadsheet of your own observations is useful to you. An insurer, a client's procurement team or a Cyber Essentials assessor usually wants dated exports and a method statement from someone who did not configure the tenant. The sample report's evidence pack shows what that looks like.

Self-check, Secure Score, or an independent audit?

• Working through this checklist yourself: costs an afternoon and finds the settings that are plainly off. Good for a first look and for a tenant nobody has reviewed. Produces notes, not evidence.
• Microsoft Secure Score: included with the tenant, continuously updated, and useful as a trend line. It only scores actions Microsoft has chosen to score, so it misses manual controls and several benchmark items, and its percentage is not a pass mark anyone external recognises.
• An independent audit against the CIS Benchmark: a reviewer reads the configuration through a read-only application, checks the manual controls, grades every finding with evidence and a fix order, and writes a report designed to be used as evidence with insurers, clients and assessors. Brocent's is fixed-price by headcount, from US$450 for 1 to 10 users, with the report in 5 to 7 business days. The scope and price are on the Microsoft 365 security audit page.

The sensible sequence is to run the checklist first. If it finds nothing, you probably still want an independent view before you tell an insurer so. If it finds a lot, fix the critical items, then get the audit so that the result is documented by someone else.

Frequently asked questions

What is included in a Microsoft 365 security audit checklist?

The twelve areas above: MFA coverage, Conditional Access, privileged roles and break-glass accounts, legacy authentication and SMTP AUTH, app consent and enterprise applications, guests and external sharing, mail flow and forwarding, SPF/DKIM/DMARC, Defender for Office 365 policies, the audit log and alerts, DLP and sensitivity labels, and device and app protection. They map to the domains of the CIS Microsoft 365 Foundations Benchmark and to the structure of Brocent's sample report.

How long does it take to audit a Microsoft 365 tenant with this list?

For a tenant of up to about 50 users, reading every setting and recording it takes an afternoon if you already hold a reader role. Checking the manual controls, interviewing the people who hold privileged roles and writing up findings with severity and fix steps takes considerably longer, which is why an independent audit is quoted at 5 to 7 business days.

Do I need Global Administrator to run the checklist?

No. Global Reader can read almost everything on this page. Security Reader covers the Defender and Purview portals. Avoid auditing from a Global Administrator account; part of the point is to see how little you can do with least privilege.

Is an Office 365 security audit the same thing?

Yes. Office 365 is the older name for the suite; the tenant, Entra ID, Exchange Online and SharePoint are the same services, and the checklist applies without change. Searches for an Office 365 security audit are usually looking for exactly this.

Which CIS Benchmark version should I audit against?

The current published version of the CIS Microsoft 365 Foundations Benchmark at the time you audit. Brocent's sample report states v7.0.0, and the version is written on every report so that a reader can tell which recommendations were used. Ask any provider to name the version.

What does a Microsoft 365 security audit cost if I would rather not do it myself?

Brocent's independent audit is a fixed price set by headcount: US$450 for 1 to 10 users, US$990 for 11 to 25, US$1,800 for 26 to 75 and US$2,900 for 76 to 150, with larger tenants quoted. The report arrives 5 to 7 business days after a Global Administrator consents to the read-only application. The full price list and what each band includes are on the audit pricing page, and the background is in the post on Microsoft 365 security audit cost.

Will the checklist get me through cyber insurance or Cyber Essentials?

The checklist helps you find and fix the settings those questionnaires ask about, in particular MFA, administrator accounts, legacy authentication and patching. Neither this page nor an audit report grants certification or guarantees an insurer's decision. An audit report is designed to be used as evidence in those conversations; whether it is sufficient is the assessor's or insurer's call.

Next steps

Run the twelve areas against your own tenant and keep the notes, with dates. If you want a second pair of eyes, Brocent's independent audit reads the same areas through a read-only application, checks the manual controls, and delivers a graded report in 5 to 7 business days for a fixed price from US$450. Details are on the Microsoft 365 security audit page, and the sample report shows what you receive. To discuss your tenant, talk to a consultant.