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

Every company is different, with different risks but here is the change management i have implemented successfully.

Minor, medium, major change category depending on potential impact with documented guidelines when each apply.

First release of a service always recommend to be major. (They are few vs daily changes and can be redtaped more to get many stakeholders requirements. Functional and non functional) Author of the change and his team decide the category.

- Minor need one more reviewer outside author. Team decide everything.

- Medium need min one more, and usually QA team or other affected team.

- Major change need CAB meeting with all major stakeholders to sign off.

CAB is responsible for the process and high level monitor the program, see if any cheating goes on, performance metrics such as number of changes per category etc. Help support people what could be considered minor vs major changes.

Overall rel flexible and balanced. Pushes people towards making smaller changes with less risk and at the same time increase velocity while still protect reasonable against bad actors, mistakes etc.

It is not perfect, medium changes tends to be more difficult to coordinate, some changes are missclassified etc but that is okey. It is not only about the process, communication matters and ci/cd have to be robust etc.

This balanced approach works for many.

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.

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.

Engineers often over-think compliance. SOC2 is regulatory capture, and an audit that tests your controls. You define the appropriate controls. As long as you do what you say you're going to do, you should pass the audit. It's not rocket science. It's a feature of a correct system that it is auditable. How easy it is to audit is really a function of your maturity. SOC2 and its ilk such as ISO27001 are just maturity signalling mechanisms. Stop overthinking it or applying black and white rules -- in actual practice its always shades of grey and most auditors are just happy to have an engaged and switched on team to be auditing, vs someone who treats it as adversarial. You're paying them!

> 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?

Does there exist any tool to analyze PR feedback quality and usefulness?

I've been trying to explain to compliance employees that if the majority of PR reviews anyway is just "LGTM - Just merge" (I don't care), what's the actual value of PRs? It's just facade.

On a different note, we're looking into artifact attestations and admissions through Sigstore, which is solves many of the same challenges but through different means.

Soc2 is pointless.

But how do they review each other's work? Prs are indispensable for collaboration...

there goes the neighborhood

So an engineer who knows your codebase and tests can sneak in malicious code/backdoors because you're high trust.

And I am guessing you'll extend that high trust to your agents/'orbs' next. And I am sure you'll find an auditor who'll go with it coz frankly most don't care.

I am not surprised there are folks willing to do this, but I am surprised that you feel you must brag about it. And you ARE bragging when you title the post the way you did. Good luck.

AICPA should have spent 5 seconds on a web search to find out that SoC means System on a Chip, and chosen something else.