AU-13(2): Review of Monitored Sites

AU-13(2) requires you to periodically review the list of open-source information sites your organization monitors and confirm the list is still appropriate, authorized, and operationally useful. To operationalize it, set an owner and review cadence, maintain an approved “monitored sites register,” document each review decision (add/keep/remove), and retain evidence that changes were implemented. ¹

Key takeaways:

• Treat this as a governed inventory control: a reviewed, approved list with change history, not an informal bookmark list.
• Define “what counts” as an open-source site and set clear criteria for adding/removing sites to reduce scope drift.
• Auditors look for proof of recurring execution: dated reviews, approvals, and implemented updates tied to monitoring tooling.

AU-13(2) (“Review of Monitored Sites”) sits inside NIST’s Auditing and Accountability (AU) family and is usually implemented by threat intelligence, SOC, and security operations teams with compliance oversight. The control enhancement is narrow but easy to fail in practice because many teams monitor open-source sites organically: analysts add sources over time, tooling subscriptions change, and no one can later explain why a given site is in scope, whether it is still relevant, or whether monitoring it introduces legal, security, or data-quality issues.

For a CCO or GRC lead, the fastest path to “audit-ready” is to turn monitored open-source sites into a controlled register with explicit ownership, review cadence, and documented decisions. You are not being asked to prove your entire threat intel program is effective. You are being asked to prove you periodically reassess the inputs to that program: which sites you monitor, and whether that list remains complete, appropriate, and governed.

This page gives requirement-level implementation guidance: who owns it, how to run the review, what evidence to retain, and where exams and customer due diligence teams get stuck.

Regulatory text

Requirement (excerpt): “Review the list of open-source information sites being monitored [frequency].” ¹

Operator interpretation: You must define a review frequency, then repeatedly execute a documented review of the open-source sites you monitor. The review must result in an updated list (even if unchanged) and a record of decisions. “Frequency” is intentionally variable; you set it based on risk, operational change rate, and how monitoring is implemented.

Plain-English interpretation (what this really means)

• Maintain a current, authoritative list of OSINT/open-source sites you monitor for security-relevant information (breach mentions, phishing kits, paste sites, forums, code repositories, status pages, etc.).
• On a recurring cadence, reassess the list for: relevance, coverage gaps, duplication, access/collection method changes, legal/terms constraints, and operational value.
• Document outcomes: what was added, removed, or reclassified; who approved; and when monitoring configurations were updated to match.

Who it applies to

Entity scope

This requirement commonly applies to:

• Federal information systems and
• Contractor systems handling federal data (for example, environments aligned to NIST SP 800-53 through FedRAMP, agency ATOs, or contractual security requirements). ¹

Operational scope (where it shows up)

AU-13(2) is relevant when you monitor open-source sites for:

• Threat intelligence and brand protection
• Vulnerability exploitation chatter tied to your tech stack
• Leaked credentials or sensitive data exposure
• Security event enrichment and investigations

If your monitoring is performed by a third party (managed detection provider, threat intel subscription, brand monitoring service), AU-13(2) still applies. You must be able to show governance over what sources are monitored, even if a third party operates the tools.

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

Step 1: Assign ownership and set the review frequency

1. Name a control owner (often Threat Intel Lead or SOC Manager) and a GRC reviewer/approver for governance.
2. Define review frequency in a control card/runbook. Pick a cadence you can sustain and defend. The control fails most often because the cadence is implied, not stated.

Practical tip: Add trigger-based reviews in addition to cadence-based reviews (for example, tool changes, new business lines, new regions, major incident, or new legal constraints). Keep triggers in the runbook so audits don’t rely on “tribal knowledge.”

Step 2: Define what counts as a “monitored open-source information site”

Write a one-paragraph scoping statement:

• “Open-source information sites” include public websites, repositories, forums, paste sites, and other publicly accessible sources you monitor for security-relevant signals.
• Clarify exclusions (for example: internal systems, paid data feeds that are not “sites,” or social media platforms if you treat them separately).

This reduces arguments later about whether a source “should have” been on the list.

Step 3: Build the Monitored Sites Register (the core artifact)

Create a register (spreadsheet, GRC record, or system-of-record) with, at minimum:

Field	Why auditors care
Site name + URL	Proves the list is explicit and testable
Source type (forum, paste, repo, news)	Shows you understand coverage categories
Monitoring method (manual review, alerting tool, scraper, third party feed)	Connects list to actual monitoring controls
Purpose / use case	Shows relevance to risk and operations
Data handling notes	Flags collection constraints and sensitive handling
Terms/permission notes (if applicable)	Shows governance and reduces legal/ethical risk
Owner	Establishes accountability
Status (active/paused/retired) + rationale	Captures decisions
Last reviewed date + reviewer	Demonstrates recurring execution
Change log reference	Preserves history

Step 4: Run the recurring review (a repeatable checklist)

Use a consistent checklist each cycle:

1. Confirm completeness: Are there new OSINT site categories you should monitor given changes in your stack, threat profile, customer base, or geography?
2. Confirm relevance: For each site, does it still produce actionable signal for your defined use cases?
3. Confirm access/collection method: Did the site change format, access restrictions, or content patterns that break monitoring?
4. Confirm duplication/noise: Are multiple sources producing the same content with low value?
5. Confirm governance constraints: Are there updated terms, collection restrictions, or internal policies that should change how you monitor?
6. Confirm operational ownership: Is there still a team accountable for reviewing alerts, triaging hits, and escalating?

Capture outcomes explicitly: Add / Keep / Remove / Pause, with a short rationale.

Step 5: Approve changes and implement them in tooling

1. Route proposed changes for approval (SOC leadership and/or GRC, depending on your governance model).
2. Update configurations in monitoring tools or third-party subscriptions to match the register.
3. Validate implementation (for example, screenshots, export of config, or third-party confirmation).

