This is the final post in my 5 part series focusing on the practical implications surrounding the General Data Protection Regulation (GDPR) and how some of the features within Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E) can be utilised to smooth your organisations transition towards achieving compliance with the regulation. In this week’s post, we will be delving deep into the murky world of Subject Access Requests (SAR’s) (a process that already exists within existing E.U. Data Protection legislation), some of the changes that GDPR brings into the frame and the capabilities of the Word Template feature within CRM/D365E in expediting these requests as they come through to your organisation.

All posts in the series will make frequent reference to the text (or “Articles”) contained within Regulation (EU) 2016/679, available online as part of the Official Journal of the European Union – a particularly onerous and long-winded document. If you are based in the UK, you may find solace instead by reading through the ICO’s rather excellent Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be garnered.

Before jumping into the fun stuff, it’s useful to first set out the stall of what SAR’s are and to highlight some of the areas to watch out for under GDPR

A SAR is a mechanism through which an individual can request all information that a business or organisation holds on them. Section 7 of the UK’s Data Protection Act 1998 sets out the framework for how they operate and they are applicable to a wide variety of contexts – from requesting details from an Internet Service Provider regarding your account through to writing to an ex-employer to request what details of yours they hold on file. The types of information covered under a SAR can be quite broad:

  • Documents containing personal details
  • Emails
  • Call Recordings
  • Database Records

The effort involved in satisfying a SAR can be significant, typically due to the amount of information involved, and time will need to be put aside compiling everything together. You will also need to ensure certain types of information are redacted too, to prevent against an inadvertent data breach by revealing other data subjects details. It is for these reasons why SAR’s are typically seen as the bane of IT support personnel’s existences!

Be Aware Of The Implications Of Ignoring A SAR

Article 12 provides a broad – but nonetheless concerning – consequence should you choose to disregard or not process a SAR within the appropriate timeframes:

If the controller does not take action on the request of the data subject, the controller shall inform the data subject without delay and at the latest within one month of receipt of the request of the reasons for not taking action and on the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy.

Under current guidelines issued by the ICO for the Data Protection Act, the type of enforcement action include being mandated to process a SAR via a court order and even compensation for the data subject, if it can be proven that the individual has suffered personal damage through your lack of action. Whilst GDPR makes it unclear at the stage whether these consequences will remain the same or beefed up, organisations can make an assumption that there will be some changes under the new state of play, particuarly given that enforcement actions have been developed significantly in other areas (e.g. data breaches).

Overrall, SAR’s remain largely the same under GDPR, but there are a few subtle changes that you should make note of:

  • Most organisations currently will charge an “administration fee” for any SAR that is sent to them. GDPR does not specifically mandate that organisations can levy this charge anymore, so it can be inferred that they must now be completed free of charge. An organisation can, however, charge a “reasonable fee” if the data subject requests additional copies of the data that has already been sent to them (Article 15) or if requests are deemed to be “manifestly unfounded or excessive” (Article 12).
  • All information requested as part of an SAR must now be supplied within 1 month (as opposed to 40 days under existing legislation) of the date of the request. This can be extended to a further 2 months, subject to the organisation in question informing the data subject of the extension and the reason for the delay. Delays should only be tolerated in instances where the “complexity and number of the requests” exceeds normal situations (Article 12).
  • Organisations are within their right to request documentary evidence that the individual who has sent the SAR is the person they claim to be, via official identification or similar. This is useful in two respects: it enables an organisation to mitigate the risk of a potential data breach via a dishonest SAR and also affords the organisation additional time to process the request, as it can be inferred that the request can only be reasonably processed once the individual’s identity is confirmed.

The ability to expedite SAR’s in an efficient and consistent manner becomes a significant concern for organisations who are aiming to achieve GDPR compliance. But if you are using CRM 2016 or later, then this process can be helped along by a feature that any application user can quickly get to grips with – Word Templates

This feature, along with Excel Templates, is very much geared towards bridging the gap for power users wanting to generate reports for one or multiple record types, without having to resort to more complex means (i.e. SQL Server Reporting Services reports). I looked at the feature a while back on the blog, and it is very much something I now frequently jump to or advise others to within the application; for the simple reasons that most people will know how to interact with Word/Excel and that they provide a much easier means of accessing core and related entity records for document generation purposes.

