RS.AN-08 incident magnitude: requirements and evidence

What RS.AN-08 asks when one system is compromised

RS.AN-08 asks the organization to estimate how far an incident has spread and to validate that estimate. It is a Subcategory of the Incident Analysis (RS.AN) Category in the Respond Function of the NIST Cybersecurity Framework (CSF) 2.0. The situation it describes is familiar to any analyst: one host has been confirmed as compromised, and the open question is whether it is an isolated event or the first sign of a wider intrusion. The outcome is that the magnitude is estimated and then checked, so that containment, notification and recovery decisions rest on evidence rather than on the first host alone. NIST writes RS.AN-08 as an outcome, not a checklist, so it does not prescribe a method. The organization decides how to meet it and owns the result. It succeeds part of CSF 1.1 RS.AN-2, which addressed the impact of an incident, and the CSF 2.0 transition spreadsheet from NIST shows that mapping if you need to trace it.

Underestimating scope is the costly error. If the team contains one workstation while a service account, a second host or a cloud workload still holds the attacker's access, the incident reopens later, often with more data exposed and a weaker timeline to report. Overestimating has costs too, because unnecessary isolation of production systems disrupts the business. The work is hard for three reasons: fleet visibility is often incomplete, so the team cannot easily see which other systems ran the same software or hold the same indicators; time pressure pushes analysts to decide before the search is finished; and without a known baseline for normal process, network and account behavior, an unusual artifact on one system is difficult to judge against the rest of the estate.

The practical decisions sit with the incident lead and the owners of the affected systems. Define which other targets will be searched for indicators of compromise and signs of persistence, such as scheduled tasks, new accounts, unusual processes and outbound connections. Decide in advance which tools can run that search across the fleet and who can authorize it. Record the search scope and the negative results, not only the hits, so an assessor can see what was checked. Confirm with your own environment and with the vendor documentation of any tool you intend to use what it can query, how quickly it reaches offline hosts and how results are retained. An independent assessor will test whether this reasoning was done and written down, but it is your team that must carry it out.

Which systems, teams and third parties fall under RS.AN-08 scope

RS.AN-08 asks the organization to estimate how far an incident reaches by checking other potential targets for indicators of compromise and evidence of persistence. The scope is set by a handful of decisions about which hosts, identities, control planes, log sources, third parties and approvers belong in the sweep, and each decision changes how much work the estimate takes.

Host and identity population

Start by defining the population of endpoints, servers and directory identities that could share the affected trust path or credentials. The size of the fleet, how many operating systems it spans and how current the asset inventory is all determine how long a sweep takes. Check which hosts are offline, laptops that roam, and build systems that are rebuilt often, because these need a schedule to be collected when they return. Confirm the inventory from ID.AM before choosing the population, since a sweep cannot cover hosts nobody has recorded.

Cloud and SaaS control planes

Identity providers, cloud management consoles and SaaS administration panels can expose persistence without touching a single server. Attackers often add keys, roles, OAuth grants or forwarding rules here. The work grows with the number of cloud accounts, subscriptions and tenants, and with how many of them keep audit logs for a usable period. Confirm which control planes you can query, who holds administrative rights in each, and whether logs from before the incident window still exist.

Network and security device logs

Firewalls, proxies, DNS resolvers, VPN concentrators and endpoint detection platforms show which other systems spoke with the affected assets. Without them, a sweep can only look at hosts directly. The volume of retained logs, the time window they cover and whether they are normalized into one searchable store all change the effort. Check retention on each source against the period the attacker could have been active, and note any source that drops events under load.

Third parties with access or management rights

Managed service providers, outsourced hosting teams and software vendors that hold credentials or remote management paths to your systems are part of the potential target set. Their access must be reviewed for the same indicators you search internally. Confirm contractually who can produce logs and host evidence, how quickly, and under what chain-of-custody rules. Where a third party cannot provide that access, record the gap in the magnitude estimate rather than assuming those systems are clean.

Incident response roles that approve scope

