The GDPR - how it will affect the way you develop?

Note: This article is not a legal advice and should not be construed as such.

The GDPR act has been adopted due to the fact that in the Internet age, the law did not keep up with reality - most of the regulations were few laps behind, dated back to the 1990s (who even thought about Facebook or Google that time?). Right now, people and their personal data are not protected enough, more and more security breaches and violations in headlines show up every day - it is the time to push changes. New regulations apply to all data controllers (those who collect data from and about EU citizens) and data processors (those who process this data on behalf of a data collector).

But first things first - what is personal data/information? Basically, personal data is any information relating to an identified or identifiable natural person: chunk of information that allows someone to identify someone else without “excessive effort”. It might be a name, surname, address, ID card number, email, and so on. There is no strict definition of what excessive effort is, but if you type this info in Google, hit enter and find something on the first few pages, it’s definitely not.
When it comes to processing personal data, the matter is unclear - and that’s why it might be tricky. It’s best to assume that if you possess any personal information in any form, you process it, and you are a subject of the GDPR. It means that you have to adopt certain rules and obligations, the sooner the better. As they say, preparation is prevention.
If unprepared for welcoming the GDPR with arms wide open, your company may face a fine up to €20 million or 4% of annual turnover. You have been warned.

At the heart of the GDPR are transparency, consent and security.

From now on, you have to explicitly ask a user for permission to process his or her data. It means there’s no “default permission” - burying the vague information about it deep in regulations or terms of service is not allowed anymore.
Moreover, you have to specify for how long you’ll store the data and for what purposes it will serve, and how (in what way) it will be stored.

You have to specify how users can contact you, for example on the “terms of the service” page. If a user of your app or platform asks about his or her data you have to address this issue without any “unnecessary delay”. No more waiting ages for removal from newsletter list or email change - you have to act as soon as possible.

The GDPR grants unlimited access to one’s personal data - a person can check what and how information is processed, modify it in any way, withdraw the consent to process the data, or order to erase all or only part of it at any time.
When asked, you have to prepare a complete set of one’s stored and processed personal data and provide it in “commonly used file format”, such as .csv. And if your user asks you to erase her- or himself from your database - to “be forgotten” - you have to do it. If erasure is not possible (for example, because of the platform architecture), you have to delete as much data as possible and fully anonymize all that has left.
Of course, if removing the person from your database means excessive amount of work to do that, you have all the time you need… but not more. User can come back to you and ask about a status of his request - and you have to update him that the job is done or you need more time.

The GDPR requires the adoption of the Privacy by Design framework, which is about anticipating, managing and preventing privacy issues before a single line of code is written. Not to create privacy risks in the first place is, according to the PbD philosophy, the best strategy. PbD which requires optimal data protection as a standard across all uses or applications.
What is also required under the GDPR for data-intensive projects is a Privacy Impact Assessment (PIA). In a nutshell, it’s a document and set of rules accessible to all team members involved in the project, where you discuss, audit, inventory, and mitigate the privacy risks inherent in the data you collect and process.
Not having it is a very bad practice. You might be asked for it by a data protection regulator of your country during regular inspection, in the event of a privacy concern or data breach, so better have yours prepared.
If you have any problem with constructing such document, you are not alone - it’s not an easy task. Sample templates are widely distributed over the Web, feel free to take a look and use it.

Data audits and file storage have been toughened and tightened up, too.
Unencrypted hardware, unprotected servers, insecure connections, human factor (i.e. misuse of an employee login) - you have to take a better look at them. There’s a good reason to do so: the GDPR treats an internal data breach as an external one! Unauthorized access to data (for example, an access to a project database for your coworker to “just check something”) constitutes a data breach that has to be reported. System monitoring and logging into it should be measured and checked, if we talk about good security.
What’s more, you will need to ensure (in a formal way) that any non-European third parties you use - a web host, cloud storage, a business partner, and so on - guarantees they are safeguarding your European data to European standards. Evaluation of technical and security measures must include your international data transfers.

To wrap it up: being either a data controller or data processor, you must meet certain strict conditions set forth by the GDPR. You have to keep in mind three key aspects of the regulation - transparency, consent, and security. Obtain specific consent for every personal data use from your users, make it clear what you are using the data for, and keep it locked by ensuring the best possible security and technical measures. You either adapt to these (and many other) provisions, or your business is likely to suffer severe consequences!

Photo by Patrick Tomasso on Unsplash