RA-10 Threat hunting: requirements and evidence

What RA-10 threat hunting requires and why it is not in any baseline

If your organization selected RA-10 through tailoring or an overlay, you must be able to show that a threat hunting capability exists and runs at a defined frequency. RA-10 asks for an ongoing capability that searches organizational systems for indicators of compromise and for threats that have slipped past existing controls, then detects, tracks and disrupts them. The control is organization-defined, so the frequency and the scope of the hunts are decisions you make and document, not values the standard supplies. SP 800-53B does not assign RA-10 to the low, moderate, high or privacy baseline, and FedRAMP's Rev5 baselines do not require it at Class B, C or D. Its absence from those baselines is why it is easy to overlook, and why an assessor who finds it in your control selection will ask pointed questions about it. Appendix C of SP 800-53 marks it as an assurance-related control, which signals that the assessor will look for proof that the capability works, not only that a policy describes it.

The risk RA-10 addresses is the adversary who gets past preventive and detective controls and stays. Vulnerability scans, alerts and log rules only catch what someone has already written a signature or rule for, so a hunt starts from a hypothesis, such as an unusual administrative login pattern or a process running from an unexpected directory, and tests it against collected data. This is why the capability is hard to deliver. It needs analysts who understand the environment and attacker behavior, a data set with enough history to search, and a cadence the organization can actually sustain. Confirm with your team who owns hunts, what data sources they can query, how long those sources retain events, and how each hunt's findings feed incident response and the plan of action and milestones. A tool without those people and decisions will produce searches, not a capability.

Deciding whether RA-10 applies to your systems

RA-10 is not assigned in any SP 800-53B baseline, so its scope starts with a selection decision, not a baseline lookup. The cards below set out the choices that determine which systems, telemetry and providers the hunts must cover, and the work each choice adds or removes.

Selected by tailoring or overlay

Confirm first whether RA-10 was chosen through tailoring of a baseline or through an overlay that your authorizing official approved. If it was never selected, the hunting capability is not a required control for that system, and the work below does not apply. If it was selected, record the selection rationale and the defined frequency for hunts in the system security and privacy plan, because the assessor will test against both. Ask the authorizing official whether the selection covers the whole boundary or only specific components.

Systems inside the hunt boundary

Map every system the hunts must search, including production workloads, build infrastructure, identity systems and management planes. Each system you exclude needs a documented reason, since an assessor may ask why a path an adversary could use was left out. Expect the boundary to grow when a new system joins the authorization boundary, so the hunt scope should be reviewed at the same trigger points as the system security plan.

Log sources the hunts can read

Hunts depend on logs that exist and are retained. Inventory the sources for each in-scope system, such as authentication events, process execution, DNS queries and administrative changes, and confirm that each one is forwarded to a store the hunting team can query. A source that is logged locally but never reaches the hunting platform adds no coverage, and the gap should appear in your hunt documentation rather than surprise the assessor.

Cloud control plane telemetry

Decide whether cloud audit logs for accounts, subscriptions and projects are in scope, including control plane activity such as role changes, new access keys and disabled logging. Adding this telemetry raises the volume and parsing work for the hunting platform and usually requires cross-account collection. Removing it narrows the hunts to workloads, which leaves credential misuse in the control plane outside the search.

Endpoint and network telemetry

Choose whether hunts cover endpoint process and file activity, and whether network flow or DNS data is included. Endpoint agents such as osquery or Velociraptor support hunts across hosts, but they add deployment, certificate and update work on every machine. Network telemetry adds sensor placement and storage cost. Document which telemetry types are excluded and what detection gap that creates.

Third-party managed services

Identify managed services that hold data your hunts depend on, such as hosted email, SaaS identity providers, managed detection providers or outsourced SOC platforms. Confirm in writing whether you can export logs or query them yourself, how long the provider retains them, and whether the provider runs hunts on your behalf. Where a provider holds the evidence, the hunt records and outputs may sit outside your boundary, which changes both the evidence you can show and the contract terms you need.

How an assessor tests threat hunting against RA-10

This table maps each RA-10 assessment element to the methods an assessor uses, the evidence to prepare, and the gaps that commonly cause findings. Read the frequency rows together, because the organization-defined frequency is only meaningful when it is checked against dated hunt records. Confirm the exact determination statement wording in the SP 800-53A Release 5.2.0 OSCAL content before you build your evidence list.

