Securing medical data

Medical data is the most sensitive category most organisations will ever handle, and healthcare is digitising fast. System-to-system exchange between hospitals, clinics, laboratories, insurers and research programmes is now routine. Every one of those interfaces is a control point, and every stored copy is an obligation.

The applicable regimes — GDPR, NIS2, ISO/IEC 27001, HIPAA where relevant, and now the AI Act — largely agree on what good looks like. Here is how it decomposes into architecture.

1. Encryption at rest and in transit

At rest: ECG and MRI files stored in databases, file systems or cloud storage should be encrypted with current standards — AES-256 as the baseline. Encryption is only as strong as key handling: use a proper Key Management System, rotate keys on a defined schedule, and never store keys alongside the data they protect.

In transit: transfers between systems must run over TLS or VPN. For server-to-server exchange, use mutual TLS so both parties are authenticated, closing off man-in-the-middle attacks that one-way authentication leaves open.

2. Access control and identity

Role-based access control limits access according to organisational role — radiologists see imaging, and the finance system does not. Fine-grained access control extends this to file and field level within a record, because access to the patient record is usually too coarse a permission.

Multi-factor authentication should be mandatory for any system holding clinical data. Least privilege must be a design property, not a periodic clean-up exercise: each user and each system gets exactly what its function requires.

3. Secure APIs and exchange

Use OAuth 2.0 or OpenID Connect for API authentication so only authorised parties can retrieve data. Validate structure and content of exchanged payloads — JSON Schema or equivalent — to prevent injection and preserve integrity. For analytics, development and testing environments, apply data masking so that non-production systems never hold real patient data.

4. Minimisation and anonymisation

Minimisation: collect and transmit only what is needed. A processed or summarised derivative is frequently sufficient and always safer than a full imaging volume. Audit collection practice regularly — data accumulates by default.

Anonymisation and pseudonymisation: strip identifiers from signals and images wherever the use case permits. For pseudonymisation, use cryptographic hashing with proper key separation so the original identity cannot be reconstructed without controlled access to a separate store.

5. Building in the right to be forgotten

This is where most architectures fail, because deletion was never treated as a first-class operation.

Deletion that actually deletes

Erasure must reach every copy — primary storage, replicas, caches, backups, logs and archives. If your backup strategy makes deletion impossible, your backup strategy is a compliance defect.

Verifiable erasure

In some architectures, zero-knowledge proofs allow a third party to verify erasure occurred without exposing the data. Digital signatures on deletion confirmations provide a lighter-weight equivalent.

Automated retention

Define retention periods per data category and enforce them automatically. Data that no longer needs to exist should not require a human to remember it.

Erasure audit trail

Log each request, its time, its requester and confirmation of completion. This record is what demonstrates compliance if it is ever questioned.

De-identification as an alternative

Where full erasure conflicts with legitimate retention, de-identification retains analytical value while satisfying the individual's position.

6. Monitoring and incident response

Continuous monitoring of access and exchange, with logging of access attempts, transfers and anomalies. SIEM tooling to automate detection. Real-time alerting on unauthorised access, failed authentication patterns and probable breach indicators.

An incident response plan that is written, tested and owned: containment, notification within regulatory timeframes, remediation, and a defined chain of command. NIS2 reporting deadlines are short enough that the process must exist before it is needed.

7. Compliance in practice

Alignment with GDPR, HIPAA where applicable, ISO/IEC 27001 and NIS2, verified through regular security audit and penetration testing rather than assumed from a design document.

The underlying principle

Privacy by design is not a slogan. It means that when the erasure request arrives, the deletion path already exists; when the auditor asks, the evidence is already there; and when the breach attempt happens, the monitoring already sees it. Retrofitting any of these is expensive. Designing for them costs almost nothing at the start.