When a senior employee leaves for a competitor, the first question is often whether confidential information was copied. The more immediate question is narrower and more important: what evidence may disappear before that question can be examined properly?
Audit records may have limited retention. Cloud activity can continue after departure. A personal device may contain both business material and intensely private information. Encrypted messaging may leave little accessible message content. A collection that is technically extensive can still be difficult to defend if its authority, scope, methods or chain of custody were not documented.
The central principle is straightforward: preserve the most volatile and relevant evidence first, beginning with enterprise-controlled sources and proportionate administrative measures. Collection should then proceed in defined stages, using provider-native exports and targeted device methods where possible. A personal device should not become the default starting point merely because it may contain relevant evidence.
The preservation window is a decision problem, not simply a race to image devices
The first hours after a departure should be used to record the trigger facts and identify sources that may change or expire. This includes the departure time, access changes, devices returned or retained, relevant accounts, known concerns raised by HR or IT, and any indication that files were copied, downloaded, shared or transferred.
NIST guidance on integrating forensic techniques into incident response supports attention to order of volatility and coordination between response and forensic activity. In practice, this means that short-lived audit, network, VPN, proxy, CASB and DLP records may require urgent preservation, while cloud content may be preserved through administrative holds before a more intrusive collection is considered.
A defensible process records who took each action, when it occurred, what authority supported it, which systems and accounts were in scope, and which tools or platform functions were used. The preservation record is part of the evidence story.
What to preserve first
1. Corporate accounts and cloud repositories
The initial priority should generally be tenant-controlled sources associated with the custodian. Depending on the organisation’s environment, these may include the mailbox, OneDrive, SharePoint, Teams, Slack workspaces, Google Drive and other corporate repositories.
Microsoft Purview and Google Vault provide examples of hold functionality that can preserve server-side content and suspend routine deletion where configured and available. Holds should be documented by scope, owner, time, rationale and affected accounts or repositories. A hold is not a substitute for a collection plan, but it can provide a lower-impact first step while that plan is developed.
Relevant audit and activity records should also be preserved. These may include unified audit records, authentication events, file-share activity, administrator actions, DLP alerts, download events and sharing changes. Exact availability, retention and fields vary by platform, tenant configuration and licensing. Those details should be verified against the target environment rather than assumed from general product descriptions.
2. Network and security telemetry
VPN, proxy, firewall, CASB and DLP records may help identify transfers, unusual access patterns, large uploads or access outside normal activity. Their retention periods are platform- and policy-dependent, so the responsible team should identify and secure relevant records promptly.
These records may corroborate activity observed in a cloud repository or endpoint. They do not, by themselves, establish the full meaning or intent of an event. Their evidentiary value depends on context, time synchronisation, system configuration and the reliability of the associated records.
3. Corporate-owned endpoints
A corporate-owned laptop or mobile device may warrant forensic triage or imaging, depending on the question, the device state and the authority for collection. If a system is running and relevant data is time-sensitive, live-response considerations may apply. If an image is taken, the process should address acquisition method, write protection where applicable, hashes, tool versions, validation and storage of the original output.
The appropriate method is case-specific. A full image is not automatically the most proportionate or useful first step. The collection design should reflect the evidentiary question and the volatility of the relevant data.
Use cloud-native preservation and collection where possible
Cloud evidence has a different boundary from evidence held on a local device. NIST SP 800-201 provides a framework for considering cloud architecture, responsibilities and collection patterns. Provider-native records and export mechanisms may preserve server-side content or context that a copy of a user’s local synchronisation folder does not. Their provenance, scope, coverage and limitations still require assessment against the relevant provider, tenant configuration, account identity and export parameters.
Where supported and appropriately authorised, use the platform’s hold, eDiscovery or export capability to collect targeted content and associated metadata. Examples identified in the Research Pack include Microsoft Graph eDiscovery and Export APIs, Google Vault and Slack Discovery or enterprise export mechanisms.
A defensible cloud export should preserve the raw output and its associated manifest or report. Record the export job, relevant parameters, account or repository scope, timestamps, permissions, tool or API version where available, and checksums. A checksum supports later integrity checking of the defined captured output against alteration; it does not, by itself, establish that the export was complete, authentic, comprehensive or entitled to evidential weight. Export scope, provider process, account authority, coverage limitations and independent corroboration remain separate questions. Exact export fields and coverage require confirmation for the relevant product, licence and tenant.
Manual copying can lose server-side context, version information or activity records. Provider-native collection may therefore preserve context that a local copy does not, but the particular export still needs to be understood in terms of what it includes and excludes.
Collaboration platforms require platform-specific caution
Teams, Slack and similar platforms may contain messages, attachments, links and records of activity. Their collection paths depend on the organisation’s plan, permissions, retention settings and available discovery or export features.
For Teams, the Research Pack identifies Microsoft Purview and Microsoft Graph eDiscovery export capabilities as relevant collection routes. For Slack, Discovery API or enterprise export mechanisms may be available, subject to organisational approval and platform configuration. Where a discovery export is unavailable, administrative audit records and retained archives may still be relevant, but they should not be treated as equivalent to a complete message collection.
Content involving shared channels, external participants or cross-organisational workspaces requires particular care. Coverage can vary, and the exact behaviour of a given export should be verified before making operational or completeness claims.
BYOD: separate business evidence from private material
A personally owned device may contain relevant work applications, corporate files and account artefacts alongside personal communications, photographs, health information and other material outside the investigation’s proper scope. That makes authority, proportionality and minimisation central to the collection design.
A blanket forensic image should not be the default approach without explicit authority or consent. The preferred sequence is generally to preserve and collect corporate-controlled material first, then use the narrowest suitable method for the personal device. Depending on the environment, this may include:
- extracting data from a corporate container, work profile or managed application;
- using MDM or MAM controls as possible management, scoping or corporate-data-separation mechanisms, subject to the product, configuration and application; these controls should not be assumed to provide a forensic collection of business content;
- conducting a limited triage to establish whether relevant applications or files are present;
- applying time, repository, file-type or keyword limits where those limits are technically reliable; and
- expanding the scope only where necessary and supported by appropriate authority.
If a device image is essential, collection should be staged. First identify the relevant data sources. Then consider a targeted logical collection or other proportionate method. If a broader image is taken, private material should be segregated and protected through restricted access, filtering, redaction and an appropriate review workflow. Any filtered, redacted or segregated review copy should be created from, and remain traceable to, an unchanged preserved source. The separation method, validation basis and technical limitations should be documented; filtering does not itself establish that business and private material have been perfectly separated.
The legal basis for accessing or imaging a personal device depends on jurisdiction, employment context, provider terms and case-specific process. This article does not determine that authority. Counsel and, where relevant, the data protection officer should be involved before intrusive collection or cross-border transfer.
Encrypted messaging may impose a hard technical limit
End-to-end encrypted messaging can limit server-side access to message content. Depending on the application and configuration, relevant plaintext may exist only on an unlocked device or in a backup for which the necessary key or passphrase is available.
The preservation target should therefore not be limited to message text. Relevant artefacts may include application installation, account metadata, timestamps, delivery records, local database presence, operating-system artefacts and backup metadata. A provider may retain some account or delivery information even where it cannot provide message content.
Recovery from a backup is conditional, not guaranteed. Encryption, device keystores, user-controlled passphrases and provider limitations may prevent access. The resulting limitation should be recorded rather than silently treated as a collection failure or converted into an assumption about what was communicated.
An illustrative early-stage triage sequence
The following sequence is illustrative, not a universal 0–72 hour deadline or international operating standard. Immediate priorities depend on known retention periods, system state, available authority, provider processes and the risk that information will be altered or lost.
At the outset
Record the triggering facts and identify the custodian, relevant accounts, devices, repositories and suspected activity. Coordinate with the appropriate legal, HR, IT and privacy stakeholders.
Place holds on relevant corporate accounts and repositories where available. Preserve audit and DLP records, and identify short-retention network and security logs. Secure copies with appropriate access controls and document the action, scope and time.
Any account suspension, credential change or external-sharing restriction should be authorised and documented. Such steps may be operationally necessary, but they should be considered alongside legal, privacy and preservation implications.
During the next collection phase
Run targeted provider-native exports for relevant mailboxes, sites, cloud storage and collaboration platforms. Preserve native files, available metadata, manifests, export identifiers and checksums. Treat checksums as support for integrity checking of defined outputs, not as proof of completeness or authenticity. Prioritise corporate-owned endpoint triage and design a separate, authority-based BYOD approach.
Where encrypted messaging or personal cloud storage may be relevant, preserve available backup and account metadata and assess whether provider assistance, voluntary preservation or legal process is required. Tenant administration does not itself guarantee access to, or production of, data held in a separate personal account; appropriate provider process and legal advice may be required.
During collection and review
Maintain a contemporaneous preservation or activity log for each action. Record the person responsible, date and time, method, tools and versions, source, output, relevant authority, scope and storage location.
Keep that log distinct from the custody record. Where relevant, the custody record should document transfers, access, storage controls and the responsible persons who handled the defined output, so that continuity of possession can be assessed. Hashes or checksums can support integrity checking of those defined outputs, but do not by themselves establish provenance, completeness, authenticity or evidential meaning.
Test forensic tools and parsing methods against known data where appropriate, and document the validation basis for material methodology claims. Use a segregated review process for private, privileged or otherwise sensitive material. Limiting reviewer access is not only a privacy measure; it also helps keep the review question aligned with the authorised scope.
What the evidence can and cannot establish
A cloud audit record may show that an account accessed, downloaded, shared or modified an item, subject to the platform’s logging and retention behaviour. A file export may show the content and available server-side metadata. A network record may corroborate a transfer event. A device artefact may provide context about an application, file or account.
None of these sources should automatically be treated as proof of intent, authorship or unauthorised use. Interpretation depends on identity controls, shared accounts, system configuration, timestamps, retention, completeness and corroboration. The strongest analysis normally compares multiple sources rather than relying on a single event record.
The reverse is also important. The absence of message content does not necessarily establish that no communication occurred. It may reflect encryption, deletion, unavailable keys, limited platform retention or an export boundary. The report should distinguish between evidence that was not found, evidence that was not retained, and evidence that could not be accessed using the authorised method.
A defensible preservation design is deliberately narrow at the beginning
For litigation and investigations professionals, the immediate objective is not to collect everything. It is to prevent avoidable loss while preserving the ability to answer the relevant questions later.
That usually means starting with enterprise-controlled holds, audit captures and targeted cloud exports; then assessing corporate-owned devices, BYOD and encrypted applications according to authority, volatility, relevance and proportionality. It also means maintaining a transparent record of limitations, including unavailable provider data, uncertain retention, incomplete export coverage and jurisdictional restrictions.
IVIDENTIA’s perspective is that digital evidence should be understood before it is over-collected. A preservation and collection plan should make clear what each source can establish, what it cannot establish, how private material will be protected and which decisions require legal or privacy approval.
This article is general technical guidance, not legal advice. Before collecting from personal devices or transferring personal-account data across borders, obtain advice on applicable authority, privacy requirements and local process.
Sources
- NIST Cloud Computing Forensic Reference Architecture (NIST SP 800-201) — NIST.
- Guidelines on Mobile Device Forensics (NIST SP 800-101 Rev. 1) — NIST.
- Guide to Integrating Forensic Techniques into Incident Response (NIST SP 800-86) — NIST.
- ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidence — ISO/IEC.
- Create a hold to suspend documents or items — Microsoft.
- Place Drive, Meet, and Sites data on hold — Google Workspace.
- Get started with auditing solutions — Microsoft.
- Drive log events — Google.
- Slack — Review your workspace’s settings / Discovery API & Audit Logs — Slack.
- Microsoft Graph eDiscovery Export API docs — Microsoft / Microsoft Graph.
- ACPO Good Practice Guide for Digital Evidence — Association of Chief Police Officers / NPCC.
- ENFSI Best Practice Guidelines for Digital Forensics — ENFSI.
- Forensic Science Regulator — Code of Practice and method validation guidance — Forensic Science Regulator.
- EDPB employment-context data protection materials — European Data Protection Board.
- Practitioner/technical commentary on message recovery and mobile artefacts — Digital forensics practitioner literature.
