A.5.28 Collection of evidence: requirements and evidence

What A.5.28 collection of evidence asks for in ISO 27001

A.5.28 asks the organization to establish and implement documented procedures for identifying, collecting, acquiring and preserving evidence related to information security events. The aim is that when something goes wrong, the logs, images and records you later rely on are still usable for a disciplinary case, a regulator, an insurer or a court. The control carries forward control A.16.1.7 from the 2013 edition, so organizations that certified under the earlier version already had this requirement in some form. What changed is the wording and placement, not the purpose. Auditors will look for a written procedure, evidence that people follow it, and records showing that evidence was handled in a way someone could later defend. The risk is simple to describe and easy to underestimate. Logs roll over before anyone asks for them, an administrator reboots a compromised server to restore service and wipes memory the investigators needed, or a screenshot is passed around without a record of who had it. Evidence can also be challenged if no one can show it was not altered after collection. Lost or contested evidence weakens disciplinary action, legal claims and reporting to authorities, even when the underlying incident was handled well. The control is hard to run because ownership is split. IT operates the systems that generate logs and hold images, the security team decides what to capture during an investigation, and legal or HR decides what is admissible and who may see it. Before an incident, the organization should confirm who authorizes evidence collection, which tools may be used, where copies are stored, and who signs off on the chain of custody. Confirm these decisions with your legal counsel and your incident response plan under A.5.24 and A.5.26, because the procedure must reflect the rules that apply in your jurisdiction.

Which systems and teams A.5.28 covers

A.5.28 procedures only work where the organization has decided which sources of evidence fall inside them. The cards below set out the scoping decisions that determine how much collection, preservation and chain of custody work the control adds, and which of them change the work most.

Endpoints and servers

Decide which laptops, workstations, virtual machines and production hosts feed event data into the evidence process, and whether collection runs continuously or only after an event is triaged. Collection on a fleet is far more involved than on a handful of machines, because each host needs a defined artifact set, a retention period and a way to collect from machines that are offline. Check that the agent or query tool can hash files and capture process and network state, and that its own administrative access is logged.

Identity and access platforms

Identity providers, directories, privileged access tools and secrets managers record who did what and when, and they are often the first source an investigator requests. Decide which authentication, administration and token events must be kept, and where they are stored. Confirm that audit records from these platforms cannot be edited by the administrators whose actions they record, and that clock sources match across systems so timelines hold up.

SaaS and cloud control planes

Cloud consoles, API management planes and SaaS admin logs often hold the most decisive evidence for a cloud account compromise, yet each provider keeps different retention periods and export options. Decide which tenants, accounts and subscriptions are in scope, who may export logs, and whether exports go to storage the security team controls. Ask each provider what it retains, for how long, and whether it can supply records in a form that supports a chain of custody.

Network and security logs

Firewalls, DNS resolvers, proxies, VPN concentrators and detection tools generate records that show connections, data movement and blocked activity. Decide which devices forward logs centrally, which fields must be preserved unchanged, and how long each source is kept. Time synchronization matters here because records from different devices are only useful together if their timestamps agree, so confirm that each source is synchronized to the same reference.

Backups and forensic images

Backups, snapshots and forensic disk images are evidence only if they are captured, labeled, hashed and stored in a way that shows they were not altered after capture. Decide which systems get forensic imaging on incident, who may authorize an image, and where working copies are kept separate from originals. Restoring a backup for operational reasons can change the state of a system, so confirm that the procedure records every step taken on a copy.

Third parties holding logs

Managed security providers, hosting companies, SaaS vendors and outsourced monitoring services may hold logs that the organization needs during an investigation. Decide which contracts must give timely access to those records, in what format, and who may request them. Contract terms about retention, legal hold and cooperation with investigators are the controls that determine whether this evidence can be obtained at all, and they should be checked before an incident rather than during one.

How an assessor tests evidence collection

