GDPR is a sprawling regulation. Firstly, this article classifies the requirements into the various governance, legal and process changes needed. Very few companies in the UK of any size will be fully GDPR compliant by May 2018 but they can all be on a meaningful plan to get there. The article then describes three key areas of development which can give major GDPR compliance benefit as well as strategic bank benefit. HBW believes these three areas should be a core part of any bank’s GDPR meaningful plan for compliance.
GDPR Requirements
HBW classifies the GDPR into five “buckets” of required change;
- Legal – this covers privacy notices to customers and contracts with suppliers, sub-contractors and intermediaries. This is not significant in IT architecture terms.
- Governance – There is a Data Protection Officer in the organisation and Data Privacy by Design in change practices. Again this is not significant in IT architecture terms.
- Process Inventory – There is a need to have a clear understanding and documented inventory of all processes involving personal data and that they are executed with the right permissions. This should be significant in IT architecture terms.
- Systems Inventory – there is a need to ensure that personal information is handled correctly (suitably protected, anonymised by default, records deleted when their retention is no longer justified). There is no explicit systems inventory requirement but fulfilling these requirements without a system inventory is well nigh impossible and so a good systems inventory is critical both architecturally and for GDPR compliance.
- Consent as an active Data item – There is a need for processes to be carried out, only in conjunction with the customer’s express consent. This means systems need to check there is an “active” consent in place before execution or “re-ask” the customer for consent. Traditionally, systems generally assume consent has been given (and is stored on a piece of paper somewhere).
The thesis of this paper is that, for even relatively small banks and financial institutions, the volume of change driven by these requirements will go far beyond May 2018, but that an architectural approach will create value for the company.
Process Inventory
The GDPR is explicit about being the need for a company to demonstrate it understands that it knows all the processes that handle personal information and that they do so in a compliant manner. For HBW this implies the need for a process inventory. Some companies might be tempted to create a list specifically for those processes that handle personal information. We consider this an inappropriate approach.
- A process catalogue that covers all the processes of the organisation will give the DPO, board and regulator much greater confidence that all the personal information handling processes have been captured. The non personal information process will not need the same level of detailed description but the completeness is an important GDPR factor.
- The process catalogue is very likely to be needed for other regulatory requirements; particularly in large banks – For example, Resolution Planning Regulations require banks to identify which services that support critical functions use which operational assets. The best way to identify this relationship is via process descriptions which typically describe the operational assets used (e.g. which people, which systems, which location). Business Continuity Planning also requires a bank to understand the impact of events, typically an impact on a process such as a building fire or a systems failure, on processes.
- Most business improvements; whether it be automation; whether it be outsourcing, or whether it be self service via digital channels; all require process descriptions of current and future states. Having a common, shared version of processes and their descriptions will help.
Hence a strategic approach to process inventory management will not only improve the credibility of the Bank’s GDPR but also create extra value.
System Inventory
GDPR does not explicitly require a bank to have a systems inventory but does require all systems that handle personal information to secure that information (e.g. with encryption); anonymise it wherever possible; delete it when it is no longer justified or if the data owner requests (and there is no legitimate interest) and amend it if the data is incorrect. To be able to carry this out without a comprehensive and up to date systems inventory is implausible.
A large bank will typically have several thousand systems, many of which will contain personal information.
As with the process inventory a good systems inventory can generate extra value;
- Directly support other regulatory projects such as Resolution Planning, Business Continuity Planning and Brexit Planning.
- Help with managing costs by managing the IT assets more actively (e.g. software supplier management; outsourcing contract management; infrastructure rationalisation are all driven off scope boundaries expressed as lists of systems).
Hence, as with the process inventory, a strategic approach to the systems inventory can both help comply with GDPR, but also generate value to the bank.
Consent
Successful management of consent, permissions, data rights is the future in the digital world. The current methods that banks use to manage these concepts are a legacy of the last century;
- Permissions/consents were obtained and recorded on paper forms (in banking jargon often called mandates).
- The computer systems assumed they had permission to do whatever they were doing.
As can be seen in the recent furore over Facebook and Cambridge Analytica as well as various data breaches (e.g. Experian) the public are becoming much more aware of the importance of the data banks hold on them. Banks take data protection very seriously, better than most organisations. But once the data is safely “inside their firewalls” they are not very transparent to their customers on what is it used for.
The trend in the future will be that the data/service trade off will become more explicit and more granular. By which, we at HBW mean that we expect individuals to reveal a lot about themselves at a point in time for a particular intention (e.g. a mortgage application/ health insurance policy quote) but that the permission is limited to that particular transaction and is not a general right for the bank to use that data.
Thus consent will become a fundamental data item that will be used by systems all over the bank in a much more active way. By creating a consent database with API’s that can be accessed by all the various processes (marketing, HR, KYC, Credit, quotations, account opening etc), not only will a bank be complying with GDPR, it will also be building the bank of the future.
Conclusion
GDPR is an important regulatory change which requires a lot of effort to implement. By taking strategic approach to Process Inventory, Systems Inventory and particularly a Consent Database, a bank can obtain additional benefits from the GDPR spend.