To best understand how Word Templates can be utilised for SAR’s, consider the following scenario: ABC Company Ltd. use D36E as their primary business application system for storing customer information, using the Contact entity within the application. The business receives a SAR that asks for all personal details relating to that person to be sent across via post. The basic requirements of this situation are twofold:

  • Produce a professional response to the request that can then be printed onto official company stationary.
  • Quickly generate all field value date for the Contact entity that contain information concerning the data subject.

Both requirements are a good fit for Word Templates, which I will hopefully demonstrate right now 🙂

In true Art Attack style, rather than go through the process of creating a Word Template from scratch (covered by my previous blog post above), “here’s one I made earlier” – a basic, unskinned template that can be uploaded onto CRM/D365E via the Settings -> Templates -> Document Templates area of the application:

Subject Access Request Demo – Contact

When this is uploaded into the application and run against a sample record, it should look similar to the below:

Once deployed, the template can then be re-used across multiple record types, any future SAR’s can be satisfied in minutes as opposed to days and (hopefully) the data subject concerned is content that they have received the information requested in a prompt and informative manner.

Thanks for reading and I hope that this post – and the others in the series – have been useful in preparing your for GDPR and in highlighting some excellent functionality contained within CRM/D365E. Be sure to check out the other posts in the series if you haven’t done so already using the links below and do please leave a comment if you have any questions 🙂

Part 1: Utilising Transparent Database Encryption (TDE)

Part 2: Getting to Grips With Field Security Profiles

Part 3: Implementing & Documenting A Security Model

Part 4: Managing Data Retention Policy with Bulk Record Deletion

Welcome to part 4 of my 5 part series looking at the practical implications surrounding the General Data Protection Regulation (GDPR) in the context of Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E). The series looks at how some of the features within this application can assist you in your journey towards GDPR compliance. This week’s post will be jumping across to an arguably underrated aspect of the application – Bulk Record Deletion and how it be used to satisfy your organisation’s data retention policy.

All posts in the series will make frequent reference to the text (or “Articles”) contained within Regulation (EU) 2016/679, available online as part of the Official Journal of the European Union – a particularly onerous and long-winded document. If you are based in the UK, you may find solace instead by reading through the ICO’s rather excellent Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be garnered.

As we get started, here’s a question for you: Do you know how long your organisation holds personal data for before it is deleted?

Most organisations that you speak to may struggle to provide an answer to the above question. The tendency is very much towards holding data for an indefinite period, with this approach typically being borne out of a lack of understanding of legal/contractual requirements, a result of a genuine oversight or as a necessary evil. The problem with any of these justifications is that, as well as falling foul of GDPR, it more than likely also is a contravention of your countries existing data protection legislation. In the UK, for example, Principle 5 of the Data Protection Act 1998 states clearly that “Personal data…shall not be kept for longer than is necessary…”. Despite being quite broad in its interpretation, it can be inferred very clearly that organisations should be aware of how long all of their data is held for and to have the appropriate documentary evidence to support this, via a policy or similar.

The existence of this principle demonstrates one of the areas where GDPR does not differ greatly from the Data Protection Act 1998. Article 17 covers all aspects concerning when and how data should be removed, under the broad principle of the “right to be forgotten”:

