With a year to go it is safe to say that organisations vary widely in their readiness for the GDPR, with the clear majority being far from confident that they are going to be able to comply with the new Regulation. The clients that I speak to are often still struggling with the basics, let alone being able to thinking about a complete overhaul of their records and data management, access control and other privacy-related processes, as the GDPR actually requires. In a lot of cases there is still a sense of complacency, a belief that it will be the Googles and Amazons of this world that will be hit first with any fines.

When thinking about this article I was tempted to focus on some of the more common and apparent issues that I hear being discussed around independence of data protection officers (DPOs), particularly following the November decision of the Bavarian Data Protection Authority; or on how to contemplate the minefield created by ‘the right to be forgotten’, or even on how to find competent people in a resource-constrained environment. These are all important issues, but there are some simple steps that will have a significant impact on your GDPR programme, and which, if you have not already done so, you must take now:

  1. Know what the personally identifiable information (PII) you hold is, where it is located, and where it goes;
  2. Plan for what you will do in the event of a breach;
  3. Take the opportunity to rationalise and streamline data; and
  4. Understand 3rd parties and your mutual dependence on privacy of data.

Know where your PII is, where it is and where it goes

Companies are generally good at cataloguing data when it is stored in core systems, and mature organisations have even gone a long way to securing that data. The challenge is, and this is borne out of experience in helping too many companies during and after data breaches, data is almost always existent outside of those core systems as well. Almost every breach I have dealt with has targeted the data that has been outside of those systems – so called ‘Shadow IT’.  In a large breach I investigated I found an almost complete copy of the client’s ‘Crown Jewels’, which included PII being stored on an unsecured development web-facing server!

The rise of Shadow IT raises a significant problem for security, and in the case of PII is a compliance nightmare. This means that, as a first step, organisations need to move quickly to identify all the locations where the data is being stored and understand the flows of PII inside and outside of the organisation. This is almost impossible to do without the use of an automated tool that captures data in motion or at rest. This will allow organisations to prioritise an approach comprising of both technical and training measures to reduce exposure.

I have focused this article on four things an organisation should be doing right now, as there is not much time left before the GDPR comes into effect. However, such monitoring tools as described in this article can also be used on an ongoing basis to ensure the continuous monitoring of data transfers, allow for a regular assessment of the effectiveness of governance systems and structures, and maintain the compliance programme put in place.

Plan for what you will do in the event of a breach – and practice it

It is a fact – breaches happen! Regardless of whether those breaches are due to malicious activity or result from a human error, organisations need to be prepared in order to be able to respond to a breach, and respond very quickly. The adage of the 7Ps is very relevant (Proper Planning and Preparation Prevent Poor Performance), and thus organisations need to already be thinking about how they are going to respond. The Regulation not only requires organisations to report very quickly following a data breach, they also need to clearly understand the nature and size of the breach, who was affected, whether individuals need to be notified and whether adequate controls to prevent the breach had been in place.

There are hardly any organisations that I have ever worked with that were able to do this to a satisfactory degree. Recent data breaches have demonstrated that organisations are unable to quickly identify what they have lost. In a GDPR world that means there is a risk of over- or under-reporting the scale of a breach, not being able to notify all relevant parties, and thereby opening the door for regulatory sanctions.

Dealing with a breach is a combination of having the right stakeholders involved (Board, Internal and External Counsel, Auditors, Employees, Shareholders, Customers, Vendors etc.), not just IT and Security departments/experts. A good response programme provides a consistent, scalable way to deal with breaches and needs to be rehearsed regularly in order to become ‘muscle memory’.

Having the right tools in place also helps. Organisations should seek to have a ‘black box’ that provides enough forensic quality data recording capability that, as in airline crash investigations, will allow you to reconstruct the breach and quickly understand what data has gone missing, and how.

Equally importantly is to have a well-rehearsed communications strategy in place – a single voice for the organisation that maintains the confidence of stakeholders and minimises the reputational damage that result from a breach.

Take this opportunity to rationalise your use of PII

I remember listening to a presentation about 10 years ago on SAP implementation, the key tenet of which was that if you don’t clean your master data before implementing SAP then you are going to have problems. Moreover, this was an important opportunity for organisations to rationalise and clean up their master data files. I draw parallels between this wisdom and how we address the challenge of PII and the GDPR.

It is very clear that most organisations are holding more PII than they need to, in places they don’t need to, and for reasons they don’t understand. The GDPR affords organisations with the opportunity to take a fresh look at how they use data, to identify new ways for rationalising data, as well as to reduce the relevant associated risks.

The first steps described above provide insights into what data is being held and where it is located. The logical next step would be to critically question, and employ some creative thinking to, whether this data is really needed and what alternatives may exist. Could anonymising data suffice? Are all the data elements needed, or could we reduce risk by only keeping limited data elements? Do we need this data at all?

This approach needs to be robust and decisions made must be communicated effectively, not just to deal with the status quo, but also to reduce the ongoing risks that people will start to revert back to bad habits such as keeping unnecessary data after the initial GDPR compliance surge is completed. That means creating sustainable solutions that will safeguard that organisations will continue to receive the benefit of the data while reducing the risks to this data at the same time.

In the same way as the PCI-DSS set of standards has led to many retailers eliminating any card data being held on their networks (at least in Europe, less so in the US), I believe we will see a rise in outsourcing the capture and use of personal data. PII brokers may seem far-fetched to some, but if you look at the credit scoring industry as an example, we can see that organisations have already outsourced storing and managing sensitive financial data. We are likely to see the same happen for PII as part of a risk transferral strategy.

Understand 3rd parties and your mutual dependence on privacy of data.

The topic of PII brokering leads nicely into a discussion about how we need to better understand our third-party relationships and the potential GDPR exposures arising from them. A lesson from more ‘exotic’ jurisdictions is that once penalties increase and start to be enforced, lawsuits will follow. Organisations will start to look to third parties that may have had a duty of care of their data and have handled PII inappropriately.

Step 1 outlined above is a good starting point for understanding PII data flows and mapping the third-parties that PII is sent to, received from or processed/stored by. Steps 2 and 3 are also critical in that both are creating and rehearsing incident responses, clearly defining breach notification thresholds, devising communication strategies as well as critically assessing whether each of the third-parties need PII or whether there are alternatives.

I have included this as a separate point as, from my experiences in dealing with breaches, the relationships and dependencies with third parties is very poorly understood. An organisation I worked with recently actually believed that they had no personal data and had outsourced it all to a third party. The reality, however, was that due to a specific and one-off business requirement, there was a full copy of certain PII stored within the company.

Following the four steps above will not make you compliant, but they are fundamental steps that each organisation needs to get right on their journey to compliance. If you don’t have taken these early on in your compliance journey, the chances are that you will have a harder time with the GDPR than would need to be the case. They are also steps that ought to be build into an ongoing compliance programme to address the GDPR and information and data security for the longer term.

Please follow and like us: