When may a native export be sufficient?¶
A native export may be sufficient when it proportionately preserves the content, metadata and account context required by the investigative question and its limitations are understood.
Test what the export actually contains¶
Depending on the service, an export may include message bodies, attachments, headers, account IDs, timestamps, audit records, folders or version history. Record the service, account, method, operator, time, scope, filters, format and provider reference. Preserve the delivered files unchanged rather than renaming or converting them unnecessarily.
Check whether deleted items, reactions, read state, message IDs, permissions, linked devices, headers or versions are absent. A file is not “native” merely because an application produced it: screenshots, printouts and copied text remain derivatives.
Decide against the evidential risk¶
Export alone may be proportionate where the source remains available, material is limited, authenticity is not contested and no deeper device evidence is needed. It may be inadequate for compromised or shared accounts, disappearing content, missing metadata or a process that itself changes account state.
Record provider-stated and observed omissions before deciding the original device is unnecessary. Complex or challenge-prone questions merit specialist advice on acquisition and interpretation.
Key takeaway
Rely on a native export only after confirming that its scope and metadata answer the investigative question and documenting every omission that could still make the original source necessary.