Data Protection Impact Assessment Guidelines for GDPR from IAB Europe and UK

The IAB (Europe and UK) have worked jointly to publish new guidance on best practices for conducting Data Protection Impact Assessments (DPIAs) in accordance with the requirements of the EU’s General Data Protection Regulation (GDPR).i The guidance is not jurisdiction specific, and it is not intended as a paint-by-numbers approach to conducting assessments. Instead, is designed to help mainly digital advertising technology companies (understood in the broadest possible sense of the term — from ad tech developers to agencies using their products, and all the shadings in between) build a DPIA process into their product lifecycles.

I begin by surveying what I see as the essential features of the guidance. I pay particular attention to the constructive recommendation that the DPIA should be effectively integrated into the product lifecycle as function of best practice. I follow with a discussion of how DPIA process can help digital professionals balance the requirements of success and compliance and can actually benefit product design and development. Finally, on more critical note I consider the case of Real Time Bidding (RTB) as a crucial instance of programmatic advertising falling under the scope of the guidance. I ask whether the guidance is sufficient to assist digital professionals in making the relevant risk and impact determinations in the case of RTB.

Key steps to a successful DPIA

The IAB guidance supplies a clear and comprehensive structural framework for designing and developing a DPIA process (including a description of the key steps involved) that will best fit organisations facing this task. These key steps are only briefly summarized for the purposes of this article (for the detail of these steps consult the guidance).

1. Convene a team to deliver the DPIA, making ensuring that is representative of the processing being planted. The relevant range of disciplines must be represented (from business, legal, to marketing through to technical).
2. Establish the processing objectives ensuring that the team fully understand what those objectives are and that all relevant stakeholders have been consulted.
3. Establish the processing context. The processing context is a complete picture of all relevant data flows, stores, the systems involved and the status vis-à-vis GDPR obligations as the data moves between systems and stores (including retention periods, transfers to other processors and across jurisdictions etc.). This is likely to be one of the most time consuming and technically challenging parts of the process. The guidance recommends using the “purposes and features” taxonomy from IAB Europe TCF framework here (and again for the risk analysis step below) which can help shape and streamline these activities.
4. Ensure that the team understand both processing objectives and context. If an iterative process is being used for product development, then the team members will need to be kept up to date as the product evolves.
5. Apply data minimization/Privacy by Design (PBD) techniques. The IAB is at pains in the guidance to point out that the sequence of steps will need to be adapted to an organisation’s design/delivery approach. Equally that many steps will need to be revisited and even repeated. If the product strategy changes, then it is likely that these minimization steps will need to be repeated at each iteration. It is also worth noting that the developers should not attempt to retrofit PDB techniques, PBD should be an integrated part of the design process.
6. Evaluate risks and mitigate. A DPIA is at its core a risk management activity, so this step is crucial to the process. Again, the step should be understood as a continuous part of product development.
7. Iterate. And of course, iterate, because any change in processing or context can have wide-ranging impacts.

The requirement for iteration is appropriately emphasized in the guidance. This might appear burdensome, but it doesn’t have to be. Over time and as the design process continues the risk count should be going down as the relevant mitigations are applied. Obviously, the eye here will be on “residual risk”, not least because the level of such risk will determine whether consultation with an appropriate DPA will be required. It will also feed into broader decisions about whether the processing should go ahead. I discuss some of the nuances of risk evaluation and mitigation in the next section.

An integrated DPIA approach - Some principles

Core to the guidance is the recommendation that the DPIA should form an integral part of the product lifecycle. DPIA’s should not be a casual afterthought, but should be a planned, resourced and fully integrated part of the product approach. In fact, it is possible to extract a set of integration principles from the guidance which I summarize here.

