Sensitive data, CUI/ITAR and your compliance scope

In short

• Do not put Controlled Unclassified Information (CUI), ITAR technical data, other export-controlled technical data or classified information in CMDash Cloud.
• CMDash Cloud runs in the commercial AWS region us-east-1. It is not hosted in AWS GovCloud (US) and holds no FedRAMP authorization.
• When CUI has to sit with your compliance records, run the self-hosted edition inside your own boundary. Coming soon

What to keep out of CMDash Cloud

CMDash holds no FedRAMP authorization or FedRAMP Moderate equivalency, no DoD Impact Level authorization and no authorization to store, process or transmit CUI, and it makes no claim that the hosted service meets ITAR requirements. So none of the following may be uploaded to CMDash Cloud, typed into it, or synced into it from a connected tool:

• Controlled Unclassified Information (CUI). Including Controlled Technical Information and covered defense information under DFARS 252.204-7012.
• ITAR technical data and other export-controlled technical data. Data controlled under the ITAR or the Export Administration Regulations, whatever its marking.
• Classified information. At any level.
• Documents your organization marks as CUI. For example a system security plan, network diagram or asset inventory that carries a CUI marking.

The rule covers every part of the product: evidence files, descriptions and notes, comments, risk and policy text, questionnaire answers, and the system security plan and POA&M you build. Your SSP in CMDash can say which CUI categories you handle and where CUI lives; it must not contain the CUI itself. The rule also covers CMDash support: do not send CUI or export-controlled data in a ticket, an e-mail, a screen share or an attachment, whichever deployment you run.

If an evidence file contains CUI, redact it before you upload it, or keep it inside your enclave and attach a link or a short narrative that says where it is and who can see it. CMDash does not inspect uploads for CUI markings, so keeping CUI out is part of your own process.

Before you connect a tool that watches systems holding CUI, check what it sends. CMDash Cloud stores the records a tool syncs, such as vulnerability findings with host names, account lists with names and e-mail addresses, device inventory and cloud configuration findings. Host names and asset tags sometimes carry CUI.

Why the line is drawn here: DFARS 252.204-7012 lets you use an external cloud service provider to store, process or transmit covered defense information only if the provider meets security requirements equivalent to the FedRAMP Moderate baseline and the clause’s cyber-incident reporting and forensic-access requirements. CMDash Cloud does not meet that condition.

What CMDash Cloud stores, and where

CMDash Cloud runs in a single commercial AWS region, us-east-1 (US East, N. Virginia), not in AWS GovCloud (US). Its database, the files you upload, the reports and exports it generates, and the database’s automatic backups with point-in-time restore are all kept in that region.

• Account data. Names, work e-mail addresses, roles and sign-in settings for the people in your workspace.
• Your program. Framework and control status, policies, risks, exceptions, vendor records and questionnaires, and the SSP and POA&M content you write.
• Evidence. The files you upload (screenshots, documents, configuration exports), links and written narratives, and the reports and exports CMDash builds from them.
• Data from connected tools. What each tool syncs, for example vulnerability findings, identity and MFA coverage, device inventory and cloud configuration findings, and the credentials for each connection.
• Activity. An audit log of who changed what in your workspace.

Other service providers process limited data for specific purposes, such as sending e-mail or taking payment. Each is listed with its purpose, the data it receives and its region at https://www.cmdash.com/trust/subprocessors.

How CMDash fits your assessment scope

Your assessor decides how CMDash is scoped in a CMMC assessment. Two things drive that decision: the data you put in it, and what you let it do.

• CUI. If you follow the rule above, CMDash Cloud does not store, process or transmit CUI.
• Security Protection Data. If you connect tools that watch assets inside your assessment scope, CMDash Cloud stores data about their configuration and vulnerability status. The CMMC Program rule, 32 CFR Part 170, calls that Security Protection Data, and a provider that stores it for you can count as an External Service Provider.
• Changes in your tools. CMDash changes something in a connected tool, such as opening a ticket or deactivating an account, only after write-back is switched on for the workspace and a user approves that change in CMDash. Every workspace starts in preview, where CMDash shows the change it would send and sends nothing.

However your assessor classifies it, record CMDash in your system security plan: what you use it for, what it connects to, and who is responsible for what. If CMDash is treated as an External Service Provider, the rule expects its services to be documented in your SSP and described in the provider’s customer responsibility matrix. The responsibility matrix below is CMDash’s.

When CUI must stay inside your boundary Coming soon

The self-hosted edition is the same product, run on infrastructure you control, on the Enterprise plan: your own servers with Docker Compose, or your own AWS account from the CMDash CloudFormation templates, one of which is for AWS GovCloud (US).

• Its database, uploaded files and backups stay on that infrastructure.
• CMDash does not host or operate it. You decide who can reach it, including whether CMDash support ever sees it.
• With its default settings it sends no customer data to CMDash. Its license is checked offline, and the install guides list the outbound calls it makes with those settings.
• Inside your boundary it is one of your own systems. If it stores CUI, scope it as a CUI asset and apply your NIST SP 800-171 controls to it like any other system there.

Install guides: your own servers and your own AWS account.

Customer responsibility matrix

Who is responsible for what, for CMDash Cloud and for a self-hosted installation. Use it in your system security plan alongside your own control descriptions.

The hosted service’s own security posture is published at https://www.cmdash.com/trust/security, and the rest of CMDash’s security documents are on /security.