← CMDash as an alternative to Secureframe
Switching
Moving from Secureframe to CMDash
Export your controls, policies and evidence index from Secureframe 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 Secureframe 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 (or Frameworks) page → Export (CSV) · Secureframe’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.
Policies
From: Policies page → Export (CSV) · Secureframe’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: Data Room → table view → Export (CSV) · Secureframe’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.
The columns CMDash reads
Header names, not column positions — Secureframe’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, 13 are spelled the way Secureframe documents them and 5 had to be inferred.
Controls
| Accepted header | Needed? | Where the name comes from |
|---|---|---|
| ControlV2:id · id · Control ID · key | Optional | Documented |
| ControlV2:name · name · Control Name | Optional | Documented |
| ControlV2:description · description · Control Description | Optional | Documented |
| ControlV2:framework_requirement_keys · framework_requirement_keys · framework_requirement_ids · Framework Requirements | Required | Documented |
| Framework · Frameworks | Optional | Inferred |
| Status · Health Status · health_status | Optional | Inferred |
| ControlV2:implementation_date · implementation_date · Implementation Date | Optional | Documented |
| owner · Owner · owner_name | Optional | Documented |
Policies
| Accepted header | Needed? | Where the name comes from |
|---|---|---|
| Policy name · Name | Required | Documented |
| Status | Optional | Documented |
| Owner | Optional | Documented |
| Mapped Frameworks · Frameworks | Optional | Documented |
Evidence index
| Accepted header | Needed? | Where the name comes from |
|---|---|---|
| Name | Required | Documented |
| Evidence type · evidence_type | Optional | Documented |
| Date uploaded | Optional | Documented |
| Framework Requirements · Requirements · Controls | Required | Inferred |
| Framework | Optional | Inferred |
| URL · Link · Download URL | Optional | Inferred |
What we could not confirm
Secureframe 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
- The header ROW of an actual export. Every spelling above comes from Secureframe’s own IMPORT template and its REST schema; the export is explicitly "your current view, including any filters or column selections", so no fixed header row exists to publish.
- The `Framework` and `Status` column names.
- Whether enum cells render the REST token (`at_risk`) or the UI label (`At Risk`) — undocumented for every Secureframe enum.
- The multi-value delimiter on the EXPORT side. Comma-without-spaces is documented for the import direction only.
- Secureframe silently truncates CSV exports (documented as "often 1,000" rows) and documents that a blank cell may mean "not collected" rather than "empty" — so a short file is not evidence of a short control set.
Policies
- The header row and its order — the Policies table’s columns are user-toggleable ("toggling the columns on or off in the right side panel") and saved views are shared company-wide, so order varies per view.
- Whether the status cell carries `needs_review` or `Needs Review`.
- Everything not in the documented column list: version, effective date, next-review date, approver, source filename. None of these appears in any documented Secureframe column list, so none is read.
Evidence index
- ⚠ The whole file. No Secureframe article describes exporting the evidence library as a row-per-file index; what IS documented is exporting the evidence FILES (a zip, delivered by email, link expiring in 24 hours). The three column names above are the Data Room’s display/filter columns, offered by Secureframe with an "e.g.". Treat this parser as best-effort for a Data Room table-view export.
- Every linkage column — which control, test or framework an evidence file belongs to. This is exactly the column the mapping needs, and it is the one Secureframe documents least.
- File hash, size, uploader, validity window: not documented, not read.
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.