I don’t typically stray too far from Microsoft technology areas as part of this blog, but having experienced this particular issue at the coalface and, being acutely aware of the popularity of the WordPress platform for many bloggers, I thought I’d do a specific post to help spread awareness. For those who are in a hurry…

TL;DR VERSION: IF YOU ARE USING THE WP GDPR COMPLIANCE PLUGIN ON YOUR WORDPRESS WEBSITE, UPDATE IT ASAP AND CHECK YOUR WORDPRESS INSTANCE FOR ANY NEW/SUSPICIOUS USER ACCOUNTS; IF EXISTING, THEN YOUR WEBSITE HAS BEEN HACKED. IMMEDIATELY TAKE YOUR SITE OFFLINE AND RESTORE FROM BACKUP, REMOVING AND THEN REINSTALLING THE ABOVE PLUGIN MANUALLY.

When it comes to using WordPress as your blogging platform of choice, the journey from conception to fully working blog can be relatively smooth. The ease of this journey is due, in no small part, to the vast variety of custom extensions – Plugins – available to end-users. These can help to overcome common requirements, such as adding Header/Footer scripts to your website, integrating your website with tools such as Google reCAPTCHA and even to allow you to transform WordPress into a fully-featured e-commerce site. The high degree of personal autonomy this can place in your hands when building out your web presence is truly staggering, and there is no fault on the part of the WordPress project for its regular performance, feature and security release cycles. All of this has meant that the product has grown in popularity and adoption over time.

Regrettably, the applications greatest strength is also its critical weakness point. WordPress is by far the most highly targeted application on the web today by hackers or malicious users. The latest CVE database result for the Content Management System (CMS) proves this point rather definitively but does not explain one of the most common reasons why WordPress is such a major target – namely, that most WordPress deployments are not subject to regular patching cycles. Plugins are by and large more susceptible to this, and any organisation which does not implement a monthly patching cycle for their WordPress site is significantly heightening their risk of being attacked. Even with all of this in place, you are not immune, as what follows demonstrates rather clearly:

On the 6th of November, a plugin designed to assist administrators in meeting their requirements under GDPR vanished from the WordPress Plugin store due to a “security flaw”. The developers deserve full credit and recognition here – within a small space of time, they had released a new version of the plugin with the flaw addressed – but hackers were quick on the ball with this particular vulnerability. On the afternoon of Thursday 8th November, I was alerted to the following actions which were carried out on numerous WordPress websites that I have responsibility for looking after:

  • The WordPress site setting Anyone can register setting was forcibly enabled, having been disabled previously.
  • Administrator became the default role for all new user accounts, having been set to Subscriber previously.
  • Next, a new user account – with a name matching or similar to “trollherten” – was created, containing full administrator privileges. Depending on your WordPress site configuration, an email was then sent to an email address, exposing the full details of your website URL and giving the attacker the ability to login into your site.

From this point forward, the attacker has the keys to the kingdom and can do anything they want on your WordPress website – including, but not limited to, blocking access for other users, installing malicious codes/themes or accessing/downloading the entire contents of the site. The success of the attack lies in its rapid targeting, given the very brief window between the disclosure of the plugin flaw and the timing of the attack, and the relative straightforwardness of automating all of the required steps outlined above. For those who are interested in finding out more about the technical details of the attack, then WordFence has published a great article that goes into further detail on this subject.

So what should I do if my WordPress site is using this plugin or there is evidence of a hacking attempt?

