Best Practice for GDPR Compliance

On 25th May 2018, the European Parliament enforced the General Data Protection Regulation (GDPR). The new law regulates how companies collect and handle data.  

To comply with GDPR, you need to consider how you handle your data. In Agillic, we've added several features and improvements to make it easier for you to become GDPR compliant. 

We've put together the following article as suggested best practices to do with GDPR. They do not guarantee GDPR compliance. For legal advice on this subject, please contact a lawyer or expert.

GDPR ensures any individual with some fundamental rights including:

• Data Modelling
• Right of Access
• Right to Have Data Transferred to Another System
• Right to Request a Restriction of Data Processing for a Period of Time
• Right to Information Correction
• Right to Be Forgotten: Have All Data Concerning a Person to Be Deleted
• Right to Object Profiling
• Right to Object Data Processing

Best Practice for GDPR Compliance

Data Modelling

First of all, follow Agillic's best practices when it comes to storing personal data. 

Global Data Tables are only intended for public non-personal data e.g. product information. Be aware that recipient specific data in Global Data Tables could lead to GDPR issues for you as a data controller. Recipient specific data has to exist either as Person Data or One-to-Many data. 

Right of Access

The recipient has the right to access the personal data that's stored or processed about them. In Agillic terms, this process requires you to export all the recipient-specific data saved for the recipient.

You can read more about how to export all data for a specific recipient here.

Right to Have Data Transferred to Another System

You may need to export all personal data for a recipient. In this case, you'll need to:

• Setup an Export Template for Person Data.
• Setup an Export Template for each One-to-Many Table you may have.
• Setup an Export Profile to transfer the data to a server or inbox.
• Create a Flow with one or more export Steps, depending on the number of One-to-Many Tables.

You can learn more about how to create an export Flow here.

If you need to export activity data, you'll need to set up an activity export. You can read more about how to create an activity export here.

Once you've generated the export, it will consist of all activity data for all recipients. You'll need to then filter the export to only show data for the specific recipient.

Right to Request a Restriction of Data Processing for a Period of Time

This can be solved by making sure the recipient isn't part of any Flow for the time period. This ensures that the recipient won't have data processed. If you wish to set up a restriction for a limited time period, you can set it up in Agillic.

You can learn more about how to work with permissions here. 

Right to Information Correction

You can correct Person Data or One-to-Many for a recipient by looking up the recipient in a Target Group. We recommend that you keep your data transfer in mind as some data may be overwritten by external systems. In that case, you'll need to correct data externally and have the data transferred to Agillic.

Right to Be Forgotten: Have All Data Concerning a Person to Be Deleted

In order to delete recipients from Agillic, you need to create a Target Group with the recipient(s) you would like to delete. 

In some cases, you may need to delete the recipient on external systems as well as in Agillic. In this case, an external system can send an API to delete the recipient in Agillic while also being deleted externally. You can find developer documentation on our APIs on developers.agillic.com 

Remember that deleting a recipient removes the data about the recipient from the current Agillic system, but not from the backups. The recipient data will be fully deleted from all Agillic backups six months after the deletion date.

Right to Object Profiling

In GDPR-terms, 'profiling' refers to any automated processing of personal data that aims to evaluate certain aspects of a person. For example, profiling might analyse someone's personal preferences, economic situation, or behaviour. In Agillic, this means personalisation. If you're personalising a lot of your communications, you might want to consider what to do if a recipient objects to profiling.

You can learn more about the ways you can work with Permissions here.

Right to Object Data Processing

As data processing is defined as 'any operation or set of operations which is performed on personal data or on sets of personal data', objecting to data processing would, in Agillic terms, result in full opt-out.

You can learn more about the ways you can work with Permissions here.