Most SOX access reviews I've been involved in run the same way. IT exports a user access report. The report goes to each manager as a spreadsheet. The manager approves their rows, usually without reading them carefully, because they have other things to do and the deadline is tomorrow. Audit closes the finding. Nothing changes.
The process satisfies the checkbox. It doesn't catch anything.
I owned SOX audit responsibilities for IT systems and access controls at Life360 for 3 years. The access review was my process. I designed it, ran it quarterly, and delivered it to our external auditors. And for the first year and a half, it was exactly that kind of checkbox process.
What changed it was not the process itself — it was building the RBAC framework underneath it that made the review actually meaningful. Once we had defined access tiers, mapped app permissions to roles, and enforced group-based provisioning through Okta, the access review became a comparison between what the model said people should have and what they actually had. That comparison surfaces real findings.
The Access Review Tool automates that comparison using Claude. It covers the full access lifecycle: new hire provisioning, quarterly access review, policy violation detection, offboarding, and SOX audit report generation.
New Hire Provisioning Recommendations
Over-provisioning starts at day one. The standard access package gets applied, sometimes with admin-level access on tools where the hire needs read-only at most, because it's easier to grant full access than to figure out the right level during onboarding.
The New Hire Intake page takes the hire's details — role, department, seniority level, reporting manager — and runs them against Claude with the organization's standard access package as context. The output is a per-app recommendation: the appropriate permission level (user, read-only, or admin), the rationale in one sentence, a SOX sensitivity flag for apps in scope for access controls, and a provisioning priority (immediate, within 24 hours, or within a week).
The provisioning priority is the output that makes the IT technician's job cleaner. Immediate means the hire needs this on day one to do their job. Within 24 hours means it can wait until their second morning. Within a week means it's lower priority than the core tooling. This prevents the situation where every app request gets treated as urgent and the tech spends day one of a new hire's employment getting 15 Jira tickets at once.
The SOX sensitivity flag is what makes this useful for compliance specifically. Not every app is in SOX scope. The ones that are — financial reporting systems, ERP access, any system touching revenue recognition — need additional approval routing and documentation. The flag surfaces that requirement at provisioning time rather than during the quarterly review.
Violation Detection
The Policy Violations page runs a Claude-powered analysis against the full employee access dataset and returns a structured list of violations with severity ratings.
The 6 violation patterns the tool detects:
Terminated active access: an employee whose status is terminated or inactive still has active accounts in one or more systems. This is the highest-severity finding. A former employee with active access to a financial reporting system is a definite audit finding.
Over-provisioned: an employee has access at a higher permission level than their role requires. Admin access where the role requires read-only. This is the most common finding in any access review and the hardest to defend in an audit because it usually represents provisioning decisions made for convenience.
Stale SOX access: an employee with access to SOX-sensitive systems hasn't had that access reviewed in the required period. In most SOX environments, access to financial systems requires quarterly certification. Older than 90 days is a finding.
Orphaned approval: an employee has elevated or sensitive access that was approved by a manager who is no longer with the organization. The approval record exists but the approver is gone, which means the access has no current accountability chain.
Incomplete provisioning: an employee was granted access to some systems in their standard package but not others. This usually indicates a provisioning failure partway through an onboarding ticket.
On-leave sensitive access: an employee on extended leave still has active access to sensitive systems. Most access policies require suspension of sensitive system access during leave periods longer than a defined threshold.
Each violation comes with the specific employees and apps affected, a description of the risk, and a recommended action. Severity tiers (Critical, High, Medium) drive the remediation priority in the audit report.
The Offboarding Flow
The Offboarding page surfaces the per-employee deprovisioning checklist based on what systems they had access to. This connects directly to the violation detection: if a terminated employee is flagged for active access, the offboarding checklist shows exactly what needs to be revoked and in what order.
The checklist distinguishes between systems with automated deprovisioning via Okta SCIM and systems requiring manual revocation. For the manual systems, it lists the specific steps and who should execute them. This is the document you show the auditor when they ask how you ensure departed employees don't retain access — not a policy statement, but the actual executed checklist for a specific employee.
The SOX Audit Report
The Audit Report page pulls from the violation detection results and generates a structured report via Claude formatted for the CTO, CFO, and external auditors.
The report has 6 sections: an Access Review Summary (scope, date, employee count, methodology), Critical Findings (every Critical and High violation with employee IDs and apps affected), SOX Compliance Status (which systems were reviewed and any access gaps found), Risk Assessment (an overall rating of Low, Medium, High, or Critical with a 4-sentence justification), a Remediation Plan (5 numbered action items with responsible party and deadline), and a Sign-off Block.
The Sign-off Block ends with a status line: either "FINDINGS REQUIRE IMMEDIATE ACTION" or "COMPLIANT WITH NOTED EXCEPTIONS." That's the line the auditor reads first. Everything else in the report supports whichever status the data produces.
The report is what distinguishes a meaningful access review from a checkbox exercise. It names specific employees and specific violations. It produces specific remediation commitments with deadlines. A manager who knows the quarterly access review produces this kind of output reviews their rows more carefully.
The demo dataset ships with 50 employees across 12 departments and 15 applications, with pre-seeded violations across each category so you can see what the violation detection output looks like without configuring anything. The code is on GitHub.