Collection of evidence

ISO/IEC 27017 Clause 16.1.7 requires you to define and follow procedures to identify, collect, acquire, and preserve information that may serve as evidence in cloud environments. To operationalize it fast, standardize “what to collect, who collects it, how to preserve it, and how to prove chain of custody” across your cloud providers, SaaS tools, and internal teams. ¹

Key takeaways:

• Evidence collection in cloud is a documented, repeatable process with clear roles, tooling, and chain-of-custody records. ¹
• Your procedures must cover identification, collection, acquisition, and preservation, not just “logging.” ¹
• You need provider-ready workflows for multi-tenant and distributed systems, including how to request evidence from third parties and how to store it immutably. ¹

“Collection of evidence” is the control that determines whether your incident response ends with a defensible timeline and actionable findings, or with gaps you cannot explain to auditors, customers, counsel, or law enforcement. In cloud environments, the hard part is rarely intent; it’s mechanics. Data is distributed across services, access is role-based, systems are multi-tenant, and key forensic artifacts may sit with a cloud service provider or SaaS third party you don’t control directly.

ISO/IEC 27017:2015 Clause 16.1.7 tells you to define and apply procedures for identification, collection, acquisition, and preservation of information that can serve as evidence, specifically in cloud computing environments. ¹ For a CCO or GRC lead, the fastest path is to make this a “forensic readiness” requirement: establish what evidence types matter, pre-authorize the right access paths, standardize collection steps, and retain proof that evidence was handled properly.

This page gives you requirement-level guidance you can put into tickets, playbooks, third-party contract language, and audit binders immediately.

Regulatory text

Requirement (verbatim): “The organization shall define and apply procedures for the identification, collection, acquisition and preservation of information, which can serve as evidence, in cloud computing environments.” ¹

What the operator must do: Maintain written, actionable procedures and follow them in practice. Those procedures must cover:

• Identification of potential evidence sources in cloud systems
• Collection of relevant information (logs, snapshots, records)
• Acquisition (obtaining evidence from the system or third party in a reliable manner)
• Preservation so it remains intact, attributable, and defensible (including chain of custody) ¹

Plain-English interpretation

You must be able to answer, consistently and provably: “If something happens in the cloud, how do we gather evidence that stands up to scrutiny, and how do we prevent alteration or loss?” That means you predefine evidence sources across IaaS/PaaS/SaaS, control who can collect them, document how you export or snapshot them, and store them in a way that preserves integrity and traceability.

Who it applies to (entity and operational context)

This requirement applies to:

• Cloud Service Providers (CSPs): You host or operate cloud services and must support evidence collection for your own investigations and, where applicable, for customer incidents. ¹
• Cloud Service Customers: You rely on cloud services and must be able to collect and preserve evidence from your tenant and from relevant cloud control planes, often with third-party involvement. ¹

Operationally, it matters most when:

• You run regulated workloads in cloud (security incidents trigger reporting and litigation risk).
• You depend on SaaS third parties where logs and admin actions are stored outside your environment.
• You have shared responsibility boundaries (provider has some evidence; you have other evidence).

What you actually need to do (step-by-step)

1) Define your evidence scope and triggers

Create a short “Evidence Collection Standard” aligned to incident severity and legal/regulatory triggers.

• Define incident categories that require formal evidence handling (e.g., suspected intrusion, fraud, insider threat, data exfiltration, customer-impacting outage with potential claims).
• Define which systems are in scope (cloud accounts/subscriptions, SaaS tenants, identity providers, endpoint platforms, CI/CD, ticketing/chat).

Deliverable: Evidence Collection Standard + incident classification mapping. ¹

2) Inventory evidence sources across cloud layers

Build an “Evidence Source Register” that is specific to cloud:

• Control plane logs: admin actions, IAM changes, API calls
• Data plane logs: application, database, storage access logs
• Identity evidence: SSO logs, MFA events, privileged role assignments
• Workload artifacts: VM/container snapshots, disk images (where feasible), configuration states
• SaaS audit trails: admin audit logs, message/email exports, file access logs
• Network evidence: flow logs, firewall logs, WAF events

Make the register practical: where it lives, who administers it, retention, export method, and access prerequisites.

Deliverable: Evidence Source Register with owners and collection method per source. ¹

3) Establish roles, authority, and separation of duties

Write down:

• Who can declare an evidence collection event (Incident Commander, Security lead, Legal).
• Who can perform collection (Forensics lead, Cloud security engineer).
• Who can approve access elevation and provider requests.
• Who maintains custody records.

Add guardrails: break-glass access, approvals, and logging of collector actions. This prevents “the investigator changed the evidence” problems.

Deliverable: RACI for evidence handling and privileged access procedure tied to evidence events. ¹

4) Standardize collection and acquisition workflows

Create repeatable runbooks per platform type:

• IaaS/PaaS runbook: export relevant logs; capture configuration state; take snapshots; preserve metadata (timestamps, resource IDs); record commands executed.
• SaaS runbook: export audit logs and relevant records; document limitations (what cannot be exported); request provider-side logs if needed.
• Third-party request runbook: template for requesting evidence from a provider, including time window, tenant identifiers, log types, format, and delivery method.

Key practice: collect “supporting context” (who collected, from where, with what permissions, exact time range, hash/signature if you use it).

Deliverable: Platform runbooks + third-party evidence request templates. ¹

5) Preserve evidence with integrity and traceability

Preservation should address:

