GDPR Logo
>

Implementing GDPR at Hafslund Nett - Part 1

Graham Moore 
30. jan. 2018

Follow our adventure as we help implement a data access portal and automated request handling system using the Sesam GDPR Platform at Hafslund Nett.

GDPR Implementation at Hafslund Nett - Part 1

Sesam is working with Hafslund Nett to implement their GDPR requirements. We would like to share our experiences during this process. Stay tuned for insight as the work progresses. 

GDPR is coming…

With Christmas vacation over its time for many companies to start getting serious about GDPR. It's only 20 or so weeks until the new EU regulations on the data rights of citizens comes into effect. Hafslund have realised that there are two key parts to delivering on the rights demanded by GDPR, firstly to have good documentation and knowledge of what data is where, and secondly to actually be able to respond to requests for data from their customers.

Requests from data subjects

The practicalities of actually dealing with requests from data subjects has been ignored by many companies. Often, they are planning to do this process manually, while some simply hope no one will ask for their data! Many organisations think that if they know where the data is the rest will take care of itself. 

GDPR as a means to gain customers’ trust

Hafslund understand that being able to deliver the rights of the data subject is not just a requirement under GDPR but a means to gain even greater trust with their customers, and this is why they are starting on their implementation now. At Sesam we have had the pleasure of working with Hafslund Nett for many years, they have great vision in the application of technology to improve their business and this is now being extended to how they will deliver GDPR. Last week we began helping Hafslund get started on the implementation phase of GDPR.

Collection of the data about the data subject

To implement GDPR requires a couple of key things; a portal where users can manage their consents, see and download their data etc, and an engine that can automate the collection of the data about the data subject. We will install and configure the Sesam GDPR Platform as the basis for meeting both of these key criteria.  

Purpose, datatypes and systems

With the GDPR platform in place the first thing we are going to be looking to do is fill in a simple Excel document. This excel document provides the configuration for the platform to automate the delivery of data via the data access portal.

The Excel document is designed to capture what data types exist in which systems, and which legal basis (and related process) the company has for keeping the data. For all the complexities of modelling and analysis we see that this simple trio provides the core information needed to implement a solution.

GDPR core datamodel
Simple core data model for systems, types and purposes.

To populate this data model an organisation is required to know what data is available in each system, and they must document the purpose and legal basis for having that data. This provides the basis for collecting all data about a subject when they ask for it, and it also provides the basis to allow data subjects to retract consent. If they retract consent then the model allows us to know which data, in which system must be deleted or anonymised. 

Breadth first rather than depth

In the kick-off meeting we saw that Hafslund have done a lot of work, like many organisations, documenting this kind of information. Our strategy around implementation is breadth first rather than depth first. While the documentation process tries to consider all systems and processes, in the start of the implementation we are going to focus on end-to-end for just one or two core systems. What we mean by this is that we will implement the portal where data subjects can request data, and then we will automate the collection of data and modelling of consent management for one or two systems.

 

LEAN approach: Learning by doing

The reason for this approach is that if we learn things about what should be modelled, or how things should be automated it is better to learn that as soon as possible so that we avoid making those mistakes for the remaining systems. It is much easier to apply an end-to-end template that works than do each step for 50 systems not knowing if a mistake has been made and the work needs to be redone. The additional value in defining a working practice for a single system is that after May 2018 new systems will be added and when this occurs having a best practice for incorporating that into an automated GDPR solution is crucial.

Next up are reflections on how the analysis provides a basis for actual implementation.

Temaer