GDPR liability: software development and the new law

August 16, 2017 4807 Views Sebastian Holst

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.

(CHAPTER IV Controller and processor, Section 1 General obligations, Article 25 Data protection by design and by default)

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.

(CHAPTER IV Controller and processor, Section 2 Security of personal data, Article 32 Security of processing)

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.

Latest Blog Posts

Dotfuscator 6.0 Beta: Entering the Next Era of Dotfuscator

Today we're announcing the first new major-version release of Dotfuscator in thirteen years: Dotfuscator Professional 6.0 Beta. It's an exciting new release with major new capabilities, but before we get into that, let's take a look at why it's been so long since we had a major release and why we're choosing to do one now.

For development teams, adding Dotfuscator to a build pipeline can often seem like a challenge; the value it adds is mostly gained by the surrounding business, and the cost of adding it is mostly borne by the development team. We understand that constraint, which is why we focus on making Dotfuscator as easy to integrate and maintain as possible. If you're a long-time user of Dotfuscator, you've probably experienced that - release after release of painless upgrades. That's our "first do no harm" philosophy in action.

The dynamic type in C# provides flexibility that is not available in other statically-typed languages. Since its introduction in C# 4.0 (.NET 4.5), we have worked with customers who wanted to know more about how dynamic types are impacted by the obfuscation process.

Malicious actors — like any thieves — live by a simple rule: If the front door is locked, break the window.

It’s why threats like fileless malware and crypto-jacking have seen substantial gains over last few years. It’s why — despite increasing employee education and IT training — hackers are still hooking phish by developing more sophisticated and authentic-looking email spoofs. Cybercriminal communities, meanwhile, continue to grow on the dark web, allowing attackers to share info, purchase exploit kits and identify potential targets.

What does this mean for CISOs? That typical defense efforts are being outpaced as familiar attack vectors are replaced with non-traditional threats. But it’s not all bad news; here are three questions every CISO needs to ask to help close the doors, bolt the windows and leave hackers out in the cold.

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

Our customers build a lot of really innovative apps that enable their users and customers to do new and cool things. These apps frequently run on untrusted client computers/devices and they control access to customer’s sensitive data or critical devices.

And after all the effort of designing, building, debugging, and deploying their applications, the last thing they want is for an attacker to steal their work or use it to look for vulnerabilities to break into their system.

Long ago, we built a Java code optimizer, but it became clear to us that our customer cared more about the obfuscation effects of the optimization than the actual performance improvement. That is when we really began to focus on app protection. First with Java, then .NET, Android, iOS, Xamarin, JavaScript, etc.

Gartner calls In-App Protection “crucial” in their July 2019 Market Guide for In-App Protection In-App Protection. The guide’s summary advises security and risk management leaders to “take due care in protecting their application clients” in order to avoid “security failure.”

This raises the question – what constitutes “due care?” Obviously, no development organization looks to recklessly expose their applications or sensitive data to attack or compromise. On the other hand, over-engineered (or poorly engineered) security controls can quickly lead to excessive development costs, performance and quality issues, and, ultimately, unacceptable user experiences. While terms and terminology may vary, there is broad consensus on how to best define “due care” for any given application/user scenario.

GDPR liability: software development and the new law

GDPR Roles

Responsibilities

Liabilities

Processing system obligations

Processing system infringement

GDPR Processing System Assessment

GDPR Software Development Assessment

Dotfuscator 6.0 Beta: Entering the Next Era of Dotfuscator

Protecting C# Applications That Use Dynamic Types

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

The Secret to Effective In-App Protection

Latest Blog Posts

Dotfuscator 6.0 Beta: Entering the Next Era of Dotfuscator

Introducing JSDefender: PreEmptive Protection now includes JavaScript

Protecting C# Applications That Use Dynamic Types

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

Twitter