What Should a Company's 2017 EU General Data Protection Regulation Budget Look Like?

Bloomberg Law: Privacy & Data Security brings you single-source access to the expertise of Bloomberg Law’s privacy and data security editorial team, contributing practitioners,...

EU Privacy Compliance

The author provides advice on how companies should set up a budget in preparation for compliance obligations under the European Union's new privacy regime—the General Data Protection Regulation—which will take effect in May 2018.

Chiara  Rustici

By Chiara Rustici

Chiara Rustici advises businesses as an independent European Union General Data Protection Regulation analyst and implementation consultant. Rustici was formerly an Italian National Research Centre research fellow and a business director with strategy and profit and loss responsibility for the City of London. She is the author of the forthcoming book GDPR: The functional specifications of EU-grade privacy, published by O'Reilly.

Postponing a budget exercise until after the Article 29 Working Party (WP29)—the European Union's 28 privacy commissioners— released their official EU General Data Protection Regulation guidelines in English risked leaving businesses short of time. The EU privacy commissioners and the European Data Protection Supervisor have, so far, published sufficient indications and guidelines for businesses to know what is expected of them in preparing for the GDPR, albeit not all in the same place or in the same language. It is highly unlikely that the WP29 guidelines, due out in stages between the end of December and the first few months in the new year, will radically depart from what has been issued by other EU institutions or the national privacy commissioners themselves so far. There are no excuses for not having a GDPR budget in place before the end of 2016.

Another common misperception is that businesses should wait until a data protection officer (DPO) has been hired and leave the GDPR budget up to them.

In fact, a lot needs to be in place—and can be put in place—in an organisation before a DPO is hired. The role of the DPO is crucial in navigating data protection issues, but there is a very early role for the enterprise data architect in making an organisation's information technology (IT) infrastructure GDPR-ready. Think of a DPO as a ship's captain and of a GDPR architect as the naval engineer: to set sail to the seas you rely on a good captain, who can chart a course and avoid thirty-foot waves; but to build or make a ship sea-worthy, and ensure that it can withstand even thirty-foot waves, you first rely on a good naval engineer. They perform different functions.

We know that an IT director has already been fined by one the German privacy commissioners for taking on the data protection officer role: the arrangement was deemed a conflict of interest under the current directive. Seeing this as a precedent for the GDPR's required independence of the DPO role from an IT director role, understandably, chief information officers (CIOs) are reluctant to take the lead and display apprehension in owning the GDPR implementation budget if a DPO is not yet in place.

In this case, too, the best business advice is not to procrastinate. That the DPO roles should be kept separate and independent because a conflict of interest might arise between the DPO function and all the other business functions in the day-to-day operations of the business once the GDPR is enforceable, is no reason for IT and other C-suite leaders to skirt their current responsibilities in building a GDPR-ready organisation. That does not appear to me to be the message of this fine. Additionally, there are ten key data architecture reasons why CIOs and other IT leaders should be involved in GDPR preparations right from the start. See Chiara Rustici, GDPR, The functional specifications of EU-grade privacy, Chapter 1, O'Reilly, early release edition.

A 2017 GDPR Budget Should Be a Federated Budget Exercise

As the regulation impacts, horizontally, all business functions, the total must include both front-end and back-end functions. In other words, the budget is there to ensure that any interaction of EU-based individuals with a brand's real and digital estate follows the EU data protection principles: that will mean product design, user experience, distribution and after sales support, HR, marketing, legal, risk and compliance, storage and security should all own a share of the corporate GDPR budget.

It is very dangerous to think in terms of key, “personal data”- centric business functions and those that can worry about the impact of the GDPR later or not at all.

There is also a very dangerous temptation for businesses to allocate their entire GDPR implementation budget to external advisors. Anecdotal evidence suggests consulting firms are selling compliance services by relying on an unquantifiable army of GDPR implementation contractors they expect to hire once the market “revs up.” The trouble is, this army does not yet exist and the few GDPR architects I am aware of—professionals capable of translating the regulation's functional requirements into technical requirements—are four times oversubscribed. For businesses that want to minimise risks, allocating budget to train their own employees to grasp GDPR requirements and empower them to actively find their own solutions is the safest bet.

How much should businesses allocate to GDPR implementation?

Businesses should take no risks on this count, either. A good starting point is to presume one is far from being GDPR-ready and will be fined. I advise businesses to ring fence 4 percent of the 2016 global turnover and earmark it as budget for the 2017 compliance exercise: one way to look at it is that if it doesn't get used in 2017 for GDPR preparations, it'll have to be used in 2018 to settle the fine. A business may achieve compliance with less, of course, and carry any excess over to the following years, but it would be hard to argue to a regulator that the business was serious about data protection if it can't even point to a budget that is at least commensurate with the fine. The fact that technology solutions are not yet available or are far from being perfect, and one cannot precisely quantify the cost for implementing each GDPR obligation yet, shouldn't be an excuse not to have a figure earmarked for each issue. Below I share my own ten bullet point memo-to-self: if a business has nothing else to go by, the total budget allocated may be divided in equal parts. As the year progresses, and one's GDPR compliance journey becomes more specific, amounts can be refined and re-allocated from one heading to another.

