GDPR liability: software development and the new law
The GDPR is comprehensive; its impact is far reaching, and the penalties for infringement are severe (up to €20 million or 4% of global annual revenue, whichever is higher).
In short, no impacted business can afford to ignore The GDPR. As the May 2018 deadline looms, organizations find themselves scrambling to be “GDPR ready” – but what exactly does that mean?
I’ve simplified the GDPR legalese (while preserving the links to the original regulation) to help answer this question from a development perspective. If I can convey just one point with this post, it’s that the GDPR is much more than an IT or operational responsibility.
If you’re following the GDPR and your organization develops software (directly or through partners – for internal use or external use), this post is for you.
GDPR Roles
The GDPR is organized around the notion of Controllers and Processors and the responsibilities and liabilities they share.
Responsibilities
- A Controller determines the “why” and the “how” of processing personal data.
- A Processor (or processors as the case may be) processes personal data for the Controller
(CHAPTER 1, General provisions, Article 4 Definitions)
Liabilities
The GDPR states that a person who has suffered any kind of damage (material or non-material) from a GDPR infringement has the right to compensation.
More to the point, processing systems that do not meet GDPR requirements (and therefore infringe) trigger GDPR liability for every user whose data is processed.
(CHAPTER VIII Remedies, liability and penalties, Article 82.2 Right to compensation and liability)
The cost of a single GDPR incident is too high for anyone to ignore. An infringing processing system has the potential to generate thousands – if not millions – of these incidents.
With this potential exposure, do processing system developers have any special obligations?
Processing system obligations
The GDPR mandates that processing systems include “appropriate” technical safeguards. For the GDPR, “appropriate” would consider factors like the state-of-the-art of hacking techniques and their corresponding countermeasures at any given time (implying an ongoing commitment to track and keep pace with developments in this area), the cost of safeguard implementations (time, money, other risks), as well as the relative likelihood and severity of any given class of data breach occurring.
In this sense, the GDPR is consistent with well-understood risk management practices that call for proportionate risk mitigation investments. For a discussion of these basic risk concepts in the context of application development, see The Six Degrees of Application Risk.
The GDPR amplifies these basic concepts and, by implication, expands the working definition of “infringement.”
Processing system infringement
The GDPR places a special importance on “ensuring ongoing confidentiality, integrity, availability and resilience of processing systems and services.”
In other words, the GDPR deliberately carves out obligations for the processing system implementer – not just for the owners and caretakers of the data that flows through those systems.
The GDPR goes on to state that special care must be taken in both assessing and proactively mitigating processing risks stemming from
- Unlawful destruction, loss, or alteration of personal data, and from
- Unauthorized disclosure of, or access to personal data transmitted, stored or otherwise processed.
GDPR Processing System Assessment
Extrapolating directly from the GDPR text, we can see that Controllers and Processors are responsible for implementing processing systems that
- Are secure, resilient, and reliable (trusted),
- Include controls to protect against unlawful and/or unauthorized access or disclosure of personal data, AND
- Include “state of the art” (up-to-date) countermeasures against current attack techniques.
The “appropriate technical and organisational measures” standard used throughout the GDPR needs to be extended to ensure that bespoke (custom) software includes the required GDPR safeguards.
GDPR Software Development Assessment
A Controller or Processor that develops components of a processing system must ensure that the code they write does not violate the GDPR obligations list above.
The development organization must be able to demonstrate that it has not – and will not – release software with commonly known, well-understood or otherwise avoidable software gaps or vulnerabilities.
Now that we have a notion of what GDPR compliance means for development organizations – how do development organizations get “GDPR ready” efficiently, effectively, and reliably?
I thought you would never ask!
For a general discussion, see Like magicians, hackers do not reveal their tricks – but we will.
