Data retention

This schedule defines how long each category of personal data is retained, the legal basis for the retention period, the storage location, and the deletion mechanism, in compliance with UK GDPR Article 5(1)(e) (storage limitation) and Article 17 (right to erasure).

Principles

Personal data is retained only for as long as necessary to fulfil the purposes for which it was collected, or as required by applicable law. Where retention is discretionary rather than mandatory, the shortest defensible period is preferred. Deletion is hard deletion (not soft deletion or archival) except where law requires otherwise.

Any retention period may be shortened at the customer's request unless a legal retention obligation applies.

Schedule

Clinician account data

Categories: Name, email, authentication credentials (hashed), MFA secrets, subscription status, account preferences. Retention period: For the duration of the customer relationship, plus 30 days after termination. Rationale: Necessary for the provision of the contracted service (UK GDPR Art 6(1)(b)). The 30-day post-termination window supports account recovery if requested and transitional operational needs. Storage: UK-hosted Postgres database. Deletion mechanism: Scheduled hard deletion job runs daily; processes accounts 30 days past termination. Verified deletion includes database rows, any cached copies, and authentication-provider records. Exception: Does not apply where a legal obligation requires longer retention (e.g., financial records, see below).

Financial records (invoices, payment history, VAT)

Categories: Invoice numbers, payment amounts, VAT details, Stripe identifiers. Retention period: 7 years from the end of the relevant tax year. Rationale: UK statutory requirement under the Companies Act 2006 and HMRC VAT regulations (Art 6(1)(c) legal obligation). Storage: Cogent Clinic database and Stripe. Deletion mechanism: Scheduled annual review; records past 7 years deleted. Note: Deletion of financial records does not delete the underlying customer account record where other obligations apply.

Audit log entries

Categories: User ID, timestamp, action type (for example document generated, exported, account setting changed), document type, model used. No content. Retention period: 24 months from log creation. Rationale: Supports security monitoring, DPA and DPIA accountability, incident investigation, and response to data subject access requests. 24 months balances operational utility against data minimisation. Storage: UK-hosted Postgres database and UK-hosted observability store. Deletion mechanism: Automated monthly deletion job removes entries older than 24 months.

Usage counters

Categories: Per-user, per-model, per-month counts of generations. Retention period: Rolling 24 months at per-month granularity; longer aggregated data without individual identifiers may be retained for business intelligence. Rationale: Supports billing enforcement, quota monitoring, and business analysis. Storage: UK-hosted Postgres database. Deletion mechanism: Automated pruning; individual-level data older than 24 months is deleted; aggregate statistics retained without personal identifiers.

Draft content

Categories: Draft documents the clinician has generated, including session notes, formulation letters, assessment reports, supervision briefs, and other document types. Always stored de-identified (placeholders replace names and identifiers before transmission). Retention period: Until the clinician deletes the draft or closes their account. Account closure triggers a soft-delete with a 7-day grace period, then hard deletion with foreign-key cascade. Rationale: Clinical documentation is long-lived by its nature. Supports continuity across weeks and months of work on a client. The de-identification posture means what is retained is not patient-identifiable content. Storage: UK-hosted Postgres database. Encrypted at rest. Deletion mechanism: Explicit per-draft delete action in the app (immediate). Account deletion cascades on the 7-day grace + hard-delete sweep.

Encrypted session transcripts

Categories: Transcripts of live clinical sessions, captured through the in-browser transcription feature, encrypted with a key derived from the clinician's password before upload. We hold ciphertext only. Retention period: Until the clinician deletes the transcript or closes their account. Indefinite retention is by design; clinicians control lifecycle. Rationale: A transcript is clinically useful across later sessions and report-writing. Because we cannot read the ciphertext, we do not make retention decisions on the clinician's behalf. Storage: UK-hosted Postgres database. Ciphertext only; the decryption key lives on the clinician's device. Deletion mechanism: Explicit per-transcript delete action in the app (immediate hard-delete). Account or client-folder deletion cascades.

Client-folder (per-client) records

Categories: Client labels (chosen by the clinician), tags, notes, and the living formulation (four plan sections: presenting issues, goals, interventions, next steps). Stored tokenised; the token map is held on the clinician's device, encrypted. Retention period: Until the clinician deletes the folder or closes their account. Rationale: The folder is the longitudinal record for one client. It persists for the duration of the clinical relationship. Storage: UK-hosted Postgres database. Deletion mechanism: Folder delete cascades to drafts, transcripts, formulation, and conversations filed within it.

