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
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
IT 2020: A Look Ahead
Are you ready for the critical changes that will occur in 2020? We've compiled editor insights from the best of our network (Dark Reading, Data Center Knowledge, InformationWeek, ITPro Today and Network Computing) to deliver to you a look at the trends, technologies, and threats that are emerging in the coming year. Download it today!
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: 2020-01-27
CRLF injection vulnerability in Zend\Mail (Zend_Mail) in Zend Framework before 1.12.12, 2.x before 2.3.8, and 2.4.x before 2.4.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via CRLF sequences in the header of an email.
PUBLISHED: 2020-01-27
A Local Privilege Escalation issue was discovered in Avast Secure Browser 76.0.1659.101. The vulnerability is due to an insecure ACL set by the AvastBrowserUpdate.exe (which is running as NT AUTHORITY\SYSTEM) when AvastSecureBrowser.exe checks for new updates. When the update check is triggered, the...
PUBLISHED: 2020-01-27
PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to obtain sensitive column values by triggering constraint violation and then reading the error message.
PUBLISHED: 2020-01-27
The Scribunto extension for MediaWiki allows remote attackers to obtain the rollback token and possibly other sensitive information via a crafted module, related to unstripping special page HTML.
PUBLISHED: 2020-01-27
The to_char function in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via a (1) large number of digits when processing a numeric ...