IMPLEMENTING & DOCUMENTING A SECURITY MODEL FOR DYNAMICS CRM (GDPR)
I am a Microsoft Dynamics Certified Solutions Expert. and writting these considerations for everyone to review their planning of GDPR so in writting these does not mean l am a GDPR Expert or a GDPR Officer these posts are designed to help you look at your considerations carefully when preparing for GDPR.
In This article l take a closer look at the practical implications the General Data Protection Regulation (GDPR) has upon organisations/businesses in Europe and Businesses/Organisations holding Data belonging to European residents and some of the ways Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E) can assist you as part of the transition.
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 l discuss in most of my GDPR posts will make some references 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. For those that are based in the UK, you may find solace instead by reading through the streamlined ICO’s rather excellent Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be cleared defined.
The critical points of the regulation which we need addressing, is 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 of article 24 intergrates in with key requirements for having clearly auditable and documented processes under GDPR.
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 foundation towards this.
The need for clear documentation under GDPR is emphasised further over multiple articles in the Regulation therefore these are key areas your business or organisation will need to keep in mind:
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 reasonable safeguards” must be clearly documented (Article 30 & 49).
All data breaches must be clearly documented (Article 33).
To simplify this, 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.
Having looked at the above lets explore the four key concepts of CRM/D365E security model 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 Consideration
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 Considerations
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 if you have a global seating. 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 a long subject to discuss or write about, so I would strongly recommend reading up on the topic separately to gain a broader understanding of what they are and what they do.
Key GDPR Considerations
Business Units provide an effective means of satisfying Article 5’s requirements for data protection “by design and by default”.
Always keep in mind 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 (I will cover more on this on the section below on Security roles).
Each Business Unit will also have a corresponding Team created for it by design. Theis capability can be utilised to segregate out security permissions in a more centralised/Global manner.
Security Roles
The most important area of security roles surrounding within your CRM/D365E instance and the “cornerstone” that holds all other dependencies together, Security Roles define the permissions for every feature and entity within the application, giving you the opportunity to fine tune and define access privileges on a clearly regulated 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 Write.) 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 Considerations
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/Updates of the CRM/D365E application which are released twice each year,(online instances online) generally introduce new functionality and – as a result – new permissions are required to successfully utilise them.
As best practice you should be updating your application in line with Microsoft's recommended approach as these bring further opportunities to review your existing security roles model and to verify that they are current and do not contain incorrect privileges which can expose data integrity.
In This article l take a closer look at the practical implications the General Data Protection Regulation (GDPR) has upon organisations/businesses in Europe and Businesses/Organisations holding Data belonging to European residents and some of the ways Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E) can assist you as part of the transition.
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 l discuss in most of my GDPR posts will make some references 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. For those that are based in the UK, you may find solace instead by reading through the streamlined ICO’s rather excellent Overview of the General Data Protection Regulation (GDPR) pages, where further clarification on key aspects of the regulation can be cleared defined.
The critical points of the regulation which we need addressing, is 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 of article 24 intergrates in with key requirements for having clearly auditable and documented processes under GDPR.
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 foundation towards this.
The need for clear documentation under GDPR is emphasised further over multiple articles in the Regulation therefore these are key areas your business or organisation will need to keep in mind:
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 reasonable safeguards” must be clearly documented (Article 30 & 49).
All data breaches must be clearly documented (Article 33).
To simplify this, 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.
Having looked at the above lets explore the four key concepts of CRM/D365E security model 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 Consideration
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 Considerations
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 if you have a global seating. 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 a long subject to discuss or write about, so I would strongly recommend reading up on the topic separately to gain a broader understanding of what they are and what they do.
Key GDPR Considerations
Business Units provide an effective means of satisfying Article 5’s requirements for data protection “by design and by default”.
Always keep in mind 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 (I will cover more on this on the section below on Security roles).
Each Business Unit will also have a corresponding Team created for it by design. Theis capability can be utilised to segregate out security permissions in a more centralised/Global manner.
Security Roles
The most important area of security roles surrounding within your CRM/D365E instance and the “cornerstone” that holds all other dependencies together, Security Roles define the permissions for every feature and entity within the application, giving you the opportunity to fine tune and define access privileges on a clearly regulated 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 Write.) 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 Considerations
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/Updates of the CRM/D365E application which are released twice each year,(online instances online) generally introduce new functionality and – as a result – new permissions are required to successfully utilise them.
As best practice you should be updating your application in line with Microsoft's recommended approach as these bring further opportunities to review your existing security roles model and to verify that they are current and do not contain incorrect privileges which can expose data integrity.
Comments
Post a Comment