Design NHS-Style Information Governance in 2026: A Build Guide for Custom Healthcare Platforms

Most healthcare software fails its first NHS procurement conversation not on features, but on information governance. The product demos well. The clinical workflow makes sense. Then the trust's IG lead asks where the data is hosted, who can see a patient record, how long you keep it, and what your last DSPT submission said, and the deal stalls for six months while you retrofit answers.

Information governance is not a compliance document you write after the build. It is a set of design decisions that touch your schema, your auth model, your logging, your hosting, and your deletion logic. Get them right early and they cost almost nothing. Bolt them on later and you are rewriting the foundations of a live system that handles real patient data.

This guide maps the frameworks a UK healthcare buyer actually checks (UK GDPR, the Data Security and Protection Toolkit (DSPT), role-based access control, audit trails, and the NHS retention schedule) into concrete platform design decisions. It is written for product owners and digital leaders building a custom healthcare platform for NHS requirements, not for lawyers. Where a decision changes your database or your code, we say so.

What NHS buyers actually check before they buy

Before a trust, ICB, or NHS-funded service signs anything, your platform usually has to clear a recognisable set of gates. Knowing them up front tells you what to design for.

• **DTAC (Digital Technology Assessment Criteria):** the standard baseline assessment covering clinical safety, data protection, technical security, interoperability, and usability. Most NHS buyers will send you the DTAC questionnaire early. Treat it as your requirements spec.
• **DSPT (Data Security and Protection Toolkit):** an annual self-assessment that any organisation handling NHS patient data must publish. In 2026 many organisations are completing the version aligned to the Cyber Assessment Framework (CAF). Buyers check your published status before sharing data.
• **Clinical safety (DCB0129 / DCB0160):** if your software could affect patient care, you need a named Clinical Safety Officer, a hazard log, and a clinical safety case. DCB0129 is your obligation as the manufacturer; DCB0160 is the deploying organisation's.
• **Cyber Essentials / Cyber Essentials Plus:** frequently a contractual requirement, not a nice-to-have.
• **ICO registration and a UK GDPR-compliant DPIA:** expect to provide a Data Protection Impact Assessment for any new processing of health data.

None of these are optional extras for a serious NHS product. The good news: every one of them maps onto design decisions you can make now. The rest of this guide works through them.

Start with a data map, not a feature list

Information governance starts with one question your engineers can answer and your lawyers cannot: what data flows through the system, from where, to where, and who touches it?

Before you model a single screen, build a data flow map. For every category of data, record the source, the lawful basis, where it is stored, who can access it, how long it is kept, and how it leaves the system. This is the backbone of your Record of Processing Activities (ROPA), your DPIA, and your DTAC data protection answers, and it is also the spec for your patient data management model.

A useful exercise: split your data into tiers and design controls per tier rather than treating every field the same.

The single most valuable architectural decision here is to separate identity from clinical content. If your analytics, your support tooling, and your background jobs operate on pseudonymised records that cannot be re-identified without a controlled key, most of your downstream IG burden shrinks dramatically.

UK GDPR for health data: the decisions that hit your schema

Health data is special category data under Article 9 of the UK GDPR. Processing it requires both a lawful basis under Article 6 and a separate Article 9 condition; for NHS care this is usually 'provision of health or social care' (Article 9(2)(h)). You do not generally rely on consent for direct care, which surprises teams who default to a consent checkbox.

What matters for the build is that these legal requirements translate into specific design decisions:

Two patterns repay the effort early. First, pseudonymisation: store a stable internal patient ID and keep the link to NHS number, name, and DOB in a separate, tightly controlled table. Second, field-level purpose tags: a small amount of metadata on sensitive fields lets you enforce purpose limitation in queries instead of trusting every developer to remember it.

Layer the eight Caldicott Principles on top of GDPR. They are the NHS lens on confidential patient information, and most trusts have a Caldicott Guardian who will expect to see them reflected in your design. Principle 7 is the one teams forget: the duty to share information for individual care can be as important as the duty to protect it. Over-locking a clinical record can be as much an IG failure as leaking one.

DSPT: what "compliant" means at the platform level

The DSPT is where abstract security intentions become evidenced controls. You do not pass it with good intentions; you pass it by pointing at things that exist. Designing for it means making sure those things exist as platform features rather than manual processes.

Map the recurring DSPT themes to concrete platform capabilities:

• **Access control:** unique named accounts (no shared logins), least-privilege roles, MFA for staff, and a documented joiner/mover/leaver process your platform supports.
• **Audit and monitoring:** tamper-evident logs of access to patient data, retained long enough to investigate an incident, with alerting on anomalous access.
• **Encryption:** at rest and in transit, with managed keys and a documented key rotation policy.
• **Patch and vulnerability management:** a real process covering dependency scanning, a known patch cadence, and evidence of it.
• **Backups and resilience:** tested restores, not just backups that exist. 'We have backups' is not the same as 'we restored last quarter.'
• **Incident response:** a documented plan with breach notification timelines (72 hours to the ICO for reportable breaches).

If your organisation handles NHS data directly, you complete your own DSPT. If you are a supplier, buyers will check your published status and may flow DSPT-style requirements into your contract. Either way, build the platform so the evidence is a query away, not a fire drill every renewal.

RBAC: model roles around clinical reality

Role-based access control is where clinical workflow management and information governance meet. Get the role model wrong and you either block clinicians from doing their jobs or expose records to people who should not see them. Both are IG failures.

Design roles from the actual care pathway, not from your org chart. A receptionist needs demographics and appointment data but not consultation notes. A treating clinician needs the full record for their patients. A clinical administrator needs workflow state across many patients but not necessarily detailed notes. A researcher needs pseudonymised data only.

Three patterns separate a credible RBAC model from a checkbox one:

1. **Least privilege by default.** New roles start with no access and gain it explicitly. It is far safer than starting broad and trying to claw permissions back.
2. **Relationship-based access, not just role-based.** A clinician should see their patients, not every patient. Enforce this with row-level security in the database or a policy layer, not with UI hiding, which is trivially bypassed.
3. **Break-glass access.** Emergencies happen. Allow an authorised override to reach a record outside the normal relationship, but make every break-glass event loudly audited and reviewed. Clinicians accept friction here when lives are not at stake and speed when they are.

Where you integrate with NHS infrastructure, plan for NHS CIS2 authentication (the successor to smartcard-based access) so clinical staff sign in with their existing NHS identity and role profile. Designing your permission model to consume those role codes is far cheaper than mapping them in later.

A practical rule: if a permission decision can be made in the database, make it there. UI-level access control is a usability feature, not a security control.

Audit trails that survive an investigation

When a patient asks who looked at their record, or the ICO investigates a suspected breach, your audit log is the evidence. A weak audit trail is one of the fastest ways to fail an IG review, and one of the cheapest things to get right at build time.

The standard for sensitive healthcare access is who did what, to which record, when, and from where. Design for it explicitly:

• **Log reads, not just writes.** In most systems you audit changes. In healthcare, viewing a record is itself an auditable event, and unauthorised viewing is a real and common breach type.
• **Make logs tamper-evident.** Append-only storage, write-once buckets, or a separate audit store that application accounts cannot modify. An audit log your app can rewrite is not evidence.
• **Capture identity, not just a user ID.** Record the authenticated user, their role at the time, the access justification where relevant (especially break-glass), and the source context.
• **Keep audit logs long enough.** Access logs for patient data generally need a longer retention than ordinary application logs; align them to your records retention obligations, and never let them contain the clinical content itself.
• **Alert on anomalies.** Bulk exports, out-of-hours access, a clinician viewing a colleague's or a VIP's record: these are the patterns IG teams care about. Detection beats a log nobody reads.

Data retention: encode the schedule, don't bolt it on

Storage limitation is a GDPR principle, but in the NHS it has a specific shape: the Records Management Code of Practice 2021 sets out how long different health records must be kept. These are not suggestions. Keeping records too long is as much a breach as deleting them too early.

A sample of the schedule shows why retention has to live in your data model rather than in a policy PDF nobody reads:

Always check the current Code for the record types you handle; this is an illustration, not legal advice, and schedules change. The design lesson is constant: retention is a property of the data, not a manual cleanup job. Tag each record with its retention class and a calculated review date. Run a scheduled process that, when a record reaches end of life, either deletes it or anonymises it according to its class, and logs that action.

