RS.AN-06 says actions performed during an investigation are recorded, and the records' integrity and provenance are preserved. If responders change systems during an incident and nobody writes it down, you cannot later tell attacker activity from your own, and the records will not stand up to a customer, insurer or regulator asking questions. No CSF certification exists.
What good looks like
Each responder logs what they did, when, on which system, and why. The log is append only or otherwise protected from edits. One person, the incident lead, owns the documentation and its integrity. Anyone can later see who wrote each entry and where the supporting data came from.
How to implement it
- Open one incident document or ticket per incident, with a timestamped entry format.
- Require every responder to add an entry for each action, including commands run and systems touched.
- Store the log where edits are tracked, such as a ticketing system with history, or write once storage.
- Store a hash of exported evidence files next to the entry so later changes are detectable.
- Name an incident lead who reviews the log for gaps before closing.
- Restrict who can delete or alter incident records.
Evidence to collect
- A completed incident log from a past incident or a tabletop exercise.
- Proof of edit history or write protection.
- The role description of the incident lead.
- Hash values for exported artifacts.
Common gaps
Responders work in chat and nothing is copied out. Entries are edited after the fact. Screenshots replace logs. Nobody checks that the record is complete.
Quick check
What does provenance mean here?
It means you can show where each piece of information came from and who handled it, so the record can be trusted.
Sources
- NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 Reference Tool and implementation examples: https://csrc.nist.gov/Projects/Cybersecurity-Framework/Filters#/csf/filters
