RS.AN-07: Incident data and metadata are collected, and their integrity and provenance are preserved

The rs.an-07: incident data and metadata are collected, and their integrity and provenance are preserved requirement is an operational requirement disguised as a sentence. Collection alone is not enough; you need to prove that evidence is complete, trustworthy, and attributable to a known source. For a CCO or GRC lead, the fastest path is to treat incident evidence like regulated records: define what “must be captured,” control how it is handled, and make integrity verifiable after the fact.

In practice, this requirement touches Security Operations (SIEM/EDR), IT (identity, endpoints, servers), Cloud (control-plane logs), and Legal/HR (internal investigations). It also touches third parties because you may need provider logs, ticketing records, or forensics artifacts to establish what happened. If you cannot prove provenance, you create decision risk: wrong root-cause, wrong containment, weak disclosures, and failed recovery prioritization.

This page gives requirement-level implementation guidance: scope, control design, step-by-step execution, evidence to retain, audit questions, and common mistakes. Sources: NIST CSWP 29 and NIST CSF 1.1 to 2.0 Core Transition Changes. ¹

Regulatory text

Requirement text (RS.AN-07): “Incident data and metadata are collected, and their integrity and provenance are preserved.” ¹

What the operator must do:

1. Collect incident data relevant to detection, analysis, containment, eradication, and recovery (for example: alerts, logs, endpoint artifacts, network telemetry, tickets, communications).
2. Collect incident metadata that explains and supports trust in the data (for example: timestamps, time source, system identifiers, user/service account context, collection method/tool, analyst actions, transformation history).
3. Preserve integrity so evidence remains tamper-evident and defensible (for example: hashing, immutable storage, restricted write permissions, audit logs).
4. Preserve provenance so you can show where evidence came from and how it was handled (for example: chain-of-custody records, source system attestation, tool configuration state, export receipts).

Plain-English interpretation

You must be able to answer, confidently and repeatedly:

• What evidence did we capture for this incident?
• Where did each artifact come from (system, account, sensor, tenant, region)?
• When and how was it collected (and by whom or what automation)?
• Has it been altered (and can we prove it hasn’t)?
• Can a third party reviewer reproduce or validate key facts?

Treat incident evidence like you would treat financial records during an audit: consistent collection, controlled handling, and a clear record trail.

Who it applies to

Entity scope: Any organization running a cybersecurity program that investigates security incidents, including regulated enterprises, critical infrastructure, SaaS providers, and organizations with material security reporting obligations. ²

Operational scope (where it shows up):

• SOC / IR team: triage, case management, evidence capture, analysis notes.
• IT Ops / Cloud Ops: log sources (IdP, EDR, firewalls, cloud audit logs), time sync, retention.
• GRC / Compliance / Internal Audit: control ownership, evidence of operation, policy and procedure mapping.
• Legal / Privacy: preservation for investigations, legal hold workflow where applicable.
• Third parties: managed detection and response (MDR), cloud providers, SaaS apps that hold relevant logs and tickets.

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

1) Define your “minimum incident evidence set”

Create a short standard that says what must be captured for any confirmed incident and for any high-severity suspected incident. Keep it implementable.

Baseline evidence categories (example):

• Detection artifacts: SIEM alert, correlation rule ID/version, triggering events, alert timestamps, detection source.
• Identity context: user IDs, device IDs, role/group membership, IdP events, MFA events, service accounts.
• Endpoint and server artifacts: EDR telemetry, process tree, file hashes, persistence indicators, isolation actions.
• Network and cloud telemetry: firewall/proxy logs, DNS, flow logs, cloud audit logs (control plane), storage access logs.
• Case management records: incident ticket, timeline, actions taken, approvals, communications.
• Containment/eradication proof: change records, configuration diffs, patches, blocked indicators, key rotations.

Metadata to require for each artifact:

• Source system name/tenant/account, region, hostname/resource ID
• Collection method (API export, agent capture, screenshot, manual note)
• Collector identity (automation identity or analyst)
• Time captured and time zone, plus time source (NTP reference if applicable)
• Hash/signature where feasible, and storage location pointer
• Handling history (transfers, conversions, redactions)

2) Map sources to collectors and owners

