Microsoft 365 security assessment: what to review and where to start

Published and reviewed on 16 September 2026.

In Microsoft 365, the problem is rarely a lack of security controls. The work lies in establishing which controls are configured, whom they protect, which exceptions exist and whether they work as expected.

In an assessment, I usually start with a specific question: what would the organisation need to demonstrate before I could consider an important access path protected? “We have MFA” is a starting point. We still need to know which accounts require it, for which applications, using which methods and what happens to those left out.

A Microsoft 365 audit cannot be reduced to a score

Microsoft Secure Score helps identify improvements and track progress. It is a useful baseline for an assessment. Microsoft explicitly states that its recommendations do not cover every attack surface for each product. It also recognises alternative mitigations and solutions from other vendors. Secure Score documentation.

A reasonably high score can coexist with an administrative account excluded from a policy, old application consents or confidential information shared too broadly. These are scenarios to investigate, not claims about every tenant.

A tenant is the organisation's environment in Microsoft's cloud services. If you searched for an “Office 365 audit”, this guide covers security assessment of a Microsoft 365 environment; some subscriptions and services retain the Office 365 name.

Identity Secure Score focuses on identity posture in Microsoft Entra ID. It should not be confused with the broader Microsoft Secure Score or treated as a complete measure of the tenant. Identity Secure Score scope.

Before opening the portals: context, scope and licensing

The same configuration can represent different risks depending on what it protects. Before evaluating controls, I need to understand users, locations, remote work, devices, critical applications and sensitive data, alongside supplier access and any hybrid architecture with on-premises systems.

The sector, contractual or regulatory requirements, maturity and previous incidents help determine where to go deeper. Licences are reviewed by capability and benefiting users: seeing an option in a portal does not prove it is available under every plan.

I would distinguish four references from the outset: requirements applicable to the organisation, Microsoft recommendations, an external benchmark such as CIS Microsoft 365 Foundations and good practices proposed by ACBSEC. A benchmark deviation does not, by itself, establish a legal breach.

Evidence collection is agreed with minimum permissions and read access wherever possible. Global Administrator is not needed for every part of an assessment. Tests with operational impact, configuration changes and rollback must be authorised and separated from observation.

Identity: who exists and how they prove who they are

In Microsoft Entra ID, I would first examine identity lifecycle and authentication mechanisms. An inactive account with significant access raises a different question from an active user with a weak authentication method.

Accounts, guests and hybrid identity

I would map personal, administrative, guest and service accounts to an owner and purpose. The last sign-in is a signal, not an automatic instruction to delete an account. Non-interactive access, dependencies and offboarding must be checked. In a hybrid environment, the identity's source and the consequences of synchronisation failure also matter.

Methods and phishing resistance

Multifactor authentication (MFA) requires more than one factor, but methods do not all provide the same protection. I would review registration, recovery and allowed methods. Authentication strengths allow Conditional Access to require combinations of methods, including phishing-resistant authentication. Microsoft Learn: authentication strengths.

Where passkeys/FIDO2 are appropriate, I would check compatibility, recovery and actual deployment before treating the work as complete. The Entra ID passkeys guide covers implementation in more detail.

With Microsoft Entra ID Protection, I would examine detections and the handling of user and sign-in risk available under the licence. The full experience requires Entra ID P2; access to some data is not equivalent to having every capability. Availability and licensing.

Conditional Access: what each policy actually protects

Reviewing Conditional Access means checking which access decisions apply to each scenario. Microsoft defines it as its Zero Trust policy engine: it uses identity, device, location and other signals to decide access. It requires Entra ID P1; user-risk and sign-in-risk policies require P2. Scope and licensing.

I would pay particular attention to administrators, guests, unmanaged devices and any remaining legacy clients. A trusted location does not, by itself, establish that a device is secure. Reviewing one policy in isolation is also insufficient: understand the others applying to the same access.

