SOC 2 — We Do It to Ourselves
A developer's guide to SOC 2 Compliance
If your SOC 2 compliance requirements seem excessive, you only have yourself to blame.
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.
If you’ve ever complained, you’ve probably gotten the standard reply: "We can't do anything — it’s a SOC 2 compliance issue."
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.
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.
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.
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.
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.
And you don’t have to take my word for it.
While some security frameworks like ISO 27001 and PCI DSS have rigid requirements, that isn’t the case with SOC 2.
Controls and attestation reports are unique to every organization.
Each company designs its own controls to comply with its Trust Services Criteria.
An independent auditor is then brought in to verify whether the company’s controls satisfy SOC 2 requirements.
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.
This needs to change.
Principles for Developer-Friendly Compliance
How do we escape this bureaucratic mess and build developer-friendly compliance?
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.
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.
Better defaults also empower discovery. Developers can see what’s available, experiment, and move faster without waiting in line for approvals.
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.
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.
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.
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.
Internal wrappers over cloud APIs might seem helpful — adding guardrails, simplifying complexity — but too often they just create hard dependencies on the operations team. Developers get locked out of directly configuring infrastructure. And when cloud providers release new features, you lag months behind because your wrapper hasn’t caught up.
Good abstractions empower developers. Bad abstractions create dependency loops. The best approach is to give developers direct access to manifests and configuration, with clear policy guidance, rather than hiding everything behind custom tooling. Native manifests and configurations are already auditable. That’s as far as you need to go.
Unnecessary abstraction is unnecessary complexity.
Principle 4: Favor Visibility Over Restriction
Restricting access might feel safer, but it often does the opposite.
Visibility is a better security posture. Open systems let developers understand how things work, spot problems early, and contribute to improvements. It’s the same principle that makes open source software often more secure than closed systems: more eyes, fewer surprises.
Defaulting to locked-down, opaque systems hides risks and slows down diagnosis when things go wrong. Instead of "security through obscurity," aim for transparent systems with auditable logs and clear visibility into operations.
Allowing all code repos to be at least readable by anyone in the organization, for example, makes it hard for nefarious code to see the light of day. It also makes it easy for all developers to check and contribute to each other—a requirement for any high functioning software organization.
Principle 5: Interim Controls
The road to automation is long. But that doesn’t mean you have to live in ticket hell while you're trying to get there.
Most ops teams agree: the best solutions use self-service and automation. This is typically their long-term goal. But ops teams often get so overwhelmed with their near-term manual processes that they never get around to their automated end goals. Manual access approvals, manual deploy reviews, manual evidence collection — they devour the time and energy that could have gone toward building a better solution.
Be careful to design interim controls that are not only sufficient from a compliance viewpoint, but that also don't take up all your time.
For example: use templated requests that reduce manual decision-making. Grant permissions in blocks (see Principle 1). Let devs manage their own CI/CD pipelines. Do whatever you have to to avoid getting buried under a mountain of Jira tickets.
Trust that auditors will accept these interim solutions in light of your long-term goals.
Don’t accept the false choice between painful manual processes today and full automation someday (a day that may never comes). There’s a temporary middle road that can get you to your goal faster.
Yes, You Can Change SOC Controls (And You Should)
Here’s another dirty little secret: SOC 2 controls are not set in stone. Despite what they may say at your company, you can absolutely change them. In fact, mature companies revise their controls all the time as they automate processes, improve risk posture, or grow out of old startup-era hacks.
If management says, "We can't fix that because of SOC 2," when confronted with a poorly designed control, you can (and should) reply: "Then it’s time to fix it."
If you switch from manual approvals to automated pipeline enforcement, you haven’t weakened your posture — you’ve improved it. Good auditors know and accept this. They care about outcomes, not ceremony. There is nothing sacred about your first attempt at defining controls. What matters is getting it right eventually.
If you’ve inherited bad controls? Change them!
If a policy is crushing your developers? Replace it!
Your controls are yours to define.
If you don’t take charge of improving your controls, you’ll be stuck living with someone else’s bad decisions forever.
Developer Action
If you’re a developer, and you’ve felt powerless to push back against excessive bureaucracy, hopefully this essay has made you feel more empowered.
You should feel comfortable challenging a painful status quo. Push back against:
Controls that are more performative than useful.
Ticket queues and approval bottlenecks.
Manual processes.
The lack of sandboxed environments.
Wrappers around available cloud tools.
Opaque systems.
Treat compliance design as an engineering responsibility. Good compliance should feel like good engineering: reliable and low-friction.
Your company wrote the rules.
Now make them write better ones.
Disclaimer:
This post reflects my personal opinions and experiences and is not legal or compliance advice. Always consult with your own legal counsel and auditors when making decisions about your compliance strategy.