3.1.22 — Keep CUI Off Public Systems

The One-Liner

One accidental CUI upload to your public website is a reportable incident. Have a review process before anything goes public.

What It Says

Control CUI posted or processed on publicly accessible systems.

What It Actually Means

Prevent CUI from reaching anything publicly accessible — your website, public file shares, public APIs, social media, or any system the public can reach.

Three controls:

1. Limit who can publish — only designated people can post to public-facing systems
2. Review before publishing — every piece of content is checked for CUI before it goes live
3. Have a response plan — if CUI is accidentally posted, you can remove it fast and report the incident

Don’t forget document metadata — author names, tracked changes, comments, and embedded data can contain CUI even if the visible content doesn’t.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are authorized publishers identified?	A list of who can post to public systems
2	Are review procedures in place?	Content checked for CUI before publication
3	Is there a review process before posting?	Formal approval workflow, not just trust
4	Is published content reviewed for CUI?	Periodic checks of what’s already public
5	Can improperly posted CUI be removed quickly?	A documented response process

---

What to Have Ready on Assessment Day

Documents they’ll review: Access control policy, public content procedures, system security plan, list of authorized publishers, training records, content review records, incident response records, audit logs

People they’ll talk to: Personnel managing public-facing content, information security staff

Live demos they’ll ask for: “Walk me through your content review process. How quickly can you remove improperly posted content?”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Who is authorized to post content to public-facing systems?”
• “What review process ensures CUI doesn’t end up on public systems?”
• “Has CUI ever been accidentally posted? What happened?”
• “How quickly can you remove improperly posted content?”

Real-World Example

A contractor’s website publishing workflow: marketing drafts content, a security-designated reviewer checks for CUI and sensitive information (including metadata scrubbing), then approves publication. Only two people have publish access. If CUI is found on a public page, the documented response process requires removal within one hour and incident reporting within four hours.

---

Where Companies Trip Up

No review process. Content goes to the website with no security review.

Too many publishers. Everyone in marketing can post with no oversight.

No response plan. If CUI is accidentally posted, there’s no defined process to handle it.

Metadata leakage. Documents posted publicly with CUI in author names, comments, tracked changes, or embedded objects.

---

How to Talk About This

To a CEO or Board

We have a formal review process before anything goes on our public-facing systems. Only two people can publish, and everything is checked for sensitive content first.

To an Engineering Team

Restricted publish access to two accounts. Content approval workflow with security review step. Metadata scrubbing on all public documents. Response SLA: CUI removal within 1 hour, incident report within 4 hours.

---

Connected Requirements

Requirement	Why it matters here
3.1.3 — Where CUI Can Flow	Public systems are a prohibited CUI destination
3.8.4 — Mark Your CUI	CUI markings make it identifiable during review

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: AC.L2-3.1.22 | SPRS Weight: 1 point | POA&M Eligible: Yes