Data processing agreement

Draft: this wording is waiting for review by a solicitor, and may change. You’ll be asked to accept the final version.

Version 2026-10-22. Accepted for the Controller by the person signing up on the date of sign-up, by ticking to agree in Hally. UK GDPR Article 28(9) allows this agreement to be in electronic form.

Between

• The clinic signing up, at the address it gives in its settings (the Controller); and
• [Company name] Ltd, trading as Hally, company number [company number], [registered address] (the Processor).

The Processor provides Hally, clinic management software, to the Controller. In providing it, the Processor processes personal data on the Controller's behalf. This agreement sets out the terms of that processing, as UK GDPR Article 28 requires.

1. Definitions

Words defined in UK GDPR and the Data Protection Act 2018 (together, Data Protection Law) have the same meaning here. Personal Data means the personal data described in Annex 1 that the Processor processes for the Controller. Sub-processor means a third party the Processor engages to process Personal Data. Breach means a personal data breach affecting Personal Data.

2. Roles and scope

2.1 The Controller is the controller and the Processor is a processor of the Personal Data.

2.2 The subject matter, duration, nature and purpose of the processing, the types of Personal Data and the categories of data subjects are set out in Annex 1.

2.3 The Controller is responsible for having a lawful basis for the processing, for the accuracy of the Personal Data it provides, and for the information it gives data subjects.

3. The Processor's obligations

The Processor shall:

3.1 Instructions. Process Personal Data only on the Controller's documented instructions, including as to international transfers, unless required to do otherwise by UK law (in which case it will tell the Controller first, unless the law forbids it). This agreement, the terms of service and the Controller's use of the software's settings are the Controller's instructions. The Processor will tell the Controller at once if it thinks an instruction breaks Data Protection Law.

3.2 Confidentiality. Ensure that everyone it authorises to process Personal Data is bound by confidentiality, and that access is limited to those who need it to provide the service.

3.3 Security. Take the technical and organisational measures in Annex 2, and keep them appropriate to the risk (Article 32). The Processor may update them provided the overall level of protection does not fall.

3.4 Sub-processors. Not engage a Sub-processor without the Controller's authorisation. The Controller gives general authorisation for the Sub-processors in Annex 3. The Processor will email the Controller at least 30 days before adding or replacing a Sub-processor; the Controller may object on reasonable data protection grounds, and if the parties can't resolve the objection the Controller may end the service without penalty. The Processor will put terms in place with each Sub-processor giving at least the same protection as this agreement, and remains liable to the Controller for each Sub-processor's performance.

3.5 Data subject rights. Help the Controller respond to requests to exercise data subjects' rights, mainly through the software itself (export of a patient's record; correction; marketing opt-outs; deletion at the end of the retention period). It will pass on any request it receives directly, without responding to it, within 5 working days.

3.6 Assistance. Help the Controller meet its obligations on security, breach notification, DPIAs and prior consultation with the ICO (Articles 32 to 36), taking into account the nature of the processing and the information available to the Processor. A DPIA template describing the software is available to the Controller in the software (Settings → Account).

3.7 Breaches. Notify the Controller without undue delay, and in any case within 24 hours, after becoming aware of a Breach, with what it knows (the nature of the Breach, the categories and approximate number of data subjects and records, likely consequences, and the measures taken or proposed), and follow up as more is known. The Processor will not notify the ICO or data subjects on the Controller's behalf unless asked to.

3.8 End of the service. At the Controller's choice, return or delete the Personal Data at the end of the service:

• the Controller can export all of its data at any time from the software (Settings → Account), in common formats (CSV and JSON), with clinical notes and forms decrypted;
• when the Controller closes its account, the data remains available for 90 days to export, after which it is deleted: the Controller's encryption key first (making encrypted data unreadable at once), then all records;
• copies in backups are overwritten within the backup retention period;

unless UK law requires the Processor to keep it.

3.9 Records and audits. Keep a record of processing activities (Article 30(2)); make available the information needed to show compliance with this agreement; and allow for and contribute to audits, including inspections, by the Controller or an auditor it appoints, on 30 days' notice, no more than once a year unless after a Breach, at the Controller's cost and subject to confidentiality.

4. International transfers

4.1 The Personal Data is stored in the United Kingdom, and the application runs in the European Union (which the UK recognises as adequate).

4.2 Some Sub-processors may process Personal Data, or have access to it, outside the UK (see Annex 3). The Processor will only allow this with appropriate safeguards under Data Protection Law, such as the UK International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, and a transfer risk assessment where required.

5. The Controller's obligations

The Controller shall:

5.1 give instructions that comply with Data Protection Law;

5.2 ensure its staff use the software as intended: keep their own sign-in details safe, use two-step sign-in, leave patient details out of free-text boxes that say so (for example, questions to the AI features), and record no medical reasons for staff sickness;

5.3 decide and set its own retention periods for clinical records in the software, review and confirm the deletions it proposes, and export records it must keep before closing its account.

6. Liability

Liability under this agreement is as set out in the terms of service.

7. Term

This agreement lasts as long as the Processor processes Personal Data for the Controller. Clauses 3.7, 3.8 and 3.9 survive its end for as long as needed.

8. Changes

The Processor may update this agreement by giving the Controller notice in the software. The Controller accepts the new version by ticking to agree; until then the version last accepted applies.

9. Precedence

If this agreement conflicts with the terms of service on the protection of Personal Data, this agreement prevails.

10. Law and jurisdiction

This agreement is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction.

Annex 1: Details of the processing

Annex 2: Technical and organisational measures

Access control

• Two-step sign-in (an authenticator app) required for every staff account.
• Minimum 12-character passwords and sign-in rate limits.
• Sessions end after 30 minutes without activity.
• New staff are invited by single-use links that expire after 7 days; no passwords are sent.
• Role-based access: reception staff cannot open clinical notes; settings and data export are limited to the clinic's owner.

Separation of clinics

• Each clinic's data is kept apart by the database itself: row-level security limits every query to one clinic.
• Each clinic has its own encryption key.
• Automated tests check that no clinic can read or change another's records.

Encryption

• All connections use TLS.
• Data is encrypted at rest by the hosting provider.
• Clinical notes, form answers, signatures and patient messages are also encrypted in the database (AES-256-GCM) with the clinic's own key. That key is itself encrypted with a platform key held separately from the database.

Accountability

• An append-only access log of who viewed or changed each patient record, and when. It cannot be edited or deleted.
• Patient data is never written to application logs or error reports.

Minimisation

• Messages contain no clinical detail, and the message log keeps no message bodies.
• AI features receive no patient data, and free-text inputs are screened before sending.

Retention

• The Controller's retention periods are applied automatically: records past their period are listed for review every day, and deleted on the Controller's confirmation. Financial records are kept without the person's details.

Resilience

• Daily backups with point-in-time recovery; restores are tested.
• Imports can be undone.

Development

• Automated tests (security, clinic separation and the core rules) run on every change before it's released.
• Test and demonstration systems use invented data only.

People

• Confidentiality obligations for everyone with access.
• Access removed when someone leaves.

Annex 3: Authorised Sub-processors

Questions about this agreement: ehwalker92@gmail.com.