1. Purpose

The purpose of this procedure is to ensure that information and evidence related to security incidents, suspected incidents, investigations, vulnerabilities, fraud, unauthorized access, data breaches, or other security events are identified, preserved, protected, and handled in a manner that maintains their integrity and supports reliable investigation and decision-making.

The procedure helps the organization:

• Preserve relevant evidence before it is lost, altered, or overwritten.
• Maintain the integrity and reliability of investigation records.
• Establish who collected, accessed, transferred, or reviewed evidence.
• Support incident investigation and root-cause analysis.
• Support legal, regulatory, contractual, customer, or insurance requirements where applicable.
• Provide a clear audit trail for security investigations.

Evidence preservation should be risk-based and proportionate to the incident. Not every security event requires forensic-level preservation.

---

2. Scope

This procedure applies to evidence associated with:

• Security incidents
• Suspected security incidents
• Data breaches
• Account compromise
• Cloud compromise
• Malware and ransomware
• Phishing and credential theft
• Unauthorized access
• Privilege escalation
• Vulnerability exploitation
• Insider security events
• Supplier or third-party incidents
• Fraud or suspicious activity
• Production security events
• Source-code or CI/CD compromise
• Security investigations
• Regulatory or contractual investigations

Evidence may exist in:

• Cloud platforms
• Servers and virtual machines
• Containers
• Databases
• Applications
• Endpoints
• Network infrastructure
• Identity and access systems
• Email and messaging systems
• SaaS platforms
• Source-code repositories
• CI/CD systems
• Security monitoring platforms
• Backup systems
• Physical devices
• Documents and records

---

3. Evidence Preservation Principles

Evidence should be handled according to the following principles.

3.1 Preserve Before Investigating

Where practical, preserve relevant evidence before making changes that could alter or destroy it.

3.2 Protect Integrity

Evidence should not be unnecessarily modified, edited, deleted, or overwritten.

3.3 Record the Source

The organization should record where the evidence came from, when it was obtained, and who collected it.

3.4 Maintain Traceability

The organization should be able to determine:

Who collected it → When it was collected → Where it came from → How it was collected → Where it was stored → Who accessed it → What happened to it.

3.5 Minimize Access

Evidence should only be accessible to authorized personnel with a legitimate business or investigation requirement.

3.6 Preserve Relevant Evidence

Evidence preservation should focus on information that can help establish:

• What happened
• When it happened
• Who or what was involved
• Which systems were affected
• What information was accessed
• How the event occurred
• What actions were performed
• What impact occurred
• Whether the threat remains active

---

4. Types of Evidence

Evidence may include both technical and non-technical information.

Evidence Type	Examples
Authentication	Login records, MFA events, SSO logs
Identity	IAM activity, role assumptions, privilege changes
Network	Firewall, VPN, DNS, proxy, WAF and network-flow logs
Cloud	CloudTrail, CloudWatch, GuardDuty, Security Hub
Application	Application logs, API logs, transaction records
Database	Query logs, audit logs, access records
Storage	S3 access logs, file access records, object history
Endpoint	EDR alerts, system logs, malware artifacts
Email	Original email, headers, attachments, URLs
Source Code	Git history, pull requests, commits, CI/CD logs
Configuration	Security groups, IAM policies, infrastructure configuration
Vulnerability	Scanner results, exploitation evidence
Communications	Incident notifications and investigation communications
Documents	Policies, procedures, reports, investigation notes
Physical	Device, media, photographs, access records
Third Party	Supplier reports, cloud provider investigation records

---

5. Evidence Classification

Evidence should be classified according to its sensitivity.

Classification	Example
Public	Public security documentation
Internal	Internal investigation records
Confidential	Customer or business-sensitive investigation data
Restricted	Credentials, personal data, security logs, forensic information

Evidence containing credentials, authentication secrets, private keys, tokens, or highly sensitive personal information should receive appropriate additional protection.

Passwords, MFA codes, API keys, private keys, recovery codes, or active authentication tokens should never be stored as investigation evidence unless specifically required and securely controlled.

---

6. Evidence Preservation Process

The standard evidence preservation lifecycle is:

Identify → Assess → Preserve → Collect → Record → Secure → Analyze → Transfer → Retain → Dispose

---

7. Step 1 — Identify Potential Evidence

When an incident or investigation begins, the Incident Response Team should identify sources that may contain relevant evidence.

Consider:

• User accounts
• Administrator accounts
• Cloud identities
• Endpoints
• Servers
• Databases
• Applications
• Network devices
• Email
• SaaS platforms
• Source-code repositories
• CI/CD systems
• Security tools
• Backup systems
• Supplier systems

The investigation should consider the possibility that evidence exists across multiple systems.

---

8. Step 2 — Determine Preservation Priority

Not all evidence requires immediate preservation.

