A Microsoft 365 security audit examines who can access your email and files, what administrators and applications can change, and whether your organisation can detect and recover from misuse. This guide explains how to perform that review, with 60 checks and a downloadable worksheet.
Consider a tenant where everyone has registered for MFA, yet the policy protecting finance staff is still in report-only mode. An old supplier retains administrator access. An invoice-processing application can read mail long after its original owner has left. Each problem needs a different investigation, even though all three sit under “identity security.”
A useful audit connects the setting to the people, data and business process it affects. For each important control, establish three things: what is configured, where it applies, and what happens when you test it. That gives the person fixing the problem enough information to act—and gives you a way to verify the result.
Use the worksheet during your assessment. It contains all 60 checks with space for the result, evidence reference, owner and retest notes.
Download the audit worksheet (HTML). Complete it locally, then print or save it as a PDF. Entries are not saved automatically.
Start with the access that could do the most damage
Before working through every setting, identify the accounts and systems that could expose sensitive information, interrupt operations or change security controls. A finance mailbox, a tenant administrator and a widely used application deserve different tests.
- Administrator and partner access: who can change roles, policies, mail flow or recovery settings? Include former suppliers and eligible role assignments.
- Effective MFA coverage: which users and applications fall outside the intended protection? Check exclusions and sign-in results.
- Email forwarding and delegation: can someone read financial or customer correspondence through a rule, a shared mailbox or an old permission?
- Application access: which integrations can read mail or files independently of a user session?
- Sensitive-file permissions: can a guest or ordinary employee reach information outside their role?
- Investigation records: can you retrieve the events needed to explain a suspicious change?
- Recovery: can the business restore essential mail and files within an agreed time?
If this review uncovers suspicious active access or forwarding, involve your incident-response team. Preserve the relevant records and agree containment; a routine configuration change can otherwise remove information needed to understand what happened.
Define the tenant, workloads and evidence you will review
Start with a one-page scope that the tenant owner can approve. Record the tenant ID, verified domains, identity model, critical business processes, licences and review period. Name the workloads being assessed: Entra ID, Exchange Online, SharePoint, OneDrive, Teams, and any relevant Defender, Intune or Purview capabilities.
Then list the access paths: employees, guests, privileged accounts, managed-service providers, applications and hybrid identity connections. A small tenant with several external administrators and custom integrations can require more investigation than its user count suggests.
Choose samples deliberately. Include an administrator, a finance user, a recent leaver, a guest, a sensitive SharePoint site and an important application where those exist. Write down how you selected them and what remains untested. If a sample exposes a broad permission or policy problem, extend the review to the other objects affected.
Include Power Platform, Fabric/Power BI, Copilot and connected services when the organisation uses them. Azure subscriptions, virtual networks and hosted applications require an explicitly agreed additional scope. The identity connections between those systems and Microsoft 365 still need attention within the tenant review.
Agree read access, an evidence location and authorised test accounts before collection starts. Match permissions to the task, using an administrator-assisted review where necessary. For every material finding, retain the object or policy ID, collection time, affected scope and observed result. Reference sensitive evidence in a controlled repository rather than copying secrets or unnecessary personal data into the report.
Choose a baseline and record licensing limits
Use the applicable CIS Microsoft 365 Benchmarks and CISA ScubaGear and secure configuration baselines alongside Microsoft’s service guidance. Record the benchmark version and profile you used. The 60 checks below are our practical review structure, not a reproduction of either baseline and not a complete control mapping.
Microsoft Secure Score can help identify recommendations, but it cannot decide whether a permission is justified, whether an exception is acceptable or whether a recovery test meets your business needs.
| Capability | What to establish before assessing it |
|---|---|
| Security defaults / Conditional Access | Security defaults provide a baseline without custom Conditional Access policies. Conditional Access generally requires Entra ID P1; risk-based policies require P2. Record which model is active and verify its effect. |
| Privileged Identity Management | PIM requires Entra ID P2 or Entra ID Governance licensing for the relevant users. It is not simply “E5 or nothing.” |
| Defender, Intune and Purview | Confirm the specific service plans, assignments and workload entitlements. An administrator seeing a feature does not prove that every user is licensed or protected. |
| Audit retention | Purview Audit Standard generally retains records for 180 days. Premium retention depends on workload, policy and the licences of the users generating events. Entra sign-in retention is a separate consideration. |
Licensing references: Conditional Access overview and licensing, Microsoft Entra security defaults, Entra governance licensing, risk-based access policies, and Audit log retention policies and licensing.
Use Pass, Gap, Not tested, Accepted exception or Outside scope. Unavailable functionality is not an automatic pass. Explain compensating controls or the remaining risk.
1. Identity, privileged access and tenant ownership
Start with who can change the tenant. Include direct assignments, eligible roles, role-assignable groups, delegated partners and accounts inherited from earlier projects.
Where to verify: Microsoft Entra admin center, Microsoft 365 admin center and partner relationships.
ID01Account and owner inventory
Verify: Export enabled members, guests, service accounts and owners; reconcile them with current staff and suppliers.
Assessment: Every enabled identity has a current purpose and accountable owner. Investigate orphaned or unexplained accounts.
ID02Privileged assignments
Verify: Inspect active and eligible roles, group membership and delegated administrator relationships.
Assessment: Each grant is justified; daily work uses a separate account. Unexplained standing privilege is a finding.
ID03Password and recovery configuration
Verify: Review cloud and synchronised account policies, password reset methods and helpdesk identity checks.
Assessment: Recovery cannot bypass identity verification. Routine cloud-only password expiry is not treated as a security improvement.
ID04Emergency access
Verify: Inspect cloud-only recovery accounts, credential custody, strong authentication, alerts and the latest authorised access test.
Assessment: Recovery works independently of normal identity dependencies. Review restrictive policy exclusions and alert on every use.
ID05Privileged activation
Verify: Where licensed, examine PIM eligibility, activation duration, approvals and activation records.
Assessment: Privilege is time-limited where appropriate; emergency roles remain recoverable. A disabled or unlicensed feature is recorded honestly.
ID06Leavers and external administrators
Verify: Sample recent departures and ended supplier engagements; check sessions, credentials, roles and delegated access.
Assessment: Removal covers all access paths, not only the user account. Retained access has an owner and expiry.
Reference guidance: Emergency access accounts; Microsoft password policy recommendations.
2. MFA, authentication strength and Conditional Access
An MFA registration report does not establish that a particular sign-in required MFA. Read the effective policy result for representative users, administrators, applications and devices.
Where to verify: Entra authentication methods, Conditional Access, sign-in logs and identity risk reports.
AU01Effective MFA coverage
Verify: Compare authentication registration with enabled policy scopes, exclusions and sampled sign-in results.
Assessment: Required users actually encounter the intended control. Registration alone, report-only policies and unexplained exclusions do not pass.
AU02Phishing-resistant administrator access
Verify: Inspect accepted methods and authentication-strength requirements for privileged sign-ins.
Assessment: Administrators use the required phishing-resistant methods. SMS, push approval or a registered key alone do not prove enforcement.
AU03Conditional Access policy behaviour
Verify: Use policy evaluation tools and authorised pilot sign-ins for normal, guest, unmanaged-device and exceptional access.
Assessment: Expected access succeeds and prohibited access is denied. Retain policy IDs, outcomes and approved exceptions.
AU04Legacy and unused authentication paths
Verify: Review sign-in protocols, application dependencies and mailbox-level authentication exceptions, including SMTP AUTH usage.
Assessment: Unused paths are disabled; required applications use an approved method. Do not disable a business workflow without validating its replacement.
AU05High-risk sign-ins and sessions
Verify: Inspect risk response, session controls, token revocation procedures and the handling of lost devices.
Assessment: There is a tested response to suspected compromise. Distinguish licensed risk automation from manual review and compensating controls.
AU06Registration and policy changes
Verify: Review authentication-method changes, Temporary Access Pass issuance and Conditional Access changes for a defined period.
Assessment: Changes have accountable operators and reviewable records. Emergency exclusions do not become a permanent route around protection.
Reference guidance: Conditional Access overview and licensing; Microsoft Entra security defaults; Emergency access accounts.
3. Enterprise applications, consent and workload identities
Applications can retain access without a human signing in again. Review delegated permissions and application permissions separately, including existing grants created before current consent restrictions.
Where to verify: Entra enterprise applications, app registrations, consent policies and workload sign-in records.
AP01Application ownership
Verify: List enterprise applications and registrations; record business purpose, owners and recent use.
Assessment: Each active application has an owner. Dormant or ownerless applications are reviewed before removal or continued approval.
AP02Permission scope
Verify: Inspect tenant-wide application permissions and delegated grants, including mail, files and directory access.
Assessment: Permissions match the actual workflow. Broad access without a documented need becomes a prioritised finding.
AP03User and administrator consent
Verify: Review who can grant consent, approval workflows and sensitive grants already present.
Assessment: Users cannot silently approve unacceptable access. Existing grants receive review rather than relying only on the current consent setting.
AP04Secrets, certificates and federation
Verify: Inspect credential expiry, owners, rotation processes and federated credentials for important workloads.
Assessment: Credentials are controlled and monitored; expired ownership, long-lived secrets and unexpected trust relationships are investigated.
AP05App-only access
Verify: Review service-principal sign-ins and how application access is constrained and monitored.
Assessment: The review does not assume that user MFA protects app-only tokens. Unusual access has an investigation and containment path.
AP06Removal and incident response
Verify: Sample a retired integration and rehearse the documented process for disabling a compromised application.
Assessment: Revocation covers grants, credentials and continuing automation. The business understands what will stop when access is withdrawn.
Reference guidance: Application consent controls; CISA ScubaGear and secure configuration baselines.
4. Exchange Online, forwarding and domain authentication
A correct DNS record is only part of the review. Include every legitimate sender and inspect real mail flow, privileged mailbox access and rules that can redirect messages.
Where to verify: Exchange admin center, Defender outbound policies, public DNS and delivered message headers.
EM01Mail domains and sending services
Verify: Reconcile accepted domains with all systems that send mail, including finance, support, marketing and website services.
Assessment: Every sender is owned and documented. Obsolete services and unexpected domains are investigated.
EM02SPF, DKIM and DMARC alignment
Verify: Inspect DNS and authentication results on authorised test messages from each sending service.
Assessment: Legitimate mail authenticates and aligns with the visible From domain. Plan enforcement changes around validated senders and monitoring.
EM03Automatic external forwarding
Verify: Review outbound policy, remote domains, mailbox forwarding and inbox-rule destinations together.
Assessment: Unapproved external forwarding is prevented. A single tenant setting is not accepted as proof that all paths were checked.
EM04Delegation and shared mailboxes
Verify: Export Full Access, Send As and Send on Behalf grants; examine shared-mailbox identities and direct sign-in.
Assessment: Delegation has current owners and business reasons. Unneeded direct sign-in and historic permissions are removed through an approved change.
EM05Transport rules and connectors
Verify: Review mail-flow rules, inbound/outbound connectors and trust or filtering bypasses.
Assessment: Exceptions have a limited scope, an owner and a review date. Investigate routing or bypasses unrelated to a current requirement.
EM06Suspicious mailbox activity
Verify: Search a defined period for rule changes, forwarding changes and unusual access; correlate with sign-in history.
Assessment: Suspicious changes are resolved or escalated. A configuration review does not declare the tenant breach-free without investigating activity.
Reference guidance: External email forwarding controls; CISA ScubaGear and secure configuration baselines.
5. Defender for Office 365 and email threat protection
Check the policy that actually applies to the recipient. Built-in, preset and custom protection can coexist; a policy name or a purchased licence does not prove effective coverage.
Where to verify: Microsoft Defender portal: email policies, protection coverage, quarantine and incidents.
DF01Licensed recipient coverage
Verify: Reconcile users and groups with assigned licences, preset policies, custom policies and exclusions.
Assessment: Expected recipients receive the intended protection. Capture effective policy precedence and missing coverage.
DF02Impersonation protection
Verify: Review protected people and domains, actions, thresholds and exceptions.
Assessment: High-impact impersonation targets are included where the capability is used. Stale executives or broad exceptions are corrected.
DF03Safe Links behaviour
Verify: Inspect applicable settings, excluded URLs and authorised benign tests in the workloads being used.
Assessment: Protection behaves as intended; exclusions and user override options have an approved rationale.
DF04Safe Attachments coverage
Verify: Review attachment policies and the settings for SharePoint, OneDrive and Teams protection where licensed.
Assessment: Each in-scope workload has verified protection. A mail policy alone is not evidence of collaboration-workload coverage.
DF05Allow lists and quarantine
Verify: Inspect allow entries, transport-rule overrides, quarantine permissions and release procedures.
Assessment: Bypasses are narrow and reviewed. Users and helpdesk staff cannot routinely release threats without the intended safeguards.
DF06Reporting and response
Verify: Submit an authorised harmless test through the user-reporting process and follow its route to the response team.
Assessment: Reports reach an accountable responder with a recorded outcome. An enabled reporting button without operational handling is a gap.
Reference guidance: Defender for Office 365 deployment and policy coverage.
6. SharePoint, OneDrive, Teams and guest access
Tenant defaults do not describe every existing site or sharing link. Sample sensitive locations and test access as a legitimate external or low-privilege user.
Where to verify: SharePoint admin center, Teams admin center, site permissions and Entra external identities.
CO01External sharing defaults
Verify: Review tenant and site settings, default link types, expiry and who can invite external users.
Assessment: Defaults fit data sensitivity and business needs. Existing sites and exceptions are reviewed separately.
CO02Sensitive-site permissions
Verify: Inspect owners, members, direct grants, broad groups and broken inheritance on selected sensitive sites.
Assessment: Access corresponds to an approved audience. Unexpected broad access is evidenced using a permitted test identity.
CO03Existing links
Verify: Review anonymous and organisation-wide links to selected sensitive files and folders.
Assessment: Unnecessary links are revoked after owner review. Changing the default link type is not recorded as revoking old links.
CO04Guest lifecycle
Verify: Sample guest invitations, sponsors, last use, review decisions and access after an engagement ends.
Assessment: Guests have sponsors and review dates; stale memberships and cross-tenant access exceptions are addressed.
CO05Teams collaboration settings
Verify: Inspect guest access, external federation, shared channels, meeting access and third-party apps.
Assessment: Each collaboration path is reviewed in its own context; external chat access is not confused with guest file access.
CO06Unmanaged-device access
Verify: Test approved browser and download restrictions against in-scope SharePoint and OneDrive content.
Assessment: Results match the agreed device policy. Document any access path that permits downloading sensitive data to unmanaged devices.
Reference guidance: CISA ScubaGear and secure configuration baselines; Copilot permissions and data protection.
7. Intune, endpoints and mobile access
Record which device platforms and users are in scope. Enrolment, compliance and endpoint detection are separate checks; a managed device is not automatically healthy.
Where to verify: Intune admin center, endpoint protection inventory and effective device access results.
EP01Device inventory and ownership
Verify: Reconcile active access with enrolled devices, ownership, operating systems and stale records.
Assessment: Unsupported or unknown devices do not disappear from the audit simply because they are absent from Intune.
EP02Compliance enforcement
Verify: Review policy assignments, grace periods, exclusions and sign-in outcomes for a noncompliant test device.
Assessment: Compliance requirements affect access as designed. A compliance dashboard alone is not evidence of enforced access control.
EP03Encryption and recovery material
Verify: Sample disk-encryption status and the permissions and process used to retrieve recovery keys.
Assessment: Required devices are encrypted and keys are recoverable only by authorised staff through a controlled process.
EP04Endpoint protection health
Verify: Inspect sensor onboarding, active protection, tamper controls and alert connectivity on sampled endpoints.
Assessment: Required protection is healthy and reporting; installed software without current telemetry does not pass.
EP05Patching and local privilege
Verify: Review update policy, overdue security updates and local administrator access on representative devices.
Assessment: Exceptions have owners and treatment dates. Administrator rights are justified rather than assigned by convenience.
EP06Mobile application protection
Verify: Review app-protection assignments, data-transfer rules, lost-device response and selective wipe where used.
Assessment: Corporate data is handled according to the BYOD policy. Verify the user experience with an authorised test account.
8. Purview, sensitive data and Copilot readiness
Start with the data and audience, then assess the feature. Copilot follows existing access controls; oversharing can therefore become easier to discover without Copilot granting new permissions.
Where to verify: Microsoft Purview, SharePoint permissions and the administration surfaces for the AI features in use.
DP01Sensitive-data locations
Verify: Identify where regulated, confidential and commercially sensitive information is stored and who owns it.
Assessment: The review includes actual high-impact locations, not only an empty classification policy or demonstration site.
DP02Labels and protection
Verify: Inspect published sensitivity labels, assignment scope and a permitted protected-file access test.
Assessment: Labels and any encryption settings work for the intended audience; the presence of a label alone is not treated as access restriction.
DP03Data loss prevention
Verify: Review policy scope, exclusions, simulation/enforcement state and a benign test using synthetic data.
Assessment: The intended action occurs in the relevant workload, and alerts are handled. Record licensing and any unprotected channels.
DP04Retention and deletion
Verify: Inspect retention policies, holds, deletion rules and the handling of departed users.
Assessment: Retention follows approved requirements and does not substitute for a tested recovery plan. Resolve conflicting or unintended policies.
DP05Copilot content access
Verify: Where deployed, test approved low-privilege identities against representative sensitive-content scenarios and review sharing permissions.
Assessment: Unexpected discoverability is traced to permissions or governance gaps. Do not infer safety solely from a successful Copilot rollout.
DP06Agents and connected data
Verify: Inventory AI agents, connectors and other integrations with access to organisational data; inspect consent and data boundaries.
Assessment: Each connection has an owner and approved purpose. Permissions, publication scope and monitoring fit the data it can reach.
Reference guidance: Copilot permissions and data protection.
9. Audit logs, detection and investigation readiness
Test retrieval. A screenshot showing auditing enabled does not prove that the event, user, workload or time period needed for an investigation is available.
Where to verify: Purview Audit, Entra sign-in/audit logs, Defender and any connected SIEM.
LG01Audit capture
Verify: Verify auditing status and retrieve known authorised test events from relevant workloads.
Assessment: Expected events are searchable with actor, action, object and time. Record collection delay and any unavailable events.
LG02Retention by log source
Verify: Record retention and export arrangements for Purview, Entra and other relevant logs, including user licensing.
Assessment: Required investigation periods are supported. Do not assume Purview retention also applies to Entra sign-in logs.
LG03Log collection health
Verify: Inspect connector health, permissions, ingestion gaps and monitoring of collection failures.
Assessment: A stopped or degraded pipeline produces an actionable alert. Historical events can be retrieved from the intended destination.
LG04Privilege and policy alerts
Verify: Test or review detections for administrator changes, consent grants, security-policy changes and emergency-account use.
Assessment: Alert scope includes important change paths and reaches an owner; noise is managed without silencing critical events.
LG05Mailbox and data-access detection
Verify: Review detections for suspicious forwarding, unusual downloads and other scenarios relevant to the organisation.
Assessment: Investigators can correlate identities, apps and activity. Record coverage gaps rather than assuming every licence provides every detection.
LG06Investigation access and records
Verify: Rehearse log access with the incident-response role and capture an example investigation timeline.
Assessment: Responders have appropriate access, timestamps are interpretable, and evidence handling is documented without copying unnecessary sensitive content.
Reference guidance: Verify that audit logging is enabled; Audit log retention policies and licensing.
10. Recovery, incident response and ongoing governance
The review is not finished when a report is produced. Decide who fixes each gap, how the change will be tested and what evidence closes the finding. If the audit uncovers signs of an existing compromise, our Microsoft 365 incident response service on AI/Response covers account takeover, mailbox activity and data exposure.
Where to verify: Response procedures, backup administration, change records and the risk register.
RC01Account-takeover response
Verify: Walk through an authorised scenario covering account isolation, session revocation, app grants and malicious mailbox changes.
Assessment: The team knows who can act and how to preserve evidence. A password reset alone is not the entire containment procedure.
RC02Restore capability
Verify: Perform an approved recovery test for representative mail and files; record elapsed time and restored content.
Assessment: Recovery meets agreed business objectives. Recycle bins or retention settings are not accepted as a substitute for a demonstrated restore.
RC03Recovery-system access
Verify: Review backup administrators, authentication, deletion rights and dependence on the production tenant.
Assessment: An attacker controlling ordinary tenant access cannot automatically erase every recovery option; dependencies and residual risks are documented.
RC04Findings and exceptions
Verify: Review owners, deadlines, risk acceptance, expiry dates and retest evidence for outstanding items.
Assessment: Every unresolved material gap has a decision and an accountable owner. Deferred work is not reported as a passed control.
RC05Safe configuration changes
Verify: Inspect pilot groups, change approvals, rollback planning and confirmation of policy effects.
Assessment: Hardening changes are tested before broad enforcement; emergency recovery remains available.
RC06Reassessment triggers
Verify: Agree review dates and triggers such as acquisitions, new domains, licence changes, new apps, AI deployments or incidents.
Assessment: The organisation can detect configuration drift between full reviews and update the evidence after material changes.
Three checks worked through in practice
The checklist provides coverage. These examples show how to turn a configuration export into a conclusion. The PowerShell examples retrieve information; they do not change tenant settings. Use the relevant Microsoft Graph or Exchange Online modules and an authorised account with the required read access. An access error or failed collection must be recorded as incomplete evidence.
1. Establish whether MFA applies to the people you intend to protect
Begin with the intended access rule: for example, finance staff must use the approved authentication strength when accessing Exchange Online. Identify the policies, groups, exclusions and applications that determine that outcome.
This Graph query lists Conditional Access policies and prints their configuration for review. The documented delegated scope is Policy.Read.All; the signed-in account also needs an appropriate Entra role, such as Security Reader.
Connect-MgGraph -Scopes 'Policy.Read.All'
$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies | Select-Object Id, DisplayName, State
$policies |
Select-Object Id, DisplayName, State, Conditions,
GrantControls, SessionControls |
ConvertTo-Json -Depth 20Investigate disabled and report-only policies, excluded groups, and grant controls that differ from the intended requirement. Where security defaults provide the tenant’s protection, review that configuration separately; an empty Conditional Access export does not establish that MFA is absent.
Next, inspect an authorised test sign-in’s Conditional Access and authentication details. Record the account, application, device context, policy result and timestamp. A valid earlier authentication can satisfy an MFA requirement without a new prompt, so the absence of a prompt alone is inconclusive. Microsoft explains this distinction in its MFA sign-in reporting guidance. Report-only evaluation does not enforce the policy.
Close the check when: you can explain which control applied to the tested access, what authentication satisfied it, and how approved exceptions are handled. Retain the sign-in result alongside the policy configuration.
Microsoft references: Conditional Access PowerShell query, applied policies in sign-in logs, and report-only evaluation.
2. Follow the routes by which a mailbox can forward messages
Start with mailbox-level forwarding. Exchange Online’s Delivery property set includes the forwarding properties used below. The results identify configured destinations; you still need to establish whether the destination is internal or external, approved and reachable under the effective mail-flow policies.
Connect-ExchangeOnline
Get-EXOMailbox -ResultSize Unlimited -PropertySets Delivery |
Where-Object {
$_.ForwardingAddress -or $_.ForwardingSmtpAddress
} |
Select-Object DisplayName, PrimarySmtpAddress,
ForwardingAddress, ForwardingSmtpAddress,
DeliverToMailboxAndForward |
Format-ListInspect inbox rules separately. Replace the placeholder with a mailbox in the agreed audit scope. Including hidden rules broadens the review; examine conditions, enabled state and rule order as well as the destination.
Get-InboxRule -Mailbox 'finance@example.com' -IncludeHidden |
Format-List Name, Enabled, Priority, Description,
ForwardTo, ForwardAsAttachmentTo, RedirectTo,
DeleteMessage, StopProcessingRulesThen review outbound forwarding policy, remote domains, connectors and transport rules. Resolve directory-based destinations to their actual recipients. Check the owner and change history of unexplained rules. Where a live test is needed, use approved recipients and harmless test mail.
Close the check when: every forwarding route reviewed has a documented outcome. Distinguish an unwanted configuration that is currently blocked from a route that successfully delivers mail outside the organisation. Treat unexplained changes as investigation leads; their presence alone does not prove data theft.
Microsoft references: Get-EXOMailbox, Delivery property set, Get-InboxRule, and external forwarding controls.
3. Trace an application's permissions to its business purpose
Suppose an invoice-processing integration needs access to one shared mailbox. Its approved purpose gives you something specific to test: which mailboxes and data can the application actually reach?
Record the enterprise application’s object ID, owner, permissions, consent grants, credentials and available activity. Separate access performed on behalf of a user from app-only access. Check the workload’s effective restrictions as well as the permission grant; a broad-looking grant and an effective resource restriction need to be assessed together.
Ask the business owner to explain each permission. If the integration was retired, establish whether its credentials and grants still allow access. If it remains necessary, validate the proposed restriction with an approved test before changing production permissions.
Close the check when: the application's reachable data matches its documented purpose, or the excess access has a finding, owner and treatment decision. Keep the permission evidence and test outcome together. MFA controls for employees do not establish the security of an application's own credentials.
Microsoft reference: application consent settings. Review existing grants as well as the rules for future consent.
Write findings that an administrator can fix and retest
A finding needs an affected object, an observed condition, a credible consequence and a way to verify the repair. Keep the configuration evidence separate from conclusions about incident activity.
The following is a fictional example to illustrate the reporting detail. It is not a client result.
| Field | Example finding |
|---|---|
| Title | Finance group excluded from the required MFA policy |
| Observed condition | The finance group is excluded from the policy intended to protect Exchange Online. An authorised test with a member account confirms that access does not receive the required MFA protection, and the review identifies no other applicable control providing it. |
| Evidence | Policy and group IDs, membership at collection time, effective grant controls, and the test sign-in record with its timestamp and authentication details. Store sensitive exports in the evidence repository. |
| Business risk | Access to financial correspondence relies on weaker authentication than the organisation requires. A compromised account could expose payment discussions or support invoice fraud. The test does not establish that a compromise has occurred. |
| Remediation | Identify why the exclusion exists, validate the replacement with a pilot group, and remove or narrow the exception through change control. Confirm recovery access before enforcement. |
| Closure | The administrator provides the changed scope and a new test result showing the intended protection. Record the owner, completion date and any residual exception. |
Decide what needs action first
Prioritise by what an attacker could reach and what the business would lose. A naming inconsistency and an unexplained privileged account should not compete for attention merely because a scanner labels both as failures.
- Investigate promptly: unexplained privileged access, suspicious forwarding or other evidence that may indicate active misuse. Follow the incident process while preserving records.
- Schedule urgent remediation: confirmed gaps that expose critical identities or sensitive information, such as ineffective administrator authentication or excessive application access.
- Plan controlled improvements: changes with dependencies, including consent restrictions, sharing defaults and new device requirements. Agree a pilot, owner and deadline.
- Record accepted exceptions: document the business reason, affected scope, compensating controls, approver and expiry date.
Set deadlines using your risk method, actual exposure and operational constraints. Give each finding a named owner. Close it against the original test objective, with fresh evidence collected after the change.
What the completed report should contain
The report should let management make decisions and let administrators implement them. Include the scope and exclusions, review dates, methods, sampling limits, benchmark versions, findings with supporting evidence, a prioritised remediation plan and the status of any retests. State which controls were not tested and why.
For management, explain the affected business processes and unresolved decisions. For the technical team, include object references, effective policy details and acceptance criteria. Keep a setting that was never tested visibly separate from one that passed.
Choose tools for collection, then validate their findings
CISA ScubaGear can compare supported Microsoft 365 configurations with the SCuBA baselines. A CIS assessment uses the selected benchmark version and profile. Microsoft Secure Score helps track recommendations. Record which resource you used and what it covered so another reviewer can interpret the result.
Our Microsoft 365 and Entra ID auditing script and 365 Auditor application also support collection. Review their current permissions and coverage before use; the PowerShell audit guide explains the script’s intended scope.
Keep the raw output, collection time and any errors. Follow up missing data and manually validate material findings. Business ownership, acceptable sharing, policy exceptions and recovery outcomes still require investigation and decisions.
Getting an independent Microsoft 365 security audit
An internal review can identify obvious gaps and assemble the evidence for a deeper assessment. An independent audit is useful when you need someone to challenge the existing design, validate remediation or produce findings for a customer, insurer or management team.
Before commissioning work, agree the workloads, access, testing methods, deliverables and retest arrangements. Ask how the auditor will investigate policy exceptions and application permissions, and how much effective behaviour they will verify. Those choices determine the usefulness of the report.
Atlant’s Microsoft 365 security audit reviews tenant security and provides prioritised findings. Request a sample audit report by email to inspect the format, or review the scope and pricing.
Microsoft 365 security audit checklist: questions
What should a Microsoft 365 security audit include?
Review tenant ownership, privileged identities, effective MFA and Conditional Access, application consent, Exchange mail flow, email protection, collaboration, devices, data controls, logs and recovery. Record configuration, effective behaviour, exceptions and a remediation owner for each finding.
Is Microsoft Secure Score enough for an audit?
Use Secure Score to identify recommendations and track changes. It does not replace checking your policy exclusions, sensitive-data permissions, application grants, incident history or recovery results. A score improvement does not by itself establish that a particular business risk has been resolved.
Do we need Microsoft 365 E5 to use this checklist?
No. Record the licences and features your organisation actually has. Some controls use standard capabilities; others need specific Entra, Defender, Intune or Purview entitlements. Mark unavailable features explicitly and assess alternatives or residual risk instead of marking them passed.
Is this the same as a CIS Microsoft 365 audit?
No. These are 60 original review questions organised for practical use. For a CIS assessment, use the applicable licensed benchmark, record its version and profile, and map findings to its exact recommendations. This page does not reproduce the benchmark or claim certification.
How long does a Microsoft 365 security audit take?
The effort depends on tenant complexity, access, workload coverage and how much evidence must be collected and tested. Distinguish a configuration export from a review that validates effective access, investigates suspicious changes and tests recovery. Agree scope and deliverables before estimating duration.
Does the auditor need Global Administrator?
Not automatically. Match access to each evidence-collection task and use the least privilege that supports it. Some checks may require additional service-specific read permissions or an administrator-assisted session. Do not assume one reader role can retrieve everything.
How often should we repeat the checks?
Set a review cycle based on risk, change rate and contractual requirements. Recheck affected controls after material changes or an incident, and monitor important identity, permission and mail-flow changes between reviews. A previous report describes the tenant at that time.
References and review notes
This guide was updated on 16 October 2026. The checks are original Atlant Security review questions, informed by the linked Microsoft guidance and baseline resources. Product interfaces, licensing and available controls change; confirm the current documentation and effective behaviour in the tenant you are assessing.
For example, Microsoft’s current cloud-only password guidance discourages routine expiration. Emergency access needs a tested design rather than a blanket removal of every exclusion. Audit logging must be verified, not assumed from a licence name. Record how you assessed those decisions in the tenant under review.
- Emergency access accounts
- Microsoft password policy recommendations
- Conditional Access overview and licensing
- Microsoft Entra security defaults
- Application consent controls
- External email forwarding controls
- Defender for Office 365 deployment and policy coverage
- Verify that audit logging is enabled
- Audit log retention policies and licensing
- Copilot permissions and data protection
- CISA ScubaGear and secure configuration baselines
- CIS Microsoft 365 Benchmarks
