Last Updated: October 23, 2026
Quick Summary
A security audit checklist is a structured, repeatable set of controls you validate against your tenant, with evidence recorded for each one. Run it in four phases: scope the tenant and confirm licensing, collect evidence and baseline Secure Score, validate each control, then report findings with an owner and due date.
- Report-only Conditional Access policies look configured but enforce nothing, making them the quietest gap in most tenants.
- Validate mailbox auditing with PowerShell because the portal can hide shared and inactive mailboxes where defaults drift.
- Record unlicensable controls as Not Licensed with the tier that would unlock them to turn an IT failure into a budget decision.
- Score findings on likelihood, impact, and exploitability using a 1-to-3 scale per axis, then multiply for a total.
- Set due dates of 30 days for high scores, 90 for medium, and 180 for low, with a re-validation date recorded at the same time.
Table of Contents
- Why a Microsoft 365 Security Audit Checklist Matters in 2026
- How to Run a Microsoft 365 Security Assessment
- Microsoft 365 Identity and Access Management Audit
- Microsoft 365 Email Security Audit
- Data Protection, Endpoint, and Logging Controls to Validate
- Building a Microsoft 365 Security Audit Report Template
- Prioritizing Remediation After the Audit
- Conclusion
- Frequently Asked Questions
Why a Microsoft 365 Security Audit Checklist Matters in 2026
A security audit checklist is a structured, repeatable set of controls you validate against your tenant, with evidence recorded for each one.
Credential theft, ransomware staging, and business email compromise target the identity layer first, where Microsoft 365 concentrates the most value.
Below is a practical audit workflow, control-by-control validation, and remediation sequencing, so your next review produces evidence instead of opinions.
How to Run a Microsoft 365 Security Assessment
A Microsoft 365 security assessment is a scoped, evidence-based review of tenant configuration against a defined control set. Run it in four phases: scope, collect, validate, report.
The sequence matters more than the tooling.
Step 1: Scope the Tenant and Confirm Licensing
- List every subscribed workload: Exchange Online, SharePoint Online, Teams, OneDrive, Intune, Defender, Purview.
- Record license tiers per user group. Conditional Access, Defender for Office 365, and Purview sensitivity labels depend on specific licensing, and a control you cannot license is a finding about budget, not configuration.
- Identify break-glass and service accounts, guest accounts, and any federated identity providers.
Document the scope in one page. It becomes the cover sheet of your report.
Step 2: Collect Evidence and Baseline Secure Score
Microsoft Secure Score gives you a starting number and a prioritized improvement list, but treat it as a compass, not a verdict: it rewards configuration that may not match your risk profile and cannot see your business context.
On day one, export a date-stamped baseline of Secure Score, your Conditional Access policy list, MFA registration status, and admin role assignments. That baseline makes remediation measurable later.
Then validate rather than assume. For each control, ask: is it configured, is it enforced for the right population, and can I prove both?
Microsoft 365 Identity and Access Management Audit
Identity and access management is where the audit earns its keep: nearly every serious Microsoft 365 incident begins with a credential that should not have worked, or an account with more access than its job required.
MFA Enforcement and Conditional Access Validation
Multifactor authentication is table stakes; enforcement coverage is the actual finding.
Pull the authentication methods report and check registration by group, not tenant-wide. A tenant-wide number hides the population that matters: admins, executives, and anyone with mailbox delegation rights.
Then validate Conditional Access policy by policy:
| Check | What to Verify | Evidence to Capture |
|---|---|---|
| Policy state | Enabled, not report-only | Policy list export with state column |
| Coverage | All users and all cloud apps, with named exclusions | Policy JSON or screenshot of assignments |
| MFA requirement | Enforced for admin roles separately | Sign-in log sample of a blocked legacy attempt |
| Legacy auth | Blocked at the tenant level | Sign-in log filter for legacy protocols |
| Break-glass | Excluded and documented | Written exception record with owner |
Report-only policies are the quietest gap in most tenants. They look configured and enforce nothing.
Privileged Accounts and Least Privilege Checks
Administrator accounts deserve separate scrutiny.
- Confirm every Global Administrator has a justified business need, and that the count stays small.
- Check for standing access where just-in-time elevation through Privileged Identity Management would do.
- Review role assignments for scope: a User Administrator scoped to the tenant is not the same as one scoped to a single group.
Least privilege is a recurring review, not a one-time configuration; record the date of the last one.
Microsoft 365 Email Security Audit
Email remains the most-targeted workload in the tenant, and the Microsoft 365 email security audit should test both inbound filtering and the trail proving what happened to a message.
Exchange Online and Mailbox Auditing Controls
Mailbox auditing is the control teams forget until they need it: if it is off, you cannot reconstruct who read, forwarded, or deleted a message during an investigation. Turn it on by default, set a retention period that matches your legal and operational needs, and verify it is logging.
Then validate the filtering stack:
- Anti-phishing and anti-spoofing policies applied to all recipients, not a subset.
- Safe Links and Safe Attachments active for internal as well as external mail.
- Transport rules reviewed, with no stale rules silently redirecting or allowing mail.
For each, capture the policy configuration and one test message result. A policy you have not tested is a policy you have not validated.
Data Protection, Endpoint, and Logging Controls to Validate
Data protection, endpoint security, and logging are where licensing dependencies bite hardest, so validate capability before configuration. The table below gives each control a validation method, a pass criterion, and the license tier that unlocks it, so findings can be classified as configuration gaps or budget gaps.
| Control | Validation Method | Pass Criterion | License Dependency |
|---|---|---|---|
| Sensitivity labels published | Purview compliance portal > Information protection > Label policies; confirm at least one policy targets all users | Labels visible in Office apps for a test user in each group | Microsoft 365 E3/E5 or Purview Information Protection |
| Auto-labeling running | Purview > Information protection > Auto-labeling; check policy status and simulation results | Policy in enforce mode, not simulation, with a recent run timestamp | E5 or Purview Information Protection add-on |
| DLP in enforce mode | Purview > Data loss prevention > Policies; open each policy and read the mode | Enforce, not test, and scoped to Exchange, SharePoint, OneDrive, and Teams | E3 for base DLP; E5 for advanced classifiers |
| Device compliance | Intune admin center > Devices > Compliance policies; check assignment and a sample device status | All targeted devices report Compliant or an approved exception | Intune Plan 1 (included in E3) |
| Conditional Access device requirement | Entra admin center > Protection > Conditional Access; inspect grant controls | At least one policy requires compliant or hybrid-joined device for access to Microsoft 365 | Entra ID P1 |
| Unified audit log on | Purview > Audit > search for a known event from the last 24 hours | Results returned for a test query | E3 (E5 adds longer retention and advanced hunting) |
| Mailbox auditing on | Exchange admin center > Recipients > Mailboxes > Manage mailbox auditing, or PowerShell `Get-Mailbox | Select AuditEnabled` | AuditEnabled is True for all mailboxes, including shared and inactive |
| Alert review cadence | Defender portal > Incidents and alerts; confirm a named reviewer and a documented cadence | At least one review logged in the last 30 days | Defender for Office 365 P1/P2 depending on workload |
Validating Data Protection
Sensitivity labels are only a control if published, applied, and enforced. Confirm the label policy targets all users, then open a document as a test user in each group and verify the label appears. Auto-labeling policies in simulation mode protect nothing; check policy status and the latest run timestamp. For DLP, read the mode on every policy: test mode with a large match count is evidence of a gap, not a control.
Validating Endpoint and Device Controls
Device compliance is a chain: enrollment, compliance policy assignment, and Conditional Access enforcement. Validate each link. In Intune, confirm devices are enrolled and a compliance policy is assigned to every supported platform. In Entra, confirm at least one Conditional Access policy requires a compliant or hybrid-joined device for Microsoft 365 access. A compliance policy with no Conditional Access requirement is documentation, not enforcement.
Validating Logging and Monitoring
Logging makes every other control provable. Run a test audit search in Purview for an event you can trigger, such as a file download, and confirm results return within the expected window. Check mailbox auditing with PowerShell rather than the portal, which can hide shared and inactive mailboxes where defaults drift. Then confirm a named person reviews alerts on a documented cadence; an audit trail with no reader is storage, not monitoring.
Building a Microsoft 365 Security Audit Report Template
A Microsoft 365 security audit report template turns findings into decisions. Keep it to five columns.
| Field | Purpose |
|---|---|
| Control | The specific setting or policy validated |
| Status | Pass, Fail, Partial, or Not Licensed |
| Evidence | Link or reference to the captured proof |
| Risk | Business impact if left unresolved |
| Owner and Due Date | Named accountability with a deadline |
The "Not Licensed" status is the one most templates omit, and the one that gets budget approved: a control you cannot implement without a license upgrade is a business case, not an IT failure.
Write findings in plain language for the leadership summary. "Legacy authentication is not blocked, allowing password-only sign-in attempts" lands better than a control ID.
Prioritizing Remediation After the Audit
Remediation order should follow exploitability and blast radius, not report order. Score each finding on three axes, then convert the score into a time-bound plan with owners and re-validation dates.
Scoring Findings
Score every finding on likelihood, impact, and exploitability using a simple 1-to-3 scale per axis, then multiply for a total. A finding that scores high on all three goes first regardless of which workload it belongs to.
| Axis | 1 (Low) | 2 (Medium) | 3 (High) |
|---|---|---|---|
| Likelihood | Requires insider access or unusual conditions | Exploitable with valid credentials | Exploitable without credentials or by commodity phishing |
| Impact | Limited to a single low-sensitivity workload | Reaches business data or a department | Reaches executive mailboxes, finance, or tenant administration |
| Exploitability | Complex, multi-step, or noisy | Known technique with public tooling | Trivial and commonly observed in the wild |
A legacy authentication finding typically scores 3 x 3 x 3: exploitable with a password alone, reaching any mailbox, and a known commodity attack. A stale transport rule might score 1 x 2 x 1.
Sequencing the Work
Fix in this sequence, adjusted by score:
- Identity exposure first. Block legacy authentication, enforce MFA for admins, reduce standing Global Administrator assignments, and remove report-only Conditional Access policies that should be enforcing.
- Detection second. Turn on audit logging and mailbox auditing before you start changing other controls, so you can see what breaks and reconstruct events during the change window.
- Data protection third. Enforce DLP and label policies once the identity layer is stable, because enforcement without identity controls can block legitimate work without stopping an attacker.
- Hardening last. Tighten Conditional Access conditions, device compliance, and transport rules incrementally, with a pilot group first.
Turning Scores into a Plan
Convert each score into a due date: high within 30 days, medium within 90, low within 180 or the next review cycle. Assign a named owner per finding, not per section.
Record the re-validation date at the same time you record the due date. A finding is not closed when the setting changes; it is closed when the evidence shows the setting is enforced for the right population and the re-check is scheduled.
Conclusion
The hard part of a Microsoft 365 security audit is rarely knowing which controls matter.
That is where we come in. MTRC Enterprises runs hands-on Microsoft 365 assessments alongside your team, with knowledge transfer built into every engagement so your staff can own the controls after we leave.
If your last audit produced a report nobody acted on, schedule a free consultation with MTRC Enterprises and leave with a scoped, prioritized remediation plan your team can actually execute.
Frequently Asked Questions
What should a Microsoft 365 security audit include?
A complete audit covers identity and access management, MFA enforcement, Conditional Access policies, privileged administrator accounts, Exchange Online and email protection, data protection with sensitivity labels and DLP, endpoint and device management, and audit logging. It should also record evidence for each control so findings are verifiable. A security audit checklist keeps the scope consistent between reviews and makes it easier to show progress to leadership.
How do I run a security audit in Microsoft 365?
Start by scoping the tenant and confirming which licenses are active, because features like Conditional Access and advanced auditing depend on them. Then collect evidence: export Secure Score, review sign-in and audit logs, and check configuration against your security audit checklist. Document each finding with a screenshot or export, assign an owner, and set a remediation date. Repeat the process on a fixed schedule so results stay comparable.
How often should you audit Microsoft 365 security?
Most mid-market organizations should run a full Microsoft 365 security assessment at least twice a year, with lighter configuration reviews quarterly. High-change areas such as privileged accounts, guest access, and Conditional Access policies benefit from monthly checks. Trigger an extra audit after major changes like a migration, a new Teams rollout, or a staffing change in IT. Frequent small reviews catch drift before it becomes a security gap.
What should be included in a Microsoft 365 security audit report template?
A useful report template includes the audit scope and date, the license tier reviewed, a control-by-control pass or fail status, evidence references, risk rating for each gap, the assigned owner, and a remediation deadline. Add an executive summary that highlights the top five risks in plain language. Keeping the template fixed lets you compare audits over time and show measurable improvement in security posture.
How do you audit Microsoft 365 user accounts and permissions?
Review all user accounts for stale or inactive sign-ins, confirm every account has MFA registered, and check that guest access is limited to people who need it. List members of privileged roles such as Global Administrator and reduce them to the smallest group possible. Compare assigned licenses against actual usage, then document exceptions. This identity and access management review is usually where the biggest security gaps appear.
How can you check Microsoft 365 email security settings?
In the Microsoft Defender portal, review anti-phishing, anti-spam, and anti-malware policies, confirm Safe Links and Safe Attachments are active, and check that DMARC, DKIM, and SPF records are published correctly. Turn on mailbox auditing for all users and verify audit logs are retained. Also review forwarding rules and inbox rules that could indicate business email compromise. Record each setting's current state in your audit checklist.
