What Vanta and Drata Can't Automate

Companies that implement Vanta or Drata expecting near-complete automation of their SOC 2 compliance work tend to hit the same wall. The integrations connect. The dashboard lights up. Tests start passing. And then, somewhere around the midpoint of their first audit cycle, they discover a significant portion of their control environment was never in scope for the platform at all.

This is not a flaw in Vanta or Drata, both are well-built tools that do exactly what they are designed to do. The issue is a characteristic of how integration-driven platforms work, and understanding it is the difference between using these tools effectively and building a compliance program around a false sense of coverage.

What Vanta and Drata Do Well

Before addressing the gaps, it is worth being precise about the value these platforms provide, because the value is real.

Vanta and Drata connect to cloud infrastructure, identity providers, endpoint management systems, and development tooling through API integrations. Once connected, they pull configuration data automatically: MFA enforcement status across your identity provider, access logs from cloud storage, vulnerability scan results from your security tooling, encryption settings across cloud services, and user provisioning and deprovisioning records. Evidence that would otherwise require manual export and upload is collected continuously.

For a company running entirely in a major cloud provider with standard SaaS tooling, this automation is substantial. Roughly 40 to 50 percent of SOC 2 controls in a cloud-native environment can be covered through these integrations, according to patterns observed across multiple compliance engagements. The reduction in manual evidence collection time compounds over an observation period. Audit preparation moves from a months-long scramble to a more manageable review.

Beyond evidence collection, the platforms provide a structured framework for tracking control status, managing vendor reviews, maintaining policy acknowledgment records, and monitoring deadlines. For a company that would otherwise be managing this in spreadsheets, the operational value is significant.

The platforms are partners in compliance work, not obstacles to it. The issue is what sits outside the integration surface, and how often that population of systems turns out to be larger than expected.

The Reason for the Gaps

TLDR: Vanta and Drata are integration-driven platforms, not inventory-first systems.

An inventory-first approach begins by mapping every system, service, data flow, and control owner in scope for the compliance framework, regardless of whether a technical integration exists. The platform then determines which controls can be automated and which require manual processes, with full visibility into both categories.

Integration-driven platforms work from the other direction. They connect to the systems they support through pre-built integrations, and tests run against those connections. The platform's visibility is bounded by its integration surface. Systems that aren't connected don't appear in the compliance picture at all. They don't generate passing tests. They don't generate failing tests. They simply don't exist from the platform's perspective.

This means the dashboard reflects the health of the integrated environment, not the health of the full compliance scope.

A company with three connected integrations and a passing dashboard may have a perfectly clean cloud environment and a significant number of unmonitored systems sitting outside the platform's view. The dashboard is accurate within its own frame. But the frame is smaller than the compliance scope.

This is the structural reality of every integration-driven platform, and it becomes more consequential as organizations move beyond purely cloud-native environments.

What Falls Outside the Integration Model

The systems most commonly outside GRC platform coverage fall into predictable categories.

The Audit-Readiness Gap

The practical consequence of this structure appears clearly during audits.

A company with a clean Vanta or Drata dashboard will enter an audit with confidence. The tests are passing. The evidence is collected. The control library shows green. Then the auditor asks about the on-prem development server that runs a critical internal tool. About the co-lo rack where the database backups are stored. About the six SaaS applications in the vendor list that have no corresponding integration in the platform.

The platform has no evidence for any of those systems, because it has no visibility into them. The auditor does not care that the platform's dashboard is green. The auditor cares whether controls exist and are evidenced for every system in scope under the agreed-upon trust services criteria.

This is not a theoretical risk. The pattern appears consistently in organizations that operate mixed infrastructure and rely exclusively on a GRC platform for compliance coverage. The platform covers what it can see. The audit covers everything.

What GRC Engineering Adds

The starting point in a GRC engineering approach is a complete asset and system inventory, conducted before any compliance work begins.

This inventory maps every system, service, and data flow in scope for the relevant framework, including the systems that have no integration path to a GRC platform. The control framework is then mapped to the real scope, not to the platform's integration surface.

From this inventory, the work divides cleanly. For systems with available integrations, the GRC platform handles evidence collection.

For systems outside the integration surface, custom tests and evidence collection processes are built: scripts that extract configuration data from on-prem systems on a defined schedule, manual review processes with documented completion records, monitoring instrumentation for legacy applications, and structured workflows for process controls that require human review.