Priority should be based on:

• Incident severity
• Risk of evidence loss
• Log retention period
• Possibility of attacker activity
• Regulatory requirements
• Customer impact
• Data sensitivity
• Legal requirements
• Business impact

High-Priority Evidence

Examples include:

• Short-retention security logs
• Active attacker sessions
• Cloud audit logs
• Authentication records
• Endpoint volatile information
• Deleted or temporary files
• Suspicious email
• Active network connections
• Evidence likely to be overwritten

---

9. Step 3 — Preserve the Original Source

Where technically possible, preserve the original evidence source before making investigative changes.

Examples:

• Export relevant logs.
• Preserve original email messages.
• Snapshot affected systems where appropriate.
• Preserve cloud audit records.
• Capture relevant configuration.
• Preserve database audit records.
• Preserve source-code history.
• Preserve security alerts.
• Preserve relevant backup or snapshot information.

Investigators should avoid making unnecessary changes to the original source.

---

10. Step 4 — Collect Evidence

Evidence should be collected using an authorized and documented method.

The Evidence Record should include:

• Evidence ID
• Incident ID
• Description
• Source
• Date and time
• Time zone
• Collector
• Collection method
• Original location
• File or record name
• System involved
• Hash value where appropriate
• Storage location
• Classification
• Restrictions
• Transfer history

---

11. Evidence Integrity

Where appropriate, cryptographic hashing should be used to demonstrate that an exported file or evidence package has not changed.

For example:

Evidence file → SHA-256 hash → Evidence Register

If the evidence is subsequently copied or transferred, the hash may be recalculated and compared.

A mismatch should be investigated and documented.

Hashing is particularly useful for:

• Exported log files
• Disk images
• Forensic files
• Email exports
• Evidence archives
• Configuration exports
• Security reports

---

12. Evidence Chain of Custody

A chain-of-custody record should be maintained when evidence requires formal traceability.

The record should capture:

Field	Description
Evidence ID	Unique evidence identifier
Incident ID	Related incident
Description	What the evidence represents
Source	System/person/location
Collected By	Person who collected it
Collection Date/Time	When collected
Method	How collected
Hash	Integrity value where applicable
Storage Location	Where stored
Transferred By	Person transferring evidence
Received By	Person receiving evidence
Transfer Date/Time	Date and time
Purpose	Reason for access/transfer
Access Record	Who accessed it
Final Disposition	Retained, returned, deleted, etc.

---

13. Evidence Storage

Evidence should be stored in an appropriately secured location.

Security requirements should include, where appropriate:

• Access control
• Least privilege
• Encryption
• Backup
• Integrity protection
• Access logging
• Restricted deletion rights
• Retention controls
• Separation from ordinary business data

Evidence should not be stored only on an investigator’s personal laptop or local desktop.

---

14. AWS SaaS Example

Consider an AWS SaaS company that detects suspicious activity involving a privileged administrator account.

The investigation may require:

• AWS CloudTrail logs
• IAM activity
• IAM policy changes
• STS role-assumption records
• S3 access activity
• RDS audit/query logs
• Security group changes
• CloudWatch logs
• GuardDuty findings
• WAF logs
• VPC Flow Logs
• Secrets Manager access
• CI/CD activity

The Incident Response Team should preserve relevant records before deleting the account, changing configurations, or rebuilding affected resources where practical.

For example:

Suspicious IAM Activity

→ Identify affected IAM identity
→ Preserve CloudTrail records
→ Export relevant logs
→ Record collection time
→ Calculate hash where appropriate
→ Store evidence securely
→ Record collector
→ Restrict evidence access
→ Investigate activity
→ Maintain investigation timeline
→ Preserve supporting evidence
→ Document findings

This allows the organization to demonstrate what occurred rather than relying only on investigator recollection.

---

15. Email and Phishing Evidence

For phishing or email-related incidents, preserve the original message where possible.

Relevant evidence may include:

• Original email
• Email headers
• Sender information
• Recipient information
• Timestamp
• URLs
• Attachments
• Message ID
• Mailbox audit records
• Authentication results
• Related emails
• User actions
• Endpoint security alerts

Screenshots can support an investigation but should not automatically replace the original email or technical records when those are available.

---

16. Cloud Evidence Preservation

For cloud environments, preservation should consider:

Identity

• Login events
• MFA events
• Role assumptions
• Access-key activity
• Permission changes
• New users or roles
• Policy changes

Infrastructure

• Instance activity
• Container activity
• Serverless activity
• Network changes
• Security-group changes
• Configuration changes

Data

• Storage access
• Database access
• Object downloads
• Data exports
• Encryption-key usage

Security Controls

• Logging changes
• Monitoring changes
• Security alerts
• Detection-rule changes
• Disabled security services

---

17. Volatile Evidence

