25 May 2018 is the date when all organisations are expected to be compliant with the new General Data Protection Regulation (GDPR). The key features of the regulation were outlined in a previous article (OHM33, 2016/2, p24-27) while in this article the key principles of data protection will be discussed along with the role of the data protection officer, tasks that should be undertaken to achieve compliance and the key aim of ‘privacy by design’.
The GDPR is fundamentally about protecting information specific to living individuals, (deceased people do not have the same rights!) especially sensitive data such as health records, and information such as trade union membership. IT administrators should also remember that userids, email addresses and even IP addresses count as personally identifiable information.
This means that even application log files (e.g. GroupWise and Vibe logs) which contain this sort of information are also on the GDPR radar. Administrators need to have clear policies on what is logged and the storage of such files. This should be made clear to users when they first start using the application.
In one sense the law is asking organisations to look after people’s data in the way they would like their own data managed. The GDPR has the power to enforce compliance through the mechanism of fines (greatly increased compared to existing laws) but individuals can also take their own legal action if they have suffered as a result of a data breach or mis-use of personal information. Although the financial penalties may be serious (up to €20M or 4% of turnover) and damaging for some offenders the objective of the law is to instil new accountability for personal data in organisations; to promote good practice in data management and to design privacy into services. (ICO (UK) blog August 2017).
The regulation defines Data Subjects, Data Controllers and Data Processors. Data Subjects are the individuals who are providing the source data. As such they have the right of consent to provide the information and the right to withdraw consent at any time. They may make “Subject Access Requests” to organisations to see what data is being held on them. Organisations can no longer charge for this and must respond within 30 days (formerly 40 days). The only way for an organisation to avoid disclosure is to argue that the request is too costly and impractical. To use this argument then the organisation needs to be able to show that it is already compliant with the GDPR.
Data Controllers are the entities (usually an organisation as a whole rather than an individual) who are responsible for managing the information collected and using it for various tasks e.g. product sales related activities. Controllers may delegate or sub-contract some of the activities to Data Processors who may be responsible for initially collecting the data, analysing it or just storing it.
Immediately you can see that cloud services are most likely to be data processors for many Controllers. It is the responsibility of the controller to ensure that the processor is compliant with GDPR and this needs to be clarified in their contract of work. Processors have to demonstrate compliance and alert all data breaches without ‘undue delay’ to the Controller.
The reach of the GDPR is global. It does not matter where the controller or processor are located. If they are dealing with the personal information of EU citizens (and yes, also the UK) then they still need to be GDPR compliant and are liable to penalties. The GDPR specifies how data should be managed when transferred outside of the EU. Only a few countries e.g. Canada, New Zealand, Uruguay and Israel are considered to have comparable safeguards to the GDPR. Data transfers to the United States are governed by the ‘Privacy Shield’ agreement.
The GDPR is a major piece of legislation and leads the way in privacy controls. Consequently there are still parts of it that have yet to be fully ‘tested’. For example, the term ‘undue delay’ has yet to be quantified (but is likely to be less than 72hours, the specified maximum delay for notifications of data breaches). Also there are no official certifications yet available - although information security management accreditations such as ISO27001 help demonstrate a commitment to compliance – certainly in larger organisations.
The accountability sought by the law is achieved by adherence to the six core principles outlined in it. These confirm that the personal information held by organisations should be:
- Legal, transparent and fair. This is the core principle in a way. Personal data processing must be fair to the extent that it is what the data subject has consented to and transparent in that the processing matches what the subject has been told. Legal means in-line with the purposes of the GDP Regulation. So for example if you purchase something with a maintenance contract then you will expect the vendor to keep your name and address. This does not give the vendor the right to use your data to offer further unrelated products and services (perhaps from an affiliated company) which was not obvious during the initial transaction.
- Limited in purpose. You must define at the start what the data you collect (as a Controller) will be used for and limit the processing just to meet that purpose. The data subject must be provided with the appropriate privacy notices and consent forms which clearly state the purpose.
- Minimised. Controllers should only hold the information relevant to the purpose they are processing the information. Generic data collection forms should not be used, but should be specific to the need.
- Accurate. The regulation requires that any personal data kept is accurate and kept up to date. The data subject has the right to rectify any incorrect or incomplete data. This means that the data controller needs a mechanism by which the subject can request changes. A web link is one option but it still requires the relevant procedures to be put in place. Accuracy is also ‘of a time’. For example an initial medical diagnosis may be incorrect, but the information should be kept as it provides a full record of the patient’s treatment. This principle also leads to the right of deletion of incorrect data (the so-called ‘right to be forgotten’).
- Limited storage. If you don’t need the data then delete it, is the message of this principle – a data retention policy is required.
- Confidential and integrity maintained. Article 5, clause 1, states that Organisations must process data “that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage”. Procedures and processes that limit access to only the staff who need to access the data need to be put in place. Organisations should also consider the use of encryption as a defence mechanism.
Data Protection Officers
The principles outlined above will in one way or another already be familiar to most organisations who comply with existing data protection laws. Public organisations such as councils (local government) and most large companies will already have appointed a Data Protection Officer (DPO) to oversee compliance with privacy and data protection laws. The GDPR believes this is good practice and recommends that all organisations appoint one. It does not have to be a full-time role – a senior member of a small company may take on the responsibility – and a DPO can even be a contract member of staff (part-time or full time).
DPOs need to be granted a high level of independence in order to perform their roles, and have a good understanding of the relevant laws (although a legal background is not essential). They take the responsibility of ensuring that all the necessary procedures, processes and checks are put in place and maintained in order to achieve compliance.
Data protection should be a board level responsibility and constantly reviewed and so the DPO needs to have good channels of communication directly to the board. One method that boards can adopt to manage their responsibilities for data protection is to appoint a “senior information risk owner” to the board. This is a business risk management role and should lead to a holistic approach to data management.
Data Protection Impact Assessments (DPIAs)
Fines, law suits for compensation claims and loss of reputation are the outcomes of not complying with the GDPR. Consequently it makes sense that organisations seek to recognise and reduce their risks, and the GDPR mandates that organisations should undertake DPIAs to demonstrate compliance. Controllers and processors need to evaluate the risks inherent in their business activities and implement measures to mitigate those risks. Risks include accidental destruction, loss or unauthorised disclosure which cause physical, material or non-material damage.
The GDPR sets out what a DPIA must contain:
- a description of the processing and purposes
- legitimate interests pursued by the controller
- an assessment of the necessity and proportionality of the processing
- an assessment of the risks to the rights and freedoms of data subjects
- the measures envisaged to address the risks
- safeguards and security measures to demonstrate compliance
- an indication of timeframes if processing relates to erasure
- an indication of any data protection by design and default measures
- a list of recipients of personal data
- confirmation of compliance with approved codes of conduct
- details of whether data subjects have been consulted
This is a serious and critical work commitment which may be new to many organisations. One of the first steps needs to be to recognise the flow of personal information throughout the business, which leads to the process of data mapping.
Data mapping brings into focus the who, what, why, when and where of an organisation’s data - the 5 W’s. Basically it’s an investigative exercise in finding the sources of your data and how it’s stored, managed and distributed within the organisation. More often than not the information is obtained by discussion or questionnaire with departmental stakeholders. The result of the exercise may be a detailed diagram of data flows or in more tabular form.
There are four elements in data mapping; the data items that are the core information; the format which is the state in which the data is stored, for example in the cloud, but you must also identify paper based formats, backups, even usb storage. The third element is transfer – the methods by which data items move from one location to another (they generally do), either physically or across the network. This includes faxing – which creates a new data item at the recipient end. Finally location – the site where the data items are processed (including stored).
The data map should also include how the data is collected - web form, call centre, email etc – and who is accountable for the data. All data should have an owner (as IT administrators well know). It’s important to know who should have access to the data and how, or if, it can be shared.
For large organisations data maps can become highly complex. So it makes sense to start with a ‘high level’ view and then dig down into smaller areas in greater detail. Creating data maps will clearly indicate where issues and risks associated with the processing of personal data arise. Consequently mitigations should be put in place to minimise the risk of a data breach.
Data maps are a key input to the impact assessments mentioned earlier. Together they help to embed the ideas of privacy by design in project and business operations. This is one of the key objectives that the GDPR wishes to achieve.
Impact assessments and data mapping are two of the processes that lead to GDPR compliance along with a management framework (documentation and processes). Effective staff education is also required to create the new culture and responsible attitudes to data handling. While all the requirements of the GDPR appear onerous to all organisations there are definite business benefits once the nirvana of compliance has been reached.
Ref: EU General Data protection Regulation – an implementation and compliance guide, by the IT Governance Privacy Team. ISBN 978-1-84928-835-4, published by IT Governance Publishing, 2016.
This article was first published in OHM Issue 38 (2017/3), p32-34.