Data Processing Agreement

Version v5-2026-09-09 — a draft pending legal review; practices are notified when a reviewed version replaces it.

# Data Processing Agreement — PatientMail

**v5 · 9 September 2026 · IN FORCE AS THE INTERIM AGREEMENT** (v1 2 Sep 2026; v2 3 Sep
2026 after remediation P4.7 added the access record and the acceptance rule; v3 7 Sep
2026 names Kari Labs Ltd, the company that actually exists — a correction, not an
amendment, as no practice had accepted v2; v4 8 Sep 2026, after the whitebox audit: the
company number, the sub-processor list named by its path rather than a hostname that will
change, the limitation period cited, the subject-access stop-the-clock rule, the
Practice's Caldicott Guardian and clinical-safety reviewer in the acceptance record, the
allocation of record-keeping for stored replies, and the electronic-form basis for this
Agreement — no obligation on the Practice is widened, which is why the notice period
rather than a fresh negotiation is the right instrument; v5 9 Sep 2026 adds the
operational-record row to the §5 schedule, below). (Operator decision, 2 Sep:
solicitor review deferred, not skipped). Art 28 requires a written contract before the
processing — it does not require counsel to have written it, and an imperfect executed
DPA protects everyone more than a perfect unsigned one. Questions held for counsel's
later pass are marked ⚖️ and are drafted conservatively in the meantime. Bump the
version when the reviewed text lands; practices re-accept at their next connect.

This Agreement forms part of the contract between **Kari Labs Ltd**, a company registered
in England and Wales (company no. 17441859) whose registered office is 105–111 High
Street, Houghton Regis, Dunstable LU5 5BJ ("**Kari Labs**", the **processor**) and the dental practice identified at acceptance (the "**Practice**", the
**controller**), and governs Kari Labs's processing of personal data on the Practice's behalf
through the PatientMail service.

## 1 · The processing (Art 28(3) particulars)

| | |
|---|---|
| **Subject matter** | Patient communications: appointment reminders, confirmations, recall invitations, booking, cancellation-list offers, review requests, and — only as instructed under §6 — promotional messages. |
| **Duration** | The term of the service contract, plus the wind-down in §10. |
| **Nature** | Mirroring patient records from the Practice's management system (Dentally); evaluating audience rules; sending and receiving messages by email, SMS and WhatsApp; taking booking deposits via Stripe; recording delivery, replies and opt-outs. |
| **Purpose** | Delivering the messages the Practice configures, showing the Practice what was sent, and honouring patient opt-outs and consents. |
| **Personal data** | Identity and contact details (name and preferred name, title, DOB, gender, email, mobile, postcode/town/county/region — not the street address); whether an NHS number and a home telephone number are recorded, but neither value; appointment history and attendance; treatment records **including clinical notes charted against treatments**; recall dates, intervals and method; medical-alert, special-needs, arrears, student and booking-block flags; assigned dentist and hygienist; payment plan; deposit payment records (never card numbers); message and conversation content and delivery records; waiting-list entries and any note taken with them; feedback requests and ratings; consent and opt-out records. Much of this is **special category data (health)** under Article 9 UK GDPR. The full inventory in patient-readable form is the “What we hold” section of the public privacy notice, which is kept in step with the database schema. |
| **Data subjects** | The Practice's patients; Practice staff (account details, and the access record described in §11 — source address, user agent and session per action — for which Kari Labs is controller and which sit outside this Agreement). **Stored replies.** Patients' replies by WhatsApp and SMS are recorded in the Practice's inbox. The Practice is a party to those conversations and the sender of record; both the Practice (as holder of the WhatsApp Business Account) and Kari Labs (as the platform) control the system that records them, so the responsibility is allocated here: replies are kept as part of the Practice's record of care and to act on what the patient asked, are never read to build audiences or for any marketing purpose, are retained on the schedule in §5, and each party's privacy notice tells patients that replies are stored (Investigatory Powers Act 2016 s.46; SI 2018/356). |
| **Controller obligations & rights** | As set out in this Agreement, the service terms, and documented instructions given through the PatientMail interface. |

## 2 · Instructions

2.1 Kari Labs processes patient data **only on the Practice's documented instructions**,
including for transfers (Art 28(3)(a)). The Practice's configuration of PatientMail —
pools, flows, templates, schedules, the retention schedule in §5 — constitutes those
instructions.

2.2 Kari Labs will tell the Practice immediately if, in its opinion, an instruction infringes
UK data protection law (Art 28(3)(h) second sentence), and may suspend the affected
processing until resolved. The platform enforces some of this in software: a flow that
promotes treatment to an audience selected from clinical records will not run against any
patient without recorded explicit consent, whatever its configuration says.

