Our Microsoft 365 tenant audit methodology

Our principles

A tenant audit must never become a risk in itself. Four principles frame every engagement:

• Read-only. We use a dedicated account with the Global Reader role and read-only Microsoft Graph permissions. Nothing is changed during the audit.
• Explicit, time-bound consent. The audit account is created by the client for the duration of the engagement, then disabled.
• Minimal data. We collect configuration, not the content of emails or files. Exports stay encrypted and are destroyed at the end of the engagement.
• Reproducible evidence. Every finding comes with the command or screen that demonstrates it, so the IT team can verify it themselves.

What we cover

We group checks into six areas, inspired by the CIS Microsoft 365 Foundations Benchmark and Microsoft’s own recommendations:

• Identity and access: MFA, Conditional Access, legacy authentication, administrators, guest accounts.
• Email and domain: SPF, DKIM, DMARC, forwarding rules, anti-phishing protection.
• Logging: unified audit log, mailbox auditing, sign-in log retention.
• Collaboration: SharePoint and OneDrive external sharing, guest access in Teams.
• Applications: user consent, third-party apps and their permissions.
• Azure (if present): Owner roles, exposed resources, Defender for Cloud.

The next articles in this series cover the first three areas in detail, with commands you can run yourself.

Read-only data collection

Most checks rely on the official Microsoft Graph PowerShell module, complemented by Exchange Online PowerShell and DNS queries. The connection only requests read permissions:

# Official module : Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -NoWelcome -Scopes "Directory.Read.All","Policy.Read.All","AuditLog.Read.All","Reports.Read.All","SecurityEvents.Read.All"

# Confirm the account, the tenant and the granted permissions (read-only)
Get-MgContext | Select-Object Account, TenantId, Scopes

First, we record Microsoft’s Secure Score. It is not a goal in itself, but it is a useful baseline to measure progress after remediation:

Get-MgSecuritySecureScore -Top 1 |
  Select-Object CreatedDateTime, CurrentScore, MaxScore

Prioritizing findings

A long, unordered list of findings helps no one. Each finding gets a level based on two questions: how exploitable is it? and what would the impact be?

• Critical: easy to exploit and high impact. Example: a global administrator without MFA.
• High: exploitable with some effort, or significant impact. Example: legacy authentication still allowed.
• Medium: weakens defences or investigation capability. Example: DMARC set to p=none.
• Low: good practice or hygiene. Example: guest accounts inactive for a long time.

We also take the client’s context into account: a ten-person business and a financial institution do not have the same priorities or obligations, including under Quebec’s Law 25.

Deliverables

• An executive summary: the main risks in plain language, in one or two pages.
• A technical report: each finding with its evidence, level, recommended fix and estimated effort.
• A 30/60/90-day action plan: quick wins first, then the more structural work.
• A debrief session with the IT team to answer questions and confirm priorities.