This table walks through the assessor's test of A.5.28 in the order it usually runs, from the documented procedure to sampled events and their collection records. Read each row as a test step: the evidence requested, what a passing result looks like, and the findings auditors most often write up.

Test step	Evidence requested	Passing result	Common findings
Review the documented procedure	Written evidence collection procedure, its version history and approval record	Procedure names triggers for collection, the roles that collect, handling steps and where records are kept	Collection steps exist only in analysts' heads or in tool defaults, with no written procedure
Check triggers and scope	Examples of events that required collection, such as data loss, unauthorized access or malware on a host	Triggers are defined in terms the team can apply, for example by incident category or severity	Triggers are vague, or no link exists between the incident classification and the decision to preserve evidence
Confirm roles and authority	Role assignments, on-call rota, and the authority to request system images or log exports	Named roles can act alone during an incident, with an escalation path to legal or management	Roles are named in the procedure but the people named were never briefed or lack system access
Sample past security events	Incident register extract covering a sample of events chosen by the assessor	Each sampled event with collection needs shows a matching collection record	Events with evidence needs have no collection record, or records exist for events outside the sample
Trace collection to hashes	Hash values recorded at acquisition, and hash recalculation performed by the assessor on copies	Recorded hashes match recalculated values and the algorithm used is documented	Hashes are missing, computed on the working copy only, or the hashing method is undocumented
Inspect chain-of-custody records	Custody forms or ticket history showing each transfer, storage location and person handling the item	Every handover is signed or logged with time, person and reason, with no gaps	Custody gaps between handovers, unsigned forms or evidence copied to personal storage
Check storage and access	Access lists and access logs for the evidence store, plus retention settings	Only authorized roles can read or change evidence, and access is logged	Shared administrator accounts access evidence, or retention settings delete items before the case closes
Verify tool logs used as evidence	Audit logs from the collection tools and the source systems, with time sources	Log timestamps are synchronized and the collection tool's own actions are recorded	Tool actions are not logged, or source system clocks drift so timelines cannot be reconstructed

How to implement evidence collection step by step

This sequence takes an organization from undefined incident handling to a documented, tested procedure that keeps evidence of information security events usable for internal investigation, disciplinary action or legal proceedings.

Define evidence triggers and sources
Start by listing the events that require evidence to be preserved, such as suspected account compromise, malware detection, data exfiltration or a disputed insider action, and link each trigger to the incident categories used under A.5.25. Then build a log source register that names each system, its owner, the log or artifact type, retention location and whether it is centralized. Sources usually include identity providers, endpoints, cloud control planes, application audit logs and secrets managers. The step closes when the register is approved by the security lead and each source has a named owner who confirms it is producing data.
Write the collection and acquisition procedure
Document how responders identify relevant evidence, collect it without altering the source, and acquire forensic images or memory captures. The procedure should set the order of volatility, specify which tools are approved for live collection and state who may authorize collection from a production system. Where legal action is possible, the procedure should require the responder to record the method, tool version and time of each acquisition. Confirm the procedure with legal counsel or the internal investigations team before it is published. The output is a versioned procedure that responders can follow without interpreting it.
Set preservation and retention rules
Define how evidence is stored once collected: the protected location, access restrictions, encryption, and the retention period for each evidence class. Align these periods with the legal, contractual and regulatory requirements identified under A.5.31 and with the records rules under A.5.33, and confirm the periods with counsel rather than copying them from another organization. Include a hold process that suspends deletion when an investigation or dispute starts. The step is complete when storage locations are configured, access is limited to named roles, and a hold can be placed and lifted with a recorded decision.
Build custody and integrity records
Create a custody form template that records each item's identifier, description, source system, collector, date and time, collection method, hash value, storage location and every subsequent transfer or access. Hash each file or image at collection and again at each transfer so that any later change can be detected. Store the custody record with the evidence, not in a separate informal document. The step closes when a test item can be followed from collection to storage with every handover logged and its hash verified at the end.
Configure tooling and time sources
Set up the collection tools the procedure names, such as osquery for scheduled host queries, Velociraptor for artifact collection across endpoints, and the audit logging features of self-hosted applications and secrets managers. Confirm that the audit logs are enabled, that their output paths are protected and that timestamps are consistent across systems, which depends on clock synchronization under A.8.17. Record the configuration of each tool in version-controlled files so that the state of collection can be shown later. Confirm the exact configuration options and capabilities against each vendor's current documentation before relying on them.
Train responders on the procedure
Brief incident responders, system administrators and anyone who may be first on scene on the procedure, the custody form and the approved tools. Include the escalation route to legal or the investigations lead, and explain what must not be done, such as rebooting a host before volatile data is captured or altering logs to clean up an error. Record attendance and each person's acknowledgment of the procedure. The step is complete when every named responder has been trained and the training record is filed with the procedure's version number.
Test the procedure with a tabletop exercise
Run a tabletop exercise based on a realistic but invented scenario, such as an insider deleting files before resigning, and walk the responders through identification, collection, custody logging and storage. Record each gap the exercise exposes, including missing log sources, unclear authority to collect and custody steps that were skipped. Assign each gap an owner and a due date, then retest the affected steps. The output is a test record that lists the scenario, participants, findings, corrective actions and the date of the retest. Keep this record as evidence for the ISMS, and repeat the exercise after significant changes to systems or the incident process.

Chain of custody and integrity for logs and forensic images

Chain of custody is a written record of who handled a piece of digital evidence, when, why, and how its integrity was shown at each step. For A.5.28 Collection of evidence, an assessor will want to see that the procedure produces this record for logs, memory captures, disk images and exported case files, and that the record can be produced without reconstructing it from memory. In practice this means a case or ticket reference for each item, a named person for each transfer, a purpose for each access, and a cryptographic hash recorded when the item is acquired and checked again each time it moves. If a hash changes, the organization has to be able to say when and why. Confirm with your legal and incident response leads which hash algorithms they accept for evidence, because that choice is usually made by counsel or by the reviewing authority rather than by the engineering team.

Logs are only useful as evidence if their timestamps can be trusted. A log line that says an administrator changed a firewall rule at a particular time is weak if the sources disagree by several minutes, because the sequence of events across endpoints, identity providers and network devices is what an investigator reconstructs. This is why A.5.28 sits next to A.8.17 Clock synchronization: each log source should draw time from the same controlled reference, and the procedure should record that reference. Check how each platform in scope gets its time, whether the time zone is stored in UTC, and whether the collection tool records its own clock offset at acquisition.

A forensic image has to be taken without altering the source. The collection method should be read-only or write-blocked where the platform allows it, the source should be hashed before and after acquisition, and the acquisition itself should be logged with the tool name, version and operator. Live systems add a complication: running processes, memory and network state change constantly, so the procedure must say which volatile data is captured first and accept that a live capture is a snapshot, not a copy. Decide in advance who may authorize imaging a production system, how an outage is weighed against preserving evidence, and where the working copies are stored. Those decisions belong in the procedure before an incident starts, not during one.

Evidence artifacts that satisfy A.5.28

A.5.28 is tested through records, not intentions. The artifacts below show that the collection procedure exists, that it covers the right sources, that evidence stayed intact, and that the procedure has been exercised. Keep each one current between audits so it reflects the systems as they are today.

Evidence collection procedure

The written procedure defines what counts as evidence, who may collect it, which tools and steps apply to endpoints, servers, cloud accounts and applications, and when legal or HR must be involved. Auditors check that it is approved, version controlled and linked to the incident response process under A.5.26. Review it after every significant tooling or architecture change and after each real or simulated collection, recording the review date and owner.

Log source inventory

This register lists every system that produces evidence, its owner, log type, retention location and whether it forwards to central storage. Gaps here are the most common reason collections fail during an investigation. Reconcile the inventory against the asset inventory from A.5.9 at a set interval, and confirm that new cloud accounts and self-hosted services are added when they are provisioned.

