RA-10: Threat Hunting

Quick-reference card

What This Control Requires

RA-10 requires your organization to build and maintain a dedicated cyber threat hunting capability that actively searches for indicators of compromise and disrupts threats before they cause damage. This goes beyond passive defenses like firewalls or intrusion detection systems. You need a proactive function that hunts through your systems, networks, and infrastructure for signs of adversary activity that your automated controls have missed.

In practice, this means standing up a team or process that regularly searches for anomalous network traffic, unexpected file changes, and the presence of malicious code across your environment. The threat hunting capability must operate at a defined frequency, and findings should feed back into your broader risk assessment and continuous monitoring programs.

Where most organizations fall short is treating threat hunting as an ad hoc exercise rather than a sustained, documented program. RA-10 demands a repeatable capability with clear objectives, not a one-time sweep after a security incident. Your threat hunting function should also produce and consume threat intelligence, sharing findings with peer organizations, information sharing and analysis organizations (ISAOs), and relevant government agencies.

Why It Matters

Organizations that rely solely on automated detection tools are structurally blind to advanced adversaries who design their techniques to evade those exact controls. RA-10 exists because the gap between what your perimeter defenses catch and what actually moves through your environment is where the most damaging compromises take root.

Without a formal threat hunting program, your compliance posture under NIST SP 800-53 carries a documented gap that auditors will flag. Because RA-10 isn’t assigned to any baseline, its absence won’t automatically fail a minimum-security review, but assessors evaluating your risk assessment family will note that you lack a proactive mechanism for detecting threats that bypass your existing stack.

The operational cost of not hunting is measured in dwell time. Adversaries who evade initial detection can persist in your environment for months, escalating privileges, exfiltrating data, and establishing redundant access paths. A sustained hunting program compresses that window by searching for the indicators of compromise that automated tools weren’t configured to catch.

What attackers exploit

• Gaps between detection signatures and real adversary behavior, where threat actors use living-off-the-land techniques that blend with legitimate system activity
• Environments without centralized log correlation, where unusual network traffic patterns go unnoticed across segmented systems
• Organizations that lack a defined hunting cadence, giving adversaries uninterrupted dwell time to move laterally
• Stale threat intelligence that doesn’t reflect current tactics, techniques, and procedures (TTPs), leaving TTP-based hunting blind to emerging campaigns
• Insufficient integration between threat hunting findings and incident response workflows, allowing discovered threats to persist without remediation

How to Implement

Most organizations struggle with RA-10 because threat hunting requires skills, tooling, and processes that sit outside traditional security operations. The most common failure mode is standing up a hunting program on paper without investing in the analyst expertise or data infrastructure to execute it.

For your organization

1. Define your threat hunting charter. Document the program’s scope, objectives, and authority. Specify which systems, networks, and data repositories fall within the hunting mandate, and establish the cadence at which hunts will occur. This charter becomes a core artifact in your system security plan.

2. Build or acquire the capability. You need analysts with experience in hypothesis-driven hunting, behavioral analysis, and network forensics. If you can’t staff this internally, consider a managed threat hunting service, but retain ownership of the program’s direction and findings. Common tooling categories include endpoint detection and response (EDR) platforms, security information and event management (SIEM) systems, and threat detection tools that support custom query languages.

3. Establish hypothesis-driven hunt cycles. Each hunt should start with a specific hypothesis grounded in current threat intelligence, such as searching for evidence of credential dumping techniques documented in the MITRE ATT&CK framework. Document the hypothesis, the data sources queried, the analytical techniques used, and the findings.

4. Integrate with your broader risk program. Threat hunting findings should feed directly into your risk assessment process (RA-03) and continuous monitoring program (CA-07). When a hunt identifies a gap in your detection coverage, that gap becomes a finding in your next control assessment.

5. Produce and share threat intelligence. RA-10 explicitly expects your hunting capability to generate intelligence that you share with ISAOs, information sharing and analysis centers (ISACs), and government agencies. Build a workflow for sanitizing and disseminating hunt findings.

6. Maintain audit records. Every hunt should generate documentation that includes the trigger, methodology, data sources, findings, and remediation actions. These audit records and event logs are primary evidence artifacts for assessors.

