See what API testing solution came out on top in the GigaOm Radar Report. Get your free analyst report >>

See what API testing solution came out on top in the GigaOm Radar Report. Get your free analyst report >>
Jump to Section
Organizations must comply with GDPR requirements to safeguard user data, prevent misuse, get users' informed permission, and be subject to severe financial penalties for noncompliance. Check out this post to learn for vital insights.
Jump to Section
Jump to Section
Since EU General Data Protection Regulation (GDPR) began enforcement on May 25, 2018, its real and severe penalties have been handed out. So, what is GDPR, to whom does it apply, and what happens when 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’s 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.
GDPR requires organizations to make sure that user data is well-protected and not misused. Users get informed consent. Noncompliance is met with big financial penalties
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 considers 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.
Fines. Fines are what happens. The EU can fine you daily 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
The California Consumer Privacy Act (CCPA) has similar goals to GPDR but differ mainly in scope since CCPA is specific to California, and GPDR the EU. In summary, the key differences are:
The State of California Department of Justice publishes their CCPA Enforcement Case Examples. Although details of company names and penalties aren’t shown, it’s clear enforcement is changing the way some businesses operate online. Some examples include:
GPDR enforcement is usually on a much larger scope than CCPA and the examples show the large difference in the scale and scope of the two regulations:
GPDR noncompliance can result in serious and severe penalties. The penalty framework is based on a maximum of 20 million Euros or 4% of global revenue, whichever is higher.
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’re 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.
With the aim to enhance individuals’ control and rights over their personal data, the regulation applies to any of the following based in the EU and EEA (European Economic Area, which includes Iceland, Liechtenstein and Norway):
A key aspect of the GDPR is that it applies to organizations based outside the EU if they collect or process personal data of anyone living in the EU/EEA, whether or not they are a citizen, and any EU/EEA citizen regardless of where they are living. As we’ve seen, the penalties are large and are often levied against technology companies outside the EU. Unfortunately, the scope of GDPR is large and is considered “light of specifics” by privacy experts. Compliance is especially daunting for small and medium-sized businesses.
The key definitions of GDPR relate to the individual and the organizations that collect, process, store, and transfer their personal data.
The GDPR is designed to protect the data of EU citizens and residents. It applies to any organization handling such data, regardless of whether they are based in the EU or not. This is known as “extra-territorial effect.”
According to Article 3 of the GDPR:
The GDPR applies to non-EU organizations that offer goods or services to people in the EU or monitor their online behavior. Regulators look for clues to determine whether the organization set out to offer goods and services to people in the EU.
For example, If an organization uses web tools to track cookies or IP addresses of people who visit their website from EU countries, then it falls under the scope of the GDPR.
There are exceptions, such as for “purely personal or household activity” and organizations with fewer than 250 employees might be excluded. Despite this, GDPR only applies to all organizations engaged in “professional or commercial activity” so many small- and medium-sized businesses might not be exempt from the GDPR.
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
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 that 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.
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 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
The key data protection principles of the GDPR are listed below.
Processing must be lawful, fair, and transparent to the data subject.
You must process data for the legitimate purposes specified explicitly to the data subject when you collected it.
You should collect and process only as much data as absolutely necessary for the purposes specified.
You must keep personal data accurate and up to date.
You may only store personally identifying data for as long as necessary for the specified purpose.
Processing must be done in such a way as to ensure appropriate security, integrity, and confidentiality (e.g. by using encryption).
The data controller is responsible for being able to demonstrate GDPR compliance with all of these principles.
An important aspect of GDPR is outlining and enforcing an individuals’ rights in relation to their use of websites, software, and products that might collect personal information.
Organizations must clearly inform and document how and what personal data is used.
Individuals have the right to correct inaccurate personal information.
All personal data is accessible by individuals and can be requested without charge.
Individuals can ask and be granted that all their data be removed, permanently.
Individuals can request that the processing of their data be restricted or suppression of their data.
Means that all data is obtainable from the organization and useable by the individual.
Individuals can object to their data being used for marketing purposes.
This restricts how much an individual’s data can be used by automated processes, including AI.
The GDPR defines a data breach as a “breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed”. This definition applies to both accidental and deliberate causes.
In simpler terms, a data breach under GDPR occurs when there is a security incident that compromises the integrity or confidentiality of personal data. This could be due to accidental or unlawful actions leading to the destruction, loss, alteration, unauthorized disclosure of, or access to, personal data.
The GDPR has specific guidelines regarding data breaches. According to Articles 33 and 34 of the GDPR:
An organization must report a data breach to a data protection authority (DPA), also known as a supervisory authority (SA), if there is an incident leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data that leads to a potential risk to people’s rights and freedoms.
If the breach could result in loss of control over their personal data, discrimination, identity theft or fraud, financial loss, unauthorized reversal of pseudonymization, damage to reputation, loss of confidentiality of personal data protected by professional secrecy, or any other significant economic or social disadvantage to the natural person concerned, the company is required to report the incident.
The data breach notification requirements are mandatory and time-sensitive under GDPR. Organizations must report personal data breaches to the relevant supervisory authority within 72 hours of becoming aware of the breach.
Failure to notify a data protection authority of a breach can result in a fine of €10 million ($11.3 million) or 2 percent of a company’s global turnover.
Compliance with the GDPR means that an organization meets the requirements for properly handling personal data as defined in the law. Given its legal status and severe penalties, compliance requires serious attention for organizations that collect, process, and store personal information, which, includes most commercial websites but also encompasses applications and physical products.
The key aspects that organizations need to embrace include the following:
GDPR has a large scope. There are some key principles that software developers can follow today to reduce the overhead and workload needed for compliance.
Here are some initial steps that software developers can take to ensure GDPR compliance.
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.
It’s a little bit scary, and in some sense, it should be, given the potential financial penalties. But overall, it’s 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.