Skip to content

Glossary · Digital forensics

Cloud forensics

Also called: Cloud investigation, SaaS forensics

Cloud forensics is the collection and analysis of evidence held by cloud and SaaS providers rather than on a device you can seize. There is nothing to image, so integrity rests on documented API or admin-console collection, provider audit logs, and hashing the exported output.

What changes when there is no device

Traditional digital forensics rests on a physical premise: obtain the storage, write-protect it, image it, verify the image against the source. None of that is available in the cloud. The storage is shared infrastructure the provider will not surrender, and no forensic image of it exists to be made.

Integrity therefore has to be established differently. What substitutes is documentation: which account performed the export, through which interface, on what date, against what parameters — plus a hash of the exported output so the collected set can be verified from that point onward. The chain starts at collection rather than at seizure.

Possession, custody and control

A recurring threshold question is whether a party even has the right to produce cloud data. The answer is usually yes for a corporate tenancy the party administers, and much less clear for a personal account, a third party's system, or data held by a vendor under a contract that does not address litigation.

Where the provider holds data the party cannot compel, the routes are a subpoena to the provider or the account holder's consent — and providers vary widely in what they will produce, how quickly, and in what format. Stored Communications Act constraints also limit what a civil subpoena can obtain from a provider directly, which surprises parties who assume a subpoena solves the problem.

Logs are the evidence, and they expire

In a cloud investigation the audit log frequently matters more than the content. Who accessed what, from where, when, and what they did with it is exactly the question in a data-theft or unauthorised-access matter, and it is answerable only from provider-side records.

The difficulty is retention. Default audit-log retention on major platforms is often measured in weeks or a few months, longer retention is a configuration decision most organisations have never made, and some detailed logging is only available on higher licence tiers. Organisations regularly discover during an incident that the period they need to reconstruct predates anything they still hold.

If there is any prospect of investigation, extending log retention is the cheapest preparatory step available and it has to be taken in advance.

Collection routes, in order of preference

  1. The platform's own compliance or eDiscovery interface, where one exists. Built for the purpose, produces a defensible record, and preserves more metadata than the alternatives.
  2. Administrative export or API collection, documented as to parameters and scope.
  3. A subpoena to the provider, slow and often narrow.
  4. Manual download, which strips metadata, has no record, and should be the last resort.

Where cloud data hides

Version history, deleted-item recovery areas, shared-link records, third-party application connections, and the sync clients installed on end-user devices. That last one matters: a cloud file synced to a laptop leaves local artifacts that may survive after the cloud copy is deleted, which is why device and cloud collection are complements rather than alternatives.

From our work

Dealing with cloud forensics in a live matter?

Our examiners and testifying experts work these questions for a living. Tell us what you're facing.

Reviewed by Law & Forensics. See our editorial standards.