Any data provider worth their salt must be aware of the legal considerations and regulations for their zone of operations. How user data is stored and processed is controlled by a wide range of regulations, and understanding these regulations is key to running a compliant operation. The EU GDPR is perhaps the most sweeping regulation set on privacy that the industry has ever seen.

The General Data Protection Regulation (GDPR) is chiefly designed to enforce privacy over EU data. Though the data protected might be EU-specific, the EU is in no way the only group impacted by such legislation – the GDPR is effectively a global regulation, and failure to meet these GDPR regulations can be expensive – not to mention dangerous.

Accordingly, with a compliance date quickly approaching, you must act now. Today, we’ll describe the intricacies of GDPR, then dive into 5 steps to GDPR compliance that any organization – regardless of size, purpose, or history – can incorporate into their data protection scheme.

As web APIs are at the heart of transferring and storing data, much of it personal, it is imperative that all providers understand the implications of GDPR. For one, you may be storing way too much data than you need to…

What is the GDPR?

The GDPR, or General Data Protection Regulation, is a wide-ranging regulation from the European Parliament, the Council of the European Union, and the European Commission. The GDPR was designed to replace the data protection directive, officially known as Directive 95/46/EC, which was an older and somewhat obsolete data protection directive from 1995.

The GDPR is enforceable from May 25th, 2018, and overhauls the methods for how data is collected and protected. The intent of the GDPR is to establish a single, unified set of rules across the EU to harmonize regulations on security, and establish a more secure data ecosystem.

What Protection Laws Are Part of the GDPR?

The chief concern of the GDPR is to protect personal data. The GDPR defines personal data as information relating to a person who can be identified, either directly or indirectly, by such data. This data can include a wide range of types and values, ranging from identification numbers to location data, economic data, financial data, to social identities, and more. This data can be as highly specific as social security information, and as general as IP addresses and cookies.

Controllers and Processors

The GDPR regulation separates responsibilities between two chief parties – Data Controllers and Data Processors. Controllers and Processors are both required to “implement appropriate technical and organizational measures”, and to take into account “the state of the art and costs of implementation”.

Ultimately, Controllers and Processors are required to treat their data as highly important, as extremely secure endpoints. In fact, the GDPR requires both Controllers and Processors consider “the nature, scope, context, and purposes of the processing as well as the risk of varying likelihood and severity for the rights and freedoms of individuals.” (source).

Data Protection Officers

Larger scale entities, especially those who might deal with mass amounts of data, such as research firms or payment processors, must appoint a Data Protection Officer under the GDPR. These officers are required to have expert knowledge of both the GDPR data protection regulation and of general data protection practices, and are considered the “responsible entity” for data security in general.

The actual level of expertise as required by the GDPR should be, accordingly to the regulation, appropriate for and particular to the data processing operations the organization carries out, and should support the protection methods and standards required for personal data as processed and managed by the Controller or Processor.

It should be noted that the existence of such an officer is largely mandated for organizations dealing with large scale data, and because of this, larger organizations will likely already have such an officer in their executive team that will meet this requirement. Smaller organizations and their APIs will likely not run into this requirement due to their much more limited, isolated scope of data collection range.

Privacy and Consent

The GDPR is concerned chiefly with a risk-based approach to maintaining data privacy. All of the measures and risk assessments ordered by the GDPR are made with the concept of keeping data subject rights intact – this has been the entire focus of the GDPR from day one, and is otherwise known as “Privacy by Design”.

As part of this concept, consent is a huge piece of the puzzle, informing every action taken by the data provider. Consent is required of all data subjects to ensure that they are not only aware their data is being collected, but that their data is also being handled and protected in an adequate manner. Subjects should also be told why their data is being collected, as well as for what duration said data is kept – ultimately, subjects should be the owners of their own data, and be given controls over that data regardless of who is currently using it.

Data should only be collected, according to the GDPR, under terms that are specific, explicit, and legitimate. Consent should likewise be collected under these strict guidelines, and should be demonstrable – this consent should be recorded alongside information as to how it was collected, and should be stored to prove this consent in the future. Consent should be freely given – data not required for the contract cannot be demanded as part of this consent. Perhaps most importantly, this consent should be optional and under the subject’s control – it should be able to be rescinded.

Breaches, Notifications, and Sanctions

The GDPR is a directive – it has teeth in enforcement. First and foremost, the GDPR requires a mechanism for alerting users when a data breach has occurred, and demands that such a notification occurs without “undue delay,” and when possible, “not later than 72 hours” after the provider has become aware of such a breach. If the time between breach and notification is greater than 72 hours, the provider has to provide a reasonable justification for why it took so long.

Failing to meet the GDPR is when fines come into the picture. Up to 20 million Euro or 4% of the annual worldwide sales are held as the maximum penalty for breaking the GDPR – this is not even to mention the fact that data subjects are provided a mechanic for civil suits against the organization responsible for the breach and the data exposed.

This might seem excessively large, but it should be contextualized with the fact that such penalties are not applied lightly, and are not universally applied for every situation – first time, accidental breaches are likely to be treated much lighter than those who willfully defy regulations out of greed and willful negligence.

Does the US and Non-EU Entities Have to Comply?

