Data processing agreement

1 Definitions

In this DPA the following terms have the meanings set out below. Terms not defined here have the meanings given in the Terms, the Service Confirmation or the UK GDPR, as applicable.

• "Applicable Data Protection Law" means the UK GDPR, the Data Protection Act 2018 (as amended, including by the Data (Use and Access) Act 2025), the Privacy and Electronic Communications Regulations 2003, and any other UK legislation, binding guidance or code of practice applicable to the processing of Personal Data under this DPA.
• "Annexes" means Annex 1 (Details of Processing), Annex 2 (Technical and Organisational Measures) and Annex 3 (Approved Sub-processors and Transfer Mechanisms), each of which forms part of this DPA.
• "Approved Sub-processor" means a Sub-processor listed in Annex 3, or added in accordance with Section 7.
• "Authorised Users" means the individuals whom the Controller authorises to access and use the Service under the Controller's subscription.
• "Commissioner" means the Information Commissioner, and after the transfer of functions under section 119 of the Data (Use and Access) Act 2025, the Information Commission.
• "Contract Year" means each successive period of 12 months beginning on the Effective Date recorded in the Service Confirmation and on each anniversary of it. This definition matches the Terms.
• "Controller" means the entity identified as the Controller in the Service Confirmation, and where more than one entity is so identified under Section 2.3, each of them. Before a Service Confirmation is issued, it means the organisation on whose behalf the Terms were accepted, as recorded in the Acceptance Record.
• "Data and Security Claims" has the meaning given in Section 14.1(b), which matches the meaning given in Section 12.3 of the Terms.
• "Customer Data" means all data, including Personal Data, that is uploaded, submitted, stored, generated or transmitted by the Controller or its Authorised Users through the Service, or generated by the Service on the Controller's behalf.
• "Data Subject" means an identified or identifiable natural person to whom Personal Data relates.
• "Personal Data" means any information relating to an identified or identifiable natural person that is Processed by the Processor on behalf of the Controller through the Service.
• "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.
• "Processing" and "Process" mean any operation or set of operations performed on 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" means Lumina Dental Limited, which Processes Personal Data on behalf of the Controller.
• "Read-Only Period" means the period after termination during which the Controller may view and export Customer Data but not create, modify or delete records, as set out in Section 11.2 and the Terms.
• "Restricted Transfer" means a transfer of Personal Data to which the restrictions in Chapter V of the UK GDPR apply, including making Personal Data accessible to a person outside the United Kingdom.
• "Service" means the Lumina platform described in the Terms, comprising Lumina Core, Lumina Admin and the Lumina Patient Portal, together with the other applications and interfaces made available to the Controller.
• "Service Confirmation" has the meaning given in paragraph A above.
• "Sub-processor" means any third party engaged by the Processor to Process Personal Data on behalf of the Controller.
• "Technical and Organisational Measures" or "TOMs" means the measures set out in Annex 2.

2 Scope and Roles

2.1 Data Processing Roles

The parties acknowledge and agree that:

• (a) the Controller is the controller for all Personal Data entered into or Processed through the Service by the Controller or its Authorised Users, including patient data, clinical records and staff information; and
• (b) Lumina is the processor of that Personal Data, Processing it only on behalf of, and in accordance with the documented instructions of, the Controller.

The Terms, this DPA, the Service Confirmation, the Controller's configuration of the Service and the Controller's and its Authorised Users' use of the functionality of the Service together constitute the Controller's documented instructions to Lumina. The Controller may give further written instructions. Lumina may charge for instructions that require material work outside the ordinary functionality of the Service, having told the Controller in advance.

2.2 Lumina as Controller in its Own Right

Lumina acts as an independent controller, outside this DPA, for:

• Customer account and organisational information, including the Service Confirmation and acceptance records, for contract management and account administration;
• billing and payment information, for invoicing and payment processing;
• website visitor statistics for luminadental.co.uk;
• marketing communications data, where the recipient has consented or another lawful basis applies;
• support correspondence and service records, and security and operational logs generated by the Service, to the extent Lumina uses them to secure, operate and improve the Service.

Lumina's processing of that data as controller is governed by the Privacy Policy , not this DPA. Where the same record contains both Customer Data and data Lumina holds as controller, this DPA governs the Customer Data.

2.3 Joint Controllers

Where two or more entities jointly determine the purposes and means of Processing Customer Data through the Service, so that they are joint controllers under Article 26 UK GDPR, the following applies.

• (a) The Customer must notify Lumina in writing before the Service is used for that Processing, and each joint controller must be named as a Controller in the Service Confirmation.
• (b) The joint controllers must confirm in writing to Lumina that an arrangement under Article 26 is in place between them, allocating responsibility for compliance with Applicable Data Protection Law, including for responding to Data Subject rights requests and for providing the information required by Articles 13 and 14. Lumina does not need to see the arrangement itself, only a written confirmation that it exists and that the essence of it has been made available to Data Subjects.
• (c) The joint controllers must name a single instructing contact in the Service Confirmation. Lumina may give and receive instructions, breach notifications, sub-processor notices, deletion instructions and Data Subject request routing through that contact alone, and is entitled to treat an instruction from that contact as given on behalf of all of them.
• (d) Lumina serves all named joint controllers under this single DPA. Lumina is not a party to the Article 26 arrangement, and receiving or being told about it does not make Lumina a controller of the Customer Data.
• (e) If Lumina receives conflicting instructions from different Controllers or contacts, it may (without being in breach of this DPA) continue secure storage of the Customer Data, suspend the affected Processing, and ask for a single instruction from the instructing contact before acting.
• (f) Each joint controller is jointly and severally liable for the Controller's obligations under this DPA.
• (g) Where the Controller believes another party may be a controller of the same Customer Data but has not confirmed an Article 26 arrangement, the Controller must tell Lumina. Lumina may decline to accept instructions from an entity that is not named in the Service Confirmation.

2.4 No Processing for Lumina's Own Purposes

Lumina shall not Process Customer Data for its own purposes. In particular, Lumina shall not use Customer Data to develop, train, fine-tune or evaluate any artificial intelligence or machine learning model, to build or enrich any product data set, for benchmarking, or for marketing or sales, except:

• (a) where the data has been anonymised so that it is no longer Personal Data, in accordance with the aggregated data provisions of the Terms; or
• (b) to the extent strictly necessary to operate, secure, support, maintain and repair the Service for the Controller, in which case Lumina remains a processor.

The parties acknowledge Article 28(10) UK GDPR: if Lumina determines the purposes and means of Processing beyond the Controller's instructions, Lumina is a controller for that Processing and carries controller obligations and liability for it.

3 Details of Processing

3.1 Particulars

The subject matter, duration, nature and purpose of the Processing, the types of Personal Data, the categories of Data Subjects and the Processing operations are set out in Annex 1 . Annex 1 satisfies Article 28(3) UK GDPR and supports the Controller's Article 30(1) record.

3.2 Instructions Limited to the Service

Lumina Processes Personal Data only for the purposes set out in Annex 1, only in relation to the categories of data and Data Subjects set out in Annex 1, and only for the duration set out in Section 3.5. The Controller must not use the Service to Process categories of Personal Data that are not described in Annex 1 without first agreeing an updated Annex 1 with Lumina.

3.3 Types of Personal Data

Set out in Annex 1, paragraph 4 . The Processing includes special category data.

3.4 Special Category Data

