GDPR Art. 9: Special Category Data #

Patient health data is special category data under Art. 9. This means:

  • Processing requires an explicit legal basis beyond the standard Art. 6 bases. For healthcare, Art. 9(2)(h) provides the basis for treatment purposes; Art. 9(2)(i) covers public health obligations.
  • Data minimisation is mandatory: only data necessary for the specific purpose may be processed and retained.
  • Security requirements are heightened: Art. 32 requires appropriate technical and organisational measures proportionate to the sensitivity. For health data, this sets a high baseline.
  • Data subject rights apply, including the right of access and, where applicable, erasure, but these rights are balanced against retention obligations under national law (Art. 17(3)(b)).

The critical implication for archiving: the legal basis for initial treatment does not automatically extend to long-term archiving. Organisations must identify a specific legal basis for archiving, typically a national retention obligation, and document it.

National Retention Requirements #

Retention periods for medical records vary by EU member state and by record type, commonly ranging from 10 to 30 years. Germany provides a representative example of the complexity involved:

  • General patient records: 10 years after last treatment
  • X‑ray and imaging records: 10 years
  • Radiation therapy records: up to 30 years
  • Children’s records: in practice until well into adulthood, because limitation periods run from majority
  • Occupational health records: substantially longer periods after hazardous substance exposure

Other member states have comparable frameworks with varying periods; map your own jurisdiction’s rules per record type. The key operational consequence is the same everywhere: the archiving system must support retention periods of up to 30 years for certain record types, with provable immutability. Records must not be alterable after creation.

US cloud providers, including the major hyperscalers, are subject to the US CLOUD Act regardless of where their servers are physically located. The CLOUD Act gives US authorities a legal basis to compel US-based companies to produce data stored outside the United States.

For EU healthcare organizations, this creates a structural conflict:

  • The restricts transfers of personal data to third countries without adequate protections (Art. 44 to 49)
  • The CLOUD Act creates an access mechanism that operates independently of those restrictions
  • Health data as special category data under Art. 9 intensifies the conflict, because the consequences of unauthorised disclosure are severe

The European Data Protection Board and several national supervisory authorities have flagged this issue. Standard Contractual Clauses do not resolve the CLOUD Act problem, because the legal access mechanism operates independently of the contractual relationship.

The practical conclusion: storing patient data on US-based cloud infrastructure, or on EU-based infrastructure operated by a US parent company, carries legal risk that on-premises storage avoids entirely.

Technical Requirements for Healthcare Archiving #

WORM: Immutability by Hardware, Not Policy #

Long-term patient record archiving requires immutable storage. ​“Immutable” here means the record cannot be altered, overwritten, or deleted after it has been written: not by administrators, not by ransomware, not by any software process.

There are two categories of immutability:

Software-based immutability ( by policy): Enforced by software controls. These can be bypassed by administrators with elevated privileges, or by attackers who obtain administrative credentials. For healthcare archiving, this is insufficient.

Hardware : enforced by the storage system itself. Once data is written, it cannot be overwritten or deleted before the retention period expires. This level of assurance survives administrator credential compromise and ransomware, and it is the appropriate technical control for records subject to 10- and 30-year retention obligations.

Audit Trails and Access Logging #

Every access to a patient record must be logged. This is both a clinical governance requirement and a data protection obligation. The audit trail must record:

  • Who accessed the record (authenticated identity)
  • When the access occurred (timestamp, ideally cryptographically verifiable)
  • What action was taken (read, export, print)
  • From which system or application

Audit logs themselves must be tamper-proof: an attacker who can modify audit logs can cover their tracks. Audit log integrity must be architecturally guaranteed, not just administratively required.

Encryption #

Patient data at rest must be encrypted, both on primary systems and in archives. Encryption keys must be managed by the healthcare organization, not by a cloud provider, so that the organization retains control and can demonstrate that third-party access (including by the provider) is not possible.

Practical Architecture for Healthcare Organizations #

The following architecture reflects the legal and technical requirements above. It is a structural approach, implementable with appropriate hardware.

Primary Patient Data: On-Premises with Access Control #

Active patient records in use by clinical systems belong on on-premises infrastructure under the direct control of the healthcare organization:

  • Storage systems within the organization’s own data centre or server room
  • Access control at the application layer (clinical systems) and the storage layer
  • Network segmentation to limit exposure to the broader hospital network
  • Encryption at rest with keys managed internally

Long-Term Archive: Hardware WORM #

Records subject to 10- or 30-year retention obligations require hardware . Silent Cubes from FAST LTA provide hardware archive storage designed for exactly this purpose. Key characteristics relevant to healthcare compliance:

  • Hardware-enforced immutability: data cannot be overwritten or deleted once written, at the system level
  • Long-term reliability: redundant storage with erasure coding, engineered for multi-decade retention
  • On-premises deployment: the storage resides within the organization’s infrastructure; no data leaves the facility
  • EU jurisdiction: no CLOUD Act exposure, no third-country transfer issues
  • Retention management: immutable during the statutory period, deletable and deletion-logged afterwards, which resolves the tension with erasure

Backup: Air-Gap Protection #

Clinical IT systems are a high-value ransomware target: the operational consequences of system unavailability are severe and the pressure to pay is high. A backup architecture without an air gap provides limited protection against ransomware that specifically targets backup systems.

The Silent Brick System provides disk-based air-gap backup in two variants:

  • Silent Brick Pro: storage bricks are physically removable from the Controller X. Removal creates a genuine physical air gap; the backup cannot be reached over any network because the connection is physically broken.
  • Silent Brick Max Air: galvanic separation without physical removal. The backup is isolated from the network at the electrical level, preventing network-based access without manual handling.

Both approaches protect backup data from ransomware that propagates over the network, from credential-based attacks, and from administrative mistakes, while keeping restores fast because the data stays on disk.

Architecture Summary #

  • Active patient records: primary on-premises secondary storage with access control and encryption at rest, on-premises in the EU
  • Long-term archive (10 to 30 years): hardware (Silent Cubes) with immutability and audit logging, on-premises in the EU
  • Backup (): air-gap backup (Silent Brick System) with physical or galvanic separation, on-premises in the EU

NIS2 and Healthcare: Hospitals as Essential Entities #

NIS2, the Network and Information Security Directive 2, applies to hospitals and other healthcare organizations classified as essential entities. Transposition into national law was due by October 2024; member states are at varying stages of implementation.

For healthcare IT, the relevant NIS2 obligations include:

  • Risk management measures: cybersecurity measures proportionate to risk exposure. Given the value of patient data and the criticality of clinical systems, the baseline is high.
  • Incident reporting: significant incidents must be reported to the competent national authority within defined timeframes (24 hours for early warning, 72 hours for the incident notification, NIS2 Art. 23).
  • Supply chain security: organizations must assess the security of their ICT supply chain, including storage and archiving vendors.
  • Business continuity: plans must exist to maintain or restore operations after a cybersecurity incident, and backup management is explicitly named among the required measures.

The air-gap backup requirement maps directly to the NIS2 business continuity obligation. An organisation that cannot restore clinical systems within an operationally acceptable timeframe after a ransomware attack has a NIS2 compliance gap, regardless of whether backups technically existed.

Common Mistakes in Healthcare Record Archiving #

Retention periods are set by law and professional standards, not by available storage capacity. Organisations that set retention based on storage costs create compliance gaps that surface only during a legal challenge or inspection.

Assuming Cloud Means Compliant #

Cloud providers market services as ​“ compliant” or ​“healthcare ready.” These claims refer to the provider’s own controls, not to your legal basis for processing or to the CLOUD Act conflict. compliance is an outcome of the entire processing arrangement, not a product feature. Cloud is not a primary strategy for patient data; on-premises control is.

Relying on Software WORM for Long-Term Archives #

Policy-based immutability does not survive administrator credential compromise and does not provide the assurance required for records that must remain unaltered for 30 years.

Neglecting Audit Log Integrity #

Logs stored in the same environment as the data they protect can be altered by the same attacker. Audit log integrity requires a separate, tamper-resistant log storage mechanism.

Applying One Retention Period to All Record Types #

A single global retention period is almost certainly wrong. Imaging, radiation therapy records, and general case notes each have their own periods under national law. The archiving system must support per-record retention metadata.

Failing to Test Recovery #

A backup that cannot be restored is not a backup. Healthcare organisations routinely test backup creation but rarely test full recovery from air-gapped or storage. The recovery test is the only proof that the architecture meets business continuity and compliance requirements.

Data Protection Checklist for Healthcare IT #

Legal framework

  • Legal basis for each category of patient data documented (Art. 9(2) basis identified)
  • Retention periods mapped per record type and national law
  • Data processing agreements in place with all processors, including storage vendors
  • Third-country transfer risk assessed for all cloud services; CLOUD Act exposure documented

Technical controls

  • Active patient data stored on-premises under direct organisational control
  • Long-term archives (10 to 30 years) on hardware storage, not software-enforced immutability
  • Backups protected by an air gap (physical or galvanic separation)
  • Encryption at rest for all patient data tiers, keys managed internally
  • Access control at application and storage layer, least privilege enforced

Audit and logging

  • All patient record access logged (who, when, what action)
  • Audit logs stored separately from primary data in tamper-resistant storage
  • Log retention period meets national legal requirements
  • Regular audit log review process in place

NIS2 and

  • Organisation classified correctly as an essential entity (if applicable)
  • Incident reporting process documented and tested (24-hour early warning, 72-hour notification)
  • ICT supply chain security assessment completed, including storage vendors
  • Business continuity plan covers the ransomware scenario with realistic recovery timelines

Retention management

  • Per-record-type retention metadata implemented in the archiving system
  • Deletion process for records past retention documented, with legal basis
  • Annual review of the retention schedule against applicable national law
  • Full recovery test from archive and air-gap backup at minimum annually

Further Resources #

→ Guide (/en/blog/datensouveraenitaet-leitfaden/) → Compliance: ICT Third-Party Management (/en/blog/dora-ict-third-party-management/) → US CLOUD Act Explained (/en/blog/us-cloud-act-erklaert/) → Silent Cubes: Hardware Archive Storage (/en/produkte/silent-cubes/) → Silent Brick System: Air-Gap Backup (/en/produkte/silent-brick-system/)

Disclaimer

This article was written by our editorial team and edited using AI. It provides a general overview and does not constitute legal advice – we recommend seeking professional advice for your specific situation.