Why can't software alone maintain a SOC 2 program?

There's a promise circulating in the compliance space right now, pushed by a growing number of AI-powered platforms: that you can buy a tool, connect your integrations, and have it manage your SOC 2 program for you. Automate the evidence collection. Let the AI handle the controls. Get compliant without hiring anyone or changing how your team works.

It's an appealing pitch. It's also not how compliance actually works.

What software does well

To be clear: compliance platforms are useful. Tools like Vanta and Drata have made it significantly easier to track control status, collect evidence, and manage the documentation that an audit requires. They integrate with your cloud environment, your code repos, your HR systems, and they surface gaps in a way that would take much longer to identify manually.

For a team that's starting from scratch and wants a structured framework to work through, these platforms are a reasonable place to begin. They guide you through the process. They tell you what needs to be in place. They automate the parts of evidence collection that are genuinely automatable.

The problem isn't what the platforms do. The problem is what they can't do — and what happens when teams mistake the former for the latter.

What software can't do

A compliance platform doesn't understand your business. It knows what a generic implementation of a given control should look like, and it applies that template to your organization regardless of how your organization actually operates.

That creates a specific and recurring problem: overengineering. The platform flags every possible control as applicable, whether or not it's relevant to your scope. Teams end up doing significantly more work than necessary, implementing controls that don't fit their model, and generating documentation for requirements that don't actually apply to them. One of the first things a good compliance partner does when onboarding a customer who already has a platform is rightsize what they've built — strip out what isn't applicable and focus on what is.

But the more fundamental issue is this: software can tell you whether a control is marked as complete. It can't tell you whether the control is actually working.

Your policy says you review user access quarterly. The platform shows the control as green. But did the review actually happen? Did someone look at the list, verify it against your current team, and document what changed? Or did someone click through the workflow without really doing the work?

The platform doesn't know. The platform records what you tell it. And in a real audit — with a rigorous auditor — that distinction matters enormously.

The observation period problem

This gap between what the platform records and what's actually happening becomes most visible during the Type II observation period, which is where the real compliance work lives.

Getting to Type I on a platform is manageable. It's a sprint: you work through the checklist, implement the controls, get the audit done. The platform is genuinely helpful for that phase.

The observation period is different. It requires sustained operational discipline over months — user access reviews on schedule, vendor assessments before new sub-processors are onboarded, incident documentation, quarterly risk assessments, policy updates when your infrastructure changes. Every one of those activities requires a human being to actually do the work, verify it was done correctly, and ensure the evidence exists.

What happens in practice is that the platform becomes a to-do list that nobody has time to work through. Compliance tasks compete with engineering priorities, and in a small team, they lose. Controls drift. Evidence doesn't get collected. The observation period that looked clean in month one has holes by month four.

And then the audit comes.

The rubber-stamp problem

Here's the part of this conversation that the platforms don't advertise: the companies that use automation to run their entire program — minimal human involvement, everything delegated to the tool — tend to pass audits from firms that aren't looking closely. And there are firms that aren't looking closely.

A certification from one of those firms is worth less than it appears. It might satisfy a less sophisticated buyer. It won't satisfy an enterprise security team that does its own due diligence. And it creates a specific kind of problem: you've spent time and money getting certified, the program looks compliant on paper, and then you onboard a real compliance partner and discover that the controls aren't actually running the way the platform says they are. Everything has to be rebuilt from scratch.

That's not a hypothetical. It's a pattern that comes up regularly — companies that were technically certified and practically unprotected, with an observation period that has to restart from zero.

The role automation actually plays

None of this means automation has no place in compliance. It means automation is a tool, not a program.

Evidence collection for integrations that genuinely support it — cloud configuration monitoring, code repository activity, endpoint status — is a good use of automation. Tracking control status across frameworks in one place is useful. Alerting when something goes out of compliance is valuable.

What automation can't replace is the human judgment required to understand which controls apply to your specific business, verify that the work behind the controls is actually being done, make decisions when the standard answer doesn't fit your model, and navigate the relationship with your auditor when findings come up.

Compliance is messy. Integrations change. Teams develop workarounds that break automated tests. Edge cases appear that no platform has a clean answer for. The organizations that maintain strong programs over time — the ones that pass rigorous audits from reputable firms — have people running those programs who understand the difference between a green status on a dashboard and a control that's genuinely working.