Data Processing Agreement

Effective 19 June 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 to which the Provider is subject, in which case the Provider will inform the Customer of that legal requirement before processing, unless the law prohibits such notice on important grounds of public interest.

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, documentation-completeness review, standardised-measure administration and scoring, between-session homework journals, supervision and session-preparation briefs, and formulation diagrams.

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 sections drawn from the clinician's own content, 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 session transcripts captured through the in-browser live-transcription feature, encrypted at rest under a Provider-held key in AWS Key Management Service (KMS) with access scoped to least-privilege roles and logged,
• 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's opt-out from the sub-processor using audio or transcripts for model training, benchmarking or de-identified model development was confirmed in writing by the sub-processor on 23 April 2026; 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.1.1 Two features collect personal data from the Customer's patient directly rather than through the clinician, and the Customer should account for them separately in its own records of processing.

• Standardised measures. The clinician issues a time-limited link for a named standardised measure. The patient completes it in their own browser and the responses are stored encrypted at rest under a Provider-held key in AWS Key Management Service (KMS). Scoring is arithmetic, applied by the Service without inference, and the clinician reviews the result before it is imported to the client folder. Responses are not transmitted for inference before that review.
• Homework journals. The clinician approves a set of prompts and issues a time-limited link. The patient writes free text in their own browser and the entry is stored encrypted at rest on the same basis. The entry is not transmitted for inference at any point before the clinician has reviewed and saved it.

In both cases the link is the only route in, the Provider does not contact the patient, and the Provider does not collect the patient's name or contact details through either feature.

4.2 Three processing paths carry different exposure, and they are described separately because a single statement about them would be inaccurate.

(a) Clinician-submitted text. Patient-identifiable information is replaced with placeholders in the clinician's browser, and the clinician confirms the de-identification, before the content is transmitted for inference. On this path, which carries the great majority of clinical content through the Service, the inference sub-processor does not receive direct patient identifiers.

(b) Session audio. Where the clinician uses live transcription, the audio stream is relayed from the clinician's browser to the speech-to-text sub-processor as spoken. It therefore contains whatever names and identifying detail were spoken in the session. This is inherent in speech-to-text and is not a failure of de-identification. The safeguards on this path are contractual and architectural rather than technical de-identification: the sub-processor is EU-hosted, the Provider has opted out of the sub-processor using audio or transcripts for model training, benchmarking or de-identified model development, the sub-processor's zero-retention controls apply to streaming so audio and transcripts are not retained beyond the session, and the audio does not pass through the Provider's own infrastructure.

(c) Handwritten-note extraction. Where the clinician uploads a handwritten note as an image or PDF, the image bytes are sent to the inference sub-processor for transcription, and those bytes may contain identifying information. The protection on this path applies to the extracted text rather than to the image: the transcribed text is returned to the clinician for tokenisation review, and no extracted text enters a draft until the clinician has reviewed and confirmed the de-identification. Uploaded source images are session-bound and short-lived; see the Retention Schedule.

4.3 The mapping between placeholders and original identifiers, and any saved session transcripts captured through the live-transcription feature, are stored by the Provider encrypted at rest under a Provider-held key in AWS Key Management Service (KMS) on UK infrastructure, with access scoped to least-privilege roles and logged. The parties acknowledge that the Provider can technically decrypt this stored content under those access controls, and that the design therefore materially reduces the identifiable patient data reaching the inference sub-processor on path (a) rather than rendering stored content unreadable to the Provider.

4.4 Because the Provider holds the placeholder mapping, tokenised clinical content is pseudonymised personal data in the Provider's hands within the meaning of Article 4(5) UK GDPR, and is not anonymous data outside the scope of applicable data protection law. Clause 5.2 states the categories accordingly.

4.5 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,
• pseudonymised clinical content held server-side (drafts, formulation sections, chat messages). Because the Provider holds the placeholder mapping, this content is personal data in the Provider's hands and is not anonymous data; see clause 4.4,
• the placeholder mapping and saved session transcripts, stored encrypted at rest under a Provider-held key in AWS Key Management Service (KMS), with access scoped to least-privilege roles and logged,
• clinician-uploaded handwritten notes, as images or PDFs, which are session-bound and short-lived and may contain identifying information before the clinician's tokenisation review.

