AC-22: Publicly Accessible Content

AC-22 requires you to formally designate who is authorized to publish information to public channels (websites, repos, app stores, social media, public cloud buckets) and to operate a repeatable process that prevents unauthorized public release. Operationalize it by naming content publishers, defining approval rules, and keeping evidence that only authorized people can make content public. ¹

Key takeaways:

• Assign named roles (and backups) who can make content public, then enforce that in tools and workflow. ¹
• Treat “publicly accessible” as a distribution state across many platforms, not just your corporate website. ²
• Keep assessor-ready evidence: the authorization list, access controls, and change/approval records for public releases. ¹

The ac-22: publicly accessible content requirement is a simple sentence with broad operational impact: you must decide, explicitly, who is allowed to publish information to the public. In regulated environments, “public” includes any channel where unauthenticated users can retrieve data, code, documents, screenshots, marketing content, system diagrams, or configuration details. A single misstep can cause data exposure, contract noncompliance, incident response costs, and reputational harm.

AC-22 is often treated as “a comms policy,” but assessors will look for practical controls: named authorizers, enforced permissions in publishing systems, and a trail that proves public release is intentional and reviewed. This control also intersects with third parties: agencies, hosting providers, and marketing firms can publish on your behalf, so your authorization model must extend to outsourced publishing and shared platforms.

This page translates AC-22 into an implementation checklist a CCO, compliance officer, or GRC lead can assign, track, and validate quickly.

Regulatory text

Control requirement (excerpt): “Designate individuals authorized to make information publicly accessible;” ¹

What the operator must do

You must (1) name specific individuals or roles that are allowed to publish information to the public, and (2) ensure your operating model matches the designation. “Designation” without technical enforcement and records typically fails in assessment, because it does not show the requirement is operating in practice. ¹

Plain-English interpretation (what AC-22 is really asking)

AC-22 expects a controlled publishing boundary. Your organization should be able to answer, quickly and consistently:

• Who is allowed to post content publicly?
• Which systems count as “public publishing” systems?
• What review happens before something becomes public?
• How do you prevent other people (including well-meaning engineers) from making something public “just to test”?

This is access control applied to public release. You are reducing the likelihood that sensitive, proprietary, export-controlled, regulated, or contract-restricted information ends up publicly accessible.

Who it applies to (entity and operational context)

AC-22 applies wherever you implement NIST SP 800-53 controls, including:

• Federal information systems and the programs that operate them. ²
• Contractor systems handling federal data, including environments used to develop, host, process, or store federal information. ²

Operationally, it applies to any team that can publish or expose information externally, including:

• Web/content teams (CMS, corporate site, landing pages)
• Engineering (public repos, package registries, API docs)
• Cloud/platform (public buckets, object storage, CDN paths)
• Product (app store listings, public documentation sites)
• Support/sales (knowledge bases, community forums)
• Security (public advisories, status pages)
• Third parties acting as publishers (PR firms, web agencies, MSPs)

Scoping: what counts as “publicly accessible content”

Define “publicly accessible” based on access path, not your intent. Include at least these categories in your scope statement:

• Corporate website and CMS
• Public documentation portals (static site generators, wikis)
• Public code repositories (org accounts and personal accounts used for work)
• Public cloud storage endpoints (object storage, file shares, CDN origins)
• Public ticketing/knowledge base portals
• Social media and video platforms used for official communications
• App store and browser extension listings
• Public status pages and incident communications pages

A practical scoping method: inventory “places where anonymous users can access your content,” then tie each place to an owner, a permission model, and a publishing workflow.

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

Step 1: Create a “public publishing systems” inventory

Build a table and keep it current. Minimum columns:

• System/platform name (CMS, GitHub org, S3 buckets, Confluence public spaces, etc.)
• Public exposure mechanism (domain, repo visibility, bucket policy, sharing setting)
• Business owner
• Technical owner/admin
• Where permissions are managed (IAM group, CMS roles, org team)
• Logging source for publishing events (audit log location)

This table becomes your AC-22 scope anchor for audits.

Step 2: Designate authorized publishers (by role and by named individuals)

AC-22 explicitly calls for designation of individuals authorized to publish. ¹

Do it in two layers:

• Roles (e.g., “Web Content Publisher,” “Open Source Maintainer,” “Public Docs Release Manager”)
• Named assignments to those roles (primary + backup), tracked in an access request system or GRC register

Make the designation unambiguous. A common audit failure is “Marketing can post,” with no named authorization and no tie to system permissions.

Step 3: Enforce designation through access controls in each system

Policy alone does not stop publication. Align your designation list to technical controls:

• Create groups/roles in each platform that map to “Authorized Public Publisher.”
• Restrict “make public” actions (publish, change repo visibility, modify bucket policy, change KB visibility) to those groups.
• Remove direct permissions from individuals who are not designated.

If a platform cannot restrict “public” actions cleanly, implement compensating controls such as:

• Mandatory peer review for changes to “public exposure” settings
• Change management approvals for configuration updates affecting public access
• Scheduled configuration checks for accidental exposure

Step 4: Implement a lightweight pre-publication review gate

AC-22 does not prescribe a review process, but operationally you need one to make the designation meaningful and defensible.

A workable minimum:

• Content classification check (does it contain nonpublic information?)
• Security/privacy check for screenshots, logs, architecture diagrams, or identifiers
• Legal/contract check if content references customers, government work, or third-party IP
• Approval by an authorized publisher (the designated role)

Keep the workflow simple so teams follow it. Complex gates drive “shadow publishing.”

Step 5: Add monitoring for public exposure drift

Assign someone (often security or platform engineering) to monitor for:

