A Departing Employee's Data

When someone leaves, their data does not. Deciding what happens to it in advance avoids both loss and unnecessary retention.

What exists

Mailbox, containing business correspondence and personal material mixed together.

Files in company storage, personally owned within a shared platform.

Files in personal accounts used for work, which you cannot reach.

Documents they own in collaborative platforms, where ownership affects whether others can edit.

Repositories, automations and integrations they created and own.

Accounts they registered with external services on the company's behalf.

Devices, with local data.

The decisions to make in advance

Mailbox retention period, by role and by regulatory requirement. Indefinite retention is the default in many organisations and it is a growing liability.

Whether a manager gets access to the mailbox, under what approval, and with what notice to the departing person. This has employment and data protection dimensions in several jurisdictions.

Who inherits owned documents, which should be automatic where the platform allows.

What happens to personal material found in company systems.

Whether an out-of-office or forwarding is set, and for how long.

Write these down as a policy, because deciding them for each departure produces inconsistency and pressure.

The transfer, done properly

Reassign ownership before closing the account, not after. Closing first can orphan or delete content.

Documents and folders to the manager or the team.

Repositories to a team rather than an individual.

Automations and scheduled jobs, which break silently when their owner's account closes and are frequently discovered weeks later.

Application ownership, from the register.

External service accounts, to a shared or team account.

Run this as a checklist generated from the register, which is the practical payoff of maintaining ownership fields.

Mailbox handling

Convert to a shared or archived mailbox rather than leaving an active licensed account, which also reclaims the licence.

Set forwarding only where there is a business need and a defined end date, and only where the jurisdiction permits it.

Notify correspondents through an auto-reply rather than silently forwarding, which is both more honest and generally safer legally.

Delete at the end of the retention period, which requires the deletion to be scheduled rather than remembered.

Personal data of the departing person

They have rights over their own personal data in most jurisdictions, including access and in some cases deletion.

Personal material in a company mailbox is a known ambiguity. A policy stating that mailboxes are for business use and may be retained and accessed is the usual position, and it needs to have been communicated in advance to be relied upon.

Do not simply delete everything on the assumption that it is safer. Retention obligations may apply.

Legal hold

Overrides deletion, and it must be applied before the automated process runs.

Requires knowing that a hold applies, which requires legal to be part of the departure process for the relevant cases.

Test that a hold survives your retention automation, because this is the failure that only becomes visible during litigation.

The checklist

Generated per departure from the register: applications owned, documents owned, repositories owned, automations owned, external accounts registered, mailbox disposition, device recovery, retention clock started.

Eight items, each with an owner and a completion record. Assembling it by memory is how the automations that break three weeks later get missed.

The retention schedule

Deciding retention per departure produces inconsistency and pressure. Deciding it in advance produces a schedule.

Mailbox: a defined period by role, driven by regulatory and litigation requirements rather than by convenience.

Files in company storage: transferred to the team, not retained separately.

Chat history: the platform's organisational retention, unchanged by departure.

Personal material: identified and returned where practical, deleted otherwise.

Access logs and audit records: their own retention, usually longer.

Write it down, communicate it in advance, and automate the deletion at the end of the period.

A schedule nobody executes is worse than none, because it documents an intention you can be shown to have ignored.

Legal hold, tested

A hold that does not survive your retention automation is discovered during litigation, which is the worst possible time.

Know who can apply a hold and how it reaches the systems.

Apply it before the leaver automation runs, which requires legal to be part of the departure process for relevant cases.

Test it: apply a hold to a test account, run the retention job, and confirm nothing was deleted.

Test it after any platform change, since retention behaviour is a common casualty of migrations.

Document the test, which is itself useful evidence.

Review active holds periodically and release the ones no longer needed, since indefinite holds accumulate and defeat the retention schedule entirely.