Assessment element	Methods and objects	Evidence an assessor asks for	Common findings
Defined hunt frequency	Examine policy, procedures and hunt plan for the organization-defined frequency value	Approved hunt plan stating the frequency, scope of systems covered and the approving owner	Frequency left as 'as needed' or missing from the plan
Hunting capability exists	Examine the threat hunting capability, audit records and event logs; test a sample hunt	Tool configuration, log sources feeding the hunt, saved hunt queries and a demonstrated hunt run	Hunting tooling deployed but missing the log sources it needs
Searches for indicators and evasive threats	Examine hunt definitions and indicator sources; test that a hunt returns results from ingested data	Hunt hypotheses, indicator lists, query definitions and sample output tied to real telemetry	Hunts run only on known signatures with no hypothesis for evasive activity
Hunts run at the defined frequency	Examine assessment reports and hunt records; compare dated runs with the defined interval	Run timestamps from the scheduler or hunt log, covering the full assessment period	Hunts performed once, or gaps longer than the defined interval
Checking frequency against hunt records	Set the defined interval beside each dated run and list any missed or late runs	Scheduler export, run history and a written explanation for each missed run	Schedule exists on paper but run history shows gaps with no explanation
Results recorded and acted on	Examine hunt reports, tickets and plan of action entries that trace back to hunt results	Hunt reports, tickets, incident links and plan of action and milestones entries from hunt findings	Hunts that find nothing or find something are never written down
Interview with hunt operators	Interview analysts on hypotheses, escalation paths and how hunts feed related controls	Analyst explanations consistent with hunt records and escalation procedures	Analysts cannot describe the current hunt cycle or who receives results
Links to related controls	Examine how hunt results inform vulnerability scanning, monitoring and risk assessment	Documented handoffs to RA-5, SI-4, CA-7 and RA-3 with dated examples	Hunt results never reach vulnerability, monitoring or risk processes

Setting up a threat hunting capability step by step

This sequence turns the RA-10 requirement into a working hunting program, from the organization-defined frequency and scope through documented hunts, detection updates and periodic review, with an output named at each step so an assessor can trace the capability.

Set the frequency and scope of hunting
RA-10 leaves the hunting frequency as an organization-defined parameter, so the first decision is how often hunts run and which systems fall inside the capability. The control owner, usually the security operations lead with sign-off from the authorizing official or equivalent risk owner, records the frequency, the in-scope systems and the reason for each choice in the system security plan. The step is complete when the parameter value is written down, approved and traceable to the risk assessment under RA-3. Ask whether the parameter value has been approved in writing before the first hunt runs.
Choose data sources and map log coverage
Hunts can only find what the collected data shows, so the team lists the data sources for in-scope hosts, network devices, identity systems and cloud services, then records which of them are actually forwarded, retained and searchable. A coverage map shows each source, its log types, its retention period and known gaps. Gaps found here feed back into the audit logging controls in the AU family and into the monitoring controls in SI-4. The step is done when the coverage map has an owner and each gap has a remediation decision or an accepted-risk entry.
Define hunt hypotheses and rank them
Each hunt starts from a hypothesis about how an adversary could be operating in the environment, such as credential misuse, persistence through scheduled tasks or unusual outbound connections. Hypotheses come from threat intelligence, the current risk assessment, recent incidents and known gaps in the coverage map. The team ranks them by likelihood and impact and keeps a backlog. The output is a prioritized hypothesis list where every entry names the data needed to test it and the expected signal if the hypothesis holds.
Assign hunt roles and protected analyst time
A hunt needs a named lead who owns the hypothesis and the conclusion, analysts who run the queries, and a reviewer who checks the method and findings before they are closed. Analyst time for hunting should be scheduled separately from alert triage, because routine alert queues tend to crowd out proactive work. The output is a roster with roles and a documented schedule that matches the frequency set in step one. Confirm with the organization how many analysts are available, since that figure determines how many hypotheses the program can realistically test in each cycle.
Run hunts and record each one in a hunt log
The hunt lead executes the queries against the data sources, records the time window, query logic, data sources used, results and a conclusion for each hypothesis. Conclusions are recorded whether they find something or not, so negative results count as evidence that the capability ran. The hunt log is the primary artifact an assessor will examine for RA-10. The step closes when every hunt has an entry with a reviewer sign-off and a conclusion of confirmed, refuted or inconclusive.
Route findings into detection and incident response
Hunt results should change what the organization detects and how it responds. A confirmed indicator goes to incident response under the IR family, with the containment and eradication actions recorded there. A pattern that is likely to recur becomes a new or tuned detection rule, which is then tested so it does not flood analysts with false positives. The output is a link between each confirmed or inconclusive hunt and either an incident record, a detection change or a documented decision to take no further action.
Review the program and update the parameters
At a set interval, the program owner reviews the hunt log, the coverage map and the hypothesis backlog to see whether hunts are finding gaps, whether the frequency still matches the threat picture and whether data sources have changed. Findings from the review update the system security plan, the risk assessment and the hypothesis list. The review record, with dated decisions and the people who approved them, is the evidence that the capability is maintained rather than set up once and forgotten.