• Newly public repos
• Bucket/object policy changes that allow anonymous read
• New DNS records pointing to public endpoints
• CMS permission changes

Monitoring is not required by the AC-22 sentence, but it is a practical safeguard when multiple teams and third parties can change exposure settings.

Step 6: Operationalize third-party publishing

If a third party publishes on your behalf (PR agency, web developer, managed service):

• Require them to follow your designation model (named individuals at the third party)
• Contractually restrict public release authority to approved contacts
• Ensure their accounts are in your permission groups and removed promptly on offboarding

This is where AC-22 meets third-party risk management: you must control who can publish, even if they are external.

Required evidence and artifacts to retain

Assessors typically want proof that designation exists and is enforced. Retain:

• AC-22 procedure: a short standard operating procedure describing designation, platforms in scope, and how permissions are enforced ¹
• Authorized publisher roster: named individuals, roles, effective dates, approving manager
• Access control mappings: screenshots or exports showing group/role membership in each publishing system
• Access request and approval records: tickets for granting/removing publisher access
• Change/approval records for public releases: PR approvals, CMS publish approvals, change tickets
• Audit logs (where available): evidence of who published and when
• Periodic access reviews: sign-offs showing publisher access was reviewed and still appropriate

Tip for audit-readiness: store artifacts per platform, then roll them up into a single AC-22 evidence folder by review period.

Common exam/audit questions and hangups

Expect these questions:

• “Show me who is authorized to publish content publicly.” (You should produce a roster quickly.)
• “Which systems are in scope for public publishing, and who owns them?”
• “How do you technically prevent a non-authorized user from making a repo/bucket/page public?”
• “Show evidence of a recent public release and the approvals.”
• “How do you handle third parties that can publish on your behalf?”
• “How do you remove access when someone changes roles or leaves?”

Hangups that trigger deeper testing:

• Personal accounts used for official publishing (GitHub, social media)
• Multiple CMS instances with inconsistent permissions
• Cloud storage and CDN misconfigurations that can bypass your “publisher” workflow
• “Everyone in Engineering can create public repos” defaults

Frequent implementation mistakes (and how to avoid them)

1. Designation exists only in a policy PDF. Fix: map designated roles to real permission groups and prove membership with exports/screenshots.
2. Only scoping the corporate website. Fix: include repos, cloud storage, KBs, social channels, and third-party-managed properties.
3. Relying on “tribal knowledge” approvals. Fix: require a ticket, pull request, or documented approval for publication events.
4. No offboarding path for publishers. Fix: tie publisher access to identity lifecycle triggers and run periodic access reviews.
5. Treating configuration as separate from content. Fix: include “make public” settings (repo visibility, bucket policies) as publishing actions covered by AC-22.

Enforcement context and risk implications

No AC-22-specific public enforcement cases were provided in the source catalog for this requirement page, so this guidance stays focused on assessment expectations and operational risk rather than citing specific actions.

From a risk lens, AC-22 failures usually show up as:

• Accidental public exposure of sensitive information
• Breach notifications and customer trust impacts
• Contract findings in federal or regulated audits
• Increased incident response workload due to unclear publishing authority

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign an AC-22 control owner and a backup owner.
• Inventory public publishing systems and identify current admins.
• Publish an initial “authorized publisher” roster for the highest-risk platforms (website CMS, code repos, cloud storage consoles).
• Freeze ad hoc publishing where possible (temporary permission tightening) until roles are clear.

Days 31–60 (enforce and instrument)

• Implement role-based access groups for authorized publishers in each platform.
• Remove “make public” permissions from broad groups.
• Stand up a basic approval workflow (ticket or PR-based) for each platform.
• Start capturing recurring evidence (access lists, approval records, audit logs).

Days 61–90 (prove operations and close gaps)

• Run an access review of authorized publishers and document results.
• Test a sample of publication events end-to-end (request → approval → publish → log retention).
• Extend the model to third parties and less obvious channels (status pages, KB, social media).
• Add monitoring for public exposure drift and document response steps when drift is detected.

How Daydream fits (without adding process drag)

Most AC-22 programs fail on evidence consistency across many platforms. Daydream helps by mapping AC-22 to a named control owner, a repeatable implementation procedure, and a recurring evidence set so you can answer assessor questions quickly and keep the control operating without rebuilding spreadsheets every audit cycle. ¹

Frequently Asked Questions

Does AC-22 require a formal approval before every public post?

AC-22 requires designation of who is authorized to make information public. ¹ A lightweight approval step is the easiest way to prove the designation is working, but you can also meet intent through strict role permissions plus auditable publishing logs.

Are social media posts “publicly accessible content” under AC-22?

If the account is used for official communications and the public can access the content, treat it as in scope. Your designation should cover who can post, and you should retain evidence of account access control and role assignment.

What about engineers publishing open source code to a public repository?

Treat “make repo public” as a controlled action. Either restrict repo visibility changes to designated maintainers or require a documented approval workflow for visibility changes and new public repos.

We use a third-party web agency. Can they be the designated individuals?

Yes, but you still need explicit designation of named individuals (or tightly defined roles) at the third party and proof that only those accounts can publish. ¹ Build the requirement into the statement of work and offboarding process.

How do we handle emergencies where we need to publish quickly (outage/status updates)?

Pre-designate an on-call publisher role with backup coverage, and pre-authorize the channels used for emergency communications. Keep the same evidence trail: who posted, when, and under what authority.

What evidence is usually most persuasive to an auditor for AC-22?

A current authorized publisher roster plus system screenshots/exports showing that only those people have publish permissions is the fastest path. Add a small sample of recent publish approvals or logs to show the control operates in practice. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5