Trust & Security Pack

Data Retention Schedule

Current schedule

How long different types of information are kept in Unpack, why they are kept, and what happens to them on deletion.

This schedule describes how the live service behaves. Where a period is set by an infrastructure provider, or where information is deliberately kept for as long as the account is active, we say so rather than stating a period we do not apply.

By data type

Audio recordings

Expiry assurance outstanding

Current retention: Only for as long as processing requires. Once transcription, analysis and the related processing outputs have been verified as stored, the source audio is deleted immediately and automatically. Failed or incomplete audio has a designed seven-day expiry. The retention audit found the scheduled sweep missing; remediation and verified deletion remain outstanding. No seven-day guarantee is made.
Why: Data minimisation: audio is needed only to produce the transcript and derived outputs, and only failed processing needs a short retry window.
On deletion / end of service: Audio files are removed from storage, the stored file paths are cleared, and a small non-audio audit stamp records when the deletion happened. Transcript text is not affected. Deleting an account removes the user’s audio files directly rather than waiting for the sweep.

Transcripts and cleaned transcripts

No fixed period

Current retention: Kept while the account is active and the material is needed for the history, coaching and preparation features in use. No fixed period is set in the service today.
Why: The transcript is the working record the rest of Unpack is built on: history, patterns, preparation and coaching all read from it.
On deletion / end of service: Users can delete individual sessions and transcripts at any time. On account purge, transcripts are deleted with the account.

AI analyses, behavioural observations, patient-experience and meeting observations

No fixed period

Current retention: Kept alongside the session or meeting they belong to, for as long as that record is kept. No separate fixed period.
Why: These are what makes progress over time visible; removing them early would remove the history the product exists to show.
On deletion / end of service: Deleted when the parent session, meeting or account is deleted.

Coaching history, meeting history and preparation outputs

No fixed period

Current retention: Kept while the account is active. No fixed period.
Why: Longitudinal history and preparation for future conversations.
On deletion / end of service: Deleted with the account, or individually by the user where the feature allows.

Account, profile and contact data

Implemented

Current retention: Kept while the account exists.
Why: Required to operate the account, authenticate the user and contact them about the service.
On deletion / end of service: Removed on purge, including the login record itself. A minimal audit record that the account was scheduled, cancelled or purged is retained.

Practice membership and role data

Set by practice contract

Current retention: Kept while the membership exists. Membership rows are removed when the underlying user account is purged.
Why: Determines who can see what within a practice.
On deletion / end of service: Removed with the account. Membership and role history at the end of a practice contract is handled under that practice’s contract with us.

Uploaded and imported files (diary page images, imported recordings)

Audio expiry assurance outstanding

Current retention: Diary page images are kept while the diary entry exists. Imported audio follows the same lifecycle as recorded audio: deleted once processing has completed, with a designed seven-day failed-processing expiry that is not guaranteed: the scheduled sweep was missing at audit.
Why: The uploaded material is part of the record the user created.
On deletion / end of service: Diary page images are deleted from storage during account purge; imported audio is deleted on successful processing or by account purge. Scheduled expiry assurance remains outstanding.

Push notification device tokens

Removed with the account

Current retention: Kept while the device is registered. A token is marked disabled when the user turns notifications off, or when the push provider reports it as invalid. Disabled rows are not currently deleted on a schedule.
Why: Needed to deliver notifications to the right device and to stop sending to dead tokens.
On deletion / end of service: Removed with the account on purge.

Administrative, security and application logs

Provider-governed

Current retention: Application, database, authentication and platform logs are generated and rotated by our infrastructure providers. We do not currently set our own retention period for them.
Why: Fault diagnosis, security and service integrity.
On deletion / end of service: Governed by the provider’s rotation, not by account deletion.

Account deletion audit records

Retained as an audit record

Current retention: Retained after the account is purged. No expiry is currently set.
Why: To evidence that a deletion request was made, cancelled or completed, and when.
On deletion / end of service: Deliberately survives the purge. Holds the request, the user id, the email and the event; it does not hold the user’s content.

Support and administrative access records (admin audit log)

Implemented

Current retention: Retained indefinitely. A dedicated admin audit log is now implemented: privileged actions such as starting and ending support access to an account, member and access-request changes, and account-purge runs are written server-side to a tamper-resistant table that no client can write to or amend. No expiry or clean-up job is implemented for these records today.
Why: To evidence who accessed or acted on an account, when, and for what stated reason.
On deletion / end of service: Deliberately survives account purge. It holds the actor, the action, the target identifiers, the stated reason and the outcome — not the account’s content.

Inbound integration webhook records

Retained as an audit record

Current retention: Records of inbound recording deliveries from a practice’s own integration are stored for troubleshooting. No expiry is currently set.
Why: So a practice can see whether a recording actually arrived and why an import failed.
On deletion / end of service: Removed with the practice integration or the account it belongs to. No separate expiry is applied to these records.

Backups

Provider-governed

Current retention: Our infrastructure providers hold routine backups. The exact backup retention period and cycle are set by those providers and have not been verified by us.
Why: Recovery from failure or data loss.
On deletion / end of service: Deleting data from the live service does not immediately erase it from an existing backup. It falls out when that backup expires on the provider’s cycle.

Shared practice-level material

Set by practice contract

Current retention: Material a user contributed at practice level — for example approved evidence or shared knowledge — remains with the practice after that user’s account is deleted, in de-identified form.
Why: It belongs to the practice’s shared record rather than to the individual account.
On deletion / end of service: Not removed by individual account deletion. Handling at the end of a practice contract is covered by that practice’s contract with us.

Aggregated and de-identified material

Derived material

Current retention: Practice-level aggregates and summaries are derived from underlying records rather than held as a separate long-term store, and de-identified contributions persist as described above.
Why: Practice-level insight that does not identify an individual.
On deletion / end of service: Aggregates change as the underlying records change; de-identified contributions are not restored to identified form.

Retention principles

We collect and keep the least information needed for the purpose, and no longer than that purpose requires.
Information is kept only while it is needed to provide the service the practice and its users have asked for, or to meet a legal obligation.
Different types of information need different periods — audio, transcripts, account data and audit records are not treated the same way.
Deleting something from the live service does not mean it disappears from routine provider backups at the same moment.
The practice remains the controller and may have its own retention and clinical record-keeping duties. Unpack is not a clinical record and should not be relied on as one.

Where we do not set a fixed period

Transcripts, analyses and history are kept while the account is active, because the product exists to show change over time. They are deleted by the user or with the account.
Backup retention and expiry are set by our infrastructure providers on their own cycle; we do not override it.
Administrative, security and application logs follow provider rotation rather than a period we set.
Account-deletion audit records, admin audit log records and inbound integration records are kept as audit evidence without an expiry, and hold no account content.
Shared practice-level material, membership history and de-identified contributions stay with the practice, and are handled under that practice's contract at the end of it.
Disabled push notification tokens are marked disabled and removed with the account rather than on a separate schedule.
A practice that needs shorter, contractually fixed periods for its own governance can agree them with us.

In each of these cases the position above describes exactly what the service does today. A practice that needs a shorter or fixed period for its own governance can agree that with us as part of its contract.