What a SOC 2 audit actually checks

SOC 2 has a reputation for being a paperwork exercise. It is not, but it is also not the technical gauntlet that engineering teams imagine. After taking a dozen companies through Type II audits, the pattern is consistent: the time goes into evidence, and the evidence comes from a small number of controls that most teams half-implement.

The audit is about evidence, not opinions

An auditor does not judge whether your architecture is good. They check that you said you would do something, that you did it for the whole observation window, and that you can prove it. A control you run perfectly but cannot evidence is, for audit purposes, a control you do not have.

That changes how you build. Every control should produce its own record as a side effect of running. Access reviews that happen in a script leave a log. Changes that go through pull requests with a required reviewer leave a trail. Backups that restore on a schedule leave a timestamp. Spreadsheets that people fill in on Friday afternoons do not survive the first sample request.

Where the findings come from

Across the audits we have supported, five control areas produce most of the exceptions:

1. Access reviews. Quarterly reviews that were not performed, or were performed without evidence that departed staff were removed on time.
2. Change management. Production changes without a reviewer, or infrastructure changed by hand outside the pipeline.
3. Vulnerability management. Critical findings older than the policy allows, usually because nobody owned the scanner output.
4. Logging and monitoring. Logs that exist but are not reviewed, or alerts that fire into a channel nobody reads.
5. Vendor management. Vendors with access to customer data who were never assessed.

None of these are hard. All of them require someone to own them for twelve months.

What a Type II observation window really means

A Type I report says your controls were designed properly on a date. A Type II says they operated for a period, usually six to twelve months. Customers ask for Type II. That means the clock starts when the controls are in place, not when you decide to pursue the audit. If a renewal depends on a report in nine months, you need the controls running in month three.

The three things to do first

If you are starting from a failed readiness review, start here:

• Enforce MFA on every account and remove shared admin credentials. This closes the largest category of findings in one week.
• Put infrastructure changes through code with a required reviewer. Terraform, a pull request and a branch rule give you change management for free.
• Centralize logs and assign one person to review alerts daily, with the review recorded.

Then build the rest in priority order from a posture assessment. The security snapshot on our Cybersecurity page takes five minutes and tells you which function to start with.