RS.AN-07 incident data collection and preservation

What RS.AN-07 asks for and why assessors test it

RS.AN-07 asks an organization to collect incident data and metadata, then preserve their integrity and provenance under evidence preservation and chain-of-custody procedures. In plain terms, when an incident happens, the records that show what happened, where the data came from and when it was gathered must be captured and kept in a state that can be trusted later. NIST's Implementation Example for this Subcategory describes the same idea: collect, preserve and safeguard all relevant incident data and metadata, such as the data source and collection time, under evidence preservation and chain-of-custody procedures. The Subcategory sits in the Incident Analysis (RS.AN) Category of the RESPOND Function in CSF 2.0 (CSWP 29).

Assessors test this because the risk is concrete. If logs or disk images cannot show where they came from, who handled them and whether they changed, their value falls in a dispute, a regulator inquiry or a customer audit. Weak evidence also undermines root cause analysis (RS.AN-03) and the investigation record (RS.AN-06), and it can leave gaps in the facts an organization reports to regulators or contract counterparties. NIST's transition spreadsheet flags RS.AN-07 as new in CSF 2.0, so an organization that moved from CSF 1.1 cannot point to an existing 1.1 Subcategory and assume its practice already covers this outcome. Retrofitting provenance is hard because collection timestamps, hashes and custody records must exist from the moment data is gathered. Confirm with your assessor which evidence format they expect before an incident forces the question.

Which systems, data and teams RS.AN-07 covers in practice

RS.AN-07 asks that incident data and metadata are collected and their integrity and provenance preserved. In practice, the hardest part is deciding what counts as incident data, which metadata travels with each item, who collects it and who analyzes it, and how an outside provider fits in. These decisions shape the workload far more than the choice of tool.

Log sources and audit trails

Decide which log sources, identity provider events, firewall and proxy records, and SaaS audit trails are in scope for an incident. Include the sources an investigator would need to rebuild the sequence of events, such as authentication logs and administrative changes. Check whether each source retains enough history to cover the detection delay you expect, and confirm that log retention is set by the organization rather than left at a vendor default. Gaps found during an incident cannot be filled afterward.

Endpoints and servers in scope

List the endpoints, servers and virtual machines from which volatile and persistent data may be collected during an incident, including remote and offline laptops. Running processes, loaded kernel modules, open network connections and file hashes are typically the first items lost when a host is rebooted or reimaged. Confirm that the collection agent is deployed on every class of host and that a host can be reached without relying on the compromised network path.

Cloud control planes and SaaS logs

Cloud administrative actions, such as changes to identity policies, storage permissions and network rules, often leave the most important evidence and are not visible on the host. Decide which cloud accounts, subscriptions and SaaS tenants feed the incident record, and who holds the access needed to export their audit trails. Ask each provider how long its audit records are kept and how they can be exported in a form that can be verified later.

Metadata that travels with each item

Every collected item should carry its data source, collection time, collector identity and a hash value computed at the moment of collection. Without these fields, an item cannot later show where it came from, when it was taken or whether it has changed. Tools such as DFIR-IRIS can log evidence with SHA-256 verification and chain of custody, but the organization must define the required fields before collection begins.

Collection teams versus analysis teams

Separate the people who collect evidence from the people who analyze it, or document why they are the same. Collectors need authority to acquire data from production systems and a written procedure for doing so. Analysts need read access to the collected copies, not the originals. Name the incident lead who approves collection steps and confirm that each role appears in the chain-of-custody record, since an assessor will ask who touched each item.

Managed security provider responsibilities

When a managed security service provider monitors logs or runs endpoint tooling, the contract should state who collects evidence, where it is stored, who holds the keys to the storage and how the organization retrieves items during an incident. Confirm that the provider's collection follows the same metadata and hashing rules as internal staff, and that the organization keeps a copy it controls. Responsibility for the evidence record stays with the organization, even when the provider performs the work.

How an assessor tests RS.AN-07

This table sets out the five checks an assessor is likely to run against RS.AN-07, the test approach for each, the evidence typically requested and the findings that tend to appear. Read it as a preparation list: each row shows what the organization should be able to produce before the assessment begins. The assessor, not DeployOpen, reaches the conclusion on each check.

