AC-22: Publicly Accessible Content

NIST SP 800-53 Revision 5 Access Control Low Moderate High

What this control requires

AC-22 requires organizations to control who publishes information on publicly accessible systems and ensure nonpublic data never appears there. The control applies to any system the organization operates that the public can reach, typically without authentication, including websites, public-facing portals, cloud storage buckets, and downloadable document repositories. It belongs to the Access Control family.

In practice, the control means four things must happen. First, the organization must formally name the individuals allowed to publish content to public-facing systems. Second, those individuals must receive training that teaches them to distinguish nonpublic information (such as personally identifiable information (PII), proprietary data, and content protected under the Privacy Act) from information cleared for release.

The result is that every proposed publication must pass a review gate before reaching the public, and content already live must be checked on a defined schedule. Anything nonpublic found during those checks must be removed.

Where organizations lack formal controls, the boundary between internal and publicly available information depends entirely on individual judgment. Individual judgment, in the absence of documented processes, is the root cause of most data exposure incidents tied to cloud storage misconfigurations, website errors, and accidental document publishing.

Why it matters

The risk class AC-22 addresses, nonpublic data accidentally published to a publicly accessible location, is one of the most common and preventable sources of data exposure in modern organizations. Specifically, cloud storage defaults, web CMS permissions, and vendor-operated infrastructure all create conditions where a single misconfiguration can expose millions of records to the open internet.

Verizon and NICE Systems S3 bucket exposure (2017)

In June 2017, an UpGuard security researcher discovered an unprotected Amazon S3 storage bucket containing records on approximately 14 million Verizon subscribers. The bucket was not operated by Verizon directly but by NICE Systems, an Israeli telecom analytics vendor that Verizon used for call center operations and customer data analysis.

Specifically, NICE had set the S3 bucket’s access control to public, meaning any internet user with the bucket URL could download its contents without authentication. The data included customer names, addresses, account details, and, for a subset of records, account PINs.

In practice, the AC-22 failure was that information restricted to authorized users, specifically customer account data including PINs, ended up published to a publicly accessible location by a vendor operating on Verizon’s behalf. None of the control’s requirements were effective here. No formal review process caught the misconfiguration, and no periodic check identified the public exposure before an external researcher did.

Where this failure deepened was in vendor governance. Verizon’s data was in NICE’s custody, but the controls governing how NICE stored that data were insufficient to prevent public exposure. Verizon confirmed the exposure after notification from UpGuard and stated that no data had been stolen by a malicious actor.

The consequence extended beyond Verizon: the incident was one of a wave of S3 bucket disclosures in 2017 that collectively demonstrated the systemic risk of cloud storage misconfiguration, the precise risk class AC-22 is designed to address. (ZDNet)

What attackers exploit

• Misconfigured cloud storage permissions. S3 buckets, Azure Blob containers, and Google Cloud Storage buckets set to public access by default or by error, as documented in the Verizon data exposure
• Vendor-operated infrastructure. Third parties storing or processing organizational data without equivalent access controls
• Lack of content review before publishing. No gating process between content creation and public posting
• Absent periodic review of posted content. Nonpublic data persists on public systems because no one checks what is already live
• Confusion between internal and external systems. Staging environments, test portals, or analytics tools exposed to the public internet

How to implement

The most common failure mode for AC-22 is not the absence of a policy (most organizations have one) but the gap between policy and operational practice. Content review processes break down when they rely on manual steps that are easy to bypass, when they do not extend to vendor-operated infrastructure, or when periodic reviews of already-posted content happen only on paper.

For your organization

Step 1. Designate authorized publishers. Maintain a formal, current list of individuals authorized to post information on each publicly accessible system your organization operates. Applicable systems include websites, public portals, cloud storage, document repositories, and any system reachable without authentication. Store this list alongside system access records and review it quarterly or when personnel change.

Step 2. Train authorized individuals. Go beyond generic security awareness. Training must cover the specific categories of nonpublic information relevant to your organization (PII, proprietary data, Privacy Act-protected records, controlled unclassified information if applicable), how to identify them in draft content, and what to do when nonpublic data is found in a proposed publication. Document completion in your learning management system or training records.

Step 3. Implement pre-publication review. Require a documented review and approval step before any content reaches a publicly accessible system. For web content, the review step may take the form of a content management system (CMS) workflow with an approval gate. For cloud storage, it may require a second reviewer to confirm bucket permissions and file classifications before data is uploaded.

For documents, it may involve a data classification check. No content should reach the public without at least one person other than the author confirming it contains no nonpublic information.

Step 4. Schedule periodic reviews of live content. Define a frequency (monthly or quarterly is typical) and review all content on publicly accessible systems for nonpublic information. Automate where possible; cloud security posture management tools can flag storage buckets with public permissions, and data loss prevention solutions can scan public-facing sites for sensitive data patterns. Document each review cycle and any remediation actions taken.

