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 to illustrate exactly how important these roles are in ensuring GDPR compliance (and avoiding the consequences of non-compliance). The GDPR came into effect in May 2018, meaning that since then you have (hopefully) ensured to be compliant with what is, in effect, a radical new privacy law “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.” ( Harvard Business Review)

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 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 our work

Armed with these basics, the idea here, despite initial changes to our work and how we approach it, is to make things more transparent, more structured and less ambiguous. As far as how GDPR influences or changes our work, we will be faced with a two-pronged reality. First, the way we work (and the company in which we work) may generally be affected on a business level. Second, how we 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?”

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store