The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:
(a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed;
4.5.2016 L 119/43 Official Journal of the European Union EN
(b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing;
(c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2);
(d) the personal data have been unlawfully processed;
(e) the personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject;
(f) the personal data have been collected in relation to the offer of information society services referred to in Article 8(1).

To summarise, this means that organisations should remove information pertaining to data subjects when:

  • There is no further requirement to do so, either contractually or legally (i.e. they are no longer required to as part of a statutory instrument)
  • The subject has withdrawn their consent
  • It has been identified that data is being held which is at odds with an organisations policies or primary business activities

Article 5 extends this further by making it clear that data which you are unable to keep sufficiently accurate should be “erased…without delay”. To avoid this scenario would require the need to regularly contact the data subject concerned to verify their details are correct. One of the major “get out of jail free” cards that GDPR provides surrounding data retention is in instances where the data will be used as part of “archiving purposes in the public interest, scientific or historical research purposes or statistical purposes..” (Article 5). The scope of this is, as you can tell, rather limited and most non-governmental organisations/businesses may struggle to demonstrate their data archiving is in line with these broad principals.

The importance of ensuring a clearly defined and structured process for the removal of customer data, therefore, becomes a paramount concern under GDPR. Investigating and defining your organization’s data retention periods is an exercise that should be carried out if it has not been done so already. Once implemented, we can then turn to a component within CRM/D365E to automate and streamline the actual process – the Bulk Record Deletion feature.

In a nutshell, this feature is a really efficient means of deleting large amounts of predefined data within CRM/D365E. Administrators of the application will most often work with them when attempting to reduce the storage footprint of a CRM/D365E instance, via the removal of completed System Job records and other superfluous record types. The ability to define filter criteria, re-occurrence settings and to send out email notifications upon completion of a job, make them an excellent candidate to consider when streamlining your internal processes surrounding data retention.

For example, let’s assume your business has implemented a data retention policy that states Contact entity data that has not been updated or changed within 12 months should be deleted from the system. Setting up a Bulk Record Deletion Job within the application to assist with this task is remarkably straightforward, as the step-by-step guide below indicates:

  1. Within the application, navigate to Settings -> Data Management on the Sitemap and click the icon to navigate to the Data Management page:
  2. On the Data Management page, click on the Bulk Record Deletion icon to open the All Bulk Deletion Systems Jobs view. Once this has loaded, click on the New icon:
  3. The Bulk Deletion Wizard will open a pop-up window. Click Next on the first screen to move to the Define Search Criteria window. Modify the settings as follows:
    • Look for: Contact
    • Search Criteria: Modified On Older Than 365 Days

An example of how this looks can be seen below:

   

  1. Click Next when you are ready to navigate to open the Select Options page. Give the Bulk Record Deletion Job a descriptive name and then ensure that the following settings are configured:
    • Specify whether the Job should run immediately or in the future. It is recommended to schedule Jobs out of peak hours to prevent any performance detriment to other users.
    • Ensure that the Run this job after every box is ticked and then select an appropriate time period. I would recommend 30 days.
    • Ensure that the Send an email to me… box is ticked. You can also (optionally) specify additional email recipients, but note that these have to be valid application users (i.e. not any other email enabled entity such as Contact, Account etc.)

The screenshot below indicates how this should look. Click Next when you are ready to proceed:

  1. The final step in the wizard gives you the opportunity to review all configured settings. Press Submit to create the Job in the system and, if specified to start immediately, begin running it in the background. You can also navigate to the Recurring Bulk Deletion System Jobs view at any time to review the current status of a job, check to see when it is next scheduled to run or even modify its properties to suit your requirements:

 

The example above is a simplified one but could be extended further in conjunction with other features in the application to suit specific requirements. For example:

  • Create a custom entity to store contractual/statutory data retention limits and link these to your common entities within the application via a 1:N relationship. Once selected when a record is created, you can then define a workflow with a wait condition that updates a Two Option custom field on the entity as a flag for a Bulk Delete Job to remove from the system.
  • Using a custom field on your entity to indicate that a customer has expressed their “right to be forgotten”, define a workflow that sends a customer confirmation that their details will be removed from the system within 30 days and then use this same field as a flag for a Bulk Record Deletion Job.
  • Define a workflow that sends an email to owners of records that have not been modified within a set period (i.e. are inaccurate), prompting them to speak to the customer to update their details. Records that are not updated would then be deleted, using a Job similar to the one above.

Application features, such as the one discussed in this week’s post, really start to come into their element when you combine them with other tools found within the application. With this in mind, I would encourage you to roll up your sleeves to see what you can “cook” up 🙂

Thanks for reading! Be sure to check out the other posts in this series if you haven’t already using the links below. Part 5 next week will look at Subject Access Requests and how these can be processed more efficiently using CRM’s/D365E’s Word Template feature.

Part 1: Utilising Transparent Database Encryption (TDE)

Part 2: Getting to Grips With Field Security Profiles

Part 3: Implementing & Documenting A Security Model

This is part 3 of a 5 part series, where we take a closer look at the practical implications the General Data Protection Regulation (GDPR) has upon organisations/businesses in Europe and some of the ways Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E) can assist you as part of the transition. Last week, we saw how Field Security and Field Security Profiles can be utilised to protect sensitive data categories, complementing any existing security model you may have in place. In this week’s post, we are going to discuss the concepts that will enable you to utilise CRM’s/D365E’s security features to their fullest extent, as well as how this can be documented.

All posts in the series will make frequent reference to the text (or “Articles”) contained within Regulation (EU) 2016/679, available online as part of the Official Journal of the European Union – a particularly onerous and long-winded document. If you are based in the UK, you may find solace instead by reading through the ICO’s rather excellent Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be garnered.

Before we jump in further, let’s set the scene by looking at the importance of security and documentation towards achieving GDPR compliance

Article 5 of GDPR clearly states that all personal data must be “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing…using appropriate technical or organisational measures“. This principle is embellished further by Article 24, which states:

Taking into account the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. Those measures shall be reviewed and updated where necessary.

The final sentence links in nicely with the requirements for clearly auditable and documented processes under GDPR (more on this shortly). Finally, Article 25 – which is subtitled Data protection by design and by default – places a clear onus on Processors to implement systems that “ensure by default personal data are not made accessible…to an indefinite number of natural persons“. In summary, clear thought and effort must be borne out to ensure that application systems not only restrict access to personal data on a “need to know” basis but also that these systems are reviewed and updated regularly; with, invariably, documentation forming an important bedrock towards this.

The need for clear documentation under GDPR is emphasised further over multiple articles in the Regulation:

  • If you are processing data on behalf of a controller, you must only do so based “on documented instructions from the controller” (Article 28).
  • Organisations can opt to become “GDPR accredited” to demonstrate compliance with the regulations (Article 24, 25, 28, 32 & Section 5). Such accreditations will likely require sufficient documentary evidence to successfully attain.
  • In situations where data is being transferred “to a third country or an international organisation“, all “suitable safeguards” must be clearly documented (Article 30 & 49).
  • All data breaches must be clearly documented (Article 33).

To summarise, it can be inferred, but not definitively said, that the documentation of security models and user access to data is a broad requirement to satisfy compliance with the Regulations. By comparison, sufficient organisational security measures, both physical and technical, are mandatory requirements under GDPR.

With all this in mind, let’s take a look at the four cornerstones of CRM/D365E security and some of the things to think about from a GDPR perspective: Users, Teams, Business Units and Security Roles

Users

There are no prizes for guessing what this is 🙂 Like with any application system, Users in CRM/D365E are the mechanism through which you log on, interact with and access partial or whole areas of the application. Users utilise the existing identity provider, Active Directory. The benefits of this are that a consistent end user experience can be assured from a login perspective (enhanced further via the implementation of Single Sign On solutions) and there is less management required within CRM/D365E. This is because key information will be synchronised from your Active Directory accounts, such as job title, email address and telephone number. Users begin to come into their element when used in conjunction with the three other “cornerstones” mentioned above, so will be referenced again shortly.

Key GDPR Takeaways
  • Users of your CRM/D365E should be reviewed regularly to verify that access is still required to information within the application.
  • As Users do technically contain personal data relating to employees, all sufficient measures should be taken to ensure that the data that is held within them is kept up to date (Article 5).
  • Appropriate organisational security measures should be put in place to ensure Users are protected against malicious access (e.g. scheduled password resets, multi-factor authentication etc.).
Teams

Teams provide a mechanism for grouping together multiple users under a clearly defined label. For example, you could have a Team called Sales Team that has the account manager Users Bob, Alice and Steve as members. There are two types of Teams that can be setup in the application – Owner Teams, which operate much the same way as a Users (e.g. records can be assigned to them) and Access Teams, which provide specific permissions/access to records. More information about both types can be found on this useful MSDN article.

Key GDPR Takeaways
  • Structuring Teams correctly in conjunction with Security Roles can provide a more streamlined means of managing appropriate levels of access for teams, departments or other groups within an organisation. This is due to the fact that Security Roles can be assigned to Owner Team records, similar to Users.
  • Access Teams require a much higher degree of ongoing management, as you will need to constantly review their membership to verify that only approved Users are members.
  • Reports can be quickly generated for records that are owned by a Team and/or which Users are part of a particular Access Team record via the applications Advanced Find feature. This can assist greatly in satisfying any ongoing documentation requirements.
Business Units

Getting to grips with how Business Units operate can be one of the major challenges when first learning about CRM/D365E. They provide a means of segregating data within your instance so that only Users that are part of a particular “unit” can interact with the records that most directly concern them. Business Units can be best understood and utilised when thinking about your organisation in the following terms:

  • Business Departments
  • Subsidiaries/Parent Companies
  • Regions

Taking the third of these examples, you could, therefore, look at having a “root” Business Unit, with “child” Units for each region that your organisation operates within. Users can then be moved into the appropriate Business Unit for their locality and, as a consequence, only have access to Account records that are situated within their location. Business Units are anything but an exhaustive subject, so I would strongly recommend reading up on the topic separately to gain a fuller understanding of what they are.

Key GDPR Takeaways
  • Business Units provide an effective means of satisfying Article 5’s requirements for data protection “by design and by default”.
  • Remember that Users may still be able to see records that do not exist in their current Business Unit if they have been assigned a security role that gives them Parent:Child or Organization privilege on the entity in question (more on this in the next section).
  • Each Business Unit will also have a corresponding Team created for it. These can be utilised to segregate out security permissions in a more centralised manner, as discussed above.
Security Roles

The most important cornerstone of security within your CRM/D365E instance and the “glue” that holds all other components together, Security Roles define the permissions for every feature and entity within the application, giving you the opportunity to fine tune access privileges on a granular basis. For example, you can grant a user permission to read all records within their current Business Unit, but only allow them to modify records that they directly own. Privileges are structured very much in line with how Business Units operate, with each individual permission (Read, Create etc.) having the following “levels” of access:

  • No Access
  • User Level – Can only perform the specified action on records owned by the User.
  • Business Unit Level – Can only perform the specified action on records within the same Business Unit as the current User.
  • Parent:Child Business Unit Level – Can only perform the specified action on records within the same or all child Business Units as the current User.
  • Organization Level – Action can be performed against any record on the system.

The potential is limitless with Security Roles and, if mastered correctly, they can satisfy a lot of the problems that GDPR may bring to the table.

Key GDPR Takeaways
  • Microsoft provides a number of default Security Roles out of the box with the application and it may be tempting to utilise these directly instead of modifying or creating new ones specific to your needs. I would caution against this, particularly given that the roles may end up having excessive privilege levels on certain record types and could, by implication, fall foul of several articles within GDPR.
  • Similar to how Teams can be used to represent teams or departments within an organisation, Security Roles can be best utilised when they are broadly structured to provide the minimum level of privileges needed for several Users or more. This can also reduce any a headache when it comes to documentation of these roles as well.
  • New versions of the application (which come out twice each year) generally introduce new functionality and – as a result – new permissions required to successfully utilise them. Assuming you are updating your application in line with Microsofts recommended approach, these opportunities can be the best time to review your existing security roles, to verify that they are current and do not contain incorrect privileges.

Quickly Generating Documentation of your Security Model

To assist you in gaining a “bird’s eye” view of your users and their access privileges, the application provides a means of achieving this – the User Summary report:

This report has been tucked away inside the application from many years, a fact that can be attested to below with its rather archaic look. Regretfully, it hasn’t received any love or attention as part of recent updates 🙁

Having said that, the report does have some nice features:

  • It can be configured to run on a specific Business Unit, thereby providing a more closely defined list of the Users/Security Roles.
  • Can be exported to PDF, Excel and other common file formats.
  • Provides full information about each User, including their job title (make sure you are populating this field on your Active Directory first to ensure this appears!).

If you have never run the report before, then I would strongly recommend that you check it out to determine whether it satisfies your documentation requirements around GDPR.

Hopefully, this post has given you a good flavour of what can be achieved within the application to fully build out a suitable security model within CRM/D365E. In next week’s post, we’ll look more carefully at the implications GDPR has surrounding data retention and how the Bulk Delete feature can be configured to automate this process. In the meantime, be sure to check out the other posts in the series if you haven’t already using the links below:

Part 1: Utilising Transparent Database Encryption (TDE)

Part 2: Getting to Grips With Field Security Profiles

This is part 2 of a 5 part series, where we take a closer look at the practical implications the General Data Protection Regulation (GDPR) will have upon your organisation and some of the ways Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E) can assist you as part of the transition. Last week, we took a look at the database encryption feature within the application and why you should devote some time to understanding how it works. The primary focus of this weeks post is how an organisation can ensure that highly sensitive data categories are only made accessible to authorised individuals only.

