The simple path to making SOC 2 auditors happy

One of the questions we get asked most is, “Are you SOC compliant.” Yes. It’s table stakes. Plus, we have the right tools for the job.

SOC 2 audits rarely fail because a company lacks policies. They fail because nobody can prove the policies are actually working. Ask most engineering teams a few simple questions and the conversation can quickly become awkward:

• Who currently has admin access in your cloud environments?
• Which engineers can access production data?
• When was the last time those privileges were reviewed?

We might get a spreadsheet. We might get a Slack thread. We might get a shrug.

SOC 2 compliance, however, is not about good intentions. It is about demonstrable controls. Proof that access is limited, monitored, and revoked when it should be. In modern cloud environments where thousands of identities interact across platforms, that proof can often be the hardest part.

SOC 2 isn’t (primarily) a documentation challenge. It’s an identity management challenge.

SOC 2 is Really About Controlling Access

At its core, SOC 2 compliance evaluates whether an organization has effective controls protecting customer data. These controls are defined under the Trust Services Criteria, particularly the logical access requirements within the CC6 control family.

Those requirements boil down to several expectations. Users receive only the access they need, access is reviewed regularly, privileges are monitored and logged, and access is removed when it’s no longer required.

On paper, this seems straightforward. In cloud-native infrastructure, it becomes complicated very quickly. Modern environments likely include multiple cloud providers, hundreds of services, thousands of identities, and dynamic infrastructure created by automation. As a result, the number of permissions multiply faster than most teams realize.

Research from Google Cloud’s Threat Horizons report found that misconfigured identities and excessive privileges remain one of the most common cloud security risks. Meanwhile, the Verizon Data Breach Investigations Report repeatedly shows credential misuse and privilege abuse among the leading breach patterns year after year.

The same problems that cause breaches are, quite sensibly, also the ones auditors look for.

The Standing Privilege Problem

Many organizations approach SOC 2 by documenting processes around access management, but the technical architecture underneath often tells a different story.

Developers and engineers frequently receive standing privileges (permanent access to elevated roles) because it is operationally convenient. Admin permissions are granted “temporarily” and then forgotten. Service accounts accumulate privileges as systems evolve, and orphaned AI agents are sneaking under the deprovisioning radar.

Over time, this produces broad roles granted for convenience, privileges that outlive the task they were created for, and accounts that retain access long after responsibility changes. All crushingly familiar. Security teams often refer to this as identity debt.

From an auditor’s perspective, it creates a problem: there is no clear evidence that least privilege is actually being enforced.

Why Least Privilege Is Hard to Prove

Every SOC 2 audit eventually arrives at the same crucial point. The auditor asks a deceptively simple question:

“Can you prove that users only have the access they require?”

Most organizations can explain their policy. Fewer can produce clear, structured evidence.

The difficulty lies in how permissions are typically managed. Access approvals might live in ticketing systems, chat threads, manual IAM changes, or undocumented admin actions.

When auditors request evidence, teams so often find themselves reconstructing access history from fragments. It is not unusual to see engineers rummaging through old tickets trying to answer questions about permissions granted months earlier, and from a compliance perspective, this approach is fragile. SOC 2 compliance requires systematic proof, not archaeology.

The Architectural Shift: Zero Standing Privileges

A growing number of organizations are addressing this challenge by rethinking how privileges are granted in the first place. Instead of assigning permanent elevated access, they adopt Zero Standing Privileges (ZSP).

Under the ZSP model, users operate with minimal baseline permissions, elevated access must be requested when needed, privileges are granted temporarily, and access automatically expires after the task is completed. This approach aligns closely with the principle of least privilege while also producing clear evidence for auditors.

Temporary privilege grants create a visible lifecycle:

1. Access requested.
2. Access approved.
3. Access granted for a defined period.
4. Access automatically revoked.

Each step produces a traceable record, and from a SOC 2 compliance perspective, this is significantly easier to demonstrate.

Access Reviews: Where Compliance Often Breaks

Another SOC 2 requirement involves periodic access reviews.

Organizations must verify that permissions remain appropriate. In theory, this is simple. In practice, it often becomes a painful, manual process.

Typical access reviews involve exporting user lists, distributing spreadsheets to managers, chasing responses, and manually removing outdated permissions. Unsurprisingly, these exercises are frequently incomplete.

The Identity Defined Security Alliance reported that more than 90% of organizations experienced identity-related incidents in a single year, often linked to poor visibility into permissions.

When access reviews rely on manual processes, errors and omissions are inevitable.

Automated certification campaigns change this dynamic. Instead of emailing spreadsheets, managers review activities directly against live permissions, with their decisions recorded and enforced automatically.

The difference is not merely convenience. It creates an auditable record of governance.

Visibility Is the Missing Ingredient

One of the least discussed challenges in SOC 2 compliance is simply understanding who has access to what, and more importantly, whether they use any of it.

In cloud environments, permissions are rarely simple. Roles inherit permissions, groups are assigned permission sets, groups can be members of a group, and roles can be assigned to roles.

Without a unified view, SOC teams struggle to answer questions like:

• Who has administrative privileges across cloud environments?
• Which identities can access sensitive data stores?
• Which permissions have never been used?

Visibility becomes the foundation for every other control.

Continuous monitoring of permission usage allows teams to detect overprivileged accounts, reduce risk, and demonstrate that access is actively governed. For auditors evaluating SOC 2 compliance, that visibility signals maturity.

Compliance Becomes Easier When the Architecture is Right

Anecdotally, when talking to our customers and prospects, the most interesting lesson many organizations learn during SOC 2 preparation is that compliance becomes easier when the underlying identity architecture is sound.

When privileges are temporary, approvals are recorded, access reviews are automated, and permissions are continuously monitored, the evidence auditors request already exists.

Security teams are no longer reconstructing history. They are simply showing how the system works.

SOC 2 compliance stops feeling like an annual administrative ordeal and becomes something closer to a by-product of good security engineering. And that, ultimately, is the easy route. Not more documentation, but better control of identity.

Want your SOC 2 compliance problem to go away? No problem. Start with our free, full-featured trial. In about 30 minutes you’ll get a clear view of every entitlement across your cloud and SaaS stack, including non-human identities and agent accounts, so you can prove least privilege, run access reviews, and stroll into your next audit with real evidence instead of a fist full of spreadsheets.

‍