We cleared our SOC 2 gap assessment in 48 hours (and you can too!)

The Problem With Gap Assessments

Every compliance audit (SOC 2, HIPAA, FedRAMP) starts with a gap assessment: the step where you identify the controls that will actually be tested. With SOC 2, this is more complicated than it sounds. Every auditor is free to interpret the AICPA's guidelines their own way, and each brings a different control set. There is no single, canonical list.

Many organizations hire consultants or buy compliance software to surface the problems and suggest fixes. Even then, depending on how your environment was built in the first place, you can end up staring at a very long list, one that takes many hours to resolve and prove.

Remediation

In most cases, your team has to stop in-flight work to close the gaps the assessment identified. In the organizations I've worked with, that usually looks like one person, who owns the assessment, pestering developers into fixing issues and producing evidence. Those developers may or may not prioritize the requests.

Sometimes there are hundreds of findings. Sometimes a single finding takes hours to resolve. It's not hard to see why there has to be a better way.

How We Bridged the Gap

This is where experience and the right tooling compound. We had real advantages going into our first SOC 2: both our cloud environment and our offering were purpose-built by people who had been through these audits before. Our Compliance-Native DevOps Platform was designed specifically for SOC 2, with agents and systems built to use Infrastructure as Code (IaC) to its fullest.

What's IaC?

Simply put, IaC is a way to build infrastructure and run commands in a cloud environment using coded templates. Build from a template, and your systems come up exactly as specified, correct configuration options selected every single time. Without IaC, drift between what you built and best practice is nearly guaranteed.

If you know the best practices, and you know the compliance controls an auditor will look for, you can bake both into your infrastructure from the start. Everything you deploy is compliant by construction, and stays that way.

IaC has a second benefit: the "stacks" it creates can be removed as single objects. No hunting down your compute instance, database, and security group one by one. Delete the stack, and everything in it goes with it. Use IaC for everything, and you eliminate configuration drift entirely, which is increasingly something auditors require rather than merely appreciate.

How Do We Use IaC?

IaC is the core of our platform, and our agents use it in different ways. The basic flow:

1. Each service generates IaC.
2. All IaC is checked for compliance issues.
3. Clean IaC is sent to a GitHub repo as a pull request.
4. The repo owner, typically you, or your most senior admin, reviews the code and merges if it's acceptable.
5. The merge triggers an action that automatically updates your cloud environment.

This means any number of users can suggest changes without you constantly reworking IAM permissions. The merge is the control point.

Of course, the concept is only as good as the services built on it:

• The Architect agent ensures everything is compliant from the start. It works the way any frontier LLM would for building infrastructure, but instead of deploying unreviewed resources directly into your cloud, it submits what you've built as a pull request to the IaC repo.
• The Remediator agent starts where every other compliance tool does, a catalog of checks, but instead of just pointing out issues, it ships fixes as IaC. It also includes a powerful agent for building custom IaC when a finding needs a more tailored fix. On AWS, it monitors your security services, Security Hub, Inspector, GuardDuty, and Trusted Advisor. It generates custom fixes right from the app, and opens a PR. You don't have to bug your cloud architects.
• The Documentarian agent let us build our entire policy set through an interview process. We supplied the context we had; it filled in the boilerplate. Creating and updating our full documentation set took about an hour.

The Overall Timeline

We signed with our SOC 2 auditor at the very end of June 2026. Good auditors typically provide a portal exposing the controls you need to satisfy before the audit itself begins. In our case:

• June 30, 2026, 5:33 PM — portal access granted.
• July 1, 2026, 8:35 PM — last control met and submitted.

Barely a day of work, roughly 90% of the SOC 2 done in a day.

The audit itself started July 7th. As with every SOC 2, there was a fair amount of back and forth afterward as we clarified points and the auditor wrote the report. We received the draft report on August 11th and the final report on August 18th — an entire engagement of about six to seven weeks. Technically we were done much sooner than that, but you never control your auditor's schedule.

The biggest takeaway: the gap assessment and remediation phase is normally where many, many weeks disappear. That's exactly where we saved the most time — by completing it in a day or so.

‍