SOC2 requires basically nothing beyond that you follow the procedures that you say you're going to follow. The relevant text of CC8.1 is:
> The entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives.
You'll note that this doesn't actually say much of anything.
It's very common for companies which are working on SOC 2 compliance to write down that all changes will be reviewed and once you do that you're required to actually follow through and do it, but you don't have to write down that all changes will be reviewed. The point of SOC2 is mostly that if you are vibing slop into production you have to document that fact (or rather, document your lack of change controls that make it possible) and so your customers can be aware of that. Large conservative customers may insist on more rigid processes as a condition of buying from you.
> The entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives.
You'll note that this doesn't actually say much of anything.
It's very common for companies which are working on SOC 2 compliance to write down that all changes will be reviewed and once you do that you're required to actually follow through and do it, but you don't have to write down that all changes will be reviewed. The point of SOC2 is mostly that if you are vibing slop into production you have to document that fact (or rather, document your lack of change controls that make it possible) and so your customers can be aware of that. Large conservative customers may insist on more rigid processes as a condition of buying from you.