Data Processing Agreement

Effective 24 May 2026. Auto-incorporated into each customer's terms of service.

Data Processing Agreement

This Data Processing Agreement ("DPA") forms part of the agreement between:

Controller: the clinician practice or regulated healthcare professional using Cogent Clinic ("Customer")
and
Processor: Cogent Clinic Ltd ("Provider")

and applies where the Provider processes personal data on behalf of the Customer in connection with the Cogent Clinic service.

1. Purpose and relationship of the parties

1.1 The Customer is the controller of the personal data processed through its use of the service, to the extent that such data constitutes personal data under applicable data protection law.

1.2 The Provider is the processor and will process personal data only on documented instructions from the Customer, unless required to do otherwise by law.

1.3 The parties intend this DPA to satisfy Article 28 UK GDPR and, where relevant, equivalent requirements under the Data Protection Act 2018.

2. Definitions

For the purposes of this DPA:

• Applicable Data Protection Law means UK GDPR, the Data Protection Act 2018, PECR where applicable, and any successor or related legislation.
• Controller, Processor, Data Subject, Personal Data, Personal Data Breach, and Processing have the meanings given in Applicable Data Protection Law.
• Service means the Cogent Clinic software and related support services.
• Sub-processor means any third party appointed by the Provider to process personal data on behalf of the Customer.

3. Subject matter and duration

3.1 Subject matter: provision of an AI-assisted clinical practice environment, including draft documentation support, client-folder workflow, living formulation, reflective-thinking chat, live session transcription, handwritten-note extraction, and documentation-completeness review.

3.2 Duration: for as long as the Provider processes personal data on behalf of the Customer in connection with the Service.

4. Nature and purpose of the processing

4.1 The Provider processes data in order to provide the Service, including:

• receiving clinician-submitted content (structured fields and free-text narrative) for document generation and revision,
• generating draft documentation, formulation-suggestion proposals, folder-scoped reflective-thinking chat replies, and documentation-completeness checks,
• storing draft outputs under the clinician's account, re-tokenised server-side so the stored form does not contain direct patient identifiers,
• storing client-side-encrypted session transcripts captured through the in-browser live-transcription feature; the Provider holds only ciphertext,
• relaying audio from the clinician's browser to an EU-hosted speech-to-text sub-processor for live transcription; UK GDPR transfers are covered by the UK Addendum to the EU SCCs within the sub-processor's Data Processing Addendum; the Provider has opted out of the sub-processor using audio or transcripts for model training, benchmarking, or de-identified model development; audio is not routed through the Provider's infrastructure,
• extracting text from clinician-uploaded handwritten-note PDFs or images through Bedrock in AWS London before the extracted text is returned for tokenisation review,
• maintaining related metadata, audit records, and technical logs necessary to operate the Service securely.

4.2 The product is designed so that patient-identifiable information is replaced with placeholders in the clinician's browser before content is transmitted for inference. The mapping between placeholders and original identifiers is held on the clinician's device, encrypted with a key derived from the clinician's account password, and is not transmitted to the Provider. Session transcripts captured through the live-transcription feature are encrypted on the clinician's device using the same key before upload, and are stored by the Provider as ciphertext only. The parties acknowledge that this design materially reduces the identifiable patient data reaching the Provider's infrastructure and inference sub-processors, but does not eliminate all residual risk. A plain-English explanation of the design, the residual-risk scenarios, and the Customer's responsibility for reviewing tokenisation before submission is published on the Trust Centre as "Scope of use" and "AI principles"; the Customer may cite those pages in its own DPIA.

5. Types of personal data and categories of data subjects

5.1 Categories of data subjects may include:

• the Customer,
• the Customer's staff or authorised users,
• the Customer's patients,
• third parties referred to in clinical records.

5.2 Types of personal data may include:

• clinician account data,
• professional contact details,
• authentication data,
• usage and audit metadata,
• de-identified or pseudonymised clinical content held server-side (drafts, formulation sections, chat messages, formulation-suggestion proposals),
• ciphertext of session transcripts encrypted client-side with a key held only on the clinician's device,
• in residual-risk scenarios, special category data including health information that may be inferable from clinical context even after tokenisation, or that may reach the Service where tokenisation is bypassed or fails.

