If you’re preparing for a SOC 2 audit, you’ve probably already figured out that the scope is broad. Security policies, change management, vendor risk, incident response, it’s a lot.
But there’s one area that consistently catches teams off guard: identity.
Not because you don’t have controls in place. Most organisations running Entra ID, Okta, or Active Directory have reasonable access management standards. The problem is evidence. When your auditor asks you to prove that your identity controls actually worked consistently, across every system, over the entire observation period, that’s where things get painful.
A Quick Note on How Auditors Think About Identity
SOC 2’s Security criterion (the “Common Criteria”) is mandatory for every audit. Within that, access control is one of the heaviest areas of scrutiny. Your auditor isn’t just checking that you have an access control policy. They’re testing whether that policy was followed, consistently, throughout the observation period.
They do this by sampling. They may pull a list of joiners, leavers, and role changes during the audit window and ask you to produce the evidence trail for each one. If you can’t, that’s an exception in your report.
The identity evidence they’re looking for generally falls into these areas.
1. User Provisioning Evidence
What the auditor wants to see
Proof that every new user account was requested, approved, and created in that order. When a new employee joins, the auditor expects a clear chain: a formal access request (usually a ticket in ServiceNow, Jira, or similar), a documented approval from a manager or system owner, and then a system record showing the account was created after that approval.
What they may actually do
Pull a sample of new hires from the audit period and ask you to produce the request, approval, and account creation timestamp for each one. If the account was created before the approval was documented, that’s a finding.
Where teams get caught out
- Access is granted informally — someone messages IT on Slack, the account gets created, and there’s no ticket or approval trail.
- The approval exists in one system but the account was created in three different platforms (Entra ID, Okta, a SaaS app), and you can only show the provisioning evidence for one of them.
- HR says the start date was Monday, but the account was created the previous Friday. Small gap, but auditors notice.
What good looks like
A consistent, documented workflow where every access grant has a request, an approval, and a timestamped account creation record across every in-scope system, not just your primary identity provider.
2. Deprovisioning Evidence
What the auditor wants to see
Proof that when someone leaves the organisation, their access was revoked across all systems within your stated SLA (typically 24 hours). This is the single most common source of SOC 2 exceptions related to identity. Auditors will cross-reference your HR termination list with your identity platform records.
What they’ll actually do
Take a sample of terminated employees and check whether their accounts were disabled in every system within your SLA window. If an account was active beyond your policy, that can be an exception.
Where teams get caught out
- The employee was disabled in Entra ID but their Okta account stayed active for two weeks.
- Active Directory was cleaned up, but a direct-provisioned SaaS application was missed entirely.
- The HR system shows a termination date of the 15th, but the account wasn’t disabled until the 22nd because the ticket sat in a queue.
- Contractor accounts are managed separately from employee accounts, and nobody remembered to include them in the offboarding process.
What good looks like
An automated or tightly managed deprovisioning process that covers every in-scope system — not just the primary IdP — with timestamped evidence showing access was revoked within your committed timeframe.
3. Access Reviews
What the auditor wants to see
Evidence that you conduct regular, documented access reviews — typically quarterly — across all critical systems. The auditor wants to see that managers periodically reviewed who had access to what, confirmed that access was still appropriate, and that any inappropriate access was revoked.
What they may actually do
Ask for the records of every access review conducted during the audit period. They’ll check that reviews were completed on schedule, that they covered all in-scope systems, that reviewers actually made decisions (not just rubber-stamped), and that actions were taken on any flagged items.
Where teams get caught out
- Reviews were done for Entra ID but not for Okta or standalone applications.
- The review was completed, but the only evidence is a spreadsheet with no sign-off or timestamp showing when decisions were made.
- Reviews are happening, but they’re inconsistent — quarterly for one system, annually for another, never for a third.
- All access was approved with no removals. Auditors treat this as a red flag that the review wasn’t taken seriously.
- A review was scheduled for Q3 but actually completed in Q4. That gap in the review cycle creates an exception.
What good looks like
Regularly scheduled access reviews covering all in-scope systems, with documented decisions (approve/revoke), reviewer sign-off, timestamps, and evidence that revocations were actually executed. The output should be exportable, timestamped, and tied to specific reviewers — not a spreadsheet someone backfilled the week before the audit.
4. Privileged Access Evidence
What the auditor wants to see
A current list of all privileged accounts (admin roles, elevated permissions) with justification for why each one has that level of access. Privileged access is high-risk, and auditors scrutinise it more closely than standard user access.
What they’ll actually do
Request a complete list of privileged accounts across every in-scope system. They’ll check whether each account maps to a real person (no shared admin accounts), whether access is justified by role, and whether privileged access reviews are conducted regularly.
Where teams get caught out
- There are global admin accounts in Entra ID that nobody can explain.
- Service accounts have been granted privileged roles but aren’t included in access reviews.
- Someone changed roles six months ago but still has their old admin permissions alongside their new ones.
- Privileged access exists in Okta and AD but the review only covered Entra ID.
What good looks like
A maintained inventory of all privileged accounts, mapped to named individuals, with documented justification, regular reviews, and evidence that unnecessary privileges are removed promptly.
5. MFA Enforcement Evidence
What the auditor wants to see
Proof that multi-factor authentication is enforced across all in-scope systems, for all users, with no unexplained exceptions. MFA is a baseline expectation for SOC 2 — auditors aren’t just checking that MFA is available, they want evidence it’s enforced for every user.
What they’ll actually do
Request configuration screenshots or exports from your identity providers showing MFA enforcement policies.
Where teams get caught out
- MFA is only partially enforced across user populations.
- A handful of service accounts or legacy integrations have MFA exceptions that were never documented or approved.
- Conditional access policies have gaps — MFA is required for some apps but not others.
- The evidence is a screenshot from today, but the auditor needs to know it was enforced throughout the observation period, not just at the point in time they asked.
What good looks like
Exportable evidence from each identity provider showing MFA enforcement policies, a list of any exceptions with documented approval and business justification, and logs showing MFA was active across the audit period — not just a current-state snapshot.
6. Role-Based Access Control and Least Privilege
What the auditor wants to see
Evidence that access is assigned based on defined roles and that users only have the minimum access needed for their job function. This one is less about a single document and more about the overall picture — auditors look at whether you have defined roles, whether users are assigned to appropriate roles, and whether access creep is being managed.
Where teams get caught out
- Roles are defined in Entra ID but not in Okta, so there’s no consistent RBAC model across platforms.
- Users accumulate permissions over time as they move between teams, and nobody cleans up the old ones.
- There’s no documentation mapping roles to specific permissions — the “role model” exists in someone’s head but not on paper.
- Contractors or temporary workers are given the same broad access as full-time employees because it was faster to provision.
What good looks like
A documented role model that maps job functions to specific access levels, evidence that users are assigned roles consistently, and regular reviews that catch and remediate access creep.
The Real Challenge: Evidence Across Multiple Platforms
If you’re running a single identity provider, gathering this evidence is manageable. Tedious, but manageable.
If you’re running Entra ID, Okta, and Active Directory — which many enterprises are — the challenge multiplies. Each platform has its own admin console, its own reporting format, and its own gaps. Pulling a complete picture of who has access to what, across every platform, with timestamps and audit trails, is where teams spend weeks of manual work before an audit.
The most common pattern we see is this: organisations have decent controls in their primary identity provider, but the evidence trail breaks down when you look across all three platforms together. The joiner was provisioned in Entra ID and Okta, but AD wasn’t updated until a week later. The access review covered Entra ID roles but didn’t include Okta application assignments. The leaver was disabled in AD but their Okta account is still active.
These aren’t catastrophic failures. They’re the natural consequence of managing three identity platforms independently. But they’re exactly what auditors find — and exactly what creates exceptions in your SOC 2 report.
Where Custodeum Fits
We built Custodeum specifically for organisations managing identities across Entra ID, Okta, and Active Directory.
It gives you a single view of identity operations across all platforms, so when your auditor asks for provisioning evidence, deprovisioning timelines, access review records, privileged account inventories, or MFA enforcement data, you can pull it from one place.
Governance campaigns in Custodeum track reviewer decisions with full audit trails. License and access reports are exportable, timestamped, and formatted for auditor consumption. And because everything is unified, the gaps between platforms — the ones that create most SOC 2 exceptions — become visible before your auditor finds them.
If you’re preparing for a SOC 2 audit, we’d be happy to show you how Custodeum can simplify the evidence side of things. Visit custodeum.com and get in touch with the team.