In the past couple of years, companies throughout Europe, and beyond, have been taking steps through their internal departments to ensure organisation-wide GDPR compliance is achieved.
Quite a few activities fall under the scope of the information services and information technology department since IT manages the applications and the infrastructure in which much of the private data resides. IT teams have, therefore, initiated many projects that are drawn from the organisation’s data privacy strategy in the wake of GDPR becoming effective.
Even one year on from GDPR coming into effect, few IT teams can confidently say they really are where they need to be at this point of time. Some IT teams though have carefully analysed the scope, their current state and the required projects from a GDPR standpoint and have implemented such projects in a streamlined, phased manner to provide the necessary GDPR assurance to the organisation’s legal team.
Review the IS application landscape
The starting point for the IT team in this journey is the IT application landscape, and in a typical large or medium-sized organisation this is comprised of several hundred applications and platforms. Empirically, around a third of such applications and platforms contain what is termed as personal and/or sensitive personal data. Controls and capabilities from a GDPR standpoint are to be focused on these applications and platforms.
The IT landscape snapshot itself, as taken from the enterprise architecture toolsets, such as the configuration management database (CMDB), may not be fully up to date. Changes due to projects implemented are not always fully reflected in the CMDB. These changes could include modifications in the applications that deal with personal data. Hence it is worthwhile to review this snapshot to come up with the scope.
E-discovery of personal data
Having identified the applications and platforms that deal with personal data, it is necessary to determine the nature of personal data in these applications to draw up a personal data register that will need to be maintained in an enduring manner.
Conducting this exercise of data discovery over several hundred applications accurately in a limited period is a daunting task. Fortunately, there exist e-discovery tools that can scan applications - containing structured and / or unstructured data - and report out the personal data elements.
These e-discovery tools, combining meta-data search with data discovery rules applied to sample data sets within the application, can provide a near complete personal data heat map of the applications.
There are a few options for e-discovery tools available, such as BigID, Stored IQ and INFA S@S. The choice of the e-discovery tool in an enterprise is dependent on the IS landscape at hand. Since the setting up of e-discovery tools with non-prod environments of all applications may not be feasible due to competing projects vying for the environments at any point in time, it is a good idea to attempt manual personal data discovery on applications with a smaller data footprint.
One needs to be aware that e-discovery can be a resource - compute and memory - hungry process and these resources need to be provisioned accordingly.
It is also important to identify personal data flow among connected applications. Drawing up such a data flow is a painstaking process, but it is well worth the effort. This data flow needs to be maintained as an artefact in the enterprise architecture repository.
The report of personal data across connected applications is utilised during data subject access requests (DSAR). There are tools that use the data flow map to generate an automated report of the personal data of a data subject drawn from multiple connected applications. Generating a DSAR in this fashion is faster, accurate and lends much more credence to the process.
GDPR capability register
The next step in the process is to analyse the GDPR capabilities needed in the applications that contain personal data. The capabilities needed flow directly from the rights of the data subject and thus the obligations on the data controller or processor as covered under the articles, recitals and the principles of the GDPR. The presence of these capabilities in each application needs to be used as a yardstick to measure the GDPR completeness of the application.
Also, any analysis done on the application capabilities needs to be duly evidenced. This shall be useful during an audit of GDPR compliance in the organisation. Tools such as RSA Archer can serve as a register of an application’s GDPR capabilities.
During the analysis of GDPR capabilities of applications, if any shortfalls are observed, then correcting or remediating features need to be implemented. In some cases, this may even require complete revamping of the application. However, the most common cases of such remediation typically tend to be managing consent in a better manner and enabling features to implement the ‘right to be forgotten’.
Data retention management
The right to be forgotten and the legal basis to hold data are talked about in detail in various discussions in the International Association of Privacy Professionals (IAPP) fora. Even when the legal basis ends and the personal data cannot be legally retained any longer, there have been instances where the applications do not have features to remove such data. This affects the ‘storage limitation’ requirement of GDPR.
Many long-running GDPR projects deal with implementing this data retention management. They are also some of the more complex ones requiring thorough testing and longer timelines. The business teams are often reluctant to let go of the data even when the legal basis is no longer valid. This ‘keep the data, just in case’ mindset must be done away with and all data retention requirements need to be fully documented, approved and complied with.
Usage of personal data
‘Purpose limitation’ means personal data of individuals cannot be used for any purpose other than the one explicitly stated. This also means IT project teams cannot use the personal data from production systems for development and test activities as-is. But the IT project teams need data that is production-like for accurate and reliable solution development.
Test data management tools that extract limited production data and anonymise personal data elements solve this problem. The rules for anonymisation implemented in different connected applications need to be aligned. This should enable testing of scenarios that involve the same anonymised personal data elements used across connected applications.
Privacy by design
IT systems compliance with GDPR is not an activity that can be completed once and then be forgotten. The GDPR capability register is a living document that must be continually updated with the GDPR capabilities of the applications in the IT landscape as and when any design changes are made, to implement new capabilities or modify existing ones.
The IT design assurance boards need to implement categorically defined gates and controls for application changes that deal with personal data. This is the idea behind the ‘privacy by design’ principle that no change ever gets implemented that doesn’t comply with the personal data protection principles.
Adherence to data privacy protection principles and compliance with GDPR is a continual activity. All the teams in an organisation, including the IT team, are in this for the long haul as far as GDPR is concerned because the stakes are so much higher.