Build a simple matrix and assign ownership. This is where many programs fail because “logs exist” but nobody owns their evidentiary quality.

Evidence source map (minimum fields):

• Source (e.g., EDR, IdP, SaaS audit logs, cloud audit)
• Collection mechanism (streaming to SIEM, scheduled export, on-demand)
• Retention location(s)
• Integrity control (hashing, immutability, access restrictions)
• Control owner (named role)
• Verification check (what you test to confirm it’s working)

Daydream (or your GRC system) fits naturally here as the system of record to map RS.AN-07 to the policy, procedure, control owner, and recurring evidence collection so audits do not become a scramble. ¹

3) Implement integrity protections (tamper-evident by design)

Pick controls that match how evidence is generated and stored:

Common integrity patterns:

• Immutable/WORM storage for exported logs and forensics packages where your platform supports it.
• Hashing at capture time for discrete artifacts (disk images, memory dumps, file collections, exported log bundles). Store hashes in a separate controlled system (case system + secure repository).
• Strict write permissions: ingestion pipelines write; analysts read. Break-glass write requires approval and is logged.
• Centralized audit logging for the evidence repository itself: access, export, deletion attempts, permission changes.
• Time integrity: consistent time sync for systems that produce evidence; document time drift handling in IR procedures.

4) Implement provenance (chain-of-custody that holds up under review)

Provenance is the “story of the evidence” with supporting records.

Minimum chain-of-custody fields:

• Artifact ID and description
• Source system and original location/path/query parameters
• Collector (person or automation identity)
• Collection timestamp and method/tool
• Hash/signature (if used) and verification step
• Storage destination and access classification
• Transfer events (who, when, how, why), including third-party transfers
• Redactions performed (what, why, by whom), with a preserved original where permitted

Operational tip: make this a required template inside your incident ticketing system so it happens during the incident, not after.

5) Standardize evidence handling procedures (and make them runnable)

Write short, role-specific procedures:

• SOC playbook addendum: “Evidence to capture for X incident types” (phishing, ransomware, cloud key compromise, insider, web app attack).
• Forensics procedure: “How to package, hash, store, and document artifacts.”
• Third-party evidence request runbook: “How to request logs from cloud/SaaS/MDR, required metadata, and how to store receipts.”

6) Validate with recurring tests

Do lightweight checks that prove the control operates:

• Pull a sample incident and confirm the minimum evidence set is present.
• Verify a stored artifact’s hash matches the recorded value (where hashing is used).
• Confirm repository access logs show who accessed and exported evidence.
• Confirm log sources are still streaming and that parsing/normalization did not drop key fields.

Required evidence and artifacts to retain

Auditors and examiners usually want both design artifacts and operational artifacts.

Design evidence

• Incident Response Policy and Evidence Handling Standard referencing integrity and provenance requirements (RS.AN-07 mapping). ²
• Evidence source inventory and ownership matrix.
• Chain-of-custody template and instructions.
• Data retention standard for incident evidence repositories.
• Tool configurations that support integrity/provenance (repository settings, SIEM ingestion configs, access control model).

Operational evidence

• Completed incident tickets showing: timeline, actions, evidence list, and chain-of-custody entries.
• Export receipts and API query details for collected logs (where applicable).
• Hash manifests and verification records for discrete artifacts (where used).
• Access logs for evidence repositories and case management systems.
• Proof of periodic validation (sampling logs, test results, exceptions and remediation).

Common exam/audit questions and hangups

Expect these questions because they test whether you can prove trust:

1. Show one incident end-to-end: What did you collect, where is it stored, and who accessed it?
2. How do you prevent tampering or silent deletion? What stops an admin or analyst from modifying evidence?
3. How do you establish provenance for cloud/SaaS logs? Can you show the tenant/account, API method, and query used?
4. How do you handle screenshots and analyst notes? Are they time-stamped and attributable, or floating in chat threads?
5. What is your retention approach for incident evidence? Is it consistent across repositories?

Hangup to plan for: teams often retain “some logs” but cannot show the metadata that explains context (identity, time source, tool version, query parameters). That gap undermines the analysis record even if raw logs exist.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails RS.AN-07	Avoid it by
Treating SIEM retention as “incident evidence retention”	SIEM data may be filtered, normalized, or incomplete for forensics	Preserve raw or export bundles for material incidents, with provenance and integrity controls
No standard artifact naming/IDs	You cannot link ticket narrative to stored evidence	Use a consistent artifact ID scheme and require it in the ticket
Chain of custody done after the incident	You miss handling steps and timestamps	Embed chain-of-custody fields into the incident workflow template
Analysts share evidence in chat/email	Loses access control, audit trail, and retention	Centralize in an evidence repository and restrict exports
Admins have broad write/delete rights	Integrity is not defensible	Separate duties, enforce approvals, and log all privileged actions

Enforcement context and risk implications

No public enforcement case sources were provided in the supplied catalog for this requirement, so this page does not cite specific enforcement actions.

Operationally, weak integrity and provenance increases:

• Investigation risk: wrong root-cause or missed scope because evidence is incomplete or altered.
• Reporting risk: you cannot substantiate claims made to executives, customers, or regulators.
• Litigation and insurance friction: lack of defensible chain-of-custody complicates claims and disputes.
• Third-party risk: you depend on external logs without a repeatable method to request, verify, and store them.

Practical 30/60/90-day execution plan

First 30 days (stabilize the basics)

• Assign a single control owner for RS.AN-07 and document RACI across SOC, IR, IT, and Legal. ²
• Publish the minimum incident evidence set and chain-of-custody template in the incident ticketing system.
• Identify top evidence sources (EDR, IdP, SIEM, cloud audit logs, case management) and document collection methods and retention locations.
• Lock down evidence storage access: define roles, require MFA, enable access logging, and restrict delete permissions.

Next 60 days (make it repeatable)

• Implement hashing/manifests for discrete artifacts and add a required “hash verified” step to the workflow where feasible.
• Configure immutability/WORM controls for the evidence repository where your platform supports it.
• Add third-party evidence request runbook and standard request language (required metadata, format, timestamps, tenant/account identifiers).
• Run a tabletop that includes evidence handling: prove you can reconstruct the incident timeline from preserved artifacts.

Next 90 days (prove operating effectiveness)

• Do recurring sampling: select closed incidents and check completeness of evidence set, presence of provenance fields, and integrity controls.
• Build a dashboard or recurring report: missing evidence fields, missing exports, access anomalies in the evidence repository.
• Formalize retention and disposition rules for incident evidence, including escalation to legal hold where applicable.
• In Daydream (or your GRC system), attach recurring evidence (samples, screenshots, reports) to the RS.AN-07 control record so audits run off artifacts, not memory. ¹

Frequently Asked Questions

What counts as “incident metadata” for RS.AN-07?

Metadata is the context that makes evidence trustworthy: source system identifiers, timestamps and time zone, collection method, collector identity, and handling history. If you cannot explain where an artifact came from and how it was captured, it is weak evidence under RS.AN-07. ²

Do we need hashing for every log record?

You don’t need to hash every individual event to meet the intent; you need tamper-evident integrity for the incident evidence you preserve. Many teams hash exported bundles or discrete forensic packages and rely on repository immutability plus access logging for streamed logs.

How do we handle evidence collected by a third party (MDR, IR firm, cloud provider)?

Require provenance in your request: tenant/account, query parameters, time range, export method, and the third party contact who produced it. Store the request, response, and any export receipts alongside the artifacts in your evidence repository.

Are screenshots acceptable incident evidence?

Screenshots can support triage, but they are rarely sufficient alone because they often lack provenance and can be edited. If you keep screenshots, store them with capture time, collector identity, the source URL/path, and a link to the underlying exported data where possible.

Where should evidence live: ticketing system, SIEM, or a separate repository?

Keep the ticketing system as the index (what exists, where it is, who approved actions) and store artifacts in a controlled evidence repository with strong access logging and retention controls. Your SIEM remains a primary source but should not be the only preserved record for material incidents.

What’s the fastest way to get audit-ready for RS.AN-07?

Standardize the minimum evidence set, embed chain-of-custody fields into the incident workflow, and retain a small set of closed incidents as “golden samples” with complete artifacts and access logs. Then map the requirement to an owner and recurring evidence collection in your GRC system. ²

Footnotes

1. NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes

2. NIST CSWP 29