Ioan Popovici
Chief Software Engineer
Last time, I tried to brief some of the steps you need to cover before starting to choose the tools that will help you achieve compliance. Let’s dig a little deeper by using some real-life negative examples that I ran into during this faze.
Case 1. The insufficiently authenticated channel.
Disclosure disclaimer: following examples are real. I have chosen to anonymize the data about the bank in this article, although I have no obligation whatsoever to do so. I could disclose the full information to you per request.
At one point, I received an e-mail from a bank in my inbox. I was not, am not, and hopefully, will not be a client of that particular bank. Ever. The e-mail seemed (from the subject line) to inform me about some new prices of the services the bank provided. It was not marked as spam, and so it intrigued me. I ran some checks (traces, headers, signatures, specific backtracking magic), got to the conclusion that it is not spam, so I opened it. Surprise, it was directly addressed to me, my full name appeared somewhere inside. Oh’ and of course thanking ME that I chose to be their client. Well. Here’s a snippet (it is in Romanian, but you’ll get it):
Of course, I complained to the bank. I was asking them to inform me how they’ve got my personal data, asking them to delete it, and so on. Boring.
About four+ months later (not even close to a compliant time) a response popped up:
Let me brief it for you: It said that I am a client of the bank, that I have a current account, where the account was opened. Oh, but that is not all. They have also given me a copy of the original contract I supposedly signed. And a copy of the personal data processing document that I also signed and provided to them. With the full-blown personal data. I mean full blown: name, national id numbers, address, etc. One problem though: That data was not mine, it was some other guy’s data that had one additional middle name. A thus, a miracle data leak was born. It is small, but it can grow if you nurture it right.
What went wrong?
Well, in short, the guy filled in my e-mail address and nobody checked it, not him, not the bank, nobody. You imagine the rest.
Here’s what I am wondering:
1. Now, in the 21st century, is it so hard to authenticate a channel of communication with a person? Is it so difficult to implement a solution for e-mail confirmation based on some contract id? Is it, really? We could do it for you, bank. Really. We’ll make it integrated with whatever systems you have. Just please, do it yourselves or ask for some help.
2. Naturally, privacy was 100% absent from the process of answering my complaint, even though I made a privacy complaint. Is privacy totally missing from all your processes?
In the end, this is an excellent example of poor legislative compliance, with zero security involved, I mean ZERO security. They have some poor legal compliance: there is a separate document asking for personal data and asking for permission to process it. The document was held, and it was accessible (ok, it was too accessible). They have answered my complaint even though it was not in a timely compliant manner.
Conclusions
0. Have a good privacy program. A global one.
1. Have exquisite security.
2. When you choose tools, make sure they can support your privacy program.
3. Don’t be afraid to customize the process or the tools. We (and, to be honest, anybody in the business) could easily give you a quote for an authentication/authorization solution of your communication channels with any client.
I am sure you can already see for yourself how this is useful in the context of choosing tools that will help you organize your conference event, and still maintain its privacy compliance.
About the author
