Compliance briefing
Data Protection Impact Assessment
Holdfast's self-assessed DPIA, structured against the UK Information Commissioner's Office (ICO) methodology, covering personal data - including special category health data - processed on behalf of an NHS Trust or Integrated Care Board.
This is a self-assessment written by the product team, not an independently verified or legally binding determination. A DPIA is, by its nature, meant to be reviewed, challenged, and where necessary revised by the data controller (the commissioning NHS Trust/ICB) and their Data Protection Officer before the processing described here begins for real patient data. This page states plainly, throughout, what is implemented today versus what remains outstanding, so it can be independently verified rather than taken on trust.
Product one-liner: Holdfast is a digital check-in and risk-monitoring tool for NHS Trust/ICB mental health waiting lists. Patients complete short structured check-ins while they wait; each check-in is scored against explainable, rules-based clinical safety criteria; scores above threshold auto-escalate to a named support worker or clinician, with every state change written to an audit trail.
Step 1
Identify the need for a DPIA
A DPIA is required because the processing described in this document involves:
- Special category data (UK GDPR Article 9): health data, including direct disclosures of self-harm risk and ideation, mental health questionnaire scores, and diagnostic/referral pathway information.
- Systematic monitoring of individuals over an extended period (the full duration of a waiting list wait, potentially months).
- Automated decision-support logic that influences which member of staff is alerted and how quickly, based on personal data (though never a decision made about an individual without human involvement - see Step 4).
- Large-scale processing potential: the platform is designed to serve every person on a Trust/ICB's mental health waiting list, which for a mid-sized service can be several thousand people at any one time.
- Data concerning vulnerable individuals: people awaiting mental health treatment, including children and young people (via a parent/carer login) on CAMHS pathways.
Each of these independently triggers the ICO's criteria for "likely high risk" processing, so a DPIA is mandatory before this processing begins, and must be reviewed and re-approved by each deploying organisation's own Data Protection Officer as part of their local governance, not solely relied upon from this document.
Step 2
Describe the processing
Nature of the processing
Holdfast is used by NHS Trusts/ICBs (and voluntary-sector organisations commissioned to deliver waiting-list support on their behalf) as a data processor, acting under instruction from the Trust/ICB as data controller, unless a specific commissioning arrangement states otherwise. Each Trust/ICB is expected to complete its own local DPIA and confirm the controller/processor relationship, retention schedule, and data-sharing basis with Holdfast in a written Data Processing Agreement before go-live - this document is the evidence base that agreement would draw on, not a substitute for it.
The system collects short structured check-ins and standard NHS-used clinical questionnaires from patients on a recurring schedule chosen by the service (e.g. weekly or fortnightly), scores each one against a fixed, deterministic, published rule set, and - where a response crosses a risk threshold - notifies a named support worker or clinician so a human can act. Staff use a caseload view to see and prioritise the people they are responsible for. Commissioners (where enabled) see only aggregate, non-identifiable reporting.
Categories of data subject
- Patients - adults and children/young people referred into a mental health, ADHD, autism, eating disorder, perinatal, older adult, or trauma pathway and placed on a waiting list.
- Carers - a parent or carer given a scoped login to complete carer-perspective instruments on behalf of a child or dependent patient.
- Staff - support workers, clinicians, administrators, commissioners, and clinical safety officers employed or contracted by the Trust/ICB or a commissioned provider.
Categories of personal data processed
| Category | Examples | Special category? |
|---|---|---|
| Identity and contact data | Name, date of birth, NHS number, phone number, email address | NHS number is not itself special category, but is treated with equivalent sensitivity as a unique health-service identifier |
| Referral and pathway data | Referral date, clinical pathway, referring service, team assignment | Special category (health) |
| Check-in and questionnaire responses | Mood, sleep, coping, self-harm risk disclosure, PHQ-9/GAD-7/CORE-10 and other validated instrument scores | Special category (health) |
| Free-text responses | Patient's own words describing how they are doing | Special category (health); may also incidentally reveal other special category information volunteered by the patient |
| Risk assessment outputs | Automatically generated Red/Amber/Green rating and the named rules that produced it | Special category (health) - derived data |
| Safety plan content | Warning signs, coping strategies, named personal and professional contacts | Special category (health) |
| Escalation and response records | Who was notified, when, response time, outcome | Special category (health), as it relates to a specific patient's care |
| Optional equity-monitoring data | Ethnicity, gender identity, age band | Special category, collected only under a separate explicit consent and only where a Trust has opted into equity reporting |
| Staff account data | Name, email, role, team/organisation membership, login activity | Not special category |
| Audit and security telemetry | Every record change, every login success/failure, IP-level rate-limit events | Mixed - audit entries referencing patient records inherit that record's special-category status |
Volumes and duration
Designed to serve an entire Trust/ICB mental health waiting list on a continuous basis - potentially several thousand active patients per deployment at any time, each generating a recurring stream of check-ins for as long as they remain on the waiting list (typically weeks to many months). Data is not processed as a one-off snapshot; it accumulates for the duration of the person's wait and is retained afterward as part of the clinical/audit record (see the retention note below).
Recipients and sharing
- Within the deploying organisation: staff see only the patients on their own team's caseload (support workers/clinicians) or, for administrator/clinical safety officer/commissioner roles, organisation-wide aggregate or audit views appropriate to that role. Commissioners are deliberately restricted to aggregate reporting only and never see identifiable patient records.
- Between organisations: never. Each NHS Trust/customer's data is completely isolated from every other's, enforced throughout the software, and no in-app role - including the most senior administrator role - can access another organisation's data.
- Third parties (sub-processors): the platform's infrastructure and a small number of supporting services are provided by Amazon Web Services (AWS) - this includes the hosting environment, the database, the identity/authentication service, and the underlying delivery mechanisms for SMS and email notifications (e.g. multi-factor authentication codes, password reset emails). No other third party receives patient data. AWS acts purely as infrastructure - it does not use, analyse, or repurpose the data for its own or any other customer's purposes.
- No sale, marketing, or research use of patient data occurs anywhere in the system as designed.
Retention - confirmed outstanding gap. No specific retention/deletion period is currently enforced by the software for patient data - data persists "for the duration of the commissioning relationship" as a working assumption, not a configured or contractually agreed retention schedule. A concrete retention period (aligned to the NHS Records Management Code of Practice, and to each Trust's own retention policy for the relevant record type) must be agreed and technically enforced before this is considered complete.
International transfers
All infrastructure holding patient data is deployed to a single UK AWS region (London) - there is no cross-border transfer of patient data as part of normal operation. The only components with any wider geographic footprint are a global content-delivery network (which caches only the public, non-patient-data web application code, not patient data) and an account-wide security audit service that can span multiple regions for resilience purposes - patient records themselves are not held outside the UK by either of these.
Step 3
Consultation
- Internal: this assessment has been produced by the product/engineering team responsible for building Holdfast, cross-checked against the platform's actual implemented behaviour rather than its intended design, so that gaps are surfaced rather than assumed closed.
- External - outstanding: formal consultation with a Trust/ICB's own Data Protection Officer, Caldicott Guardian, and Clinical Safety Officer has not yet occurred for any specific deployment, since no live Trust/ICB deployment exists at the time of writing. This consultation is expected, and required, before real patient data is processed by any specific organisation - this document is intended as the starting evidence base for that conversation, not a replacement for it.
- Patients and the public: no direct patient/public consultation on the DPIA itself has taken place. Patient-facing consent language and crisis-safety wording have been designed with patient welfare as the explicit priority (see Step 4), but this is not equivalent to formal patient and public involvement (PPI) consultation on the processing itself, which is recommended before wide rollout.
Step 4
Assess necessity and proportionality
Lawful basis
- Article 6 (general processing): expected to be Article 6(1)(e) - processing necessary for the performance of a task carried out in the public interest (NHS-commissioned care), since the controller is an NHS Trust/ICB or a body commissioned to deliver NHS-funded care.
- Article 9 (special category health data): expected to be Article 9(2)(h) - processing necessary for the provision of health or social care, undertaken by or under the responsibility of a professional subject to an obligation of confidentiality (or an equivalent condition under Schedule 1 of the Data Protection Act 2018, such as the health and social care purposes condition).
This is the manufacturer's expected basis, not a confirmed legal opinion. Each deploying Trust/ICB, as the data controller, is responsible for confirming and documenting its own lawful basis and Schedule 1 condition as part of its local DPIA and Data Processing Agreement with Holdfast.
Purpose limitation
Data collected through check-ins and questionnaires is used only for the stated purpose: monitoring wellbeing while waiting, prioritising staff attention, and enabling safe escalation. It is not used for research, service marketing, or any purpose beyond direct care and the operational/safety reporting a commissioner needs to evidence that waiting-list support is working - and even that reporting is restricted to aggregate, non-identifiable figures.
Data minimisation
- The routine check-in is deliberately kept short (around a minute to complete) rather than collecting an exhaustive clinical history at every touchpoint.
- Optional protected-characteristics data (ethnicity, gender identity, age band) for equity reporting is collected only where a Trust has explicitly opted in via a per-organisation setting, under its own separate consent type - it is not collected by default.
- Free-text responses are read by staff for clinical review, not algorithmically mined, analysed, or repurposed by the software itself.
- NHS numbers and phone numbers - the two most re-identifying pieces of contact data - are held in encrypted form at the application layer, with only the last three digits of an NHS number ever decrypted for on-screen display, rather than being freely queryable in plain form.
Fairness and transparency to data subjects
- Patient consent (for digital monitoring and data sharing) is captured explicitly, as a versioned, withdrawable record, before a patient's first check-in - not assumed or bundled into a generic terms-of-service click-through.
- Patients are never shown a risk score, rating, or category about themselves - a deliberate transparency-and-welfare balance: the system is transparent with staff (every score traces to a named, readable rule) while deliberately not exposing a raw risk label to the patient themselves, which could cause distress or be misinterpreted without clinical context.
- Where a patient discloses risk, they are shown crisis support information (NHS 111, Samaritans, Shout, 999) immediately - before the practical effect of their disclosure (a staff notification) has necessarily happened - so they are never left without immediate, actionable information at the point of highest need.
Individual rights
| Right | Current position |
|---|---|
| Right to be informed | Consent capture and crisis-disclosure messaging exist; a full, plain-language privacy notice for patients has not yet been finalised as a standalone published document. |
| Right of access (SAR) | No dedicated self-service subject access tooling exists yet. A request would currently need to be handled manually by the deploying organisation's information governance team using the platform's audit trail and record views - functionally possible today, but not yet a streamlined, documented process. |
| Right to rectification | Staff can correct referral, pathway, and demographic data through normal case management; every change is audited. Patients do not currently have self-service edit access to their own submitted check-in history (by design, since check-ins are a point-in-time clinical record, not a mutable profile). |
| Right to erasure | Not yet implemented as a self-service or even fully documented administrative process. Health records are also subject to NHS retention obligations that can lawfully limit erasure - this needs to be resolved as a documented policy before it can be described as complete. |
| Right to restrict processing | Not yet implemented as a distinct technical control (e.g. a "frozen" record state) beyond normal account deactivation. |
| Right to data portability | Not yet implemented as a patient-facing export; a staff-facing aggregate CSV export exists for commissioner reporting, but this is not the same as an individual's personal data export. |
| Right to object | Consent withdrawal exists for the specific consent types captured and is itself audited. A broader "object to processing" mechanism beyond consent withdrawal has not been separately implemented. |
| Rights related to automated decision-making (Article 22) | Holdfast's risk scoring is explicitly designed so that no decision "based solely on automated processing" is ever made about a patient - every escalation is a notification to a human, who makes the actual decision. This substantially reduces Article 22 risk, though it should still be confirmed by each controller's DPO. |
This table is the clearest evidence that the DPIA process is doing its job: several individual-rights mechanisms are not yet built, and that is stated plainly rather than glossed over.
Step 5
Identify and assess risks
Each risk is rated for likelihood and severity (Low/Medium/High) before mitigation ("inherent") and after the controls described in Step 6 ("residual").
| # | Risk | Inherent | Residual | Notes |
|---|---|---|---|---|
| R1 | A defect in an application handler causes one organisation's staff to see another organisation's patient data | High | Low | Every data-holding record carries an organisation identifier resolved from verified login credentials, never client input; every query is scoped to it; a dedicated automated test suite specifically asserts cross-organisation isolation holds. |
| R2 | Patient-identifiable data (especially NHS number, phone number) is exposed through a database compromise or backup leak | High | Medium | NHS number and phone number are separately encrypted at the application layer on top of database-level encryption at rest; only the last three digits of an NHS number are ever displayed. Residual risk is Medium rather than Low because the current demo-stage environment runs with weakened account-security settings (see R4) and has not yet undergone independent penetration testing. |
| R3 | A member of staff accesses a patient record outside their legitimate caseload/role ("browsing") | Medium | Low | Role-based access control is enforced on the server, not just hidden in the interface; every relevant record view/change is logged with the acting user's identity, supporting after-the-fact detection even though real-time "break glass" alerting is not yet built. |
| R4 | Account takeover of a staff account leads to unauthorised access to multiple patients' data | High | Medium (production config) / High (current demo config) | The production-shaped configuration requires multi-factor authentication and enforces advanced compromised-credential protection. The current disposable demo environment deliberately runs with MFA switched off to simplify testing - this must never be the configuration used for real patient data. |
| R5 | A patient in crisis is not helped quickly enough because their disclosure sits unactioned | High | Medium | Every risk-crossing check-in raises a service-configurable-deadline escalation with automatic re-notification and visible breach flagging; independently, crisis signposting to NHS 111/Samaritans/Shout/999 is shown to the patient immediately regardless of staff response time. |
| R6 | Data is retained indefinitely with no clear deletion point, increasing the impact of any future breach | Medium | Medium | A confirmed, undischarged gap - no enforced retention/deletion schedule exists yet. Rated Medium rather than High because the underlying data is already well-isolated and encrypted, but this should be treated as a priority pre-go-live action. |
| R7 | A subject access, erasure, or objection request cannot be efficiently fulfilled, causing a statutory-timescale breach | Medium | Medium | Several individual-rights mechanisms are not yet self-service or fully documented (Step 4). The data itself is retrievable, but the process to fulfil a request within statutory timescales is manual and undocumented today. |
| R8 | A third-party infrastructure provider (AWS) or its sub-services experiences an outage or incident affecting data availability or integrity | Medium | Medium | All infrastructure is UK-region-only, from a major cloud provider with its own extensive compliance certifications; a disaster recovery plan exists. Current backup retention is short (a single day) with no point-in-time recovery, and this is an explicitly scoped, not-yet-built improvement. |
| R9 | A child or young person's data is processed via a carer account without adequate verification of the carer relationship | Medium | Low | Carer accounts are explicitly created and scoped by staff to one named patient, not self-registered, and are restricted server-side to only the instruments appropriate to a carer/parent respondent. |
| R10 | Optional equity-monitoring data (ethnicity, gender identity) is used to re-identify a small group of patients in aggregate reporting | Medium | Low | Collected only under separate explicit consent and only where a Trust opts in; reports apply small-number suppression (any group under five people is withheld) specifically to prevent re-identification through small cell sizes. |
Step 6
Measures to reduce risk
Controls already in place
- Application-enforced multi-tenancy with a dedicated automated cross-organisation isolation test suite (R1).
- Field-level encryption of NHS numbers and phone numbers, independent of and in addition to database-level encryption at rest, with minimal on-screen display of the underlying value (R2).
- Server-side role-based access control and a complete, immutable audit trail of every relevant record change and login event (R3, R7 partially).
- Multi-factor authentication and advanced identity protection, available and enforced in the production-shaped configuration (R4) - with the explicit, disclosed caveat that the current demo environment does not run this configuration.
- Deterministic, explainable risk scoring with a service-configurable response deadline, automatic breach escalation, and independent crisis signposting shown directly to the patient regardless of staff response time (R5).
- UK-only data residency for all patient-data-holding infrastructure, backed by a documented disaster recovery plan (R8).
- Staff-mediated, scoped carer accounts rather than self-service carer registration (R9).
- Consent-gated, small-number-suppressed equity reporting, off by default (R10).
Priority actions - not yet implemented
- Agree and technically enforce a concrete data retention and deletion schedule (R6), aligned to NHS Records Management Code of Practice guidance and each Trust's own policy.
- Build and document a subject access / rectification / erasure / portability request-handling process capable of meeting UK GDPR statutory timescales (R7).
- Publish a finalised, plain-language patient privacy notice.
- Confirm, in writing, that any production/live-patient deployment runs the production-shaped security configuration (multi-factor authentication, advanced identity protection, web application firewall) - never the disposable demo configuration (R4).
- Extend database backup retention and add point-in-time recovery ahead of any live deployment (R8), and complete independent penetration testing.
- Agree a written Data Processing Agreement with each deploying Trust/ICB confirming the controller/processor relationship, lawful basis, and retention terms.
Step 7
Sign-off and outstanding actions
This DPIA has not yet been signed off by an independent Data Protection Officer, Caldicott Guardian, or any specific deploying NHS Trust/ICB. It represents the manufacturer's own honest self-assessment, intended as the starting evidence base for that independent review - not a substitute for it.
Before this processing begins for real patient data at any organisation, the following must happen:
- The deploying Trust/ICB's DPO reviews and either endorses or amends this assessment against their own local context (their own retention policy, their own information governance framework, their own existing Data Processing Agreement templates).
- The priority actions listed in Step 6 are either completed, or explicitly accepted as a time-bound risk by the controller with a documented remediation date.
- A named individual at the controller organisation is recorded as having reviewed and accepted this DPIA, alongside the date and any conditions attached to that acceptance.
| Field | Status |
|---|---|
| DPIA author | Holdfast product/engineering team (self-assessment) |
| Independent DPO review | Not yet completed |
| Controller sign-off | Not yet completed - pending a named deploying organisation |
| Residual risk accepted by controller | Not yet recorded |
| Review due | Before any live patient data is processed, and at minimum annually thereafter or on any material change to the processing described in Step 2 |
Summary for assessors
Where each area stands today
| Area | Current state |
|---|---|
| Lawful basis | Clearly identifiable expected basis (Article 6(1)(e) + Article 9(2)(h)) - not yet confirmed in writing by a specific controller. |
| Data minimisation and purpose limitation | Strong by design - short check-ins, consent-gated optional data, no secondary use. |
| Security controls | Strong technical foundation (encryption, isolation, audit trail, MFA-capable) - currently demonstrated in a deliberately weakened demo configuration; production configuration must be confirmed before go-live. |
| Individual rights | The weakest area today - several rights (erasure, portability, a documented subject access process) are not yet built or documented. |
| Retention | Not yet defined or enforced - the single highest-priority open action from this assessment. |
| Governance | No independent DPO/Caldicott Guardian sign-off yet; this document is the evidence base for that review, not a replacement for it. |
This assessment should be re-issued whenever a material change lands in the categories of data processed, the purposes of processing, the sub-processors used, or the security configuration described in Step 2 - and, in any case, reviewed independently by each deploying organisation before real patient data is processed.