Permission on distributed ledgers – GDPR considerations
Katherine Kennedy, SETL General Counsel
8/22/2019
Quite a bit of ink has been devoted to inherent tensions between blockchain/DLT and GDPR. Most commentators acknowledge that whilst private, permissioned networks use the cryptographic techniques originally leveraged by Bitcoin to create ‘trust’ in a trustless environment, the ‘challenges’ posed by blockchain/DLT have less to do with the underlying technology and more to do with how it is used.
Unlike a public, permissioned network like Bitcoin, the SETL blockchain is designed as a private, permissioned network. As the group of users is closed, the network operator can require that all network participants commit to a set of legally binding rules, and enforce those rules. This little article examines four GDPR challenges which are surmounted by this model.
Is there any processing of personal data?
Of course the best way of ensuring compliance with the GDPR (or any other regulation, where possible) is to avoid falling under its remit altogether. If personal data can be kept out of the network, then it should. This may be possible for some financial services use cases – however it is not unusual for clients to require the technology to store the identity of the individuals requesting transactions. DLT seems almost tailor-made for Know Your Client use-cases within a private network, and is a popular element of SETL’s offering. Whilst the majority of the information processed is ‘business data’ (e.g. the work e-mail address or unique identifier of a fund manager), the GDPR does not distinguish between ‘business’ and ‘private’ information – it is all personal data. Similarly, whilst KYC information may be available online and therefore not secret (or ‘private’ in an American sense) – again this does not matter to the GDPR.
Controller/Processor Identification
The effect of the GDPR on an entity processing data is different depending whether the entity is a data controller or data processor (for those familiar with the old Data Protection Directive but not the GDPR, data processors now have liabilities of their own, and the old scramble to be classified as a ‘data processor’ has abated somewhat). A data controller is an entity that, alone or with another data controller, has primary responsibility over the processing of personal data, and who determines the manner in which, and the purposes for which, the personal data is processed. A data processor processes personal data on behalf of a data controller, under mandatory contractual provisions set out in the GDPR.
A private, permissioned blockchain, which supports the commitment by participants to a set of rules, enables the parties to clearly set out who can do what with personal data – i.e. who determines the manner and purpose of the processing. It is likely that participants submitting personal data to the network, and the network operator, will both be data controllers – possibly controllers in common depending on the data flows.
A permissionless distributed ledger, on the other hand, creates scope for argument about the role of the participants. Whilst it is clear that a participant uploading data to the network controls that data, it is not clear whether the other participants are controllers or processors.
Challenge 1 – Data processing agreements
If a network includes data processors, Article 28 of the GDPR requires data processors and data controllers to document the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects implicated by the data processor’s processing. Additionally, the Article 28 provisions require data processors to agree that, among other things, they will only process personal data on documented instructions from a data controller and will preserve the confidentiality of the data.
Challenge 2 – Joint data controller agreements
It is not possible to avoid Challenge 1 simply by deciding that all participants are joint data controllers. If an entity is processing personal data, then it must either be a data processor or a data controller. Article 26 of the GDPR obliges joint controllers to transparently determine how they will ensure GDPR-compliant treatment of data subjects’ personal data, and what each data controller’s relationship will be with data subjects. The joint data controllers must then make the essence of their arrangement available to data subjects.
Challenge 3 – Restrictions on transferring personal data out of the EEA
The GDPR provides that personal data may only be transferred outside the EEA only under certain specified conditions. Clearly this will be challenging in the context of a network where the geographic location of all of the participants is not determined. A permissioned network, on the other hand, enables control over the locations from which the network can be accessed. Where the blockchain has global application, the Article 29 Working Party has endorsed the inclusion of data protection clauses into multilateral agreements as a means to comply with restrictions on international data transfers.
Challenge 4 – Fair Processing Notices
Articles 13 and 14 of the GDPR oblige data controllers to provide data subjects with prescribed fair processing information (i.e. privacy notices). A clear governance framework enables network members to operate the network in coordination while clarifying each member’s role in the network – and therefore where the responsibility to provide the notification lies – as well as providing common agreement on the content of the information to be provided to data subjects. A UI-based system may provide an FPN to users at the point of login.
In short, blockchain/DLT, though using the technology developed for Bitcoin, if used in a private, permissioned environment does not require a great departure from existing ways of working for closed networks, and can therefore leverage the same compliance mechanisms. A permissionless network, on the other hand, poses compliance challenges which it can be difficult to see a way through.