Engineers heading into a first SOC 2 often imagine it as a giant code audit. It is mostly not that. SOC 2 is an attestation against the Trust Services Criteria, and the bulk of those criteria are about policies, processes, and evidence that controls operated over a window. Only a slice is decided by what your code does, and knowing which slice makes the whole thing less mysterious.
The criteria that touch code
The code-facing criteria cluster in the CC6 common-criteria family for logical access: CC6.1 restricting access to what a role needs, CC6.6 protecting against threats from outside the system boundary, CC6.7 protecting data in transit and its movement, plus CC7.2 for monitoring and CC8.1 for change management. If you can reason about who can reach what, how data is protected in transit, and what gets logged, you are reasoning about most of the code-facing surface of SOC 2.
Notably, a lot of what feels SOC-2-ish in engineering (code review existing at all, change approvals, access reviews) is evidence that a process operated, gathered outside the code. The code itself mostly speaks to the CC6 family.
The exceptions that become findings
An auditor samples these controls over a window and writes an opinion. A single pull request that widens an IAM role to a wildcard, or drops a TLS floor, can create an exception in that window: the control may not have operated as described for that change. Caught at the PR, it is a one-line fix. Caught in the audit, it is a remediation with a paper trail.
That asymmetry is the whole argument for checking the CC6 surface at the diff rather than discovering exceptions months later.