Or how to avoid another GDPR meeting
I recently blogged about Regulations as bad. And how regulations help big corporate. However, also big corporate is being challenged, and the usual solution is to hire a team of lawyers and have them schedule endless meetings across the company.
Regulations are one thing. They demand the absolute minimum with an abolute maximum of bureaucracy. This is an opportunity to take an engineering approach. To find purpose. To do better than demanded. And also to do it right from a technical standpoint.
So, what can an engineer do?
Start with asking the question. Asking the question of the one person who is not at the meeting table. The customer. Your customer. What would she think if you’d discuss how to find a loophole in the regulation instead of taking care of her desire to treat her data with respect and the deserved respect and privacy?
I’m glad we agree. Let’s dive into simple technical solutions: End-to-end encryption (in transit and at rest). This might have been hard a few years ago (remember self-signed certificates in a local intranet?), but in todays world of cloud-computing there are no excuses of not using HTTPS with a free certificate or enable the option for encryption at rest of storage, backups or databases.
Use an external authentication provider to authenticate access to your systems. Don’t re-invent the wheel. Auth0, Facebook Connect, Azure AD and many more have long solved OAuth and SAML authentication and can be connected to directory services for federated logins. Most 3rd party systems support that, and custom services should leverage those systems and just deal the straight forward call of validating JWTs.
Encryption and authentication alone don’t solve the privacy problem, especially if everyone working in your company has access to the data. Tokenizing data containing personal information is moving it however to a next level, especially for central log or analytics systems. Those system often contain the full contact details of a customer. But why? Why do you want to expose your analytics system to data breaches that can be executed with a simple “select email from customers” query? Why isn’t it enough to just store the postal code and country, and potentially a token to assign a useful primary key without personal information to the customer address?
And finally, there are still regulatory requirements you need to meet, such as having a data protection officer assigned. But hopefully that’s just a small administrative overhead to everything you already do. All the things you do much better than regulation demands.
Disclaimer: Above is a simlification trying to make a point. There’s more you can and should do from a security and privacy standpoint. And there are a few more things you must do for aligning with regulatory authorities.