Test approach	Evidence requested	Common findings
Review of the documented collection and preservation procedure	Approved procedure covering incident data sources, collection steps, metadata fields, storage locations and chain-of-custody forms, with version and approval records	Procedure exists but is generic, does not name data sources, or has not been approved or reviewed since the last major system change
Sampling of recent incidents to confirm data was collected with metadata	Case records for a selection of recent incidents showing collected items, data source, collection time and collector identity	Collection is described in the procedure but case records lack source or collection time, or key data was gathered only from memory or chat logs
Verification that hashes or integrity checks exist and were applied	Hash values recorded at acquisition, hash verification logs, and tool settings showing the algorithm used (for example SHA-256 in a case management tool)	Hashes are missing for some items, were computed after files were copied, or were never re-verified before analysis
Review of chain-of-custody records for specific items	Custody logs for selected evidence items showing each transfer, handler, date, purpose and storage location from collection to disposal	Gaps in custody between handlers, unsigned transfers, or evidence moved to personal storage without a log entry
Checks that preserved data is access-controlled	Access lists for evidence repositories, role assignments, authentication settings and audit logs of access to preserved incident data	Broad read access to evidence stores, shared administrator accounts, or no record of who viewed or exported preserved data

Implementing RS.AN-07 step by step

This sequence takes an organization from an undefined approach to incident evidence to a tested process that collects incident data and metadata, keeps its integrity and provenance intact, and records who handled it at each point.

Define incident data classes and minimum metadata
The incident lead, with security operations and legal or compliance staff, lists the data classes an incident typically produces: host and endpoint artifacts, network captures and flow records, log extracts, cloud audit trails, alert records, responder notes and communications. For each class, define the minimum metadata to capture with it, such as data source, collection time, collector identity, host or system of origin and hash values. Record who owns each class and where it is stored. The output is a data inventory that names every class, its minimum metadata fields and its custodian. Confirm the list with legal counsel before publishing it, since retention and privacy duties may shape what is kept.
Set collection triggers and sources
Decide which events start collection and which systems feed it. Triggers might include a confirmed alert from the SIEM or EDR, a file integrity change on a monitored asset, or a declared incident in the response plan. Map each source to the data classes from the inventory so that no class lacks a feeder. Document the trigger conditions and the source owner in a short collection standard. The output is a reviewed trigger and source matrix that the security team can apply during triage without needing to reinterpret it under pressure.
Deploy collection tooling and file integrity monitoring
Configure the collectors that the matrix requires. Open-source options include osquery for scheduled, fleet-wide SQL queries against host state, Velociraptor for artifact collection and hunts across groups of endpoints, and Wazuh for file integrity monitoring that baselines checksums and attributes and alerts on creation, modification or deletion with the actor and time. Limit collector privileges to what collection needs, and store collected data in a location the responders cannot silently alter. Confirm each tool's capabilities and licensing against your own environment before rollout. The output is a configured collector set, with a test record showing that each source delivers the metadata fields defined in step one.
Define hashing and time synchronization
Set one hashing method for all collected artifacts, such as SHA-256, and require that a hash is calculated at the point of collection and recorded with the artifact. Require all collectors and case systems to synchronize clocks to a common time source and to log the time zone used, so that timelines built from different sources agree. Where a case management platform is used, confirm that it supports hash verification and logs evidence entries, as DFIR-IRIS does for SHA-256 with a chain of custody record. The output is a written hashing and time standard, and a verification test showing that re-hashing a sample artifact reproduces its recorded value.
Write the evidence preservation and chain-of-custody procedure
The incident lead and legal counsel write the procedure that governs how evidence moves from collection to storage and eventually disposal. It should state who may collect, how each transfer is logged with the name of the person, the time, the hash and the reason, where originals are kept and who may access them, and how working copies are made. It should also state how responder actions and log changes are recorded so that the record of the investigation stays consistent. Include the steps for escalating to outside forensic or legal support. The output is an approved procedure with a custody log template, assigned owners and a review date set by the organization.
Run a tabletop or live exercise to test it
Run a scenario that produces realistic-looking alerts for the data classes in the inventory, such as a suspicious process on an endpoint and a modified monitored file. Have responders collect the data, hash it, record custody transfers and produce a timeline, then check each record against the procedure. A tabletop tests decisions and handoffs. A live exercise also tests the collectors and storage. Record gaps, such as missing metadata, unsynchronized clocks or unlogged transfers, and assign fixes. The output is a signed test record listing what worked, what failed and the changes made, which becomes the evidence that the RS.AN-07 process operates as written.

Evidence that passes RS.AN-07 and the open-source tools that produce it

RS.AN-07 is tested by whether incident data is collected and its integrity and provenance can be shown afterward. The cards below cover the evidence artifacts an assessor will ask for, followed by four open-source tools that can generate parts of that evidence. No single tool satisfies the outcome on its own, and the organization owns the procedures and the decisions behind them.

Collection procedure and scope

A written procedure that names which incident data is collected, from which sources, by whom and under what triggers. An assessor will compare it against real cases to see whether the procedure was followed. Check that it covers endpoints, cloud control planes, identity logs and network sources, and that it states how collection starts when an incident is declared. Ask the implementation partner to map each source to a named owner.

Metadata standard for each item

A defined set of fields recorded with every piece of incident data, such as data source, collection time, collector, host identifier and collection method. The Implementation Example for RS.AN-07 names data source and collection time explicitly, so these fields should appear in the standard. Confirm that every collection tool writes these fields in the same format, because mismatched timestamps and host names are a common reason provenance cannot be reconstructed.

Hash and integrity records

Cryptographic hashes calculated when evidence is collected and checked again before it is used. Records should show the hash value, the algorithm, the time of calculation and the person or system that performed it. Verification results must be kept too, not only the original hashes. Confirm the hash algorithm your procedure requires and whether your case tooling verifies hashes on upload.

Chain-of-custody logs

A record of every transfer, access and handling step for each evidence item, from collection through storage to release to counsel, a regulator or an auditor. Each entry should identify the person, the reason and the time. Gaps in custody are often found only when an assessor samples a case, so test the log by tracing one item end to end before the assessment begins.

Case audit trails and retention settings

Audit trails show who changed a case, evidence or record, and when. Retention settings define how long incident data, logs and case records are kept and who can delete them early. Check that case records cannot be edited without a trace, that retention periods match legal and contractual needs, and that deletion is itself logged. Confirm with legal counsel which retention periods apply in your jurisdiction and sector.

Periodic test records

Dated records showing that collection and preservation were tested, such as a tabletop exercise or a test case that was collected, hashed, logged and retrieved. These records show the procedure works in practice, not only on paper. Keep the scope, participants, findings and the fixes made afterward. Ask the partner to plan the test cycle in the written scope so that results are available before an assessment.

osquery for scheduled fleet queries

osquery exposes system state, including running processes, loaded kernel modules, open network connections and file hashes, as SQL tables. Its osqueryd daemon can schedule the same queries across an entire fleet, which produces repeatable snapshots of host state at known times. Licensed under Apache-2.0 OR GPL-2.0-only. Confirm how query results are shipped and stored, whether they are signed or otherwise protected, and how they are linked to the metadata standard.

Velociraptor for artifact collection

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that gather one or more artifacts across a group of systems. Offline machines are scheduled to collect when they reconnect, and each hunt gets a notebook for analyzing the combined results. Licensed under AGPL-3.0-only. Confirm how hunts are authorized, how collected artifacts are hashed and stored, and how offline collection is recorded in the chain of custody.

DFIR-IRIS for case records

DFIR-IRIS keeps each case as one record of assets, indicators, tasks and evidence, with a full audit trail. It logs evidence with SHA-256 verification and chain of custody, and builds a timeline from the case data. Licensed under LGPL-3.0-or-later. Confirm how it connects to your SIEM and EDR sources, who can edit case records, and how exported reports are preserved so they match the case as it was recorded.

Wazuh for file integrity baselines

