Privacy Notice
Last updated: · Sub-processors
Who we are
GPDash is a practice management dashboard for UK GP practices, operated by GPDash (operated by Darren Cox, NHS GP practice administrator). This notice describes how we handle personal data about people who use GPDash — usually practice staff (administrators, owners, and clinicians) and our platform admins.
If you're a patient of a GP practice using GPDash: this notice doesn't describe your data. GPDash doesn't store patient-level information. We hold aggregate appointment counts (e.g. "Dr Smith had 12 routine slots on Tuesday morning"), not anything that identifies an individual patient. Your GP practice is responsible for your patient data and has its own privacy notice.
Controller vs processor
GPDash plays two roles, depending on the data:
- For your account (your email, name, audit log of your actions, MFA factors, etc.) we are the controller. This notice covers that data.
- For operational data uploaded by your practice (slot counts, working patterns, sync data from TeamNet) we are a processor acting on the practice's instructions. Your practice is the controller for that data and you should refer to their privacy notice for details.
What we collect, why, and on what basis
Account information
When you sign up, we collect your email address, your name, and a hashed password (we never see your actual password — that's handled by Supabase Auth). Optionally you also choose a role and link yourself to a clinician record.
Lawful basis: (b) Performance of a contract — we need this to provide the service you signed up for.
Multi-factor authentication
If you enrol MFA (mandatory for platform admins), we store the factor metadata — when you enrolled, the name you gave it, and when it was last verified. The TOTP secret itself is held by Supabase Auth and is never readable by GPDash application code, even to us.
Lawful basis: (b) Contract, (f) Legitimate interest in account security.
Authentication events
Every sign-in, sign-out, password change, MFA enrolment, and failed sign-in attempt is recorded with the event type, your user ID (where known), IP address, user-agent, and timestamp.
Lawful basis: (c) Legal obligation (under the UK Data Protection Act and your practice's DSPT requirements), (f) Legitimate interest in detecting and investigating unauthorised access.
Audit logs
When you change practice configuration — e.g. updating slot filters, adjusting working patterns, removing a member — we log what changed, who changed it, when, and (where useful) what the value was before and after. This is the audit trail your practice can review in Settings.
We also keep a platform-level audit log for actions performed by GPDash platform admins (suspending users, providing support via the impersonation feature, etc.) — including the reason given by the admin and a timestamped record of the session.
Lawful basis: (f) Legitimate interest in audit and accountability; (c) where the practice has a regulatory record-keeping obligation.
Practice membership
We record which practices you belong to and your role within each (owner, admin, or user). This is what controls what data you can see and edit.
Lawful basis: (b) Contract.
Service-operation data
We keep short-lived rate-limit counters (typically a one-minute sliding window) to throttle abusive request patterns; these are keyed by your user ID or IP address but contain no content beyond a request count. We also collect Content Security Policy violation reports from your browser if it ever flags one — these don't include personal identifiers.
Lawful basis: (f) Legitimate interest in service availability and security.
If your practice enables the public buddy cover page
Practices can optionally publish their daily buddy cover allocations at a public URL of the form gpdash.net/buddy/<practice-slug> so that reception and admin staff can click through from EMIS without having to sign in. This is opt-in per practice and disabled by default.
If your practice owner or administrator enables this option, the following information about you becomes visible at that public URL: your name, initials, role, your present / absent / day-off status for the current day, and the cover allocations between you and your colleagues. No patient data is ever shown.
The decision to publish this data is made by your practice (as the data controller for its staff records). GPDash, acting as a processor under the practice's Data Processing Agreement, displays the data at the public URL only for as long as the practice leaves the feature enabled. If your practice disables the option, the URL returns "not found" immediately.
Where we don't process
- We don't profile you, target ads, or share your data with advertisers — there are no ads in GPDash.
- We don't sell personal data.
- We don't use cookies for tracking. The only cookies we set are strictly necessary: an HTTP-only session cookie, a CSRF protection cookie, and (during platform-admin impersonation) a cookie identifying the impersonation session.
- We don't run any third-party analytics tied to your identity.
- We don't use your data to train AI models.
Who we share data with
We work with a small set of sub-processors who host or operate parts of the service on our behalf. Each is bound by a data processing agreement and acts only on our instructions. The full list, including the country each operates from, is at /privacy/processors.
We don't share your personal data with anyone else unless (a) you ask us to, (b) we're required by law (e.g. a court order, an ICO investigation), or (c) it's necessary to investigate or prevent fraud or a security incident affecting users.
Where your data is stored
Account data and audit logs live in a Supabase database hosted in London (eu-west-2). The GPDash application runs on Vercel with the Frankfurt region as our default. Rate-limit counters live on Upstash in an EU region. We do not transfer personal data outside the UK / EEA in the normal course of business; if that ever changes (e.g. a sub-processor migrates), we'll update this notice and the sub-processor list, and rely on UK IDTA / EU SCCs as the transfer mechanism.
How long we keep your data
- Account profile + practice memberships — for the life of your account. On deletion, removed within seconds.
- MFA factors — until you remove them, or until account deletion.
- Authentication events — 1 year for routine events; up to 7 years for events flagged in a security incident investigation.
- In-practice audit log — 7 years (NHS records retention standard for operational records).
- Platform-level audit log — 7 years.
- Rate-limit counters — sliding window of up to 1 hour, automatically evicted.
- CSP violation reports — 30 days (Vercel log retention).
When you delete your account, the rows containing your personal data are deleted for: profile, MFA, practice memberships. For audit logs, the row is preserved (audit integrity matters) but your user ID is set to NULL and denormalised mirrors of your email are removed — so the row no longer identifies you. This is sometimes called "pseudonymisation" or "anonymisation in place."
Your rights
Under UK GDPR you have the following rights. The ones marked "built-in" can be exercised yourself in the app; the others require you to contact us.
- Access (Article 15) — built-in. Account Settings → Data & privacy → Download JSON.
- Rectification (Article 16) — built-in. Edit your profile in Account Settings.
- Erasure (Article 17) — built-in. Account Settings → Data & privacy → Delete my account.
- Portability (Article 20) — built-in. The export above is a machine-readable JSON archive.
- Restriction (Article 18) — contact us.
- Object (Article 21) — contact us.
- Withdraw consent (Article 7) — not applicable; we don't process your personal data on the basis of consent.
- Complain to a supervisory authority — the UK regulator is the Information Commissioner's Office (ICO). We'd appreciate the chance to address things first, but you don't have to come to us before complaining to the ICO.
Security
We use HTTPS with HSTS preload on all traffic; a strict Content Security Policy; per-row Row-Level Security on every database table; enforced TOTP MFA for platform admins; per-endpoint rate limiting; and an append-only audit trail for every change to practice data. The full set of security headers is documented in our security.txt file, which also tells security researchers how to report vulnerabilities.
If we ever detect a personal data breach that's likely to result in risk to your rights and freedoms, we'll report it to the ICO within 72 hours and tell affected users without undue delay.
Children
GPDash is for practice staff, not for children. We don't knowingly collect data from anyone under 18.
Changes to this notice
We'll update this notice as the service evolves. The "Last updated" date at the top reflects the latest substantive change. For any change that affects your rights or how we process your data materially, we'll let you know by email before the change takes effect.