What is ISO 27001 Annex A 5.28 – Collection of Evidence?
ISO 27001 Annex A 5.28 focuses on ensuring that the organization has appropriate processes for the identification, collection, acquisition, and preservation of evidence related to information security events and incidents.
When a security incident occurs, an organization may need evidence to determine:
- What happened?
- When did it happen?
- Which systems were affected?
- Which users or accounts were involved?
- What information was accessed, changed, or deleted?
- How did the incident occur?
- What actions were performed?
- Was information disclosed or exfiltrated?
- Which security controls failed or were bypassed?
Evidence may also be needed to support:
- Internal investigations
- Customer communications
- Regulatory investigations
- Legal proceedings
- Contractual requirements
- Cyber-insurance claims
- Disciplinary actions
- Forensic investigations
- Root-cause analysis
Simple explanation
A.5.28 means that when something goes wrong, the organization should know what evidence to collect, how to preserve it, and how to protect its integrity.
The objective is not to collect every piece of information.
The objective is to collect relevant evidence in a controlled and documented manner.
Why is A.5.28 Important?
Security evidence can disappear or change quickly.
For example:
- Cloud logs may reach their retention limit.
- Security alerts may be overwritten.
- Temporary files may disappear.
- Users may delete emails.
- Systems may be rebooted or rebuilt.
- Attackers may modify logs.
- Configuration changes may overwrite useful information.
If evidence is not preserved at the right time, the organization may later be unable to determine what actually happened.
Effective evidence collection helps an organization:
- Establish facts
- Reconstruct an incident timeline
- Identify affected systems
- Determine root cause
- Understand attacker activity
- Determine potential data exposure
- Support legal or regulatory requirements
- Demonstrate appropriate response
- Improve security controls
Simple principle
If evidence may be needed later, preserve it before it disappears or changes.
What Does A.5.28 Require?
The organization should establish appropriate procedures for:
- Identifying relevant evidence
- Collecting or acquiring evidence
- Preserving evidence
- Protecting evidence from unauthorized access or alteration
- Recording how evidence was obtained
- Maintaining evidence integrity
- Controlling access to evidence
- Retaining evidence for an appropriate period
- Involving legal or forensic specialists when necessary
The process should be proportionate to the organization’s size, risks, incident type, and applicable legal or contractual requirements.
A small startup does not necessarily need an internal digital-forensics team.
However, it should know:
What evidence matters, who should preserve it, where it should be stored, and when external expertise is required.
What is Security Evidence?
Evidence is information that can help establish facts about a security event or incident.
Common Evidence Sources
1. Identity and Authentication Evidence
Examples include:
- Login records
- Failed-login records
- MFA events
- Password-reset records
- Session information
- Privilege changes
- Account creation/deletion
- API-key activity
2. Cloud Evidence
Examples include:
- AWS CloudTrail
- Azure activity logs
- Google Cloud audit logs
- Microsoft 365 audit logs
- Google Workspace logs
- GitHub audit logs
3. Endpoint Evidence
Examples include:
- EDR alerts
- Malware detections
- Process activity
- File changes
- Device information
- Security agent logs
- Forensic images where appropriate
4. Network Evidence
Examples include:
- Firewall logs
- VPN logs
- DNS logs
- Proxy logs
- Network-flow information
- Intrusion-detection alerts
5. Application Evidence
Examples include:
- Application logs
- Database logs
- API activity
- Administrative activity
- Transaction records
- Error logs
6. Communication Evidence
Examples include:
- Phishing emails
- Email headers
- Incident tickets
- Relevant chat messages
- Security-team communications
7. Physical Evidence
Where relevant:
- CCTV
- Badge/access records
- Physical devices
- USB devices
- Printed documents
Evidence Collection vs. Evidence Preservation
These terms are related but are not the same.
Evidence Collection
Obtaining relevant information.
Example:
Exporting authentication logs from Microsoft 365.
Evidence Preservation
Protecting the evidence so it remains available and trustworthy.
Example:
Storing the exported logs in a restricted evidence repository and recording when and how they were collected.
An organization may collect evidence correctly but still fail A.5.28 if the evidence is subsequently altered, lost, deleted, or accessed improperly.
Activities Required to Implement A.5.28
1. Establish an Evidence Handling Procedure
The organization should define how evidence will be handled during an investigation.
The procedure may cover:
- Evidence identification
- Collection
- Acquisition
- Preservation
- Storage
- Access
- Integrity
- Documentation
- Retention
- Disposal
- Escalation
For a startup, this can be incorporated into the Incident Response Procedure rather than creating a large standalone document.
2. Identify Potential Evidence Sources
Before an incident occurs, the organization should know where useful evidence is likely to exist.
For example, a SaaS startup may use:
| System | Potential Evidence |
|---|---|
| Google Workspace | Login, email and administrative activity |
| AWS | CloudTrail, IAM and service activity |
| GitHub | Authentication and repository activity |
| Microsoft 365 | Identity and audit records |
| EDR | Endpoint activity |
| Firewall | Network connections |
| SIEM | Security events and correlations |
| Jira | Incident/change records |
| Application | User and administrative activity |
| Database | Authentication and query logs |
Knowing these sources before an incident occurs can significantly reduce investigation time.
3. Determine What Evidence is Relevant
The organization should determine what evidence is actually needed.
For example, for a suspected administrator-account compromise, relevant evidence may include:
- Authentication logs
- MFA records
- IP addresses
- Device information
- Cloud audit logs
- Administrative actions
- Application activity
- Privilege changes
- Email evidence
The organization does not necessarily need to collect every available log.
Ask:
What facts are we trying to establish?
Then identify the evidence required to establish those facts.
4. Preserve Evidence Quickly
Evidence should be preserved before it is automatically deleted, overwritten, or modified.
Potential actions include:
- Exporting relevant logs
- Preserving email
- Creating appropriate system snapshots
- Preserving cloud audit records
- Securing relevant files
- Preserving endpoint information
- Extending retention where necessary
- Preventing automatic deletion where appropriate
This is particularly important for systems with short retention periods.
5. Protect Original Evidence
Where evidence may be used for a formal investigation, the organization should avoid unnecessary modification of the original evidence.
A useful approach is:
Original Evidence
↓
Preserved Copy
↓
Controlled Analysis
This helps reduce the risk of accidentally modifying the original material.
For complex forensic investigations, specialized forensic procedures may be required.
6. Document the Collection Process
The organization should maintain sufficient information to explain how evidence was obtained.
Important information may include:
- Evidence ID
- Incident ID
- Evidence description
- Source
- Date and time
- Person who collected it
- Collection method
- Reason for collection
- Storage location
- Integrity information
- Access history where appropriate
Example
| Field | Example |
|---|---|
| Evidence ID | EV-2026-001 |
| Incident ID | INC-2026-014 |
| Evidence | AWS CloudTrail logs |
| Source | AWS production account |
| Collected By | Security Engineer |
| Date/Time | 26-Sep-2026 10:30 |
| Purpose | Investigate suspicious IAM activity |
| Storage | Restricted evidence repository |
| Integrity | Hash recorded |
| Access | Security Team |
7. Maintain Chain of Custody Where Appropriate
For certain investigations, particularly those that may involve legal proceedings or formal forensic analysis, the organization may need to maintain a chain of custody.
This records who handled the evidence and when.
Example:
Security Engineer
↓
Collected evidence
↓
Incident Manager
↓
Transferred evidence
↓
Forensic Investigator
↓
Analyzed evidence
↓
Secure Evidence Repository
A chain-of-custody record may include:
- Evidence ID
- Person releasing evidence
- Person receiving evidence
- Date/time
- Reason for transfer
- Storage location
- Confirmation/signature
A formal chain of custody may not be necessary for every routine security log. The level of control should be appropriate to the circumstances.
8. Protect Evidence Integrity
The organization should consider mechanisms that help demonstrate that evidence has not been improperly modified.
Depending on the type and importance of evidence, this may include:
- Cryptographic hashes
- Read-only storage
- Immutable storage
- Digital signatures
- Access controls
- Audit logs
- Secure evidence repositories
For example, a cryptographic hash can be generated for a collected file.
If the file is subsequently modified, its hash may change.
9. Restrict Access to Evidence
Security evidence may contain sensitive information.
It could include:
- Customer information
- Employee information
- Email content
- IP addresses
- Source code
- Security logs
- Personal information
- Confidential business information
Access should therefore be restricted to authorized personnel.
Controls may include:
- Role-based access
- Encryption
- Access logging
- Restricted repositories
- Need-to-know access
Simple principle
Security evidence should be protected with the same seriousness as the information it contains.
10. Consider Legal and Regulatory Requirements
Evidence may contain personal or sensitive information.
The organization should therefore consider:
- Privacy requirements
- Regulatory requirements
- Contractual obligations
- Customer requirements
- Legal instructions
- Insurance requirements
- Evidence retention requirements
Where an incident could result in legal proceedings or regulatory action, appropriate legal advice may be necessary.
11. Involve Forensic Specialists When Necessary
Not every incident requires external forensic support.
However, specialist assistance may be appropriate when:
- Criminal activity is suspected
- Significant customer information may be affected
- Legal proceedings are possible
- Regulatory investigation is possible
- A compromised device requires forensic examination
- Evidence integrity is critical
- The organization lacks the required expertise
- Cyber-insurance requirements apply
A startup should define escalation criteria before a major incident occurs.
12. Consider Time Synchronization
Incident investigations often depend on establishing an accurate timeline.
For example:
09:15:02 — Login
↓
09:15:18 — MFA event
↓
09:16:04 — Privileged action
↓
09:16:20 — Database activity
If different systems use inconsistent timestamps, reconstructing the incident can become difficult.
This is why A.5.28 is closely related to Annex A 8.17 – Clock Synchronization.
13. Define Evidence Retention
The organization should determine how long evidence should be retained based on applicable requirements.
Consider:
- Legal requirements
- Regulatory requirements
- Customer contracts
- Insurance requirements
- Internal investigation needs
- Security requirements
Evidence should not automatically be retained forever.
It should be retained for an appropriate period and securely disposed of when no longer required.
Startup Example – Compromised AWS Administrator Account
Consider a SaaS startup using AWS.
The security team detects unusual activity from an administrator account.
Step 1 – Identify
The team identifies potentially relevant sources:
- AWS CloudTrail
- IAM activity
- Authentication records
- MFA records
- Application logs
- GitHub audit logs
- EDR records
Step 2 – Preserve
The team preserves relevant logs before they are overwritten.
Step 3 – Collect
Relevant records are exported or otherwise acquired using appropriate methods.
Step 4 – Record
The team documents:
- What was collected
- Who collected it
- When it was collected
- Why it was collected
- Where it came from
Step 5 – Protect
The evidence is placed in a restricted repository.
Step 6 – Analyze
The investigation determines:
Compromised credentials
↓
Unauthorized authentication
↓
Privileged activity
↓
Attempted production access
↓
Containment
Step 7 – Learn
The investigation identifies:
- Weak authentication
- Excessive privileges
- Insufficient monitoring
The organization then improves its controls under the lessons-learned process.
Startup-Focused Quick Summary
A startup can implement A.5.28 without building a complex forensic department.
Start with seven practical questions:
| Question | What the startup should know |
|---|---|
| What? | What evidence may be relevant? |
| Where? | Where does the evidence exist? |
| Who? | Who can collect it? |
| When? | When must it be preserved? |
| How? | How should it be collected? |
| Where stored? | Where will it be protected? |
| How long? | How long must it be retained? |
Simple startup approach
Identify → Preserve → Collect → Record → Protect → Analyze → Retain/Dispose
Evidence Collection Register
A startup can maintain a simple evidence register.
| Evidence ID | Incident | Evidence | Source | Collected By | Date/Time | Storage | Status |
|---|---|---|---|---|---|---|---|
| EV-001 | INC-001 | CloudTrail Logs | AWS | Security Engineer | 26-Sep-2026 | Restricted Repository | Preserved |
| EV-002 | INC-001 | Login Records | Google Workspace | IT Admin | 26-Sep-2026 | Restricted Repository | Preserved |
| EV-003 | INC-001 | Audit Logs | GitHub | Security Engineer | 26-Sep-2026 | Restricted Repository | Preserved |
Important: Never place passwords, API keys, private keys, authentication tokens, or other secrets directly into an evidence register.
Chain-of-Custody Example
For evidence requiring stronger controls:
| Evidence ID | Date/Time | From | To | Purpose | Storage |
|---|---|---|---|---|---|
| EV-001 | 10:30 | Security Engineer | Incident Manager | Investigation | Secure Repository |
| EV-001 | 14:00 | Incident Manager | Forensic Consultant | Analysis | Secure Transfer |
| EV-001 | 18:30 | Forensic Consultant | Incident Manager | Return | Secure Repository |
This provides a documented history of evidence handling.
Audit Evidence for A.5.28
An auditor may look for evidence that the organization has actually implemented evidence-handling processes.
Useful evidence includes:
Policies and Procedures
- Information Security Incident Management Policy
- Incident Response Procedure
- Evidence Collection Procedure
- Evidence Preservation Procedure
- Data Retention Policy
Incident Records
- Incident reports
- Investigation records
- Evidence registers
- Evidence collection forms
- Chain-of-custody records
Technical Evidence
- Cloud audit logs
- Authentication logs
- EDR records
- SIEM records
- Firewall logs
- Application logs
- Database logs
Evidence Protection
- Evidence repository access controls
- Encryption
- Hash records
- Immutable storage
- Access logs
- Retention records
Specialist Support
- Forensic investigation reports
- External forensic engagement records
- Legal instructions where applicable
Audit Checklist – ISO 27001 A.5.28
| Audit Question | Evidence |
|---|---|
| Do you have an evidence collection procedure? | Procedure |
| Who is authorized to collect evidence? | Roles/RACI |
| What evidence sources have been identified? | Evidence source inventory |
| How is evidence preserved? | Procedure/incident records |
| How is evidence integrity protected? | Hash/access/immutability records |
| How is evidence access restricted? | Access controls |
| Is collection documented? | Evidence collection form |
| Is chain of custody maintained where appropriate? | Chain-of-custody records |
| How long is evidence retained? | Retention policy |
| When are forensic specialists engaged? | Escalation procedure |
| Can you show an example of evidence collected during an incident? | Incident evidence |
| Are relevant logs protected from premature deletion? | Logging/retention configuration |
Common Mistakes
1. Collecting Only Screenshots
Screenshots can be useful, but they may not provide:
- Complete timestamps
- Source information
- Context
- Full activity
- Reliable evidence of the underlying event
Use screenshots as supporting evidence rather than automatically treating them as complete evidence.
2. Waiting Too Long
Important logs may expire before the investigation begins.
Evidence preservation should therefore happen early.
3. Modifying Original Evidence
Investigators may accidentally change files or systems during analysis.
Where appropriate, preserve the original and analyze a controlled copy.
4. No Collection Record
The organization has evidence but cannot explain:
- Who collected it
- When
- From where
- Why
- How
This makes the evidence harder to rely upon.
5. Storing Evidence in an Ordinary Shared Folder
A shared folder may expose sensitive evidence to employees who do not need access.
Use appropriately restricted storage.
6. No Integrity Protection
For important investigations, the organization should consider appropriate mechanisms to demonstrate evidence integrity.
Examples include:
- Hashes
- Immutable storage
- Read-only storage
- Access logging
7. Deleting Logs Too Quickly
Short retention periods can result in important evidence disappearing before an investigation is complete.
8. Giving Everyone Access
Security evidence may contain highly sensitive information.
Access should follow least-privilege and need-to-know principles.
9. Attempting Complex Forensics Without Expertise
A startup may be able to handle basic evidence collection internally but may need specialists for complex investigations.
The escalation process should be defined in advance.
Practical Startup Implementation Model
A simple implementation model is:
1. Identify
Determine what evidence is relevant.
↓
2. Preserve
Prevent evidence from being deleted or overwritten.
↓
3. Collect
Acquire relevant evidence appropriately.
↓
4. Record
Document what, who, when, where, why, and how.
↓
5. Protect
Restrict access and maintain integrity.
↓
6. Analyze
Use the evidence to investigate the incident.
↓
7. Retain / Dispose
Retain evidence according to applicable requirements and securely dispose of it when appropriate.
Startup model
Identify → Preserve → Collect → Record → Protect → Analyze → Retain/Dispose
Policy vs. Process vs. Evidence
| Type | Example |
|---|---|
| Policy | Information Security Incident Management Policy |
| Process | Evidence Collection & Preservation Procedure |
| Template | Evidence Collection Form |
| Register | Evidence Register |
| Record | Completed Chain-of-Custody Form |
| Technical Evidence | Cloud audit logs |
| Protection Evidence | Evidence repository access logs |
| Investigation Evidence | Forensic investigation report |
A startup does not need dozens of separate documents.
A practical structure could be:
Incident Management Policy
↓
Incident Response & Evidence Procedure
↓
Evidence Collection Template
↓
Evidence Register
↓
Actual Incident Records
Relationship with Other ISO 27001 Controls
A.5.28 works closely with the other incident-management controls.
| Control | Relationship |
|---|---|
| A.5.24 | Prepares the organization for incident management |
| A.5.25 | Assesses security events and determines whether they are incidents |
| A.5.26 | Responds to information security incidents |
| A.5.27 | Learns from incidents and improves |
| A.5.28 | Collects and preserves evidence |
| A.8.15 | Logging provides important evidence |
| A.8.16 | Monitoring helps identify and investigate security events |
| A.8.17 | Clock synchronization supports reliable incident timelines |
| A.5.31 | Legal, statutory, regulatory and contractual requirements can affect evidence handling |
| A.5.34 | Privacy and PII requirements may apply to evidence |
Overall incident-management cycle
A.5.24 – Prepare
↓
A.5.25 – Assess
↓
A.5.26 – Respond
↓
A.5.28 – Collect & Preserve Evidence
↓
A.5.27 – Learn & Improve
↓
Update Risks, Controls & Procedures
Useful Documents for A.5.28
- Evidence Collection Procedure
[Insert Draft Document Link] - Evidence Collection Form
[Insert Draft Document Link] - Evidence Register
[Insert Draft Document Link] - Chain-of-Custody Form
[Insert Draft Document Link] - Incident Investigation Report
[Insert Draft Document Link] - Digital Forensics Procedure
[Insert Draft Document Link] - Security Log Retention Standard
[Insert Draft Document Link]
Questions an Auditor May Ask
An auditor may ask:
“Suppose you have a suspected administrator account compromise tomorrow. How would you preserve the evidence?”
A practical answer should cover:
- Identify relevant systems
- Preserve relevant logs
- Prevent critical evidence from being overwritten
- Record collection details
- Restrict access
- Protect evidence integrity
- Investigate using controlled evidence
- Escalate to specialists when necessary
- Retain evidence according to applicable requirements
The auditor may then ask:
“Show me evidence that you have implemented this process.”
The organization should be able to provide appropriate records from actual incidents, exercises, or tests.
Startup-Focused Final Takeaway
ISO 27001 Annex A 5.28 is not about collecting every possible piece of information.
It is about ensuring that relevant evidence is identified, collected, preserved, protected, and available when needed.
A startup should know:
- Where important security evidence exists
- What evidence should be preserved
- Who is authorized to collect it
- How it should be collected
- How its integrity should be protected
- Who can access it
- When legal or forensic expertise is required
- How long it should be retained
In one sentence:
A.5.28 ensures that when a security event or incident occurs, relevant evidence is handled in a controlled and trustworthy manner so the organization can establish what happened and support appropriate investigation, legal, regulatory, contractual, and business decisions.
The practical sequence
Identify → Preserve → Collect → Record → Protect → Analyze → Retain/Dispose
A strong A.5.28 implementation therefore connects incident response, investigation, evidence integrity, legal requirements, and continual improvement.