Open-source tools that produce threat hunting evidence

RA-10 asks for a hunting capability that runs at a defined frequency, so the evidence is a record of repeated searches, their findings and the actions taken. The four tools below cover different parts of that work: detection content, log correlation, fleet-wide queries and collection hunts. Each must be confirmed against the organization's own environment before it is named in a plan.

OpenSearch Security Analytics

Licensed under Apache-2.0. Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and alerts can go to channels such as Slack or email. The correlation engine links findings across log types in a correlation graph, which helps show how a suspected intrusion spans systems. Confirm that the log sources you need are supported and that retained findings can be exported as hunt records.

Wazuh ruleset and alerts

Licensed under GPL-2.0-only. Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK techniques, and forwarded to the Wazuh indexer for review in the dashboard. For RA-10, the alert history and the custom rules written from hunt results are useful evidence. Confirm that the built-in ruleset covers your operating systems and applications and that you have a process for tuning noisy rules.

osquery scheduled fleet queries

Licensed under Apache-2.0 OR GPL-2.0-only. osquery exposes running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables. The osqueryd daemon schedules those queries to run across an entire fleet of hosts, so the same hunting question can be asked repeatedly on a fixed schedule. Saved query definitions and their result logs document the hunt frequency that the control requires. Confirm the platforms you run are supported, and plan how query results will be stored and reviewed given the volume they generate.

Velociraptor collection hunts

Licensed under AGPL-3.0-only. Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that gather one or more artifacts across a group of systems. Machines that are offline when a hunt starts collect when they reconnect, and each hunt gets a notebook for analyzing the combined results. Those hunt definitions, scopes and notebooks give an assessor a traceable record of what was searched and what was found. Confirm that the AGPL-3.0-only license terms fit how you plan to distribute or modify the software, and that your endpoints can reach the Velociraptor server.

Which evidence shows the hunting capability exists

What documented hunting procedure does an assessor expect to see for RA-10?

A written threat hunting procedure that states the hunting frequency, who runs hunts, which data sources they use and how results flow into incident handling and risk decisions. RA-10 requires the capability to run at a defined frequency, so the organization must set that frequency as its own parameter and show that the procedure matches what staff actually do. The procedure should name the systems in scope and the tools used, such as a SIEM, endpoint query tooling or a forensic collection platform. Keep it under version control, record each review with a date and approver, and update it when the hunting toolset or system boundary changes. Confirm the exact wording of the parameter against the current SP 800-53 Rev. 5.2.0 catalog before you finalize the procedure.

How do hunt plans and hypotheses show that hunting is deliberate?

Each hunt should start from a written plan that states a hypothesis, the adversary behavior being tested, the data and systems in scope, and the query or artifact set to be run. An assessor looks for a clear link between the hypothesis and the threat intelligence, prior incidents or risk assessment findings that prompted it. A plan that says only "search for malware" fails because it cannot be tested or closed. Store plans in the same system as other security records so they can be retrieved by date. The effort to write a plan is small compared with the analysis, but skipping it is the most common reason a hunt program looks like ad hoc log review on paper.

What should a hunt log record, and why do dates and analysts matter?

A hunt log should record the hunt identifier, start and end dates, the analyst or team, the systems and time window searched, the queries or artifacts run, the number of hosts or events reviewed and the outcome. Dates and named analysts let an assessor confirm that hunts occurred at the defined frequency and were not back-filled before an audit. Gaps in the log are the most visible failure, so a missed period should be documented with the reason, such as a tooling outage or a reassignment. Tools like osquery and Velociraptor keep execution history for scheduled queries and hunts, which can be exported as supporting records. Confirm the retention period for these records with your assessor.

How should hunt findings and their disposition be recorded?

