Integrations / Identity & access
Screenata + OktaHow do you prove SOC 2, ISO 27001, and HIPAA access controls in Okta?
Quick answer
Okta is where logical access control is proved. It is the first thing an auditor samples under SOC 2 CC6.1, and it is where quarterly access reviews get their source of truth. An access control policy existing is not the control. The control is the enforced setting in Okta plus the record that it operated for every user across the audit period. Screenata runs 25 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.
Screenata connects to Okta read-only and runs 25 native checks against your org: MFA enforcement, password policy, session controls, and user lifecycle state. Each finding becomes a signed, timestamped evidence artifact mapped to SOC 2, HIPAA, and ISO 27001 controls, and the same data feeds quarterly access reviews, so the identity evidence auditors ask for first is collected continuously.
25 native checks · read-only · signed evidence
What it proves
Okta evidence, mapped to controls.
Whether MFA policies cover your users and how enrollment is enforced across the org.
Proof that workforce access requires strong authentication, the first thing an auditor samples.
Password length, complexity, and reuse settings in force on the org.
Configuration snapshot showing the policy in force on the scan date.
Session lifetime and idle timeout settings across sign-on policies.
Proof that unattended sessions expire, which HIPAA names explicitly as automatic logoff.
Active, suspended, and deprovisioned user state across the org, reconciled against your HR roster.
The joiner-mover-leaver record that quarterly access reviews and offboarding evidence are built from.
Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.
Compliance checks
What Screenata checks on Okta, and why each matters.
MFA Enrollment Required By Policy
If no active enrollment policy rule actually requires a second factor, users can sign in with a password alone. An auditor checks that at least one enabled policy forces MFA enrollment rather than leaving it optional.
MFA Factors Configured
A policy that requires MFA is only as strong as the factors it allows, so weak or absent factors leave accounts exposed. Auditors confirm that possession-based factors such as Okta Verify, WebAuthn, or a hardware token are enabled for enrollment.
Password Policy Strength
Short or simple passwords are the first thing an attacker guesses or sprays. An auditor verifies the active policy enforces a minimum length with complexity and blocks passwords that contain the username.
Account Lockout Policy
Without a lockout threshold, an attacker can try passwords indefinitely. Auditors check that the policy locks an account after a bounded number of failed attempts.
Password Rotation Window Enforced
A password that never expires stays valid long after it may have leaked. An auditor confirms the policy sets a maximum age so credentials are rotated on a defined schedule.
Session Lifetime Configured
Sessions that never end let a single successful sign-in grant access indefinitely. An auditor verifies sign-on rules cap the maximum session lifetime.
Session Idle Timeout Enforced
An unattended workstation with a live session hands full portal access to anyone nearby, which is why HIPAA names automatic logoff explicitly. Auditors confirm idle sessions expire within a set window and that persistent cookies do not defeat it.
Admin Roles Limited
Every extra super admin widens the blast radius of a compromised account. An auditor checks that the number of accounts holding super admin stays within a defined least-privilege threshold.
Privileged Administrators Have MFA Enrollment
Admin accounts are the highest-value target, so an admin without an enrolled factor is a direct path to tenant takeover. Auditors verify every user holding an administrator role has at least one active MFA factor.
Inactive Users Deprovisioned
Dormant but enabled accounts are a standing entry point for a departed employee or an attacker. An auditor confirms inactive accounts are suspended or removed rather than left active.
API Token Age
A long-lived API token that is never rotated stays usable long after it may have leaked. An auditor checks that org tokens are within a defined maximum age.
Classic Sign-On Policy Requires a Second Factor
A sign-on policy that permits a single factor lets a stolen password reach the portal. Auditors confirm the classic sign-on policy requires a second factor to sign in.
App Authentication Policies Require MFA
Application-level policies can silently exempt individual apps from the org MFA requirement. An auditor verifies each app authentication policy still requires MFA.
Offboarding Completed For Suspended Accounts
A suspended account still needs evidence that offboarding actually happened and access was fully removed. Auditors correlate each suspension with a deliberate deprovisioning action rather than a partial state.
ThreatInsight Enabled
Without ThreatInsight, credential-stuffing and password-spray traffic reaches the login endpoint unthrottled. An auditor confirms threat detection is turned on for the org.
System Log Streaming Configured
If system logs are not streamed off Okta, audit evidence can be lost or altered inside the retention window. Auditors verify a log stream ships events to an external destination.
Password History Enforcement
Allowing password reuse lets a user cycle straight back to a leaked credential. An auditor confirms the policy blocks reuse of recent passwords.
Okta User Inventory
Access reviews and termination testing depend on a complete, system-generated list of who has access. This check enumerates the full user roster so auditors can sample against an authoritative population rather than a hand-kept list.
Drawn from Screenata’s Okta check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.
How it connects
Read-only, revocable, yours.
Read-only by construction
OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.
Signed findings
SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.
Mapped to controls
Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.
BAA & attestation status
Okta offers a BAA for customers who need one on qualifying plans, and publishes its own SOC 2 report. That covers Okta's own layer. You still configure MFA, session, and lifecycle policy in your org, and you still have to evidence that those settings operated across the audit period.
What access does Screenata need to Okta?
A read-scoped API token that you create and control. Screenata uses it for scheduled scans and never receives write access to your org. You can revoke the token at any time from the Okta admin console.
Does the Okta integration handle access reviews?
It feeds them. Quarterly access reviews are scheduled and orchestrated by Vera using the lifecycle and assignment data from Okta, and every review decision stays with a human reviewer. The completed review is recorded as signed evidence.
Does connecting Okta cover HIPAA too?
The same findings map to both frameworks through the shared control catalog: one MFA scan satisfies SOC 2 CC6.1 and HIPAA §164.312(d) at once, and session timeout evidence lands on the HIPAA automatic logoff requirement. Nothing is collected twice.
What happens when an Okta check fails?
Vera opens a ticket describing the failing configuration and re-verifies after a human applies the fix. Nothing in your org is changed by Screenata; the connection is read-only by construction.
What are the steps to implement SOC 2 with Okta?
Connect Okta read-only with a scoped API token. Let the first scan establish a baseline so you can see which settings already pass and which do not. Fix what fails: enforce MFA by policy so no sign-on path accepts a password alone, bound session lifetime and idle timeout, keep super admin assignments limited, and deprovision inactive users. Collect the passing results as signed evidence on a schedule, so you hold coverage across the whole audit period rather than one snapshot. Then hand the evidence package to an independent auditor. The audit is a separate engagement with a CPA firm; Screenata prepares the evidence and does not issue the report.
How do you automate user access reviews?
Okta supplies the authoritative list of accounts and entitlements. The HR roster supplies who should still have them. Screenata reconciles the two, schedules the review, routes each account to the right reviewer, and records the reviewer's decision as signed evidence. The access decision stays with the human reviewer. What the automation covers is gathering, routing, chasing, and recording.
Do auditors accept evidence Screenata collects from Okta?
Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.
Connect and see
Fifteen minutes after connecting Okta, you know your real posture.
Related: Google Workspace · Auth0 · JumpCloud · BambooHR