Module 9: Practical Handling – Marking, Access, and Lifecycle of CUI

Step 1 – Where This Fits: CUI Handling in Real IT Environments

In earlier modules you saw:

• Module 7 – how FAR, DFARS, and contracts create CUI obligations.
• Module 8 – how CUI maps to FedRAMP and cloud impact levels.

Now we focus on day‑to‑day handling:

• How CUI is marked in documents and systems
• How users get access (and are restricted) to CUI
• How CUI is stored, transmitted, backed up, and logged
• How CUI is retained and destroyed at end of life

Current Regulatory Context (as of late 2025)

The main sources you should connect to this module are:

• 32 CFR Part 2002 – CUI program rule (implements E.O. 13556)
• NIST SP 800‑171 Rev. 3 – security requirements for CUI in non‑federal systems (finalized 2024)
• NIST SP 800‑53 Rev. 5 – control catalog underlying many federal baselines
• DoD CUI Registry and agency‑specific CUI registries

Historically, agencies used many labels (FOUO, SBU, etc.). Today, those are largely superseded by the unified CUI framework. You may still see legacy labels, but your system configuration and procedures must follow current CUI rules, not the old ones.

In this module, imagine you’re an IT service provider supporting:

• A SaaS ticketing system used by a civilian agency, and
• A DoD contractor network with CUI//SP‑CUI (e.g., export‑controlled data)

You will learn how to design and operate these systems so they actually comply with CUI handling requirements, not just on paper.

Step 2 – CUI Markings: What You Need to Recognize

CUI must be marked so that people and systems know how to handle it.

1. Basic CUI Marking Elements

On documents and screens you will typically see:

• CUI banner (top and bottom of page or display)
• Portion markings (optional but common in some agencies)
• Dissemination controls (e.g., NOFORN, DL ONLY) when allowed by policy
• Contact / authority line (who applied the marking, or reference to guidance)

2. Example CUI Markings (Plain Language Descriptions)

Common banner styles (visualized in words):

• `CUI` – simple banner for CUI Basic
• `CUI//SP-EXPT` – CUI with a Specified category, e.g., export control
• `CUI//SP-PRVC` – CUI with a privacy category (example pattern)
• `CUI//SP-CTI` – Controlled Technical Information (DoD context)

You might see a header bar in a PDF or web app that looks like:

> [Bright orange bar across the top]: `CUI//SP-EXPT`

> [Footer bar]: `CUI//SP-EXPT` – Handle in accordance with DoD Instruction XXXX

3. Portion Markings (Inside the Document)

Some documents mark each paragraph or table cell, for example:

• `(CUI)` – this paragraph contains CUI
• `(U)` – unclassified

Example paragraph markings (described):

• Heading: `CUI//SP-EXPT`

Body paragraph 1 label: `(U)` – general background

Body paragraph 2 label: `(CUI)` – specific export‑controlled specs

4. Why IT People Must Care

As an IT provider, you use markings to:

• Configure data labeling in tools (e.g., Microsoft Purview, Google labels)
• Drive DLP rules (e.g., block sending `CUI//SP-EXPT` to personal emails)
• Configure access policies (e.g., only certain groups can open `SP-CTI` data)
• Tune logging and monitoring (e.g., extra alerts for downloads of SP‑CUI)

When you see a CUI marking, you should immediately think:

> “What technical controls should be triggered by this label?”

Step 3 – Quick Label Recognition Exercise

Imagine you’re looking at a shared drive folder called `/Projects/DroneDesign`. Inside you see three files with visible headers:

1. File A – `DroneSpecs_v3.docx`

Header text: `CUI//SP-CTI`

Footer text: `CUI//SP-CTI – Controlled Technical Information – DoD`

1. File B – `BudgetSummary_FY25.xlsx`

Header text: `CUI`

No specified category in the banner.

1. File C – `MarketingFlyer_Public.pdf`

Header text: `UNCLASSIFIED`

No CUI markings.

Thought Exercise:

1. Which file(s) clearly contain CUI Specified?
2. Which file(s) contain CUI Basic (if any)?
3. Which file(s) should be treated as non‑CUI for handling purposes?
4. As the IT admin, name two technical controls you would apply specifically to `CUI//SP-CTI` files.