Report-only evaluates a policy but does not enforce its access controls. Its results help assess impact; they are not evidence that access was blocked. Microsoft also warns of possible device certificate prompts in certain scenarios, so it should not be presented as a mode that is always invisible to users. Report-only evaluation.

I would use simulation tools as support and compare their results with logs. The absence of a fresh MFA prompt does not establish that the requirement was bypassed: previous authentication may have satisfied it. The conclusion needs to rest on the access details.

Privileges: who can do what, and for how long

The number of Global Administrators is an initial signal. Other roles, their permission scope, who can assign them and whether an everyday account shares credentials with administrative work also matter.

I would review permanent and eligible assignments, service accounts and workload-specific privileges. With Privileged Identity Management (PIM), I would check activation, duration, justification and approval where configured. PIM requires Entra ID P2 or Entra ID Governance; other governance features have their own conditions. Identity Governance licensing.

Emergency access, or break-glass, accounts need separate treatment. Independence, credentials, protection, monitoring and access tests must be validated. An exclusion intended to prevent tenant lockout must not turn into an everyday account or be interpreted as a recommendation to leave it without MFA. Microsoft's current recommendations.

Devices: what changes when the device is unmanaged

A valid identity says nothing about the device being used. Where Intune is available, I would review compliance policies, their assignments and how Conditional Access uses the result. Registration in Entra, enrolment in Intune and compliance with a policy are different states. Intune and Conditional Access.

I would not assume Intune or Defender for Endpoint has been deployed. If the organisation uses other tools, the assessment must include them and check their coverage. For personal devices — bring your own device, or BYOD — the decision may be to limit certain uses or protect applications, depending on context and licensing, rather than requiring the same management as corporate devices.

Email: what can enter, leave or be redirected

In Exchange Online, I would review both message protection and routes that can redirect information. Antispam and antiphishing policies are evaluated through assignments, exclusions and results, not simply their existence.

I would check SPF (authorised senders), DKIM (message signing) and DMARC (domain policy for authentication failures) against all legitimate senders for the domain, including suppliers. Changing email authentication without that inventory can disrupt valid messages. Safe Links, Safe Attachments and advanced impersonation protection are reviewed where the corresponding Defender for Office 365 plan covers them. Microsoft's recommended settings.

I would also examine external forwarding, relevant inbox rules, connectors and shared mailbox permissions. An automated rule is not inherently malicious: its destination, author, date and purpose must be checked. Protocols and applications still using legacy mechanisms need current evidence rather than an assumption that they have all disappeared.

Collaboration: who can share which information

SharePoint, OneDrive and Teams require reviewing who can reach data and how access can expand. Tenant-wide settings alone do not describe permissions on each site, team or file.

An organisation can have correctly configured MFA while sharing confidential information through anonymous links. There is no contradiction: authentication and sharing controls protect different situations. I would review Anyone links, direct permissions, guests, owners and the continued need for old collaboration spaces.

In Teams, I would distinguish external access for communication from guest access and shared channel mechanisms. I would then follow the files into SharePoint or OneDrive. The assessment connects sensitivity, external access and devices, without concluding that disabling one Teams setting resolves every sharing issue. External sharing model.

Applications and OAuth: access without an interactive session

Applications can retain access to information even when nobody opens their interface again. I would therefore review app registrations, enterprise applications and their service principals, the local identities through which they act in the tenant. Applications and service principals.

Delegated permissions and application permissions are different. The former allow action on behalf of a user; the latter allow an application to act under its own identity without a signed-in user. OAuth is the authorisation framework used to grant access, not evidence that an integration still serves a valid purpose. Permissions and consent.

The business question is which applications can read email, files or Microsoft Graph data without a person signing in each time. I would look for an owner, purpose, granted permissions, admin consent, recent use and valid secrets or certificates. A familiar application can have excessive access; an old integration may still be critical. Check before removing permissions.

User MFA does not, by itself, cover all application identity access. User Conditional Access policies should not be assumed to apply to those identities in the same way.

