Unless developers understand GDPR and how to implement it, compliance will never happen and the level of ethics on personal data will never rise. We need a new generation of Privacy Developers.

59% of privacy incidents originate with an organization’s own employees

The United Nations Conference on Trade and Development (UNCTAD) calculates that 128 out of 194 countries have put in place legislation to secure the protection of data and privacy. 66% of countries globally have data privacy regulations in place, and 10% of countries have drafted legislation. This move towards strengthening data regulations raises data governance concerns on how companies can collect, use, treat, manage and erase personal data according to the user centricity principle, that is, that users should be able to control data about themselves.

Most of these regulations follow the same principles, but this isn’t necessarily widely understood within a business, which creates ambiguity and fragmentation for employees seeking to operate or innovate with data. The result is that employees have become the biggest source of privacy risks. 59% of privacy incidents originate with an organization’s own employees and 45% of these employee-driven privacy failures come from intentional — although not malicious — behavior.

GDPR is complex on the legal side due to the many interpretations and fragmented nature of implementation at the country level, within specific industry sectors, and when applied to a bimodal IT model where implementation needs to pull data from both legacy and modern digital systems.

The responsibility for regulatory compliance organisationally falls to the Data Protection Officer (DPO). The DPO is responsible for implementation of ensuring data governance meets privacy and personal regulations. However, within organisations, there remains a huge collaboration gap between the DPO, and developers in IT departments. For digital businesses that are seeking to make greater use of data as a digital asset, privacy regulations like GDPR are not (well) implemented. Even world class tech companies mess up. Google and Amazon, for example, have been fined 50M€ and 746M€ respectively for not adhering to GDPR requirements.

Data Protection Officers don’t get IT, IT don’t get Legal

In 2015, according to a survey by the French national data protection authority, CNIL, most Data Protection Officers were former IT professionals. Today, however, most Data Protection Officers come from a legal background.

GDPR is a legal framework, but it still requires implementation in IT systems including in ERP, CRM, databases, data warehouse and datamarts, services, applications, APIs, and websites… Unless DPOs have a behind-the-scenes understanding of the IT complexities and associated requirements, compliance and personal data governance will be challenging as there is no link between the knowhow and the implementation.

The perfect combination of technical and legal skills make the ideal DPO profile as rare as a five-legged sheep. However, it is clear that DPOs that come from an IT background are actually more well adapted to the nature of the data protection implementation than those DPOs from a purely legal background. All the same, the problem remains, as former IT DPOs will still need regular internal or external legal advice. Even after taking any specific legal training course, DPOs will still be overwhelmed with detailed GDPR and data privacy knowledge. Experiencing impostor syndrome is not uncommon, limiting their capacity to assure top management and the entire organisation that their advice is reliable.

In any case, DPOs often do not have any real power in a large organization, making GDPR compliance impossible. According to Gartner:
– 40% of the time, the DPO reports to the CIO,
– 30% of the time to the CISO, and
– only 23% of the time to the C-Suite.

That means that in more than 75% of the cases, the DPO does not have a real enforcing power nor the budget to ensure proper GDPR implementation.

Many businesses are facing a privacy dilemma: if DPOs don’t understand what happens on the tech or on the legal side, they will be unable to collaborate effectively with IT teams and developers. Developers, meanwhile, are without the legal knowledge to understand the privacy implications when designing their data models, databases, services, APIs, applications, and user interfaces.

Developers have no real power to say “no” when a privacy practice is wrong

GDPR implementation is hard. When assessing a customer data use scenario, the entire workings of the organization must be considered.

For every use of personal data in the IT system, an organization will need to track how they process:
– The purpose for why the data is collected and processed
– The type of data and how it is categorized
– Their declared legal base (from the GDPR’s 6 officially defined legal bases)
– The list of all recipients of the data internally and also all the third parties involved
– The duration of how long the data will be kept.

Additionally, the company will need to understand how to interpret data regulations, apply them to their own systems, and accept a boolean “true” of “false” binary input and output.

At any time, the company will need to represent how personal data is mapped inside their system, as well as be able to declare that there are security measures in place for each item of personal data that is processed.

Data is also variable, so categorizations cannot be static settings that are applied only once. For example, when a user moves from being a prospect to becoming a customer, the GDPR context changes, and regulations redefine how data should be processed, how long data can be stored, and how data can be used internally. When an organization needs to track all their internal user events and match them with the right GDPR legal case, they also need to review how the regulation applies internationally. They may need to check if local countries have their own internal data privacy laws. As a result, companies must manage data based on the GDPR context of each country where customers reside. Even if the GDPR adoption allowed more harmonization within the legal frameworks of the EU member states, national sovereignty empowers countries to add further rules, which adds new layers of complexity and new opportunities to bring in their own interpretation on the way that these legal additions should be implemented.

Privacy developers are the only ones able to create digital economies based on principles of privacy and personal data governance

These new complexities all point to the need for a new role to be created in organizations: the “privacy developer”. A privacy developer acts alone or within a team to own the GDPR compliance within a company, and is responsible for communicating with the DPO office, IT managers, the CIO office, and the CISO office.

A privacy developer would have the capacity, skills and understanding to design the implementation of privacy and personal data governance regulations for their organization. Privacy implementation choices and design must be owned by developers, not by DPOs. As the builders of the systems that make use of data as a digital asset, developers need to help oversee the implementation of a tech stack that embeds privacy and compliance requirements.

At ALIAS, we seek to support the growth of the privacy developer sector through our Privacy Developer training. This delivers the DevRegOps certification, which offers developers concrete skills on:
– How to handle personal data according to GDPR
– How to implement GDPR regulations in IT systems
– How to manage GDPR compliance at API level, Database level, File level and 3rd- party SaaS level
– How to manage and track user event that may affect GDPR context
– How to react technically to user rights.

Interested participants can sign up for our next course starting date, with the first 100 signups receiving free access to become a certified privacy developer today.

With a hat tip to Andrew Russell and Lee Vinsel for the update to the seminal Hail the Maintainers article.