Pause and answer in your own words, then compare with the guidance below.

---

Suggested Answers (for self‑check):

1. CUI Specified: File A (`CUI//SP-CTI`) – the `SP-` prefix and `CTI` category indicate a specified type.
2. CUI Basic: File B (`CUI` with no `SP-` category) – typical of CUI Basic.
3. Non‑CUI: File C (`UNCLASSIFIED` only) – unless another policy applies, it’s handled as non‑CUI.
4. Example IT controls for `CUI//SP-CTI`:

• Restrict access to a CTI‑cleared group in your IdP/AD.
• Enforce encryption at rest and TLS 1.2+ in transit.
• Block sharing outside the approved tenant/domain.
• Enable detailed access logging and anomaly alerts.

Step 4 – Access Control and Least Privilege for CUI

CUI access is governed by “lawful government purpose” and need‑to‑know, implemented technically as least privilege.

Key references:

• 32 CFR 2002.14 – CUI safeguarding and access
• NIST SP 800‑171 Rev. 3 – especially Access Control (AC) and Identification and Authentication (IA) families

1. Core Principles

• Least privilege: Users get only the CUI access they need to do their job.
• Separation of duties: Critical actions (e.g., data export) may require different roles.
• Accountability: Every access is tied to a unique user identity.
• Revocation: Access must be removed promptly when a user changes roles or leaves.

2. Practical Access Patterns

In a typical cloud or on‑prem system, you implement:

• Role‑Based Access Control (RBAC)
• Roles like `CUIBASICUSER`, `CUISP-CTIADMIN`, `CUI_AUDITOR`.
• Map roles to groups in your identity provider (Azure AD, Okta, etc.).

• Attribute‑Based Access Control (ABAC) (where supported)
• Decisions based on data label + user attributes (e.g., project, clearance, org).
• Example: Only users with `attribute: program = DRONE-X` can open `CUI//SP-CTI//DRONE-X`.

• Multi‑Factor Authentication (MFA)
• Enforced for all CUI systems, especially for remote or privileged access.

3. Common Access Control Mistakes

• Putting CUI in a “general” shared drive accessible to the whole company.
• Granting access to email distribution lists instead of specific people.
• Not removing access when a project ends or a person changes teams.
• Allowing service accounts broad access to CUI without tight controls.

As an IT provider, your job is to make sure the technical configuration aligns with the markings and the contractual scope (from Module 7).

Step 5 – Quick Access Control Check

Choose the best answer based on NIST SP 800‑171 principles and CUI rules.

Step 6 – Secure Storage, Transmission, and Backup of CUI

IT providers must ensure CUI is protected everywhere it lives or moves.

Key references:

• NIST SP 800‑171 Rev. 3 – especially SC (System and Communications Protection), MP (Media Protection), CP (Contingency Planning)
• FedRAMP baselines (from Module 8) for cloud environments

1. Storage (At Rest)

Technical expectations:

• Encryption at rest using FIPS‑validated modules where required (e.g., DoD contracts).
• Store CUI only in authorized locations (approved cloud regions, data centers).
• File and database permissions aligned with RBAC/ABAC.
• Endpoint protections (EDR, full‑disk encryption) for devices that store CUI.

Example:

• A PostgreSQL database in a FedRAMP Moderate cloud, disk volumes encrypted with FIPS 140‑3 validated crypto, access restricted via private subnets and security groups.

2. Transmission (In Transit)

Technical expectations:

• Use TLS 1.2+ (strong ciphers) for all web/API traffic carrying CUI.
• Use VPN or equivalent secure tunnels for remote admin access.
• For email: use end‑to‑end encryption or at least TLS and DLP policies.

Example policies:

• Block sending messages labeled `CUI` to external domains unless explicitly whitelisted.
• Require S/MIME or similar encryption for CUI attachments sent outside the agency network.

3. Backups and Logs

CUI in backups and logs is still CUI:

• Backups must be encrypted, access‑controlled, and stored in approved locations.
• Logs containing CUI (e.g., full URL paths, query parameters, payloads) must be:
• Minimized (avoid logging sensitive content where possible).
• Protected with the same or stronger controls as production data.
• Test restores must follow the same safeguards as production.

4. Multi‑Tenant Cloud Considerations

For cloud service providers:

