Disclaimer: This article isn’t the entire GDPR doc retelling (Google it). Neither is it a magic pill that brings lifetime safety and tons of happy users (never happens). This GDPR startup guide is more about finding ways to take care of users from day 1 and protect the most precious thing they can ever give you. Simply because whether you’re going to create an app yourself or by asking an MVP development company for help — you are to do this in the best possible way.
See the four points I’m going to cover in this GDPR startup guide:
- Who has to obey the rules ( almost everyone has)
- What exactly personal data is (almost everything is)
- What to do to capture all data you have
- What to rely on to process personal data
Some guys might consider this GDPR startup guide to be a true longread (not 100% sure, though), so get a snack, settle in and let’s figure this all out.
See who’s on the radar
Think that only Silicon Valley giants have to obey the new regulations? Of course, no.
A few cases that I put in this GDPR guide to prove this statement:
Everyone is involved, see?
What to protect
In short, you should protect EVERYTHING. Literally every damn piece of users’ info that you store and process.
It’s likely that you already know what personal data is, so I won’t provide long explanations for this term. Just for the sake of clarity, check out a couple of examples.
Let’s say your user is an ‘average’ John. The info you have on him is like:
A recent user’s full name is John Smith. He lives in San Francisco at 87 Hudson Terrace.
Will this info be his personal data? Actually, it will. It clearly identifies his name and location.
What about his ID address and cookies? Just like with the name and the location, it is counted as personal data. Just because of the same ‘identifying’ reason.
Whoever’s data you store and process, be it John or Sam or someone else, think about it this way:
Everything that can be used to narrow down the search results and establish someone’s identity is gonna be personal data
Be it cookies, hair color or occupation info, this rule will actually work for it.
There’s also a subcategory that contains ‘sensitive’ data — this one requires more protection. It contains the details about the user’s:
- Race
- Ethnic origin
- Political affiliation
- Religion
- Trade union membership
- Genetics
- Biometrics (where needed for ID purposes)
- Health status
- Sex life & sex orientation
In case you’re gonna use any of these, get consent first. Ensure it’s clear, visible and obvious. Do not bundle this in your Terms & Conditions.
If you allow kids to create accounts or offer in-app purchases, get parental consent first. Get permission if kids are younger than 16 (some countries lowered it down to 13, so check this up beforehand).
Put it out there
And that’s actually a real starting point.
Map all data that you plan to hold or are already holding. Gather all team members in order to ensure you haven’t missed anything important.
The following ‘data-chain’ map might be helpful to speed up the entire process:
Pen-and-paper is ok for it, but All-in-one GDPR might be a perfect option for founders with poor drawing skills:)
While reading this GDPR startup guide, keep in mind that ‘data minimisation’ approach works best here. So, anything that you didn’t tick as ‘mission critical’ in the very last column, might be worth removing. Pretty evident that you don’t need people’s job details to send them announcements about your app, right?
Pick a legal reason to lawfully use it
First of, I want to tell you that consent isn’t the only legal reason for the entire personal data processing. Three most commonly used grounds (aside from consent) are set out below:
1. The data are needed to fulfill a contract
You’re a selling app. The data like credit card number, postal address and phone number are needed for collecting fees, delivering goods and communicating with users on service-related issues.
2. Processing is a legal requirement (contractual obligations are not included)
The charity app intends to process names and emails to send marketing materials for its fundraising purpose (though the materials contain the info about how a user can opt out of receiving such info in future).
3. Processing is required to pursue the legitimate interests (cannot be the default basis for all your processing)
Data processing is a part of fraud prevention and data security
None of these grounds is a default or ‘the most preferable’ option. You can pick any reason to make data processing lawful. So look through all the conditions on which you store data and ensure you meet at least one legal reason for that. Then tell so everyone who shares data with you – at the very moment when you collect it.
Know your users’ rights
These include:
1. Right to be informed (typically privacy notices are used for that)
Once John gave you his consent, he owned the right to know about how his personal data is being used at every step of the way.
2. Right of access
If one day John Smith asks you to show all data you have on him (plus explain why you do this and where you process it), you must present it within one month since he requested.
3. Right to rectification
If John Smith discovers that his first name isn’t correctly spelled in his personal data stored by your web app, he can have it rectified.
4. Right to erasure (where there’s no legitimate reason for holding on that data)
If John Smith wants to unsubscribe, you’ll have to erasure all personal info stored and inform him after you’ll be done with it.
5. Right to restrict processing
If John Smith objects to the processing or claims that his data is inaccurate.
6. Right to data portability
If John Smith finds a product that better suits his needs, he can transfer his personal data to start using it in a very smooth way.
7. Right to object to processing
At any time John Smith can ask you to stop processing his personal data for, like, direct marketing. This refers to any data related to direct marketing.
This GDPR startup guide is not for scaring you
At least, you’re not Facebook or Amazon, so the risks of hefty fines and massive data breaches are damn minimal. GDPR is more like a good business practice that shows your respect to users (give it and you’ll earn it). And simply a sure way to achieve harmony and sleep easier at night 🙂
Just keep what is necessary to carry out your duties and keep your users informed about what (plus what for and for how long) you use it. Actually it’s a real must-be-done thing even without any ‘strictest thing in the whole universe’ horrors.