• (a) Personal Data Processed under this DPA includes health data, which is special category data under Article 9(1) UK GDPR.
• (b) Identifying and documenting the Article 6 lawful basis and the Article 9 condition is the Controller's responsibility. The Controller confirms that its Processing of health data through the Service is carried out under Article 9(2)(h) UK GDPR (health or social care purposes) read with paragraph 2 of Part 1 of Schedule 1 to the Data Protection Act 2018, together with an Article 6 basis, or under another condition that the Controller identifies to Lumina in writing. No appropriate policy document is required for the paragraph 2 condition.
• (c) Lumina does not rely on an Article 9 condition of its own for this Processing. It Processes health data only on the Controller's instructions.
• (d) Every Lumina individual with access to health data is bound by a written duty of confidentiality that survives the end of their engagement, and is subject to Lumina's internal policy on the handling of health data. This supports the Controller's position under section 11(1)(b) of the Data Protection Act 2018, which allows the safeguard required by Article 9(3) to be met where Processing is carried out by a person who, in the circumstances, owes a duty of confidentiality under an enactment or rule of law. Lumina's Processing is not carried out under the responsibility of a health professional, so section 11(1)(a) is not available.
• (e) Lumina applies the enhanced measures described in Annex 2 to special category data, and treats the special category nature of the data as a factor in the risk assessment required by Article 32.

3.5 Duration of Processing

Processing continues for the term of the Terms, plus the Read-Only Period and the retention buffer described in Section 11.2, plus any extended retention agreed in writing under Section 11.4, plus the backup expiry period described in Section 11.1(d).

4 Processor Obligations

4.1 Article 28(3) Obligations

The Processor shall:

• (a) Process Personal Data only on documented instructions from the Controller, including in relation to Restricted Transfers, unless required to Process by Applicable Data Protection Law, in which case the Processor shall inform the Controller of that legal requirement before Processing, unless the law prohibits that notification on important grounds of public interest;
• (b) ensure that persons authorised to Process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that the confidentiality obligation survives the end of their engagement;
• (c) implement and maintain appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as set out in Section 6 and Annex 2, having regard to the special category nature of the data;
• (d) not engage a Sub-processor without the prior specific or general written authorisation of the Controller, as set out in Section 7;
• (e) assist the Controller, taking into account the nature of the Processing, by appropriate technical and organisational measures, in fulfilling the Controller's obligation to respond to requests from Data Subjects exercising their rights under Applicable Data Protection Law, as set out in Section 8;
• (f) assist the Controller in ensuring compliance with the obligations in Articles 32 to 36 UK GDPR, taking into account the nature of the Processing and the information available to the Processor, including as set out in Sections 4.7, 6 and 9;
• (g) at the choice of the Controller, delete or return all Personal Data after the end of the provision of the services, and delete existing copies unless Applicable Data Protection Law requires storage, as set out in Section 11;
• (h) make available to the Controller all information necessary to demonstrate compliance with the obligations in this DPA, and allow for and contribute to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller, as set out in Section 12; and
• (i) immediately inform the Controller if, in the Processor's opinion, an instruction from the Controller infringes Applicable Data Protection Law.

4.2 Instructions that Infringe the Law

Where Section 4.1(i) applies, the Processor shall tell the Controller in writing, identify the part of the instruction concerned and the reason for its opinion, and may suspend the affected Processing (other than continued secure storage of the Personal Data) until the Controller withdraws, amends or confirms the instruction in writing. Suspension under this Section is not a breach of the Terms or this DPA. The Processor is not required to give the Controller legal advice, and the Controller remains responsible for the lawfulness of its instructions.

4.3 Records of Processing

The Processor shall maintain a record of the categories of Processing activities carried out on behalf of the Controller as required by Article 30(2) UK GDPR, including the categories of Processing, Restricted Transfers and the safeguards relied on, the Sub-processors engaged, and a general description of the technical and organisational measures. The Processor shall make the record available to the Controller and to the Commissioner on request.

4.4 Cooperation with the Commissioner

The Processor shall cooperate with the Commissioner, on request, in the performance of the Commissioner's tasks, as required by Article 31 UK GDPR. Where the Processor is contacted by the Commissioner or any other supervisory or regulatory authority in relation to Processing carried out for the Controller, it shall notify the Controller without undue delay unless prohibited from doing so by law, and shall keep the Controller informed of the substance of its response so far as it relates to the Controller's Personal Data.

4.5 Requests from Law Enforcement and Public Authorities

If the Processor receives a request or order from a law enforcement agency, court, regulator, government body or other public authority for Personal Data Processed on behalf of the Controller, the Processor shall:

• (a) notify the Controller without undue delay and, where practicable, before making any disclosure, unless legally prohibited from doing so;
• (b) where notification is prohibited, use reasonable efforts to obtain a waiver of the prohibition, keep a record of the request and its handling, and notify the Controller as soon as it is permitted to do so;
• (c) not disclose Personal Data unless it is legally obliged to, and challenge the request where the Processor considers that it is unlawful, that it is overbroad, that it does not meet the requirements of the applicable law, or that a lawful ground for the disclosure is absent, including by seeking interim relief where appropriate;
• (d) disclose only the minimum amount of Personal Data reasonably necessary to comply with the request, and object to any request for bulk or unrestricted access;
• (e) make no voluntary disclosure of Personal Data to any public authority; and
• (f) keep a record of every request received, the response given and the Personal Data disclosed, and provide a summary to the Controller as soon as it is permitted to do so.

4.6 No Processing for the Processor's Own Purposes

Section 2.4 applies.

4.7 Assistance with Data Protection Impact Assessments

• (a) The Controller is responsible for carrying out a data protection impact assessment under Article 35 UK GDPR where one is required, and for any prior consultation with the Commissioner under Article 36. The parties acknowledge that a dental practice adopting a cloud practice-management platform that Processes health data at scale and includes AI-assisted features is likely to need a data protection impact assessment.
• (b) The Processor shall provide reasonable assistance with that assessment and with any prior consultation, including by supplying: the description of the Processing in Annex 1; the technical and organisational measures in Annex 2; the Sub-processor, location and transfer information in Annex 3; a description of how the AI-assisted features operate, what data they receive and where they Process it; and information about known residual risks.
• (c) The Processor maintains a data protection impact assessment support pack and shall provide the current version to the Controller on request and, in any event, before the Controller begins live Processing.
• (d) Assistance under this Section does not transfer responsibility for the assessment to the Processor, and the Processor's provision of information is not an assurance that the Controller's Processing is lawful.

5 Controller Obligations

The Controller shall:

• (a) ensure that it has a valid lawful basis under Article 6, and a valid condition under Article 9 where special category data is Processed, for all Processing that it instructs the Processor to carry out;
• (b) provide the information required by Articles 13 and 14 to Data Subjects, including that Lumina acts as its processor;
• (c) obtain any consents needed where consent is the lawful basis relied on, and maintain records of them;
• (d) ensure that its instructions to the Processor comply with Applicable Data Protection Law, and not instruct the Processor to Process Personal Data in a way that would put the Processor in breach of it;
• (e) respond to Data Subject rights requests and to data protection complaints within the time limits set by Applicable Data Protection Law, using the tools and the assistance provided by the Processor;
• (f) maintain its own record of Processing activities under Article 30(1);
• (g) provide accurate and complete details in the Service Confirmation, including the identity of every Controller, the instructing contact and the data protection contact, and keep them current, notifying the Processor in writing of any change without undue delay;
• (h) carry out a data protection impact assessment where one is required before beginning live Processing, and notify the Processor if the assessment identifies a measure that the Processor would need to implement;
• (i) configure the Service, manage Authorised User accounts and apply access permissions appropriately, disable access promptly for personnel who leave or change role, and be responsible for the acts and omissions of its Authorised Users;
• (j) not upload to the Service Personal Data outside the categories described in Annex 1, and in particular not use free-text fields to record categories of Personal Data that the Service is not designed to hold; and
• (k) notify the Processor promptly of any change to its Processing instructions or requirements, and of any Personal Data Breach affecting Customer Data of which the Controller becomes aware and which may involve the Service.

