Here is a summary of the most common mistakes that arise in adopting the sets of measures designed to ensure GDPR compliance. We need to learn from these mistakes and become proactive. Only in this way we can demonstrate our accountability, the seventh GDPR principle (as some consider) and become responsible for our responsibility.

Lack of a project plan – the decision to “do something for the GDPR” was most often made under pressure, passing the responsibility of someone from IT or from the Legal, who started why they thought it was more urgent. Of course, anyone can lead an action team, but without a step-by-step implementation project, it is difficult to see the end of the road and to make the alignment efforts more efficient.

Nothing was done until the appointment of a DPO – this delayed things quite often, wasting precious time to initiate organizational measures, which could also be taken in the absence of a DPO, where the appointment is mandatory.

Incorrect understanding of the notion of ”Personal Data” – the definitions in Art.4, the preambles and WP29 guides did not solve the problem of correctly identifying personal data. There are many websites that at the Cookies Policy declare that they do not use personal data. Certainly their administrators did not find out that IP is considered as personal data, they simply did not bother to update their policies…

The difficulty in establishing the role of Controller or Processor – the mere analysis of the fact that an organization determines the purpose and the means is not sufficient to assume the Controller role. There is still a lot of confusion between the position of Processor and that of Joint Controller or Independent Controller (B2B). The most omitted idea is the same organization may play different roles in the processing of personal data, depending on the business process being analysed.

Excess of Consent – too much emphasis is placed on obtaining the agreement, to the detriment of the other 5 legal grounds that can justify the processing of personal data. You can avoid the need to obtain consent by introducing an additional provision in a contract. Moreover, it does not take into account the requirement that a consent can always be proven, in the idea that it can be withdrawn with the same ease with which it was obtained.

Lack of online transparency – Many organizations that have a website do not show transparency by not publishing a Privacy Policy or Notifications for processing personal data. The presence of a page with the privacy policy of the organization is a public declaration of conformity and a label is trusted for the way the personal data is processed.

Non-updating of content – There are concerns that many of the sites that publish a Privacy Policy have not updated their content, referring to Law associated with EU Directive from 1995 or continuing to display the Registration Number as National Operator of Personal Data. This may be a reflection of the fact that the organization to which the site belongs has not made enough efforts to ensure the alignment, failing to update the only visible content, meant to publicly confirm compliance and take responsibility for the personal data processed.

Deficiencies of Internet pages – a lot of public sites do not have a Terms and Conditions page, which establishes rules for accessing and browsing online, although this is not a GDPR requirement, but a rule of conduct for all organizations present. Internet.

 Lack of cookies bar – There are many sites that, although they have a page dedicated to the cookie policy, do not have a cookie bar that requires them to accept their use before starting browsing the site.

Unnecessary Acceptance of Privacy Policy – There are many websites that use online forms for collecting personal data (newsletter sign-ups, contact page, document downloads, etc.) and make it necessary to send this data by checking a box to accept the Privacy Policy. Why do we ask for this approval? It is my Policy as a Data Controller and it is public. At most I can make a reference informing that the personal data collected through the form are processed only for the purpose for which they were collected, according to the Privacy Policy.

Lack of granularity in requesting the agreement – there is excessive use of the Legitimate Interest, as a legal basis for marketing processes, which also involves third parties, without a granular approach to the types of activities that fall into this category of processing activities.

Granularity Abuse – granular pop-up pages are displayed, with the possibility of setting options, but which appear with pre-ticked acceptance boxes – a serious contradiction of the rules for requesting/obtaining consent in the spirit of GDPR.

Conditional consent without the possibility of opt-out – the vast majority of cookie bars offer only the option of OK, with the condition of continuing browsing by choosing this option. As I pointed out in a previous analysis, not everything the old ePrivacy law allows is GDPR acceptable, where consent to the use of cookies does not have to be conditional on access to the content of the page. Of course, the user must know the consequences of not accepting cookies, but this must be his freely agreed option. Moreover, the GDPR teaches us that a consent obtained through a certain process must be as simple as possible. That is, if I put a box of Accept on the cookie bar, it is absolutely advisable to offer the possibility of opt-out, by displaying a box of Reject.

Protection vs. Security – there is a high degree of confusion between data security and personal data protection. Data protection involves all the measures that can be taken to restore them in case of loss or corruption. While data security refers to the mechanism for keeping data safe, from unauthorized access and distribution. Data security protects data from unauthorized access that could lead to data corruption or deletion, if data security strategy fails, data protection facilitates the recovery of clean data copies.

Incident vs. Security breaches – At the same time, there is confusion between Security incidents and Data breaches. An incident can be any event that violates the security or confidentiality policies of an organization and can be anything from a malfunction of a memory unit, to the loss of a laptop containing personal data. A data breach, on the other hand, is an event that led to a loss or theft of data, the severity of the loss being quantified by the volume and importance of the data affected. By Art.33 the GDPR obliges the organizations to report a data breach within a maximum 72 hours from the awareness of the breach, recommending a breach plan and organizing a response team to the data breach. One of the duties of this team is to keep a strict record of the Security incidents, in the idea of ​​being able to later associate the emergence of a breach of the vulnerability of the system that led to its occurrence.

Can all these problems be solved? Surely, yes, as long as everyone involved understands and takes responsibility. The success of a long-term GDPR project is based on creating an organization-wide culture, in which people primarily think about how they would like their personal information to be processed. Companies must adopt this attitude when handling personal data of customers, employees and other subjects. It’s not just about threatening financial sanctions. It’s about business continuity and building a trustworthy attitude.