Clinic Data Processing Agreement
Version 2026-10-04.1 · Last updated 4 October 2026
Download a copy of this version · Archived version (4 October 2026)
Starter is the current name for the Free plan referred to in this document.
The Curatory Group Limited trading as planner.clinic
This Agreement sets out how planner.clinic processes personal data on a clinic’s behalf when providing its informational treatment-planning service.
1 Parties and incorporation
1.1 This Agreement is between the clinic business or practitioner identified in the clinic’s account and acceptance record (the Clinic) and The Curatory Group Limited, company number 16808153, registered in England and Wales, trading as planner.clinic (the Provider, we or us). The Provider’s registered office is Higgison House, 381-383 City Road, London, United Kingdom, EC1V 1NW. This is the registered office. Contract and privacy enquiries should be emailed to info@planner.clinic.
1.2 This Agreement, version 2026-10-04.1, forms part of the Terms and Conditions, version 2026-10-04.3, and applies to Free, Pro and Team accounts. It takes effect when an authorised representative expressly accepts those Terms, including this Agreement, for the Clinic, or expressly accepts this Agreement separately, electronically or in writing. The representative confirms that they have authority to bind the Clinic. We will retain a record identifying the Clinic, accepting representative, document versions and acceptance date. Publication alone does not create acceptance or change any historical acceptance record.
1.3 This Agreement takes precedence over conflicting service terms concerning the processing it covers. Mandatory data-protection law and applicable international transfer terms take precedence over this Agreement. The service terms govern other matters, including fees and cancellation, without limiting either party’s mandatory duties or individuals’ rights.
2 Scope and roles
2.1 Data Protection Law means the UK GDPR, the Data Protection Act 2018 and other applicable UK data-protection legislation, as amended. Controller, processor, personal data, processing, personal data breach and special-category data have their meanings under that law. Clinic Data means personal data we process on the Clinic’s behalf as described in Schedule 1. Subprocessor means another organisation engaged to process Clinic Data on that behalf.
2.2 The Clinic is the controller and we are its processor for Clinic Data. The Clinic determines the purposes of that processing and remains responsible for clinical decisions, the patient relationship, the lawfulness of its instructions, privacy information and its relevant Article 6 lawful basis and, where applicable, Article 9 condition. This Agreement is not patient consent or a substitute for those requirements.
2.3 We act as a separate controller for our own account administration, billing, business compliance, marketing and security activities where we determine their purposes and means. Those activities are described in our Privacy Policy. This distinction does not permit us to use patient treatment content for unrelated purposes or to reclassify processing on the Clinic’s behalf to avoid our processor duties. Any new use requires a lawful basis and any necessary separate arrangements before it begins.
2.4 We will not use Clinic Data for advertising, sale, unrelated profiling or training general-purpose AI models. The intended service provides generic treatment information and administrative planning, not the storage of clinical records or patient-specific health information. Clinics must keep those records on their own clinical systems. Generic descriptions, prices and general treatment information do not automatically constitute health data. Classification depends on what the actual information reveals about an identifiable person; using a first name or recall code does not itself determine the answer.
2.5 This Agreement covers personal data processed on the Clinic’s behalf even where it is not special-category data. Any proposed use involving patient health data requires a prior scope review and appropriate lawful and contractual arrangements. If information outside the permitted scope is entered accidentally, our applicable security, confidentiality, assistance and deletion duties still apply while the parties arrange appropriate handling.
3 Instructions and Clinic responsibilities
3.1 We will process Clinic Data only on the Clinic’s documented instructions, including for international transfers, unless UK law requires otherwise. If such law requires processing, we will inform the Clinic of the requirement before processing unless the law prohibits that notification on important grounds of public interest.
3.2 The initial instructions are to provide the service described in Schedule 1, act on authorised in-app actions, apply the stated retention periods, and use authorised subprocessors and lawful transfers under this Agreement. Further instructions may be recorded through the service or an authenticated written request to info@planner.clinic. We may verify the requester’s authority and clarify ambiguous instructions.
3.3 We will immediately inform the Clinic if, in our opinion, an instruction infringes Data Protection Law. We may pause the affected instruction while seeking clarification and will not carry out processing we know to be unlawful. If the issue cannot be resolved, the parties will arrange lawful return or deletion and termination of the affected processing.
3.4 The Clinic will provide accurate instructions, grant access only to authorised people, protect its devices, accounts, downloaded documents and recall codes, and promptly report suspected compromise. It must keep clinical records and patient health data on its own systems and observe the input restrictions in Schedule 1. The Clinic will identify a contact able to receive data-protection and security notices and keep that contact current.
4 Confidentiality and access
4.1 We will ensure that anyone authorised to process Clinic Data is subject to an appropriate contractual or statutory duty of confidentiality. Access will be limited to people who need it for the permitted service, support, security or legal purpose, using appropriate authorisation and access controls.
4.2 We will maintain procedures for granting, reviewing and withdrawing privileged access, including when responsibilities change. Routine customer support does not require patient names, personal messages or PDFs. We will request only information needed to handle the issue and use an appropriate secure route if Clinic Data must be exchanged.
5 Security measures
5.1 We will implement and maintain appropriate technical and organisational measures under Article 32, taking account of the state of the art, implementation costs, the nature, scope, context and purposes of processing and the risks to individuals. These include appropriate confidentiality, integrity, availability and resilience; restoration capabilities appropriate to the risk; and regular assessment of the measures’ effectiveness.
5.2 Schedule 2 describes the service controls and the operational measures to be maintained. We may improve or replace measures provided the overall protection is not materially reduced. We will tell the Clinic about material changes that affect its risk assessment.
5.3 The Clinic remains responsible for the security of its own devices and exports. Browser storage is a convenience recovery mechanism and should be used on appropriately secured clinic devices. Signing out is not a guarantee that a local draft has been removed.
6 Subprocessors
6.1 The Clinic gives general written authorisation for the subprocessors and processing purposes in Schedule 3, subject to this section. Before using a subprocessor, we will assess its suitability and put a binding written contract in place imposing equivalent applicable Article 28 obligations. We remain responsible to the Clinic for the subprocessor’s performance of those obligations.
6.2 We will notify the Clinic’s designated contact in writing before an intended addition or replacement becomes involved in its Clinic Data, with sufficient information and a reasonable opportunity to object on data-protection grounds. We will seek to give at least 30 days’ notice for changes we control directly. For changes within an existing provider’s supply chain, we will promptly pass on the notice we receive and identify the response deadline. We will not treat silence following an inadequate opportunity to object as authorisation for new processing.
6.3 If the Clinic raises a reasonable objection, we will work with it on safeguards or an alternative. We will not permit the disputed new processing of its data while the objection is unresolved. Where an upstream provider cannot accommodate that restriction, we will suspend or move the affected processing. If no reasonable solution is available, the Clinic may end the affected service without an early termination penalty and receive a refund of unused prepaid fees for that service, with return or deletion under section 10.
6.4 We will keep an accessible register of direct subprocessors and make relevant information about their downstream providers available to the Clinic. The provider links in Schedule 3 supplement our own notification and contractual obligations under this section.
7 International processing
7.1 We will not initiate or allow a restricted international transfer of Clinic Data without the Clinic’s documented instructions and a lawful transfer mechanism. Where required, we will use applicable UK adequacy regulations, the UK International Data Transfer Agreement, or approved standard contractual clauses with the UK Addendum, and carry out the required data protection test or transfer assessment and supplementary measures.
7.2 Schedule 3 records known service locations and cross-border considerations. A London database does not establish that hosting, provider support, logs, backups or onward processing remain exclusively in the UK. We will provide relevant transfer information and copies of safeguards on request, with only necessary redactions for confidentiality or security. This Agreement does not itself replace a required transfer instrument.
8 Assistance and requests
8.1 Taking account of the nature of processing and the information available to us, we will provide appropriate technical and organisational assistance for the Clinic to meet individuals’ rights requests and its obligations under Articles 32 to 36, including security, breach reporting, DPIAs and consultation with the ICO.
8.2 If we receive a request from an individual concerning Clinic Data, we will inform the Clinic without undue delay and follow its instructions. We will not respond substantively on the Clinic’s behalf without authorisation unless the law requires it. We may direct the person to the appropriate Clinic and assist proportionately with identifying the relevant records without collecting unnecessary identifiers.
8.3 We will respond to the Clinic’s requests promptly enough to support its applicable statutory deadlines and will communicate any difficulty immediately. The Clinic should supply the relevant clinic identifier and, where available, a plan code or record reference through an appropriate channel. We cannot search for a patient name that the server never held or reconstruct an original recall code from its hash.
8.4 We will cooperate with the ICO and other competent authorities as required by law. Any separately agreed charges for exceptional assistance must be reasonable and must not prevent compliance with mandatory obligations or timely incident assistance.
9 Personal data breaches
9.1 We will notify the Clinic without undue delay after becoming aware of a personal data breach affecting Clinic Data. We will not wait for a completed investigation to give the initial notice. We will use the Clinic’s designated email address and other appropriate contact methods where necessary.
9.2 As information becomes available, the notice and updates will describe the nature of the breach, affected categories and approximate numbers of individuals and records where possible, likely consequences, measures taken or proposed, and a contact for further information. We will investigate, contain and mitigate the breach, preserve relevant evidence and keep the Clinic informed of material developments.
9.3 We will assist the Clinic in deciding on and making required notifications to individuals or regulators. The Clinic retains its controller reporting responsibilities; our duty to notify it is not deferred until its own reporting deadline. We will not notify patients on the Clinic’s behalf without its instruction unless legally required, in which case we will inform the Clinic where permitted.
10 Retention and ending processing
10.1 We will apply the instructions and retention arrangements in Schedule 1. Cancelling a paid subscription or archiving a clinic does not itself instruct account deletion: the Clinic may continue using the Free service or retain an archived workspace. Paid-access restrictions will not remove the Clinic’s ability to request assistance with return or deletion.
10.2 At the end of the relevant processing services, or on a lawful earlier instruction, we will, at the Clinic’s choice, return or securely delete the Clinic Data and delete existing copies, unless UK law requires storage. Return will use a commonly used, reasonably usable electronic format agreed with the Clinic, such as JSON or CSV for structured records, through a secure delivery method. We will not delete the only available copy before fulfilling an agreed return request.
10.3 Bulk return or deletion is support-assisted. We will verify authority, agree the scope, begin without undue delay and provide a written completion timetable reflecting any statutory deadline. There is no charge merely because a Clinic has cancelled its paid plan. The current service does not offer a one-click complete clinic export or account-erasure feature.
10.4 Where immediate deletion from a backup is technically impracticable, we will put the data beyond ordinary use, continue protecting it and arrange deletion as soon as possible within an appropriate documented backup lifecycle. If a backup is restored, relevant deletion instructions will be reapplied before the data becomes available for ordinary use. We will disclose the applicable residual period and any legal retention requirement to the Clinic, and confirm completion on request.
10.5 Return or deletion can cover only data within our control. It cannot recover patient names, messages or PDFs never retained on our servers, reconstruct an original recall code from its database hash, or remove copies held on the Clinic’s devices or by its recipients. The Clinic must handle those copies separately. Any independent-controller records retained by us remain subject to the distinct purposes, lawful bases and retention requirements described in the Privacy Policy; this is not permission to retain patient content for unspecified future use.
11 Accountability and audit
11.1 We will make available all information necessary to demonstrate compliance with Article 28 and allow and contribute to audits and inspections by the Clinic or its appointed independent auditor. We will maintain appropriate processing, security and subprocessor records to support that obligation.
11.2 The parties will ordinarily start with relevant documents and existing assurance evidence, and arrange further examination proportionately to the risk. Reasonable notice, confidentiality and security arrangements may protect other clinics’ data and service availability, but will not prevent a necessary audit. Routine scheduling limits do not apply where a breach, reasonable evidence of non-compliance or a regulator requires more urgent scrutiny.
11.3 We will investigate identified deficiencies, take appropriate corrective action and provide relevant progress information. No contractual restriction or fee may render the Clinic’s statutory audit rights ineffective.
12 Changes and duration
12.1 This Agreement continues while we or our subprocessors hold Clinic Data on the Clinic’s behalf, including during agreed return, deletion and restricted backup retention. Its confidentiality, security, assistance and audit provisions continue as needed for that period.
12.2 Material changes to the Agreement or processing schedule will be presented in a versioned document with appropriate notice and express agreement where required. Subprocessor changes follow section 6. Changes will not retrospectively create acceptance or reduce mandatory protection. England and Wales law and jurisdiction apply, subject to mandatory Data Protection Law and transfer terms.
Schedule 1 Processing details
Subject and purpose. Preparing informational treatment plans using generic descriptions and administrative details; authorised storage and recall of pseudonymised plan structures; clinic configuration; controlled team access; support; and return or deletion on instruction. The service does not make clinical decisions or hold clinical records. The Clinic keeps all patient health data on its own platforms.
People concerned. Patients and prospective patients whose plans are prepared by the Clinic; authorised practitioners, clinic staff and other individuals whose information is included in permitted clinic content or instructions.
Local browser information. Patient first name, personal message and working draft remain on the Clinic’s device. PDF generation takes place in the browser. Drafts expire 48 hours after their last edit and are cleared while the app is open or when next opened; discard and successful final generation also clear the persisted draft. Downloaded files and recipients’ copies remain under the Clinic’s control. Patient names, messages and PDF bytes are not part of the saved server-plan payload.
Saved server information. Clinic and location references; selected generic treatment names and descriptions; quantities, prices, suggested sessions and intervals; proposed dates or flexible timing; generic treatment pain and downtime indicators; display choices; creator and updater user references; a one-way hash of the random plan code; creation, update, access and expiry timestamps. The pain and downtime indicators describe treatments generally, not an individual’s symptoms or recovery. The service also processes clinic-provided configuration, treatment libraries, branding, locations and access information where necessary for these instructions. The intended scope excludes patient-specific health information; classification must be reconsidered if the actual content or use reveals health status.
Operations and frequency. Collection of permitted service inputs, validation, transmission, storage, organisation, retrieval, display to authorised users, support access when necessary, export on instruction and deletion. Processing occurs when the Clinic uses the service and continuously as needed for storage, security and scheduled retention.
Plan retention. A saved plan expires one year after creation. Recall is blocked after expiry and a daily job deletes expired saved-plan rows. Recalling a plan does not extend the original period; generating a new final copy creates a separate row and code with a new period. An authorised clinic member with the code can delete a saved copy earlier. Deletion of that copy does not erase an open local draft, downloaded PDF or separate audit record.
Audit and other records. Saved-plan audit metadata records the plan and clinic reference, actor, action and time. It is retained separately and is not removed by the one-year saved-plan purge. We will keep this metadata only for as long as necessary for the relevant access-accountability, security and service-support purposes, or a legal retention requirement. We will maintain and review a documented, proportionate retention schedule and provide the applicable periods or criteria to the Clinic on request. Section 10 applies to these records where we hold them on the Clinic’s behalf. Other instructed clinic records remain for the service period and are subject to return or deletion at its end. Separate billing and independent security records follow the Privacy Policy.
Restrictions. Do not enter diagnoses, symptoms, medical histories, medications, allergies, clinical findings, treatment outcomes or other patient-specific health information into the service, including personal messages. Keep these on the Clinic’s own clinical platforms. Use only the designated local field for a patient’s first name; do not put patient names, dates of birth, contact details, photographs or other patient identifiers into server-bound fields. Free-text fields can still contain prohibited information if misused; input validation does not guarantee detection. No patient plan content is to be passed to Stripe.
Schedule 2 Security measures
Service controls. Access uses authenticated user sessions and clinic membership checks. Database row-level security and role checks constrain ordinary user access. Saved-plan tables are not directly available to ordinary authenticated users and are accessed through restricted functions. Recall requires membership of the relevant clinic and a cryptographically random plan code; the database stores its SHA-256 hash. Allowed-field validation and size limits reduce excess inputs. HTTPS protects service traffic. Server credentials remain outside the browser. The support console does not display saved-plan contents, patient names, personal messages or PDFs.
Operational measures. We will maintain confidentiality commitments and access reviews; appropriate administrator authentication and credential protection; risk-based vulnerability and dependency management; incident and rights-request procedures; subprocessor and transfer review; a documented retention process; and suitable backup and recovery arrangements. We will assess and test the effectiveness of these measures, including restoration, as appropriate to the risk, and keep records of material findings and corrective action.
Access and recovery boundaries. Authorised infrastructure administrators may have privileged database access, subject to sections 4 and 5. Plan codes may appear in request URLs and associated infrastructure logs; we will protect them as access information. Recall also requires authenticated membership of the relevant clinic. The service does not enforce multi-factor authentication for every clinic user. This Agreement does not specify a guaranteed recovery time or a fixed backup-expiry period; the retention and disclosure duties in section 10 still apply.
Clinic measures. Use individually assigned accounts and appropriately secured devices, restrict shared-device access, protect downloads and recall codes, remove former team members promptly, and discard local drafts when no longer needed. The Clinic must not rely on sign-out alone to clear browser data.
Schedule 3 Subprocessors and locations
The Clinic authorises the following providers for the informational service in Schedule 1, subject to sections 6 and 7. Their listed purposes do not extend the permitted scope to clinical records or patient health information. We remain responsible for our obligations concerning their contracts, security and international transfers.
Supabase Pte. Ltd. Database, authentication and storage services, handling the relevant stored clinic, user, access and saved-plan records. The primary project is in London, United Kingdom, AWS region eu-west-2. The contracting entity is in Singapore. Support, logs, backups and downstream services may involve other countries, subject to section 7. Provider information: Supabase DPA and subprocessor register.
Vercel Inc. Application hosting, network delivery and server request handling, including relevant clinic, user and saved-plan information transmitted in those requests. The production functions use the United States region iad1; network delivery and provider support may involve other locations, subject to section 7. Saved-plan creation and recall requests pass through these functions. Provider information: Vercel DPA and Trust Center and subprocessor register.
Stripe. Stripe is used for separate account and payment processing described in the Privacy Policy. It is not authorised under this Agreement to receive patient treatment content. It is not listed here as a subprocessor for saved patient plans.