Step 6: Perform control health checks (lightweight, but real)

Between formal reviews, perform periodic spot checks:

• Does the tool configuration match the register?
• Are “retired” sites still being monitored?
• Are there sites being monitored that are not in the register?

Daydream (or any GRC workflow system) becomes useful here because you can track the review as a recurring task, attach evidence, route approvals, and maintain an auditable change history without building a custom process.

Required evidence and artifacts to retain

Auditors typically want to see both design evidence (how the control is supposed to work) and operating evidence (proof it ran).

Design artifacts (baseline)

• Control card/runbook for AU-13(2): objective, scope, owner, review frequency, triggers, steps, approval rules, and exceptions.
• Monitored Sites Register template and field definitions.
• Procedure for updating monitoring tools and validating changes.

Operating evidence (each review cycle)

• Dated export or snapshot of the Monitored Sites Register (before/after if changes occurred).
• Completed review checklist with reviewer name/title and date.
• Approval record (ticket, GRC workflow approval, or signed meeting notes).
• Evidence of implementation in tools (config export, screenshots, or change ticket closure notes).
• Exception records (if you temporarily keep a site that fails criteria, document why and for how long).

Retention guidance (practical)

Retain evidence in a single, known location (GRC repository, evidence vault, or ticketing system) with consistent naming. The fastest way to fail is evidence scattered across chat logs and personal folders.

Common exam/audit questions and hangups

Expect questions like:

• “Show me the current list of monitored open-source sites and the last time it was reviewed.”
• “Who approves additions/removals, and how do you prevent ad hoc additions?”
• “How do you know the monitoring configuration matches the approved list?”
• “What triggers an out-of-cycle review?”
• “If a third party monitors OSINT for you, how do you govern their sources?”

Hangups that slow audits:

• You can produce a list, but you can’t show it was reviewed.
• You reviewed it, but you can’t show changes were implemented.
• The list exists, but there is no definition of “open-source information site,” so scope arguments drag on.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating this as a one-time inventory.
   Fix: Put the review on a recurring calendar with assigned owner, and require an artifact per cycle.

2. Mistake: No change control for monitored sources.
   Fix: Require a ticket/workflow for additions/removals with approval and a post-change validation step.

3. Mistake: Confusing “sites we sometimes read” with “sites we monitor.”
   Fix: Define “monitored” as sources with an explicit collection method (alerts, queries, scraper, or named manual review responsibility).

4. Mistake: Tool configuration becomes the system of record.
   Fix: Make the register authoritative, then reconcile tools to the register during each review and spot check.

5. Mistake: Ignoring third-party-provided monitoring sources.
   Fix: Contractually or operationally require the third party to provide their monitored source list (or categories) and map it to your register.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-13(2), so you should treat this primarily as an assurance and auditability requirement rather than one with a known, specific enforcement pattern in this dataset.

Risk implications are still concrete:

• Detection gaps: If your monitored sources drift away from your threat profile, you miss early warning signals.
• Uncontrolled collection: Monitoring methods can violate internal rules or create data handling issues if sources change their access model.
• Audit failure mode: Teams can’t show who owns the requirement, how often it runs, or what evidence proves operation. This is a common control design/operation gap in practice. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign owner and approver; write the AU-13(2) control card with frequency and triggers.
• Define “open-source information sites” scope statement.
• Create the Monitored Sites Register and populate it from current tools, bookmarks, and third-party reports.
• Run the first formal review and document decisions; open tickets for required changes.

Days 31–60 (make it repeatable and auditable)

• Implement approved changes in monitoring configurations and capture validation evidence.
• Add change control: require approvals for any new monitored site and document emergency additions.
• Build a simple reconciliation check: register vs. tool config vs. third-party source list.
• Store evidence in a consistent location and test retrieval as if you were responding to an auditor.

Days 61–90 (prove sustained operation)

• Perform the next scheduled review cycle (or an out-of-cycle review if triggers occur).
• Run a control health check and close remediation items with dated proof.
• Create a short metrics-less management report: what changed, why, and any open risks. Avoid invented numbers; focus on traceable outcomes.
• If you use Daydream, automate task scheduling, approvals, and evidence bundling so the control doesn’t depend on individual analysts.

Frequently Asked Questions

What counts as an “open-source information site” for AU-13(2)?

Treat it as any publicly accessible site you actively monitor for security-relevant signals, with an explicit collection method and owner. Document your definition once and use it consistently to avoid scope disputes. ¹

How often should we review the monitored sites list?

AU-13(2) leaves frequency to you, so pick a cadence you can execute consistently and add trigger-based reviews for major changes. Auditors care more about repeatability and evidence than the exact interval. ¹

If a third party provides threat intel monitoring, do we still need a register?

Yes. You still need governance evidence showing what sources are monitored on your behalf and that you review that scope on a defined cadence. Capture the third party’s source list or categories and document your review decisions.

What is the minimum evidence an auditor will accept for each review cycle?

Keep a dated monitored-sites register snapshot, proof of review (checklist or meeting minutes), approval record, and evidence that changes were implemented in tooling or third-party configurations. If nothing changed, retain the “no changes” decision with reviewer and date.

Our SOC adds sources ad hoc during incidents. How do we stay compliant?

Allow emergency additions, but require a ticket that records the source, rationale, and an after-action review to either formalize it in the register or remove it. Make this rule explicit in the runbook so incident response stays fast without breaking governance.

Do we need to store the content collected from open-source sites as evidence?

AU-13(2) is about reviewing the list of sites being monitored, not retaining all collected content. Keep evidence of the review and of configuration changes; retain collected content only if your internal procedures or other controls require it.

Footnotes

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