NHS DSPT Compliance for AI Clinical Documentation: A Complete Guide for IT Directors

As NHS Trusts, ICBs, and GP federations accelerate their adoption of ambient AI scribing tools, one compliance requirement sits at the gateway of every procurement decision: the Data Security and Protection Toolkit. Platforms like Scribing.io that provide AI clinical documentation for healthcare settings must navigate this framework rigorously — and so must the organisations that deploy them.

This guide is written specifically for IT directors responsible for evaluating, procuring, and governing AI clinical documentation tools within NHS environments. Whether you are conducting due diligence on a new AI scribe vendor or preparing your own organisation's DSPT submission to reflect a newly deployed tool, the content below maps every DSPT assertion to the practical realities of ambient voice technology, clarifies the shared responsibility model between supplier and adopter, and provides a step-by-step evidence-gathering framework. Scribing.io's platform architecture is referenced throughout as a concrete example of how compliance-ready AI documentation works in practice.

TL;DR

NHS organisations deploying AI clinical documentation tools must ensure both the supplier and the adopting organisation meet DSPT requirements — a non-negotiable element of the broader compliance stack that also includes DTAC, DCB0129/DCB0160, Cyber Essentials Plus, and (for summarising tools) MHRA medical device registration. This guide breaks down exactly what the DSPT demands from AI scribe vendors and the IT directors who procure them, maps each DSPT assertion to the practical realities of ambient voice technology, and provides an actionable evidence-gathering framework.

Contents

• What Is the NHS DSPT and Why Does It Matter for AI Clinical Documentation?

• DSPT Assertion-by-Assertion Breakdown for AI Scribe Deployments

• Supplier vs. Adopter — Who Is Responsible for What?

• Step-by-Step Evidence-Gathering Framework

• Common DSPT Pitfalls When Deploying AI Scribes

• How Scribing.io Supports NHS DSPT Compliance

• Get Started Today

What Is the NHS DSPT and Why Does It Matter for AI Clinical Documentation?

The Data Security and Protection Toolkit (DSPT) is an online self-assessment tool managed by NHS England that allows organisations to measure their performance against the National Data Guardian's 10 data security standards. Every organisation that processes NHS patient data — whether it is an NHS Trust, a GP practice, a commissioning body, or a third-party IT supplier — must complete and publish an annual DSPT submission to demonstrate baseline compliance.

For AI clinical documentation, the stakes are significantly elevated. AI scribes process special category data under Article 9 of UK GDPR in real time: audio recordings of patient consultations, machine-generated transcripts, clinical summaries produced by large language models, and coded entries written back to the electronic patient record. This data pipeline is materially more complex — and more risk-laden — than a standard SaaS deployment.

The Dual Obligation

A critical point that many IT directors underestimate: DSPT compliance for AI scribing is a dual obligation. Both the AI scribe supplier and the adopting NHS organisation must hold a current, published DSPT submission. NHS England's April 2025 guidance on ambient scribing makes this explicit, stating that suppliers must "comply with the Data Security and Protection Toolkit (DSPT), as well as Cyber Essentials Plus certification." The adopting organisation, meanwhile, must update its own submission to reflect the new data flows, sub-processors, and risk vectors introduced by deploying an AI tool.

Where DSPT Sits in the NHS AI Compliance Stack

DSPT is necessary but not sufficient. It forms the baseline of a broader compliance architecture. IT directors must understand the full stack before signing off on any AI clinical documentation procurement:

The DSPT is the gatekeeping mechanism — without it, none of the subsequent assessments proceed. This is why NHS England's CIO and CCIO communities treat it as the first filter in AI procurement decisions.

DSPT Assertion-by-Assertion Breakdown for AI Scribe Deployments

The DSPT's mandatory assertions map directly onto the risk surface of an AI clinical documentation tool. Generic compliance guides treat these assertions abstractly. Below, each assertion theme is translated into what it specifically means when the system under assessment is an ambient AI scribe capturing, processing, and writing patient data.

A) Leadership and Governance