All posts in the series will make frequent reference to the text (or “Articles”) contained within Regulation (EU) 2016/679, available online as part of the Official Journal of the European Union – a particularly onerous and long-winded document. If you are based in the UK, you may find solace instead by reading through the ICO’s rather excellent Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be garnered.

Introduction – Sensitive Data Categories, their meaning and practical implications

We saw as part of last week’s post the importance encryption plays as a “reasonable” step that any well-established organisation should have implemented to safeguard themselves against the risk of a data breach. The implications of a data breach are covered more in-depth under Articles 33, 34 and 35 of the regulation. The key takeaway from this is that encryption is by no means a silver bullet, and you must instead look at a complementary range of solutions to mitigate the risk and impact of a data breach.

Although not technically a form of encryption, Field Level Security can be seen as an apparatus for providing encryption-like functionality on a very granular basis within your CRM/D365E deployment. Whilst implementing them does broadly conform to the specifications as set out in Article 32 of GDPR, they do also provide a means of satisfying some of the requirements set out in Article 9, which states clearly:

Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.

Unless one of the following conditions apply:

  • The data subject has provided consent to record the data or has placed the details into the public domain.
  • The data needs to be processed as part of a specific line of legitimate business (employment, social security, social protection law, not-for-profit foundation/association, medical care, public health purposes or as part of scientific/historical research).
  • The recording of such personal details is required to protect the vital interests of the person concerned.

