(note - this article has been split into two parts, one to just give you an overview and one that actually dissects a small web application I have built that is compliant with GDPR.

Out of the loop - What's GDPR?

GDPR stands for General Data Protection Regulation. It's the most comprehensive and demanding set of law changes ever seen in the history of the internet. It affects whole European Union and also all companies that want to process data of europeans. Plus it sets CRAZY penalties for not adhering to it - up to 20,000,000€/4% of your yearly income, whichever's higher.

Who needs to be compliant with GDPR? Long story short - everyone that processes personal data of their users with financial gain in mind (however even non-commercial projects are not always free from it!).

Reason for GDPR is simple - to give users control and insight into data that's being used by websites. We have seen what happens nowadays with situations like Equifax breach that affected more than 100 million US citizens and EU decided to work against companies and for end users. Meaning that in itself goals of GDPR are definitely a good thing. That being said it also comes with a set of technical challenges you need to overcome.

Deadline: 25th May 2018.

GDPR requirements

While I still heavily suggest that you contact a lawyer to help you out if you are a part of a larger organization then here are some key points to go through:

  • Ability for any user to ask for information you keep on them. This one is a fairly straightforward requirement and you can already see examples running in the wild. For instance Facebook’s export data function does exactly this.
  • Don’t keep data longer than necessary – storing logs full of personal information forever is a big no under GDPR.
  • Right to be forgotten – user can be asked to be removed from your system. Now, by “your system” it does not only mean a live environment. It also means that restoring backups will not bring their information back.
  • Data has to be protected (via encryption for instance), you also need to have clear information on where is it stored. Important key point – in general you should keep user information of EU users inside EU. Transfering it to US/Asia IS possible but only via approved mechanisms such as EU-U.S. Privacy Shield
  • Explicit user agreement – you can’t just slap a big “I accept to the terms of service” OK button and be done with it. Now it’s one opt-in check box per type of personal information you are collecting, you also need to define what do you need it for.
  • Breach notification – you have 72 hours after you have discovered a breach to inform all affected users of it occurring.

Scared yet? Some of these points are simple to implement and in fact should have been a common practice for years (eg. actually informing your users of their data being stolen rather than pretending nothing happened...) but some (right to be forgotten) are quite complex to implement if you think about it.