What Do SOC 2 Auditors Look for in Your SaaS Stack?

Access control is one of the areas where SOC 2 audits frequently surface exceptions. EY's analysis of more than 2,000 SOC reports supporting 2024–2025 financial audits found that 40% of deviations in SOC 2 reports were related to logical access. That's not necessarily because companies are careless about security. Access controls are difficult to maintain consistently across every application, employee, and role, and they're difficult to document well after the fact.

Understanding what an auditor is actually looking for in your SaaS stack makes the difference between an audit that surfaces a handful of manageable findings and one that turns into a scramble to reconstruct months of missing evidence.

What SOC 2 auditors are actually evaluating

A SOC 2 audit isn't a single pass-or-fail check. It's an evaluation of whether specific controls exist, are properly designed, and, for a Type II report, actually operated consistently over the audit period, typically the prior three to twelve months. For most companies, the SaaS stack sits at the center of a meaningful share of those controls, since so much of modern business runs through software that touches customer data, employee access, and vendor relationships.

Auditors don't take your word for it that a control exists. They ask for evidence: logs, records, and documentation showing the control was actually followed, not just written down as policy somewhere.

The specific things auditors ask about

An inventory of the applications and systems relevant to the audit's scope. Depending on the audit scope, auditors may ask for an inventory of the applications and systems relevant to the services and controls being examined, rather than every piece of software the company happens to use. A gap here, or an inventory nobody can produce quickly, is still one of the more common starting points for deeper questions once the scoped systems are identified.

Evidence that access reviews happened on a regular basis, not just once. Auditors generally want to see that access was reviewed periodically throughout the audit period, with documentation of who reviewed it, when, and what was decided, not a single review completed right before the audit began.

Proof that departing employees actually lost access, and when. Given how often logical access issues surface as deviations, this is one of the areas auditors pay close attention to. Auditors typically sample a set of departures from the audit period and check the timing between the termination date and when access was actually revoked across relevant systems.

Documentation of vendor risk assessment for the SaaS tools you rely on. Auditors generally expect evidence that you've assessed the tools your company depends on, not just collected a SOC 2 report from each vendor once and filed it away. A report alone, without a documented review process behind it, is often treated as necessary but insufficient.

Evidence that third-party access and integrations were tracked, not just assumed to be fine. OAuth connections and API integrations between tools can fall inside the scope of what auditors ask about, particularly when those connections touch systems relevant to your trust services commitments.

Consistent operation of controls across the entire audit period, not just at one point in time. For a Type II report specifically, auditors are testing whether a control worked the same way in month two as it did in month eleven. A process that worked well right after it was documented but quietly lapsed a few months later is exactly the kind of gap that surfaces during sampling.

Why these specific areas trip companies up

Policies describe a process that isn't actually followed day to day. A written policy stating that access reviews happen quarterly means nothing to an auditor if the actual evidence shows reviews happening once, right before the audit period closes. Auditors are trained to look for exactly this kind of mismatch between documented policy and operational reality.

Evidence lives in too many disconnected places. Access logs sit in one system, the sanctioned tool list sits in a spreadsheet somewhere else, and vendor risk assessments live in yet another folder. Pulling all of it together into something an auditor can actually review becomes its own project every audit cycle.

Shadow IT falls outside every control that was documented. A control describing how access gets reviewed and revoked for sanctioned tools doesn't cover a tool an employee signed up for individually and never told anyone about. That gap is invisible until an auditor's sampling happens to surface it, or until it becomes a security incident first.

How to prepare before the audit starts

Build the application inventory relevant to your audit scope well before the audit window opens, and keep it current on an ongoing basis rather than reconstructing it right before the auditor asks.

Run access reviews on the actual cadence your policy claims, and keep a record of each one, who reviewed it, what was found, and what was changed as a result.

Track the gap between every departure date and every access revocation date. Given how frequently logical access issues surface in SOC 2 findings, having this readily available, rather than reconstructed after the request comes in, meaningfully speeds up the process and reduces the odds of a deviation.

Document your vendor risk review process, not just the certificates you've collected. A folder of SOC 2 reports from your vendors is a start. Evidence that someone actually reviewed each one, and revisited it periodically, is what auditors are actually looking for.

Include shadow IT discovery as part of your evidence-gathering, not an afterthought. A control that only covers the sanctioned tool list leaves out exactly the tools most likely to create an audit gap. Actively looking for unsanctioned tools before the auditor does is a much better position to be in.

Where OptyStack fits

Pulling together a current application inventory, access review history, and vendor risk documentation from a dozen disconnected systems is realistic to do once, under pressure, right before an audit. It's much harder to keep current as an ongoing practice, which is exactly what a Type II audit is actually testing for.

OptyStack keeps your application inventory, access data, and usage information in one place, so the evidence auditors ask for is available on an ongoing basis rather than something that has to be reconstructed from scratch every audit cycle.

It's free to start and doesn't require a credit card.

Keep your SaaS estate audit-ready year-round. Start free with OptyStack.