Anonymisation deserves a deliberate decision. True anonymisation removes data from GDPR scope, but it must be irreversible: pseudonymised data where a key still links back to a person is still personal data. If you anonymise for research or analytics, prove the re-identification risk is genuinely low, and document how.

Build a Subject Access Request path while you are here. Patients have the right to a copy of their data, and the NHS context adds expectations around timeliness. A platform that can assemble a complete, readable record for one patient on demand turns a stressful manual scramble into a routine export.

Encryption, hosting, and data residency

Where NHS patient data lives is a question every buyer asks, and the wrong answer ends conversations. The expectation is UK or, at minimum, UK-adequate data residency, with a clear story on any processing outside the UK.

• **Data residency.** Host patient data in UK regions and be explicit about it. If any sub-processor (analytics, email, AI services) moves data abroad, you need the safeguards and the documentation, and you should expect to defend it.
• **Encryption at rest and in transit.** TLS everywhere, encrypted storage and databases, and a managed key service with rotation. Document the algorithms and key management; DTAC and DSPT both ask.
• **Network and hosting posture.** Be ready to discuss segmentation, the boundary of your environment, and how you handle remote access. Where integration requires it, understand HSCN (the NHS network) connectivity.
• **Sub-processor transparency.** Maintain a current list of every third party that touches patient data, what they do, and where. Buyers will ask, and a vague answer reads as a red flag.

AI features deserve a specific caution in 2026: if your health IT platform sends patient data to a third-party model API, that is a data flow with a lawful basis, a residency question, and a sub-processor to document. Design AI features so identifiable patient data either stays within your controlled environment or is pseudonymised before it leaves. 'The vendor says they don't train on it' is not, by itself, an IG control.

Clinical safety is part of governance too

If your software influences clinical decisions or care delivery, clinical safety sits alongside data governance, and NHS buyers assess both. The standards are DCB0129 (for you, the manufacturer) and DCB0160 (for the deploying organisation).

In practice this means appointing a Clinical Safety Officer, a suitably qualified clinician, and maintaining a hazard log: a living record of what could go wrong, how likely and how serious it is, and what your design does to mitigate it. A confusing medication field, an ambiguous status that hides a critical result, a silent sync failure: these are clinical hazards, and the platform's design is the primary mitigation.

Teams treat this as paperwork and regret it. The hazard log is genuinely useful product input: it forces you to ask where your interface could lead a clinician to the wrong conclusion, and that question improves the software for everyone. Start it at design time and update it as the product evolves.

A design checklist for IG-ready platforms

Pulling the threads together, here is what 'designed for NHS information governance' looks like in the build rather than the brochure:

1. A data flow map and ROPA exist before the schema is finalised.
2. Identity is separated from clinical content; analytics and support run on pseudonymised data.
3. Lawful basis and purpose are modelled as data, and purpose limitation is enforced in queries.
4. RBAC is least-privilege, relationship-aware, enforced in the database, with audited break-glass access.
5. Read access to patient data is audited to a tamper-evident store, with anomaly alerting.
6. Retention classes and review dates live on every record, with automated deletion or anonymisation.
7. Subject Access Requests can be fulfilled as a routine export.
8. Patient data is UK-resident, encrypted at rest and in transit, with a documented sub-processor list.
9. A Clinical Safety Officer and hazard log are in place if the software affects care.
10. Every control above can be evidenced on demand for DTAC, DSPT, and DPIA.

If you can tick these, your first NHS procurement conversation is about whether your product solves the problem, not whether it is safe to let near patient data. That is the conversation you want to be having.

Where this fits in your build

None of this requires gold-plating. It requires sequencing: make the governance decisions while they are still cheap schema and architecture choices, not expensive retrofits to a live system. A platform designed this way is not slower to build; it is slower to fail an IG review, which is the delay that actually kills healthcare software deals.

If you are scoping a new healthcare platform, or trying to work out whether an existing one would survive NHS scrutiny, the fastest route is a design that bakes these controls in from the schema up. That is the kind of healthcare software development we do for UK product owners and digital leaders.

For the wider regulatory picture, covering GDPR, NHS digital standards, and clinical safety frameworks for UK health software, read our companion guide on healthcare app development in the UK.