The data-driven approach: Drafting cloud search warrants around the data providers actually keep

By Justin Fitzsimmons

Cloud search warrants should not begin with a generic demand for everything associated with an account. They should begin with a far more concrete question: What does this provider actually keep?

That question changes the drafting process. Instead of relying on boilerplate language or treating a cloud account as an expansive digital file cabinet, investigators and prosecutors should build the warrant around the provider’s own descriptions of its services and the specific types of data relevant to the investigation. The warrant should include a clear explanation of how each requested type of data may help prove the elements of the offense, establish who controlled the account or associated device when the evidence was created, or both.

This is the data-driven approach (DDA) to search warrants for digital evidence. It requires slightly more work at the beginning of the warrant process, but that work produces a warrant that is easier for a court to understand, more closely tied to probable cause and particularity, and better suited to the way cloud data is actually created and stored.

For every requested type of data, the affidavit should explain what the data is, why it is relevant, how it is created, why there is reason to believe the provider possesses it, and how it will help establish user attribution.

Start with the data, not the account

Smartphone, tablet, computer, application, and cloud accounts operate as parts of a connected digital ecosystem. A user may compose a message on one device, synchronize it through an application, store an attachment with a separate provider, and generate account, device, network, and security records along the way. Some evidence may remain on the device. Other evidence may exist only with the provider. Connection data may reside with a cellular carrier, internet service provider, or Wi-Fi network operator. Still other evidence may appear in several places but contain different metadata or retention histories.

The practical starting point is therefore not “search the account.” It’s found in three key questions:

1. Where is the relevant data stored?
2. How did the data get there?
3. What legal process provides lawful access?

Those three questions identify the proper source and legal process. Once investigators determine that relevant data may be held by a provider and that a warrant is the appropriate process, the five question DDA framework supplies the probable cause and particularity showing needed to justify each requested type of data.

Use the provider’s own disclosures as the roadmap

Cloud providers routinely publish documents and user-facing tools, including archiving or data export tools, that describe the information they collect, generate, use, retain, synchronize, and make available to account holders. Before drafting the affidavit, investigators should identify the version in effect during the relevant period and review, at a minimum:

• Terms of service
• Privacy policy
• End user license agreement, when applicable
• Cookie policy
• Advertising ID, or ADID, policy
• The provider’s law-enforcement guidelines, records guide, retention disclosures, and preservation instructions, when available
• The provider’s user archiving or data export tool

These materials serve different purposes, but together they can identify specific types of data the provider says it keeps, the functions that create the data, the devices or identifiers associated with it, and the ways an account holder can access or export it. They may also reveal information an investigator might never have known to request. Including dated exhibits places the technical basis for the request before the reviewing court and preserves the provider representation on which the affiant relied.

Drafting suggestion: Separate technical exhibits from warrant scope attachments

Attach the relevant provider materials to the affidavit and identify the technical proposition supported by each exhibit. If those materials are incorporated into both the affidavit and warrant, state that they are incorporated solely to support and clarify the identified technical propositions and do not expand the records the provider must disclose or the evidence the investigators may seek.

A separate attachment should define the provider’s obligations and the investigator’s authority to examine the returned data. The affidavit should expressly state what each document represents, for example, “the contents of the ‘privacy policy, or terms of service, etc., is attached and incorporated herein in its entirety, by reference to both the affidavit and the search warrant.” Each jurisdiction has its own version of the necessary language that will trigger extrinsic information being included in the four corners of your warrant for purposes of a motion to suppress. Include the effective date or capture date for each exhibit.

The attachment matters for more than just convenience. Provider webpages and user tools change. A screenshot documents what the provider represented when the warrant was prepared. If the criminal conduct occurred prior to the current adoption date of the provider’s policy, the affiant should preserve and attach the policy in effect at the time of the offense. The incorporated exhibit also gives the reviewing court the same technical source the investigator relied upon, rather than asking the court to accept a bare assertion about what may exist in the account.

The affidavit should not overstate what a policy proves. A policy may establish that the provider collects or may retain a particular type of data. It does not guarantee that the data exists for the target account, remains within the provider’s retention period, or can be produced in the same form shown to a user. The affidavit should accurately describe the provider’s representation and then explain the case-specific reason to believe responsive records will be found.

User data export tools reveal the structure and contents of a cloud account

A user data export tool enables an account holder to download or export information associated with the account. Google Takeout and comparable download tools offered by other providers serve as evidentiary roadmaps for investigators. They identify the provider’s own names for products, export entries, and data sources and may explain what an export contains. A user’s ability to export data, however, does not by itself establish that the provider can decrypt or produce the same information in response to subsequent law enforcement process.

In the Google Takeout screenshot shown in Legal Unpacked Episode 8, Google displayed 62 selectable Google products or export entries. That number should not be treated as permanent. Provider offerings change, products are added or discontinued, names and descriptions change, and the entries displayed may vary by account or based on user permissions.

