CMMC Level 2 Practice 3.1.22: Control CUI posted or processed on publicly accessible systems

CMMC Level 2 Practice 3.1.22 requires you to prevent Controlled Unclassified Information (CUI) from being posted to, processed on, or exposed through publicly accessible systems unless you have explicitly authorized controls that keep the CUI protected. Operationalize it by defining what “publicly accessible” means in your environment, blocking CUI on those systems by default, and retaining evidence that the controls work. ¹

Key takeaways:

• Treat internet-facing services (public websites, public cloud shares, external ticketing portals) as “publicly accessible” unless you can prove access is restricted.
• Implement a “no CUI on public systems” rule with technical guardrails: classification, DLP, configuration baselines, and monitoring.
• Evidence wins assessments: inventory, configurations, logs, and decision records showing where CUI is allowed and why.

For most CMMC Level 2 programs, Practice 3.1.22 fails for a simple reason: teams try to solve it with a policy statement, while assessors look for real control behavior. This practice maps to NIST SP 800-171 Rev. 2 requirement 3.1.22 and focuses on one specific risk: CUI ending up on systems that are available to the general public or broadly reachable from the internet. ²

As the Compliance Officer, CCO, or GRC lead, your job is to translate the requirement into a short list of operational decisions: Which systems are “publicly accessible”? Where is CUI allowed to live and be processed? What technical controls stop mistakes (misconfigurations, oversharing links, accidental uploads, public repo commits)? Then you need repeatable evidence that the decisions are implemented and monitored.

This page gives requirement-level implementation guidance you can hand to IT, security engineering, and system owners. It prioritizes fast operationalization: scope, controls, proof, and common assessor hangups. It is aligned to CMMC’s program structure and assessment expectations under the DoD CMMC Program. ³

Requirement: cmmc level 2 practice 3.1.22: control cui posted or processed on publicly accessible systems requirement

Goal: Prevent CUI from being placed on, handled by, or exposed through systems that the public can access, unless you have explicit authorization and compensating protections appropriate for CUI.

This is an access control outcome requirement. Assessors typically expect to see: (1) you know which assets are publicly accessible, (2) you have rules that prohibit CUI there by default, (3) you enforce those rules technically, and (4) you can prove it with artifacts. ¹

Regulatory text

CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.22: “Control CUI posted or processed on publicly accessible systems.” ¹

What the operator must do: Identify any system that is publicly accessible (internet-reachable or open to general access) and implement controls so that CUI is not posted, stored, or processed there unless you have explicitly approved the use case and implemented safeguards that keep CUI protected.

Plain-English interpretation

• “Posted” includes uploading, attaching, sharing, pasting, or publishing CUI to places like public web portals, public file shares, externally accessible collaboration sites, code repositories, ticketing systems, or knowledge bases.
• “Processed” includes viewing, editing, transforming, or analyzing CUI on a system that is publicly accessible, even if the file is not permanently stored there.
• “Publicly accessible systems” usually means internet-facing systems that do not enforce strong access restrictions and are discoverable or reachable by the public. In audits, “we didn’t intend it to be public” does not help; configuration determines exposure.

A practical interpretation you can adopt: CUI may only exist in authorized enclaves and approved SaaS tenants with access controls consistent with your CUI boundary, and must not be placed in public services or public endpoints.

Who it applies to

Entities: DoD contractors and subcontractors that handle CUI and are seeking or maintaining CMMC Level 2 certification. ³

Operational context (where this bites in real life):

• Marketing/public website teams that copy contract details into public pages.
• HR/recruiting posting position descriptions that include CUI program details.
• Engineering pushing CUI into public Git repositories or public issue trackers.
• Users creating “anyone with the link” sharing links in cloud storage.
• Customer support using an internet-facing ticketing portal where attachments or case notes include CUI.
• Third parties (managed service providers, consultants) handling your CUI on their platforms outside your authorized boundary.

What you actually need to do (step-by-step)

Step 1: Define “publicly accessible” for your environment

Create a short definition and decision rule that security and system owners can apply consistently:

• Internet-facing endpoints (public IP, public DNS, externally routable) count as publicly accessible.
• SaaS with anonymous access, guest access, or link-based sharing counts as publicly accessible unless restricted and logged.
• Public code hosting, public paste sites, and public collaboration boards are always publicly accessible.

Document the definition in your access control standard and reference it in your CUI handling policy. ²

Step 2: Inventory publicly accessible systems and services

Build and maintain a list of:

• Public web properties (sites, subdomains, CDN buckets, web apps).
• External collaboration and file sharing services.
• Internet-facing ticketing, chat, and knowledge base platforms.
• Public repositories and dev tooling that can be externally accessed.
• Cloud resources that can be made public through configuration (storage buckets, blobs, static site hosting).

Minimum operational output: an inventory table with system owner, purpose, exposure method, and whether CUI is permitted (default: No).

Step 3: Decide where CUI is allowed (your authorized CUI boundary)

Create a clear “CUI allowed systems list” (allowlist). Everything else is deny-by-default.

• If your organization uses a CUI enclave, list the enclave systems and approved SaaS tenants inside the boundary.
• If a business unit claims they “need” CUI in a public-facing workflow, require a risk exception and a design review.

Tie this to your System Security Plan (SSP) and boundary narrative for CMMC readiness. ⁴

Step 4: Implement technical guardrails that prevent CUI exposure

Assessors look for enforceable controls, not just training.

Recommended control stack (choose what fits your architecture):

• Data classification + labeling: Make CUI identifiable (labels/metadata/bannering) so other controls can act on it.
• DLP controls: Block or warn on uploading CUI to unsanctioned domains, public sharing links, or public repos.
• Cloud configuration controls: Prevent public access at the configuration layer (for example: storage public access disabled; external sharing constrained).
• Access restrictions: Require authenticated access with least privilege for any system that processes CUI.
• Egress controls: Restrict outbound data transfers from CUI environments to public services where feasible.
• Monitoring and alerting: Alerts for “public exposure” events (public link created, bucket made public, repo made public) and for suspected CUI exfiltration attempts.

Your goal is to make the wrong action hard to perform and easy to detect.

Step 5: Put an approval workflow around any exception

If you must post/process CUI in an externally accessible system, treat it as an exception with a paper trail:

• Business justification and CUI type.
• Security design (access controls, encryption, logging, retention).
• Owner accountability.
• Time-bounded approval and periodic review. Keep exceptions rare; a long exception list signals weak boundary discipline.

Step 6: Train users on the “public system” failure modes

Training must be specific:

• “Anyone with the link” is public for CUI purposes unless explicitly approved.
• Public issue trackers and public repos are prohibited for CUI.
• External portals require approved configurations before uploading CUI. Focus training on the systems your people actually use. ²

Step 7: Test and collect recurring evidence

Run periodic checks:

• Scan for publicly exposed cloud storage and public sharing settings.
• Review public repos for sensitive content patterns.
• Sample tickets/cases for improper attachments.
• Validate DLP policies are active and generating events.

Set a cadence and keep artifacts from each run.

Required evidence and artifacts to retain

Keep evidence that shows both design and operation:

Governance and scope

• CUI handling policy and “publicly accessible systems” definition ²
• CUI boundary statement and system categorization notes ⁴
• System inventory: publicly accessible systems list; CUI allowlist

Technical configuration

• Screenshots/exports of cloud tenant sharing restrictions and public access settings
• DLP policy configurations and rule scopes
• Repo/org settings preventing public repo creation (where applicable)
• Web app configuration showing authentication requirements for any CUI-processing portal

Operational records

• DLP alert samples and ticket closures
• Monitoring alerts for “resource became public” and response notes
• Exception approvals with expiration/review
• Audit logs showing access controls working (authentication/authorization events)

Assessment mapping

• A control narrative mapping 3.1.22 to your implemented controls and where evidence is stored ⁴

Daydream can help by turning this into a recurring evidence workflow: map 3.1.22 to owners, define required artifacts, and schedule evidence capture so you are not assembling proof during assessment week. ⁴

Common exam/audit questions and hangups

