Getting your FileMaker solution ready for the General Data Protection Regulation (GDPR)

The General Data Protection Regulation (GDPR) comes into effect 25 May 2018: the intention is to strengthen and unify data protection for residents and citizens within the European Union.  A primary goal of the act is to give people back control over their personal data and simplify the regulatory environment for international business with the European Union. 

If you haven’t read up on the regulations then you should start with the Information  Commissioner’s Office (ICO) website and look at their 12 steps to take now:

and then look at the full guide to the regulations:

It is important to note that in 2016 the ICO issued £880,500 of fines against companies last year, but that this would have been likely to be £69 Million under the new GDPR regulations according to an analysis by the NCC Group ( see  If you have been thinking that Brexit is likely to save you from having to implement GDPR compliant procedures then think again as it is likely that the UK regulatory framework will have to stay as close to the EU framework as possible in order to ensure that trade is not impacted (see

For many organisations using the FileMaker platform, there will be an element of their custom App or database which will have an individual’s contact information (Name, email, telephone numbers, job role and address) which falls under the definition of ‘personal data’ in GDPR.  Consequently, if you are using FileMaker, you will have to examine the implications of GDPR and modify your system and business processes to ensure that they are compliant.  The good news is that since FileMaker is optimised for custom development, it is usually quick to adjust to meet new regulatory requirements like GDPR (which is not always the case with off the shelf software).

Here are a couple of highlights of issues that you might need to address and what that would mean in the context of a FileMaker database or app:

Information Sharing

The GDPR requires that you keep records of your processing activities in a networked world: if you have inaccurate information and it is shared with another organisation, you will need to inform the other organisation about the inaccuracy so that their records can be updated.

Therefore, it is necessary to map out all of the inputs and exports that you feed and are generated by your database.  For example, it is common with FileMaker to use open database connectivity (ODBC) drivers to synchronise data with 3rd party SQL systems (such as Oracle, MySQL or MS SQL) or to integrate with a web service using cURL and REST API – so an important first step would be to document all of these integration points and highlight any cases where personal information is being exchanged and confirm there is a mechanism in place to issue corrections.

Subject access requests

Individuals have the right to request to be informed of what data you have recorded about them and in a tightening of the legislation compared with the Data Protection Act, you have only 1 month to comply with a request rather than 40 days.  If your organisation handles a large number of requests then you may need to look at improving the efficiency of processing these requests more quickly.  If you have your data within FileMaker then you may find it useful to build new interfaces to log the tracking of these requests and script the generation of suitable exports (Excel/CSV) or PDF reports to provide an overview of the information being held.


GDPR sets a higher standard for consent than the Data Protection Act – see:

Notably GDPR specifically bans pre-ticked opt-in boxes.  If you use your FileMaker system for CRM and are historically used to defaulting a flag field for adding a new prospect to a mail/email mailing list then this would need to be turned off.  Along a similar line if you are synchronising email lists with 3rd party online services like MailChimp then you need to be conscious of ensuring that if people opt out of communications that this is respected across all the systems you are using.


GDPR brings in special protections for children’s personal data and sets 16 as the age of consent for data processing.  If your organisation offers online services to children then you need to obtain consent from a parent or guardian and so you may need to put processing in place to verify an individual’s age.  For example, if you used FileMaker Go on an iPad to present a consent form and obtain a digital signature, it would be prudent to include fields to capture and check age based on their date of birth. 

Data Protection by Design and Data Protection Impact Assessments

GDPR makes privacy by design a legal requirement and data protection impact assessments (DPIAs) mandatory where new technology is deployed, a profiling operation is likely to affect individuals or where there is processing on a large scale.

FileMaker 16 includes a plethora of features which can be used to secure solutions, protect privacy and minimise the chance of data breaches so it is worth reviewing your security arrangements and determining if it is appropriate to make adjustments:

Limit Full Access accounts and turn off auto-login – by default, a new FileMaker file will have a single full access account with the login ‘Admin’ and no password.  This password should be changed as soon as a solution goes into production use with real data.  Auto-login can be turned off under File > File Options.  FileMaker 16 server by default will not allow you to host and open a file which contains a full access login with no password set.

Use Custom privilege sets – it is prudent to always create custom security privilege sets, rather than relying on the default ‘Data Entry Only’ settings for standard users.  As a minimum, you may want to turn off the ability of regular users to routinely print or export data.  FileMaker offers full granularity to specify in its security model, which fields and layouts can be accessed by a user and whether new records can be created, modified or deleted in a table.  You can also choose a minimum password length and enforce having to change it every X days.

Check Extended privileges – The X in the ‘fmreauthenticateX’ extended privilege controls how many minutes that FileMaker can be left in sleep/background before it requires a user to re-authenticate.  By default this is set to 10mins, so if you handle sensitive personal data then it may be prudent to reduce his timing to force re-authentication after a shorter period.

Make use of Active Directory/OAuth for managing security.  Delegating authentication to Active Directory or OAuth provides two obvious benefits: the password can be used across multiple files and centrally managed with strict rules on password length and complexity.  As AD is normally managed centrally, there should be a standardised process for leavers to be removed and so it is less likely that accounts will be left active for longer than they should be available.

Limit File Access.  By default, one FileMaker file can be linked and referenced within another regardless of the privilege set access level that the user has to the file.  This can be restricted to only allow users with full access privileges for explicitly authorised files (see File > Manage > Security > File Access tab).

SSL Encryption in flight.  FileMaker Server 16 is now much more explicit when there isn’t a properly configured and valid SSL certificate from a supported provider in place.  This is essential if you are accessing via a WAN connection.

AES 256 Encryption at rest.  It is possible to encrypt FileMaker database files using FileMaker Advanced 16 – this ensures that even if your network and server are compromised, it will be practically impossible to access the data without also having a copy of the encryption key to decrypt the file.  We now recommend doing this as standard for any system which includes personal data.

Use secure storage to encrypt container fields.  Documents that you have uploaded to container fields can be stored in an encrypted format in an external folder alongside your database files.  This is especially prudent if these documents contain personal or sensitive information (i.e. scans of passports for proof of identity, etc).

Encrypt data within fields.  In the past, 3rd party plugins were required to encrypt and decrypt field level data within FileMaker.  Now with FileMaker 16 there are native functions such as CryptEncrypt/CryptDecrypt.  For highly sensitive personal data such as medical information or credit card data there is a good argument for doing this as standard.

For more information on the security features of the FileMaker platform - see FileMaker's official guide:

If you are interested in finding out more about how the FileMaker platform can be used to secure data privacy or need assistance with modifying your system to meet GDPR then contact our consulting team for assistance.