AU-13: Monitoring for Information Disclosure

AU-13 requires you to monitor open-source information and public information sites on a defined cadence for signs that your organization’s information was disclosed without authorization, then route verified findings into incident response and remediation. Operationalize it by scoping what “organizational information” means, selecting monitoring sources, documenting frequency and ownership, and retaining evidence from each monitoring cycle. ¹

Key takeaways:

• Define scope first: what information types, brands/domains, and channels count as “organizational information” for AU-13.
• Make monitoring repeatable: documented sources, frequency, owners, and an auditable evidence bundle per cycle.
• Treat hits as security events: triage, validate, contain, remove, and feed lessons learned back into prevention controls.

AU-13 is a “prove you are watching” control. Examiners and customers expect you to detect public leaks quickly, not learn about them from a journalist, a threat actor, or a third party. The control is intentionally flexible: you choose which open-source sources to monitor and how often to monitor them, based on your mission, data sensitivity, threat model, and public exposure. The operational risk is straightforward: if sensitive internal data shows up on paste sites, public code repositories, breach forums, misconfigured cloud buckets indexed by search engines, or employee social posts, you need a disciplined way to notice and respond.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn AU-13 into a short control card and a recurring operating procedure with crisp inputs and outputs: “What do we search, where do we search, how often, who reviews results, what is the escalation path, and what evidence do we retain?” That evidence must show sustained operation, not a one-time setup. ¹

Regulatory text

Requirement (excerpt): “Monitor [open-source information and/or information sites] [frequency] for evidence of unauthorized disclosure of organizational information; and” ¹

What the operator must do

1. Pick the monitoring surface: identify the open-source locations and public sites you will monitor (examples below).
2. Set a defined frequency: document how often monitoring runs and what triggers out-of-cycle checks (for example, a confirmed phishing incident or a terminated employee with elevated access).
3. Look for unauthorized disclosure: define what counts as evidence, validate suspected exposures, and document outcomes.
4. Tie monitoring to action: route confirmed findings into incident response, legal/privacy review (as applicable), and remediation workstreams.

NIST intentionally leaves the bracketed items to you to tailor. Your job is to make those choices explicit, risk-based, and repeatable. ²

Plain-English interpretation

AU-13 means: search the public internet for your leaked data and secrets on a regular schedule, and be able to prove you did it. “Monitoring” here is broader than SIEM logs. It includes OSINT-style searches and third-party leak signals that sit outside your perimeter.

What auditors typically want to see:

• A documented scope (what you’re trying to find).
• A monitoring cadence that matches your risk.
• A triage and escalation process for “hits.”
• Evidence from multiple completed cycles. ¹

Who it applies to

Entity scope

AU-13 is commonly applied in:

• Federal information systems.
• Contractor systems handling federal data. ¹

Operational context where AU-13 matters most

Prioritize AU-13 implementation if you have:

• Public-facing web apps, customer portals, or APIs.
• A large workforce using collaboration tools and sharing links externally.
• Software development with public code repos or open-source packages.
• High third-party dependency (SaaS, MSPs, contractors) where data can spill outside your boundary.
• Regulated or sensitive data types (e.g., government data, credentials, proprietary technical data).

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

Step 1: Create an AU-13 control card (owner, scope, cadence, exceptions)

Write a one-page “control card” that an operator can run without interpretation:

• Control objective: detect unauthorized public disclosure of organizational information.
• Owner: Security Operations (execution) + GRC (oversight) + Legal/Privacy (as-needed review).
• In-scope information: define categories such as credentials/secrets, internal documents, customer data, source code, architecture diagrams, incident artifacts, employee PII, non-public contracts.
• In-scope identifiers/keywords: company name variants, brands, domains, key executives, product codenames, repository names, file naming conventions, unique strings (watermarks), and known internal URL patterns.
• Monitoring frequency: set your baseline cadence and name trigger events that require out-of-cycle checks.
• Exception rules: what is out of scope, and how exceptions are approved and reviewed.

This directly addresses a common audit gap: teams cannot show who owns the requirement, how often it runs, or what evidence proves operation. ¹

Step 2: Define your monitoring sources (start small, document rationale)

Build a source register with “what we check” and “why we check it.” Common open-source surfaces:

• Search engines for indexed files, misconfigurations, and cached pages.
• Public code repositories and package registries for secrets or proprietary code.
• Paste sites and public text dumps.
• Data leak indexes and breach notification services (if you subscribe).
• Social media and public forums where employees or users may post screenshots/logs.
• Public cloud object storage exposures discoverable by OSINT techniques.

You do not need to monitor everything on day one. You do need to show a risk-based selection and a plan to mature coverage.

Step 3: Implement repeatable collection and triage

Set up a workflow with clear states. A simple, auditable model:

1. Collect: run searches and alerts; capture raw results (links, screenshots, hashes, timestamps).
2. Triage: classify as false positive, benign authorized disclosure, or suspected unauthorized disclosure.
3. Validate: confirm whether the data is genuinely yours and whether it is sensitive. Pull in system owners and data owners.
4. Escalate: if confirmed unauthorized disclosure, create an incident/security event ticket and notify required stakeholders.
5. Contain and remove: rotate credentials/secrets, disable exposed accounts, coordinate takedowns with site hosts, fix misconfigurations, patch root causes.
6. Close with lessons learned: feed improvements into DLP, secrets scanning, access controls, and secure SDLC.

Step 4: Integrate AU-13 with incident response and third-party processes

Operationalize the “and” at the end of the excerpt by wiring AU-13 outputs into:

