SOC 2 from the DevOps Angle: Why Your Infrastructure Engineer Is Your Best Compliance Lead

When leadership announced we were pursuing SOC2, the first idea was the same every company has: hire a compliance consultant. Still, as a DevOps Engineer, I realised straight away that almost every control the auditor or readiness consultant were going to ask about lived in systems I already owned.

Access reviews? That’s our IAM and authentication directory. Change management? It lives in our CI/CD. Encryption at rest and in transit is reflected across our networking and configuration management. Logging and monitoring? Our observability stack. Vulnerability management? Already was on my plate as the common security exercise.

So instead of assisting in SOC2, I decided to own it. And this is the story of taking a company with hybrid infrastructure through a full SOC2 Type II audit, and why I’ve come to believe DevOps is the most viable owner and facilitator for this journey, not just a contributor to it.

SOC 2 is an infrastructure audit wearing a trust costume

If we strip away all the compliance acronyms, we’ll find out that under the hood SOC2 asks one simple question: Can you prove that your systems can do what they claim they do? And in case of Type II audit, add “over time” to this question.

Take a look at the SOC2 Common Criteria (CC) and count how many map to infrastructure:

• Logical and physical access controls;
• System operations;
• Change management;
• Control and monitoring activities.

The vast majority of the evidence an auditor requests is configured in or exported from systems that DevOps engineers administer daily. And here’s an example. While a compliance manager can only describe your change management process, a DevOps engineer will evidence exact branch protection rules, required PR approvals, CI guardrails blocking unreviewed code from reaching the production, and then pull 3-6 months of Git merge history to prove that these rules never got bypassed. And so it happens for a lot of other criteria.

As a rule, the industry treats compliance as paperwork that happens on top of engineering. But, my experience was the opposite: compliance done well is engineering. And if you worked with infrastructure-as-code, you should already know the mental model. The whole workflow maps onto the loop you run every day.

Declare the desired state. In IaC, that’s your Terraform/Pulumi or Ansible definitions. In SOC2, it’s the Trust Services criteria translated into configurations: MFA enforcement, datastore encryption, review on production changes. These criteria are your manifest declaring why your infrastructure is compliant.

Enforce it automatically. In IaC, you avoid manual configuration across your clouds and servers. Same principle applies here: Trust platforms like Drata (expanded with your tooling for parts of your infra they cannot reach) become the apply layer to reconcile reality against the declared state.

Detect drifts. This part actually makes your SOC2 posture survivable. Infrastructure also drifts from an initial manifest if, for instance, someone opens a security group “temporarily”, leaves an account of an offboarded contractor active or ships an S3 bucket without encryption. In IaC, you catch such drifts via state diffs, and in compliance you catch it with continuous monitoring that flags the moment reality deflects from the compliant baseline. It’s always better to catch a drift rather than discover it while collecting evidence: this is the difference between a silent fix and an audit exception.

Once I looked at SOC2 through this lens, the entire exercise stopped feeling like a frontline. At the end of the day, we just come to a reconciliation loop, and this is what DevOps engineers have been running for a decade – just under different labels.

What Drata actually did (and what it absolutely didn’t)

I briefly mentioned Drata above – that was the compliance automation platform of our choice. It was a vital step due to very limited engineering capacity, and here I need to be straightforward about what we achieved with it.

What Drata genuinely delivered:

• Continuous monitoring across our cloud accounts and SaaS tools;
• Automated evidence collection for everything having API integration;
• Daily automated checks: MFA enforcement, encryption settings, overly permissive roles and accounts, personnel on- and offboarding, etc.;
• Policy templates that saved us weeks of drafting.

This all justified the cost and made the compliance journey swift and automated: we got a single place reflecting our resulting compliance manifest and current control status – that’s what I meant earlier under drifts.

What it did not do: Drata did not design our controls, integrate into bare-metal or on-premise environment, or make a single judgement call. In fact, every non-integrated system needed either custom integration coding or manual evidencing on schedule I had to build and maintain. Also, Drata only told me a control was failing: deciding why and what to change architecturally was still my job.

All in all, I’d frame Drata as monitoring and evidence layer: think about it as your observability stack for compliance. Nobody thinks Splunk runs an infrastructure, it watches it. Someone still has to be an engineer behind this, and if that engineer isn’t driving the compliance workflow, the platform becomes another expensive dashboard with red checkmarks.

The part nobody warns you about

I think this section and the next one will be the most interesting for other DevOps engineers tasked with the same exercise.

While I really like the idea that DevOps engineer is everything you need to achieve and maintain your SOC2 certification, there are still few things that caught me personally off-guard.

First, evidence hygiene is harder than initial control implementation. Enforcing MFA takes a couple of hours. But, proving that MFA was enforced for every user across every system for 3 straight months requires discipline you have to design for on day one.

Second, people are the most sensitive component of your compliance posture. My hardest controls weren’t technical, they were ones requiring human beings to do things over time: complete trainings, sign and confirm policies, drop unnecessary access. On top of this, here comes interaction with vendors during their reviews. But, all of this is rather a matter of soft skills and leadership abilities.

Third, the auditor relationship which is always on the edge between technical and non-technical components. This is where compliance automation platforms come into play: they perfectly digest all the paperwork and allow you to concentrate on walking your auditor through things that really matter. Auditors are usually stonewalled by people who do not have in-depth understanding of systems they are attesting to, but you have a great chance to show them the real machinery.

If you are staring at this mountain…

I’d like to end with some high-level recommendations that might alleviate your SOC2 journey.

Own the scoping conversation. You own every system inside the audit boundary, and that’s you who will be producing evidence. So you have to give a think about segmentation and keep non-production chaos out of scope where legitimate. You know like no one that infrastructure is not a frozen snapshot, and it’s constantly changing, so maybe here’s no need to include a separated RnD VPC which will be purged tomorrow. Just let your auditor know about it, and be helpful in finding the real scope.

Start the observation window only after your evidence automation works. Delayed start is invisible, but a gap in evidence flow is permanent. This might lead to a long explanation and, potentially, a less desirable report.

Frame the whole thing to your leadership as infrastructure investment. Because it is: almost everything built for SOC2 (patch and vulnerability management, tighter IAM, change management, backups) made our systems genuinely better, not only auditable.

And one more thing, pretty personal. SOC2 definitely made me a better engineer and built a deep understanding of security and risk surface in a way that pure operations work never taught me. Also it drastically improved my communication skills because I talked a lot with auditors, vendors and executives, and talked their language. All in all, in my view, the industry is converging on this anyway: call it DevSecOps, compliance engineering or whatever, the wall between “guys who run the systems” and “guys who attest to the systems” is coming down.

If your company is starting the SOC2 journey and you’re the DevOps engineer wondering whether to participate, don’t wait to be asked. The controls already live in your systems, and all the evidence already flows through your pipelines. You are not a candidate here, you are the only one capable of leading it.