Many of the organisations listed above may already be using CRM/D365E as their primary business system and, as a consequence, will be storing the types of information referenced above. Whilst this is surely a legitimate case of data processing, issues may arise, for example, when it comes to which persons within the organisation can see and access this data; a medical doctor/nurse accessing a patient’s health information is appropriate, but surely a receptionist or IT support personnel viewing a patient record has no fair interest in viewing this information. Having appropriate controls in place to protect against these types of scenarios become a primary concern under GDPR, and Article 30 enshrines this further by requiring organisations to clearly document and implement processes that define individuals access to personal data:

Each controller and, where applicable, the controller’s representative, shall maintain a record of processing activities under its responsibility…[including] the categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries or international organisations;

To summarise, therefore, by piggybacking upon the very robust security model contained within CRM/D365E, Field Level Security can very quickly be implemented to ensure that users of the system only see the information that is relevant to them as part of their role, without disrupting the entire end-user experience in the process.

With this in mind, let’s take a look at how straightforward it is to begin working with Field Security, by following the steps outlined below:

  1. Identify the field(s) that need to be secured from being accessed by a specific group of users. Navigate to the field(s) properties and verify that the Field Security option has been set to Enable. For this example, we are going to use the Primary Contact field on the Account entity:
  2. Within the Customizations area of the application, select the Field Security Profiles option on the left-hand bar and then click on New to create a Field Security Profile:
  3. On the New Field Security Profile window, specify a name and an (optional) description value for the new profile and press the Save button:
  4. Once saved, you can then begin to configure the two most important aspects of the profile – the permissions that are granted to secured fields and the Users/Teams in the application that they apply to. In this example, we are going to restrict the Primary Contact field from step 1) so that users who are part of our Account Executive team role cannot view, update or create a record with a value in this field. To begin with, click on the Teams button and then click on Add to find and select the Account Executive team role:
  5. Next, click on the Field Permissions icon and double-click the Primary Contact field on the list. Verify that the Allow ReadAllow Update and Allow Create options are set to No:

