Because the code is written in pairs, there’s two pairs of eyes on all code. I’m not familiar with SOC 2 specifically, but that’s sufficient for other security controls I’ve seen.

The purpose of this review is to create consistency across their large number of services. It’s really just a convoluted way of using GitHub’s PR system rather than doing a diff and talking it over.

Personally, I think it’s overly complicated, but I think the root cause of that complexity is having over 40 microservices owned by a single team, each in its own repo. It’s resulted in a lot of boilerplate, aka duplication, that they might be able to factor out if they used a monorepo. (Or a modular monolith.)

What happened to curiosity for finding secure ways to push workflows forward? People said the same things before continuous deployment caught on and now that's common enough and definitely SOC 2 capable.

I believe it's doable with production rollout controls that limit customer exposure to the code changes and the code's access to data (possible these days with things like pg row level security controls, and blue/green routing etc. - already valuable practices), and ensuring the batch code reviews happen before customer rollout. Even with these controls and incremental rollout, there is tremendous benefit to getting the code deployed into production environments and enabling this review workflow. The point then is to satisfy remaining security controls while in production, under these type of controls.