A Common Framework For Auditing GDPR Compliance
One of the aspects of my work I have a particular passion for is auditing data protection compliance and through my work with a host of different organisations, I have reviewed the work of many data protection auditors. The one thing that strikes me most is the wide variation in what auditors look at, how they characterise and describe compliance, how they evidence their assessment and the recommendations they make.
Audit Scope
On the first point, the point of what to look at, getting the scope of a data protection compliance assessment right should be straightforward, right? You’d think that, for example, a GDPR compliance assessment would cover every aspect of the GDPR that affects the auditee organisation but I could not begin to tell you the number of audit reports I have read that simply miss out on large chunks of the legislation. Of course, we all know that roughly 20% of the GDPR(Keeling Schedule) doesn’t directly apply to data controllers (e.g. Articles 50 through 59), and even less applies directly to data processors, but the bits that do apply should, in my opinion, be subject to a GDPR audit unless specifically carved out in a statement of scope.
Audit Method
That brings me to the next point – how to conduct an audit.
This is the crux of it really. For example, how should one assess records of processing activities (RoPAs)?
My approach is to first determine what structures are in place to manage RoPAs. Is there evidence that compliance with this obligation is under management control? There should be a policy on maintaining RoPAs, or where applicable a policy that states the RoPA exemption is being relied upon. I like to see a process or procedure setting out who is responsible for maintaining RoPAs and how frequently. I like to see evidence that the RoPAs have been reviewed as set out in the policy because, without those basics, data protection auditee struggle to demonstrate that RoPAs are a managed entity.
Then I move on to assessing the RoPAs themselves. Do they contain at least all of the information required in Article 30 and do they make sense? For example, if a controller chooses to record the lawful grounds for processing in its RoPA (which I believe is an eminently sensible place to record them), are the RoPA entries valid or has some someone recorded “system requirement” as lawful grounds? When referring to “contract” as a lawful basis, does it seem likely that this has been correctly applied? What lawful grounds are stated for processing special categories of personal data?
During my RoPA review, I would select several records to analyse in detail. At this point, I would like to see the processing activity in action and discuss it with the process owner. I’d like to test that the RoPA entry accurately reflects what I see in the workplace and that the process owner is aware of the RoPA policy. This usually involves getting out into the organisation which also enables me to look for processing activities that I didn’t see on the RoPA!
Another way of checking the RoPAs is to compare them with privacy notices. I often find processing described on privacy information that is not recorded on the RoPA and visa versa such as profiling. Sometimes privacy notices contain more information about recipients or international transfers that is does not correspond with RoPA entries.
This detailed review of information leads to the accumulation of evidence which I tend to reference in the audit report to enable the reader to actually go and find the records I reviewed and recreate the findings. The following table illustrates a sample of SARs reviewed as part of an audit.
Similarly, the table below contains the sample of log of personal data breaches reviewed during an audit. The audit report narrative would explain why each personal data breach reviewed was handled compliantly and, in the cases below, why there was no requirement to notify the ICO.
Assessing Compliance
Once I’ve given each of the 30 or so topical areas of compliance a good prod, we come to the task of assessing compliance.
In reality, compliance is a pretty Boolean concept. Either an entity is able to demonstrate that they are compliant or they are not. But so far I have not found any organisation that is fully compliant. Therefore we have, for now, adapted our audit methodology to introduce a more subjective rating assessment between “non-compliant” and “compliant” to include “partially compliant” and “largely compliant”. But this means that the compliance rating is in danger of becoming too subjective. To counter that, our audit process includes a peer review where the auditor justifies their rating with a colleague which acts as a bit of a sense check and calibration.
Tricky Areas
There are several areas that are tricky to assess including privacy by design and by default, accountability and the security of processing. I’ll have to write a separate blog about how to go about assessing these areas but suffice to say, they are tricky because the GDPR is less prescriptive. It is clear about what it expects in terms of security for instance but what it expects are risk-based controls so the first thing I look for is evidence of the risk assessment methodology. I have to say that in most audits, there is no mature approach to data protection risk management which makes me wonder how a controller is able to demonstrate (6th data protection principle) that personal data is processed in a manner that ensures appropriate security of it.
We have developed an assessment framework for these tricky areas which are best being the subject of a separate blog.
Compliance v Assurance
However, on occasions, I have found no evidence of non-compliance. This interesting conundrum illustrates the Boolean nature of compliance. Does the absence of evidence of non-compliance render an entity compliant? If, for example, a data controller has never received any form of information rights request, are they able to demonstrate compliance with their obligations which in short form are to comply with requests within one month etc. etc. If they have never received a request, there is no evidence of either compliance nor of non-compliance. To be clear on this point, evidence of non-compliance with Article 15 would be that a controller didn’t respond to a SAR within a month, perhaps wrongly withheld personal data from disclosure, or incorrectly applied an exemption. What does a lack of any evidence one way or another mean to an auditor?
For me, I turn to the concept of assurance. How confident am I that the controller would handle a rights request in a compliant manner? And for confidence to be high, I’d need to see evidence of some compliance framework including, for example, a properly implemented policy, records of SAR training, and a register of requests albeit an empty register in the case in hand.
Corrective Actions v Recommendations
In theory, any non-compliance should have an associated corrective action – action that is required to correct the non-conformance. And here auditees have two options. Firstly they could correct the non-conforming organisational behaviour or on the other hand, they might choose (where possible) to change the measure against which they have been assessed. For example, in data retention, if a controller states that they will only retain personal data for unsuccessful job applicants for 3 months and during the audit we found records that were older than this we would rate them as non-complaint. The controller could either change their retention policy to accommodate the behaviour, or change the behaviour and implement TOMs to ensure that the retention period is adhered to.
It’s not really possible to have a non-compliance without at least one corrective action but the auditor can also make recommendations. As a seasoned privacy practitioner, a GDPR auditor could make observations that processes are not fully tested, or are weak compared to best practice observed elsewhere. Recommendations can be made to enhance control and efficiency.
The Audit Report
Unfortunately, a detailed audit over 30 topical areas punctuated with evidence results in a pretty comprehensive audit report. This is, of course unavoidable. In my experience shorter, graphical, superficial reports are harder to work with. But the auditor has to ensure the report is factual, precise, and easy to understand. It needs to be as concise as possible and avoid flowery language.
The compliance rating needs to be clear as does why a particular rating has been applied to each area assessed and what should be done to correct non-compliances.
The corrective actions ideally are separated into major and minor to help auditees prioritize implementing remediation. I once did an audit where cookie compliance was the only non-compliant area of the assessment and because it was the only “red”, the client determined that this must therefore be the most important area to address. Silly me! Fortunately in the audit report presentation I stressed the greater need to bring privacy information up to full compliance. Sure cookies were important, but not as important as the processing activities being demonstrably fair.
A long audit report therefore needs a punchy summary and I’ve found that grouping compliance measures into four categories is quite a good way of giving a high-level overview. Applying a notional score for each of the 30 or so assessment points allows a numerical score to be evaluated which can be expressed in a table such as that below.
Looking at the scores on a spider chart starts to show where an organisation is strong and weak. The devil is in the detail of course. An organisation may have a great-looking privacy framework but if there is insufficient evidence of it being effectively implemented, it’s not going to score full marks. Arguably, that’s quite an easy fix though.
Conclusion
It’s all very well Data Protection People having a mature and effective audit framework, but what if next year, an organisation decides to do an internal assessment or use a different third-party company? Where’s the consistency? What we really could do with is a standardised approach adopted by all data protection auditors. Something dare I say similar to the excellent Audit Manual that the ICO produced way back in 2001.
If you would like to download our auditing data sheet with a full breakdown of the services we provide click here: Compliance Audit – Client Data Sheet-1 (2)
EVENT – Be Audit You Can Be
On the 22nd of July Data Protection People will be hosting a live webinar where we will discuss data protection audits with our growing community of over 950 subscribers, during the session the author of this article, Phil Brining, will be joined by Oliver Rear and David Holmes to share their top tips on how to get the most value from your audits. if you would like to sign up and become part of the conversation, click here.