Between:
(1) The Dental Practice (“the Controller”)
and
(2) Dental Marketing Ltd, a company registered in England and Wales under company number 16344607, whose registered office is at 20 Wenlock Road, London, N1 7GU (“the Processor”)
Effective Date: The date on which the Controller accepts or countersigns this Agreement, or the date on which the Controller first provides Personal Data to the Processor, whichever is earlier.
Background
(A) The Controller and the Processor have entered into an agreement for the provision of clinical note-taking, practice intelligence, and dental CRM services (the “Services Agreement”).
(B) In the course of providing the Services, the Processor will process Personal Data on behalf of the Controller.
(C) This Data Processing Agreement (“Agreement”) sets out the terms on which the Processor shall process Personal Data when providing Services under the Services Agreement. This Agreement contains the mandatory clauses required by Article 28(3) of the UK General Data Protection Regulation (the retained EU law version of Regulation (EU) 2016/679) (“UK GDPR”) for contracts between controllers and processors.
(D) The parties acknowledge that the processing of Personal Data under this Agreement involves special categories of personal data, namely data concerning health, and that such processing is carried out under Article 9(2)(h) of the UK GDPR (processing necessary for the provision of health care) as relied upon by the Controller. The Processor processes such data solely under the Controller’s documented instructions.
Agreed Terms
1. Definitions and Interpretation
1.1 In this Agreement, the following terms shall have the meanings set out below:
“Applicable Data Protection Law” means all laws and regulations relating to the processing of personal data and privacy that apply to the parties, including the UK GDPR, the Data Protection Act 2018 (and regulations made thereunder), and the Privacy and Electronic Communications (EC Directive) Regulations 2003 (SI 2003/2426), each as amended or replaced from time to time.
“Controller” has the meaning given in the UK GDPR: the natural or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of the processing of Personal Data.
“Data Subject” means an identified or identifiable natural person to whom Personal Data relates.
“ICO” means the Information Commissioner’s Office, the UK supervisory authority for data protection.
“Personal Data” means any information relating to an identified or identifiable natural person that is processed by the Processor as a result of, or in connection with, the provision of the Services under the Services Agreement.
“Personal Data Breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data transmitted, stored, or otherwise processed.
“Processing” (and “process”, “processed”, and “processes”) means any operation or set of operations performed on Personal Data or sets of Personal Data, whether or not by automated means, including collection, recording, organisation, structuring, storage, adaptation, alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment, combination, restriction, erasure, or destruction.
“Processor” has the meaning given in the UK GDPR: a natural or legal person, public authority, agency, or other body which processes Personal Data on behalf of the Controller.
“Services” means the Perpetua clinical note-taking platform, Practice Intelligence analytics and lead management system, Nurtura dental CRM services, and any related services provided by the Processor to the Controller under the Services Agreement.
“Special Category Data” means Personal Data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data for uniquely identifying a natural person, data concerning health, or data concerning a natural person’s sex life or sexual orientation.
“Sub-Processor” means any third party appointed by the Processor (or by any Sub-Processor of the Processor) to process Personal Data on behalf of the Controller in connection with this Agreement.
“UK GDPR” means the retained EU law version of the General Data Protection Regulation (EU) 2016/679, as it forms part of the law of England and Wales, Scotland, and Northern Ireland by virtue of section 3 of the European Union (Withdrawal) Act 2018.
“UK IDTA” means the International Data Transfer Agreement issued by the ICO under section 119A of the Data Protection Act 2018, as amended or replaced from time to time.
“UK SCCs” means the UK Addendum to the EU Standard Contractual Clauses, as issued by the ICO under section 119A of the Data Protection Act 2018, as amended or replaced from time to time.
1.2 The Schedules form part of this Agreement and shall have effect as if set out in full in the body of this Agreement. Any reference to this Agreement includes the Schedules.
1.3 A reference to writing or written includes email.
1.4 In the event of any conflict between the terms of this Agreement and the terms of the Services Agreement, the terms of this Agreement shall prevail in respect of the processing of Personal Data.
1.5 Words in the singular include the plural and vice versa.
2. Scope and Application
2.1 This Agreement applies to the Processing of Personal Data by the Processor on behalf of the Controller as described in Schedule 1.
2.2 The Controller is the data controller of the Personal Data. The Processor is the data processor. The Controller retains control of the Personal Data and remains responsible for its compliance obligations under Applicable Data Protection Law, including providing any required notices to Data Subjects and obtaining any necessary consents or establishing another lawful basis for Processing.
2.3 The Controller warrants that it has a lawful basis under Articles 6 and 9 of the UK GDPR for the Processing of Personal Data, including Special Category Data. The Controller relies on Article 9(2)(h) of the UK GDPR (processing necessary for the provision of health care) as the basis for processing health data. The Processor processes such data solely under the Controller’s instructions.
2.4 The categories of Data Subjects, types of Personal Data, and purposes of Processing are set out in Schedule 1.
3. Processor Obligations
3.1 The Processor shall:
(a) process the Personal Data only on documented instructions from the Controller, unless required to do so by law applicable to the Processor in the United Kingdom; in such a case, the Processor shall inform the Controller of that legal requirement before Processing, unless that law prohibits such information on important grounds of public interest;
(b) immediately inform the Controller if, in the Processor’s opinion, an instruction from the Controller infringes Applicable Data Protection Law;
(c) ensure that persons authorised to process the Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, in accordance with clause 5;
(d) implement and maintain the technical and organisational security measures set out in Schedule 2, in accordance with clause 6;
(e) observe the conditions set out in clauses 7 and 8 for engaging Sub-Processors and transferring Personal Data internationally;
(f) 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 Data Subjects’ rights, in accordance with clause 9;
(g) assist the Controller in ensuring compliance with the obligations set out in clauses 10 and 11, taking into account the nature of Processing and the information available to the Processor;
(h) at the choice of the Controller, delete or return all Personal Data to the Controller after the end of the provision of Services, and delete existing copies, in accordance with clause 13, unless applicable law requires storage of the Personal Data;
(i) make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Article 28 of the UK GDPR and allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller, in accordance with clause 12; and
(j) maintain written records of all categories of Processing activities carried out on behalf of the Controller, in accordance with Article 30(2) of the UK GDPR.
3.2 The Processor shall promptly comply with any request or instruction from the Controller requiring the Processor to amend, transfer, delete, or otherwise process the Personal Data, or to stop, mitigate, or remedy any unauthorised Processing.
4. Processing Instructions
4.1 The Processor shall process the Personal Data only for the purposes described in Schedule 1, unless:
(a) the Controller gives prior written instructions to the Processor for additional or alternative Processing; or
(b) Processing is required by applicable law, in which case the Processor shall notify the Controller before carrying out such Processing (unless the law prohibits such notification on important grounds of public interest).
4.2 The Controller’s instructions at the date of this Agreement are that the Processor may process the Personal Data for the purposes set out in Schedule 1 and solely to the extent necessary to provide the Services. The Controller may issue additional written instructions consistent with this Agreement and Applicable Data Protection Law from time to time.
5. Confidentiality
5.1 The Processor shall ensure that all personnel who have access to Personal Data:
(a) are informed of the confidential nature of the Personal Data and are subject to binding obligations of confidentiality, whether by contract, statutory obligation, or professional duty;
(b) have received appropriate training on their data protection responsibilities; and
(c) process the Personal Data only on the instructions of the Controller, unless required by applicable law.
5.2 The Processor shall ensure that access to Personal Data is limited to those personnel who require access for the performance of the Services.
5.3 The Processor shall not disclose Personal Data to any third party other than as permitted by this Agreement, as instructed by the Controller in writing, or as required by applicable law. Where the Processor is compelled by law to disclose Personal Data, the Processor shall, to the extent permitted by that law, promptly notify the Controller prior to disclosure and provide the Controller with a reasonable opportunity to seek protective measures.
6. Security Measures
6.1 The Processor shall implement and maintain the technical and organisational security measures set out in Schedule 2. These measures shall take 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.
6.2 The Processor’s security measures shall include, as appropriate:
(a) the pseudonymisation and encryption of Personal Data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services;
(c) the ability to restore the availability and access to Personal Data in a timely manner in the event of a physical or technical incident; and
(d) a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures for ensuring the security of the Processing.
6.3 In assessing the appropriate level of security, the Processor shall take account of the risks presented by Processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Personal Data transmitted, stored, or otherwise processed.
6.4 The Processor shall conduct periodic reviews of its security measures and update them as necessary to maintain an appropriate level of protection.
7. Sub-Processing
7.1 The Controller provides general written authorisation for the Processor to engage the Sub-Processors listed in Schedule 3.
7.2 When engaging any Sub-Processor, the Processor shall:
(a) carry out appropriate due diligence to ensure the Sub-Processor is capable of providing the level of protection for Personal Data required by this Agreement;
(b) enter into a written contract with the Sub-Processor that imposes data protection obligations no less protective than those set out in this Agreement, in particular providing sufficient guarantees to implement appropriate technical and organisational measures such that the Processing meets the requirements of Applicable Data Protection Law; and
(c) remain fully liable to the Controller for the performance of the Sub-Processor’s obligations.
7.3 The Processor shall notify the Controller in writing of any intended addition of or change to Sub-Processors. Such notification shall identify the proposed Sub-Processor, the Processing it will perform, and the location of Processing. The Controller may object in writing to the appointment of a new or replacement Sub-Processor within thirty (30) days of the date of the Processor’s notification. If the Controller objects within this period, the Processor shall either (i) not appoint the proposed Sub-Processor, or (ii) offer the Controller the right to terminate the Services Agreement with immediate effect. This right of objection does not apply to Sub-Processors listed in Schedule 3 at the date of this Agreement.
7.4 The current list of approved Sub-Processors is set out in Schedule 3.
8. International Transfers
8.1 The Processor shall not transfer Personal Data to a country outside the United Kingdom unless:
(a) the transfer is to a country, territory, sector, or international organisation that has been deemed adequate by the Secretary of State under section 17A of the Data Protection Act 2018;
(b) appropriate safeguards are in place, including the UK IDTA, UK SCCs, binding corporate rules, or any other transfer mechanism approved under Applicable Data Protection Law; or
(c) a derogation under Article 49 of the UK GDPR applies.
8.2 Where the Processor or any Sub-Processor transfers Personal Data outside the United Kingdom in reliance on the UK IDTA, UK SCCs, or equivalent standard contractual clauses, the Processor shall ensure that such clauses are incorporated into the relevant Sub-Processor agreement. The transfer safeguards applicable to each Sub-Processor are set out in Schedule 3.
8.3 The Processor shall, upon request, provide the Controller with copies of any international data transfer agreements or assessments relevant to the transfer of the Controller’s Personal Data.
8.4 Where the legal framework governing international data transfers changes (including any revocation of adequacy decisions, invalidation of transfer mechanisms, or new guidance from the ICO), the Processor shall promptly inform the Controller and work with the Controller to implement alternative safeguards.
9. Data Subject Rights Assistance
9.1 The Processor shall, taking into account the nature of the Processing, assist the Controller by implementing appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the Controller’s obligation to respond to requests from Data Subjects to exercise their rights under Chapter III of the UK GDPR, including:
(a) the right of access (Article 15);
(b) the right to rectification (Article 16);
(c) the right to erasure (Article 17);
(d) the right to restriction of processing (Article 18);
(e) the right to data portability (Article 20);
(f) the right to object (Article 21); and
(g) rights in relation to automated decision-making and profiling (Article 22).
9.2 If the Processor receives a request directly from a Data Subject, the Processor shall notify the Controller promptly and in any event within three (3) working days of receipt. The Processor shall not respond to any such request except on the documented instructions of the Controller, unless required by applicable law.
9.3 The Processor shall provide the Controller with such information and assistance as the Controller may reasonably require in order to comply with Data Subject requests. The Processor shall not charge the Controller for fulfilling its obligations under this clause 9.
9.4 The Processor shall provide all reasonable assistance to the Controller to enable it to comply with any information or assessment notices served on the Controller by the ICO or any other supervisory authority under Applicable Data Protection Law.
10. Data Protection Impact Assessment Assistance
10.1 The Processor shall provide reasonable assistance to the Controller with any data protection impact assessment that the Controller is required or elects to carry out under Article 35 of the UK GDPR, and with any prior consultation with the ICO or other supervisory authority under Article 36 of the UK GDPR, in each case solely in relation to the Processing carried out by the Processor on behalf of the Controller and taking into account the nature of the Processing and the information available to the Processor.
10.2 Such assistance shall include providing the Controller with:
(a) a description of the Processing operations, including the purposes and means of Processing;
(b) an assessment of the necessity and proportionality of the Processing;
(c) information about the technical and organisational security measures in place; and
(d) any other information reasonably required by the Controller to fulfil its obligations under Articles 35 and 36 of the UK GDPR.
11. Personal Data Breach Notification
11.1 The Processor shall notify the Controller of any Personal Data Breach without undue delay and in any event within seventy-two (72) hours of becoming aware of it.
11.2 Such notification shall include, to the extent available at the time of notification:
(a) a description of the nature of the Personal Data Breach, including, where possible, the categories and approximate number of Data Subjects affected and the categories and approximate number of Personal Data records concerned;
(b) the likely consequences of the Personal Data Breach;
(c) a description of the measures taken, or proposed to be taken, by the Processor to address the Personal Data Breach, including, where appropriate, measures to mitigate its possible adverse effects; and
(d) the name and contact details of the Processor’s data protection contact from whom further information may be obtained.
11.3 Where it is not possible to provide all the information specified in clause 11.2 at the time of the initial notification, the Processor shall provide it in phases without further undue delay as such information becomes available.
11.4 The Processor shall co-operate with the Controller and take all reasonable steps to assist in the investigation, mitigation, and remediation of any Personal Data Breach.
11.5 The Processor acknowledges that:
(a) only the Controller (not the Processor) is responsible for notifying the ICO and affected Data Subjects of a Personal Data Breach, unless the Processor is separately required by applicable law to make such notifications; and
(b) the Processor shall not make any public statement or notification regarding a Personal Data Breach without the prior written consent of the Controller, except where required by applicable law; and
(c) the Processor shall not offer any remedy, compensation, or other response to affected Data Subjects in connection with a Personal Data Breach without the prior written consent of the Controller.
12. Audit Rights
12.1 The Processor shall make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in this Agreement and in Article 28 of the UK GDPR.
12.2 The Processor shall allow for and contribute to audits, including inspections, conducted by the Controller or a third-party auditor mandated by the Controller, subject to the following conditions:
(a) the Controller shall provide at least thirty (30) days’ prior written notice of any audit;
(b) audits shall be conducted during the Processor’s normal business hours;
(c) audits shall not unreasonably interfere with the Processor’s business operations;
(d) the Controller shall bear the reasonable costs of any audit, including any costs incurred by the Processor in providing assistance and access;
(e) audits shall be limited to once per calendar year, unless there has been a Personal Data Breach or the Controller has reasonable grounds to believe the Processor is not meeting its obligations under this Agreement;
(f) any third-party auditor shall be required to enter into a confidentiality agreement with the Processor before commencing any audit; and
(g) the Controller shall ensure that any audit is conducted in a manner that does not compromise the security of the Processor’s systems or the Personal Data of other clients.
12.3 Where a Personal Data Breach occurs or the Processor becomes aware of a breach of its obligations under this Agreement, the Processor shall:
(a) conduct its own investigation to identify the cause;
(b) provide the Controller with a written report of the investigation, including proposals to remedy any issues identified; and
(c) implement the agreed remedial measures within thirty (30) days of agreement on the remedial measures, unless the parties agree in writing to a different timeframe.
12.4 On the Controller’s written request, the Processor shall audit a Sub-Processor’s compliance with its obligations regarding the Controller’s Personal Data and provide the Controller with the results of such audit.
13. Return and Deletion of Personal Data
13.1 The Processor shall apply the following retention periods to Personal Data:
(a) Audio recordings of patient consultations: deleted within ninety (90) days of successful transcription.
(b) Transcripts, clinical notes, treatment letters, and all other clinical data: retained for the duration of the Controller’s subscription to the Services.
(c) Billing and payment records: retained for six (6) years from the date of the transaction, as required by HM Revenue and Customs.
13.2 Upon termination or expiry of the Services Agreement, the Processor shall:
(a) provide the Controller with a thirty (30) day window in which to download or request a copy of the Controller’s Personal Data in a commonly used, machine-readable format;
(b) after the expiry of the thirty (30) day download window, delete all Personal Data held by the Processor in connection with the Controller, except to the extent that storage is required by applicable law (in which case the Processor shall inform the Controller of the applicable retention requirement); and
(c) instruct all Sub-Processors to delete the Controller’s Personal Data in accordance with their respective contractual obligations and applicable law.
13.3 Where the Controller requests it, the Processor shall provide written certification of the deletion of Personal Data within fourteen (14) days of such deletion being completed.
13.4 If the Processor is required by applicable law to retain any Personal Data following termination, the Processor shall:
(a) inform the Controller in writing, specifying the legal basis for retention and the anticipated retention period;
(b) continue to protect such Personal Data in accordance with this Agreement; and
(c) delete such Personal Data promptly upon expiry of the legal retention period.
14. Term and Termination
14.1 This Agreement shall come into effect on the Effective Date and shall continue for as long as the Processor processes Personal Data on behalf of the Controller.
14.2 This Agreement shall automatically terminate upon the termination or expiry of the Services Agreement, subject to the Processor’s obligations under clause 13 which shall survive termination.
14.3 The following clauses shall survive termination or expiry of this Agreement: clause 5 (Confidentiality), clause 11 (Personal Data Breach Notification), clause 12 (Audit Rights), clause 13 (Return and Deletion of Personal Data), clause 15 (Liability), and clause 16 (General Provisions).
15. Liability
15.1 Each party’s liability under this Agreement shall be subject to the limitations and exclusions of liability set out in the Services Agreement.
15.2 Nothing in this Agreement shall limit or exclude either party’s liability for:
(a) fraud or fraudulent misrepresentation;
(b) death or personal injury caused by negligence;
(c) any matter for which it would be unlawful to exclude or limit liability; or
(d) fines or penalties imposed by a supervisory authority directly upon a party for that party’s own breach of Applicable Data Protection Law.
15.3 The Processor shall indemnify the Controller against all claims, liabilities, costs, expenses, and damages (including reasonable legal fees) arising from:
(a) any breach by the Processor of its obligations under this Agreement;
(b) any Processing of Personal Data by the Processor that is not in accordance with the Controller’s documented instructions, except where such Processing is required by applicable law; or
(c) any act or omission of a Sub-Processor that constitutes a breach of the Sub-Processor’s obligations under its agreement with the Processor,
to the extent that such claims, liabilities, costs, expenses, or damages are directly attributable to the Processor’s breach, negligent act, or omission.
16. General Provisions
16.1 Data Protection Contact. The Processor’s data protection contact is:
- Name: Ope Sodeinde
- Email: ope@dental-marketing.io
- Address: 20 Wenlock Road, London, N1 7GU
The Processor shall notify the Controller in writing of any change to the data protection contact. The Processor does not currently appoint a Data Protection Officer under Article 37 of the UK GDPR and shall reassess this requirement periodically, and in any event when the Processor’s client base exceeds ten (10) dental practices.
16.2 EU Representative. The Processor does not currently process the Personal Data of Data Subjects who are in the European Union such that the appointment of an EU representative under Article 27 of the EU GDPR is required. The Processor shall appoint an EU representative if and when this becomes necessary.
16.3 Product Improvement. The Processor may analyse anonymised and aggregated data derived from the Personal Data for the purposes of product improvement, service development, and benchmarking. Such analysis shall be conducted only on data from which no individual Data Subject can be identified. This processing is carried out by the Processor in its capacity as an independent controller on the basis of legitimate interest, as disclosed in the Processor’s Privacy Policy.
16.4 Notice. Any notice or other communication given under or in connection with this Agreement shall be in writing and shall be delivered to:
(a) For the Controller: the address and email as specified in the Services Agreement.
(b) For the Processor: Ope Sodeinde, ope@dental-marketing.io, 20 Wenlock Road, London, N1 7GU.
A party may change its notice details by giving written notice to the other party.
16.5 Severability. If any provision of this Agreement (or part of any provision) is found by any court or administrative body of competent jurisdiction to be invalid, unenforceable, or illegal, the other provisions shall remain in force. If any invalid, unenforceable, or illegal provision would be valid, enforceable, and legal if some part of it were deleted, the provision shall apply with whatever modification is necessary to give effect to the commercial intention of the parties.
16.6 No Waiver. A failure or delay by either party to exercise any right or remedy provided under this Agreement or by law shall not constitute a waiver of that or any other right or remedy, nor shall it prevent or restrict any further exercise of that or any other right or remedy.
16.7 Entire Agreement. This Agreement (together with the Schedules and the Services Agreement) constitutes the entire agreement between the parties in relation to the processing of Personal Data in connection with the Services. It supersedes and extinguishes all prior negotiations, representations, warranties, undertakings, and agreements between the parties, whether written or oral, relating to such processing.
16.8 Amendment. No amendment to this Agreement shall be effective unless it is in writing and signed by or on behalf of each party.
16.9 Third Party Rights. A person who is not a party to this Agreement shall not have any rights under the Contracts (Rights of Third Parties) Act 1999 to enforce any term of this Agreement.
16.10 Governing Law. This Agreement, and any dispute or claim (including non-contractual disputes or claims) arising out of or in connection with it or its subject matter or formation, shall be governed by and construed in accordance with the law of England and Wales.
16.11 Jurisdiction. Each party irrevocably agrees that the courts of England and Wales shall have non-exclusive jurisdiction to settle any dispute or claim (including non-contractual disputes or claims) arising out of or in connection with this Agreement or its subject matter or formation.
17. Warranties
17.1 The Processor warrants and represents that:
(a) its personnel, Sub-Processors, and agents who process Personal Data are reliable and have received appropriate training on Applicable Data Protection Law;
(b) it and anyone processing Personal Data on its behalf shall process such data in compliance with Applicable Data Protection Law;
(c) it has no reason to believe that Applicable Data Protection Law prevents it from performing its obligations under this Agreement; and
(d) it shall implement and maintain the security measures described in Schedule 2 throughout the term of this Agreement.
17.2 The Controller warrants and represents that:
(a) it has a lawful basis under Applicable Data Protection Law (including, where applicable, an appropriate Article 9 condition) for the processing of Personal Data as described in this Agreement;
(b) it has provided all necessary privacy notices to Data Subjects and, where required, obtained appropriate consents;
(c) it shall comply with its obligations as a data controller under Applicable Data Protection Law; and
(d) the content and use of Personal Data as instructed by the Controller does not infringe the rights of any third party.
Execution
This Agreement is entered into by the parties on the Effective Date.
Signed for and on behalf of the Controller:
| Name: | ______________________________ |
| Position: | ______________________________ |
| Practice: | ______________________________ |
| Date: | ______________________________ |
| Signature: | ______________________________ |
Signed for and on behalf of the Processor:
| Name: | Ope Sodeinde |
| Position: | Director |
| Company: | Dental Marketing Ltd |
| Date: | ______________________________ |
| Signature: | ______________________________ |
Schedule 1 -- Processing Details
1. Subject Matter of Processing
The provision of AI-powered clinical note-taking (Perpetua), practice intelligence and lead management (Practice Intelligence), and dental CRM services (Nurtura) to dental practices in the United Kingdom.
2. Duration of Processing
Processing shall continue for the duration of the Services Agreement between the Controller and the Processor, and for such further period as Personal Data remains in the Processor’s possession in accordance with the retention periods set out in clause 13 of this Agreement.
3. Nature and Purpose of Processing
The Processor processes Personal Data for the purposes of providing the Services to the Controller. These purposes are organised by product below.
3.1 Perpetua (Clinical Note-Taking)
| # | Purpose |
|---|---|
| 1 | Authenticating clinicians and linking them to their dental practice |
| 2 | Creating and storing patient records (personal details, medical history, allergies, medications) |
| 3 | Creating and storing appointment records (date, procedure type, clinician assignment) |
| 4 | Recording audio of dental consultations for the purpose of transcription |
| 5 | Uploading and storing audio recordings in cloud storage, including progressive segment upload for long recordings |
| 6 | Assembling audio segments for long recordings (transient processing by cloud service; audio is not retained after assembly) |
| 7 | Transcribing audio recordings into text using AI speech recognition with speaker identification |
| 8 | Anonymising transcripts to protect patient identity (replacing patient names, NHS numbers, phone numbers, email addresses, postcodes, dates of birth, and titled names with pseudonyms) |
| 9 | Extracting structured clinical information from anonymised transcripts using AI (procedures, teeth, findings, medications, warnings, confidence scores) |
| 10 | Quality-checking AI clinical extractions by validation against the anonymised transcript |
| 11 | Generating human-readable clinical narratives from anonymised extraction data, with de-anonymisation applied after generation |
| 12 | Generating patient treatment letters from anonymised clinical data, with de-anonymisation applied after generation and patient identifiers injected at document render time |
| 13 | Validating generated treatment letters against source clinical data for structural compliance and accuracy |
| 14 | Generating PDF and Word documents from treatment letters, applying practice letterhead |
| 15 | Processing clinician corrections and refinements via a chat interface |
| 16 | Answering clinician questions about patient history using AI with citations from clinical records |
| 17 | Generating AI patient summaries from anonymised clinical history across appointments |
| 18 | Generating vector embeddings for clinical context retrieval (procedure descriptions, not full patient records) |
| 19 | Generating vector embeddings for anonymised clinical note chunks |
| 20 | Analysing patient experience data using AI |
| 21 | Generating CQC compliance reports from aggregated practice data (internal database processing only) |
| 22 | Storing and managing practice knowledge base content (protocols, risk templates, pricing, SOPs) |
| 23 | Sending system alert emails containing patient references when processing issues occur |
| 24 | Sending failure escalation emails including patient name when recording recovery fails |
| 25 | Sending team invitation and verification emails to clinician email addresses |
| 26 | Processing subscription billing and payments (no patient data sent to payment processor) |
| 27 | Audit logging of all data changes for compliance and traceability |
| 28 | Hosting and serving the web application (no direct patient data processing occurs at the hosting layer) |
| 29 | Storing pseudonym mappings for de-anonymisation (linking anonymised tokens to original values) |
| 30 | Storing and managing patient personal events for rapport-building in future consultations |
| 31 | Maintaining clinical note version history for audit trail and rollback |
3.2 Practice Intelligence (PI)
| # | Purpose |
|---|---|
| 32 | Recording audio of practice meetings using a physical recording device |
| 33 | Relaying meeting transcripts from the recording device through integration middleware to the system |
| 34 | Storing meeting and conversation transcripts with interaction type, participant metadata, and confidentiality level |
| 35 | Extracting business intelligence from meeting transcripts using AI (action items, concerns, decisions, staff development notes, patient references, document signals) |
| 36 | Anonymising transcript text for vector embedding (replacing staff, patient, and owner names with anonymised tokens) |
| 37 | Generating vector embeddings for anonymised PI transcript chunks |
| 38 | Extracting patient insights from approved clinical notes (identifying patient questions, communication gaps, content opportunities, and policy friction) |
| 39 | Ingesting and classifying inbound emails from practice mailboxes (subject, sender, body classified into categories) |
| 40 | Automatically deleting or moving classified spam emails |
| 41 | Processing job applications with automated acknowledgement replies |
| 42 | Posting media release details to internal team communication channels |
| 43 | Posting payment notifications to internal team communication channels |
| 44 | Looking up and creating CRM contacts from inbound emails |
| 45 | Creating CRM opportunities from website form submissions |
| 46 | Embedding conversation history for context retrieval |
| 47 | Composing AI-drafted replies to inbound lead and patient messages using assembled context |
| 48 | Composing AI-drafted proactive outbound messages |
| 49 | Routing composed messages for delivery or human approval based on safety rules |
| 50 | Sending emergency SMS alerts when inbound messages are flagged as urgent |
| 51 | Posting draft messages to internal team channels for human review and approval |
| 52 | Delivering approved messages via email from the practice mailbox |
| 53 | Delivering approved messages via SMS or messaging platforms |
| 54 | Moving processed emails to completed folders |
| 55 | Embedding outbound messages for future conversation context retrieval |
| 56 | Logging messages and demand signals (content topic gaps identified by AI) |
| 57 | Adding tags to CRM contacts to reflect interaction status |
| 58 | Adding notes to CRM contacts summarising approved replies |
| 59 | Querying practice intelligence data using natural language with role-based access control |
| 60 | Controlling access to confidential PI data by role (staff see own data, managers see reports, owners see all within practice) |
| 61 | Ingesting and embedding public Google reviews for inclusion in the knowledge base |
| 62 | Tracking AI usage and costs (token counts, model, duration -- no content or PII stored in usage records) |
3.3 Cross-Cutting Purposes
| # | Purpose |
|---|---|
| 63 | Multi-tenant data isolation through row-level security policies ensuring one practice cannot access another’s data |
| 64 | JWT authentication and authorisation linking users to practices for all requests |
| 65 | Generating vector embeddings for knowledge base semantic search |
| 66 | Analysing anonymised and aggregated data for product intelligence and feedback (outside the core product) |
| 67 | Generating and managing social media content about the product (no patient PII involved) |
3.4 Nurtura (Dental CRM)
| # | Purpose |
|---|---|
| 68 | Storing and managing patient and lead contact data in the CRM (names, emails, phone numbers, tags, conversation history) |
| 69 | Managing sales opportunities and pipeline stages for practice business development |
| 70 | Sending messages to patients and leads via CRM channels (email, SMS, messaging platforms) |
4. Types of Personal Data
4.1 Patient Clinical Data
- Audio recordings of patient-clinician dental consultations
- Raw and anonymised transcripts of consultations
- Speaker-labelled transcript utterances with timestamps
- Structured clinical extraction data (procedures, teeth, findings, medications, warnings, confidence scores)
- Clinical narrative text
- Clinical note version history
- Treatment letters (patient name, date of birth, address, clinical content, risk disclosure, consent section, financial summary)
- PDF and Word treatment letter documents with practice letterhead
- Letter validation results
- Clinical chat messages (clinician corrections, questions, AI responses)
- Patient context summaries and snapshots
4.2 Patient Personal Data
- Full name, date of birth, address
- NHS number (where provided)
- Allergies, medications, medical history
- Personal events (birthdays, family milestones, rapport-building information)
- Email address and phone number (where provided)
4.3 Patient-Identifiable References in Practice Data
- Patient names mentioned in practice meeting transcripts
- Patient references extracted from meetings (name, treatment context, follow-up needs)
- Patient names in media release notifications
- Patient clinical records assembled transiently as context for lead reply composition
4.4 Pseudonymisation Data
- Pseudonym mappings linking anonymised tokens to original PII values
- Anonymised token mappings for PI embeddings
4.5 Staff and Team Data
- Full names, email addresses, user IDs, and practice associations
- Role assignments (clinician, admin, owner, manager, staff)
- PI role assignments controlling data visibility
- Staff development notes, action items, concerns, and decisions attributed to named individuals
- Staff names mentioned in meeting transcripts
4.6 Lead and Enquirer Data
- Full name, email address, phone number
- Inbound message content and conversation history
- Composed reply content (AI-drafted responses)
- Contact type, CRM tags, demand signals
- CRM opportunity data (pipeline stage, monetary value, status)
- CRM notes (approved reply summaries with reviewer name)
4.7 Practice Business Data
- Practice name, address, phone number, booking URLs
- Clinician names and specialisms
- Practice profile narrative
- Knowledge base content (protocols, risk templates, pricing, SOPs, policies)
- Priorities and business strategy items
- Team roster (names, roles)
- Billing data (subscription status, payment methods)
4.8 User Account Data
- Email addresses (for authentication)
- Passwords (hashed)
- JWT session tokens
- Profile information linked to practice
- Invitation records and verification codes
4.9 Communication and Message Data
- Inbound and outbound email content (subject, sender, body)
- SMS and messaging platform message content
- Internal team channel approval messages (drafted reply text, contact names, message excerpts)
- Internal team channel notifications (media release details, payment summaries, alerts)
4.10 Vector Embeddings and Search Data
- Vector embeddings of anonymised transcript chunks, conversation messages, outbound messages, clinical note chunks, and review text
- Text queries sent to embedding services
4.11 Public Review Data
- Google review text, author name, rating
4.12 Audit and Tracking Data
- Audit log entries (data changes, timestamps, user IDs)
- AI usage tracking records (no content or PII)
- Extraction queue state
4.13 Audio and Media Data
- Raw audio files of patient-clinician conversations
- Audio segment files (transient)
- Assembled audio files
- Practice letterhead images
5. Categories of Data Subjects
| Category | Description |
|---|---|
| Dental patients | Individuals receiving dental treatment at the Controller’s practice, whose clinical data is recorded and processed through the Services |
| Practice staff and clinicians | Dentists, hygienists, nurses, receptionists, practice managers, and other team members employed by or contracted to the Controller |
| Leads and enquirers | Individuals who contact the practice through its website, email, phone, or messaging channels seeking information or appointments |
| Job applicants | Individuals who apply for employment positions at the Controller’s practice |
| Referring clinicians | External dental or medical professionals who refer patients to the Controller’s practice |
| Family members | Individuals related to patients whose details may be mentioned in clinical or personal context |
| Practice owners and managers | Individuals responsible for the management and governance of the Controller’s practice |
Schedule 2 -- Technical and Organisational Security Measures
The Processor implements and maintains the following security measures to protect Personal Data. These measures are subject to periodic review and update.
1. Access Control
1.1 Authentication
| Measure | Description |
|---|---|
| JWT-based authentication | All API endpoints validate JSON Web Tokens. Every function implements internal JWT validation, linking requests to authenticated users and their practice. |
| Service role key separation | Separate client patterns for service-level operations (bypassing row-level security for system triggers) and user-level operations (respecting row-level security). Service role keys are stored as environment variables and never exposed to the frontend. |
| Practice isolation on all data queries | Every function that retrieves patient data filters by practice identifier derived from the authenticated user’s JWT. |
| Super administrator two-factor authentication | Super administrator operations require TOTP-based two-factor verification. IP allowlisting is also available for super administrator access. |
| Device verification for new logins | New login devices are verified via a verification code mechanism. Trusted devices are tracked for subsequent access. |
1.2 Row-Level Security (RLS)
| Measure | Description |
|---|---|
| RLS enabled on all patient data tables | Row-level security is enabled on all tables containing Personal Data, ensuring that database queries return only data belonging to the authenticated user’s practice. |
| Practice isolation via RLS policies | All patient-facing tables enforce practice-level isolation. One practice cannot access another practice’s data, even via direct database query. |
| Clinical note hard-delete prevention | RLS policies prevent any hard deletion of clinical notes, clinical note embeddings, and patient context summaries. Soft delete patterns are used instead. |
| Confidentiality-level access control | Practice Intelligence tables implement three-tier confidentiality: standard (all staff), manager (manager and owner only), and owner-only. Access is controlled by the user’s assigned role. |
1.3 Role-Based Access Control
| Role | Access Level |
|---|---|
| Owner | Full access to all practice data, settings, integrations, and team management |
| Admin | Audit log access, team management, patient and appointment deletion |
| Clinician | Create and update own clinical notes and appointments; view all practice data |
| Staff | View practice data, create patients and appointments; restricted update and delete |
| Super Administrator | Platform-level access with mandatory two-factor authentication |
| PI Manager / PI Owner | Access to confidential Practice Intelligence data based on assigned role |
1.4 Storage Bucket Access Control
| Bucket | Access Level |
|---|---|
| Audio recordings | Private bucket. Authenticated users may upload. Access controlled via folder path using practice and appointment identifiers. |
| Treatment letters | Private bucket. Practice members may read and upload only within their practice folder. |
| Practice logos | Private bucket. Only practice members may view. Only owners may upload, update, or delete. |
| Documents | Private bucket for internal documents. |
2. Encryption
2.1 Encryption in Transit
| Measure | Description |
|---|---|
| HTTPS/TLS on all API calls | All communications with the database platform, AI services, transcription service, embedding services, and all other external services are conducted over HTTPS with TLS encryption. |
| Frontend served over HTTPS | The web application is served over HTTPS with automatic TLS certificates. |
| WebSocket Secure (WSS) | Real-time subscriptions use WSS (WebSocket Secure) connections. |
| No unencrypted external calls | All external communications from server functions are conducted over HTTPS. |
2.2 Encryption at Rest
| Measure | Description |
|---|---|
| Database encryption (AES-256) | All data at rest is encrypted using AES-256 via the cloud provider’s key management service. |
| Storage bucket encryption (AES-256) | All stored files (audio recordings, treatment letters, documents) are encrypted at rest using AES-256. |
| Backup encryption | All database backups are stored with encryption at rest. |
| Audio transcription service encryption | The transcription sub-processor encrypts all data, including audio, at rest and in transit. |
3. Infrastructure Security
| Measure | Description |
|---|---|
| Edge network with DDoS protection | API requests are routed through an edge network with distributed denial-of-service protection. |
| API rate limiting | Rate limits are applied to all API endpoints to prevent abuse. |
| IP allowlisting for super administrators | Optional IP-based access restriction for platform administration. |
| Network isolation | Database and application services operate within isolated virtual private cloud (VPC) networks. Direct public access to database infrastructure is not permitted; all access is routed through authenticated API endpoints. |
4. Application Security
4.1 Pseudonymisation and Anonymisation
| Pipeline Stage | Description |
|---|---|
| Post-transcription anonymisation | Immediately after transcription, patient names, NHS numbers, phone numbers, email addresses, postcodes, dates of birth, and titled names are replaced with pseudonyms. Both raw and anonymised versions are stored; pseudonym mappings are retained for de-anonymisation. |
| Pre-AI anonymisation for clinical extraction | Full anonymisation is applied before any AI API call for clinical data extraction. Mappings are stored for subsequent de-anonymisation. |
| Pre-AI anonymisation for narrative generation | Anonymisation is applied before AI narrative generation; de-anonymisation is applied after the AI returns results. |
| Pre-AI anonymisation for letter generation | Combined clinical content is anonymised in a single pass before AI letter generation; de-anonymisation is applied after generation. |
| Pre-AI anonymisation for patient summaries | Clinical anonymisation (preserving dates, removing PII) is applied before AI summary generation. |
| Pre-embedding anonymisation for clinical notes | Clinical anonymisation is applied before generating vector embeddings for clinical note search. |
| Pre-embedding anonymisation for PI transcripts | Staff, patient, and owner names are replaced with anonymised tokens before generating PI transcript embeddings. |
4.2 Input Validation
| Measure | Description |
|---|---|
| Shared validation library | Centralised validation functions for required fields, email addresses, UUIDs, dates, and numeric strings. |
| Audio file validation | MIME type allowlists and file size limits (maximum 1GB) enforced on audio uploads. Only audio and video MIME types accepted. |
| Storage bucket MIME restrictions | All storage buckets enforce MIME type restrictions and file size limits appropriate to their purpose. |
5. Data Handling
5.1 Data Integrity and Retention Controls
| Measure | Description |
|---|---|
| Soft delete pattern | Clinical notes, patients, and appointments use timestamped soft deletion. Hard deletes are blocked by database security policies. |
| Version history | All versions of clinical notes, treatment letters, and knowledge base sections are preserved for audit trail and rollback. |
| Workflow state validation | Database constraints and triggers validate workflow status transitions, preventing invalid state changes. |
| One-transcript-per-appointment enforcement | Database constraints and application logic ensure a single active transcript per appointment. |
5.2 Audit Logging
| Measure | Description |
|---|---|
| Comprehensive audit log | All data changes are recorded with entity type, entity identifier, action, user identifier, before and after state, IP address, user agent, practice identifier, and timestamp. |
| Automatic audit triggers | Database triggers automatically create audit entries on clinical note and treatment letter status changes. |
| Audit log access control | Only administrator and owner roles may view audit logs. |
| Audit log export | Export functionality with CSV and JSON format options. Export actions are themselves logged. |
| Error logging | All processing errors are tracked with entity type, error type, details, and practice identifier. |
| Activity log | User-facing activity log with automatic triggers for note approvals, letter status changes, and extraction reviews. |
6. Backup and Disaster Recovery
| Measure | Description |
|---|---|
| Automated daily backups | Daily automated database backups with seven-day retention. |
| Backup encryption | All backups are stored with encryption at rest. |
7. Incident Response
| Measure | Description |
|---|---|
| 72-hour breach notification | Personal Data Breaches are notified to the Controller within 72 hours of discovery, as set out in clause 11 of this Agreement. |
| Internal investigation | The Processor conducts its own investigation into any breach and provides a written report with remedial proposals. |
| Remediation | Identified issues are remediated within a reasonable timeframe following investigation. |
8. Organisational Measures
| Measure | Description |
|---|---|
| Confidentiality obligations | All personnel with access to Personal Data are bound by contractual confidentiality obligations or appropriate statutory duties. |
| Data protection training | Personnel receive appropriate training on data protection responsibilities. |
| Least-privilege access | Access to Personal Data is limited to personnel who require it for the performance of their duties. |
| Sub-Processor due diligence | All Sub-Processors undergo due diligence and are bound by written contracts with data protection obligations no less protective than those in this Agreement. |
9. Sub-Processor Security Certifications
Key sub-processors maintain the following independently audited security certifications:
| Sub-Processor | Certification |
|---|---|
| Supabase (AWS infrastructure) | SOC 2 Type II, ISO 27001 (AWS) |
| Anthropic | SOC 2 Type II |
| Google Cloud | SOC 2, ISO 27001, ISO 27017, ISO 27018 |
| AssemblyAI | SOC 2 Type II |
| Stripe | PCI DSS Level 1, SOC 2 Type II |
| Vercel | SOC 2 Type II |
| Microsoft | SOC 2, ISO 27001, ISO 27018 |
| Elestio | ISO 27001 (Hetzner infrastructure) |
The Processor periodically reviews the security certifications and practices of its Sub-Processors.
Schedule 3 -- Approved Sub-Processors
The following Sub-Processors are authorised to process Personal Data on behalf of the Controller. The Processor shall notify the Controller of any additions or changes in accordance with clause 7.3 of this Agreement.
| # | Sub-Processor | Processing Purpose | Location | Transfer Safeguard |
|---|---|---|---|---|
| 1 | Supabase (Supabase Inc.) | Database hosting, cloud storage, authentication, and server-side functions. All patient data at rest. | United States (AWS) with EU region option (Ireland, London, Frankfurt) | UK SCCs |
| 2 | Anthropic (Anthropic PBC) | AI processing for clinical data extraction, narrative generation, letter generation, PI business intelligence extraction, lead reply composition, and natural language query synthesis. Receives anonymised clinical data. | United States | UK SCCs |
| 3 | Google Cloud / Gemini (Google LLC) | Vector embedding generation for clinical context, PI transcript search, and conversation retrieval. PDF conversion. Receives anonymised text for embeddings. | United States (default); EU regions available via Vertex AI | EU-US Data Privacy Framework (UK Extension) + UK SCCs |
| 4 | AssemblyAI (AssemblyAI Inc.) | Audio transcription with speaker identification. Receives raw audio recordings. | United States (default); EU endpoint available (Dublin, Ireland) | EU-US Data Privacy Framework (UK Extension) + UK SCCs |
| 5 | GoHighLevel (HighLevel Inc.) | CRM platform for contact management, opportunity tracking, and message delivery (email, SMS, messaging). Holds contact records for leads and patients. | United States | EU-US Data Privacy Framework (UK Extension) + UK SCCs |
| 6 | Stripe (Stripe Inc. / Stripe Payments Europe Ltd) | Payment processing for practice subscriptions. No patient or clinical data. | United States and Ireland (EMEA) | EU-US Data Privacy Framework (UK Extension) + UK IDTA |
| 7 | Vercel (Vercel Inc.) | Frontend web application hosting. Serves static frontend; no patient data stored at the hosting layer. | United States (default); EU regions available (London, Frankfurt, Dublin, Paris) | EU-US Data Privacy Framework (UK Extension) + UK SCCs |
| 8 | Railway (Railway Corporation) | Transient audio assembly service. Downloads audio segments, joins them, and re-uploads. Does not retain audio after processing. | United States (default); EU region available (Amsterdam, Netherlands) | UK SCCs |
| 9 | Slack (Salesforce Inc.) | Internal team communication for message approval workflows and practice notifications. Contains drafted reply text, contact names, and message excerpts. | United States | EU-US Data Privacy Framework (UK Extension, via Salesforce) + UK SCCs |
| 10 | Zapier (Zapier Inc.) | Integration middleware for relaying meeting transcripts from recording devices to the system. | United States | EU-US Data Privacy Framework (UK Extension) + UK SCCs |
| 11 | Microsoft (Microsoft Corporation) | Email access via Graph API for inbound email ingestion and outbound email delivery from practice mailboxes. | Regional (based on tenant location; UK tenants use UK data centres) | EU-US Data Privacy Framework (UK Extension) + UK IDTA |
| 12 | Elestio (Elestio Limited) | Managed hosting for self-hosted workflow automation tooling. Customer data stays within the EU. | European Union | N/A (EU-based processor; no international transfer) |
| 13 | Resend (Resend Inc.) | Transactional email delivery for system alerts, failure escalations, team invitations, and verification codes. May contain patient names and practice references in alert emails. | United States | UK SCCs |
End of Data Processing Agreement