6. Customer obligations

6.1 The Customer warrants that it has all necessary rights, lawful bases, notices, and procedures in place to collect, use, and disclose personal data to the Provider for the purposes of the Service.

6.2 The Customer remains responsible for:

• determining whether use of the Service is appropriate for its practice,
• ensuring an appropriate Article 6 lawful basis and, where relevant, Article 9 condition,
• ensuring users are trained in the safe use of the Service,
• reviewing outputs before relying on them clinically or operationally,
• ensuring that identifying information is not unnecessarily submitted.

6.3 The Customer must not use the Service in a manner that is unlawful or contrary to the agreement.

7. Provider obligations

The Provider shall:

7.1 process personal data only on the Customer's documented instructions, including as set out in the main service agreement and this DPA;

7.2 ensure that persons authorised to process personal data are subject to confidentiality obligations;

7.3 implement appropriate technical and organisational measures to protect personal data, taking into account the nature of the processing and the risks involved;

7.4 assist the Customer, taking into account the nature of processing and the information available to the Provider, with responding to requests from data subjects;

7.5 assist the Customer with security, breach notification, impact assessments, and regulatory consultation obligations, insofar as required by Article 28(3)(f) UK GDPR;

7.6 notify the Customer of a Personal Data Breach affecting Customer personal data without undue delay, and in any event no later than 72 hours after the Provider becomes aware of it. Where the full set of information set out in clause 11.2 is not available within that window, the Provider will issue an initial notification with the information then available and follow up as further information is established;

7.7 at the Customer's choice, delete or return personal data within 30 days of the end of the provision of services, unless the Provider is required by law to retain it or unless the Customer requests a different window in writing;

7.8 make available to the Customer information reasonably necessary to demonstrate compliance with this DPA.

8. Security measures

8.1 The Provider will maintain the following technical and organisational security measures:

• TLS encryption in transit with HSTS,
• encryption at rest for the primary database and secrets store,
• UK-region hosting for clinical-content processing, handwriting extraction, ciphertext transcript storage, audit logs, and backups; the live-transcription speech-to-text sub-processor is EU-hosted, with UK GDPR transfers covered by the UK Addendum to the EU SCCs, a contractual opt-out from model training and benchmarking submitted, and audio streamed browser-direct without transiting the Provider's infrastructure,
• client-side tokenisation of patient-identifying details before transmission for inference, and client-side encryption of session transcripts before upload, in both cases using a key derived from the Customer user's account password that is not held by the Provider,
• role-based access controls enforcing least privilege for Provider personnel,
• mandatory time-based one-time-password (TOTP) two-factor authentication on Customer user accounts, enforced server-side,
• metadata-only logging at every layer; draft bodies, chat messages, transcripts, and structured-field content are scrubbed before transmission to any logging or error-tracking sub-processor,
• append-only audit logging with a cryptographic hash chain verified nightly,
• server-side pattern scanning of AI output for raw identifier shapes and client-side round-trip validation before a draft is signed off,
• per-user rate limits and a per-user daily spend cap on AI inference,
• documented retention limits, documented incident response, and a documented vulnerability-management process.

8.2 The Customer acknowledges that no security measure eliminates risk entirely and that the Provider's obligations are to implement measures appropriate to the nature of the processing and the state of the art, not to guarantee absolute security.

9. Sub-processors

9.1 The Customer gives general authorisation for the Provider to use sub-processors for the delivery of the Service, provided the Provider maintains an up-to-date list of sub-processors on the Trust Centre and imposes, by written contract, the same data protection obligations as are set out in this DPA on each sub-processor, in accordance with Article 28(4) UK GDPR.

9.2 The Provider shall give the Customer at least 30 days' advance notice of any intended addition, substitution, removal, or change of processing region of a sub-processor. Notice will be given by:

• updating the Trust Centre sub-processors register with an effective date, and
• sending an email notification to the primary billing and administrative contacts on the Customer's account,

and customers may subscribe to change notices on the Trust Centre. A material change does not take effect in respect of the Customer's data until the notice period has expired.

