The Practical Guide to Handling CUI in Google Workspace

If your organization is a member of the Defense Industrial Base (DIB) who works on a Department of War contract, then Controlled Unclassified Information (CUI) almost certainly moves through your Google Workspace every day. It is in the emails sent between a program manager and  a subcontractor, the requirements document drafted in Google Docs, and the spreadsheet of part numbers saved in your Google Drive. The compliance question that decides your CMMC posture is not whether CUI is in Workspace. It is whether the protection required by your contract travels with that data after it’s created.

‍

This guide answers the questions DIB compliance leads, FSO-equivalent roles, and CUI program owners search for most, and then connects them to one practical point: CUI does not stop being CUI when it lands in Gmail, Docs, or Drive. The handling obligation attaches to the data object, so your controls have to as well.

What is the purpose of the ISOO CUI Registry?

‍

The Information Security Oversight Office (ISOO) CUI Registry is the federal government's single online repository for all approved CUI categories, markings, and handling guidance. Its purpose is to standardize how every executive branch agency designates, safeguards, disseminates, marks, and disposes of CUI, so that "Confidential" or "FOUO" stops meaning something different at every agency.

‍

The registry exists because Executive Order 13556 (2010) created one government-wide CUI program and named the National Archives and Records Administration (NARA) as its Executive Agent. NARA delegates that authority to its ISOO, which maintains the registry and oversees agency compliance. The legally binding rules sit in 32 CFR Part 2002; the CUI Registry at the National Archives is where you look up which category applies and what controls it carries.

‍

For a contractor, the practical use is direct: when a contract or a marking references a category, the registry tells you the authority behind it and the safeguarding that authority requires.

‍

What is CUI Basic, and what is CUI Specified?

‍

These two terms decide how much protection a given piece of CUI needs, and contractors get the distinction wrong often enough that it shows up in assessment findings.

• ‍CUI Basic is information that a law, regulation, or government-wide policy requires you to protect, but for which that authority specifies no particular controls. CUI Basic defaults to the uniform baseline: the safeguarding requirements in 32 CFR Part 2002 and, for contractor systems, NIST SP 800-171.‍
• CUI Specified is information for which the underlying law or regulation does specify particular controls beyond that baseline. ITAR (International Traffic in Arms Regulations) controlled technical data and Export Administration Regulations data are common examples. Where the authority names a control, you follow it; where it is silent, CUI Basic handling fills the gap.‍
• The 32 CFR 2002 definition draws the line plainly: an authority that requires protection but provides no specific controls makes the information CUI Basic; an authority that provides specific controls makes it CUI Specified (eCFR, 32 CFR 2002.4). The consequence is not academic. The penalties for mishandling CUI Specified are typically higher because a specific statute is in play, so misclassifying Specified data as Basic understates your obligation.

Who is responsible for protecting CUI?

‍

Every authorized holder of CUI is responsible for protecting it. An authorized holder is anyone who lawfully possesses or has access to the information, and that includes contractors and subcontractors, not only the government.

‍

Inside a DIB contractor, the responsibility is shared rather than owned by one person:

• Senior leadership owns the organization's overall NIST 800-171 posture and its DFARS 252.204-7012 attestations.
• The CUI program manager or ISSO runs the program, training, and incident response.
• System administrators and security engineers implement and maintain the technical controls.
• Every individual with CUI access applies markings correctly, follows handling rules, and reports incidents.

The federal baseline obligation is to establish controlled environments that prevent unauthorized access and to protect the confidentiality of CUI you process, store, or transmit (DoD Instruction 5200.48). In a Google Workspace environment, "controlled environment" is not just a locked room. It is the access policy on the document and the key that decrypts it.

‍

Who is responsible for applying CUI markings?

‍

The authorized holder who creates the document or material is responsible for determining, at the time of creation, whether the information is CUI, and if it is, for applying the correct CUI markings and dissemination instructions. Within a federal agency, a CUI designating official makes the initial determination; once CUI is in your hands as a contractor, you must preserve existing markings and carry them onto any derivative or newly created document (DoDI 5200.48).

