I’d like my data back please: implications of the EU General Data Protection Regulation

In a financial services industry which is increasingly technology and data-driven, banks need to consider the impact of the EU General Data Protection Regulation (GDPR) on the way they process personal data, and how they can demonstrate customer consent to do so. With fines for non-compliance of €20m or 4% of annual global turnover (whichever is larger) it is imperative institutions don’t fall short of GDPR requirements.

When the GDPR comes into force on 25^th May 2018, it will build upon the EU Data Protection Directive (1995) and the UK Data Protection Act (1998), both of which set out standards for how personal or sensitive data must be protected. Personal data is defined under GDPR as any data which can directly or indirectly identify an individual; sensitive data includes (but is not limited to) gender, race, religious beliefs and political opinions.

Among its principles, the GDPR includes much stricter requirements to demonstrate that individuals have given their consent for this data to be collected and processed. It also gives customers the right to request copies of data held about them and the ‘right to be forgotten’, i.e. for their data to be erased should they request it. Whilst many banks have already begun to embrace portability – the ability of individuals to obtain a copy of their personal data in a format which is re-usable across other platforms and services – through the “midata” standard, the erasure requirements will pose a new challenge.

I’ve seen that procedural impacts are already being considered in detail by many organisations, to ensure the ability to adequately respond to a customer request. Come May 2018, an institution cannot fold under the weight of requests for data to either be made available or to be removed from databases; the people, tools and processes must be in place to support this, as well as an understanding of the data itself.

There are three key questions that need to be answered in order to prepare for customer data requests that require action, and they each pose their own challenges.

1. Where is the data?

Given the global reach of many financial institutions and the associated global technology stacks, tracing data lineage can be a significant challenge. Data may proliferate from an original point of capture into many different places and in different forms. Identifying a “golden source” of data does not necessarily mean identifying the only source, and erasing once does not mean gone forever.

2. Where did the data come from?

Tracing where data originated from is key to understanding what consent was given at the time of capture. Even if details of consent were adequately captured at source, transfer between different systems may mean that processed data is detached from the original consent detail. This will make it difficult to meet new requirements to clearly demonstrate what the customer agreed to.

3. Who has access to the data?

Given the proliferation of data across systems and departments of an organisation, understanding who has access to personal data and ensuring appropriate controls becomes an increasing challenge for banks. This is an important question to answer, as a key tenet of data protection is to ensure personal data is only available to staff that need access in order to provide services to those customers.

So how are these challenges to be addressed? Ultimately, answering these questions requires an understanding of the flows and sources of data throughout an organisation. In my opinion this can only be adequately achieved through thorough data lineage analysis: the careful mapping of data models, data flows and data definitions, to ensure that the output of processed personal data is understood as a product of its sources.

Determining data lineage first requires an understanding of the organisation and processes which underpin the data, and a consistent set of definitions of the business objects it describes. Secondly, the data assets which need tracing through the business processes must be identified. Then, working logically upstream, each actor and touch-point must be analysed as data passes through the end to end process flow to identify all transformations, mappings and access points. The outputs of this work can then be used to confidently provide a view of data creation, enrichment, transfer and interrogation from either a system or process-based perspective. Documented results will also inform future data model or system changes when planning for ‘data security by design’, another key principle of the regulation.

Through rigorous analysis of the lineage of data as it permeates through the organisation, when GDPR goes live banks can put themselves in a position to adequately respond to customer data requests, and avoid the imposition of significant penalties by the regulator. If a customer asks, “can I have my data back please?” on 25^th May 2018, the answer will be much easier to give if analysis of where that data is, where it came from and who has access to it has been completed ahead of time.

Given the short road to May 2018, the time to act is now.