Some evidence may disappear when a system is shut down, restarted, isolated, or modified.

Examples include:

• Active network connections
• Running processes
• Memory contents
• Temporary files
• Active sessions
• Current authentication tokens
• Runtime information

For serious incidents, the Incident Response Team should determine whether volatile evidence should be captured before containment or system shutdown.

The decision should consider:

• Severity
• Active attacker presence
• Business impact
• Safety
• Availability requirements
• Forensic requirements
• Available expertise

Evidence preservation should not unnecessarily delay containment when immediate action is required to prevent further harm.

---

18. Evidence During Containment

Containment actions can change the environment and therefore potentially affect evidence.

Examples:

• Disabling an account
• Revoking sessions
• Rotating credentials
• Isolating a server
• Blocking an IP address
• Removing malicious software
• Rebuilding a workload
• Deleting unauthorized resources

Where practical, the response team should:

1. Preserve critical evidence.
2. Record the current state.
3. Document the planned containment action.
4. Perform containment.
5. Record what changed.
6. Preserve resulting evidence.

Security containment takes priority when delay could materially increase risk.

---

19. Evidence Access Control

Access to evidence should be restricted according to:

• Role
• Investigation responsibility
• Sensitivity
• Legal requirements
• Business need

Evidence access should be logged where practical.

Unauthorized copying, modification, deletion, disclosure, or distribution of evidence should be treated as a security event.

---

20. Evidence Transfer

When evidence is transferred between individuals, systems, or organizations:

• Use approved secure transfer methods.
• Record the sender and recipient.
• Record date and time.
• Record the reason for transfer.
• Verify integrity where appropriate.
• Update the chain-of-custody record.

Examples of external recipients may include:

• Cloud providers
• Incident response specialists
• Legal counsel
• Cyber insurers
• Certification/audit organizations
• Regulators
• Law enforcement

External disclosure should be authorized before evidence is shared, subject to applicable legal, contractual, privacy, and regulatory requirements.

---

21. Evidence Analysis

Evidence should be analyzed using the organization’s approved investigation process.

Investigators should distinguish between:

Facts

What the evidence directly demonstrates.

Assumptions

What is currently believed but not yet confirmed.

Hypotheses

Possible explanations that require further investigation.

Conclusions

Findings supported by sufficient evidence.

This distinction helps prevent assumptions from being recorded as confirmed facts.

---

22. Evidence Retention

Evidence should be retained according to:

• Incident requirements
• Legal requirements
• Regulatory requirements
• Contractual requirements
• Customer commitments
• Insurance requirements
• Internal retention requirements
• Investigation requirements

The Incident Owner, Security Lead, Legal/Compliance function, or other authorized role should determine retention requirements where appropriate.

Evidence should not be retained indefinitely without a defined business, legal, regulatory, or security reason.

---

23. Evidence Disposal

When the retention period expires:

1. Confirm that no legal hold or investigation requirement remains.
2. Confirm that the evidence is no longer required.
3. Obtain required approval.
4. Securely delete or destroy the evidence.
5. Record the disposal.
6. Update the Evidence Register.

Disposal should be performed using methods appropriate to the sensitivity and storage medium.

---

24. Evidence Preservation Checklist

Before closing evidence handling, confirm:

• Relevant evidence sources identified
• Critical short-retention evidence preserved
• Original evidence protected where practical
• Collection method documented
• Collector identified
• Date/time/time zone recorded
• Evidence ID assigned
• Incident ID linked
• Evidence classification assigned
• Hash calculated where appropriate
• Evidence stored securely
• Access restricted
• Chain of custody maintained where required
• Transfers documented
• Investigation access recorded
• Retention requirement identified
• Legal/regulatory requirements considered
• Evidence disposition documented

---

25. Evidence Register

A centralized Evidence Register may contain:

Evidence ID	Incident ID	Evidence Description	Source	Collected By	Date/Time	Hash	Classification	Storage	Custodian	Status
EV-001	INC-2026-001	CloudTrail export	AWS	Security Lead	30-Sep-2026 10:15 UTC	SHA-256	Restricted	Secure Evidence Store	Security	Active
EV-002	INC-2026-001	Suspicious email	Email	IT	30-Sep-2026 10:22 UTC	SHA-256	Confidential	Secure Evidence Store	Security	Active

---

26. Relationship With Other Incident Records

The Evidence Preservation Procedure should operate together with:

Incident Reporting Form
→ reports the suspected event.

Incident Register
→ provides the central incident record.

Incident Timeline
→ establishes when events occurred.

Incident Investigation Template
→ documents the investigation.

Incident Severity Matrix
→ determines impact and response priority.

Incident Escalation Matrix
→ determines who must be involved.

Incident Response Playbooks
→ provide specialized response actions.