How much should businesses aim to accomplish in 2017?

A tall order, but 2017 is the year to become 100 percent compliant. The first five months of 2018 should be set aside as contingency remediation time for minor glitches, not for major changes.

There are three phases to taking an enterprise to GDPR compliance and they need not be in sequence but can take place in parallel: (i) a fact-finding phase, where personal data flows created by the different business processes are mapped; (ii) a boardroom phase, where the corporate privacy posture and the business model around personal data is revised and agreed; and (iii) an internal crowdsourcing phase, where all the business functions are empowered to find, test or co-create the technology solution to meet their GDPR obligations. I refer to crowdsourcing for good reason: nobody gets personal data better than the people who use personal data. Top-down GDPR compliance by committee alone will fail: while central ownership of the compliance journey is crucial, evidence suggest bottom-up involvement of front-line employees in finding solutions yields the best results.

What Headings Should a 2017 GDPR Budget Itemise?

Of course, no single template will suit all businesses. Larger corporations, especially those in regulated industries, tend to centralise shared functions and may have a “compliance management system” already in place to deal with large scale regulatory changes, involving a multi-stakeholder compliance committee, codes of practice to cascade Do's and Don'ts down the organisation and whistle-blowing procedures for reporting non-compliance. Smaller businesses and start-ups may function as a network of de-centralised self-contained businesses with their own marketing team, their own databases, and may never have had to deal with anything quite so demanding before. Ultimately, it will be the structure of each business to dictate the specifics. However, these are the headings I rely upon for my own use:

  • Budget for data inventory and mapping. But, note that automated solutions promising file autoclassification or algorithmic recognition of personal data require a lot of fine-tuning: until machine learning “has cracked” the broad GDPR definition of personal data, Art. 30 still requires complex human judgment.
  • Budget for privacy and state-of-the-art safety by design and by default. But, note that neither privacy by design or state-of-the-art safety are achieved through single software solutions but involve two distinct processes - one for future data collection and one for “sanitising” legacy data sets that a business wants to hold on to or for erasing datasets it no longer wishes or has reason to rely upon.
  • Budget for solutions to enable the exercise of Art. 15-22 data subject rights. This part of the budget should be owned by IT, especially as Art. 17 right to erasure, Art. 20 right to portability, Art. 21(1) right to object to processing and Art. 18 right to restriction of processing are not achievable through ad hoc intervention alone but involve core and very demanding IT architecture changes. Note that reliance on legitimate business interest as a lawful basis for processing is no easier on the IT architecture than reliance on consent.
  • Budget to train employees to recognise GDPR personal data flows. A business' first and best line of defence, they will contribute to filling the inevitable gaps in a data map.
  • Budget for incentives for hunting down “rogue or non-obvious” personal data records . If, on budget day, anyone laughs this off, refer them to the extensive Bug Bounty literature in IT security and Microsoft Corp.'s well known six-figure vulnerability rewards for ethical hackers.
  • Budget to train employees. Existing employees should be trained to understand the functional specifications of the GDPR in their own role and business function.
  • Budget to train employees to negotiate with sector-specific vendors and co-design GDPR solutions for their role and business function . If they have not helped design these solutions, they will not use them. Central ownership of the compliance programme is key, but delegating/decentralising the research of potential solutions multiplies chances of success.
  • Budget for stress-testing GDPR resilience of the solutions proposed. Seek inspiration from the “Hack the Pentagon” initiative and the EU's own Bug Bounty funding. Keep the two budgets separate: one to support identification of personal data potential leaks, and a different one to stress-test the solutions found to prevent personal data leaks, including access control layers, encryption and de-identification of the data sets themselves.
  • Budget to co-ordinate and integrate the solutions crowdsourced from the business units/functions. Set up single accountability/demonstrability framework. The different solutions need to integrate with each other and central project management is key.
  • Budget to hire both a GDPR architect and a GDPR DPO. There will be collaboration first and then a handover between the first and the second, but a single professional profile with both sets of skills does not yet exist or is extremely rare.

Professional membership associations should help produce standards and vet Regulation Technology vendors but, at this writing, no EU certifications or trust marks have yet been approved: ultimate responsibility for vetting vendors offering solutions, and verifying that these reliably address GDPR obligations, rests entirely with the buyer.

Copyright © 2017 The Bureau of National Affairs, Inc. All Rights Reserved.

Request Bloomberg Law Privacy and Data Security