RS.AN-06: Actions performed during an investigation are recorded, and the records’ integrity and provenance are preserved

RS.AN-06 requires you to keep a tamper-evident, attributable record of what your responders did during an incident investigation, when they did it, what evidence they touched, and why. Operationalize it by standardizing investigation logging, restricting and auditing access to evidence, and preserving chain-of-custody and system-of-record integrity for every case ¹.

Key takeaways:

• Record every investigation action in a consistent system of record, not in ad hoc chat threads or personal notes ¹.
• Preserve integrity with access controls, immutable/auditable logs, and controlled evidence handling ¹.
• Preserve provenance by documenting who collected evidence, from where, how it was validated, and how it moved through the investigation ¹.

“Good investigation” is not the same as “defensible investigation.” RS.AN-06 is the difference. The requirement focuses on two outcomes: (1) you can reconstruct the investigation timeline and decision-making, and (2) you can show that the records and evidence were not altered and can be traced to their origin ¹. For a Compliance Officer, CCO, or GRC lead, this is less about deploying a new tool and more about making your incident response (IR) work auditable.

Most breakdowns happen in predictable places: responders capture actions in Slack, analysts copy artifacts to desktops, and “evidence” gets emailed around. Later, leadership asks what happened, internal audit asks for the trail, counsel asks for defensibility, and the team cannot prove who did what or whether the evidence stayed intact. RS.AN-06 pushes you toward a consistent investigation case file, strict evidence handling, and a log architecture that supports integrity and provenance ¹.

This page gives requirement-level implementation guidance you can assign to control owners, test in audit, and run repeatedly for every investigation.

Regulatory text

Requirement (RS.AN-06): “Actions performed during an investigation are recorded, and the records’ integrity and provenance are preserved” ².

What the operator must do:
You must (a) record investigation actions in a way that supports later reconstruction, and (b) protect those records so you can demonstrate they are complete, trustworthy, and attributable to specific people, systems, and sources ¹. In practice, that means you maintain an investigation system of record, enforce evidence-handling controls, and retain auditable metadata about collection and custody (provenance).

Plain-English interpretation of the requirement

RS.AN-06 expects you to answer four questions for any investigation, without guessing:

1. What happened during the investigation? A timeline of actions and decisions.
2. Who did each action? Named individuals or roles tied to authenticated identities.
3. What evidence did you rely on? Specific artifacts with references and hashes where appropriate.
4. Can you prove the record is trustworthy? Controls that prevent or expose tampering and show origin and custody ¹.

If your investigation record is scattered across email, chat, and shared drives, you will struggle to prove integrity and provenance.

Who it applies to (entity and operational context)

Entities: Any organization operating a cybersecurity program and performing security investigations ¹.
Operational contexts where RS.AN-06 should be applied:

• Incident response investigations (confirmed incidents and suspected incidents).
• Security operations investigations (alerts, suspicious activity, triage that becomes a case).
• Threat hunting and forensic reviews that may later support disciplinary action, litigation, or regulator inquiries.
• Third party-related investigations (a vendor breach affecting you, or your compromise affecting customers/partners). “Third party” evidence exchange increases provenance risk because artifacts move across organizational boundaries.

Functions involved:

• Security Operations Center (SOC) / IR team (primary doers)
• IT and Cloud Ops (system changes, containment, restoration actions)
• Legal and Privacy (holds, privilege decisions, breach notification inputs)
• GRC / Compliance (control design, audit readiness, evidence retention)
• HR (if insider activity is suspected)

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

Use this as an implementation checklist you can assign and test.

1) Define the investigation “system of record”

Pick a primary case management location where every investigation is logged. Common choices: an IR/ticketing platform, a dedicated case management tool, or a tightly controlled GRC workflow. The key is consistency: one place to reconstruct the record ¹.

Minimum required fields for every case record:

• Case ID, severity, date/time opened/closed
• Scope (systems, accounts, data types)
• Investigators and approvers (role + named identity)
• Action log entries (timestamp, actor, action, rationale, outcome)
• Evidence register (artifact ID, source, collection method, storage location, hash/validation notes)
• Decision log (containment choices, escalation points, legal/privacy involvement)

