If you really, really don’t want to do GDPR

Recently I spoke with Sarah at WP Tavern about GDPR, contact forms, and the need for developers to wake up to their new legal obligations. The article generated the expected amount of healthy, constructive pushback you’d expect, some of which raised a very important point which I’m going to briefly address here. These thoughts, of course, are not a personal go at anyone who commented in the WP Tavern post; I’m keen to support a constructive dialogue, because that’s how I roll.

Even if you are not physically or commercially located within Europe, the personal data and the sensitive personal data you collect and process about Europeans must be protected in accordance with GDPR. This is a prerequisite of being able to do business in Europe, and it has been since Europe’s overarching data protection principles were first elaborated in 1995. As always, many non-European developers and business owners are surprised to find this out and rightfully wonder how they’ll be able to comply with their new obligations. These developers’ objections tend to fall into two categories. The first small category comprises developers who have an ideological objection to complying with the laws of foreign countries, which is a subset of moral philosophy we probably shouldn’t get into on a Sunday evening. The second category, and the much larger one, comprises non-European developers who want to do the right thing but find GDPR too complex, burdensome, or expensive to comply with.

So what do you do if you’re that non-European developer who believes in privacy but doesn’t want to comply with GDPR? If that’s you, there are two things you need to remember. The first pertains to Americans only, because they are the most common source of this tension. You need to remember that the US is an outlier – and not in a good way – in not having any kind of overarching, cross-sector, nationwide data protection and privacy framework. Your competitors in other countries have been developing to privacy laws and frameworks since day one. So you need to think very carefully about how you are going to work to earn and maintain your users’ trust in the absence of safeguards they can take for granted from developers elsewhere. That was true before the current political situation made the protection of users – and their data – a lot more important than it used to be. America is looking like a hell of a scary place for data to live right now. And with no legal framework at your disposal, your users have no legal protection at their back.

In the absence of that framework, then, we come to my second point: what is your benchmark? Privacy and data protection are not wooly concepts you can pull out of the air. They need clear definitions, structures, sets of rules, and documentation. So when you say you care about protecting users’ privacy, but don’t want to work to GDPR, what are the tools you are going to use to create and measure your data protection standards? Is it the Privacy by Design framework? Is it CDT’s suggested definitions of technical privacy terms? Is it an experimental, philosophical framework such as the one proposed by the Constitution Center? Is it an international convention like the OECD guidelines or the Council of Europe’s Convention 108? Is it a sector-specific framework like COPPA? Is it a self-regulatory set of guidelines for members of an industry body such as AdChoices? What framework meets your needs, how will you incorporate it into your workflows, and how will you make it really matter for your users?

Some good advice on finding the right way forward comes from Fieldfisher’s Phil Lee, who is always an excellent source of practical, plain-English information on privacy and data protection:

Getting overly focussed on dotting every ‘i’ and crossing every ’t’ under local law creates a bigger risk too; you become so focussed on the law, you forget about the data.  It’s worth remembering that all privacy regimes worldwide are essentially built off a few core privacy principles around notice, choice, purpose limitation, data quality, access and security…If you build your data protection terms against these core principles then, even if you don’t hit every note under every local law, you won’t go too far wrong – and, more importantly, you will be building a document that does what it is supposed to: ensure protection for the data.

The bottom line is that if you want to do something about privacy, but refuse to do GDPR for whatever reason, you don’t get to mark your own homework. Not at a time like this. Choose a set of definitions, a framework, a benchmark, or a set of guidelines which is public, accountable, and transparent. Learn it, incorporate it into your workflows, and document your journey. That journey, and the framework you build for yourself, must stand up to public scrutiny. It has to be accountable to your users, your colleagues, and the wider world. So use it. Just remember that any framework or system that is not deemed equal and adequate to GDPR isn’t good enough for your European users, morally or legally. After all, the real danger of GDPR compliance isn’t the “fines fines fines”: it’s the risk of being ordered to cease data collection and processing operations in Europe due to your noncompliance. When that happens, you’ll wish you’d gone with GDPR all along.