‍

In practice this is usually the project lead, engineer, or technical writer producing the work, not a central compliance office reviewing everything after the fact. That is exactly why marking fails in email and documents: it depends on a busy person remembering to do it correctly, every time, in the compose window.

CUI documents must be reviewed according to which procedures before destruction?

‍

Before CUI is destroyed, it must be reviewed against your records management schedule and any applicable retention or legal requirements. The review confirms three things: that the record is no longer subject to a federal records retention requirement, that it is not under a current or anticipated litigation hold, and that its CUI status and category are correctly identified, typically with a designated records manager involved.

‍

Only after that review may you destroy it, and the destruction itself must render the CUI unreadable, indecipherable, and irrecoverable, using methods consistent with NIST SP 800-88 such as shredding, pulverizing, or cryptographic erase for digital media (NIST 800-171 control 3.8.3). The order matters: review first, destroy second. Skipping the retention and legal-hold review to clear out old files is its own finding.

‍

Cryptographic erase is worth a pause. If the data was encrypted at the object level and you destroy the key, the data becomes unrecoverable regardless of where copies traveled. That is only true if the protection was bound to the data in the first place, which is the through-line of this guide.

‍

Where Google Workspace helps vs. where the gap is

‍

Google Workspace gives DIB contractors a real foundation. Google Assured Workloads with Assured Controls can provide a US-personnel, US-region environment that supports ITAR and CMMC 2.0 obligations when it is configured correctly. That handles where the data lives and who administers it.

‍

What it does not do by itself is make the protection travel with the data object once an authorized user shares, forwards, or downloads it. Encryption at rest decrypts the moment an authorized identity opens the file. A classification marker tells a human the data is CUI; it does not stop the file from being forwarded to someone without authorization. Those are different jobs, and conflating them is the most common Workspace CUI mistake.

‍

This is where a data-layer approach fits. Qanapi's position is that identity, policy, and encryption should be bound to the data object itself, so the safeguarding obligation moves with the CUI rather than staying behind with the inbox or folder.

‍

On Google Workspace today:

• Live Redaction for Google Docs and slides encrypts text inline, from a single word to a whole document. Users with the matching classification level see the decrypted text; users without it see a placeholder, while collaborating in the same file. It uses FIPS 140-3 validated, quantum-resistant cryptography and is ITAR and CMMC 2.0 compliant when paired with Google Assured Controls Plus on Assured Workloads, appropriately configured.
• Email Data Classification for Gmail inserts plain-text CUI, CDI, FCI, or Confidential markers into the subject and body so the marking survives in any mail client. Worth stating plainly so no one over-relies on it: this is a labeler, not an encryptor. It marks the email; it does not encrypt the body or attachments and does not control access after sending. Use it for the marking obligation above, not as the protection control.
• Hosted S/MIME allows you to send and receive sensitive information in Gmail, by managing and validating encryption certificates for Secure/Multipurpose Internet Mail Extensions (S/MIME).

‍

The honest version: protection that travels with the data is the architectural goal, and the Docs and Slides encryption is where that is shipping on Workspace today. It does not extend to Gmail attachments or to Drive files outside Docs and Slides. Knowing exactly which control covers which obligation is the difference between an audit-ready program and a surprised one.

‍

The takeaway

CUI keeps its handling obligation wherever it goes, so the most durable thing you can do is attach the control to the data rather than to the perimeter around it. Get the basics right first: use the CUI Registry to confirm categories, classify Basic versus Specified correctly, mark at creation, and review records before you destroy them. Then close the gap that Workspace alone leaves by binding encryption and policy to the CUI objects that matter most.

‍

If you want to see what object-level encryption looks like inside a Google Doc or Slide, you can start a 30-day free trial of Live Redaction or read more about the data-layer approach on our blog.

‍