Corrective Action Tracker
→ tracks remediation.

Incident Closure Report
→ documents final findings and closure.

Together:

Incident Detected → Incident Reported → Severity Determined → Evidence Preserved → Investigation → Containment → Eradication → Recovery → Impact Assessment → Corrective Actions → Closure

---

27. Roles and Responsibilities

Role	Responsibility
Incident Commander	Overall decision-making and coordination
Security Lead	Evidence preservation requirements and security investigation
Investigator	Evidence collection, analysis and documentation
IT/Cloud Team	Technical evidence collection
Application/DevOps	Application and CI/CD evidence
Privacy/Legal	Privacy, legal and regulatory considerations
Business Owner	Business impact and operational decisions
Supplier Owner	Third-party evidence coordination
Evidence Custodian	Secure storage and access management
Executive Management	Major incident decisions and risk acceptance

For startups, one person may perform multiple roles. However, evidence access and approval should remain appropriately controlled.

---

28. Evidence Preservation Decision Logic

When an incident occurs:

Potential evidence identified?

↓ Yes

Could the evidence be lost, overwritten, or changed?

↓ Yes

Preserve immediately

↓

Is formal chain of custody required?

↓ Yes

Create custody record

↓

Store securely

↓

Verify integrity

↓

Conduct investigation

↓

Retain according to requirement

↓

Dispose securely when authorized

---

29. Common Mistakes

Avoid:

• Investigating without preserving important logs.
• Restarting or rebuilding systems before considering volatile evidence.
• Saving evidence only on a personal laptop.
• Modifying original evidence unnecessarily.
• Failing to record collection time.
• Failing to record the evidence source.
• Sharing evidence through unsecured channels.
• Sending passwords or secrets as evidence.
• Treating screenshots as the only evidence when original records exist.
• Allowing unrestricted access to investigation records.
• Deleting evidence when the incident appears resolved.
• Mixing assumptions with confirmed findings.
• Failing to document containment actions that changed the environment.

---

30. Startup Implementation Model

A startup does not necessarily need an expensive forensic platform to establish effective evidence preservation.

A practical starting model can use:

Cloud Logs + Security Alerts + Central Evidence Repository + Evidence Register + Hashing + Access Control + Incident Timeline

For example:

AWS CloudTrail

→ Export relevant events

Security Alert

→ Link alert to incident

Evidence Repository

→ Store protected evidence

Evidence Register

→ Record source, collector, time and integrity

Incident Timeline

→ Link evidence to events

Investigation Report

→ Document findings

Corrective Action Tracker

→ Track remediation

This creates a defensible evidence trail without creating unnecessary bureaucracy.

---

31. ISO 27001 Connection

Evidence preservation supports the organization’s information security incident management and investigation processes.

It can also support controls and processes relating to:

• Incident management
• Information security event reporting
• Assessment and decision-making regarding security events
• Evidence collection
• Access control
• Logging and monitoring
• Information protection
• Backup and retention
• Supplier incident management
• Compliance and contractual requirements

The exact evidence preservation requirements should be determined based on the organization’s risk assessment, applicable obligations, incident profile, and Statement of Applicability.

The procedure itself is an organizational implementation document; ISO 27001 does not mean that every organization must maintain a forensic chain-of-custody process for every minor security event.

---

32. Audit Evidence

An auditor may expect the organization to demonstrate that evidence is handled consistently.

Useful evidence may include:

• Evidence Preservation Procedure
• Evidence Register
• Chain-of-Custody Records
• Incident Reports
• Incident Timelines
• Investigation Reports
• Cloud Audit Logs
• Security Alerts
• Evidence Access Logs
• Hash Records
• Evidence Transfer Records
• Retention/Disposal Records
• Corrective Action Records
• Incident Closure Reports
• Tabletop or incident-response testing records

The objective is not simply to show that a procedure exists.

The organization should be able to demonstrate:

Incident → Evidence Identified → Evidence Preserved → Evidence Protected → Investigation Conducted → Findings Supported → Corrective Action → Closure

---

33. Final Audit Trail

Security Event Detected
↓
Incident Reported
↓
Potential Evidence Identified
↓
Evidence Priority Determined
↓
Critical Evidence Preserved
↓
Evidence Collected
↓
Evidence ID Assigned
↓
Source and Collection Details Recorded
↓
Integrity Verified Where Appropriate
↓
Evidence Secured
↓
Access Controlled
↓
Chain of Custody Maintained Where Required
↓
Investigation Conducted
↓
Evidence Linked to Findings
↓
Evidence Retained
↓
Investigation Closed
↓
Evidence Disposed of Securely When Authorized

---

Final Principle

Preserve the Evidence + Protect Its Integrity + Record Its Source + Maintain Traceability + Restrict Access + Support the Investigation + Retain Appropriately + Document the Decision.