Here is my suggested action list, in priority order, for immediate action:

  • Take your website offline, either by switching off your web server or, if you are using Azure App Service, you have some nifty options at your disposal to restrict access to your site to trusted hosts only.
  • Restore your website from the last, good backup.
  • Update the WP GDPR Compliance plugin to the latest version.
  • As a precaution, change the credentials for all of the following on the website:
    • User Accounts
    • Web Server FTP
    • Any linked/related service to your site that stores privileged information, such as a password, authorisation key etc.
  • Review the following points and put in the appropriate controls, where necessary, to mitigate the risk of a future attack:
    • Patching Cycle for WordPress, Plugins & Themes: You should ideally be carrying out regular patching of all of these components, at least once per month. There are also plugins available that can email you when a new update is available which, in this particular scenario, would have helped to more speedily identify the faulty plugin.
    • Document your Plugins/Themes: You should have a full list of all plugins deployed on your WordPress website(s) stored somewhere, which then forms the basis of regular reviews. Any plugin that has a published vulnerability that has not been addressed by the developer should be removed from your website immediately.
    • Restrict access to the WordPress Admin Centre: .htaccess rules for Apache or web.config changes for IIS can restrict specific URLs on a site to an approved list of hosts. This way, you can ensure that even if an exploit like the one described in this post takes place, the attacker will be restricted when trying to login into your WordPress backend.
    • Review Backup Schedule: Typically, I’ve found that incidents like this can immediately demonstrate flaws in any backup procedure that is in place for a website – either in not being regular enough or, in the worst case, not taking place at all. You should ideally be performing daily backups of your WordPress website(s). Again, Azure makes this particularly easy to implement, but you can also take advantage of services such as VaultPress, which take all the hassle out of this for a small monthly price.

Conclusions or Wot I Think

Attacks of the nature described in this post are an unfortunate byproduct of the internet age and, regrettably, some of the evidence relating to this particular attack does, unfortunately, show that individuals and small businesses are the unfortunate casualties in today’s virtual conflicts on the world stage. Constant vigilance is the only best defence that you can have, more so given the speedy exploitation of this particular flaw. And, there has to be a frank admission that attacks like this are not 100% preventable; all necessary attention, therefore, should be drawn towards risk reduction, with the ultimate aim being to put in place as many steps possible to avoid an obvious target from being painted on your back. I hope that this post has been useful in making you are aware of this issue (if you weren’t already) and in offering some practical tips on how to resolve.

This week’s blog post is sponsored by ActiveCrypt Software.

Encryption appears to be a topic of near constant discussion at the moment, spearheaded primarily by the impending deadline of the General Data Protection Regulations (GDPR). These are, in essence, a new set of data protection rules that will apply to all organisations operating within the European Economic Area (EEA). A key aspect of them concerns implementing appropriate technical controls over sensitive data categories, to mitigate against any damage resulting from a data breach. Now, the key thing to highlight around this is the “proportionality” aspect; i.e. any technical controls implemented should be reasonably expected, based on the size of the organisation in question and the nature of their data processing/controlling activity. You should, therefore, be carefully evaluating your organisation to identify whether the lack of encryption could result in damage to a data subject.

I’ve had a look previously at database encryption in the context of Dynamics 365 Customer Engagement. What is nice about the application, and nearly all of Microsoft’s Software as a Service (SaaS) products at the moment, is that GDPR is very much at the centre of each individual offering. I have been genuinely impressed to see the level of effort Microsoft has been devoting to GDPR and in ensuring their SaaS product lines are compliant with the regulations – often without the need for charging customers an arm and a leg in the process. The same can perhaps not be said for any on-premise equivalent of a particular SaaS product. This is, to be fair, expected – Microsoft has been incredibly vocal about adopting a “cloud first” strategy in all things. But for organisations who do find themselves having to support on-premise applications or database systems, the journey towards implementing the required technical solutions for encryption could be rocky.

Case in point – SQL Server has long provided the capability to implement Transparent Database Encryption (TDE), which satisfies the requirement for at rest encryption without the need to redevelop applications from the ground up. Setting up Transparent Database Encryption can be an onerous process (more on this in a second), and requires the involvement of manual scripting. The following script outlines all the steps involved:

--First, a Master Key should be created on the Server instance

USE master;  
GO  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'mymasterkey';  
GO

--Next, a Certificate for the Server should be created.

CREATE CERTIFICATE MyCert WITH SUBJECT = 'DEK Certificate for testing purposes';  
GO

--This then allows for a Database Encryption Key to be created for encrypting a database. This needs to be created for
--EVERY database that requires encryption

