When a dispute or investigation begins to take shape, relevant communications may not exist in one convenient archive. They may be distributed across a collaboration platform, individual devices, cloud storage, provider exports, third-party integrations and administrative records. Some content may also be subject to automatic retention rules, account changes or deletion workflows.
The practical problem is not simply whether a message can be exported. It is whether the preservation exercise identified the relevant sources, acted before data changed or was lost, and recorded what the resulting collection does—and does not—contain.
The central principle is straightforward: preservation should begin with a map of where the evidence and its context may exist, followed by early, layered action across those sources. A provider export can be important, but it should not automatically be treated as a complete representation of the underlying communications.
Preservation begins before collection
The point at which preservation action should begin depends on the matter, the jurisdiction, applicable obligations and the advice of responsible counsel. Legal preservation duties and trigger standards are not uniform internationally. Operationally, a credible investigation, anticipated dispute, threat of deletion or relevant system change may justify prompt coordination with counsel and the custodians responsible for the systems.
That trigger is not necessarily the first date on which a formal claim is filed. Retention policies may delete content automatically; licences may be removed; user accounts may be deleted; devices may be replaced or reset; and applications may be re-registered on new devices.
The appropriate response depends on the matter, the custodians and the relevant systems. It should nevertheless be prompt enough to address the platform’s deletion and access conditions before they become irreversible. This article provides operational considerations, not a universal legal test for when a hold or preservation obligation arises.
The same conversation may exist in several places
A collaboration conversation is not necessarily a single evidentiary object. Its body, attachments, metadata and surrounding context may be stored or represented separately.
Relevant material may include:
- Message bodies, attachments, images, embedded media and link previews.
- Creation, edit and deletion timestamps, where available.
- Sender and recipient identifiers, message IDs, thread IDs and channel references.
- File hashes, MIME types, storage paths and URLs.
- Channel, workspace, team and group membership records.
- Invite histories, external participant records and Slack Connect information.
- Device lists, application manifests and linked-device information.
- Retention policies, legal-hold records and export manifests.
- Audit logs showing administrative actions, exports, role assignments and system events.
- Logs or copies held by third-party connectors, bots, archiving systems and external storage providers.
This distribution creates a completeness problem. A collection may contain the message body but omit the attachment. It may preserve a channel post without the relevant membership history. It may capture a current version of a message without fully representing its edits or related event records. The investigative question is therefore not only “Was the message collected?” but also “What information is necessary to interpret it, and where else might that information reside?”
Microsoft Teams: preservation is distributed across Microsoft 365
Microsoft Teams data is not preserved solely by capturing what appears in the Teams client.
For the relevant message type and tenant configuration, Teams compliance representations may include chat messages in hidden folders in Exchange Online user mailboxes. Channel messages may be associated with group mailboxes, while files shared in channels may be represented in SharePoint or OneDrive. These are potential source or compliance representations, not necessarily complete originals or the only locations requiring examination. Microsoft Purview eDiscovery and hold mechanisms provide supported routes for preservation and export, subject to the applicable tenant configuration and matter.
For a Teams matter, the preservation plan should therefore consider, as applicable:
- User mailboxes, including relevant locations containing Teams compliance copies.
- Group or team mailboxes associated with channel messages.
- SharePoint and OneDrive content containing channel files.
- Purview eDiscovery cases, collections, holds and export packages.
- Microsoft Purview audit records.
- Licence, tenant and administrative records relevant to account status and preservation.
A Purview export may provide an HTML transcript that assists with reviewing thread order and sender and timestamp context. However, the exact fidelity of exported fields should be tested for the matter. Edits, reactions, delivery or read information and thread behaviour may vary by scenario and export format. An export should not be assumed to capture every relevant event merely because it contains the visible conversation.
Hold and retention actions may involve processing delays and background operations. Those actions should be monitored and documented, including when each action was requested, accepted and completed. Account deletion or licence removal can also affect the underlying mailbox and the survivability of Teams compliance representations, subject to tenant settings and any applicable hold or inactive-mailbox treatment.
Slack: retention settings and enterprise access matter
Slack content, files and metadata are held within Slack’s systems, but the preservation options available to investigators depend on the workspace configuration, subscription level, administrative permissions and the relevant export route.
For Enterprise Grid environments, Slack provides Discovery API and Audit Logs API capabilities for compliance-related collection. Workspace and organisation-level exports may also be relevant. A preservation plan should identify and, where appropriate, preserve:
- Workspace exports in the available formats.
- Discovery API collections for Enterprise Grid environments.
- Audit Logs API outputs.
- Message and file content, including file binaries.
- Workspace retention settings and configuration snapshots.
- Application and integration manifests.
- Administrator roles, approvals and export records.
- Third-party destinations receiving Slack content through connectors or workflows.
Slack retention settings can remove older content, and workspace owners may initiate deletion actions. Depending on the feature, plan and workspace configuration, owner-initiated deletion or retention processes may create limited recovery windows. The relevant conditions should be verified in the workspace rather than assumed to apply generally. Early preservation remains important where relevant data may otherwise be removed before an export or discovery collection is completed.
Slack’s ephemeral features require particular caution. Some ephemeral app messages are intended to be visible only to a particular user, and other transient interface elements may not be represented in the same way as persistent channel messages. The available research does not establish that all ephemeral-only items are captured consistently in Discovery API or enterprise exports across tenant configurations. That question should be tested in the relevant environment.
Signal: the endpoint may be the primary source
Signal presents a different preservation problem. Its service is designed to keep message content primarily on user devices, and Signal cannot decrypt that content. Provider-side information is therefore limited compared with a platform that maintains compliance copies in enterprise mailboxes or workspace systems.
Preservation planning for Signal should prioritise, where authorised and proportionate:
- Relevant mobile devices.
- Desktop or other linked devices.
- Device-level application data and operating-system records.
- Secure Backups, if the user enabled the feature and the required recovery material is available.
- Recipient devices, where relevant and lawfully accessible.
- Evidence of device migration, re-registration or message-history transfer.
A provider request may not yield message content where the service does not retain decryptable content. Endpoint and backup preservation should therefore be assessed separately, with appropriate authority and legal advice. The practical risk is often physical or operational: a device is replaced, factory-reset, re-registered or disconnected before its contents and backups are preserved.
Do not overlook integrations and external storage
Collaboration platforms frequently interact with systems outside the principal workspace. Bots, connectors, DLP products, archiving applications and workflow tools may create additional copies or logs. Slack or Microsoft integrations may send content to external stores such as Google Drive, Box or SharePoint.
Those systems can contain an additional or surviving copy of an attachment, an audit record or a workflow event. They may also have independent retention and deletion rules. Identifying applications, integrations, webhooks and external storage should therefore form part of the initial source map, rather than being treated as a later technical detail.
A provider export is not automatically complete
An export is an important preservation artefact, but it is not automatically a complete capture of every message field, event or related record.
Export formats may differ in how they represent edits, reactions, thread relationships, delivery or read information, attachments and deletion events. Some ephemeral interface items may exist only in client state or transient service processes. Access may also depend on enterprise licensing, administrative roles, API approval or collection limits.
Before relying on an export, investigators should test representative message types and compare the results with other available sources. Depending on the platform and matter, the sample may include private messages, private channels, threaded replies, attachments, edited messages and ephemeral app content. The purpose is not to manufacture certainty, but to document what the selected collection method captures in that environment.
A layered preservation method
A defensible preservation exercise should create a record of both the action taken and the limits that remain.
1. Define the trigger, scope and authority
Record why preservation was initiated, when the trigger was identified, which custodians and systems are in scope, the relevant time period and the authority directing the action. Scope should be proportionate to the matter, but it should account for external participants, shared channels, linked devices and third-party systems where they may contain relevant context. Legal scope and preservation obligations should be confirmed with responsible counsel.
2. Preserve across multiple layers
For Teams and Slack, this may include provider holds and exports, endpoints, file stores, administrative records and integration systems. For Signal-like applications, endpoints and available backups may be primary sources. Layered preservation reduces reliance on a single export path and helps identify discrepancies between systems.
3. Preserve the collection record
For each collected object or export package, record the source identifier, collection method, date and time, operator, export manifest and any provider receipt or ticket. Preserve raw packages alongside any normalised derivatives prepared for review. Where appropriate, calculate and retain SHA-256 hashes and maintain a documented chain of custody.
A hash can support post-acquisition integrity checking of the object that was hashed, and collection records can document process steps. Neither, by itself, proves that the source was complete, authentic or attributable, or determines evidential weight or admissibility.
ISO/IEC 27037 and NIST SP 800-86 offer general technical guidance relevant to identification, acquisition, preservation and documentation. They are not platform-specific validation rules or universally controlling litigation standards; their application should be adapted to the matter, jurisdiction and applicable procedures.
4. Test the collection
Use small-sample exports or controlled retrievals to determine whether the target message types, metadata and attachments are present. Record missing fields, count differences, format transformations and any vendor explanation. For Teams, this may include testing transcript fidelity across account or licence scenarios. For Slack, it may include testing ephemeral app messages and integration-generated records. For Signal, it may include confirming the presence and usability of available backups.
5. Reconcile and report limitations
Compare message and file counts across available sources, such as mailbox exports, channel collections, endpoint data and third-party storage. Differences may result from deletion, retention purges, client-only content, export format limitations or separate representations of the same event.
The resulting limitations statement should identify what was preserved, what was not preserved, the relevant dates, the collection methods used and the reasons for any known gaps. A limitation is not necessarily a failure. An undocumented limitation is more difficult to assess.
A practical intake checklist
At the outset of a matter, investigators and counsel should consider whether they have:
- Identified custodians, date ranges, channels, workspaces, teams and external participants.
- Recorded relevant retention policies, deletion settings and account or licence risks.
- Initiated appropriate preservation actions without delay, subject to responsible counsel’s direction.
- Identified mobile devices, desktop clients, linked devices and available backups.
- Preserved relevant Teams mailboxes, SharePoint or OneDrive content, Purview records and audit logs.
- Preserved relevant Slack workspace or Discovery exports, audit logs, files, manifests and configuration records where available.
- Identified Signal backups and the recovery information required to access them.
- Mapped bots, connectors, archiving systems, webhooks and external storage.
- Retained provider manifests, receipts, support responses and collection logs.
- Tested representative exports and documented their field-level results.
- Reconciled counts and reported known gaps, including ephemeral or transient content that may not be recoverable.
The evidentiary value of knowing what cannot be recovered
Digital Evidence Intelligence is not limited to locating surviving messages. It also requires understanding the conditions under which evidence was created, stored, deleted, exported and potentially lost.
A carefully documented preservation exercise can document which systems were examined, which controls were available, when actions were taken and what the collection method appeared capable of capturing. It can support an assessment of the resulting record, subject to the scope, access, system and validation limitations identified. It does not by itself prove completeness, authenticity, attribution or admissibility.
For litigation lawyers and investigations professionals, that distinction matters. The reliability and evidential meaning of a collection depend not only on the data presented for review, but also on the reasoning and records supporting how it was preserved and the limitations that remain.
IVIDENTIA perspective
Ephemeral collaboration data should be treated as a preservation problem before it is treated as a review problem. The relevant question is not simply which application was used. It is where the conversation, its context, its administrative history and its surviving copies may exist—and how quickly those sources can change.
Early, layered preservation; controlled testing; and explicit reporting of limits provide a more reliable basis for deciding what the digital evidence actually establishes.
If a matter involves Slack, Teams, Signal or another collaboration platform, IVIDENTIA can discuss the preservation questions that should be mapped before collection begins.
Sources
- Learn about retention for Teams — Microsoft Learn / Microsoft Purview.
- Slack Security Practices & Help Center — Slack.
- Slack — Updates & Changes — Slack Help Center.
- Signal Terms & Privacy Policy — Signal.
- Signal Secure Backups — Signal Support.
- ISO/IEC 27037:2012 — ISO.
- Commentary on Legal Holds: The Trigger & The Process — The Sedona Conference.
- NIST SP 800-86 — NIST.
- Current EDRM Model and Identification/Preservation guidance — EDRM.
- Exporting Teams Chat — SmiKar.