Skip to main content

Legal · Privacy

What data we hold, and what we don't.

Unmist collects almost no personal data. This page explains the small amount we do touch, why, how long we keep it, and the rights you have over it under UK GDPR.

Last updated: October 2026 · Data controller: Northlight Technologies Ltd (trading as Unmist) · Contact: hello@unmist.co.uk

Section 01

Who is the data controller

Northlight Technologies Ltd (company number 17513274, a private company limited by shares registered in England and Wales), trading as Unmist, operates unmist.co.uk and is the controller of the personal data described in this notice.

Registered office: 105 Lakenheath, London N14 4RY.

Contact: hello@unmist.co.uk — the fastest route for any privacy enquiry, subject access request, correction, takedown, or data-subject right under UK GDPR.

ICO registration: Northlight Technologies Ltd is registered with the UK Information Commissioner’s Office under registration number ZC272741.

Section 02

The short version

Unmist does not require an account and does not use advertising or cross-site analytics trackers. We collect contact or identity information only when you choose to submit it through a form or email us.

Personal data described in this notice includes:

  • Server-side request logs (your IP address, browser user-agent, the URL you requested, and the timestamp) kept by our hosting provider for short-term security and abuse-prevention purposes;
  • Map-related third-party content on clinic and results pages: when you click “Load map” we load the Leaflet JS library from unpkg and OpenStreetMap tiles via CARTO's CDN. Those CDNs see your IP address and may set their own cookies, in line with their own policies. Until you click it, none of this is loaded — the page shows a static placeholder instead;
  • Anything you voluntarily send us by email (when you write to us about a correction, takedown, or support question).

Usage statistics also involve temporary event records before aggregation, as explained below. The absence of a visitor number does not mean that all initial processing is anonymous.

Section 04f

Location and postcode searches

A town or postcode typed into search is resolved on our server using Nominatim (OpenStreetMap) for place names or postcodes.io for UK postcodes. Those services receive the place name or postcode needed to return a coordinate; your browser IP is not sent to them by us. The requested URL and search wording can still appear in the short-lived Vercel request logs described in Section 03.

If you choose Near me, the exact coordinate supplied by your device is reduced in your browser to a two-decimal point (an area roughly one kilometre across in the UK) before anything is sent to Unmist. That approximate point is placed in the results URL, can appear in the short-lived server logs, and is sent to Nominatim to produce an area label and to Google Places to find nearby public clinic listings. We do not add it to a profile or a persistent location history.

Lawful basis: Article 6(1)(b), providing the location search you explicitly requested. You can instead type a town or postcode and decline the browser location prompt.

Section 03

Server logs

Our hosting provider Vercel Inc. automatically records standard web-server log lines for every request to the site. Each line contains your IP address, browser user-agent, the URL you requested, the HTTP status code, and a timestamp.

