Skipping Pull Requests Isn't Un-SOC 2 Compliant
"That's not SoC 2 compliant"
Amp, a 20-person engineering team, ships continuously by pushing directly to main, skipping pull requests entirely. When pursuing SOC 2, they discovered the framework doesn't mandate PRs—it requires managing risks. They worked with auditors to design controls like restricted push access, signed commits, automated CI, and a detailed audit trail. This approach scales not by size but by risk assessment, challenging the assumption that PRs are essential for compliance.
SOC 2 doesn't require pull requests. It requires that you think about your risks.
- aleda145
This stance is a breath of fresh air. In my experience change management is the first thing to slap on when a bad release happens.
I've worked at a large enterprise that have a "Change Advisory Board", that you need to convince when you want to bump the major version on your linter. It has the effect of velocity slowing down to a crawl. Changes have to large, since otherwise it wouldn't be approved by the CAB. A slow mess.
At my current place we have to loudly declare "I CONFIRM COMPLIANCE" in every PR description. I'm not sure that anyone knows why, but it keeps the bureaucrats happy. Shrug
- jpollock
I was in a high trust environment that didn't use dual auth on some things. They lost $250k to embezzlement.
High trust is high trust until someone exploits it, and the likelihood of encountering an exploit (embezzlement, fraud, political speech, etc.) approaches 100 as the total number of staff hours increase.
- abofh
Youre required to have a policy. That policy may be throwing bananas at the wall, but if it's documented and you follow it, you're compliant with policy.
- 6ty6thhDJEHDE
This is easy for Amp Code to do but not so easy for other people with different types of businesses.
I started at a business doing millions of customer transactions worth 100s of millions of dollars and their whole process was a complete YOLO Playground. As a result they lost money, people (it is high stress if everything breaks all the time) and most importantly: customer confidence.
What brought back some sanity? The basics for a mature business: deployment reviews and approvals, removing prod access, code reviews, QA in the loop. Release notes. All these things come up in audits. In SOC1 because the customer wants assurances, in SOC2 because we need to show prospects that we are serious and mature enough to get their business.
Please don't think it is just theatre. If you get away with bending the rules to the bare minimum to get a checkmark then good for you and all the power to you.
But if you are running a business where you are dealing with critical systems, PII, customer data, money, etc. Well maybe being very strict about having good change management policies in place will actually help you mature.
That maturity will also allow you to get customers. Because guess what, most customers who are going to trust you with their business have some expectations about how you run your ship.
I wish my company was as "simple" as Amp. No disrespect, I love what they do. But it doesn't really look like the kind of business where you get in serious trouble for using a minimal proc […]
- swiftcoder
> What they ask for is that changes are authorized, tested, approved, and recorded — and pull requests are just one way of doing that.
I'm pretty unclear how approvals are ensured in your system?
Authorisation and recording are pretty much out-of-the-box with a version control system, CI can guarantee testing, but how are we demonstrating approval without any evidence of change reviews?