The first SOC 2 audit I sat in on with an engineering team went sideways in about eleven minutes.
Not because the pipeline was bad. It was a good pipeline. Trunk-based, tests gated on merge, deploys on green, everything in Terraform. The kind of setup an engineering lead is quietly proud of.
The auditor asked one question: "Show me that the code deployed to production on 14 March was reviewed by someone other than the person who wrote it."
Long pause. Everyone knew the answer was yes. Nobody could produce it.
That gap, between a control that genuinely works and a control you can prove worked, is where most first-time SOC 2 audits burn six weeks they did not budget for. I have watched it happen at companies with far better engineering hygiene than the average. It has almost nothing to do with how secure you are.
Here is what auditors actually ask, in the order they ask it, and what satisfies them.
1. Who can push to main, and how do you know?
The control is separation of duties. The evidence is your branch protection configuration plus a population of merges over the audit window.
What auditors want to see:
- Branch protection on your default branch, with required reviews set to at least one
- Force-push and branch deletion disabled
- Admin bypass either disabled, or enabled with an alerting trail for every use
That last point is where teams lose. Almost every repo has one or two people with admin override, because at some point production was down at 2am and somebody needed it. That is fine. What is not fine is having no record of when it was used.
Turn on the audit log export before your window starts. On GitHub that is Organization settings, then Audit log, then streaming to your log destination. If your observation window has already started and you did not have it on, you cannot retroactively create it, and you will be writing a management response explaining a gap instead.
2. Can a change reach production without passing your gates?
Auditors are testing whether your pipeline is the only path to production. Almost always, it is not.
The usual culprits:
- A manual deploy script that someone still has on their laptop
- Direct console or CLI access to the production cluster
- A hotfix workflow that skips the test stage by design
- Infrastructure changes applied by hand outside Terraform
None of these are automatically findings. A documented emergency change procedure with post-hoc review is an entirely acceptable control. An undocumented one that three engineers know about is a finding.
Write the emergency path down. Say who can invoke it, what approval it needs after the fact, and where the record lives. That one paragraph closes a control most teams fail on.
3. Show me a change from ticket to production
This is the walkthrough, and it is where the eleven-minute failure happens.
The auditor picks a date, usually at random, from your deploy history. You need to link, for that one change:
- The ticket or issue describing the change
- The pull request implementing it
- The approval, by a different human
- The passing test run
- The deployment record with a timestamp
Five artifacts, four systems. If your ticket IDs are not in your commit messages or PR titles, you are going to be reconstructing this by hand, per sample, for however many samples the auditor pulls.
The fix costs about twenty minutes. Add a commit message convention that includes the ticket ID, and enforce it in a pre-merge check. Every subsequent sample becomes a two-link lookup instead of an archaeology project.
4. What happens when a dependency has a critical CVE?
Auditors are not asking whether you scan. Everyone scans. They are asking what happens next.
The control they are testing is vulnerability management, and it needs three things you probably have not written down:
- A severity threshold that triggers action
- A remediation window per severity
- Evidence that you met the window, or documented why you did not
"We use Dependabot" is not a control. "Critical findings are remediated within 7 days, high within 30, tracked in our issue board with the security label, and reviewed monthly" is a control. The tooling is identical. The difference is entirely in whether you defined the policy before the auditor asked.
The pattern underneath all four
Every one of these is the same shape. The engineering practice is already sound. What is missing is the artifact that proves it was sound on a specific date to someone who was not in the room.
That reframing matters, because it changes what you spend your pre-audit time on. Teams tend to assume they need to build new security controls. Mostly they need to make existing controls legible. Configuration exports, audit log retention, a naming convention, a two-paragraph policy document.
The teams that clear a first SOC 2 in ninety days rather than seven months are almost never the more secure ones. They are the ones who set up their evidence collection before the observation window opened rather than after it closed.
Practical sequencing
If you are three to six months out from your first audit:
Now: turn on audit log streaming and set your log retention to cover the full window plus a margin. This is the only item on this list that cannot be fixed later.
This month: write the four documents. Change management, emergency change, vulnerability management, access review. Two pages each is plenty. Auditors read them for existence and coherence, not literary quality.
Next month: run a self-sample. Pick three random deploys from the last thirty days and try to assemble the five artifacts yourself. Whatever takes more than five minutes is what will cost you weeks in the real audit.
Ongoing: do your quarterly access review and actually date it. Undated access reviews are the single most common finding I see, and the single cheapest to avoid.
I lead the vCISO practice at IRM Consulting & Advisory, where a good share of the work is walking SaaS engineering teams through exactly this sequence before an auditor is in the room. Our approach to embedding security into delivery pipelines is here: https://irmcon.com/devsecops-dso/
If you are specifically scoping a first SOC 2, we publish the readiness detail at SOC 2 readiness for SaaS.
What is the control your team found hardest to evidence rather than hardest to implement? I am genuinely curious whether the pattern above holds outside the companies I have worked with.
Top comments (0)