USE EncryptionTest;  
GO  
CREATE DATABASE ENCRYPTION KEY  
WITH ALGORITHM = AES_256  
ENCRYPTION BY SERVER CERTIFICATE MyCert;  
GO  

--Once created, Encryption can then be enabled/disabled using the snippets below

ALTER DATABASE MyTestDatabase 
SET ENCRYPTION ON;  
GO

ALTER DATABASE MyTestDatabase 
SET ENCRYPTION OFF;
GO

--The Server Certificate should be backed up for disaster recovery scenarios or to enable databases to be restored to
--other SQL Server instances. First, backup the certificate with an encrypted private key...

USE master;
GO
BACKUP CERTIFICATE MyCert TO FILE = 'C:\MyCert.cer'  
    WITH PRIVATE KEY ( FILE = 'C:\MyCert.pvk',
    ENCRYPTION BY PASSWORD = 'mypassword');
GO  

--Once saved, execute the following code on the target instance to restore the certificate...

CREATE CERTIFICATE MyCert FROM FILE ='C:\MyCert.cer'
	WITH PRIVATE KEY(FILE='C:\MyCert.pvk', DECRYPTION BY PASSWORD='mypassword');

Whilst TDE is a neat solution, it does have some issues:

  • It’s important to keep in mind any potential disaster recovery scenario, when working with TDE, by backing up the server certificate to a separate physical location. The above script provides the necessary snippet to accomplish this, so it is imperative that this is done for every certificate you plan to work with.
  • All required configuration steps have to be accomplished via scripting and the feature is not enabled by default, unlike Azure SQL Databases. Depending on your level of expertise when working with SQL Server, you may have to leverage assistance from other sources to get up and running with the feature.
  • Perhaps the biggest barrier to adopting TDE is the version restrictions. It is only made available as part of the Developer and Enterprise editions of SQL Server. As the name suggests, the Developer edition is licensed strictly for non-Production environments and the Enterprise edition has a staggering cost, licensed based on the number of cores the target server is running. To put this into better context, I was recently quoted a whopping £68,000 through Microsoft Volume Licensing! For most organisations, this can result in an incredibly high cost of ownership just to satisfy a single requirement.

Fortunately, for those who are wanting to implement database encryption via an accessible interface, there are a number of products available on the market to assist. The best one I have come across is DbDefence from ActiveCrypt, which offers a simple to use and efficient means of configuring encryption for your databases. In fact, depending on your database size, you can more than likely have your databases encrypted in less than 5 minutes 🙂 Let’s take a closer look at how straightforward the software is to use by encrypting a database from scratch:

  1. After downloading the installation package, you will need to run it on the server where your SQL Server instance resides. During the installation process, the Full installation option can be selected and you will also need to specify the SQL Server instance that you wish to utilise with the software:

  1. After the installation completes successfully, launch the application and then connect to your target SQL Server instance. Next, select the database that you want to encrypt. You should see a window similar to the below if done correctly:
  2. At this point, you could choose to accept the default Encryption and Protection options and proceed to the next step. However, I would recommend changing the options as follows:
    • Modify the AES Encryption Options value to 256-bit. Whilst the risk of a successful brute force between 128 and 256 bit is effectively zero, 256 still supports longer keys and is, therefore, more secure.
    • In most cases, you just need to ensure data is encrypted at rest and not provide any additional access restrictions beyond this. In these situations, I would recommend setting the required level of protection to Only Encryption. Maximum Transparency. This negates the need for any additional configuration after encryption to ensure your client applications still work successfully.

  1. To encrypt the database, a password/key is required. You should always ensure you utilise a random, sequential password that contains upper/lower case letters, numbers and symbols. I would also recommend having a seperate password for each database you encrypt and to ensure that these are all stored seperately (as they may be required to decrypt the databases at a later date). The length of the password to use will depend on the AES encryption mode, but if you are using 256 bit, then an 18 character password is recommended.
  2. When you are ready to start the encryption process, press the Encrypt button and confirm the warning box that appears:

Give it a few minutes and you will then be able to see in the main window that your database has been encrypted successfully:

