Support Centre

EU: IAB Europe and UK guidance for DPIAs - Highlights and concerns

The International Advertising Bureau ('IAB') Europe and the IAB UK have worked jointly to publish new guidance on best practices for conducting Data Protection Impact Assessments1 ('DPIAs') in accordance with the requirements of the General Data Protection Regulation (Regulation (EU) 2016/679) ('GDPR'). The guidance is not jurisdiction specific, and it is not intended as a paint-by-numbers approach to conducting assessments. Instead, it 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. Fergal McHugh, Head of Strategy at Arekibo Communications Ltd, discusses the essential features of the guidance and how the DPIA process can help digital professionals balance the requirements of success and compliance.

Cristian Prisecariu / Essential collection /

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 summarised for the purposes of this article (for the detail of these steps consult the guidance).

  • Convene a team to deliver the DPIA, ensuring that it is representative of the processing being planted. The relevant range of disciplines must be represented (from business, legal, to marketing through to technical).
  • Establish the processing objectives, ensuring that the team fully understands what those objectives are and that all relevant stakeholders have been consulted.
  • 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's Transparency and Consent Framework here (and again for the risk analysis step below) which can help shape and streamline these activities.
  • 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.
  • Apply data minimisation and Privacy by Design 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 minimisation steps will need to be repeated at each iteration. It is also worth noting that the developers should not attempt to retrofit Privacy by Design techniques, Privacy by Design should be an integrated part of the design process.
  • 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.
  • Iterate. And of course, iterate, because any change in processing or context can have wide-ranging impacts.

The requirement for iteration is appropriately emphasised 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 focus here will be on 'residual risk,' not least because the level of such risk will determine whether consultation with an appropriate data protection authority ('DPA') will be required. It will also feed into broader decisions about whether the processing should go ahead.

An integrated DPIA approach and 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, summarised below.

  • 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; it 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, centralised leadership will be required to 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 real-time bidding ('RTB'), 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 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 has a natural affinity with design-thinking approaches. As 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 marshalled 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 themselves in the user's shoes) with design objectives. It is a positive feature of the IAB guidance that it emphasised 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 data processing. As the IAB points out, selecting a sweet spot which balances the need for processing with these requirements is an 'art' as much as a science. The IAB recommendation here is to go broad and utilise 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 up-skilling within the organisation.

The challenge of RTB

As 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 DPIAs may require consultation with an appropriate DPA. With respect to RTB, there is currently a debate on whether the use of RTB should automatically trigger a DPA consultation.

The ongoing debate between the IAB and privacy campaigners and the increasing numbers of 'privacy actives' who support their efforts is relevant here. 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 DPIA requires a controller to satisfy themselves on all relevant states and movements of the data they intend to process (including transfers), 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, but, fundamentally, the critical barrier to risk management/mitigation is the perceived lack of transparency available from RTB vendors about how the relevant data is used, stored, and transferred.

Now admittedly much of the above is orthogonal to the IAB guidance. 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.

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 fundamentally this is a question of trust and a pragmatic DPIA process relies on a 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. On the other hand, it could be argued 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 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, however it will not assist with any RTB related dilemmas.

Fergal McHugh Head of Strategy
[email protected]
Arekibo Communications Ltd, Dublin

1. Available at: