Collecting Evidence From Cloud Services

Determine the Custodian and Collection Path

Collection of cloud evidence rests first on a factual and legal question: who holds the authority to produce the data? The lawful custodian is the owner, person, or enterprise with legal authority over the data. [1] This determination drives the entire collection strategy.

When an enterprise uses a cloud storage provider—such as a business using Microsoft 365, Google Workspace, or Salesforce—and the enterprise itself is not the subject of investigation, the ordinary collection path is to request an export directly from the enterprise custodian, ideally using their own credentials and the provider's native export tools. [1] This approach is often faster, requires no legal process, and preserves the chain of custody through a known actor.

The analysis changes when the custodian is the subject of investigation. When either the enterprise or the cloud provider is the subject of investigation, or when approaching the enterprise might compromise the investigation, the preferred method is to seek the data through legal process directed to the cloud service provider itself. [1] In the federal system, this typically occurs through a warrant issued under 18 U.S.C. § 2703, which permits a court to issue a warrant for records held by a cloud provider located in another district and authorizes the provider to conduct the search. [2] State and local practitioners should consult applicable statutes governing their jurisdiction.

The choice between these paths affects not only who produces the export but what legal authority must be demonstrated and what authentication evidence will later be available at trial or in discovery.

Understand the Limits of Provider Exports

Data returned by a cloud service provider's native export tools may not be as complete as if the same data had been obtained directly from the provider through legal process and formal forensic acquisition. [1] This incomplete nature deserves explicit documentation. Provider export tools are designed principally for user accessibility and recovery—a user who wishes to migrate their mail or files to another system—not for forensic completeness or the capture of system artifacts, metadata, or account administration records.

When the lawful custodian consents, or when you possess appropriate credentials and legal authority to act, use of the provider's native tools is a best practice. [1] These tools are transparent, often audited, and produce exports that can be traced back to the provider's official processes. But you must understand what they do and, critically, what they omit.

A typical mailbox export contains message bodies and attached files, but it may exclude or truncate server-side rules, delegate access logs, recoverable deleted items in an archive folder, detailed header information, or metadata about when items were moved, forwarded, or accessed. A file export may contain the current version of documents but not version history, deletion events, share permissions at the time of export, or access logs. These omissions are not errors; they are choices built into the tool. Document them explicitly.

Collect Account-Level Artifacts Separately

No export of mailbox contents or file stores will capture account-level artifacts—data that describe how the account itself is configured and used. [1] These items include login history and geographic anomalies, account settings and security configurations, delegation structures and recovery options, connected devices and mobile app authorizations, and security events flagged by the provider's own threat detection.

These artifacts must be specifically requested from the custodian or the provider. In many civil discovery contexts, parties exchange information about key custodians of electronically stored information and relevant retention policies; requirements and best practices vary by jurisdiction and court. [6] [7] [8] In federal criminal cases, the Recommendations for ESI Discovery in Federal Criminal Cases provide a framework for planning and producing ESI, including the identification of the custodians and systems from which data will be extracted. [4]

When collecting from an enterprise custodian with consent, ask for a comprehensive account configuration export—a formal report from the provider's administrative console showing all account settings, permissions, and recent activity at the moment of collection. This becomes part of your baseline.

Observe Preservation Deadlines and Provider Retention Policies

Under 18 U.S.C. § 2703(f), a provider must, at the request of a governmental entity, preserve records and other evidence in its possession pending the issuance of legal process. [3] Preservation lasts 90 days and can be extended for another 90 days on a renewed request. The mechanism is available only to the government. A civil litigant cannot use § 2703(f), and the Stored Communications Act (18 U.S.C. § 2702) generally bars a provider from disclosing the contents of communications to a private party, so civil parties ordinarily obtain content from the account holder—through the account holder's own export, or discovery directed to that party. Whatever the route, confirm the provider's retention window early and put any preservation request in writing.

If legal process is delayed or the investigation scope expands, critical logs—authentication records, account access events, or metadata—may be overwritten by routine provider data retention cycles before collection occurs. Provider retention policies vary substantially by service type and business model. You must confirm retention windows with the provider before planning your collection and include this in your written preservation request.

Document the Export Completely

Accurate documentation of how, when, and by whom the export occurred is as important as the export itself. Your record must capture:

Method and version. Note the specific tool used (e.g., "Microsoft 365 eDiscovery export via the Compliance Portal, version [X.X.X]"), the date it was run, and by whom. If the custodian ran the export themselves, note their name, title, and the date and time they performed it.

Scope. What data types were requested and exported—mail, calendar, contacts, files, shared drives, teams, or other formats? What date range does the export cover? Were attachments included? Were deleted items included? State this explicitly.

Service provider's local time. Record the date and time of export using the service provider's recorded local time, and note the timezone. [1] Examiners should use their forensic knowledge to identify any discrepancies between the export timestamp and the metadata within the exported data, and if needed, conduct further artifact analysis. [1] If a discrepancy appears—for instance, message timestamps suggesting they were sent before the export began, or file modification dates after export completion—document the discrepancy and your investigation of it.

Operator credentials and authorization. Who executed the export, and on what authority? If done by the custodian, note their identity and method (direct provider portal login, delegated admin access, etc.). If done via legal process by the provider, note the warrant number or other legal instrument.

Manifest and exclusions. Provide an explicit accounting of what the export contains: the number of messages, files, or items; hash values if available; and the total volume in bytes or gigabytes. Explicitly state what was not exported—what was excluded by tool design or by deliberate choice. "The export includes mail from January 1, 20XX to December 31, 20XX, but excludes the Deleted Items and Archive folders, which the provider [did/did not retain at time of export]." "Shared file permissions and version history were not exported with the file export tool."

Account baseline. Capture account settings, metadata structures, and configuration at the moment of export. This becomes part of your evidence record and is critical to establishing the context of what the export contains.

If the export is large or complex—thousands of files, multiple accounts, or data spanning years—consider engaging a digital forensics examiner to verify the completeness and integrity of the export and to produce a formal collection report. This is particularly important if the evidence will be contested or if the case involves allegations that data was hidden, destroyed, or altered.

Legal Basis for Collection and Admissibility

Under the Federal Rules of Civil Procedure, electronically stored information stands on equal footing with paper documents. [5] Discovery under Rule 34 applies to information that is fixed in a tangible form and to information that is stored in a medium from which it can be retrieved and examined. [5] This means cloud-held data is discoverable; the method of collection must be appropriate to the legal authority you possess.

Authentication of cloud evidence is governed by the Federal Rules of Evidence. The proponent must produce evidence sufficient to support a finding that the item is what the proponent claims it is. [9] A cloud export is ordinarily authenticated through testimony from someone with knowledge of the account or the export process—often the custodian or the examiner who documented the collection—about the accuracy of the export and the chain of custody. Records the provider itself keeps, such as subscriber or access logs, are usually authenticated by a provider custodian's certification under Rule 902(11) or by testimony.

Careful documentation of the collection process supports the admissibility of evidence. A court will examine how the evidence was collected, by whom, under what authority, and with what safeguards against alteration or loss. Gaps in documentation invite challenge and may limit a court's ability to rely on the evidence.