• Incident response: define severity tiers for public disclosure events and required response SLAs (your internal targets).
• Privacy/breach assessment: define when legal/privacy must review (e.g., possible personal data exposure).
• Third party management: if the disclosure occurred at a third party, require notification, investigation results, and corrective actions under contract and your third-party issue management process.

Step 5: Define the minimum evidence bundle ¹

Decide what you will retain every time the control runs, so evidence doesn’t depend on who was on shift. This is the fastest way to pass audits with minimal friction. ¹

A practical minimum bundle:

• Monitoring run log (date/time, operator, method/tool, sources checked).
• Search queries/keywords used (or a reference to the version-controlled query set).
• Results summary (counts, notable hits, “no findings” attestation).
• Screenshots/exports of relevant hits (where policy allows).
• Triage notes (why it was false positive vs confirmed).
• Tickets created (incident, problem management, third-party issue) with closure evidence.
• Approval/oversight sign-off (lightweight, often GRC review of the monthly rollup).

Step 6: Run control health checks (prove sustained operation)

Schedule a recurring check by GRC or control owners:

• Confirm monitoring ran on schedule.
• Confirm evidence bundles exist and are complete.
• Confirm tickets closed to validated remediation.
• Track drift: source register outdated, keywords stale, ownership changes.

This is explicitly aligned to recommended best practices for demonstrating the control operates over time. ¹

Required evidence and artifacts to retain

Use this as an audit-ready checklist:

Artifact	What it proves	Owner
AU-13 control card (objective, owner, cadence, exceptions)	Control design and governance	GRC
Monitoring source register	Risk-based selection of OSINT sources	SecOps with GRC
Keyword/query library (versioned)	Repeatability and coverage	SecOps
Cycle evidence bundle (run log + results + triage)	Control operation	SecOps
Tickets and remediation records	Findings handled, not ignored	SecOps / IT / App teams
Metrics/rollups (trend of hits, classes of findings)	Oversight and continuous improvement	GRC

Retention period should match your broader audit log and incident record retention policy; keep it consistent and documented.

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me the last monitoring cycle. Who ran it? What sources were checked?”
• “How did you decide frequency? What triggers an out-of-cycle run?”
• “What counts as ‘organizational information’ here?”
• “How do you validate that a paste/repo content is truly yours?”
• “Walk me from a finding to an incident ticket to closure. Where’s the evidence?”
• “How do you handle findings caused by a third party?”

Hangup to avoid: producing a policy statement without execution logs. AU-13 is judged on operation, not intent. ¹

Frequent implementation mistakes (and how to avoid them)

1. No defined frequency
   Fix: put the cadence in the control card and calendar it. Tie missed runs to an exception process.

2. Monitoring only one channel (e.g., just Google searches)
   Fix: keep a small but diverse source register: search, repos, paste sites, and breach signals.

3. No triage criteria, so everything becomes an “incident”
   Fix: define severity and validation rules. Most “hits” are noise; document why.

4. No evidence of “no findings” runs
   Fix: retain a lightweight attestation and run log even when nothing is found.

5. Findings don’t feed prevention
   Fix: require a post-closure root cause mapping (secrets scanning gap, misconfig baseline, access control weakness, third-party contract gap).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-13, so you should treat this as a customer diligence and auditability control rather than an enforcement-driven one for this page. The practical risk remains high: undetected public disclosures can force incident response, breach notifications, contract impacts, and loss of government/customer trust.

A practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign AU-13 owner(s) and publish the control card. ¹
• Define “organizational information” categories and top keywords.
• Build the monitoring source register with an initial small set.
• Decide evidence bundle contents and storage location.
• Run the first monitoring cycle end-to-end and retain evidence.

Days 31–60 (make it repeatable and auditable)

• Automate where feasible (alerts, scheduled queries, ticket templates).
• Add validation playbooks (how to confirm leaked credentials, code, documents).
• Integrate with incident response intake and severity matrix.
• Start monthly rollups to GRC with completion checks. ¹

Days 61–90 (mature coverage and close gaps)

• Expand keyword library and sources based on early false positives and misses.
• Add third-party path: standardized outreach, required artifacts, and corrective action tracking.
• Run a control health check and document remediation items to closure. ¹

Where Daydream fits: Daydream can store the AU-13 control card, schedule control runs, enforce a consistent evidence bundle per cycle, and track remediation to validated closure so your audit response is a click-through package, not a scramble. ¹

Frequently Asked Questions

What counts as “open-source information and/or information sites” for AU-13?

Any publicly accessible site where your information could appear qualifies, including public repositories, paste sites, indexed cloud storage links, forums, and social platforms. Document your chosen set in a source register and explain why it is risk-based. ¹

How do we choose the monitoring frequency?

Pick a cadence that matches your exposure and the sensitivity of the information you handle, then document it. Also define trigger events (confirmed credential theft, third-party breach notice) that require out-of-cycle monitoring. ¹

Does AU-13 require a specific tool?

No. AU-13 requires monitoring and evidence of operation, not a particular product. Tools help with scale and retention, but a documented manual process can meet the requirement if it is repeatable and auditable. ¹

What evidence should we keep if there were no findings?

Keep the run log, sources checked, query set reference, and a brief “no findings” result summary. Auditors often fail controls where only “bad news” is documented and routine operation is invisible. ¹

How do we handle suspected disclosures at a third party?

Treat it as a finding that triggers your third-party issue process: notify the third party, request investigation artifacts, track corrective actions, and document closure. Preserve the same AU-13 evidence bundle plus third-party communications. ¹

Can we scope AU-13 to only “sensitive” information?

You can scope by risk, but document the scoping decision and keep it consistent with your data classification scheme. If you exclude categories, define an exception process and revisit scope during control health checks. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5