6 Technical and Organisational Measures

6.1 Security Obligation

The Processor shall implement and maintain the technical and organisational measures set out in Annex 2 , and shall ensure a level of security appropriate to the risk under Article 32 UK GDPR, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the Processing, the risks to Data Subjects, and the fact that the Personal Data includes special category health data.

The Processor shall not materially reduce the overall level of protection provided by the measures in Annex 2 during the term of this DPA.

6.2 Personnel, Support and Administrative Access

• (a) Named and individually authorised Lumina personnel may access Customer Data, including clinical records, where it is necessary to:
  • provide support requested by or on behalf of the Controller or an Authorised User;
  • investigate, diagnose and resolve a fault, defect, data-integrity problem or incident;
  • investigate and respond to a suspected or actual security incident or Personal Data Breach;
  • carry out a migration, import, export, correction or restore requested by the Controller; or
  • operate, maintain, secure, monitor and repair the Service.
• (b) That access is granted to identified individuals rather than to shared accounts, on a least-privilege basis limited to what the task requires, is subject to authentication controls, and is logged.
• (c) Every individual with that access is bound by a written duty of confidentiality that survives the end of their engagement, and is subject to Lumina's internal policy on the handling of health data and to Lumina's disciplinary process for misuse.
• (d) Lumina personnel shall not access Customer Data for any purpose other than those listed in paragraph (a). Access for product development, testing, training, analytics, marketing or curiosity is prohibited.
• (e) Lumina maintains a record of the individuals authorised under this Section and of the access they hold, and shall provide the current record and, on reasonable request, extracts from the access logs to the Controller.

6.3 Emergency Access

• (a) Where immediate access to Customer Data is necessary to prevent or limit harm to Personal Data, to patient safety, or to the availability, integrity or security of the Service, and it is not reasonably practicable to obtain the Controller's prior instruction, Lumina may access the Customer Data without that prior instruction.
• (b) Where Lumina does so it shall: limit the access to what the emergency requires; record the access, the individual who carried it out, the individual who authorised it, the reason and the time; and notify the Controller's data protection contact without undue delay and in any event within 24 hours of the access.
• (c) Emergency access must not be used to avoid Section 6.2. Where the emergency involves a Personal Data Breach, Section 9 also applies.

6.4 Environment Separation

Production Customer Data is not copied into development, test or staging environments. Development and testing use synthetic or anonymised data.

6.5 Changes to Annex 2

Lumina may update Annex 2 from time to time to reflect changes in technology, threat and practice, provided that the overall level of protection is not materially reduced. Lumina shall publish the current version of Annex 2 and shall notify the Controller's registered contacts by email at least 30 days before a change that materially alters the measures takes effect. A change to Annex 2 does not require the Terms or this DPA to be re-executed.

6.6 Certifications and Assurance

Lumina has completed the NHS Data Security and Protection Toolkit with a Standards Met outcome for the 2025 to 2026 assessment year, published 8 April 2026, under NHS organisation code K1G1E. Cyber Essentials certification is in progress at the date of this DPA. Lumina does not currently hold ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3 or Cyber Essentials Plus certification, and has not committed to a certification timeline for them. Certifications held by Lumina's Sub-processors are held by those Sub-processors and are not Lumina's. Lumina shall not represent a Sub-processor's certification as its own. Where Lumina obtains a further certification or an independent audit report of its own it may offer it as evidence under Section 12.2.

7 Sub-processors

7.1 General Authorisation

The Controller gives the Processor general written authorisation to engage Sub-processors, subject to the conditions in this Section 7.

7.2 Approved Sub-processors

The Sub-processors authorised at the date of the Service Confirmation are listed in Annex 3 , with the entity name, the service performed, the categories of Personal Data involved, the Processing and storage locations, and the transfer mechanism relied on where Processing occurs outside the United Kingdom. Annex 3, as most recently updated in accordance with this Section 7, governs the parties' contractual position on Sub-processors. The current list is also published at luminadental.co.uk/subprocessors . That published page is the live notification surface for Sub-processor changes, kept current for the Controller's convenience; publication on it is not, by itself, how a change takes effect. A change to the Sub-processors takes effect only through the notice process in Section 7.3 and, where exercised, the objection process in Section 7.5. Where the published page and Annex 3 differ, Annex 3, read together with any notice given under Section 7.3 that has not yet been superseded, governs, and Lumina shall correct the published page and reissue Annex 3 to match without delay.

7.3 Notification of Changes

The Processor shall notify the Controller in writing at least 30 days before adding or replacing a Sub-processor. The notification shall state the identity of the proposed Sub-processor, the Processing it will carry out, the categories of Personal Data involved, its Processing and storage locations, and the transfer mechanism relied on where those locations are outside the United Kingdom.

7.4 How Notifications are Given

• (a) The Processor shall send each notification by email to the Controller's data protection contact and to any additional contacts the Controller registers for that purpose. The Controller may register or change those contacts at any time by writing to privacy@luminadental.co.uk , and Lumina shall confirm the change in writing.
• (b) The Processor shall also publish each change on the Sub-processor Schedule at luminadental.co.uk/subprocessors , showing the date of the change.
• (c) The Processor shall maintain a notification list so that a Controller can receive sub-processor notices without having to monitor the published page. Delivery to a registered contact is treated as notice to the Controller. It is the Controller's responsibility to keep its registered contacts current.

7.5 Right to Object

The Controller may object to a new or replacement Sub-processor by notifying the Processor in writing within 14 days of receiving notice. The objection must state reasonable grounds relating to data protection. The Processor shall make reasonable efforts to address the Controller's concerns, which may include offering an alternative Sub-processor, a change to the Processing, or a configuration in which the Controller's Personal Data is not exposed to that Sub-processor. If the parties cannot resolve the objection within 30 days, the Controller may terminate the Terms in accordance with their termination provisions, without penalty and with the post-termination export and deletion rights in Section 11 preserved. Pending resolution, the Processor shall not begin the Processing objected to in relation to the Controller's Personal Data unless it cannot reasonably continue to provide the Service without doing so, in which case it shall tell the Controller.

7.6 Sub-processor Obligations

Where the Processor engages a Sub-processor it shall:

• (a) impose on the Sub-processor, by a written contract, data protection obligations that are no less protective than those in this DPA, including the obligations in Article 28(3);
• (b) carry out reasonable due diligence on the Sub-processor's technical and organisational measures before engaging it, and keep a record of that diligence;
• (c) put in place a valid transfer mechanism under Section 10 before any Restricted Transfer to the Sub-processor; and
• (d) remain fully liable to the Controller for the performance of the Sub-processor's obligations, and for the Sub-processor's acts and omissions in relation to the Controller's Personal Data, as if they were the Processor's own.

8 Data Subject Rights

8.1 Assistance

The Processor shall assist the Controller, taking into account the nature of the Processing, in responding to requests from Data Subjects to exercise their rights under Applicable Data Protection Law, including:

• right of access (Article 15);
• right to rectification (Article 16);
• right to erasure (Article 17);
• right to restriction of Processing (Article 18);
• right to data portability (Article 20);
• right to object (Article 21); and
• the rights that apply to automated decision-making under Articles 22A to 22D UK GDPR as amended by the Data (Use and Access) Act 2025.

8.2 Tools Provided

• (a) The Processor provides functionality within the Service that enables the Controller to locate, view, correct, restrict and delete Personal Data, so that the Controller can respond to Data Subject requests itself. The Controller is responsible for using that functionality.
• (b) Export is provided on request, not self-service. On the Controller's written request, Lumina will provide reasonable assistance to enable export of Customer Data. Lumina and the Controller will agree the scope, format, secure delivery method and delivery timetable for the request.
• (c) The scope of an export under paragraph (b) includes, unless the Controller asks for less, patient demographic records, clinical notes, charting, medical histories, consents, treatment plans, appointment history, clinical images and document attachments, financial and claim records, and the audit trail relating to the exported records.
• (d) The Processor shall assist the Controller in applying the "reasonable and proportionate" search standard now set out in the Data Protection Act 2018 as amended, by describing where the relevant categories of Personal Data are held in the Service and what a proportionate search looks like. Any decision to seek clarification from a Data Subject, or to pause a statutory deadline while doing so, is the Controller's.

8.3 Requests Received Directly

If the Processor receives a request from a Data Subject relating to Personal Data Processed for the Controller, the Processor shall notify the Controller without undue delay and in any event within 5 business days, redirect the Data Subject to the Controller, and shall not respond substantively unless instructed by the Controller or required to by law. The Processor may acknowledge receipt and explain that it acts as the Controller's processor.

8.4 Data Protection Complaints

• (a) The parties acknowledge that under the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025, a controller must facilitate the making of data protection complaints, acknowledge a complaint within 30 days and respond to it without undue delay. That duty falls on the Controller in relation to Customer Data.
• (b) Where the Processor receives a data protection complaint relating to Processing carried out for the Controller, it shall route the complaint to the Controller's data protection contact without undue delay and in any event within 5 business days, and shall provide the information and assistance the Controller reasonably needs to acknowledge and respond to it.
• (c) The Processor shall not investigate or determine a complaint about the Controller's Processing, and shall not correspond substantively with the complainant, unless the Controller instructs it to.
• (d) The Processor operates its own complaints route for Processing it carries out as a controller. That route is described in the Privacy Policy and is not part of this DPA.

8.5 Records

The Processor shall keep a record of Data Subject requests and complaints it receives and routes under this Section, and shall make the record available to the Controller on request.

9 Personal Data Breach

9.1 Notification to the Controller

The Processor shall notify the Controller of a Personal Data Breach affecting Personal Data Processed for the Controller without undue delay and in any event within 48 hours of becoming aware of it .

For this Section, the Processor becomes aware of a Personal Data Breach when it has a reasonable degree of certainty that a security incident has occurred that has led to Personal Data being compromised. The Processor shall not delay notification in order to complete its investigation, to establish the cause, or to assess whether the breach is notifiable to the Commissioner or to Data Subjects. That assessment is the Controller's.

9.2 Content of the Notification

The notification shall include, to the extent known at the time:

• (a) a description of the nature of the Personal Data Breach, including where possible the categories and approximate number of Data Subjects concerned and the categories and approximate number of Personal Data records concerned;
• (b) the name and contact details of the Processor's point of contact for further information;
• (c) a description of the likely consequences of the Personal Data Breach; and
• (d) a description of the measures taken or proposed to address the Personal Data Breach, including where appropriate measures to mitigate its possible adverse effects.

The notification shall also state, where known, when the breach started and ended or is believed to be continuing, whether Customer Data was accessed, exfiltrated, altered or destroyed, and whether any Sub-processor was involved.

9.3 Phased Information

Where the Processor cannot provide all of the information in Section 9.2 within the period in Section 9.1, it shall provide the information it has within that period, state what is missing and why, and provide the remainder in phases without further undue delay as it becomes available. Incomplete information is not a reason to delay the initial notification.

9.4 No Admission of Liability

A notification or any other communication under this Section is made so that the Controller can meet its obligations under Applicable Data Protection Law. It is not, and shall not be treated as, an acknowledgement or admission by either party of fault, breach or liability.

9.5 The Controller's Notifications

The Controller is responsible for deciding whether to notify the Commissioner under Article 33 and affected Data Subjects under Article 34, and for making those notifications. The Processor shall not notify the Commissioner or any Data Subject about a breach affecting Customer Data on the Controller's behalf unless the Controller instructs it to in writing. The Processor shall provide the information and assistance the Controller reasonably requires for those notifications, and shall not make any public statement that identifies the Controller without the Controller's prior written consent unless required to by law.

9.6 Cooperation, Remediation and Other Reporting

• (a) The Processor shall cooperate with the Controller and take reasonable steps to assist in the investigation, containment, mitigation and remediation of the Personal Data Breach, shall preserve relevant logs and evidence, and shall provide a written post-incident summary on request, including the root cause and the corrective actions taken.
• (b) Where the Controller has an incident-reporting obligation to a body other than the Commissioner, including reporting through the NHS Data Security and Protection Toolkit incident tool, to a commissioning body, to the Care Quality Commission or to a hospital information governance function, the Processor shall provide the information the Controller reasonably needs to make that report within the time the Controller specifies.
• (c) The Processor shall maintain a record of Personal Data Breaches affecting Customer Data and of the steps taken in response, and shall make it available to the Controller on request.

10 International Transfers

10.1 Restriction

The Processor shall not make a Restricted Transfer of Personal Data Processed for the Controller unless:

• (a) the transfer is to a country, territory or specified sector that is the subject of adequacy regulations made by the Secretary of State under section 17A or section 74 of the Data Protection Act 2018; or
• (b) the transfer is made under appropriate safeguards in accordance with Article 46 UK GDPR, being the International Data Transfer Agreement or the International Data Transfer Addendum to the EU Standard Contractual Clauses, supported by a documented transfer risk assessment that applies the data protection test introduced by the Data (Use and Access) Act 2025.

The Processor shall complete the transfer risk assessment before the transfer begins, shall review it when circumstances change, and shall provide a copy or a summary to the Controller on request.

10.2 Consent is Not a Transfer Mechanism

The Controller's consent to, or authorisation of, a transfer is not a transfer mechanism, and nothing in this DPA treats it as one. The Controller's authorisation of a Sub-processor under Section 7 is an authorisation to engage that Sub-processor. It does not provide, and does not substitute for, a safeguard under Section 10.1.

10.3 Remote Access Counts as a Transfer

Making Personal Data accessible to a separate legal entity located outside the United Kingdom is a Restricted Transfer, including where access is remote, temporary, read-only or for support purposes. Section 10.1 applies to it.

10.4 Where Customer Data is Held

Customer Data is hosted and stored in the United Kingdom, in AWS's London region. Limited Processing by named Sub-processors, including payment processing by Stripe, may occur outside the United Kingdom under Article 46 safeguards, as listed in Annex 3 and on the Sub-processor Schedule.

The Processor makes no claim that Customer Data never leaves the United Kingdom.

10.5 Mechanisms in Force

Annex 3 records, for each Sub-processor, the Processing and storage locations and the transfer mechanism relied on. The Processor shall keep Annex 3 current, and shall provide a copy of the relevant transfer instrument on request, redacted only for commercial terms that are not relevant to data protection.

10.6 If a Mechanism Fails

If a mechanism relied on under Section 10.1 ceases to be valid, is invalidated, or the Processor becomes aware that a recipient can no longer comply with it, the Processor shall notify the Controller without undue delay and shall either put an alternative valid mechanism in place, suspend the transfer, or end the transfer. Where the Processor cannot do so and the Controller reasonably objects to the continued transfer, the Controller may terminate the Terms without penalty, with the export and deletion rights in Section 11 preserved.

10.7 AI Processing Locations

The location of Processing for AI-assisted features is dealt with in Section 13.

11 Data Retention and Deletion

11.1 During the Subscription

Personal Data is retained for the term of the Controller's subscription. The Controller may delete individual records at any time using the functionality of the Service. The parties acknowledge that deletion in the Service works as follows.

