Handle incident evidence carefully
Keep incident records traceable with provenance, timestamps, integrity checks, controlled access and a worked evidence register and transfer record.
Good incident records let another authorised person understand where information came from, what happened to it and what it can reasonably establish. A screenshot or exported log without that context may be difficult to interpret later.
This guide introduces record-keeping for an organisation's response team. It does not teach forensic acquisition or establish that material will meet a court's evidential requirements. Where formal investigation, specialist capture or legal proceedings are possible, involve appropriately qualified people early.
Preserve context alongside the data
NIST SP 800-61r3 includes preserving the integrity and provenance of investigation records and collected incident data, and restricting access appropriately. See RS.AN-06 and RS.AN-07. Provenance means the record's origin and history; it is more than the name of the file you downloaded.
For each collection, record the source system, collector, authority, collection time, method, tool or interface, selected time range and relevant filters. Preserve the original timezone and note any conversion used in an analysis timeline.
If an export is incomplete, record that immediately. A query covering one account is not evidence that every account was examined. An empty result can mean no matching activity, missing retention, a failed export or the wrong filter.
Worked evidence register
The following entries are fictional. They illustrate useful fields without containing real account identifiers, personal information or operational secrets.
| Field | Example entry E-001 |
|---|---|
| Incident reference | HWP-IR-07 |
| Description | Cloud administration audit export for the account-setting change under investigation |
| Source | The organisation's cloud-service administration audit facility |
| Collector and authority | Assigned technical responder acting under the incident lead's recorded instruction |
| Collection time | Incident day, 10:05 UTC; original event times retained in the export |
| Method and scope | Export through the authorised interface; account filter and requested start/end times recorded in the collection note |
| Known limits | The export covers the selected account and retained event types; wider activity is not established |
| Stored original | Restricted incident repository, item E-001-original; access limited to the assigned response team |
| Integrity record | Full SHA-256 digest, byte length and collection timestamp recorded in the restricted manifest |
| Working copy | E-001-analysis-01, with a separate record of any sorting, filtering or derived columns |
| Retention decision | Incident owner assigns a review in line with applicable policy, obligations and investigation needs |
Record real values in the actual register. A reference such as “digest stored in manifest” only works if the manifest exists, is protected and can be found by the authorised team.
Understand what an integrity check proves
A cryptographic digest can help compare the bytes of a collected file with a later copy. It does not, by itself, prove that the source system's events were accurate, that the export was complete or that a particular person performed an action.
Record the digest when the authorised collection is made, and compare it as appropriate after copying or transfer. If it differs, preserve both records and investigate the reason. Do not overwrite the expected value merely to make the check pass. An intentional transformation should create a labelled derivative, leaving the original and transformation record available.
Keep a transfer history
| Transfer record | Fictional example |
|---|---|
| Item | E-001-original |
| From and to | Technical responder to the assigned specialist investigator |
| Time | Incident day, 11:20 UTC |
| Purpose | Examine the sequence of account-setting changes |
| Method | Approved restricted transfer channel |
| Checks | Recipient confirms item identity, byte length and matching recorded digest |
| Access change | Recipient added to the incident's authorised evidence-access list |
The register should also explain later disposal or retention changes. A chain of recorded transfers helps accountability; it is not a substitute for an appropriate investigative method.
Avoid changing the thing you are trying to understand
Opening files, changing settings, running tools and restoring services can alter a system or its records. The response team may still need to act urgently to reduce harm. Record the action and reason, and obtain specialist advice about collection order when it matters.
Do not delay necessary safety or containment measures simply to complete a generic checklist. Equally, do not treat routine copying as a full forensic image. NIST's SP 800-86 is an older introductory reference on integrating forensic techniques into response; it expressly is not a complete investigation procedure. Platform-specific acquisition needs current expertise and documentation.
Share the minimum useful information
Separate detailed evidence from the broad incident update. Give decision-makers the conclusions and uncertainty they need, while restricting raw records that may contain personal data, credentials or sensitive system information.
When preparing a report for a wider audience, make a redacted derivative and document what was removed. Check that the redaction actually removes the information from the shared file rather than only hiding its visible display.
At handover, ask whether another authorised responder can locate the original, understand the collection scope, reproduce the analysis and see who changed or transferred the material. Feed missing records into the review action register so evidence gaps become specific improvements.
Sources and further reading
- NIST SP 800-61r3: full publication — checked 2 November 2026
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response (2006) — checked 2 November 2026