"That's not SoC 2 compliant"
This article debunks the common misconception that SOC 2 compliance strictly requires using pull requests for code changes. It details how the author's company, Amp, maintains continuous delivery and auditability through a tailored risk-management approach without PRs. This resonates with HN's audience by challenging industry norms and offering a practical, alternative workflow for compliance.
The Lowdown
The author addresses a frequent reaction to their company's 'no pull requests' workflow: the assertion that it isn't SOC 2 compliant. They argue that this assumption is incorrect, as SOC 2 doesn't mandate specific tools but rather requires a thorough consideration of risks and the implementation of appropriate controls. The article then outlines their compliant alternative:
- SOC 2 compliance centers on identifying and managing risks, not on specific tools like
gitpull requests. - Amp ensures compliance through a system of controls, including restricted push access to
main, mandatory signed commits, and a robust automated CI pipeline that includes extensive validation and security checks. - Their audit trail links commits directly to internal discussion threads, providing comprehensive context beyond just code diffs, satisfying the need for authorized, tested, approved, and recorded changes.
- The author clarifies that SOC 2 criteria do not explicitly demand a 'second human to stare at a diff' (i.e., traditional code review).
- While acknowledging this approach benefits their small, high-trust team, the core message is to apply a 'think about your risks' mindset universally, tailoring processes to the actual risk level of each system rather than enforcing a one-size-fits-all solution.
The piece concludes by encouraging organizations to scrutinize the risks their current processes, like pull requests, are truly managing and to explore alternative, equally compliant methods of mitigation.