2.3 ⚖️ Kari Labs authors template wording and ships pre-built campaign kits. To the extent Kari Labs
determines the purposes and means of any processing, it is controller of that processing
(Art 28(10)) and accepts the corresponding responsibility. *(Counsel to settle the
classification and reflect it here — register item L4 / escalation item 3.)*

## 3 · Confidentiality

Persons authorised by Kari Labs to process patient data are bound by contractual
confidentiality obligations (Art 28(3)(b)). Access is limited to staff who need it for
support or operation, and support access is audited and read-only.

The common-law duty of confidentiality applies alongside this Agreement: the care lane
rests on the patient's implied consent to disclosure to those directly involved in their
care, of whom a messaging processor acting for the care team is one; anything beyond
direct care rests on explicit consent recorded under §6. The Practice names, in the
acceptance record (Annex B), its **Caldicott Guardian**, who reviews PatientMail's uses of
confidential patient information under Caldicott Principle 1, and the **principal** who
reviews the clinical hazard log (`legal/HAZARD_LOG.md`) as the clinician of record.

## 4 · Security (Art 32)

Kari Labs maintains the technical and organisational measures in **Annex A**, including:
encryption in transit and at rest; row-level security enforcing tenant and practice
isolation in the database itself; nightly automated attack-testing of those isolation
rules; hashed, expiring, single-use booking tokens; encrypted PMS credentials; audited
support access; and continuous-integration guards that fail any code change which would
weaken the consent, marketing-flag or retention controls.

## 5 · Retention and deletion — the Practice's documented instruction

The Practice instructs Kari Labs to retain and delete as follows. This schedule matches the
published privacy policy; the eleven-year period aligns the communications record with
the NHS retention period for the dental record it relates to. ⚖️ *(Counsel to confirm the
comms-as-part-of-the-record justification — escalation item 1.)*

| Data | Retention |
|---|---|
| Working copy of the patient record | While the patient is active in the Practice's PMS; a Dentally archive that stands for 90 days triggers erasure of the clinical and demographic profile, retaining name, contact routes and the send log below |
| Messages, delivery records, bookings | **11 years** from creation; where the patient was under 18 at the time, until their 25th birthday if longer |
| Deposit and payment records | **7 years** |
| Audit events | 6 years — the limitation period for a claim in contract or tort (Limitation Act 1980 ss.5 and 2) |
| Consent records | While relied upon, plus 6 years after withdrawal (the same period) |
| Opt-out records | Indefinitely (necessary to honour the opt-out) |
| Raw PMS webhook payloads | 6 months |
| Operational records — whether the service completed a task it was supposed to complete | **6 months** |

The **operational record** added in v5 is the log of whether the service did what it was
supposed to do — a webhook processed, a nightly update run, a message accepted by a
provider. It holds no name, no contact detail and no message content; what it holds is an
internal identifier, which Kari Labs can resolve back to a patient through its own tables
and which is therefore pseudonymised personal data rather than anonymous telemetry. Six
months is the same ceiling the raw payload row above takes, for the same reason: it
records whether the machinery ran, not what was said, so the argument that communications
form part of the dental record does not reach it.

The record of care itself lives in the Practice's PMS and its statutory retention is the
Practice's responsibility; PatientMail is not an archival system and must not be treated
as the primary record.

## 6 · Special category data and marketing

6.1 The Practice warrants it holds a lawful basis and an Article 9 condition for the
patient data it directs Kari Labs to process: Art 9(2)(h) (provision of health care) for care
communications, and Art 9(2)(a) (explicit consent, recorded in PatientMail) for any
promotional use of treatment history.

6.2 Where the Practice uses proposal-based care messaging (chasing treatment already
proposed to a patient), the Practice warrants the underlying treatment-plan entry
reflects a real clinical conversation.

## 7 · Sub-processors

7.1 The Practice gives **general written authorisation** (Art 28(2)) to the
sub-processors listed on the service's **/sub-processors** page — the same list the
sending code is bound to, so a provider absent from it cannot be used — engaged on terms
no less protective than this Agreement (Art 28(4)).

7.2 Kari Labs will give at least **30 days' notice** of any addition or replacement, during
which the Practice may object on reasonable data-protection grounds; if the objection
cannot be resolved, the Practice may terminate the affected service without penalty.

7.3 Stripe (card, fraud and tax data) and Meta (parts of the WhatsApp Business Platform)
act as **independent controllers** for defined aspects of their services, as described on
the sub-processors page.

## 8 · International transfers

Transfers outside the UK occur only as described in **legal/TRANSFERS.md**: to US
providers holding an active UK Extension (Data Privacy Framework) certification, or,
where a provider is not certified, under an International Data Transfer
Agreement/Addendum supported by a completed data protection test (transfer risk
assessment). Kari Labs notifies each recipient that the data includes health data. Kari Labs
re-verifies certifications quarterly.

## 9 · Assistance

