Your data can always leave

A data export is a snapshot of every table in CMDash that carries your organization’s data — not a hand-picked subset. Coverage is determined by scanning CMDash’s own live database schema for anything scoped to your organization, so a newly shipped feature is covered automatically the moment it ships, without anyone having to remember to add it to an export list by hand.

As of 2026-09-03, that is 182 tables — 168 directly, plus 14 more resolved through a parent record (for example, an invoice line item is reached through the contract it belongs to). This number grows over time as CMDash ships new capability; treat it as a snapshot, not a ceiling. Every current customer can see the always-current, authoritative figure themselves, inside the product, without asking CMDash: any Owner or Admin can call GET /data-export/plan — a manifest of exactly what is included and excluded, and why, with no row data in the response — before ever running a real export.

Each export produces two things in one job: a JSON archive (the complete, canonical record — the same one a re-import reads back) and a CSV bundle, one file per table, for opening directly in a spreadsheet or loading into another system. A column that holds nested data — a JSON configuration blob, for instance — appears in the CSV as that value’s JSON text in a single cell rather than being silently dropped or approximated.

A short, published list of tables is withheld from every export — every one of them live credential or session material, or internal CMDash operations data that was never your organization’s content to begin with. Nothing is excluded because it would be inconvenient to include.

This is the same list GET /data-export/plan returns live, with the same reasons — this page does not maintain a separate copy that could quietly drift from what the API actually does.

An export you cannot use anywhere else is not much of an exit guarantee. On a self-hosted or licensed CMDash deployment (on-prem or customer-AWS), the importer takes that same archive and loads it back into a fresh, empty CMDash tenant. It is a real, authenticated write path, not a script someone ran once: every tenant reference in the archive is remapped by name and checked against the real database’s foreign-key constraints as it writes, and the import refuses outright — rather than silently merging — if the destination tenant already has any data in it, so a retry always starts from a clean, predictable state.

This path is exercised by an automated test that exports a tenant with real data across multiple tables, imports the archive into a fresh tenant, and checks that row counts, business content, and cross-table references all came back correctly — against a real PostgreSQL database with the same row-level security enforced in production, not a simplified stand-in.

On the hosted multi-tenant service the round trip is not self-service. You can export your data there, but the import routes refuse an uploaded archive with the error DATA_IMPORT_SELF_HOSTED_ONLY, because a restore writes into a workspace on infrastructure every customer shares and an uploaded archive is untrusted input. To move hosted data to a self-hosted deployment, or back, contact security@cmdash.com. See the exit guarantee for what each deployment type does.

The JSON archive carries an explicit format version, so a future structural change is never silent — the CSV bundle produced alongside it is generated from that exact same snapshot in the same job, so the two can never disagree about which tables or rows they cover. For a first release, CMDash is not committing the CSV layout to its own independent version number: because both formats always come from one identical snapshot, tying the CSV to the JSON archive’s version is simpler and cannot drift, and is revisited only if the two formats' structures ever need to diverge.

Separately, for organizations that have assessed themselves against a specific compliance framework, CMDash can also produce a framework-specific submission document (an OSCAL system-security-plan, component definition, or assessment-results file) — a narrower, differently-shaped artifact for a specific audit process, not a substitute for the full export above and not replaced by it. That capability exists today; there is no dedicated in-product download button for it.