Perhaps a key question in this entire conversation is: do non-EU companies have to comply with the GDPR? Because the regulation has to do with data concerning EU citizens specifically, many seem to think that the GDPR is only concerned with EU operations. The simple fact is, however, that international organizations are just as likely to use EU data as they are US or SEA data – accordingly, if an organization does any business whatsoever in the EU or using data from EU citizens, their compliance is required.

How Does the GDPR Affect APIs and their Data?

All of these regulatory issuances add up to one specific requirement – improved user data security and limited collection. This has been a common security suggestion for years, and it bears repeating – collect only what you need, and lock down what you’ve collected. Until now, that has merely been a suggestion – many providers have often collected more data than they’ve needed, with punitive responses by regulators only being discussed during security breaches as part of suits brought against exposing organizations.

Now that the EU has enacted this more stringently, the relatively lax regulatory limitations on collection that US companies have enjoyed are now going to be subject to the EU regulations if those organizations do business in the EU. Accordingly, if your API uses EU data whatsoever, or ever wants to expand beyond their local regional data stores, you WILL need to adapt to the GDPR and ensure compliance.

5 Steps to GDPR Compliance

Now that we understand the GDPR, we need to ensure compliance. While it might seem daunting to reach this level, the fact is that, through a few simple steps, even the largest, most complex APIs can ensure compliance.

1 – Audit Organizational Requirements

Before anything else, the organization must be audited to see what is collected in terms of user information. While much of the data collected in modern applications has just broadly been considered part of analytics, much of this data is now covered in the GDPR, and should either be secured with greater focus on security or removed from collection entirely.

Providers should look at what data is collected from a holistic point of view, and restrict such collections to only what is needed. Many APIs, especially those forked from other development projects, may by default collect much more than is needed.

Accordingly, figuring out the organizational requirements of your API, and either increasing security methodologies or limiting the scope of collection, is key to complying with the GDPR – and in many ways, is the lowest cost-effective solution, all things considered.

2 – Understand the System

Not all collection of data will originate from a known source. With the GDPR, failing to note these additional sources and properly deal with them is negligence. API providers often use heavily versioned or mutated versions of their codebase, and as such, there are often many undocumented endpoints, buggy systems, and more that collect data without the user or the provider being aware of such collection.

This process is generally considered “data discovery”, and is key to ensuring compliance. While limiting your collection from an organizational standpoint is a first step, it means nothing if you are also additionally collecting mass amounts of data with little understanding of the mechanics behind such collection.

Perform data discovery, and check every single endpoint, every internal component, and ensure that the data you are collecting is what you think it is. With the first step, and now this second step, your data collection should be understood and well-managed, addressing the largest hurdles for compliance.

3 – Assess, Document, and Resolve Risks

With an organizational audit in place and a greater understanding of the system as whole-formed, risks and vulnerabilities to data should be assessed for their potential damage and exposure. These should then be documented, both in terms of where the risk is, how it was discovered, and what is being done to mitigate them

The reason to document vulnerabilities is two fold. First, fines and other punitive measures are largely issued to those who maliciously or negligently ignore regulations – having proof that the entity is aware of risks and went out of their way to mitigate them will go a long way to proving that any breach was not due to negligence, but instead of circumstances beyond the entity’s control. Additionally, mitigation should be guided by an audit-able process to ensure compliance and conformity with the GDPR to ensure risks are at least minimized, if not eliminated.

Ultimately, the resolution of risks within the system will go a long way towards securing the system as a whole, and GDPR or no, this is likely a process providers should go through regardless.

4 – Secure Critical Data and Processes

This step is important, but to think of it as chiefly applied to only the GDPR is not true – securing critical data and processes is chief to the daily operations of any organization.

Providers should look at all critical data and processes, and immediately secure them to the highest appropriate levels possible. A good mantra for this step is this – if you think you’re being overzealous with security, you are likely meeting the minimum requirements of the GDPR.

Start with your core assets – financial data, federal information, addresses, etc. should be secured as stringently and diligently as possible, as they are in many ways the most important data that is collected. From here, branch out to less important, but still critical data, such as IP address and location information. These may not need the same stringent security controls, but they should still be heavily secured with appropriate mechanisms.

5 – Revise, Repeat, Revise

Once you’ve completed the initial four steps, repeat the processes. If you introduced any external solutions or internal fixes in the third and fourth steps, they could create their own issues, or reveal undiscovered ones. Therefore, reiterated checking is required.

Running through the process again, and capping it with a simple audit to ensure compliance, will help to catch any straggling issues and holes in security. While this might seem excessive, many bugs and issues in common implementations don’t arise because they were part of the first codebase, but are instead the results of hot-fixes, new features, and additional versioning. The same rings true in APIs, and as such, secondary or even tertiary checks are required to ensure total compliance.

Conclusion

Ultimately, if an organization does any amount of business that relies on EU clients, adopting the GDPR regulations and considerations is not a choice – it’s a matter of requirement. Adopting such regulations will become even more important as big data gets bigger and core collection practices grow more prolific – accordingly, taking a few simple steps now and securing data to the GDPR regulations will go a long way towards mitigating any additional cost in time and effort down the road.