Article 29 Working Party (WP29) has published several guidelines under the GDPR and such guidelines contain recommendations regarding best practices that are regarded by the authorities as compliant with the requirements of the GDPR. In this post, I have collected such recommendations. 

1. Guidelines on Transparency (WP260)

(i) Information on the most important consequences of the processing: 

• "As a best practice, in particular for complex, technical or unexpected data processing, the WP29 position is that controllers should not only provide the prescribed information under Articles 13 and 14, but also separately spell out in unambiguous language what the most important consequences of the processing will be: in other words what kind of effect will the specific processing described in a privacy statement/ notice actually have on a data subject? Such a description of the consequences of the processing should not simply rely on innocuous and predictable “best case” examples of data processing, but should provide an overview of the types of processing that could have the highest impact on the fundamental rights and freedoms of data subjects in relation to protection of their personal data." (p. 8)

(ii) Link to the privacy statement: 

• "WP29 recommends as a best practice that at the point of collection of the personal data in an online context a link to the privacy statement / notice is provided or that this information is made available on the same page on which the personal data is collected." (p. 8)

(iii) Layered privacy satetements: 

• "WP29 recommends the use of layered privacy statements / notices, which allow website visitors to navigate to particular aspects of the relevant privacy statement / notice that are of most interest to them [...]" (p. 10)
• "WP29 has previously made recommendations around transparency and provision of information to data subjects in its Opinion on Recent Developments in the Internet of Things (such as the use of QR codes printed on internet of things objects, so that when scanned, the QR code will display the required transparency information). These recommendations remain applicable under the GDPR." (p. 11)
• "WP29 recommends that where a data controller has an online presence, an online layered privacy statement / notice should be provided." (p. 13)
• "WP29 recommends that layered privacy statements / notices should be used to link to the various categories of information which must be provided to the data subject, rather than displaying all such information in a single notice on the screen, in order to avoid information fatigue." (p. 17)

(iv) Article 13 exemptions: 

• Best practice example regarding exemptions under Article 13 is also available on pages 24-25. 

(v) Information on the balancing test: 

• "As a matter of best practice, the data controller should also provide the data subject with the information from the balancing test, which should have been carried out by the data controller to allow reliance on Article 6.1(f) as a lawful basis for processing, in advance of any collection of data subjects’ personal data." (p. 31)

2. Guidelines on Consent (WP259) 

(i) Refreshing consents: 

• "WP29 recommends as a best practice that consent should be refreshed at appropriate intervals. Providing all the information again helps to ensure the data subject remains well informed about how their data is being used and how to exercise their rights." (p. 20)

(ii) Gathering parent's consent: 

• "[...] the WP29 recommends the adoption of a proportionate approach, in line with Article 8(2) GDPR and Article 5(1c) GDPR (data minimisation). A proportionate approach may be to focus on obtaining a limited amount of information, such as contact details of a parent or guardian." (p. 25)

3. Guidelines on Automated individual decision-making and Profiling (WP251rev.01)

Annex 1 of such guidelines contains good practice recommendations:

(i) Right to have information: When the controller provides information about the logic involved, "instead of providing a complex mathematical explanation about how algorithms or machine-learning work, the controller should consider using clear and comprehensive ways to deliver the information to the data subject, for example:

• the categories of data that have been or will be used in the profiling or decision-making process;
• why these categories are considered pertinent
• how any profile used in the automated decision-making process is built, including any statistics used in the analysis;
• why this profile is relevant to the automated decision-making process; and
• how it is used for a decision concerning the data subject.

Controllers may wish to consider visualisation and interactive techniques to aid algorithmic transparency." (p. 31) 

(ii) Right of access: "Controllers may want to consider implementing a mechanism for data subjects to check their profile, including details of the information and sources used to develop it." (p. 31) 

(iii) Right to rectification: "Controllers providing data subjects with access to their profile in connection with their Article 15 rights should allow them the opportunity to update or amend any inaccuracies in the data or profile." (p. 31) 

"Controllers could consider introducing online preference management tools such as a privacy dashboard. This gives data subjects the option of managing what is happening to their information across a number of different services – allowing them to alter settings, update their personal details, and review or edit their profile to correct any inaccuracies." (p. 32)

(iv) Right to object: "Controllers need to ensure that this right is prominently displayed on their website or in any relevant documentation and not hidden away within any other terms and conditions." (p. 32)

(v) Appropriate safeguards: "The following list, though not exhaustive, provides some good practice suggestions for controllers to consider when making solely automated decisions, including profiling (defined in Article 22(1)):

• regular quality assurance checks of their systems to make sure that individuals are being treated fairly and not discriminated against, whether on the basis of special categories of personal data or otherwise;
• algorithmic auditing – testing the algorithms used and developed by machine learning systems to prove that they are actually performing as intended, and not producing discriminatory, erroneous or unjustified results;
• for independent ‘third party’ auditing (where decision-making based on profiling has a high impact on individuals), provide the auditor with all necessary information about how the algorithm or machine learning system works;
• obtaining contractual assurances for third party algorithms that auditing and testing has been carried out and the algorithm is compliant with agreed standards;
• specific measures for data minimisation to incorporate clear retention periods for profiles and for any personal data used when creating or applying the profiles;
• using anonymisation or pseudonymisation techniques in the context of profiling;
• ways to allow the data subject to express his or her point of view and contest the decision; and,
• a mechanism for human intervention in defined cases, for example providing a link to an appeals process at the point the automated decision is delivered to the data subject, with agreed timescales for the review and a named contact point for any queries." (p. 32)

"Controllers can also explore options such as:

