M365 Security Audit Without a Security Team

How do I audit Microsoft 365 security when I have no security team?

A single-admin Microsoft 365 security audit runs five sequential passes: privileged-access enumeration, MFA and Conditional Access coverage, oversharing exposure ahead of Copilot, a one-page findings report, and a scheduled re-run to catch drift. Running these passes in order, rather than opening every admin center at once, turns a vague health check into named, actionable findings.

The real constraint on a Microsoft 365 security audit is almost never headcount — it is sequencing. An admin with no security background can produce a credible, evidence-backed audit in an afternoon if the four passes run in the right order. Run them out of order, or try to do all four at once, and the result is a pile of half-finished tabs and no clear finding to act on first. The temptation, faced with a tenant that has been running unmanaged for two years, is to open every admin center at once and start clicking. That produces anxiety, not a finding list. The order below exists specifically so each pass finishes with something concrete before the next one starts. You do not need a security team — you need an order of operations Each pass below produces a concrete, named list — not a percentage, not a color-coded tile. That list is the deliverable, and it is what makes the next pass possible. Pass 1: who has privileged access, and is any of it standing when it should be eligible-only Pass 2: where MFA and Conditional Access actually apply, versus where a named policy exists but a user or app is quietly excluded from it Pass 3: what is shared more broadly than it should be, before a Copilot rollout makes that reach far larger Pass 4: turn the first three passes into one report management can actually read Pass 5: re-run this on a schedule to catch drift Step 1 — Enumerate who has privileged access Privileged access is where a single missed account causes the most damage, so it goes first. The goal is a named list, not a role count. A tenant with "12 Global Administrators" is not a finding — it is a starting point. The finding is which twelve, whether each one still needs standing access, and whether any of them is a service account nobody remembers creating. Entra ID role assignments, listed by person, not by role name alone Standing role assignments versus eligible (activation-required) roles — a standing Global Administrator is a bigger finding than an eligible one Service principals and app consents with high-privilege Graph scopes, which are frequently forgotten because no human logs in with them Break-glass accounts — confirm they exist, are excluded from Conditional Access as intended, and are not being used for day-to-day work Step 2 — Check MFA and Conditional Access coverage A tenant can have Conditional Access policies that look complete on paper and still have real gaps — a named policy is not the same thing as actual coverage. This pass exists to find the difference. The most common gap is not a missing policy; it is an exclusion group that was added for a one-time troubleshooting session and never removed, quietly carving a hole in coverage that otherwise looks complete in the policy list. Users or groups explicitly excluded from a Conditional Access policy, and whether that exclusion is still justified Legacy authentication protocols still permitted anywhere, since they bypass modern MFA enforcement entirely Gaps between what a policy claims to cover and what actually gets enforced at sign-in — check a real sign-in log sample, not just the policy configuration screen Step 3 — Find the oversharing before Copilot does This pass matters on its own, and it matters more specifically if Copilot is coming. Copilot answers a prompt using whatever the asking user can already reach — it does not create new exposure, but it does make existing oversharing far easier to stumble into. A site with a broken permission boundary sitting quietly for three years is a low-probability risk today; the same site is a much higher-probability risk the day everyone in the company gets a natural-language way to ask "what does this company know about X" and get an instant answer pulled from wherever that answer happens to live. Anonymous and "anyone" sharing links still active anywhere in SharePoint or OneDrive Sites shared externally, and whether that external access is still needed Sites with broken or unusually broad permission inheritance, where a folder-level grant quietly widened past its intended scope Why this pass is worth doing before a Copilot rollout specifically: fixing an oversharing finding before rollout is a quiet cleanup; discovering it during a rollout demo is not Step 4 — Turn findings into a one-page report Management does not need the raw output of three passes — it needs a one-page summary with the highest-severity findings at the top and a clear next action for each. The export from each pass is the evidence behind that report; keep it, because it is what turns "we looked into it" into something you can actually show. Structure the page the same way every time: finding, severity, owner, and target date. A report that changes shape every quarter is harder for management to compare against the last one, and comparison is the entire point of Step 5. Step 5 — Re-run it on a schedule Posture drifts the moment you stop looking — a new privileged role gets granted for a project and never revoked, a sharing link gets created for a one-time file drop and stays live for a year. A single audit is a snapshot; the real signal comes from comparing two runs and seeing what changed between them. Put this on a recurring schedule rather than treating it as a one-time project. A monthly cadence for the privileged-access and Conditional Access passes, and a quarterly cadence for the oversharing pass, catches most drift before it turns into an incident — and a second run that shows the same four passes clean is itself a useful piece of evidence for the next audit or insurance questionnaire. What an audit cannot tell you This is a detective control, not remediation and not a SIEM — it produces a findings list, and the fix happens afterward in the Entra ID, Defender, or Purview consoles. Severity ranking uses a documented internal heuristic that may diverge from Microsoft Secure Score. Coverage stops at the Graph permission surface actually granted, and some signals require a matching Microsoft license to enumerate at all. Nothing described here remediates a finding automatically.

How to run a Microsoft 365 security audit without a security team

Frequently asked questions

Related topics

• m365 security audit
• entra id privileged role review
• conditional access coverage
• sharepoint oversharing
• copilot readiness audit