AU-13: Monitoring for Information Disclosure

What This Control Requires

AU-13 requires organizations to actively monitor open-source information sites for evidence that sensitive data has been disclosed without authorization. You need to define which public platforms to watch, set a monitoring frequency, and establish a response plan that includes notifying designated personnel and taking corrective action when your team detects a disclosure.

The scope of monitoring extends beyond your own website or domains. Social networking sites, code-sharing repositories, paste sites, and public forums all fall within the control’s reach. Any platform where employees, contractors, or automated systems could inadvertently expose personally identifiable information, proprietary documents, or internal configurations qualifies as a target for NIST SP 800-53 AU-13 monitoring.

Where this breaks down in practice is the response side. Many organizations set up monitoring alerts but lack documented procedures for what happens next. AU-13 doesn’t just require detection. It requires a defined notification chain and a set of additional actions your organization commits to taking when unauthorized disclosure surfaces.

Why It Matters

Unauthorized information disclosure creates compounding risk across credential theft, intellectual property loss, and regulatory exposure. Organizations that don’t monitor for leaked data on public platforms leave a gap that auditors will flag and attackers will exploit.

Failure to maintain AU-13 introduces audit risk and may result in certification withdrawal or regulatory findings. Federal agencies and contractors operating under FISMA or FedRAMP face direct consequences when assessors find no evidence of open-source monitoring. The control sits at the intersection of audit accountability and data breach prevention, making it a recurring line item in authorization packages and continuous monitoring programs.

The gap between “we have a DLP tool” and “we monitor open-source sites for disclosure” is exactly where AU-13 lives. DLP tools focus on preventing exfiltration at the boundary. AU-13 addresses what happens after data has already left your perimeter and landed on a public platform. Without both, your detection posture has a blind spot.

In practice, the organizations that struggle most with AU-13 are those that treat it as a one-time configuration task rather than an ongoing operational commitment. A quarterly scan of GitHub for exposed API keys doesn’t satisfy a control that requires a defined monitoring frequency aligned to organizational risk.

What Attackers Exploit

Exposed credentials and API keys published to code repositories like GitHub, GitLab, or Bitbucket
Sensitive internal documents or data sets posted to paste sites and file-sharing platforms
Proprietary architectural details discussed by employees on public forums or social media
Configuration files and infrastructure details indexed by search engines after accidental publication
Leaked customer PII or trade secrets surfaced through dark web marketplaces or data dump sites

How to Implement

The most common failure mode for AU-13 is treating it as a tooling checkbox rather than a process. Organizations purchase a monitoring platform, enable default alerts, and assume the control is satisfied. Without defined scope, frequency, notification procedures, and documented response actions, the tool alone won’t pass an audit.

For Your Organization

Step 1 — Define what requires monitoring. Start by identifying the categories of organizational information that would cause harm if disclosed publicly. At minimum, this includes PII, source code, authentication credentials, internal architecture documentation, trade secrets, and financial data. Document these categories in your system security plan.

Step 2 — Identify the platforms to monitor. Build a registry of open-source information sites relevant to your organization’s risk profile. Code-sharing platforms, paste sites, social media networks, dark web forums, document-sharing services, and public search engine caches should all be on the list. Tailor the registry to your industry and the types of data you handle.

Step 3 — Set a monitoring frequency. AU-13 requires you to define how often monitoring occurs. The frequency should reflect the sensitivity of the data and the speed at which an attacker could weaponize leaked information. High-risk environments may warrant continuous or daily monitoring. Lower-risk contexts might justify weekly scans, but ad hoc or undefined schedules won’t satisfy the control.

Step 4 — Deploy and configure monitoring tools. Categories of tooling that support AU-13 include compliance monitoring platforms, brand protection services, code repository scanners, dark web monitoring tools, and data loss detection solutions. Configure alerts to match the information categories and platforms you defined in Steps 1 and 2.

Step 5 — Establish notification and response procedures. Document who receives alerts when unauthorized disclosure is detected. Define the communication channel, the escalation path, and the timeframe for initial notification. Then specify the additional actions your organization will take, such as credential rotation, takedown requests, legal engagement, or triggering the incident response plan.

Step 6 — Maintain records. Retain monitoring logs, alert histories, notification records, and response documentation. Auditors will examine these artifacts to verify that monitoring actually occurs at the stated frequency and that your team follows through on detected disclosures.

Common mistakes:

Monitoring only company-owned domains while ignoring third-party platforms where data commonly leaks
Lacking a defined monitoring frequency, relying instead on ad hoc or event-triggered checks
Notification procedures that route alerts to a shared inbox without named individuals or role-based escalation
No documented response actions beyond “investigate,” leaving assessors without evidence of a repeatable process

For Your Vendors

When your vendors handle sensitive organizational data, their exposure on public platforms becomes your risk. Evaluating AU-13 compliance in your vendor population requires targeted questions and evidence validation.

What to ask in security questionnaires:

Do you maintain a program for monitoring public information sites for unauthorized disclosure of client data?
What is your defined monitoring frequency?
Which categories of platforms do you monitor (code repositories, paste sites, social media, dark web)?
Who is notified when a disclosure is detected, and within what timeframe?
What corrective actions do you take after discovering an unauthorized disclosure?

What evidence to request:

Information disclosure monitoring policy or procedure document
Configuration documentation for monitoring tools
Sample monitoring logs or alert records (redacted as needed)
Records of past disclosure incidents and the response actions taken
Third-party data protection agreements that include monitoring obligations

Red flags:

The vendor has no formal monitoring program and relies on customers or external researchers to report exposed data
Monitoring frequency is undefined or described as “as needed”
No named roles responsible for receiving and acting on disclosure alerts
The vendor cannot produce any monitoring records or incident response documentation

How to verify beyond self-attestation. Request a demonstration of the vendor’s monitoring tool configuration. Ask for evidence of a past disclosure detection and the documented response. Cross-reference the vendor’s monitoring scope against the types of data they handle on your behalf. If the vendor processes PII or source code but only monitors their own domain, the gap is material.

Evidence Examples

Evidence Type	Example Artifact
Policy documentation	Audit and accountability policy defining information disclosure monitoring requirements, roles, and escalation procedures
System security plan	SSP sections specifying monitored open-source platforms, monitoring frequency, and notification chains
Privacy plan	Privacy plan addressing monitoring of public sites for unauthorized PII disclosure
Monitoring procedures	Documented procedures for scanning code repositories, paste sites, social media, and dark web forums for organizational data
Tool configuration	Screenshots or exports of monitoring tool settings showing platform coverage, alert rules, and scan schedules
Monitoring records	Logs from monitoring tools showing scan execution history, alert triggers, and timestamps aligned with stated frequency
Incident response records	Incident ticket and response log showing detected disclosure event, notified personnel, timeline of corrective actions taken
System audit records	Audit trail entries confirming monitoring activities occurred at the defined frequency

Cross-Framework Mapping

Framework	Control(s)	Coverage
ISO 27001:2022	8.12 Data leakage prevention	Partial
ISO 27001:2022	8.16 Monitoring activities	Partial

AC-22 — Publicly Accessible Content: Governs what the organization approves for public release, reducing the surface area that AU-13 must monitor for unauthorized disclosures.
PE-03 — Physical Access Control: Restricts physical access that could lead to unauthorized removal and public disclosure of sensitive information.
PM-12 — Insider Threat Program: Provides the organizational framework for detecting insider-driven disclosures that AU-13 monitoring may surface on public platforms.
RA-05 — Vulnerability Monitoring and Scanning: Identifies technical weaknesses that could enable or indicate unauthorized information disclosure across systems.
SC-07 — Boundary Protection: Controls information flow at network boundaries, complementing AU-13’s external monitoring focus with internal egress controls.
SI-20 — Tainting: Embeds traceable markers in sensitive data, enabling AU-13 monitoring to attribute unauthorized disclosures back to their source.

Frequently Asked Questions

What Is NIST SP 800-53 AU-13

AU-13 is the NIST SP 800-53 control that requires organizations to monitor open-source information sites for evidence of unauthorized disclosure of organizational data. It applies to any public platform where sensitive information could appear, including code-sharing repositories, social networking sites, paste sites, and dark web forums. The control mandates a defined monitoring frequency, a notification chain for designated personnel, and documented additional actions to take when a disclosure is discovered.

What Happens if AU-13 Is Not Implemented

Without AU-13, your organization has no structured process for detecting when sensitive data appears on public platforms. Leaked credentials, exposed PII, and published proprietary documents can persist on open-source information sites indefinitely, compounding the risk with every day they go undetected. Auditors assessing your Audit and Accountability controls will flag the absence of monitoring procedures, monitoring records, and notification documentation as a direct finding against your authorization package.

How Do You Audit AU-13

Auditors assess AU-13 by examining your information disclosure monitoring procedures, reviewing monitoring records to confirm scans occur at the defined frequency, and verifying that notification chains reach designated personnel. They will test whether your monitoring scope covers the open-source information sites specified in your system security plan. They also look for documented evidence that your organization took the defined additional actions when an unauthorized disclosure was detected, including incident response records and communication logs.

What Open-Source Sites Should Organizations Monitor Under AU-13

Organizations should monitor any publicly accessible platform where organizational data could surface without authorization. The most common targets include code-sharing repositories like GitHub and GitLab, paste sites such as Pastebin, social networking platforms, public cloud storage buckets, dark web marketplaces, document-sharing services, and search engine caches. Your specific monitoring list should reflect the types of sensitive data you handle and the platforms most likely to host unauthorized disclosures of that data, as documented in your system security plan and privacy plan.