Wazuh file integrity monitoring records a baseline of checksums and attributes for monitored files and directories, then alerts when a user or process creates, modifies or deletes one. Alerts include how and when the change happened and who made it, which supports provenance questions about altered evidence. Licensed under GPL-2.0-only. Confirm which paths must be monitored, whether the baseline is stored outside the monitored host, and how alerts are retained.

What meeting RS.AN-07 costs in money and effort

This table breaks down the cost components of collecting and preserving incident data under RS.AN-07, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written scope and to compare quotes, since no price or duration is stated here.

Cost component	One-time or recurring	What drives it and how to keep it down
Tooling and licenses	Recurring if you use hosted or support subscriptions, one-time setup otherwise	The named tools (osquery, Velociraptor, DFIR-IRIS, Wazuh) are open source, but each carries its own license terms (for example AGPL-3.0 for Velociraptor), so have counsel read them. Ask whether any support tier or add-on is priced separately.
Storage for preserved evidence	Recurring	Volume of collected artifacts, retention periods set by your legal and regulatory duties, and whether copies are replicated. Scope collection to relevant sources and define retention per evidence class.
Engineering time to configure collection	One-time, then periodic updates	Number of log sources, endpoints and SIEM, EDR and REST feeds to integrate, and how many custom artifacts or queries you need. Start with a defined asset set and expand in written phases.
Integrity and chain-of-custody setup	One-time, then recurring checks	Hashing workflow, SHA-256 verification in the case system, custody logging and access controls. Reuse one documented procedure across incidents to avoid repeated design work.
Evidence upkeep and sampling readiness	Recurring	Frequency of incidents, staff turnover, and how often you test that records are complete and retrievable. Run periodic tabletop checks on a sample case so gaps surface before an assessor finds them.
External forensic or review support	Usually per engagement	Incident volume, need for outside investigators, and whether a retainer is in place. Agree on contact rules and retainer terms in advance so responders are not contracted during a live incident.
Auditor or assessor sampling effort	Recurring at each assessment cycle	Number of incidents the assessor samples and how quickly you can produce complete case files with provenance. Ask the independent auditor which records they will request before the audit starts.
Implementation partner scope	One-time fixed scope, optional retainer	Number of systems, integrations and documentation deliverables. DeployOpen quotes follow a written scope, so request a line-item breakdown that separates configuration, testing, documentation and handover.

Who owns RS.AN-07 inside, with a partner and at audit

RS.AN-07 is an outcome the organization must achieve, so accountability stays with the organization even when specialists configure the tools. Your incident response lead, security operations team and legal or privacy counsel decide what incident data is collected, how long it is kept and who may access it. These decisions are hard to delegate because they depend on your regulatory obligations, your litigation exposure and your internal investigation rules.

Procedure ownership: Approve a written evidence preservation and chain-of-custody procedure, and assign a named owner who reviews it after significant incidents or tooling changes.
Data inventory: Maintain a list of the log sources, endpoints, cloud accounts and SaaS platforms whose data would matter in an incident, with the owner of each source.
Custody decisions: Decide who may collect, export or hand over evidence, and record the approvals that allow external parties to receive it.
Retention and legal hold: Set retention periods and the process for placing and releasing legal holds on incident data.
Operational records: Keep the incident tickets, approvals and handover logs that show the procedure was followed in practice.

Before relying on any partner or tool, confirm that your own owner can explain the procedure and produce the records without outside help.

Where RS.AN-07 programs usually fall short

Most RS.AN-07 failures are not missing tools. They are missing rules: how evidence is labeled, when clocks are checked, how integrity is fixed, where custody is recorded, how collection continues, and whether the procedure has been rehearsed. Each card below names one gap and the action that closes it.

No metadata standard for collected items

Collected files, memory captures and log exports often arrive with a filename and nothing else. RS.AN-07 expects collected data and metadata such as data source and collection time to be preserved, so an item that cannot be tied to its origin is hard to use in a case. Define a short required field set (source host, collector, collection time, collection method, case reference) and reject intake that lacks it. Check a sample of recent items against that list.

Unsynchronized clocks across sources

