Vanta Is Not the Audit

I started with one question: when a company says it is SOC 2 compliant, what has actually been proven, and what has not?

The first distinction I had to get straight was between a live system check and an audit conclusion. Automated tests tell me what a system looks like right now. An audit asks whether people and systems did the right thing throughout the audit period. Those are different claims, and the useful work sits in the gap between them.

That difference ended up driving the whole assignment. Before I touched the tool, I needed the vocabulary to be exact.

I had to get the labels right before I could talk about the tool. SOC 2 is an attestation: a licensed CPA firm examines controls against the AICPA Trust Services Criteria and issues an opinion. There’s no certificate and no pass/fail badge. A report can include testing exceptions and still carry a clean, unqualified opinion. ISO 27001 is a certification, issued by an accredited body on a three-year cycle with surveillance audits in between. GDPR and CCPA are laws. You don’t get certified against a law; you demonstrate compliance with it.

One thing I didn’t want to lose from that table: ISO 27001:2022 has 93 reference controls in Annex A, but not all of them are mandatory. Applicability is decided by a risk assessment and recorded in the Statement of Applicability, including a written justification for anything excluded. The control set is driven by risk, not by a checklist.

After working through Vanta’s product model, I’d describe it as a compliance-operations platform. It connects systems, pulls configuration, runs rules against it, organises controls and evidence, assigns the work to people, hosts the auditor handoff, and publishes a Trust Center. It isn’t the auditor, the CPA firm, or the certification body.

The mechanic I kept using to understand it is simple. A test takes a resource, applies exactly one rule, and returns pass or fail with a reason. MFA enabled on this account. Disk encryption on this volume. Review before merge on this repository. Access revoked for this leaver. This vulnerability past its deadline. Individual results roll up into a control, and controls map to framework requirements.

Documents follow a similar path, except their states are human ones: Needs document, Needs update, OK, Not relevant, plus Due soon and Overdue. Each needs an owner, an effective date, and a description. Uploads can be automated through the API, but Vanta doesn’t read or evaluate the content of your Information Security Policy. It records that a file exists, who owns it, and when it was approved.

I started with the boundary, not with an integration: which legal entity, which products, which environments, which systems touch customer data, which people are in scope, and which vendors are subprocessors. Production is in scope; sandbox usually isn’t. If something can’t be integrated, it belongs in a manual-evidence list rather than quietly disappearing.

I kept the auditor early in the sequence for a blunt reason: the auditor decides what evidence is acceptable, not the platform. An audit firm’s own quick-start guide makes this point directly. Auditors often request different or additional evidence than the tool’s defaults, depending on which systems are integrated.

This was the part I couldn’t reduce to an integration. For SOC 2 there are three central documents: the management assertion, the system description, and the controls matrix. Around them sit approved policies, the risk assessment, the penetration-test report, disaster-recovery test results, board and management review minutes, access-review records, vendor DPAs, training records, and insurance certificates.

“No integration can prove those.”

Each one needs a human artifact with a date, an owner, and an approval. I kept noticing how quietly this material goes stale. Nothing fails loudly when a policy’s effective date drifts a year behind.

What makes a record strong, RATCC

The fifth is Consistent: the record comes from a trustworthy, verifiable source. A dated export from the system of record passes. An undated screenshot, or a spreadsheet reconstructed after the fact, doesn’t.

This was the clearest difference between a Type II audit and a dashboard. The auditor doesn’t want my best examples. They want the complete population: every change in the window, every person who left, with the source, filters, and date range visible. Then they select the samples, not me.

A population listing that begins in March is unusable if the observation window began in January. That one mismatch is one of the most common ways a well-run program can still fail a control.

The failure modes weren’t philosophical. They were specific and technical, and three came up repeatedly:

Timing is another trap I had to keep separate from remediation. Fixing a problem before fieldwork improves the future, but it doesn’t erase a historical deviation inside the observation window. Type II asks what happened during the window, not only what is true today.

Enterpret already has a running program. The report is dated and the certificates are live, so I didn’t see value in explaining its own evidence back to it. I focused instead on what a customer’s procurement team can see. Reading the public pages side by side gave me four reconciliation items. I’m reporting them as reconciliation items, not findings about control effectiveness.

• ✗Two live trust centres. A current Vanta-hosted portal and a still-live legacy Sprinto portal both return 200. The legacy surface publishes 46 controls; the current one publishes 78, in five categories, with no overlapping category names. That makes the old-to-new crosswalk the useful artifact.
• ✗The subprocessor list and the privacy policy disagree.The list shows seven US providers: AWS, OpenAI, Snowflake, Fireworks, PostHog, Anthropic, and TurboPuffer. Google isn’t among them, while a privacy policy names Google as an LLM provider. The DPA is authoritative, not the website; the issue is that two public pages disagree.
• ✗An AI-training contradiction with no version numbers.One document says customer data is never used for training or fine-tuning. Another describes sharing roughly 1% of anonymised feedback with OpenAI to fine-tune models. Neither carries a version or a date, so an external reader can’t tell which supersedes which.
• ✗ISO 27701 edition drift. The certificate is for the 2019 edition; the current standard is a standalone 2025 edition. That needs a transition plan agreed with the certification body before the next surveillance audit.

I don’t see these as gotchas. They’re exactly the kind of surface detail this role owns, and they cost almost nothing to fix once someone is looking.

Given a completed migration from Sprinto to Vanta, I wouldn’t start with another dashboard. I’d start with a control-continuity ledger , one row per control, answering whether history carried across.

I’d send two questions to the auditor alongside it: is the old-to-new mapping accepted, and which platform is the authoritative source of control history for the period under examination?

I treated these as India planning numbers rather than converting a US quote sheet. Where an India-facing provider published an INR band, I used it; where it did not, I marked the number as an inference or a scope-dependent planning example. Audit fee, readiness and remediation, tooling, and internal time are not interchangeable.

While working through the compliance problem, I kept seeing the same structure from the other end. A trust knowledge base where every claim is stored with its source, its owner, and a timestamp is exactly the shape a Type II audit needs. When an auditor samples month four, I either have a record with an author, an approver and an effective date, or I reconstruct it from memory. Only one of those passes.

The same structure catches the public contradictions above before a customer does, because two claims about the same subject with different values is a detectable condition rather than a thing someone happens to notice.

“The job is not to make the dashboard green.”

For me, the useful test is whether the company’s public claims, its actual system behaviour, and its provable evidence all describe the same thing.