Chain-of-custody records

Each item collected needs a record of who handled it, when, from where, for what purpose and where it was stored, with every transfer logged. Assessors ask for these records for a sample of collections, so a missing transfer entry can undermine an otherwise sound case. Use a fixed template or ticket field, and require a signed entry before any item leaves the evidence store.

Hash and integrity records

Cryptographic hashes recorded at acquisition let the organization show that an image, export or log bundle has not changed since collection. Store the hash values separately from the evidence, and re-verify them at intervals and before any handover. Confirm with your legal adviser which hash algorithms and verification steps they expect for your jurisdiction.

Collection tool logs and evidence store access

Logs from collection tools show which queries or artifacts ran, against which hosts and when, while access records for the evidence store show who opened, copied or deleted material. Together they prove the collection was controlled and that no one altered the evidence afterward. Restrict store access to named roles, review those access lists on a schedule, and retain tool logs for the same period as the evidence they describe.

Past collections and exercises

A register of past collections, including exercises run against test hosts, shows that the procedure works in practice and where it needs improvement. Record the scope, timing, participants, issues found and the follow-up actions raised. Run exercises at planned intervals so the register holds recent entries, and feed the lessons into the procedure under A.5.27.

What meeting A.5.28 costs in money and effort

This table breaks down the cost and effort components of meeting A.5.28 Collection of evidence, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request, since most of the cost sits in engineering time and ongoing upkeep rather than in licenses. No prices are shown because none are supplied for this topic.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Tooling and licenses	Recurring where subscription-based	Number of endpoints and log sources, and whether the collection tools are commercial or open source. Self-hosted open-source collectors such as osquery, Velociraptor and audit logging in Nextcloud or OpenBao carry no license fee, though hosting still costs money.	Itemized list of every licensed product, its metric (per host, per user or per log volume), renewal terms and the cost of hosting open-source components in your own environment.
Engineering time to build collection	One-time	Number of systems in scope, how many have native audit logging enabled, and whether forensic artifacts and queries must be written from scratch.	Fixed-scope deliverables listing which log sources, artifacts and audit trails are configured, and what is handed over at the end.
Retention and storage design	One-time setup, recurring storage	Retention length required by your contracts, regulators and legal advice, and the volume generated by each source. Longer retention multiplies storage cost.	Written retention schedule per log type, the storage estimate behind it and who approves changes to retention periods.
Chain of custody and integrity controls	One-time design, recurring operation	Number of evidence handling steps, whether hashing and access logging are automated, and how many people must sign off on each collection.	Description of how hashes, timestamps and access records are produced, and which steps remain manual.
Evidence upkeep	Recurring	Frequency of access reviews, log reviews and checks that retention and integrity controls still work after system changes.	Named owner and schedule for each recurring check, and whether upkeep is internal staff time or a retainer.
Exercises and collection tests	Recurring	Number of scenarios tested per year and whether tests involve production systems or a separate lab.	Test plan, the scenarios covered, the evidence each test produces and the people who must attend.
External forensic or legal review	Per engagement	Whether a dispute, regulator request or litigation is likely, and how much of the procedure must stand up in court. Scope of review drives the hours.	Named reviewer, what they will check, and whether the quote covers only the procedure or also review of a live case.
Auditor sampling time	Recurring at each audit cycle	Number of samples the auditor selects, how easily records can be retrieved, and whether evidence is organized before the audit starts.	Confirmation with the certification body of the sample sizes and evidence formats it expects, so the preparation work matches them.

Who owns evidence collection and what a partner can prepare

Your organization owns A.5.28. The control asks you to establish and implement procedures for identifying, collecting, acquiring and preserving evidence of information security events, and those procedures are your decisions. Your security lead, legal counsel and system owners decide what counts as an event worth preserving, who may authorize collection, when a legal hold applies, and who receives copies of the material. No partner or auditor can make those calls for you, because they carry the accountability for the outcome.