Someone with authority must agree the boundary of the sweep, the systems excluded and the reasons for each exclusion. Typically this involves the incident lead, system owners, legal counsel and, where business operations depend on them, the operations team. Scope decisions that change during the investigation should be recorded with their rationale so the magnitude estimate can be reviewed later. Ask who may approve expansion of the scope at night or during a weekend response, and how that approval is documented.

How an assessor tests RS.AN-08 and what they ask to see

This table compares the four checks an assessor is likely to run against RS.AN-08, the evidence each check requests and the gaps that appear most often. Read each row as a question the organization should be able to answer from its own incident records before an assessor arrives. The main takeaway is that the magnitude estimate must be written down, searched for across other targets, and tied to a decision, because assessors work from the organization's records rather than from recollection.

Test approach	Evidence requested	Common findings
Review the incident record for a documented scope estimate	The incident ticket or case file showing a stated magnitude estimate, the date it was made, the assets and accounts considered and the person who approved it	Estimate is missing, undated or restated only in a closing summary, with no list of assets considered
Sample past incidents to check that other potential targets were searched	A sample of closed incidents with search queries, scope lists of hosts or accounts checked, and timestamps showing when the searches ran	Searches limited to the initially affected host with no record of checks on peer systems or shared credentials
Confirm the search covered indicators of compromise and evidence of persistence	Saved queries or hunt definitions covering IOCs such as file hashes, IP addresses and domains, plus persistence locations such as scheduled tasks, services, run keys and accounts	Only IOC matching is recorded, with no persistence checks, or persistence checks exist but are not tied to the incident
Check whether automated tools were run across targets where used	Tool configuration or schedules, job or hunt logs, and output showing which endpoints responded and which were offline or unreachable	Tool coverage is assumed rather than shown, offline systems are not tracked for later collection and gaps are not disclosed
Validate that results fed back into the incident decision	Decision log showing how search results changed containment, scope, notification or recovery choices, and the approver's sign-off	Results are collected but not linked to the decision, so the magnitude estimate is never revised after new findings

Implementing an incident magnitude process that holds up in an audit

This sequence turns RS.AN-08 into a repeatable process: defined indicator sets, a target inventory, agreed search methods, a sign-off procedure, tested exercises and a decision record that an assessor can follow from start to finish.

Define indicator and persistence sets per incident type
The incident lead and security analysts agree which indicators of compromise and which evidence of persistence to search for, grouped by incident type such as malware on endpoints, credential misuse or cloud account compromise. Each set names its source, such as threat intelligence feeds, prior incident findings or detection rules, and states who approves changes. The output is an indicator and persistence catalog, versioned and signed off by the control owner. It is done when every incident type in your incident response plan maps to at least one defined set.
Build a target inventory for the sweep
Assets that could be affected by the same activity are listed from your asset inventory, including hosts, identities, cloud accounts and network segments that share a trust path with the affected system. Owners confirm which entries are in scope and which are excluded, with reasons. The output is a target inventory that the sweep draws from, along with a note on known gaps where assets are unmanaged. Because the inventory decides how far the sweep reaches, an assessor will ask how it was built and how it stays current.
Choose manual and automated search methods and triggers
Decide which searches analysts run by hand, such as reviewing logs and timelines on high-value systems, and which run automatically with tools. Automated options include scheduled queries across a fleet of hosts with osquery, forensic artifact hunts across endpoints with Velociraptor, and detector runs against ingested logs with OpenSearch Security Analytics or Wazuh rules. Define the trigger for each method, such as a confirmed compromise on one host. The output is a sweep runbook listing each method, its trigger, its owner and the evidence it produces. Confirm that each tool supports your log sources and retention needs before you commit to it.
Write the validation and sign-off procedure with the incident lead
The procedure states how sweep results are validated, including how false positives are cleared, how a negative result is shown to be complete for the target inventory and what evidence closes each target. The incident lead signs the magnitude estimate after reviewing the validation record, and the procedure says who can override the lead and how that override is logged. The output is a written validation and sign-off procedure approved by the incident lead and the control owner. It is done when a reviewer can trace each conclusion back to its search results.
Test the process in a tabletop or cyber range exercise
Run the sweep runbook against a realistic scenario in a tabletop session or a private cyber range, with responders following the procedure as written. Observers record where the inventory was incomplete, where triggers were unclear and where validation took longer than the plan allowed. DeployOpen can design and run this kind of exercise as part of a fixed-scope engagement. The output is an exercise report with findings and assigned fixes, feeding back into RS.AN-08 improvements. Retesting the changed steps shows that the fixes work.
Adopt the magnitude decision record template
A standard template captures the incident identifier, the indicator and persistence sets used, the target inventory version, the methods run and their triggers, the validation results, the magnitude conclusion, the sign-off and any open items. Responders store the completed record with the investigation actions and incident data already preserved under RS.AN-06 and RS.AN-07, so the chain of evidence stays intact. The output is a template and a filled example kept in your incident management system. Label the example as illustrative and keep real records under access control.

