Now you see it, now you don’t - practical data privacy (part 1)
22 Jun 2017 | by James Alty
The forthcoming GDPR legislation requires data privacy protection by design and default.
The General Data Protection Regulation (GDPR) becomes law across the EU in May 2018. GDPR builds on existing data protection principles by extending both the scope and depth of existing rules and imposing strict legal responsibilities on organisations using any form of personal data.
The broad scope of GDPR regulations mean that they will have an impact across your organisation extending far beyond marketing data analysis. This technical note is limited to helping you meet GDPR requirements within marketing data, accessed and analysed through a FastStats system.
Specifically, it does not address related areas like general IT security, data gathering, consents and online tracking.
Here are some useful background links:
The following relevant concepts are highlighted within the requirements for GDPR compliance.
Data protection by design and default
Use technical and organisational measures to both ensure and demonstrate data privacy and security.
Personal data must be relevant and limited to that required for the data processing task.
Personally Identifiable Information (PII)
PII is any data that could be used to identify a specific individual. Obvious examples include name, date of birth, national insurance number, email address, phone number. Clearly, data privacy requires that PII is secured.
This ‘pseudo-word’ is an aspect of data privacy and protection by design. It requires that personal data cannot be directly associated with a specific individual. A simple example would be to use a unique reference number (URN) or account number only on the data record. The mapping of URN to a person’s name is held separately and is only available to processing that requires this contact information.
These concepts are clearly related and this technical note will review the tools and working methods that can be adopted within a FastStats environment to achieve compliance.
As a first step always review the data that is to be included in a FastStats data store. Wherever possible, avoid storing PII altogether. If you don’t store the data in the first place then it can never be leaked or misused.
In general marketing data analysis does not require access to PII. With forward planning use of PII can be avoided:-
- Geographical analysis might require a postcode but almost certainly doesn’t require the full address lines.
- The age of an individual is useful information but is it necessary to know an exact date of birth?
- The email domain (following the @ e.g. hotmail, gmail etc.) could be useful for analysis but is the full email address required?
FastStats Designer enables you to exclude data columns and map data (e.g. date to age) so PII can be easily excluded from the system build. Unique reference numbers (URNs) can be used to identify records for marketing and a separate table linking URN to personal addressing data can be used at the point of fulfilment.
But there are reasons that PII might need to be included in your FastStats data store:
- An existing operational FastStats system might use PII variables in saved selections and other definitions. There are scanning utilities that can help you check variable usage (see “Who’s Been Looking At My Data?”). For example, if you make selections based on birthday then possibly you can’t do without date of birth.
- If you are using PeopleStage or uploading directly to Email Service Providers (ESPs) or other digital marketing platforms it will often be necessary to maintain the email address and possibly the name of the individual in FastStats. Similarly, direct mail requires the postal address. Where possible you should consider storing the table linking URN to name and address with the trusted fulfilment partner. It is also possible to work with a hash of the email address.
- The facility to view some PII data is useful when checking data integrity. The same is true when investigating and correcting issues with an individual’s stored information.
A practical compromise involves limiting access to PII to the few processes and personnel who really require it using column filters.
Column filters enable you to restrict access to PII and other sensitive fields to certain users. On an enterprise system, FastStats users are arranged in groups and access rights to data can be set at the group or individual level. Usually it is convenient to use groups.
Typically, you will allow trusted administrators to at least view all the data (for validation purposes). Most analyst and marketing users will be able to work with more restricted access to data. The ‘select’, ‘browse’ and ‘export’ functions of each variable can be allowed or restricted as appropriate.
For example, you could decide that all users in the group “Analysts” can select on date of birth but not view or export this variable. This means that the variable will be allowed in selection criteria but always displayed as an empty column in datagrids or exported files.
Column filter user properties are accessed from a “Users Explorer” tab. This tool can only be accessed by a system administrator.
Even without direct access to PII, a FastStats system contains valuable data and it is good practice to impose restrictions on data extraction.
‘Modify Transferable Extensions’ limits the file types that can be transferred out of the user’s Discoverer folders.
‘Velocity Limits’ tightly specify the number of records that can be exported from the system per week or per day.
‘Velocity Periods’ are used to limit exports to working hours.
- Review PII data
- Check carefully whether PII is required for analysis processes or outputs
- Omit PII data that isn’t required
- Use ‘Column Filters’ to restrict access to PII to those who really need it