PII and CUI in Preview Environments: A Federal Contractor's Guide

PII in preview environments is a problem with reasonable solutions. The general guidance — synthesize, never copy production, tokenize what you must reference — is in /blog/handling-pii-preview-environment-seed-data/. CUI is different. When the data is Controlled Unclassified Information, architectural choices are constrained in ways ordinary PII isn’t, and “we use synthetic data” is no longer a complete answer.

This guide walks through the CUI categories most likely to appear in federal software contracting, the rules that constrain previews, and the patterns that work.

CUI Is a Family

CUI consolidated dozens of legacy markings (FOUO, SBU, LES) under 32 CFR Part 2002. The umbrella matters less than the specific category. The ones that show up most often in software contractors’ work:

• Controlled Technical Information (CTI). Technical data with military or space application, governed by DFARS 252.204-7012. What most DoD contractors mean by “CUI” without qualification.
• Export Controlled (including ITAR). Subject to ITAR or EAR. U.S. persons only or otherwise authorized recipients. Strictest commonly-encountered case.
• Law Enforcement Sensitive (LES). Tied to law enforcement need-to-know.
• Privacy (PRVCY). Personal information governed by the Privacy Act of 1974 and agency-specific implementations.
• Procurement and Acquisition. Source selection, contractor proposals, pre-award material.
• Critical Infrastructure (PCII). Protected under the CII Act of 2002.

Each has its own dissemination markings, handling rules, and answer to whether it can appear in a preview.

The Constraints

A preview is a copy of system state in a new place, accessible to a new audience, on a different network path. Every one of those is something CUI rules care about.

Data at rest. FIPS 140-2/140-3 validated encryption. RDS with KMS in GovCloud meets it. Default RDS encryption in commercial AWS does not, for most CUI categories.

Data in transit. FIPS-validated TLS. Most modern stacks are fine, but the CA and crypto modules matter. Verify.

Access controls. CUI requires access limited to people with a lawful basis. ITAR and most export-controlled: U.S. persons. LES: law enforcement need-to-know. Privacy: Privacy Act need-to-know. “Anyone with the link” is not an access control.

Marking. CUI requires visible markings — banner markings in the UI, document markings on PDFs, header markings on API responses. Most frameworks don’t ship with this.

Spillage handling. If CUI ends up somewhere it shouldn’t, federal rules require notification, remediation, and sometimes formal reporting. A preview tool that processes CUI becomes a place spillage can happen.

Patterns That Work

Pattern 1: Synthetic Data Only

Generate all preview data synthetically. No copies of production, no derivatives. Faker-style generators or a hand-curated dataset mirroring schema and statistical properties. /blog/synthetic-data-test-fixtures-realistic-previews/ applies directly.

Right for the majority of CUI cases and the only pattern straightforwardly compatible with most ITAR work. If reviewers need behavior on specific production records, you’re outside this pattern.

Pattern 2: Tokenized References with Detokenization at the Boundary

The preview database stores tokens — opaque identifiers referencing real records but containing none of the underlying data. The application calls a detokenization service to resolve tokens, but only for users authorized to see the underlying CUI.

Preview DB:    user_id=tok_a8f3..., name=tok_8c91..., ssn=tok_31fa...
                              |
                              v
Detokenization:   tok_a8f3 -> "12345"   (id, not CUI, returned to all)
                  tok_8c91 -> "Jane S." (name, returned per policy)
                  tok_31fa -> "***-**-1234" (PII, redacted unless authorized)

The detokenization service sits inside the authorized boundary, holds the mapping, enforces policy at request time, and logs every detokenization. The preview never holds CUI — it holds tokens. Useful when reviewers need real data shapes without the preview becoming a CUI repository.

The cost is architectural: the application must accept tokenized inputs throughout, and the detokenization service must be reliable and audited. Retrofitting is a real project; building in from the start is straightforward.

Pattern 3: Authorized Boundary, U.S.-Persons-Only Access

Preview runs entirely inside the contractor’s authorized environment with real CUI in the database, access strictly limited to authorized reviewers. Same handling regime as production, scaled-down environment.

Works for CTI and some Privacy data when reviewers need real records. Does not work well for ITAR — having data in more places increases spillage risk. For ITAR, default to synthetic.

The most expensive and most robust pattern. For high-stakes pre-deployment validation or post-incident reproduction, it’s the only pattern that answers the question.

Where Previews Are Essentially Impossible

• Classified information. Out of scope for FedRAMP and GovCloud. Classified previews require SIPR, JWICS, and certified tooling. No commercial preview tooling addresses this.
• Some IC CUI categories. Dissemination restrictions tight enough that even synthetic data is hard to implement without leaking controlled implementation details.
• LES with active operational data. Where disclosure could compromise an active operation, the answer is in-place review on production with extreme access controls, not a preview.

For these, design the system so review happens on production with strict access controls and rollback capability.

Vendor Disclosure

When a vendor processes CUI on a contractor’s behalf, the contractor inherits a documentation burden:

• Under DFARS 252.204-7012, the contractor is responsible for ensuring the vendor’s environment meets NIST SP 800-171 for any system processing covered defense information. Applies to subcontractors and SaaS vendors handling CUI in scope.
• Vendor must report cyber incidents within 72 hours per DFARS.
• Contractor must flow these requirements down in subcontracts.
• Under CMMC, these are formalized and audited at the contractor level.

A preview-tool vendor whose architecture causes them to process CUI is a subcontractor under DFARS — a category most preview-tool vendors are not prepared to be. The cleaner architecture is to deploy inside the contractor’s authorized environment so the existing DFARS posture covers it and the vendor never processes CUI. Same structural argument as /blog/preview-environments-fedramp-tool-requirements/. For CUI it’s not just a posture preference; it’s a contractual constraint flowing from DFARS and CMMC.

Decision Tree

1. ITAR or otherwise export-controlled? → Synthetic data only.
2. Genuine need for production data shapes, reviewer access tightly bounded? → Consider tokenized references.
3. CTI or Privacy with reviewers needing real records, authorized boundary in place? → Authorized boundary with U.S.-persons access is feasible.
4. One of the “essentially impossible” cases? → Don’t preview. Review on production with strict controls.

In all four, the preview tool should run inside the contractor’s authorized environment — not because the tool itself is the problem, but because anything else creates a vendor-as-subcontractor relationship most teams don’t want.

A Note on PreviewProof

Honest disclosure: PreviewProof is not currently FedRAMP authorized and is not designed to process CUI in any vendor-controlled SaaS. It deploys inside the customer’s authorized environment, so CUI stays under the customer’s existing handling regime, and it supports U.S.-persons access enforcement, marking display, and the evidence-log requirements in /blog/audit-trail-preview-environment-evidence-portable/. If you want a tool already shaped this way, it’s a candidate. The harder work — designing the application to fit the CUI regime — is yours regardless of which preview tool you pick.