AU-13(1): Use of Automated Tools

AU-13(1) sits in the NIST SP 800-53 Audit and Accountability (AU) family, but in practice it is an external threat visibility requirement: you are expected to watch what the public internet reveals about your organization and your systems, and to do it with automation rather than ad hoc manual searching. The control text is short, which is why teams often under-implement it or treat it as “nice to have.”

For a Compliance Officer, CCO, or GRC lead, the fastest path to a defensible AU-13(1) implementation is to turn it into an operating control with (1) a written scope, (2) an automated monitoring workflow that generates audit-ready records, and (3) a triage and escalation process that results in measurable actions (tickets, blocks, takedown requests, credential resets, exposure remediation).

This page translates the requirement into a practical runbook: what to monitor, how to select and configure automated mechanisms, how to integrate results into incident handling and vulnerability management, and what evidence auditors typically request. It also highlights the most common failure mode: having tools in place, but no clear ownership, cadence, or retained evidence that proves the control operated.

Regulatory text

Requirement (AU-13(1)): “Monitor open-source information and information sites using [automated mechanisms].” ¹

Operator interpretation: you must implement automated monitoring of publicly available sources (“open-source information and information sites”) for information relevant to the security of your organization and the system(s) in scope, and you must be able to prove the monitoring occurred and was acted on. Automation is the point: a manual Google search during an incident does not satisfy “use automated mechanisms” as an operating control. ²

Plain-English interpretation (what the control really demands)

AU-13(1) expects you to:

• Continuously watch public sources for indicators that your environment is exposed or being targeted (e.g., leaked credentials, mentions of system names, exposed IPs/domains, brand impersonation, public paste sites).
• Use tooling that runs without human initiation and produces repeatable output (alerts, logs, reports).
• Route findings into action through triage, escalation, and remediation paths (security operations, IAM, vulnerability management, legal/brand protection as applicable).

If you cannot show (a) what sources you monitor, (b) how automation runs, (c) what it found, and (d) what you did about it, the control will read as “policy-only.” ³

Who it applies to (entity + operational context)

AU-13(1) is most directly applicable when you operate:

• Federal information systems or systems assessed against NIST SP 800-53 controls ²
• Contractor systems handling federal data, including environments supporting federal contracts where NIST 800-53 is contractual, flowed down, or used for ATO packages ²

Operationally, it applies to:

• Your internet-facing footprint (domains, subdomains, public IPs, externally accessible apps, code repos, SaaS tenant configurations)
• Your identity surface area (credential dumps, MFA fatigue campaigns, password reuse, exposed API keys)
• Your brand and communications channels (impersonation, fraudulent domains, social profiles) when security impact is plausible

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

1) Build a requirement “control card” (make it operable)

Document AU-13(1) as an operating control with:

• Objective: detect externally observable security exposures and compromise indicators through automated OSINT monitoring.
• In-scope systems/assets: domains, IP ranges, critical brands, key executives (if appropriate), cloud tenant names, product names, and other identifiers tied to your system boundary.
• Owner: name a primary owner (often SecOps, Threat Intel, or GRC with SecOps execution).
• Execution cadence: define how often monitoring runs (tool-driven continuous monitoring is acceptable; define the review/triage cadence).
• Trigger events: new domain acquisition, new product launch, new third party integration, major incident, M&A, rebrand.
• Exceptions: what you intentionally exclude (e.g., certain brand monitoring handled by marketing) and how you still capture security-relevant outputs.

This aligns to the operational risk factor: teams fail audits when they cannot show ownership, frequency, and evidence. ¹

2) Define monitoring scope as a “watchlist”

Create a controlled list of monitored terms and assets, such as:

• Primary domains and common typosquats
• Public IPs and ASN (if you track it)
• Application names, login portals, tenant identifiers
• Email domains and key formats (for credential leak matching)
• High-risk keywords (e.g., “vpn,” “admin,” “prod,” “backup,” “customer data”) paired with your org name

Keep it version-controlled. Treat updates like configuration changes.

3) Select automated mechanisms and integrate with your security workflow

Your “automated mechanisms” can include:

• OSINT monitoring platforms (threat intel feeds, dark web monitoring, brand/domain monitoring)
• Custom scripts that query defined sources on a schedule
• SIEM ingestion of external intel feeds
• SOAR playbooks that enrich and route alerts

Minimum implementation characteristics auditors look for:

• Automated execution (scheduled jobs, continuous feed ingestion)
• Alerting (tickets, pager, Slack/email notifications)
• Logging (time-stamped outputs proving monitoring ran)
• Access control over tool configuration and results

Where Daydream fits naturally: if you struggle to keep the “control card,” evidence bundle, and recurring control health checks consistent across teams, Daydream can standardize AU-13(1) as a requirement-level control with owners, runbooks, and evidence checklists so audits don’t become archaeology.

4) Create triage criteria and escalation paths

Write a short decision table so analysts make consistent calls:

Finding type	Example	Severity factors	Required action
Credential exposure	leaked corporate emails + passwords	privileged accounts, recent activity, MFA status	open incident/ticket, force reset, investigate login activity
Exposed system details	public repo leaks config, keys	key validity, system criticality	revoke/rotate secrets, remove exposure, scan for misuse
External attack chatter	mentions of your domains/IPs	credibility, specificity	enrich, monitor, consider threat hunt
Typosquat/impersonation	lookalike login domain	brand similarity, active phishing	takedown process, blocklists, user comms

Tie escalations to your incident response and vulnerability management processes so remediation has a home.

