Evidence is only as good as the record of how you handled it. A screenshot with no timestamp, a log file no one can prove came from the system it claims, a decision that everyone remembers differently — each is a hole that a later reviewer, an auditor, or a colleague picking up the incident will fall straight through. Evidence notes and chain of custody are the unglamorous discipline that keeps observations trustworthy over time: writing down what you saw and where it came from, capturing it in a form that survives, and recording every hand that touched it along the way.
This guide belongs to the Cybersecurity Encyclopedia’s Triage and Incident Response path and assumes curiosity rather than a forensics lab. The goal is practical: to show how a working note, a screenshot, a file hash, and a clean handoff combine into a record that still means something a week later, when the urgency has faded and someone asks how you know what you claim to know.
What a good evidence note contains
A useful evidence note answers four questions without the reader having to ask them: what was observed, where it came from, when it was recorded, and who recorded it. “Odd login” is not a note. “At 15:42 UTC I exported the identity-provider sign-in log for the account dana-r covering 14:00 to 16:00 UTC; the export shows two sign-ins from a network not previously seen for this user, saved as dana-r-signins.csv” is a note. It fixes the observation in time, names its source, and leaves a trail another responder can walk.
The second discipline inside a note is to keep the observation apart from your reading of it. Write the fact — what the log literally shows — in one place, and your interpretation — what you think it means — clearly labeled in another. When those two blur together, a reasonable guess hardens into an assumed fact by the next morning, and no one can tell which parts of the record were seen and which were surmised. This is the same separation that makes a timeline trustworthy, and the two practices reinforce each other; Incident Timeline Building is the companion piece, since a timeline is really just evidence notes placed in order.
Screenshots, exports, and hashes
Screenshots are the reflex, and they have their place: they capture what a console actually displayed at a moment, including context a raw export might omit. But on their own they are weak evidence — easy to crop, hard to verify, and silent about where they came from. Whenever the underlying system can produce a native export — a log file, a configuration snapshot, a downloaded record — prefer it, and treat the screenshot as a supplement that shows the same fact in context rather than as the primary artifact.
Integrity is the piece beginners most often miss. A cryptographic hash is a fixed-length fingerprint computed from a file’s contents: change a single byte and the fingerprint changes completely. By recording the hash of an exported file next to its name and collection time, you give anyone later the ability to recompute that fingerprint and confirm the file is byte-for-byte the one you collected. You do not need a forensics background to benefit from this; the concept alone — collect the file, note its hash, store both — is what lets an evidence bag survive a skeptical review. Store the artifact and its hash together in a location with restricted, logged access so that “the file has not changed” is something you can demonstrate rather than merely assert.
Toy example
Consider a fictional bakery-supply company, Corvin and Loaf, whose IT lead notices that a finance mailbox has a new forwarding rule sending copies of invoices to an outside address. Rather than clicking around and hoping to remember it later, she opens an evidence note. She writes the observed fact — “a forwarding rule named ‘archive2’ on the accounts-payable mailbox forwards to an external address, seen in the mail admin console at 10:12 UTC” — exports the mail audit log for that mailbox, saves it as a file, and records the file’s hash and the export time beside the filename.
When she hands the incident to a colleague for the afternoon, she does not simply forward a screenshot. She writes a short custody line: “Collected ap-mailbox-audit.csv at 10:20 UTC, hash noted; transferring to sam at 14:00 UTC for review; file stored in the restricted incident folder.” Sam can now confirm the hash matches, read the same log she read, and see exactly when custody changed hands. If this ever needs to be explained to a manager or outside reviewer, the record stands on its own. None of the names, mailboxes, or addresses here are real; the point is the shape of the note and the handoff, not the specifics.
What evidence matters?
Three properties make evidence hold up: provenance, integrity, and continuity. Provenance is knowing precisely where an artifact came from — which system, which account exported it, at what time. Integrity is being able to show it has not changed since collection, which is exactly what a recorded hash provides. Continuity is the unbroken record of who has held the evidence from collection to review, with no gaps where it sat somewhere unaccounted for. Miss any one of the three and a determined reviewer can wave the evidence away.
Notice that the most persuasive evidence is rarely the most dramatic. A crisp screenshot of an alarming screen is worth less than a plain exported log whose source, time, and hash are all recorded, because the export can be independently checked and the screenshot cannot. When you decide what to preserve, imagine the most skeptical reasonable colleague and collect what would satisfy them. That instinct is also what makes evidence useful downstream, when a decision has to be justified — the subject of Response Actions and Approvals .
Chain of custody: who touched what, and when
Chain of custody is simply the continuous, written answer to “who has had this evidence, and when.” Every time an artifact is collected, moved, copied, or handed to another person, the transfer gets a line: what was transferred, from whom, to whom, at what time, and why. The goal is that at no point in the artifact’s life is there an unexplained gap. This is not about distrusting colleagues; it is about being able to show, later, that the evidence in the review is the same evidence that was collected, untouched by anyone with a reason to alter it.
Handoffs are where custody usually breaks. A responder goes off shift and drops a folder of screenshots into a chat with no note; a file is emailed around until no one can say which copy is authoritative. The fix is boring and effective: a single restricted store for incident evidence, access to it that is logged, and a short custody line accompanying every transfer. Clock discipline matters here too, because custody entries are timestamped and a review may need to reconcile them against system logs — Time Synchronization and Log Correlation explains why those times must share a reference. When the moment comes to update stakeholders, do it through defined paths rather than scattering evidence across channels, as Incident Communications Channels describes.
Common mistakes and false positives
The frequent mistakes are all small and all costly: capturing a screenshot instead of an export and losing the provenance; forgetting to record a hash, so integrity cannot be shown; letting evidence live in a personal download folder with no access log; and writing interpretation into a note as though it were observed fact. Each is easy to avoid and hard to repair after the fact, because you usually discover the gap exactly when you need the evidence to be airtight.
False positives deserve the same careful handling as confirmed findings. A forwarding rule that looked malicious may turn out to be a legitimate accounting workflow; an unfamiliar export may have a mundane owner. When that happens, do not quietly delete the note — annotate it with what resolved the question and who confirmed it. A well-preserved false positive still pays off: it leaves behind a documented baseline and a clearer sense of what “normal” looks like, which is precisely what makes the next real alert easier to judge.
What to do next
Practice the small habits before you need them: write the observed fact first, capture native exports over screenshots, record a hash and a collection time, and store artifacts where access is restricted and logged. With those in place, evidence flows cleanly into the rest of the response path — into Incident Timeline Building as ordered entries, into Response Actions and Approvals as the justification for a containment step, and into the After-Action Review as the record everyone trusts. When the evidence concerns new AI tools or connectors, the intake discipline in Secure AI Tool Intake is a useful complement.
During an active incident, resist the urge to improvise: preserve evidence, follow your organization’s response plan, and bring in qualified responders and legal counsel where appropriate. For learning, keep the scenarios invented and rehearse the note-and-handoff rhythm until it feels automatic.
How this guide was made
This page is defensive education, drawn from public incident-response and forensics guidance and illustrated with invented scenarios. It borrows the structure of established frameworks but makes no claim to compliance, certification, legal advice, or incident-response authority, and it keeps every example non-operational so it remains safe to study.
Official references
The NIST SP 800-61 Rev. 3: Incident Response Recommendations sets out the documentation and evidence-handling expectations these notes support, and the NIST Cybersecurity Framework 2.0 places careful record-keeping within the wider respond-and-recover functions. For incidents involving disruptive or extortion-style events, the CISA StopRansomware Guide illustrates why preserved records matter to later analysis. Treat all three as orientation rather than certification.
Related guidebooks
Evidence notes feed directly into Incident Timeline Building and justify the choices in Response Actions and Approvals . When the incident closes, well-kept records make an honest After-Action Review possible.