As of August 3, 2026, Google continued to describe Web & App Activity as saving activity from certain Google services and associated information, while separately rolling out a Search Services History setting for Search, Maps, Shopping, Flights, Hotels, Translate, and News. Google also stated that Timeline visits and routes are saved separately on each eligible signed-in device and that a user may elect to store an encrypted backup on Google’s servers. These representations do not establish that responsive records exist for a particular account or that Google can produce an encrypted backup in readable form.

These changing representations demonstrate a central point: relevant activity or location data may reside on a device, in provider-held storage, or both. Legal process must follow the data’s actual location and what the provider can produce, rather than an assumption based on an earlier product name or storage model.

The point is the method: preserve a dated screenshot, identify the provider’s description of each potentially relevant source, and request only the data supported by the investigation. A provider-defined product or export label is the beginning of particularity, not the end. Selecting ‘Gmail’ or ‘Google Drive’ identifies a potential source of evidence, but the warrant must still identify the specific types of data sought from that source and the evidence investigators are authorized to examine them for.

An investigator may determine that only eight or nine of the displayed products or export entries matter to the case. Within those selections, the warrant should identify the precise data sought, such as Gmail message content and headers, Drive files and sharing metadata, Google Photos content and metadata, Calendar events, Contacts records, Chrome activity, YouTube history, account registration records, or location-related information, with date and time limits appropriate to the investigation. The appropriate selection depends on the offense, the known facts, the account settings, the provider’s current documentation, and the evidence already developed.

The five questions to answer for every requested type of data

For each type of data, law enforcement seeks to seize and analyze, the affidavit should answer five data-driven questions. The warrant and its incorporated attachments should then convert those answers into the specific records the provider must disclose, and the evidence investigators are authorized to seek within those records. The five questions should not appear once as a generalized discussion of the account. They should be applied to each requested type of data.

Explaining digital artifacts: digital footprints and digital exhaust

User attribution is usually not established by a single record. It’s built by combining digital artifacts that reflect both intentional activity and the system activity surrounding it. For purposes of this framework, those artifacts can be understood as digital footprints and digital exhaust.

Putting the digital footprints and digital exhaust framework into practice

Suppose a suspect uses a coffee ordering application near a crime scene, reloads a stored-value account through a payment service, places an order, receives directions, and later has the device reconnect to a previously joined Wi-Fi network. The searches, account reload, and order are digital footprints reflecting intentional activity. Login and session records, device identifiers, payment records, location metadata, synchronization activity, and network records are digital exhaust generated around those actions. Examined together, the artifacts may establish both what occurred and who controlled the relevant device and accounts at the time.

Digital footprints

Digital footprints are artifacts created through an intentional user action. They include actions like:

• Sending a message
• Uploading a photograph
• Creating a calendar event
• Saving a file
• Entering a search term
• Changing a setting
• Adding a contact

Like footprints in wet concrete, they reflect an act taken by a user. The artifact may help prove what was done, communicated, possessed, searched for, or planned.

Digital exhaust

Digital exhaust is generated by the device, application, network, or provider as a consequence of use. It can include:

• Login records
• IP addresses
• Device associations
• Browser information
• Cookies
• Advertising identifiers
• Session records
• Synchronization activity
• Security events
• Account recovery changes
• Records showing interactions with provider services

The user may not intentionally create each record, but the surrounding systems generate it as the account is accessed and used.

Build user attribution around control at the relevant time

The response to the fifth question should be written with the investigation, the trial, and the permitted scope of review in mind. The issue is not simply whether the defendant’s name appears on the account. The issue is whether the available artifacts support the conclusion that the defendant controlled the account when the relevant message, file, search, upload, or other evidence was created.

Potential attribution evidence may include:

• Subscriber information and verified contact information
• Login IP addresses and session records
• Devices, browsers, applications, or advertising identifiers associated with the account
• Recovery email addresses and telephone numbers
• Security alerts, password changes, and account-recovery events
• Cookies or persistent session information associated with repeated use
• Content reflecting knowledge unique to the user
• Photographs, contacts, calendars, payment records, or communications that corroborate identity
• Location, network, or synchronization records that place the account activity with a known device or user
• Metadata from existing files that provides location or temporal information related to the elements of the underlying investigation.

The affidavit should explain how these artifacts work together. No single fact may be conclusive. Woven together, however, they can connect the relevant activity to a particular person and undermine a claim that the account was merely registered in that person’s name or was accessible to or in use by someone else.

User attribution is not a freestanding justification to search every record associated with an account. Although United States v. Holcomb involved a computer rather than a cloud account, its reasoning provides an important warning. The Ninth Circuit concluded that a dominion and control provision was overbroad and insufficiently particular because it lacked meaningful limitations by time and type of evidence and the affidavit did not establish probable cause for a limitless attribution search. The affidavit must therefore establish why attribution evidence is relevant in the particular investigation and confine that search by data type, time when possible, and other objective criteria. When an attribution artifact lacks usable temporal metadata, the affidavit should identify that technical limitation and explain the narrower features investigators are authorized to examine.

A model paragraph for one requested type of data

The following language is illustrative, not jurisdiction-specific form language. It demonstrates how the five questions can be integrated into one coherent paragraph rather than presented as disconnected conclusions.