• (a) Deletion is a flag, then a purge. When a record is deleted through the Service it is marked as deleted, removed immediately from the Controller's ordinary views and from ordinary Processing, and retained in a restorable state for a defined period appropriate to the record type, so that a deletion made in error can be reversed. After that period it is purged from the active data store. The Processor shall state the applicable period for a record type on the Controller's request.
• (b) Some clinical record types are retained in a restricted partition by design so that a deletion can be reversed by an authorised user. Those records are not visible in the Controller's ordinary views and are not included in ordinary Processing, but they continue to exist until purged.
• (c) The Service does not offer instant irreversible destruction of an individual record. Where the Controller needs a specific record or set of records destroyed ahead of the ordinary purge cycle, for example to give effect to a decision on an Article 17 erasure request, it must instruct the Processor in writing. The Processor shall carry out the destruction within 10 business days and shall certify it under Section 11.5.
• (d) Backups. A copy of a deleted record may persist in the Processor's backups after purge. Backups expire on a rolling basis within 35 days. Backups are not used to restore individual records except on the Controller's instruction or to recover from an incident. Where a restore from backup reintroduces a record that the Controller had deleted, the Processor shall tell the Controller and shall re-apply the deletion.
• (e) Nothing in this Section limits the Controller's obligation to decide what to delete and when. The Processor does not delete Customer Data on its own initiative except as set out in Section 11.2.

11.2 After Termination

Following termination of the Terms, and unless the Controller instructs otherwise in writing or Applicable Data Protection Law requires retention:

• (a) Read-Only Period, 90 days. The Controller has 90 days of read-only access to view Customer Data, and may request an export of it under Section 8.2(b) at any time during that period. The Processor shall complete an export requested during the Read-Only Period even if the Read-Only Period ends before the export is delivered, and shall not begin the purge in paragraph (c) while an export request made in time is outstanding.
• (b) Retention buffer, 30 days. After the Read-Only Period ends, Customer Data is retained in encrypted form for a further 30 days for outstanding export requests or dispute resolution. Access is closed during this period.
• (c) Purge. After the retention buffer ends, Customer Data is purged from the Processor's active systems.
• (d) Backup expiry. Backup copies expire on a rolling basis within 35 days of the purge.
• (e) The Processor shall not delete Customer Data during the Read-Only Period or the retention buffer other than on the Controller's written instruction.

11.3 The Controller's Own Retention Duties

• (a) The parties acknowledge that dental records carry long retention duties, and that those duties are the Controller's, not the Processor's . Under the current NHS Records Management Code of Practice (an England and Wales instrument), dental clinical care records are ordinarily retained for 11 years. For children, the professional standard is 11 years or until the patient's 25th birthday, whichever is longer . Where the Controller practises in Scotland, Wales or Northern Ireland, the equivalent national records management guidance applies instead of the England and Wales code (for Scotland, the relevant NHS Scotland or Scottish Government records management guidance), and the Controller should confirm the applicable retention period with its own professional and regulatory advisers before relying on the figure above. Separate duties may apply to financial and NHS claim records, and the General Dental Council's record-keeping standards apply to the Controller's clinicians.
• (b) The Processor does not undertake to retain Customer Data for those periods. The periods in Section 11.2 are shorter than them.
• (c) The Controller must request and receive an export of the Customer Data it needs under Section 8.2(b), or agree extended retention in writing under Section 11.4, before the retention buffer ends. If it does not, the Customer Data will be purged and the Processor will not be able to provide it. The Controller should make its request early in the Read-Only Period, so that the scope, format and delivery timetable can be agreed and the export delivered before the retention buffer ends.
• (d) The Processor shall, on request during the Read-Only Period, tell the Controller what data categories an export would include and in what formats, so that the Controller can satisfy itself that the export meets its retention and future subject-access obligations before deletion occurs. Export is provided on request and is not a self-service function of the Service.
• (e) The Processor may retain Personal Data where Applicable Data Protection Law requires it to, in which case it shall tell the Controller what it is retaining, why, and for how long, and shall continue to protect it under this DPA and Process it only for the purpose that requires the retention.

11.4 Extended Retention

The Controller may instruct the Processor in writing, before the end of the retention buffer, to retain Customer Data beyond the standard timeline, including in order to meet its own retention duties. Extended retention is subject to a separate written agreement and may incur additional fees. Where extended retention is agreed, this DPA continues to apply to the retained Customer Data for as long as it is held.

11.5 Certification of Deletion

On completion of a deletion under Section 11.1(c) or Section 11.2, and at any time on the Controller's reasonable request, the Processor shall provide a written certificate signed by an authorised officer of the Processor, stating what Personal Data was deleted, the date of deletion, the systems and Sub-processors covered, any Personal Data retained and the reason for retaining it, and the date on which the remaining backup copies will have expired.

12 Audits and Inspections

12.1 Audit Rights

The Processor shall make available to the Controller all information reasonably necessary to demonstrate compliance with this DPA. The Controller, or an independent auditor appointed by the Controller, may audit the Processor's Processing of the Controller's Personal Data, subject to the following conditions:

• (a) the Controller shall give at least 30 days' advance written notice of an audit;
• (b) audits shall be conducted during normal business hours and shall not unreasonably interfere with the Processor's operations;
• (c) the Controller shall bear its own costs;
• (d) the auditor must agree reasonable confidentiality obligations, and must not be a competitor of the Processor;
• (e) an audit must not require the Processor to disclose another customer's data, or information that would compromise the security of the Service or of another customer; and
• (f) audits are limited to once in any 12-month period, unless a Personal Data Breach has occurred or is suspected, unless the Controller is required to audit by a supervisory authority, or unless a previous audit identified a material deficiency that has not been remedied.

12.2 Alternative Evidence

The Processor may satisfy an audit request by providing relevant certifications, independent audit reports, penetration test summaries, security questionnaire responses or other written evidence, where that material addresses the Controller's reasonable concerns. Section 6.6 states the Processor's current assurance position, including its NHS Data Security and Protection Toolkit outcome; the Processor shall not offer a Sub-processor's certification as evidence of its own compliance.

12.3 Regulatory and Assurance Evidence

The Processor shall provide, on reasonable request and without charge for a reasonable volume of requests, the information the Controller reasonably needs for:

• (a) its registration with, and inspection by, the Care Quality Commission or the equivalent regulator in Wales, Scotland or Northern Ireland;
• (b) its NHS Data Security and Protection Toolkit submission, including evidence about the Processor's technical and organisational measures, data locations, Sub-processors and incident handling;
• (c) any information governance assurance process operated by an NHS body, a commissioning body, an insurer or a hospital of which the Controller forms part; and
• (d) its own data protection impact assessment, under Section 4.7.

The Processor shall respond to a request under this Section within 20 business days, or sooner where the Controller's deadline requires it and the Controller tells the Processor what that deadline is. The Processor does not warrant that the information provided will satisfy the requirements of any regulator or assurance body.

13 AI-Assisted Processing

Where AI-assisted features are used in the Service, the following applies in addition to the rest of this DPA.

13.1 Instruction and Control

• (a) AI-assisted features are optional. The Controller can enable or disable all AI functionality, or individual AI capabilities, at organisation level through the Service, and can change those settings at any time.
• (b) The use of AI-assisted features by the Controller and its Authorised Users, with those controls set as the Controller has chosen, is an instruction to the Processor to Process the relevant Personal Data through those features, as described in this Section and in the AI Usage Policy .
• (c) The Controller remains responsible for reviewing every AI-generated output before it is relied on or entered into a patient record, and for ensuring that its Authorised Users use AI functionality appropriately, including in free-text fields.

13.2 What is Sent to a Model