Folder-scoped chat conversations

Categories: Clinician messages and AI replies in folder-scoped reflective-thinking chats. Clinician messages are written by the clinician into the reflective register (no patient-identifiable content expected); the AI has the folder's plan and recent drafts as cached system context. Retention period: Until the clinician deletes the conversation or the folder. Rationale: Reflective thinking across sessions is cumulative; retention preserves continuity. Storage: UK-hosted Postgres database. Deletion mechanism: Explicit per-conversation delete; cascades on folder or account deletion.

Formulation suggestions

Categories: AI-generated proposed updates to the living formulation, produced after a draft is accepted. Pending and terminal states, with per-section decisions (accepted, rejected, dismissed). Retention period: Until the clinician resolves or dismisses the suggestion, then retained as an audit record for the duration of the client folder. Rationale: Provides a decision trail for the clinician and supports consistent evolution of the formulation. Storage: UK-hosted Postgres database. Deletion mechanism: Cascades on folder or account deletion.

Tokenisation map (client-side, encrypted)

Categories: Mapping from placeholder tokens to original identifiers. Retention period: Persistent on the clinician's device until the clinician signs out or explicitly clears it. Rationale: The map is required to restore real names when the clinician views drafts they have generated previously. Storing it encrypted in browser IndexedDB lets the clinician open prior drafts without having to re-supply the context, while keeping the map on the clinician's device and out of our infrastructure. Storage: Browser IndexedDB, encrypted with a key derived from the clinician's password. Never transmitted to our servers. Deletion mechanism: Cleared on sign-out, explicit "lock tab" action, or password change. Per-draft entries are removed when the underlying draft is deleted.

Session tokens and authentication state

Categories: Session identifiers, CSRF tokens, MFA challenge state. Retention period: Session-bound, typically 1 to 24 hours with sliding renewal where configured. Rationale: Operational security and minimisation of session hijack exposure. Storage: Managed by authentication provider and relevant session infrastructure. Deletion mechanism: Automatic expiry and immediate revocation on logout, password reset, or administrator action.

Error tracking records

Categories: Error stack traces, timestamps, user ID, browser context. No document bodies or content should be captured. Retention period: 90 days. Rationale: Sufficient for debugging while limiting unnecessary storage of operational data. Storage: Error tracking provider in an approved region, or self-hosted equivalent. Deletion mechanism: Provider retention policy or scheduled purge.

Support correspondence

Categories: Emails and support tickets between Cogent Clinic and customers. Retention period: 3 years from the date of the last communication. Rationale: Necessary for operational follow-up, troubleshooting history, contractual defensibility, and continuity. Storage: Email provider and support records. Deletion mechanism: Annual review and purge.

Marketing communications data

Categories: Opt-in status, unsubscribe records, prospect email addresses, campaign preferences. Retention period: Until consent is withdrawn or 3 years of inactivity, whichever is shorter. Rationale: Consent-based communications should not continue indefinitely. Storage: Transactional email provider (EU). Deletion mechanism: Immediate suppression on unsubscribe and periodic inactivity review.

Beta-test feedback

Categories: Clinician-provided feedback, bug reports, usability notes, and interview notes. Retention period: Duration of the beta plus 1 year, or until no longer needed, whichever is shorter. Rationale: Legitimate interest in improving the product, balanced against minimisation. Storage: Founder-controlled project records and selected support tools. Deletion mechanism: End-of-programme review.

De-identified test corpus

Categories: De-identified clinical notes used to validate tokenisation and generation quality, or synthetic test cases. Retention period: For the operational lifetime of the product, subject to annual review. Rationale: Needed for regression testing and safety validation. Material must remain genuinely de-identified to fall outside personal data scope. Storage: Private founder-controlled repository or secure internal storage. Deletion mechanism: Annual review; remove anything no longer needed or assessed as insufficiently de-identified.

Data subject deletion requests

A clinician's deletion request should trigger deletion of:

• account data,
• saved drafts,
• user-linked usage counters,
• user-linked operational data where deletion is legally and technically appropriate.

Financial and compliance records required by law are retained until the statutory period expires.

Where we act as processor for clinician-submitted content, the clinician controller's instructions determine deletion timing, subject to legal and technical limits.