OCPL — Octane Cyber Safe Private Limited

Compliance

What auditors actually look for in SOC 2 readiness

Auditors don't grade policy documents on how well-written they are. They test whether controls actually operated the way the documentation says they do.

Aditya Mandar Bodhe Updated 2 min read
Compliance

A common misconception going into a first SOC 2 audit is that the goal is to produce well-written policies. Policies matter, but an auditor’s real job is to test whether the organization’s actual behavior matches what those policies claim — and that distinction is where most first-time readiness gaps show up.

Evidence, not documentation

A policy that says “access is reviewed quarterly” isn’t evidence that access was reviewed quarterly. An auditor wants to see the actual review — who ran it, when, what was found, what changed as a result. This is the single biggest gap between companies that pass smoothly and companies that scramble: whether evidence was generated as a byproduct of doing the work, or has to be reconstructed after the fact.

Design vs operating effectiveness

For a Type I report, an auditor checks whether controls are designed appropriately as of a specific date — do the right processes exist, on paper and in practice, at that moment. For a Type II report, they check operating effectiveness — did those controls actually run consistently over the observation period, typically three to twelve months. A control that existed for one week before the audit doesn’t have an operating history to test.

Common gaps auditors flag

Access reviews that don’t actually happen on a cadence. Access control policy exists, but there’s no evidence of a regular, documented review process removing access that’s no longer needed.

Incident response plans that have never been exercised. A well-written plan that’s never been tested (even informally) is a common finding — auditors increasingly look for evidence of at least a tabletop exercise, not just a document.

Vendor and subprocessor management that’s inconsistent. Critical vendors were vetted; smaller ones were not, with no documented criteria for why.

Logging and monitoring that exists but isn’t reviewed. Logs are being collected, but nobody can point to a process for actually looking at them or acting on alerts.

The practical implication

Readiness work is less about writing better policies and more about making sure the operational habits described in those policies are actually happening, consistently, with evidence left behind — well before the audit window starts, especially for a Type II report.

SOC 2 readiness engagements are built around this distinction specifically: closing the gap between what’s documented and what’s actually operating, not producing better-looking paperwork. A vulnerability assessment is often part of the evidence auditors expect to see as well.

SOC 2AuditsCompliance

Have a question this didn't answer?

Every engagement starts with a conversation about your specific situation, not a generic package.