Common mistakes: treating threat hunting as identical to incident response, failing to document negative findings (hunts that find nothing are still evidence of capability), and running hunts without a defined hypothesis.

For your vendors

Questionnaire questions to ask:

• Do you maintain a dedicated threat hunting program, and at what frequency do hunts occur?
• How do you develop hunt hypotheses, and what threat intelligence sources inform them?
• Can you provide documentation of recent threat hunting activities, including scope, methodology, and findings?
• How are threat hunting results integrated into your risk assessment and continuous monitoring programs?
• Do you share threat intelligence derived from hunting activities with ISAOs, ISACs, or peer organizations?

Evidence to request:

• Threat hunting program charter or policy documentation
• Sample hunt reports showing hypothesis, methodology, data sources, and outcomes
• Risk assessment policy sections that reference threat hunting inputs
• Audit records demonstrating the defined hunting cadence is maintained
• Threat intelligence sharing agreements or participation records

Red flags to watch for:

• Vendors who conflate threat hunting with standard SIEM alerting or automated scanning. These are fundamentally different activities, and substituting one for the other indicates the vendor doesn’t have a genuine hunting capability.
• Hunt documentation that lacks specificity, showing no defined hypothesis, no named data sources, and no findings beyond “no threats detected.”
• No evidence of a defined hunting frequency. An ad hoc approach suggests the program exists on paper only.

Verification approach: Request a sample threat hunt report and evaluate whether it demonstrates hypothesis-driven analysis rather than reactive alert triage. Confirm that the vendor’s system security plan references the hunting program and that assessment reports reflect its outputs.

Evidence Examples

Cross-Framework Mapping

Related Controls

• CA-02 — Control Assessments: threat hunting findings feed into control assessment processes, identifying gaps in detection coverage that assessors evaluate
• CA-07 — Continuous Monitoring: the hunting program complements continuous monitoring by catching threats that automated monitoring tools miss
• CA-08 — Penetration Testing: penetration testing validates whether the threat hunting capability can detect simulated adversary techniques
• RA-03 — Risk Assessment: threat hunting outputs directly inform risk assessments by identifying previously unknown threat vectors and vulnerabilities
• RA-05 — Vulnerability Monitoring and Scanning: scanning identifies known vulnerabilities, while threat hunting searches for active exploitation that scanning alone won’t reveal
• RA-06 — Technical Surveillance Countermeasures Survey: both controls address the detection of unauthorized activities, with RA-06 focused on physical surveillance and RA-10 on cyber threats
• SI-04 — System Monitoring: system monitoring provides the data infrastructure and event logs that threat hunters query during hunt operations

Frequently Asked Questions

What is NIST SP 800-53 RA-10

RA-10 is the NIST SP 800-53 control that requires organizations to establish and maintain a proactive threat hunting capability. This capability must search for indicators of compromise in organizational systems, detect and track threats that evade existing controls, and operate at a defined frequency. Unlike passive detection controls, RA-10 specifically mandates an active hunt function staffed by analysts who pursue hypothesis-driven investigations across your environment.

What happens if RA-10 is not implemented

Without a threat hunting capability, adversaries who bypass your automated defenses can persist undetected in your environment, extending dwell time and increasing the scope of potential damage. Auditors assessing your risk assessment family will document the absence as a gap, weakening your overall compliance posture. Your organization also loses the ability to generate and share threat intelligence with ISAOs and ISACs, reducing your visibility into emerging threat campaigns that peer organizations may already be tracking.

How do you audit RA-10

Auditors verify RA-10 by reviewing the threat hunting program charter, completed hunt reports, and audit records that demonstrate hunts occur at the defined frequency. They evaluate whether hunt reports show hypothesis-driven methodology rather than reactive alert triage, and whether findings are integrated into risk assessment reports and the system security plan. Assessors also confirm that the capability produces threat intelligence and that event logs from hunting activities are retained as evidence.

How often should threat hunting be performed

The frequency depends on your organization’s risk profile, threat landscape, and the cadence defined in your system security plan. RA-10 requires you to establish a specific frequency and maintain it consistently. Many mature programs operate on weekly or biweekly hunt cycles, with additional ad hoc hunts triggered by new threat intelligence or indicators of compromise identified through continuous monitoring.