The same process should be repeated for each selected type of data. The explanation will change because the data, creation mechanism, storage basis, relevance, and attribution value are different. Repeating generic language defeats the purpose of the framework.

Separate what the provider must disclose from what investigators may analyze

A cloud warrant should distinguish between the records the provider is commanded to disclose, and the evidence investigators are authorized to search for within those records. The two descriptions should correspond, but they perform different functions.

The production language identifies the specific types of data the provider must produce. The search language explains what investigators may examine those records to find, such as communications proving an element of the offense, files demonstrating possession or knowledge, or digital exhaust establishing account control. A production command that lists specific data but authorizes an unlimited evidentiary search is incomplete. A narrow evidentiary search that commands the provider to disclose everything associated with the account creates the opposite problem.

Tailor temporal limitations to each type of data requested

Temporal limits are an important means of tailoring a cloud warrant. When a record contains reliable date or time information and the probable cause showing concerns a defined period, the warrant should ordinarily state the appropriate period. The problem arises when a single calendar window is applied to every requested type of data without considering how that data is created or stored.

Digital evidence does not always carry an intrinsic creation date or time. A contact record may identify a person, telephone number, or email address without preserving when the contact was first added. A photograph may have lost or never contained usable metadata. A current account setting may show a recovery address or linked device without identifying the precise moment the relationship began. A browser or application database may retain only a last-used value. Provider exports may preserve content separately from the metadata that once described it. System records may be overwritten, summarized, synchronized, or retained according to a provider-controlled schedule.

A rigid date or time filter can therefore remove evidence that is relevant to attribution even though the evidence itself cannot be searched by creation date. Suppose the charged communication falls within a seven-day period. Login records from that period may be directly limited by time. But an undated contact connecting the account to the defendant, a persistent device identifier, or a recovery telephone number may still help establish who controlled the account during those seven days. Excluding those artifacts merely because they lack an intrinsic date does not necessarily make the warrant more precise. It may prevent the prosecution from proving who created the time-limited evidence.

The better approach is to tailor time by data type:

• Apply a defined period to records that contain usable dates and directly reflect the conduct under investigation.
• Explain why a modest surrounding period is needed for context, account access, synchronization, or attribution.
• Identify untimed or current-state records separately and explain their specific attribution value.
• State that the absence of temporal metadata is a technical characteristic of the requested data, not a request for unrestricted review.
• Limit the analysis to evidence of the identified offenses and the artifacts necessary to establish who controlled the account when that evidence was created.

This is not an argument against time restrictions. It’s an argument for restrictions that correspond to the data and the probable cause showing rather than an arbitrary, single rule imposed across the entire account.

A repeatable process for drafting cloud search warrants

A well-drafted cloud warrant should allow the reviewing court to follow a direct line from the provider’s own disclosures to the requested data and from the requested data to the facts the prosecution must prove.

The following sequence provides a repeatable drafting method:

1. Identify the provider and the target account with precision. Confirm the provider, service, account identifier, and jurisdictional requirements.
2. Preserve relevant provider records when delay may risk loss. Use a targeted preservation request and renew it when appropriate.5
3. Preserve the applicable provider materials. Capture the terms of service, privacy policy, EULA, cookie policy, Advertising ID policy, user data-export tool, retention disclosures, preservation instructions, and other relevant materials, as applicable.
4. Attach and explain the technical exhibits. Identify what each exhibit represents, its date, and the technical proposition it supports.
5. Inventory the potentially available data. Use provider products and export entries as a roadmap, then identify the precise data types within each relevant source.
6. Select only the data supported by the investigation. Do not treat the provider product name as a substitute for particularity.
7. Answer the five questions for each selected type of data. Draft a separate paragraph addressing description, relevance, creation, provider possession and user attribution.
8. Draft the provider-production language. Identify the specific data the provider is commanded to disclose.
9. Draft the authorization to analyze the return. Limit the examination to evidence of the identified offenses and user attribution.
10. Apply data-specific temporal limits and confirm consistency. Ensure that the affidavit, production selection, and analysis authorization request the same data and describe the same permitted scope.

Moving beyond “any and all” in cloud search warrants

The data-driven approach does not require investigators to know exactly what the evidence will show before executing the warrant. Probable cause requires a fair probability, not certainty.6

The approach does require law enforcement to know what it is asking for and why. Provider materials help identify what may exist. The five questions explain why the selected data matters. Digital footprints and exhaust show how evidence of the offense and evidence of account control may arise from different user or system functions. Data-specific temporal analysis keeps attribution language from becoming an unrestricted, general search.

The resulting warrant provides a coherent narrative. It identifies the relevant data, explains how it is created, shows why the provider is expected to possess it, and demonstrates how the requested artifacts will help prove both the offense and the identity of the person behind the account. That is not boilerplate adapted to the cloud. It is legal process built around how the data actually works.

Practice note: Provider interfaces, policies, retention practices, and governing law change. Confirm current provider materials and controlling federal, state, and local authority before using this framework in a particular case.

Discover more about the relationship between digital forensics and the legal system in other installments of our Legal Unpacked webinar series.