This control is often overlooked because small contractors don’t think of their public websites as security-relevant. But if CUI accidentally ends up on your public website or social media, that’s a failure. The assessor is checking whether you have a process to prevent that. This is the public side of CUI boundary protection covered more broadly in SC.L2-3.13.1 and AC.L2-3.1.20 (external connections).
What the assessor is actually evaluating
The NIST language says “control information posted or processed on publicly accessible information systems.” The assessor is checking:
Do you have a process for managing public information? Is there a documented procedure for what can be posted on your website, who approves it, and how you prevent CUI from being included?
What systems are public-facing? Can you identify all the systems you maintain that are accessible to the public? This includes websites, social media, cloud storage, GitHub repos, or any service that doesn’t require authentication.
How do you prevent CUI from being posted? Technical controls might include preventing certain file types from being uploaded, restricting who can post, or reviewing all public content before publication. Policy controls might include training or explicit restrictions on CUI handling.
Do you review public information? The assessor wants to know that someone periodically checks what’s publicly visible to catch any accidental disclosures.
What a realistic SSP definition looks like
[Organization Name] identifies and controls information posted on publicly accessible information systems. Our public information systems include our company website, social media accounts, and any other platforms or services accessible without authentication.
All information posted on public systems is approved by the Marketing Director (or equivalent) prior to publication. Public content is reviewed to ensure no Controlled Unclassified Information (CUI) is included. CUI is never intentionally posted to public systems. Employees are trained that public systems are not appropriate for CUI.
For the company website, content is submitted through a ticketing system, reviewed, and published only after approval. Social media posts are drafted, reviewed, and scheduled through [platform / internal process]. GitHub repositories containing code are reviewed to ensure no API keys, credentials, or CUI are included in commits.
Public information systems are reviewed monthly for unapproved or inappropriate content. Any public information containing CUI is immediately removed and investigated.
The key points: identified public systems, approval process for content, explicit CUI restriction, and periodic reviews. Training employees on CUI boundaries also supports the identification and awareness required under IA.L2-3.5.2 (authentication management).
How to present your evidence
- Public Information Control Policy
- List of all public information systems your organization maintains
- Content approval process for public postings (tickets, forms, etc.)
- Evidence of periodic reviews of public information systems
- Training materials covering CUI and public systems
- Incident records for any CUI accidentally posted (if applicable)
List of public systems. Your company website, any public cloud storage accounts, social media pages, public repositories, forums, or any system the public can access. Be complete. If you have a LinkedIn page, it goes on the list.
Content approval process. How you control what gets posted. This might be a ticket system, an approval form, a workflow, or a documented process. The key is that it’s defined and followed.
Policy documentation. Your policy on public information and CUI. Make it explicit: CUI must not be posted to public systems.
Review records. Evidence that you or someone on your team has periodically reviewed public information systems. Monthly is a good frequency. Show dated records of reviews.
Training. Evidence that employees have been trained about not posting CUI to public systems. This can be part of your security awareness training or a specific memo.
Incident records (if applicable). If you’ve ever accidentally posted CUI, document how you discovered it, removed it, and what you changed to prevent it happening again.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
No documented public information control policy. You have a website but no process for controlling what gets posted. This is a finding.
Can't identify all public information systems. The assessor asks "what systems are public" and you miss some. This is concerning because it suggests you're not actively managing them. Social media, public repositories, even public cloud storage shared links count.
No approval process for public content. Anything can be posted without review. If CUI ends up on your website, nobody's checking for it.
CUI is accessible on public systems. This is a critical failure. If the assessor finds sensitive information on your public website or repository, this control is failed.
No periodic reviews of public information. You have a policy but nobody actually checks what's public. Accidental exposures go undetected.
A documented list of all public systems. A formal approval process for public content. Training on CUI and public systems. Periodic reviews of public information. No CUI visible on any public platform. That's a passing control that demonstrates you understand and enforce your CUI boundaries.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
If your MSP manages your website or cloud services, they should help you control what’s published and assist with reviews.
What’s typically on you:
- Defining what is and isn’t appropriate for public posting
- Approving content before it goes public
- Training employees on CUI and public systems
- Periodic review of public information
What’s typically on the MSP:
- Managing the website platform and access controls
- Assisting with content reviews
- Helping with periodic scans of public systems
- Alerting you to any suspicious or unexpected content
In the assessment, you should be able to walk through an example of something being posted to your website and explain the approval process. The MSP can assist in pulling up the website or platform, but the control is ultimately yours.
Assessors check your public systems to look for CUI. They'll visit your website, check your social media, review your GitHub or public repositories. Have a clear list of what's public and what's not. Know your approval process for public content. Be prepared to walk the assessor through how something goes from being developed internally to being published publicly. If you discover CUI on public systems during the assessment, that's a finding.
If you use GitHub or similar platforms, I recommend setting repositories to private by default and only making them public after explicit approval. I've seen contractors accidentally commit API keys, internal URLs, or customer names to public repositories. Review commits before making repos public, and scan public repos periodically for anything that shouldn't be there. This is especially important in engineering teams that might not be thinking about CUI while coding.
This page covers AC.L2-3.1.22 from NIST SP 800-171 Rev 2 (3.1.22). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.