GDPR / Data Protection Act

SQL Server and The Data Protection Act / GDPR

Summary

On May 25, 2018, the new Data Protection Act, effectively the same as the EU GDPR (General Data Protection Regulations) replaces the previous Data Protection Act. This new act is likely to affect everyone that handles personal data and is almost certain to require changes to system holding such data. If you need any assistance in complying with these new regulations Aldex Software can help, please contact us.

The new Data Protection Act/GDPR significantly tightens up the rules on the handling and storage of personal data – with much larger fines for those who fail to comply. Additionally the definition of personal data has been extended and now includes IP and email addresses amongst others. Organisations should not hold personal data unnecessarily and have to show that consent was given to record and process any such data, especially where this relates to secondary purposes such as marketing; essentially you need to show that you are being responsible with personal data and to protect it from being misused. For example, you cannot pass personal data on to a third party without the positive agreement of the relevant data subject, additionally you may have to ensure that the third party will also treat the data responsibly, especially if they are outside of the UK or the EU.

Consumers can now make Subject Access Requests, showing what data an organisation holds on them, for free, and can demand that such data be corrected or deleted under a new “right to be forgotten”.

This page is a brief overview of the risks and potential solutions to data breaches with particular reference to the UK and SQL Server. Further information can be found at the web site of the Information Commissioner’s Office:
 https://ico.org.uk/for-organisations/data-protection-reform/overview-of-the-gdpr/

Caveat: This document is provided ‘as is’ and is a summary of our understanding and interpretation of GDPR/The Data Protection Act. It is not comprehensive and does not constitute legal advice.

Implications with respect to databases:

·       Personal data needs to be encrypted, not held in clear text. Depending upon the situation this may include data at rest, in transit or in use. There are a significant number of different options for encryption, each with its own advantages and disadvantages.

·       Administrative staff, who do not require access to personal data, should not be able to view such data.

·       Your users should only see the minimum amount of personal data required by their job. For example a person in one team may need to be prevented from seeing data from another team unless this is a job requirement.

·       Each user viewing personal data should have a their own, separate, login so that data access can be controlled and audited.

·       You should use the principle of ‘least privilege’ with users having the minimum data permissions as is needed to undertake their job. E.g. do not give all users administrative permissions to the database. This is especially important for web sites, which often use a single administrator connection to access the database.

·       Retrieving and displaying large amounts of personal data, say on a large scrolling list, should only be performed when there is a clear business requirement. Otherwise you should only retrieve personal data for one person at a time.

·       The accessing of personal data should be audited and written away to a location outside of the database.

·       The agreement, or otherwise, of a subject to permit their data to be used, for example for marketing purposes, need to be logged together with dates and associated corroborating details e.g. how and where permission was given (web site tick box, paper form, etc.). Data subjects should also be able to revoke previously given permissions; again this needs to be logged including date and time information. 

·       You need to put processes in place, preferably automated to reduce costs, to retrieve all data for a specific data subject on receipt on a valid Subject Access Request. This could either be gathered together as an electronic document, a paper copy or, in some circumstances, you could give individuals online access to their own data.

·       You need to put processes in place to alter or delete a data subject’s records on request providing there is no compelling reason for its retention. Such changes also need to be forwarded to any other organisation that you have provided that individual’s data to. This implies that you now need to log any such third party transfers of information against each individual.

·       You must be able to recover from database problems. The minimum that would be required is a properly thought out back-up regime for your database (which should already be in place irrespective of the regulations).

·       SQL Server databases and associated front ends should be hardened against SQL Injection attacks. It is difficult to understand why SQL Server databases can still be compromised by such well known security holes but yet the breaches and resultant bad publicity still continue.

 

The Risks

Hacking, i.e. an external person or organisation gaining unauthorised access to your database, usually by exploiting a security weakness.

Unauthorised access by authorised users. For example an existing member of staff downloading your entire client list; which could be done for financial gain, malicious reasons or even due to blackmail. Unlikely perhaps but you should be taking steps to prevent these possibilities.

Password/account phishing

Compromised user names/passwords

Guessing account/usernames

SQL Server injection attacks

Viruses, Trojans, worms, etc.

Man-in-the-middle servers

Dishonest/compromised employees or contractors

Social engineering attacks

Honest mistakes (oops – I accidentally sent a copy…)

Physical breaches (burglary)

Etc.

 

What To Do Next

First, you need to identify what personal data is being held, who can access it, how and where it is being used and what the potential risks are.

Second, you need to take the results from the first stage and decide, in principal, what changes will be needed in order to satisfy GDPR.

Then you need to decide how to physically implement these changes, whether they are practical, or even possible, and how resource constraints will affect this. If you cannot comply with the new requirements you may need to review and reduce what data you hold.

Next, the agreed changes have to be implemented. Depending upon what is required, this may involve considerable rework of the existing database structures and front end software, perhaps upgrading of some of the existing IT infrastructure, implementation of new security methods, etc.

The changes should then be tested, including ensuring that auditing/logging is working as expected.

Finally you need to review your systems at regular intervals to ensure that everything is still working as planned. Additionally, whenever changes are made to the system these should be reviewed to ensure that they still meet the requirements.

How Aldex can help

We can assist with identifying personal data, reviewing your existing procedures, adding encryption to your SQL Server databases, adding Auditing to your SQL Server databases, altering databases to store additional columns, creating stored procedures to retrieve/delete all data about a person, creating or modifying application software and web sites, hardening databases against SQL Server injection attacks, etc.

Further information can be found at the web site of the Information Commissioner’s Office: https://ico.org.uk/for-organisations/data-protection-reform/overview-of-the-gdpr/

To discuss how we can help you with this please contact us.

Comments