In this series of articles I will be looking at the new data protection regulation (GDPR) that come into force in the UK and Europe in the spring. I will be examining how GDPR will affect the development and design of organisational information to comply with the GDPR's "data protection by design" requirement.
In the last article I pointed the way to the general resources that an organisation should be using to learn more about GDPR. I also mentioned the importance of an organisation's information systems, as they form a key part of moving towards compliance in time for the 25th May 2018.
It is a fact of life that whatever the size of the organisation it is likely that the information systems that support the running of that organisation will be too complex to be fully understood by any one individual. Usually tasks of maintenance and knowledge regarding the architecture and precise mechanism of the systems is shared between an organisation and some form of system maintainer. In some cases this will be because a smaller organisation is subscribing to some kind of SaaS stack, or because the organisation has a bespoke system in place maintained by a third-party contractor.
The relationship between the contractor and the organisation in all cases seeks to run along the lines of a partnership. Even SaaS platforms prioritise communication with subscribers that is collaborative, every system is backed by some kind of community.
The part of any information system that appears to have the most overlap with the concerns of the GDPR is the data store. Under the current DPA the onus is on the data stored by the organisation, its accuracy and a basic level of transparency about why they have it and what they do with it.
What is causing an air of mild panic when it comes to the GDPR is that the focus has changed to include aspects of how data is processed in addition to what that data is. Central to this re-focus is the re-definition of the role and responsibility incumbent upon data processors.
To put this in context, data protection law has always included the concepts of “Data Controller” and “Data Processor”. The ICO's Guide to the GDPR defines the former as the party that "determines the purposes and means of processing personal data". In plain English the controller is the party that requires the store of personal data in order to function. In plainer English the organisation that uses the personal data in order to function is the Controller.
From the perspective of a software development consultancy like Digital Morphosis all our clients are the Controllers of the data that they possess. This concept hasn't changed since the DPA. Essentially, we should advise on specified system requirements that expose a liability risk from a DPA point of view. If we were told to implement that requirement any way we were previously somewhat insulated from the responsibility for breaches that resulted from that requirement’s implementation.
This will change at a fundamental level when the GDPR comes into force. The GDPR redefines the concept of data processor. Under the GDPR the processor can now be identified as non-compliant separately to, or, more likely, along with, the data controller.
The ICO defines the data processor as the party "responsible for processing personal data on behalf of the controller". In fact, we are not the sole processor for our clients, as you can probably guess from the definition. We are one of a number of processors, some internal to our client's organisation and some, like us, external.
As a processor, under Article 28 of the GDPR it is required that we provide a guarantee to "implement appropriate technical and organisational measures in such a manner that [any processing we do] will meet the requirements of [the] regulation".
In the case of a software consultancy, as we are, the amount of actual processing/handling of personal data that we will do is limited to begin with. It is our job to diagnose system problems, and possibly to fix data if required.
Other than that what we do is provide controllers with their data containers and to give them the means to process that data lawfully and efficiently. For our part we have to guarantee you, the client, that we will handle any of your data safely and that the systems we provide will be compliant with the GDPR.
It is this latter requirement that should be the priority of anyone involved in bespoke system design. Our chief focus, something we have to guarantee our clients, is "Privacy By Design". This concept will be the subject of the next article in this series.