5) Operationalize cadence: “monitor continuously, review predictably”

Even if tooling runs continuously, you still need a defined operational rhythm:

• A review queue (daily/weekly) with assigned analyst
• A backlog SLA for non-critical findings
• A standing meeting or async review for trends (e.g., spikes in credential exposures)

6) Retain a minimum evidence bundle (audit-ready)

Define what evidence you retain each cycle so you can prove operation without over-collecting.

Required evidence and artifacts to retain

• Control card / runbook for AU-13(1) (scope, owner, cadence, exceptions)
• Tool configuration evidence: watchlists/keywords, monitored domains/IPs, feed subscriptions, alert rules
• Execution proof: system logs, scheduled job history, SIEM ingestion logs, or platform “activity” reports showing monitoring ran
• Alert/ticket samples: a selection of findings showing intake, triage decision, and closure notes
• Remediation evidence (as applicable): password reset records, key rotation tickets, repo takedown/secret removal PRs, domain takedown requests
• Control health checks: periodic validation that monitoring is still running, sources are reachable, alerts route correctly, and ownership is current ¹

Retention period is typically dictated by your broader audit logging, incident response, or contractual requirements; AU-13(1) itself does not prescribe a fixed retention duration in the provided text. ²

Common exam/audit questions and hangups

Expect auditors to probe four areas:

1. “What open-source sources are you monitoring?”
   Have a list of categories and example sources (without oversharing sensitive intel methods), plus your watchlist.

2. “Where is the automation?”
   Show scheduled jobs, feed ingestion, alert rules, and timestamped run history. A screenshot alone is weak; pair it with exportable logs or reports.

3. “Show me outcomes.”
   Provide a small set of closed tickets with consistent dispositions: false positive, informational, remediated, accepted risk.

4. “Who owns this and how do you know it keeps working?”
   Point to your named owner, coverage review cadence, and health checks. This is a frequent failure point. ¹

Frequent implementation mistakes (and how to avoid them)

• Mistake: buying a tool and stopping there.
  Fix: write triage criteria, integrate to ticketing, and require closure notes.

• Mistake: no documented scope.
  Fix: maintain a watchlist tied to your system boundary and update it on trigger events.

• Mistake: “automation” that still depends on a person clicking run.
  Fix: require scheduled execution or continuous feed ingestion with logs.

• Mistake: evidence gaps.
  Fix: define an evidence bundle per cycle and store it in a known repository with consistent naming.

• Mistake: treating OSINT findings as “FYI.”
  Fix: route actionable findings into IR, IAM, vuln management, or brand protection workflows with owners and due dates.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-13(1), so you should treat this as a control effectiveness and auditability requirement rather than a “case law” driven one.

Risk-wise, weak AU-13(1) implementation increases the chance you learn about credential leaks, exposed secrets, or active impersonation late, after accounts are compromised or customers are phished. The compliance risk shows up during ATOs, customer diligence, and third-party assessments when you cannot demonstrate repeatable monitoring and response tied to open-source exposure signals. ²

Practical execution plan (30/60/90)

Because fixed day-count timelines are not source-backed here, treat these as phases you can map to your delivery cadence.

First 30 days (Immediate)

• Assign control owner and backups; publish the AU-13(1) control card.
• Create the initial watchlist (domains, brands, key systems, identity patterns).
• Pick the automated mechanism(s) you will standardize on; define alert routing to ticketing.
• Define triage dispositions and escalation paths; train the on-call/triage team.
• Start capturing the evidence bundle from day one (config export + run logs + sample alerts).

60 days (Near-term)

• Tune alert rules to reduce noise and document tuning decisions.
• Add health checks: verify jobs run, feeds ingest, and alerts route.
• Run a tabletop: simulate a leaked credential set and prove your workflow produces tickets, resets, and investigation steps.
• Implement governance for watchlist updates (change control, approvals if needed).

90 days (Operationalize)

• Produce a quarterly (or similar) trend report: top finding types, time-to-triage, recurring exposures.
• Validate coverage against your evolving asset inventory and third-party changes.
• Demonstrate sustained operation with multiple evidence cycles and closed remediation items.
• Formalize exception handling and risk acceptance for findings that are informational but persistent.

Frequently Asked Questions

Does AU-13(1) require dark web monitoring specifically?

The text requires monitoring “open-source information and information sites” with automated mechanisms, but it does not prescribe specific sources. Define the sources you monitor and justify them based on your threat model and system exposure. ¹

What counts as an “automated mechanism”?

A mechanism is automated if it runs without a person initiating it each time and it produces repeatable outputs (alerts/logs/reports). Scheduled scripts, feed ingestion to a SIEM, or an OSINT monitoring platform can qualify if you retain execution evidence. ²

We already have a threat intel vendor. Is that enough?

Only if you can show how the service monitors for your specific identifiers, how you receive findings, and how you triage and remediate them. Auditors will still want proof of operation and outcomes, not just an invoice. ²

How do we scope AU-13(1) to a specific system boundary for an ATO?

Start from the system’s internet-facing assets, identities, and public references, then build the watchlist around those identifiers. Document exclusions and show that results route to the system’s incident and vulnerability processes. ³

What evidence is most persuasive in an audit?

Time-stamped run history plus a small set of tickets that show triage decisions and remediation closure is usually stronger than screenshots alone. Pair that with the control card and tool configuration export. ¹

How do we handle false positives without failing the control?

False positives are expected; what matters is consistent triage and documented disposition. Track tuning changes and show your process reduces repeat noise while keeping coverage for high-risk identifiers. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5 DOI