Import from CISO Assistant

What it is

CMDash's switching importer reads a CISO Assistant export — CSV, from five different screens — and maps it onto CMDash's own framework catalogs, policy templates, risk register, and vendor register. It always runs as a dry run first: it performs every lookup a real import performs, including resolving each match to a row that actually exists in your workspace, and reports what it would do — matched, low-confidence, or unmatched, line by line — before it writes anything. Nothing is written until you explicitly ask for a real run.

CISO Assistant (intuitem/ciso-assistant-community) is a fourth vendor alongside Drata, Vanta and Secureframe (see /switch/ciso-assistant on the marketing site for the same capability table this guide describes, and the other three vendors' own switching guidance). It is the only one of the four that is open source, so — unlike the other three, whose export column headers had to be inferred from prose documentation — CISO Assistant's headers are read verbatim out of its own shipped source code.

Before you start

There is a page for this now: open Migrate from GRC tool (Admin section, or /migration directly), pick CISO Assistant, and upload or paste each export instead of calling the API by hand. This guide's "Running a dry run" section below still describes what happens underneath — the same preview-then-apply flow, the same report — but the page is the normal way to run it now; see Migrate from another GRC tool for the walkthrough. If you would rather not run it yourself at all, ask CMDash support — the marketing page's "Email us" link on /switch/ciso-assistant is for exactly this.

You need:

• OWNER or ADMIN on the CMDash workspace you are importing into (only those two roles can run an import), and the compliance permission at admin level if your workspace uses custom roles.
• A CISO Assistant instance you can export from — self-hosted or the vendor's own hosted offering — with access to the exports listed below.
• The framework(s) you are migrating already enabled in this CMDash workspace. A match against a framework CMDash has not seeded is reported as unmatched, naming the framework, rather than silently skipped — enable the framework, then re-run.

The five exports, and where to get each one

CISO Assistant does not publish one combined export; each file kind below comes from a different screen, and two of them (Controls and Evidence) are the same underlying file read twice for two different purposes.

⚠ CISO Assistant has no dedicated evidence-index export. Evidence only ever appears as an "Associated evidences" column embedded in each control's row of the Action Plan export. Upload the identical file to both controlsCsv and evidenceCsv — the importer reads the "Covered requirements" and "Associated evidences" columns for the control pass, and explodes each control row's evidence names into their own rows for the evidence pass, inheriting that control's mapped requirement(s).

⚠ Two different delimiters. The Action Plan CSV (controls/evidence) is comma-delimited; the Policies/Risk scenarios/Entities exports are semicolon-delimited (CISO Assistant's own generic CSV exporter writes ;). CMDash's importer detects which one a file uses from its header row, so you do not need to convert anything — just export each file the way CISO Assistant gives it to you.

You do not have to supply all five. Send only the ones you have; each is optional and independent.

Running a dry run

POST /api/data-import/switching/ciso-assistant
Authorization: Bearer <your OWNER or ADMIN token>
Content-Type: application/json

{
  "framework": "SOC 2",
  "controlsCsv": "<paste the Action Plan CSV text>",
  "evidenceCsv": "<paste the SAME Action Plan CSV text again>",
  "policiesCsv": "<paste the Policies CSV text>",
  "risksCsv": "<paste the Risk scenarios CSV text>",
  "entitiesCsv": "<paste the Entities CSV text>"
}

dryRun defaults to true — an omitted flag never writes, so the call above is safe to run as many times as you like while you check the report. The framework field names which CMDash framework catalog to match controlsCsv/evidenceCsv rows against when a row's own "Covered requirements" cell does not resolve on its own (it names a framework-native requirement code, not a framework — one audit export is normally all one framework, so this is the usual case, not an edge case). Run one import per framework if you are migrating more than one audit.

The response reports, per file, per line: mapped (with every CMDash target it resolved to), low-confidence (a title-similarity guess it will never write on your behalf — you decide), or unmatched (with the reason). Nothing is written on a dry run, including the audit-log entry.

To write for real, send the identical request with "dryRun": false. A second import of the same files is safe to run again — every file kind skips a row it already created (an existing control assessment, an existing policy by title, an existing risk by title, an existing vendor by name) rather than creating a duplicate.

What each export carries over, and what it does not

Controls

CMDash matches on the framework-native requirement code inside each row's "Covered requirements" cell (formatted <ref id> - <name>, one per line) — never on CISO Assistant's own internal identifiers. A row citing several requirement codes can map onto several CMDash controls. What does not carry over: Category, CSF Function, Priority, ETA, Expiry date, Effort, Impact and Cost (real columns of the export with no CMDash control-assessment equivalent); a row citing no framework requirement at all; and anything CMDash could match only by title similarity — those are reported with a score and never written.

Evidence

One evidence record per name found in a control's "Associated evidences" cell, attached to that control's mapped requirement(s), filed as PENDING review (never as already-reviewed) and tagged switching:ciso-assistant plus the line it came from. What does not carry over: the evidence FILES themselves (this is an index import, not a file transfer), a direct link to the file, or any evidence attached to a control that no compliance audit in CISO Assistant covers (the Action Plan export is per-audit).

Policies

A policy whose CISO Assistant title matches one of CMDash's starter policy templates is created in your library from that template. What does not carry over: the policy text you wrote in CISO Assistant (CMDash creates the document from its own template, deliberately — a policy is a document people attest to, and silently importing text CMDash cannot vouch for into an attestation flow is not a migration, it is a liability), acceptance/attestation history, approval history and review cadences, and a policy with no matching CMDash template.

Risk scenarios

A CMDash risk is created for every scenario with a name and a recognised current probability and impact — CISO Assistant's risk matrices are configurable, so the export carries a matrix label word ("Low", "High", "Very High", …) rather than a fixed number, and CMDash recognises the shipped default 5×5 matrix's five label words case-insensitively. A row rendering -- (unrated) or using a label from a different, customised matrix is reported unmatched rather than guessed at. The treatment column (open / mitigate / accept / avoid / transfer / cancelled) maps onto CMDash's risk status, and the justification column carries over as the risk's notes. What does not carry over: inherent/residual probability and impact, linked assets/threats/vulnerabilities/ applied controls, owners, and qualifications — CMDash's risk register has no equivalent slots for these.

Third parties (entities)

A CMDash vendor is created for every entity row with a name, honouring your plan's vendor-register capacity: a Starter, Essentials or Command workspace without the Third-Party Risk Management add-on holds a 5-vendor lite register, and rows beyond the remaining slots in that register are reported — never created — with the same message you would see adding a sixth vendor by hand. What does not carry over: country, currency, legal identifiers (LEI/EUID/DUNS/VAT), the stakeholder-assessment scores (dependency/penetration/maturity/trust) CISO Assistant tracks per entity, website, industry, and parent-entity hierarchy — none of these has a CMDash vendor-record equivalent.

Common questions

Why does the importer only recognise some frameworks? It maps onto whatever CMDash's own catalog ships. A framework CISO Assistant supports that CMDash does not ship (NIS2, for one — CISO Assistant has a library for it; CMDash has no catalog slug for it at all) is reported as an unresolved framework, by name, rather than silently dropped.

My export uses a column name this guide does not list — what happens? Nothing is guessed. The report names your header row and says which required column it could not find a match for, so you can either rename the column or send the header row to CMDash support to have the accepted spellings extended.

Can I run this from the app instead of the API? Not yet — see "Before you start" above.

Is my data safe to paste into a request body? The endpoint requires your own workspace's OWNER or ADMIN bearer token and writes only into the tenant that token belongs to; it is not a public endpoint.

Related

• Migrate from another GRC tool — the in-app page this guide's "Running a dry run" section describes, covering all four supported tools.
• /switch/ciso-assistant — the public capability table this guide mirrors, with the full column-by-column reference for every field CMDash reads.
• Risk Register — where imported risk scenarios land.
• Vendors (TPRM) & Questionnaires — where imported third parties land, and the vendor-register-lite cap this guide's "Third parties" section describes.
• Policies and Attestations — CMDash's starter policy templates, which the Policies import matches titles against.