Moving from Vanta to CMDash
Export your controls, policies and evidence index from Vanta as CSV. CMDash maps them onto its own framework catalogs and policy templates and shows you, line by line, what it matched, what it is only guessing about, and what it could not place at all — before it writes anything.
Two months free on Command or Enterprise
Show us a current Vanta contract and your first 2 months on a monthly Command or Enterprise plan are 100% off. Use code SWITCH2MO at checkout.
The code is entered at card checkout. Coming soon
- Monthly billing only — the discount runs for 2 months, so on an annual plan it would discount a whole year rather than two months.
- New customers only, and one to a company: Stripe refuses the code for anyone who has already paid us.
- Limited to 25 redemptions, and the code stops working 180 days after it is issued.
What carries over
3 exports, 3 answers. Each list below is read from the importer’s own capability table — if the code stops doing one of these, this page stops saying it.
Controls
From: Controls page → Export (CSV) · Vanta’s own documentation, read 2026-09-10
- The implementation status of every control whose framework-native requirement code matches a control in CMDash’s own catalog for that framework.
- The exported control’s name and description, kept as the note on the CMDash assessment so you can see where the status came from.
- One exported row mapping to several CMDash controls, when it cites several requirement codes.
- Automated tests and their pass/fail history. CMDash runs its own integrations and re-derives control state from them — importing another tool’s test results would show green on evidence CMDash never saw.
- Controls for a framework CMDash does not ship. The report names the framework label it could not resolve, per line.
- Controls that cite no framework requirement code at all — a custom control that maps to nothing in the source tool maps to nothing here either.
- Anything matched only by title similarity. Those lines are reported with their score and their best candidate, and are never written; a person decides.
Policies
From: Policies page → More → export · Vanta’s own documentation, read 2026-09-10
- A policy whose title matches one of CMDash’s starter policy templates is created in your library from that template, pre-linked to the framework controls the template declares.
- The policy TEXT you wrote in the other tool. CMDash creates the document from its own template — a policy is a document people attest to, and silently importing prose CMDash cannot vouch for into an attestation flow is not a migration, it is a liability.
- Acceptance and attestation history — who acknowledged which version, and when.
- Approval history, version numbers, effective dates and review cadences from the other tool.
- A policy with no matching CMDash template. It is reported by line with its best candidate, never guessed at.
Evidence index
From: Audit → Requests tab → Export (the IRL request list) · Vanta’s own documentation, read 2026-09-10
- One evidence record per indexed row, attached to the control it cites, filed as PENDING review and tagged with the tool it came from (`switching:<vendor>`) and the line it came from.
- The row’s link, where the export carries one, so the artifact in the old tool stays one click away while you re-collect it.
- The evidence FILES. This is an index import, not a file transfer: CMDash records that the artifact existed and what it covered, and files it for review.
- Rows whose control reference does not resolve to a CMDash control — reported by line.
- Reviewer state from the other tool. Every migrated row lands as PENDING, deliberately: a competitor’s CSV is not a review, and letting one satisfy a freshness check would make a control look evidenced when nobody here has looked at it.
The columns CMDash reads
Header names, not column positions — Vanta’s exports do not have a fixed column set. Anything CMDash does not recognise is ignored rather than treated as an error, and the import report shows you your own header row so you can see what it skipped. Of the 20 columns below, 17 are spelled the way Vanta documents them and 3 had to be inferred.
| Accepted header | Needed? | Where the name comes from |
|---|---|---|
| Control ID | Optional | Documented |
| Control Name · Control Summary | Optional | Documented |
| Control Description | Optional | Documented |
| Framework Code | Required | Documented |
| Framework · Standard | Optional | Inferred |
| Status | Optional | Inferred |
| Owner | Optional | Documented |
| Accepted header | Needed? | Where the name comes from |
|---|---|---|
| Name · Policy Name | Required | Documented |
| ID · Policy ID | Optional | Documented |
| Description | Optional | Documented |
| Status · Latest Policy Status | Optional | Documented |
| Owner | Optional | Inferred |
| Accepted header | Needed? | Where the name comes from |
|---|---|---|
| Unique ID | Optional | Documented |
| Request Name · Name | Required | Documented |
| Description | Optional | Documented |
| Control ID | Required | Documented |
| Type | Optional | Documented |
| Status | Optional | Documented |
| Owner | Optional | Documented |
| Capture Date · Due Date | Optional | Documented |
What we could not confirm
Vanta does not publish the header row of any export. Everything below is a limit of this importer that we know about and are telling you before you sign, rather than after you upload. If your export does not parse, the error names your own header row — send it to us and the accepted spellings get extended.
- The header ROW itself. Vanta publishes no export header row anywhere; these spellings come from its custom-control IMPORT template, which describes the same object.
- The `Framework` and `Status` column names.
- The delimiter inside a multi-value cell. Vanta documents `CC 1.1, CC 1.2` for the import direction only; comma, semicolon, pipe and newline are all accepted.
- That the export is one flat CSV at all. Vanta’s controls export is "all controls and columns in the table", and a customer custom field becomes a column, so the real column set is per-tenant.
- The header row, and whether a flat policy-list CSV exists at all. Vanta’s documented policy export is a ZIP of folders — `policies` (PDFs of approved policies), `policy_acceptances` (CSV), `policy_approvals` (CSVs) — per https://help.vanta.com/en/articles/11345490-v2-policy-migration. The columns of the two CSVs in it are not published.
- The `Owner` column name.
- Whether statuses render as UI labels or API enums.
- The header row of the exported requests CSV. Vanta documents the ZIP structure ("A CSV of each request per row alongside available request metadata") and the IRL field LABELS, but never the CSV’s own headers, and "available request metadata" is not asserted to be the same set as the import fields.
- That the Documents-page export has an index at all — it is documented as a ZIP of the files themselves, with no manifest.
- How `relatedControls` / `sectionNames` are flattened into a cell, and with what delimiter.
Nothing is written until you say so
- The import runs as a dry run by default. It performs every lookup the real run performs — including checking each matched control actually exists in your workspace — and stops before writing.
- The report gives every line one of three outcomes: matched, low-confidence, or unmatched — each with the reason, by line number.
- A control matched only because its TITLE resembled one of ours is never written. It is reported with its score and its best candidate, and a person decides.
- Nothing already done in CMDash is overwritten: a control you have already assessed and a policy you already have are skipped and counted, not replaced.
- The whole import is one audit-log entry, carrying what it declined to map as well as what it wrote.
Want us to run the import with you, or got an export shape this page does not cover? Email us and send the header row.