• (a) Each AI-assisted feature sends a deliberately constructed, feature-specific request to the model, not a general extract of Customer Data. Relevant context, which may include clinical content, is included in the request where the requested functionality requires it.
• (b) The Processor applies feature-specific data minimisation, pseudonymisation and payload controls designed to reduce identifiable Personal Data where it is not required for the relevant AI-assisted functionality.
• (c) Certain AI-assisted clinical functions necessarily Process clinical or other Personal Data, because that information is required to provide the requested functionality. Authorised Users may also enter Personal Data into free-text fields. The Processor does not warrant that requests contain no Personal Data, and the Controller should ensure that its users use AI functionality appropriately.
• (d) Customer Data is not used to train, fine-tune or evaluate any model, whether by the Processor or, under the arrangements described in Section 13.3, by the infrastructure provider or the provider of the underlying model. Section 2.4 applies.

13.3 Where AI Processing Happens, and Who Can Access It

• (a) AI model inference is provided through Amazon Bedrock, an AWS service. Live dictation transcription is provided through Amazon Transcribe, an AWS service, in AWS's London (United Kingdom) region only. AWS is the Sub-processor for this Processing, as recorded in Annex 3.
• (b) AI model requests are ordinarily served in AWS's London (United Kingdom) region. The Processor's controls restrict production AI model inference to approved European geographic inference profiles, under which a request and its response may be Processed in another AWS region within the United Kingdom or the European Economic Area. Global inference profiles, which can route worldwide, are not authorised for the Processor's production AI processing. The regions in scope are recorded in Annex 3. The European Economic Area is covered by UK adequacy regulations, so no separate Article 46 safeguard is required for that movement. Personal Data is not Processed outside the United Kingdom and the European Economic Area for AI processing.
• (c) For the foundation models the Processor has currently approved for production use, under AWS's published commitments for Amazon Bedrock and the Processor's configuration as verified in August 2026:
  • (i) Amazon Bedrock does not durably retain model inputs or outputs. Requests and responses are processed and returned; they are not stored at the model layer;
  • (ii) AWS service operators do not have access to model input or output content under the applicable Amazon Bedrock controls;
  • (iii) the Processor has not enabled Amazon Bedrock model invocation logging, so request and response content is not captured in the Processor's logs through that mechanism;
  • (iv) the Processor has not enabled any sharing of inference data with model providers; and
  • (v) the provider of the underlying foundation model does not receive, and does not have access to, requests, responses or Amazon Bedrock logs.
• (d) On the basis of paragraph (c), the provider of the underlying foundation model does not receive or have access to Personal Data and is not a Sub-processor. If a change to the arrangements described in this Section would give a model provider access to Personal Data, the Processor shall treat that provider as a new Sub-processor and shall follow Section 7 before the Processing begins.
• (e) The Processor reviews the processing location, retention characteristics, provider-access arrangements and applicable data-protection requirements of a foundation model before approving it for production use. Paragraph (c) describes the models and configuration currently approved; it is not a statement about every model that AWS may offer.

13.4 AI Retention

Retention differs by layer. The parties acknowledge the following, which Annex 2 paragraph 10 restates as a technical measure.

• (a) Model layer. For the currently approved production models, no request or response is durably retained at the model layer, as described in Section 13.3(c).
• (b) Transient clinical AI content. Certain clinical AI inputs, including AI charting requests and streamed dictation audio, are Processed transiently for the duration of the request and are not retained by the Processor as stored AI content or as an AI conversation history.
• (c) Application AI histories. Where an AI-assisted feature provides a user-facing conversation or session history, the Processor retains that application data for the documented retention period for that feature and then deletes it automatically. The current periods are: booking assistant conversations, 7 days; form builder conversations, 7 days; Lumina Intelligence conversations, 90 days by default; Lumina Intelligence attachments, 30 days. The Processor shall keep the documented retention schedule current and available to the Controller. A change that materially increases the retention of Personal Data under this paragraph is a change to the measures for the purposes of Section 6.5.
• (d) Clinical records and clinical drafts. AI-assisted output that a clinician accepts into a patient record becomes part of the clinical record and follows the normal clinical-record lifecycle under this DPA and the Controller's retention duties. AI involvement in drafting does not convert clinical-record content into temporary AI data. Unaccepted draft notes produced by AI-assisted note-taking are retained within the patient record pending clinical review; they follow the practice's normal clinical-record lifecycle and can be reviewed, accepted, superseded or deleted by an authorised clinician. They do not expire automatically. A draft does not form part of the final clinical record until a clinician accepts it, and it is not treated as temporary AI conversation history.
• (e) Governance and audit metadata. The Processor maintains audit and governance information designed to support accountability, security monitoring and incident investigation, including relevant user, timing, feature and activity information. That metadata does not include the verbatim content of transient AI inputs.
• (f) Reconstruction. Because the transient AI inputs described in paragraph (b) are deliberately not retained, the Processor may not be able to reproduce the verbatim input after processing has completed. This reflects data minimisation: the Processor does not maintain an archive of transient AI content. What can be established afterwards is the audit metadata described in paragraph (e) and, where applicable, the accepted output in the clinical record.

13.5 Automated Decision-Making and Human Oversight

AI-assisted features produce drafts, suggestions and summaries for human review. AI-assisted clinical output is subject to clinician review before acceptance into the patient record, and administrative changes proposed by an AI-assisted feature require user confirmation before they take effect. The Processor does not rely on the AI capabilities described in this Section to make a decision about a Data Subject based solely on automated Processing that produces legal or similarly significant effects. The Controller must not configure or use the Service to make such a decision on the basis of special category data, which remains restricted under Articles 22A to 22D UK GDPR as amended by the Data (Use and Access) Act 2025. Meaningful human review by a suitably qualified person is required before any AI-generated output is acted on.

13.6 Not a Medical Device

AI-assisted features are not a medical device or a diagnostic tool, and are not held out as regulated clinical software. Clinical decisions remain the responsibility of the Controller and its clinicians. This does not affect the Processor's responsibility for the Service performing materially as described, including for defects that cause Personal Data to be recorded, displayed or presented incorrectly.

14 Liability

14.1 Structure

• (a) General cap. Subject to Sections 14.2 and 14.3, and except for Data and Security Claims, each party's liability arising out of or in connection with this DPA is limited, in aggregate in each Contract Year, to the general cap in Section 12.2 of the Terms, being the greater of:
  • (i) the fees paid or payable in the 12 months immediately before the event giving rise to the claim. Where that event occurs in the Controller's first 12 months, this amount is the fees paid or payable from the Effective Date up to the date of that event, with no annualisation, grossing up or projection; and
  • (ii) £5,000.

  The floor in paragraph (a)(ii) exists so that a Controller on the free Starter Practice plan is not left without a remedy, which is the reason given in Section 12.2 of the Terms.

• (b) Data and Security Claims cap. Notwithstanding paragraph (a), each party's liability for Data and Security Claims is limited, in aggregate in each Contract Year, to £50,000.

  "Data and Security Claims" means claims in respect of any of the following four categories, and has the same meaning as in Section 12.3 of the Terms:

  • (i) data protection: breach of Applicable Data Protection Law or of this DPA, including a Personal Data Breach;
  • (ii) confidentiality: breach of the confidentiality obligations in Section 16 of the Terms;
  • (iii) loss or corruption of Customer Data: loss, corruption, destruction or unauthorised alteration of Customer Data, except to the extent excluded by Section 12.4 of the Terms; and
  • (iv) security: failure of the Processor's security obligations under this DPA, Annex 2 and Section 5.5 of the Terms, including unauthorised access to, or unauthorised disclosure of, Customer Data.

  The limit in paragraph (b) applies instead of, and never in addition to, the general cap in paragraph (a) for those claims. No claim, and no connected series of claims, may be recovered under both. The two limits are separate aggregate limits, and an amount recovered under one does not reduce the other.