The DSPT requires a named data security lead and senior-level accountability for information governance. For AI scribe deployments, governance must explicitly cover AI model risk — including LLM drift, unintended output generation, and the risk that generative AI introduces clinical functions beyond its intended purpose. NHS England's ambient scribing guidance warns against this scope creep explicitly.

Required evidence: Board or governance meeting minutes referencing AI scribe risk; a named Clinical Safety Officer (CSO) appointed per DCB0129/DCB0160; documented terms of reference for any AI governance committee or subgroup.

B) Staff Training and Awareness

All staff handling patient data must complete information governance training annually. For AI scribes, this extends to product-specific training: clinicians and administrative staff need structured education on reviewing AI outputs, understanding when the tool may hallucinate or omit information, and how to report errors. NHS England's guidance explicitly requires training on "appropriate dictation regarding voice and words used" and makes clear the "ongoing responsibility for practitioners to review and revise the outputs."

Required evidence: Training completion records for IG and product-specific modules; documented clinician sign-off acknowledging output review responsibility. Organisations using AI scribes in primary care should ensure GP trainees and locums receive the same training as permanent staff.

View Scribing.io Pricing

C) Data Security and Protection Processes

This is the DSPT's heaviest assertion theme for AI scribes. A DPIA must address every stage of the data pipeline: audio capture from the consultation room, transcript generation (including whether speech-to-text occurs on-device or in-cloud), temporary data storage during LLM inference, whether data transits to a third-party model provider, data residency (which jurisdiction hosts the processing infrastructure), retention and deletion policies for audio files and transcripts, and whether patient data is ever used for model retraining.

The lawful basis for processing must be clearly documented. Most NHS AI scribe deployments rely on Article 6(1)(e) (public task) paired with Article 9(2)(h) (health care purposes), but this must be confirmed by the organisation's Data Protection Officer, not assumed.

Required evidence: Completed DPIA; data flow diagrams showing audio → transcript → summary → EPR write-back; data processing agreements with all sub-processors; records of processing activities under Article 30 UK GDPR.

D) Access Control and Privileged Access

Role-based access control, joiner/mover/leaver processes, MFA enforcement, and privileged account separation. For AI scribe platforms, the key questions are: Who can access raw audio recordings? Who can access transcripts before clinician review? Are API keys to the LLM provider tightly scoped with least-privilege principles? How are administrative accounts for the AI scribe platform managed and audited?

Required evidence: RBAC configuration documentation; access review logs (quarterly minimum); MFA enforcement records across all accounts including service accounts; API key rotation policy.

E) Incident Reporting and Response

The DSPT requires mechanisms for reporting breaches and near misses, with evidence of organisational learning. AI scribe deployments introduce novel incident types that traditional IG frameworks do not anticipate: a summary that omits a critical finding, a hallucinated diagnosis, or a data leak to a model provider. Incident response plans must explicitly cover these scenarios and integrate with the Learn from Patient Safety Events (LFPSE) service and Yellow Card reporting for medical devices where applicable.

Required evidence: Incident response plan explicitly covering AI output errors; tabletop exercise records; post-incident review documentation.

F) Business Continuity and Disaster Recovery

Tested DR plans with documented recovery time objectives. The AI scribe-specific dimension: what happens when the tool is unavailable? Clinicians must have a documented fallback workflow — typically reverting to manual note-taking or dictation. DR testing must include scenarios where the LLM provider is unreachable or returns degraded outputs, not just scenarios where the scribe platform itself is offline.

Required evidence: DR test records (at least annual); clinician fallback procedure documentation; RTO and RPO metrics for the AI scribe service.

G) Vulnerability and Patch Management

Regular scanning, risk-based prioritisation, and defined patching timelines. For AI scribes, this extends to the AI model supply chain: prompt injection vulnerabilities, adversarial attacks on the LLM, and API security. NHS England's guidance warns that "AI-enabled systems can introduce unique security challenges" including "indirect prompt injection attacks." Penetration testing must be CREST-certified and must include the AI-specific attack surface.

Required evidence: CREST penetration test reports; vulnerability scan outputs; patch management logs including model update versioning.

H) Network Security and Supplier Management

