Here are some free and honest advice on the topic of EU General Data Protection Regulation (GDPR) – because frankly we are a little tired of the corporate jargon.
Being a good custodian of personal data does not have to be scary nor difficult. I happen to think it is quite straight forward, though it can be a fair amount work. Most important piece of the puzzle for the data controllers or processors is that you will require a devops/fullstack team. If you are an old school enterprise, then you should have gone through some kind of I.T. transformation to embrace and put in place principles of devops. This is because during the process of working through the various controls surrounding personal data, chance are things will be missed, particularly if you have a very large portfolio. The only sure thing is that as an organisation, you can work in an iterative, lean and agile, and collaborative manner.
Some unsorted advice in bullet points below.
- You should have a crew of fullstack devops superheroes for your customer facing application stack.
- The definition of a customer facing application stack includes the full spectrum of interactions between the consumers and your organisation. This include direct user interactions all the way down to the back office. If you need personal data somewhere along the chain, then it is in scope.
- As data controller or data processor, or both, you will not sell, distribute or own said data without clearly informing the users and obtaining consent at the very least.
- You have evaluated if you need a Data Protection Officer (DPO), and if so, you have appointed or sourced one.
- Customer facing application has clear privacy policies and terms and conditions
Naturally your system follow and oblige these terms and conditions and privacy policies.
- You may even have content or communiqué explaining how you have secured your customers’ data.
- Safe harbour and privacy shield is not settled yet. Avoid storing data in US physical locations to play it safe.
- Should probably have infra as code (terraform or puppet etc) and be a little lean to be able to move data and applications from various public clouds or onprem setups when required.
- Encryption matters. Don’t be an idiot. Do it at rest, and do it on transit and don’t use dated.
- Use bcrypt or scrypt for password hashes, salted of course.
- Exercising sound ITSec principles are a no brainer.
- Spread the use of an unique user id across all system as a pseudonymisation effort and standardisation.
- OAuth2 has a great selection of grant mechanisms that supports different ways of authentication and authorisation towards different systems and user-agents.
- Build and customise your consent process to that of OAuth2.
- Nuke data when your users wants out, including the source and integrated systems even with OAuth.
The hard truth is, GDPR is not in anyway shape or form finite or deterministic to warrant an engineering approach or a scientific model as basis for discussion. It is more likely that the process of addressing GDPR will be personalised and unique to each company. Ironically, it is a little like personal data itself. Most importantly, if you do not meet some of these devops requirements, you might want to start there first, and fast.
I have been racking my brains trying not to sound like a giant multi level marketing douche on the topic of EU General Data Protection Regulation (GDPR). This is my nth attempt at drafting this blog post and literally the writing has gone from selling fear and greed to regurgitating some hallelujah self-help Secret-esque scheme that regurgitated the same old concepts like “consent”, “transparency”, “pseudonymisation”, that is suppose to concretely address “privacy by design”, “obligation of data controllers”, or “data subject rights” etc. Well, at least I will portrait an image of misguided confidence whilst oozing a ton of leadership if I may say so myself. Nevertheless, I personally feel some simple, down-to-earth steer is needed on the subject matter and I have decided to put it out to the universe.