During a ransomware incident, an analyst isolates a server, captures RAM and disk images, and records each person who handled the media, timestamps, transport method, and hash values. Why must this chain-of-custody documentation be completed?
Select an answer to reveal the explanation.
Short Explanation
Think of chain-of-custody as the evidence's passport: every handoff needs a stamp. If you can't show who held the server image, when, and that it hasn't changed, the whole incident record gets shaky. That's why you document it for review and legal use, not just to keep the storage team happy.
Full Explanation
Chain-of-custody documentation exists to show that incident evidence remained complete, unaltered, and traceable from collection through analysis and presentation. By recording the custodian, timestamp, transfer method, and integrity hash, the analyst creates an auditable record that supports review by internal teams, auditors, insurers, or courts. The mechanism is not convenience; it is legal and forensic defensibility. If the chain is broken, a reviewer may question whether the image still represents the system as it existed during the incident. A change-control record explains authorization for containment but does not prove that collected media remained intact or who handled it after seizure. An alert-generation record shows detection logic and triage context, not the custody path or integrity of the forensic artifacts. A compression or storage note may support repository operations, yet it does not establish that each transfer was controlled, documented, and resistant to tampering. Exam caveat: choose evidence handling, not workflow efficiency, when the scenario emphasizes timestamps, custodians, hashes, and legal review. Operational check: before analysis begins, confirm the evidence log includes collector, date/time, source, destination, transfer method, hash algorithm, and verification result.