5.3 The Service routinely processes special category personal data concerning health, within the meaning of Article 9 UK GDPR. This is not a residual or exceptional case and the Customer should treat it as the ordinary position when carrying out its own data protection impact assessment. It arises at least through:

• saved session transcripts, which are identifiable clinical content,
• the placeholder mapping, which permits re-identification of tokenised content,
• session audio relayed for transcription, which contains spoken clinical content as described in clause 4.2(b),
• uploaded handwritten notes before tokenisation review, as described in clause 4.2(c),
• health information that remains inferable from clinical context after tokenisation.

5.4 Separately from clause 5.3, a residual risk remains that a direct identifier reaches the Service where tokenisation is bypassed, fails, or is not corrected by the clinician at review. The Customer's review obligation under clause 6 addresses this risk; it does not eliminate it.

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 24 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;

7.9 immediately inform the Customer if, in the Provider's opinion, an instruction from the Customer infringes Applicable Data Protection Law. The Provider is not obliged to carry out an instruction it reasonably considers to be unlawful.

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, storage of saved transcripts and the placeholder mapping (encrypted at rest under a Provider-held KMS key), 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, benchmarking and de-identified model development confirmed in writing by the sub-processor on 23 April 2026, and audio streamed browser-direct without transiting the Provider's infrastructure,
• client-side tokenisation of patient-identifying details before transmission for inference, so the inference sub-processors do not receive real names; the placeholder mapping and saved session transcripts are stored encrypted at rest under a Provider-held key in AWS Key Management Service (KMS), with decryption restricted to least-privilege application roles and decrypt operations logged,
• role-based access controls enforcing least privilege for Provider personnel,
• time-based one-time-password (TOTP) two-factor authentication available on Customer user accounts and enforced server-side when enabled (optional for clinician users, required for the Provider's administrator accounts),
• 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, data protection obligations on each sub-processor that satisfy Article 28(3) UK GDPR and are no less protective of personal data than those set out in this DPA, in accordance with Article 28(4) UK GDPR.

9.1.1 The Provider's commercial and operational timescales under this DPA, including the breach notification period in clauses 7.6 and 11.1 and the sub-processor objection period in clause 9.3, are obligations of the Provider to the Customer. They are not represented as being mirrored in the Provider's contracts with its own sub-processors, several of which are engaged on the sub-processor's standard terms. The Provider remains liable to the Customer for the performance of those obligations irrespective of the periods its sub-processors offer it, and the periods each sub-processor does offer are stated in the Trust Centre sub-processor register. Where a sub-processor fails to fulfil its data protection obligations, the Provider remains liable to the Customer for the performance of that sub-processor's obligations, subject to clause 15.1.

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.2.1 The notice period in clause 9.2 does not apply where the Provider must remove or replace a sub-processor urgently to protect personal data, including on discovery of a security compromise, a loss of certification, or a change that would place the sub-processor outside the safeguards recorded for it. In those circumstances the Provider may act immediately and will notify the Customer without undue delay and in any event within the period in clause 11.1, with reasons. This clause permits urgent removal and replacement for the protection of personal data; it does not permit the Provider to add a sub-processor for its own convenience without notice.

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.

7.10 The Provider does not use Customer personal data, including clinical content, draft bodies, formulation text, chat messages, transcripts, uploaded notes, or any identifier the Customer has entered into the Service, to train, fine-tune, evaluate or develop any model, nor for product improvement, nor for any purpose other than providing and securing the Service to the Customer. This obligation is the Provider's own and is in addition to the contractual position of the Provider's sub-processors recorded in clause 4.2 and in the Trust Centre sub-processor register. Clause 8.4 of the Terms of Service states the same limit in respect of feedback.

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.2.1 For clarity on the mechanism relied on in each case. Transfers from the United Kingdom to the European Economic Area are made on the basis of the UK adequacy regulations for the EEA, under which no additional transfer mechanism is required. The UK Addendum to the EU Standard Contractual Clauses is relied on for onward access from outside the EEA where a sub-processor's support or engineering functions sit in a third country, which is the position for the live-transcription sub-processor and the payment sub-processor. Where a sub-processor relies on a different mechanism, the Trust Centre sub-processor register states which.

10.3 All clinical content held on the Provider's own infrastructure, including clinical-content processing, draft and formulation records, the placeholder mapping, saved session transcripts (encrypted at rest under a Provider-held KMS key), audit logs, and backups, is performed and retained in the United Kingdom. Certain operational sub-processors, named later in this clause and in the Trust Centre register, are hosted in the European Union; this clause describes the Provider's own infrastructure and not those sub-processors. 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's opt-out from the sub-processor using customer audio or transcripts for model training, benchmarking or de-identified model development was confirmed in writing by the sub-processor on 23 April 2026. Separately from that opt-out, the sub-processor's zero-retention controls apply to streaming, so audio and transcripts are not retained beyond the session; only limited logging and billing metadata is kept. The audio 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-processor register on the Trust Centre names each current sub-processor and sets out its processing location and transfer mechanism. Copies of each sub-processor's executed data processing addendum are available on request at privacy@cogent.clinic.

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 24 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 the placeholder mapping and saved session transcripts encrypted at rest under a Provider-held KMS key, with access least-privilege and logged), 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,
• pseudonymised clinical text (drafts, formulation sections, chat messages), which is personal data in the Provider's hands because the Provider holds the placeholder mapping,
• clinician-uploaded handwritten-note images or PDFs, session-bound and short-lived, which may contain identifying information before tokenisation review,
• the placeholder mapping and saved session transcripts, stored encrypted at rest under a Provider-held KMS key with access least-privilege and logged (Provider can technically decrypt under those controls),
• special category personal data concerning health, routinely and by design; see clause 5.3 and section G below.

