What should I ask a provider for?¶

Ask for the records that can answer the question you actually have, using the most stable account identifiers and the narrowest useful time period.

A request for “everything about this account” can be both too broad and strangely unhelpful. You may get a large export without the security or session records that actually matter.

Start with the investigative question¶

Before drafting the request, be clear what you are trying to establish.

For example:

If you need to know…	Useful record categories may include…
Who created the account?	Creation time, supplied/verified details, source connection, device/client, recovery and payment records
Who accessed it?	Authentication, sessions, devices, applications, source addresses, MFA and trusted-device records
Was it taken over?	Password/recovery changes, new factors, trusted devices, session revocation and security alerts
Who sent a particular message?	Event record, exact time, message/resource ID and any link to session, client, device or connection
Who paid for the service?	Provider transaction, billing and payment-instrument records

That makes the request easier for the provider to understand and easier for you to assess when the return arrives.

Identify the account precisely¶

Where possible, include:

• stable account ID;
• exact username/profile URL;
• relevant email address or telephone number;
• service/product;
• tenant or organisation where relevant;
• known event or transaction ID;
• relevant dates and time zone.

That is much better than asking for records relating to “Fenland Classics” without saying which underlying account or event you mean.

Ask for the records behind the event¶

If a specific action matters, ask for the provider records that connect it to the surrounding access.

That may include:

• event timestamp;
• session ID;
• application/client;
• device identifier;
• source IP address;
• authentication method;
• account-security changes;
• linked transaction/resource IDs; and
• relevant audit or activity records.

Do not invent provider field names if you do not know them. Describe the event clearly enough that the provider can identify the corresponding record set.

Preserve meaning, not just data¶

A return is much easier to use if you know what the fields mean.

Where appropriate, ask for or retain:

• field definitions;
• original time zone;
• export scope;
• filters applied;
• known exclusions;
• retention limitations; and
• whether identifiers are stable, user-editable or provider-generated.

What account records might a provider hold? explains the different record systems you may be dealing with.

Think about preservation early¶

Some provider records may have shorter retention than others.

If the information is likely to matter and delay risks losing it, use the appropriate preservation process before the acquisition route catches up.

The exact legal or organisational mechanism depends on your environment, so follow the authority and process that applies to your investigation.

A good return may still stop short of the person¶

The provider may be able to show:

• this account;
• this session;
• this device record;
• this connection;
• this event.

That can be extremely useful.

You may still need device, communications, payment or real-world evidence to identify the person behind the activity.

The practical point is: build the provider request from the investigative question, stable identifiers and relevant event. Ask for records that explain what happened, how access was granted and which session or device was involved — not an undefined dump of “everything”.