Security & IG

Controls designed to be inspected, not taken on trust

An open repository only earns a place in an NHS estate if the governance story is at least as strong as the technical one. This page sets out both what is implemented and what is deliberately still open.

Implemented in the reference build

Data stays in your estate

The repository is deployed into the Trust's own cloud tenancy or on-premise. There is no default third-party processor, no vendor-side copy and no egress charge for reading your own data.

Role and organisation row-level security

Access policies are enforced in the database, not in a reporting layer. A user's role and organisation determine which rows return, so a bypassed dashboard does not become a bypassed control.

Pseudonymisation at the boundary

Identifiable fields are held in a restricted layer. Analytical models consume pseudonymised keys by default, with re-identification a separately authorised and logged action.

Append-only audit

Every read, export and privileged action is written to an append-only log with actor, purpose and timestamp. The log is queryable by the Trust's own IG team without asking anyone's permission.

Standards-based authentication

The FHIR service uses OAuth2 with scoped tokens. It is designed to sit behind the Trust's existing identity provider rather than introduce a parallel user directory.

Reviewable logic

Transformation logic is version-controlled, source-available SQL. IG and clinical colleagues can read exactly how a figure was derived — an auditability property closed platforms cannot offer.

Evidence pack for your IG committee

Draft artefacts included with evaluation access. They are starting points shaped for a Trust to complete, not certifications.

DPIA skeleton

Pre-filled with the repository's processing purposes, lawful bases to confirm locally, and the risks a Trust will need to assess.

Data flow map

Source systems, staging, canonical layer, serving interfaces and every point at which identifiability changes.

Retention & minimisation positions

Default retention per domain with the rationale, ready to be checked against local policy.

Access control matrix

Roles mapped to row-level policies and to the audit events each role generates.

Exit & cutover runbook

A 90-day plan with reconciliation gates, so exit is an executable process rather than an intention.

Test and reconciliation evidence

Generated test results and source-to-canonical variance reports for each load.

What is not in place yet

No DSPT submission, ISO 27001 certification or NHS assurance has been completed for this build.
No clinical safety case (DCB0129 / DCB0160) exists. It cannot meaningfully be written without a partner Trust and a defined clinical use.
No independent penetration test has been carried out on the reference deployment.
The build has been exercised against synthetic data only — never against live patient data in an NHS environment.
There is no 24/7 support organisation, service credit regime or signed data-processing agreement behind it today.

Stating this plainly is the point. A design-partner Trust would be working with an early reference implementation and shaping the assurance path with us, not buying a finished, accredited product.

Why openness helps governance

Every derivation in the repository can be read, challenged and corrected by the Trust's own analysts and IG team. Where a closed platform asks a committee to accept a figure, an open repository lets it verify one.

Next step

Bring it to your IG committee

Request evaluation access to review the controls, the audit design and the draft IG pack in full.

Open the live sandbox Request evaluation access