Written by: Guy Bakshi
This is the monthly edition of “Ask the DPO”. Our Head of DPO Services, Guy Bakshi, looks at frequent questions that the DPO is asked. This time, we tackle some of the most common privacy misconceptions.
Myth: “We’re GDPR compliant”. Reality: You’re probably not.
The GDPR is a regulation, not a certification. A closer look at the GDPR’s provisions will show that there is room for controllers and processors to adjust requirements to their operations and activities. This is not a coincidence. The GDPR is meant to apply broadly. At its core, it assumes that there is a huge variety of organizations of all shapes, processing personal data in lots of different ways. It is meant to be followed by small, medium, and large-sized controllers and processors across all sectors.
On top of that, every company has its own risk appetite and tolerance, gaps, and grey areas. Some companies are willing to take the risk of not being 100% transparent. Some companies are missing required privacy documentation. Not all privacy policies, consent flows, or processes are fully compliant. Some take some risks with their cookie practices, so as not to damage their marketing efforts. This is acceptable, provided you understand what the gaps are, the risks involved, and the implications.
Remove those “GDPR Compliant” statements from your documentation and websites. Instead, invest in transparency. As a DPO reviewing vendors on an ongoing basis, I would rather see a well-written privacy policy that is up-to-date than such compliance statements.
Myth: “We don’t process the data. We just store it”. Reality: You do process data, even if you’re not actively accessing it.
Under the GDPR, “Processing” is defined to include storage. Consequently, storage constitutes processing, by definition.
Even if you treat the dataset as a “black box” and do not intend to touch it, you are still engaged in processing, and the GDPR applies.
If you store the data for someone else, you are likely a processor, and your storage provider is your subprocessor. Ensure you have a DPA in place that addresses this with (a) your customer and (b) your subprocessor.
Myth: “IP addresses are personal data”. Reality: It depends.
It is often said that IP addresses are personal data. However, their nature dictates their classification. IP addresses could certainly be considered personal data, but only if they can be traced back to an individual. This aligns with the concept of identifiability. To clarify, let us examine the definition of “personal data” under the GDPR.
“Personal Data” is defined as “any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”.
Once we understand the identifiability concept, we can confidently argue that an IP address of a company server, for example, is not personal data, if it cannot be linked in any way to an individual.
Myth: “We’re just the processor. It’s the controller’s job to send over the DPA”. Reality: Both parties are responsible.
According to Article 28(3) of the GDPR, “processing by a processor shall be governed by a contract…”. The GDPR is silent on the question of who is responsible for establishing this contract. Guidelines from the European Data Protection Board (EDPB) clarify: “Both the controller and processor are responsible for ensuring that there is a contract or other legal act to govern the processing. Subject to the provisions of Article 83 of the GDPR, the competent supervisory authority will be able to direct an administrative fine against both the controller and the processor, taking into account the circumstances of each individual case”.
Even if we set the legal requirement aside, from a commercial/business standpoint, you have an interest as a processor in having the controller sign your DPA template that fits your operational limitations and capabilities, business goals, and commercial interests. Do not blindly sign any DPA provided by controllers. Invest in a good template. Strive to use it. Also, refer to our previous edition of “Ask the DPO” for some tips on DPAs.
