Trust Centre UK GDPR Article 6
Lawful basis
The lawful basis Cogent relies on for each category of processing, and how that basis is reflected in the privacy notices.
Version 1.0 · in effect from 5 July 2026
This page maps Cogent Clinic's core processing activities to the lawful basis under which each one is carried out, with the processor-side activities set out separately and the special-category-data position named explicitly.
Controller processing
| Processing activity | Data subjects | Data categories | Lawful basis |
|---|---|---|---|
| Website enquiry handling | Prospects, website visitors | Name, email, enquiry details, phone if supplied | Article 6(1)(b) for pre-contract steps, or Article 6(1)(f) legitimate interests for general business enquiries |
| Waitlist management | Prospects | Name, email, organisation, interest notes | Article 6(1)(f) legitimate interests, or Article 6(1)(a) consent where framed as marketing signup |
| Marketing emails | Prospects, customers | Email, preferences, engagement data | Article 6(1)(a) consent, with PECR compliance where applicable |
| Customer onboarding and account setup | Clinician customers, authorised users | Name, work email, credentials, MFA, account data | Article 6(1)(b) contract |
| Billing and financial administration | Clinician customers | Billing details, invoices, payment identifiers | Article 6(1)(b) contract and Article 6(1)(c) legal obligation |
| Support and service communications | Clinician customers, authorised users | Contact details, support messages, service context | Article 6(1)(b) contract and Article 6(1)(f) legitimate interests |
| Security logging and fraud prevention | Customers, users, some visitors | IP, user IDs, timestamps, audit metadata | Article 6(1)(f) legitimate interests, with Article 6(1)(c) where legal accountability applies |
| Product-usage analytics (authenticated app) | Clinician customers, authorised users | Server-side, cookieless, metadata-only usage events (feature used, document type, timestamps, account identifier); no draft, chat, transcript, or client-identifying content | Article 6(1)(f) legitimate interests (see the Legitimate Interests Assessment). No PECR consent is engaged: the analytics provider's browser SDK is never loaded, so no cookie or client-side storage is set |
| Essential cookies and site measurement | Visitors, users | First-party strictly-necessary sign-in and session cookies only | Necessary to deliver the requested service, so no consent is required. No non-essential, advertising, or cross-site tracking cookies are set on the marketing site or the product (strict-necessary-only posture, per the cookie policy) |
Processor processing
| Processing activity | Controller | Data categories | UK GDPR position |
|---|---|---|---|
| Draft generation from clinician-submitted content | Clinician customer | Tokenised clinical narrative (placeholders in place of real names); still special category health data, because the draft is re-identifiable through the placeholder mapping | Processor under Article 28, on the clinician's documented instructions |
| Saved drafts and client-folder content (treatment plans, formulation, diagrams) | Clinician customer | Tokenised clinical text and clinician-authored formulation prose; special category health data | Processor under Article 28 |
| Folder-scoped reflective-thinking chat | Clinician customer | Tokenised chat messages and model replies; special category health data | Processor under Article 28 |
| Documentation-completeness review | Clinician customer | Tokenised draft body and the prompt list returned to the clinician; special category health data | Processor under Article 28 |
| Handwritten-note extraction | Clinician customer | Uploaded image or PDF and the extracted text, which may contain identifiers until the clinician reviews tokenisation; special category health data | Processor under Article 28; UK-hosted cleartext pre-tokenisation step, the uploaded file deleted within 24 hours |
| Live session transcription (audio path) | Clinician customer | Raw session audio, which may contain identifiable speech of clinician, patient, and third parties; special category health data | Processor under Article 28; audio streamed browser-direct to an EU speech-to-text sub-processor (AssemblyAI) under the UK Addendum to the EU SCCs, not transiting Cogent infrastructure |
| Saved session transcripts (encrypted store) | Clinician customer | Identifiable, untokenised session transcript; special category health data, and the single most sensitive store | Processor under Article 28; stored encrypted at rest under a provider-held AWS KMS key, access least-privilege and logged, which Cogent can technically decrypt |
Special category data
Cogent Clinic routinely processes special category health data as a processor, and this is not a rare edge case. A de-identified draft remains special category data, because the placeholder mapping re-identifies it, and a saved session transcript is identifiable health data by design. The clinician customer is the controller and provides the applicable Article 9 condition, ordinarily Article 9(2)(h) (provision of health or social care) in their role as a healthcare professional. Cogent's de-identification step reduces the identifiable data reaching the inference model and its sub-processors; it does not remove the special category nature of the data Cogent processes on the clinician's behalf.