Microsoft Dynamics NAV and GDPR: what’s next?

The General Data Protection Regulation (GDPR) comes into force on May 25, 2018 and represents a significant overhaul of data protection legislation; the accountability principle will mean that businesses will need to examine how they hold and use data and take steps to demonstrate compliance with the data protection principles.

With the release of NAV 2018 Cumulative Update 3 last week, Microsoft has done a first step on making NAV GDPR compliant. This Cumulative Update adds Data Classification to your NAV tables and this is the NAV version you need to deploy as soon as possible in order to be at least “level 0” GDPR compliant.

When installing NAV 2018 CU3 and open properties of a Table’s field, you can see the new DataClassification property:

NAVDataClassification_01.jpg

The DataClassification property can be set on table objects and field controls:

Classification Description Examples
CustomerContent Content directly provided/created by admins and users. This is the default when no value has been specified.
  • Customer generated BLOB or structured storage data
  • Customer-owned/provided secrets (passwords, certificates, encryption keys, storage keys)
EndUserIdentificationInformation (EUII) Data that identifies or could be used to identify the user of a Microsoft service. EUII does not contain Customer content.
  • User name or display name (DOMAIN\UserName)
  • User principle name (name@company.com)
  • User-specific IP address
AccountData Customer billing information and payment instrument information, including administrator contact information, such as tenant administrator’s name, address, or phone number.
  • Tenant administrator contact information (for example, tenant administrator’s name, address, e-mail address, phone number)
  • Customer’s provisioning information
EndUsePseudonymousIdentifiers (EUPI) An identifier created by Microsoft tied to the user of a Microsoft service. When EUPI is combined with other information, such as a mapping table, it identifies the end user. EUPI does not contain information uploaded or created by the customer (Customer content or EUII).
  • User GUIDs, PUIDs, or SIDs
  • Session IDs
OrganizationIdentifiableInformation (OII) Data that can be used to identify a tenant, generally config or usage data. This data is not linkable to a user and does not contain Customer content.
  • Tenant ID (non-GUID)
  • Domain name in e-mail address (xxx@contoso.com) or other tenant-specific domain information
SystemMetadata Data generated while running the service or program that is not linkable to a user or tenant.
  • Database table names, database column names, entity names
ToBeClassified Content that has not yet been given a classification. This is the initial value when table or field is created.
  • New tables or columns added by developers while developing extensions or customizations

Dynamics NAV operates with some standard rules for classification:

  • When you add a new field to a table, the field is assigned an initial value of ToBeClassified.
  • FlowField and FlowFilter fields are automatically set to the SystemMetadata data classification. This cannot be changed.
  • Existing tables and fields (except for FlowFields and FlowFilters) in an application that has been upgraded from a Dynamics NAV version without the DataClassification property, will automatically be assigned the CustomerContent classification.

When you upgrade an application from a Dynamics NAV version that does not contain the DataClassification property, existing tables and fields (except for FlowFields and FlowFilters) will automatically be assigned the CustomerContent classification. You can then access the DataClassification property on these tables and fields, and change the classification as needed. FlowFields and FlowFilters will be assigned the SystemMetadata classification automatically.

You can view the data classification of tables and fields in the Table Metadata Virtual table (ID 2000000136) and Field virtual table (ID 2000000041), respectively. You can also perform a bulk-insert of data classification by executing the Field Data Classification (page 1750).

You can bulk-edit classifications only for fields in CSIDE (the script does not update fields in extensions). To bulk-edit classifications, export the classifications to Excel from the NAV page and then re-import the updated file with the new Powershell package (provided in the DVD image of CU3):

Import-Module WindowsPowerShellScripts\DataClassification\DataClassification.psm1
Set-FieldDataClassificationFromExcelFile -ExcelFilePath <YourXLSXGeneratedFile> -SheetName 'Field Data Classification' -RTCFolder <FilePath> -DBName <YourAVDBName> -OutputFolder <OutputFolder>

where FilePath is the full path of the NAV client files (for example C:\Program Files\Microsoft Dynamics NAV\110\RoleTailored Client).

Microsoft is clear regarding the Data Classification topic for GDPR:

You should consider the data classification features offered in Dynamics NAV as the first layer of classification – done by developers (Dynamics NAV and partners) on customizations, add-ons, and extensions.

And what’s next?

Data Classification is in my opinion only the basic requirement in order to define your product to be totally GDPR-compliant. I don’t think this is enough, at least if you want to provide GDPR features to your customers. What we need right now in NAV?

One of the key aims of the GDPR is to empower individuals and give them control over their personal data. For having a good GDPR-compliance, we need to have features to satisfy at least these GDPR articles and topics:

  • Personal / sensitive data discovery
  • The right to be informed (Articles 12, 13, 14)
  • The right of access (Article 15)
  • The right to rectification (Article 16)
  • The right to erasure (Article 17)
  • The right to restrict processing (Articles 18, 19)
  • The right to data portability (Article 20)
  • Data encryption and destruction (automated)
  • GDPR activities logging

What to do in practice? What should the NAV Product Team do? These are my ideas:

  1. Data Classification (done)
  2. Providing GDPR-related entity management (like Data Protection Officer card, Administrators or other controllers identification).
  3. Providing a quick way to retrieve sensitive data in the entire database (for example, if your old contact asks you to retrieve all his sensitive data you have in your system, you need to have a quick way to retrieve them).
  4. Providing a quick way to rectify sensitive data (for example, change of a contact data: you need to change this data in the entire database and documents).
  5. Providing a quick and automated way to mask or delete sensitive data (if your old contact asks you to immediately delete all his sensitive data in your database, you need to remove them or cypher them).
  6. Provide a way to export all sensitive data of an individual in a standard format (CSV or XML) for data portability.
  7. Providing a centralized way where launching all these GDPR tasks, log them, log GDPR incoming requests and action performed on the database.

