It depends what’s in scope and the control being evaluated. For example, if your SDLC/release and infrastructure processes the environment(s) that are built from them are in scope of your SOC2 audit, then a change to the code deployed to the in-scope environment must meet a defined policy for change control. Auditors aren’t eager to accept “there is no SDLC,” or “our change control policy is to deploy to production whenever.”
A lot of SOC2 is hand waived as paperwork, but the point is that an organization (and their independent auditor) can show evidence that they have established certain processes and controls, and that they can demonstrate compliance with their word. (This belies the tension that some use to discredit independent auditors: that the client pays the auditor for their report. What’s less well understood is that the auditor has a much greater vested interest in being honest, and that they’re going to get questioned if a matter ever goes to court. No one client is worth losing the entire firm. There are, of course, bad auditors just as there are bad developers, admins, accountants, etc.)
I spent time working in compliance and led the inaugural SOC2 Type 2 audit at a household name. These days I spend my time primarily on infrastructure.