GDPR Compliance for Dental Software in the UK

Why dental software is high-risk for GDPR

Dental records are special category (health) data under UK GDPR Article 9. You need two things to process them: an Article 6 lawful basis (commonly public task for NHS care, or legitimate interests or contract for private care) and an Article 9 condition (usually Article 9(2)(h), health or social care, which in the UK is met through the Data Protection Act 2018, Schedule 1, paragraph 2). Consent is not usually the right basis for routine care. Security expectations are higher, and so are the consequences of a breach.

Every dental software application that processes patient identifiable data — PMS (Dentally, SOE Exact, R4), notes apps, AI scribes, patient communication tools (SMS, email), online booking, social media schedulers handling patient enquiries — falls under this regulatory regime. You as practice owner are the Data Controller. Every vendor is a Data Processor.

The Data Processing Agreement (DPA)

A written Data Processing Agreement is legally required between you (Controller) and any third party (Processor) handling patient data on your behalf. UK GDPR Article 28(3) and (9) require a written contract with every processor.

• Identifies what data is processed
• Specifies the lawful basis and purpose
• Lists sub-processors (the vendor's third parties — AI providers, hosting, etc.)
• Documents security measures (encryption, access controls, training)
• Defines breach notification timeline (vendor to you within 24-72h)
• Sets data retention and deletion procedures
• Confirms data location (UK/EEA or valid transfer mechanism)

Patient consent for dental software

Most dental data processing relies on the Article 9(2)(h) health or social care condition, together with an Article 6 lawful basis, rather than consent. This means routine PMS and notes app use doesn't require explicit patient consent, but your privacy notice must tell patients the purposes and the lawful basis (UK GDPR Article 13(1)(c)).

AI scribes that record patient speech need particular care. Tell patients, in your privacy notice and before recording starts, that the consultation will be recorded: transparency is required whatever your lawful basis (UK GDPR Articles 5(1)(a), 13 and 14). Whether you also need explicit GDPR consent depends on the basis you rely on; many providers rely on Article 9(2)(h). GDPR consent is separate from clinical consent to treatment.

Data Protection Impact Assessment (DPIA)

Run a Data Protection Impact Assessment (UK GDPR Article 35) before adopting any tool that processes health data with new technology, including AI: the ICO's list of high-risk processing requires one where innovative technology is combined with sensitive data such as health records. Record the data flows, the risks and your mitigations.

Data location: UK, EEA, or international?

Where the data physically sits matters. UK GDPR allows transfer to:

• UK or EEA: covered by UK adequacy regulations, no extra mechanism needed
• Other countries with UK adequacy regulations (for example the Republic of Korea): no extra mechanism needed
• USA: the UK Extension to the EU-US Data Privacy Framework (the "UK-US data bridge", in force since 12 October 2023) covers transfers to US organisations certified under it
• Anywhere else, or a US recipient that is not certified: the ICO's International Data Transfer Agreement (IDTA) or the UK Addendum to the EU Standard Contractual Clauses, plus a transfer risk assessment. The EU SCCs on their own are not valid for UK transfers

Many AI scribes use US-based AI providers (OpenAI, Anthropic). That can be lawful under one of the routes above. Ask vendors: "Where is patient data processed and stored? What's your transfer mechanism for non-UK/EEA processing?"

Security expectations

UK GDPR Article 32 requires "appropriate technical and organisational measures." For healthcare-grade software, expect:

• Encryption in transit (TLS 1.2+) AND at rest (AES-256)
• Multi-factor authentication for user accounts (ask whether every user can turn it on today)
• Role-based access controls
• Audit logging of access to patient data
• Independent security assurance, for example Cyber Essentials, ISO 27001 or SOC 2. None is legally required, but they help evidence your due diligence; ask how the vendor meets Article 32 either way
• Annual or more frequent penetration testing
• Vulnerability disclosure programme
• Incident response plan with breach notification process

Breach notification — your 72-hour obligation

If your dental software suffers a breach involving patient identifiable data, you have 72 hours from awareness to notify the ICO. Late notification compounds the regulatory consequence. The vendor's DPA should require them to notify you immediately (typically 24-48h) so you can meet your own deadline.

What changed in 2026: the Data (Use and Access) Act 2025

The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025, and most of its data protection changes came into force on 5 February 2026. UK GDPR still applies; the Act amends it. The changes a dental practice is most likely to meet:

• Subject access requests: you must make a reasonable and proportionate search, not an unlimited one. If you ask the patient to clarify the request, the one-month time limit pauses until they reply ("stopping the clock").
• Automated decisions: the Act widens the lawful bases you can rely on for significant automated decisions, as long as safeguards stay in place. This does not extend to special category data such as health records, which remain more protected.
• Complaints: controllers must help people complain about how their data is used (for example with an electronic form), acknowledge complaints within 30 days and respond without undue delay. GOV.UK expected this duty to start about 12 months after Royal Assent; check the ICO guidance for the current position.

The pragmatic GDPR checklist for dental practices

1. Maintain a register of all software processing patient data (PMS, notes app, AI scribe, communications, booking).
2. Have a written DPA with every vendor on that list. No DPA = stop using until obtained.
3. Confirm UK/EEA data location OR valid transfer mechanism for each.
4. Ask each vendor what independent assurance it has (for example Cyber Essentials, ISO 27001 or SOC 2) and how it meets UK GDPR Article 32. None is legally required, but they help evidence due diligence. Record the answers (Nosht's own position is stated below).
5. Update privacy notice to list all data processors and your lawful basis for each.
6. Tell patients before any AI scribe records them, and record the lawful basis and Article 9 condition you rely on.
7. Run a DPIA before adopting AI or any other new technology that processes patient data.
8. NHS contract holders in England: complete the Data Security and Protection Toolkit (DSPT) each year.
9. Train staff annually on data handling, breach recognition, and reporting procedures.
10. Test breach response process annually — table-top exercise.
11. Verify backup + deletion processes meet your retention policy.
12. Review the data register annually and on adding any new software.

Sources and scope of this guide

This is general information about UK data protection, not legal advice. Sources checked on 30 September 2026:

• UK GDPR Articles 5, 6, 9, 13, 14, 28, 35, 58 and Chapter V: legislation.gov.uk/eur/2016/679
• Data Protection Act 2018, Schedule 1 para 2 and section 157: legislation.gov.uk/ukpga/2018/12
• UK-US data bridge, SI 2023/1028: legislation.gov.uk/uksi/2023/1028
• ICO guidance on special category data, DPIAs and international transfers: ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources
• ICO data protection fee, including the 17 February 2025 changes: ico.org.uk/for-organisations/data-protection-fee
• NHS England Data Security and Protection Toolkit: dsptoolkit.nhs.uk
• Data (Use and Access) Act 2025: plans for commencement (GOV.UK, updated 5 February 2026): gov.uk/guidance/data-use-and-access-act-2025-plans-for-commencement
• ICO, The Data (Use and Access) Act 2025: what does it mean for organisations, and A guide to subject access (updated 16 July 2026): ico.org.uk

Where Nosht fits

Nosht is designed to minimise the patient data it holds, and no audio is captured. Your clinical notes hold no patient identifiers — only clinical descriptors. There are two exceptions, both optional: the Referral Letter template, where you choose to enter patient details (name and date of birth, with NHS number, address and contact optional); and Send Leaflet, which processes a patient's email address or mobile number solely to deliver a patient information leaflet. Drafts and saved notes, including any referral-letter details you enter, are stored in Nosht's database (Supabase, London, UK) so you can resume, audit and retrieve them; patient details can also be entered in the optional short label you give a note. Nosht is therefore a data processor for your practice: sign its data processing agreement (nosht.io/dpa/) and list Nosht and its sub-processors (below) in your record of processing.

Compliance posture: ICO-registered Data Controller (ZC186303) for Nosht's own data. Database in London, UK (Supabase); hosting and functions on Netlify (US); optional AI via Anthropic (US, no model training); leaflet email and SMS via Resend and Twilio (US). Encrypted at rest and in transit. Nosht does not yet offer multi-factor authentication for user accounts. Nosht does not currently hold Cyber Essentials certification; Supabase and Stripe hold their own. Sub-processors: nosht.io/security/.