Six weeks before a SOC 2 audit with 40 applications outside your identity stack is not a comfortable place to be. But it's a recognizable one. Most organizations that have grown beyond a handful of purpose-built SaaS tools end up with a mixed environment: a clean, well-governed SSO layer sitting on top of a much messier layer of legacy ERPs, regional procurement tools, department-specific applications, and custom-built systems from a decade ago that no one has had budget to replace.

Auditors know this environment exists. What they want to see is that you know it exists too — and that you have controls in place to manage the risk it creates, even if those controls look different from what you'd apply to an Okta-integrated application.

Here's a realistic framework for handling this before your audit window closes.

Why Spreadsheets Fail the SOC 2 Test

The access review spreadsheets your app owners are ignoring aren't failing because your team is disorganized. They're failing because spreadsheets don't produce the evidence auditors actually need.

SOC 2 auditors looking at access reviews want to see non-repudiation: proof that a specific person reviewed a specific access record at a specific time and made a documented decision about it. A spreadsheet that an app owner filled out at some point doesn't demonstrate that. It demonstrates that someone put names in cells. There's no timestamp on individual decisions, no mandatory justification for why access was retained, no evidence that anything was actually remediated after the review concluded.

The same problem applies to offboarding. “The app owner handles it” is not a control. It's a hope. Auditors distinguish between the two, which is why you got a finding last time and why the finding will repeat if the process hasn't changed.

Step One: Build a Complete Application Inventory

Before you can govern access to your 40 legacy apps, you need a documented inventory that establishes you know what those apps are, who owns them, and who has access to them. This is the foundation auditors look for before evaluating your controls.

For applications that aren't integrated with Okta or AD, discovery has to happen through other signals. Browser activity data — tracking which URLs employees are accessing — can surface applications that IT didn't formally provision. Financial and expense data can identify regionally purchased tools that appear in procurement records but not in your application catalog. HRMS data can help correlate which employees are associated with which systems based on department and role.

Once discovered, each application needs a formally assigned internal owner. This isn't just an organizational nicety — it establishes the accountability chain that auditors expect. The app owner is the person responsible for access reviews and for confirming that offboarding has been completed. If that ownership isn't formally documented, you can't demonstrate the control exists.

Step Two: Replace Hope-Based Offboarding With a Documented Process

The finding from your last audit — inadequate offboarding controls for non-SSO applications — is one of the most common SOC 2 findings in mixed environments, and it's fixable without technical integration into the legacy apps themselves.

The key is replacing informal notification (“we emailed the app owner”) with a structured, trackable task that generates a record regardless of whether it's completed via API or manually.

For applications without API access, offboarding playbooks can generate manual tasks — structured work items with unique identifiers assigned to the designated app owner, with a deadline and a completion requirement. The app owner has to mark the task complete to close the audit loop. That completion record, with a timestamp, is the evidence of timely access removal that auditors need — even though the underlying action was manual.

If your IT team already works in Jira, these manual tasks can trigger Jira tickets automatically, so the process fits into existing service desk workflows rather than requiring people to operate in a separate system. The governance layer maintains the centralized record of request to fulfillment; your team works in the tool they already use.

The shift this creates is significant. Instead of “we notified the app owner and assumed they handled it,” you have a documented chain: offboarding triggered, task assigned, task completed, timestamp recorded. That's a control. The previous process wasn't.

Step Three: Run a Formal Access Review Campaign Now

If your audit is in six weeks, the most important thing you can do this week is launch a formal access review for these 40 applications. Not a spreadsheet — a structured campaign with defined reviewers, mandatory justification requirements, and an output that produces auditable evidence.

The difference between a structured access review and a spreadsheet review is what happens at the end. A structured campaign produces a non-editable report with timestamps for each reviewer decision, documentation of the justification provided for retained access, and proof of remediation for access that was revoked. That report is what auditors mean when they ask for evidence of periodic access reviews.

For your 40 legacy apps, reviewers should be the formally assigned app owners from Step One. For each user in scope, the reviewer confirms whether access is still appropriate, provides a justification if it is, and flags it for removal if it isn't. The platform closes the loop by generating a remediation task for anything flagged for removal — using the same manual task workflow from Step Two if no API is available.

Running this now gives you review evidence before the audit. Running it annually, or triggered by events like role changes, gives you a defensible ongoing control.

Step Four: Address the MFA Gap With Compensating Controls

Most SOC 2 frameworks recognize that some systems can't support MFA. What auditors want to see in those cases is that you've identified the gap, documented why technical controls aren't feasible, and implemented compensating controls that reduce the risk.

For legacy applications that can't enforce MFA natively, a compensating control approach works by using a system that does enforce MFA — typically Okta — as a signal source. If a user becomes inactive or is deprovisioned in Okta, that status change can be used to flag their access in connected legacy applications as a risk that requires immediate review. The user can't log in through Okta-protected channels, but their local credentials in the legacy app still exist — surfacing that gap proactively is the compensating control.

Risk scoring by application helps prioritize this work. Not all 40 apps carry the same risk. Your custom ERP from the 2000s with access to financial data is a different risk profile than a regional procurement tool with read-only access. Prioritizing more frequent reviews and tighter manual controls for your highest-risk applications demonstrates a risk-based approach that auditors generally respond well to.

Step Five: Document What You're Doing and Why

One thing that helps significantly in SOC 2 audits for mixed environments is a clear, written narrative of your control environment for non-integrated applications. This isn't a gap — it's context.

The narrative explains which applications aren't integrated with your IdP, why they aren't (legacy architecture, no SSO support, no API), what compensating controls you've implemented in lieu of technical integration, and what your remediation roadmap looks like for modernizing or replacing these systems over time.

Auditors who understand enterprise environments know that 40-year-old ERPs don't get replaced in a quarter. What they're evaluating is whether you have a defensible, documented approach to managing the risk these systems create. A written narrative paired with the access review evidence from Step Three and the offboarding task records from Step Two gives them what they need to assess your controls, even if those controls look different from a fully integrated identity stack.

What to Prioritize in the Next Six Weeks

With a six-week window, the realistic priority order is:

First, complete the application inventory and assign formal ownership for all 40 apps. This takes days and is the prerequisite for everything else.

Second, launch the access review campaign immediately. The longer you wait, the less time you have for remediation before the audit.

Third, implement the manual offboarding task workflow so that any terminations between now and the audit are handled with a documented process rather than the informal one that generated your previous finding.

Fourth, document your compensating controls for the MFA gap and your remediation roadmap for each system category.

The budget conversation for modernizing or replacing these systems is a longer-term project. For the immediate audit, the goal is demonstrating that you have governance controls in place for these applications as they currently exist — not that you've solved the underlying technical debt. Those are different conversations, and conflating them is what causes teams to feel like they have nothing to show auditors when they actually have more than they realize.