• (c) Aggregation across the documents. The liability limits in this Section are aggregate limits across the Terms, this DPA and the Service Confirmation together. A claim that could be brought under more than one of them does not attract more than one cap.
• (d) Contract Year and connected claims. Each limit in this Section is an aggregate limit that applies to all claims arising in the same Contract Year taken together, and is not a limit on each claim. A series of connected claims is treated as a single claim. Claims are connected if they arise from the same facts, events or circumstances, or from facts, events or circumstances that are connected to one another, including a continuing state of affairs and a repeated or continuing act or omission. A connected series is treated as one claim arising in the Contract Year in which the first claim in the series arose, and is subject to the limit for that Contract Year only. Section 12.2A of the Terms says the same thing and governs if the two are read differently.
• (e) Enhanced Cap. Where the Controller is on the Enterprise plan and its Service Confirmation records a higher general cap, a higher Data and Security Claims cap, or both (an "Enhanced Cap") under Section 12.3A of the Terms, the Enhanced Cap applies in place of the corresponding figure in paragraph (a) or paragraph (b), and the rest of this Section applies unchanged. Where the Service Confirmation records no Enhanced Cap, the figures in paragraphs (a) and (b) apply.
• (f) Mutual application. The limits in this Section apply to both parties on the same basis, including the Data and Security Claims limit in paragraph (b).
• (g) Paragraph (f) does not bring the exclusions from the Controller's cap in Section 12.5 of the Terms within either limit in this Section 14.1. The Controller's obligation to pay Subscription Fees, Extra Usage charges and amounts recoverable under Section 4.6 of the Terms, and the Controller's liability under the indemnity in Section 13.1 of the Terms, remain uncapped, exactly as Section 12.5 of the Terms provides; this DPA does not narrow that carve-out or bring those amounts within the limit in paragraph (a) or paragraph (b).
• (h) Exclusions do not empty this Section. Nothing in Section 12.4 of the Terms excludes or limits a liability that paragraph (b) of this Section makes recoverable as a Data and Security Claim. Section 12.4 of the Terms lists expressly what remains recoverable, including compensation payable to a Data Subject, the reasonable costs of investigating, containing, notifying and remediating a Personal Data Breach, and the reasonable costs of restoring Customer Data.

14.2 What Cannot Be Limited

Nothing in this DPA or the Terms excludes or limits:

• (a) liability for death or personal injury caused by negligence;
• (b) liability for fraud or fraudulent misrepresentation;
• (c) any liability that cannot lawfully be excluded or limited;
• (d) either party's liability to a Data Subject under Article 82 UK GDPR, which is a statutory liability owed to the Data Subject and cannot be limited by agreement between the parties; or
• (e) either party's liability to pay an administrative fine or other penalty imposed on it by the Commissioner or another regulator, which cannot be limited by agreement and cannot be recovered from the other party except as provided in Section 14.3.

14.2A The Limits Allocate Liability Between the Parties Only

This Section 14 allocates liability between the Processor and the Controller. It does nothing else. In particular, nothing in this Section, and nothing in Section 12 of the Terms:

• (a) limits or affects any claim a Data Subject may bring directly against either party, including a claim for compensation under Article 82 UK GDPR;
• (b) limits or affects any investigation, enforcement action, penalty or fine by the Commissioner or by any other regulator against either party;
• (c) limits or affects either party's own obligations under Applicable Data Protection Law, or any other liability that cannot lawfully be limited or excluded; or
• (d) limits or affects a party's right of contribution or recovery under Article 82(5) UK GDPR or under the Civil Liability (Contribution) Act 1978, except that the amount one party may recover from the other under those rights is subject to the applicable limit in Section 14.1, as Section 14.3(c) provides.

Neither party may rely on this Section, or on Section 12 of the Terms, against a Data Subject or against a regulator. Section 12.6A of the Terms says the same thing.

14.3 Contribution and Recovery Between the Parties

• (a) The parties acknowledge Article 82(4) UK GDPR: where a controller and a processor are both involved in the same Processing and are both responsible for damage caused by it, each is liable to the Data Subject for the entire damage, so that the Data Subject receives effective compensation.
• (b) The parties acknowledge Article 82(5): a party that has paid full compensation for that damage may claim back from the other the part of the compensation corresponding to the other's responsibility for the damage.
• (c) Nothing in this DPA or the Terms excludes or restricts a party's right of contribution or recovery under Article 82(5), or under the Civil Liability (Contribution) Act 1978. The amount a party may recover under this Section is subject to the applicable limit in Section 14.1, which for a Data and Security Claim is the limit in Section 14.1(b), except where Section 14.2 applies.
• (d) Each party shall notify the other without undue delay of any claim, complaint or regulatory action relating to the Processing under this DPA, and shall provide the other with the information and cooperation it reasonably needs to respond, including the information needed to assess the allocation of responsibility under Article 82(5).

14.4 Interpretation

This Section is a stand-alone allocation of liability for data protection matters. Where it conflicts with the limitation of liability section of the Terms, this Section prevails. This Section does not create a liability that would not otherwise exist.

This Section is drafted to match Section 12 of the Terms and not to displace it. The figures (£5,000 and £50,000), the four Data and Security Claims categories, the per-Contract-Year aggregation, the connected-claims rule, the instead-of-not-additional rule, the Enhanced Cap and the allocation-only statement are the same in both documents. If a future change makes them differ on a point this Section does not expressly cover, that is a drafting error to be corrected rather than a deliberate divergence to be construed.

14.5 Survival

This Section 14 survives termination of this DPA without limit, as Section 15 provides.

15 Term and Termination

This DPA takes effect on the earlier of the Effective Date under the Terms and the date on which the Processor first Processes Personal Data on behalf of the Controller, and remains in effect for as long as the Processor Processes Personal Data on behalf of the Controller. An effective date recorded in the Service Confirmation does not postpone the start of this DPA. Sections 3.4(d), 6.2(c), 8, 9, 10, 11, 12, 14 and 16 survive termination for as long as the Processor holds Personal Data of the Controller, and Sections 11.5, 14 and 16 survive without limit.

Termination of this DPA does not by itself terminate the Terms. Termination of the Terms terminates this DPA once the Processor has completed its obligations under Section 11.

16 Governing Law

This DPA is governed by and construed in accordance with the laws of England and Wales. The courts of England and Wales have exclusive jurisdiction to settle any dispute arising out of or in connection with it.

17 Contact

For questions about this DPA, to give an instruction under it, or to exercise a right under it:

A1 Annex 1: Details of Processing

This Annex sets out the particulars required by Article 28(3) UK GDPR and supports the parties' records under Article 30.

1. Subject Matter

The provision of the Lumina dental practice management platform to the Controller under the Terms, and the Processing of Personal Data necessary to provide it.

2. Duration

As set out in Section 3.5.

3. Nature and Purpose of the Processing

The Processor Processes Personal Data to:

• host and store patient records and clinical data;
• enable clinical workflow management, charting, treatment planning and scheduling;
• provide practice administration, reporting and analytics functionality to the Controller;
• operate the Lumina Patient Portal and the patient-facing applications for the Controller's patients;
• send appointment, recall, clinical and administrative communications on the Controller's behalf;
• support payment, invoicing and financial record functionality, and route payment transactions to the Controller's payment provider;
• support NHS claim and course-of-treatment processing where the Controller uses that functionality;
• provide AI-assisted features, subject to the Controller's AI controls described in Section 13;
• maintain audit logs and compliance records;
• perform backups, restores and disaster recovery;
• provide support, incident response and service operation, in accordance with Sections 6.2 and 6.3.