As you can imagine, there’s something to implement also as new NAV objects in order to obtain a good result (and a very GDPR compliant product).

We’ll have something similar before the May 25? Or we’ll have to develop all by ourself?

I’ve shared the requests/suggestions to the product team, now having a clear feedback could help everyone of us…

9 Comments

  1. Hi Stefano
    Microsoft has published a white paper that addresses most of your questions you ask here. White paper is located here:
    https://servicetrust.microsoft.com/ViewPage/TrustDocuments?command=Download&downloadType=Document&downloadId=cc632c1c-15b7-42d1-879f-487f9592ee53&docTab=6d000410-c9e9-11e7-9a91-892aae8839ad_FAQ_and_White_Papers

    Most of the answers you’ll find on pages 5-13 of the white paper, however here’s a short recap by your questions:
    1. Data classification that was published in March CUs is just the beginning. It is focused on developer/partner/ISV part of classification. There another classification (Data Sensitivity) coming in next CU that is focused on customer classification
    2. Although we don’t provide this, you can utilize customization capabilities to handle this.
    3. Read the Export Data Subject’s Personal Data section of the white paper
    4. Read the Modify Data Subject’s Personal Data section of the white paper
    5. Read the Delete Data Subject’s Personal Data section of the white paper
    6. Read the Export Data Subject’s Personal Data section of the white paper
    7. Read the Manage Data Subject Requests section of the white paper

    One additional thing I want to note though. Even though Dynamics NAV will help you with data privacy requirements of legislation such as GDPR, getting compliant with GDPR is not a check box exercise, nor is there a product that is GDPR compliant. GDPR compliance involves a lot more than modifications to any of your systems of record be it NAV or any other ERP/CRM solution.

    Regards
    Ivan

    Like

    1. Ivan, thanks for your feedback. I’ve downloaded the whitepaper the day you’ve released it and read it carefully. Thanks for providing that but in my opinion (as feedbacks I’ve previously shared with the Italian MS Team) the procedure you’ve described regarding Export Personal Data, Modify Personal Data, Delete Personal Data involves manual procedures for extracting data from NAV to something like Excel, modify the data and then updates NAV. I don’t think this is a way of work that can be useful.
      Imagine a scenario where I’ve create thousands orders and invoices and other documents related to a contact. How can I easily obtain these data and delete (or mask) sensitive data on these documents? It’s unbelievable to think that we have to export all the archives for searching these data.
      The implementation I was thinking is a procedure to automatically retrieve all NAV documents related to a physical subject and operate on this data accordingly to the GDPR action I’ll launch from NAV. NAV must also be able to log these actions. This procedure must be launched from an end-user directly from the NAV client.
      There are some partners that are working on this type of customizations (personally, I think that we’ll do these features by ourself if MS will not have plans on providing NAV features for that).
      My question is that: ok for data classification and data sensitivity (great!), but there are plans on providing end-user features for sensitive data manipulation in NAV (features on a menu in the NAV client) or not?

      Like

      1. Hi Stefano,
        As written in white paper, I’d keep a close eye on upcoming (April) cumulative update. We are aware that personal data does not solely reside in master data tables and that there are other related tables may contain the same. White paper also says that tooling will be provided for this, hence reason we mention rapid start packages in export section.
        The message from the white paper is that you should not wait with classifying the data either from ISV/developer/partner perspective nor from customer perspective. All enums for classifications are mentioned in the white paper.
        This means that once you prepare data classifications you’ll be set to go to do export, modify and delete requests. For modify and delete requests you need to keep in mind that there are different data archiving requirements in different countries that may “prevent” you from modifying or deleting documents or transaction even though they may contain personal data, as such actions might make you (company) incompliant to local audit and tax regulations. That’s why we’re taking risk-averse approach here.
        The tooling I’m talking about will be made available to administrators through IT Manager (and in SaaS Administrator of User, User roles and Permissions) role centers. Our assumption here is that in our market segment the person responsible for data privacy will be the administrator.
        I’ll ping you over email if you want to have short discussion about this as we’re very keep to get feedback.

        Liked by 1 person

      2. Feel free to ping me via email Ivan. I’m very interested to know you plans and yo provide feedbacks on this topic. Thanks a lot for these info.

        Like

  2. Thank you for the information! I have noticed when you add new field in new or existing table object, and set DataClassification property as CustomerContent,this field can not be find in Data Classification Worksheet and thus Data Sensitivity cannot be set..Do you know why and how to overcome this? Thanks in advance!

    Like

    1. Hi MilekMM

      Hope Steffano won’t mind me aswering this 🙂
      Once new fields are added (the old way, meaning not through the extension) you need to call SynchAllFields in Data Classification Management codeunit (CU 1750).
      Read more about this here:
      https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-classifying-data#data-classification-on-upgrade
      Latest cumulative update should have an action on Data classification worksheet that does that as well. I think it’s called sync fields or something similar.

      Liked by 1 person

  3. Hi Demiliani,

    My client has a requirement of changing Dataclassification property of fields with TobeClassified to CustomerContent.

    I have tried the above procedure to update DataClassification property. But few strange things I have noticed that is
    a) we are unable to change TobeClassified option to customer content , but we are able to change it to Accountdata.
    b)Also if DataClassification property is empty/Blank, we are able to update Customercontent.

    Please request you to suggest me on this.

    Thanks & Regards,
    Venu

    Like

Leave a reply to Ivan Koletic Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.