The result is a compliance program where every in-scope system has a defined control owner, an evidence collection method, and a test that runs against it. The platform covers its portion. The custom layer covers the rest. No system sits outside the coverage map.

This approach also produces a more honest compliance posture. The organization knows what it's monitoring, what it's not, and why. When the audit question comes about the on-prem development server, the answer isn't silence or a scramble. The evidence exists because the system was in scope from day one.

For a fuller treatment of what GRC engineering involves as a discipline, see What is GRC Engineering?

Applying This to an Existing Platform Deployment

For organizations already running Vanta or Drata, the starting point is a gap assessment rather than a platform replacement. The goal is to understand the actual compliance scope and determine what falls outside the current integration surface.

A few diagnostic questions help structure this:

Which systems in scope for the compliance framework have no corresponding integration in the platform? This includes on-prem servers, co-lo infrastructure, legacy applications, and custom internal tools.

Which controls in the current framework map to those systems? For each unintegrated system, which trust services criteria apply, and is there any current evidence collection method for those controls?

What percentage of controls are currently covered by platform integrations, and what percentage requires manual evidence gathering? For many organizations with mixed infrastructure, the automation percentage drops well below the cloud-native baseline of 40 to 50 percent.

What process controls exist outside the platform? Policy acknowledgment records, vendor reviews, training completion, and risk assessment documentation all require structured processes with completion records, whether the platform supports them or not.

The answers to these questions define the gap between current coverage and audit-readiness. In cloud-native environments, that gap may be manageable. In organizations with significant on-premises or legacy infrastructure, it often represents the majority of the compliance work.

The Takeaway

Vanta and Drata are valuable tools. They automate a meaningful portion of compliance work and provide infrastructure that any serious compliance program should use.

They are also bounded tools. The boundary is the integration surface. Anything outside that surface is invisible to the platform, and compliance programs built entirely around these tools will have coverage gaps that correspond exactly to the systems they can't integrate with.

The green dashboard is accurate within its own frame. Making that frame match the actual compliance scope is a different problem, and it's one that requires an engineering approach to solve.

Explore GRC Engineering services

Frequently Asked Questions

What percentage of SOC 2 controls can Vanta or Drata automate?

In fully cloud-native environments with standard SaaS tooling, Vanta and Drata can automate evidence collection for roughly 40 to 50 percent of SOC 2 controls. In organizations with on-premises infrastructure, legacy systems, or custom tooling, that percentage is often significantly lower because those systems fall outside the platform's integration surface.

Can Vanta or Drata cover on-premises servers and infrastructure?

No. Vanta and Drata are built around cloud provider and SaaS application integrations. On-premises servers, co-location racks, and bare-metal infrastructure generally have no out of the box integration path, which means controls tied to those systems require manual evidence collection outside the platform.

What is the difference between an integration-driven and inventory-first compliance approach?

An integration-driven platform connects to systems it supports via pre-built APIs and runs tests only against those connected systems. An inventory-first approach maps every in-scope system first, then determines coverage method. The difference is visibility: integration-driven platforms don't surface systems they can't connect to, while an inventory-first approach makes the full scope visible, including systems that require manual processes.

What is GRC engineering and how does it differ from using a GRC platform?

GRC engineering is a discipline that treats compliance program design as an engineering problem. Where GRC platforms provide automation within their integration surface, GRC engineering extends coverage to every system in scope, including those without platform integrations, by building custom evidence collection processes, automated scripts, and structured manual workflows. The GRC platform becomes one component of a broader, fully mapped compliance program rather than the whole program.

Why does a passing Vanta or Drata dashboard not guarantee audit readiness?

A passing dashboard in either platform indicates that the systems connected to the platform are passing their configured tests. It says nothing about systems that have no integration. Auditors evaluate every system in the agreed audit scope, regardless of whether a GRC platform has visibility into it. Organizations with unintegrated systems in scope will encounter evidence gaps that the dashboard never surfaced.

What should we do if we are already using Vanta or Drata and suspect we have coverage gaps?

Start with a gap assessment against your full system inventory. Identify every in-scope system that has no corresponding platform integration, map which SOC 2 trust services criteria apply to those systems, and determine whether current evidence collection exists for each. The goal is not to replace the platform but to build coverage for the systems it cannot reach. A GRC engineering engagement typically begins with exactly this scoping exercise.