Microsoft 365 security audit for SOC 2 compliance

SOC 2 is the report your enterprise customers ask for before they sign. Most of the effort goes into policy and process, but the part that trips teams up at evidence time is technical: proving how access to your systems is actually controlled. If your company runs on Microsoft 365, that proof lives in Entra ID, Active Directory and Azure.

What SOC 2 actually is

SOC 2 is not a certification. It is an attestation report issued by a licensed CPA firm, based on the AICPA's Trust Services Criteria. You choose which criteria are in scope; the Security criterion — often called the Common Criteria — is mandatory, and Availability, Confidentiality, Processing Integrity and Privacy are optional additions.

There are two flavours. A Type I report describes your controls at a single point in time. A Type II report tests whether those controls operated effectively across a period, commonly three to twelve months. Type II is what most enterprise buyers actually want, and it is the harder one, because you have to show the control held up over time — not just on the day of the screenshot.

The criteria where identity does the heavy lifting

CC6 — Logical and Physical Access Controls

This is the family where a Microsoft-heavy organisation spends most of its evidence effort. In practice, auditors want to see how you handle:

• Authentication strength — is multi-factor authentication actually enforced, and for whom? A policy that says "MFA required" while conditional access has exclusions is a finding waiting to happen.
• Provisioning and authorisation — how users get access, and on what basis.
• Deprovisioning — the single most commonly failed control. Stale, disabled-but-not-removed accounts and lingering service principals are exactly what a Type II sample will surface.
• Privileged access — how many people hold administrative roles, whether that access is standing or just-in-time, and whether it is reviewed.
• Restricting access paths — legacy authentication protocols that bypass modern controls are a direct contradiction of a stated access policy.

CC7 — System Operations

Monitoring and detection. For a Microsoft environment, the practical questions are whether sign-in and audit logs are retained long enough to investigate an incident, whether they are exported somewhere durable, and whether anything is watching them.

Where teams actually lose time

The failure pattern is consistent: the policies exist, the intentions are good, and then the auditor asks for evidence covering a nine-month window. Someone starts taking screenshots of admin portals. Each portal has a different export format. Nobody can produce a consistent view of "who had Global Administrator in March", and the exclusions buried in a conditional access policy come out three weeks before the report deadline.

The underlying issue is that Microsoft's configuration lives across a dozen separate planes, each with its own console. Evidence gathering becomes a manual archaeology project rather than a measurement.

What an automated audit contributes

An audit tool does not make you SOC 2 compliant — no tool does. What it produces is the technical evidence behind a specific subset of criteria, in a form an auditor can read:

Each finding carries its framework reference and a remediation step, which matters because an auditor's next question is always "and what did you do about it?"

Do not forget on-premises Active Directory

If your production systems authenticate against an on-premises domain, or if privileged accounts are synced from AD into the cloud, then AD is in scope for your access controls whether or not your cloud dashboard mentions it. This is a genuine gap in most tooling: cloud-only assessments report a comfortable picture while the domain that actually holds the keys goes unexamined.

Auditing both together also closes the seam where hybrid environments tend to fail — synced admin accounts that inherit privilege on both sides, or MFA enforced in the cloud but not on the legacy path.

A practical sequence

1. Run a baseline audit across Entra ID, Active Directory and Azure before you start the observation window. You want to find the gaps before the auditor samples them.
2. Remediate the fundamentals first — MFA coverage, legacy authentication, privileged role count, stale accounts. These map directly to CC6 and they are the ones that fail visibly.
3. Set a cadence. Monthly or quarterly audits across the observation period give you dated, consistent evidence of operating effectiveness — which is the whole point of Type II.
4. Keep the reports. A folder of dated compliance reports showing a rising score is a far better artefact than a pile of screenshots.
5. Map findings to criteria with your auditor early, so everyone agrees what the evidence demonstrates.

A note on scope

SOC 2 covers a great deal that no technical audit touches: vendor management, change management, HR onboarding, incident response procedures, physical security. A configuration audit addresses the access control and monitoring evidence, which is a meaningful slice of the Security criterion — not the whole report.