Which self-hosted open-source tools can support the magnitude search

osquery is licensed under Apache-2.0 OR GPL-2.0-only and exposes operating system state, such as running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes, as SQL tables. Its osqueryd daemon can schedule the same query to run across an entire fleet of hosts, which lets a team ask one question of many endpoints and compare the answers. For a magnitude search, this makes it practical to check whether a suspicious process name, outbound connection or file hash appears on systems beyond the first confirmed target.

Fleet-wide queries: The osqueryd daemon schedules a query across many hosts, so one definition can cover the whole estate.
Persistence checks: Tables for processes, network connections and loaded modules help show whether an attacker has left footholds on other hosts.
File hash comparison: Hash tables let the team compare file hashes from the incident against every target it inspects.
Scheduled repetition: Scheduled queries can rerun during the investigation to catch hosts that were offline during the first pass.
Query design: Each indicator needs a query written and tested by the team, so coverage depends on how carefully the queries are built.

Confirm in your environment which hosts run osqueryd, whether every target is enrolled, and how long query results are retained.

Evidence that passes RS.AN-08 and how to keep it current

An assessor testing RS.AN-08 will want to see that magnitude was estimated for a real incident, that other targets were searched in a documented way, and that the conclusion was signed off. The cards below cover each artifact and how to keep it current between assessments, so the evidence is ready when it is requested rather than rebuilt under pressure.

Incident record with magnitude estimate

The incident record should state the magnitude estimate in plain terms: which systems, accounts, data sets and business units are believed affected, how that belief was formed, and what remains unknown. Record the time the estimate was made and each revision, so an assessor can see how the picture changed as evidence arrived. Between assessments, review a sample of closed incidents each quarter and check that every one has a magnitude statement, not only a closure note. Confirm with your incident platform how it timestamps and versions edits to this field.

Sweep queries and hunt definitions

Keep the exact queries or hunt definitions used to search other potential targets, with the indicators searched, the target scope, and the start and end time of each run. For example, a fleet query for a suspicious process hash across all Linux hosts, run at a stated time against a stated inventory, is far more useful to an assessor than a sentence saying hosts were checked. Store these definitions in version control so the version run is provable. Schedule a regular review to confirm that queries still run against current inventory.

Results and triage notes per target

For each target searched, keep the raw results, whether the target was offline or unreachable, and a triage note stating what was found and what was ruled out. Empty results are evidence only when they show the search reached the target, so record coverage as well as hits. Hunt notebooks or saved results should be retained under the same retention rules as the incident record. Between assessments, test one retained hunt by re-running it to confirm the stored output matches what was recorded.

Validation sign-off by the incident lead

A named incident lead should sign off that the magnitude estimate was validated, meaning the searched targets, the coverage gaps and the residual uncertainty were reviewed by someone accountable. Record the sign-off date, the lead's role and any open items that carried forward. Assessors often test whether the sign-off came before closure and whether it covers unreached targets. Review the sign-off template after each significant incident and after any change in who holds the lead role.

Indicator set updates after new findings

When a sweep finds new indicators of compromise or evidence of persistence, the indicator set used by detection and by future sweeps should be updated and the change dated and attributed. Keep a changelog linking each new indicator to the incident that produced it. Between assessments, schedule a periodic review of the indicator set against recent incidents and threat intelligence, and confirm that detection rules such as Sigma rules in your analytics platform reflect the updated indicators.

