The Microsoft 365 security assessment checklist for MSPs

Security assessments are one of the easiest services for an MSP to sell and one of the hardest to deliver profitably. The economics only work if the assessment is standardised, repeatable and largely automated. Here is the checklist, and how to turn it into a service that scales past a handful of clients.

Why most MSP assessments do not scale

The first assessment goes fine. You know the client, you spend two days in the admin portals, you write a decent report and the client is happy. The tenth one is where it breaks down: every assessment is slightly different, the findings depend on who did the work, the report takes as long to write as the review took to run, and nobody can tell whether client A is genuinely in better shape than client B because they were assessed differently.

Three constraints have to be satisfied for this to be a real service line: consistency across clients and across technicians, speed, so the labour cost does not eat the margin, and a deliverable the client will act on rather than file.

The checklist

Organised by where the risk actually concentrates, not by which portal you happen to be in.

Identity and access — Entra ID

• MFA enforcement: coverage for all users, and specifically for every privileged role. Note exclusion groups — they are where coverage quietly dies.
• Legacy authentication: blocked, and confirmed against sign-in logs before blocking.
• Global Administrator count, and whether privileged access is standing or just-in-time.
• Conditional access policy set: baseline policies present, admin portals protected, no policy in report-only mode that everyone assumes is enforcing.
• Break-glass accounts: exist, excluded appropriately, documented, monitored.
• Guest access and external collaboration settings.
• Self-service: app registration, user consent to third-party applications, guest invitation rights.
• Stale accounts, unused service principals, credentials nearing expiry.

On-premises Active Directory

Skip this and your assessment covers half the estate. For any client with a domain:

• Domain Admins and Enterprise Admins membership — size and justification.
• Delegation, particularly unconstrained delegation.
• Kerberos hygiene, including the age of the krbtgt password and service accounts with SPNs and weak passwords.
• Password and lockout policy, and fine-grained policies for privileged accounts.
• Accounts with passwords set never to expire, reversible encryption, or long inactivity while still enabled.
• Domain and forest trusts — which exist, and whether anyone still needs them.

Azure

• Owner and Contributor assignments at subscription or management group scope.
• Publicly exposed resources: storage accounts, databases, management endpoints.
• Defender for Cloud coverage on subscriptions carrying real workloads.
• Key vault access policies and purge protection.

Collaboration and mail

• Auto-forwarding to external recipients — the single most valuable thing on this list.
• SharePoint and OneDrive external sharing defaults, and any "anyone with the link" surfaces.
• Teams guest access and meeting policy.
• Defender threat policies: safe links, safe attachments, anti-phishing.

Logging and evidence

• Unified audit log enabled — verify, do not assume.
• Sign-in and directory audit log retention, and whether anything is exported for longer-term retention.
• Mailbox auditing.

Turning the checklist into a service

Standardise before you scale

Define one assessment methodology and apply it to every client. The moment two technicians assess differently, your comparisons across the client base become meaningless and your reports stop looking like a product. Anchor the methodology to a recognised framework — CIS benchmarks are the natural fit for Microsoft environments — so findings carry an external reference rather than your technician's opinion.

Allow for per-client variation, deliberately

Clients differ. Some do not use a service at all; some have a control that is genuinely out of scope; others have requirements stricter than the standard. Handle this with a documented per-client baseline rather than ad-hoc judgement calls, so exclusions are visible in the report instead of hidden in someone's head. Custom baselines also stop irrelevant findings from burying the ones that matter.

Make the deliverable the product

The report is what the client pays for. It needs a score they can track over time, findings ranked by severity rather than listed by service, a remediation step for each one, and a framework reference so the recommendation is not just your say-so. White-labelling it with your own branding matters more than it sounds — it is your service, not a tool's output.

Sell the cadence, not the one-off

A single assessment is a transaction. The recurring version is the business: quarterly re-assessment, with the score trend as the proof of value. It also solves the awkward conversation where you deliver findings and never hear whether anything was fixed. When the next report shows the score moved from 54% to 78%, the value of the engagement is self-evident — and so is the case for renewing it.

Watch the read-only boundary

Assessment and remediation are different engagements with different risk profiles. Running an assessment that cannot modify a client tenant is both safer and easier to sell: you are not asking for write access to their production identity system to tell them what is wrong with it.

Realistic economics

The variable that decides whether this line is profitable is technician hours per assessment. Manual review across a dozen portals for a mid-sized tenant is a multi-day job, and multi-day jobs price the service out of reach for the small and mid-market clients most MSPs actually serve. Automating the data collection and report generation is what moves the assessment from a bespoke project to a repeatable deliverable — and lets you offer it to the whole client base rather than the top three accounts.