9.1 **Data subject rights (Art 28(3)(e)).** Kari Labs assists the Practice in responding to
patients' requests (access, rectification, erasure, objection, portability) within 10
business days of a request from the Practice — including a per-patient export of
everything PatientMail holds, and immediate erasure of a patient's clinical and
demographic profile at the Practice's instruction. The export covers every table keyed to
the patient, so it is the "reasonable and proportionate" search Art 15(1A) describes. The
one-month period the Practice owes the patient may be paused while the Practice seeks
clarification or verifies identity (Art 12(3) as amended by the Data (Use and Access) Act
2025 s.76); Kari Labs' ten business days run from the Practice's request and are not
paused. Where a patient complains to the Practice about its processing, Kari Labs supplies
the facts it holds within the Practice's 30-day acknowledgement period (Data Protection
Act 2018 s.164A).

9.2 **Security, breach, DPIA (Art 28(3)(f)).** Kari Labs assists with Articles 32–36. On
becoming aware of a personal data breach affecting patient data, Kari Labs notifies the
Practice **without undue delay** with the information in Art 33(3), per
**legal/BREACH_PROCEDURE.md** — the Practice's 72-hour clock to the ICO is the
Practice's, and Kari Labs will not exhaust it.

## 10 · End of the service (Art 28(3)(g))

At termination the Practice chooses **return, deletion, or both**. Kari Labs executes the
choice within **90 days**, provides a deletion certificate, and retains only what UK law
requires (and the opt-out records patients rely on). If no instruction arrives within 60
days of termination, Kari Labs returns an export and then deletes.

## 11 · Audit (Art 28(3)(h))

Kari Labs makes available the information necessary to demonstrate compliance — this
Agreement's annexes, the sub-processor list, CI verification results, the DPIA, and the
Art 30(2) record — and permits audits by the Practice or its mandated auditor, on 14
days' notice, at most annually unless a breach or supervisory authority requires
otherwise, under confidentiality, and without access to other practices' data.

**The Practice does not have to ask for the access record.** An owner of the Practice's
account can read it at any time at **Settings → Access log**: every occasion on which a
patient record was opened, searched, previewed, exported or messaged, who did it, from
what address, and whether it was one of the Practice's own staff or Kari Labs support.
The rows are kept for six years (§5), each one hashes the row before it so that a
deletion or an edit is detectable, and Kari Labs is alerted if one account's reading
volume departs sharply from its own normal.

## 12 · Liability, term, law

⚖️ Liability allocation, indemnities and caps: counsel to draft alongside the Terms of
Service. This Agreement is governed by the law of England and Wales. It takes precedence
over the service terms for data protection matters.

This Agreement is in writing in electronic form, as Art 28(9) permits. Acceptance by an
owner of the Practice's account, after the full text has been shown, by an affirmative
act recorded with the version, the user and the time, is a simple electronic signature
(Electronic Communications Act 2000 s.7; the UK eIDAS Regulation), and the record in
Annex B is its evidence. A new version is offered with thirty days' notice (§7.2 applies
by analogy to every material change); an acceptance of one version is not an acceptance
of the next.

---

## Annex A — Technical and organisational measures (summary)

- Row-level security on every tenant table, with practice-level scoping enforced in
  PostgreSQL; nightly CI runs 42 cross-tenant/cross-site attacks against the live
  database plus a policy-coverage assertion.
- Encryption in transit (TLS) and at rest; PMS credentials encrypted separately
  (AES-256-GCM).
- Booking and manage links: 256-bit random tokens, SHA-256 hashed at rest, expiring,
  single-use.
- Opt-out: POST-confirmed page (scanner-proof), three-tier scope, written back to the
  PMS so a sync cannot resurrect consent; STOP keywords honoured as a floor.
- Marketing controls: consent gate at send; consent-first rail at audience evaluation,
  enrolment and activation; CI guards that fail on unflagged promotional templates,
  consent-gate regressions, or retention-schedule regressions.
- Retention: nightly automated enforcement of §5, verified in CI.
- Two-step verification: available to every account and **required for owners and
  admins** at sign-in; members may enrol and are not compelled to.
- Access: role-based; bulk export gated and audited; support access audited. Every read
  or export of patient data is recorded before it is served — a failure to record
  refuses the read — with the actor, their address, user agent and session. The record
  is hash-chained and readable by the Practice's owners at Settings → Access log.
  Staff addresses and user agents are Practice staff data held for the same six years
  as the rest of the row, for security monitoring and incident response.

## Annex B — Acceptance

Accepted electronically in PatientMail onboarding, and at Settings → Data processing
agreement on each new version. Kari Labs records the DPA version, the accepting user and
the timestamp, and — from v4 — the name of the Practice's Caldicott Guardian and of the
principal who reviews the clinical hazard log, as the Practice supplies them to
privacy@patientmail.co.uk at onboarding (§3). The record is available to the Practice on
request.

See also the sub-processor list and privacy policy.