Every hunt should end with a recorded disposition for each finding: confirmed malicious, benign with explanation, or inconclusive with a follow-up task. A finding that is confirmed should open an incident record or a plan of action item, and the record should link to the containment and remediation evidence. A finding dismissed as benign needs enough detail to show the analyst ruled out the activity, such as the process parent, the user and the business reason. Hunts that produce no findings are still valid evidence when the log shows what was searched and why nothing matched. Assessors often sample a few findings and trace them end to end, so the chain must be complete.

Which detection rules created from hunts should be kept as evidence?

When a hunt reveals a repeatable behavior, the organization should convert it into a detection rule and record the rule, its source hunt and the date it was deployed. Rules can be written in Sigma and run through tools such as OpenSearch Security Analytics or Wazuh, which map alerts to MITRE ATT&CK and keep rule identifiers that can be cited in evidence. An assessor checks that the rule exists in the running system, not only in a document, so export the rule configuration and a sample alert. Rules that are later tuned or retired should keep a change history. This link between hunting and monitoring is one of the clearest signs that RA-10 feeds the rest of the program.

How do hunt records connect to the risk assessment and assessment reports?

Hunt results should be traceable to the risk assessment under RA-3, the vulnerability and monitoring records under RA-5 and the monitoring controls such as SI-4, which RA-10 relates to in the Release 5.2.0 catalog. A traceability matrix or a short cross-reference table in the assessment report can show which hunt informed which risk decision and which control evidence it supports. The independent assessor uses this trail to test whether the capability is integrated rather than isolated. Keep the matrix current by updating it at each hunt cycle, not only before an assessment. Whether your assessor requires a specific format is a question to confirm with them directly.

Can an in-house team produce this evidence, or does an implementation partner help?

An internal team can produce all six evidence types if it owns the procedure, runs hunts on schedule and keeps the records current. An implementation partner such as DeployOpen can plan and deploy the self-hosted tooling that produces hunt records, configure logging and export evidence, and document the procedure and templates. DeployOpen does not run your hunts as a compliance outcome, and it does not issue assessment reports; the independent assessor does that. Cost depends on the number of systems in scope, the existing logging maturity and how much hunting your staff already do. Ask any partner for a written scope that lists each evidence artifact, who produces it and how often it is refreshed.

What meeting RA-10 costs in money and effort

This table compares the main cost components of an RA-10 threat hunting capability, who is paid for each, whether it recurs, and what moves it. Read it as a list of items to price in a written quote, since no dollar figures or durations are supplied for this control. The main takeaway is that telemetry engineering and analyst hunt time, not licenses, usually dominate, and self-hosted open source mainly removes license spend.

Cost component	One-time or recurring, and who is paid	What drives it up or down, and how to keep it down
Tooling or licenses	Recurring if commercial. Self-hosted open-source options such as Wazuh, osquery, Velociraptor and OpenSearch Security Analytics carry no license fee, though their platform licenses differ, so confirm terms with counsel.	Up with commercial endpoint or SIEM licensing tied to data volume or host count. Keep it down by choosing open-source tooling where the license terms fit your use and by limiting ingestion to hunt-relevant sources.
Engineering time to deploy and tune telemetry	One-time to set up, then recurring for tuning. Paid to internal engineers or an implementation partner under a fixed-scope written agreement.	Up with the number of log sources, cloud services and OS types, and with custom Sigma or Wazuh rules needed. Keep it down by starting with a defined set of high-value sources and documenting each one.
Analyst time for hunts	Recurring. Paid as internal staff time or retained analyst hours, at the frequency your RA-10 parameter defines.	Up with hunt frequency, scope across the fleet, and the depth of each investigation. Keep it down by writing repeatable hunt hypotheses and reusing osquery queries and Velociraptor artifacts.
Evidence upkeep	Recurring. Paid as staff time to retain hunt records, findings, queries and assessment reports for the assessor.	Up when hunt results are not stored in a consistent format. Keep it down by using a fixed hunt-record template and automating exports from the tool's findings or notebooks.
External testing or review	Recurring or periodic. Paid to a testing firm or reviewer, and scoped in writing with the organization.	Up with the number of systems in scope and the depth of the review requested. Keep it down by aligning the review scope with the hunt scope and the CA-8 testing schedule.
Auditor sampling	Recurring at each assessment. Paid to the independent assessor, not to DeployOpen or the organization's own staff.	Up when hunt evidence is spread across systems or undocumented. Keep it down by keeping one current hunt log that links each hunt to its frequency, scope and outcome.

