A few days ago, I saw an article that began with the words “Now that the GDPR is over”, which is pretty reflective of an idea that’s surprisingly common — that post May 25th the GDPR is no longer an issue. This couldn’t be more wrong.
“GDPR day” was simply the date that it became legally possible to enforce the GDPR and to issue punishments and sanctions where violations occur. With that said, the GDPR is absolutely a concern for Startups — whether you’re just about to get started or already launched, but didn’t get everything in order by May 25th — this is definitely something that’s more relevant than ever.
If you are a startup (or any business really), the GDPR should make you think about how you manage your data in a transparent, responsible, and accountable way — showing and ensuring that you’ve put the right systems in place to manage user data securely.
Despite the initial effort, this can actually be a good thing (especially for startups).
In a time where iterative development has become increasingly popular (and with good reason), this regulation pushes us to pay attention to the undeniable fact that we’re responsible for people’s data and forces us to think about and design the data lifecycle in a minimalistic and responsible way.
This can be further useful for new/unheard-of companies as it gives the opportunity to build trust and make that a feature of your branding.
The meat of the matter
There’s no point talking about the GDPR without talking about the biggest motivating factor for compliance —
If you’re not already aware, the consequences of non-compliance are pretty steep.
A first-time violation may or may not get you a warning. If you fall within the “may not” category, you’re looking at up to EUR 20 million (€20m) or 4% of your global revenue (which ever is more), and that’s not all. You can be audited, which can result in you being barred from making use of valuable data if some aspect of your data life-cycle was found to be in violation, and you’ll also be open to lawsuits, as the GDPR gives users the right to file a complaint and seek damages where their data was not handled in a compliant way.
Needless to say, there are real reasons for the panicked scramble that occurred in the weeks leading up to May 25th.
Does it apply to you?
It likely does. The GDPR can apply in any one of three scenarios:
- where your base of operations is in the EU;
- where you’re not established in the EU but you offer goods or services (even if the offer is for free) to people in the EU; or
- where you’re not established in the EU, but monitor the behavior of people who are in the EU (as long as that behavior takes place in the EU).
So with all of this said, what sort of data should you be paying attention to?
The GDPR specifically refers to “personal data”. Personal data under the GDPR means any information relating to a natural person which can be used to directly or indirectly identify the individual. This definition is pretty wide-reaching and includes such identifiers as name, id, location data, photos, email addresses, IP addresses etc.
The scope of this protection extends to any natural person in the EU which can mean users, employees, vendors, partners, customers or even members of the general public.
This means that not only must you manage user data responsibly, but you must also pay attention to your privacy management within your organization as well (aka how you manage your internal data) as similar rules may apply.
So what exactly does this mean for startups? What sorts of things do you need to pay attention to and how do you address them?
Main Points requiring attention
Central to the GDPR are the newly defined roles and responsibilities. The main ones are:
- Data Controller: Any person or legal entity involved in determining the purpose and ways of processing the personal data (this will most likely apply to you and/ or your organization).
- Data Processor: Any person or legal entity involved in processing personal data on behalf of the controller. For example, an internet company may collect user information via their website and store it using a 3rd party cloud service. In this scenario, the internet company is the data controller and the organization running the cloud service is the data processor. Data processors must be officially appointed via a Data Processing Agreement (DPA).
- Data Subject (also referred to as the “user” within this article): An individual whose personal data is processed by a controller or processor.
2) Privacy by design
The GDPR requires that data protection be considered from the onset of design and development of the business processes and infrastructure. This means that privacy settings should be set to ‘high’ by default and measures put into place to make sure that the processing life cycle of the data falls within the GDPR requirements.
Some factors to pay special attention to are:
- Data Subject Rights: These rights include things like the “Right to be informed” and the “Right to erasure”. It’s important to factor this into the design process to make sure that these requirements can be met.
- DPIA: A Data Protection Impact Assessment, is more or less an internal process of risk evaluation used to help organizations comply effectively with the GDPR. An effective DPIA makes it possible for you to find and fix issues at an early stage. Generally speaking, the DPIA is only mandatory in cases where data processing activity is likely to result in a high risk for users (this is particularly applicable when introducing new processing technology). However, if you’re not sure whether or not your processing activity falls within this category, your best bet would be to carry one out nonetheless as it is a useful tool for ensuring that the law is complied with and fulfilling the “privacy by design” requirement.
- DPO: The Data Protection Officer is an independent entity (natural or legal person) who supervises, informs and advises you (the data controller) on your compliance with privacy requirements. The DPO is only required under certain circumstances — where there’s large-scale systematic monitoring of users; where you’re performing complex operations with sensitive data; or where the processing is carried out by a public authority.
- Breach Notification: Under the GDPR, you must notify the Supervisory Authority within 72 hours of becoming aware of a data breach. Users must also be informed of the breach (within the same time frame) unless the data breached was protected by encryption (where data was rendered absolutely unreadable for the intruder), or, where the breach is unlikely to result in a risk to individuals’ rights and freedoms. You’re also required to keep comprehensive records related to such breaches.
3) Privacy Notice
4) Defining the types of data
Not all personal data is the same. Some types of data are given additional protections under the GDPR. These are:
5) Legal Bases
The Legal Bases for processing data are just that — the basis or legal justification for your processing. There are 6 legal bases under the GDPR (you can read them here).
One of the more common legal bases is consent, however under the GDPR consent can be a bit taxing and in some cases is may not be your best basis (For example, if you’re processing employee data, your legal basis might be “performance of a contract” as opposed to consent). Data subjects may have more or less rights depending on the legal basis applied. Generally determining your best applicable legal basis can be tricky and it is highly recommended that you consult with a legal professional for this.
Monitoring” under the GDPR is referred to within the context of *”profiling a natural person, particularly in order to take decisions concerning her or him or for analysing or predicting her or his personal preferences, behaviours and attitudes.” *In many cases, monitoring can require consent with users reserving the right to object to, or restrict this type of processing. Whether or not something constitutes a profiling can often be determined by the purpose of the processing activity. The example here (involving Google Analytics) illustrates this point.
7) Cross-border data transfers
If transferring EU resident data outside of the European Economic Area (EEA), you must only do so where certain conditions are met. Under these conditions, the country or region the data is being transferred to must have an “adequate” level of personal data protection by EU standards, or the data may be transferred under the protections of standard contractual clauses (SCCs) or binding corporate rules (BCRs) in some cases. In regards to data transfer to the US, all transfers either require that the data processor adhere to the EU-US Privacy Shield or that informed consent is received from the user.
So what are some practical steps that I can take right now?
1) Strategize and plan with risk in mind
- Consider what data is actually needed — the more types of data you process, the greater the burden and responsibility. Furthermore, under the GDPR you are required to minimize data usage, i.e use only what’s needed and keep it only for as long as necessary to fulfill its purpose.
- Categorize your data to see if special protections apply as this may mean that you’d have to put additional provisions in place such as acquiring parental consent, a DPIA or appointing a DPO.
- Evaluate the necessity of over-seas data transfer and if necessary
2) Identify/review your legal basis for processing, ideally with a legal professional.
Under the GDPR privacy notices must be easy to access, easy to read and understand, must not contain unnecessary legalese and must be up-to-date.
These notices should contain:
- owner details including address;
- purposes of data collection;
- legal basis of data collection;
- which third parties are involved in the processing and for which purposes;
- users’ rights in relation to their data;
- the effective date of your policy;
4) Review third-party involvement (including your cloud hosting provider)
- Ensure that third parties are compliant as far as you can reasonably determine as the responsibility for your users’ data ultimately lies primarily with you (the data controller).
- Be sure to have a proper Data Processing Agreement in place with all appointed processors (third parties) as this not only sets the terms and responsibilities for the processing of user data, but can also serve to protect you in the event of non-compliance by the processor.
- Keep track of who you share data with. This is very important as you’re required to disclose this information to users via your privacy notice and third-party policies can change over time (which may affect their level of compliance or ability to meet the terms of your agreement).
- Make sure your processors’s systems supports the ability to fulfill user rights (for example, if a user exercises their right to erasure, can your processor fulfill this request?)
7) Review your own processes and systems for dealing with user rights.
8) Keep valid records of your data processing activities (including internal records of processing)
To be considered valid, consent must be:
- not based on coercion;
- it must be as easy to withdraw the consent as it was to grant it; and
- it must be based on an‘opt-in’ mechanism rather than ‘opt-out’)
However you choose to handle the extra responsibilities that the GDPR brings, one thing is certain — while it may cost you more up-front, it can give you the competitive advantage of starting things right: mitigating risk and saving you money in the long-run.
The GDPR is here to stay, so why not embrace it?
You can read more in-depth information about the GDPR in the dedicated GDPR guide here.