• Ensure logical separation of tenants is robust (e.g., per‑tenant keys, strong IAM boundaries).
• Confirm your FedRAMP authorization level is sufficient for the CUI impact level.
• Make sure sub‑processors / sub‑service organizations also meet CUI requirements.

Step 7 – Example: Tagging and Protecting CUI in a Cloud App

Below is a simplified example (Python + pseudo‑config) showing how an internal app might:

1. Tag records as CUI or non‑CUI
2. Enforce role‑based access
3. Require encryption in transit

This is illustrative, not production‑ready.

Step 8 – Retention, Disposal, and Sanitization of CUI

CUI has a lifecycle: collection → use → sharing → storage/backup → archival/retention → disposal.

Key references:

• 32 CFR 2002.18 – CUI decontrol and destruction
• NIST SP 800‑88 Rev. 1 – media sanitization
• NIST SP 800‑171 Rev. 3 – MP (Media Protection) and CP (Contingency Planning)

1. Retention

Retention is usually driven by:

• Agency records schedules and contract terms
• Legal holds (for investigations or litigation)

IT responsibilities:

• Implement automated retention policies (e.g., delete or archive after X years).
• Ensure backups follow the same retention rules.
• Coordinate with records officers before deleting anything under legal hold.

2. Disposal and Decontrol

When CUI is no longer needed, it must be:

• Decontrolled (officially removed from CUI status) or
• Destroyed so it cannot be reconstructed.

For electronic media, use:

• Clear (logical overwrite) when media will stay in the same security environment.
• Purge (e.g., cryptographic erase) for stronger protection.
• Destroy (e.g., physical shredding, pulverizing) when media is leaving control.

Examples:

• Virtual disks in a cloud: use provider’s cryptographic erase function and verify logs.
• Old backup tapes: send to an approved destruction service; obtain certificate of destruction.

3. Common Pitfalls

• Forgetting CUI in system logs, debug dumps, or test environments.
• Keeping backups containing CUI longer than allowed by the contract.
• Failing to sanitize developer laptops or portable drives used for CUI projects.

As an IT provider, you should know: “Where does CUI live in my environment, and how will it be securely removed when the contract or retention period ends?”

Step 9 – Lifecycle Mapping Exercise

You are a managed service provider (MSP) hosting a ticketing system for an agency. Some tickets contain CUI Basic related to security incidents.

Scenario: A typical CUI‑containing ticket goes through these stages:

1. User submits a ticket with incident details.
2. Analysts investigate, attach logs and screenshots.
3. Ticket is resolved and closed.
4. Tickets are retained for 7 years per contract.
5. After 7 years, tickets and related artifacts must be disposed of.

Task: For each stage, list at least one technical control you would implement.

Use this structure in your notes:

• Stage 1 – Collection: (e.g., TLS for web form, input validation, etc.)
• Stage 2 – Analysis: (e.g., role‑based access, secure workstations, etc.)
• Stage 3 – Closed: (e.g., restrict edits, archive state, etc.)
• Stage 4 – Retention: (e.g., WORM storage, retention policies, etc.)
• Stage 5 – Disposal: (e.g., scheduled deletion, backup purge, sanitization logs, etc.)

After you draft your answers, compare with the sample mapping below.

---

Sample Mapping (for self‑check):

• Stage 1 – Collection
• Enforce HTTPS (TLS 1.2+) for ticket submission.
• Use CAPTCHA and auth to prevent anonymous spam with CUI.

• Stage 2 – Analysis
• Limit access to a CUI_Incident_Analyst role.
• Require MFA and full‑disk encryption on analyst workstations.
• Prevent analysts from copying CUI to personal cloud drives (DLP).

• Stage 3 – Closed
• Mark ticket as read‑only except for authorized auditors.
• Preserve audit logs of all access and changes.

• Stage 4 – Retention
• Apply a 7‑year retention label to tickets and attachments.
• Ensure backups reflect the same retention schedule.

• Stage 5 – Disposal
• Run a scheduled job that deletes tickets older than 7 years and flags them for backup deletion.
• Use cryptographic erase for storage volumes retired from the service.
• Keep sanitization records for compliance audits.

Step 10 – Flashcard Review of Key CUI Handling Concepts

Flip through these cards to reinforce the most important ideas from this module.