A SOC 2 Type II audit is not, primarily, a test of your security controls. It is a test of your evidence. The controls are table stakes. What separates companies that pass cleanly from companies that scramble is whether evidence of those controls was being collected continuously, in a retrievable format, throughout the observation period. Most engineering teams discover this the hard way.
This guide is written for engineering leads at companies between 20 and 200 engineers who have either just engaged an auditor or are six months out from needing to. It is not legal or compliance advice. It is a practical account of what we have learned from teams who have been through the process.
What the auditor is actually measuring
SOC 2 Type II auditors assess whether your controls operated effectively over a defined observation period - typically six to twelve months. The critical phrase is 'over a defined period.' A screenshot of your access control policy taken the week before the audit means nothing. A log of 400 access-grant and access-revoke events with timestamps, user IDs, and approver IDs tells a story that the auditor can follow.
Access management falls under the logical and physical access controls (CC6) category of the Trust Services Criteria. The auditor will typically ask for: evidence that access to production systems is restricted to authorized personnel; evidence that access is reviewed periodically; evidence that access is removed promptly when personnel leave or change roles; and evidence that privileged access requires a higher level of authorization than standard access.
The most common finding we see in first-time audits is not that companies have bad security. It is that they have good security with incomplete evidence.
The access-control evidence checklist
Before your observation period opens, you should be generating the following evidence automatically: a record of every access grant and revoke with a timestamp, the identity of the person who approved the change, and the system or resource affected; a periodic (at minimum quarterly) access review showing that someone with authority reviewed who had access and confirmed it was correct; termination and offboarding records showing that access was removed within your defined SLA; and a privileged access log showing every use of elevated permissions.
If you are managing credentials manually - shared password managers, .env files, spreadsheets - none of these logs exist. You will have to reconstruct them from Slack messages and email threads, which is both painful and unconvincing to an auditor.
The RBAC audit trail problem
The specific thing that causes the most last-minute stress is role-based access control evidence. Auditors want to see that access was granted according to a defined role model, not on an ad-hoc basis. If your access log shows 'user A was added to production database credentials on March 12' but there is no corresponding ticket, approval record, or role definition to explain why, the auditor has to mark it as an untestable control.
The fix is not to add a ticketing requirement retroactively. The fix is a system that associates every credential access event with the role that authorized it. When the auditor asks 'why did this engineer have access to the Stripe production key in February,' the answer should be a single query, not a conversation with three different managers.
Preparing your team without losing a sprint
The engineering team's primary contribution to the audit is making sure the evidence collection systems are in place and the policies are documented. This does not require a compliance sprint. It requires about two focused days of work spread over a month, distributed across two or three engineers.
Week one: document your access control policy. One page. Who can grant access to what, what approval is required, and what the SLA is for offboarding. This does not need to be comprehensive - it needs to be specific and accurate. An auditor comparing your policy to your log will notice immediately if they diverge.
Week two: audit your current access lists. Walk through every production system and verify that the people who have access should have access. Remove access that exists from a previous role, a completed contractor engagement, or a project that has ended. Document that you did this.
Week three: confirm that your logging is continuous. Pull a sample of the last ninety days of access events. Make sure there are no gaps. Make sure the records include the fields the auditor will want.
The two weeks before the audit window opens
Do not make significant changes to your access control infrastructure in the two weeks before the audit window opens. Auditors are suspicious of systems that look dramatically different at the start of the observation period than they did in the historical logs you provide for context.
Use these two weeks to do a dry run. Pull the evidence package that you would hand the auditor today: access grant logs, quarterly review records, offboarding records, role definitions. Read them as if you are the auditor. Are there gaps? Are the timestamps consistent? Does the story hold together?
If you find gaps, document them and the remediation. A gap with a documented corrective action is a finding. A gap with no documentation is a material weakness.
What good looks like on the far side
Companies that pass SOC 2 Type II cleanly have two things in common. First, they treat access management as an ongoing operational process, not a compliance event. The audit did not change what they do - it validated what they were already doing. Second, they use systems that generate evidence as a natural byproduct of their security controls, not systems that require a separate effort to produce evidence at audit time.
If your current credential and access management system cannot produce a report showing who had access to what, when, and why, you will spend the two months before every audit reconstructing that story manually. The audit passes or fails on that story.