← CMDash as an alternative to Drata
Switching
Moving from Drata to CMDash
Export your controls, policies and evidence index from Drata 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.
The switching offer
Two months free on Command or Enterprise
Show us a current Drata 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: Frameworks → a framework → Downloads → "Controls to requirements" (CSV) · Drata’s own documentation, read 2026-09-10
Carries over
- 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.
Does not carry over
- 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.
- Controls Drata marked Out of Scope — Drata excludes them from the export itself ("Only in-scope controls are included"), so they never reach this importer.
Policies
From: Policy Center — a policy LIST as CSV (see the warning: Drata documents no such export) · Drata’s own documentation, read 2026-09-10
Carries over
- 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.
Does not carry over
- 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 Hub evidence package → `evidence_manifest` (documented as HTML; save it as CSV) · Drata’s own documentation, read 2026-09-10
Carries over
- 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.
Does not carry over
- 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.
- Drata’s evidence renewal schedule (`ONE_MONTH` … `CUSTOM`). CMDash sets its own validity windows from its own evidence-freshness policy, which is the thing that will actually be enforced here.
The columns CMDash reads
Header names, not column positions — Drata’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 18 columns below, 12 are spelled the way Drata documents them and 6 had to be inferred.
Controls
| Accepted header | Needed? | Where the name comes from |
|---|---|---|
| Control Code · Control ID · Code | Optional | Documented |
| Name · Control Name | Optional | Documented |
| Description | Optional | Documented |
| Requirements · Requirement Ids · Framework Requirements · Mapped Requirements | Required | Inferred |
| Framework · Framework Name | Optional | Inferred |
| Status · Readiness | Optional | Inferred |
| Control Owners · Owner | Optional | Documented |
Policies
| Accepted header | Needed? | Where the name comes from |
|---|---|---|
| Name · Policy Name | Required | Documented |
| Description | Optional | Documented |
| Status · Policy Status | Optional | Documented |
| Policy Owner · Owner | Optional | Documented |
| Renewal date · Renewal Date | Optional | Documented |
Evidence index
| Accepted header | Needed? | Where the name comes from |
|---|---|---|
| Requirement | Required | Documented |
| Control · Name | Required | Documented |
| Original Path · Abbreviated Filename (/Evidence) · Abbreviated Filename | Optional | Documented |
| Framework | Optional | Inferred |
| Type · Evidence Type · Source | Optional | Inferred |
| Status | Optional | Inferred |
What we could not confirm
Drata 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.
Controls
- Every column header except `Control Owners`, which is the single literal export header Drata documents. The other spellings come from its own bulk-import template, which describes the same object.
- The rendered form of the import template’s `<Framework> Requirement Ids` header — the template is per-framework and no doc shows a rendered example.
- Which columns the "Requirements to controls" variant carries. Drata says only that controls land in "column F" of it, without naming columns A–E; this parser targets the "Controls to requirements" variant, which is one row per control.
- Delimiter, quoting, encoding and date format. Drata documents comma-separation for the IMPORT direction only, and its custom-framework importer bans `<`, `>` and backslash anywhere in the file.
- Custom fields append as their own columns ("Custom fields appear as their own columns in the spreadsheet"), so the real column set is per-tenant here too.
Policies
- ⚠ THE WHOLE FILE. Drata documents no policies CSV export at all: "Export or archive policies: Download policies as PDFs", and every documented download path — published version, draft version, Download All — yields a PDF. Unlike controls, risks and assets, there is no documented policy bulk-import CSV to borrow a vocabulary from either. A Drata customer’s "policies CSV" is therefore something they produced from the public API or a list view, and this parser is built for that shape.
- Every column header, and the order of them.
- Which of the two status enums a given file carries.
Evidence index
- ⚠ That the file is a CSV. Drata documents these four columns precisely — `Requirement`, `Control`, `Original Path`, `Abbreviated Filename (/Evidence)` — but as the audit package’s `evidence_manifest.html`, an "interactive manifest for viewing, searching, and opening evidence directly in your browser". Saving it as CSV is the customer’s step, not Drata’s.
- That any evidence-INDEX export exists outside that package. Drata states the opposite: "there is currently no single workflow that supports exporting all evidence in bulk without using the API."
- The columns of `Controls-to-Requirements.csv`, which ships inside the same package and IS a CSV — Drata names the file and describes it ("Lists mappings of controls to related requirements") without publishing its headers.
- The `Framework`, `Type` and `Status` column names.
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.