Procedure ownership: Approve the written procedure, name the roles that may start collection, and define the triggers, such as a confirmed incident or a legal request.
Custody decisions: Record who took possession of each item, when, from which system, and where it is stored, and keep that record with the item.
Legal hold calls: Decide with counsel when retention overrides normal deletion schedules, and when a hold is lifted.
Disclosure and access: Decide who may view preserved evidence and who may receive it outside the organization, including regulators and law enforcement.
Review: Confirm the procedure still matches your systems after each major change.

Check that the named owners can explain each custody step to an auditor without referring to a vendor or consultant.

Where organizations usually fall short on evidence collection

Most organizations have some logging and an incident process, so the gaps under A.5.28 Collection of evidence sit in the details: who decides to collect, how the material is handled afterward, and whether it holds up when someone tests it. Each card below names one gap an assessor is likely to probe and the check that closes it.

Procedures without triggers or owners

A collection procedure that says evidence should be preserved, but not what event starts collection or who authorizes it, leaves responders guessing under pressure. Assessors look for named triggers, such as a suspected compromise of a privileged account or a ransomware alert, and a named role that can order collection and sign off on it. Check that each trigger maps to an owner and a documented escalation path to the people who decide on legal action.

Logs with no custody trail

Log files copied to an analyst's workstation or shared drive lose their value if nobody can show who extracted them, when and under which case number. Chain of custody records the handover of each item from collection through storage and analysis. Check that every extract carries a record of who collected it, the hash or identifier at collection, and each transfer after that, so the evidence can be explained later in a disciplinary or legal setting.

Unsynchronized clocks

Evidence from several hosts is only useful if the timestamps line up. When endpoints, firewalls and applications drift from one another, the sequence of events in a timeline becomes unreliable and can be challenged. This ties directly to A.8.17 Clock synchronization. Check that every system in the collection scope uses a common time source and that the time offset is recorded alongside any extract taken from a device.

Retention shorter than the response window

Logs rotated out or overwritten before an investigation starts cannot support A.5.28, however good the procedure is. Retention periods should be set against how long it takes to detect, investigate and close an incident, plus the time a legal process may need. Check the retention settings on each log source against the incident response timeline, and confirm that preserved copies are protected from routine deletion when a case opens.

No integrity checks on images

Disk and memory images that are never hashed cannot show they were unchanged between acquisition and analysis. Hashing at the point of acquisition, and rehashing before each examination, gives a verifiable basis for the evidence. Check that the acquisition tool records the hash algorithm and value, that the hash is stored separately from the image, and that a verification step is part of the analysis procedure.

Evidence collected but never exercised

A procedure that has never been run against a realistic scenario often breaks at the first real case, where an access path is missing or a tool is unavailable. Tabletop exercises and technical drills show whether triggers, owners, custody records and retention work together. Check that at least one collection exercise per cycle covers the full path from detection to a sealed evidence package, and that the lessons feed back into the procedure under A.5.27.

Questions buyers ask about A.5.28 cost, effort and outsourcing

How much extra effort does A.5.28 add on top of incident management?

Usually less than the incident process itself, because A.5.28 adds rules for how evidence is handled rather than new events to respond to. The added work is defining which sources matter for each incident type, writing collection and preservation steps, recording chain of custody, and testing that a log export or forensic image can be verified later. Most of the effort is one-time design, followed by recurring checks that collection tools still run and that retention settings have not drifted. Your own incident records and past events will show how much collection work your team already does informally, which is the best starting point for estimating the increment.

Can a small team run evidence collection in-house?

Yes, if the team has someone who understands logging and incident response and the procedure is kept proportionate to the organization's size and risk. A small team can run the procedure in-house by naming one owner, limiting the source list to systems that would matter in a real incident, and using existing log platforms rather than buying specialist tooling. The harder part is keeping the procedure exercised. If the same two people handle every incident, evidence handling will depend on them, so cross-training and a written checklist matter more than tool choice. Ask whether your auditor expects a documented exercise, and plan for one at least once.

What should a partner prepare, and what must stay internal?

A partner can prepare the technical parts: collection scripts or queries, forwarding and retention configuration, hashing and storage workflows, and documented procedures that match your systems. The organization must keep ownership of the decisions and the people who act on them:

How long does preparation take, and does it depend on the number of log sources?

Yes, the number of sources is one of the main drivers, along with how many environments are in scope, whether logs already reach a central store, and how many people must approve procedures. A short list of well-understood systems is far quicker to document and test than a large estate with several cloud accounts and on-premises networks. No general duration applies, so ask a provider to give a timeline tied to a named source list and to state which sources are excluded. Treat any figure given without a source list as an opening guess to be checked.

Will an auditor test whether evidence is legally admissible?

Auditors check whether the procedure exists, is followed and produces records that show integrity, such as hashes, timestamps and handling logs. They generally do not give a legal opinion on admissibility, which depends on jurisdiction, the case and the court. Your legal counsel should confirm what standard of handling your sector and region expect. Avoid claiming in the Statement of Applicability or in customer documents that evidence is admissible in court, because that statement is a legal conclusion you cannot obtain from an auditor. Describe the controls and the records they produce instead.

What should we ask a partner for in a fixed-scope quote?

Ask for the written scope before any figure. A useful quote lists the systems and log sources in scope, the collection tools and whether they are self-hosted in your environment, the procedures and templates to be delivered, the testing that will show evidence can be collected and verified, and what the organization must provide, such as access, named approvers and staff time. Also ask what is excluded, how changes to scope are priced, whether ongoing support is separate, and who will be the contact for an auditor. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides a quote from that scope.

Do we need specialist forensic tooling to meet A.5.28?

Not necessarily. A.5.28 asks for procedures that identify, collect, acquire and preserve evidence, so the tooling should match the sources you actually need. Many organizations start with the logging and query tools they already run, then add specialist forensic capability only where a risk assessment shows a need, such as endpoint investigation at scale. Open-source options such as osquery for host queries, Velociraptor for endpoint artifact collection, and the audit logs of self-hosted applications can cover many cases. Confirm each tool's capabilities against its documentation in your own environment before relying on it.

How DeployOpen prepares evidence collection for A.5.28

DeployOpen's part of A.5.28 starts with a written scope that lists which log and evidence sources the organization needs to preserve: endpoint telemetry, identity and access events, application audit trails, secrets management logs, cloud control plane records and the incident tickets that tie them together. The agreement names each source, its owner inside the client, where it lives and how long it must be kept. Because most engagements are fixed-scope, these decisions are settled before any collector is deployed, so the client can see exactly what will be gathered and what is left out. The organization still owns the control itself, including the decision about which events count as information security events and who may authorize collection. An independent auditor, not DeployOpen, decides whether the resulting evidence is sufficient.

Within the client's own cloud accounts, data centers or air-gapped network, DeployOpen builds the collection and retention layer from self-hosted open-source components. Depending on the scope, this may include osquery for scheduled host queries across a fleet, Velociraptor for collecting defined forensic artifacts from endpoints and hunting across groups of systems, and the audit logs of platforms such as Nextcloud and OpenBao. Each source is configured to write to a central, access-restricted store with time synchronization, and retention periods follow the client's own schedule. Clients should confirm each platform's current logging options and any integrity features against the vendor documentation for their version, since those details change between releases.

The procedures and custody records are the part auditors test most closely. DeployOpen drafts the collection procedure, the request and approval steps for pulling forensic images or log extracts, and a custody form that records who collected each item, when, with which tool, its hash at acquisition, and every later transfer. Exercise testing then runs a simulated event through the chain, from detection to a preserved, verifiable package, so gaps show up before a real incident or a legal request. The organization decides what to do with the findings. Ask any implementation partner to show the written scope, the custody template and the exercise report before signing, and ask the auditor to confirm which of these records it will sample.

A.5.28 Collection of evidence