1. Purpose
The Evidence Collection Procedure defines how information security evidence is identified, collected, recorded, protected, transferred, analyzed, and retained during security incidents, investigations, audits, security events, and other situations where reliable evidence is required.
The procedure is designed to ensure that evidence:
- Comes from a known source
- Is collected using an appropriate method
- Maintains integrity
- Can be traced to the person who collected it
- Is protected from unauthorized access or alteration
- Can support investigation and decision-making
- Can be produced during audit or review when appropriate
The core principle is:
Collect Only What Is Needed + Preserve Integrity + Record the Source + Maintain Traceability + Protect the Evidence.
2. Scope
This procedure applies to evidence collected from:
- Security incidents
- Security events
- Suspected incidents
- Account compromise
- Cloud compromise
- Data breaches
- Malware
- Ransomware
- Phishing
- Unauthorized access
- Vulnerability exploitation
- Insider activity
- Supplier incidents
- Security testing
- Internal investigations
- Internal audits
- External audits
- Compliance assessments
- Business continuity exercises
- Security control testing
Evidence may originate from:
- Cloud platforms
- Endpoints
- Servers
- Applications
- Databases
- Networks
- Identity systems
- SaaS platforms
- Source-code repositories
- CI/CD platforms
- Security tools
- Physical records
- Third parties
3. Evidence Collection Principles
3.1 Preserve Before You Analyze
Where practical, preserve relevant evidence before performing actions that could modify or destroy it.
3.2 Maintain Original Evidence
Do not unnecessarily modify the original evidence.
Where possible:
Original Evidence → Preserved Copy → Working Copy → Analysis
3.3 Record the Source
Every evidence item should have a known source.
3.4 Record Who Collected It
The collector and collection method should be documented.
3.5 Protect Evidence
Evidence should be protected according to its sensitivity.
3.6 Maintain Traceability
The organization should be able to explain:
Where the evidence came from → Who collected it → When → How → Where it was stored → Who accessed it.
3.7 Minimize Collection
Collect evidence that is relevant to the investigation or defined objective.
Avoid unnecessary collection of personal or unrelated information.
3.8 Do Not Destroy Evidence
Do not delete, overwrite, modify, or unnecessarily manipulate evidence.
4. Types of Evidence
Evidence may include:
Identity Evidence
- Login records
- MFA records
- SSO logs
- IAM activity
- Access-token activity
- API-key activity
- Role-assumption records
- Privilege changes
Network Evidence
- Firewall logs
- VPN logs
- DNS logs
- Proxy logs
- Network-flow logs
- WAF logs
- IDS/IPS records
Endpoint Evidence
- EDR alerts
- System logs
- Process information
- File activity
- Malware artifacts
- Browser activity
- Device information
Application Evidence
- Application logs
- API logs
- Authentication events
- Administrative actions
- Error logs
- Configuration changes
Database Evidence
- Database audit logs
- Query logs
- Authentication records
- Administrative activity
- Data-access records
Cloud Evidence
- Cloud audit logs
- IAM activity
- Resource changes
- Security alerts
- Storage access
- Network activity
- Configuration history
Communication Evidence
- Email headers
- Chat messages
- Security notifications
- Supplier communications
- Customer communications
Development Evidence
- Git history
- Pull requests
- CI/CD logs
- Deployment records
- Build logs
- Configuration changes
- Secrets-management activity
Physical Evidence
- Access-control records
- CCTV where legitimately available
- Visitor records
- Physical documents
- Device inventory
- Asset handover records
5. Evidence Classification
Evidence should be classified according to the organization’s information-classification scheme.
Example:
| Classification | Example |
|---|---|
| Public | Public security documentation |
| Internal | Internal logs and operational records |
| Confidential | Incident investigation records |
| Restricted | Sensitive personal/customer/security evidence |
Additional restrictions may apply to:
- Personal data
- Customer data
- Authentication information
- Legal information
- Security credentials
- Sensitive vulnerability information
6. Evidence Collection Trigger
Evidence collection may be initiated when:
- An incident is confirmed
- A serious security event requires investigation
- An investigation is formally opened
- A potential data breach is identified
- An account compromise is suspected
- A cloud compromise is suspected
- A security test requires evidence
- An audit requires supporting evidence
- Management requests an investigation
- A supplier reports an incident
- Legal or regulatory requirements require preservation
7. Evidence Collection Authorization
Before collecting evidence, determine:
- Investigation purpose
- Scope
- Authorized collector
- Systems involved
- Information involved
- Required access
- Privacy considerations
- Legal considerations
- Business impact
Where the investigation involves employee activity, personal data, privileged communications, or other sensitive information, appropriate Legal, HR, Privacy, or management involvement should be considered.
8. Evidence Collection Record
Every significant evidence item should receive a unique identifier.
Evidence ID
Use:
EV-YYYY-0001
Example:
EV-2026-0042
Record:
| Field | Information |
|---|---|
| Evidence ID | |
| Incident/Investigation ID | |
| Description | |
| Source | |
| System | |
| Collector | |
| Date/Time | |
| Time Zone | |
| Collection Method | |
| Original Location | |
| File/Record Name | |
| Classification | |
| Integrity Verification | |
| Storage Location | |
| Access Restrictions |
9. Collection Planning
Before collecting evidence, determine:
What?
What evidence is required?
Why?
Why is it relevant?
Where?
Where is the evidence located?
Who?
Who is authorized to collect it?
When?
What time period should be collected?
How?
What collection method should be used?
How Will It Be Protected?
Where will the evidence be stored and who can access it?
10. Establish the Investigation Time Window
Define the relevant period.
Example:
Start: 15 September 2026 09:00 IST
End: 18 September 2026 18:00 IST
Where possible, record:
- Time zone
- Source-system time
- Normalized investigation time
- Any clock synchronization issues
For cloud and distributed environments, timestamps should be interpreted carefully because different systems may record events using different time zones or timestamp formats.
11. Evidence Priority
Not all evidence has equal urgency.
Priority 1 — Critical / Volatile
Collect immediately where practical.
Examples:
- Active sessions
- Current network connections
- Running processes
- Active cloud sessions
- Temporary credentials
- Memory-related evidence
- Current attacker activity
Priority 2 — High
Collect quickly.
Examples:
- Authentication logs
- Cloud audit logs
- EDR events
- Application logs
- Firewall/WAF logs
- Security alerts
Priority 3 — Normal
Collect during investigation.
Examples:
- Configuration records
- Historical access reviews
- Change records
- Policies
- Procedures
- Asset records
Priority 4 — Supporting
Collect when required.
Examples:
- Training records
- General communications
- Background documentation
- Historical records
The priority should be adjusted based on the specific investigation.
12. Volatile Evidence
Some evidence can disappear when a system is:
- Shut down
- Rebooted
- Isolated
- Logged out
- Reconfigured
- Automatically rotated
- Automatically deleted
Examples:
- Active sessions
- Running processes
- Network connections
- Temporary files
- Memory
- Short-retention logs
- Temporary cloud credentials
Where volatile evidence is important, determine whether it should be collected before containment.
However:
Containment takes priority when delaying containment would materially increase security risk.
Record the decision.
13. Log Collection
When collecting logs, record:
- Source system
- Log type
- Time period
- Time zone
- Export method
- Collector
- Collection date/time
- File name
- File size
- Integrity information
- Storage location
Examples:
- Authentication logs
- VPN logs
- Firewall logs
- EDR logs
- Application logs
- Database logs
- Cloud audit logs
- WAF logs
- DNS logs
- SIEM records
14. AWS Evidence Collection
For an AWS SaaS environment, relevant evidence may include:
AWS CloudTrail
Collect relevant:
- API activity
- IAM activity
- Role assumptions
- Resource changes
- Security configuration changes
- Data-access events where enabled
IAM
Review:
- User activity
- Role activity
- Policy changes
- Access keys
- MFA changes
- Permission changes
GuardDuty
Collect:
- Findings
- Detection timestamps
- Affected resources
- Finding status
- Investigation details
Security Hub
Collect:
- Security findings
- Control findings
- Finding history
- Severity
- Resource information
S3
Where relevant, review:
- Object access
- Bucket configuration
- Public access changes
- Object-level activity
- Versioning
- Deletion activity
RDS
Where enabled and relevant:
- Database authentication
- Database activity
- Audit records
- Administrative changes
VPC / Network
Review:
- VPC Flow Logs
- Security Group changes
- Network ACL changes
- WAF activity
- Load-balancer logs
Secrets and Keys
Investigate relevant:
- Secrets Manager activity
- KMS activity
- Key usage
- Secret access
Do not copy or store secret values in the evidence repository merely because the secret was accessed.
15. Email Evidence
For phishing, BEC, malicious attachments, or email-based incidents, preserve:
- Original message
- Full headers
- Sender
- Recipient
- Timestamp
- Subject
- URLs
- Attachments
- Message ID
- Authentication results
- Relevant mailbox activity
Where possible, preserve the original message in an approved format rather than relying only on screenshots.
16. Endpoint Evidence
Where authorized and appropriate, collect:
- Hostname
- Device identifier
- User
- Operating system
- EDR alerts
- Process information
- File information
- Relevant logs
- Network connections
- Malware indicators
- Security-tool findings
Avoid unnecessary collection of unrelated personal information.
17. Application Evidence
Collect relevant:
- Application logs
- API logs
- Authentication records
- Administrative activity
- Configuration changes
- Deployment records
- Error records
- Security alerts
Determine whether logs are:
- Complete
- Time synchronized
- Protected
- Retained
- Accessible
- Potentially modified
18. Database Evidence
Depending on the investigation, collect:
- Authentication activity
- Administrative actions
- Query/audit logs
- Access records
- Configuration changes
- Data-access records
Where customer or personal data may be involved, minimize the amount of actual data copied into the investigation repository.
Prefer metadata and access records where they are sufficient.
19. Source Code and CI/CD Evidence
For application or supply-chain investigations, preserve:
- Git commits
- Pull requests
- Branch changes
- Build records
- Deployment records
- Pipeline logs
- Configuration changes
- Repository access logs
- CI/CD authentication activity
Investigate:
- Unexpected commits
- Unauthorized deployments
- New users
- Token usage
- Workflow modifications
- Secret access
- Build changes
20. Evidence Integrity
Evidence integrity should be protected using appropriate technical and procedural controls.
Where practical, record:
- Cryptographic hash
- File size
- Collection timestamp
- Original source
- Collection method
Example:
Evidence EV-2026-0042 was exported from the AWS CloudTrail environment on 18 September 2026 at 14:20 IST and stored in the restricted investigation repository. Integrity was verified using a cryptographic hash.
A hash is useful for demonstrating that a collected file has not changed after collection.
21. Hashing
For files where integrity verification is appropriate:
Original File → Hash Calculated → Evidence Stored → Hash Rechecked
Record:
- Algorithm
- Hash value
- Date/time
- Collector
Example fields:
| Evidence ID | Algorithm | Hash | Verified |
|---|---|---|---|
| EV-2026-0001 | SHA-256 | Yes |
Do not rely on screenshots of hash values when the underlying file can be preserved directly.
22. Working Copies
Where analysis could modify the evidence:
Do not analyze the only preserved copy.
Use:
Original Evidence → Preserved Master → Working Copy → Analysis
Record when a working copy is created.
23. Evidence Storage
Evidence should be stored in an approved location with:
- Access control
- Least privilege
- Encryption where appropriate
- Backup
- Access logging
- Restricted deletion
- Appropriate retention
- Integrity protection
Access should be limited to authorized personnel.
24. Evidence Access Log
Maintain an access record for sensitive evidence.
| Date/Time | Evidence ID | Person | Action | Reason |
|---|---|---|---|---|
| View | ||||
| Copy | ||||
| Transfer | ||||
| Analyze |
25. Chain of Custody
For significant investigations, maintain a chain-of-custody record.
| Field | Details |
|---|---|
| Evidence ID | |
| Incident ID | |
| Description | |
| Source | |
| Collected By | |
| Collection Date/Time | |
| Collection Method | |
| Integrity/Hash | |
| Storage Location | |
| Transferred By | |
| Received By | |
| Transfer Date/Time | |
| Purpose | |
| Access Record | |
| Final Disposition |
The chain of custody should allow the organization to reconstruct the handling history of important evidence.
26. Evidence Transfer
When evidence is transferred:
- Confirm authorization.
- Identify sender.
- Identify recipient.
- Record date/time.
- Record reason.
- Use an approved secure transfer method.
- Verify integrity.
- Update chain of custody.
Do not send sensitive evidence through ordinary unsecured email or consumer file-sharing services unless specifically approved and appropriately protected.
27. Third-Party Evidence
Evidence may be obtained from:
- Cloud providers
- SaaS providers
- Managed security providers
- Suppliers
- Customers
- External investigators
- Security researchers
- Legal counsel
Record:
- Provider
- Contact
- Evidence description
- Date/time received
- Source
- Method
- Integrity information
- Restrictions
- Associated incident
28. Evidence From Suppliers
When a supplier reports an incident, request appropriate evidence such as:
- Incident summary
- Timeline
- Affected services
- Affected information
- Root cause
- Containment
- Recovery
- Indicators of compromise
- Customer impact
- Corrective actions
Record the supplier evidence under the relevant incident or supplier-security record.
29. Personal Data in Evidence
Incident evidence may contain personal information.
Apply:
- Data minimization
- Need-to-know access
- Appropriate classification
- Secure storage
- Access logging
- Retention controls
- Appropriate deletion
Do not collect large amounts of personal information simply because it might be useful.
30. Sensitive Credentials and Secrets
Never place the following into ordinary evidence records:
- Passwords
- MFA recovery codes
- Private keys
- API secrets
- Access tokens
- Session tokens
- Database passwords
- Cloud secret values
If a credential is compromised:
- Record the credential identifier where appropriate.
- Preserve relevant evidence showing its use.
- Revoke or rotate it.
- Record the action.
- Store any specially protected forensic material only under an approved process.
31. Evidence Analysis
During analysis, distinguish:
Fact
Supported directly by evidence.
CloudTrail shows an IAM role was assumed at 14:32 IST.
Observation
Something identified during review.
The role was used from an unfamiliar source location.
Hypothesis
A possible explanation.
The access key may have been compromised.
Conclusion
A conclusion supported by the available evidence.
The investigation determined that the access key was used without authorization.
This distinction prevents assumptions from becoming documented “facts.”
32. Evidence Gaps
Not all evidence will always be available.
Record:
- Evidence required
- Evidence unavailable
- Reason unavailable
- Retention issue
- Logging limitation
- Access limitation
- Technical limitation
- Supplier limitation
- Impact on investigation
Example:
CloudTrail data for the relevant period was unavailable because the affected account did not have the required data-event logging enabled.
The investigation should consider how the evidence gap affects confidence in its conclusions.
33. Evidence Quality Review
Before relying on evidence, consider:
- Is the source trustworthy?
- Is the timestamp reliable?
- Is the evidence complete?
- Could it have been modified?
- Is the collection method documented?
- Is the evidence relevant?
- Is the evidence consistent with other sources?
- Are there gaps?
- Are alternative explanations possible?
34. Evidence Retention
Retention should consider:
- Incident requirements
- Legal requirements
- Regulatory requirements
- Contractual requirements
- Customer requirements
- Insurance requirements
- Internal policy
- Investigation needs
Evidence should not be retained indefinitely without a defined business, legal, regulatory, or security reason.
35. Evidence Disposal
When retention expires:
- Confirm disposal authorization.
- Verify no legal hold or active investigation exists.
- Identify evidence to be disposed.
- Use an approved secure disposal method.
- Record disposal.
- Update the evidence register.
Disposal Record
Evidence ID:
Disposition:
Date:
Authorized By:
Method:
36. Evidence Collection Checklist
Before Collection
- Investigation authorized
- Scope defined
- Evidence sources identified
- Time window defined
- Privacy considerations assessed
- Legal considerations assessed
- Volatile evidence considered
- Collector authorized
During Collection
- Source recorded
- Date/time recorded
- Time zone recorded
- Collection method recorded
- Evidence ID assigned
- Original preserved
- Integrity protected
- Hash calculated where appropriate
- Evidence securely stored
- Access restricted
After Collection
- Evidence register updated
- Chain of custody updated
- Working copy created where required
- Evidence analyzed
- Evidence gaps recorded
- Findings linked to evidence
- Retention determined
- Disposal requirements documented
37. AWS SaaS Example
Scenario
A SaaS company detects an unusual login to an AWS privileged identity.
Investigation
The incident team creates:
Incident: INC-2026-0041
Evidence collected:
| Evidence ID | Source | Evidence |
|---|---|---|
| EV-2026-0101 | CloudTrail | Authentication/API activity |
| EV-2026-0102 | IAM | Role and permission changes |
| EV-2026-0103 | GuardDuty | Security finding |
| EV-2026-0104 | S3 | Relevant access activity |
| EV-2026-0105 | VPC | Relevant network activity |
| EV-2026-0106 | CI/CD | Deployment activity |
The team records:
- Collection time
- Source
- Collector
- Relevant time window
- Collection method
- Integrity information
- Storage location
The evidence is then correlated to establish:
Identity → Authentication → Privilege → Resource → Data Access → Network Activity → Impact
This evidence supports the investigation, containment, root-cause analysis, and final incident-closure decision.
38. Relationship With Other ISMS Records
The Evidence Collection Procedure should connect to:
Security Event → Incident Report → Incident Register → Evidence Collection → Investigation → Timeline → Root Cause Analysis → Corrective Action → Lessons Learned → Risk Reassessment → Post-Incident Review → Closure
It may also connect to:
- Supplier Incident
- Data Breach Assessment
- Cloud Incident Response
- Vulnerability Management
- Internal Audit
- Security Testing
- Management Review
39. Startup Implementation
A startup does not need a complex forensic laboratory to establish a useful evidence-collection process.
A practical model is:
1. Central Evidence Repository
Restricted storage for investigation evidence.
2. Evidence Register
Track every important evidence item.
3. Incident ID
Every evidence item links to an incident or investigation.
4. Cloud Logging
Enable and retain appropriate AWS/cloud audit logs.
5. Security Monitoring
Use available EDR, identity, application, cloud, and network security telemetry.
6. Integrity Protection
Hash important exported evidence where appropriate.
7. Access Control
Restrict evidence to authorized responders.
8. Chain of Custody
Use it for significant or sensitive investigations.
9. Retention
Define retention based on organizational requirements.
10. Review
Ensure investigation conclusions are supported by evidence.
40. Minimum Evidence Register
A simple spreadsheet can start with:
| Evidence ID | Incident ID | Source | Description | Collected By | Date/Time | Method | Classification | Hash | Storage | Status |
|---|
This can later be expanded as the organization’s investigation capability matures.
41. Audit Evidence
The organization should be able to demonstrate, where applicable:
- Evidence was identified
- Evidence was collected appropriately
- Sources were documented
- Collection dates/times were recorded
- Authorized personnel performed collection
- Evidence integrity was considered
- Sensitive evidence was protected
- Access was restricted
- Chain of custody was maintained where required
- Investigation findings were linked to evidence
- Evidence gaps were documented
- Retention requirements were defined
- Disposal was controlled
42. ISO 27001 Alignment
Evidence collection supports the organization’s incident management, information protection, access control, logging, monitoring, investigation, and continual-improvement processes.
It can support activities relating to:
- Reporting information-security events
- Assessing and responding to incidents
- Preserving information-security evidence
- Logging and monitoring
- Access control
- Protection of information
- Supplier incidents
- Risk management
- Corrective action
- Continual improvement
The exact collection forms, evidence IDs, hashing methods, chain-of-custody requirements, retention periods, and repositories are organizational implementation choices and should be based on the organization’s risk, legal requirements, technology, and investigation needs.
43. Final Evidence Collection Audit Trail
Investigation Authorized → Scope Defined → Evidence Sources Identified → Time Window Defined → Evidence Priority Determined → Volatile Evidence Considered → Evidence Collected → Evidence ID Assigned → Source Recorded → Collection Method Recorded → Integrity Verified → Evidence Secured → Access Controlled → Chain of Custody Maintained → Evidence Analyzed → Findings Linked to Evidence → Evidence Gaps Recorded → Evidence Retained → Investigation Completed → Retention Reviewed → Evidence Disposed Securely
Final Principle
Collect the Right Evidence + Preserve Its Integrity + Record Where It Came From + Maintain Traceability + Protect Sensitive Information + Distinguish Facts From Assumptions + Support the Investigation + Retain Appropriately + Document the Decision.