Startup demonstrates SOC 2 compliance without pull requests or code review

Amp’s SOC 2 compliance demonstrates that the standard’s Trust Services Criteria do not prescribe specific tools or workflows. The criteria require controls for change authorization, testing, approval, and recording, but leave implementation open. Pull requests are a common solution, but Amp’s auditors accepted an alternative system built around signed commits, restricted push access, and automated CI. This flexibility is often overlooked in engineering teams, where SOC 2 is assumed to mandate rigid processes like pull requests or mandatory code review.

The controls Amp adopted are not exotic but are designed to match its risk profile. Restricted push access ensures only authorized engineers can merge changes, while signed commits verify authorship beyond Git metadata. Automated CI acts as a gatekeeper, blocking changes that fail tests or security checks. The audit trail links commits to internal discussion threads, providing context beyond a diff. These controls satisfy SOC 2’s requirements without the overhead of pull requests, but they rely on a high-trust, small-team environment where engineers are close to the code.

Scalability is the primary limitation of Amp’s approach. The system works for a 20-person team where most members are engineers and trust is high, but it may not translate to larger organizations or teams with lower trust. However, the principle of risk-based controls can scale: not all code carries the same risk, and processes can be calibrated to the system being changed. Amp’s example suggests that even in larger companies, teams could adopt lighter processes for lower-risk code while maintaining stricter controls for critical systems.

The trade-off between process overhead and compliance is central to this case. Pull requests add friction, which can slow down development, but they also provide a familiar structure for auditors. Amp’s alternative reduces friction but requires more deliberate design and higher trust. For teams considering a similar shift, the key question is whether the risk profile of their code justifies the overhead of traditional processes. If not, SOC 2’s flexibility allows for alternatives, provided the controls are documented and auditable.