Now, when we log into the application as a user who is a part of the Account Executive role and navigate to a sample record on the system, we can see that the field in question has been obfuscated. We have no way of seeing, changing or otherwise interacting with the value contained within this field:

Fields that are impacted in some way as a result of Field Security can always be clearly distinguished by the key icon on the top left of the field name. This can prove useful in helping users to understand their current levels of access and in troubleshooting why a user cannot read or modify a particular field.

So what have we learned about Field Security Profiles and how they conform to GDPR? Here’s a quick summary of the key points:

  • Demonstrates that sensitive data information is stored with “appropriate security” in place (Article 5)
  • They can be used as a tool for storing and controlling access to sensitive data types (Article 9)
  • Provides a mechanism to demonstrate compliance with the relevant articles of GDPR, should the organisation be subject to an Audit as a Data Processor (Article 28)
  • Can be seen as an appropriate technical safeguard in the protection of both non-sensitive and sensitive data types (Article 32)
  • Could be used as documentary evidence (or the basis thereof) that covers the documentation requirements for data processing (Article 30)

Thanks for reading! As part of next’s week post, we will take a deeper dive into CRM/D365E’s wider security model and the importance of documentation in the context of GDPR.

Monday may not have been my day of choice for attending an all-day session on the General Data Protection Regulation (GDPR), but it was something that I walked away from feeling more well-informed on:

