That's not SOC 2 compliant

Amp, a 20-person software company, has achieved SOC 2 compliance without using pull requests, a practice its auditors confirmed is not required by the standard. The company's controls include restricted access to main, verified commit authorship, and a documented change process, demonstrating that SOC 2 focuses on risk management rather than specific workflows. Amp's approach highlights that pull requests are just one way to meet compliance criteria, and companies can tailor controls to their size and risk profile.

Will Dollman//August 13, 2026 We’ve been sharing more about how we work: building Amp with Amp, orbs /manual/orbs , killing features, no pull requests. And the most common reaction isn’t about the AI workflows or whatever kind of ~~loop~~ graph engineering is flavor of the week. It’s this: Wait, you don’t use pull requests? You push to main? How? That’s not SOC 2 compliant. Except it is. Skipping pull requests was a deliberate choice from the first commit. It’s a big part of how we build /notes/pave-the-road and why we can ship continuously. So when we started working toward SOC 2, we took that question straight to our auditors: “you need PRs for that… right?” SOC 2 doesn’t require pull requests. It requires that you think about your risks . That’s the real answer we came away with. Auditors, and SOC 2 itself, are more flexible than you might assume. Ours didn’t ask us for pull requests; they asked what our change process was, and worked with us on a set of controls that fit it. The Trust Services Criteria never mention git or pull requests. What they ask for is that changes are authorized, tested, approved, and recorded — and pull requests are just one way of doing that. Here are the controls we landed on: main follows business function: every engineer at Amp can push, and most of Amp is engineers. But the percentage of people with access matters less than being able to explain exactly who has it and why. main , which makes the author on every commit verifiable. main .None of this is exotic. But it isn’t the standard process with a step deleted, either. It’s a system designed on purpose, and it gives an auditor the same thing a PR workflow gives them. And no, code review isn’t on the list. The criteria don’t say a second human has to stare at a diff. We’re 20 people, mostly engineers, and everyone is close to the code. Being small and high-trust is our advantage, and we aren’t going to give it away for a process we don’t need. When writing code is fast, slow process becomes what you’re actually waiting on. But we’re not going to pretend a 2,000-person company should let everyone push to main. What does scale is think about your risks , because risk isn’t uniform inside a company either. Amp is customer-facing production software, and we ship it this way. Meanwhile, plenty of code at bigger companies carries less risk than that, yet every change goes through the same process, calibrated to the scariest system the company runs. And you don’t have to overhaul the whole company to fix that. Pick one system and ask: “What risks are our pull requests actually managing here?” Then ask how else you could manage them. The answer doesn’t have to be pull requests.