Defender: verify coverage and alert response

A Microsoft Defender assessment starts with what is licensed, onboarded and sending signals. Microsoft Defender XDR connects information from available solutions; the presence of its portal does not establish that every component has been purchased or deployed. Defender XDR prerequisites.

I would check email protection with Defender for Office 365, onboarded devices and sensor health in Defender for Endpoint, identity coverage where Defender for Identity is present, and application integrations with Defender for Cloud Apps. The selection depends on architecture and available plans.

For each, compare the expected inventory with observed coverage, exclusions and last communication. Then follow an alert to its recipient: who receives it, how they investigate, when they escalate and what they can contain. A control producing alerts nobody reviews has an operational limitation that belongs in the report.

Purview: start with the information needing protection

Before creating data loss prevention (DLP) rules, establish what information needs protection, where it resides, who uses it and which movements are legitimate. Then decide what behaviour to prevent and how to handle exceptions.

Where Microsoft Purview applies, I would review classification, sensitivity labels, label publication and DLP policies across the channels actually covered. A label does not always imply encryption; its effect depends on configuration. Retention, Audit and insider risk capabilities are assessed separately, according to needs and licensing.

Advanced capabilities are not universally included. The official service description is the licensing reference; ACBSEC's Purview guide helps with orientation. Our DLP approach develops the business decisions preceding the rules.

Logs: can we reconstruct an incident?

Having logs does not guarantee they can be used when needed. I would check which events are collected, from when, how long they are retained, who can query them and whether they are exported to an analytics platform or security information and event management system (SIEM).

Entra sign-in logs and Microsoft Purview Audit are distinct sources with different retention and conditions. For standard audit and sign-in logs, Entra documents seven days with Free and thirty with P1/P2. Longer retention needs planned export and storage, or an applicable alternative. Microsoft also documents extended Entra audit-log retention through Purview Audit (Premium) with suitable licences. Entra retention.

In Purview, I would verify that auditing is actually enabled and which retention applies to the users and activities in scope. Microsoft warns that auditing is not enabled by default for certain small-business plans; having Microsoft 365 is not enough to assume it is active. Audit status and conditions.

A useful check is to ask the team to reconstruct a known, authorised action: who accessed it, from where, what changed and what evidence remains. If data is missing, the finding must say so. An assessment cannot promise to reconstruct months of activity when the logs were never retained.

Exceptions: ownership, justification and continued need

Exceptions deserve as much attention as the main policy. I would ask why an account, device or application was excluded, who authorised it, for how long and what would allow that exclusion to be removed.

The same analysis applies to Conditional Access, Defender exclusions and DLP exceptions. “We did it to make things work” explains the origin, not the continued need. Some exclusions are reasonable; they need proportionate scope and a verifiable compensating control.

A simple register covering owner, reason, accepted risk, alternative measure and review date is often more useful than an exception list without context. This is an ACBSEC governance proposal, not a mandatory Microsoft document format.

From a technical finding to a decision

A finding should help decide what to do next Monday. “Fourteen users are excluded from CA-01” is not enough to evaluate risk until we know who they are and which other controls affect them.

Prioritise by risk and feasibility

Priority combines exposure, impact, ease of exploitation, scope and compensating controls. Effort and dependencies organise delivery, but they do not make a serious risk disappear because fixing it is expensive.

Fictional case: a business with 400 employees

What an assessment should deliver, and what I would ask for

A good assessment provides an executive summary, scope and methodology, evidence, findings, risks and recommendations. Its plan should separate immediate improvements, dependencies and decisions needing business input, with a feedback session to agree next steps.

It should also explain limitations: excluded services, samples used, missing data and unverified controls. Exporting automated recommendations is not a substitute. The cybersecurity audit service provides that evaluation; technical consulting can address subsequent implementation.

Initial information

I would ask for user numbers, domains, licences, services used, hybrid architecture, owners, objectives and known problems. These define scope and required access. I would not ask for passwords or application secrets in a preparation email.

