A Microsoft 365 security baseline should tell a small-business leader what is protected, who maintains it, and how that protection is verified. Having licenses or a collection of enabled settings is not the same as having an operating security process.
Use this checklist to organize a review with your administrator. It is a planning baseline, not tenant-specific configuration instructions, an exhaustive security assessment, or proof of regulatory compliance. Record each check as verified, needs work, not applicable with a reason, or unknown. Unknown is not a pass.
Confirm licensing and recovery before changing policies
Identify your subscriptions, supported devices, administrator roles, existing policies, and recovery paths. Do not assume every control is included in every Microsoft 365 plan.
Microsoft lists Entra ID P1 for Conditional Access and Entra ID P2 for sign-in/user-risk-based policies. Other connected products can have separate requirements. Security defaults provide a different baseline option; do not disable existing protections simply to copy a policy example. Review the Conditional Access licensing and security-defaults guidance for your environment.
Security defaults and custom Conditional Access require a planned transition, not an assumption that both can remain active together. Microsoft calls for replacement protections to be enabled immediately when security defaults are disabled. Plan that change with recovery access and appropriately scoped validation; do not leave production protected only by report-only policies during testing. See moving from security defaults to Conditional Access.
Have a qualified administrator validate emergency access before broad identity changes. Keep it protected, monitored, and usable when the normal administrative path fails; it is not a general-purpose unprotected administrator account. Follow Microsoft's emergency-access guidance.
Priority A: establish ownership and close fundamental gaps
These priorities are an editorial starting point; active incidents and your assessed risks may change the order.
Scroll horizontally to compare all columns.
| Check | Suggested owner | Evidence that answers the question |
|---|---|---|
| Can the business recover administrative control? | IT lead and business account owner | Tested authorized recovery process, protected emergency access, current recovery contacts |
| Are human users protected by the intended authentication policy? | Identity administrator | Policy scope, registration status, representative sign-in results, documented exceptions |
| Are privileged roles limited and reviewed? | IT lead | Role inventory, named administrators, business justification, separation of routine/admin use |
| Does a leaver lose the intended access promptly? | HR authorizer and IT operator | A completed offboarding test covering sessions, memberships, apps, and data handoff |
| Are shared-mailbox accounts blocked from direct sign-in? | Exchange administrator | Account state and delegate review; delegates use their own protected identities |
| Are important alerts reaching someone who will act? | Security operations owner | Tested routing, staffed-hours statement, escalation and containment authority |
Shared mailboxes are a specific case: Microsoft says to keep direct sign-in blocked for the mailbox account. Protect and review the delegated users instead of sharing a mailbox password. See Microsoft's shared-mailbox guidance.
Service principals, managed identities, and other workload identities need their own permission, credential, and lifecycle review. Do not treat them as human users who can simply complete an MFA prompt.
Make the identity checks specific
- Verify MFA enforcement, not only registration. Check ordinary and privileged human accounts, policy coverage, and representative sign-in results. Prefer phishing-resistant methods where supported and appropriate, particularly for administrators; review dependencies and emergency access separately. Microsoft's authentication-strength guidance distinguishes the available method combinations.
- Review legacy authentication dependencies. Identify applications or devices using older sign-in paths, assign remediation owners, and validate the chosen blocking policy. Do not create a permanent broad exception simply to preserve an undocumented dependency.
- Review application consent and granted permissions. Inventory connected applications, owners, privileged grants, and the process for approving new access. Restrict consent according to business needs and review existing grants; changing the policy for future consent is not a review of access already granted. See Microsoft's user-consent controls.
- Check investigation evidence. Confirm that required sign-in and audit events are available to authorized responders for the necessary retention period, within licensed capabilities. Test retrieval of a representative event and name the person who investigates it.
Priority B: validate endpoint, email, and information controls
Scroll horizontally to compare all columns.
| Check | Suggested owner | Evidence to retain |
|---|---|---|
| Are supported devices inventoried and managed as intended? | Endpoint administrator | Inventory-to-management reconciliation, missing/stale device list, ownership classification |
| Are updates, encryption, and endpoint protection working? | Endpoint/security operators | Coverage and failure reports, recovery-key access test, approved exceptions |
| Is email protection appropriate to the licensed service and risk? | Messaging/security owner | Reviewed settings, quarantine/reporting process, representative tests and follow-up owner |
| Is external sharing intentional? | SharePoint/Teams and business data owners | Reviewed site ownership, guest access, sharing links, and exceptions |
| Do protection and retention rules match business requirements? | Data owner with IT and relevant advisers | Approved classification/retention decisions and tested feature scope |
| Can critical information be recovered? | Recovery owner and application/data owner | Workload coverage, recovery requirements, restore-test result and unresolved gaps |
Verify feature and platform entitlements before relying on device-risk integration, advanced email protection, DLP, automatic labeling, privileged identity features, or advanced auditing. A product name alone does not establish the coverage available in your tenant. Retention settings and backup/recovery arrangements answer different questions; validate the recovery scenarios the business actually needs.
For email, explicitly check authorized sending services and SPF, DKIM, and DMARC configuration—not just the spam-filter dashboard. Review alignment and reporting before tightening enforcement so that legitimate third-party senders are not accidentally blocked. Include external forwarding and suspicious-message reporting in the operational review. Microsoft's email-authentication overview explains how the domain-authentication controls work together; they do not replace account protection or user reporting.
Roll out changes without losing control
- Capture existing settings, dependencies, approved scope, and recovery instructions.
- Choose a pilot covering relevant devices, applications, locations, and user roles.
- Test intended allowed and blocked access, including administrators and emergency access.
- Evaluate suitable Conditional Access changes in report-only mode before enforcement. This is a Conditional Access feature, not a universal safe mode for all Microsoft settings. Microsoft also documents platform-specific certificate prompts, so plan for potential user impact. See report-only behavior.
- Resolve unexplained results and agree exception expiry, support instructions, and a reversal path.
- Expand only after evidence is reviewed, then verify the enforced result.
Do not turn on every restrictive control at once. If an emergency requires rapid containment, use the authorized incident process rather than this planned-change sequence.
Keep a baseline evidence register
For each check, retain the control name, scope, operator, business approver, review date, evidence location, exception owner, and next action. Keep sensitive exports in approved storage, not attached to public requests.
For example, “MFA enabled” is weak evidence. “All in-scope human accounts mapped to the approved policy; sample sign-ins checked; two exceptions assigned owners and expiry dates” is an actionable operating record. This example describes evidence quality, not an attestation about your tenant.
Common questions
Do we need the highest license tier before doing anything?
No. Inventory, ownership, access cleanup, and configuration review can identify useful improvements immediately. Which technical controls you can enforce depends on the actual subscriptions and architecture. Validate that before purchasing or changing policies.
Will completing this checklist satisfy an insurer or auditor?
Not by itself. Their questions, required evidence, and your obligations may differ. Use the checklist to organize work and have the relevant parties evaluate the specific requirements.
Start with the gaps you can describe
Request a Free Initial Assessment to discuss your Microsoft environment and priorities. The initial request is not a comprehensive tenant audit. For ongoing ownership, explore Microsoft 365 governance.