Data Processing Agreement
Version d2-v0.7-2026-10-05 · Last updated 30 September 2026
Working draft. Draft v0.7 — pending independent DPO review. Not yet in effect; published as a preview of the Data Processing Agreement Aurical intends to adopt. You will be asked to accept the updated version when it is published.
This Data Processing Agreement ("DPA") is entered into between you, the therapist or practice entity using Aurical ("the Controller"), and:
Aurical Ltd ("the Processor" / "Aurical") Company Number: 17257201 Registered Address: SIU Offices, 4-6 Greatorex Street, London, E1 5NF, United Kingdom
Together "the Parties."
RECITALS
A. The Controller is a talking therapist (clinical psychologist, counselling psychologist, psychotherapist, counsellor, or CBT therapist) operating in private practice in the United Kingdom, who is a data controller in respect of their clients' personal data.
B. The Processor provides a practice management and clinical documentation platform ("Aurical" / "the Service") that processes personal data on behalf of the Controller.
C. This DPA sets out the terms on which the Processor will process personal data on behalf of the Controller, in compliance with Article 28 of the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018.
D. This DPA is supplemental to and forms part of the Aurical Terms of Service ("the Agreement"). In the event of conflict between this DPA and the Agreement, this DPA shall prevail in respect of data protection matters.
E. The Service processes data relating to adult clients (18+) only. Processing of data relating to children and young people is not supported in the current version of the Service.
1. Definitions
In this DPA, unless the context otherwise requires:
"Applicable Data Protection Law" means the UK GDPR (the retained EU law version of Regulation (EU) 2016/679 as it forms part of UK law), the Data Protection Act 2018, the Privacy and Electronic Communications Regulations 2003, and any successor legislation.
"Client" means an individual who is a client of the Controller and whose personal data is processed through the Service.
"Client Data" means all personal data relating to Clients that is processed by the Processor on behalf of the Controller through the Service.
"Data Breach" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Client Data.
"Data Subject" means an identified or identifiable natural person whose personal data is processed under this DPA.
"IDTA" means the UK International Data Transfer Agreement issued by the ICO under Section 119A of the Data Protection Act 2018, or the UK Addendum to the EU Standard Contractual Clauses.
"Processing" has the meaning given in Article 4(2) UK GDPR.
"Special Category Data" means data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data, data concerning health, or data concerning a natural person's sex life or sexual orientation, as defined in Article 9(1) UK GDPR.
"Sub-Processor" means any third party engaged by the Processor to process Client Data on behalf of the Controller.
"UK GDPR" means the UK General Data Protection Regulation as defined in Section 3(10) of the Data Protection Act 2018.
2. Subject Matter, Duration, Nature and Purpose
2.1 Subject Matter
The Processor shall process Client Data solely for the purpose of providing the Service to the Controller, as described in this Clause 2 and Schedule 1.
2.2 Duration
This DPA shall remain in force for the duration of the Controller's subscription to the Service, and shall continue in respect of any Client Data retained by the Processor after termination, until all Client Data has been deleted or returned in accordance with Clause 11.
2.3 Nature and Purpose of Processing
The Processor provides a clinical practice management platform that assists the Controller with:
(a) Conversational thread interface (primary workspace): A per-client conversational interface through which the Controller accesses all Service capabilities via natural-language requests. The Service uses AI-based tool-use/function-calling to determine the Controller's requested action. On each interaction, a context bundle of the Client's existing records is transmitted to the AI inference provider.
(b) Clinical documentation: AI-assisted generation of draft session notes, clinical formulations, client-facing session summaries, and therapeutic tools (session prep, thought records, defusion exercises, behavioural experiments, compassionate letters). All AI-generated content is presented as a draft for the Controller's review, optional editing, and approval.
(c) Real-time audio transcription (opt-in): Where the Controller and Client have both provided explicit consent, the Service captures audio from the Controller's microphone during therapy sessions, streams it in real-time to a UK-based transcription provider, and displays a live transcript to the Controller during the session. Audio is never persisted — it is processed as a transient stream and discarded after transcription. On session end, the finalised transcript is stored and used to generate a draft session note.
(d) Client onboarding: Collecting intake questionnaire responses and validated screening measure responses (PHQ-9, GAD-7, CORE-10, ORS/SRS) from Clients, scoring those measures, and presenting results to the Controller.
(e) Interactive therapeutic tools: Providing Clients with structured interactive forms (thought records, behavioural experiments, defusion worksheets) that Clients complete between sessions. Client responses are stored as part of the clinical record and visible to the Controller.
(f) Appointment management: Scheduling appointments, sending reminders to Clients on behalf of the Controller.
(g) Payment processing: Generating invoices and facilitating payment collection via a third-party payment processor on behalf of the Controller.
(h) Email triage: Categorising incoming client emails and generating draft responses for the Controller's review and approval.
(i) Client engagement: Providing a client-facing dashboard where Clients can view appointments, invoices, therapist-approved session summaries, therapist-approved therapeutic tools and exercises, log daily mood entries, complete therapist-assigned tasks, and complete periodic outcome measures. Clients do not have access to the raw conversational thread.
2.4 Controller Instructions
The Processor shall process Client Data only on documented instructions from the Controller. In the conversational thread interface, the Controller's natural-language requests constitute instructions to the Processor. For audio recording, the Controller's activation of the recording feature (after Client consent is documented) constitutes an instruction to process the audio stream.
If the Processor is required by Applicable Data Protection Law to process Client Data other than on the Controller's instructions, the Processor shall inform the Controller of that legal requirement before processing, unless the law prohibits such information on important grounds of public interest.
3. Types of Personal Data and Categories of Data Subjects
3.1 Categories of Data Subjects
(a) Clients of the Controller — adults (18+) receiving talking therapy services. May include vulnerable individuals (persons with mental health conditions, emotional distress, trauma).
(b) The Controller themselves (therapist) — professional and financial data processed for account management and payment processing.
3.2 Types of Personal Data Processed
| Category | Data Types | Special Category? |
|---|---|---|
| Client identity | Name, email address, telephone number, date of birth | No |
| Clinical notes | Session notes, progress notes (typed or derived from audio transcription) | Yes — health data |
| Clinical formulations | AI-drafted psychological formulations (therapist-approved) | Yes — health data |
| Session summaries | Client-facing summaries of therapy sessions (therapist-approved) | Yes — health data |
| Screening/outcome measures | PHQ-9, GAD-7, CORE-10, ORS/SRS questionnaire responses and calculated scores | Yes — health data |
| Mood data | Daily mood ratings (numerical scale) and optional text notes | Yes — health data |
| Homework/prompts | Therapist-assigned therapeutic tasks, pre/post-session prompt responses | Yes — health data |
| Thread conversation history | Per-client conversation between the Controller and the Service's AI | Yes — health data (contains clinical content) |
| Message artifacts | AI-generated actionable outputs within threads: therapeutic tools, session prep, draft bookings, draft invoices, formulation updates | Yes — health data (where clinical); No (where administrative) |
| Interactive tool responses | Client-completed therapeutic exercises: thought records, behavioural experiments, defusion worksheets, compassionate letters | Yes — health data (clinical self-reports) |
| Audio stream (transient) | Real-time audio captured from the Controller's microphone during therapy sessions (opt-in). Streamed and discarded — never persisted. | Yes — health data |
| Live transcript / finalised transcript | Real-time transcript of therapy session audio with speaker diarisation. Live fragments are transient; finalised transcript stored as clinical record. | Yes — health data |
| Email content | Client-therapist email communications processed through the Service | Potentially — if health-related |
| Appointment data | Dates, times, attendance status | No |
| Financial data | Invoice amounts, payment status, billing references | No |
| Authentication data | Email, hashed password, session tokens | No |
3.3 Special Category Data
The Parties acknowledge that the Processor will process Special Category Data (health data) as part of the Service. This includes:
- Clinical records (notes, formulations, session summaries, transcripts)
- Client self-reports (mood entries, screening responses, interactive therapeutic tool responses)
- Conversational thread content (therapist-AI clinical discussion)
- Transient audio and live transcript data during recorded sessions
- Clinical context bundles assembled and transmitted to the AI inference provider on each thread interaction
The Controller is responsible for ensuring that a valid condition under Article 9 UK GDPR applies to this processing (see Clause 4). Where audio recording is used, explicit consent under Article 9(2)(a) must be obtained from the Client before recording begins. The Processor shall treat all Client Data with the heightened security and confidentiality measures appropriate to Special Category health data.
4. Controller Obligations and Rights
The Controller warrants, represents, and undertakes that:
4.1 Lawful Basis
(a) The Controller has established a valid lawful basis under Article 6 UK GDPR for the processing of Client Data through the Service.
(b) The Controller has established a valid condition under Article 9 UK GDPR for the processing of Special Category Data through the Service. Where the Controller relies on Article 9(2)(h) (health professional condition), the Controller shall maintain an Appropriate Policy Document in compliance with Schedule 1, Part 1, Paragraph 2 and Part 4 of the Data Protection Act 2018.
(c) Where audio recording is used, the Controller has obtained explicit consent from the Client in compliance with Article 9(2)(a) UK GDPR, and has documented that consent.
4.2 Privacy Notice
The Controller shall provide their Clients with a clear, accessible privacy notice that:
(a) Identifies the Controller as the data controller;
(b) Describes the processing carried out through the Service, including the use of AI-assisted documentation;
(c) Names Aurical as the data processor;
(d) Explains the human-in-the-loop approval process;
(e) Sets out the Client's rights under Applicable Data Protection Law.
Aurical provides a template privacy notice for Controllers to adapt.
4.3 Instructions
The Controller is responsible for ensuring that their instructions to the Processor comply with Applicable Data Protection Law. The Controller acknowledges that AI-generated outputs are drafts only and that the Controller bears clinical and legal responsibility for reviewing, editing, and approving all content before it enters the clinical record or is made visible to the Client.
4.4 Clinical Responsibility
The Controller retains full clinical responsibility for:
(a) The accuracy and appropriateness of approved session notes, formulations, and session summaries;
(b) The selection and interpretation of screening and outcome measures;
(c) All clinical decisions made in the course of treatment;
(d) Compliance with their professional body's code of ethics and standards of practice.
The Processor's Service is a documentation and administration tool. It does not provide clinical advice, diagnosis, or treatment recommendations.
4.5 Data Subject Rights
The Controller is responsible for responding to data subject access requests and other rights requests from Clients. The Processor shall assist the Controller in fulfilling these obligations (see Clause 5.5).
4.6 DPIA
The Controller is responsible for conducting a Data Protection Impact Assessment where required by Article 35 UK GDPR. The Processor provides a DPIA as a resource, but the Controller should review it in the context of their own practice and seek independent advice where appropriate.
5. Processor Obligations
The Processor shall:
5.1 Processing Limitations
(a) Process Client Data only on documented instructions from the Controller, as set out in Clause 2.4.
(b) Not process Client Data for any purpose other than providing the Service, unless required by Applicable Data Protection Law.
(c) Not sell, rent, or otherwise commercially exploit Client Data.
(d) Not use Client Data to train, fine-tune, or improve any artificial intelligence or machine learning model without separate, explicit, informed consent from the relevant Data Subjects. This prohibition applies to all forms of model improvement, including but not limited to: supervised fine-tuning, reinforcement learning from human feedback, embedding generation, distillation, and any form of model training or evaluation that uses Client Data as input. See also Clause 9.
5.2 Confidentiality
(a) Ensure that all persons authorised to process Client Data are subject to appropriate obligations of confidentiality (whether contractual or statutory).
(b) Limit access to Client Data to personnel who require access for the performance of the Service.
5.3 Security
(a) Implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing, as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons. These measures shall include, as a minimum, those set out in Schedule 2.
(b) The Processor shall regularly test, assess, and evaluate the effectiveness of these measures.
5.4 Sub-Processing
(a) The Controller provides general written authorisation for the Processor to engage the Sub-Processors listed in Schedule 3, subject to the conditions in Clause 6.
(b) The Processor shall impose on each Sub-Processor, by way of a written contract, data protection obligations no less onerous than those set out in this DPA.
5.5 Assistance with Data Subject Rights
(a) The Processor shall, taking into account the nature of the processing, assist the Controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the Controller's obligation to respond to requests for exercising the Data Subject's rights under Chapter III of the UK GDPR (access, rectification, erasure, restriction, portability, and objection).
(b) The Processor shall promptly notify the Controller if it receives a request from a Data Subject directly, and shall not respond to that request except on the Controller's documented instructions.
(c) The Service shall provide the Controller with the ability to access, export, rectify, and delete Client Data through the Service's interface.
5.6 Assistance with DPIA and Prior Consultation
The Processor shall provide such information as is reasonably necessary to assist the Controller with any DPIA and any prior consultation with the ICO under Articles 35 and 36 UK GDPR.
5.7 Records of Processing
The Processor shall maintain records of processing activities carried out on behalf of the Controller, in compliance with Article 30(2) UK GDPR.
6. Sub-Processors
6.1 General Authorisation
The Controller hereby provides general written authorisation for the Processor to engage the Sub-Processors listed in Schedule 3 of this DPA.
6.2 Notification of Changes
(a) The Processor shall notify the Controller in writing at least 30 days before engaging a new Sub-Processor or replacing an existing Sub-Processor.
(b) The notification shall include: the Sub-Processor's name, the nature of the processing, the location of processing, and the transfer mechanism (if applicable).
(c) The Processor shall maintain a current list of Sub-Processors, accessible to the Controller via the Service.
6.3 Objection Right
(a) The Controller may object to the engagement of a new or replacement Sub-Processor by notifying the Processor in writing within 14 days of receiving the notification under Clause 6.2.
(b) The objection must set out reasonable grounds relating to data protection.
(c) If the Controller objects, the Processor shall use reasonable efforts to make available an alternative Sub-Processor or to modify the Service to avoid processing by the objected-to Sub-Processor.
(d) If the Processor cannot reasonably accommodate the objection, either Party may terminate the affected portion of the Service (or, if the Sub-Processor is integral to the Service, the Agreement) on 30 days' written notice, and the Processor shall refund any prepaid fees for the terminated period.
6.4 Sub-Processor Obligations
The Processor shall:
(a) Enter into a written agreement with each Sub-Processor imposing data protection obligations no less protective than those in this DPA.
(b) Remain fully liable to the Controller for the performance of each Sub-Processor's obligations.
(c) Conduct appropriate due diligence on each Sub-Processor's data protection practices before engagement.
(d) Ensure that each Sub-Processor's contract includes: processing limitations consistent with this DPA; confidentiality obligations; security measures appropriate to Special Category health data; breach notification obligations (see Clause 7); the prohibition on model training set out in Clause 9; and data deletion obligations on termination.
7. Personal Data Breach
7.1 Processor Notification to Controller
(a) The Processor shall notify the Controller of a Data Breach without undue delay, and in any event within 24 hours of becoming aware of it.
(b) The notification shall include, to the extent known at the time: a description of the nature of the breach, including where possible the categories and approximate number of Data Subjects and records concerned; the name and contact details of the Processor's contact point; a description of the likely consequences of the breach; and a description of the measures taken or proposed to address the breach.
(c) Where it is not possible to provide all information at the time of notification, the Processor shall provide the information in phases without further undue delay.
7.2 Sub-Processor Breach Cascade
The Processor shall ensure that each Sub-Processor agreement includes a breach notification obligation of no more than 24 hours from the Sub-Processor to the Processor, so that the cascade (Sub-Processor → Processor → Controller) can be completed within 48 hours.
7.3 Cooperation
The Processor shall cooperate with the Controller and provide all reasonable assistance in investigating the breach, fulfilling the Controller's obligations to notify the ICO and affected Data Subjects, mitigating the effects of the breach, and documenting the breach and remedial actions.
7.4 Processor's Own Breach Log
The Processor shall maintain a log of all Data Breaches (whether or not notifiable to the ICO), including the facts of the breach, its effects, and the remedial action taken.
8. International Data Transfers
8.1 General Principle
The Processor shall not transfer Client Data outside the United Kingdom or the European Economic Area unless:
(a) The transfer is to a country or territory that has been granted an adequacy decision by the UK Secretary of State under Section 17A of the Data Protection Act 2018; or
(b) Appropriate safeguards are in place in accordance with Article 46 UK GDPR, including execution of a UK International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, together with a Transfer Risk Assessment where required.
8.2 Current Transfers
The Processor's Sub-Processors include entities headquartered in the United States (see Schedule 3). Although data is processed and stored within the UK and/or EEA (as specified in Schedule 3), the corporate relationship with US parent entities constitutes a restricted transfer requiring appropriate safeguards. For each such Sub-Processor, the Processor has ensured that either the Sub-Processor's DPA includes UK IDTA or UK Addendum provisions, or a separate IDTA has been executed. Details of transfer mechanisms are set out in Schedule 3.
8.3 Data Residency Commitment
The Processor commits that Client Data at rest shall be stored within the United Kingdom (AWS eu-west-2, London) or the European Economic Area, operationally enforced through region-pinning of all infrastructure components as described in Schedule 3.
8.4 Changes in Transfer Law
If the legal basis for any international transfer is invalidated, the Processor shall: promptly notify the Controller; take reasonable steps to ensure continuity of adequate safeguards; and, if adequate safeguards cannot be maintained, work with the Controller to identify alternative processing arrangements or, if necessary, suspend the affected processing.
9. Prohibition on Model Training
9.1 Absolute Prohibition
The Processor shall not use Client Data — in any form, including anonymised, pseudonymised, aggregated, or de-identified forms — to train, fine-tune, evaluate, benchmark, or otherwise improve any artificial intelligence or machine learning model, whether owned by the Processor, a Sub-Processor, or any third party.
9.2 Scope
This prohibition applies to: all Client Data described in Clause 3, including but not limited to clinical notes, formulations, session summaries, screening scores, mood entries, audio recordings, and transcriptions; all prompts, queries, and inputs sent to AI/LLM services in the course of providing the Service; all AI-generated outputs produced from Client Data; and any metadata derived from Client Data that could reveal clinical information.
9.3 Sub-Processor Cascade
The Processor shall ensure that each Sub-Processor (including LLM inference providers and transcription services) is contractually bound by an equivalent prohibition, and shall verify that LLM providers and transcription providers do not use prompts, outputs, audio, or transcripts for model training, and that any Sub-Processor default permitting training on customer data has been explicitly opted out of.
9.4 Exception: Separate Consent
The prohibition in Clause 9.1 may only be overridden if separate, specific, informed consent is obtained from the relevant Data Subject(s), distinct from any consent for the provision of the Service, and the consent clearly describes the purpose, scope, and nature of the model training. As of v1, the Processor does not seek or intend to seek such consent.
9.5 Audit and Verification
The Controller may request, no more than once per calendar year, written confirmation from the Processor that the prohibition in this Clause 9 is being complied with, including evidence of opt-out confirmations from relevant Sub-Processors.
10. Audit Rights
10.1 Right to Audit
(a) The Processor shall make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Article 28 UK GDPR and in this DPA.
(b) The Processor shall allow for and contribute to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller.
10.2 Scope and Procedure
(a) Audits may cover: data processing activities, security measures, Sub-Processor compliance, breach response procedures, training records, and compliance with this DPA.
(b) The Controller shall give the Processor at least 30 days' written notice of an intended audit, unless the audit is in response to a Data Breach or regulatory investigation, in which case reasonable notice shall be given.
(c) Audits shall be conducted during normal business hours and shall not unreasonably disrupt the Processor's operations.
(d) The Controller shall bear the costs of the audit, unless the audit reveals material non-compliance by the Processor, in which case the Processor shall bear reasonable costs.
10.3 Third-Party Certifications
The Processor may satisfy audit requests in whole or in part by providing current third-party security certifications, penetration test reports (redacted for other customer data), or written responses to a reasonable audit questionnaire. Provision of such certifications does not extinguish the Controller's audit right but may reduce the scope of on-site inspection required.
10.4 Confidentiality
Any information obtained during an audit shall be treated as confidential and shall not be disclosed to third parties except to the extent required by law or regulation.
11. Termination and Deletion
11.1 Return and Deletion on Termination
(a) Upon termination or expiry of the Agreement, the Processor shall, at the Controller's election: (i) return all Client Data to the Controller in a structured, commonly used, machine-readable format; and/or (ii) delete all Client Data from the Processor's systems, including all copies, backups, and replicas, except to the extent that retention is required by Applicable Data Protection Law.
(b) The Controller shall communicate their election within 30 days of termination. If the Controller does not communicate an election, the Processor shall delete all Client Data.
11.2 Deletion Timeline
(a) The Processor shall complete deletion within 90 days of the Controller's election (or the expiry of the 30-day election period).
(b) Backup copies that cannot be immediately deleted due to technical constraints shall be isolated from production systems and deleted at the earliest opportunity, and in any event within 180 days.
(c) The Processor shall provide written confirmation of deletion upon request.
11.3 Export Functionality
The Service shall provide the Controller with a self-service data export function that allows the Controller to export all Client Data at any time during the subscription, without charge.
11.4 Ongoing Obligations
The Processor's obligations under this DPA shall continue in respect of any Client Data retained after termination (e.g., for legal compliance) until all such data is deleted.
11.5 Specific Deletion Rules
| Data Type | Deletion Trigger | Timeline |
|---|---|---|
| Audio recordings | Confirmed transcription | Immediate (within minutes, automated) |
| All Client Data (on termination) | Controller election or 30-day default | 90 days (production) / 180 days (backups) |
| Authentication credentials | Account closure | 30 days |
| Financial records (invoices) | Termination + HMRC retention period | 7 years from creation, then deleted |
Schedule 1 — Description of Processing
| Field | Description |
|---|---|
| Subject matter of processing | Provision of a clinical practice management and documentation platform for talking therapists |
| Duration of processing | Duration of the Controller's subscription to the Service, plus post-termination retention/deletion period |
| Nature of processing | Collection, recording, storage, retrieval, use (including AI-assisted text generation), disclosure by transmission (to Controller and authorised Clients), alignment (combining intake data with session data), restriction, erasure, destruction |
| Purpose of processing | To enable the Controller to manage their therapy practice, create and maintain clinical records, communicate with Clients, process payments, and engage Clients between sessions |
| Types of personal data | As set out in Clause 3.2 of this DPA |
| Categories of data subjects | As set out in Clause 3.1 of this DPA |
| Special category data | Health data (clinical notes, formulations, session summaries, screening/outcome scores, mood data, audio recordings, transcriptions, therapeutic homework content) |
| Controller's obligations | As set out in Clause 4 of this DPA |
| Processor's obligations | As set out in Clauses 5-11 of this DPA |
Schedule 2 — Technical and Organisational Measures
The Processor implements the following technical and organisational measures to protect Client Data, appropriate to the Special Category nature of the data processed.
Encryption
| Measure | Implementation |
|---|---|
| Application-layer encryption | AES-256-GCM encryption of sensitive clinical text fields before storage. Encrypted fields include note content, formulation content, transcript content, session summary content, tool content, thread message content, and mood entry notes. The database stores ciphertext only — it cannot read clinical content. Keys are held in an EU-incorporated environment, separate from the database provider. |
| Encryption at rest (database layer) | AES-256, in addition to the application-layer encryption above |
| Encryption in transit | TLS (minimum TLS 1.2) for all data transmissions between client, server, and Sub-Processors |
Access Control
| Measure | Implementation |
|---|---|
| Authentication | Email verification; hashed passwords |
| Authorisation | Role-based access control: therapist (tenant admin) and client (scoped to their therapist) |
| Multi-tenant isolation | Every clinical record is scoped to a specific therapist and enforced through server-side access checks before each database operation. PostgreSQL Row-Level Security is additionally enabled on all production tables as a defense-in-depth measure. |
| Principle of least privilege | Clients see only their own data; therapists see only their own clients' data; Aurical staff access is restricted to operational necessity |
Data Minimisation
| Measure | Implementation |
|---|---|
| Audio deletion | Real-time streaming — audio is never persisted and is discarded after transcription |
| Analytics exclusion | Product analytics configured to exclude clinical data content |
| Payment metadata | Invoice descriptions restricted to non-clinical content |
| LLM data retention | Zero Data Retention enforced with the AI inference provider — no prompts or completions are stored, and no model training occurs on Client Data |
Availability and Resilience
| Measure | Implementation |
|---|---|
| Database backups | Aurical is moving to a database service tier with automated backups ahead of general availability; current status can be requested under the audit provisions in Clause 10 |
| Infrastructure redundancy | Provider-managed hosting resilience for the database and application layers |
Organisational Measures
The Processor is building out its organisational security programme ahead of general availability, including staff data-protection training, a documented incident response plan, independent penetration testing, and audit logging of access to clinical records. Current status of these measures can be requested under the audit provisions in Clause 10.
Schedule 3 — Sub-Processor Register
The following Sub-Processors are authorised by the Controller under Clause 6.1 of this DPA. Changes to this list are governed by the notification and objection mechanism in Clause 6.2-6.3.
| # | Sub-Processor | Purpose | Data Processed | Processing Location | Jurisdiction | DPA Status |
|---|---|---|---|---|---|---|
| 1 | HostStack (MICCI) | Application hosting, server-side processing, WebSocket relay, encryption key holder | Request/response data, transient audio relay. Holds application-layer encryption keys. | Hetzner DE/FI (EU) | Denmark | Executed |
| 2 | Supabase, Inc. | Authentication + database | All Client Data. Sensitive clinical fields stored as encrypted ciphertext. | AWS eu-west-2 (London) | US | Executed, with app-layer encryption as a supplementary measure |
| 3 | Cantab Research Ltd (Speechmatics) | Real-time streaming transcription + speaker diarisation | Transient audio (never stored); live transcript fragments | Azure EU/UK | UK | Executed |
| 4 | Amazon Web Services (Bedrock) | AI text generation | Clinical prompts, context bundles, thread history (all transient — Zero Data Retention enforced) | AWS eu-west-2 (London) | US | Executed, with Zero Data Retention as a supplementary measure |
| 5 | Stripe Payments Europe Ltd | Payments and invoicing | Financial data only — no clinical content | Dublin | Ireland | Executed |
| 6 | PostHog, Inc. | Product analytics | Usage data only — no clinical content | Frankfurt (EU Cloud) | US (EU-hosted) | Executed |
| 7 | Google (Calendar API) | Calendar sync | Appointment data only — no clinical content | Google infrastructure | US | Executed |
| 8 | Resend (Plus Five Five, Inc.) | Transactional email delivery | Recipient email address, sender address, email subject line, email body (non-clinical), delivery metadata | United States | US | Executed, with content minimisation as a supplementary measure |
| 9 | Microsoft (Graph API — Microsoft 365 / Outlook / Teams) | Calendar sync (event push/update/delete, busy-time read) and auto-provisioned Teams meeting links for online sessions, where the Controller connects a Microsoft account | Appointment date/time; client-initials-only event label (no full name or email sent); optional non-clinical location text; Teams join URL; the Controller's own connected mailbox address (for busy-time queries) | Variable — the Controller's own Microsoft 365 tenant or personal Outlook.com account; not controlled or pinned by Aurical | US (Microsoft Corporation) | Under review — no clinical data is sent |
This list is maintained on an ongoing basis and updated in line with Clause 6.
General Provisions
Governing Law
This DPA shall be governed by and construed in accordance with the laws of England and Wales. The courts of England and Wales shall have exclusive jurisdiction.
Entire Agreement
This DPA, together with the Agreement and its Schedules, constitutes the entire agreement between the Parties in relation to the processing of Client Data.