In recent discussions some people said that humans are not the problem, but rather the lack of good technology to protect them. I beg to differ. I think the human is the weakest link in any security system. In this blog I’ll explain why I think what I think. And, by all means, open up the discussion in the comments on LinkedIn if you agree or if you don’t.
I was planning on writing a blog on G is for Governance, Risk and Compliance, but after yesterday's long and complicated topic F is for Fines, I decided it would be more fun to give something away.
There are many reasons for getting a fine under the GDPR and there are ways of influencing the ‘whether you get one’ probability and the height of a fine. Before you continue to read, I suggest grabbing an extra cup of something, because minds will be blown and heads might burst. But let’s start easy.
Don’t worry, I’m not going to go too deep into the technical and operational side of what encryption is but I do want to point out that the GDPR requires you to use it.
In the very early days, Julius Caesar used encryption. By sending secret notes he moved letters up 3 spots and the receiver knew to go back 3 spots for each letter to decrypt the message. Obviously, this was easily deciphered but thank goodness nowadays we have a more sophisticated way of encrypting that is a lot more difficult to decrypt. And since this is a nutshell, this is about as in-depth as I’m going to go in this blog.
We all hope we’re not subject to one (either as controller or as data subject) but most likely in one way or another you will have witnessed a data breach at some level at one point.
A 'personal data breach' means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.
In the “me too” era we all know that consent is a must to have and prove, and it’s no different for processing personal data.
The Merriam Webster Dictionary explains the term ‘consent’ as “compliance in or approval of what is done or proposed by another.” So, in the privacy context that would mean you need to explain first to your data subject what personal information of them you would like to process and for what purpose, what third parties you might share the data with, how long you’ll store it, etc.. Then you ask for consent for the aforementioned.
The other day a client had approached me for a GDPR Quick Scan and a Risk Quick Scan. I sent them a list of documents I needed to look over before making the actual appointment at their organization. A few days later the client had said that they’d also had a scan done last year and felt that they should probably use those results instead of having a new scan.
I spoke with the client and explained that it’s wonderful that they already have scans to compare with! You see, scans are snapshots of your current situation and last year's scan doesn't tell you anything about where you stand today. So, having regular (yearly at least) scans is extremely useful to compare and see trends.
In order to assess risks you basically need 2 types of information:
What a lot of organizations unfortunately still don’t realize is their legal obligation to audit their vendors under the GDPR. The GDPR distinguishes two direct parties: the controller and the processor.
The controller decides (controls) the scope, nature, etc, and level of security for the protection of their personal data.
The processor processes the personal data on behalf of the controller. The processor may not process the personal data given by the controller for any other reason than what they agreed upon.
You must have a legal binding agreement between processor and controller.
The agreement must mention: