When a security incident hits and the organization can’t prove what happened — because logs were overwritten, no one followed a forensic procedure, and the chain of custody was never documented — investigations collapse, legal action fails, and auditors issue nonconformities. ISO 27001 control 5.28 exists to prevent exactly that outcome.
What 5.28 Requires
ISO 27001 Annex A 5.28 requires organizations to establish and maintain documented procedures for the identification, collection, acquisition, and preservation of digital evidence related to information security events. The objective is straightforward: when an incident occurs, the organization must be able to produce evidence that is forensically sound and admissible for legal or disciplinary proceedings.
This means defining how evidence is handled before an incident happens — not improvising during one. Procedures must cover the entire evidence lifecycle: identifying relevant data sources, collecting evidence without altering it, acquiring forensic copies, and preserving everything with documented integrity controls. The procedures must also account for different legal jurisdictions, since admissibility requirements vary across regulatory environments.
5.28 applies to all forms of digital evidence — system logs, network captures, disk images, memory dumps, email records, and application audit trails. The control expects organizations to have these procedures tested and ready, with trained personnel who know how to execute them under pressure.
Why 5.28 Matters
Consider this scenario: an organization detects signs of an insider threat — unauthorized data exports over several months. The security team investigates, but the SIEM logs only retain 30 days of data. No one created forensic images of the affected workstations. The evidence that was collected was handled by an IT administrator with no forensic training, and there’s no chain of custody documentation. When the organization tries to pursue disciplinary action, legal counsel advises the evidence is likely inadmissible.
This is not hypothetical. Organizations without formal incident response and evidence procedures pay 58% more per breach compared to those with structured, tested protocols (Ponemon Institute). The global average cost of a data breach reached $4.88 million in 2024 (IBM Cost of a Data Breach Report), and detection alone takes an average of 258 days — nearly nine months of exposure during which evidence can degrade or disappear entirely.
Failed evidence collection has cascading consequences: the organization can’t attribute the attack, can’t pursue legal remedies, can’t take defensible disciplinary action, and can’t demonstrate to regulators that it responded appropriately. Post-incident analysis becomes guesswork instead of fact-based learning.
What attackers exploit
The failure modes that 5.28 addresses are specific and predictable:
- Auto-rotated or overwritten logs with no WORM (Write Once Read Many) or immutable storage — critical evidence disappears before anyone reviews it
- No predefined evidence collection procedures — responders improvise under pressure and inadvertently alter or destroy evidence
- Broken chain of custody — evidence handled by unauthorized or untrained personnel, making it inadmissible
- Volatile evidence lost during containment — RAM contents, running processes, and network connections destroyed when responders prioritize shutting systems down
- Inconsistent timestamps across systems — without NTP synchronization, correlating events across log sources becomes unreliable
- No pre-vetted forensic suppliers — organizations waste critical hours sourcing a DFIR firm during an active incident instead of having a retainer in place
How to Implement 5.28
For your organization (first-party)
Implementing 5.28 requires building forensic readiness into your incident response capability before an incident occurs. Only 30% of organizations regularly test their incident response plans (CISA), which means the majority discover procedural gaps during a real incident — the worst possible time.
1. Create an Evidence Collection Policy. Define the scope (which systems and data sources are covered), roles (who is authorized to collect evidence), triggers (what events initiate evidence collection), and jurisdictional requirements (which legal frameworks apply to your operations).
2. Pre-vet and retain forensic suppliers. Identify and contract with a Digital Forensics and Incident Response (DFIR) firm before you need one. Verify their qualifications, agree on response SLAs, and ensure NDAs are in place. Waiting until an active incident to find a forensic provider adds days to your response timeline.
3. Implement technical controls. Deploy centralized logging through a SIEM platform with sufficient retention periods. Configure WORM or immutable storage for critical log sources. Enforce NTP synchronization across all systems to ensure timestamp consistency. Maintain write-blockers and forensic imaging tools for physical evidence acquisition.
4. Define chain of custody procedures. Create templates that capture: evidence ID, description, collector name, date and time of collection, storage location, and every subsequent handover with signatures. Every person who touches the evidence must be documented.
5. Apply cryptographic hashing at acquisition. Generate SHA-256 hashes at the point of evidence collection and record them alongside the chain of custody documentation. These hashes prove that evidence has not been altered since acquisition — a fundamental requirement for admissibility.
6. Train incident responders. Integrate evidence collection steps into your incident response playbooks. Ensure responders understand the difference between containment actions and evidence preservation — and know how to do both without one destroying the other.
7. Test annually through tabletop exercises. Run scenarios that specifically test evidence collection procedures, not just incident detection and containment. Include legal counsel in exercises to validate that collected evidence would meet admissibility requirements.
Common mistakes:
- Waiting until an incident to define evidence procedures
- Overwriting volatile evidence (RAM, process lists) during containment by rebooting or reimaging systems immediately
- Relying solely on internal IT staff without forensic qualifications to handle evidence
- Having no defined retention periods — evidence deleted before legal proceedings begin
- Failing to document the state of systems at the time of collection
For your vendors (third-party assessment)
When assessing vendor compliance with ISO 27001 third-party risk requirements, ask specific questions and request concrete artifacts:
Questions to ask:
- Do you have a documented evidence collection procedure?
- Who performs forensic acquisition — internal staff or a retained DFIR firm?
- What forensic tools and standards do you follow (ISO/IEC 27037, NIST SP 800-86)?
Evidence to request:
- Evidence Collection and Handling Policy
- Chain of custody template
- DFIR retainer contract
- Sample log retention configuration
Red flags:
- No documented evidence collection procedure
- Evidence handled exclusively by untrained staff
- No chain of custody process
- Log retention periods under 12 months
- Refusal to share forensic readiness documentation
Verification steps: Confirm the vendor’s ISO 27001 certification scope covers incident response. Use a vendor risk management checklist to standardize your assessment. Request a sample chain of custody form from a past exercise or test. Validate that log retention periods meet your contractual and regulatory requirements.
Audit Evidence for 5.28
Auditors assessing 5.28 expect specific, tangible artifacts that demonstrate the control is implemented and operational — not just documented.
| Evidence Type | Example Artifact |
|---|---|
| Policy | Evidence Collection and Handling Policy defining scope, roles, triggers, jurisdictional requirements, and retention periods |
| Procedure | Digital Forensics Standard Operating Procedure (SOP) covering acquisition, chain of custody, and storage |
| Chain of custody records | Completed chain of custody logs from incidents or exercises showing evidence ID, handler, timestamps, and handover signatures |
| Forensic tool validation | Records of approved forensic tools (write-blockers, imaging software) with calibration or validation evidence |
| Supplier agreements | DFIR retainer contract with pre-vetted forensic firm including NDA and qualification verification |
| Training records | Evidence that incident responders completed forensic awareness training and tabletop exercises |
| Log retention configuration | Screenshots or exports showing SIEM/log management retention settings and WORM storage configuration |
| Hash verification records | SHA-256 hash values generated at acquisition with comparison records from subsequent integrity checks |
Cross-Framework Mapping
Control 5.28 maps to equivalent requirements across multiple compliance frameworks. Organizations operating under multiple standards can use these mappings to demonstrate overlapping coverage.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | AU-03 (Content of Audit Records) | Full |
| NIST 800-53 | AU-10(03) (Non-repudiation — Chain of Custody) | Full |
| NIST 800-53 | AU-11 (Audit Record Retention) | Full |
| SOC 2 | CC7.4 (Incident Response) | Partial |
| CIS Controls v8.1 | 8.8 (Collect Audit Logs) | Partial |
| NIST CSF 2.0 | RS.AN-03 (Analysis — forensic analysis) | Full |
| DORA (EU) | Article 17 (ICT-related incident management) | Partial |
For organizations operating under both ISO 27001 and NIST frameworks, the AU-03/AU-10(03)/AU-11 mapping is particularly valuable — the same evidence artifacts satisfy requirements across both standards, reducing duplicate compliance effort.
Related ISO 27001 Controls
Control 5.28 does not operate in isolation. It connects to a cluster of incident management and record-keeping controls within ISO 27001.
| Control ID | Control Name | Relationship |
|---|---|---|
| 5.24 | Information security incident management planning and preparation | Defines the incident response framework that triggers evidence collection |
| 5.25 | Assessment and decision on information security events | Determines which events escalate to incidents requiring evidence |
| 5.26 | Response to information security incidents | Evidence collection happens during active response |
| 5.27 | Learning from information security incidents | Post-incident analysis depends on preserved evidence |
| 5.29 | Information security during disruption | Evidence procedures must work during business continuity events |
| 5.33 | Protection of records | Governs retention and protection of evidence as organizational records |
| 5.5 | Contact with authorities | Forensic evidence may need to be shared with law enforcement |
| 8.15 | Logging | Provides the raw log data that becomes evidence |
Frequently Asked Questions
What is ISO 27001 5.28?
ISO 27001 Annex A 5.28 is an organizational control that requires organizations to establish procedures for identifying, collecting, acquiring, and preserving digital evidence from information security events. Its purpose is to ensure evidence maintains integrity and remains admissible for legal proceedings, regulatory compliance, or internal disciplinary action.
What happens if 5.28 is not implemented?
Without 5.28, organizations cannot reliably prove what happened during a security incident. Evidence may be altered, lost, or ruled inadmissible — undermining legal action, disciplinary proceedings, and regulatory responses. From an audit perspective, the absence of documented evidence collection procedures is a nonconformity that can jeopardize ISO 27001 certification.
How do you audit 5.28?
Auditors verify that the organization has a documented evidence collection policy, chain of custody records (from real incidents or tabletop exercises), validated forensic tools, trained responders, and appropriate log retention configurations. They check that procedures are not just written but actively maintained and tested. Refer to the audit evidence table above for the specific artifacts auditors expect.
How UpGuard Helps
Maintain Evidence-Ready Compliance Across Your Attack Surface
UpGuard’s platform provides continuous visibility into your organization’s security posture and your vendors’ compliance status — giving you the audit-ready evidence trail that ISO 27001 5.28 demands. Monitor security controls, track vendor risk assessments, and demonstrate compliance readiness without scrambling when auditors arrive.