If you ever have the requirement to decrypt the database, then you can return to the application at any time, connect up to the database, enter the password and then press Decrypt:

  1. As a final step, you can then test that your database files have been encrypted successfully by attempting to mount the encrypted database files onto a seperate SQL Server instance. You should get an error message similar to the below, indicating that your database has been encrypted successfully:

Conclusions or Wot I Think

The world of encryption can be a veritable nightmare to those approaching for the first time, and GDPR can be blamed – but also, I would argue, welcomed – in raising the profile of the topic recently. As with a lot of things concerning GDPR, there is a real opportunity for organisations to get a handle on the personal data they work with every day and to implement the required processes and systems to ensure the right thing is being done when handling sensitive data. Database encryption is one weapon in your arsenel when it comes to satisfying a number of areas within GDPR; but, as we have seen, the total cost of ownership and technical expertise required to implement such a solution could – regrettably – force many to simply look the other way when it comes to securing their databases. DbDefence assists greatly in both these regards – by significantly reducing cost and providing a simplified, easy to use interface, to deploy database encryption within minutes. What’s great as well is that, as part of evaluating the software, I found the support team at ActiveCrypt incredibly reactive and helpful in dealing with the queries I had around the product. If you are looking for a cheaper, yet wholly effective, solution to implement database encryption for SQL Server, then I would not hesitate to recommend the DbDefence product.

I took some time out this week to head down to Microsoft’s Reading offices for the November CRMUG meeting. There is often a whole host of reasons that can be conjured up to excuse yourself from events like this – “I’m too busy at work!”, “It’s such a long way away!” etc. – but, ultimately, it’s always best to make the effort and get involved. The theme of the day was around Awareness of your CRM system, which was neatly kicked off by a short presentation from Microsoft on the current roadmap for Dynamics 365 for Customer Engagement (D365CE). There was a clear emphasis towards GDPR on some of the available presentation tracks, a topic that regular readers of the blog should be well prepared for I hope. 🙂 Another key aspect of the day was networking, with ample opportunities to meet new people and to understand their current journey involving CRM/D365CE. Here are my thoughts on the sessions I attended, along with some closing remarks on why these types of events are always beneficial.

Accelerate GDPR with Microsoft Cloud

The first talk I attended was all about GDPR from Microsoft’s perspective. The session was co-led by David Hirst and David Reid from Microsoft and did a really good job in setting out the GDPR stall for the uninitiated, as well as offering some pointers towards Microsoft solutions/technologies that may prove beneficial towards achieving compliance. There were also some fascinating anecdotal pieces, such as, for example, the story of a UK based pub chain who has decided to completely remove all customer email address data from their systems, presumably with GDPR in mind. An extreme, but arguably pragmatic, approach.

The talk came across as refreshingly candid, with a real demonstrable attempt of portraying a concerted effort behind the scenes at Microsoft to ensure that they – and their entire product range – are prepared for GDPR. Microsoft is not just talking the talk when it comes to GDPR (which, to be frank, can often result in a lot of scaremongering by other companies), but are instead providing current and new customers with the tools and information they need to streamline their route towards compliance. The key takeaway from the session, which was borne out by some of the Q&A’s at the end, is that it’s naive to assume that technology companies like Microsoft can provide a “silver bullet” solution to deal with all of your GDPR woes. Organisations need to go away and do a lot of the hard work when it comes to determining the type of data they hold across the entire organisation, whether the source of consent for this could be considered risky and to implement the appropriate business processes and technological helper tools to make dealing with things such as subject access requests as simple as possible.

What is GDPR and how it impacts your business and your Dynamics 365 solutions, Get Ready for your new legal obligations.

The next talk was (again!) on GDPR and was presented by CRM MVP, Mohamed Mostafa, and was specifically focused on GDPR in the context of D365CE. Mohamed’s talk was very focused, assisted by some great visual aids, and he also presented some interesting examples on how you can leverage existing application features to help you towards GDPR compliance. Plenty of food for thought!

One area mentioned by Mohamed in his presentation which I perhaps disagree with him on (sorry!) is the emphasis placed on the massive fine figures that are often quoted when it comes to GDPR. A heavy focus towards this does, in my view, present a degree of scaremongering. This is confirmed by the fact that Elizabeth Denham, the Information Commissioner, has gone public herself on the whole issue and cautions businesses to be wary of the “massive fines” narrative. I agree with her assessment, and that fines should always be considered a “last resort” in targeting organisations that have demonstrated a willful disregard for their obligations in handling personal data. My experience with the ICO on a personal level backs this up, and I have always found them to be fair and proportional when dealing with organisations who are trying to do the best they can. GDPR presents a real opportunity for organisations to get to grips with how they handle their personal data, and I encourage everyone to embrace it and to make the necessary changes to accommodate. But, by the same token, organisations should not be panic-stricken into a narrative that causes them to adopt unnecessary technologies under the whole “silver bullet” pretence.

What’s new in Dynamics 365 9.0

To date, I have not had much of a chance to play around in detail with version 9.0 of D365CE. For this reason, MVP Sarah Critchley’s talk ranked highly on the agenda for me. Sarah’s enthusiasm for the application is infectious, and she covered a wide breadth of the more significant new features that can be found in the new version of the application, including (but not limited to):

  • Presentation changes to the Sitemap
  • Introduction to Virtual Entities and how to set them up
  • Changes to the mobile application

Sarah framed all of the changes with a before/after comparison to version 8.2 of the application, thereby allowing the audience to contextualise the changes a lot better. The best thing that I liked about the whole presentation is that it scratched beneath the surface to highlight less noticeable changes that may have a huge impact for end-users of the application. Attention was paid to the fact that the web application refresh is now a fully mobile responsive template, meaning that it adjusts automatically to suit a mobile or tablet device screen size. Another thing which I didn’t know about the new Virtual Entities feature is that they can be used as Lookup fields on related entities. This immediately expands their versatility, and I am looking forward to seeing how the feature develops in the future.

Implementing a Continuous Integration Strategy with Dynamics 365

I’ll admit that I went into the final talk of the day with Ben Walker not 100% sure what to expect, but walked away satisfied that it was perhaps the most underrated session of the day 🙂 Ben took us through his journey of implementing a continuous integration strategy (translation: testing through the development process and automating the deployment process) for CRM 2015 in his current role, and he should be proud of what he has achieved in this respect. Ben showed the room a number of incredibly useful developer tidbits, such as:

  • The ability to export CRM/D365CE solution information into Visual Studio and then sync up to a Git repository.
  • Deep integrating of unit testing, via the FakeXrmEasy framework.
  • The ability to trigger automated builds in TFS after a code check-in, which can then be used to push out solution updates into a dev/test environment automatically. With the additional option of allowing somebody else to approve the deployment before it starts.

All of the above Ben has been able to build together as an end to end process which looks almost effortless in its construction. The benefit – and main caveat from the whole session, it has to be said – is that Ben is primarily working within an on-premise CRM environment and is using tools which may not be fully supported with online versions of the application. For example, the ability to deploy Solution updates via PowerShell is definitely not supported by D365CE online. Despite this, Ben’s presentation should have left everyone in the room with enough things to go away with, research and implement to make their CRM/D365CE development more of a breeze in future.

Conclusions or Wot I Think

This was my first time attending a CRMUG meeting, and I am glad that I finally found the time to do so. As Sarah highlighted at the start of the day, the key benefit of the whole event is the opportunity to network, and I had ample opportunity to meet face-to-face some of my CRM heroes, as well as others working in the industry. It can often feel like a lonely journey working with applications like CRM/D365CE, particularly if you are working as part of a small team within your business. Events such as these very much bring you together with other like-minded individuals, who will happily talk to you non-stop about their passion for the application and technology. And, because the events are closely supported by Microsoft, it means that Tuesday’s meeting allowed for lots of authoritative information to come to fore throughout the entire day. I am very much looking forward to attending my next CRMUG meeting in the future and would urge anyone with at least a passing interest in the world of CRM/D365CE to consider attending their next local meeting.

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