With an enforcement deadline of 25th May 2018 it is estimated that more than *50% of small businesses are not familiar with GDPR. With fines of up to €20,000,000 or 4% of global turnover GDPR demands to be taken seriously. The good news is that its not too late for companies to start to prepare as long as they act quickly.

If you fall into this category, the first step is awareness – make yourself aware of what GDPR is and what it means for you and your organisation.
Our first two posts on GDPR looked at what is GDPR  and who it affects. If you are in any doubt, then we suggest reading the first two posts before reading this one.

In this post, we will explore some of the possible ways to protect data as part of a compliance strategy by using the standard out of the box features of Microsoft Dynamics 365.

GDPR & Microsoft Dynamics security features

Microsoft Dynamics 365 has strong and flexible security features that can be leveraged to create complex security models.  We would always advise our customers to fully explore the out of the box security features before using customisations to create additional security. This is because of the extra maintenance and overhead associated with additional customisations.

Controlling access to data

When was the last time you audited who can access what data within your organisation?
You may not want every member of your team to access all of your customer data. In fact, they should only have access to the data they need to do their jobs.  You may also have a requirement to store sensitive data about clients such as legal records or health records.

Charity example

Consider the following example: A charity holds contact records for their clients. These records contain sensitive data such as information on disabilities, or mental health as well as personal contact details. The charity has some people on staff that deal directly with clients and these people need access to all data. The charity also depends on volunteers to collect the data and update records. In this example, the volunteers do not need to see the sensitive data in order to carry out their role therefore access to this data could be seen as being in breach of GDPR.

Forms-based approach

One way to approach this problem, using Microsoft Dynamics 365, is to restrict data access using a forms-based approach. The charity could provide a form for the contact entity that only contains the fields that the volunteers need to see and interact with. Then another form can be configured so that the staff can access the data that they need to see. The permissions on each form would be based on Microsoft Dynamics 365 security roles. Form access can be restricted to one or more security roles in Microsoft Dynamics 365 so in the example used above the charity may decide to create a security role for the volunteer users and another one for staff and let them use two different forms.

Field level security

Another way to restrict access to data is to set security at the field level rather than at the form level. In the case that only one or two fields contain sensitive data it is possible to use a feature called field level security to set permissions on an individual field. There are three levels of permission which are:

• Read – access to read the value in the field.
• Create – permission to add a new value to the empty field.
• Write – permission to edit the data in an already populated field.

A system administrator can create a field level security profile record that has a set of the above permissions (e.g. Read only). Then they will add users or teams to the profile. In the case that a user who isn’t in a field level security profile encounters a field with field level security, they will just see the field label followed by a series of asterisks. So, in the case of the charity example, the volunteer users would not be added to the field security profile.
Image here

Restricting data with custom entities

A third way to deal with the same issue is to create a custom entity (e.g. an entity called “sensitive data”).  The charity may then restrict access to that whole entity so that only the staff can access it (think of a custom entity as a folder linked to a contact in which various information can be stored).

Microsoft Dynamics security roles can be set to five different levels of read access on an entity, including no access. So, in our scenario, the staff who have access to the custom entity will go to the customer record and will be able to access the data from within the customer record. Whereas the volunteers will have no access to the sensitive data entity so will just see an empty table. Microsoft Dynamics 365’s security model is very flexible. Staff permissions can be set to have a range of different levels of access to the data depending upon their role or needs within the organisation. When they change role within the organisation then it’s just a matter of changing their security role.

Sensitive Data Collection

So far, we have looked at how we can restrict access to data that is already collected, but what about collecting data in the first place? This could be tricky if the volunteers are not authorised to collect, store or process sensitive data.
There are several ways in which this could be achieved:

1. The volunteers will collect the basic contact details which then triggers an automatic Process (using a Microsoft Dynamics 365 workflow). The workflow might create and send a portal login for the contact. This would then leave the customer to add the remainder of the data via a secure portal. Thus the volunteer does not see or have access to the data.
2. Another scenario might be where the creation of a “basic” record triggers an action for a security cleared member of staff to get in touch with the individual to collect further data to assess a case.
3. A third option could be to have the creation of the basic record trigger the sending of a private survey for the individual to populate and submit. When the client submits the survey it will automatically write data back in to a secure area in Microsoft Dynamics 365.

In the fourth and final post in this short series, we will look at other ways to restrict data access and at the topic of consent (what is it and how long does it last?).

If you need any help in configuring the above or in preparing for GDPR or guidance on GDPR & Microsoft Dynamics safety features, contact us to discuss how Rocket CRM can help you

*According to survey by leading law firm Collyer Bristow