Who owns RA-10: your team, a partner and the auditor

Your organization owns RA-10. That means you define what the threat hunting capability is, set the frequency at which hunts run (the control uses a parameter that the organization defines), decide which systems fall in scope, and accept the residual risk of anything a hunt finds or misses. Your security team also has to act on results, because a hunt that finds an indicator of compromise and goes nowhere produces no defensible evidence.

Defining the parameter: Set and document the hunt frequency and scope in your system security plan or hunting procedure, and approve it at the level your governance requires.
Staffing the work: Name the analysts who run hunts, who reviews their findings, and who escalates to incident response.
Owning the outcomes: Record each hunt, its hypotheses, what was searched and what was decided, including the findings you chose not to pursue.
Operating the tools: Keep log sources flowing into your detection platform, since a hunt cannot find what was never collected.
Retaining records: Keep hunt reports, tickets and approvals in a location your assessor can access.

Before engaging anyone, confirm with your assessor which artifacts they expect for each of the three RA-10 determination statements.

Where threat hunting programs fall short of RA-10

RA-10 asks for an ongoing hunting capability with a defined frequency, and assessors look for proof that hunts happen, what they found and what changed afterward. The gaps below are the ones that most often leave an organization with tools but no demonstrable capability.

No defined hunt frequency

RA-10 leaves the hunt cadence as an organization-defined parameter, so the parameter has to be set and written down before an assessor can test against it. Without a stated frequency, hunts happen when someone has time, and the assessor has nothing to measure. Record the frequency in the risk assessment policy or the hunting procedure, state which systems each cycle covers, and keep the schedule that shows the cycles actually ran.

Ad hoc, undocumented hunts

A hunt run from a analyst's notes with no hypothesis, query or result record cannot be reviewed or repeated. Each hunt should start from a written hypothesis, name the data sources and queries used, and end with a record of findings, including negative results. Those records are the examine evidence an assessor will ask to see, and they show that the capability is operating rather than described.

Telemetry gaps in cloud and endpoints

Hunts can only find what the collected logs show, so a cloud control plane that is not forwarded or endpoints that report only sporadically leave blind spots. Inventory the log sources each hunt depends on, including cloud audit logs, identity provider events and endpoint process data. Confirm coverage on a sample system before relying on a hunt result, and record which sources were missing for any period a hunt covered.

Hunts that never reach detection

When a hunt finds a technique that existing rules miss, the useful output is a new detection, yet many programs stop at a one-time report. Each confirmed pattern should produce a detection rule, a tuning change or a documented decision not to act. Tracking that handoff shows the hunting capability feeding back into monitoring and reduces the chance the same behavior is found again by hand.

Hunt findings disconnected from incident response

A suspicious host found during a hunt has to enter the incident handling process with the same ticket, timestamps and chain of custody as any other event. If hunt results sit in a separate spreadsheet, the response team cannot reconstruct what was seen or when. Route hunt escalations into the incident response workflow, and keep the link between each escalation and the hunt that produced it.

No trail from hunts to the risk assessment

RA-10 sits next to RA-3, RA-5 and SI-4 in the control catalog, and an assessor will expect hunt results to inform the risk assessment report and vulnerability and monitoring decisions. Without a trail, a threat the hunt surfaced never shows up in risk decisions or plans of action and milestones. Reference each hunt cycle in the risk assessment update and note any resulting risk response, so the link can be followed from one document to the next.

How much effort does threat hunting take, and can we run it ourselves?

How much effort does threat hunting take for an SP 800-53 system?

The effort depends on the size of the environment, how many log sources feed the hunt, how often hunts run, and how much detection engineering the team has to do after each hunt. No public figure for hours or cost is supplied for RA-10, so treat any number a vendor gives you as a claim to verify. The main drivers are the number of hosts, endpoints, cloud accounts and network devices in scope, the maturity of logging and time synchronization, the hunt frequency your organization defines for RA-10, and whether hunts produce new detection rules that must be tested and maintained. Ask any provider for a written scope listing systems, data sources, hunt cadence, deliverables and the people who perform each task, then compare quotes against that scope rather than against headline day rates.

Can our own team run threat hunts without an outside partner?

