One of the most common misconceptions is to think that the GDPR only applies to the online environment: it doesn’t!
The GDPR is technology-neutral: it applies to the processing of personal data no matter how it takes place (online, offline, via a website, via an app, in an employment relationship etc. etc.).
This post dives into what we’ll call offline-compliance. Find some of the most relevant offline-compliance requirements to be taken care of below:
- Appointment of an EU-representative
- Data processors and Data Processing Agreement (DPA)
- The Data Protection Officer (DPO)
- Confidentiality obligations of employees
- The Data Protection Impact Assessment (DPIA)
1. Appointment of an EU-representative
If you are a controller based outside of the EU, but you are offering goods or services (even for free) to EU-based users or you are monitoring their behaviour as far as it’s taking place within the EU, you have to appoint an EU-representative established in one of the EU countries your Users are based in.
The EU-representative may be a natural or legal person.
What does the EU-representative do?
The EU-representative acts as one-stop-shop for any inquiries, requests or claims submitted against the controller by data subjects or supervisory authorities. This means that the representative has to forward to the controller any such inquiry along with all thereto related information it disposes of. More generally, it has to support the controller in complying with the GDPR under all aspects, including but not limited to notifying data breaches or cooperating with supervisory authorities. In general, however, the controller and not the representative bears all responsibility for the data processing activities.
The EU-representative also has specific own obligations (and thereto connected liabilities). For instance, it has to maintain records of processing activities.
How to appoint the EU-representative (template)
The GDPR requires you to appoint the EU-representative “in writing”. You may use for instance our standard appointment agreement, available via Quip (where you can export – top left corner – into various file formats) and .docx direct download:
2. Data processors and data processing agreement (DPA)
When processing personal data as a controller, you often need to have a part of the processing activities done by an external supplier. Such a supplier will then typically process personal data referring to your clients on your behalf: it will not process them in its own interest. Such suppliers are called “processor” by the GDPR and the underlying relationship with you as a controller is a data processing order.
Let’s look at a practical example:
You have an online shop for shoes. When customers place an order, the shoes are actually packed and prepared for delivery by your external supplier, who obviously needs to receive all necessary customers’ personal data to fulfill the order. The external supplier is, therefore, processing customers’ data on your behalf as a data processor.
What do I need to do?
Pursuant to art. 28 GDPR, data controllers and data processors must close a “Data Processing Agreement” in writing – including in electronic form. Such agreement is intended to specify the parties’ rights and duties in the performance of processing activities by a processor. Just to name a few, processors shall only act on instructions by controllers, adopt adequate technical and organizational security measures to ensure personal data protection, cooperate with the controller in case of data subjects’ inquiries or actions by supervisory authorities, etc. etc..
The greatest news brought about by the GDPR is that, pursuant to art. 82, controllers and processors bear a joint liability vis-à-vis third parties. This means that, whenever a data subject considers that his data have been processed unlawfully, he may turn to the controller or to the processor and claim compensation of the entire damage suffered. Only subsequently may the party that has paid compensation, in turn, take recourse to the other one.
A data subject receives a pair of shoes delivered at his home address, although he has never ordered them. He chooses to claim compensation from the fulfillment supplier. The latter pays and eventually takes recourse to the controller since that’s who issued the instruction to deliver the pair of shoes to the complaining data subject.
What happens if I don’t appoint all my suppliers as processors?
Any entity that’s not appointed as a processor is a “third party“. Therefore, if you forward personal data of your clients to any party that has not been appointed as a processor, from a legal perspective you are transferring data to a third party: which you can only do according to a legal basis – typically the data subject’s consent. However, it’s often not easy to meet the requirements of valid consent when transferring data to a third party.
DPA and transfer of data to third countries
Sometimes the processors you appoint for specific data processing activities are based outside of the EU. This confronts you with the problem of providing a valid legal basis for the transfer of personal data to such country. We have explained the different legal bases available here. What must be stressed is that the legal basis for transfer and the DPA are two different issues that may or may not coincide with the same document.
Here are some examples:
– You transfer data to Google (e.g. Google Analytics). You will need to sign a DPA with Google, but your transfer of data to Google, Inc. in the US will be based on the Privacy Shield agreement, that Google Inc. is adhering to.
– You transfer data to a company based in Australia. Currently, there is no adequacy decision or any other framework, such as Privacy Shield, applicable to transfers to Australia (from the EU or Switzerland). Therefore, you might want to base the transfer on “standard contractual clauses”. If so, your DPA with the Australian data recipient will include also the standard contractual clauses provided by the European Commission’s decision 78/2010/EC. In this case, the basis for transfer and the DPA will actually coincide.
A base template for the Data Processing Agreement can be found via Quip (where you can export – top left corner – into various file formats) and .docx direct download:
3. The Data Protection Officer (DPO)
Pursuant to art. 37 GDPR, controllers must under certain conditions appoint a Data Protection Officer (DPO). But what is a Data Protection Officer?
What is a DPO?
A DPO is a natural (or legal) person, that has to supervise the controller’s (or processor’s) compliance with privacy provisions. Whenever the conditions for a mandatory appointment exist, the DPO must at least
- inform and advise the controller (or processor) and their employees about relevant data protection provisions;
- monitor compliance with such applicable provisions, first and foremost the GDPR;
- upon request, assist the controller (or processor) in connection with the data protection impact assessment (DPIA) and monitor its performance;
- cooperate with and act as contact point for supervisory authorities on any issues relating to the processing of personal data;
- act as contact point for data subjects with regard to all issues related to the processing of their personal data and to the exercise of their rights under the GDPR.
The GDPR does not expressly require the DPO to be a natural person: this means, in principle also a legal entity such as a consultancy company may be appointed as DPO. However, already now various commentators are pointing out at least some of the requirements provided for by the GDPR can only apply to a natural person: for instance the “professional qualities and, in particular, expert knowledge of data protection law and practices and the ability to fulfill the tasks referred to in Article 39 GDPR” are clearly to be referred to a natural person, rather than to a legal person.
However, at this stage it’s not possible to answer this question conclusively: we’ll have to wait and see which approach is embraced by data protection authorities and/or courts of law.
How does the DPO perform its tasks?
First of all, the DPO can be either internal to the controller’s organization (typically an employee) or an external supplier (free-lance). In both cases, he may also fulfill other tasks or duties while performing its activities as a DPO. However it must always be guaranteed that this does not result in a conflict of interests: therefore, the company’s managing director may for instance not be appointed as a DPO. The same applies to the CTO: it would be rather awkward to have the same person develop the IT infrastructure and have it checked from a personal data protection point of view!
Overall, the DPO is subjected to a statutory duty of secrecy regarding any information learned while performing its task, and must always maintain full independence (even if formally he’s an employee!). This means that the DPO must be provided with all necessary means of work, workforce, and budget to fulfill its tasks and may not be subjected to any directive powers.
Let’s look at a practical example:
The data protection authority carries out a data protection audit and requires access to the registry of processing activities pursuant to art. 30 GDPR. The DPO knows that there is no such registry because the controller never took this requirement too seriously. However, the DPO must be neutral and may not “defend” the controller with some excuse: he must confirm that the registry has never been made.
In terms of liability, it’s important to note that the DPO is not liable for the controller’s compliance. The DPO’s duty is to inform, advise and cooperate as already described. If the controller does not follow the DPO’s advice, it’s its sole responsibility. The DPO could only be considered liable vis-à-vis the controller if he has delivered wrong advice. But even then, with respect to the data subjects, the controller shall always be liable.
When do I have to appoint a DPO?
Under the GDPR, the appointment of a DPO is mandatory in three scenarios:
- the controller (or processor) is a public body or authority (e.g. an administrative or governmental agency);
- the core activities of the controller (or processor) consist of processing on a large scale of sensitive data or personal data relating to criminal convictions and offenses;
- the core activities of the controller (or processor) consist of processing operations which require regular and systematic monitoring of data subjects on a large scale;
The scenarios nos. 1 and 2 are relatively clear: “sensitive” data are data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation.
But what about the “regular and systematic monitoring of data subjects on a large scale”? Does this only apply to entities such as Facebook or Google, whose business model is pretty much based on the massive processing of personal data, or is this already applicable if – say – you implement Google Analytics in your webshop since this feature allows you to monitor your customers?
The truth is: we don’t know yet. Several authorities, commentators, and experts, such as the WP29, have delivered their two cents on this issue, but none of them is legally binding. Therefore, also in this regard, all we can do is wait and see which approach is embraced by data protection authorities and/or courts of law.
Here’s a template for a DPO appointment, currently available via Quip (where you can export – top left corner – into various file formats) and .docx direct download:
4. Confidentiality obligations of employees
Although the GDPR, unlike some pre-GDPR legislations (e.g. the Italian and German), does not introduce an express and general requirement to subject employees or, more generally, staff involved in the processing of personal data to a confidentiality obligation, it is still advisable to inform staff members about the duty of secrecy and to have them sign a binding obligation in order to meet the conditions set by some GDPR provisions, such as:
- The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by Union or Member State law (art. 32 par. 4).
- The processor ensures that persons authorized to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality (art. 28 par. 3 lit. b).
- The data protection officer must inform and advise the controller or the processor and the employees who carry out processing of their obligations pursuant to this Regulation and to other Union or Member State data protection provisions (art. 39 par. 1 lit a).
On top of all that, art. 24 requires the controller to “be able to demonstrate that processing is performed in accordance with this Regulation”, which at least indirectly also includes being able to demonstrate that employees and other stuff have been processing personal data in compliance with the GDPR.
We suggest that you close a specific confidentiality and non-disclosure agreement with all staff members, thereby referring to the instructions about the correct dealing with personal data you have previously given to them. You should make sure that such instructions are handed out to staff and signed for receipt, in order to be able to eventually provide evidence thereof.
A template for non disclosure/confidentiality of employees is currently available via Quip (where you can export – top left corner – into various file formats) and .docx direct download:
5. The Data Protection Impact Assessment (DPIA)
Pursuant to art. 35 GDPR, controllers must under certain conditions proform a Data Protection Impact Assessment (DPIA). But what exactly is a Data Protection Impact Assessment?
What is a DPIA?
A DPIA is a process used to help organizations comply effectively with the GDPR and ensure that the principles of accountability, privacy by design and privacy by default are put in practice by the organization.
The DPIA should include:
- Full descriptions of the data processed
- The purpose of the processing activity (and where applicable, information on the legitimate interests of the data controller)
- An evaluation of the scope and necessity of the processing activity in relation to the purpose
- An assessment of the risk posed to users
- Measures in place to address that risk
The DPIA process should be recorded in writing.
When is it mandatory?
Generally speaking, the DPIA is only mandatory in cases where data processing activity is likely to result in a high risk for users (this is particularly applicable when introducing new processing technology). However, if unsure as to whether or not your processing activity falls within what is considered “high risk”, it is recommended that a DPIA be carried out nonetheless as it is a useful tool for ensuring that the law is complied with.
“High risk” data processing activities include:
- Large-scale processing of sensitive data
- Systematic monitoring of a publicly accessible area (e.g. CCTV)
- Situations where there are extensive automated evaluations of personal data that is intended to influence decisions that can affect the user’s life significantly
DPIAs can also be required in other circumstances (based on a by case evaluation) including but not limited to processing data concerning vulnerable persons (e.g. children, the elderly), data transfer across borders outside the EU and data that is being used in profiling (e.g. credit scores). You can read more about the criteria here [PDF].
While publishing the DPIA is not a general legal requirement of the GDPR, it is suggested that data controllers consider publishing all or part of their DPIA as a gesture of transparency and accountability, especially in cases where members of the public are affected (for example, where a public authority carries out the DPIA).
An effective DPIA is useful in meeting the requirement of “Privacy by design” as it makes it possible for organizations to find and fix issues at an early stage, thus mitigating both data security risks for users, and the risk of fines, sanctions and reputation damage that might otherwise occur to the organization.
A base template for the Data Protection Impact Assessment can be found here: