Vanta and Drata Show the Gaps. Who Actually Fixes Them?
Compliance-automation platforms are excellent at surfacing failing controls, but they don't remediate anything. The implementation gap between a red check in Vanta or Drata and the engineering work of actually closing it.
You bought Vanta. You connected AWS, GitHub, Google Workspace, and your identity provider. The integrations sync, the dashboard lights up, and within an hour you're staring at a wall of failing checks: MFA not enforced on three admin accounts, branch protection missing on two repos, CloudTrail not enabled in a region you forgot existed, an S3 bucket flagged as public.
The platform did exactly what it promised. It looked at your environment and told you, precisely and continuously, where you fall short of the SOC 2 control set. That's genuinely valuable — you couldn't have assembled that list by hand without weeks of work.
But here's what happens next, and it's the part nobody warns founders about: the dashboard sits there, red, for months. Because finding the gap and fixing the gap are two completely different jobs, and you only bought a tool for the first one.
What these platforms are actually for
Vanta, Drata, and Secureframe are continuous-monitoring and evidence-collection systems. They are very good at it. They watch your cloud accounts and SaaS tools, map the observed state to a framework's controls, collect screenshots and config exports automatically, and flag drift the moment a control slips out of compliance. They turn an annual audit scramble into a live feed.
What they do not do — what they were never designed to do — is change your
configuration. They are read-only observers with write access to nothing that
matters. A check that reads "MFA not enforced" is a sensor reading, not a
remediation. The platform cannot go into Okta and flip the policy. It cannot
open a pull request to add branch protection. It cannot enable CloudTrail in
eu-west-2.
The trap most teams fall into: treating the platform purchase as the compliance deliverable. The dashboard feels like progress because it's quantified and visual. But a 64%-compliant dashboard is not 64% of the way to a SOC 2 report — it's a backlog of engineering tickets that no one has been assigned to own.
The gap, concretely
Every failing check has two halves. The platform owns the left column. Someone on your team has to own the right one.
| Failing check | What the platform tells you | What actually fixing it requires |
|---|---|---|
| MFA not enforced | "3 users without MFA on AWS console" | Move IdP policy from "encouraged" to "required," remove long-lived IAM users, route humans through IAM Identity Center, re-verify, export the per-user report |
| Branch protection missing | "Repo api has no protection on main" | Configure a GitHub ruleset: required reviews, required status checks, no force-push, no deletion — across every production repo, not just the flagged one |
| Audit logging disabled | "CloudTrail not enabled in 1 region" | Turn on a multi-region trail, point it at a locked S3 bucket with retention, enable log file validation, confirm management + data events are captured |
| Vulnerable dependencies | "Dependabot alerts unresolved" | Triage real vs. noise, bump the packages, fix the breakages the bumps cause, wire Dependabot into CI so it doesn't recur |
| Encryption at rest | "Bucket not using KMS" | Choose customer-managed vs. AWS-managed keys, apply, write the bucket policy that denies unencrypted puts, handle the apps that break |
| No access reviews | "Quarterly access review overdue" | Pull the actual access lists, get owners to attest, deprovision the stale accounts, file the signed artifact |
The left column took the platform a few seconds. The right column is days of engineering work per row, and most of it touches production.
Why the backlog doesn't clear itself
There's a reason these red checks linger. None of the work is glamorous, all of it is interrupting someone's roadmap, and a lot of it carries real risk of breaking things.
Enforcing MFA can lock out a service account that was quietly using a human's credentials. Adding a required status check to a GitHub ruleset can wedge every open PR until CI is green. Flipping a bucket to deny unencrypted writes can take down an ingestion job that nobody documented. Engineers know this, so the tickets get deprioritized behind shipping features — which is the rational call right up until a deal stalls in security review.
The gap: the platform creates infinite visibility and zero capacity. It will faithfully show you the same failing check every day for a year. It has no opinion about who fixes it, in what order, or how to do it without an outage.
This compounds for teams shipping AI products, where the control surface is wider than the framework templates assume. Your Vertex AI or Bedrock setup, the IAM roles your inference service assumes, the logging on your model endpoints, the data-retention posture of your RAG pipeline — these map awkwardly to generic SOC 2 checks, so the platform either ignores them or flags them in ways that don't tell you what to actually change.
What "closing the loop" really means
A control isn't fixed when the dashboard turns green. It's fixed when three things are true:
- The configuration is actually changed in the live environment, and it survives the next deploy (i.e. it's in Terraform / IaC, not clicked in once).
- Evidence exists — the policy export, the ruleset screenshot, the CloudTrail config, the signed access review — filed somewhere an auditor or a buyer's security team can be handed it without a scramble.
- It doesn't silently drift back. The platform helps here — that's its core strength — but only once the control is correct in the first place.
That middle step is where even teams that do the engineering work fall down. You enforce MFA, you never export the proof, and six months later the auditor asks for evidence as of a date that's already passed. The fix was real; the evidence wasn't captured, so it doesn't count.
If you want a sense of exactly what artifacts each control needs, the free Cloud Controls Evidence Kit walks through the specific exports and screenshots buyers and auditors ask for, per control — so you're not guessing what "evidence" means for a given red check.
Who actually fixes them
Three honest options:
- Your engineers do it. Correct, if you have the headcount and they have the cloud-security context. The cost is roadmap time and the learning curve on controls they've never had to implement before.
- The platform's "expert network" / a vCISO advises. Useful for policy and process. But advisors largely produce documents and guidance — they tell your engineers what to do; they don't open the pull request. The implementation gap stays on your side.
- An engineer who does the implementation. Someone who treats the red dashboard as a work queue, ships the config changes through your IaC, gathers the evidence, and hands you back green checks with artifacts attached.
The first and third close the loop. The middle one moves it.
The Controls Review
That's the offer. A Controls Review is an engineer walking your failing checks in Vanta, Drata, or Secureframe and shipping the fixes — not a slide deck telling you what's wrong. You already have the platform telling you that.
It looks like this: connect the dashboard, triage the red checks by what's actually blocking deals or the audit, then work the queue — enforce the MFA, write the GitHub rulesets, turn on the multi-region trail, lock the buckets, wire Dependabot into CI — through your infrastructure-as-code so the fixes stick. Every closed check comes with its evidence artifact filed. For AI teams, that extends to the controls the generic templates miss: the IAM scoping on your inference roles, logging and retention on model endpoints, the data path through your RAG pipeline.
The platforms are great. Keep them — they're the right tool for continuous monitoring, and nothing here replaces that. The point is narrower: monitoring is not remediation, and the red checks don't fix themselves.
If you've got a dashboard full of gaps and no one who owns closing them, book a fit call and we'll look at what's actually blocking you.