Firewall management, network segmentation, and a complete supplier register. The supplier register must include every entity in the AI scribe data chain: the LLM provider (if the foundation model is hosted by a different company than the scribe vendor), the cloud infrastructure provider, any audio processing sub-processor, and any EPR integration middleware. This level of supply chain transparency is non-negotiable and frequently incomplete in early-stage AI scribe vendors.

Required evidence: Supplier register with all AI scribe sub-processors identified; firewall rule reviews; data flow architecture diagrams showing all network boundaries and data transit paths.

Summary Matrix: DSPT Themes Mapped to AI Scribe Risks

Supplier vs. Adopter — Who Is Responsible for What?

The shared responsibility model for AI clinical documentation DSPT compliance is where confusion most frequently derails procurement timelines. The AI scribe vendor submits their own DSPT as a Category 2 IT supplier. The NHS organisation submits theirs as a health or care organisation. But the responsibilities overlap and interlock in ways that demand explicit contractual clarity.

What the Supplier Must Own

• Platform security: Encryption at rest and in transit, infrastructure hardening, penetration testing, vulnerability management, and patch cycles for the AI scribe application and its underlying model pipeline.

• Sub-processor transparency: A complete, maintained register of every third party that touches patient data — including LLM providers, cloud hosts, and audio transcription services.

• DCB0129 clinical safety case: A hazard log and clinical risk management report maintained by the supplier's Clinical Safety Officer.

• Data processing agreement: A UK GDPR-compliant DPA that explicitly addresses audio data, transcript data, and LLM inference data, including clear commitments on data residency, retention, and non-use for model training.

• DSPT submission as "Standards Met": Published annually and verifiable on the DSPT portal.

What the Adopting Organisation Must Own

• DPIA for the local deployment: The supplier's DPIA covers their platform. The adopting organisation needs its own DPIA covering local data flows — how audio enters the system from the consultation room, who reviews outputs, how summaries are imported into the local EPR (whether that is Epic or another system), and how patient consent or privacy notices are managed.

• DCB0160 clinical risk management: The deploying organisation must appoint its own CSO, maintain a local hazard log, and assess risks specific to how the tool will be used in its clinical environment.

• Staff training: Ensuring every clinician and support staff member who interacts with the AI scribe has completed both annual IG training and product-specific training.

• Ongoing monitoring: Regular audits of AI output quality, error reporting uptake, and user compliance with review workflows.

• Updating the organisation's own DSPT submission: Reflecting the new AI tool in the organisation's data flow maps, supplier register, DPIA register, and risk assessment documentation.

Try Scribing.io Free

The Contractual Bridge

The data processing agreement is the contractual mechanism that formalises this split. IT directors should insist on seeing the supplier's DPA before any proof-of-concept begins — not as a post-procurement afterthought. Key clauses to scrutinise include: data deletion timelines after contract termination, audit rights (can the NHS organisation inspect the supplier's infrastructure?), breach notification timelines (the ICO requires 72 hours; best-practice DPAs should commit to notifying the controller within 24 hours), and explicit confirmation that patient data is never used for model training or improvement without separate, documented consent.

Step-by-Step Evidence-Gathering Framework

For IT directors preparing to either procure an AI scribe or update their DSPT submission post-deployment, the following framework organises the work into manageable phases:

Phase 1: Pre-Procurement Due Diligence

1. Verify the supplier's DSPT status on the DSPT portal. Confirm the status is "Standards Met" (not "Standards Not Met" or "Approaching Standards").

2. Request the supplier's Cyber Essentials Plus certificate — check it is current and covers the AI scribe product, not just a parent company.

3. Request the supplier's DCB0129 clinical safety case report and hazard log. Review it for AI-specific hazards (hallucination, omission, latency-induced data loss).

4. Review the supplier's data flow architecture — insist on a diagram showing every data transit point, every sub-processor, and every jurisdiction involved.

5. Assess MHRA status — if the tool generates clinical summaries or suggests ICD-10 codes (as some platforms do), it may meet the definition of a medical device. Ask the supplier for their regulatory classification rationale.

Phase 2: DPIA and Local Risk Assessment

