The General Data Protection Regulations (GDPR) passed by the European Union in 2016 and becoming active on May 25, 2018, are a set of regulations that are meant to protect European Union citizens who have their personal information collected and processed by companies. Primarily these regulations relate to internet usage; however, they extend to any type of collection and processing of data about an individual that is used by a company. The regulations are not only for EU companies but apply to all countries who collect, store and process information about EU residents. If your company is doing business in the EU you will need to comply with these regulations starting at the end of May; otherwise, you may be subject to hefty fines.
There’s a lot of information available on the web about the letter of these regulations but not as much available on how to implement the business and IT practices that are required to enforce them. In this article, we will discuss the technical aspects of GDPR- proofing your Dynamics 365 instance. There are a few requirements as they relate to your Dynamics 365 back-office as well as Dynamics 365 portals to collect information from customers. We’ll start with the portal facing requirements and then move on to the back office.
Dynamics 365 Portals and GDPR: Be Concise, Specific and Transparent
One of the regulations in GDPR is that “consent must be explicit for data collected and the purposes data are used for” (Article 7; defined in Article 4). In addition, all consent must be on an opt-in basis, meaning if you have a checkbox on your portal that says, “I agree,” that checkbox must be unchecked by default, and you are not allowed to have a checkbox that reads, “I don’t agree”. Additionally, the regulation requires you to be specific about what the user is opting into, and each opt-in must be explicitly called out and must use simple and direct language. The reason for this is obvious to anyone who has been presented with several pages of legal text that has an opt-in buried somewhere in the verbiage that a user may not be aware that they are opting into. For example, you can’t embed your opt-in to a newsletter in your terms and conditions; you must explicitly call out the opt-in to the use of the user’s email address for marketing purposes. Likewise, a user must be able to opt-out at any time and must be given access to the ability to opt-out.
However, this type of message will no longer be sufficient because it does not allow users to opt-out. Instead, the new requirements would need to look more like the following.
Another aspect of GDPR is discovery and access to personal data. An individual has the right to view and update the personal information stored by a data processor. In the case of this regulation, portals provide a perfect solution for compliance. You can use your portal to publish an individual’s information, so they can see what data is being stored and edit that information.
Back Office Dynamics 365 and GDPR: Time to Get your Data in Order
Chances are, if you’ve been using Dynamics 365 for a while, you already have a lot of personally identifiable information on your customers in your data. If you work with EU customers, you will be responsible for conforming to the GDPR regulations for the information you’ve already collected, including getting explicit consent for processing their data. One way to do so would be to email your customers who have already consented to receive email and ask them to consent to the more explicit opt-in agreements. One thing to consider is that if an individual has already opted-out, you should not email them to get reconsent.
The GDPR regulations include the right to be forgotten, under which an individual can ask for their personal information to be removed from your data. There are a couple of ways to achieve this.
- Delete the individual’s records in Dynamics – This is likely not the best solution since there can be associated non-PII data that will be deleted as well and may not be technically feasible in Dynamics depending on the way relationships are configured
- Obfuscate the user’s information so no personally identifiable information is stored. – This would involve changing the personally identifiable information to something unidentifiable (e.g. changing first and last name to John Doe). This is preferable to deleting the data, but in this case, there’s no way to ever know who the person was which is the idea, but there’s a better way.
- Pseudonymize a user’s information where the personally identifiable information is changed in such a way that it is no longer identifiable without matching against the original information. This is probably the best solution and involves a technique known as hashing, which is commonly used to store passwords. The data is encrypted in such a way that it can never be decrypted or human readable, but could be matched against the original data by hashing the original data and comparing it against the hashed value. This provides your organization with an opportunity to identify data that comes into Dynamics as already being forgotten. You can then choose to not allow the data to be re-entered or restore the original data assuming that you have obtained consent from the customer to do so.
Another interesting part of GDPR relates to automated processing of data. Most commonly in Dynamics we would see automated processing happen via workflows that act on data in Dynamics to perform some sort of operation on the data or kick off additional processes in response to a change in the data. Most of these types of automated processes are inconsequential and won’t necessarily require consent. However, there are some cases where you will need to get consent from users to use their data in an automated process. Particularly if that process has the potential to do harm to the individual, including things like running credit checks, importing information about a user from third parties like social media sources, or sharing the information with a third party. Again, if there is a consent statement in place for performing these actions, it is considered legal reasons for doing so. You may want to start looking in the following areas of your system to audit your GDPR compliance.
- Document all personal information that you are storing. Most likely these will be on system entities like contacts and leads.
- Document your workflows and integrations to make sure you have consent to perform automated processes and share personal information.
- Document your internal processes for marketing, service and sales automation to ensure you have consent to use personal information in these workflows.
- Ensure that you have the proper consent mechanisms in place in your portal as well as through email channels, and that you are auditing these for full consent (including when, where and how consent was given).
The regulations in GDPR are not meant to cause undue headache for businesses that collect and process information. They are meant to give customers more control of their information and improve the relationship between businesses and customers. The simplest rule of thumb is if you are collecting information about a user on the web, let them know why and how you plan to use it and give them the opportunity to control who sees that data, when and how it is used, and if they choose to do so.
A lot of the regulations are common-sense business practices and will ultimately forge better relationships with your customers/users through transparency and trust. If you aren’t sure if a practice you are using today conforms or if it is 100 percent transparent, take a step back and think about how you would want your information or your family members’ information to be used and make the best choice based on that. You’ll likely find that you’ll be compliant simply by making the choice to be transparent in your collection and processing strategies.