GDPR for developers

The General Data Protection Regulation (GDPR) is a term that’s been bandied about frequently for the last year or so, but few references have targeted developers and devops to illustrate exactly how important these roles are in ensuring GDPR compliance (and avoiding the consequences of non-compliance). The GDPR comes into effect next month (May 2018) meaning that the countdown is on to ensure compliance with what is, in effect, a radical new privacy law (as Harvard Business Review describes it): “which covers any business that processes information about EU residents, will dramatically affect the way data is collected, stored, and used, including for U.S. companies doing business abroad.” HBR also argues that GDPR may mean “the end of what has long been the internet’s grand bargain: the exchange of free or subsidized content for personalized advertising”.

Whether or not this dramatic outlook bears out, it’s clear that the GDPR is a big deal and it affects users, companies, certain business models and the stewards of data and technology that keeps personal data private. There may be costs associated with implementing systems and infrastructure to become GDPR compliant, but the costs of not implementing those changes stands to be much higher.

And at the heart of ensuring how and what data we collect are developers. “After all, healthy data protection practice is as much about the development side — code, data, and security — as it is about the business side of process, information, and strategy.”

GDPR may be an opportunity to make you a better, more security and privacy focused, developer.

What you need to know

GDPR affects data of European Union residents, wherever the data is collected, stored or used. This data includes personal data, which is defined as “any information relating to an identified or identifiable natural person.” What is unique about GDPR is that it extends the definition of “personal data” to include data points, such as genetic data, biometric data (such as facial recognition or fingerprint logins), location data, pseudonymized data and other online identifiers, such as IP addresses, mobile device IDs and cookies, among others - which is key information for developers to know. Many applications (and business models) are built around this kind of data, meaning that GDPR will require you to evaluate what you have developed or will develop and with what data/identifying information.

Companies will also need to realize, with regard to data, whether they are a data processor, a data controller - or, potentially, both. The data controller decides what data is collected, how it is used, and whom it is shared with. The data processor processes the data on behalf of the data controller. As a developer, your company could be one, the other or possibly both, and while the data responsibility may not rest solely with an individual developer, understanding what role your company plays with regard to data is important.

What GDPR means for your work

Armed with these basics, the idea here, despite initial changes to your work and how you approach it, is to make things more transparent, more structured and less ambiguous. As far as how GDPR influences or changes your work, you will be faced with a two-pronged reality. First, the way you work (and the company in which you work) may generally be affected on a business level. Second, how you specifically work, i.e. the nitty gritty coding, will change.

Digital law expert, Heather Burns, developed and published in Smashing Magazine a near-comprehensive overview of how GDPR will affect development work. It goes into detail about the interdisciplinary nature of post-GDPR data collection and the privacy-by-design development approach that post-GDPR development will demand as well as some of the work you should already have done, i.e. privacy-impact assessments required as a part of GDPR, as well as other steps you should do now and in all future development projects to bake privacy into everything you create.

Technical security: Awareness is not enough

As GDPR makes clear, just being aware of privacy and security-related issues is not enough. Unambiguous, clear assessments must be undertaken - followed by implementing robust solutions as needed. For developers, much of this can be satisfied by implementing rigorous coding standards, design standards and transparency into the end-to-end lifecycle of development (and how privacy fits into that development at each stage).

Beyond these best practices, though, putting in place technical and security measures to address many of the concerns GDPR outlines is one data-handling ‘headache’ managed. For Varnish, these measures include standard actions, such as client and backend-side TLS/SSL transport, as well as Total cache encryption, which assigns each cache object its own unique encryption key based on the Advanced Encryption Standard (AES) and prevents an entire class of cache vulnerability, the cache leak. With each object uniquely encrypted with its own key, the data is useless to any interloper who gets their hands on it, which aligns with GDPR’s demand for data security.

As we’ve discussed before, you can strengthen your cache and data security with these measures - ensuring that even in the worst case scenario (data is stolen), it remains impenetrable to third-parties.

If you are curious about the features Varnish offers to help you on your way to GDPR compliance fetch the on-demand webinar “How to make your cache infrastructure GDPR compliant?”