1. Commission a local DPIA involving the DPO, Caldicott Guardian, CCIO, and clinical leads from the departments that will pilot the tool.

2. Map local data flows — from consultation room microphone to EPR entry, including any intermediary storage, network paths, and user touchpoints.

3. Conduct a DCB0160 clinical risk assessment — appoint the organisation's CSO, hold a hazard workshop, and produce a local hazard log.

4. Document the lawful basis for processing — confirm with the DPO whether Article 6(1)(e) and Article 9(2)(h) apply, and update privacy notices accordingly.

Phase 3: DSPT Submission Update

1. Update the organisation's asset register to include the AI scribe platform.

2. Update the supplier register with the AI scribe vendor and all identified sub-processors.

3. Update the DPIA register to include the AI scribe DPIA.

4. Ensure training records reflect product-specific AI scribe training for all relevant staff.

5. Document fallback procedures in the business continuity plan.

6. Publish the updated DSPT submission by the annual deadline (typically 30 June).

Common DSPT Pitfalls When Deploying AI Scribes

Based on patterns observed across NHS AI adoption programmes, several recurring mistakes undermine DSPT compliance:

• Treating the supplier's DSPT as sufficient: The supplier's "Standards Met" status does not discharge the adopting organisation's obligation. Both must comply independently.

• Ignoring the sub-processor chain: If the AI scribe vendor uses a third-party LLM (which many do), that LLM provider must appear on the supplier register and be covered by a DPA. IT directors should ask: "Does patient data leave your infrastructure at any point during inference?"

• Conflating DTAC with DSPT: DTAC is a separate assessment. A product listed on the NHS Digital Health Technology Catalogue may have passed DTAC but that does not mean the deploying organisation's own DSPT submission is compliant.

• Omitting audio data from the DPIA: Many DPIAs focus on the text output (the clinical note) and fail to address the audio recording — its capture method, encryption standard, retention period, and deletion mechanism. Audio is the most sensitive data element in an AI scribe deployment.

• Failing to plan for model updates: When the LLM underpinning the AI scribe is updated (which may happen without direct notification from the vendor), clinical outputs may change. The risk is particularly acute in specialties where nuanced language matters. DSPT's change management assertions require documented processes for evaluating such updates.

How Scribing.io Supports NHS DSPT Compliance

The architecture and compliance posture of Scribing.io are purpose-built to support NHS organisations through every DSPT assertion. While no vendor can guarantee an adopter's compliance — that remains the organisation's responsibility — the platform is designed to make the supplier side of the shared responsibility model as transparent and evidence-rich as possible.

• Sub-processor transparency: Scribing.io maintains and publishes a complete sub-processor register, including the LLM provider, cloud infrastructure host, and any audio processing component. IT directors can access this during pre-procurement due diligence.

• Data residency controls: The platform supports data residency configurations that align with NHS requirements for UK-based processing, a critical DSPT and UK GDPR consideration.

• No model retraining on patient data: Patient consultation data processed through Scribing.io is never used to retrain or fine-tune foundation models — a contractual commitment documented in the DPA.

• RBAC and audit logging: Granular role-based access controls with comprehensive audit trails support the access control assertions in both the supplier's and adopter's DSPT submissions.

• EPR integration support: Direct integration pathways with NHS EPR systems — including those covered in guides for Athenahealth and other platforms — reduce the number of intermediary data transit points, simplifying data flow diagrams and reducing risk surface.

• Clinician review workflow: Every AI-generated note passes through a mandatory clinician review step before EPR write-back, directly supporting the NHS England requirement that practitioners retain "ongoing responsibility to review and revise outputs."

For organisations navigating regulatory requirements across multiple jurisdictions, Scribing.io's compliance team provides deployment-specific guidance tailored to the regulatory environment.

Get Started Today

Meeting DSPT requirements for AI clinical documentation is not a checkbox exercise — it demands genuine alignment between your organisation's information governance posture and the technical architecture of the tool you deploy. Scribing.io is built to make that alignment straightforward, with the sub-processor transparency, data residency controls, and clinical safety documentation that NHS IT directors need to move from evaluation to deployment with confidence.

Start Your Free Trial — No Credit Card Required