In the first part of this series we were just getting started helping Hafslund Nett with implementing GDPR. In this second part, we reflect on the first few meetings and report on the technical progress in setting up and using the Sesam GDPR platform

Our Goals

The primary objective in the first week or so was twofold. Firstly, we wanted to try and get some core data about customers from the business system into the Sesam GDPR platform and data access portal. This would show how end-to-end delivery of core data would work and provide the basis for a process that could be repeated for data from other systems. The other key thing was to start filling in an excel template that describes the different data types, how they are connected to the data subject and also, what purpose exists for why Hafslund Nett have that data. This data is used by the Sesam GDPR platform to automate the process of handling data subject requests.

The devil is in the data detail

What was great was that Hafslund Nett have made a great start with their analysis. It documents core PII data and which systems it currently resides it. The implementation project is also staffed by some great people – Kim Foshaug is a man that knows almost everything about the actual data residing in most of the systems. I’m sure lots of organisations have information and data flow architects like Kim and getting them involved in the GDPR implementation process is critical. A couple of things we noticed as we discussed different data that the analysis had identified was that there is a bit of a gap between the data identified during the analysis phase and the data actually in the databases of the systems in question. As we discuss data that is in the systems there are then inevitably questions about if this data that should be included.

Another thing that created a bunch of questions was around the purposes for why the data is kept. This wasn’t explicitly conveyed as part of the initial analysis and now there are questions to that process to clarify the business purposes around the different data types. Knowing these purposes is critical to further automate the process. For example, if a purpose is backed by consent then the data subject can retract that consent, if the user can request rectification that also needs to be captured.

So, the outcome from the initial data sessions is that we aligned quite a lot of the core data from the analysis to the main customer and billing system in Hafslund Nett. This was documented in the excel spreadsheet and that drives the technical implementation. Kim and the implementation project lead, Are , also defined the core business purposes that related to these different data types. This allowed us to test these out in the GDPR platform. With some of the core system data identified work will now turn to a) refining the consents, and b) defining which data from other systems should also be included.

The Technical Part

The technical part of the project concerns configuring the Sesam GDPR platform and automating the collection of the data about the data subject from the source systems.

The Sesam GDPR platform is just a refinement of the Sesam data integration platform and Sesam DataBrowser. We deployed this stack as part of the installation that already exists at Hafslund Nett. So now we have somewhere to collect the data and a portal where data subjects can log in, request their data, and request changes etc.

Data Subject Data From Core Systems

With the platform in place we updated the configuration excel spreadsheet living in office365 to reflect the data we wanted to expose as data subject data. However, that data wasn’t in the platform yet, so we had to go get it. Hafslund Nett already has great control over their data. They are using Sesam as a central Datahub for controlling the flow of data between systems. It provides a self-service for datasets for new projects to make use of. So rather than having to go to the source system (in this case the customer and billing system) a new project can consume the data from the Datahub. So, this is what we did, we set up feeds from the new GDPR platform to collect data about customers, contracts, invoices and work orders. In addition, we found that some data wasn’t yet in the Sesam Datahub. So we created some new data extractors to collect that data from the source database. In this case it was customer data in the IFS system. That data is now flowing and because Sesam can merge data about the same ‘thing’ we can now just connect the IFS customer with the Customer and Billing customer to create a unified data record that can be presented to the data subject.

Logging in and Seeing Data

Ironically, the data flow stuff all went very smoothly (this is usually the hardest part – but Sesam made it simple). The front end GDPR application has been designed with security in mind. All data is encrypted on the server for a given data subject with a private key that is generated and stored on the client machine. This means that each and every data subjects data is uniquely encrypted. The data is only unencrypted when rendered to the data subject in the web page or as part of a download. Access to the portal is also governed by one time access codes sent to verifiable email or phone numbers. Getting all this working has been a new experience and has taken a few iterations to start smoothing out the kinks.

Status and Next Steps

The main goal was to show that in a week or so we could have the Sesam GDPR platform setup, core data into that platform, and access for data subjects. After some issues with one time passwords and SMS we have met that objective. The next steps are to refine purposes, add more data and begin to think about automating other aspects, such as sending rectification requests back into the customer and billing system.