Where a module or feature is not enabled for the Controller, the corresponding Processing does not take place for that Controller.

4. Types of Personal Data

5. Categories of Data Subjects

• Patients of the Controller's practices, including children and other individuals who may lack capacity;
• parents, guardians, carers and other individuals with authority for a patient;
• emergency contacts, guarantors and other third parties whose details a patient or the Controller provides;
• staff, contractors, associates and other personnel of the Controller who hold or are named in Service accounts;
• individuals at referring or receiving practices, laboratories and other organisations with whom the Controller corresponds through the Service.

6. Processing Operations

Collection, recording, organisation, structuring, storage, adaptation, alteration, retrieval, consultation, use, disclosure by transmission to recipients the Controller designates, making available to the Controller's patients through the Patient Portal, alignment, combination, restriction, erasure, destruction, backup, restore, and provision of the support and service operation described in Sections 6.2 and 6.3.

7. Sensitivity and Safeguards

The Processing involves special category data at volume, relating to identifiable individuals including children, in a health care context. The measures in Annex 2 apply, together with the confidentiality obligations in Sections 3.4(d) and 6.2(c).

8. Controller's Contacts

A2 Annex 2: Technical and Organisational Measures

Version: 11 August 2026. Maintained under Section 6.5.

This Annex describes security outcomes and categories of control. It does not describe Lumina's internal security architecture, infrastructure topology or vendor-specific control mechanics; further detail can be provided to a Controller under the confidentiality terms of the customer agreement where an assessment genuinely requires it (Section 12).

1. Encryption and Key Management

• Personal Data is encrypted in transit and at rest using industry-standard cryptographic protections, covering databases, file and object storage, and backups.
• Encryption keys are managed through appropriate managed and Lumina-controlled key-management arrangements according to the relevant system and the sensitivity of the data.

2. Identity, Access Control and Tenancy

• The Service uses passwordless authentication by default. Passkeys are recommended and supported. Additional authentication controls, including SMS verification where enabled, can be configured by the Controller at organisation level.
• Access to protected functions is authenticated, scoped to the relevant organisation and, where applicable, practice, and subject to server-side authorisation before Personal Data is accessed or changed.
• Access is role-based, with granular, action-level permissions. Staff can see and change only what their assigned role permits, and the creation and amendment of clinical entries is restricted to appropriately qualified clinical roles.
• Each organisation's Personal Data is logically separated. Separation between organisations is enforced by server-side controls, not by the user's device or browser.
• Internal systems are segregated and access-controlled according to least-privilege principles.
• Administrative access to production is held by named individuals under Section 6.2, is logged, and is not shared.

3. Infrastructure and Environment Security

• Customer Data is hosted within the United Kingdom in resilient, access-controlled infrastructure. Lumina applies network protections, monitoring, environment separation and controlled deployment processes designed to protect Customer Data from unauthorised access, loss, alteration and accidental destruction.
• Customer Data is stored in the United Kingdom and is not replicated outside the United Kingdom. The locations applicable to AI processing and to Sub-processors are recorded in Section 13 and Annex 3.
• Development, test and production environments are segregated. Production Customer Data is not used in development or test environments (Section 6.4).

4. Resilience, Backup and Restore

• Point-in-time recovery is enabled on production database stores, providing a rolling 35-day restore window. This is a production configuration; non-production environments are not covered.
• Prior versions of production documents and images are retained, so that accidental overwrite or deletion can be recovered.
• Data stores are protected against destruction during infrastructure changes, and deleted records can be restored from the point-in-time recovery window during its currency.
• Recovery time and recovery point objectives are operational targets described in the Service Level Agreement. They are not commitments under this DPA.

5. Logging, Monitoring and Audit

• The Service maintains an audit trail of data modifications and of key access and security events, including authentication events, permission changes and administrative actions, designed to support accountability, security monitoring and incident investigation, including relevant user, timing and activity information.
• Audit records are encrypted, protected against alteration, and retained for compliance purposes.
• Application and infrastructure logs are collected centrally with defined retention, and error rates and security-relevant events raise automated alerts.
• Continuous monitoring is applied for anomalous access patterns and security events.

6. Personnel

• Every individual with access to Personal Data is bound by a written confidentiality obligation that survives the end of their engagement, and by Lumina's internal policy on the handling of health data.
• Access to production systems and Customer Data is restricted to named, individually authorised personnel on a need-to-know basis, is least-privilege, and is logged. Sections 6.2 and 6.3 of the DPA govern that access.
• Access authorisations are kept under review and are revoked promptly when an individual leaves or changes role.
• Personnel receive data protection and information security guidance appropriate to their role.

7. Secure Development and Change Management

• Changes to the Service are made under version control, are peer reviewed, and are released through controlled deployment processes.
• Security-sensitive changes, including changes affecting authentication, authorisation, tenant separation, payment handling and patient data handling, receive security review before release.
• Third-party and internal software dependencies are kept under review.
• Security review is currently performed internally. Independent penetration testing has not yet been commissioned; where the Processor commissions independent testing, summaries may be offered as evidence under Section 12.2.

8. Special Category Data

• The measures in this Annex apply to all Personal Data. In addition, for health data: access is scoped to the practice and the clinical role of the requesting user; clinical writes are restricted to treating clinical roles; audit records are kept of clinical record changes; and the confidentiality obligations in Sections 3.4(d) and 6.2(c) apply to every individual who can access it.

9. Deletion and Restorability

• Deletion behaviour is as described in Section 11.1. Records deleted through the Service are flagged and removed from ordinary Processing, remain restorable for a defined period, and are then purged. Backup copies expire on a rolling basis within 35 days.

10. AI-Assisted Features

• The processing locations, model-layer retention and access position, and provider arrangements for AI processing are as set out in Section 13 and Annex 3.
• Feature-specific data minimisation, pseudonymisation and payload controls are applied so that identifiable Personal Data is reduced where it is not required for the relevant functionality (Section 13.2).
• Application-level retention of AI conversation and session data follows the layered schedule in Section 13.4 and expires automatically.
• The Controller can enable or disable all AI functionality, or individual AI capabilities, at organisation level (Section 13.1), and per-organisation usage metering and controls are applied to AI features.
• AI-generated clinical output requires clinician review before acceptance into the patient record (Section 13.5).
• Customer Data is not used to train, fine-tune or evaluate any model.

11. Certifications and Assurance

As stated in Section 6.6: NHS Data Security and Protection Toolkit, Standards Met (2025 to 2026 assessment year, NHS organisation code K1G1E); Cyber Essentials in progress; ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2 and SOC 3 not held at the date of this Annex.

A3 Annex 3: Approved Sub-processors and Transfer Mechanisms

Current as at the date of the Service Confirmation. Maintained under Section 7 and published at luminadental.co.uk/subprocessors .

1. Approved Sub-processors

1.1 Infrastructure, Hosting, Communications and AI

1.2 Payment Processing

2. Sub-processors Used by Lumina as Controller

Sub-processors that Lumina uses for its own controller activities, such as its customer relationship management, accounting and email systems, do not Process Customer Data and are not listed here. They are covered by the Privacy Policy . Where any such system would receive Customer Data, it must be added to paragraph 1 of this Annex first.

3. Changes

Changes to this Annex are notified and may be objected to under Sections 7.3 to 7.5. The Controller may register additional contacts for those notifications by writing to privacy@luminadental.co.uk .

4. Transfer Risk Assessments

Lumina maintains a transfer risk assessment for each Restricted Transfer relied on in this Annex, applying the data protection test in the Data Protection Act 2018 as amended. A copy or a summary is available to the Controller on request under Section 10.1.