9.3 The Customer may object to a new or substituted sub-processor on reasonable data protection grounds by notifying the Provider within the 30-day notice period. The parties will work in good faith to resolve the objection, including by exploring alternative sub-processors or alternative technical arrangements that meet the Customer's grounds. If the objection cannot reasonably be resolved within a further 30 days, the Customer may terminate the affected Service for convenience and without penalty, with a pro-rata refund of any prepaid fees for the unused portion of the then-current subscription term, and the Provider will delete or return Customer personal data in accordance with clause 7.7. Termination under this clause does not by itself give rise to any further liability for either party.

9.4 In addition to the rights in clause 9.3, the Customer may at any time withdraw an authorisation previously given for a specific sub-processor by written notice to the Provider, stating the grounds. To the extent the withdrawal prevents the Provider from continuing to provide the affected Service, the parties will discuss in good faith whether an alternative arrangement can be put in place. If no alternative can reasonably be put in place, either party may terminate the affected Service with a pro-rata refund as described in clause 9.3.

10. International transfers

10.1 The Provider will not transfer Customer personal data outside the UK unless an appropriate safeguard is in place under Applicable Data Protection Law.

10.2 Where a transfer outside the UK occurs, the Provider will ensure that it is covered by an adequacy decision, the UK IDTA, the UK Addendum to SCCs, or another lawful transfer mechanism.

