What AC-22 asks for when your website or portal is public
AC-22 asks an organization to name the people allowed to post information on publicly accessible systems, train them to keep nonpublic information out, review content before it is posted, and review what is already public at a defined frequency, removing any nonpublic information it finds. If your public website, customer portal or content system must meet SP 800-53 in the low, moderate or high baseline, AC-22 applies to it. The control has no enhancements and is not selected in the privacy baseline, so the work is the same four duties at each impact level, with the frequency and scope of reviews set by your own organization-defined parameter.
The risk is ordinary and easy to miss: an internal architecture diagram exported to a downloads folder, a staging login left in a page source, a spreadsheet of customer records attached to a news post, or a draft that quietly exposes an unreleased program. In practice the problem grows with the number of people who can publish. Marketing, support, product and partner teams each add content, CMS templates drift from their original settings, and legacy files sit in media libraries long after the pages that linked to them are gone. Any of these can expose internal documents, credentials or personal data without anyone deciding to publish them.
Start by asking your CMS or portal owner for the current list of accounts with publish rights, the role each one holds, and the date of the last training record for each poster. Then confirm whether pre-posting approval is enforced by the platform or only by policy. Assessors will examine that list, the training materials, and records of past content reviews, and will interview the people responsible for public information. Open-source content platforms such as XWiki and BookStack keep version history and role-based permissions, which can help you show who changed what and when, but you should confirm with your own environment which settings and logs your assessor will accept.
Which public systems and people AC-22 reaches
AC-22 applies to any system the organization makes available to the public, and the work it creates depends on which systems are in scope, who can publish to them and which baseline selects the control. Settle these three decisions first, because each one changes how many systems, people and review cycles the program must cover.
Corporate and marketing websites
Public corporate sites are the most common publicly accessible systems, and they are usually the first place assessors look. List every domain, subdomain and hosted content platform the organization operates, including sites run by a marketing agency under the organization's domain. Each one needs a named set of posters, a pre-publication review step and a scheduled review of content already live. Check whether any site is an inherited or legacy property that nobody currently reviews.
Customer portals and public APIs
Customer-facing portals and public API documentation can expose nonpublic information through error messages, sample data, changelogs or example responses. Treat the content they serve as publicly accessible content, not only the static pages. Confirm whether anyone outside the organization can reach the content without authentication, because that boundary decides whether AC-22 applies to a given page or endpoint.
Documentation and knowledge sites
Public product documentation, status pages and developer wikis are often maintained by engineering teams with little oversight. Each page that anyone can read without logging in falls under AC-22. Ask who can publish, whether drafts are visible outside the organization, and how often pages are reviewed for internal hostnames, architecture details or personnel names. Version history helps prove that a review or removal happened.
Social channels run by system owners
Official social accounts and video channels that the system owner operates can publish nonpublic information through posts, images or attached files. Decide whether these channels sit inside the AC-22 boundary, and document the decision in the system security plan. Where a social media manager is an external agency, its staff become people who may post, so they need to appear on the authorized list and receive the same training.
Contractors, agencies and shared posting rights
Posting rights often sit with people outside the organization's payroll, such as web agencies, content vendors, translators and conference staff. Each of these people is a designated poster for AC-22 purposes. The authorization list should name them, the training should reach them, and access should end when the engagement ends. Ask each vendor how it manages its own staff's access, and confirm this in the contract.
Baseline selection: low, moderate and high
SP 800-53B selects AC-22 in the low, moderate and high baselines, but not in the privacy baseline. Any system categorized at one of those three impact levels therefore carries the control, and the cost of the control does not change across those levels in the baseline text. The scope question is whether a system is in a baseline at all. Confirm the impact level in the security categorization, and check whether an overlay or tailoring decision changes the selection.
How an assessor tests AC-22 with examine, interview and test
When assessing examine methods, the assessor reviews the documents and records that show AC-22 is designed and operated. The starting point is a current list of the people authorized to post information on publicly accessible systems, because every other check depends on who that list says may publish. The assessor then looks for training materials and training records showing those people were taught to keep nonpublic information off public pages. Last, the assessor examines records of publicly accessible information reviews, which show that proposed and posted content was actually checked at the frequency the organization defined.
- Authorization list: A named list of authorized posters, with approval dates and the owner who approved each entry.
- Training materials: Content that explains what counts as nonpublic information and how to recognize it before publishing.
- Training records: Completion records tied to the people on the authorization list, showing who was trained and when.
- Review records: Dated logs of pre-posting reviews and periodic sweeps of posted content, including what was found and removed.
- Defined frequency: The review interval the organization set for posted content, which the assessor compares against the review records.
Before an assessment, confirm that the authorization list, training records and review logs match each other, since a mismatch between them is one of the first things an examiner notices.
Interview methods test whether the people responsible for public content understand their role and can describe how the control works in practice. The assessor typically speaks with the staff who manage publicly accessible information, such as web content owners, communications staff and the people who approve postings. The aim is to confirm that the process described in documents matches what these people actually do. Answers that are vague, or that differ from the written procedure, suggest the control exists on paper only.
- Role awareness: Whether interviewees can name their authority to post and the limits on what they may publish.
- Screening knowledge: How they recognize nonpublic information such as internal system details, personal data or unreleased plans.
- Review practice: How they check drafts before posting and how they find problem content after it is live.
- Escalation: What they do when they find nonpublic information already published, and who they notify.
- Consistency: Whether answers from different staff agree with each other and with the documented procedure.
Before an assessment, ask a sample of posters to walk through a recent posting from start to finish, since that is the most direct preparation for the questions an assessor will ask.
Test methods check the mechanisms that enforce the control rather than the people or paper that describe it. For AC-22, the assessor looks at the systems that publish content and asks whether unauthorized users are prevented from posting and whether a review step can be bypassed. Typical objects include content management system workflows, role assignments, approval steps and any scheduled scanning that flags nonpublic information. The assessor may attempt a posting with an account that is not on the authorization list and confirm the system refuses it.
- Posting permissions: Whether only accounts on the authorized list can publish to public locations, verified against the live configuration.
- Approval workflow: Whether drafts must pass a reviewer before going live, and whether the reviewer role can be bypassed.
- Role configuration: Whether permissions are assigned by role and whether overrides at the page or section level are visible and controlled.
- Versioning and rollback: Whether previous versions are retained so the organization can show what was posted and remove it cleanly.
- Scanning or review tooling: Whether any automated checks for nonpublic information run on the defined schedule and produce logs.
Before an assessment, test the workflow yourself with an unauthorized account and keep the result, because an assessor will expect to see that the mechanism behaves as documented.
How to implement AC-22 in sequence
This sequence turns AC-22 from a policy statement into working practice: named people who may post, trained staff, a review gate before publication and a recurring check of what is already public. Each step produces a record that an assessor can examine.
Set the organization-defined parameter values
AC-22 leaves two choices to the organization: how often posted content is reviewed and which roles are responsible for the review. Assign a named owner, usually the information owner or communications lead working with the security team, to propose values and approve them. Record the approved review frequency and the roles that perform each review in the access control procedures or the system security plan. Done means the values are written down, approved by an accountable official and traceable to the control's parameter in the SP 800-53A procedure for AC-22.
Designate who may post publicly
Identify every person or group allowed to publish information on publicly accessible systems, such as a website, a public file share or a public documentation site. Keep the list short and tie each entry to a business role. Have an accountable manager approve the list and record the approval date, then review the list when roles change. The output is a signed or approved authorization list of posters, which assessors examine directly as the list of users authorized to post publicly accessible content.
Train designated posters on nonpublic information
Deliver training to everyone on the posting list before they gain publishing rights. The material should explain what counts as nonpublic information in your organization, such as internal project names, personal data, system addresses, credentials and unreleased financials, and how to recognize it in drafts and attachments. Track completion for each person and retain the training materials. Assessors look for the training content and the records showing who completed it, so both should be kept with the posting list.
Configure a pre-posting review gate
Before content goes live, require a second reviewer to check it against the nonpublic information criteria from the training. In a self-hosted content platform, this is usually done with a draft state, page or chapter permissions that separate editing from publishing, and an approval step recorded in the platform's history. Confirm with your platform's documentation that publish rights can be restricted to designated roles and that changes are logged with author and time. The check is complete when a test post by a non-approver cannot go live without review, and each approved item leaves a review record.
Run the recurring review of posted content
Review everything already public at the review frequency set in step one. Start from an inventory of publicly accessible pages, files and repositories, then sample or inspect each item against the nonpublic information criteria. Include content that was posted before the gate existed. Record the date, scope, reviewer, items checked and findings. The output is a review record for each cycle, which assessors examine as records of publicly accessible information reviews.
Remove and log nonpublic findings
When a review finds nonpublic information, remove it from the public location promptly, confirm the removal from outside the internal network, and decide whether the exposure needs further action, such as incident handling or a notice to affected parties. Record what was found, where it appeared, who removed it, when it was removed and the follow-up taken. Use version history to identify when the content first appeared and who published it, but do not delete the history of the removal itself. The closed finding, with its removal record, shows the control operated as designed.
Keep the sequence current and evidenced
Revisit the posting list, training content and review frequency when staff, platforms or public services change, and when assessment findings or incidents show a gap. Keep the procedures, lists, training records, review records and removal logs together so that one assessor request can be answered from a single location. Confirm with your assessor which evidence format and retention period they expect, since those requirements come from the assessment and the organization's own policy rather than from the control text.
Evidence that passes an AC-22 assessment
An assessor testing AC-22 looks for records that show who may post, how content is checked before it goes live, and how posted content is reviewed and cleaned up over time. The cards below cover the artifacts that answer those questions and how to keep each one current between assessments.
Authorized poster list
This is the list of people your organization has designated to post information on publicly accessible systems, which AC-22 examines directly. Keep it as a named roster with role, approving manager and the date each designation was made or withdrawn. Review it whenever staff change roles or leave, and record the review date on the list itself. Check that every account on the content management system appears on this list and that no departed employee still has posting rights. Version history on the roster lets you show who was authorized on any past date.
Training materials and completion records
AC-22 expects designated posters to be trained to keep nonpublic information off public systems. Retain the current training content, its version and the date it was last revised, along with a completion record for each authorized poster. Refresh the material when the publishing workflow or the categories of nonpublic information change. Assessors commonly ask whether training was completed before a person first posted, so compare the dates in your completion records against the dates in the roster.
Pre-posting review records
Before proposed content goes live, a reviewer should check it for nonpublic information and record the decision. Keep a log with the item, author, reviewer, date and outcome, and make sure the reviewer is not the author where your process requires separation. Where a publishing tool supports approval steps, export the approval history rather than relying on memory. Test the log by selecting several recent postings and confirming each has a reviewer entry dated before the publication date.
Dated periodic review reports
AC-22 requires review of content already posted, at a frequency your organization defines. Each review should produce a dated report stating the scope, the pages or files examined, the reviewer and any nonpublic information found. Set the frequency in your procedures, then keep one report per cycle, even when nothing was found, so the sequence of reviews is provable. Assessors compare report dates against the frequency you documented, so a missed cycle is a finding unless it is recorded and explained.
Removal tickets for nonpublic content
When a review or a report finds nonpublic information on a public system, the removal should be tracked as a ticket with the finding, the content location, the time it was discovered, the time it was removed and who verified the removal. Link each ticket to the review report that surfaced it. Assessors use these tickets to test whether the review process produces action rather than just documentation. Ask your team to confirm whether any cached or archived copies were also addressed, and note that step on the ticket.
CMS permission and audit exports
Export the role and permission settings from the content management system at each review cycle so the configuration is captured as it stood at that time. In XWiki, page history records what changed, when and by whom. In BookStack, permissions come from roles and can be overridden at shelf, book, chapter or page level, so the export should show effective rights, not only role names. Store exports with dates, and compare them between cycles to catch unexpected grants.
What meeting AC-22 costs in money and effort
This table breaks the cost of running AC-22 into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. The NIST sources supply no dollar or hour figures, so use the table to structure a request for a written scope and quote rather than as a budget.
| Cost component | Who is paid or who spends time | One-time or recurring, and what drives it |
|---|---|---|
| Web platform or CMS licensing | Vendor, if the publishing platform is commercially licensed | Usually recurring. Driven by number of editors, sites and seats. Self-hosted open-source platforms remove this license line but not the operating effort. |
| Engineering time to configure roles and workflows | Internal platform team or an implementation partner under a written scope | Mostly one-time. Driven by how many publishing roles, approval steps and site sections must be separated, and by how many systems expose public content. |
| Staff time for training and reviews | Designated posters, reviewers and the security or communications staff who train them | Recurring. Driven by staff turnover, publishing volume and how often the review frequency the organization sets is applied. |
| Pre-publication and periodic content reviews | Reviewers who check proposed content and sweep posted content for nonpublic information | Recurring. Driven by page volume, number of content sources (such as uploads and attachments) and the review frequency the organization defines. |
| Evidence upkeep | Internal compliance or content owners who keep training records, review logs and role lists current | Recurring. Driven by how the evidence is captured. Version history and access logs kept in the platform lower manual effort. |
| External review of the content process | Independent consultant or assessor, if engaged before audit | Optional and variable. Driven by scope, number of publishing systems and whether gaps need outside remediation. Request a fixed-scope quote. |
| Auditor sampling and testing | Independent auditor or assessor, who issues any formal findings | Recurring at each assessment cycle. Driven by the number of publishing systems, roles and review records the assessor samples. Ask the assessor for its sampling approach in writing. |
Who owns AC-22 and what a partner can prepare
Your organization owns AC-22. Accountability for deciding who may post publicly, for keeping nonpublic information off public channels and for performing the periodic reviews cannot be handed to a vendor or auditor. The people who run communications, web publishing and the public-facing applications are the natural owners, with security and compliance responsible for setting the rules they follow. Your team also decides the review frequency, which is an organization-defined parameter that the assessor will expect to see written down and followed.
- Designate posters: Name the individuals or roles allowed to publish content on publicly accessible systems, and keep that list current.
- Set the training requirement: Decide what those people must learn about keeping nonpublic information out of public content, and record who completed it.
- Approve content before posting: Assign a reviewer who checks proposed material against the nonpublic information rules.
- Run periodic reviews: Schedule and perform reviews of content already public, and remove anything that should not be there.
- Own the records: Keep the designation list, training records and review results as the evidence an assessor will examine.
Before engaging anyone, confirm that your own list of posters, your review frequency and your training records exist and match what staff actually do.
An implementation partner such as DeployOpen can prepare the technical and documentary setup that makes your AC-22 process repeatable. For a fixed scope agreed in writing, this typically covers configuring the roles and permissions in self-hosted publishing platforms, building review workflows that hold content until a designated reviewer approves it, and drafting evidence templates. The partner works inside your infrastructure and does not decide who may post or what counts as nonpublic information. DeployOpen prepares systems and evidence and does not issue assessment results.
- Role configuration: Set up posting rights so that only designated roles can publish to public areas, with permissions scoped at the appropriate level of the platform.
- Review workflows: Build approval steps so proposed content is reviewed before it goes live.
- Version history: Enable change tracking so you can show what was posted, when and by whom.
- Evidence templates: Draft forms for designation lists, training attestations and review logs that your staff complete.
- Documentation: Record the configuration in the system documentation so the assessor can trace the control to its settings.
Ask the partner to state in the statement of work which configurations, templates and documents will be delivered, and who will test them.
The independent auditor, assessor or certification body is the only party that tests AC-22 and issues a report or certificate. Under SP 800-53A, the assessment uses examine, interview and test methods against five determination statements. The assessor will review the designation list and training records, interview the people who manage publicly accessible information, and test whether the platform mechanisms actually restrict posting and support reviews. Their findings belong to them, not to your implementation partner.
- Examine: Review the list of authorized posters, training materials, training records and records of publicly accessible information reviews.
- Interview: Speak with personnel responsible for managing publicly accessible information on your systems.
- Test: Verify that the mechanisms implementing content management behave as documented, such as restricted posting rights and approval steps.
- Judge the result: Determine whether each determination statement is satisfied based on the evidence presented.
- Report: Issue findings through the assessment or authorization process your framework requires.
Before the assessment, confirm which assessor is engaged, what sampling they will perform and which evidence formats they accept.
Where AC-22 programs usually fall short
AC-22 looks simple on paper, but most gaps come from ownership and routine, not from missing policy text. The cards below cover the places assessors most often find nothing on file, and each one pairs the gap with an action that leaves a record behind.
No written list of authorized posters
AC-22 requires the organization to designate who may post information publicly, and an assessor will ask for that designation in writing. Many programs rely on whoever has the password, so nobody can say who was meant to publish. Create a named list tied to roles, approved by the content owner, and check it against the current staff roster at the review interval you set. Ask your assessor which form of list they expect to examine.
Shared logins on the CMS
When a website or intranet publishing tool is accessed through one shared account, posts cannot be traced to a person, and removing a departed editor means changing a password for everyone. This undermines both the designation and the training evidence AC-22 expects. Give each authorized poster an individual account with a role limited to publishing that content, and record who holds each role. Confirm in your platform's admin console that the audit history shows individual users.
No record of pre-posting review
AC-22 expects proposed content to be reviewed for nonpublic information before it goes live. Teams often review informally in chat or email, and nothing ties the approval to the page that was published. Require a reviewer sign-off step before publication, and keep the approver, date and final version together. Version history in a wiki or document system can show what changed and who made each change, which makes the review trail easier to reproduce.
Review frequency never defined
AC-22 requires periodic review of content already posted, and the organization must set the frequency itself. Programs that never write a number tend to review only after a complaint or incident, which an assessor will treat as no defined review at all. Set a frequency for each public site, record it in the procedure, and log each completed review with the reviewer's name. Choose a frequency your team can keep, since a missed review with a documented interval is easier to explain than an undocumented one.
Orphaned pages from former staff
Pages published by people who have left often stay online with no owner, and they are the ones most likely to contain outdated contact details, internal project names or draft material. A periodic account review will not catch them because the content still exists. Assign an owner to every published page, and when an author leaves, reassign or retire their pages as part of offboarding. Search for pages whose creator no longer has access and include them in each scheduled review.
Attachments and APIs exposing nonpublic data
A page review often reads the visible text and misses the PDF, spreadsheet or image attached to it, as well as JSON endpoints or data exports that a public site feeds from internal databases. AC-22 concerns what is publicly reachable, so these paths belong in scope. Inventory every public file store, export and API that serves content, and include them in the review checklist. Test the public endpoints from outside your network so the review reflects what an outsider can actually retrieve.
Questions buyers ask about AC-22 cost, effort and outside help
How much effort does AC-22 take to implement?
AC-22 is one of the lighter access control requirements because it has no control enhancements and a short set of determination statements, but the effort sits in process and people rather than in technology. The work is to name who may post publicly, train them, put a review step in front of publishing, and run recurring reviews of content already live. The amount of effort rises with the number of websites, portals, repositories and social channels that publish on the organization's behalf, and with how many people hold posting rights. NIST's SP 800-53A Rev. 5 assesses AC-22 with 5 determination statements, which gives a sense of the scope an assessor will test. Ask your team to inventory every public channel before estimating effort.
Can we implement AC-22 in-house without outside help?
Most organizations with an established communications or web team can implement AC-22 in-house, because the control is mainly about authorization, training and review records. The organization owns the control and must make the decisions: who may post, what counts as nonpublic information, and how often public content is reviewed. Outside help is most useful when the public content runs on several self-hosted platforms that need consistent permission models, logging and review workflows. An implementation partner can configure those systems and prepare evidence, but it cannot decide the organization's posting policy or issue an assessment result. Only an independent assessor can issue that finding.
What does the work need from our team?
The work needs input from four groups, and the list is useful when you scope an engagement:
- Policy owners who define the review frequency and the categories of nonpublic information to remove.
- Content owners who know which pages, documents and repositories are public.
- Platform administrators who manage permissions on the systems that host public content.
- Training and records staff who keep the training materials and review logs that an assessor will examine.
Each group needs a named person and a little time for review sessions. Your team should decide these roles before any outside partner starts configuration work.
How long does it take to prepare AC-22 evidence, and what drives the timing?
No fixed duration applies, because the time depends on the number of public channels, how many people hold posting rights, and whether review and training records already exist. Preparation is faster when a list of authorized posters, training materials and review logs is already kept, and slower when the organization must build those records from nothing. Platform choices also matter: a wiki or documentation system that keeps version history and role-based permissions makes the review trail easier to produce. Ask any partner to base its timeline on a written scope that lists each public system and each evidence artifact.
Will an auditor accept our AC-22 evidence?
An auditor or assessor decides whether the evidence is sufficient, and no implementation partner can promise a result. Assessors typically examine the list of users authorized to post publicly accessible content, the training materials and records, and records of publicly accessible information reviews. They also interview the people responsible for managing public information and test the mechanisms that enforce posting controls. Evidence is more persuasive when it is dated, attributable to a named person and easy to retrieve. Confirm the assessor's expectations before you build the evidence set, because the assessment method and scope are set by the authorizing body and the organization's own policies.
What should we put in a quote for AC-22 outside help?
A quote should follow from a written scope, and it should list the deliverables and their boundaries. Ask for these items in writing:
- The public systems in scope and the access model for each.
- The authorized poster list, training material and review workflow to be prepared.
- The evidence artifacts the partner will deliver and how they are stored.
- The assumptions about your team's time, including review sessions and approvals.
- Whether ongoing review support or a retainer is included, since recurring reviews are a separate cost.
DeployOpen does not publish a price list, and its engagements are fixed-scope, so the quote is agreed in writing before work begins.
Which AC-22 costs are one-time and which recur?
One-time costs include setting up posting permissions, writing the authorization list, building training material and configuring review workflows on each public system. Recurring costs include periodic reviews of public content, refresher training, updates when staff change and retained evidence for each assessment cycle. The recurring share grows with the volume of public content and the frequency your policy sets for reviews. When you compare options, ask whether a quote separates setup from recurring review work, because the two are often priced differently.
How DeployOpen prepares AC-22 evidence
DeployOpen starts AC-22 work with a fixed-scope written agreement that names each publicly accessible system in scope, such as a public website, a documentation portal or a public download area, along with the content types each one carries and who on the client side approves posting. The agreement also states which self-hosted platforms run inside the client's own cloud accounts, data centers or air-gapped networks, and which parts of the control the client keeps. The organization owns AC-22: it decides who may post, how often public content is reviewed, and what counts as nonpublic information. DeployOpen configures the systems and prepares the records so those decisions can be shown to an assessor. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not publish a price list.
On the technical side, the work centers on the role model and review workflow. In a wiki or knowledge base such as BookStack, DeployOpen maps posting rights to named roles at the shelf, book, chapter or page level so that only the designated individuals can publish to public content, and it records which roles were granted and why. Where a draft must be reviewed before it appears publicly, the review step is configured so the reviewer's sign-off is retained alongside the page. XWiki's version history, which records what changed, when and by whom, supplies the change trail an assessor can sample. The client confirms the platform's exact capabilities for its chosen version before the design is finalized, because the features described here depend on how the publishing path is built.
DeployOpen then assembles the evidence file the independent assessor will examine: the list of authorized posters, training materials and attendance records, review logs for proposed content, periodic reviews of posted content with any nonpublic information removed, and the configuration exports that show who can publish. DeployOpen does not issue assessment results, attestations or certifications. Those come from the organization's independent assessor or certification body, which tests the control against SP 800-53A's procedures and decides what the evidence supports. Before engaging, ask the assessor which review frequency and evidence format it expects, and confirm with the client's own assessment authority which AC-22 organization-defined parameter values apply to each public system.
