How to implement privacy by design for GDPR Part 3.

Privacy by design will be one of the framework for GDPR going into the future. This will impact on how software is built and deployed for decades to come.

The principles of Privacy by Design should be at the very core of your system.

As mentioned previously, as part of your due diligence you will be required to verify that your vendors are compliant with the principles of GDPR. For software companies, it will mean that they have incorporated

Copyright: vska / 123RF Stock Photo
© profile_vska’>vska

the principles of “Privacy by Design” within the core of their programming. The flip side of this will affect the process of software procurement. In our first article, we went through the exercise of taking stock of the different packages that are deployed throughout your company. Now factor in the amount of data that is entered multiple times across different systems from CRM systems, to accounts, to deliveries etc. and not only is this time intensive, but it greatly increases the prospect of data entry errors. One of the requirements of due diligence under GDPR is the accuracy of information at all points of the life cycle of the organisation. In that context, this may be an opportunity to review what you have an opportunity to upgrade your software solutions to a multi-relational database ERP system.

Controlling client data conveniently

We have written previous articles on the benefits of Enterprise Resource Planning, but in the context of GDPR, there is a case for a complete package that can manage client data at all the touch points in the organisation. Not only does it mean one point of capture for information, but the purpose (as defined by the data controller) can easily be defined, traced and managed if it’s all in one place. The same information can be used for multiple tasks – sales, accounts, deliveries – and staff could only see what they entitled to organised by distinct user profiles. When a GDPR “request to be forgotten” comes through, instead of checking several different packages, as well as paper archives, you run a “wizard” in an ERP system and you can instantly “hide” or make inaccessible that data element or set. You can also run an audit trail to prove that you met the request, at a specified date and time and who carried out the task. With multiple software packages that task becomes that much more difficult. Even paper files can be scanned into an ERP system for ease of access and if you still need to do calculations in Excel, that can be live within the system and managed accordingly (see related article).

Example of using Mamut software.

The one we use internally is Mamut, which is the most cost effective solution on the market for the level of functionality it provides. It is a close cousin of the major player SAP and we are developing processes that allow our clients to manage their profiles via an on-line portal so they can enter their own details, make corrections and apply for a GDPR deletion in one place. That means that consent is easy obtain as our clients are asked to tick the T&Cs while they feel engaged with the process, but at the same time does it is not adding to our administrative burden. Ultimately the purpose of GDPR is to encourage organisations to become more efficient and it helps having the right tools.

Comprehensive and effective software

I believe the type of software provided by an organisation will govern the principle of “Privacy of Design”. As GDPR is global in scope, I would suggest an overarching software would be the best way forward, not only for compliance, but also for the opportunities it will provide to think about the organisation in its entirety and to seek a holistic approach to dealing with data life cycles in each of our organisations.

 

For more information see our services and FAQ pages.

GDPR Seminar at the Doyle Club 1st of February
What is Privacy by design for GDPR? Part 2