1. “Show me which of your systems are publicly accessible.” If you cannot produce an inventory with owners, you will struggle.
2. “How do you prevent users from sharing CUI via public links?” Expect scrutiny on cloud drive sharing and external collaboration.
3. “Where is CUI allowed to be processed?” Assessors want a boundary and an allowlist, not “any corporate system.”
4. “Prove the control operates.” Policies alone fail; produce logs, alerts, and configuration states.
5. “How do you control third parties that touch CUI?” They must operate within your approved boundary or equivalent controls, with contractual and technical constraints.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating “publicly accessible” as only the corporate website. Fix: include SaaS, cloud storage, repos, and portals in scope.
• Mistake: Relying on user training without technical prevention. Fix: implement DLP and tenant-level sharing restrictions.
• Mistake: No clear “CUI allowed systems” list. Fix: create an allowlist and deny-by-default language in policy and configurations.
• Mistake: Misconfiguration drift (a bucket or repo becomes public). Fix: baseline configurations plus monitoring for “public exposure” changes.
• Mistake: Exceptions without governance. Fix: require time-bounded approvals, security review, and documented compensating controls.
• Mistake: Weak evidence hygiene. Fix: store config exports, screenshots, and logs in an assessment-ready repository with dates and owners.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions.

Operationally, the risk is straightforward: public exposure of CUI can trigger contractual noncompliance, incident response obligations, and loss of trust with the DoD customer. From a CMMC assessment standpoint, weak control of CUI on public systems commonly shows up as boundary confusion, missing technical enforcement, and missing evidence. ⁵

Practical execution plan (30/60/90)

Use this as a sprint plan. The time boxes are planning aids, not a claim about how long implementation “must” take.

First 30 days (Immediate stabilization)

• Publish a one-page standard: definition of “publicly accessible,” deny-by-default rule, and the exception path.
• Build initial inventory of internet-facing systems and common SaaS used for sharing/collaboration.
• Implement quick wins: disable anonymous/public link sharing where feasible; restrict external sharing defaults.
• Start evidence capture: screenshots/exports of settings, plus the inventory and ownership list.

Days 31–60 (Technical enforcement + boundary clarity)

• Establish the “CUI allowed systems” allowlist and align it to your SSP boundary narrative. ⁴
• Deploy or tune DLP rules focused on: web uploads, cloud share links, and email exfil paths.
• Configure monitoring for “resource became public” events in your cloud environments.
• Create an exception register with required fields and review cadence.

Days 61–90 (Operational maturity + repeatable proof)

• Run targeted testing: attempt to share labeled CUI externally; validate controls block or alert.
• Expand coverage to dev workflows: repo visibility controls, secret scanning, and commit hooks where relevant.
• Conduct a tabletop on “CUI posted publicly” response: detection, containment, notifications, and lessons learned.
• Convert artifacts into an assessment package: control narrative, evidence index, and sample records for 3.1.22.

Frequently Asked Questions

Does “publicly accessible” include authenticated SaaS like Microsoft 365, Google Drive, or Jira Cloud?

It can. If the tenant or project allows anonymous access, broad guest access, or “anyone with the link,” treat it as publicly accessible for 3.1.22 until you lock it down and can show configuration evidence. ²

Are “anyone with the link” sharing links allowed for CUI?

Treat them as prohibited by default because the link can be forwarded and effectively becomes public access. If you approve an exception, document why and show compensating access controls and logging. ²

What evidence is most persuasive to a CMMC assessor for 3.1.22?

Current configuration exports (showing public access disabled), DLP policy settings, and operational logs or alerts showing the control detects or blocks improper sharing. Pair that with an inventory and a clear CUI allowlist. ⁴

How do we handle third parties who need to collaborate on CUI through their own systems?

Require them to operate within an approved CUI boundary or an explicitly authorized environment with access controls and logging appropriate for CUI, and document the decision. If they use public portals or public sharing, treat it as noncompliant until corrected. ⁴

Does a company’s public website ever need to host CUI?

Generally, no. If a program office claims a need to publish information, confirm whether it is truly CUI and obtain written authorization to decontrol or release the information through the proper channels before posting. ²

How do we operationalize this without slowing the business down?

Use an allowlist for approved CUI systems, deny-by-default technical controls, and a fast exception path with clear owners and required artifacts. Tools like Daydream help keep the exception register and evidence capture from becoming a spreadsheet fire drill. ⁴

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

2. NIST SP 800-171 Rev. 2

3. 32 CFR Part 170; DoD CMMC Program Guidance

4. DoD CMMC Program Guidance

5. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2