I think it's safe to assume we all process personal data in our business or organization. Most of us also use several vendors and systems to help us organize and streamline operations, for example (depending on your business or organization) for email, bookkeeping, online storage, medical journals, video conferencing, webinars, newsletters and more.
You already keep records of your processing activities (“ROPA”, Article 30), where you (hopefully) also have your processors listed. You know – those processing personal data on your behalf. These can be more or less pure system providers (like Confrere, Whereby, Fathom Analytics, Protonmail etc.) or agencies/consultancies (for IT support, software development, project management, marketing etc.).
And, of course, you’ve already checked that you have data processing agreements (“DPA”, Article 28(3)) and safeguards for international transfers (like SCCs, Chapter V, in line with Schrems II) in place. ✅
PS: Access the GDPR online with all its Articles and Recitals on this ads-free tracking-free site: GDPR.Fan
On top of this, you have to audit these processors, "audits, including inspections". This is part of the requirement for ongoing compliance as per the GDPR.
Auditing all of your processors can seem like a daunting task (especially if you’re a school or municipality with 200-500 systems, which isn't uncommon). Unfortunately, the GDPR doesn’t say anything about the level of audit or what’s specifically required.
Fortunately, we have pro-active data protection authorities like the Danish one to give us concrete advice. 👏 The following builds on their very useful guidance for auditing processors.
And here is a snapshot of the process:
Start with a solid overview
So I mentioned the ROPA (might as well learn that acronym straight away). Apart from knowing Article 5 by heart, this is the one thing you must have in place for your GDPR compliance. No ROPA - no idea what you're doing.
The ROPA should provide the complete overview over all your processing activities.
When you know this is in place, auditing your processors will be so much easier! And here’s what you need to do – first:
- Ensure your ROPA includes all processors you use.
- Check that you have DPAs in place with all processors.
- And that every DPA is up to date (red flags are those referring to the -95 Directive or outdated national legislation…).
- And while you're at it, check that you have safeguards (like SCCs) in place for international transfers – and that these are current, too.
Now that we got the basics down, move on to assessing the risk profile for the processing and processor. A few key factors increase the risk profile of the processor you're about to audit:
- The amount of personal data.
- The number of people.
- The categories of personal data.
- Special category personal data.
- Sensitive personal data.
- More invasive processing.
On one extreme you can have a website form collecting subscriptions for your Bergen city rain alert (which would be, let’s be honest, a frequent newsletter!), totaling 276 subscribers (email only). On the other extreme a mental healthcare hospital can have thousands medical journals with numerous pieces of all sorts of highly sensitive personal data. Obviously, these two scenarios require two completely different audit approaches.
Scoring scale and audit concepts
Finding the right level of audit can be tricky. You don’t want to do too little (especially if you at a point must demonstrate these efforts to an authority) – but you don’t want to overdo it either as audits take time, resources and can be very costly if conducted by third parties.
To help us with this, the Danish supervisory authority created a guiding model for assessing how to conduct audits and inspections of processors.
The model includes a points scale to give us a sense of how risky the processing of personal data in question is, as well as six concepts which gradually increase the level of audit recommended for a given processor.
A low sum represents lower risk and you can choose from one of the least resource-intensive concepts. In contrast, the higher the sum – the more risk and higher requirements for conducting (more resource-intensive) audits/inspections.
Here’s the scoring scale, shown slightly different from the actual guidance:
The facial expression gives you an indication of how daunting the audit might be. ;)
Although I really like the Danish SA’s guidance, I don’t think it's necessary or realistic to recommend concepts 5-6 for the lowest scores (and it's unclear why they’ve set it up like this). For example, you wouldn’t ask for an external audit twice a year for the processor you're using for that Bergen rain alert…
What and how to audit – the six audit concepts
First and foremost you must audit the data processing agreement (DPA) and ensure that it includes all requirements as per Article 28(3).
Next, you can base your audit on one of the six concepts described in the guidance. For any of the concepts, always keep your correspondence with the processor. You might need it, for example if you end up being audited by an SA yourself. 😬
In addition, keep an eye out for any relevant press/news involving the processor, especially related to any data breaches/security incidents. If you become aware of any such incidents, consider conducting an additional audit and assess the need to conduct higher-level audits (a higher concept) onwards.
Concept 1: 🟢 Passive approach
💡 No need to actively audit the processor.
If the processing in question is low risk and you use a credible and widely recognized processor, you can probably trust that they comply with the DPA and there’s likely no need to audit them as such.
If something happens you’d have to get in touch of course, for example if your data all of the sudden has gone missing or you read about a data breach/security incident they’ve had.
Concept 2: 🟢 Regular confirmation
💡 Regular confirmation of DPA compliance.
If the processing in question is low risk and you use a credible and widely recognized processor, a regular (preferably written) confirmation of their ongoing compliance with the DPA is likely sufficient. Depending on the processing, conduct this audit yearly or bi-yearly.
Concept 3: 🟡 Annual confirmation
💡 Written, annual confirmation of DPA compliance.
Conduct annual audits of the processor, where they confirm ongoing compliance with the DPA and other relevant areas (for example related to organizational or product changes).
The processor could post annual updates/reports on their website and/or pro-actively send such updates to all customers. What’s important is that you get some sort of annual update that you can save in your compliance folder.
This annual update should also include information about any particular clauses you might have agreed, for example if the processor is to delete test data at regular intervals. If their annual update doesn’t include this information, ask for it specifically and also consider conducting ad hoc sampling to verify their compliance.
Finally, ask the processor to disclose if they’ve had any data breaches since the last audit. If they have, make sure you get comprehensive information about the breach, assess if the processor notified you in time and consider if you need to audit them more often/extensive going forward.
Concept 4: 🟡 Certification/CoC
💡 Confirmed certification or Code of Conduct.
The processor should confirm, in writing, that processing of personal data on your behalf happens according to a current certification as per Article 42 or approved Code of Conduct (CoC) as per Article 40.
This one’s interesting, as there are no officially approved certification schemes as of May 2022 (although there are several initiatives in progress) and very few EDPB approved CoCs (and the ones approved appear to have a national scope only) – indeed, the only one we could find in Denmark is related to the Ministry for Ecclesiastical Affairs for parish care. Here, the Danish SA could have provided other options for this concept until we have officially available certifications/CoCs.
In the meantime, I recommend obtaining a written confirmation from the processor stating that they have taken steps to comply with the GDPR in all aspects relevant for the processing they do on your behalf. Key areas should be specified (for example if they have ensure encryption, deleted test data at agreed intervals etc.). And as with concept 3, ask about and get written confirmation relating to breaches.
Concept 5: 🔴 External audit
💡 Third-party audit.
Base your audit on third-party standards, for example ISAE 3000 (the international standard on assurance engagements for non-financial information) – and if you rely on ISAE 3000 for processing with 7-10 points you should select the “high” (full version) one (instead of the “low/light” one).
You can also rely on other parties’ audits, for example if an industry/interest organization conducts audits on behalf of their members or an authority conducts audits on behalf of several authorities. Finally, you and other controllers can authorize an independent third-party to conduct an audit on behalf of you all.
Regardless of the approach, you should ensure that the audit:
- covers all processing activities conducted by the processor
- covers DPA compliance
- covers any specific requirements agreed in the DPA (beyond the standard ones)
- covers how the processor ensures compliance with the requirements with sub-processors (if any)
- is conducted by a party independent of the processor (the auditor shouldn’t be part of the processor’s company or organizational structure (main company, subsidiary etc.), nor have any financial ties
Concept 6: 🔴 Risk assessment + external audit
💡 Third-party or own audit.
Start with conducting a risk assessment to determine what to audit and how extensive the audit should be. And keep in mind – the assessment should focus on the risks for the data subjects (not your company risks!).
Assess first how and where the processing (the processor is doing on your behalf) can go wrong, then what and how much must be audited to minimize these risks you’ve identified.
The intention with the audit is to uncover how the processor fulfils their obligations as per the DPA, for example related to ensuring compliance with sub-processors, notification of personal data breaches, security for the processing, specific (additional) DPA requirements agreed for your particular processing activities, etc.
You can conduct the audit by sending the processor a questionnaire, reviewing and controlling the response and, if necessary, clarify on any uncertainties.
How often should you audit?
The rule of thumb is: the more “severe” the processing is for the people involved (the data subject you process personal data on), the more rigorous audits with any processor involved in the processing. Sometimes this means conducting annual, external audits – sometimes you wouldn’t even require anything specific from the processor (just do an online check for security incidences, for example).
The Danish SA gives some concrete examples for situations that would increase the audit frequency or trigger additional audits:
- 🚩 The processor struggles with keeping agreements (not only the DPA).
- 🚩 They’ve had several serious security incidents, including (so not limited to) personal data breaches, especially if they haven’t pro-actively informed you about such (that they’re required to).
- 🚩 They change sub-processors frequently.
- 🚩 They have frequent legal, structural changes such as new owners, M&A activities or other extensive organizational changes.
Any of the items above, as well as significant societal events such as a pandemic, could change/influence the way people work (and thus how your data is processed), where data is stored etc. and could be a reason for conducting additional audits.
Similarly, if you have used a processor for years without (major) discrepancies or breaches and they always respond timely to your inquiries, you can conduct more infrequent audits.