Endpoints, servers, firewalls and cloud services each keep their own time. When collection timestamps disagree, the incident timeline built from them conflicts with itself, and the conflict often surfaces only during review. Confirm that every collection source syncs to an agreed time source and record the offset observed at collection. Ask the team to state which clock is authoritative for the case before analysis begins.

Hashes computed after copying

If a file is copied first and hashed later, the hash describes the copy, not the data as it was collected, and any copy error goes undetected. Compute the hash at the moment of acquisition and store it with the item. Verify it again before analysis and after each transfer. DFIR-IRIS logs evidence with SHA-256 verification, which can serve as the place where these values are recorded and rechecked.

Custody records kept in email or chat

When handoffs are described in email threads or chat messages, the custody trail is scattered, editable and hard to prove. A reviewer cannot easily confirm who held an item, when, and for what purpose. Move custody entries into the case system, one record per transfer, with the person, time, location and reason. Restrict edits to the record so changes are visible.

Collection that stops when responders move on

Investigations often end collection once the immediate containment is done, yet offline machines, late alerts and additional hosts can hold relevant data for days. Missing items are then collected inconsistently or not at all. Decide in advance how long collection stays open, who owns it after the first responders rotate off, and how systems that reconnect later are handled. Velociraptor hunts can schedule collection on machines that return to the network.

Procedure never tested before a real incident

A written evidence procedure that no one has run tends to fail at the first real collection: tools are missing permissions, hash commands differ by host, or custody forms are unknown to the people who need them. Run a tabletop or technical exercise that collects a known test artifact end to end, then check that the record, hash and timestamps match what was expected. Repeat the exercise after tool or staffing changes.

How RS.AN-07 maps to SP 800-53, ISO 27001 and SP 800-171

The NIST CSF 2.0 Reference Tool links RS.AN-07 to three SP 800-53 Rev. 5.2.0 controls, AU-7, IR-4 and IR-6, to Annex A control 5.28 of ISO/IEC 27001:2022, and to SP 800-171 Rev. 3 requirements 03.03.06, 03.06.01 and 03.06.02. These links are informative references, not equivalences. They point to controls that address similar outcomes, so a reader can see where a related control already exists. They do not state that satisfying one framework satisfies another, and an assessor will still test each control against its own procedures and its own scope. Before you rely on any link, open the current NIST dataset through the NIST CSF 2.0 Reference Tool export and confirm the mapping version and the exact mapped identifiers against your target framework's current edition.

For an organization preparing one body of evidence for several frameworks, the practical step is to build the evidence once and tag it to each framework's requirement. Collected incident data and metadata, such as data source, collection time, the collector and hash values, can support AU-7 (audit record reduction and report generation), IR-4 (incident handling) and IR-6 (incident reporting) in SP 800-53 terms. The same records are the sort of artifacts an assessor would look at for ISO/IEC 27001 control 5.28 (collection of evidence). For SP 800-171, the mapped requirements sit in the audit and accountability and incident response families. Confirm with your assessor whether they accept a single evidence record mapped to several requirements, and ask them to state which requirement numbers they will test against each record.

Common questions about RS.AN-07 cost, effort and ownership

Does RS.AN-07 require a certification?

No. RS.AN-07 is a Subcategory of the NIST Cybersecurity Framework 2.0, and NIST does not offer certifications or endorsements of CSF-related products, implementations or services. NIST also has no plans to create a conformity assessment program for the CSF. An organization that shows RS.AN-07 is met usually does so through an internal assessment, a customer questionnaire or an independent assessment, and the result is a report or assessment record, not a certificate. If a contract or regulator names a certification body for a related standard, such as ISO/IEC 27001, confirm in writing which standard and which assessor apply, because that is a separate obligation.

How long does it take to implement RS.AN-07, and what drives the time?

The timeline depends mostly on scope and on the logging you already have. Organizations with centralized logs, defined evidence handling and a tested incident response plan usually need less work to show RS.AN-07 than those that collect incident data ad hoc. The main drivers are the number of log sources and endpoints in scope, whether evidence preservation procedures already exist, how many systems must be brought under file integrity monitoring or fleet queries, and how much existing case management must be reconfigured. No fixed duration applies to every environment, so ask for a timeline that lists each source and each procedure in the written scope before work begins.

