What FoxPro users need to know about GDPR
What is GDPR?
Unless you’ve been living under a rock for the last 12 months or so, it’s quite likely that you have heard the term GDPR bandied around a lot. In a nutshell, it’s the new European-wide regulation that comes into force on the 25th May 2018. It applies to all European citizens and applies globally if you deal with European citizens in any way. This means if you’re a US company with clients in Europe then yes, GDPR applies to you and you need to comply if you don’t want to lose lots of your European customers.
Why it matters
GDPR is being introduced to being our data and privacy protection laws up to date in the digital age. There have been too many stories in the media where companies lost their clients data through data breaches or were flagrantly misusing what they had collected. The new laws ensure greater parity across Europe and aim to set the standard for global security and privacy laws. The new regulations also have some big teeth to back it up. Companies found to be in breach could be hit with huge fines so non-compliance could be a costly exercise from both monetary and client trust angles.
Scaremongering and FUD
Much like the Year 2000 bug and the eponymous cookie law, there’s a lot of scaremongering going around from people looking to sell solutions to the GDPR “problem”. In reality GDPR, in essence, is just tightening up on our existing data protection laws and that is a good thing. We all want to know that our personal information isn’t being abused for nefarious purposes or will cause problems for us in the future. If you’re a responsible company who cares for your customers then GDPR is a good opportunity to show that they can trust and depend on you, which is good for business.
Don’t get me wrong, GDPR is a big deal but if you’re not selling people’s personal data and you take care of and don’t mistreat private data in any way then you don’t need to be too worried. But you do need to make sure that you’re putting the necessary systems and documentation in place, no matter the size of your enterprise.
There are plenty of other resources available so I’m not going to go into details here. For more information your initial go-to source should be the ICO themselves who have plenty of good information on what you need to do.
In brief though;
- Take necessary steps to protect personal and sensitive data (proven through documented processes)
- Don’t keep data any longer than you are required to
- Don’t keep data you don’t need to legitimately process
- Be able to provide the clients with all the data you hold about them on request
- Don’t do anything with the data that the user couldn’t predict or hasn’t consented to. For example, people signing up to a newsletter know that they will get emails from you, and that some of the emails may contain promotional material. But they can’t predict that you will upload those email addresses to Facebook in order to create a look-alike audience campaign to market to them via other mediums.
- Notify people if you become aware of a data breach
FoxPro and the GDPR
So, you’re likely reading this because you are responsible for a FoxPro application that’s running in your organisation. Unsurprisingly we’re being contacted by clients wondering if their Visual FoxPro systems are GDPR compliant and asking for necessary changes such as being able to effectively respond to SARs (Subject Access Requests), delete or anonymise data they have been asked to remove or encrypt sensitive data.
Top issues and areas of concern
Storage and protection of personal/sensitive data
Let’s start with the biggest issue – storage of personal and/or sensitive data. The primary problem is that FoxPro is a file-based database system. The database files have to be freely available to the application — it’s generally the point of a database system. In a typical network system the database files are in a shared folder available to any employee who has been given access to the application. You don’t need much know-how to realise any employee can simply walk off with the entire database. FoxPro DBF files are easy to read with even just a simple text editor.
On top of that you also have to consider what happens if your servers are stolen. At the absolute minimum you must ensure the disks that the database files are stored on are encrypted. You can do this using the built-in encryption features if you at least have a remotely recent version of Windows.
If your application stores what’s classified as sensitive personal data, e.g. racial or ethnic origins, political opinions, trade union membership, and so on, you’ll need to take extra precautions such as encrypting the data at the field level and possibly consider adding additional access controls so that only employees who need access to that data can do so.
Subject Access Requests
This is one of the most commonly requested items. Fortunately, it’s also one of the simpler and easier requirements to deal with. You are likely to receive Subject Access Requests (SARs) which means that you must provide all the data you hold on a data subject to them, preferably in a suitable electronic format such as a CSV file, with “undue delay” and within a month at most.
If you expect to receive a reasonable number of these requests then adding this as a function to your system is likely to be a more cost-effective exercise than having to dedicate staff time to laboriously copy and paste all the relevant data out of your system into another file to provide to the user instead of their regular duties.
Deletion or Anonymisation of data
One of the new requirements is the data subjects right to be forgotten. If you’re asked to remove them from your system you need to process the request within 4 weeks.
In most systems, deletion of data is not a simple affair. Blindly removing data is highly likely to cause many knock-on effects such as historical reporting to become inaccurate. You also may not need to delete the data if you can demonstrate that you have a legitimate interest which overrides the request of the data subject. However, you can, and should, still take steps to remove data that you no longer need. To meet all the legal requirements, often the most typical option is anonymisation of the data subject. This means replacing the personal data with some other data so they cannot be identified but still retaining necessary information to maintain system integrity and deal with other legal requirements where data needs to be kept. It will certainly help limit your liability. For example, you could replace names with a default option such as ”Mx Data Anonymised” and a standard faux address and so on. Depending on your legitimate processing interests it may be acceptable to keep some data. For example, you may be able to keep a postcode in order to be able to draw on general trends, since a postcode on its own cannot be used to identify an individual. Much of the work required here is identifying everywhere throughout the system where there is personal information, and its purpose, and then determining if it should be deleted without issue or whether it can be anonymised.
Audit trails and consent
If you’re relying on consent as your lawful basis for processing, where you need to obtain explicit consent to process data, it’ll likely be necessary to add capabilities to your system to record this information and provide it upon request. This means changes to forms and processes to record when explicit consent was granted. Depending on the processing that you do, you may also need to alter processes to exclude individuals from the processing activities where you have not obtained it or where it temporarily needs to be restricted. You also need to be able to revoke that consent at any time at the request of the data subject and ensure it’s acted upon.
You’ll also need audit reports generating since you need to be able to prove that consent has been given or revoked.
Documentation
A large part of the GDPR relates to documentation of your policies and processes as they relate to your processing of personal data. You also need to know who in your organisation has access to personal data and what sort of access and control they have over it. Systems that have been developed over many years (practically every (Visual) FoxPro system we have ever seen) often means sprawling screens and not much in the way of access control mechanisms in place, where too many people actually have access to data that they have no business needing.
Identifying and auditing this information to create the necessary documentation we’re finding that companies need help understanding this from their system perspective. Having expert knowledge of how FoxPro systems work and knowing where and what you’re looking for in the source code of the application can reduce the time needed to do this.
If you need any help achieving GDPR compliance with your FoxPro-based applications please contact us. Or schedule a call using the link below for a free no-obligation chat to see if we can help.