• certification mechanisms for processing operations;
• codes of conduct for auditing processes involving machine learning;
• ethical review boards to assess the potential harms and benefits to society of particular applications for profiling." (p. 32)

4. Guidelines on Personal data breach notification (WP250rev.01)

(i) Joint controllers: "WP29 recommends that the contractual arrangements between joint controllers include provisions that determine which controller will take the lead on, or be responsible for, compliance with the GDPR’s breach notification obligations." (p. 13)

(ii) Processor's obligations: "[...] WP29 recommends the processor promptly notifies the controller, with further information about the breach provided in phases as more details become available." (pp. 13 and 14)

(iii) Notification in phases: "WP29 recommends that when the controller first notifies the supervisory authority, the controller should also inform the supervisory authority if the controller does not yet have all the required information and will provide more details later on." (p. 15)

(iv) Breaches at non-EU establishments: "WP29 recommends that notification should be made to the supervisory authority in the Member State where the controller’s representative in the EU is established." (p. 17)

(v) Contacting individuals: "WP29 recommends that controllers should choose a means that maximizes the chance of properly communicating information to all affected individuals. Depending on the circumstances, this may mean the controller employs several methods of communication, as opposed to using a single contact channel." (p. 21) 

(vi) Documenting breaches: "WP29 recommends that the controller also document its reasoning for the decisions taken in response to a breach. In particular, if a breach is not notified, a justification for that decision should be documented. This should include reasons why the controller considers the breach is unlikely to result in a risk to the rights and freedoms of individuals." (p. 27)

(vii) Role of the DPO: "WP29 recommends that the DPO is promptly informed about the existence of a breach and is involved throughout the breach management and notification process." (p. 28)

5. Guidelines on Data Protection Impact Assessment (DPIA) (WP248rev.01)

(i) Carrying out DPIAs in ambigous cases: 

• "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." (p. 8)

(ii) Reassessment of DPIAs: 

• "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." (p. 14)

(iii) Specific roles and responsibilities in connection with carrying out the DPIA: 

• "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 professions (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." (p. 15)

(iv) Publishing a DPIA: 

• "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." (p. 18)

6. Guidelines on Data Protection Officers ('DPOs') (wp243rev.01)

(i) Designating a DPO: 

• "WP29 recommends that controllers and processors document the internal analysis carried out to determine whether or not a DPO is to be appointed, in order to be able to demonstrate that the relevant factors have been taken into account properly." (p. 5)

(ii) Public authority or body: 

• "WP29 recommends, as a good practice, that private organisations carrying out public tasks or exercising public authority designate a DPO." (p. 6)

(iii) Accessibility of the DPO: 

• "To ensure that the DPO is accessible, the WP29 recommends that the DPO be located within the European Union, whether or not the controller or the processor is established in the European Union." (p. 11)

(iv) DPO team: 

• "For the sake of legal clarity and good organisation and to prevent conflicts of interests for the team members, it is recommended to have a clear allocation of tasks within the DPO team and to assign a single individual as a lead contact and person ‘in charge’ for each client. It would generally also be useful to specify these points in the service contract." (p. 12)

(v) Publication of the DPO's contact details: 

• "As a matter of good practice, the WP29 also recommends that an organisation informs its employees of the name and contact details of the DPO. For example, the name and contact details of the DPO could be published internally on organisation’s intranet, internal telephone directory, and organisational charts." (p. 13)

(vi) Opinion of the DPO:

• "The opinion of the DPO must always be given due weight. In case of disagreement, the WP29 recommends, as good practice, to document the reasons for not following the DPO’s advice." (p. 14)

(vii) Role of the DPO in a DPIA:

• "The WP29 recommends that the controller should seek the advice of the DPO, on the following issues, amongst others:
  - whether or not to carry out a DPIA
  - what methodology to follow when carrying out a DPIA
  - whether to carry out the DPIA in-house or whether to outsource it
  - what safeguards (including technical and organisational measures) to apply to mitigate any risks to the rights and interests of the data subjects
  -  whether or not the data protection impact assessment has been correctly carried out and
  - whether its conclusions (whether or not to go ahead with the processing and what safeguards to apply) are in compliance with the GDPR." (p. 17)
• "The WP29 further recommends that the controller clearly outline, for example in the DPO’s contract, but also in information provided to employees, management (and other stakeholders, where relevant), the precise tasks of the DPO and their scope, in particular with respect to carrying out the DPIA." (p. 18)

7. Guidelines on the right to "data portability" (wp242rev.01)

(i) Applicability of data portability:

• "[...] it is a good practice to develop processes to automatically answer portability requests, by following the principles governing the right to data portability. An example of this would be a government service providing easy downloading of past personal income tax filings. For data portability as a good practice in case of processing based on the legal ground of necessity for a legitimate interest and for existing voluntary schemes [...]" (p. 8, footnote 16)

(ii) Prior information: 

• "WP29 recommends in particular that data controllers clearly explain the difference between the types of data that a data subject can receive through the rights of subject access and data portability." (p. 13)
• "In addition, the Working Party recommends that data controllers always include information about the right to data portability before data subjects close any account they may have. This allows users to take stock of their personal data, and to easily transmit the data to their own device or to another provider before a contract is terminated." (p. 13)
• "Finally, as leading practice for “receiving” data controllers, the WP29 recommends that data subjects are provided with complete information about the nature of personal data which are relevant for the performance of their services. In addition to underpinning fair processing, this allows users to limit the risks for third parties, and also any other unnecessary duplication of personal data even where no other data subjects are involved." (p. 13)

(iii) Timeframe of answering data portability requests: 

• "To meet user expectations, it is a good practice to define the timeframe in which a data portability request can typically be answered and communicate this to data subjects." (p. 14)