• Begin early. Build the requirements of the DPIA, and what it represents, — fair, necessary and legal processing — into all stages of the product process, from inception through to service and retiral.
• Be willing to iterate. A DPIA is not a static document; is a “dynamic” process that should form an integral part of product and campaign design and execution. In line with the requirement for privacy-by-design, a DPIA should be iterated in cadence with product development cycles, ensuring that it is always captures the actual processing activities being considered.
• Be inclusive. A DPIA is a “team effort” bringing together relevant capabilities from across the organisation. Senior, centralized leadership will be required make it happen, but input must also be actively sought from the personnel involved in processing the data in order to make sure that the assessment is comprehensive and accurate.
• Assume a DPIA is required. One should assume that a DPIA is always required when contemplating a new data processing activity; the burden vis-à-vis decision-making is to justify why a DPIA is not required (and not the other way around). In the context of programmatic digital advertising including RTB (real time bidding), a DPIA will almost always be required.
• Follow the process. The deciding factor is not simply whether the processing is “subjectively” envisaged by the assessor as high risk (or has been historically experienced as high risk). Assessors should focus instead on whether the activity corresponds to objective “indicators” of high risk. Organisations should use the process to deliver the assessment (and not make too many assumptions in advance).
• Be as objective as possible. This principle is related to the previous one. Both concern the challenges of achieving objectivity both in the determination of the relevant level of risk and whether the processing is necessary. A crucial skill to be nurtured in conducting DPIA is that of taking a disinterested perspective vis-à-vis the activity being envisaged in order to ask whether the processing will be necessary. In the same vein, one should consider if there are lower-risk ways of achieving the same result. Objectivity here then is not just stepping-back from the activity; it also involves clarifying your intentions.

Some guidance highlights

The DPIA as a design tool

The overall spirit of the IAB guidance there incorporates the welcome insight that product development accompanied by a fully integrated, rigorous DPIA process is likely to result in a better product. As per the IAB positioning the DPIA process appropriately conceived has a kind of natural affinity with design-thinking approaches. As I noted above the IAB places a crucial emphasis on the “art” of the DPIA. The challenge of stepping back from the overall business context and achieving objectivity with respect to the proposed methods and scope of data processing is precisely the type of challenge that design-thinking frameworks are marshaled to meet. Equally, while there are many variations on design-thinking in use, central to most is a practical iterative process that seeks to balance empathy (where the designer puts herself in the user’s shoes) with design objectives. It is a positive feature of the IAB guidance that it emphasized how the data risk management can complement the way products are being actually being designed.

Knowledge, training and the art of assessing risk

An important focus of the guidance is helping organisations meet the GDPR requirements of proportionality, necessity and fairness in processing. As the IAB points out, selecting a sweet spot which balances the need for processing with these requirements is an “art” as much of a science. The IAB recommendation here is to go broad and utilize the full range of guidance provided by protection authorities, academic studies etc. to inform and hone judgment.

Implicit in this recommendation and a recurring theme in the guidance overall is the importance of appropriate training. Digital professionals need to be informed and thoroughly understand the relevant concepts and understand what they are doing, if not on an individual level then as part of a contribution to an effectively led team. Effective use of the IAB guidance should drive an appropriate upskilling within the organisation.

The challenge of RTB

As I have discussed above, the IAB recommends that where programmatic advertising is involved a DPIA will almost always be required. A perhaps unanticipated effect of making the DPIA more or less mandatory is that it can draw attention away from questions of why a DPIA is required in specific instances. The stakes may be a great deal higher for some DPIAs and merely conducting the required internal assessment and documentation may not be sufficient (and in certain cases organisations may have a strong inkling of this in advance). For example, some DPIA’s may require consultation with an appropriate Data Protection Authority (DPA). With respect to RTB there is a currently a debate on whether the use of RTB should automatically trigger a DPA consultation.

The ongoing debate between the IAB and privacy campaigners (for example Johnny Ryan) and the increasing numbers of “privacy actives” who support their efforts is relevant here. Ryan’s complaint dates to 2018 and has not yet been resolved. There have been a variety of additional complaints since then, and most recently (December 2020) human rights campaigners Liberties coordinated a six-country complaint implicating RTB providers (including the IAB) in a failure to meet the requirements of the GDPR for data processing. I follow some features of the Ryan complaint here as a paradigm concern with the status of RTB vis-à-vis the effective conduct of DIPAs, and examine the IAB guidance in the light of this challenge.