2) Standardize what “record an action” means

Create an investigation logging procedure with “must log” triggers:

• Any access to suspected systems outside normal admin activity
• Any command execution intended to confirm/deny compromise
• Any evidence acquisition (disk, memory, logs, SaaS exports)
• Any containment/eradication action (disable account, isolate host, block IOC)
• Any data handling decision (copying files, sharing artifacts with a third party) ¹

Define acceptable logging formats:

• Structured notes in the case tool (preferred)
• Attachments with controlled metadata (screenshots, exports) linked to the case
• Automated action capture (SOAR run history, EDR response audit trail) referenced by immutable IDs

3) Preserve integrity of the records (tamper-evident and access-controlled)

You need controls that either prevent alteration or make alteration visible. Implement:

• Role-based access control for case files and evidence repositories (least privilege)
• MFA for systems that store case records
• Audit logging on the case system and evidence storage (who viewed, edited, exported)
• Write-once or immutable storage settings for key evidence and final reports where feasible
• A defined “record finalization” step: once the incident report is approved, changes require a controlled amendment with rationale and approver identity ¹

Operational note: if your case tool allows silent edits to prior entries, auditors will question integrity. Prefer append-only activity logs or systems that keep revision history.

4) Preserve provenance (chain-of-custody and origin detail)

Provenance is your ability to show origin and handling. Implement an evidence register and chain-of-custody workflow:

• Evidence intake form: who collected it, from what system, how, when, and under what authority/ticket
• Validation: note hashes/checksums when practical, export IDs for SaaS logs, and the query parameters used to generate the export
• Storage: evidence location, encryption, retention label
• Transfers: if evidence is shared internally or with a third party (forensics firm, outside counsel, affected partner), record recipient, method, and authorization ¹

Where teams get stuck: SaaS evidence. For cloud and SaaS, provenance often depends on documenting the admin console path/API endpoint, the account used, and the export configuration.

5) Tie investigation actions to identity and authorization

Provenance fails if you cannot map actions to a person and their authority. Require:

• Named assignment of investigator-on-call and incident commander for each case
• Logged approvals for high-impact actions (e.g., shutting down production services, deleting malicious artifacts, resetting keys broadly)
• Documented escalation criteria and who authorized escalation ¹

6) Operationalize retention and legal holds

Define retention for:

• Case records (notes, decision log, communications captured in the case tool)
• Evidence artifacts (exports, images, samples)
• Supporting system logs relevant to the case (EDR telemetry references, SIEM searches)

Add a legal hold trigger workflow so Legal can instruct preservation without responders improvising. RS.AN-06 does not set retention durations by itself; you set them based on your risk, contracts, and other obligations, then enforce them consistently ¹.

7) Make it auditable: map to policy, procedure, owner, recurring evidence

Document a control statement and assign ownership:

• Policy: Incident Response / Investigation Management
• Procedure: Investigation logging + evidence handling + chain-of-custody
• Control owner: Head of IR/SOC with GRC oversight
• Recurring evidence: periodic sampling of closed cases to confirm required fields, access logs, and evidence register completeness ²

If you use Daydream, the clean implementation pattern is to map RS.AN-06 to a named control owner, attach the procedure, and automate recurring evidence requests (for example: quarterly case-file samples, system audit logs, and evidence register exports) so audits do not turn into manual fire drills.

Required evidence and artifacts to retain

Maintain a defensible “RS.AN-06 evidence pack” per investigation plus program-level evidence.

Per-investigation artifacts

• Case record export or immutable snapshot (with timestamps and assigned roles)
• Action log (append-only history or revision history enabled)
• Evidence register with collection metadata and custody trail
• Copies/links to key artifacts (logs, EDR reports, SaaS exports) with source references
• Approval/decision records (containment, eradication, restoration)
• Post-incident report and documented amendments, if any ¹

Program-level artifacts (proves the control operates)