Can our own team implement RS.AN-07 without outside help?

Often yes, if the team has security engineering capacity, access to the systems in scope and someone who understands chain of custody. The work covers defining what incident data and metadata must be collected, such as data source and collection time, deciding who may collect and handle it, configuring tools to capture it and writing the procedures that prove integrity and provenance. Teams without recent incident handling experience, or those that must test their procedures against an outside assessor's expectations, often bring in an implementation partner to prepare systems and evidence. Your organization keeps ownership of the control either way, and only an independent auditor or assessor issues any report.

What does meeting RS.AN-07 ask of our staff?

It asks for named roles and repeatable habits rather than one large project. Typical responsibilities include an incident lead who approves evidence collection, responders who follow the preservation procedure, and system owners who confirm which logs and hosts are in scope. Staff also need training on how to record source, time and handling steps without altering evidence. Expect recurring effort for reviewing collection results, checking hash verification where it is used, and rehearsing the procedure during exercises. Ask the provider to name the roles it expects your staff to fill and the hours each role requires for ongoing operation.

Do open-source tools remove license costs for RS.AN-07, and what remains?

Open-source tools can remove per-seat or per-endpoint license fees for the tools themselves, but they do not remove cost. Each of the tools that can support this Subcategory has its own license, such as Apache-2.0 OR GPL-2.0-only for osquery, AGPL-3.0-only for Velociraptor, LGPL-3.0-or-later for DFIR-IRIS and GPL-2.0-only for Wazuh, so confirm how your use, modification or hosting triggers obligations under each. Remaining costs include infrastructure to host the tools, installation and integration work, storage for preserved evidence, staff time and any external support you purchase. Ask any provider to separate one-time setup costs from recurring operating costs in the quote.

What will an assessor ask for to test RS.AN-07?

An assessor typically asks to see the written procedure for collecting and preserving incident data, the list of data sources and metadata fields it covers, and examples of records from past or exercise incidents. They may also ask how integrity is verified, how chain of custody is recorded, who can access preserved evidence and how the procedure was tested. Evidence should be dated, attributable and retained under access controls. Confirm with your assessor which format and sample size they expect before you assemble it, because assessment methods vary by engagement and by the framework that references RS.AN-07.

What should we ask a partner to include in a quote for RS.AN-07?

Ask for a written scope that names every system, log source, endpoint group and tool in scope, and a list of deliverables such as the collection procedure, configuration records, evidence templates and test results. The quote should state what is one-time, such as design and installation, and what recurs, such as retainers for upgrades or testing. Ask who performs each task, what the partner will not do, such as issuing an audit report, and what you must provide, such as access, staff time and infrastructure. DeployOpen works from a fixed written scope and does not publish a price list, so a quote follows from that scope.

How DeployOpen prepares RS.AN-07 evidence

DeployOpen works on RS.AN-07 by preparing the systems that collect incident data and metadata and the procedures that preserve their integrity and provenance inside the client's own infrastructure. The organization owns its controls and its incident response process, while an independent auditor or assessor decides whether the evidence meets any framework requirement.

How we scope

Engagements are fixed-scope, with systems, data sources, deliverables and timelines agreed in writing before work starts.
The written scope names which endpoints, servers, cloud logs and case records are in scope for incident data collection.
We confirm with the client which evidence preservation and chain-of-custody procedures already exist and which must be written.

How we build

We configure collection tools such as osquery, Velociraptor and Wazuh file integrity monitoring to gather incident data and metadata.
Collected items are recorded with source and collection time so each piece of incident data carries its provenance.
Case handling in DFIR-IRIS is configured to log evidence with SHA-256 verification and to keep a full audit trail of changes.

How we hand over

We deliver a written description of collection sources, retention settings, access controls and evidence handling steps.
We provide a test record showing that sample incidents produce evidence with hashes, timestamps and custody entries.
We document the evidence package the client can present to its own auditor, with the limits of what the tooling does and does not prove.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover tool upgrades, periodic checks that collection still runs and review of procedure changes.
Any certification or formal attestation is issued only by an independent auditor or certification body chosen by the client.