In brief, Ryan argues that any marketer using/buying targeted advertising must in the process of conducting a DPIA consult the appropriate DPA.iii Now the decision on whether a controller should consult with their DPA is dependent on whether or not the risks of processing can be effectively managed. In Ryan’s view it is intrinsic to the current form RTB takes that such risks cannot be managed. Planned use of RTB should automatically trigger a DPA consultation. Naturally this is not echoed in the IAB guidance.

Underpinning Ryan’s argument is the claim that a marketer buying target ad services is exposed to liability as a joint controller along with the RTB provider. Ryan also suggests that this may be applicable to agencies who work with those marketers. This could have significant consequences. Right now, it is not current practice for a marketer purchasing RTB services to complete a DPIA, nor is it practice of any relevant intermediaries to do so. And of course, this connects to a broader issue: the lack of genuine knowledge by actors within the industry of their effective controllership status.

Since the logic of the DPIA requires a controller to satisfy themselves on all relevant states and movements of the data they intend to process (including transfers etc.) a conscientious DPIA process may, where RTB is involved, identify a significant amount of residual risk. For example, a marketer using a RTB provider might find themselves in the position of having to accept joint controllership without being able to demonstrate that the relevant risks can be appropriately mitigated. There is a great deal of complicated background here, right now it suffices to note that crucial barrier to risk management/mitigation is the perceived lack of transparency available from RTB vendors about how the relevant date is used, stored and transferred.

Now admittedly much of the above is orthogonal to the IAB guidance. Not because the concerns of Ryan (and other campaigners) are necessarily unjustified, but rather because the IAB guidance is positioned at such a general, abstract level. It is general enough to work for any planned processing and does not depend on any specific type of processing being regarded as exempt from consideration. It is also general enough to avoid being implicated in questions of whether certain activities are prima facie going to meet the requirements for an escalation to a DPA or for the planned processing to be deemed inappropriate. (In a similar vein the guidance is effectively silent on the role key concepts such as joint controllership could play in a DPIA process). As such an organisation might share Ryan’s view and still make full use of the IAB guidance. They will however need to rely on other guidance and advice to make the appropriate determination concerning whether to accept joint controllership and conduct the DPIA in accordance with the specific status.

Conclusion: The marketer's dilemma

What does this mean for a marketer using the IAB guidance for a product with a reliance on a RTB as a component? Of course, the crucial point is that the ultimate legal fate of RTB will not invalidate the IAB Guidance. The IAB suggests making the DPIA a default where programmatic advertising is involved. Good, but it is the level and thorniness of residual risk following the completion of the DPIA that will determine whether processing should go ahead, and that determination, at least as it relates to the incorporation of RTB, stands outside of the guidance as offered. A more fleshed out guidance might have included more emphasis on incorporating an additional assessment of whether the level of transparency provided by third party vendors (including RTB providers) is sufficient. As noted above organisations will need to look elsewhere for that kind of guidance.

One might argue that this is fundamentally it is a question of trust and pragmatic DPIA process relies on foundation of trust in assessing risk. An organisation conducting a DPIA can build its risk assessment on top of the assurances of organisations like the IAB. Johnny Ryan on the other hand would likely argue that there is no trust without transparency. Overall, the situation leaves the putative controller with something of a dilemma, which naturally guidance from the IAB cannot help them resolve.

As the IAB guidance notes the “art” of the DPIA requires both objectivity and a certain element of subjective evaluation of the risks involved. As I have noted above there is no sense in the IAB guidance that the use of RTB should automatically trigger consultation with the appropriate DPA. An organisation planning to use RTB would need to arrive at its own, subjective evaluation of the risks involved.

Ultimately the guidance provides a useful resource for building an effective DPIA process into a product lifecycle, it will not however assist with any RTB related dilemmas.

If you would like to discuss your digital strategy with Fergal and the team, get in touch today.