Periodic sweep exercises

Exercises show that the magnitude process works before a real incident forces it. Run a tabletop or a technical sweep against a planted indicator on a set schedule, record the time to search the full target scope, and note any targets the tooling could not reach. Keep the exercise report with its action items and track those items to closure. Confirm with your security team how often exercises are scheduled and who reviews the results.

What meeting RS.AN-08 costs in money and staff time

This table lists each cost component of estimating incident magnitude under RS.AN-08, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Read it as a checklist for building a written quote, because no price or duration is published for this work and the real figures depend on your environment.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling and licenses	Recurring if commercial, one-time setup otherwise	Number of endpoints, log volume and whether the sweep tool is commercial or open source. Open-source tools such as osquery, Velociraptor, Wazuh and OpenSearch remove license fees, but hosting, storage and staff remain.	Confirm license terms for each tool before selection. Size storage for the log retention you actually need, and budget hosting inside your own cloud or data center.
Engineering time to build indicator sets and sweep runbooks	One-time, with periodic updates	Number of incident types you plan to sweep for, how many indicators of compromise and persistence you define, and how many platforms (Windows, Linux, cloud) must be covered.	Start with a small set of high-value indicators tied to your past incidents and threat intelligence. Reuse Sigma rules and existing Wazuh rules where they fit.
Analyst time for each incident sweep	Recurring, per incident	Number of potential targets to search, depth of persistence checks, whether sweeps are manual or automated, and how many findings need validation.	Automate scheduled and fleet-wide queries so analysts review results instead of collecting them. Agree a target list and a stopping rule before each sweep.
Evidence upkeep	Recurring	Retention periods for sweep queries, results, hunt notebooks and analyst notes, plus the integrity controls applied to them under RS.AN-06 and RS.AN-07.	Define retention and storage locations once in a procedure. Store sweep outputs in the same evidence system used for other incident records.
Testing and exercises of the sweep process	Recurring, at a frequency you set	How often you run tabletop or technical exercises, how many systems the exercise covers and whether the exercise uses a private cyber range.	Ask the provider to scope a fixed set of exercises and reuse the same runbooks across them.
External compromise assessment or review	Recurring or one-time, optional	Whether an outside party is asked to validate that no other targets are affected, the scope of hosts and identities reviewed, and the report format you need.	Request scope in writing, limit the review to the incident's identified targets, and use internal sweeps for routine validation.
Auditor sampling time	Recurring, per assessment cycle	How many incidents fall in the sample period, whether the auditor samples sweep records and the quality of your documentation.	Keep one consistent record per incident showing targets searched, tools used, results and the validation decision. Auditors do not issue reports on your behalf; they test the evidence you hold.
Implementation partner services	One-time for build, optional recurring for support	Scope of tooling configured, number of environments, integration with existing SIEM or case management, and handover documentation.	Request a fixed-scope written proposal listing deliverables, environments, number of targets, log retention and exercise frequency. Compare quotes against the same scope.

Who does what for RS.AN-08: your team, a partner and the auditor

Your organization owns RS.AN-08. Your incident lead decides how far an incident reaches, which other systems must be searched, and when the estimate is considered validated. Those decisions, and the reasoning behind them, must be recorded by your people, because an assessor will ask who made the call and on what basis. Your team also keeps the magnitude record that links each sweep to the incident it supports.

Magnitude decisions: Assign an owner who decides the scope of the sweep, the targets to search and the point at which the estimate is validated.
Indicator and persistence criteria: Define the indicators of compromise and persistence evidence your analysts search for, and update them as the investigation changes.
Magnitude record: Keep a dated record of each sweep, its targets, its results and the conclusion reached, linked to the incident ticket.
Operation of the tooling: Review query and alert output, triage matches and document false positives so the sweep stays reliable.
Oversight of partners: Approve any partner-built tooling or runbooks and confirm they match your procedures.

Check that someone on your team can explain, without the partner present, how a magnitude estimate was reached for a past incident.

Where organizations fall short on incident magnitude and how to close it

