Amp passes SOC 2 without pull requests
Amp has never used pull requests, a choice the company says it made from its first commit so it could ship continuously. In a post dated August 13, 2026, engineer Will Dollman writes that the most common reaction to Amp's public posts about its way of working is disbelief that this is even allowed under SOC 2, the security compliance framework many enterprise customers require of their vendors.
So when Amp started working toward SOC 2 certification, it put the question directly to its auditors: do you need pull requests for that? The answer, as the post reports it, was no. SOC 2's Trust Services Criteria never mention git or pull requests by name; they require that changes be authorized, tested, approved and recorded, and a pull request is only one way to satisfy that. The auditors did not ask Amp for PRs. They asked what Amp's change process actually was, then worked with the company on a set of controls that fit it.
Amp lists four controls it landed on. Restricted push access ties who can push to main to business function, on the reasoning that the percentage of staff with access matters less than being able to name exactly who has it and why. Signed commits, enforced by GitHub on main, make commit authorship verifiable rather than just metadata a pusher could fake. Automated CI runs every change through the full validation pipeline, tests, infrastructure checks and security checks, and blocks main on failure. Finally, an audit trail links each commit to the Amp AI-assistant thread that produced it, so the record covers the reasoning behind a change and not just the resulting diff, with CI/CD then tracking the path from commit to deployment. Notably absent from the list is code review: the post states plainly that the Trust Services Criteria do not require a second human to look at a diff.
Dollman is explicit that this is not a universal fix. Amp is 20 people, mostly engineers, all close to the code, and the company frames that closeness and high trust as an advantage it is not willing to trade away for process it does not need. He does not claim the same setup would work at a 2,000-person company, used in the post purely as a contrasting example of scale, and he acknowledges that Amp ships customer-facing production software, a genuinely risky category of code. His broader point is that risk is not uniform across a company: plenty of code at large organizations carries less risk than that, yet gets routed through the same review process calibrated to the organization's scariest system. What he argues does scale is asking what risk a given control is actually managing for a given system, rather than assuming pull requests are the only way to manage it.
Key facts
- Amp has skipped pull requests since its first commit and pushes straight to main to keep shipping continuously.
- Amp's SOC 2 auditors told the company the standard requires authorized, tested, approved and recorded changes, not pull requests specifically; the Trust Services Criteria never mention git or PRs.
- The four controls Amp uses instead: push access restricted by business function, GitHub-enforced signed commits, automated CI that blocks main on failed tests or security checks, and an audit trail linking commits to the Amp threads that produced them plus CI/CD deployment records.
- Code review is not among the controls; the post says the criteria do not require a second person to review every diff.
- Amp is a 20-person, mostly-engineer team and says the same approach would not suit a much larger organization; it frames risk assessment, not any fixed process, as what scales.
Why it matters
The post pushes back on a common assumption that SOC 2 mandates pull-request-based code review. Amp's account of its audit shows the standard's Trust Services Criteria care about outcomes, authorized, tested, approved and recorded changes, and stay silent on the specific tooling or workflow used to get there. That reframes SOC 2 for engineering teams as a set of properties to satisfy rather than a checklist that assumes GitHub's PR model.
Who it affects
Small, high-trust engineering teams, particularly startups pursuing SOC 2 certification for the first time while wanting to preserve a fast, direct-to-main workflow. Amp names itself as a 20-person, mostly-engineer company shipping customer-facing production software.
How to use it
Amp's four substitute controls: restrict push access to main by business function and be able to name who has it and why; enforce signed commits on main via GitHub so authorship is verifiable; run every change through automated CI covering tests, infrastructure checks and security checks, blocking main on failure; and keep an audit trail linking each commit to the Amp thread that produced it, with CI/CD recording the path from commit to deployment.
How solid is it
The account comes from Amp's own engineering blog, written by Will Dollman and published August 13, 2026, describing the company's own conversation with its own auditors. It names no auditing firm and gives no date for when certification was granted or expected, only that Amp was working toward it. There is no independent or third-party confirmation in the source.
Risks and caveats
Amp is explicit that this is not a general recipe. It attributes the setup to being small, 20 people, mostly engineers, with everyone close to the code, and says outright that it would not expect a 2,000-person company to let everyone push to main. Dropping code review specifically rests on that closeness and trust, and the post frames calibrating controls to actual risk, not the removal of pull requests or review as such, as the part meant to generalize.
“SOC 2 doesn't require pull requests. It requires that you think about your risks.”
— Will Dollman, Amp