You do not need a consultant to start understanding how safe your Microsoft 365 tenant is. With a few hours of focused time, read-only access and a clear order of work, a capable administrator can run a useful first-pass Microsoft 365 tenant security audit. It will not replace an independent review, but it will surface the most common problems and give you a stronger starting point.
This guide walks through the process in order: scope, access, identity, email, collaboration, devices, data, logging, reporting and remediation. For each step, you will see what to check, what "good" looks like and where people often get stuck. It also marks the points where DIY ends and expert help becomes worth the money.
The steps assume a typical small or mid-sized US organisation with a single tenant. If you have several tenants, hybrid identity or strict compliance duties, the same flow applies but takes longer. If you would rather hand the work to specialists, a professional Microsoft 365 tenant security audit follows the same structure with deeper evidence and reporting.
Set yourself up properly before opening any portal.
Use the least privilege you can. For reviewing, roles such as Global Reader and Security Reader give broad visibility without the power to change things. If you must use a more powerful role for a specific task, use it only for that task and sign out afterwards.
Work from a trusted device. Use a managed, patched computer, not a personal laptop, particularly if you export data.
Keep notes as you go. Record what you checked, when, with which account and what you found. Notes become your evidence and your report.
Take screenshots and exports carefully. They contain sensitive information. Store them in a restricted folder and delete them when no longer needed.
Do not change things during the review. Resist the urge to fix as you go. Record the finding first, then plan the change. Otherwise you lose the baseline and risk breaking something unexpectedly.
Write one paragraph that answers four questions. Why are we doing this? Which tenant or tenants are in scope? Which workloads will we cover? Who will read the report?
A reasonable first scope covers Entra ID (identity), Exchange Online (email), SharePoint, OneDrive and Teams (collaboration), Intune (devices, if used), enterprise applications and the Purview audit log. Add anything that matters to you, such as a hybrid Active Directory or a third-party mail filter.
Also write down what is out of scope. If you are not reviewing on-premises servers, say so.
Where people get stuck: A scope that is too large. If time is short, do identity and email first. You can run the other sections in a second pass.
Licences decide which controls are available. In the Microsoft 365 admin centre, review which plans your users hold and which add-ons exist. Note the plan names and the number of users on each. For example: Business Premium for most staff, E3 for managers, Exchange Online Plan 1 for shared mailboxes.
What good looks like: A simple table of user groups and plans, plus a list of key security features you do and do not have. For instance, Conditional Access and Intune are included in some plans and not in others.
Where people get stuck: Mixed plans and old add-ons. If you find users with no licence or licences no one can explain, note them. They are findings too.
Identity comes first because it carries the most risk.
List privileged roles. In the Entra admin centre, open Roles and administrators. Export or note every holder of Global Administrator, Privileged Role Administrator, Exchange Administrator, SharePoint Administrator, Security Administrator and similar roles. Ask for each: is this still needed, is the account separate from daily email, and is it protected by strong authentication?
Review the Global Administrator count. A small number is better. If you see more than a handful, find out why.
Check emergency access accounts. You should have two. Confirm they exist, have long passwords stored securely and are monitored. Check they were not forgotten or deleted.
Review MFA coverage. Work out who is actually required to use MFA. Look at Conditional Access policies, Security Defaults and per-user settings. Use authentication methods reports to see who has registered methods. Note anyone without coverage, and pay attention to service accounts and shared mailboxes with sign-in enabled.
Review guests. List guest users, who invited them and when they last signed in. Flag stale ones.
What good looks like: A short list of named administrators using separate, strongly protected accounts, MFA required for everyone with documented exceptions, two monitored emergency accounts and a guest list that matches current projects.
Conditional Access is where identity rules are enforced, and where most hidden gaps live.
List every policy. Note its name, state (on, off or report-only), included users and apps, excluded users and groups, conditions and grant controls.
Look closely at exclusions. For each exclusion, find out who is in it, who approved it and why. Emergency accounts are acceptable. Large groups of ordinary users are not, unless there is a clear reason.
Check for a legacy authentication block. Look for a policy that blocks legacy client types, and check sign-in logs for any remaining legacy sign-ins.
Test with "What If" and report-only. The What If tool lets you simulate a sign-in and see which policies apply. Report-only mode lets you see the effect of a new policy before enforcing it.
Check device and risk-based controls. If you hold the licences, see whether device compliance or sign-in risk conditions are used.
What good looks like: A small, readable policy set with clear names, justified exclusions, a legacy block, MFA for all users, stronger methods for admins and tested effect.
Email carries many attacks, so check the full chain.
DNS records. Look up SPF, DKIM and DMARC for each domain you send from. Free online lookups work, or command-line tools. Note whether DMARC is set to none, quarantine or reject.
Protection policies. In the Defender portal, review anti-phishing, anti-spam and anti-malware policies. If you have Defender for Office 365, look at Safe Links, Safe Attachments and whether the Standard or Strict preset security policies are applied. Check that executives and finance users have impersonation protection.
Mail flow rules and connectors. In the Exchange admin centre, list transport rules and connectors. Look for rules that bypass spam filtering, forward mail externally or exist from old migrations. Remove nothing yet. Record what each does and who owns it.
Forwarding and inbox rules. Check outbound spam policy settings on automatic forwarding. Use PowerShell to list mailboxes with forwarding set and inbox rules that forward or redirect. These are classic signs of compromise.
Mailbox permissions. Review Full Access and Send As permissions on executive, finance and shared mailboxes.
What good looks like: SPF and DKIM in place, DMARC moving toward reject, strong anti-phishing policies with priority accounts covered, clean mail flow rules with owners, no unexplained forwarding and permissions that match current roles.
Tenant sharing level. In the SharePoint admin centre, check the organisation-wide external sharing setting and default link type. "Anyone" links are the most permissive.
Site-level overrides. Identify sites with more open sharing than the tenant default.
Anonymous links and guests. Use reports or the Purview audit log to see how many anonymous links exist and how old they are. Look at guest membership in teams and sites.
Ownership. Check for teams and sites with no owner, or with owners who have left.
Sensitive locations. Ask department heads where sensitive data lives, such as HR, finance, legal or client records. Check the sharing and membership of those locations first.
What good looks like: A restrictive default, link expiry where anonymous links are allowed, owners for every team and site, and tighter rules on sensitive locations.
Enterprise applications. In the Entra admin centre, open Enterprise applications. Sort or filter by permissions such as reading mail or files for all users. Note the publisher, when it was consented and by whom.
User consent settings. Check whether any user can consent to any app. Look for an admin consent workflow.
App registrations. Review applications your own staff or vendors registered, especially those with secrets or certificates that never expire.
What good looks like: Consent limited to verified publishers and low-risk permissions, an approval workflow, and a short list of apps with known owners and purposes.
If you use Intune, open the device compliance and configuration sections.
Compliance policies. Check that there is at least one for each platform you use, covering encryption, screen lock, OS version and endpoint protection.
Link to access. Confirm that Conditional Access uses device compliance for sensitive apps. A compliance policy that nothing enforces is only a report.
App protection. For personal phones, see whether mobile app protection policies exist.
Unmanaged devices. Check sign-in logs to see how many devices connect without management.
What good looks like: Clear compliance rules, enforced for key apps, with a sensible approach for personal devices.
If you do not use Intune, note how unmanaged devices reach company data and whether you rely on another tool.
Unified audit log. In Microsoft Purview, confirm that auditing is on. Check which audit tier your licences provide and the retention period.
Mailbox auditing. Confirm it is enabled for all mailboxes.
Sign-in and audit logs. In Entra, see how far back the logs go. Decide whether you need longer retention and whether to export logs elsewhere.
Alert policies. List existing alerts and who receives them. Look for coverage of new admin role assignments, new forwarding rules, mass downloads and risky sign-ins.
Run a test. Search for a known action from last week, such as a file download or a sign-in, and check that evidence appears.
What good looks like: Logging on, retention that matches your investigation and compliance needs, and alerts that someone reads.
If you have Microsoft Purview features, review sensitivity labels, data loss prevention and retention policies. Note whether they are active or stuck in test mode, which locations they cover and whether anyone reviews matches.
Be realistic. For many small organisations, labelling a handful of the most sensitive locations is a better first step than a broad classification scheme.
Now turn your notes into findings. For each issue, write:
What we observed. A plain statement of fact.
Evidence. Where you saw it, such as a policy export, screenshot or log search.
Why it matters. The risk in simple terms.
Recommended action. What to change, and any licence dependency.
Owner and target date. A real name and a date.
How to confirm it is fixed. A test you can repeat.
Use three honest labels: observed, not observed and unable to verify. If a log was unavailable, do not call the control missing. Say you could not verify it and explain why.
Rate each finding as high, medium or low based on likelihood and impact. Missing MFA for finance staff is high. A tidy-up of a rarely used Team is low.
Group findings into three buckets:
Quick wins with what you already own. Examples include blocking legacy authentication, removing stale guests and reducing Global Administrators.
Changes that need planning. Examples include moving DMARC to reject, enforcing device compliance and restructuring sharing.
Items that need budget or a licence change. Examples include Privileged Identity Management or advanced auditing.
Order the work by risk and effort. Pilot anything that could affect users, use report-only mode where it exists and keep a rollback plan. Communicate changes to staff before they happen.
After the fixes, check that they work. Re-run the relevant tests, such as sign-in checks and sharing reports, and update your notes. Then schedule the next review. Quarterly checks on identity, sharing and apps work well, with a fuller review each year and extra checks after big changes.
A self-run audit is a strong start. Consider bringing in an independent reviewer when:
The tenant is large, hybrid or spread across several tenants.
An insurer, customer or regulator wants independent evidence.
You need deeper work on areas such as OAuth abuse, privileged paths or device code phishing exposure.
Your team lacks time or specific expertise.
You want a fresh view of a setup your own team built.
Experts also bring comparison with many other tenants, which helps you judge what is normal and what is unusual.
For a small tenant, a focused first pass might take a day or two spread over a week. Larger tenants take longer. Writing up findings often takes as long as the checking.
Read-only roles such as Global Reader and Security Reader cover most of the review. A few checks in Exchange may need specific read permissions.
Yes. PowerShell and Microsoft Graph help with exports, and tools such as ScubaGear and Maester help compare against baselines. Use read-only commands and review any script before you run it.
If you find signs of compromise, such as unexplained inbox rules, unfamiliar admin accounts or odd sign-ins, stop treating it as an audit. Contain it first: reset credentials, revoke sessions and remove malicious rules and consents. Consider professional incident response help.
Lead with the top three risks in plain language, say what is already working, and show a short plan with owners, dates and rough costs.
Running a Microsoft 365 tenant security audit is mostly a matter of order and discipline. Define the scope, gather evidence without changing anything, look at identity and email first, then sharing, apps, devices and logging. Write findings that someone can act on, and plan the follow-up before you start.
Do the work once and you will have a baseline. Repeat it on a schedule and you will have a trend. If you decide you want independent support, Atlant Security offers reviews built around evidence, licences and practical remediation. Either way, the real value comes from what you fix afterwards.