Twenty questions to assess your starting point

Tick the questions for which you have a verified answer. This is not a compliance test and produces no security rating. Selections only support reading; they are neither saved nor sent.

When to repeat the assessment

Frequency depends on change and exposure, alongside applicable requirements. Combine an agreed periodic review with checks after significant additions, identity changes, integrations, mergers or incidents.

Monitoring alerts and changes is part of daily operations; a one-off audit does not replace it. After remediating a finding, verify the outcome. I would not present annual or quarterly assessments as a universal Microsoft, ISO or NIS2 requirement.

Frequently asked questions

What does a Microsoft 365 security assessment include?

An agreed scope covering identities, access, privileges, devices, email, data, applications and detection. It should verify coverage and exceptions, retain evidence and deliver prioritised recommendations.

Does Microsoft Secure Score replace an assessment?

No. It helps identify improvements, but its recommendations do not cover every attack surface. An assessment adds context, testing, dependencies and risk evaluation.

Can Microsoft 365 be assessed without E5?

Yes. The assessment reviews available controls and the risks in the environment. E5 is not a universal prerequisite; additional capabilities should be justified against specific needs and licensing.

Does enabling MFA mean every account is protected?

Not necessarily. Check users, applications, accepted methods, exceptions and logs. An earlier authentication can satisfy MFA without a fresh prompt.

Does Microsoft require MFA for every Microsoft 365 access?

Microsoft’s mandatory MFA rollout covers specific scopes and phases, including certain administration portals and tools. It does not prove that every user, application and scenario in a tenant has the intended coverage.

Which licence does Conditional Access require?

Conditional Access policies require Entra ID P1; policies based on user or sign-in risk require P2. Other capabilities and identity types may have different requirements. Verify the scenario and licence assignments.

Does a report-only policy block access?

It does not enforce the access control: it evaluates the outcome for review in logs. Some device scenarios can trigger certificate prompts, so the user experience also needs testing.

How does an Entra ID assessment differ from a Microsoft 365 assessment?

The former focuses on identity and access. A Microsoft 365 assessment extends to email, collaboration, information protection, devices, applications and operations, within the agreed scope.

Is it safe to exclude emergency access accounts?

The design should preserve recovery access without leaving an everyday account unprotected. Microsoft recommends phishing-resistant methods, monitoring and testing. Assess exclusions alongside compensating controls.

How long does an assessment take?

It depends on tenants, services, integrations, hybrid complexity and evidence availability. An estimate should specify scope, samples, meetings and deliverables; user count alone is insufficient.

Does the assessment require administrator passwords?

Passwords should not be shared. Agree named access with appropriate minimum permissions, a limited duration and traceability, or supervised sessions and exports where suitable.

Does an assessment change the configuration?

Review work and implementation should be distinguished in the scope. Any test or change needs agreement, impact assessment, supervision and a rollback approach.

How long are logs retained?

It depends on the source, licence and configuration. Entra documents seven days on Free and thirty on P1/P2 for standard audit and sign-in logs. Purview Audit has different conditions; verify what evidence is actually available.

Does the assessment demonstrate ISO 27001 or NIS2 compliance?

Not by itself. It can provide evidence for a broader evaluation. Obligations depend on the scope and applicable framework; a Secure Score recommendation does not thereby become a regulatory requirement.

What should I receive at the end?

An executive summary, scope and limitations, evidence-backed findings, risks and recommendations. Also a prioritised plan with dependencies, suggested owners and a meeting to agree next steps.

Microsoft mandatory MFA scopes.

Check whether accumulated decisions still make sense

Microsoft 365 changes with every new user, application, exception and service. Documentation does not always keep pace. An assessment establishes which decisions remain valid, which have lost their justification and which risks have gone unattended.

If you want to review how your environment is actually configured, ACBSEC's Microsoft Security service connects assessment with improvement. The priority is to help you decide what to fix and enable your team to maintain it.