SOC 2 — We Do It to Ourselves - by Adam Ard

SubscribeSign in

SOC 2 — We Do It to Ourselves<br>A developer's guide to SOC 2 Compliance

Adam Ard<br>Apr 08, 2025

Share

If your SOC 2 compliance requirements seem excessive, you only have yourself to blame.<br>That’s the dirty little secret of SOC 2 compliance that management hasn’t been so eager to explain. Most developers imagine there are evil compliance officers breathing down the company’s neck, forcing it to lock everything down. They assume that long ticket queues, deployment request forms, and code review requirements are all part of some SOC 2 rulebook.<br>If you’ve ever complained, you’ve probably gotten the standard reply: "We can't do anything — it’s a SOC 2 compliance issue."<br>But the truth is, there is no SOC 2 rulebook. There are no external compliance officers. SOC 2 isn’t a list of mandatory tasks like a regulation. It’s a framework where you write your own rules and prove you follow them. Of course, they need to be reasonable enough to pass audit scrutiny. But the organization chooses the rules — not some outside body.<br>So if controls are overly rigid and painful, it’s because the company chose to make them that way. They’re the ones tasked with creating the controls.<br>The pain is self-inflicted.

Who Really Makes the Rules?

At big companies, there may be dedicated security and compliance professionals. They might even call themselves compliance officers, but don’t be confused — they work for your company, not a regulatory body.<br>In smaller organizations without dedicated compliance professionals, the task of choosing and maintaining SOC 2 compliance rules normally falls to the Ops, DevOps, or Platform engineering teams.<br>Regardless of who inside the company is setting the rules, one thing is certain: the company itself is in charge, not the SOC 2 auditors.<br>And you don’t have to take my word for it.<br>While some security frameworks like ISO 27001 and PCI DSS have rigid requirements, that isn’t the case with SOC 2.<br>Controls and attestation reports are unique to every organization.<br>Each company designs its own controls to comply with its Trust Services Criteria.<br>An independent auditor is then brought in to verify whether the company’s controls satisfy SOC 2 requirements.<br>After the audit, the auditor writes a report about how well the company’s systems and processes comply with SOC 2.1

… organizations are given full autonomy over which TSC they develop controls for as well as what those controls consist of.2

Another thing is certain, developers aren’t being consulted when compliance controls are designed—even though compliance controls directly effect their daily workflows.<br>This needs to change.

Principles for Developer-Friendly Compliance

How do we escape this bureaucratic mess and build developer-friendly compliance?<br>The way out is to design systems around better principles. Here are five that can help recalibrate an otherwise overly restrictive set of compliance practices.

Principle 1: Better Defaults

Some operations teams default to zero access, forcing developers to request every single permission individually — a tedious, frustrating, and unnecessary mode of operation.<br>All developers on a team typically need the same permissions. It’s much more efficient to grant those permissions as a block, upfront, for every member of the team. They’re going to be approved eventually, so you might as well save yourself from fielding a dozen tickets just to get someone onboarded.<br>Better defaults also empower discovery. Developers can see what’s available, experiment, and move faster without waiting in line for approvals.<br>Another smart default is granting better access to CI/CD systems. Without proper access, it’s nearly impossible for developers to build, debug, and tune their pipelines.

Principle 2: Sandboxed / Prototyping Environments

Developers need environments where they can safely explore, experiment, and learn — with real access to cloud services, infrastructure definitions, and deployment tooling.<br>Give developers direct access to Terraform files, Kubernetes manifests, and CloudFormation templates. Let them prototype infrastructure changes in dev environments without gatekeeping. Not every change must be fully polished in every iteration and prototypes are part of the learning process.<br>Formal reviews can wait for when changes move to production — after developers have had the chance to spin up resources and see how they work. Later, when they’ve formalized their work into a pull request, ops engineers can review the cloud configurations they create.<br>Developers who have full control in dev environments write better, safer production systems — and you avoid turning every infrastructure change into a ticket queue nightmare.

Principle 3: Avoid Unnecessary Abstractions

Every time you wrap an API in a bespoke internal tool, you add latency and risk.<br>Internal wrappers over cloud APIs might seem helpful — adding guardrails, simplifying complexity — but too...