Differences over GDPR terminology perpetuate internal conflicts

Boards trust departments to execute, but turning data-privacy policy into action can be a “nightmare”

Businesses around the world may now be operating under the tough privacy protections of the European Union’s general data protection regulation (GDPR), but ongoing confusion about its requirements and terminology has kept security experts working overtime to ensure compliance.

Many businesses, for example, have struggled to clarify the requirement in GDPR Article 25 that companies implement “appropriate technical and organisational measures” that “[take] into account the state of the art”.

A recent Trend Micro survey of 1000 IT decision-makers revealed widespread confusion about just what the term ‘state of the art’ implies, with 30 percent defining it as buying security from an established market leader; 17 percent as using products that pass independent third-party tests; 16 percent choosing products based on analyst reports; and 14 percent believing it refers to startups providing innovative technology.

Yet GDPR’s example of appropriate technical measures – pseudonymisation – has itself been a bone of contention in countries including Australia, where the government was forced to pull a massive anonymised Medicare Benefits Schedule (MBS) data dump after university researchers showed the data could be deanonymized.

What, then, of GDPR’s expectation that customers implement “state of the art” security technology?

“Customers have no idea what to do with this wording,” Trend Micro executive vice president of network defence Steve Quane recently told CSO Australia. The Japan-based global company’s own fortnightly ‘GDPR fire drills’, he said, had revealed the inherent complexities of security policies that are often drafted by legal departments and offer very little practical guidance about security response.

“It was a nightmare to try and figure out what information we were going to disclose if a breach happens,” he explained, noting that internal work and customer workshops had highlighted a lack of clarity about to whom breaches would be disclosed, how they would be disclosed, who would approve reports internally, and so on.

That experience is shared by a concerning number of companies, with recent figures suggesting that European companies could expect an onslaught of GDPR data requests within the next six months – but that employees still had very little understanding of how to comply with them.

Good policy can be instrumental in earning customer trust – which, research has shown, can drive broader information sharing and use – but many companies are still dealing with internal divisions as they struggle to build a coherent internal story to tell around GDPR and related privacy protections.

A lack of agreement on the policy’s expectations and obligations was often compounded by differing perspectives between departments, with areas like Marketing and HR taking different views to Legal and others.

Internecine conflict muddies the waters for board members, who may well depend on a consensus among internal divisions before pursuing major new policy directions.

“Even though the board is liable [under GDPR], in many cases the board has just said ‘craft whatever you want and I will support it’,” Quane said. “Most customers come into the workshops with a written policy on disclosure that was usually crafter by Legal. But when customers to do the drill, they realise it’s way more difficult to craft the actual statements than their policy would indicate.”

Policy – both its creation and execution – can be even more of an issue in compliance than technological solutions such as microservices containers, which exist and “will evolve as the toolsets and APIs evolve”, he said. “The biggest concern we have is that often times, security isn’t in the discussion. CSOs need to convince the team to put security up front so they can move faster later.”