"your partner in provenance"


Data Protection

DocuChain regards personal data as an extension of the individual and embeds the protection of personal information into our company policy. DocucChain’s 4Trust services are provided by a series of system integrators. These system integrators have their own GDPR policies and take final responsibility for GDPR compliance in partnership with their clients and end users. DocuChain’s 4Trust platform has many intrinsic features which support GDPR compliance. To this end, DocuChain employs current industry best practice and is compliant with GDPR regulations through our adherence to industry guidelines.

For clarification on the scope and intent of GDPR legislation, see below.

GDPR means the EU General Data Protection Regulation, a new regulation that was published in May 2016 and has come into effect on 25 May 2018, replacing the current Data Protection Directive (95/46/EC). GDPR will apply to all countries that are part of the EU, the UK has agreed to bring GDPR into effect regardless of their exit from the European Union. Only personal data is effected by GDPR. Any data that allows a person to be identified or recognised constitutes personal data. Any operation or application of said data is considered the processing of data, for example, collection, recording, organisation, structuring, storage, adaptation and alteration. A Data Controller dictates how data shall be handled and which processes and operations may be applied, whereas a Data Processor carries out the processes and operations on behalf of the Data Controller.*

Six core data principles

  1. data should be collected for a specific purpose and not processed for incompatible purposes (purpose limitation);

  2. data held should be adequate;

  3. and not excessive (data minimisation);

  4. data should be accurate and up to date;

  5. data should notbe stored for longer than necessary;

  6. data should be processed securely.

Checklist for data processors

  1. What personal data will be collected? What part of it will be stored or processed in a blockchain?

  2. What processing personal data will undergo in a blockchain? What is the advantage of decentralising that process?

  3. What type of blockchain will be used? What is known about the validators in it? Can they be bound to a contractual agreement?

  4. If data is going to enter the blockchain encrypted or hashed, who holds the keys (or links to

  5. original data)?

  6. If the blockchain intends to support a certain type of transaction, are the identities of transactors inferrable from the contents of the blockchain? If pseudonyms are used, who holds the‘linking table’ back to data subjects?

Right to erasure

A key design feature of DLT Blockchain technology is the inability to alter or change data that has already been entered into the ledger and/or chain. Transactions following the initial may nullify said transaction, however, it will never be removed. The GDPR recognises a right to erasure. The right to erasure allows an individual to have their data removed if there is no feasible reason for their data to consider being processed that will benefit the individual. Although every individual has the right to erasure, it only applies under certain circumstances:

  • The data that was collected is now being processed for uses other than originally proposed.

  • When the individual withdraws consent.

  • When the individual objects to the current data processing that is occuring.

  • The data was obtained or processed illegally.

  • Data must be erased in order to comply with legal obligations.

  • The personal data is processed in relation to the offer of information society services to a child.

Erasure may not mean the removal of data, for instance, some Data Protection Authorities consider unbreakable encryption a form of erasure, in other words, if the data is inaccessible then they have been erased. Technically, Blockchains make erasure impossible due to the inability to remove data. However, smart contracts will control access rights, therefore, access rights could be removed, thus, enabling the erasure of said data. *

Selected GDPR terms

  • Processing Any operation performed on or using personal data, including collection, organisation, storage, adaptation, retrieval, use and transmission, among others.

  •  Personal data Any information relating to a data subject.

  •  Data subject An identified or identifiable individual in the EU.

  •  Controller A natural or legal person, public authority, agency or other body that, alone or jointly with others, determines the purposes and means of processing personal data.

  •  Processor Any natural or legal person, public authority, agency or other body that processes personal data on behalf of a controller.

  •  Special data A separate category of personal data that has additional legal protections and requirements. Special data rules apply to several categories of data, including racial or ethnic origin, genetic data, biometrics and data concerning health, among others.

HyperLedger 1.2 addresses compliance to GDPR

Hashing is not considered anonymized data, but pseudonymized data, since technically, hashes can be broken.  A bill of lading is fully anonymized, since it relates to companies not people.  Therefore, GDPR law clearly conflicts with the core technology of blockchain (as regards to personal data):

  •  all data is transparent to all members of the blockchain;

  • all data passes through all nodes in the blockchain whether public or private;

  • all data cannot be erased, since the very essence of blockchains is its immutability.

In the UK, it is currently acceptable to take private data, hash it, enter the hash in a block and keep the original document in the end user’s cloud.  If someone wants to be forgotten, the original is destroyed in the cloud, AND there is no way to replicate the original from the HASH, since it is a one way function.  There is some legal contention in this model, since someone may have another “original”, access the same hashing function and create the same hash (and then, you are no longer forgotten).

In each block there are two types of data:

  • Header: includes a date stamp, the identity of the source of the data (an address), and the previous block’s header hash, called ‘the pointer’;

  • Payload: the data to be stored. The header is not encrypted, only the payload is normally encrypted.

The hash in the header is of earlier blocks to create the immutable chain of blocks. The payload is generally a description of the document (metadata) and the hash representing the actual document.

HyperLedger Fabric uses “smart contracts” to manage the creation of blocks and who has access to them.  It operates as follows:

  • When X wants to upload a new document description to the blockchain, the smart contract will create a transaction by combining a description of the document and its hash to form a payload and add a header.

  •  The header plus payload equals a transaction and a validated transaction equals a block.

  •  Upon validation of the block, the smart contract would then send the document itself to the Y database system for storage.

  •  We assume that the Y database is off the blockchain and has limited access through the use of passwords.

  • The blockchain transaction will be proof that the document was uploaded at a given time, and anyone will be able to verify that the document held in the off-chain database is the same document as the one referred to in the blockchain transaction.

HyperLedger Fabric 1.2 provides a ‘GDPR Compliant', In-Built Solution Woven in to the Fabric.  Private data comes with the ability to create collections of data, but also use policies in order to interdict who has access to this data and who doesn't.

This access can simply be managed by adding policies: some data to be public and some to be private for some parties.

Blockchain & data protection

Under the GDPR, a data protection impact assessment is required for processing, which is likely to present a high risk to the rights and freedoms of natural persons. Blockchain projects can be roughly divided into three categories:

  • Specialised blockchain systems designed to process essentially non-personal data, such as bills of lading, letters of credit, or diamond certificates;

  • Specialised blockchain systems designed to process personal data, such as proof of identification, or even sensitive personal data such as medical records;

  • Non-specialised blockchain systems that can be used to process any form of data.

A data protection impact assessment is likely to be required for the second category of blockchain system, where processing personal data is the purpose of the system. In that case, regulators will expect the system to build in privacy protections, via data protection by design and default, to ensure that the system does not pose a risk to the rights and liberties of individuals.

*Courtesy “A guide to blockchain and data protection”, Hogan Lovells