Magnitude estimates fail in predictable ways: the sweep has no written scope, covers only part of the estimated environment, or leaves no trail. The cards below are a planning list of common gaps for RS.AN-08, and each must be checked against your own assessment results before you act on it.

No documented sweep scope

Without a written scope, the team decides during the incident which hosts, accounts and segments to search, so the magnitude becomes a guess. RS.AN-08 expects an incident's magnitude to be estimated and validated, which requires a defined set of other potential targets. Close the gap by writing a scope template that names the asset classes, the criteria for adding a target (shared credentials, same image, same network zone) and the owner who approves changes. Evidence: an approved scope statement per incident type, reviewed after each exercise.

Sweeps limited to endpoints

Endpoint-only sweeps miss compromise that moved through identity providers, cloud control planes and network devices. Attackers often reuse valid accounts, so a clean endpoint can still sit inside an affected estate. Extend the sweep to identity logs, cloud audit trails and network telemetry, and record which data sources were searched for each target class. Confirm that your Wazuh or OpenSearch deployment ingests these sources before you rely on them. Evidence: a coverage matrix listing each source and whether it was queried.

Indicators set once and never updated

Indicators of compromise taken from the first incident go stale quickly, so a sweep run weeks later can report false comfort. Each new analysis should add indicators from the current investigation, such as file hashes, process names, persistence locations and command lines, and retire those that no longer apply. Sigma rules and Wazuh custom rules can carry these indicators forward when they are version controlled. Evidence: a dated indicator set with source, owner and review history.

No record of targets searched

If the record does not show which targets were searched and when, the team cannot prove the magnitude estimate or repeat it. Auditors and regulators asking how scope was determined will find gaps. Log every query run, the target set it covered, the time window and the operator, and keep the output with the incident record. Velociraptor hunts and osquery scheduled queries can produce this trail when their results are retained. Evidence: a sweep log that links each target to its query and result.

No link to containment decisions

A magnitude estimate that does not reach the people deciding on isolation, credential resets or customer notification adds no value. Without a sign-off step, containment can be too narrow or too broad. Assign a named decision owner who reviews the validated magnitude against the containment plan and records the decision and its basis. Check that the sign-off aligns with your incident response plan and escalation roles. Evidence: a signed decision record that cites the sweep results.

Common questions about RS.AN-08 cost, effort and outsourcing

Does NIST certify that we comply with RS.AN-08?

No. NIST does not certify organizations, products or services against the Cybersecurity Framework, and it has no plans to create a conformity assessment program. RS.AN-08 is an outcome in your own program: an incident's magnitude is estimated and validated. Any assessment is therefore run against your documented process and its records, by an internal reviewer, a customer's assessor or an independent auditor who chooses the criteria they test. Only an independent auditor or certification body can issue a report or certificate. An implementation partner can prepare the sweep procedure, tooling and evidence, but it cannot grant the outcome.

How much effort does an incident magnitude sweep take, and what drives it?

Effort depends on how many systems must be searched and how quickly the team can gather their data. The main drivers are:

The number of endpoints, servers, cloud accounts and identity systems in scope
Whether telemetry is already centralized and searchable, or must be pulled from each host
How many indicators of compromise and persistence mechanisms the incident lead defines for the sweep
The number of repeat sweeps needed as new indicators emerge during the investigation
How much manual triage each hit requires before it is confirmed or dismissed

No figure is given here. Ask your team or a prospective partner to size the sweep from your inventory and log coverage, and to state which parts are one-time setup and which recur at each incident.

Can a small security team run incident magnitude sweeps in-house?

Often yes, if the team can query its endpoints and logs at short notice and has a documented procedure. A small team usually needs a fleet query tool, a log or alert platform it already operates, and an agreed list of indicators to search. The harder part is staffing for the moment an incident is live, when analysts must sweep other targets while still containing the original event. Consider whether you have at least one person who can write and run queries, someone who can judge whether a hit is malicious, and a backup for both roles. If any of these are missing, a fixed-scope engagement to build the procedure and train your staff is a common alternative to running it fully outsourced.

What does the work need from our organization?

