Switching from Vanta: what actually carries over

Every compliance-automation vendor's pitch to a Vanta customer eventually reaches the same sentence: "and switching is easy." It usually isn't backed by anything you can read before you sign up. So we wrote down, column by column, what CMDash's importer actually does with a Vanta export, published it at /switch/vanta, and pinned a test to it (switching-capability-drift.test.ts) that fails the build if the marketing page and the parser ever say something different. This post is the plain-language version of that page.

Start with the honest part: there is no "the" Vanta export

Vanta doesn't publish a fixed header row for its CSV exports. The controls export is documented as "all controls and columns in the table," and a custom field you added becomes a column automatically - so the real column set is whatever your tenant happens to have, not a schema anyone can pin down in advance. What can be sourced, and what switching-formats.ts actually records, is Vanta's documented field vocabulary: its custom-control import template, its policy and evidence-request help articles, each with a retrieval date. The importer is header-driven and ignores anything it doesn't recognize for exactly this reason - a customer's extra columns don't break the parse, they just get reported as ignored.

The one design decision that matters: it maps on the framework code, never the vendor's key

Vanta keeps two kinds of identifier for a control: its own key (something like CRY-104, or a slug like access-application-restricted), and the framework-native requirement code the control is mapped to (CC1.1, A.5.15, 3.1.1). Those are not interchangeable, and only the second one means anything to CMDash. So the importer keys exclusively on Framework Code - the comma- delimited column Vanta's own docs describe as "the framework sections or requirements the control maps to." Keying on Vanta's own control ID would have matched almost nothing while looking like a working importer, and worse, a Vanta key that happened to collide with an id in one of CMDash's catalogs would have silently overwritten status on an unrelated control. One exported row can carry several framework codes, so one row can land on several CMDash controls at once; the dry-run report lists every one of them, by line.

What a controls import gives you

For every row whose framework code resolves to a control in your CMDash catalog, the importer writes the implementation status Vanta had recorded, and keeps the exported name and description as a note on the assessment so you can see where the status came from. What it will not do is import Vanta's automated test results or their pass/fail history. CMDash re-derives control state from its own connected integrations; pulling in another tool's test outcomes would show a control green on evidence CMDash never actually saw. A row that cites no framework code at all, or cites a framework CMDash doesn't ship, is reported unmapped rather than guessed at, and anything the importer can only match by title similarity is reported with its confidence score and never written automatically - a person decides those, not the parser.

Policies come across as structure, not prose

This is the one most people get backwards. The importer does not copy the policy document you wrote in Vanta into CMDash. When an exported policy's title matches one of CMDash's own starter templates, CMDash creates a new document from that template, pre-linked to the framework controls the template already declares - not the text you wrote, a document CMDash can actually vouch for. That's deliberate: a policy is something people attest to, and quietly importing prose from another tool into an attestation workflow would mean putting your name behind wording nobody here reviewed. Acceptance history, approval trail, version numbers and review cadences from Vanta don't come across either - there is no CMDash slot for "who acknowledged version 4 on this date in Vanta," and inventing one would misrepresent an attestation that never happened inside CMDash. Vanta's own documented policy export, for what it's worth, is a ZIP of PDFs and two CSVs whose columns aren't published anywhere - another reason a byte-for-byte migration was never the design target.

Evidence: an index, not a file transfer

The evidence import reads Vanta's Information Request List export - the audit "Requests" tab - and creates one CMDash evidence record per row, attached to the control its Control ID cites, filed as PENDING review and tagged with the tool and line it came from. The files themselves don't move; this is an index saying an artifact existed and what it covered, filed for someone to look at, not a bulk file copy. Reviewer state doesn't carry over either, on purpose: every migrated row lands PENDING no matter what state it held in Vanta, because a competitor's CSV isn't a review, and letting one satisfy a freshness check would make a control look evidenced when nobody at your organization has actually looked at it since the export.

What this is not, and why that's on purpose

Drata, Secureframe and CISO Assistant get the same controls/policies/evidence treatment. CISO Assistant additionally exports risk scenarios and a third-party entity register that Vanta, Drata and Secureframe don't publish in a form this importer can read yet - so switching from CISO Assistant carries risks and vendors across, and switching from Vanta does not. That asymmetry is stated plainly on each vendor's own /switch/<vendor> page rather than smoothed over into one generic "we migrate everything" claim.

None of this is a full migration, and it isn't marketed as one. It's a dry run first, always - apps/web/src/app/(dashboard)/migration/page.tsx is a wizard that lets you drop your export files, preview exactly what would map before anything writes, and only then apply it - so you can see the real shape of what carries over before you decide whether it's worth carrying over at all. If you're evaluating a move off Vanta, the fastest way to find out what's true for your tenant specifically is to run the dry run and read the report it gives you, line by line, against what's written here.