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.).
The GDPR applies to the processing of personal data no matter how it takes place (online or offline)
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:
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.
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.
The GDPR requires you to appoint the EU-representative “in writing”. You may use for instance our standard appointment agreement, available via .docx direct download:
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.
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.
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.
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 for 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.
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.
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.
A base template for the Data Processing Agreement can be found via .docx direct download:
Pursuant to art. 37 GDPR, controllers must under certain conditions appoint a Data Protection Officer (DPO). But what is a Data Protection Officer?
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
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.
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.
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.
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.
Under the GDPR, the appointment of a DPO is mandatory in three scenarios:
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 .docx direct download:
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:
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 staff 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 .docx direct download:
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?
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:
The DPIA process should be recorded in writing.
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:
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:
Since you’ve ticked off your offline compliance duties, why don’t you check that you’re 100% compliant?
