How to properly hold personal data in compliance with the DPA (Data Protection Act) and GDPR.

In a recent article I looked into the 3 P’s for GDPR success – policy, process and people. One of the practical outcomes of GDPR compliance you need to achieve is the easy retrieval of data you store about people – whether they are supporters, donors, fundraisers, members or stakeholders.

Almost every charity or NFP organisation will hold data about people on more than one system. But what happens if someone wants to see the data you hold on them – can you be sure you will know where to find it all? They would be fully within their rights to request to see the data you store about them under section 7 of the DPA or after 25^th May 2018 under GDPR, “the right of access by the data subject”.

Therefore, it’s important to take data storage seriously and address any problems right away. This is where integration of disparate systems comes in, but before we consider this on a technical level, we need to take a step back and really understand the best way to manage the journey of a subject’s data across several disparate, integrated systems.

In order to integrate several disparate systems, which may be a combination of on-site, data centre and cloud-based, then it’s vital to understand Data Governance. I don’t advise going straight to solution design – for one thing there could well be pieces of the design that are missing, and which your Data Governance should have answered when you were initially scoping the design. Secondly, you could run the risk of integration becoming a series of tactical fixes strung together with ever more complex pieces of middleware code and no real sense of how the whole structure works together.

Continue like this and you will start seeing random breakages, which become ever trickier to track down because the code has started to become non-maintainable. It’s also important to ensure each piece of integration work is documented and updated when each change is made, including the dependencies on the other pieces of integration.

In terms of Data Governance, there are 4 key areas to focus on – ensuring the data is usable, has integrity, is available, and is secure.

1.Usability

What is the data, what does it represent, how do we make sure we can get useful information out of it to help us make decisions? To get a really good handle on the data, we need to define it well, and this means developing a Logical Data Model.

You might be thinking “hang on, haven’t we already got the database schema for our CRM system? That’s a data model, right?”  Well, yes it is – but it’s a physical data model, and that’s a bit different.  Firstly, the database schema is designed around the storage and retrieval needs of the CRM system itself, which means that it won’t necessarily reflect your organisational data needs.

Secondly, it will no doubt have been added to and extended by your CRM vendor as they’ve developed the product, and these changes may well have been the easiest way of implementing the enhancements they had to make, but not necessarily the most logical way of doing it.

And thirdly, you are probably using other systems outside of your CRM system precisely because the CRM database doesn’t do some of the things that your organisation does, so the CRM schema will obviously be incomplete.

Your Logical Data Model needs to be built around the business objectives and data needs that your organisational processes actually require. It shouldn’t reflect the table structure of your CRM system; in fact your Logical Data Model ought to stay the same even if you change systems.

2. Integrity

You will know that as soon as you have the same data in more than one system, one of the systems will be “wrong”.  In fact, one of the reasons you probably started thinking about integration was to try to keep two (or more) systems in sync, so that (for example) if you looked up a person on both systems, you’d get the same address, phone number and email address. This is where we start thinking about Master Data Management.

The aim of Master Data Management is to achieve an authoritative source which is trusted and reliable, with the ultimate goal of achieving a single version of the truth.  And, assuming that we treat our CRM system as the “central” system that contains the records of all the people that we have contact with, it starts to look as if all our disparate systems need to agree with CRM.

Master Data Management therefore becomes our overriding reason for integrating our disparate systems.  We want to get to a point where all the systems use a common ID for each person across all systems (bearing in mind that often a person’s record will not need to exist in all the systems).  And so far as possible, we want to avoid or eliminate duplication across systems.  For name, address and other contact information, this may well be tricky – and our integrations will need to help reconcile that data.  For everything else, try to keep the data in the one system that processes it, and avoid duplication.

3. Availability

We need to know where all our data is kept, and the typical tool for this is a Data Asset Register. This needs to list every (and I mean every) database, list or file that contains data that is represented in our Logical Data Model.

Only when we actually know where all our data is, will we be able to ensure that it is all available.  It should be possible to map your Data Asset Register onto the Logical Data Model and, ideally, there should be little to no overlap of business objects between the assets (basic contact data likely being one of the exceptions). There also should be nothing in the Logical Data Model that lacks coverage in the Data Asset Register – if there is, then how (and where) are you managing that data?

4. Security

Of course we need to make sure that systems cannot be accessed by unauthorised users – h but what about unauthorised systems? When doing system integration, authentication between systems is essential – but it’s also often not that easy.

Make sure that you have proper processes in place for ensuring systems can trust each other, without leaving great big security holes.  It shouldn’t need saying, but don’t put passwords in plain-text files, especially when those passwords will allow full access to the CRM database. Modern systems have better methods of authentication, using tokens, certificates, PKI and the like. Make sure to use them.

Once you’ve got all your Data Governance in place, you need to focus on your process. You should know what all you data is (Logical Data Model), how reliable it is (Master Data Management), where it is (Data Asset Register) and that it is secure.

You still need to be able to find all that data about a particular person. You need to start with your master data so that you know all the possible business objects that could hold information about the data subject. Your process should then take you through every item in your data asset register, identifying that person’s data in each one, and so long as all your governance has been done, the process should deliver the right answer, which is all the data about the person who requested it.

For further assistance ensuring your data is easily attainable, complies with law and legislation and is fully secure, contact MAST ICT today to discuss how we can help you integrate your disparate systems.