• Immutability: write-once storage or controlled repository with strict permissions.
• Access logging: every view/download is logged.
• Custody records: chain-of-custody form or system record capturing transfer and storage.
• Time synchronization: document time source assumptions to support timeline reconstruction.

Deliverable: Evidence repository procedure + chain-of-custody template + access controls configuration evidence. ¹

6) Prove you “apply” the procedures

Auditors will look for execution, not just documentation:

• Tabletop exercises that include evidence handling steps
• One or more completed evidence collection packages from a real incident or simulation
• Training completion for responders and cloud admins

If you use a GRC system or workflow tool, attach artifacts to the incident record so the audit trail is automatic. Daydream can help by turning your evidence register, runbooks, and custody steps into assigned workflows with consistent artifact capture, which reduces gaps during a real incident.

Required evidence and artifacts to retain

Use this as your audit binder checklist:

Core governance artifacts

• Evidence Collection Standard / procedure document ¹
• Evidence Source Register (cloud services, SaaS tenants, log sources, owners, retention, export method)
• RACI and access authority for evidence collection
• Third-party contact paths and escalation procedures for evidence requests

Operational artifacts ¹

• Incident ticket or case record referencing the evidence collection trigger
• Chain-of-custody record (collector, date/time, source, transfer path, storage location)
• Evidence package index (what files/exports/snapshots were collected)
• Administrative access logs for collectors (break-glass approvals, role grants, API calls)
• Proof of preservation controls (repository permissions, immutable storage settings, access logs)

Validation artifacts

• Tabletop/exercise record including evidence steps
• Training record for responders and cloud administrators

Common exam/audit questions and hangups

• “Show me your evidence collection procedure and where it is used during incidents.” Expect follow-up: “Show an incident where you followed it.” ¹
• “How do you handle evidence when the cloud provider holds the logs?” Auditors want to see a documented request workflow and proof it works.
• “Who can collect evidence, and how do you prevent tampering?” This drives review of privileged access controls and logging.
• “How do you preserve timestamps and correlate across systems?” Have a consistent approach for time sources and documentation.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating ‘evidence’ as ‘logs.’ Fix: include snapshots, configuration state, identity events, and SaaS audit trails in the evidence register.
• Mistake: No chain-of-custody trail. Fix: require a custody record for every collection, even internal-only investigations.
• Mistake: Evidence collectors have broad admin rights all the time. Fix: break-glass roles with approvals and strong logging tied to incidents.
• Mistake: No third-party evidence pathway. Fix: prebuild provider request templates and test them during exercises.
• Mistake: Procedures exist but aren’t used. Fix: embed steps into the incident workflow so evidence tasks are mandatory checklists with artifact uploads.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat risk as practical and defensibility-driven rather than tied to a specific cited regulator action. Weak evidence handling creates compounding exposure: you may be unable to confirm scope, support required reporting, defend customer claims, or pursue legal remedies. The control is also a credibility test during audits and customer due diligence because it reflects incident maturity in cloud environments. ¹

Practical execution plan (30/60/90)

Use phases rather than fixed timelines if your environment is large.

Immediate (first phase)

• Assign an owner for evidence handling (Security + Legal point of contact).
• Draft the Evidence Collection Standard and chain-of-custody template.
• Identify your top cloud platforms and top SaaS tenants to include in the initial Evidence Source Register. ¹

Near-term (next phase)

• Build platform runbooks for each major cloud and SaaS environment.
• Implement or confirm an evidence repository with strict access control and tamper-resistant storage characteristics.
• Create third-party evidence request templates and escalation paths for your critical providers. ¹

Operationalize (ongoing phase)

• Run a tabletop that forces evidence collection (include provider evidence requests).
• Review one completed evidence package for completeness and custody traceability.
• Add evidence collection checkpoints into incident tooling so collectors must attach artifacts before closing a case.

Frequently Asked Questions

Do we need a full digital forensics program to meet the collection of evidence requirement?

You need defined and applied procedures for identification, collection, acquisition, and preservation of evidence in cloud environments, not a lab-grade forensics capability. Right-size by focusing on repeatable runbooks, custody records, and provider request workflows. ¹

What counts as “evidence” in a SaaS incident where we can’t image disks?

Evidence can include SaaS audit logs, admin activity, access logs, exported records, configuration snapshots, and provider-supplied reports. Your procedure should define which SaaS artifacts you can acquire and how you preserve them with traceability. ¹

How do we handle evidence when a cloud provider controls key logs?

Document an acquisition process for third-party evidence: what you request, how you authenticate the request, how evidence is delivered, and how you record custody. Test the workflow so you can show it works during audits. ¹

Who should own chain of custody: Legal, Security, or GRC?

Security typically executes collection, Legal often sets defensibility expectations, and GRC makes it auditable and consistent. Assign a single operational owner for custody records and require Legal involvement when matters may become disputes or law enforcement referrals. ¹

How do we prove we “apply” the procedures if we haven’t had a major incident?

Run a tabletop or simulation that produces a complete evidence package: register references, runbook steps, custody record, and preserved exports. Auditors accept exercised procedures when real incidents are unavailable, as long as artifacts show execution. ¹

Can our ticketing system serve as the evidence record?

Yes, if the ticket captures who collected what, when, from where, approvals for access elevation, and links to the preserved evidence in a controlled repository. Ensure the ticket itself is access-controlled and has an immutable audit trail. ¹

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services