Security & Compliance

Last updated: 26 June 2026

Get Patient Consent handles special category health data, so security and data protection are designed in from the foundation — not added on. This page sets out, in full, how patient and clinician data is protected, how each signed consent is sealed with a digital signature and an independent trusted timestamp, and how anyone can verify a record without relying on us. It is written for the people who need the detail: information governance leads, data-protection officers, and procurement teams.

Where your data lives

Patient and clinician data is held in a managed PostgreSQL database provided by Neon, running in the UK region — Amazon Web Services' eu-west-2 (London). We select the UK region specifically so that stored data remains in the United Kingdom. Neon is independently certified to SOC 2 Type II and ISO 27001, and provides a data processing agreement. If we ever needed a sub-processor outside the UK, we would put a UK GDPR-approved transfer mechanism (UK IDTA or equivalent) in place and update our Privacy Policy first.

Encryption

• At rest: all stored data is encrypted using AES-256, with encryption keys managed in AWS KMS and rotated under Neon's key-management policy.
• In transit: every connection is secured with TLS 1.2 or higher.

Tamper-evident audit trail

Every meaningful action in a consent journey is written to an append-only audit log: what was shown to the patient, when each section was viewed, how long was spent reading, every question and answer, and the final signature.

Each entry is linked to the one before it using a cryptographic hash chain. Altering any past record would break the chain and be immediately detectable. The result is evidence that can be independently verified years after the event — the documented dialogue the law expects, not just a signature.

How each signed consent is sealed

When a patient signs, we do not simply capture a signature image. The complete consent record — who the patient is, what they were shown, the benefits, risks and alternatives explained, every question and answer, the declarations they confirmed, and the signing event itself — is assembled into a single canonical data record (a normalised JSON document, RFC 8785). That canonical record is the authoritative, signed object of record; the PDF and the on-screen pages are faithful renderings of it.

The canonical record is sealed with a digital signature using ECDSA on the NIST P-256 curve with SHA-256 (ES256). The private signing key is held in AWS Key Management Service (KMS) and never leaves it. The signature is stored detached, alongside the record, so the visible PDF can never change what was signed: any later edit to the document diverges from the sealed record and is detected the moment it is verified.

Trusted timestamps

At the moment of signing, the signature is submitted to an independent Time-Stamp Authority (TSA), which returns an RFC 3161 timestamp token cryptographically attesting the time. This anchors when a consent was signed to a neutral third party with no stake in the outcome — not to our own clock — which matters if the timing of a consent is ever questioned, for example that it pre-dated the procedure.

Timestamping is a blocking step: a consent is not treated as signed until a token has been obtained, so every signed record carries one. We use a primary TSA with an automatic fallback, so a single provider's outage cannot halt signing. The TSA's certificate is archived alongside the token, so the timestamp stays verifiable offline years later, even if that authority no longer exists.

Independently verifiable — without relying on us

Each signed record is designed to be checked by anyone — a patient, clinician, solicitor, regulator or expert witness — using standard, freely available tools, without contacting us and without having to trust us.

• The public half of every signing key (the current key and every retired one) is published openly in a separate, permanent public verification repository, alongside a small dependency-free verifier and a step-by-step OpenSSL recipe. Trust derives from the key fingerprint carried inside each document, not from any server being online.
• Signed PDFs are produced as PDF/A-3 — an archival PDF standard — with the canonical record, the signature and the timestamp token embedded as attachments. A single PDF is therefore self-verifying offline: a recipient extracts the files and checks the signature and timestamp for themselves.
• The record is self-describing: it carries the human-readable facts a reader or court would need — the patient's full demographics and the responsible and answering clinicians' names — not just internal identifiers, so it remains meaningful and provable on its own.

This is a deliberate control. A consent record may be relied upon many years after signing, and its validity should never depend on our systems being available or on our continued involvement. To be clear, verification proves the record's integrity, authorship and timing; whether the consent was clinically valid still rests, as it always has, on the patient's capacity, the information given, and a voluntary decision. The full method is set out in our independent verification white paper.

Consent versioning

Every signed consent stores a complete, immutable snapshot of exactly what the patient was shown — the procedure description, the specific risks, and the exact version of every leaflet. Editing a template later never alters a consent that has already been signed. What was signed is preserved, word for word.

Access controls

• Access to production systems is restricted to named individuals on a least-privilege basis.
• Administrative access is protected by multi-factor authentication.
• All access to production systems is logged.
• Within the platform, clinicians control who may act on their behalf. Every action taken by a delegated staff member is recorded under that person's own identity, showing who did what, when, and on whose behalf. Access can be revoked instantly.

Data protection & compliance

Get Patient Consent is the trading name of CSSL Ltd, registered in England and Wales (company number 03996773) and registered with the Information Commissioner's Office under reference ZB417718.

• A Data Protection Impact Assessment (DPIA) has been completed for the platform.
• The service is built around UK GDPR principles of data minimisation, purpose limitation, and defined retention.
• For patient health data we act as a data processor, on the documented instructions of the clinician or organisation (the data controller), under a data processing agreement. The clinician relies on Article 9(2)(h) — the provision of health care — as the condition for processing special category data.

Full detail of roles, lawful bases, and individual rights is set out in our Privacy Policy.

Sub-processors

We do not sell or rent personal data. We rely on a small number of vetted sub-processors, each bound by a written contract meeting UK GDPR requirements:

Data retention

Clinicians, as controllers, determine how long consent records are kept. The default minimum we support is 8 years from the date of the procedure, in line with NHS records management guidance, and clinicians may instruct us to retain for longer. Security and audit logs are retained for up to 24 months. Retention rules are documented in our Data Retention Schedule, available on request.

Accessibility & resilience

The patient experience is designed to meet WCAG 2.1 AA and works on any modern phone, tablet, or computer, on any browser, with no app to download. Consent can be completed on the patient's own device, in their own time — which removes a common barrier to genuinely informed consent.

Business continuity

Consent is critical infrastructure, so the service is engineered for high availability and continuity is designed into the record itself. Every signed consent is a self-contained, independently verifiable PDF/A-3 that the clinician and patient already hold — so an individual record stays readable and provable even if our systems are temporarily unavailable, and indeed without us at all (see Independently verifiable, above). Business continuity and disaster recovery — including independent retrieval of recent records during an outage — are addressed in our information-security management system; the relevant summary is available to IG and procurement teams on request.

Reporting a security concern

If you believe you have found a security vulnerability, please tell us at security@getpatientconsent.com. We welcome responsible disclosure and will acknowledge your report.

Questions from your IG or procurement team

We are happy to support due diligence. For a copy of our DPIA summary, data processing agreement, or data retention schedule, contact hello@getpatientconsent.com.