Two years on and GDPR is still going strong. However, there’s still so much in front of us. Case law and other regulations like the new ePrivacy Regulation (ePR) whenever it will be approved will bring even more changes.
In retrospective, the implementation of GDPR was an eye opener to so much more than the mere implementation of a regulation. Like any Change program, The GDPR implementation affected every part of the organisation in a way that could be deeply transformative, even disruptive.
The reason for this is because, like dice, Data Protection has many interconnected faces. I particularly like The POPIT model, a development of Leavitt’s Diamond to explain the different elements to be considered during a Business Change process:
- Information and Technology
The challenges smaller organisations have tend to be different from large ones. Smaller firms may have more issues with resources or having a full time person in charge of Data Protection. Some tech startups may not see GDPR as a priority.
Larger organisations, on the other hand, may find difficult to have a unified Data Protection front if they have many auto sufficient business units that are not in a close geographical proximity.
Other times organisations are structured in silos and they may not know what happens with data that leaves their area, to move into another within the same company. It’s also possible that personal data is treated differently in different areas; even in the same area, depending on the project. This can cause re-duplications but also inaccurate data. Organisational changes may be hard and take time to plan. A good outcome of the project is to build robust data governance.
The more Data Protection practitioners liaise with the Legal department or the IT or Cybersecurity department (depending on where the function is) the more successful the implementation and the business as usual afterwards will be.
Processes may not be mapped or stakeholders may not know there’s a process. Sometimes, things are done in a certain way but not recorded.
Mapping and changing processes may mean cutting through silos and the collaboration of adjacent areas that were working separately before like marketing and analytics. That could also lead to changes in the organisation to reorganise the work that is carried out.
A process that needed to be created was certainly providing way for data subject rights: mostly for access and deletions requests: processes that could also go across different areas of the business and would need assistance from IT.
Information and Technology
The most troubling word that can be heard in this area is legacy: legacy systems, legacy data. Old systems that may not be able to delete data or providing the necessary technical safeguards anymore.
This is the area where automation of data retention schedules or privacy engineering lives. Privacy engineering is an area that is growing. LINDDUN is an example of privacy threat modelling methodology to deal with privacy threats in software architectures.
It’s very important to work alongside Cybersecurity, too (if Data Protection does not reside in this area) as there are many similar challenges that were faced by this area some years ago and have a very acute sense of risk management.
People: mostly, people
All the areas above must be worked on. Changing one of these elements has an impact upon the other three, as all four aspects are interrelated. In addition, there needs to be an alignment with the business, as change has to be planned taking into account the idiosyncrasies of an organisation in order to be successful. The most important part of a GDPR program is to influence the mindsets of people, so there’s a different approach to personal data. Sometimes, that also means learning what data is and what it can be: the significance in organisations and in our personal lives. The cultural change. This could be done through different kinds of awareness programs and training.
Building Data Protection by Design and Default starts within the hearts and minds of the people.
The change in mindset comes first and fore-mostly from understanding what data is, what particular data types a business collects and how is processed in a particular area and the business as a whole. Stakeholders will understand not only from an intuitive way what’s the work their area is actually carrying out. This is an interesting distinction to understand and improve processes but also to understand the value of personal data. Also teaches about risk and liability.
Once knowledge about data has been built, we can start asking questions about how processing can be carried out with less or with different data; What’s the reason to retain data or asking ourselves if are we supposed to carry out the processing in the first place.
Data Protection has as many faces as each one of us, as Personal data are the immense amounts of little bits of us generated in each interaction that live in a digital form. Even if Data Protection programs can be complex and overarch many countries and jurisdictions, they always refers back to the protection of the individual: the right to privacy that needs to be taken in consideration and balanced when necessary but never forgotten as we risk to lose it otherwise.
One Reply to “A GDPR Retrospective”
This is a short and effective article, Maria. Thanks for sharing!