Much of the discussion to date around blockchain and distributed ledger technology (DLT) has been about making data more secure. This is unsurprising given that the technology is designed to ensure:
Further, it is not always clear whether the application environment in which DLT is intended to operate enables compliance with related privacy regulation. For example, GDPR Articles 12 – 22 set out data subject rights including rights of access, rectification, erasure, restriction and portability. The blockchain principle of immutability referenced above would seem to run contra to these data subject rights, if personal data is included in the blocks that make up the chain.
The use of "on-chain and off-chain" deployment models, is an example of how areas of potential regulatory non-compliance can be addressed. This type of hybrid deployment model could be used to keep part of the transaction on-blockchain and any personal data processing off-blockchain. One possible use of on-chain off-chain blockchain technology is identity verification. Where an organisation is subject to know your customer (KYC) regulations, blockchain and DLT technology could be used to verify a prospective customer's identity, without the need to collect, store or process any personal data to verify such identity.
In this case, the personal data required to validate an individual’s identity, will be confirmed by a trusted third party and held by the individual in an encrypted digital wallet. The organisation wishing to verify the customer’s identity for the purpose of KYC, would use public key/private key authentication to verify the individual’s identity, without ever having to further process this personal data in the form of identity checks with for example, credit reference agencies.
A digital identity solution of this kind would be very attractive to organisations who might wish to supply or market goods and services to consumers, but who are also keen to ensure, to the greatest extent possible, that their KYC processes remain outside the scope of the GDPR and other related data privacy legislation. However, this would require the organisation to "trust" the validity of the personal data held in the digital wallet, so some form of authentication or certification of trusted third parties would be required.
Does this not then defeat the purpose of blockchain and distributed ledger technology if not all data is stored on the blockchain and the very information that is most important to protect i.e. personal data for the purposes of identity verification, still sits on a centralised database albeit with a ‘trusted third party’?
When embarking on a software or application development project, a key consideration should be the development methodology to be used. Generally, the commissioning party ("the customer") will have the choice of an "Agile" or "Waterfall" style of development. The methodology selected by the customer will often depend upon whether the customer wishes to have flexibility during the development cycle, or whether it wishes to agree a detailed set of business specifications and technical requirements before the developer begins work. The choice made will of course inevitably have legal and commercial implications. These implications should be identified and addressed in a software development agreement between the customer and the developer. Some of the factors to consider in making the decision are set out below.
Agile software development methodology allows the customer to develop its requirements during the project phase in short, frequent development cycles. Agile development is flexible and scalable; it enables the scope of a project to be changed based on feedback received during these short development cycles. In short, the specifications can be changed post contract signature, without the need to follow a strict and potentially time consuming change control process. However, this does not mean that the parties should abandon recording any agreed changes to the high level specifications agreed at the very beginning of the project.
Therefore, if you are a customer thinking about using Agile you should ask yourself:
Waterfall software development methodology is focused on agreeing a detailed set of business requirements and technical specifications prior to the commencement of work. Detailed documentation is required for each project phase, including technical specifications, which set out measurable deliverables and performance criteria.
If you are a customer thinking about using Waterfall you should ask yourself:
It is also possible to use a mixture of Agile and Waterfall during the development. For example, the early scope and analyse phase of the project could be completed using Waterfall, whilst Agile development principles are applied to later or selected phases of the build. In these circumstances care must be taken to ensure that the correct contracting principles are agreed and applied at the appropriate stages of the development. For example, the point at which testing and acceptance should occur may differ depending on which methodology is used.
Although, Agile is flexible and collaborative, it does not equal "zero paperwork". It is still advisable (for both parties) to agree: a contract, project plans, interface designs and technical specification documents. After all, you would not embark on a software development project based on the Waterfall methodology without addressing issues concerning project governance, deliverables, testing and acceptance, warranties, cost and IP ownership - to name just a few. Agile is not a "free for all" in terms of scope and scope change, so organisations should still consider all of the above even when using the Agile methodology.
GDPR Article 35: Pop up Quiz! Do you know what this section of the new Regulation requires companies to do if developing new products and services (including software) could result in a "high risk" to individuals?
To find out or to arrange your free one hour initial consultation please contact us.
The introduction of Regulation (EU) 2016/679, otherwise known as GDPR ("the Regulations") has resulted in significant changes to the UK and European data protection landscape.
As businesses large and small consider the practical and operational implications of these changes, an interesting aspect might be the relationship between the providers of cloud services and their clients. An example, of this can be seen in Article 28 of the new Regulations, which sets out a prescriptive and detailed set of data protection obligations that controllers are required to contractually impose on their processors.
Of course, under GDPR the client would normally be the controller of personal data, and the cloud provider its processor. At a time when businesses are increasingly reliant on cloud computing services, the provisions of Article 28 will create an interesting challenge for small businesses who as controllers, are now required to ensure the detailed list of obligations required under Article 28 are included in their cloud services contracts.
One particular obligation under Article 28(2), is that the processor must provide the controller with notice of any sub-processors it wishes to appoint and the controller will have the right to object. Typically, large cloud providers are reluctant to move away from their standard terms of business, and many adopt a "take-it-or-leave-it" position in contract negotiations, in particular with respect to their preferred sub-processors. However, European data protection supervisory authorities have indicated that an inequality in the bargaining position between a cloud client and its supplier will not release the small cloud client from its obligations under Article 28.
Therefore, a careful review of the terms of their cloud services contracts by all cloud service clients is strongly recommended. It also goes without saying that as a result of Article 28 of the Regulations, cloud providers used to operating under their standard terms, will in future be required to display a greater degree of flexibility when negotiating contracts with prospective smaller clients.
Please contact us if you require legal advice or would like to find out more information about our services.
Blockchain or distributed ledger technology, has the power (its supporters say) to transform the processes traditionally used by banks, power supply companies and logistics providers to name but a few.
In fact, the technology is potentially suitable for any business process which operates in a pre-arranged, methodical and organised basis. Transacting in real estate and securities would be other good examples. It even has its uses in intellectual property as a method of verifying the authenticity and ownership of works of art, authorship, creation and design. From a data privacy perspective there is potential for application of blockchain technology to verify an individual’s identity, without the need to process that individual’s personal data.
The reported key benefits of blockchain technology include:
Despite these benefits, blockchain technology is still viewed with a mixture of caution, and interest by many regulators. Particularly sectoral regulators in the areas of data privacy and financial services. For example, when used as the underlying technology for processing bitcoin payments, the non-application of existing regulations such as the Electronic Money Directive and the Payment Services Directive (which only applies to "real" money such as banknotes and even electronic money as defined by the EMD) raises real consumer and business protection concerns.
From a data privacy perspective, it is not always clear whether the distributed nature of blockchain servers/nodes across multiple jurisdictions, enables or facilitates compliance with international personal data transfer requirements under GDPR and related data privacy legislation.
From a business technology perspective, any organisation considering utilising blockchain technology as a means of working with its customers and suppliers, will have to commission the development of systems be it with a blockchain development company or by sourcing “Blockchain-as-a-Service”.
In either case consideration needs to be given to the contracts entered into with the service providers to ensure that requirements are clearly identified and linked to a business goal, liability appropriately limited, privacy issues addressed and intellectual property position in terms of ownership agreed. As you can imagine these considerations will differ depending on whether an organisation sources to develop its own blockchain solution or utilises a cloud service.
In summary, as sexy as blockchain technology sounds with its many potential applications and ability to disrupt traditional business processes, organisations wishing to transition to blockchain technology should still consider the usual run-of-the-mill, but indescribably important contract, legal and regulatory matters forming part of any well-run IT transformation project.
Please contact us if you require legal advice or would like to find out more information about our services.