Skip to main content

​
Overview

The General Data Protection Regulation (GDPR, EU 2016/679 - RGPD in Portuguese) applies to any organisation processing personal data of EU data subjects, regardless of where the organisation is established. It sets requirements for data security, record-keeping, and evidence of compliance. Two GDPR principles create a specific challenge for blockchain-based systems:
  • Integrity and confidentiality (Article 5(1)(f)): Data must be processed with appropriate security, including protection against unauthorised or unlawful processing and against accidental loss, destruction, or damage
  • Right to erasure (Article 17): Data subjects have the right to have their personal data deleted under certain conditions
ROOTKey is designed to satisfy both - through a protocol architecture that separates on-chain integrity proofs (which contain no personal data) from off-chain data storage (which can be deleted on request).

​
Article-Level Coverage

​
The GDPR–Blockchain Architecture Challenge

Blockchains are immutable by design. GDPR’s right to erasure requires that personal data can be deleted. This creates a direct tension that ROOTKey resolves at the protocol level:

What goes on-chain

Only the hash - a SHA-256 fingerprint of the data. A hash contains no personal information and cannot be reversed to reveal the original data. Deleting the underlying data does not require modifying the on-chain record.

What stays off-chain

The actual data - stored in your controlled systems or ROOTKey’s off-chain storage, which can be deleted in response to an erasure request. Deletion severs the proof without compromising the blockchain record’s integrity.

​
GDPR Erasure Compatibility by Protocol

Do not anchor personal data directly into a blockchain record. Always anchor the SHA-256 hash of the data, keeping the data itself in erasure-capable off-chain storage. This is how ROOTKey’s protocols are designed to be used.

​
Processing Records and Accountability

GDPR Article 30 requires controllers and processors to maintain records of processing activities. ROOTKey supports this by anchoring:
  • Data access logs (who accessed what data, when)
  • Data transfer records (cross-border transfers under Chapter V)
  • Consent records (with timestamp and version of consent language)
  • Data subject request records (access, rectification, erasure, portability)
  • Third-party processor agreement records
Each anchored record is independently timestamped and cannot be retroactively altered - satisfying the accountability principle (Article 5(2)).

​
Breach Notification Evidence

GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. Regulators investigate whether:
  1. The 72-hour deadline was genuinely met, or whether notification was backdated
  2. The breach scope was accurately reported at the time, or was revised to minimise apparent impact
ROOTKey anchors:
  • The detection record (time of awareness)
  • The assessment record (scope determination)
  • The notification record (time of submission)
Each record carries a blockchain timestamp that cannot be altered retroactively - providing independently verifiable proof of compliance with Article 33.

​
Data Sovereignty

For GDPR compliance, personal data must be processed lawfully when transferred outside the EEA. ROOTKey’s EU-sovereign deployment uses EBSI and OVH - ensuring no data (or hash) leaves EU jurisdiction. → European Data Sovereignty

Request a GDPR compliance review

We’ll design a ROOTKey architecture that satisfies GDPR integrity and accountability requirements while remaining fully compatible with erasure obligations.

Healthcare use case

GDPR-compatible integrity protection for clinical data, trial records, and patient information.