Get the basics down, the documentation can follow. Get the basics wrong and it becomes painful.
1. Stop collecting any data you don't need. If you don't collect it, it's not an issue!
2. Have a way for users to access their data or request it be deleted. This can be a manual process.
3. Make sure you gain explicit consent for any data you capture from users, and explain why you are using it.
4. Make sure any data you capture is stored securely using industry best practices.
5. Put a retention policy in place for backups and logs – for example, delete them after 30 days.
That's basically it. It's more complex if you have a product that needs to store lots of data to function, or if you have a sprawling set of databases, or if you have some kind of un-deletable storage. But in general, you only need to do the sort of things that you should really already be doing if you use personal data.
And bear in mind that the goal of GDPR is not to fleece companies for fines, but to achieve compliance with the rules. If you do something wrong but act in good faith, you can expect a letter from whichever SA is coming after you. But you're not going to see a €20m fine any time soon.
That's trickier than it sounds.
If you embed a copy of jQuery on your page hosted by a CDN, you're collecting and sending personal data to the CDN. Do you have consent for that?
Same with web fonts, icon fonts, javascript libraries, social media follow/share buttons, analytics tags, etc you embed in the tags.
Every time your page is loaded, you're sending personal data to all those third parties, most of them not even located in the EU, which means you're sharing with a third party and doing a cross-border transfer.
You need more than just consent to do that, they're sub-processors for you, and you likely need signed Data Processing Addendums with each of those companies, and they need to have adequate protections for cross-border data transfers, like participation in the EU-US Privacy Shield Framework. Have you signed those agreements?
You can easily be sharing more data than you meant to, too. Let's say you send a newsletter for your website and you host a copy of phpList or similar software to manage and send it. In each mail you send out, you include an unsubscribe link, which has the address to unsubscribe embedded in the link.
When someone clicks that link, their email address will be part of the HTTP referrer header sent to all those third party scripts on your page. Now you're transferring email addresses to a half dozen third parties with no legitimate business reason to do so. Do you have consent to do that?
You're not collecting anything there, so it's nothing to do with the GDPR - it might impact the CDN, but it's unlikely without them tying your IP to other personally identifying information. Analytics would be, because that's personal data you are collecting, so you'd need to ask permission for that.
I haven’t actually read the regulation and couldn’t care less if I comply (I’m sure there is like 10% of it that I might not comply with), but my point is that nobody ever complained - I give users an easy way to nuke all their data (actual delete, not pretending to delete), I don’t share their data with anyone, no analytics/tracking/advertising and problem solved.
1. aimed at, at the very least, medium-sized for-profit businesses, and as such include requirements that explicitly don't apply to very small projects
2. very often are trying to sell you something (consulting services, compliance audits, training, etc.) and as such are motivated to make GDPR sound as scary as possible.
There is a little more to it than this, but, my advice would be to just be mindful of any info you collect on users.
If you are worried about it, you can focus on projects that are open-access or don't necessarily involve accounts and login, but if you are implementing auth, just note what the auth collects, and be careful with it, both in terms of consent and securiy.
Don't give it to 3rd-parties (the easiest way to do this is doing things like sending userIds to Google Analytics in custom JS events). Consider whether your small side-project really needs Google Analytics (logging, crash analytics is good for debugging issues, but behavioural analytics is moving towards building a business, imo).
Note: I'm not implying side-projects shouldn't be moving toward building a business, but I'm just making the point that if that is your intent, you should be spending a little bit more time considering user privacy and compliance. And getting proper advice about it. You don't even need a DPO for <250 employees, so this really isn't that burdensome.
My very basic understanding is that countries set up SAs (supervisory authorities) to deal with complaints, and have the legal power to sanction and so forth.
So is it only the SA that can take action against you? If someone wanted to harass you, must they complain through the SA, or can they bring a civil suit based on the GDPR?
Yes.
> If someone wanted to harass you, must they complain through the SA, ...
Yes. There are also provisions for handling malicious requests to access personal data:
https://ico.org.uk/for-organisations/guide-to-the-general-da...
> ... or can they bring a civil suit based on the GDPR?
Nope.
So... Blackhole .eu and move on with my life?
Hopefully you're storing encrypted hashes and not simply encrypting passwords.
https://blog.varonis.com/gdpr-requirements-list-in-plain-eng...
https://ico.org.uk/for-organisations/resources-and-support/d...
As an aside that checklist is misleading. Some of the requirements they list expressly don't apply to small businesses, for example you don't need a DPO unless you're over 250 employees.
Do you set cookies that are required? Need to identify them and inform the user.
Server logs? You probably have ip addresses. Despite what us nerds think the EU considers them personal data.
I run the site behind cloudflare and don't store X-Forwarded-For IP, the analytics software I use immediately anonymizes them before storing them. So I should be fine I hope.
Email list needs to be updated - Only consented customer data needs to be stored, and erase the other unless you want a fine of 20 million euros or so. (remove data of those who have unsubscribed to your service immediately). Data erasure - Remove data of those who have unsubscribed to your service. Check for the Unsubscribe button everywhere - It’s mandatory that each and every mail of yours needs to contain an unsubscribe button with updated privacy policy given below. Update the privacy policy & terms of service - these need to contain what and how you are going to use the user’s data. For more info, read from the links given below in this answer. Double opt-in- for both entry and exit needs to be mentioned. Permission for profiling - Sales people can get prospective customer’s data through gated content(whitepapers, e-books) etc and they shouldn’t get this data from any other source like email hunters etc. (without their consent you can’t even breathe!) Employee data handling - You need to mention how and where is the data used and stored and for which purpose too. If you are using the data for multiple purposes, then you need to mention each purpose every time. Referral Program - You can’t process the referral email ids/data gained through offers/discounts etc. Yes, even they have to be GDPR compliant. Data usage policy - already mentioned in this answer(this is just to remind its importance in this context) Right to forget - option to be provided if the user wants you to erase(forget) their data from your databases. Usage of cookies - to track email opens etc you need to mention you are using cookies to the user. Some notes you would want to keep for GDPR compliance:
GDPR: Key Points and Steps to Prepare (https://www.agilecrm.com/blog/gdpr-key-points-steps-prepare/) https://www.superoffice.com/blog/gdpr-marketing/ (https://www.superoffice.com/blog/gdpr-marketing/) Salesforce PDF on GDPR(fiction vs fact) (https://www.salesforce.com/content/dam/web/en_us/www/documen...) GDPR Regulation (https://www.eugdpr.org/the-regulation.html)
