High Risk Holders
Data Protection Impact Assessment
Where a type of processing, in particular, one using new technologies, taking account of its nature, scope, context and purposes, is likely to result in a high risk to the rights and freedoms of persons, the data controller must, prior to the processing, carry out an impact assessment of the envisaged processing operations on the protection of personal data.
A single assessment may address a set of similar processing operations that present similar high risks. The data controller must seek the advice of the data protection officer, where designated when carrying out the assessment.
A data protection impact assessment is required, in particular in the case of:
- a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the person or similarly significantly affect him;
- the processing on a large scale, of sensitive personal data or data relating to criminal convictions;
- the systematic monitoring of a publicly accessible area on a large scale.
DPC Designates Bodies Requiring Impact Assessment
The supervisory authority (the Data Protection Commission) must establish and publish a list of processing operations subject to the requirement for a data protection impact assessment. The supervisory authority may establish and publicise a list of the kind of processing operations for which no data protection assessment is required. It shall communicate those lists to the EU Board.
Prior to adopting the list, the authority shall apply the consistency mechanism in the legislation where the list involves processing activities which are related to the offering of goods and services to persons or to monitoring their behaviour in several states or which may substantially affect the free movement of personal data within the EU.
Where processing is necessary in order to comply with a legal obligation or a task carried out in the public interest under the law of the Member State concerned and a data protection assessment has already been carried out as part of a general impact assessment in the context of the adoption of that legal basis, the requirement for a further data protection assessment does not apply unless the state deems it to be necessary to carry out an assessment prior to the processing activities.
Requirements of Assessment
The assessment shall contain at least:
- a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller;
- an assessment of the necessity and proportionality of the processing operations in relation to the purposes;
- an assessment of the risks to the rights and freedoms of persons;
- the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with the GDPR taking account of the legitimate interests of the persons concerned and others.
Compliance with approved codes of practice by the controller or processor shall be taken into account in assessing the impact of the processing operations performed by them, in particular for the purpose of a data protection impact assessment.
Where appropriate, the data controller must seek the views of the persons, the subject of the data or their representatives on the intended processing. This is without prejudice to the protection of commercial and public interests and the security of processing operations.
Where necessary, the data controller must carry out a review to assess whether processing is performed in accordance with a data impact assessment as necessary and at least when there is a change of the risk represented by the processing operations.
The Data Protection Officer
The data protection officer must be designated on the basis of professional qualities and, in particular, expert knowledge of data protection law and practices and the ability to fulfill its below-mentioned tasks. The data protection officer may be a staff member of the data controller or processor or fulfil the tasks on a contract basis. The controller and processor must publish the contact details of the data protection officer and communicate them to the supervisory authority
The controller and the processor must ensure that the data protection officer is involved properly and in a timely manner, in all issues which relate to the protection of personal data. They shall
- support the data protection officer in performing his / her below tasks by providing the resources necessary to carry out those tasks
- give access to the personal data and processing operations and
- enable him to attain his or her expert knowledge.
The controller or processor must ensure that the data protection officer does not receive instructions regarding the exercise of these tasks. He shall not be dismissed or penalised for performing his tasks. The data protection officer shall report directly to the highest management level of the controller or the processor.
The data protection officer is bound by secrecy or confidentiality concerning the performance of his tasks, in accordance with domestic or EU law. The data protection officer may fulfil other tasks provided that they do not result in a conflict of interests.
Role of Data Protection Officer
The data protection officer shall have at least the following tasks:
- to inform and advise the data controller and processor and their employees who carry out processing, of their obligations under the GDPR, EU and State law;
- to monitor compliance with the GDPR and other data protection provisions and with the policies of the controller or processor in relation to the protection of personal data; this shall include the assignment of responsibilities, awareness-raising and training of staff involved in processing operations and related audits;
- to provide advice where requested as regards the data protection impact assessment and monitor its performance;
- to cooperate with the supervisory authority;
- to act as the contact point for the supervisory authority.
The data protection officer shall in the performance of his tasks have due regard to the risk associated with processing operations, taking account their nature, scope, context and purpose.
Persons whose information is held or processed may contact the data protection officer with regard to all issues related to the processing of that information and the exercise of their rights under the Regulation.
High-Risk Processing Notified to Authority and Consent
States may require controllers to consult with and obtain prior authorisation from the authority in relation to processing by a controller for the purpose of a task carried out by it in the public interest, including processing in relation to social protection and public health. This may involve registration and ongoing registration requirements.
A data controller must consult the supervisory authority prior to processing where a data impact assessment indicates that the processing would result in a high-risk, in the absence of measures taken by the controller to mitigate the risk.
Where the supervisory authority is of the opinion that the intended processing would infringe the regulation and in particular where the controller has insufficiently identified or mitigated the risk, the supervisory authority must within a period of eight weeks of receipt of the request, provide written advice to the data controller or the processor. It may use its powers. The period may be extended having regard to the complexity of the intended processing.
The supervisory authority shall inform the controller and where applicable, the processor of any such extension within one month of the request for consultation together with the reasons for the delay. The periods may be suspended until a supervisory authority has obtained the information it has requested for the purpose of the consultation.
Information to be provided to and Consultation with Authority
On consulting the supervisory authority, the controller must provide the authority with, where applicable,
- the respective responsibilities of the joint controllers and processers involved in the processing;
- the purposes and means of the intended processing;
- the measures and safeguards provided to protect the rights and freedoms of data subjects, subject to the regulation;
- where applicable, the contact details of the data protection officer;
- the data protection impact assessment;
- any other information requested.
Member States must consult the supervisory authority during the preparation of a proposal for a legislative measure to be adopted by a national parliament, or of a regulatory measure based on such a legislative matter, which relates to processing.
Data Protection Officer
The data controller and the processor must designate a data protection officer in any case where:
- the processing is carried out by a public authority or body, except for courts in a judicial capacity;
- the core activities of the controller or processor consist of processing operations which by their nature, scope or purposes, require regular or systematic monitoring of data subjects on a large scale;
- the core activities of the controller or the processor consist of the processing on a large scale of special categories of sensitive data or criminal convictions.
A group of undertakings may appoint a single data protection officer, provided that he or she is easily accessible from each establishment. Where controller or processor is a public authority or body, a single data protection officer may be designated for several such authorities or bodies, taking account of their organisational structure or size.
In other cases, the controller or processor or bodies representing categories of them may, or where required by EU or State law shall designate a data protection officer. The data protection officer may act for associations and other bodies representing the controllers or processors.
Power of Supervisory Authority under GDPR
The supervisory authority has the following authorisation and advisory powers:
- to advise the controller in accordance with the prior consultation procedure;
- to issue opinions on its own initiative or on its request, to governmental bodies and public authorities;
- to authorise certain processing in the public interest including processing in relation to social protection and public health;
- to give an opinion and approve draft codes of conduct
- to accredit certification bodies
- to issue certifications and approve criteria for certification
- to adopt standard data protection clauses;
- to authorise other standard contractual clauses;
- to authorise binding corporate rules;
- to authorise administrative arrangements.
Registration Pre-Data Protection Act 2018
Certain categories of entities and persons who controled data in Ireland were obliged to register with the Data Protection Commission under the Data Protection Acts 1988-2003. These provisions were repealed by the Data Protection Act 2018 and replaced by the above provisions.
The legislation required all data controllers and data processors to register other than those exempted by regulations made under the Data Protection Act. Designated data controllers were required to register the purpose of their data processing. There were wide exemptions.
The register is open to inspection by members of the public, free of charge. They may take copies of extracts from the register.
A data controller who processes data commits and offence, if he fails to register. In effect, it was a requirement, that data controllers register under the Act if they wish to process personal data.
A data processor or controller may process data only, in the manner registered. It is an offence
- to keep data of a type, other than that registered;
- to use personal data other than for a purpose registered;
- to obtain data from a source that is not described;
- to disclose data to a person who is not described; or
- to directly transfer out of the state other than as registered.
General Exemptions (pre-Data Protection Act 2018)
The legislation provided an exemption from the designation for an obligation to register,
- for holders of statutory registers, which were intended to provide information to the public which is open for consultation by the public generally or to persons who demonstrates a legitimate interest (those maintaining public registers).
- processing of manual data;
- processing data with appropriate guarantees in the course of their legitimate activities, by a foundation, association or other non-profit-seeking body with political, philosophical, religious or trade union aims. The processing could relate to membership, supporters in regular contact or administration in connection with its purposes. The data must not be disclosed to a third party without consent.
Broad Exemptions (pre- Data Protection Act 2018)
Regulations provided that the following categories of data controller were exempt from the registration requirement:
- Data controllers who process data relating to personnel administration,
- Candidates for and holders of elective political office who process personal data for electoral activities or for the purpose of providing advice or assistance,
- Educational establishments,
- Solicitors and barristers who process personal data for legal professional purposes,
- normal commercial activity which by definition requires the processing of personal data, e.g. keeping details of customers and suppliers (with the exception of data controllers who process personal data relating to physical or mental health),
- Companies which process personal data relating to shareholders, directors or other officers of the company with a view to compliance with the Companies Acts,
- Data controllers who process personal data with a view to the publication of journalistic, literary or artistic material,
- data controllers or data processors to which an approved code of practice applies,
- Data processors who process personal data on behalf of data controllers where the processing of the data would fall under one or more of the above categories.
Commercial Activity Exemption (pre- Data Protection Act 2018)
The regulations exempted a data controller, who processed personal data relating to the past, existing or prospective customers or suppliers of the data controller for the purposes of—
- advertising or marketing the data controller’s business, activity, goods or services,
- keeping accounts relating to any business or other activity carried on by the data controller,
- deciding whether to accept any person as a customer or supplier,
- keeping records of purchases, sales or other transactions for the purpose of ensuring that the requisite payments and deliveries are made or services provided by or to the data controller in respect of those transactions,
- making financial or management forecasts to assist in the conduct of the business or other activity carried on by the data controller, or
- performing a contract with a data subject,
where the data are not processed other than where it is necessary to carry out such processing for any of the above purposes.
This exemption does not apply to a health professional who processes personal data relating to the physical or mental health or condition of a data subject for medical purposes,
Bodies Required to Register (pre- Data Protection Act 2018)
All bodies not falling within the above exemptions were required to register. The Data Protection Commissioner guidance indicated that the following are the main categories. Accordingly, those required to register included
- public authorities; this category encompassed the Government and most sub-governmental entities, including local authorities, many statutory bodies and bodies entrusted by the Government with certain functions, who were financed partly or wholly out of public funds
- financial institutions and intermediaries including credit reference agencies and debt collectors;
- data controller’s keeping data in relation to racial, political, religious or other beliefs, physical or mental health matters or criminal convictions; (holders / controllers of sensitive personal data)
- prescribed data controllers.
- Internet access providers;
- electronic communications network or service providers;
- persons who process genetic data;
- those whose business consists wholly or mainly of direct marketing;
- data controllers whose business consists wholly or mainly in providing credit references;
- data controllers whose business consists wholly or mainly in collecting debts;
- internet access providers
- telecommunication service providers;
- Insurance undertakings (not including brokers)
- telecommunications network
- health professionals processing personal data related to mental or physical health
- data controllers processing genetic data
- data controllers whose business consists of processing personal data for the supply to others, other than journalistic, literary or artistic purposes
- data processors; (all person and bodies who “process” personal information) in the above categories.
Application (pre- Data Protection Act 2018)
The application for registration was made in a prescribed form. Giving false particulars was an offence. Registration was for a period fixed at a year. Registration could be continued annually. If the data controller is not the person to whom requests are to be made, that person’s name is to be specified. A nominated compliance officer is required.
The application must give details of the name and address of the controller or processor, the purpose of processing or control, a description of the data and categories of data subject, recipients or category of recipients to whom data may be disclosed. There is a prescribed fee for registration. This is based on the number of employees in the organization concerned. At more than 25 employees, it was at €317. The lowest level was €25.37.
The application must set out proposed and possible transfers of data to third countries. The application must give a general description, following assessment, of the appropriateness of measures taken to ensure security in processing. If the Commissioner required, details were to be furnished of the persons or categories of person from whom the data and information are acquired.
An application for registration must be accepted unless the particulars furnished for inclusion are insufficient, the required information has not been furnished, or the Commissioner is of the opinion that the person applying for registration is likely to contravene provisions of the Act. An application for registration by a controller of sensitive data may be accepted provided that the Commissioner is of the opinion that appropriate safeguards for the protection of the privacy of the data subjects, are being and will continue to be, provided.
A determination of registration must be made as soon as possible. If registration is refused, the reasons for refusal must be given. There is a right of appeal within 21 days.
Prior Checks (Data Protections Acts 1988-2003)
Prior checks were required by the Commissioner in relation to processing, which is particularly likely to cause substantial damage or substantial distress to individuals or otherwise significantly prejudice the rights and freedoms of the data subject. In such cases, the controller could also request the Commissioner to review compliance of his data processing operation.
Where the request was made, the Commissioner must consider and determine whether the processing complies with the provisions of the Act, within 90 days. The notice must be served on the data controller, stating the opinion of the Commissioner as to compliance.
The processing of data which requires prior checking is an offence, unless the controller has successfully registered in the previous year and the matter has been considered, or the data controller has requested the prior check and the period of 90 days has elapsed without receiving notice or the Data Protection Commissioner has notified the controller that the processing operation is likely to comply with the Act or the controller has taken the steps required by the Data Protection Commissioner.
Codes
The Member States and supervisory authorities, the EU Board and the Commission shall encourage the drawing up of codes of conduct intended to contribute to the proper application of the Regulation. They must take into account the specific features of the various processing sectors and the specific needs of micro, small and medium-sized enterprises.
Associations and other bodies representing categories of controllers or processors may prepare codes of practice, for the purpose of specifying the application of the Regulation. They may be amended and extended from time to time.
In addition to adherence by controllers and processors who are subject to the legislation, approved codes of conduct and having general validity may also be adhered to by controllers and processors who are not subject to the GDPR in order to provide appropriate safeguards within the framework of data transfers to third countries or international organisations. The controllers or processors shall make binding and enforceable commitments, through contractual or other legally binding instruments, to apply those appropriate safeguards including the rights of data subjects.
Content of Codes
The codes may relate to:
- fair and transparent processing;
- the legitimate interests pursued by controllers in specific contexts;
- the collection of personal data;
- the pseudonymisation of personal data;
- information provided to the public and to data subjects;
- the exercise of the rights of data subjects;
- the information provided to, and the protection of, children, and the manner in which the consent of the holders of parental responsibility for children is to be obtained;
- the measures and procedures for safeguarding information and to ensure the security of processing;
- the notification of personal data breaches to the persons concerned;
- the transfer of personal data to third countries or international organisations;
- out-of-court proceedings and other dispute resolution procedures for resolving disputes between data controllers and data subjects.
A code of conduct must contain a mechanism to enable the supervisory / private body to carry out the mandatory monitoring of compliance with its provisions by the controllers and processors which undertake to apply it. This is without prejudice to the responsibilities and powers of the competent supervisory authorities.
Approval of Codes
Associations and other bodies which intend to prepare a code of conduct or amend and extend it, must submit a draft to the supervisory authority (the Data Protection Commission). The authority shall provide an opinion on whether the draft, amendment or extension complies with the Regulation. It shall approve if it finds that it provides sufficient and appropriate safeguards.
Where the draft code, amendment or extension is approved and where the conduct does not relate to processing activities in several States, the supervisory authority shall register and publish the code.
Where the code relates to processing in several States, it must be submitted through a particular procedure whereby the EU Board issues an opinion as to compliance with the GDPR. Where the opinion confirms compliance, the EU Board may submit the opinion to the EU Commission.
The Commission may, by way of implementing acts, decide that the approved code of practice (or amendments etc.) shall have general validity throughout the EU. It may be adopted in the same way as secondary/implementing legislation.
Approved Monitoring Bodies
Without limiting the powers and tasks of the supervisory authority, the monitoring of compliance with a code of conduct may be carried out by a body which has an appropriate level of expertise in relation to the subject-matter of the code and is accredited for that purpose by the competent supervisory authority.
A body may be accredited to monitor compliance where the body has:
- demonstrated its independence and expertise in relation to the subject-matter of the code to the satisfaction of the supervisory authority;
- established procedures which allow it to assess the eligibility of controllers and processors to apply the code, to monitor compliance and to periodically review its operation;
- established procedures and structures to handle complaints about infringements or the manner in which the code is being implemented by a controller or processor, to make those transparent to persons who are the subject of the data and
- demonstrated to the satisfaction of the authority that its tasks and duties do not result in a conflict of interests.
The competent authority must submit the draft criteria for accreditation of a body to the EU pursuant to the consistency mechanism.
Enforcement by Accredited Bodies
Without limiting the tasks and powers of the competent authority, the accredited body shall, subject to appropriate safeguards, take appropriate action in cases of infringement of the code by a data controller or processor. This may include the suspension or expulsion of the controller or processor from the code. It shall inform the supervisory authority of such actions and the reasons for taking them.
The supervisory authority shall revoke the accreditation of the body if the conditions for accreditation are not or are no longer met or where actions taken by the body infringe the GDPR. These provisions do not apply to processing undertaken by a public authority or body.
Certification Mechanisms
The Member States, the supervisors, the EU Board and Commission shall encourage, in particular at EU level, the establishment of data protection certification mechanisms and data protection seals and marks, for the purpose of demonstrating compliance with the regulation of processing operations by controllers and processors. The specific needs of micro, small and medium-sized enterprises must be taken into account.
In addition to adherence with compliance with the GDPR, the certification mechanisms, seals etc. approved, may demonstrate the existence of appropriate safeguards provided by controllers or processors that are not subject to the GDPR within the framework of personal data transfers to third countries or international organisations. Such controllers or processors shall make binding and enforceable commitments, through contractual or legally binding instruments, to apply the appropriate safeguards, including the rights of data subjects.
The certification shall be voluntary and available through a process that is transparent. The certification does not reduce the responsibility of the controller or processor for compliance with the legislation.
Certification Process
A certification is issued by the certification bodies or the supervisory authority, on the basis of criteria approved by that authority or by the EU Board. Where it is approved by the EU Board, there may be a common certification, the European Data Protection Seal.
The controller or processor which submits its processing to the certification mechanism shall supply the certification body or the competent supervisory authority, with all information and access to its processing activities that are necessary to conduct the certification procedure.
Certification bodies shall, after informing the supervisory authority in order to allow it exercise powers, where necessary, issue or renew certification.
Certification is issued to a controller or processor for a maximum period of three years. It may be renewed, under the same conditions, provided that the requirements continue to be met. It shall be withdrawn by the certification bodies where the conditions are no longer met.
The EU Board shall collate all certification mechanisms and data protection seals and marks in a register and make them publicly available by any appropriate means.
Certification Bodies
Member States must ensure that certification bodies are accredited by the relevant supervisory authority or national accreditation authority as defined in EU legislation.
Certification bodies must be accredited only where they have:
- demonstrated their independence and expertise in relation to the subject-matter of the certification to the satisfaction of the authority;
- undertaken to respect the relevant criteria;
- established procedures for issuing, periodic review and withdrawal of data certification seals and marks;
- established procedures and structures to handle complaints about infringements of certification or the manner in which it is being implemented by processors, controller etc.;
- demonstrated, to the satisfaction of the competent authorities, that their tasks do not result in a conflict of interest.
Accreditation Bodies
The accreditation of certification bodies is to take place in accordance with criteria approved by the supervisory body under the Regulation. The Irish National Accreditation Board is the accreditation body in Ireland.
The certification bodies are to be responsible for the due assessment leading to certification or withdrawal of certification without prejudice to the responsibilities of the controller or processor in relation to compliance with the GDPR.
Certification bodies are responsible for assessment leading to the certification or withdrawal of certification, without prejudice to the responsibilities of the controller or processor for compliance with the GDPR. Accreditation shall be assessed for a maximum period of five years and may be renewed on the same terms and conditions provided that the body meets the relevant criteria in the GDPR.
Certification bodies shall provide supervisory authorities with reasons for granting and withdrawing certification. The requirements shall be made publicly available by the supervisory authority in an accessible form.
The competent authority or the national accreditation body shall revoke accreditation of a certification body where the conditions are no longer met, or actions taken by it infringe the GDPR.
References and Sources
Data Protection Act 1988
Data Protection (Amendment) Act 2003
Data Protection Act 2018
Data Protection (Fees) Regulations 1988, S.I. No. 347 of 1988
Data Protection Act 1988 (Commencement) Order 1988, S.I. No. 349 of 1988
Data Protection (Registration Period) Regulations 1988, S.I. No. 350 of 1988
Data Protection (Registration) Regulations 1988, S.I. No. 351 of 1988
Data Protection Act 1988 (Restriction of Section 4) Regulations 1989, S.I. No. 81 of 1989
Data Protection (Access Modification) (Health) Regulations 1989, S.I. No. 82 of 1989
Data Protection (Access Modification) (Social Work) Regulations 1989, S.I. No. 83 of 1989
Data Protection Act 1988 (Section 5 (1) (D)) (Specification) Regulations 1993, S.I. No. 95 of 1993
Data Protection Commissioner Superannuation Scheme 1993, S.I. No. 141 of 1993
Data Protection Act 1988 (Section 16(1)) Regulations 2007, S.I. No. 657 of 2007
Data Protection (Fees) Regulations 2007, S.I. No. 658 of 2007
Data Protection (Processing of Genetic Data) Regulations 2007, S.I. No. 687 of 2007
Data Protection (Processing of Genetic Data) Regulations 2007, S.I. No. 687 of 2007
Data Protection Act 1988 (Section 5(1)(D)) (Specification) Regulations 2009, S.I. No. 421 of 2009
Data Protection Act 1988 (Section 2B) Regulations 2011, S.I. No.486 of 2011
Data Protection Act 1988 (Section 2B) Regulations 2012, S.I. No.209 of 2012
Data Protection Act 1988 (Section 2A) Regulations 2013, S.I. No.313 of 2013
Data Protection Act 1988 (Commencement) Order 2014, Sino. 337 of 2014
Data Protection Act 1988 (Section 2B) Regulations 2015, S.I. No.240 of 2015
Data Protection Act 1988 (Section 2A) Regulations 2016, S.I. No.220 of 2016
Data Protection Act 1988 (Section 2B) Regulations 2016, S.I. No.426 of 2016
Data Protection Act 1988 (Section 2B) (No. 2) Regulations 2016, S.I. No. 427 of 2016
Data Protection (Amendment) Act 2003 (Commencement)Order 2003, S.I. No. 207 of 2003
Data Protection (Amendment) Act 2003 (Commencement) Order 2007, S.I. No. 656 of 2007
Data Protection (Amendment) Act 2003 (Commencement) Order 2014
EU Legislation
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance)
Directive (EU) 2016/680 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data by competent authorities for the purposes of the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, and on the free movement of such data, and repealing Council Framework Decision 2008/977/JHA
Regulation (EC) No 45/2001 of the European Parliament and of the Council of 18 December 2000 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data
Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data
Irish Books
EU Data Protection Law Kelleher & Murray 2018
Information & Technology Communications Law Kennedy & Murphy 2017
Social Networking Lambert 2014
Law Society PPG Hyland Technology & Intellectual Property Law 2008
Information Technology Law in Ireland 2 Kelleher & Murray 2007
Data Protection Law in Ireland: Sources & Issues 2 Lambert 2016
Privacy & Data Protection Law in Ireland Kelleher 2015
Data Protection: A Practical Guide to Irish & EU Law Carey 2010
Practical Guide to Data Protection Law in Ireland A&L Goodbody 2003
EU and UK Texts
Information Technology and Intellectual Property Law 7th ed 2018 Bainbridge 2018
Guide to the General Data Protection Regulation and the UK Data Protection Act 2nd ed
Rosemary Jay 2018
Government and Information: The Law Relating to Access, Disclosure and Their Regulation 5th ed
Patrick Birkinshaw, Mike Varney 2018
Commentary on the EU General Data Protection Regulation Christopher Kuner, Lee A. Bygrave, Christopher Docksey 2018
A User’s Guide to Data Protection: Law and Policy A User’s Guide to Data Protection: Law and Policy 3rd ed Paul Lambert 2018
Protecting Individuals Against the Negative Impact of Big Data: Potential and Limitations of the Privacy and Data Protection Law Approach Manon Oostveen July 2018
Information Exchange and EU Law Enforcement Information Exchange and EU Law Enforcement Anna Fiodorova 2018
Data Privacy and Cybersecurity: A Practical Guide Rafi Azim-Khan 2018
The General Data Protection Regulations (GDPR): How to get GDPR consent Simon McNidder 2018
The Cambridge Handbook of Consumer Privacy Edited by: Evan Selinger, Jules Polonetsky, Omar Tene 2018
Data Protection: A Practical Guide to UK and EU Law Data Protection: A Practical Guide to UK and EU Law 5th ed Peter Carey 2018
The EU General Data Protection Regulation (GDPR): A Commentary Lukas Feiler, Nikolaus Forgo, Michaela Weigln 2018
A Practical Guide to the General Data Protection Regulation (GDPR) Keith Markham 2018
EU Data Protection Law EU Data Protection Law Denis Kelleher, Karen Murray 2018
New European General Data Protection Regulation: A Practitioner’s Guide Edited by: Daniel Rucker, Tobias Kugler 2017
Encyclopaedia of Data Protection and Privacy Annual Subscription Rosemary Jay, Hazel Grant, Sue Cullen, Timothy Pitt-Payne 2017
Determann’s Field Guide to International Data Privacy Law Compliance 3rd ed 2017
The EU General Data Protection Regulation (GDPR): A Practical Guide Paul Voigt, Axel von dem Bussche 2017
EU General Data Protection Regulation (GDPR) – An Implementation and Compliance Guide Alan Calder, Richard Campo, Adrian Ross 2017
Privacy, Data Protection and Cybersecurity in Europe Privacy, Data Protection and Cybersecurity in Europe Edited by: Wolf J. Schunemann, Max-Otto Baumann 2017
Guide to the General Data Protection Regulation: A Companion to the 4th ed of Data Protection Law and Practice Rosemary Jay 2017
Post-Reform Personal Data Protection in the European Union: General Data Protection Regulation (EU) 2016/679 Post-Reform Personal Data Protection in the European Union: General Data Protection Regulation (EU) 2016/679 Mariusz Krzysztofek 2016
Privacy and Legal Issues in Cloud Computing Privacy and Legal Issues in Cloud Computing Edited by: A. S. Y. Cheung, R. H. Weber 2016
EU General Data Protection Regulation (GDPR) – An Implementation and Compliance Alan Calder, Richard Campo, Adrian Ross 2016
Data Protection and Privacy: International Series Data Protection and Privacy: International Series 3rd ed Edited by: Monika Kuschewsky 2016
Data Protection: The New Rules Ian Long 2016
A User’s Guide to Data Protection A User’s Guide to Data Protection 2nd ed Paul Lambert 2016
The Foundations of EU Data Protection Law Orla Lynskey 2015
Privacy and Legal Issues in Cloud Computing Privacy and Legal Issues in Cloud Computing Edited by: A. S. Y. Cheung, R. H. Weber 2015
Data Protection: A Practical Guide to UK and EU Law Data Protection: A Practical Guide to UK and EU Law 4th ed Peter Carey 2015
Data Protection: Law and Practice 4th ed with 1st Supplement Data Protection: Law and Practice 4th ed with 1st Supplement Rosemary Jay 2014
Information Rights: Law and Practice Information Rights: Law and Practice 4th ed Philip Coppel 2014
Cloud Computing Law Christopher Millard 2013
Transborder Data Flow Regulation and Data Privacy Law (eBook) Christopher Kuner 2013
Consent in European Data Protection Law Consent in European Data Protection Law Eleni Kosta 2013
A User’s Guide to Data Protection A User’s Guide to Data Protection Paul Lambert 2013
Confidentiality (Book & eBook Pack) Confidentiality 3rd ed The Hon Mr Justice Toulson, Charles Phipps 2012
Binding Corporate Rules: Corporate Self-Regulation of Global Data Lokke Moerel 2012
Property Rights in Personal Data: A European Perspective Property Rights in Personal Data: A European Perspective Nadezhda Purtova 2011
Global Employee Privacy and Data Security Law 2nd ed Morrison & Foerster LLP 2011
Computers, Privacy and Data Protection: An Element of Choice Computers, Privacy and Data Protection: An Element of Choice Edited by: S. Gutwirth, Y. Poullet, P. De Hert, R. Leenes 2011
Information Rights: Law and Practice Information Rights: Law and Practice 3rd ed Philip Coppel 2010
Data Protection: Legal Compliance and Good Practice for Employers Data Protection: 2ed Lynda Macdonald 2008
GDPR
CHAPTER IV
Controller and processor
Section 1
General obligations
Article 24
Responsibility of the controller
1. Taking into account the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. Those measures shall be reviewed and updated where necessary.
2. Where proportionate in relation to processing activities, the measures referred to in paragraph 1 shall include the implementation of appropriate data protection policies by the controller.
3. Adherence to approved codes of conduct as referred to in Article 40 or approved certification mechanisms as referred to in Article 42 may be used as an element by which to demonstrate compliance with the obligations of the controller.
Article 25
Data protection by design and by default
1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.
3. An approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2 of this Article.
Article 26
Joint controllers
1. Where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers. They shall in a transparent manner determine their respective responsibilities for compliance with the obligations under this Regulation, in particular as regards the exercising of the rights of the data subject and their respective duties to provide the information referred to in Articles 13 and 14, by means of an arrangement between them unless, and in so far as, the respective responsibilities of the controllers are determined by Union or Member State law to which the controllers are subject. The arrangement may designate a contact point for data subjects.
2. The arrangement referred to in paragraph 1 shall duly reflect the respective roles and relationships of the joint controllers vis-à-vis the data subjects. The essence of the arrangement shall be made available to the data subject.
3. Irrespective of the terms of the arrangement referred to in paragraph 1, the data subject may exercise his or her rights under this Regulation in respect of and against each of the controllers.
Article 27
Representatives of controllers or processors not established in the Union
1. Where Article 3(2) applies, the controller or the processor shall designate in writing a representative in the Union.
2. The obligation laid down in paragraph 1 of this Article shall not apply to:
(a)
processing which is occasional, does not include, on a large scale, processing of special categories of data as referred to in Article 9(1) or processing of personal data relating to criminal convictions and offences referred to in Article 10, and is unlikely to result in a risk to the rights and freedoms of natural persons, taking into account the nature, context, scope and purposes of the processing; or
(b)
a public authority or body.
3. The representative shall be established in one of the Member States where the data subjects, whose personal data are processed in relation to the offering of goods or services to them, or whose behaviour is monitored, are.
4. The representative shall be mandated by the controller or processor to be addressed in addition to or instead of the controller or the processor by, in particular, supervisory authorities and data subjects, on all issues related to processing, for the purposes of ensuring compliance with this Regulation.
5. The designation of a representative by the controller or processor shall be without prejudice to legal actions which could be initiated against the controller or the processor themselves.
Article 28
Processor
1. Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.
2. The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes.
3. Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller. That contract or other legal act shall stipulate, in particular, that the processor:
(a)
processes the personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which the processor is subject; in such a case, the processor shall inform the controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest;
(b)
ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality;
(c)
takes all measures required pursuant to Article 32;
(d)
respects the conditions referred to in paragraphs 2 and 4 for engaging another processor;
(e)
taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III;
(f)
assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor;
(g)
at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data;
(h)
makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller.
With regard to point (h) of the first subparagraph, the processor shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions.
4. Where a processor engages another processor for carrying out specific processing activities on behalf of the controller, the same data protection obligations as set out in the contract or other legal act between the controller and the processor as referred to in paragraph 3 shall be imposed on that other processor by way of a contract or other legal act under Union or Member State law, in particular providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that the processing will meet the requirements of this Regulation. Where that other processor fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller for the performance of that other processor’s obligations.
5. Adherence of a processor to an approved code of conduct as referred to in Article 40 or an approved certification mechanism as referred to in Article 42 may be used as an element by which to demonstrate sufficient guarantees as referred to in paragraphs 1 and 4 of this Article.
6. Without prejudice to an individual contract between the controller and the processor, the contract or the other legal act referred to in paragraphs 3 and 4 of this Article may be based, in whole or in part, on standard contractual clauses referred to in paragraphs 7 and 8 of this Article, including when they are part of a certification granted to the controller or processor pursuant to Articles 42 and 43.
7. The Commission may lay down standard contractual clauses for the matters referred to in paragraph 3 and 4 of this Article and in accordance with the examination procedure referred to in Article 93(2).
8. A supervisory authority may adopt standard contractual clauses for the matters referred to in paragraph 3 and 4 of this Article and in accordance with the consistency mechanism referred to in Article 63.
9. The contract or the other legal act referred to in paragraphs 3 and 4 shall be in writing, including in electronic form.
10. Without prejudice to Articles 82, 83 and 84, if a processor infringes this Regulation by determining the purposes and means of processing, the processor shall be considered to be a controller in respect of that processing.
Article 29
Processing under the authority of the controller or processor
The processor and any person acting under the authority of the controller or of the processor, who has access to personal data, shall not process those data except on instructions from the controller, unless required to do so by Union or Member State law.
Article 30
Records of processing activities
1. Each controller and, where applicable, the controller’s representative, shall maintain a record of processing activities under its responsibility. That record shall contain all of the following information:
(a)
the name and contact details of the controller and, where applicable, the joint controller, the controller’s representative and the data protection officer;
(b)
the purposes of the processing;
(c)
a description of the categories of data subjects and of the categories of personal data;
(d)
the categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries or international organisations;
(e)
where applicable, transfers of personal data to a third country or an international organisation, including the identification of that third country or international organisation and, in the case of transfers referred to in the second subparagraph of Article 49(1), the documentation of suitable safeguards;
(f)
where possible, the envisaged time limits for erasure of the different categories of data;
(g)
where possible, a general description of the technical and organisational security measures referred to in Article 32(1).
2. Each processor and, where applicable, the processor’s representative shall maintain a record of all categories of processing activities carried out on behalf of a controller, containing:
(a)
the name and contact details of the processor or processors and of each controller on behalf of which the processor is acting, and, where applicable, of the controller’s or the processor’s representative, and the data protection officer;
(b)
the categories of processing carried out on behalf of each controller;
(c)
where applicable, transfers of personal data to a third country or an international organisation, including the identification of that third country or international organisation and, in the case of transfers referred to in the second subparagraph of Article 49(1), the documentation of suitable safeguards;
(d)
where possible, a general description of the technical and organisational security measures referred to in Article 32(1).
3. The records referred to in paragraphs 1 and 2 shall be in writing, including in electronic form.
4. The controller or the processor and, where applicable, the controller’s or the processor’s representative, shall make the record available to the supervisory authority on request.
5. The obligations referred to in paragraphs 1 and 2 shall not apply to an enterprise or an organisation employing fewer than 250 persons unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10.
Article 31
Cooperation with the supervisory authority
The controller and the processor and, where applicable, their representatives, shall cooperate, on request, with the supervisory authority in the performance of its tasks.
Section 2
Security of personal data
Article 32
Security of processing
1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
(a)
the pseudonymisation and encryption of personal data;
(b)
the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
(c)
the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
(d)
a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
2. In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.
3. Adherence to an approved code of conduct as referred to in Article 40 or an approved certification mechanism as referred to in Article 42 may be used as an element by which to demonstrate compliance with the requirements set out in paragraph 1 of this Article.
4. The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by Union or Member State law.
Article 33
Notification of a personal data breach to the supervisory authority
1. In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.
2. The processor shall notify the controller without undue delay after becoming aware of a personal data breach.
3. The notification referred to in paragraph 1 shall at least:
(a)
describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;
(b)
communicate the name and contact details of the data protection officer or other contact point where more information can be obtained;
(c)
describe the likely consequences of the personal data breach;
(d)
describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.
4. Where, and in so far as, it is not possible to provide the information at the same time, the information may be provided in phases without undue further delay.
5. The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article.
Article 34
Communication of a personal data breach to the data subject
1. When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.
2. The communication to the data subject referred to in paragraph 1 of this Article shall describe in clear and plain language the nature of the personal data breach and contain at least the information and measures referred to in points (b), (c) and (d) of Article 33(3).
3. The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:
(a)
the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption;
(b)
the controller has taken subsequent measures which ensure that the high risk to the rights and freedoms of data subjects referred to in paragraph 1 is no longer likely to materialise;
(c)
it would involve disproportionate effort. In such a case, there shall instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner.
4. If the controller has not already communicated the personal data breach to the data subject, the supervisory authority, having considered the likelihood of the personal data breach resulting in a high risk, may require it to do so or may decide that any of the conditions referred to in paragraph 3 are met.
Section 3
Data protection impact assessment and prior consultation
Article 35
Data protection impact assessment
1. Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. A single assessment may address a set of similar processing operations that present similar high risks.
2. The controller shall seek the advice of the data protection officer, where designated, when carrying out a data protection impact assessment.
3. A data protection impact assessment referred to in paragraph 1 shall in particular be required in the case of:
(a)
a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person;
(b)
processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10; or
(c)
a systematic monitoring of a publicly accessible area on a large scale.
4. The supervisory authority shall establish and make public a list of the kind of processing operations which are subject to the requirement for a data protection impact assessment pursuant to paragraph 1. The supervisory authority shall communicate those lists to the Board referred to in Article 68.
5. The supervisory authority may also establish and make public a list of the kind of processing operations for which no data protection impact assessment is required. The supervisory authority shall communicate those lists to the Board.
6. Prior to the adoption of the lists referred to in paragraphs 4 and 5, the competent supervisory authority shall apply the consistency mechanism referred to in Article 63 where such lists involve processing activities which are related to the offering of goods or services to data subjects or to the monitoring of their behaviour in several Member States, or may substantially affect the free movement of personal data within the Union.
7. The assessment shall contain at least:
(a)
a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller;
(b)
an assessment of the necessity and proportionality of the processing operations in relation to the purposes;
(c)
an assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1; and
(d)
the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned.
8. Compliance with approved codes of conduct referred to in Article 40 by the relevant controllers or processors shall be taken into due account in assessing the impact of the processing operations performed by such controllers or processors, in particular for the purposes of a data protection impact assessment.
9. Where appropriate, the controller shall seek the views of data subjects or their representatives on the intended processing, without prejudice to the protection of commercial or public interests or the security of processing operations.
10. Where processing pursuant to point (c) or (e) of Article 6(1) has a legal basis in Union law or in the law of the Member State to which the controller is subject, that law regulates the specific processing operation or set of operations in question, and a data protection impact assessment has already been carried out as part of a general impact assessment in the context of the adoption of that legal basis, paragraphs 1 to 7 shall not apply unless Member States deem it to be necessary to carry out such an assessment prior to processing activities.
11. Where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operations.
Article 36
Prior consultation
1. The controller shall consult the supervisory authority prior to processing where a data protection impact assessment under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk.
2. Where the supervisory authority is of the opinion that the intended processing referred to in paragraph 1 would infringe this Regulation, in particular where the controller has insufficiently identified or mitigated the risk, the supervisory authority shall, within period of up to eight weeks of receipt of the request for consultation, provide written advice to the controller and, where applicable to the processor, and may use any of its powers referred to in Article 58. That period may be extended by six weeks, taking into account the complexity of the intended processing. The supervisory authority shall inform the controller and, where applicable, the processor, of any such extension within one month of receipt of the request for consultation together with the reasons for the delay. Those periods may be suspended until the supervisory authority has obtained information it has requested for the purposes of the consultation.
3. When consulting the supervisory authority pursuant to paragraph 1, the controller shall provide the supervisory authority with:
(a)
where applicable, the respective responsibilities of the controller, joint controllers and processors involved in the processing, in particular for processing within a group of undertakings;
(b)
the purposes and means of the intended processing;
(c)
the measures and safeguards provided to protect the rights and freedoms of data subjects pursuant to this Regulation;
(d)
where applicable, the contact details of the data protection officer;
(e)
the data protection impact assessment provided for in Article 35; and
(f)
any other information requested by the supervisory authority.
4. Member States shall consult the supervisory authority during the preparation of a proposal for a legislative measure to be adopted by a national parliament, or of a regulatory measure based on such a legislative measure, which relates to processing.
5. Notwithstanding paragraph 1, Member State law may require controllers to consult with, and obtain prior authorisation from, the supervisory authority in relation to processing by a controller for the performance of a task carried out by the controller in the public interest, including processing in relation to social protection and public health.
Section 4
Data protection officer
Article 37
Designation of the data protection officer
1. The controller and the processor shall designate a data protection officer in any case where:
(a)
the processing is carried out by a public authority or body, except for courts acting in their judicial capacity;
(b)
the core activities of the controller or the processor consist of processing operations which, by virtue of their nature, their scope and/or their purposes, require regular and systematic monitoring of data subjects on a large scale; or
(c)
the core activities of the controller or the processor consist of processing on a large scale of special categories of data pursuant to Article 9 and personal data relating to criminal convictions and offences referred to in Article 10.
2. A group of undertakings may appoint a single data protection officer provided that a data protection officer is easily accessible from each establishment.
3. Where the controller or the processor is a public authority or body, a single data protection officer may be designated for several such authorities or bodies, taking account of their organisational structure and size.
4. In cases other than those referred to in paragraph 1, the controller or processor or associations and other bodies representing categories of controllers or processors may or, where required by Union or Member State law shall, designate a data protection officer. The data protection officer may act for such associations and other bodies representing controllers or processors.
5. The data protection officer shall be designated on the basis of professional qualities and, in particular, expert knowledge of data protection law and practices and the ability to fulfil the tasks referred to in Article 39.
6. The data protection officer may be a staff member of the controller or processor, or fulfil the tasks on the basis of a service contract.
7. The controller or the processor shall publish the contact details of the data protection officer and communicate them to the supervisory authority.
Article 38
Position of the data protection officer
1. The controller and the processor shall ensure that the data protection officer is involved, properly and in a timely manner, in all issues which relate to the protection of personal data.
2. The controller and processor shall support the data protection officer in performing the tasks referred to in Article 39 by providing resources necessary to carry out those tasks and access to personal data and processing operations, and to maintain his or her expert knowledge.
3. The controller and processor shall ensure that the data protection officer does not receive any instructions regarding the exercise of those tasks. He or she shall not be dismissed or penalised by the controller or the processor for performing his tasks. The data protection officer shall directly report to the highest management level of the controller or the processor.
4. Data subjects may contact the data protection officer with regard to all issues related to processing of their personal data and to the exercise of their rights under this Regulation.
5. The data protection officer shall be bound by secrecy or confidentiality concerning the performance of his or her tasks, in accordance with Union or Member State law.
6. The data protection officer may fulfil other tasks and duties. The controller or processor shall ensure that any such tasks and duties do not result in a conflict of interests.
Article 39
Tasks of the data protection officer
1. The data protection officer shall have at least the following tasks:
(a)
to inform and advise the controller or the processor and the employees who carry out processing of their obligations pursuant to this Regulation and to other Union or Member State data protection provisions;
(b)
to monitor compliance with this Regulation, with other Union or Member State data protection provisions and with the policies of the controller or processor in relation to the protection of personal data, including the assignment of responsibilities, awareness-raising and training of staff involved in processing operations, and the related audits;
(c)
to provide advice where requested as regards the data protection impact assessment and monitor its performance pursuant to Article 35;
(d)
to cooperate with the supervisory authority;
(e)
to act as the contact point for the supervisory authority on issues relating to processing, including the prior consultation referred to in Article 36, and to consult, where appropriate, with regard to any other matter.
2. The data protection officer shall in the performance of his or her tasks have due regard to the risk associated with processing operations, taking into account the nature, scope, context and purposes of processing.
Section 5
Codes of conduct and certification
Article 40
Codes of conduct
1. The Member States, the supervisory authorities, the Board and the Commission shall encourage the drawing up of codes of conduct intended to contribute to the proper application of this Regulation, taking account of the specific features of the various processing sectors and the specific needs of micro, small and medium-sized enterprises.
2. Associations and other bodies representing categories of controllers or processors may prepare codes of conduct, or amend or extend such codes, for the purpose of specifying the application of this Regulation, such as with regard to:
(a)
fair and transparent processing;
(b)
the legitimate interests pursued by controllers in specific contexts;
(c)
the collection of personal data;
(d)
the pseudonymisation of personal data;
(e)
the information provided to the public and to data subjects;
(f)
the exercise of the rights of data subjects;
(g)
the information provided to, and the protection of, children, and the manner in which the consent of the holders of parental responsibility over children is to be obtained;
(h)
the measures and procedures referred to in Articles 24 and 25 and the measures to ensure security of processing referred to in Article 32;
(i)
the notification of personal data breaches to supervisory authorities and the communication of such personal data breaches to data subjects;
(j)
the transfer of personal data to third countries or international organisations; or
(k)
out-of-court proceedings and other dispute resolution procedures for resolving disputes between controllers and data subjects with regard to processing, without prejudice to the rights of data subjects pursuant to Articles 77 and 79.
3. In addition to adherence by controllers or processors subject to this Regulation, codes of conduct approved pursuant to paragraph 5 of this Article and having general validity pursuant to paragraph 9 of this Article may also be adhered to by controllers or processors that are not subject to this Regulation pursuant to Article 3 in order to provide appropriate safeguards within the framework of personal data transfers to third countries or international organisations under the terms referred to in point (e) of Article 46(2). Such controllers or processors shall make binding and enforceable commitments, via contractual or other legally binding instruments, to apply those appropriate safeguards including with regard to the rights of data subjects.
4. A code of conduct referred to in paragraph 2 of this Article shall contain mechanisms which enable the body referred to in Article 41(1) to carry out the mandatory monitoring of compliance with its provisions by the controllers or processors which undertake to apply it, without prejudice to the tasks and powers of supervisory authorities competent pursuant to Article 55 or 56.
5. Associations and other bodies referred to in paragraph 2 of this Article which intend to prepare a code of conduct or to amend or extend an existing code shall submit the draft code, amendment or extension to the supervisory authority which is competent pursuant to Article 55. The supervisory authority shall provide an opinion on whether the draft code, amendment or extension complies with this Regulation and shall approve that draft code, amendment or extension if it finds that it provides sufficient appropriate safeguards.
6. Where the draft code, or amendment or extension is approved in accordance with paragraph 5, and where the code of conduct concerned does not relate to processing activities in several Member States, the supervisory authority shall register and publish the code.
7. Where a draft code of conduct relates to processing activities in several Member States, the supervisory authority which is competent pursuant to Article 55 shall, before approving the draft code, amendment or extension, submit it in the procedure referred to in Article 63 to the Board which shall provide an opinion on whether the draft code, amendment or extension complies with this Regulation or, in the situation referred to in paragraph 3 of this Article, provides appropriate safeguards.
8. Where the opinion referred to in paragraph 7 confirms that the draft code, amendment or extension complies with this Regulation, or, in the situation referred to in paragraph 3, provides appropriate safeguards, the Board shall submit its opinion to the Commission.
9. The Commission may, by way of implementing acts, decide that the approved code of conduct, amendment or extension submitted to it pursuant to paragraph 8 of this Article have general validity within the Union. Those implementing acts shall be adopted in accordance with the examination procedure set out in Article 93(2).
10. The Commission shall ensure appropriate publicity for the approved codes which have been decided as having general validity in accordance with paragraph 9.
11. The Board shall collate all approved codes of conduct, amendments and extensions in a register and shall make them publicly available by way of appropriate means.
Article 41
Monitoring of approved codes of conduct
1. Without prejudice to the tasks and powers of the competent supervisory authority under Articles 57 and 58, the monitoring of compliance with a code of conduct pursuant to Article 40 may be carried out by a body which has an appropriate level of expertise in relation to the subject-matter of the code and is accredited for that purpose by the competent supervisory authority.
2. A body as referred to in paragraph 1 may be accredited to monitor compliance with a code of conduct where that body has:
(a)
demonstrated its independence and expertise in relation to the subject-matter of the code to the satisfaction of the competent supervisory authority;
(b)
established procedures which allow it to assess the eligibility of controllers and processors concerned to apply the code, to monitor their compliance with its provisions and to periodically review its operation;
(c)
established procedures and structures to handle complaints about infringements of the code or the manner in which the code has been, or is being, implemented by a controller or processor, and to make those procedures and structures transparent to data subjects and the public; and
(d)
demonstrated to the satisfaction of the competent supervisory authority that its tasks and duties do not result in a conflict of interests.
3. The competent supervisory authority shall submit the draft criteria for accreditation of a body as referred to in paragraph 1 of this Article to the Board pursuant to the consistency mechanism referred to in Article 63.
4. Without prejudice to the tasks and powers of the competent supervisory authority and the provisions of Chapter VIII, a body as referred to in paragraph 1 of this Article shall, subject to appropriate safeguards, take appropriate action in cases of infringement of the code by a controller or processor, including suspension or exclusion of the controller or processor concerned from the code. It shall inform the competent supervisory authority of such actions and the reasons for taking them.
5. The competent supervisory authority shall revoke the accreditation of a body as referred to in paragraph 1 if the conditions for accreditation are not, or are no longer, met or where actions taken by the body infringe this Regulation.
6. This Article shall not apply to processing carried out by public authorities and bodies.
Article 42
Certification
1. The Member States, the supervisory authorities, the Board and the Commission shall encourage, in particular at Union level, the establishment of data protection certification mechanisms and of data protection seals and marks, for the purpose of demonstrating compliance with this Regulation of processing operations by controllers and processors. The specific needs of micro, small and medium-sized enterprises shall be taken into account.
2. In addition to adherence by controllers or processors subject to this Regulation, data protection certification mechanisms, seals or marks approved pursuant to paragraph 5 of this Article may be established for the purpose of demonstrating the existence of appropriate safeguards provided by controllers or processors that are not subject to this Regulation pursuant to Article 3 within the framework of personal data transfers to third countries or international organisations under the terms referred to in point (f) of Article 46(2). Such controllers or processors shall make binding and enforceable commitments, via contractual or other legally binding instruments, to apply those appropriate safeguards, including with regard to the rights of data subjects.
3. The certification shall be voluntary and available via a process that is transparent.
4. A certification pursuant to this Article does not reduce the responsibility of the controller or the processor for compliance with this Regulation and is without prejudice to the tasks and powers of the supervisory authorities which are competent pursuant to Article 55 or 56.
5. A certification pursuant to this Article shall be issued by the certification bodies referred to in Article 43 or by the competent supervisory authority, on the basis of criteria approved by that competent supervisory authority pursuant to Article 58(3) or by the Board pursuant to Article 63. Where the criteria are approved by the Board, this may result in a common certification, the European Data Protection Seal.
6. The controller or processor which submits its processing to the certification mechanism shall provide the certification body referred to in Article 43, or where applicable, the competent supervisory authority, with all information and access to its processing activities which are necessary to conduct the certification procedure.
7. Certification shall be issued to a controller or processor for a maximum period of three years and may be renewed, under the same conditions, provided that the relevant requirements continue to be met. Certification shall be withdrawn, as applicable, by the certification bodies referred to in Article 43 or by the competent supervisory authority where the requirements for the certification are not or are no longer met.
8. The Board shall collate all certification mechanisms and data protection seals and marks in a register and shall make them publicly available by any appropriate means.
Article 43
Certification bodies
1. Without prejudice to the tasks and powers of the competent supervisory authority under Articles 57 and 58, certification bodies which have an appropriate level of expertise in relation to data protection shall, after informing the supervisory authority in order to allow it to exercise its powers pursuant to point (h) of Article 58(2) where necessary, issue and renew certification. Member States shall ensure that those certification bodies are accredited by one or both of the following:
(a)
the supervisory authority which is competent pursuant to Article 55 or 56;
(b)
the national accreditation body named in accordance with Regulation (EC) No 765/2008 of the European Parliament and of the Council (20) in accordance with EN-ISO/IEC 17065/2012 and with the additional requirements established by the supervisory authority which is competent pursuant to Article 55 or 56.
2. Certification bodies referred to in paragraph 1 shall be accredited in accordance with that paragraph only where they have:
(a)
demonstrated their independence and expertise in relation to the subject-matter of the certification to the satisfaction of the competent supervisory authority;
(b)
undertaken to respect the criteria referred to in Article 42(5) and approved by the supervisory authority which is competent pursuant to Article 55 or 56 or by the Board pursuant to Article 63;
(c)
established procedures for the issuing, periodic review and withdrawal of data protection certification, seals and marks;
(d)
established procedures and structures to handle complaints about infringements of the certification or the manner in which the certification has been, or is being, implemented by the controller or processor, and to make those procedures and structures transparent to data subjects and the public; and
(e)
demonstrated, to the satisfaction of the competent supervisory authority, that their tasks and duties do not result in a conflict of interests.
3. The accreditation of certification bodies as referred to in paragraphs 1 and 2 of this Article shall take place on the basis of criteria approved by the supervisory authority which is competent pursuant to Article 55 or 56 or by the Board pursuant to Article 63. In the case of accreditation pursuant to point (b) of paragraph 1 of this Article, those requirements shall complement those envisaged in Regulation (EC) No 765/2008 and the technical rules that describe the methods and procedures of the certification bodies.
4. The certification bodies referred to in paragraph 1 shall be responsible for the proper assessment leading to the certification or the withdrawal of such certification without prejudice to the responsibility of the controller or processor for compliance with this Regulation. The accreditation shall be issued for a maximum period of five years and may be renewed on the same conditions provided that the certification body meets the requirements set out in this Article.
5. The certification bodies referred to in paragraph 1 shall provide the competent supervisory authorities with the reasons for granting or withdrawing the requested certification.
6. The requirements referred to in paragraph 3 of this Article and the criteria referred to in Article 42(5) shall be made public by the supervisory authority in an easily accessible form. The supervisory authorities shall also transmit those requirements and criteria to the Board. The Board shall collate all certification mechanisms and data protection seals in a register and shall make them publicly available by any appropriate means.
7. Without prejudice to Chapter VIII, the competent supervisory authority or the national accreditation body shall revoke an accreditation of a certification body pursuant to paragraph 1 of this Article where the conditions for the accreditation are not, or are no longer, met or where actions taken by a certification body infringe this Regulation.
8. The Commission shall be empowered to adopt delegated acts in accordance with Article 92 for the purpose of specifying the requirements to be taken into account for the data protection certification mechanisms referred to in Article 42(1).
9. The Commission may adopt implementing acts laying down technical standards for certification mechanisms and data protection seals and marks, and mechanisms to promote and recognise those certification mechanisms, seals and marks. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 93(2).
Article 29 Guidance on Data Impact Assessment
ARTICLE 29 DATA PROTECTION WORKING PARTY
This Working Party was set up under Article 29 of Directive 95/46/EC. It is an independent European advisory body on data
protection and privacy. Its tasks are described in Article 30 of Directive 95/46/EC and Article 15 of Directive 2002/58/EC.
The secretariat is provided by Directorate C (Fundamental Rights and Union Citizenship) of the European Commission,
Directorate General Justice, B-1049 Brussels, Belgium, Office No MO-59 03/075.
Website: http://ec.europa.eu/justice/data-protection/index_en.htm
17/EN
WP 248 rev.01
Guidelines on Data Protection Impact Assessment (DPIA) and determining whether
processing is “likely to result in a high risk” for the purposes of Regulation 2016/679
Adopted on 4 April 2017
As last Revised and Adopted on 4 October 2017
2
THE WORKING PARTY ON THE PROTECTION OF INDIVIDUALS WITH REGARD TO THE
PROCESSING OF PERSONAL DATA
set up by Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995,
having regard to Articles 29 and 30 thereof,
having regard to its Rules of Procedure,
HAS ADOPTED THE PRESENT GUIDELINES:
I. Introduction
Regulation 2016/6791 (GDPR) will apply from 25 May 2018. Article 35 of the GDPR introduces the
concept of a Data Protection Impact Assessment (DPIA2), as does Directive 2016/6803.
A DPIA is a process designed to describe the processing, assess its necessity and proportionality and
help manage the risks to the rights and freedoms of natural persons resulting from the processing of
personal data4 by assessing them and determining the measures to address them. DPIAs are important
tools for accountability, as they help controllers not only to comply with requirements of the GDPR,
but also to demonstrate that appropriate measures have been taken to ensure compliance with the
Regulation (see also article 24)5. In other words, a DPIA is a process for building and
demonstrating compliance.
Under the GDPR, non-compliance with DPIA requirements can lead to fines imposed by the
competent supervisory authority. Failure to carry out a DPIA when the processing is subject to a DPIA
(Article 35(1) and (3)-(4)), carrying out a DPIA in an incorrect way (Article 35(2) and (7) to (9)), or
failing to consult the competent supervisory authority where required (Article 36(3)(e)), can result in
an administrative fine of up to 10M€, or in the case of an undertaking, up to 2 % of the total
worldwide annual turnover of the preceding financial year, whichever is higher.
II. Scope of the Guidelines
1
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of
natural persons with regard to the processing of personal data and on the free movement of such data, and
repealing Directive 95/46/EC (General Data Protection Regulation).
2
The term “Privacy Impact Assessment” (PIA) is often used in other contexts to refer to the same concept.
3 Article 27 of the Directive (EU) 2016/680 of the European Parliament and of the Council of 27 April 2016 on
the protection of natural persons with regard to the processing of personal data by competent authorities for the
purposes of the prevention, investigation, detection or prosecution of criminal offences or the execution of
criminal penalties, and on the free movement of such data, also states that a privacy impact assessment is needed
for “the processing is likely to result in a high risk to the rights and freedoms ofnatural persons”.
4 The GDPR does not formally define the concept of a DPIA as such, but
– its minimal content is specified by Article 35(7) as follows:
o “(a) a systematic description of the envisaged processing operations and the purposes of the
processing, including, where applicable, the legitimate interest pursued by the controller;
o (b) an assessment of the necessity and proportionality of the processing operations in relation
to the purposes;
o (c) an assessment of the risks to the rights and freedoms of data subjects referred to in
paragraph 1; and
o (d) the measures envisaged to address the risks, including safeguards, security measures and
mechanisms to ensure the protection of personal data and to demonstrate compliance with this
Regulation taking into account the rights and legitimate interests of data subjects and other
persons concerned”;
– its meaning and role is clarified by recital 84 as follows: “In order to enhance compliance with this
Regulation where processing operations are likely to result in a high risk to the rights and freedoms of
natural persons, the controller should be responsible for the carrying-out of a data protection impact
assessment to evaluate, in particular, the origin, nature, particularity and severity of that risk”.
5 See also recital 84: “The outcome of the assessment should be taken into account when determining the
appropriate measures to be taken in order to demonstrate that the processing of personal data complies with this
Regulation”.
5
These Guidelines take account of:
– the Article 29 Data Protection Working Party (WP29) Statement 14/EN WP 2186;
– the WP29 Guidelines on Data Protection Officer 16/EN WP 2437;
– the WP29 Opinion on Purpose limitation 13/EN WP 203 8;
– international standards9.
In line with the risk-based approach embodied by the GDPR, carrying out a DPIA is not mandatory for
every processing operation. A DPIA is only required when the processing is “likely to result in a high
risk to the rights and freedoms of natural persons” (Article 35(1)). In order to ensure a consistent
interpretation of the circumstances in which a DPIA is mandatory (Article 35(3)), the present
guidelines firstly aim to clarify this notion and provide criteria for the lists to be adopted by Data
Protection Authorities (DPAs) under Article 35(4).
According to Article 70(1)(e), the European Data Protection Board (EDPB) will be able to issue
guidelines, recommendations and best practices in order to encourage a consistent application of the
GDPR. The purpose of this document is to anticipate such future work of the EDPB and therefore to
clarify the relevant provisions of the GDPR in order to help controllers to comply with the law and to
provide legal certainty for controllers who are required to carry out a DPIA.
These Guidelines also seek to promote the development of:
– a common European Union list of processing operations for which a DPIA is mandatory
(Article 35(4));
– a common EU list of processing operations for which a DPIA is not necessary (Article 35(5));
– common criteria on the methodology for carrying out a DPIA (Article 35(5));
– common criteria for specifying when the supervisory authority shall be consulted
(Article 36(1));
– recommendations, where possible, building on the experience gained in EU Member States.
6
WP29 Statement 14/EN WP 218 on the role of a risk-based approach to data protection legal frameworks
adopted on 30 May 2014.
http://ec.europa.eu/justice/data-protection/article-29/documentation/opinionrecommendation/files/2014/wp218_en.pdf?wb48617274=72C54532
7
WP29 Guidelines on Data Protection Officer 16/EN WP 243 Adopted on 13 December 2016.
http://ec.europa.eu/information_society/newsroom/image/document/2016-
51/wp243_en_40855.pdf?wb48617274=CD63BD9A
8
WP29 Opinion 03/2013 on purpose limitation 13/EN WP 203Adopted on 2 April 2013.
http://ec.europa.eu/justice/data-protection/article-29/documentation/opinionrecommendation/files/2013/wp203_en.pdf?wb48617274=39E0E409
9 e.g. ISO 31000:2009, Risk management — Principles and guidelines, International Organization for
Standardization (ISO) ; ISO/IEC 29134 (project), Information technology – Security techniques – Privacy impact
assessment – Guidelines, International Organization for Standardization (ISO).
6
III. DPIA: the Regulation explained
The GDPR requires controllers to implement appropriate measures to ensure and be able to
demonstrate compliance with the GDPR, taking into account among others the “the risks of varying
likelihood and severity for the rights and freedoms of natural persons” (article 24 (1)). The obligation
for controllers to conduct a DPIA in certain circumstances should be understood against the
background of their general obligation to appropriately manage risks10 presented by the processing of
personal data.
A “risk” is a scenario describing an event and its consequences, estimated in terms of severity and
likelihood. “Risk management”, on the other hand, can be defined as the coordinated activities to
direct and control an organization with regard to risk.
Article 35 refers to a likely high risk “to the rights and freedoms of individuals”. As indicated in the
Article 29 Data Protection Working Party Statement on the role of a risk-based approach in data
protection legal frameworks, the reference to “the rights and freedoms” of data subjects primarily
concerns the rights to data protection and privacy but may also involve other fundamental rights such
as freedom of speech, freedom of thought, freedom of movement, prohibition of discrimination, right
to liberty, conscience and religion.
In line with the risk-based approach embodied by the GDPR, carrying out a DPIA is not mandatory for
every processing operation. Instead, a DPIA is only required where a type of processing is “likely to
result in a high risk to the rights and freedoms of natural persons” (Article 35(1)). The mere fact that
the conditions triggering the obligation to carry out DPIA have not been met does not, however,
diminish controllers’ general obligation to implement measures to appropriately manage risks for the
rights and freedoms of data subjects. In practice, this means that controllers must continuously assess
the risks created by their processing activities in order to identify when a type of processing is “likely
to result in a high risk to the rights and freedoms of natural persons”.
10 It has to be stressed that in order to manage the risks to the rights and freedoms of natural persons, the risks
have to identified, analyzed, estimated, evaluated, treated (e.g. mitigated…), and reviewed regularly. Controllers
cannot escape their responsibility by covering risks under insurance policies.
7
The following figure illustrates the basic principles related to the DPIA in the GDPR:
A. What does a DPIA address?
A single processing operation or a set of similar
processing operations.
A DPIA may concern a single data processing operation. However, Article 35(1) states that “a
single assessment may address a set of similar processing operations that present similar high risks”.
Recital 92 adds that “there are circumstances under which it may be reasonable and economical for
the subject of a data protection impact assessment to be broader than a single project, for example
where public authorities or bodies intend to establish a common application or processing platform or
where several controllers plan to introduce a common application or processing environment across
an industry sector or segment or for a widely used horizontal activity”.
A single DPIA could be used to assess multiple processing operations that are similar in terms of
nature, scope, context, purpose, and risks. Indeed, DPIAs aim at systematically studying new
situations that could lead to high risks on the rights and freedoms of natural persons, and there is no
need to carry out a DPIA in cases (i.e. processing operations performed in a specific context and for a
specific purpose) that have already been studied. This might be the case where similar technology is
used to collect the same sort of data for the same purposes. For example, a group of municipal
authorities that are each setting up a similar CCTV system could carry out a single DPIA covering the
processing by these separate controllers, or a railway operator (single controller) could cover video
surveillance in all its train stations with one DPIA. This may also be applicable to similar processing
operations implemented by various data controllers. In those cases, a reference DPIA should be shared
or made publicly accessible, measures described in the DPIA must be implemented, and a justification
for conducting a single DPIA has to be provided.
When the processing operation involves joint controllers, they need to define their respective
obligations precisely. Their DPIA should set out which party is responsible for the various measures
8
designed to treat risks and to protect the rights and freedoms of the data subjects. Each data controller
should express his needs and share useful information without either compromising secrets (e.g.:
protection of trade secrets, intellectual property, confidential business information) or disclosing
vulnerabilities.
A DPIA can also be useful for assessing the data protection impact of a technology product, for
example a piece of hardware or software, where this is likely to be used by different data controllers to
carry out different processing operations. Of course, the data controller deploying the product remains
obliged to carry out its own DPIA with regard to the specific implementation, but this can be informed
by a DPIA prepared by the product provider, if appropriate. An example could be the relationship
between manufacturers of smart meters and utility companies. Each product provider or processor
should share useful information without neither compromising secrets nor leading to security risks by
disclosing vulnerabilities.
B. Which processing operations are subject to a DPIA?
Apart from exceptions, where
they are “likely to result in a high risk”.
This section describes when a DPIA is mandatory, and when it is not necessary to carry out a DPIA.
Unless the processing operation meets an exception (III.B.a), a DPIA has to be carried out where
a processing operation is “likely to result in a high risk” (III.B.b).
a) When is a DPIA mandatory?
When processing is “likely to result in a high risk”.
The GDPR does not require a DPIA to be carried out for every processing operation which may result
in risks for the rights and freedoms of natural persons. The carrying out of a DPIA is only mandatory
where processing is “likely to result in a high risk to the rights and freedoms of natural persons”
(Article 35(1), illustrated by Article 35(3) and complemented by Article 35(4)). It is particularly
relevant when a new data processing technology is being introduced11.
In cases where it is not clear whether a DPIA is required, the WP29 recommends that a DPIA is
carried out nonetheless as a DPIA is a useful tool to help controllers comply with data protection law.
Even though a DPIA could be required in other circumstances, Article 35(3) provides some examples
when a processing operation is “likely to result in high risks”:
– “(a) a systematic and extensive evaluation of personal aspects relating to natural persons
which is based on automated processing, including profiling, and on which decisions are
based that produce legal effects concerning the natural person or similarly significantly affect
the natural person12;
– (b) processing on a large scale of special categories of data referred to in Article 9(1), or of
personal data relating to criminal convictions and offences referred to in Article 1013; or
– (c) a systematic monitoring of a publicly accessible area on a large scale”.
11 See recitals 89, 91 and Article 35(1) and (3) for further examples.
12 See recital 71: “in particular analysing or predicting aspects concerning performance at work, economic
situation, health, personal preferences or interests, reliability or behaviour, location or movements, in order to
create or use personal profiles”.
13 See recital 75: “where personal data are processed which reveal racial or ethnic origin, political opinions,
religion or philosophical beliefs, trade union membership, and the processing of genetic data, data concerning
health or data concerning sex life or criminal convictions and offences or related security measures”.
9
As the words “in particular” in the introductory sentence of Article 35(3) GDPR indicate, this is
meant as a non-exhaustive list. There may be “high risk” processing operations that are not captured
by this list, but yet pose similarly high risks. Those processing operations should also be subject to
DPIAs. For this reason, the criteria developed below sometimes go beyond a simple explanation of
what should be understood by the three examples given in Article 35(3) GDPR.
In order to provide a more concrete set of processing operations that require a DPIA due to their
inherent high risk, taking into account the particular elements of Articles 35(1) and 35(3)(a) to (c), the
list to be adopted at the national level under article 35(4) and recitals 71 , 75 and 91, and other GDPR
references to “likely to result in a high risk” processing operations14, the following nine criteria should
be considered.
1. Evaluation or scoring, including profiling and predicting, especially from “aspects concerning
the data subject’s performance at work, economic situation, health, personal preferences or
interests, reliability or behavior, location or movements” (recitals 71 and 91). Examples of
this could include a financial institution that screens its customers against a credit reference
database or against an anti-money laundering and counter-terrorist financing (AML/CTF) or
fraud database, or a biotechnology company offering genetic tests directly to consumers in
order to assess and predict the disease/health risks, or a company building behavioural or
marketing profiles based on usage or navigation on its website.
2. Automated-decision making with legal or similar significant effect: processing that aims at
taking decisions on data subjects producing “legal effects concerning the natural person” or
which “similarly significantly affects the natural person” (Article 35(3)(a)). For example, the
processing may lead to the exclusion or discrimination against individuals. Processing with
little or no effect on individuals does not match this specific criterion. Further explanations on
these notions will be provided in the upcoming WP29 Guidelines on Profiling.
3. Systematic monitoring: processing used to observe, monitor or control data subjects, including
data collected through networks or “a systematic monitoring of a publicly accessible area”
(Article 35(3)(c))15. This type of monitoring is a criterion because the personal data may be
collected in circumstances where data subjects may not be aware of who is collecting their
data and how they will be used. Additionally, it may be impossible for individuals to avoid
being subject to such processing in public (or publicly accessible) space(s).
4. Sensitive data or data of a highly personal nature: this includes special categories of personal
data as defined in Article 9 (for example information about individuals’ political opinions), as
well as personal data relating to criminal convictions or offences as defined in Article 10. An
example would be a general hospital keeping patients’ medical records or a private
investigator keeping offenders’ details. Beyond these provisions of the GDPR, some
categories of data can be considered as increasing the possible risk to the rights and freedoms
14 See e.g. recitals 75, 76, 92, 116.
15 The WP29 interprets “systematic” as meaning one or more of the following (see the WP29 Guidelines on Data
Protection Officer 16/EN WP 243):
– occurring according to a system;
– pre-arranged, organised or methodical;
– taking place as part of a general plan for data collection;
– carried out as part of a strategy.
The WP29 interprets “publicly accessible area” as being any place open to any member of the public, for
example a piazza, a shopping centre, a street, a market place, a train station or a public library.
10
of individuals. These personal data are considered as sensitive (as this term is commonly
understood) because they are linked to household and private activities (such as electronic
communications whose confidentiality should be protected), or because they impact the
exercise of a fundamental right (such as location data whose collection questions the freedom
of movement) or because their violation clearly involves serious impacts in the data subject’s
daily life (such as financial data that might be used for payment fraud). In this regard, whether
the data has already been made publicly available by the data subject or by third parties may
be relevant. The fact that personal data is publicly available may be considered as a factor in
the assessment if the data was expected to be further used for certain purposes. This criterion
may also include data such as personal documents, emails, diaries, notes from e-readers
equipped with note-taking features, and very personal information contained in life-logging
applications.
5. Data processed on a large scale: the GDPR does not define what constitutes large-scale,
though recital 91 provides some guidance. In any event, the WP29 recommends that the
following factors, in particular, be considered when determining whether the processing is
carried out on a large scale16:
a. the number of data subjects concerned, either as a specific number or as a proportion
of the relevant population;
b. the volume of data and/or the range of different data items being processed;
c. the duration, or permanence, of the data processing activity;
d. the geographical extent of the processing activity.
6. Matching or combining datasets, for example originating from two or more data processing
operations performed for different purposes and/or by different data controllers in a way that
would exceed the reasonable expectations of the data subject17.
7. Data concerning vulnerable data subjects (recital 75): the processing of this type of data is a
criterion because of the increased power imbalance between the data subjects and the data
controller, meaning the individuals may be unable to easily consent to, or oppose, the
processing of their data, or exercise their rights. Vulnerable data subjects may include children
(they can be considered as not able to knowingly and thoughtfully oppose or consent to the
processing of their data), employees , more vulnerable segments of the population requiring
special protection (mentally ill persons, asylum seekers, or the elderly, patients, etc.), and in
any case where an imbalance in the relationship between the position of the data subject and
the controller can be identified.
8. Innovative use or applying new technological or organisational solutions, like combining use
of finger print and face recognition for improved physical access control, etc. The GDPR
makes it clear (Article 35(1) and recitals 89 and 91) that the use of a new technology, defined
in “accordance with the achieved state of technological knowledge” (recital 91), can trigger
the need to carry out a DPIA. This is because the use of such technology can involve novel
forms of data collection and usage, possibly with a high risk to individuals’ rights and
freedoms. Indeed, the personal and social consequences of the deployment of a new
technology may be unknown. A DPIA will help the data controller to understand and to treat
such risks. For example, certain “Internet of Things” applications could have a significant
impact on individuals’ daily lives and privacy; and therefore require a DPIA.
16 See the WP29 Guidelines on Data Protection Officer 16/EN WP 243.
17 See explanation in the WP29 Opinion on Purpose limitation 13/EN WP 203, p.24.
11
9. When the processing in itself “prevents data subjects from exercising a right or using a
service or a contract” (Article 22 and recital 91). This includes processing operations that
aims at allowing, modifying or refusing data subjects’ access to a service or entry into a
contract. An example of this is where a bank screens its customers against a credit reference
database in order to decide whether to offer them a loan.
In most cases, a data controller can consider that a processing meeting two criteria would require a
DPIA to be carried out. In general, the WP29 considers that the more criteria are met by the
processing, the more likely it is to present a high risk to the rights and freedoms of data subjects, and
therefore to require a DPIA, regardless of the measures which the controller envisages to adopt.
However, in some cases, a data controller can consider that a processing meeting only one of
these criteria requires a DPIA.
The following examples illustrate how the criteria should be used to assess whether a particular
processing operation requires a DPIA:
Examples of processing Possible Relevant criteria
DPIA
likely to be
required?
A hospital processing its patients’ genetic and
health data (hospital information system).
– Sensitive data or data of a highly personal
nature.
– Data concerning vulnerable data subjects.
– Data processed on a large-scale.
Yes
The use of a camera system to monitor driving
behavior on highways. The controller envisages to
use an intelligent video analysis system to single
out cars and automatically recognize license plates.
– Systematic monitoring.
– Innovative use or applying technological
or organisational solutions.
A company systematically monitoring its
employees’ activities, including the monitoring of
the employees’ work station, internet activity, etc.
– Systematic monitoring.
– Data concerning vulnerable data subjects.
The gathering of public social media data for
generating profiles.
– Evaluation or scoring.
– Data processed on a large scale.
– Matching or combining of datasets.
– Sensitive data or data of a highly personal
nature:
An institution creating a national level credit rating
or fraud database.
– Evaluation or scoring.
– Automated decision making with legal or
similar significant effect.
– Prevents data subject from exercising a
right or using a service or a contract.
– Sensitive data or data of a highly personal
nature:
Storage for archiving purpose of pseudonymised
personal sensitive data concerning vulnerable data
subjects of research projects or clinical trials
– Sensitive data.
– Data concerning vulnerable data subjects.
– Prevents data subjects from exercising a
right or using a service or a contract.
12
Examples of processing Possible Relevant criteria
DPIA
likely to be
required?
A processing of “personal data from patients or
clients by an individual physician, other health care
professional or lawyer” (Recital 91).
– Sensitive data or data of a highly personal
nature.
– Data concerning vulnerable data subjects.
No
An online magazine using a mailing list to send a
generic daily digest to its subscribers. – Data processed on a large scale.
An e-commerce website displaying adverts for
vintage car parts involving limited profiling based
on items viewed or purchased on its own website.
– Evaluation or scoring.
Conversely, a processing operation may correspond to the above mentioned cases and still be
considered by the controller not to be “likely to result in a high risk”. In such cases the
controller should justify and document the reasons for not carrying out a DPIA, and
include/record the views of the data protection officer.
In addition, as part of the accountability principle, every data controller “shall maintain a record of
processing activities under its responsibility” including inter alia the purposes of processing, a
description of the categories of data and recipients of the data and “where possible, a general
description of the technical and organisational security measures referred to in Article 32(1)” (Article
30(1)) and must assess whether a high risk is likely, even if they ultimately decide not to carry out a
DPIA.
Note: supervisory authorities are required to establish, make public and communicate a list of the
processing operations that require a DPIA to the European Data Protection Board (EDPB) (Article
35(4))18. The criteria set out above can help supervisory authorities to constitute such a list, with more
specific content added in time if appropriate. For example, the processing of any type of biometric
data or that of children could also be considered as relevant for the development of a list pursuant to
article 35(4).
b) When isn’t a DPIA required?
When the processing is not “likely to result in a high
risk”, or a similar DPIA exists, or it has been authorized prior to May 2018, or it has a
legal basis, or it is in the list of processing operations for which a DPIA is not
required.
WP29 considers that a DPIA is not required in the following cases:
– where the processing is not “likely to result in a high risk to the rights and freedoms of
natural persons” (Article 35(1));
– when the nature, scope, context and purposes of the processing are very similar to the
processing for which DPIA have been carried out. In such cases, results of DPIA for
similar processing can be used (Article 35(1)19);
18
In that context, “the competent supervisory authority shall apply the consistency mechanism referred to in
Article 63 where such lists involve processing activities which are related to the offering of goods or services to
data subjects or to the monitoring of their behaviour in several Member States, or may substantially affect the
free movement of personal data within the Union” (Article 35(6)).
19
”A single assessment may address a set of similar processing operations that present similar high risks”.
13
– when the processing operations have been checked by a supervisory authority before May
2018 in specific conditions that have not changed20 (see III.C);
– where a processing operation, pursuant to point (c) or (e) of article 6(1), has a legal basis in
EU or Member State law, where the law regulates the specific processing operation and
where a DPIA has already been carried out as part of the establishment of that legal basis
(Article 35(10))21, except if a Member state has stated it to be necessary to carry out a DPIA
prior processing activities;
– where the processing is included on the optional list (established by the supervisory
authority) of processing operations for which no DPIA is required (Article 35(5)). Such a
list may contain processing activities that comply with the conditions specified by this
authority, in particular through guidelines, specific decisions or authorizations, compliance
rules, etc. (e.g. in France, authorizations, exemptions, simplified rules, compliance packs…).
In such cases, and subject to re-assessment by the competent supervisory authority, a DPIA is
not required, but only if the processing falls strictly within the scope of the relevant procedure
mentioned in the list and continues to comply fully with all the relevant requirements of the
GDPR.
C. What about already existing processing operations?
DPIAs are required in some
circumstances.
The requirement to carry out a DPIA applies to existing processing operations likely to result in
a high risk to the rights and freedoms of natural persons and for which there has been a change
of the risks, taking into account the nature, scope, context and purposes of the processing.
A DPIA is not needed for processing operations that have been checked by a supervisory authority or
the data protection official, in accordance with Article 20 of Directive 95/46/EC, and that are
performed in a way that has not changed since the prior checking. Indeed, “Commission decisions
adopted and authorisations by supervisory authorities based on Directive 95/46/EC remain in force
until amended, replaced or repealed” (recital 171).
Conversely, this means that any data processing whose conditions of implementation (scope, purpose,
personal data collected, identity of the data controllers or recipients, data retention period, technical
and organisational measures, etc.) have changed since the prior checking performed by the supervisory
authority or the data protection official and which are likely to result in a high risk should be subject to
a DPIA.
Moreover, a DPIA could be required after a change of the risks resulting from the processing
operations22, for example because a new technology has come into use or because personal data is
20
“Commission decisions adopted and authorisations by supervisory authorities based on Directive 95/46/EC
remain in force until amended, replaced or repealed” (recital 171).
21 When a DPIA is carried out at the stage of the elaboration of the legislation providing a legal basis for a
processing, it is likely to require a review before entry into operations, as the adopted legislation may differ from
the proposal in ways that affect privacy and data protection issues. Moreover, there may not be sufficient
technical details available regarding the actual processing at the time of adoption of the legislation, even if it was
accompanied by a DPIA. In such cases, it may still be necessary to carry out a specific DPIA prior to carrying
out the actual processing activities.
22 In terms of the context, the data collected, purposes, functionalities, personal data processed, recipients, data
combinations, risks (supporting assets, risk sources, potential impacts, threats, etc.), security measures and
international transfers.
14
being used for a different purpose. Data processing operations can evolve quickly and new
vulnerabilities can arise. Therefore, it should be noted that the revision of a DPIA is not only useful for
continuous improvement, but also critical to maintain the level of data protection in a changing
environment over time. A DPIA may also become necessary because the organisational or societal
context for the processing activity has changed, for example because the effects of certain automated
decisions have become more significant, or new categories of data subjects become vulnerable to
discrimination. Each of these examples could be an element that leads to a change of the risk resulting
from processing activity concerned.
Conversely, certain changes could lower the risk as well. For example, a processing operation could
evolve so that decisions are no longer automated or if a monitoring activity is no longer systematic. In
that case, the review of the risk analysis made can show that the performance of a DPIA is no longer
required.
As a matter of good practice, a DPIA should be continuously reviewed and regularly re-assessed.
Therefore, even if a DPIA is not required on 25 May 2018, it will be necessary, at the appropriate
time, for the controller to conduct such a DPIA as part of its general accountability obligations.
D. How to carry out a DPIA?
a) At what moment should a DPIA be carried out?
Prior to the processing.
The DPIA should be carried out “prior to the processing” (Articles 35(1) and 35(10), recitals 90
and 93)23. This is consistent with data protection by design and by default principles (Article 25
and recital 78). The DPIA should be seen as a tool for helping decision-making concerning the
processing.
The DPIA should be started as early as is practicable in the design of the processing operation even if
some of the processing operations are still unknown. Updating the DPIA throughout the lifecycle
project will ensure that data protection and privacy are considered and will encourage the creation of
solutions which promote compliance. It can also be necessary to repeat individual steps of the
assessment as the development process progresses because the selection of certain technical or
organizational measures may affect the severity or likelihood of the risks posed by the processing.
The fact that the DPIA may need to be updated once the processing has actually started is not a valid
reason for postponing or not carrying out a DPIA. The DPIA is an on-going process, especially where
a processing operation is dynamic and subject to ongoing change. Carrying out a DPIA is a
continual process, not a one-time exercise.
b) Who is obliged to carry out the DPIA? The controller, with the DPO and processors.
The controller is responsible for ensuring that the DPIA is carried out (Article 35(2)). Carrying
out the DPIA may be done by someone else, inside or outside the organization, but the controller
remains ultimately accountable for that task.
23 Except when it is an already existing processing that has been prior checked by the Supervisory Authority, in
which case the DPIA should be carried out before undergoing significant changes.
15
The controller must also seek the advice of the Data Protection Officer (DPO), where designated
(Article 35(2)) and this advice, and the decisions taken by the controller, should be documented within
the DPIA. The DPO should also monitor the performance of the DPIA (Article 39(1)(c)). Further
guidance is provided in the WP29 Guidelines on Data Protection Officer 16/EN WP 243.
If the processing is wholly or partly performed by a data processor, the processor should assist the
controller in carrying out the DPIA and provide any necessary information (in line with Article
28(3)(f)).
The controller must “seek the views of data subjects or their representatives” (Article 35(9)),
“where appropriate”. The WP29 considers that:
– those views could be sought through a variety of means, depending on the context (e.g. a
generic study related to the purpose and means of the processing operation, a question to the
staff representatives, or usual surveys sent to the data controller’s future customers) ensuring
that the controller has a lawful basis for processing any personal data involved in seeking such
views. Although it should be noted that consent to processing is obviously not a way for
seeking the views of the data subjects;
– if the data controller’s final decision differs from the views of the data subjects, its reasons for
going ahead or not should be documented;
– the controller should also document its justification for not seeking the views of data subjects,
if it decides that this is not appropriate, for example if doing so would compromise the
confidentiality of companies’ business plans, or would be disproportionate or impracticable.
Finally, it is good practice to define and document other specific roles and responsibilities, depending
on internal policy, processes and rules, e.g.:
– where specific business units may propose to carry out a DPIA, those units should then
provide input to the DPIA and should be involved in the DPIA validation process;
– where appropriate, it is recommended to seek the advice from independent experts of different
professions24 (lawyers, IT experts, security experts, sociologists, ethics, etc.).
– the roles and responsibilities of the processors must be contractually defined; and the DPIA
must be carried out with the processor’s help, taking into account the nature of the processing
and the information available to the processor (Article 28(3)(f));
– the Chief Information Security Officer (CISO), if appointed, as well as the DPO, could
suggest that the controller carries out a DPIA on a specific processing operation, and should
help the stakeholders on the methodology, help to evaluate the quality of the risk assessment
and whether the residual risk is acceptable, and to develop knowledge specific to the data
controller context;
– the Chief Information Security Officer (CISO), if appointed, and/or the IT department, should
provide assistance to the controller, and could propose to carry out a DPIA on a specific
processing operation, depending on security or operational needs.
c) What is the methodology to carry out a DPIA?
Different methodologies but common criteria.
24 Recommendations for a privacy impact assessment framework for the European Union, Deliverable D3:
http://www.piafproject.eu/ref/PIAF_D3_final.pdf.
16
The GDPR sets out the minimum features of a DPIA (Article 35(7), and recitals 84 and 90):
– “a description of the envisaged processing operations and the purposes of the processing”;
– “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:
o “address the risks”;
o “demonstrate compliance with this Regulation”.
The following figure illustrates the generic iterative process for carrying out a DPIA25:
Compliance with a code of conduct (Article 40) has to be taken into account (Article 35(8)) when
assessing the impact of a data processing operation. This can be useful to demonstrate that adequate
measures have been chosen or put in place, provided that the code of conduct is appropriate to the
processing operation. Certifications, seals and marks for the purpose of demonstrating compliance
with the GDPR of processing operations by controllers and processors (Article 42), as well as Binding
Corporate Rules (BCR), should be taken into account as well.
25 It should be underlined that the process depicted here is iterative: in practice, it is likely that each of the stages
is revisited multiple times before the DPIA can be completed.
17
All the relevant requirements set out in the GDPR provide a broad, generic framework for designing
and carrying out a DPIA. The practical implementation of a DPIA will depend on the requirements set
out in the GDPR which may be supplemented with more detailed practical guidance. The DPIA
implementation is therefore scalable. This means that even a small data controller can design and
implement a DPIA that is suitable for their processing operations.
Recital 90 of the GDPR outlines a number of components of the DPIA which overlap with welldefined components of risk management (e.g. ISO 3100026). In risk management terms, a DPIA aims
at “managing risks” to the rights and freedoms of natural persons, using the following processes, by:
– establishing the context: “taking into account the nature, scope, context and purposes of the
processing and the sources of the risk”;
– assessing the risks: “assess the particular likelihood and severity of the high risk”;
– treating the risks: “mitigating that risk” and “ensuring the protection of personal data”, and
“demonstrating compliance with this Regulation”.
Note: the DPIA under the GDPR is a tool for managing risks to the rights of the data subjects, and thus
takes their perspective, as is the case in certain fields (e.g. societal security). Conversely, risk
management in other fields (e.g. information security) is focused on the organization.
The GDPR provides data controllers with flexibility to determine the precise structure and form of the
DPIA in order to allow for this to fit with existing working practices. There are a number of different
established processes within the EU and worldwide which take account of the components described
in recital 90. However, whatever its form, a DPIA must be a genuine assessment of risks, allowing
controllers to take measures to address them.
Different methodologies (see Annex 1 for examples of data protection and privacy impact assessment
methodologies) could be used to assist in the implementation of the basic requirements set out in the
GDPR. In order to allow these different approaches to exist, whilst allowing controllers to comply
with the GDPR, common criteria have been identified (see Annex 2). They clarify the basic
requirements of the Regulation, but provide enough scope for different forms of implementation.
These criteria can be used to show that a particular DPIA methodology meets the standards required
by the GDPR. It is up to the data controller to choose a methodology, but this methodology
should be compliant with the criteria provided in Annex 2.
The WP29 encourages the development of sector-specific DPIA frameworks. This is because they can
draw on specific sectorial knowledge, meaning the DPIA can address the specifics of a particular type
of processing operation (e.g.: particular types of data, corporate assets, potential impacts, threats,
measures). This means the DPIA can address the issues that arise in a particular economic sector, or
when using particular technologies or carrying out particular types of processing operation.
Finally, where necessary, “the controller shall carry out a review to assess if processing is performed
in accordance with the data protection impact assessment at least when there is a change of the risk
represented by processing operation” (Article 35(11)27).
26 Risk management processes: communication and consultation, establishing the context, risk assessment, risk
treatment, monitoring and review (see terms and definitions, and table of content, in the ISO 31000 preview:
https://www.iso.org/obp/ui/#iso:std:iso:31000:ed-1:v1:en).
27 Article 35(10) explicitly excludes only the application of article 35 paragraphs 1 to 7.
18
d) Is there an obligation to publish the DPIA?
No, but publishing a summary could foster
trust, and the full DPIA must be communicated to the supervisory authority in case of
prior consultation or if requested by the DPA.
Publishing a DPIA is not a legal requirement of the GDPR, it is the controller´s decision to do so.
However, controllers should consider publishing at least parts, such as a summary or a
conclusion of their DPIA.
The purpose of such a process would be to help foster trust in the controller’s processing operations,
and demonstrate accountability and transparency. It is particularly good practice to publish a DPIA
where members of the public are affected by the processing operation. This could particularly be the
case where a public authority carries out a DPIA.
The published DPIA does not need to contain the whole assessment, especially when the DPIA could
present specific information concerning security risks for the data controller or give away trade secrets
or commercially sensitive information. In these circumstances, the published version could consist of
just a summary of the DPIA’s main findings, or even just a statement that a DPIA has been carried
out.
Moreover, where a DPIA reveals high residual risks, the data controller will be required to seek prior
consultation for the processing from the supervisory authority (Article 36(1)). As part of this, the
DPIA must be fully provided (Article 36(3)(e)). The supervisory authority may provide its advice28,
and will not compromise trade secrets or reveal security vulnerabilities, subject to the principles
applicable in each Member State on public access to official documents.
E. When shall the supervisory authority be consulted?
When the residual risks are high.
As explained above:
– a DPIA is required when a processing operation “is likely to result in a high risk to the rights
and freedoms of natural person” (Article 35(1), see III.B.a). As an example, the processing of
health data on a large scale is considered as likely to result in a high risk, and requires a DPIA;
– then, it is the responsibility of the data controller to assess the risks to the rights and freedoms
of data subjects and to identify the measures29 envisaged to reduce those risks to an acceptable
level and to demonstrate compliance with the GDPR (Article 35(7), see III.C.c). An example
could be for the storage of personal data on laptop computers the use of appropriate technical
and organisational security measures (effective full disk encryption, robust key management,
appropriate access control, secured backups, etc.) in addition to existing policies (notice,
consent, right of access, right to object, etc.).
In the laptop example above, if the risks have been considered as sufficiently reduced by the data
controller and following the reading of Article 36(1) and recitals 84 and 94, the processing can
proceed without consultation with the supervisory authority. It is in cases where the identified risks
cannot be sufficiently addressed by the data controller (i.e. the residual risks remains high) that the
data controller must consult the supervisory authority.
28 Written advice to the controller is only necessary when the supervisory authority is of the opinion that the
intended processing is not in line with the regulation as per Article 36(2).
29
Including taking account of existing guidance from EDPB and supervisory authorities and taking account of
the state of the art and the costs of implementation as prescribed by Article 35(1).
19
An example of an unacceptable high residual risk includes instances where the data subjects may
encounter significant, or even irreversible, consequences, which they may not overcome (e.g.: an
illegitimate access to data leading to a threat on the life of the data subjects, a layoff, a financial
jeopardy) and/or when it seems obvious that the risk will occur (e.g.: by not being able to reduce the
number of people accessing the data because of its sharing, use or distribution modes, or when a wellknown vulnerability is not patched).
Whenever the data controller cannot find sufficient measures to reduce the risks to an
acceptable level (i.e. the residual risks are still high), consultation with the supervisory authority
is required30.
Moreover, the controller will have to consult the supervisory authority whenever Member State law
requires controllers to consult with, and/or obtain prior authorisation from, the supervisory authority in
relation to processing by a controller for the performance of a task carried out by the controller in the
public interest, including processing in relation to social protection and public health (Article 36(5)).
It should however be stated that regardless of whether or not consultation with the supervisory is
required based on the level of residual risk then the obligations of retaining a record of the DPIA and
updating the DPIA in due course remain.
IV. Conclusions and recommendations
DPIAs are a useful way for data controllers to implement data processing systems that comply with
the GDPR and can be mandatory for some types of processing operations. They are scalable and can
take different forms, but the GDPR sets out the basic requirements of an effective DPIA. Data
controllers should see the carrying out of a DPIA as a useful and positive activity that aids legal
compliance.
Article 24(1) sets out the basic responsibility of the controller in terms of complying with the GDPR:
“taking into account the nature, scope, context and purposes of processing as well as the risks of
varying likelihood and severity for the rights and freedoms of natural persons, the controller shall
implement appropriate technical and organisational measures to ensure and to be able to demonstrate
that processing is performed in accordance with this Regulation. Those measures shall be reviewed
and updated where necessary”.
The DPIA is a key part of complying with the Regulation where high risk data processing is planned
or is taking place. This means that data controllers should use the criteria set out in this document to
determine whether or not a DPIA has to be carried out. Internal data controller policy could extend this
list beyond the GDPR’s legal requirements. This should result in greater trust and confidence of data
subjects and other data controllers.
Where a likely high risk processing is planned, the data controller must:
– choose a DPIA methodology (examples given in Annex 1) that satisfies the criteria in Annex
2, or specify and implement a systematic DPIA process that:
30 Note: “pseudonymization and encryption of personal data” (as well as data minimization, oversight
mechanisms, etc.) are not necessarily appropriate measures. They are only examples. Appropriate measures
depend on the context and the risks, specific to the processing operations.
20
o is compliant with the criteria in Annex 2;
o is integrated into existing design, development, change, risk and operational review
processes in accordance with internal processes, context and culture;
o involves the appropriate interested parties and clearly define their responsibilities
(controller, DPO, data subjects or their representatives, business, technical services,
processors, information security officer, etc.);
– provide the DPIA report to the competent supervisory authority when required to do so;
– consult the supervisory authority when they have failed to determine sufficient measures to
mitigate the high risks;
– periodically review the DPIA and the processing it assesses, at least when there is a change of
the risk posed by processing the operation;
– document the decisions taken.
21
Annex 1 – Examples of existing EU DPIA frameworks
The GDPR does not specify which DPIA process must be followed but instead allows for data
controllers to introduce a framework which complements their existing working practices provided it
takes account of the components described in Article 35(7). Such a framework can be bespoke to the
data controller or common across a particular industry. Previously published frameworks developed
by EU DPAs and EU sector-specific frameworks include (but are not limited to):
Examples of EU generic frameworks:
– DE: Standard Data Protection Model, V.1.0 – Trial version, 201631.
https://www.datenschutzzentrum.de/uploads/SDM-Methodology_V1_EN1.pdf
– ES: Guía para una Evaluación de Impacto en la Protección de Datos Personales (EIPD),
Agencia española de protección de datos (AGPD), 2014.
https://www.agpd.es/portalwebAGPD/canaldocumentacion/publicaciones/common/Guias/Gui
a_EIPD.pdf
– FR: Privacy Impact Assessment (PIA), Commission nationale de l’informatique et des libertés
(CNIL), 2015.
https://www.cnil.fr/fr/node/15798
– UK: Conducting privacy impact assessments code of practice, Information Commissioner’s
Office (ICO), 2014.
https://ico.org.uk/media/for-organisations/documents/1595/pia-code-of-practice.pdf
Examples of EU sector-specific frameworks:
– Privacy and Data Protection Impact Assessment Framework for RFID Applications32.
http://ec.europa.eu/justice/data-protection/article-29/documentation/opinionrecommendation/files/2011/wp180_annex_en.pdf
– Data Protection Impact Assessment Template for Smart Grid and Smart Metering systems33
http://ec.europa.eu/energy/sites/ener/files/documents/2014_dpia_smart_grids_forces.pdf
An international standard will also provide guidelines for methodologies used for carrying out a DPIA
(ISO/IEC 2913434).
31 Unanimously and affirmatively acknowledged (under abstention of Bavaria) by the 92. Conference of the
Independent Data Protection Authorities of the Bund and the Länder in Kühlungsborn on 9-10 November 2016.
32 See also :
– Commission Recommendation of 12 May 2009 on the implementation of privacy and data protection
principles in applications supported by radio- frequency identification.
https://ec.europa.eu/digital-single-market/en/news/commission-recommendation-12-may-2009-
implementation-privacy-and-data-protection-principles
– Opinion 9/2011 on the revised Industry Proposal for a Privacy and Data Protection Impact Assessment
Framework for RFID Applications.
http://ec.europa.eu/justice/data-protection/article-29/documentation/opinionrecommendation/files/2011/wp180_en.pdf
33 See also the Opinion 07/2013 on the Data Protection Impact Assessment Template for Smart Grid and Smart
Metering Systems (‘DPIA Template’) prepared by Expert Group 2 of the Commission’s Smart Grid Task Force.
http://ec.europa.eu/justice/data-protection/article-29/documentation/opinionrecommendation/files/2013/wp209_en.pdf
34 ISO/IEC 29134 (project), Information technology – Security techniques – Privacy impact assessment –
Guidelines, International Organization for Standardization (ISO).
22
Annex 2 – Criteria for an acceptable DPIA
The WP29 proposes the following criteria which data controllers can use to assess whether or not a
DPIA, or a methodology to carry out a DPIA, is sufficiently comprehensive to comply with the
GDPR:
– a systematic description of the processing is provided (Article 35(7)(a)):
– nature, scope, context and purposes of the processing are taken into account (recital
90);
– personal data, recipients and period for which the personal data will be stored are
recorded;
a functional description of the processing operation is provided;
– the assets on which personal data rely (hardware, software, networks, people, paper or
paper transmission channels) are identified;
– compliance with approved codes of conduct is taken into account (Article 35(8));
– necessity and proportionality are assessed (Article 35(7)(b)):
– measures envisaged to comply with the Regulation are determined (Article 35(7)(d)
and recital 90), taking into account:
– measures contributing to the proportionality and the necessity of the
processing on the basis of:
– specified, explicit and legitimate purpose(s) (Article 5(1)(b));
– lawfulness of processing (Article 6);
– adequate, relevant and limited to what is necessary data (Article
5(1)(c));
– limited storage duration (Article 5(1)(e));
– measures contributing to the rights of the data subjects:
– information provided to the data subject (Articles 12, 13 and 14);
– right of access and to data portability (Articles 15 and 20);
– right to rectification and to erasure (Articles 16, 17 and 19);
– right to object and to restriction of processing (Article 18, 19 and 21);
– relationships with processors (Article 28);
– safeguards surrounding international transfer(s) (Chapter V);
– prior consultation (Article 36).
– risks to the rights and freedoms of data subjects are managed (Article 35(7)(c)):
– origin, nature, particularity and severity of the risks are appreciated (cf. recital 84) or,
more specifically, for each risk (illegitimate access, undesired modification, and
disappearance of data) from the perspective of the data subjects:
– risks sources are taken into account (recital 90);
– potential impacts to the rights and freedoms of data subjects are identified in
case of events including illegitimate access, undesired modification and
disappearance of data;
– threats that could lead to illegitimate access, undesired modification and
disappearance of data are identified;
– likelihood and severity are estimated (recital 90);
– measures envisaged to treat those risks are determined (Article 35(7)(d) and recital
90);
– interested parties are involved:
– the advice of the DPO is sought (Article 35(2));
– the views of data subjects or their representatives are sought, where appropriate
(Article 35(9)).