Five Things You Need to Know About GDPR

GDPR requires organizations to make sure that user data is well protected, not misused, users are given informed consent, and non-compliance is enforced by big financial penalties.

Winter is coming. The EU General Data Protection Regulation (GDPR) will begin to be enforced on May 25, 2018. In fact, if you go to the GDPR web page, you’ll see a countdown to the enforcement clock there. It’s real and it’s coming soon. So, what is GDPR, to whom does it apply, and what happens when if you run afoul of its regulations?

You can read the official regulations and try to understand what they mean, but it’s rough. It’s full of little gems like this:

“A group of undertakings should cover a controlling undertaking and its controlled undertakings, whereby the controlling undertaking should be the undertaking which can exert a dominant influence over the other undertakings” (GDPR Article 37)

…You can’t make this stuff up!

So I thought it would be helpful to break it down, at least from a software perspective, and see what the key issues are that you should understand. If you see that it is going to affect you, you’ll definitely want to take a deeper dive. GDPR will end up touching many parts of your organization, and you’ll want to get it right.

GDPR requires organizations to make sure that user data is well protected, not misused, users are given informed consent, and non-compliance is enforced by big financial penalties. For more information, read on.

What is GDPR?

GDPR is all about protecting the data of citizens. This means protecting access to the data, not storing data you don’t need, encrypting personal data, and anonymizing data when possible. In other words, all the steps you can take to limit the possibility of a data breach and the impact when a breach does occur. In addition, privacy includes unauthorized uses of data, like tracking users without their consent and any other use of data without explicit consent.

From their website itself, GDPR “was designed to harmonize data privacy laws across Europe, to protect and empower all EU citizens data privacy and to reshape the way organizations across the region approach data privacy.”

GDPR also takes into account the general EU “right to be forgotten” which means in this context that if someone wants their data removed from your system it must be done within a reasonable timeframe. Additionally, there are strict reporting requirements – you can’t have a breach and hide it, like has happened several times recently in the USA.

Let’s take a look at the 5 main issues below.

1. Who needs to follow GDPR regulations?

Of course, companies in the EU need to follow GDPR, but as it turns out, even if you’re located elsewhere, if you have customers in the EU, then you are also subject to GDPR.

If you’re not storing any personal information, this will be easy, but anyone with EU personal data must follow the guidelines. The same is true if you have employees in the EU.

It sometimes gets a bit tricky if you’re sharing user data or getting user data from elsewhere. If someone exercises the right to be forgotten, you must chase down all those shares and erase the data everywhere. So even if you’re getting data from someone else who is handing over EU personal data, you can be subject to the guidelines.

2. Consent and Transparency

GDPR states that users must consent to having any data about them collected, and that this consent is based on “a clear affirmative act.” Clear and affirmative means that the user must perform an action to opt-in rather than the common “you’re in unless you opt-out” methodology.

“For consent to be informed, the data subject should be aware at least of the identity of the controller and the purposes of the processing for which the personal data are intended.” (GDPR Article 42)

On the web, a good example is a sign-up form that has a notice that data is going to be collected, what data it is, how it will be used, how to later opt-out (or be forgotten), and then the user must do something to agree, like click a checkbox. The days of pre-checked boxes no longer apply – the GDPR specifically forbids such currently typical methods:

“Silence, pre-ticked boxes or inactivity should not therefore constitute consent.” (GDPR Article 32).

The use of the data must have some purpose related to why the data is being gathered and must be explained to the user:

“It should be transparent to natural persons that personal data concerning them are collected, used, consulted or otherwise processed and to what extent the personal data are or will be processed” 
(GDPR Article 39)

3. Controlling personal data

EU citizens are granted full control over their personal data, including access, transfer, correction, and the right to be forgotten, including “mechanisms to request and, if applicable, obtain, free of charge, in particular, access to and rectification or erasure of personal data and the exercise of the right to object.” (GDPR Article 59)

The right to access to one’s data is based on GDPR Article 63, “A data subject should have the right of access to personal data,” while the right to have corrections to the data made is in GDPR Article 65, “A data subject should have the right to have personal data concerning him or her rectified.” Think about this the next time you’re fighting a credit reporting agency, and you’ll wish it applied to your own data.

GDPR further ensures that there are no vendor locks on user data. The right to transfer data is also enumerated:

“the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller.” (GDPR Article 68)

This means that you can get your data from a vendor in a reasonable digital form so that you can move it to a different provider.