10.3 Everything the Provider stores, including clinical-content processing, draft and formulation records, ciphertext session transcripts, audit logs, and backups, is performed and retained in the United Kingdom. Live session audio, when the live-transcription feature is used, is streamed browser-direct to a speech-to-text sub-processor hosted in the European Union, with the transfer covered by the UK Addendum to the EU SCCs (within the sub-processor's Data Processing Addendum); the Provider has opted out of the sub-processor using customer audio or transcripts for model training or benchmarking; the audio is not stored by the sub-processor and does not transit the Provider's infrastructure. Transactional email, error tracking, and product analytics sub-processors operate in the European Union and do not receive draft bodies, chat messages, transcripts, or patient-identifying content. Limited international transfers of account and billing metadata may occur via the payment-processing sub-processor under UK IDTA and EU SCCs. The sub-processors register on the Trust Centre sets out the processing-location category and transfer mechanism for each sub-processor category; the named current sub-processor identities are provided to customers in the Data Processing Agreement and on request.

11. Personal data breaches

11.1 The Provider will notify the Customer of a Personal Data Breach affecting Customer personal data without undue delay, and in any event no later than 72 hours after the Provider becomes aware of it.

11.2 The notification will include, to the extent known at the time:

• the nature of the breach,
• the categories of data affected,
• the likely consequences,
• the measures taken or proposed,
• a contact point for follow-up.

11.3 The Provider will provide updates as further information becomes available.

12. Assistance with data subject rights

12.1 Taking into account the nature of the processing, the Provider will provide reasonable assistance to the Customer in responding to data subject requests.

12.2 If the Provider receives a request directly from a data subject relating to Customer personal data, the Provider will, unless prohibited by law, promptly refer the request to the Customer and will not respond substantively except on the Customer's instructions.

13. Deletion and return of data

13.1 Upon termination of the Service, the Provider will delete or return Customer personal data, at the Customer's choice, unless retention is required by law.

13.2 The Provider may retain:

• financial records where legally required (for example under the Companies Act 2006 and HMRC VAT requirements),
• limited compliance records necessary to evidence legal obligations,
• securely isolated backup data for up to 7 days, after which it is overwritten in the ordinary course.

13.3 Any optional saved drafts will be deleted in line with the Provider's retention controls unless the Customer requests export before deletion.

14. Audit and information rights

14.1 The Provider will make available reasonable information necessary to demonstrate compliance with this DPA.

14.2 Any audit rights shall be exercised in a proportionate manner, on reasonable notice, during normal business hours, and subject to confidentiality safeguards and the security of other customers.

14.3 The Provider may satisfy audit obligations through documentation, certifications, security summaries, penetration-test summaries, or other equivalent evidence where appropriate.

15. Liability and precedence

15.1 Liability under this DPA is subject to the liability provisions in the main service agreement unless Applicable Data Protection Law requires otherwise.

15.2 If there is a conflict between this DPA and the main agreement on data protection matters, this DPA prevails to the extent of that conflict.

16. Annex 1, details of processing

A. Subject matter

AI-assisted clinical practice environment: draft documentation generation and revision, client-folder workflow, living formulation, folder-scoped reflective-thinking chat, live session transcription, handwritten-note extraction, and documentation-completeness review.

B. Duration

For the duration of the Service and any agreed post-termination retention period.

C. Nature of processing

Collection, organisation, structuring, storage (including storage of ciphertext the Provider cannot read), retrieval, use, transmission for inference, transmission for handwritten-note extraction, transmission for live speech-to-text, and deletion.

D. Purpose

To provide the Service and related support, security, and account administration.

E. Categories of data subjects

• clinician customers,
• clinician staff or users,
• patients,
• third parties mentioned in records.

F. Categories of personal data

• account and billing data,
• authentication and security data,
• usage metadata,
• de-identified or pseudonymised clinical text (drafts, formulation sections, chat messages, formulation-suggestion proposals),
• clinician-uploaded handwritten-note images or PDFs during extraction only,
• client-side-encrypted session transcript ciphertext (Provider cannot read),
• potentially special category health data in residual-risk cases.

G. Special category data

Health data may be implicated in residual-risk scenarios where identifying or clinical material is submitted or not fully tokenised.

H. Per-activity processing table

The table below sets out, for each functional surface of the Service, the purpose of the processing, the categories of personal data involved, the data subjects, the processing location, the sub-processors involved, and the retention period. Where the Service's design routes personal data away from the Provider's infrastructure (live-transcription audio, ciphertext transcripts), this is stated.

Processing activity	Purpose	Categories of personal data	Data subjects	Processing location	Sub-processors involved	Retention
Account and authentication	Create and maintain the clinician's account, enforce two-factor authentication, allow sign-in	Clinician name, professional title, work email, hashed password, TOTP secret, backup codes, IP and user-agent metadata for audit	Clinician customer	UK	AWS UK (compute, database), Zoho (email)	Until account closure plus the audit retention period in the Retention Schedule
Billing	Take payment for the subscription, issue statements of charges, manage subscription state	Clinician name, billing email, last 4 digits of payment card, billing address, plan tier, period dates, invoice metadata	Clinician customer	UK with limited transfer to Stripe-controlled regions under IDTA and EU SCCs	Stripe	As required by Companies Act 2006 and HMRC VAT rules, then deleted
Document drafting	Generate a draft of a clinical or administrative document from clinician-submitted structured fields and free-text narrative	Tokenised clinical narrative (free of direct patient identifiers, with placeholders such as [PERSON_N] in place of real names), clinician structured-field input, modality preference, draft body	Clinician customer; pseudonymised references to patients and third parties	UK	AWS UK (compute), Anthropic via AWS Bedrock UK region (inference only, no training, no retention beyond the request)	Drafts stored server-side, tokenised, until the clinician deletes them
Client-folder workflow and living formulation	Maintain a per-client folder, including tokenised treatment-plan sections, formulation diagrams, formulation suggestions, and uploaded clinical documents	Tokenised clinical text, clinician-coined pseudonyms (folder labels such as "AS / anxiety"), clinician-authored formulation prose, diagram payloads	Clinician customer; pseudonymised references to patients	UK	AWS UK	Until the clinician deletes the client folder. Soft-deleted folders are permanently removed after the grace period stated in the Retention Schedule
Reflective-thinking chat	Run a folder-scoped chat the clinician uses to think out loud about a case	Tokenised chat messages, model replies, conversation metadata	Clinician customer; pseudonymised references to patients	UK	AWS UK, Anthropic via AWS Bedrock UK region (inference only)	Stored in the client folder until the clinician deletes the conversation; same lifecycle as the folder
Live session transcription, audio path	Stream microphone audio from the clinician's browser to a speech-to-text sub-processor and receive a transcript	Raw session audio (may contain identifiable speech of clinician, patient, and third parties)	Clinician customer; patient; third parties present in the room	EU (AssemblyAI). Audio is streamed browser-direct to the sub-processor and does not transit Provider infrastructure	AssemblyAI	The audio is not retained by the sub-processor under the contractual model-training opt-out; transcripts are not retained by the sub-processor. The clinician's browser holds the transcript only as long as the session window is open
Live session transcription, ciphertext storage	Save the session transcript as ciphertext the Provider cannot read	Ciphertext only. The encryption key is derived in the browser from the clinician's account password and is not transmitted to the Provider	Clinician customer (indirectly; underlying plaintext refers to patient and clinician)	UK	AWS UK	Indefinite as ciphertext. Clinician deletes through the in-product interface; deletion is permanent within the period stated in the Retention Schedule
Handwritten-note extraction	Extract text from a clinician-uploaded handwritten-note PDF or image so the clinician can review tokenisation before the text enters a draft	Uploaded image or PDF and the extracted text (may contain identifying information until the clinician reviews tokenisation)	Clinician customer; patient; third parties named in the note	UK	AWS UK (storage), Anthropic via AWS Bedrock UK region (inference only)	Uploaded file is deleted within 24 hours of successful extraction; extracted text passes into the clinician's workflow and is then subject to the same retention as the destination surface (draft, formulation section, and so on)
Documentation-completeness review	Review a finished draft and surface clinician-facing prompts for sections that look thin or missing	Tokenised draft body, the prompt list returned to the clinician	Clinician customer; pseudonymised references to patients	UK	AWS UK, Anthropic via AWS Bedrock UK region (inference only)	Same as the draft it relates to
Audit logging	Maintain an append-only audit chain for every security-relevant action (sign-in, MFA setup, document creation, deletion, sub-processor objection, and similar)	Clinician user id, event type, timestamp, IP, user-agent, redacted action metadata. No clinical text in audit records	Clinician customer	UK	AWS UK	As stated in the Retention Schedule
Error and exception tracking	Detect runtime errors so the Provider can fix defects	Error type, stack trace, redacted context. Draft bodies, chat messages, transcripts, and structured-field content are stripped before transmission	Clinician customer	EU (Sentry)	Sentry	90 days
Product analytics	Measure usage of features (in aggregate) to inform product decisions	Anonymised event metadata. Draft bodies, chat messages, transcripts, and structured-field content are not transmitted	Clinician customer	EU (PostHog)	PostHog	As stated in the Retention Schedule
Transactional email	Send verification, password-reset, two-factor codes, beta-invite, and breach-notification emails	Recipient email, sender email, subject, message body, delivery metadata	Clinician customer	EU (Zoho)	Zoho	Per Zoho's standard retention; the Provider does not retain mailbox copies beyond the audit record of the send

I. Retention summary and deletion

A consolidated retention schedule, including the soft-delete grace period for client folders and the post-termination 30-day deletion window, is published as the Retention Schedule on the Trust Centre and prevails over any inconsistent retention statement in this Annex.

17. Annex 2, technical and organisational measures

The Provider maintains:

• UK-hosted infrastructure for clinical-content workflows and handwriting extraction; EU-hosted live-transcription sub-processor covered by the UK Addendum to the EU SCCs, with model-training opt-out submitted,
• client-side tokenisation of patient-identifying details before transmission for inference, with the token map held only on the clinician's device,
• client-side encryption of session transcripts before upload, using a key derived from the clinician's account password,
• access controls and least privilege,
• mandatory MFA on clinician accounts, enforced server-side,
• encryption in transit,
• encryption at rest for the primary database and secrets store,
• append-only audit logging with cryptographic hash chain verified nightly,
• server-side identifier scanning of AI output and client-side round-trip validation before a draft is signed off,
• per-user rate limits and per-user daily AI-inference spend cap,
• incident response planning,
• data retention enforcement,
• sub-processor due diligence,
• secure development and patching practices.

18. Signature block

This DPA may be accepted electronically as part of the main customer agreement.

Customer
Name: ____________________
Organisation: ____________________
Signature: ____________________
Date: ____________________

Provider
Cogent Clinic Ltd
Company number: SC887432
Registered address: Mearns Castle Golf Academy, Waterfoot Road, Glasgow, G77 5RR
Privacy contact: [email protected]
Website: www.cogent.clinic
Name: ____________________
Signature: ____________________
Date: ____________________