The Sales lead tracking tool that got built because IT approval was "too slow" is now a SOC 2 finding with four terminated employees still holding active accounts. Marketing has the same problem with their content workflow tool. Both business units claim they handle access internally. The audit proved otherwise.

You've tried the manual workarounds — offboarding tickets to the business units, quarterly access review export requests, asking them to document access in a shared vault. Compliance is low, the evidence trail doesn't exist, and auditors won't accept "the business unit manages it" as a compensating control.

The realistic options before your next audit cycle aren't "force a rebuild" or "accept the exception." There's a middle path that doesn't require leadership to mandate a technical rewrite of working applications.

Why Manual Workarounds Don't Satisfy Auditors

The fundamental problem with asking business units to self-manage access for their custom applications is that the governance chain has no enforcement mechanism. An offboarding ticket to Sales relies on someone in Sales seeing it, acting on it promptly, and confirming completion. When that doesn't happen — and the audit shows it isn't happening — you have no evidence that timely access removal occurred, which is the specific control requirement.

Quarterly export requests have the same problem. If the export doesn't come in, you chase it. If it does come in, you have a spreadsheet that someone filled out manually with no assurance it reflects actual system state. Auditors evaluating SOC 2 access management controls need evidence that access reviews happened, that specific decisions were made, and that revocations were executed. A spreadsheet emailed by the app owner doesn't meet that bar.

Documenting it as an accepted exception is viable for a single audit cycle if the exception is genuinely low-risk and the compensating controls are substantive. Four terminated employees with active accounts in a sales tool — one of whom has likely continued to have access to prospect data — is not low-risk, and "we asked them to document access in 1Password" is not a substantive compensating control.

The Three Realistic Options (And What Each Actually Requires)

Option 1: Force integration into Okta. If the custom application can be modified to support SAML or OIDC, federating it into Okta solves the authentication problem and gives you SSO-controlled access. Disabling the Okta account cuts off access to the application. This is the cleanest long-term solution if the application has any ongoing development capacity. The business resistance you're encountering is a governance and executive sponsorship problem, not a technical one — it requires leadership to establish that any application holding company data must integrate with the identity stack, or be retired. That's a policy conversation, not an IT conversation.

Option 2: Compensating controls that actually create an audit trail. If forced integration isn't politically viable for the next audit cycle, the compensating controls need to be mechanically enforced rather than dependent on voluntary compliance. The difference between a compensating control that satisfies an auditor and one that doesn't is whether compliance is required by the system or requested from the business unit.

Option 3: IGA orchestration layer that governs without requiring application changes. For applications that won't be rebuilt and won't federate with Okta, an IGA platform governs the access lifecycle through whatever interface the application exposes — API, browser UI, or manual task — with the critical difference that the governance workflow is tracked in the IGA system, not dependent on someone in Sales responding to a ticket.

How an IGA Platform Closes the Gap for Custom-Built Apps

The connection method depends on what the application exposes.

If the application has any API surface. Even a basic endpoint — a REST endpoint the contractor can add in a few hours — is enough for an IGA platform to push lifecycle events. Zluri's HTTP Request action lets you configure a direct API call with the user identifier as a dynamic variable, so when an offboarding workflow fires, the platform makes the API call to deactivate or delete the account in the custom application automatically. No Sales team involvement required. If the contractor who built the tool is still engaged, adding a /users/{id}/deactivate endpoint is a small scope item that enables automated offboarding permanently.

If the application has no API but runs in a browser. Zluri's AI-powered integrations use deterministic browser automation to navigate the application's admin interface and execute user management actions — logging in, finding the user, deactivating the account — the same way a human administrator would. This covers the category of internally-built tools that have admin UIs but no programmatic interface, without requiring the application to be modified.

If the application is fully air-gapped with no automation path. The fallback is a governed manual task — but governed in the IGA platform, not in a ticketing system the business unit can ignore. When an employee termination fires in the HRMS, Zluri generates a "Remove User" task specifically assigned to the designated Sales or Marketing app owner. That task sits open in the IGA dashboard, visible to compliance and security teams, until the app owner marks it complete. The offboarding record remains incomplete — and visibly incomplete — until the task is resolved. Auditors can see a complete offboarding record with task completion timestamps rather than "we sent a ticket."

Getting Access Reviews Without Quarterly CSV Begging

For applications where you can't automatically sync the user list, Zluri supports a CSV upload path for access certification campaigns. The app owner uploads their current user export, the IGA platform runs the review campaign against that data, and reviewers are presented with a structured dashboard where they must explicitly approve, modify, or revoke each user's access — with mandatory justification for any changes.

The output is a timestamped, non-editable compliance report that documents who reviewed what, what decisions were made, and when. This is the evidence format that SOC 2 auditors accept as proof of a completed access review, versus a spreadsheet that someone sent over email.

The compliance incentive for the business unit changes too. Instead of asking Sales to voluntarily submit a quarterly export to IT, the access certification campaign is configured to run automatically on a schedule. If the app owner doesn't upload the user list, the campaign is overdue — which is a finding that surfaces to compliance and security rather than disappearing into an ignored email thread.

The Executive Conversation You Need to Have

The technical controls above close the audit gap. But the structural problem — departments building and running applications outside the governance framework — requires a policy response that doesn't come from IT.

The four terminated employees with active accounts in the Sales tool is the argument you need to make to leadership. That's not a hypothetical risk; it's a documented control failure. The question is whether the company wants to establish a policy that any application holding company data must register with IT for governance purposes, or whether it's prepared to repeat this finding in every future audit.

The policy doesn't require rebuilding existing applications. It requires that app owners participate in the governance process — designating an owner in the IGA system, uploading user lists for access reviews when automation isn't possible, and responding to offboarding tasks within a defined SLA. That's a reasonable ask that doesn't conflict with business unit autonomy over their tools.

Frequently Asked Questions

How do you handle SOC 2 audit findings for custom apps that aren't integrated with Okta or AD?

The options are: federate the application into Okta via SAML/OIDC if development capacity exists, add a basic API endpoint to enable automated lifecycle management, use AI-powered browser automation for admin UI-accessible apps, or implement governed manual tasks with tracked completion in an IGA platform. The key distinction from manual workarounds is that the governance trail lives in the IGA system rather than depending on voluntary compliance from the business unit.

What compensating controls satisfy SOC 2 auditors for disconnected applications?

Auditors require evidence of timely access removal and periodic access reviews — not a description of the process, but documented execution. Acceptable evidence includes: automated deprovisioning logs, IGA-generated offboarding records with task completion timestamps, and access certification reports that are timestamped and non-editable. A ticket sent to a business unit with no documented completion is not acceptable compensating control evidence.

How do you enforce offboarding for a custom application with no API?

Three paths: add a basic API endpoint (a small development task if the contractor is still engaged), use AI-powered browser automation to interact with the admin UI programmatically, or route a tracked manual task to the designated app owner in an IGA platform where the task must be explicitly completed before the offboarding record closes. The manual task path doesn't automate the access removal, but it creates an enforceable audit trail with completion timestamps.

How do you run access reviews for an application that can't sync its user list automatically?

An IGA platform that supports CSV upload for access certification campaigns lets the app owner submit their current user list manually, then runs the review workflow against that data. Reviewers approve or revoke through a structured interface with mandatory justification, and the platform generates a timestamped compliance report at campaign completion. This satisfies the SOC 2 evidence requirement without requiring the application to have an API integration.