The right to be forgotten extends to organizations with whom data has been shared:

“the right to erasure should also be extended in such a way that a controller who has made the personal data public should be obliged to inform the controllers which are processing such personal data to erase any links to, or copies or replications of those personal data.” (GDPR Article 66)

In other words, the erasure must cascade.

If you get data about a person from another organization and are going to use it and/or store it, you have to notify that person – so that they can give informed consent (see GDPR Article 60,61). This is also true if you decide to use the data in a way which was not included in the original consent.

“Where the controller intends to process the personal data for a purpose other than that for which they were collected, the controller should provide the data subject prior to that further processing with information on that other purpose and other necessary information.” (GDPR Article 61)

And watch out for fully automated algorithms like loan applications:

“The data subject should have the right not to be subject to a decision, which may include a measure, evaluating personal aspects relating to him or her which is based solely on automated processing and which produces legal effects concerning him or her or similarly significantly affects him or her, such as automatic refusal of an online credit application or e-recruiting practices without any human intervention” (GDPR Article 71)

If you’re using fully automated algorithms to make decisions this one can trip you up.

4. Data Protection – manage and defend

Once you’ve got someone’s data, you need to properly manage and protect it. The real key to this is what is known as “Personally Identifiable Information” (PII). PII has a very broad definition – for example, cookie IE, directly or indirectly identifying an individual including IP address. If you’re doing any kind of web analytics, you are collecting PII and need to make sure what you’re doing complies with GDPR.

One of the key aspects of handling PII in GDPR is the concept of secure by design. The regulation states:

“the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default.” (GDPR Article 78)

The secure by design methodology is a way of saying that you cannot simply test security and data protection into your application. Rather than build some code and try to red-team test it, you need to design the application to be secure in the first place, so things like encryption are the default to be turned off only on approved exception. Secure by design means getting serious about static code analysis as well, with a big emphasis on software engineering standards and “preventative” static analysis rules.

And if you’re collecting health-related data you need to be extra careful to secure it, (see GDPR Article 53), although there are some provisions for certain kinds of research if it’s about health rather than marketing opportunities (see GDPR Article 54).

Data retention is another important issue when collecting and storing PII. The main principle here is to retain data no longer than necessary:

“…the right to have his or her personal data erased and no longer processed where the personal data are no longer necessary” (GDPR Article 65).

In other words, data that you only need for transitory purposes, like completing a transaction, should only exist for the amount of time required. After that you should purge the data, rather than store it for convenience or future analytics.

It’s important to show that you actually need the data being collected as well:

“a data subject can reasonably expect at the time and in the context of the collection of the personal data that processing for that purpose may take place” (GDPR Article 47)

And later on, you can’t just use the data for something else, unless that something else is related to the original use of the data and/or processing (analyzing) the data.

“The processing of personal data for purposes other than those for which the personal data were initially collected should be allowed only where the processing is compatible with the purposes for which the personal data were initially collected.” (GDPR Article 50)

5. What happens when violated?

Fines. Fines are what happens. The EU can fine you on a daily basis for continuing violations. The amount of the fine can be based on the revenue of the parent organization, so it may be bigger than you think. Fines vary based on which regulations were violated, and can be up to 20 million EUR. Make sure that you can prove compliance.

“In order to demonstrate compliance with this Regulation, the controller or processor should maintain records of processing activities under its responsibility.” (GDPR Article 82)

So what do you do?

I’d love to tell you that there is a silver bullet tool or set of tools that you can use to simply comply with GDPR, but that’s just not the case. However, Parasoft can do a lot to help you out. First, you can use our static code analysis engines for Java, C/C++ and .NET with good security and privacy configurations to make sure that your code is a secure as possible. You can even configure them to enforce strict coding policies, like encryption by default.

Second, you can use service virtualization to drive complete end-to-end testing, even at an early phase on the developer desktop. Being able to fully test what happens to the data without having to have expensive test labs available makes it much easier to comply, and by allowing developers to perform deeper testing, you’ll find problems earlier when they’re easier and cheaper to fix.

Summary

It’s a little bit scary, and in some sense, it should be, given the potential financial penalties. But overall, it’s actually not that horrible unless your business model is based on tracking users and selling their data. If you have a typical business model and have customer data and sales, you will find compliance isn’t a huge headache, and will have the added benefit of making your overall system more secure in a world of increasing data breach frequency. Set the right policies in place, employ thorough, comprehensive testing, and ensure your data privacy with strong static code analysis.