• IR investigation logging procedure and evidence handling SOP
• Access control policy for the case tool and evidence repository
• Audit log settings/configuration evidence for those systems
• Training or job aids for responders (what must be logged, where)
• Periodic QA results: sampling checklist showing completeness and integrity checks ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me two closed investigations and the complete action timeline.”
• “Can an analyst edit prior entries without leaving a trace? Show revision history.”
• “How do you prove this export came from that SaaS tenant and was not modified?”
• “Who had access to the evidence folder during the incident window?”
• “How do you control and document evidence shared with a third party forensics provider?” ¹

Hangups auditors see:

• No consistent system of record.
• Action logs exist but do not tie to authenticated identities.
• Evidence stored in shared drives without access logs.
• “Final report” exists, but no supporting provenance for underlying artifacts.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails RS.AN-06	Fix
Keeping investigation notes in chat/email	No reliable integrity, poor provenance	Require case-tool logging and attach chat exports only as supporting artifacts 1
Allowing silent edits to timelines	Integrity cannot be demonstrated	Use append-only logs or enable immutable audit trails and revision history 1
Copying evidence to laptops	Provenance breaks; tampering risk	Central evidence repository with controlled access and documented transfers 1
No evidence register	You cannot enumerate what you relied on	Maintain an evidence register with source, collector, time, method, and storage reference 1
Ad hoc third party sharing	Custody and authorization unclear	Require documented approvals and record transfer details in the evidence register 1

Risk implications (why operators care)

RS.AN-06 reduces three practical risks:

• Regulatory and audit defensibility risk: you cannot evidence that investigations were performed competently and consistently without records ¹.
• Legal risk: if an event escalates to litigation, poorly controlled records create credibility challenges.
• Operational risk: responders repeat work when prior actions and rationale are not recorded; containment actions become harder to validate.

Practical 30/60/90-day execution plan

Use phases to move fast without waiting for a platform rebuild.

First 30 days (stabilize)

• Choose and declare the investigation system of record.
• Publish a one-page “minimum logging standard” and evidence register template.
• Lock down access to evidence storage; turn on audit logs where available ¹.
• Start sampling: review a small set of recent cases for missing timeline entries and missing provenance.

Days 31–60 (make it repeatable)

• Update IR procedures: action logging triggers, evidence intake steps, chain-of-custody.
• Configure the case tool for required fields and revision history.
• Train responders using real examples of “good vs. weak” entries.
• Establish approval workflow for high-impact containment actions and third party evidence sharing ¹.

Days 61–90 (make it auditable)

• Create a recurring control test: periodic closed-case reviews using a checklist mapped to RS.AN-06.
• Produce program-level evidence: access control reviews, audit log verification, and case sampling results.
• Add metrics that do not require statistics: pass/fail completeness, “exceptions with remediation,” and time-bound corrective actions.
• If using Daydream, map RS.AN-06 to the control owner and automate recurring evidence collection for case samples and system audit logs so you can answer audits with a consistent packet ¹.

Frequently Asked Questions

Do we need a dedicated forensics tool to meet RS.AN-06?

No. RS.AN-06 requires recorded actions plus preserved integrity and provenance, which you can meet with a controlled case system and evidence repository if they provide access controls and auditability ¹.

What counts as “provenance” for cloud/SaaS log exports?

Record the tenant/account used, the export method (console path or API), query parameters or filters, export time, and where the file is stored. If you can, record an export ID or hash to help demonstrate integrity ¹.

Can we keep investigation artifacts in a shared drive?

You can, but only if access is restricted, changes are logged, and you can show who accessed or modified artifacts. Without audit logs and controlled permissions, integrity and provenance are hard to defend ¹.

How do we handle investigations that involve a third party (vendor) incident?

Create an evidence transfer entry each time you receive or send artifacts: sender/recipient, method, authorization, and what was transferred. Keep the third party communication summary in the case record so the investigation timeline is complete ¹.

What should be immutable: raw evidence, the report, or both?

Prioritize immutability for raw evidence and the final approved report, then enforce controlled amendments for any post-approval changes. If full immutability is not feasible, require audit trails that show edits and who made them ¹.

Who should own RS.AN-06 operationally: SOC or GRC?

The SOC/IR leader should own execution because they run investigations; GRC should own oversight, testing, and audit readiness artifacts. Split the RACI so investigation work stays fast and evidence stays consistent ¹.

Footnotes

1. NIST CSWP 29

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