What AC.L2-3.1.22 requires for public websites and forums
AC.L2-3.1.22 requires a defense contractor to keep CUI off publicly accessible systems, meaning company websites, social media accounts, public forums and similar platforms that anyone can read. The practical way to meet it is with four working parts: a named list of people who may post publicly, a procedure and pre-posting review that stops CUI before it goes live, periodic review of content already published, and a way to remove anything that should not be there. Your organization owns all four. An assessor will look for them in writing and in the records they produce, not in a general statement that staff know better.
The risk is ordinary, which is why the requirement is hard. A marketing coordinator attaches a program briefing to a blog post, an engineer answers a technical question on a public forum with a drawing marked CUI, or a page from a years-old project still lists contract details. None of these people intends to leak anything. The control has to catch the mistake before publication and find the old mistake afterward. Staff who post from personal accounts or through third-party scheduling tools create gaps that a policy written only for the web team will miss, so the list of authorized posters and the review workflow should cover every channel the company controls.
This is one of the six requirements that can never be placed on a POA&M, so it must be MET before the organization can reach Conditional or Final Level 2 status. Before you plan the work, confirm with your assessor and your sponsor how the current assessment rules apply to your contract, since the program schedule has changed recently. Then inventory every public channel, identify who can post to each, and ask whether a written pre-posting review record exists for the last several months. Gaps in that record are the most common reason this objective fails in practice.
Which public channels and people fall under AC.L2-3.1.22
AC.L2-3.1.22 applies wherever CUI could appear on something the public can reach. Scoping starts by listing every public channel and every person who can publish to one, then deciding which of them sit near CUI and which need a documented boundary decision anyway.
Company websites and content management
Corporate sites, product pages and any content management system behind them are publicly accessible systems. If CUI is ever stored in the CMS, in a media library, or in a draft that is reachable without authentication, the site falls inside the requirement. Check who holds editor rights, whether staging or preview URLs are indexed, and whether attachments uploaded by one team are visible to the world.
Social media and vendor-hosted public pages
Company accounts on professional networks, video platforms and social channels are operated by a third party, but posts made from them are still the organization's public disclosures. Treat each account as in scope if any employee or contractor who can post also has access to CUI. Record which accounts exist, who holds the credentials, and whether scheduling tools hold copies of unreleased material.
Public forums, code repositories and support portals
Public issue trackers, community forums, open-source repositories and customer support portals accept content from outside the organization and often keep it indefinitely. A pasted configuration file, a screenshot of a system dashboard or a log excerpt can carry CUI. Confirm whether these channels are public or only reachable by authenticated partners, because that answer decides whether 3.1.22 applies.
Marketing, HR and communications staff
Marketing, recruiting and communications staff post the most often and are the least likely to hold CUI training. Job postings can describe a program, press releases can name a contract, and recruiter messages can reveal technical detail. List each role that can publish, the systems they use, and whether they have been trained to recognize CUI markings before posting.
Non-CUI public content that still needs a boundary decision
Content that never touched CUI still needs a documented decision that it is outside the CUI boundary. Examples include a product brochure, a public blog, or a public GitHub repository for a tool that never processes CUI. Write down the basis for the decision, the owner who approved it, and the review trigger, such as a new contract that introduces CUI into the program.
Systems that hold CUI and face the public
The highest-risk case is a system that stores or processes CUI and is also reachable from the internet, such as a shared file portal, a web form or a hosted application. Here the requirement applies in full, and the boundary, publishing rights and removal process must all be documented. Ask whether a public-facing component can reach an internal store, since that path is what brings CUI into scope.
How an assessor tests AC.L2-3.1.22 against NIST SP 800-171A
This table maps the five NIST SP 800-171A assessment objectives for requirement 3.1.22 to what the assessor tests, the evidence they request and the findings that most often stop a requirement from being met. Read each row as a question the assessor will ask of your records, not as a checklist of documents to produce. The main takeaway is that the requirement is MET only when every applicable objective is satisfied with evidence in final form, so a missing review record or an outdated poster list fails the whole requirement.
| Assessment objective | What the assessor tests | Evidence requested | Common findings |
|---|---|---|---|
| Authorized posters identified | Whether the organization has determined who may post content to publicly accessible systems and only those people can do so | Current list of users authorized to post public content, with approval records and dates | No current poster list, or accounts that can publish to the website without appearing on the list |
| Procedures and pre-posting review | Whether a documented procedure requires review for CUI before anything is posted, and whether that review happens in practice | Written posting procedure, pre-posting review checklist and completed review records for sampled postings | Procedure exists but reviews are not recorded, or reviews happen after content is already live |
| Content review for CUI | Whether public content and public systems are reviewed periodically to find CUI that was posted improperly | Records of periodic public content reviews, including scope, reviewer and findings | No periodic review, or reviews that check formatting but not whether CUI is present |
| Responses to nonpublic information found publicly | Whether the organization records and acts on any nonpublic information it discovers on public websites or forums | Records of discovered items, the response taken and the time to remove them | Discovered items fixed without a record, or no defined response path for staff who find CUI |
| Removal mechanisms and related training | Whether a mechanism exists to remove improperly posted CUI and whether staff know how to use it and their posting responsibilities | Removal procedure, evidence of a tested takedown path, and training and security awareness records for posters and reviewers | No removal procedure, or training records that do not cover public posting responsibilities |
Implementing public content control step by step
This sequence turns AC.L2-3.1.22 from a policy statement into a working process: every public channel is known, every poster is authorized, every item is reviewed before it goes live, and any improper posting is removed and recorded. Each step ends with an artifact an assessor can examine.
Inventory every publicly accessible channel
List every system that anyone outside the organization can reach without authentication: the corporate website, blogs, social media accounts, public code repositories, public forums, job boards, support knowledge bases and any cloud storage bucket with anonymous read access. Include channels run by marketing agencies or other third parties on your behalf. Record the owner, the platform and who can publish to each one. The output is a current channel register that the assessment team can reconcile against your system boundary and network scans, and you should confirm with your assessor how they expect external channels to be scoped.
Name authorized posters and release authority
Write a list of named individuals or roles permitted to post content to each public channel, and separate them from people who may only draft. Record who holds government release authority for any CUI that is intended for public release, because the CMMC Assessment Guide Level 2 notes that only government officials can authorize the release of CUI to the public. Confirm this decision with your contracting officer or program security lead before you finalize the list. The output is a signed authorization roster that identifies each poster, the channels they may use and the approver for any release.
Write the pre-posting and review procedure
Document the steps a draft must pass before it goes public: who checks it, what they check for (CUI markings, export-controlled technical data, program details, personnel information, contract numbers and unpublished capability descriptions), and what evidence the reviewer records. Define what happens when a reviewer finds CUI, including who is notified and who decides whether the item is withdrawn. The output is an approved procedure with a review checklist that a poster can follow without interpretation.
Configure the approval workflow
Set up the publishing path so that a draft cannot go live until an authorized reviewer approves it. Where the platform allows it, restrict publish rights to the authorized roster, require a second person to approve, and keep the approval, timestamp and approver identity in a log. If a channel cannot enforce approval technically, document a manual control and record each approval in a ticket. The output is a configuration record and a sample approval trail that shows a post was reviewed before publication. Ask your tooling team to confirm each setting against the platform documentation.
Train posters and reviewers
Brief every authorized poster and reviewer on the procedure, the CUI categories they are most likely to encounter in public-facing material, and the escalation path for suspected improper posting. Use role-based examples drawn from your own content, and record attendance with the date and version of the material used. Training records are a common assessment object for this requirement, so keep them alongside the authorization roster. The output is completed training records for every person on the roster.
Run a baseline content sweep
Review all existing public content on every channel in the register against the review checklist. Look at pages, downloads, PDFs, images with embedded metadata, old press releases, conference slides, job descriptions and code comments. Log each item as compliant, withdrawn or referred for release review, and record who performed the sweep and when. Items that are CUI must be removed through the removal procedure, not edited quietly. The output is a sweep report with dispositions and the evidence that each removal was completed.
Set removal and incident response for improper posting
Define how improperly posted CUI is found, contained and removed: who can take a page offline, how caches, search indexes, archives and third-party copies are addressed, how the event is recorded, and how it is reported under your incident response plan and any contractual reporting obligations. Confirm reporting timelines with your contracting officer and your DFARS 252.204-7012 obligations rather than assuming them. The output is a removal runbook and an incident record template, tested at least once against a sample post.
Schedule periodic review and keep the evidence current
Set a recurring review of the channel register, the authorization roster, training records and a content sweep, with the cadence chosen by your organization and documented in the procedure. Record each review's findings and the corrective actions, and feed any gaps into your plan of action and milestones only where the requirement allows it, which this one does not. The output is a dated review calendar and a log that shows the control operated over time, which is what an assessor will check beyond a single snapshot.
Why only government officials can release CUI to the public
The CMMC Assessment Guide Level 2 notes that only government officials can authorize the release of CUI to the public. For AC.L2-3.1.22 Control public information, this means a contractor does not decide on its own that a document, datasheet or technical explanation is safe to publish, even when the material looks harmless. Your job under this requirement is to make sure unauthorized posting cannot happen and that any question about releasing controlled information goes to the government authority that owns the decision. Assessors will look for that separation of roles, not for a contractor judgment that content was approved for release.
For contractor-written technical content, the practical effect is that marketing pages, capability statements, conference abstracts, blog posts, forum answers and open-source contributions must be screened for CUI before they leave the organization, and any item that touches a contract's controlled technical data is held. A writer who describes a program's architecture, performance limits or test results may be publishing CUI without knowing it. Build a pre-posting review step that asks whether the content came from, or describes, a CUI-marked contract deliverable, and send unclear cases to the security officer rather than to the contracting team alone.
Confirm the release path with your contracting officer before you need it. Ask who in the government can authorize release for each contract, what form that authorization takes, whether it must be in writing, and how it is recorded in your files. Also confirm whether the contract includes any public release or disclosure language that changes these steps. Keep the answers with your AC.L2-3.1.22 evidence, because an assessor will expect to see that the contractor knows where release authority sits and has followed it.
Evidence that passes an AC.L2-3.1.22 assessment
Assessors test AC.L2-3.1.22 by reading records, not intentions. The cards below cover the artifacts that show who may post, how content is reviewed before it goes live, and how improper postings are found and removed. Each one needs to be current, final and tied to the people who actually run the public site.
Authorized poster list
This is the roster of individuals permitted to publish content to publicly accessible systems such as the company website, social media accounts and public forums. Assessors check that the list names each poster, the approving official and the date of approval, and that it matches the accounts that can actually publish. Review it whenever staff change roles or leave. Confirm that the list is approved by an authorized official and that no former employees still hold posting rights. Since only government officials can authorize release of CUI to the public, your list should show who holds that release authority for any CUI-related content.
Written pre-posting review procedure
The procedure describes the steps every item must pass before it goes live, including who reviews it, what they check for CUI, and what sign-off is required. Assessors look for a final, approved version with an owner and an effective date, not a draft in a shared folder. The procedure should state that nothing is published until the review is complete and recorded. Confirm that the steps match what the posting staff actually do, because assessors often compare the document with the workflow in your content management or ticketing tool.
Records of public content reviews
Periodic reviews of what is already published on public systems show that CUI has not drifted onto the site over time. Keep dated records that list the pages, posts or files reviewed, the reviewer, what was found and what action followed. Reviews of older content matter as much as new postings, because documents attached to legacy pages are a common source of exposure. Confirm the review frequency you set in your procedure and make sure each review actually happened on that schedule.
Responses to nonpublic information found online
When someone finds nonpublic information on a public website, such as a leaked spreadsheet or an internal document indexed by a search engine, the response must be documented. The record should show the date the item was reported, how it was verified, who was notified, when it was removed and whether the exposure was assessed. Assessors specifically look for these records because they show the review mechanism works in practice. Use a ticketing system to track each report from intake to closure so the timeline is provable.
Takedown and removal logs
Removal logs show that improperly posted CUI can be taken down quickly and completely. Each entry should record the item, where it appeared, when it was removed, who removed it, and confirmation that cached copies, attachments and linked files were also cleared. Assessors test whether your mechanisms work, so a log of at least one documented removal, or a tested drill, is stronger than a policy that says removal is possible. Confirm that the people who can remove content are on the authorized poster list or an equivalent administrator list.
Training and awareness records
Posters and reviewers need to know what counts as CUI and why it cannot appear on public systems. Training records should show who completed the course, the date, the content covered and any knowledge check. Assessors commonly ask for these records alongside the poster list, because a poster who was never trained is a weak control. Refresh training when the procedure changes and when new staff join the posting function. Confirm that completion is tracked for every person on the authorized list, not only for the communications team.
What meeting AC.L2-3.1.22 costs in money and effort
Most of the first-year effort on AC.L2-3.1.22 is paperwork that has to exist before an assessor arrives. The organization must name who may post to publicly accessible systems, write a pre-posting review procedure, and define how improperly posted CUI is removed. Internal policy staff, the information security lead and, where CUI release decisions are involved, the officials who authorize release usually do this work. An implementation partner can draft the procedures and map them to the 3.1.22 assessment objectives, but the organization owns the approvals.
- Authorized poster list: Naming the people allowed to post and keeping that list current as roles change.
- Pre-posting review procedure: Defining who reviews content, what they check for CUI markings, and how approval is recorded.
- Removal and response procedure: Setting steps for taking down nonpublic information and documenting the response.
- Approval and sign-off time: Senior reviewers must accept the documents, which often takes several rounds.
One-time work dominates this tab, but the documents also need annual review. Ask the quote to show drafting, review cycles and who signs off.
Pre-posting review is a recurring staff task, so its cost follows the number of posts and the people who must review them. Some organizations route requests through a ticketing or approval workflow so each post has a record of who requested it, who reviewed it and when it went live. Open-source helpdesk and service management tools can hold that workflow, but licensing, hosting and administration still need budget. The cost of the tool itself is often smaller than the staff time spent using it.
- Reviewer hours: Time spent checking drafts for CUI before publication, multiplied by post volume.
- Approval workflow setup: Configuring request forms, routing rules and approver groups in the chosen tool.
- Hosting and administration: Running the ticketing system in the organization's own environment, with backups and access control.
- Integration with web publishing: Connecting approvals to the content management system so unapproved pages cannot be published.
Ask whether the quote includes tool configuration, whether it assumes existing licenses, and how many reviewers the estimate assumes.
Before the procedures take effect, the organization should review what is already public. A sweep of company websites, social media accounts, public code repositories, forums and document libraries shows whether CUI has already been posted. The effort depends on how much content exists and how many systems hold it. Legacy content is the largest driver, because older pages and archived files are often forgotten and carry no current owner.
- Channel inventory: Listing every public-facing site, account and forum the organization controls or uses.
- Content review time: Reading or searching pages, attachments and archives for CUI markings and sensitive details.
- Remediation: Removing content, correcting records and documenting each removal decision.
- Owner identification: Finding who posted old content when the author has left the organization.
A sweep produces records that assessors may ask to see, so the quote should state what the deliverable is and how findings will be documented.
After the first sweep, cost shifts to recurring work. Authorized posters need training on the rules, reviewers need refreshers, and the public content review must happen on a schedule the organization sets. The assessment objectives for 3.1.22 expect training and security awareness records, so training is part of the control rather than an optional extra. Recurring cost rises with staff turnover and the number of people who can post.
- Poster training: Teaching authorized posters what counts as CUI and how the pre-posting review works.
- Periodic content reviews: Scheduled checks of public channels for nonpublic information, with records kept.
- Turnover handling: Removing departing staff from posting rights and training replacements.
- Procedure updates: Revising the documents when channels, tools or CUI categories change.
Ask the quote to separate first-year setup from annual recurring work, so the ongoing budget is visible.
Assessor time is charged by an independent assessor, not by the implementation partner. For Level 2 certification, a C3PAO performs the assessment, and the organization pays that body directly. Assessment effort grows with the number of public channels and the volume of evidence to review. An implementation partner cannot issue the assessment result, so the quote should cover preparation and evidence, not the assessor's findings.
- Independent assessment fees: Paid to the assessor, with scope set by the systems and channels in the boundary.
- Evidence preparation: Gathering approval records, review logs and training records in final form.
- Scope definition: Deciding which public channels fall under the control and documenting that decision.
- Written scope quote: A fixed-scope proposal listing deliverables, assumptions and timelines before work begins.
DeployOpen does not publish prices. Ask any provider for a written scope that names the channels, the number of reviewers, the content sweep boundary and the recurring activities included.
Open-source helpdesk tools that can hold public content approvals
This table compares GLPI and Zammad as systems of record for posting requests, pre-posting approvals and takedown actions under AC.L2-3.1.22. Read each row as a question to test in a proof of concept with your own approval workflow, because the tools support evidence capture but do not decide whether content is CUI. The main takeaway is that either tool can hold the trail an assessor asks for, provided the process, approver roles and retention rules are defined first.
| Capability | GLPI Assistance module | Zammad |
|---|---|---|
| Posting request as a record | Tickets can capture a request to publish content, with requester, description and date, for later review | Tickets can capture a request to publish content, with requester, channel and history in one record |
| Approval evidence | Follow-ups and ticket processing steps can show who reviewed a request and when; confirm the approval step is enforced by workflow, not by convention | Ticket history and notes can show reviewer decisions; confirm whether approval gates can be configured without custom work |
| Takedown and removal actions | Tickets can track removal of improperly posted content through to closure, including follow-up notes | Tickets from email, social media or web contact forms can route a takedown report to the responsible team |
| Channel coverage | Centered on internal requests and service processing; confirm how external reports, such as a public tip about posted content, reach the queue | Brings email, chat, telephone and social media messages into one ticket system, useful for reports of nonpublic information found online |
| Statistics and recurring issues | Includes statistics and recurrent tickets, which can show repeat posting problems by team | Reporting depends on configuration; confirm the metrics you need for assessor review |
| License fit | GPL-3.0-or-later; confirm obligations if you modify the code or distribute it to others | AGPL-3.0-only; confirm obligations for network-facing modifications with counsel before deployment |
| Ownership of the control | The organization owns the approval decision; the tool records it and does not authorize CUI release | The organization owns the approval decision; the tool records it and does not authorize CUI release |
Who does what: your team, a partner and the auditor
Your organization owns AC.L2-3.1.22 in full. Only people you authorize may post to publicly accessible systems, every post must pass review, and anything that reaches a public site without approval must be removed. An assessor will ask who holds posting rights, who approved them and what records show those rights were used correctly. Your team must be able to answer those questions with records, not recollection.
- Named posters: a written list of individuals authorized to post content to company websites, social channels and public forums, with the approver and date for each entry.
- Pre-posting review: a documented step where a designated reviewer checks content for CUI before it goes live, with a record of the reviewer and the outcome.
- Content review cycle: scheduled checks of existing public pages and forums for CUI that was posted earlier, with dated results.
- Removal and response records: a procedure for removing improperly posted CUI, plus a log of each removal and the response to any nonpublic information found on a public site.
- Training records: proof that posters and reviewers understood what CUI looks like and the posting rules.
Confirm with your assessor or C3PAO which records they will request, and check that your own staff can produce them on short notice.
A DeployOpen-style implementation partner helps you build the machinery behind the control. The partner prepares the procedures, configures the workflow tools that route posting requests and review tasks, runs an initial sweep of public content and assembles the evidence package. The partner works for you, under a written scope, and the decisions stay with your organization. The partner cannot authorize a poster, approve a release of CUI or decide that a requirement is met.
- Procedure drafting: posting, review and removal procedures written to match how your organization actually publishes content.
- Ticket workflows: configuration of a helpdesk or ticketing system so each posting request, review and removal leaves a timestamped record. Open-source options such as GLPI and Zammad can serve this purpose, subject to confirmation against your environment.
- Baseline content sweep: a one-time review of public sites and forums, with findings handed to your team for decision.
- Evidence assembly: organizing procedures, logs and training records so they are complete, final and mapped to the assessment objectives.
- Independence limits: the partner must not write findings for the assessor or pre-judge the assessor's conclusions.
Before engaging a partner, ask for the written scope, the deliverables, and which tasks remain with your staff after handover.
Only an independent assessor issues findings and certification. For Level 2 certification assessments, that means a C3PAO authorized or accredited by The Cyber AB, which is the CMMC Accreditation Body. The assessor tests AC.L2-3.1.22 against the assessment objectives in NIST SP 800-171A and decides whether each objective is satisfied with evidence in final form. Because assessor independence is required, the partner cannot write the assessment, certify results or draft the assessor's conclusions.
- Objective testing: the assessor checks who may post, the pre-posting review, the content review and the removal mechanisms against the 800-171A objectives.
- Sampling and interviews: the assessor may interview posters and reviewers and sample posted content and logs.
- Findings and status: the assessor records findings and the resulting Level 2 status, which the sponsoring organization then uses in contracts.
- Final evidence: drafts and unfinished procedures do not count, so the evidence the assessor sees must be complete.
- Partner boundary: the partner may explain the requirement and help you prepare, but it does not sign, attest or issue any report or certificate.
Before booking an assessment, confirm the assessor's accreditation status with The Cyber AB and ask how they handle questions about preparation.
Where contractors usually fail AC.L2-3.1.22
Most failures on AC.L2-3.1.22 come from the gaps between written policy and daily practice, not from missing policy documents. The cards below cover the places where CUI tends to reach public systems without anyone deciding it should, and the closing action for each.
Unlisted social media accounts
Teams often create LinkedIn pages, X accounts, YouTube channels or event pages that never appear in the asset inventory or the system security plan. Assessors who search for public-facing properties find them, and the organization then cannot show who authorized them or how posts are reviewed. Build a list of every external account that carries the company name, assign an owner to each, and confirm that the list matches the authorized posters record and the training records. Close any account that has no owner.
Marketing staff posting without review
Marketing and sales staff often publish project photos, capability statements or customer wins without knowing that a program description can reveal CUI. The control expects a pre-posting review by someone who can recognize CUI and who has the authority to stop a post. Require that only named individuals hold posting rights, that a second reviewer approves each item before release, and that the review record is kept. Ask the marketing lead to show a sample of the last ten posts with their approvals.
No removal procedure
Many organizations have a review step but no defined path for taking down content that was posted in error. When a post contains CUI, the team needs to remove it, notify the responsible official and record what was done, and it should not be left to whoever notices first. Write a short removal procedure with a named owner, the steps for pulling content from every channel including caches and archives, and a record template. Walk through the procedure once with a tabletop exercise and keep the notes.
Old files on public download pages
Websites often keep whitepapers, technical datasheets, slide decks and marketing PDFs from years earlier, and those files can contain CUI that was once considered releasable. Search engines and archive services may index them even after a page is retired. Inventory every downloadable file on public web properties, check each against the CUI markings and release decisions on record, and remove or replace anything that lacks an approved release. Keep the review date and the reviewer's name for each file.
Training records missing
Assessors look for evidence that people who can post or review public content were trained to recognize CUI and understood the posting rules. Organizations frequently have a policy but no record of who completed the training, when, or what it covered. Keep a dated training roster for every authorized poster and reviewer, tie completion to the authorization itself so that no one gains posting rights without it, and repeat the training on a schedule the organization sets. Confirm the schedule and content with your assessor before the assessment.
Questions buyers ask about AC.L2-3.1.22
How much effort does controlling public information take?
The effort is mostly procedural rather than technical. It requires a short list of authorized posters, a written pre-posting review step, a periodic content review of public websites and forums, and a removal procedure that works when CUI is found. Most of the cost is staff time for reviews and training, and it recurs as long as the organization publishes content. Effort rises with the number of public channels, the number of people who can post, and how often content changes. Ask any partner to itemize the review workflow, the sample scope for content checks, and who signs off on removals in the quote.
Can we meet AC.L2-3.1.22 without outside help?
Yes, in principle. The organization owns its controls, so staff can write the posting procedure, keep the authorized poster list, run pre-posting reviews and keep the records an assessor will ask for. Outside help is most useful for preparing system security plan language, organizing evidence in final form, and testing whether the procedure works in practice. Only an independent assessor can issue a certification result, so any partner prepares the evidence but does not grade it.
What does the work need from our staff?
Staff need clear roles more than new technical skills. Typically this means a named owner for public communications, managers who can approve posters, web and marketing staff who follow the pre-posting review, and someone who can act quickly on removals. Security staff should be able to search public sites and forums for CUI. Assessors also look for training and security awareness records showing that these people understand what counts as CUI. Confirm the exact training content against your own CUI categories before rollout.
How long does it take to meet AC.L2-3.1.22?
The duration depends on scope: how many public channels exist, how many people publish, whether a procedure already exists, and how much content needs an initial review. No duration is set by the researched facts for this requirement, so ask for a timeline tied to a written scope. A fixed-scope engagement from DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the organization should confirm the same from any provider.
Do we need a partner to prepare for this requirement?
A partner is optional. Many organizations handle the procedure and records internally and bring in help only for specific gaps, such as a first sweep of legacy public content or a review of how the procedure fits the system security plan. If you do engage a partner, DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. The assessor must remain independent of the team that prepared your evidence.
Is a self-assessment enough under the current Phase 1 status?
As of the most recent Department of War information supplied for this page, implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2. Phase II was suspended on 13 July 2026, and Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Under the CMMC rule, AC.L2-3.1.22 must be MET, and it cannot sit on a POA&M, so a self-assessment still needs real evidence. Check current Department of War guidance and your contracting officer before relying on any answer, because the status has changed recently.
What happens if CUI is found on a public website?
The removal procedure should start immediately. Treat the finding as a potential incident, remove the content, record who found it, when, and what was removed, and review how it was posted. Assessors look for records of responses to nonpublic information found on public websites, so the log is part of the evidence. Work with your incident response process and confirm with your contracting officer whether any reporting obligations apply under your contract.
How DeployOpen prepares AC.L2-3.1.22 evidence
DeployOpen plans, implements and documents self-hosted open-source platforms that help an organization keep CUI off public websites, forums and other publicly accessible systems. We prepare the systems, procedures and evidence for AC.L2-3.1.22 Control public information, while the organization keeps ownership of its controls and an independent assessor makes the determination.
How we scope
- Agree in writing which public-facing systems, sites and forums are in the assessment boundary for AC.L2-3.1.22.
- Confirm who the organization has authorized to post content, and which roles can publish to each public channel.
- Define the pre-posting review and content removal steps the written scope will cover, with named owners on the client side.
How we build
- Configure posting permissions and approval workflows so content moves through a documented review before publication.
- Set up a helpdesk ticket queue, such as GLPI or Zammad, to log reported improper postings and track their removal.
- Test the workflow with sample content and record the results so the assessor can see the control operating.
How we hand over
- Deliver the authorized poster list, posting procedure, review and removal records, and training and awareness records.
- Document the evidence map so each assessment objective for 3.1.22 points to a specific artifact in final form.
- Walk the client team through the evidence and identify any gaps the organization must close before its assessment.
How we support
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
- Ongoing support, upgrades and periodic review of posting records are available as a retainer.
- Confirm with your assessor which evidence formats and review cadence they will accept for your environment.
