Where to process GDPR requests?

Most organisations have complicated architectures with personal data stored in multiple inter-connected systems. A typical organisation nowadays will have the following components in their architecture: an ERP application, a CRM system, one or more company websites, and a B.I. reporting system

An organisation will receive GDPR requests and those requests must be logged and processed. Examples of a GDPR request are: an access report of what information is stored for a particular individual; a request for deleting information for an old employee

Which application is best suited for processing the requests and is most centrally suited for data changes to be replicated to the other applications?  A decision must be made as to where in the architecture the central point for processing GDPR requests will be.  The most logical point for most companies will be the ERP application since it most often holds all Customer data, Sales order history, Vendor history and Purchase Order history.  An ERP system already has established interfaces for updating the other applications should data be deleted or changed as a result of a GDPR request

NAVGDPR offers a solution which takes NAV as the central point for processing GDPR requests. Requests can be managed and processed within NAV.  Data changes which result from GDPR requests (for example deleting a Customers’ name and address), should then flow to peripheral applications.  Alternatively our product comes with interfaces which can be used for exporting the information about GDPR requests from NAV

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

How to approach GDPR with an older version of Dynamics NAV?

On May 25, 2018, the General Data Protection Regulation (GDPR) will come into effect in the European Union. Despite the UK currently negotiating the details of Brexit, the government has confirmed that the rules of GDPR will still be fully enforced within the country

The new regulations signal a significant change in how data will be managed by companies.  NAV customers will be able to manage the GDPR regulations differently depending on what version of NAV they are using.

NAV 2018

Microsoft has promised that by May 2018, NAV 2018 will include a solution for GDPR.  The details of how the GDPR functionality will work are not yet clear but it is likely that the functions will work in combination with Microsoft’s cloud based solution, Azure. NAV 2018 may use Azure permissions to restrict access to data, and manage privileges in the cloud.  The details are yet to be finalised

Pre NAV 2018

However for any version of NAV before NAV 2018 (NAV 2017, NAV 2016, NAV 2013, NAV 2009, NAV 5.00, NAV 4.00 etc), Microsoft does not provide any solution. While some customers will see this as an incentive to upgrade to a new version of NAV, others will seek an alternative solution

The options for companies using older version of NAV are:

  • Consult your Microsoft partner for advice. Some partners will provide consultants to help you in the process of becoming GDPR compliant
  • Recruit a GDPR consultant from one of the consultancies which have been created as a result of the new regulations
  • Opt for the only one out-of-the-box solution for handling GDPR regulations created by NAVGDPR. Contact us for information about our affordable solution
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Delete or Encrypt?

GDPR regulations stipulate that data must be deleted as long its purpose of being stored has expired. However, there may be external reasons for accessing the data, which occasionally occur. These reasons mean that the data could be retained but encrypted

The encryption of data has the advantages:

  • data can’t be accessed by staff
  • it is reduces the company’s liability in case of a data breech
  • It allows the data to be decrypted and accessed if that need arises

An example of an external access reason is for auditing purposes – sometimes an auditor may want to trace where goods have been sold or purchased. An auditor may require this information up to 7 years after the sale or purchase

An example:

  • A retailer stores information about sales – which products were sold to which customers, along with the customers contact details. The customers’ information is stored for the following purposes: delivery of goods and for the returning of goods within the warranty period.  The longest period of time for the two purposes is for returning goods for warranty purposes. For this retailer, there is 12 month warranty period, therefore the customers’ data should be only stored for 12 months.  Now, the company has a responsibility to keep a record of the sales for up to 7 years for auditing purposes.  In this instance the company may encrypt the data after 1 year of storage. Then the data will be retained in an encrypted format for up to 7 years. The company can then delete the customers’ information 7 years after the sale or purchase
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

How long to retain data?

The GDPR regulations do not set out the minimum or maximum periods for storing data.  Each organisation has to determine the purpose of storing information and from there, determine how long they need the data for.  After time it is likely that benchmark periods per industry and data category will eventually be established

The GDPR regulations state that “personal data processed for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes”.  This means that organisations will have to review the data which they are keeping and determine how long to keep data depending on what the purpose of storing it is.  Personal data will need to be retained for different periods of time depending on its purpose. How long different categories of personal data are stored should be based on each business’s needs

The GDPR regulations put the onus on the individual organisation to determine the storage times. The overriding message is that personal data must be kept for as short a period as is necessary for storing it. This reduces the data privacy overheads for an organisation and reduces their liability in case of a data breech

The appropriate retention period is to depend on what the data is used for.  However the following factors are also relevant:

– what is the value of the data to the organisation now and in the future?

– what are the risks and liabilities associated with retaining the information?

– how easy is it to ensure the data remains accurate and up to date?

Information Uses:

The GDPR regulations state that “Personal data shall be obtained only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes.”

So while there is a valid reason to hold a person’s personal data, it is acceptable for an organisation to keep the data. However, when that purpose no longer exists, then the data cannot be held ‘just in case’ a need arises

Some examples:

  • A company manufactures parts for car parts. The company must know which customers have bought their parts in case safety issues arise with the parts, and a recall is necessary. In this case, car manufacturers may need to recall their parts for up to twenty years (the maximum duration a normal road vehicle is used for). Therefore, the details of the sales of these parts can be stored for up to this period
  • A company stores CCTV footage of the inside of their premises for the purposes of recording any accidents or criminal incidents. In this case, health and safety accidents are normally reported within in a few days and criminal incidents are often reported within a few weeks. It is therefore acceptable for the company to delete this information after one month
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

How to identify sensitive data in your database?

The definition of sensitive data under the GDPR regulations is “any information relating to an identified or identifiable natural person”

How can this information be determined within a NAV database? The answer is: with great difficulty. NAV stores data in a multitude of fields and tables. These tables are created by either Microsoft, your NAV partner, or your in-house development team for your own personalised Change Requests. The end result is that sensitive data is hidden in many tables and fields within your NAV database, and there is no function to find out which tables and fields they are

A trained NAV professional can find out where this data is, but it is a time consuming process.  For customers who have heavily modified NAV databases, this process will be especially time consuming. At NAVGDPR, we provide the know how and the tools to perform this search quickly and cheaply

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn