On 14th April 2016, the European Union parliament approved the General Data Protection Regulation (GDPR). It will be enforced from 25th May 2018. EU regulations are binding legislative acts that need to apply in entirety across the EU. The full text is a lengthy read intended to reduce ambiguities and pre-empt legal arguments in court.
A summary of the GDPR is available here.
In essence, the GDPR applies to any organisation in the world offering goods or services to, or monitoring the behaviour of, EU data subjects. ‘Clouds’ are not exempt. The penalties for non-compliance are a maximum of 4% of global annual turnover or €20 million, with a tiered approach to fines based on the level of infringement. Liability may be shared between data processors and data controllers. A controller is the entity that determines the purposes, conditions and means of the processing of personal data, while the processor is an entity which processes personal data on behalf of the controller.
Brexit will not make much of a difference for the U.K. GDPR comes into effect 10 months before the exit night on 29th March 2019 and the current UK government plans to pass a Grand Reform bill incorporating all EU law into UK law, including the GDPR. If a UK-only organisation breaches the privacy of any UK citizens post-Brexit, they will be fined by the Information Commissioner’s Office (ICO) within the laws of England, Wales, and Northern Ireland, or under Scottish law. If a UK organisation breaches the privacy of EU citizens at any time from 25th May 2018 they will be fined under EU law. That same rule applies to all commercial and government organisations everywhere in the world.
Personal Data
Personal Data is defined as any information related to a natural person or ‘Data Subject’, that can be used to directly or indirectly identify the person. It can be anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer IP address.
Without delving into the details of the regulation, there are some important considerations for Testers handling GDPR work. Firstly, there is the possibility that privacy is already being breached by the current systems and data handing tools (including laptop & desktop computers).
Privacy Breach
All current and planned systems that handle personal data will need analysis to determine if there is a likely privacy breach. That includes the logs and archives, especially with regard to the ‘Right to be Forgotten’. Also known as Data Erasure, the right to be forgotten entitles the data subject to have the data controller erase his/her personal data, cease further dissemination of the data, and potentially have third parties halt processing of the data. The conditions for erasure, as outlined in article 17, include the data no longer being relevant to original purposes for processing, or a data subjects withdrawing consent. It should also be noted that this right requires controllers to compare the subjects’ rights to “the public interest in the availability of the data” when considering such requests.
GDPR And Testing
Privacy by design as a concept has existed for years now, but it is only just becoming part of a legal requirement with the GDPR. At its core, privacy by design calls for the inclusion of data protection from the onset of the designing of systems, rather than an addition. More specifically – ‘The controller shall.. implement appropriate technical and organisational measures.. in an effective way.. in order to meet the requirements of this Regulation and protect the rights of data subjects’. Article 23 calls for controllers to hold and process only the data absolutely necessary for the completion of its duties (data minimisation), as well as limiting the access to personal data to those needing to act out the processing.
An effective approach to analysing systems for GDPR compliance is to undertake a Privacy Impact Assessment (PIA). I’ve provided an example in the Appendix based upon a PIA for the UK’s Data Protection Act. It doesn’t seem fair to wreck consultancies’ business models by me publishing a customised version for the GDPR, but you are free to tweak this one!
Another consideration for Testers is the possibility of personally identifiable data breaches as a result of security vulnerabilities. By now you are getting security rights or you’re probably never going to. For years there have been mountains of free advice, including mine, on security. Many organisations remain top-heavy with security governance and compliance staff, while desperately short of security-savvy workers at the code-face. Hopefully you’ve read my EuroSTAR e-books on Application Security and / or a lot of other OWASP and Wiley material, then applied the knowledge in your organisation. If you’re still drinking in the last chance saloon I strongly recommend you persuade a budget holder to invest in IAST and RASP real-time security instrumentation. It might seem expensive now, but wait until the first fine for 4% of global annual turnover arrives!
Good luck!
About The Author
Declan O’Riordan is a CESG Certified Professional – Security & Information Risk Advisor. His interest is in security testing. He speaks widely on the topic. He is a twice winner of Best Paper at the EuroSTAR Conference.
——————————————————————————————————————————
Appendix
Annex one
Privacy impact assessment screening questions
These questions are intended to help you decide whether a PIA is necessary. Answering ‘yes’ to any of these questions is an indication that a PIA would be a useful exercise. You can expand on your answers as the project develops if you need to.
You can adapt these questions to develop a screening method that fits more closely with the types of project you are likely to assess.
Will the project involve the collection of new information about individuals?
Will the project compel individuals to provide information about themselves?
Will information about individuals be disclosed to organisations or people who have not previously had routine access to the information?
Are you using information about individuals for a purpose it is not currently used for, or in a way it is not currently used?
Does the project involve you using new technology that might be perceived as being privacy intrusive? For example, the use of biometrics or facial recognition.
Will the project result in you making decisions or taking action against individuals in ways that can have a significant impact on them?
Is the information about individuals of a kind particularly likely to raise privacy concerns or expectations? For example, health records, criminal records or other information that people would consider to be private.
Will the project require you to contact individuals in ways that they may find intrusive?
Annex two
Privacy impact assessment template
This template is an example of how you can record the PIA process and results. You can start to fill in details from the beginning of the project, after the screening questions have identified the need for a PIA. The template follows the process that is used in this code of practice. You can adapt the process and this template to produce something that allows your organisation to conduct effective PIAs integrated with your project management processes.
| Step one: Identify the need for a PIA
Explain what the project aims to achieve, what the benefits will be to the organisation, to individuals and to other parties. You may find it helpful to link to other relevant documents related to the project, for example a project proposal. Also summarise why the need for a PIA was identified (this can draw on your answers to the screening questions).
|
| Step two: Describe the information flows
You should describe the collection, use and deletion of personal data here and it may also be useful to refer to a flow diagram or another way of explaining data flows. You should also say how many individuals are likely to be affected by the project.
|
| Consultation requirements
Explain what practical steps you will take to ensure that you identify and address privacy risks. Who should be consulted internally and externally? How will you carry out the consultation? You should link this to the relevant stages of your project management process.
You can use consultation at any stage of the PIA process.
|
| Step three: Identify the privacy and related risks
Identify the key privacy risks and the associated compliance and corporate risks. Larger-scale PIAs might record this information on a more formal risk register. Annex three can be used to help you identify the DPA related compliance risks.
|
| Step four: Identify privacy solutions
Describe the actions you could take to reduce the risks, and any future steps which would be necessary (e.g. the production of new guidance or future security testing for systems).
|
| Step five: Sign off and record the PIA outcomes
Who has approved the privacy risks involved in the project? What solutions need to be implemented?
|
| Step six: Integrate the PIA outcomes back into the project plan
Who is responsible for integrating the PIA outcomes back into the project plan and updating any project management paperwork? Who is responsible for implementing the solutions that have been approved? Who is the contact for any privacy concerns that may arise in the future?
|
Annex three
Linking the PIA to the data protection principles
Answering these questions during the PIA process will help you to identify where there is a risk that the project will fail to comply with the DPA or other relevant legislation, for example the Human Rights Act.
Principle 1
Personal data shall be processed fairly and lawfully and, in particular, shall not be processed unless:
- a) at least one of the conditions in Schedule 2 is met, and
- b) in the case of sensitive personal data, at least one of the conditions in Schedule 3 is also met.
Have you identified the purpose of the project?
How will you tell individuals about the use of their personal data?
Do you need to amend your privacy notices?
Have you established which conditions for processing apply?
If you are relying on consent to process personal data, how will this be collected and what will you do if it is withheld or withdrawn?
If your organisation is subject to the Human Rights Act, you also need to consider:
Will your actions interfere with the right to privacy under Article 8?
Have you identified the social need and aims of the project?
Are your actions a proportionate response to the social need?
Principle 2
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.
Does your project plan cover all of the purposes for processing personal data?
Have you identified potential new purposes as the scope of the project expands?
Principle 3
Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.
Is the quality of the information good enough for the purposes it is used?
Which personal data could you not use, without compromising the needs of the project?
Principle 4
Personal data shall be accurate and, where necessary, kept up to date.
If you are procuring new software does it allow you to amend data when necessary?
How are you ensuring that personal data obtained from individuals or other organisations is accurate?
Principle 5
Personal data processed for any purpose or purposes shall not be kept for longer than necessary for that purpose or those purposes.
What retention periods are suitable for the personal data you will be processing?
Are you procuring software that will allow you to delete information in line with your retention periods?
Principle 6
Personal data shall be processed in accordance with the rights of data subjects under this Act.
Will the systems you are putting in place allow you to respond to subject access requests more easily?
If the project involves marketing, have you got a procedure for individuals to opt out of their information being used for that purpose?
Principle 7
Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.
Do any new systems provide protection against the security risks you have identified?
What training and instructions are necessary to ensure that staff know how to operate a new system securely?
Principle 8
Personal data shall not be transferred to a country or territory outside the European Economic Area unless that country of territory ensures and adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data.
Will the project require you to transfer data outside of the EEA?
If you will be making transfers, how will you ensure that the data is adequately protected?