G. Special category data

Special category personal data concerning health is processed routinely and by design, not only in residual-risk scenarios. See clause 5.3, which sets out the routes through which it arises: saved session transcripts, the placeholder mapping, session audio relayed for transcription, uploaded handwritten notes before tokenisation review, and health information that remains inferable from clinical context after tokenisation.

Separately, a residual risk remains that a direct identifier reaches the Service where tokenisation is bypassed, fails, or is not corrected by the clinician at review. See clause 5.4.

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 is streamed browser-direct to the EU sub-processor and does not transit Provider infrastructure), and where it stores identifiable content on the Provider's infrastructure encrypted at rest under a Provider-held key (the placeholder mapping and saved 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, offer two-factor authentication (optional for clinicians, required for administrators), 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 sections drawn from the clinician's own content, 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, encrypted storage	Save the session transcript, stored encrypted at rest under a Provider-held KMS key	Saved transcript stored encrypted at rest under a Provider-held key in AWS KMS, with access least-privilege and logged; Provider can technically decrypt under those controls	Clinician customer (indirectly; underlying content refers to patient and clinician)	UK	AWS UK (storage and KMS)	Indefinite. 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	Non-content event metadata (account id, feature, doc type, timestamps); pseudonymous, not anonymous. Draft bodies, chat messages, transcripts, and structured-field content are not transmitted. Captured server-side; no analytics cookie is set	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 the model-training opt-out confirmed in writing by the sub-processor on 23 April 2026,
• client-side tokenisation of patient-identifying details before transmission for inference, so the inference sub-processors do not receive real names; the placeholder mapping is stored encrypted at rest under a Provider-held key in AWS KMS, with access least-privilege and logged,
• storage of saved session transcripts encrypted at rest under a Provider-held key in AWS KMS, with access least-privilege and logged,
• access controls and least privilege,
• TOTP two-factor authentication available on clinician accounts (optional for clinicians, required for administrators), enforced server-side when enabled,
• 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: privacy@cogent.clinic
Website: www.cogent.clinic
Name: ____________________
Signature: ____________________
Date: ____________________