If you currently work within the IT industry, then I would be very surprised if you have not yet come across GDPR or are already in the process of assessing what your organisation needs to do to prepare for it. In a nutshell, GDPR replaces existing data protection legislation within EU countries on May 25th 2018 (for the UK, this will be the Data Protection Act 1998). GDPR brings data protection guidelines firmly into the 21st century and provides a framework for organisations to apply the appropriate steps to protect individuals data. Whilst there is much within the updated guidelines that remain unchanged, there is additional emphasis towards organisations implementing the appropriate levels of security (both physical and technical), applying regular auditing processes and documentation of processes to protect against a possible data breach. For an IT professional, one of the overriding questions you should be starting to ask yourself is “What can I do to make the systems I support/implement compatible with GDPR?

Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E) is one system that is likely to be in place within businesses/organisations across the EU, and one that is arguably best placed to help meet the challenges that GDPR brings to the table. The wide berth of functionality within the application can be picked up and adapted to suit the following requirements:

  • Provide backend database encryption, to protect your key customer data in the event of a data breach.
  • Ensure that highly sensitive data categories are only accessed by relevant personnel within your organisation.
  • Enables you to implement a clear and comprehensive security model within your system, that can then clearly documented.
  • Helps you to implement a data retention policy that is line with contractual and statutory requirements.
  • Allow you to quickly and effectively respond to subject access requests, via the use of easy to generate document templates.

All of the above can be achieved using out of the box functionality within the application and, in some cases, can be more straightforwardly than you may assume.

As part of this and the next couple of week’s blog posts, I will take a look at each of the bullet points above, step by step. The aim of this is to highlight the specific elements within GDPR that each potential situation covers, how to go about implementing a solution within CRM/D365E to address each one and to provide other thoughts/considerations to better prepare yourself for GDPR. By doing so, I hope to make you aware of functionality within the application that hitherto you may never have looked at before and to explore specific use cases that provide a wider business relevance.

All posts in the series will make frequent reference to the text contained within Regulation (EU) 2016/679, available online as part of the Official Journal of the European Union – a particularly onerous and long-winded document. If you are based in the UK, you may find solace instead by reading through the ICO’s rather excellent Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be garnered.

Without further ado, let’s jump into the focus for this weeks post: Understanding and effectively utilising Transparent Database Encryption (TDE) within your CRM/D365E deployment.