Step 5. Remove and document. When nonpublic information is discovered on a public system, remove it immediately, document the finding and response, and investigate how it was posted. Incorporate findings into training and process improvements. Organizations that align this process with access enforcement controls strengthen their overall posture.

Common mistakes:

• Treating the authorized publisher list as a one-time exercise rather than a living document
• Limiting training to general security awareness without covering content classification specifics
• Relying on a single person for both content creation and review (no separation of duties)
• Defining a review frequency but never conducting or documenting actual reviews
• Excluding vendor-operated systems from the scope of AC-22 processes

For your vendors

What to ask in a security questionnaire:

• Do you maintain a list of personnel authorized to post information to publicly accessible systems?
• What training do authorized publishers receive on distinguishing nonpublic from public information?
• Describe your pre-publication content review process for data hosted on publicly accessible infrastructure.
• How frequently do you review already-published content for nonpublic information, and how are findings remediated?
• When you store or process our data, what controls prevent it from being exposed on publicly accessible systems?

What evidence to request:

• Copy of the publicly accessible content policy
• List of authorized publishers (redacted if needed)
• Training completion records for content publishers
• Sample content review and approval records
• Results from the most recent periodic review of public-facing content

Red flags:

• Vendor cannot produce an authorized publisher list or says “everyone can publish”
• No documented pre-publication review process exists
• Cloud storage buckets or data repositories default to public access
• Vendor has no periodic review schedule for publicly accessible content
• Past incidents involving accidental data exposure with no documented corrective action

Verification beyond self-attestation: Use external attack surface management tools to identify any publicly accessible storage, portals, or documents associated with the vendor’s infrastructure. Cross-reference findings with the vendor’s stated controls to validate that their processes match their attestations.

Evidence examples

The following artifacts demonstrate compliance with AC-22’s requirements and are commonly requested during audits.

Cross-framework mapping

For a complete list of NIST SP 800-53 controls, see the framework index.

Related controls

• AC-03, Access Enforcement: enforces approved authorizations for system access, intersecting with AC-22 by determining who can access and modify publicly accessible systems in the first place.
• AT-02, Literacy Training and Awareness: provides the foundational security awareness training that AC-22 builds upon with specialized training for individuals authorized to post publicly accessible content.
• AT-03, Role-based Training: delivers targeted training to personnel with specific security roles, directly supporting the specialized training requirement for authorized content publishers under AC-22.
• AU-13, Monitoring for Information Disclosure: monitors for unauthorized disclosure of information, complementing AC-22’s periodic review requirement by providing automated detection of nonpublic information on public systems.

Frequently asked questions

What is NIST SP 800-53 AC-22?

AC-22 is the NIST SP 800-53 control that requires organizations to manage who is authorized to post information on publicly accessible systems and to verify that nonpublic information is never included. It applies to any organization-controlled system that the public can reach without authentication, including websites, cloud storage, public portals, and document repositories. The control mandates four activities: designating authorized publishers, training them on nonpublic information, reviewing content before posting, and periodically reviewing posted content to find and remove any nonpublic data that slipped through.

What happens if AC-22 is not implemented?

Failure to implement AC-22 leaves organizations exposed to accidental publication of nonpublic information on publicly accessible systems, a risk that has led to some of the largest data exposures in recent years. Without a formal authorized publisher list, anyone with system access can post content without oversight. Without pre-publication review, sensitive data such as customer PII, account credentials, or proprietary documents can reach the public internet through a single misconfigured storage bucket or CMS publishing error.

Audit findings for AC-22 non-compliance can affect authorization to operate decisions across LOW, MODERATE, and HIGH baselines.

How do you audit AC-22?

Auditors assess AC-22 by examining the authorized publisher registry, verifying that training records exist for each listed publisher, and reviewing pre-publication approval logs to confirm content was checked before posting. AC-22 is part of the Access Control family, and auditors typically evaluate it alongside related access enforcement controls.

They also request evidence of periodic content reviews (documented scans or manual reviews of publicly accessible systems for nonpublic information) and inspect remediation records for any instances where nonpublic data was found and removed. Interviews with authorized publishers and information security staff confirm that personnel understand their responsibilities and can describe the review process.

Who is responsible for publicly accessible content under AC-22?

The organization is responsible for designating specific individuals authorized to make information publicly accessible. AC-22 does not delegate this responsibility to a generic “content team” or assume everyone with CMS access qualifies. In practice, organizations typically assign content publishing authority to named roles (web content managers, communications officers, or designated system administrators) and maintain a formal list tied to each publicly accessible system.

When vendors operate publicly accessible infrastructure on the organization’s behalf, the organization remains accountable for ensuring equivalent controls govern how those vendors handle content publishing.