Yes, an organization can run hunts with its own staff, provided it has analysts who understand the systems, a log pipeline that covers the relevant sources, and time set aside for hunting outside incident response. RA-10 is an organizational control, so the organization owns the capability whether or not a partner helps build it. Open-source tools such as Wazuh, osquery, Velociraptor and OpenSearch Security Analytics can support hunts in your own infrastructure. A partner can help plan the hunt program, install and harden the tools, write queries and document the results, but the organization decides what is hunted and accepts the findings. Check whether your staff can keep hunts running on a defined schedule once the initial build is finished.

What do threat hunts need from our analysts and infrastructure?

Hunts need analysts who can read logs, form a hypothesis about adversary behavior and pivot across data sources, plus infrastructure that keeps those sources searchable for long enough to be useful. In practice this means:

Analysts familiar with the operating systems, identity systems and cloud platforms in scope, and with MITRE ATT&CK technique names if alerts are mapped to them.
Endpoint visibility through a tool such as osquery or Velociraptor, with permissions to query processes, network connections and file hashes.
A central log store, such as the Wazuh indexer or OpenSearch, sized for retention and search at the volumes you expect.
A documented process for recording hunts, findings, and any new detection rules that come out of them.

Confirm retention periods and access controls with your own security and legal teams before you commit to a design.

Is RA-10 required for our system under SP 800-53?

RA-10 is not assigned to any SP 800-53B baseline, so it applies only when your organization selects it through tailoring or an overlay. Whether it is required depends on your system's impact level, the contract or authorization you operate under, and any overlay your authorizing official or customer applies. FedRAMP's Rev5 baselines, as listed in the Consolidated Rules for 2026, do not require RA-10 at Class B, C or D. Your agency, customer or assessor sets the requirement in writing, so ask for the control selection in your system security and privacy plan before deciding how much to invest. Note that RA-10 is marked as an assurance-related control in Appendix C, which can make it attractive even where it is not mandated.

What evidence will an assessor ask for first on threat hunting?

An assessor testing RA-10 will look for proof that the capability exists and runs at the frequency you defined. SP 800-53A Release 5.2.0 uses three determination statements and examines assessment reports, audit records and event logs, and the threat hunting capability itself. Expect to show the hunt procedure and its defined frequency, records of completed hunts with dates, queries or artifacts used, findings and their disposition, and any detection rules or alerts created from the work. Interviews will test whether analysts know how hunts are chosen and escalated. Keep the hunt schedule, outputs and linked tickets in one place so the assessor can trace each hunt to its result.

How does an implementation partner differ from an auditor for RA-10?

An implementation partner prepares the systems, tooling, procedures and evidence, while an independent assessor tests the control and reports on it. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your infrastructure, and runs security testing that can complement hunting. It does not issue assessment reports, attestations or certifications. The organization owns RA-10 and makes the decision about whether the capability meets its requirement. The assessor, which may be an agency assessor or an independent party engaged under your authorization process, decides whether the evidence is sufficient. Agree these roles in writing at the start so that no one assumes the partner is performing the assessment.

How DeployOpen builds the hunting capability and its evidence

DeployOpen plans, implements and documents a threat hunting capability for RA-10 inside the client's own infrastructure, using self-hosted open-source platforms. The organization keeps ownership of its controls, hunt frequency and risk decisions, while DeployOpen prepares the systems, hunts and evidence that an independent assessor will examine.

How we scope

Written scope names the systems, log sources and endpoints that hunts will cover for RA-10.
The organization defines the hunt frequency it selects as its organization-defined parameter for RA-10.
Scope records which SP 800-53A examine objects, such as threat hunting capability and event logs, the evidence must satisfy.

How we build

Deploy the chosen open-source platforms, such as Wazuh, osquery or Velociraptor, in the client's environment.
Write and tune custom detection and hunt content, mapped to the organization's threat scenarios and ATT&CK coverage.
Test hunt queries against known indicators in a controlled way before they run against production systems.

How we hand over

Deliver hunt procedures, runbooks and triage steps the client's own staff can repeat at the defined frequency.
Document each hunt run with its scope, queries, results, findings and follow-up decisions for assessors.
Provide a handover session and written records showing which hunts ran, when, and what was done about results.

How we support

Ongoing support, platform upgrades and continuous testing are available as a retainer after handover.
Retainer work can refresh hunt content as threats change and as the defined hunt frequency is reviewed.
Confirm with the client's assessor which hunt records and retention periods they will need before fieldwork begins.