This past May 25, 2018 marked the start of the EU’s General Data Protection Regulation (GDPR). All companies servicing data belonging to members of the EU are now expected to be able to log and gather consent for any usage of their customers’ data. Customers should also be empowered to control how their data is used – or if it should even be used at all.
By now, many companies are well on their way to complying with the GDPR. Typically this includes adding consent popups for any cookie usage, sending out emails notifying users of updates to privacy policies, and implementing data storage and retention policies. For users of Azuqua, this also means setting up policies around how data is cleared from the systems and applications where personal data is being processed.
This article is designed to help companies using Azuqua ensure their Azuqua-built solutions comply with GDPR – either by process or by movement of their own customers’ personal data.
How Do I Make My Solution GDPR Ready?
Being ‘GDPR ready’ often means different things to different companies depending on their specific policies and needs, but in general it covers the following:
- Right to be Forgotten: Ability to “forget” a customer or data subject if they request all personal data be deleted wherever it is stored or processed
- Consent: Asking for consent before collecting and using personal data and being able to prove that consent was obtained (and what the person consented to)
- Access & Correction: Providing details on what personal data has been collected or is currently being processed and giving individuals or companies the right to modify the data if it’s inaccurate or incomplete
- Halt Processing: Being able to stop accessing, storing, using and otherwise processing personal information upon request
In the next few sections we’ll discuss how users and customers can ensure their Azuqua solutions are able to handle these types of requirements.
Right to be Forgotten
At any time a EU citizen can ask to be forgotten from your system. Because companies need to be able to respond to these requests and fulfill them in a short amount of time, this can be an ‘intimidating’ requirement of the GDPR. There are a few best practices you can use to help ensure your Azuqua solution is ready to handle these types of requests.
- In Azuqua, certain function cards allow your FLO to stay in a paused state until a trigger occurs. Any FLOs using a Wait For, Wait Until, Pause, and/or Pause Raw card(s) are essentially configured to wait, stay paused, and be triggered again. Once your FLO has started running, however, it cannot be stopped. So if your FLOs are using any of these function cards, you need to make sure they are accounted for in your GDPR policy.
- Let’s say, for example, your GDPR policy is to respond to ‘Right to be Forgotten’ requests within 30 days. If you have an email FLO that has a “Wait For 60 days” card in it and that FLO has been triggered, the user who has requested to be forgotten may receive an email potentially up to a month after your policy period has ended.
- By default, Azuqua does not save FLO execution history, a user must ‘opt in’ to save this data. Thus, an easy way to simplify your Right to be Forgotten process is to make sure Azuqua isn’t collecting and storing any execution data for your FLO. Additionally, Azuqua allows users to clear their execution history on an ad hoc basis so in the event someone exercises their right to be forgotten, you can manually clear all execution data that has been saved.
- Azuqua users have the ability to search any Azuqua table using the “Search Rows” card and clear any data using the “Delete Row” card. So if someone requests they be forgotten, you can quickly search through any tables that may be storing PII data and delete the applicable row from your Azuqua table. You can also do a regular cleaning of your Azuqua tables by searching for old or outdated entries and deleting these rows from your table.
Prompting and logging consent can often be handled directly from within the application a user is interacting with. However, in cases where that may be insufficient or you need that consent to be shared across several different applications, Azuqua can help.
- If your company needs to be able to sync consent logging across systems, Azuqua can easily be the conduit between your consent-logging application (e.g., HubSpot) and an action-taking application (e.g., MailChimp). You can quickly and easily configure your FLO’s events to accept the consent-logging field from your source app and send that on to any other necessary applications in your FLO.
- If you’re using Azuqua’s Form FLO capabilities, you can add in a field and set type to ‘boolean’ in order to prompt users for their consent.
- You can also use Azuqua tables to act as your Azuqua-accessible data store for consent logs. If you’re collecting different types of consent from different applications, you can use FLOs and Tables together to sync that data and get a comprehensive view of your users’ consent.
Access & Correction
If a customer requests access to or information on all the personal data you have in your possession, it may be difficult to quickly gather this information from all the different data sources. Azuqua can make it easy to collect this information at once from necessary data sources and parse it as needed.
- You can set up an API endpoint or FLO that can be triggered on-demand by members of your team who would need to respond to these kinds of requests. These FLOs would search through multiple applications based off a common parameter (e.g., user email) and then compile this information back together in a readable format. This process can also include database applications as well.
- If you’re keeping information inside of tables, you can use our “Search Table” functionality to check data in that data store as well.
Many companies collect and use data in a way that is not central to their product functionality – for example using customer emails for marketing communications. If a user opts out of these types of communications, Azuqua can help make sure you’re not still using personal data for activities that someone has explicitly opted out of.
- For any FLOs that represent functionality users can opt out of (e.g., emailing external parties), you can use Azuqua’s built-in branching capabilities. This could be used to stop FLO executions that would be contacting users who have opted out of that functionality. All you would need is to store these opt outs in an application or database, connect to the application or database using an Azuqua connector, and read from it using your FLO.
- Alternatively, you can use an Azuqua table as the data store and let your FLOs read from the table instead of an additional application or database.
Interested in reading more about Azuqua’s GDPR policy? Read more here.