One area within GDPR that has changed significantly is data breaches and penalties for organisations that have demonstrated a clear dereliction of their responsibilities. When assessing whether a fine is issued by your countries appropriate authority, which could number in the millions of £’s or more, a determination is made whether the company has implemented sufficient technical controls to mitigate the potential impact of a data breach. Article 32 sets this out in broad terms:

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the [Data] controller and the [Data] processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
(a) the pseudonymisation and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
(c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
(d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

It is worth noting that an assessment will be made of your businesses size, turnover etc. when a judgement is made on what “appropriate” steps your organisation has taken to mitigate their risk in this regard. Smaller businesses can, therefore, breathe a sigh of relief in not having to implement large scale and costly technical solutions within their businesses. Speaking more generally though, the importance of encryption within your organisation’s database and application systems becomes a primary concern in demonstrating GDPR compliance. It could also help you when it comes to determining whether you need to report a Data Breach, as an encrypted piece of hardware does not necessarily expose personal data; arguably meaning that no data breach has occurred.

CRM/D365E gives us the option to utilise a well-established feature within SQL Server to implement encryption for our data – Transparent Database Encryption (or TDE). Even better, it’s enabled by default. That being said, it is prudent for you to take a copy of the default encryption key or change it entirely if you haven’t done so already.

Doing either of the above is relatively straightforward. Navigate to Settings -> Data Management within the application and then click on the Data Encryption icon:

The Data Encryption pop-up window will appear, as indicated below:

From here you have two options at your disposal:

  • Use the Show Encryption Key to allow you to copy and paste the key to your location of choice. Note that as outlined by Microsoft, the key may contain Unicode characters, leading to a potential a loss of data when using applications such as Notepad.
  • Generate a new key that meets the requirements set out above and then click on Change.

In both cases, ensure that the encryption key is stored securely and segregated as far away as possible from your CRM/D365E deployment. Keep in mind as well that there are specific privileges that control if a user can access the above or even modify the encryption key in the first place. These privileges can be found on the Core Records tab within a Security Role page:

It may be tempting, knowing that encryption is enabled by default, to put your feet up and not worry about it. Here’s why it’s important to securely hold/segregate your database encryption key and also to think carefully about which users in your organisation have full Administrative privileges on the application:

Let’s assume the following scenario: your on-premise CRM 2016 organisation has database encryption enabled and SQL Server is installed on the same machine, along with all database files. The database encryption key is saved within a .txt file on the same computer.

A rogue member of staff with full Administrative privileges on CRM or an attacker manages to gain access to this server, in the process taking your CRM organisations .mdf database file. They also manage to either take a copy of the .txt file containing the encryption key or the currently configured encryption key by accessing your CRM instance. This person now has the ability to both mount and access the database file without issue. Under GDPR, this would constitute a data breach, requiring your business to do the following as immediate steps:

  • Notify the supervisory body within your country within 72 hours of the breach occurring (Article 33)
  • Notify every person whose personal data was stored in the database that a breach has occurred (Article 34)
  • Record the nature of the breach, the actual effect caused by it and all remedial steps taken to prevent the occurrence of a breach again in the future. All of this may be required by the supervisory body at any time (Article 35)

The fun does not stop there: depending on what processes your business had in place and, given the specific nature of the scenario, a fine may be more than likely. This is due to the clear steps that could have been taken to prevent the database from being so easily accessible. Having to explain this in front of senior executives of a business is not a prospect that any of us would particularly relish and could have been avoided had the following steps being implemented:

  • The rogue member of staff had been given a much more restrictive security role, that did not grant the Manage Data Encryption key – Read privilege.
  • The SQL Server instance had been installed on a different server.
  • The database encryption key had been saved on a different server
  • The database encryption key had been saved in a password protected/encrypted file.

This list is by no means exhaustive, and there is ultimately no silver bullet when it comes to situations like this; however, you can manage your risk much more effectively and demonstrate to authorities like the ICO that you have taken reasonable steps by taking some of the appropriate steps highlighted above.

In next week’s post, we will take a look at the importance of Field Security Profiles and how they can be utilised to satisfy several of the key requirements of GDPR in a pinch!