Lawful basis: legitimate interest under UK GDPR Article 6(1)(f) — we need basic logs to detect abuse, debug outages, and meet our security obligations. Retention: Vercel keeps these runtime logs for no more than 30 days on our plan (1 day on the standard setting, up to 30 days where Vercel's extended log retention is enabled), after which they are deleted by Vercel. We do not forward logs to any other service and keep no copy of them. Recipients: Vercel staff (under their data processing terms), and ourselves if we investigate an abuse or security event. Logs are not shared with anyone else and are not used to build a profile of you.

Vercel's own privacy policy is at vercel.com/legal/privacy-policy.

Section 04

Cookies

Unmist uses a small number of first-party preference, access and abuse-prevention cookies. The full list is in our Cookie Policy; for ordinary visitors this includes the reversibletl_stats=off preference when they choose not to be counted.

  • tl_admin — strictly necessary, set only when an authorised Unmist account signs in to the admin panel. Used to authenticate administrative actions. Not relevant to ordinary visitors.

When you visit a page that embeds the interactive map (clinic pages and search results), we load the open-source Leaflet library from the unpkg CDN and OpenStreetMap tiles via CARTO's CDN. Those CDNs receive your IP address as part of any standard HTTP request and may set their own operational cookies. These are non-essential under PECR and we will not load the map until you click “Load map”. See CARTO's privacy policy and unpkg's parent (Cloudflare) privacy policy for what each can do with that data.

You can change your cookie choice at any time by clicking the "Cookie settings" link at the bottom of any page, or by clearing this site's storage in your browser.

Full list and detail: see Cookie Policy.

Section 04b

Usage statistics without identifier cookies

We count the use of pages, clinic information, recognised search categories and site features to improve Unmist. We do not use these records for advertising, personalisation or visitor profiles.

We also count site-wide daily unique visits, not people across days. The server temporarily uses the request's IP address, browser user-agent and language header with a random daily key to create a one-day pseudonymous code. We do not create clinic-, treatment-, location-, device- or referrer-level unique counts. The code is never attached to an activity event or used commercially. The daily retention job removes completed-day codes and keys; failures are alerted. We enable this count only after that deletion path and the provider's retention have been verified.

Session measurement is off, so we do not link activity into an individual browsing journey.

Sharing statistics. We do not currently share or sell usage statistics. If we later offer aggregated statistics about demand across the UK private-clinic sector (for example to clinics or sector organisations), they will be counts of actions only — never individual visits, session paths, search wording, health-related categories or anything that could identify you — and we will update this notice before that starts. You can stop contributing to all usage statistics at any time with “Do not count my visits” below or by enabling Global Privacy Control.

Search wording is classified in memory into a recognised treatment or area where possible. Our usage-statistics records keep the category and result count, not the words typed or a hash of those words. The requested results URL may still appear for the separate, short-lived server-log purpose described in Section 03. Arbitrary referring hostnames are not retained in usage statistics.

Where a page supports it, we also keep aggregated counts of how a factsheet is used: how many views had a given section on screen for at least two seconds, how far down the page visitors scrolled, and broad bands of time spent on the page. These are counts of activity, never a record about a person. Search-result impressions and clicks are counted by clinic, by list position and by the treatment or area category of the search, never with the text that was typed. Links out to a clinic's own website carry constant campaign parameters (utm_source=unmist) that identify Unmist as the source and contain no visitor data.

Device, referring-service and network-location dimensions are not added to our minimum usage-statistics records.

Core Web Vitals measurement is currently off.

We process limited event records temporarily to produce daily totals. Records for an aggregated day are then removed. If aggregation fails, older records expire rather than being kept indefinitely. With daily cleanup operating, individual records are removed within 48 hours. Storage or scheduling failures can delay cleanup; these failures are monitored and require action. Missing reporting days are not presented as zero activity.

When raw-event expiry is active, individual event records are deleted within 24 hours of the end of the day they belong to, and only the daily aggregate counts are kept permanently.

Recovery backups and hosting logs have separate lifetimes. Database backups: we do not use point-in-time recovery, and any daily backup of our database held by our database provider (Supabase) is kept for no more than 7 days before it is deleted. Recovery copies are restricted to recovery purposes; expired data must be removed before restored information is returned to use.

Where temporary statistics involve personal data, our basis is UK GDPR Article 6(1)(f), legitimate interests in understanding and improving our service, subject to necessity and balancing safeguards. Device storage or access for this limited purpose is used only where the statistical-purpose exception to PECR applies. This does not authorise advertising or visitor profiles.

Your choice: choose “Do not count my visits” to stop optional statistics without affecting use of the site. The tl_stats cookie remembers your choice for up to 12 months. We also honour Global Privacy Control as an objection and remember it in that same preference cookie. Maps choices are separate. Necessary service and security processing continues.

Section 04c

Third-party analytics

Cloudflare Web Analytics is not loaded when the minimum usage statistics configuration is active. Vercel Speed Insights is not loaded. Hosting and security processing described elsewhere in this notice is separate from optional statistics.

Section 04d

Saved clinics (your private shortlist)

When you tap Save on a clinic factsheet, we store the clinic's name, slug and save date in your browser's local storage under the key unmist_saved. The list appears under Saved, where you can compare the clinics you saved side by side, and it also pre-fills the Compare view.

The list of clinics you save stays in your browser. We don't store it, sync it to an account, or link it to you. When you open the Saved page, your browser sends us only the clinic slugs you saved (public identifiers like taktouk-clinic — nothing about you) so we can look up each clinic's public-record signals (regulator markers, published price) for the comparison. We return that public data and keep no record of the request beyond the standard, short-lived server logs described in section 03. Clear your browser data, or tap the Remove button on the /saved page, to delete the list. It stays there until you remove the clinic or clear your browser data. You can object simply by not using Save, or remove any saved clinic at any time.

Lawful basis: storing the list on your device needs none. For the server look-up, we process only public clinic identifiers to return the comparison you asked for; to the extent any of this is personal data, our basis is legitimate interest under UK GDPR Article 6(1)(f) (providing the feature you requested), and we hold nothing beyond section 03 logs. Cookies / PECR: the localStorage entry is created only when you explicitly tap Save, under paragraph 4 of Schedule A1 to PECR (storage strictly necessary for a service you requested). No cookie banner is required for this feature.

The local-storage keys used by the public site are: unmist_saved for the shortlist and unmist_ask_consent to remember that you accepted the Ask Unmist terms. Each is written only after you act, remains until you remove it or clear browser data, and is never transmitted to us. The basis for each is paragraph 4 of Schedule A1 to PECR: recording selections you made to provide the service you requested.

Section 04e

Your pre-booking check (questions, "Weigh their answers", Consultation Kit)

When you build a message to a clinic, mark it as sent, tick how the clinic's reply landed, or open your Consultation Kit, everything happens in the memory of the browser tab you are using. Unmist does not store any of it — not in cookies, not in local storage, not on our servers — and nothing is sent to us or to the clinic. If you refresh the page, close the tab or change device, those selections are gone; the pages then let you pick the questions again by hand. The questions themselves are Unmist's standard wording; anything you type into "Ask Unmist" is handled as described in section 07b and never becomes part of this check. No storage and access technology is used for this feature, so no consent under PECR is required and no personal data is processed by us.

Section 05

If you write to us

When you email hello@unmist.co.uk — for a correction, a takedown request, or a question — we will hold a copy of your email and your reply address.

Lawful basis: legitimate interest under UK GDPR Article 6(1)(f) — answering correspondence is necessary to run an honest service. Retention: we keep correspondence for as long as needed to handle your request, plus a reasonable archive window (typically two years) in case you write again or dispute something later. Recipients: only Unmist and the email provider that hosts our mailbox. Correspondence is not shared with clinics or any third party unless you explicitly ask us to.

Section 06

If you request an Unmist check

On /not-found-clinic you can ask us to build a factsheet for a clinic we don’t cover yet. The form collects the clinic name and city (required), an optional treatment of interest, and an optional email only if we need to clarify the request.

Lawful basis: Article 6(1)(b) for the clinic details needed to action the request; Article 6(1)(a) for the optional email, which you may withdraw at any time. Purpose: we use the email only if we need a clarification (for example, an ambiguous clinic name). We do not promise that every requested clinic will be added. Retention: the private request record is deleted no later than 12 months after submission, or sooner on request. Recipients: Unmist, Supabase (the private request store) and Resend (the internal notification email). The request is not committed to GitHub. We do not retain your originating search wording, raw user-agent or an IP-derived identifier in the request record. We never share or sell request emails and never use them for marketing.

Section 07

Factsheet alerts (not currently offered)

We are not currently offering factsheet email alerts, and the sign-up form has been removed from clinic pages. We are not collecting any email addresses for this purpose at the moment.

If we reintroduce alerts, opt-in will require an email address and an explicit ticked consent box (lawful basis: consent, UK GDPR Article 6(1)(a)), subscriber emails will be held in our managed database (not in source control), and every alert will carry a one-click unsubscribe link. We will update this section before any such collection begins.

Section 07b

If you use Ask Unmist (free-form question box on clinic pages)

Every clinic factsheet ends with an Ask Unmist box where you can type a free-form question about that clinic before booking. Here is exactly what happens to your text:

  • Processing. Before any external-model call, Unmist applies rule-based checks. Questions detected as containing personal health information are not sent to OpenAI and receive a local privacy response. Other unresolved free-text questions may be sent over HTTPS to OpenAI only after you agree to that processing. OpenAI processes API inputs under its Data Processing Addendum and does not use them to train its models. Restricted transfers use the safeguards in our current OpenAI DPA and transfer assessment; we do not rely on two transfer mechanisms interchangeably.
  • Storage of text: none. The current Ask Unmist interface does not store your question text or the generated response on our servers or in browser storage.
  • Personal medical information is not stored. Questions detected as mentioning medical conditions, medications, allergies, pregnancy or treatment history (UK GDPR Article 9 special-category data) are blocked locally before an external-model call. Ask Unmist does not answer or retain that health information.
  • Anonymous topic label. When a question is answered we record a single category label from a fixed list (for example “pricing”, “aftercare”, “registration”) together with the clinic page it was asked on — never the question text and never any identifier of who asked. This feeds the aggregate counts described in section 04b (for example “most questions about this clinic concerned pricing”).
  • Rate-limit cookie. A first-party unmist_ask_session cookie stores a pseudonymous browser id and recent question timestamps so we can cap free-form questions at 10 per hour and 30 per rolling 24 hours. The cookie is httpOnly and expires after 30 days. The identifier is pseudonymous personal data, not an anonymous identity.

Lawful basis: performance of a service you requested under UK GDPR Article 6(1)(b) for the generation step. The browser cookie is strictly necessary to provide the requested service safely and enforce its limits. Not medical advice: Ask Unmist never gives clinical recommendations; clinical questions are always deflected to your consultation.

Section 08

Search statistics and publication

Our usage statistics help improve Unmist. We do not publish individual searches or raw event records. Reports for clinics and brands for their own business purposes are disabled in the minimum configuration and require a separate decision before activation.

If clinic reporting is enabled in future, a clinic may receive aggregated reports about the use of its own factsheet: counts with a minimum of ten per cell, and never individual visitor data.

We import aggregate search reports from Google Search Console and Bing Webmaster Tools; they contain no visitor data.

The Unmist Index publishes search categories from completed daily totals of searches handled by our server. Browser interaction beacons are not included in that index. A category is not shown below ten searches in the reporting window. This is a publication threshold, not ten unique people or a guarantee of anonymity. Incomplete coverage is stated and comparisons need complete periods.

Separately, information derived from published clinic sources does not use your browsing activity. Its source rights, accuracy and professional-information safeguards are assessed separately.

You can object to optional statistics using the control below or Global Privacy Control.

Section 09

Data we do NOT collect

For the avoidance of doubt:

  • no advertising analytics, session replay or visitor profiling;
  • no advertising trackers and no ad networks;
  • no advertising, cross-site or stable device fingerprinting; if daily unique counting is enabled, the limited one-day server code and its request inputs are described in Section 04b;
  • no social-media share trackers (our share buttons are link-only);
  • no newsletter and no cross-site cookies; forms collect an email only when you choose to provide one;
  • no health information about you is published or sold; search wording is not stored in usage-statistics records, although the requested URL may appear temporarily in server logs as explained in Sections 03 and 04f.

Section 10

Information we publish about clinics and clinicians

Unmist publishes information that is already publicly available, sourced from the public registers of the General Medical Council (GMC), General Dental Council (GDC), Nursing and Midwifery Council (NMC) and Care Quality Commission (CQC), from clinic websites, and from the public search and map services we use to identify a clinic and find its own website (Section 10b). Where this information includes named clinicians, our lawful basis for processing it is legitimate interest under UK GDPR Article 6(1)(f) — informing consumers considering medical or aesthetic procedures is a recognised public-interest purpose.

We have considered the balance the law requires under Article 6(1)(f). The interest we serve — helping a member of the public who is about to spend money, and accept clinical risk, on a private aesthetic or cosmetic procedure verify what is already on the public record — is a recognised public-interest purpose. The information we surface (regulator listings, the clinic's own published statements, clinicians' own public credentials) is by its nature already public, was placed in the public domain by the clinician or the regulator themselves, and is processed only to the extent necessary to answer a consumer's reasonable question about the source and freshness of those records. We consider that this consumer-protection purpose outweighs the limited additional privacy expectation a regulated professional retains in information they have themselves chosen to publish on a register or a clinic website. Where that balance does not hold for an individual case — for example because a record is wrong, out of date, or no longer public — the corrections and notice-and-takedown routes below put the burden on us to act.

If you are a named clinician or clinic operator and you believe the information we publish about you is inaccurate, out of date, or that we have no lawful basis to publish it, please follow our Notice & Takedown process or write to hello@unmist.co.uk. We respond to all such requests in line with our UK GDPR obligations.

Article 14 (indirect collection): some information we publish about clinicians is collected indirectly — from a public register such as the GMC, or from the clinic’s own website — rather than from the data subject directly. Because notifying each named individual personally would require collecting personal contact details we do not hold (and do not wish to collect), we rely on the disproportionate-effort provision in Article 14(5)(e), (6) and (7). That reliance is supported by a documented internal assessment, and by these safeguards: this public notice, reachable from every factsheet; free, no-account correction and objection channels; and individual assessment of every objection we receive.

Article 21 (right to object): a regulated professional may object to our processing on grounds relating to their particular situation. Every objection is assessed individually, on its own facts, against the legitimate-interest balancing test above — no category of objection is decided in advance, in either direction. Evidence of inaccuracy, out-of-date status, or removal of the source from the underlying public record weighs strongly in favour of the objection; the patient-safety purpose of register verification weighs in favour of retaining accurate, current public-record information. While we assess a serious dispute about accuracy, the contested information is restricted or marked as under review. We respond within one calendar month and record the outcome and reasons.

Section 10a

Temporary clinic verification queue

If a technical limit prevents us from checking a clinic record, we may hold a minimised verification dossier privately in our existing Supabase database for one automatic retry. Its purpose is to check accuracy before publication. It may contain public professional names, qualifications and registration details, clinic information, source links and short evidence excerpts. The lawful basis and correction and objection routes in Section 10 apply. Access is restricted to our authorised administrators and server processes; placing a record in this queue does not publish it or confirm its claims.

The dossier is valid for 24 hours from its original completion, and a retry does not extend that period. The temporary dossier is cleared on completion or replacement, or during the next queue maintenance after expiry or a failed worker lease. If maintenance is interrupted, clearing waits for its next run; expired dossiers cannot be retried. This expiry applies to the temporary retry copy. Separate verification audit records and processor backups follow their applicable retention arrangements and are not erased by this queue cleanup.

Section 10b

Background extraction services we use to build clinic factsheets

To build a factsheet, Unmist programmatically reads each clinic’s own public website and a small number of public registers. Most of this work is done from our own servers. Some pages are JavaScript-rendered and require specialist services to fetch the rendered content; other steps use third-party APIs we do not run ourselves. Apart from Near me searches (Section 04f) and Ask Unmist (Section 07b), none of these services process personal data about visitors to Unmist — they process public information about clinics and clinicians on our behalf as data processors under Article 28 UK GDPR.

  • Google Maps Platform (Places API) — used only for clinics that are not in our catalogue, to identify a clinic’s name, address and map location, and for nearby-clinic search (including the approximate Near me point described in Section 04f). We keep only Google’s place identifier. We do not display or store Google ratings, reviews, opening hours or contact details. US-based. Google privacy policy. Transfer mechanism: UK adequacy decision for the US (UK-US Data Bridge) and Google’s Standard Contractual Clauses.
  • OpenAI (gpt-4o-mini) — used for two things: (a) parsing a clinic’s website to extract practitioner names when the regex pass is thin, and (b) generating Ask Unmist responses (see Section 07b). US-based. Operates under the OpenAI Data Processing Addendum, which incorporates EU/UK Standard Contractual Clauses (Module Two — Controller to Processor) by reference. API inputs are NOT used to train OpenAI models. See OpenAI DPA and sub-processor list.
  • Brave Search API — used to find a clinic’s own website when we do not already have it, and, where enabled, to look for UK editorial press mentions and published Advertising Standards Authority (ASA) rulings about a clinic. Press coverage on free factsheets is shown as not yet checked. The only data we send to Brave is the public clinic name, sometimes with its town or area. The data returned is already in Brave’s public search index; for press we keep only the matched outlet name and a hit count, never the underlying article text. US-based, processes under the Brave Search API Terms of Service; no visitor data is sent. Brave privacy policy.
  • Apify — retired Jun 2026. Apify was previously used to retrieve public Instagram tagged-feed content to derive the marketing-footprint composition on each factsheet. That pipeline has been fully retired and replaced by the Brave Search API listed above. The previous DPIA on Instagram processing has been archived; the current DPIA on the Brave Search pipeline is at docs/dpia-brave-search.md in our internal repository and is available on request.
  • Steel — optional headless-browser rendering fallback. Used only when a clinic’s site is JavaScript-rendered and our static fetch cannot read it (Squarespace, Wix, React app shells). When enabled, we send the page URL to Steel and receive back the fully-rendered HTML. US-based (privacy policy). Transfer mechanism: UK adequacy decision for the US (UK-US Data Bridge) and Standard Contractual Clauses where applicable.

Background extraction is separate from visitor use: when these services are used to build clinic factsheets, they do not receive your browser identifier or your activity on Unmist. They receive only the public clinic material needed for that extraction (for example a clinic name, location, public page URL or cleaned public-page text). Ask Unmist is a separate visitor-initiated use of OpenAI and is described in Section 07b.

Section 10d

Supabase and Resend — infrastructure for leads, requests and notifications

Two further processors handle a small amount of personal data on our behalf, separate from the clinic-factsheet pipeline in Section 10b above:

  • Supabase — our database provider. It stores: clinic enquiries submitted via /for-clinics (Section 06b), requests to check a new clinic via /not-found-clinic (Section 06), anonymous booking-CTA click counts (Section 04b), and the temporary clinic verification queue (Section 10a). Some of this is personal data (an email address, a contact name, free-text notes you typed); some is aggregate activity data (click counts). Public form records do not retain an IP hash or raw user-agent. Supabase privacy policy.
  • Resend — our transactional email provider. When you submit a form that triggers an internal notification (e.g. a lead via /for-clinics, a new clinic request), Resend processes the email content and the recipient/sender address metadata needed to deliver that notification to us. Resend does not email you directly — these are internal alerts only. Resend privacy policy.

Lawful basis: the same basis as the underlying activity each record relates to (see Sections 06, 06b, 07 and 07b for the specific basis and retention of each). Recipients: Supabase and Resend act as data processors under Article 28 UK GDPR — they do not use this data for their own purposes.

Section 06b

Lead enquiries from clinics (/for-clinics)

The /for-clinics page carries a waitlist and enquiry form for clinics. Paid features are not on sale yet: sending the form puts you on the Verified waitlist or sends us your question, and nothing is charged. It collects the clinic name, contact name, email, website, area of interest, and any notes you choose to add. The request record does not retain your IP address, an IP-derived identifier or your browser user-agent.

Lawful basis: legitimate interest under UK GDPR Article 6(1)(f) — responding to a commercial enquiry you initiated. Purpose: to reply to your enquiry about the Verified tier. Not used for marketing beyond that correspondence. Retention: kept for as long as needed to handle the enquiry and a reasonable follow-up window (up to 12 months), then deleted unless you become a Verified subscriber (in which case ordinary business-record retention applies). Recipients: only Unmist, via Supabase (storage). Resend sends Unmist a minimised alert containing the internal record number and admin link, not the submitted name, email, location, treatment or notes — see Section 10d.

Section 06c

Factsheet claim requests (/claim)

The /claim page helps a clinic representative prepare an email to Unmist. The form collects the clinic name, your role, name, email, optional phone number and any optional note you add. Submitting the form opens a draft in your own mail application; the website does not transmit or store the form contents. Unmist receives them only if you choose to send that email.

Lawful basis: legitimate interest under UK GDPR Article 6(1)(f) — verifying authority to manage a business factsheet and responding to the request you initiated. Purpose: to verify the claimant and handle the requested clinic-factsheet update. Retention: claim correspondence is kept only as long as needed to verify and administer the claim and a reasonable follow-up window (normally no more than 12 months), unless it becomes part of an ongoing subscriber or business record. Recipients: Unmist and the email providers used by you and Unmist to deliver the message. Do not include patient names, medical history, symptoms, medication, treatment records or other health information.

Section 10c

Instagram processing — retired Jun 2026 (historical)

Status: retired. Up to June 2026 Unmist ran a periodic scrape of the public Instagram tagged-feed of each clinic to derive the marketing-footprint composition shown on the factsheet. That pipeline has been fully decommissioned. Factsheets no longer use Instagram data; press coverage on free factsheets is shown as not yet checked, and the Meta Ad Library appears only as a link-out. See Section 10b for the current data sources.

Historical disclosure. If you are an Instagram account holder and want to know what we held about you during the period the pipeline was active, please use the Notice & Takedown route — we will confirm in writing whether any record relating to your handle survived the retirement and, if so, delete it immediately.

Section 11

International data transfers

Our hosting provider Vercel (US-based) processes server-side request logs as described in Section 03 above and stores all our static content. Vercel operates under its own DPA (link), incorporating the UK International Data Transfer Addendum and the UK Extension to the EU-US Data Privacy Framework (the UK-US Data Bridge) as transfer mechanisms. Google, OpenAI, Brave and Steel (all US) are the other US-based recipients; the transfer mechanism for each is listed in Section 10b (for OpenAI, the safeguards in its Data Processing Addendum, as described in Section 07b). See Section 10b for the full list of background processors and their disclosed transfer mechanisms.

Supabase and Resend (Section 10d) may process data on infrastructure located outside the UK/EEA depending on their hosting configuration. Some providers may process data outside the UK/EEA using appropriate safeguards such as standard contractual clauses or equivalent mechanisms. We do not transfer data to any other third country beyond the processors named in this policy.

Section 12

Your rights under UK GDPR

You have the right to:

  • be informed about how we process your data (this page);
  • access a copy of any personal data we hold about you;
  • have inaccurate data corrected;
  • have data erased where there is no overriding lawful reason to keep it;
  • restrict our processing in certain circumstances;
  • object to processing based on legitimate interest;
  • data portability where applicable;
  • lodge a complaint with the UK Information Commissioner's Office at ico.org.uk/make-a-complaint if you believe we have mishandled your data.

To exercise any of these rights, write to hello@unmist.co.uk. We normally respond to a data-rights request within one calendar month, subject to the legal rules on extensions and clarification. You may also make a data-protection complaint to us at that address; we acknowledge complaints within 30 days and investigate and respond without undue delay. This does not limit your right to complain to the ICO.

Section 13

Security

The site is served over HTTPS. Administrative access to the site is protected by password authentication. We do not intentionally request or use special-category visitor data. Public forms warn users not to enter patient or medical information. If we become aware that such information has been submitted, we restrict access and delete it where appropriate. Ask Unmist applies an automated check designed to stop detected personal health information before any external-model call and does not intentionally retain question text. No automated detector is perfect: do not enter medical history, medication, allergy, pregnancy or other patient information (section 07b). We do not run any system that processes payment information.

Section 14

Changes to this policy

When we update this policy we will change the "last updated" date at the top of the page. Material changes will be flagged on the homepage. The current version is always the one displayed at this URL.

Section 15

Governing law and jurisdiction

This Privacy Policy and any dispute or claim arising out of or in connection with it (including non-contractual disputes or claims) is governed by, and construed in accordance with, the law of England and Wales. Courts with jurisdiction under applicable law may hear any such dispute. Nothing in this paragraph removes mandatory consumer or data-protection rights, including the right to complain to the UK Information Commissioner’s Office or, where applicable, a supervisory authority in your country of residence.