6 Ways to Fail your GDPR Audit

So, you have spent hours and hours and possibly a big sum of money to ensure compliance with the much feared GDPR. You probably also got yourself a nice headache trying to interpret what it really means in practice. Congratulations on your hard work! Hopefully, you just come back after a nice and much needed summer vacation, ready for the next challenge.

But then I show up. Or one of my colleagues. Or some other friendly auditor that your company has hired to ensure that the money was well spent, and that if a supervisory authority would drop by, they would only find nicely structured documents and sunshine. Instead, you find yourself back in the GDPR-project, questioning everything you ever did. Just like your auditor, who will also make a nice report of it, possibly even a PowerPoint. So, since you’ve just had a vacation and all, I’m going to give you a little heads up on what your auditor may not like.

Here are the 6 most common findings that we have had in the projects we have reviewed so far in relation to GDPR Audit:

1. Your record of processing activities is incomplete
This one is actually more common than I would have thought, a few control questions here and there regarding your marketing activities or how your IT department is working and holes in your record is starting to show. Take a look at how your organization is structured – most departments are processing personal data, and if a department is missing then you can almost be certain that the record is missing stuff too.

2. You have not documented or explained how you assess privacy risks
Working with privacy means protecting what may have an impact on people’s lives and ensuring that it stays safe. The legislation however allows us to have a risk-based approach, where high-risk content needs better security and processes than low risk. You can either have Fort Nox security on all personal data you are processing, or start dividing your processing into categories. I’m talking information classification here, possibly even a nice matrix or policy for determining which personal data needs super encryption, and which personal data can be posted on your intranet.

3. Policy confusion 
Privacy policy, information security policy, privacy notice, information to the data subjects… I get it, there are a lot of documents and weird legalese to juggle. But you do need to keep your external privacy policy (that is aimed to inform your customers or employees on how you process their data), separated from your internal policy (that sets down the rules on how your organization is going to work internally to ensure good privacy practices). You do need to inform your data subjects, and most semi-large organizations also needs at least a basic internal policy to set down the rules regarding privacy. Or a really good explanation on why you don’t.

4. Your project only assessed IT systems
I have stumbled upon organizations asking for help in ensuring that one or two of their IT systems are compliant. I at least do not understand that approach, as working with privacy is about how a processing of personal data is made from start to finish, from collection to erasure – regardless if it is made inside/by an IT system, several systems, goes through an excel sheet or has a step where is faxed to another location. I will fail you if your processing has several steps, but you have only secured one or two main systems.

5. Your DPAs are not in order
You saw this one coming. And I know you hate me for it. Take a large organization, a bit of legacy and a de-centralized process for entering into agreements and you have a big mess. Have you found all potential processors? – Maybe, if you’ve done a good data mapping job. Have you found all service agreements for those processors? – Not likely (they are in a drawer belonging to a colleague that left the company 5 years ago). Have you gotten data processing agreements in place with all of these processors? – Nervous laughter. I get it, I’ve probably also tried all the tricks in the book to get a processor to sign the DPA. But that has to go through legal. And then, 5 months later, they come back with their own version they want you to sign. And that has to go through your legal.

Pro tip to please your GDPR auditor: show the list of all processors, and the method you used to find them. Show him or her the risk assessment you have done on those processors, and your action plan for getting the DPAs signed, starting with the high-risk ones. And your progress report. He or she will (hopefully) understand and not hang you for it.

6. You have no evidence
Most common phrase when talking about the security of the data: “we have excellent information security; the IT department is really good at this!”. All right, I believe you, but just for formality’s sake, can you show me the latest penetration test report? No? The latest information security audit report? No? Specification of your implemented measures? No? I think you can see my point here…

So, do you feel ready to take on the next season and face your friendly auditor now that you know what is coming?

You can explore our Data Privacy services by visiting our Data Privacy page.