Data Retention
The Data & Privacy page (main navigation, under Compliance & Governance) has three tabs:
- Retention Policy - how long completed offboardings are kept
- Erasure Requests - right-to-erasure requests (GDPR Art. 17)
- Data Export - an individual's data package for access and portability requests (GDPR Art. 15 and 20)
Data retention is available from the Team plan up. Viewing needs the compliance_view permission and making changes needs compliance_manage (Super Admin, Admin and HR by default). Users limited to some departments only see and act on offboardings in those departments.
Retention policy
There is one policy per organization. It has four settings:
- Enabled - whether the nightly job applies it
- Retention period - days after an offboarding's exit date (or its last update, if it has no exit date) before the action applies. Between 30 and 36,500 days.
- Action -
anonymize(recommended) ordelete - Email admins before - how many days ahead Owners and Admins are emailed. At least 1 day and no longer than the retention period.
Every night PurpletGo:
- Emails Owners and Admins once about completed offboardings that will reach the retention period within the notice period. Each record is only included in one email.
- Applies the action to completed offboardings past the retention period that are not anonymized yet and not under legal hold.
When you enable a policy (or change an enabled one), the page shows how many records are already past the retention period and will be changed that night. Run Now applies the saved policy immediately, after showing how many records it will change.
delete removes the offboarding record and everything attached to it. It cannot be undone. It anonymizes first, as described below, so the records that outlive it (the alumni profile, references, background checks, the original offboarding request, compliance evidence and notes on the replacement hire's onboarding) no longer hold the person's data. The employee directory record is kept, and anonymized as below.
Anonymize replaces the person's personal data with [Redacted] (or removes it) in:
- the offboarding record and the employee directory record with the same email
- compliance documents (the stored file is deleted), exit interview responses and schedule notes, notes, knowledge transfer items
- self-service portal activity and messages, and any open portal link
- the alumni profile (including the personal email they joined with), references and background check requests, and the original offboarding request
- shipments (sender and recipient address) and equipment-return photos (deleted), vendor access contacts, and cached AI results
- in-app notifications about the person (deleted), and other erasure requests for them (names, emails and reason removed; their status is kept)
In checklist tasks, access-removal details, compliance evidence, bulk offboarding results, revocation run messages, Google Drive transfer errors and notes on the replacement hire's onboarding, only the person's name and email are replaced with [erased], so the history of what was done is kept. The person's details in the audit log become unreadable too: see The audit log.
The manager's email on the offboarding is kept: it is the manager's data, not the person's.
The directory record is only anonymized while it is inactive: if the person was rehired with the same email, their current directory entry is kept.
If your plan changes to one below Team, an enabled policy keeps running. You can still see it and turn it off on the Data & Privacy page.
Legal holds
Records under legal hold are never anonymized or deleted, by the nightly job, Run Now, or an erasure request. See Compliance.
Erasure requests
Log the request
On Erasure Requests, click Log Erasure Request. Link the person's offboarding (their name and email are filled in), or enter their email. One of the two is required, because it is how their data is found. Add up to five other email addresses they used, for example a personal email on their alumni profile or references. The requester's name is required; their email and the reason are optional.
Approve or reject
Approve the request, or reject it with a reason (required).
Execute
Open an approved request to see what will be erased: the linked offboarding, every other offboarding under any of the person's addresses (for example a rehire), and the directory records, alumni profiles, references, background checks and offboarding requests found by those addresses. Export the data first if you need a copy, then click Execute Erasure.
Executing anonymizes everything listed, as described above, and deletes stored files. If the person joined the alumni network, they're deleted from your Mailchimp alumni list; HubSpot and Salesforce contacts are kept (they may hold your own CRM data) with the alumni marker cleared, and the result tells you to delete them there if needed. It stops with an error if any of the person's offboardings is under legal hold. Afterwards the request shows how many records of each kind were changed, including how many audit log keys were destroyed, and the names on the request itself are replaced with [Redacted], with its emails and reason removed. The audit log records the offboarding IDs, the counts and the IDs of the destroyed keys, never the person's name.
After an erasure
The erased addresses go on a suppression list, so automated imports don't add the person back: HR system sync, the Azure AD directory import and CSV import skip them (the HR sync and CSV import report how many were skipped). The list stores a one-way hash of each address, not the address.
- If your HR system reports the person as active again, PurpletGo treats it as a rehire and imports them normally.
- Adding the person by hand, or provisioning them through SCIM, also brings them back.
- SCIM treats an erased directory record as deleted, so an identity provider can't refill it.
Also remove or anonymize the person in your HR system and identity provider; PurpletGo can't erase data held there.
A request can only be executed once. A user limited to some departments can't execute a request that isn't linked to an offboarding, or one that covers offboardings outside their departments.
Exporting an individual's data
On Data Export, search for the person and click the export button (also available as Export Data First on an approved erasure request). It downloads one JSON file with:
- the offboarding record, the directory record and assigned assets
- checklist items, access removed, vendor accesses, compliance documents (details, not the files)
- notes, knowledge transfer items, exit interview schedule and responses
- self-service portal activity and messages, shipments
- the alumni profile, references, background check requests and the original offboarding request
- audit log entries about the person: those about the offboarding or the person's directory record, and those that mention the offboarding, the person's email, or have their exact name as the target, with the person's details readable
Equipment-return photos are listed by file name and notes; open the images from the shipment if they are needed. The Export Data First button on an erasure request also searches the request's other email addresses.
Review the file before sending it: references marked confidential may be covered by an exemption. Every download is recorded in the audit log.
The audit log
Erasure and retention keep every audit log entry, so the log stays a complete record of what happened. It is hash-chained, so verifying the chain detects edited or removed entries.
The person's own details in those entries are encrypted with a key for that person's records (their offboarding, directory record, alumni profile, references, background checks and offboarding requests): names, email addresses, phone numbers, employee IDs, home addresses, IP addresses, browser details, and free-text notes and reasons. Executing an erasure, and a retention run that anonymizes or deletes a record, destroys those keys in the same step. From then on the details read [erased] everywhere PurpletGo shows them, including exports downloaded afterwards, compliance evidence and the archived copies, while the chain still verifies. What was done, when, and by which member stays readable. Other placeholders you may see:
[withheld]- a value PurpletGo could not tie to a person's record, so it was never stored[unreadable]- a value that could not be decrypted. Contact support if you see it.[personal data]- where personal details are hidden: PurpletGo support's view of your audit log, and the audit trail in a member's own Export My Data
Copies already sent elsewhere are not reached: SIEM events and webhooks already delivered, emails, and exports downloaded before the erasure. Backups keep the keys for about 7 days (see Backups). While a record is under legal hold, it can't be erased and its keys can't be destroyed.
Searching the audit log by a person's name or email finds the entries about them through their current offboarding and directory records. Once they are erased there is nothing left to match, so their entries can no longer be found by name; the offboarding's timeline still lists them.
Entries are removed from PurpletGo after the audit log retention period (24 months by default, 3 to 120 months). On Team and Enterprise plans, PurpletGo also archives the log to cloud storage every night: each signed archive holds the entries written since the previous one, and is deleted after your archive retention period (7 years by default, at least 365 days, set by a Super Admin under Audit Log → Archive Retention). Archives are kept past their period while any case is under legal hold, and are not deleted with your organization: each runs down its own period. See Audit Log: archives. Mention this in your privacy notice: audit records are kept for accountability and the establishment or defence of legal claims (GDPR Art. 17(3)(b) and (e)), for the archive retention period you set.
Backups
PurpletGo's database has automated daily backups and point-in-time recovery, both kept for about 7 days. Data you delete, or that retention or an erasure removes, stays in those backups until they roll off, about 7 days later. So do the audit log keys an erasure destroys. Backups are encrypted, are not used to run the service, and are only restored to recover from a disaster, after which anything deleted in the meantime is deleted again. Deleting your organization works the same way.