The sweep needs access and accurate context before an incident starts, not during it. Plan for:

Read access to endpoint, network and cloud logs with enough retention to cover the period under investigation
A current asset inventory so the sweep covers every target that could be affected
Named contacts and approvals for querying production systems and for isolating hosts
An incident lead who can define indicators and decide when the sweep is complete
Time for the team to rehearse the procedure, since first attempts often reveal gaps in inventory or logging

Before you buy or commission anything, confirm each of these items with your own environment and log retention policy.

How long does a magnitude sweep take in general terms?

Duration depends on scope, data availability and how many indicators must be checked, so no fixed timeline applies. A sweep over a small, well-logged environment is generally much shorter than one across many segments, clouds and business units with partial logging. Two stages usually take most of the time: the initial search across targets, and the validation of each hit to decide whether it is part of the incident. Ask for milestones in a written scope, such as when the indicator list is agreed, when the first sweep completes and when results are handed to the incident lead for validation.

Can a partner produce the evidence an auditor will ask for?

A partner can help you produce and preserve the evidence, but the organization owns its controls and the auditor decides whether the evidence is sufficient. DeployOpen plans, implements, configures and documents self-hosted open-source platforms in your own infrastructure, and it can prepare the sweep procedure, collection tooling and record templates. It does not issue audit reports, attestations or certifications. Evidence you should expect to keep includes the sweep procedure, the indicator list, query or hunt records, timestamps, and the validation decisions made by the incident lead. Confirm the retention and access rules for these records with your auditor before work starts.

What will an auditor sample when testing RS.AN-08?

An auditor typically samples incidents, or recent exercises, and checks whether your organization estimated and validated magnitude as its own procedure describes. Expect requests for the written procedure, evidence that other potential targets were reviewed for indicators of compromise and persistence, records of the tools or manual checks used, and the decision record showing how magnitude was confirmed. Auditors may also ask how you know your inventory and logs were complete for the sweep. Because the test is against your own program, the criteria your team sets for the sweep matter as much as the sweep itself. Confirm the sample size and selection method with the auditor directly.

How do we write a fixed-scope request for magnitude sweep support?

Write the request around outputs you can check, not around hours. Include the systems and sites in scope, the log and inventory sources available, the open-source platforms already in use, the indicator types the sweep should cover, and the evidence the auditor expects. Ask each bidder to list deliverables such as a written sweep procedure, tooling configuration, a rehearsal and a record template, and to state which items are one-time and which recur. Request that scope, deliverables and timelines be agreed in writing before work begins, and that responsibilities for controls, evidence and audit are named separately. Fixed-scope proposals are normally priced from that written scope, so compare quotes against the same list.

How DeployOpen scopes and prepares RS.AN-08 evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so the tools that search for indicators of compromise and persistence across other potential targets run in your environment. We prepare the systems, detection content and records that show how your team estimates and validates incident magnitude, while your organization owns the controls and the independent assessor issues any report.

How we scope

Agree in writing which systems, fleets and log sources count as other potential targets for RS.AN-08.
Define which indicators of compromise and persistence each sweep will check, such as processes, network connections and scheduled tasks.
Set out who runs each magnitude check, who validates the result and which records must be kept, in a fixed-scope document agreed before work starts.

How we build

Deploy osquery, Velociraptor or Wazuh inside your environment to run queries and hunts across the agreed host groups.
Configure detection rules and hunts, including Sigma rules in OpenSearch Security Analytics, so matches are recorded as findings with severity.
Test each sweep against known indicators in a controlled setting and document how results are reviewed and escalated.

How we hand over

Deliver runbooks describing the manual and automated steps used to estimate and validate incident magnitude.
Provide sample exports, hunt notebooks and alert records that show each check ran, with timestamps and the responsible analyst.
Map each deliverable to RS.AN-08 and its informative references so your assessor can trace evidence to the requirement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review rule changes, tool upgrades and new log sources so the magnitude checks stay current with your environment.
Confirm with your assessor which evidence formats they accept, since final acceptance of evidence rests with them and not with DeployOpen.

RS.AN-08 Incident magnitude estimated