Okta + SOC 2: What Auditors Actually Test in Your Config
Quick answer. Yes, Okta publishes its own SOC 2 Type II report, plus ISO 27001 and FedRAMP Authorized status. Request it at trust.okta.com through your Okta account team (NDA required). This guide covers something different: what your auditors will actually test in your Okta configuration, and the CC6 evidence they accept.
Okta is in nearly every SOC 2 audit scope.
It controls who gets into your systems, how they authenticate, and what happens when someone leaves. That makes it one of the highest-leverage controls you can configure well, and one of the easiest places to get a finding if you have not.
This guide covers what auditors actually test, mapped to the CC6 criteria, and what evidence you need to collect.
Why Okta Is Central to CC6
SOC 2 CC6 covers logical and physical access controls. For most SaaS companies, logical access is Okta. The trust service criteria auditors care about most are:
- CC6.1: Logical access security software, infrastructure, and architectures
- CC6.2: Prior to issuing system credentials, new users are registered and authorized
- CC6.3: Access is removed or modified when users change roles or leave
Okta touches all three. A well-configured Okta tenant generates evidence for each of them automatically. A poorly configured one generates findings.
MFA Enforcement
The first thing an auditor checks in Okta is whether MFA is actually enforced, not just available, but required.
Common gap
- MFA is enabled but not required for all applications
- Admins have exceptions or bypass policies
- New users can skip MFA enrollment during a grace period
Tip
- Set a global sign-on policy that requires MFA for every app
- Require MFA enrollment on first login with no bypass window
- Apply a stricter policy to admin accounts (Okta admin console access)
Evidence to collect: a screenshot of your authentication policy showing MFA required, and your admin account policy showing the same.
Session Timeout Policies
Auditors check that inactive sessions do not stay open indefinitely. SOC 2 does not specify a timeout value, but most auditors expect something reasonable, 8 to 24 hours for standard users, shorter for privileged accounts.
In Okta, this lives under Security > Authentication Policies and your Session Lifetime settings. Set max session lifetime and idle session timeout explicitly. Leaving these at defaults (often very long) is a common finding.
Evidence: screenshot of your session policy settings.
Provisioning and Deprovisioning
Auditors look closely at whether access is actually removed when people leave. This is CC6.3 and it comes up in almost every audit.
If you use Okta as your SSO hub, confirm:
- Your HR system or directory triggers deactivation in Okta when someone is offboarded
- Deactivation happens within a defined SLA (most teams target same-day or within 24 hours)
- Okta is connected to downstream apps via SCIM so deprovisioning propagates automatically
If deprovisioning is manual, document the process and keep a log of each offboarding event. Auditors will sample terminated employees and check their Okta status and app access.
Evidence: your offboarding procedure, a sample of termination events showing prompt deactivation, and Okta provisioning settings showing SCIM where applicable.
Privileged Access and Admin Accounts
Admin accounts in Okta are a high-risk area. Auditors verify:
- Admin roles are limited to people who actually need them
- Super admin accounts are minimal and use stronger authentication
- Admin access is reviewed periodically
Best practice: use a dedicated admin account separate from your daily user account, require hardware-key MFA for it, and document who holds each admin role.
Evidence: Okta admin role assignment export, showing named individuals and roles. Include a sign-off showing this was reviewed.
Access Reviews
CC6.2 and CC6.3 require periodic reviews of who has access to what. Okta makes this tractable by letting you export a full user roster with group memberships, application assignments, and last login timestamps.
A quarterly access review process looks like:
- Export user list from Okta Admin Console
- Review for inactive accounts (no login in 90+ days), role mismatches, and anyone who changed roles
- Revoke or adjust as needed
- Document the review with a date and sign-off
Auditors will ask for evidence of at least one completed review during the audit period. The export plus a sign-off email or ticket is usually enough.
What Evidence to Have Ready
| Control Area | Evidence |
|---|---|
| MFA enforcement | Screenshot of authentication policy |
| Session timeout | Screenshot of session lifetime settings |
| Provisioning | SCIM config or documented manual process |
| Deprovisioning | Sample termination log, Okta deactivation timestamps |
| Admin roles | Admin role assignment export + review sign-off |
| Access reviews | Quarterly user roster export + sign-off |
| Okta's own compliance | Okta SOC 2 Type II report |
Okta's Subservice Report
Because Okta processes data on your behalf, it is a subservice organization in your audit. Your auditor will ask for Okta's SOC 2 Type II report to cover the controls Okta manages (physical security, availability, their own access controls).
Request the report from Okta Trust or your account team. Review it for any exceptions before sharing with your auditor, you should be able to explain any noted issues.
Common Findings
Common gap
The gaps that show up most often in Okta-related SOC 2 findings:
- MFA not enforced for all users or all applications
- Long or unlimited session timeouts
- Terminated employees with active accounts (even a few days late triggers a finding)
- Admin roles not reviewed or not documented
- No SCIM provisioning, with manual deprovisioning that lacks a log
Getting Audit-Ready
Okta is one of the easier parts of a SOC 2 audit to get right because the evidence is mostly already there. The work is configuration (enforce MFA, set timeouts, wire up SCIM) and process (run quarterly access reviews, log deprovisioning).
Lock those down, collect the screenshots and exports, and Okta becomes a strength in your audit rather than a source of findings.
Getting Okta audit-ready means mapping your identity and access configuration to your SOC 2 controls and keeping that evidence current as people join and leave. If you would rather a fractional CISO owned that than track it yourself, book a call.
Related reading
Want a security leader to run this?
Xorabyte is a fractional CISO for startups who can review your cloud for the gaps found first, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.