1. Purpose
The Chain-of-Custody Form is used to maintain a traceable record of the possession, transfer, handling, storage, and disposition of evidence.
It establishes:
Who had the evidence → When they had it → Why they had it → What they did with it → Where it went next → Whether its integrity was maintained.
The form should be used when evidence requires formal handling controls, particularly for sensitive incident investigations, forensic evidence, legal matters, customer-impacting incidents, regulatory investigations, or evidence transferred to third parties.
ISO/IEC 27001 does not prescribe a specific chain-of-custody form. The organization should determine when formal evidence custody controls are necessary based on risk, legal requirements, contractual obligations, investigation requirements, and the nature of the evidence.
2. Scope
This form may be used for:
- Security incidents
- Data breaches
- Account compromise
- Cloud compromise
- Malware and ransomware investigations
- Unauthorized access
- Insider investigations
- Supplier incidents
- Fraud investigations
- Vulnerability exploitation
- Production security incidents
- CI/CD compromise
- Digital forensic investigations
- Legal investigations
- Regulatory investigations
- Customer-impacting investigations
- Evidence transferred to external investigators
- Evidence provided to legal counsel
- Evidence provided to insurers
- Evidence provided to law enforcement where applicable
3. When Chain of Custody Is Required
Not every piece of security evidence requires a formal chain-of-custody process.
Consider using formal chain-of-custody controls when:
- Evidence may be used in legal proceedings.
- Evidence may be provided to regulators.
- Evidence is transferred outside the organization.
- Evidence is highly sensitive.
- Evidence could materially affect an investigation conclusion.
- Evidence is forensic in nature.
- Evidence could be challenged regarding authenticity or integrity.
- Evidence is transferred between multiple investigators.
- Evidence is stored on removable or physical media.
- Customer or third-party evidence is involved.
- An insurance or contractual investigation requires traceability.
For routine internal evidence, the Evidence Register and access controls may be sufficient if the organization’s procedure permits this.
4. Chain-of-Custody Principle
The chain of custody should establish:
Evidence Identified → Evidence Collected → Evidence Secured → Evidence Transferred → Evidence Received → Evidence Accessed/Handled → Evidence Transferred Again → Evidence Returned/Archived → Evidence Disposed
Every significant custody change should be recorded.
5. Chain-of-Custody Record Information
Evidence Identification
| Field | Details |
|---|---|
| Evidence ID | EV-YYYY-0001 |
| Incident ID | INC-YYYY-0001 |
| Investigation ID | INV-YYYY-0001 |
| Event ID | SE-YYYY-0001 |
| Evidence Title | Description |
| Evidence Type | File/Log/Image/Device/Export/etc. |
| Evidence Category | Cloud/Endpoint/Network/etc. |
| Classification | Internal/Confidential/Restricted |
| Priority | Critical/High/Medium/Low |
6. Original Evidence Details
Record enough information to identify the original evidence.
| Field | Details |
|---|---|
| Original Source | System/application/device |
| Source Owner | Responsible person/team |
| Original Location | Original storage location |
| Hostname/Resource | Relevant resource |
| Account/Tenant | Relevant account |
| Environment | Production/Staging/Development |
| Region | Where applicable |
| Evidence Filename | Original filename |
| File Type | JSON/CSV/EML/IMG/etc. |
| Size | File/media size |
| Record Count | Where applicable |
| Date/Time Created | Source timestamp |
| Evidence Period | Start/end |
| Time Zone | UTC/IST/etc. |
7. Integrity Information
Where integrity verification is appropriate, record:
| Field | Details |
|---|---|
| Integrity Required | Yes/No |
| Hash Algorithm | SHA-256/SHA-512/etc. |
| Original Hash | Hash calculated at collection |
| Verification Hash | Hash calculated during verification |
| Hash Match | Yes/No |
| Verified By | Reviewer |
| Verification Date/Time | Date/time |
| Integrity Notes | Additional information |
Important
Do not place:
- Passwords
- API keys
- Private keys
- Access tokens
- MFA recovery codes
- Secrets
into the Chain-of-Custody Form.
If evidence contains secrets, record only that sensitive credentials/secrets are present and protect the underlying evidence accordingly.
8. Initial Custody Record
The first custody record establishes who collected or received the evidence.
| Field | Details |
|---|---|
| Evidence ID | EV-2026-0042 |
| Released By | Person/team |
| Received By | Investigator |
| Release Date/Time | Date/time |
| Receipt Date/Time | Date/time |
| Location | Secure repository/location |
| Purpose | Incident investigation |
| Condition | Original/working copy/sealed |
| Integrity Verified | Yes/No |
| Signature/Approval | Required where applicable |
9. Custody Transfer Log
Every significant transfer should be recorded.
| Transfer # | Date/Time | Released By | Received By | From | To | Purpose | Condition | Integrity Verified | Signature |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 30-Sep-2026 10:45 | Security Engineer | Investigator | AWS evidence repository | Investigation repository | Investigation | Unchanged | Yes | Recorded |
| 2 | 30-Sep-2026 14:20 | Investigator | Security Lead | Investigation repository | Restricted review repository | Review | Unchanged | Yes | Recorded |
| 3 | 01-Oct-2026 11:00 | Security Lead | Legal Counsel | Restricted repository | Approved legal repository | Legal review | Unchanged | Yes | Recorded |
The transfer log should continue until the evidence is returned, archived, or disposed of.
10. Transfer Information
For every transfer, record:
- Evidence ID
- Incident ID
- Date/time released
- Date/time received
- Sender
- Recipient
- Sender role
- Recipient role
- Source location
- Destination location
- Reason for transfer
- Transfer method
- Evidence condition
- Integrity verification
- Authorization
- Receipt confirmation
11. Transfer Methods
Approved transfer methods may include:
- Controlled internal repository
- Encrypted file transfer
- Secure evidence platform
- Encrypted removable media
- Approved secure cloud storage
- Secure legal/forensic exchange platform
- Physical handover under controlled conditions
Do not use uncontrolled channels such as:
- Personal email
- Personal cloud storage
- Consumer file-sharing accounts
- Public messaging platforms
- Unapproved USB devices
unless explicitly authorized under an appropriate exception process.
12. Physical Evidence
For physical evidence, record additional details.
Examples:
- Laptop
- Mobile phone
- USB device
- Server media
- Security appliance
- Hardware device
- Printed records
- Physical access-control media
Record:
| Field | Example |
|---|---|
| Device Type | Laptop |
| Manufacturer | Example manufacturer |
| Model | Example model |
| Serial Number | Recorded |
| Asset ID | AST-2026-0012 |
| Condition | Powered off |
| Packaging | Tamper-evident packaging |
| Seal Number | SEC-00482 |
| Storage Location | Restricted evidence locker |
| Custodian | Security Investigator |
Photographs may be retained where appropriate to document physical condition at collection.
13. Digital Evidence
For digital evidence, record:
- Evidence ID
- Source system
- Host/resource
- Account
- Environment
- Original location
- Collection method
- Tool
- Tool version where relevant
- Date/time
- Time zone
- File name
- File size
- Hash
- Storage location
- Working-copy information
The original evidence should be preserved where required, while analysis should preferably be performed against an authorized working copy.
14. Cloud Evidence
Cloud evidence requires additional attention because evidence may be:
- Generated dynamically.
- Distributed across services.
- Retained for a limited period.
- Changed by normal system operations.
- Accessible through administrative APIs.
- Located in different regions.
- Subject to provider retention policies.
AWS Example
For an AWS account compromise, evidence may include:
- AWS CloudTrail
- IAM activity
- GuardDuty findings
- Security Hub findings
- S3 access records
- VPC Flow Logs
- WAF logs
- EC2 activity
- RDS audit records
- KMS activity
- Secrets Manager access
- CI/CD activity
Record the relevant:
AWS Account → Region → Service → Resource → Time Period → Collection Method → Evidence ID → Hash/Integrity → Storage Location
15. Example: AWS CloudTrail Evidence
Evidence
EV-2026-0042
Description
CloudTrail activity covering the period surrounding a suspected AWS administrator account compromise.
Source
AWS CloudTrail
Collection
Exported using an approved AWS security process.
Time Period
30 September 2026 00:00 UTC – 30 September 2026 12:00 UTC
Purpose
Determine:
- Authentication activity
- IAM changes
- Role creation
- Policy changes
- S3 access
- Security-group modifications
- Other unauthorized API activity
Custody
AWS CloudTrail → Security Engineer → Restricted Evidence Repository → Incident Investigator → Security Lead
Each custody transition is recorded in the transfer log.
16. Evidence Packaging
Where multiple related files are transferred together, create an evidence package.
Example:
EVPKG-2026-0017
Containing:
- EV-2026-0042 — CloudTrail
- EV-2026-0043 — IAM policy history
- EV-2026-0044 — GuardDuty finding
- EV-2026-0045 — S3 access evidence
The package should have:
- Package ID
- List of evidence IDs
- Package creation date/time
- Creator
- Hash where appropriate
- Storage location
- Transfer history
This makes large investigations easier to manage.
17. Evidence Condition
Record the condition of evidence at every relevant transfer.
Use controlled values such as:
| Condition | Meaning |
|---|---|
| Original | Original evidence preserved |
| Working Copy | Authorized copy used for analysis |
| Sealed | Evidence packaged/sealed |
| Unchanged | Integrity verified and unchanged |
| Modified | Evidence changed — document why |
| Damaged | Evidence damaged |
| Incomplete | Evidence appears incomplete |
| Unknown | Condition cannot be established |
If evidence appears altered or corrupted, immediately document the condition and investigate the cause.
18. Integrity Verification During Transfer
Where integrity controls are required:
- Calculate or record the original hash.
- Transfer the evidence through an approved method.
- Calculate the receiving hash.
- Compare the values.
- Record the result.
- Investigate any mismatch.
Example
Original SHA-256: Recorded in controlled record
Receiving SHA-256: Same
Result: Integrity verified
If hashes do not match:
Do not silently replace the evidence.
Record the discrepancy, preserve both versions where appropriate, determine the cause, and escalate for investigation.
19. Evidence Access During Custody
Access should be limited to authorized personnel.
Record access where required:
| Date/Time | Evidence ID | Person | Purpose | Action | Result |
|---|---|---|---|---|---|
| 30-Sep-2026 13:10 | EV-2026-0042 | Investigator | Timeline analysis | Viewed | Completed |
| 30-Sep-2026 14:05 | EV-2026-0042 | Security Lead | Investigation review | Reviewed | Completed |
Access should follow least-privilege and need-to-know principles.
20. Third-Party Evidence
Evidence may be received from:
- Cloud providers
- SaaS providers
- Managed security providers
- Customers
- Suppliers
- External investigators
- Penetration testers
- Legal counsel
- Insurance providers
- Law enforcement where applicable
For third-party evidence, record:
- Provider
- Contact
- Date received
- Method received
- Evidence description
- Provider’s evidence reference
- Integrity information provided
- Original source
- Restrictions
- Confidentiality requirements
- Storage location
- Internal Evidence ID
Example:
AWS Provider Reference: CASE-XXXX
Internal Evidence ID: EV-2026-0051
This allows the organization’s internal investigation record to remain linked to the external provider record.
21. Evidence Receipt Confirmation
The receiving person should confirm:
☐ Correct Evidence ID received
☐ Correct evidence package received
☐ Source identified
☐ Date/time recorded
☐ Transfer method recorded
☐ Evidence condition checked
☐ Integrity checked where required
☐ Storage location confirmed
☐ Access restrictions applied
☐ Receipt recorded
22. Lost, Damaged, or Missing Evidence
If evidence is lost, damaged, corrupted, or cannot be located:
- Record the event immediately.
- Do not alter the original record.
- Identify the last known custodian.
- Review access and transfer records.
- Determine potential impact.
- Attempt recovery where appropriate.
- Determine whether another copy exists.
- Document evidence limitations.
- Escalate according to incident/investigation requirements.
- Record corrective action if necessary.
Example
Evidence: EV-2026-0031
Issue: Original endpoint image unavailable.
Impact: Full forensic review cannot be completed.
Alternative: EDR telemetry and authentication logs available.
Decision: Investigation proceeds with documented evidence limitation.
23. Evidence Copy Management
When a copy is created:
- Assign a relationship to the original Evidence ID.
- Identify it as a working copy.
- Record creation date/time.
- Record who created it.
- Record purpose.
- Preserve the original where required.
- Apply appropriate integrity controls.
Example:
Original: EV-2026-0042
Working Copy: EV-2026-0042-WC01
Purpose: Investigation analysis
This prevents analysts from accidentally treating a working copy as the original evidence.
24. Chain-of-Custody Closure
Before closing custody, confirm:
☐ Evidence identity confirmed
☐ All transfers recorded
☐ All relevant custodians identified
☐ Integrity verified where required
☐ Evidence access reviewed
☐ Investigation completed
☐ Evidence linked to findings
☐ Retention requirement determined
☐ Legal hold checked where applicable
☐ Archive/disposal decision approved
☐ Final storage location recorded
☐ Final custodian recorded
☐ Chain-of-custody record completed
25. Final Disposition
Evidence may be:
Retained
Evidence remains in the approved repository.
Archived
Evidence is moved to controlled long-term storage.
Returned
Evidence is returned to the owner or source organization.
Disposed
Evidence is securely destroyed or deleted after authorized retention expiry.
Legal Hold
Evidence remains preserved because of legal, regulatory, contractual, or investigation requirements.
The final disposition should be recorded in the Evidence Register.
26. Chain-of-Custody Form — Minimum Template
| Field | Entry |
|---|---|
| Evidence ID | |
| Incident ID | |
| Investigation ID | |
| Evidence Title | |
| Evidence Type | |
| Source | |
| Original Location | |
| Collection Date/Time | |
| Collected By | |
| Collection Method | |
| Classification | |
| Integrity Required | |
| Hash Algorithm | |
| Original Hash | |
| Current Hash | |
| Storage Location | |
| Current Custodian | |
| Chain-of-Custody Status | |
| Retention Requirement | |
| Final Disposition | |
| Closure Date | |
| Approved By |
27. Custody Transfer Record
| Transfer # | Released By | Received By | Date/Time | From | To | Purpose | Method | Condition | Integrity Verified | Authorization |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | ||||||||||
| 2 | ||||||||||
| 3 | ||||||||||
| 4 |
28. Declaration
Collector Declaration
I confirm that the evidence identified in this form was collected or received through an authorized process and that the information recorded in this Chain-of-Custody Form is accurate to the best of my knowledge.
Name: ______________________
Role: ______________________
Date/Time: __________________
Signature/Approval: __________________
Receiving Custodian Declaration
I confirm that I received the evidence identified above and that the evidence condition and integrity were checked where applicable.
Name: ______________________
Role: ______________________
Date/Time: __________________
Signature/Approval: __________________
Final Reviewer
I confirm that the Chain-of-Custody record has been reviewed and that all material custody transfers have been recorded.
Name: ______________________
Role: ______________________
Date/Time: __________________
Signature/Approval: __________________
29. Startup Implementation
A startup does not need a complex forensic management platform to establish basic chain-of-custody controls.
A practical model is:
Evidence Collection Form
↓
Evidence Register
↓
Chain-of-Custody Form — when required
↓
Restricted Evidence Repository
↓
Investigation
↓
Findings / RCA
↓
Corrective Action
↓
Closure / Retention / Disposal
For a SaaS startup, the most important controls are:
- Centralized evidence repository
- Restricted access
- Unique Evidence IDs
- Reliable timestamps
- Source tracking
- Integrity verification where appropriate
- Transfer logging
- Clear ownership
- Retention and disposal decisions
- Linkage to the incident investigation
30. Relationship With Evidence Management
The complete evidence process becomes:
Evidence Collection Procedure
Defines how evidence is collected.
↓
Evidence Collection Form
Records what was collected and how.
↓
Evidence Register
Provides the central inventory of evidence.
↓
Chain-of-Custody Form
Records who handled or transferred important evidence.
↓
Incident Investigation
Determines what the evidence demonstrates.
↓
Root Cause Analysis
Determines why the issue occurred.
↓
Corrective Action Tracker
Records what will be changed.
↓
Incident Closure Report
Documents the final decision and outcome.
31. ISO 27001 Alignment
The Chain-of-Custody Form can support the organization’s information-security evidence and incident-management processes, including:
- Information security incident management
- Evidence preservation
- Access control
- Logging and monitoring
- Information classification
- Protection of documented information
- Investigation support
- Corrective action
- Risk management
- Continual improvement
The exact level of chain-of-custody control should be determined according to the organization’s risk, legal and regulatory environment, contractual commitments, and investigation requirements.
The form should therefore be treated as a risk-based organizational control, rather than as a document that every organization must maintain for every security event.
32. Audit Evidence
An auditor, investigator, customer, regulator, or authorized reviewer should be able to select an Evidence ID and establish:
Where did it come from?
→ Who collected it?
→ When was it collected?
→ How was it collected?
→ Was its integrity protected?
→ Where was it stored?
→ Who accessed it?
→ Who transferred it?
→ Why was it transferred?
→ What investigation did it support?
→ What happened to it at the end?
This creates a defensible evidence trail.
33. Final Audit Trail
Evidence Identified
→ Collection Authorized
→ Evidence Collected
→ Evidence ID Assigned
→ Evidence Condition Recorded
→ Integrity Established Where Required
→ Evidence Secured
→ Custodian Identified
→ Evidence Transferred
→ Transfer Recorded
→ Evidence Received
→ Integrity Reverified Where Required
→ Evidence Access Recorded
→ Evidence Reviewed
→ Evidence Linked to Findings
→ Further Transfer Recorded Where Applicable
→ Retention Determined
→ Final Custodian Recorded
→ Archived / Returned / Disposed
→ Final Disposition Recorded
→ Chain of Custody Closed
34. Final Principle
If evidence changes hands, the organization should be able to explain who handled it, when, why, where it went, and whether its integrity was maintained.
Chain-of-Custody Principle
Identify → Secure → Record → Transfer → Verify → Trace → Protect → Review → Retain → Dispose
The objective is not to create paperwork for every log or screenshot.
The objective is to ensure that important evidence remains identifiable, controlled, traceable, and defensible throughout its lifecycle.