If you are sitting in a C-suite chair and your company is chasing a SOC 2 report, you will hear the term "access controls" about fifty times between now and the auditor leaving the building. This guide explains what that actually means, which parts of the framework you need to care about, and what you need to do to get there.
It is written for executives. No jargon where I can avoid it, and an explanation when I cannot.
What is SOC 2, really?
SOC 2 is an audit that your company pays a CPA firm to run. The auditor tests whether your security practices actually ran the way you say they ran, over a defined period of time. There are two flavors. Type I is a snapshot, where the auditor checks your controls exist on a single day. Type II is a movie, where the auditor watches your controls operate over six or twelve months.
Type II is the one your customers actually want to see. It proves not that you have policies, but that your policies ran consistently.
The output is a report. Either it comes back clean, or it comes back with findings that you then have to explain to every customer who asks for the report. That report will follow you around for years, which is why most companies treat SOC 2 like it matters.
Where does identity and access fit in?
SOC 2 groups its requirements into buckets labeled CC1 through CC9, where CC stands for Common Criteria. Think of them as chapters in the audit rulebook.
Most of the identity and access work lives in one chapter, CC6, which covers logical and physical access controls. Within CC6, three sub-sections do almost all of the heavy lifting. If you get those three right, you have done most of the IAM work SOC 2 needs. A few other sub-sections matter too, and a couple of chapters outside CC6 have IAM touchpoints. I will cover all of that below.
The three criteria that do most of the work
CC6.1, in plain English
The question the auditor is asking: can you prove that only authorized people reach your production systems and your sensitive data?
In practice, that means you need:
- Single sign-on across your applications, so every login routes through one identity provider instead of each app having its own username and password
- Multi-factor authentication on anything that matters, meaning a second factor beyond a password for production, administrative access, and anywhere customer data lives
- An authorization model, meaning a documented way of deciding who can access what based on their job
- Network segmentation, meaning a compromised laptop does not automatically become a compromised database
The failure mode: a SaaS app the marketing team bought a year ago that never got put behind SSO. Or a production console that still accepts just a password. Auditors find these in minutes.
CC6.2, in plain English
The question: how does access get created, changed, and removed when people join, move roles, or leave?
The auditor wants to see that the process is repeatable and tied to real HR events. When someone joins, their access should come from a defined workflow based on their role. When they change roles, they should lose their old access at roughly the same time they pick up new access. When they leave, their access should be revoked within a defined window, and you should be able to prove it happened for every single termination during the audit period.
The failure mode: Jane was terminated on January 1. Her Okta account was disabled on January 4. Her AWS access was revoked on January 9. Her GitHub access is still active in March. The auditor pulls a random sample of terminations, finds Jane, and you have a finding.
CC6.3, in plain English
The question: is every person restricted to the minimum access they need to do their job?
This is where three related concepts live. Role definitions, which describe what each job function is allowed to do. Least privilege, meaning nobody has more access than their role requires. And user access reviews, which is when a human being sits down on a schedule and signs off on who has what.
The failure mode: role definitions drift over time because someone adds a permission for a one-off project and forgets to take it away. Five years later, every engineer has read access to every repository, every analyst has access to every dashboard, and nobody can explain why. Access reviews become a CSV export that a manager replies "looks good" to with no actual review.
The rest of CC6, briefly
CC6 has eight sub-criteria total. Three do most of the work, but a few others matter and you should be aware of them.
- CC6.6 covers access across your system's boundary. In plain English: remote access, VPN, your vendors connecting into your systems, customers connecting into your systems. Matters more if you have a lot of remote work or third parties with system access.
- CC6.7 covers data in transit and on removable media. Encryption when data moves over the network. Controls on USB drives and the like.
- CC6.8 covers malicious software prevention. Mostly an endpoint security concern, but touches device trust, which is IAM-adjacent.
You do not need to lose sleep over these. You do need to make sure someone on your team owns each one and that the controls match what you tell the auditor.
Identity also shows up outside CC6
A few criteria in other chapters interact with IAM closely. Your team should know about them.
- CC7.2 is about monitoring for anomalies. Failed login patterns, privilege escalations, unusual access times. Your identity logs need to feed into whatever security monitoring tool you use.
- CC7.3 through CC7.5 cover security incident response. When credentials get stolen or privileges get abused, you need a documented process for detecting, responding, and recovering.
- CC8.1 is change management. Changes to role definitions, new privileged access grants, and break-glass events are all changes that need to go through a controlled process with a paper trail.
A well-run IAM program does not treat these as separate problems. The same logs, the same tooling, and the same review cadence serve all of them.
The three places most companies fail
I have sat through dozens of SOC 2 prep calls. The same three problems come up in almost every one.
The offboarding gap
Everything above about termination timing. The auditor pulls a sample, finds an active account for a former employee, and it is a finding. This is the single most common SOC 2 IAM failure.
Phantom admin accounts
A break-glass admin account was created for an outage two years ago. The password never got rotated. Nobody knows who uses it. Or a platform engineer got root access in AWS for a migration and never gave it back. Auditors find these by comparing who has admin rights against role definitions and asking for the approval that authorized each elevation.
Access reviews that do not review
Someone exports a CSV of users, emails it to a manager, and the manager replies "looks good." No documented criteria, no real sign-off, no resulting changes. That is a review on paper and a finding in the audit. SOC 2 wants evidence that a human actually looked and made decisions.
What you actually need to do
This is the sequence I run for clients. If your board is asking about SOC 2 readiness, this is the order of operations.
Step 1: Make your identity provider the source of truth
Pick one identity provider. Usually Okta or Entra ID. Every application, including the obscure ones your team bought without telling you, gets pulled behind it. Every login, everywhere, routes through the identity provider.
This sounds simple. It is not. Most mid-market companies I walk into have their ten most-used apps behind SSO and twelve edge-case apps running local accounts. Those twelve apps are where findings live.
Step 2: Wire HR events to automation
Joiners, movers, and leavers should not require a ticket. When HR marks someone as terminated in the HR system, an automated workflow should suspend their identity, revoke their active sessions, and trigger downstream removals across every connected application.
Same for role changes. Same for new hires. The HR system is the source of truth for employment status, and identity should react to HR events automatically.
This is the single highest-leverage investment for SOC 2 IAM. It fixes CC6.2 structurally instead of relying on tickets and memory.
Step 3: Run access reviews that produce evidence
Quarterly is the standard cadence. The reviews should be scoped by system, assigned to a named owner, and produce an artifact the auditor can sample from. The reviewer should get a focused list of their direct reports and flagged accounts, make decisions in one session, and the tool should capture the sign-off, the criteria, and the resulting changes.
If your access reviews happen in a spreadsheet, switch to a governance tool. The tooling pays for itself in audit prep time saved.
Step 4: Put MFA on everything that matters
Every SaaS application that touches customer data. Every cloud account. Every source code platform. Every database console. The VPN. Yes, including the legacy applications that nobody wants to touch.
If an application cannot support MFA at all, that becomes a documented exception with a compensating control, not a quiet gap.
Step 5: Treat privileged access as its own problem
Anyone with elevated access in your identity provider, your cloud, your production systems, or your source code should go through a request-and-approval workflow to get that elevation, and it should be time-boxed. Standing admin access is a finding waiting to happen.
Daily-driver accounts should not be able to destroy production. Administrative work happens in a separate session, under a separate identity, with approvals and logs.
How you will know you are ready
A well-instrumented IAM program turns the audit into a data export exercise. The auditor asks for a sample of new hires. You run a query and hand over the provisioning log with HR event IDs. They ask for terminations. Same thing. They ask for the last quarterly review. You hand over the completed review with signatures and the resulting change tickets.
Teams I work with usually cut their audit prep cycle from eight weeks to about two, because most of the evidence is already there. That is the real value of doing this well. Not passing the audit. Making the audit boring.
Where to go from here
If you are six months out from your first SOC 2 Type II and you are not sure where you stand, the Identity Infrastructure Assessment is built for exactly this situation. It produces a gap analysis against CC6, a prioritized remediation plan, and evidence templates you can hand to your auditor on day one. Most clients come out of it knowing which three things to fix first and which five things they can defer.