Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk //


10:30 AM
Connect Directly
E-Mail vvv

Why Your GDPR Implementation Plan Needs CISOs & 'Legal Engineers' to Work Together

Lawyers must step into the shoes of technical roles and craft legal guidance that can be easily put into use.

Don't be fooled by recent headlines. The General Data Protection Regulation (GDPR), probably the most well-known piece of privacy legislation across the globe, is now just over a year old. Its text, however, was finalized in April 2016 and European Union member states were then given two years to prepare for it to go into effect, which started on May 25, 2018.

After three years, we can finally begin to assess the benefits of the GDPR. But any honest assessment of the way GDPR is being implemented should lead to serious concerns for anyone interested in data protection.

The reason for the GDPR's shortfalls is quite clear: legal complexity. As the law is interpreted in practice, lawyers are making the regulation much more complex than it needs to be. Rather than simplifying its mandates, they're causing unnecessary confusion. I say this as a lawyer and an EU privacy expert.

Too much legal complexity means the compliance burden is shifting to those in technical roles, who then must navigate the privacy landscape mostly on their own. And this is exactly what's happening on the ground, with CISOs and CIOs bearing the brunt of GDPR implementation efforts.

CISOs and CIOs need legal help, and that means that lawyers' advice needs to be formulated in a way that is useful for decision-making. Lawyers must step into the shoes of technical roles and craft legal guidance that can be easily put into use. In other words, lawyers should become "legal engineers" too, helping to engineer legal requirements directly into software systems and processes. This evolution is key to the GDPR's success.

The GDPR triggers questions within organizations, and the legal answers given are not always helpful for decision-making: They tend to be more convoluted than needed or too evasive. We see recommendations such as "if you can't properly anonymize, consult compliance" all too often, which creates frustration. In addition, the GDPR is the pretext of internal battles between compliance, IT, and business departments, which are all reluctant to own data stewardship programs.

Getting the Lawyers Involved
When lawyers are directly involved, they often have a hard time producing a useful strategy and spend most of their time explaining what personal data is and what the duties of data controllers are, rather than focusing on internal processes and controls.

Lawyers aren't trained to translate complex legal norms into concrete recommendations for operationalizing compliance strategies or to answer concrete questions such as: How should I minimize the data? Should I anonymize rather than pseudonymize? How do I set the trade-off between privacy and utility?

As a result, lawyers tend to step back. The foregoing also explains why lawyers have difficulties assessing the potential of expert systems and embracing legal tech.

Perhaps more problematic is that lawyers thrive on complexity, and the more complex the framework, the more difficult it will be for lawyers to adapt. Yet the EU data protection jigsaw is complex — some argue too complex, and for good reason. Take, for example, the tension it creates with other EU pieces of legislation such as eIDAS on electronic identity or PSD2 on electronic payment. Which liability rule should apply when nonqualified trust service providers are processing personal data, eIDAS or GDPR? Is explicit consent under PSD2 the same thing as explicit consent under the GDPR? And complexity in one regulation begets complexity in interpreting the other. 

If legal engineers are not inserted into the process, CISOs or CIOs will have to decide on their own which workflow to adopt, how to integrate privacy requirements within systems, and how to conduct risk assessments. Yet, at each key stage, serious legal challenges arise, which means CISOs and CIOs should be working closely with lawyers. While privacy and security requirements are converging, they do not entirely overlap.

If technical roles and lawyers do not work hand in hand, we run the risk of making data protection by design, which is the core requirement of GDPR, an empty shell.

Bridging the Great Divide
Lawyers should, as often as possible, step into the shoes of technical roles to identify the range of alternatives available, requesting and digesting technical input when needed.

Becoming "legal engineers" will enable lawyers to combine legal knowledge, technological insight, and management skills to recommend positive actions to CISOs and chief data officers (CDOs). This means that lawyers must get technical, and technical positions must get comfortable inviting lawyers to have a seat at the table before things go wrong. CISOs and CIOs must ensure that lawyers are present at every stage of the IT development life cycle. Otherwise, legal mandates will fall all-too-heavily on technical shoulders.

What's at Stake? A Lot
As the GDPR's popularity increases, and other privacy legislation follow in its footsteps — from California to Brazil — the danger is that the legal focus stays upon the divergences, the inconsistencies, the complexities. Consider what happened with the old Data Protection Directive — powerful organizations capable of harnessing the best legal minds were able to read almost entirely what they wanted into the first generation of privacy laws. As a result, the pillars of surveillance capitalism were able to claim best privacy practice.

This means that it's on lawyers to make sure laws like GDPR are implemented correctly. And it's up to CIOs and CISOs to let them.

Related Content:



Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions and service providers in the Business Hall. Click for information on the conference and to register.


Sophie Stalla-Bourdillon is a leading expert on the EU GDPR, and Senior Privacy Counsel and Legal Engineer at Immuta, where she works on tackling the ethical challenges of AI. Sophie is responsible for examining current data protection and model risk frameworks, helping ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
More SolarWinds Attack Details Emerge
Kelly Jackson Higgins, Executive Editor at Dark Reading,  1/12/2021
Vulnerability Management Has a Data Problem
Tal Morgenstern, Co-Founder & Chief Product Officer, Vulcan Cyber,  1/14/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-01-19
IBM Planning Analytics 2.0 could allow an attacker to obtain sensitive information due to an overly permissive CORS policy. IBM X-Force ID: 190836.
PUBLISHED: 2021-01-19
IBM Planning Analytics 2.0 could allow a remote attacker to obtain sensitive information, caused by the lack of server hostname verification for SSL/TLS communication. By sending a specially-crafted request, an attacker could exploit this vulnerability to obtain sensitive information. IBM X-Force ID...
PUBLISHED: 2021-01-19
XML External Entity Injection vulnerability in Micro Focus Application Lifecycle Management (Previously known as Quality Center) product. The vulnerability affects versions 12.x, 12.60 Patch 5 and earlier, 15.0.1 Patch 2 and earlier and 15.5. The vulnerability could be exploited to allow an XML Exte...
PUBLISHED: 2021-01-19
The default setting of MISP 2.4.136 did not enable the requirements (aka require_password_confirmation) to provide the previous password when changing a password.
PUBLISHED: 2021-01-19
MISP 2.4.136 has Stored XSS in the galaxy cluster view via a cluster name to app/View/GalaxyClusters/view.ctp.