Microsoft 365 security assessment

Common findings (examples)

• Privileged roles held by everyday user accounts, or standing admin without approval.
• External sharing that lets anonymous users reach sensitive libraries.
• Legacy authentication still accepted for mail.
• Third-party apps with organisation-wide mail or files permission granted years ago.
• Audit logging too short to investigate a real incident.

What we need from you

• Tenant domain and a named contact.
• A read-only administrative role, created by you.
• Rough user count and which workloads matter most (mail, files, chat, devices).
• Test accounts if you want a controlled simulation.

Typical timeline

Duration depends on tenant size, how many workloads are in scope and whether a controlled simulation is included. A focused identity and sharing review is often a short engagement; a full tenant with devices, data protection and simulation takes longer. Dates are agreed after the scope call.

Standards and method

The review follows tenant security practices recommended by Microsoft for identity, email, sharing and devices, and the assessment approach in NIST SP 800-115. We describe controls by function — identity, email filtering, device compliance, audit logging — rather than by product marketing names, so the report stays clear whoever owns each console. Licence tier is not a prerequisite; we test what you have and note what you do not.

Scope options

• Identity and access only. Sign-in policies, privileged roles, guests and legacy authentication.
• Identity plus collaboration. Adds email, sharing, meetings and chat external access.
• Full tenant. Identity, collaboration, devices, data protection, apps and monitoring.
• With controlled simulation. Test accounts you create; we check whether misuse is detected.
• Combined with Azure. Book with the Azure security assessment or the Microsoft Cloud Readiness Assessment when subscriptions and the tenant should be reviewed together.

What stays out of scope by default

• Sending phishing to real staff (see social engineering assessment).
• Changing tenant settings (review is read-only).
• Personal Microsoft accounts outside your tenant.
• Third-party SaaS that only uses Microsoft sign-in, unless you add those apps to scope.

Working with shared responsibility

Microsoft runs the platform; you configure the tenant. The report stays on the settings and paths you control — identity policies, sharing, apps, devices and monitoring — and is explicit when a risk sits on a control you cannot turn on with your current licences.

Findings are written so identity owners, messaging owners and device owners can each take a ticket without waiting for a single “tenant admin” to decode the whole report. Where a fix needs a licence you do not hold, we say so instead of pretending the toggle exists.

Evidence and confidentiality

Screenshots and export excerpts stay on encrypted storage and are handled under the engagement agreement. We avoid copying real mailbox content into the report; when a proof needs a message or file, we use a test account or a redacted sample you approve.

Scope and rules

• Scope call. Tenant, services in use, licence constraints and any regions or business units out of scope.
• Read-only access. You grant a least-privilege review role. We confirm it before testing starts.
• Configuration review. Identity, email, sharing, devices, data protection, apps and monitoring.
• Attack-path analysis. Realistic paths such as phishing into a mailbox, consent abuse, token theft and privileged role misuse.
• Optional controlled simulation. From test accounts you create, we check whether misuse is detected — only if you ask for it.
• Report and retest. Findings with evidence, a walkthrough and a retest of fixes ready within 6 months of the original test (up to 10 issues).