Blog Series: What you always wanted to know about the Transparency & Consent Framework (TCF) / Part 3

On September 25th, we held a 2.5-hour long webinar providing a Complete Overview of the IAB Europe Transparency and Consent Framework. As is usually the case, we had many interested attendees who were keen on learning more. While we usually do our best to make these as interactive as possible, we were simply overwhelmed with questions and had to skip over quite a few to be able to remain on schedule. For this reason, we have decided to answer the questions in a series of blogs. This is the second blog in the series, where we deal with the technical questions about the Framework. Upcoming blogs as part of this Blog Series will cover both policy and legal questions.

What do you mean by disclosing vendor permissions and requesting user consent? How is this done via the publisher?

The IAB Europe Transparency & Consent Framework is designed to enable publishers to (i) disclose the vendors who will be processing personal data when a user accesses the site; (ii) disclose the data processing purposes and associated legal bases for which and under which the vendors are processing personal data; (iii) request consent on behalf of those vendors who are relying on consent  as their legal ground for processing for one or more data processing purposes; (iv) store the user’s consent choices; and (v) transmit the user’s consent choices to upstream vendors. We are moreover working on enabling publishers to send a specific signal about whether they have established transparency about a vendor’s processing of personal data on the basis of a legitimate interest. As lawful processing requires transparency and a lawful basis (such as consent), and publishers are responsible and therefore in control of who is permitted to lawfully process personal data consent signals, and other signals sent through the framework are in essence doubling as permissioning signals. Publishers provide transparency and request and obtain user consent through a user interface managed by a Consent Manager Provider (CMP), operated by either a third party on their behalf or by themselves.

To learn more about how CMPs work and how information is transmitted in the Framework read the FAQ here.

“I get that OpenRTB has a field, but what about 3rd party tags pasted into various ad servers? It seems like no ad server has macros for the DaisyBit. Are you working on this?”

Yes, the Tech Lab has developed a URL-based consent passing spec that can support some non-OpenRTB implementations, and this is an open area to improve options for downstream vendors. Join the IAB Tech Lab’s GDPR working group and help us solve this! In the absence of standardized methods of transmitting the Daisybit outside of OpenRTB and URL-based methods, vendors are responsible to ensure they can transmit the Daisybit through whatever means they have available.

Browsers such as Safari are limiting cookies – how does that affect the IAB Europe Transparency & Cosnent Framework?

The Transparency & Consent Framework does not dictate the way in which consent signals are stored. The specifications standardize the data format in which consent signals are stored as well as the interaction with the consent signal, e.g. how to obtain it using a standard API. As such, the Framework allows storing consent signals in any way suitable and does not depend on cookies. However, most implementations on desktop today rely on third-party (global consent) or first-party (service-specific consent) cookies to store a user’s consent choices. On mobile, a user’s choices are stored in local app storage.  Safari Intelligent Tracking Protection (ITP) may impact cookie-based implementations of the Framework, particularly global consent implementations that rely on third party cookies. Service-specific consent implementations that leverage first party cookies are less affected. Nevertheless,  the IAB Tech Lab will be looking into solutions and strategies to account for ITP limitations in future.

“For transmitting the Daisybit string from party to party, I often see the OpenRTB protocol referenced as the required specification, but oftentimes vendors communicate via direct URLs with query string parameters. Is the query string passing guidance an official component of the IAB Europe Transparency & Consent Framework or is it purely an implementation suggestion?”

The IAB Tech Lab has published a specification for URL-based passing of consent, available on the Framework specification repository here: In situations where URL-based passing is used, it should be implemented with this guidance.

Is it correct that in the case of OpenRTB Exchanges, the Exchange is not expected to protect the requests and the responses based on the payload for consent being passed along?

This is not correct. The Framework Policies only permit a Vendor to transmit personal data to downstream Vendors, for example in the context of OpenRTB, if they have reasonable reliance on that downstream Vendor’s having an appropriate legal basis for processing that personal data. This may be done on the basis of a signal in the context of the Transparency & Consent Framework but Vendors may have other mechanisms to rely on one another’s legal bases.

Why can’t pubvendors.json and CMP be combined into a single code based to account for both?

Early working group discussion explored combining publisher controls and consent preference signals. We determined that the large payload this would require was not appropriate, considering that publisher controls would not change on a per-bid-request basis. Also, the meaning of the signals can be kept distinct between user-preferences (in the consent string) and publisher-preferences (in the pubvendors.json file).

How do interested parties or individuals come to the Lab Tech Group with suggestions?

Proposals, feature requests, and bug reports are very welcome! The GDPR Technical working group at IAB Tech Lab stewards the technical specifications for the Transparency and Consent Framework. IAB Tech Lab members are welcome to join this group. More information available at

Is it a must to store consent string on `` domain? In case if third-party cookies are disabled, what to do?

It isn’t a requirement to store the consent string on Consent can either be stored on a first party cookie (publisher-specific), or on the domain as a third-party cookie. Indeed, it is possible to store them outside of cookies altogether! The publisher/CMP can thus choose. Where third-party cookies are disabled, the publisher will not be able to recognize the user, so it may create a user experience issue for that site visitor as the CMP would ‘forget’ that user’s consent status. Publishers could consider informing users about this possibility or, more drastically, refuse access to users who do not allow third parties since this would also impact the ability to leverage ad space on its site.

Blog Series: What you always wanted to know about the Transparency & Consent Framework (TCF) / Part 2

On September 25th, we held a 2.5-hour long webinar providing a Complete Overview of the IAB Europe Transparency and Consent Framework. As is usually the case, we had many interested attendees who were keen on learning more. While we usually do our best to make these as interactive as possible, we were simply overwhelmed with questions and had to skip over quite a few to be able to remain on schedule. For this reason, we have decided to answer the questions in a series of blogs. This is the second blog in the series, where we deal with the technical questions about the Framework. Upcoming blogs as part of this Blog Series will cover additional technical questions, as well as policy and legal questions.

What about processing batch file data and not real-time requests? Do you actually need the consent string in the batch data file or can you here rely on a DPA with the data provider?

The Consent String, or daisybit, should be read in each bid request for each unique impression opportunity when passed over real-time bidding (OpenRTB).

Do users of the IAB Europe Transparency and Consent Framework have to provide a specific cookie that they want to investigate for a consent status? Could you clarify how would the investigation work?

The individual will be presented with a user interface (operated by a CMP, displayed on a publisher website page). The individual will then select their consent preferences, and this information then gets stored as a cookie (either as a third-party cookie or site-specific cookie). The user is not expected to investigate the literal cookie itself, but a CMP should offer a way for the user (consumer) to re-select their consent preferences, thereby triggering an update to the cookie that has the consent string record.

Can you define what is covered by ‘open source standard’? Is it a tech standard or does it include language and contractual structure?

The IAB Europe Transparency and Consent Framework has open source technical standards managed by IAB Tech Lab and includes a process of registration (including agreement to terms and conditions), allowing a company to express that they adhere to expected policies.

Well known examples of purely technical ‘open source standards’ include OpenRTB, VAST, or MRAID (each without a “framework” that requires corresponding terms and conditions). These technical standards have a system of community and governance to maintain and upgrade specifications to meet industry needs. Participants contribute to implementation guides, provide use cases, or propose new features. A governing body is able to commit to formal iterations and new versions of the specifications, providing structured pathways to updates.

How does the vendor know that the other vendor to whom it is transmitting the data has received the users consent?

All vendors taking part in the Transparency & Consent Framework are obliged to accept the Terms and Conditions, as well as fully adhere to the policies of the Framework. The first vendor in this scenario has to pass the ‘daisybit’ down the chain upon receiving it themselves, and it is up to the vendor down-stream to appropriately respond to the information therein and pass it further down the chain where applicable.

There is currently no technical signal to indicate that consent has been read or applied, though it is a useful suggestion that could be considered as a feature to be included in future updates to the TCF infrastructure.

Is there any way for the signal of “legitimate interest” to be assessed by the IAB Europe Transparency and Consent Framework or will the signal be accepted as it was sent by the CMP?

Signaling of a ‘legitimate interest’ legal basis through the daisybit has been explored by the technical working groups. They determined at the time that the daisybit payload would be overloaded with this extra bit of information since it would effectively double the size. In turn this would add latency and mix intended signals in the Framework.

The Global Vendor List allows a vendor to declare their purposes and legal bases. The consent string should contain information about the user’s consent preferences, and separately, the pubvendors.json file can contain information about the publisher’s permissions for vendors, and for their vendor’s legal bases.

We are still exploring ways to consolidate all the information about whether the user’s data can be processed in future, but with the current iteration we have to rely on a solution which has a consent string on the one hand, and uses pubvendors.json to declare the reliance on legitimate interest on the other.

Is there a published technology roadmap? Is there going to be a defined update/release cycle for enhancements?

There are currently a few new feature updates that are being prioritized, and shared publicly, including pubvendors.json v1.1 finalization, adding security/authentication to the Framework, and efficiency updates. Members of the IAB Tech Lab GDPR working groups have full access to backlog and detailed roadmap of proposed features.

There seem to be many “private CMPs” who have not obtained their own CMP ID and are generating and transmitting consent strings with the invalid CMP id or 1 (what’s in the IAB source code”. Is there any effort underway to eliminate these invalid consent sources?

We have partnered with The Media Trust, who are developing a self-testing tool for CMPs to assess whether their CMP implementation is compliant with the policies of the IAB Europe Transparency and Consent Framework. This will allow current CMPs to improve their products to better fit the standards. This is the first step in a larger effort to validating CMPs, and in that process, we will more diligently update the list of CMPs on, including delisting CMPs that are found to be operating in a non-compliant way.

It should also be noted that, as a matter of the policies, vendors who receive a daisybit from an invalid CMP ID are required to ignore the signal and not act any further on the bid request it is appended to.

Blog Series: What you always wanted to know about the Transparency & Consent Framework (TCF) / Part 1

On September 25th, we held a 2.5-hour webinar providing a Complete Overview of the IAB Europe Transparency and Consent Framework. As it is usually the case, we had many interested attendees who were keen on learning more. While we usually do our best to make these as interactive as possible, we were simply overwhelmed with questions and had to skip over quite a few to be able to remain on schedule. For this reason, we have decided to answer the questions in a series of blogs. This is the first blog in the series, where we deal with the ‘big picture topics’ surrounding our Framework. The next blogs in the series will delve into the technical questions, and to conclude we will answer policy-related questions about the Framework.

Some of these questions have been edited for clarity, or we have answered to topics which were asked about several times

Please provide definitions for some of the acronyms and terms used:

TCF: Acronym for the Transparency & Consent Framework.

EDAA: The European Interactive Digital Advertising Association. This organisation adheres the self-regulatory framework for online behavioural advertising (‘the OBA Framework’).

OBA: Online Behavioural Advertising. The practice of making use of data about user behaviour online to determine more relevant advertising. The EDAA’s OBA Framework is a tool that allows users to get information about this practice and to opt-out of receiving this targeted form of advertising but does not equate to an objection to data processing as provided for under the GDPR’s data subject rights.

Daisybit: This is the information containing information about consent that is given (or not given) for the various purposes standardised by the Framework as well as for different vendors. The information is compressed into a ‘bit-string’ which is daisy-chained through the online advertising supply chain, hence the name ‘daisybit’.

SSP: Supply-Side Platform. Also referred to as the ‘sell-side’, these are platforms that facilitate the sale of ad space.

DSP: Demand-Side Platform. Also referred to as the ‘buy-side’, these platforms help brands and agencies buy ad space.

Publishers: A publisher in the context of our Framework is any consumer-facing website or application, also referred to as the ‘first-party’. It does not refer exclusively to news publishers.

On Google integration with the IAB Europe Transparency & Consent Framework:

Google has stated during the webinar that it plans to interoperate with the Framework once the current work on updating the Purposes, Policies, and introducing Pubvendors.json is complete. This is so that they avoid integrating with the current Policies and Purposes only to have to transition to the revised ones almost immediately.  Our expectation is that Google will make an announcement over the next 3-4 weeks and will actually be implementing the TCF as from January 2019.

IAB is supporting the Transparency and Consent Framework as well as OBA Framework (EDAA). How do these two initiatives talk to each other? Does the first make the later redundant?

The EDAA’s OBA Framework does not help companies achieve compliance with EU data protection law. It is a self-regulatory framework providing so-called “enhanced notice” through an icon and allowing users to “opt-out” of behavioural targeting. Neither the transparency provided through “enhanced notice” nor the “opt-out” meet the relevant requirements under European data protection law.

The IAB Europe Transparency & Consent Framework (TCF) is a Framework designed and intended to help companies comply with obligations arising from EU data protection law, such as transparency, lawful processing, and accountability. Using the TCF, first-parties can enable third-parties to process user data on one of the legal bases of the regulation. The Framework standardises the presentation to users’ third-party data processing requests that require “informed” consent for data processing. The Framework enables “signaling” of user choice across the advertising supply chain. It is open-source, not-for-profit with consensus-based industry governance led by IAB Europe with significant support from industry parties and the IAB Tech Lab, which provides technical management of the open-source specifications and version control.

The two Frameworks are entirely separate and do not interoperate.

On meetings with Data Protection Authorities:

We have been meeting with European data protection authorities to present the IAB Europe Transparency & Consent Framework and to engage in an open-ended conversation to aid in our joint goal of helping companies in the online media and advertising business to comply with European data protection law. Our meetings with the DPAs are private, meaning that we will not be sharing any specific responses or feedback publicly. We hold meetings with those DPAs where we have established contact and who show an interest in meeting with us. It is therefore possible we have not met with DPAs in your jurisdiction – to date we have met with five different DPAs in Europe.

Does the IAB Europe Framework align or reference to some of the key requirements as detailed in the WFA manifesto  earlier this year?

While the IAB Europe Transparency and Consent Framework does not make any direct reference to the requirements of the World Federation of Advertisers’ (WFA) Manifesto for Online Data Transparency, we believe that the TCF is a critical tool in achieving the manifesto’s view that a sustainable digital advertising ecosystem requires the engagement and commitment of all stakeholders to practices that put consumers’ needs first, providing transparency, control, and accountability.

I am a vendor that’s included in the Framework. Could you clarify – how is the framework supposed to benefit me as a vendor?

The Framework allows Vendors to be disclosed to users, establish a lawful basis for processing, and receive a signal that allows it to verify that transparency and/or consent have been established. It is unlikely that in absence of a technical framework Vendors would be able to reliable comply with the law.

Minor Update to the Policies of the IAB Europe Transparency & Consent Framework relating to CMPs

IAB Europe has published a minor change affecting the Policies of the IAB Europe Transparency & Consent Framework (“Framework”) on Wednesday, 3 October 2018.

The update exclusively addresses a paragraph under the heading “Working with Vendors” in the “Policies for CMPs”, that could have been understood as requiring CMPs to work exclusively with Vendors who participate in the Framework.

Such an exclusivity paragraph is inconsistent with the “Policies for Interacting with Users”, which stipulate that the UI must prominently distinguish between Framework participants and others and avoid confusing or misleading users about the Framework participation of any of the disclosed parties.

To resolve this inconsistency and address confusion it has caused, IAB Europe deleted the exclusivity language under the heading “Working with Vendors” in the “Policies for CMPs”, and replaced it with the following wording:

“If a CMP works with Vendors who are not registered with the MO, the CMP must make it possible for users to distinguish between Vendors registered with the Framework, and those who are not. CMPs must not mislead others as to the Framework participation of any of the Vendors who are not registered with the MO.”

No other changes have been made to the Policies at this time. The new Policies Version 2018-10-03.2a replace the previous Version 2018-04-25.2.

Transparency And Consent Framework Mobile App Spec Ready For Adoption

Today, IAB Tech Lab and IAB Europe released the Transparency and Consent Framework’s Mobile In-app Specifications as a final version ready for widespread industry adoption. No significant changes were made to the specs in the process of finalization. Tech Lab’s GDPR Mobile Subgroup reviewed the specifications and public comments, considering their own implementation strategies in applying the Framework for in-app.

Early adopters of the mobile specs should be sure that their implementation complies with the final mobile in-app specifications and adheres to the Framework policies.

Released for public comment at the same time earlier this quarter, pubvendors.json will also be finalized in the coming weeks. Pubvendors.json provides granular controls to publishers, allowing them to whitelist vendors, addressing publisher liability concerns, and the ability for publishers to express if they support a vendor using Legitimate Interest as a legal basis. For mobile app inventory use of pubvendors.json, please review the Mobile Guidance for Ads.txt out for public comment until July 6th.

The Transparency and Consent Framework has over 350 registered vendors on the Global Vendor List, over 100 registered CMPs (Consent Management Providers), and potentially tens of thousands of publishers. This rapid adoption will be strengthened with the addition of finalized mobile in-app specifications.

General questions on the Framework can be sent to, and technical questions can be sent to

To join the Transparency & Consent Framework, register at:

The Idea That The Transparency & Consent Framework Increases Publisher Liability Is A Red Herring

A recurring theme in the feedback we are getting from the market on the Transparency & Consent Framework (TCF or “the Framework”) is that it increases the degree of legal liability that publishers bear under EU data protection rules, notably by forcing them to assume full liability for actions by third parties that are beyond their control.

In fact, nothing could be further from the truth. The TCF does not create new rules on liability, nor does it alter existing ones. Those rules are regulated by law and by contract, neither of which is affected by the Framework. The GDPR states that controllers are responsible, and therefore liable, for the processing of personal data they control. A controller is also liable for processing done on its behalf by processors under its control, unless the processor acted against the instructions of the controller.

In addition, liability is regulated through other law, such as tort law, and contract law. In many cases companies will contractually stipulate where liability lies – agreeing amongst themselves how to share it out as part of a normal commercial negotiation. Such contracts are typically concluded between publishers and their third-party partners, something that will not change under the GDPR or the TCF.

The Framework allows publishers to provide consumers transparency into the third-party partners they work with, and to obtain and transmit user consent signals to those partners. Indeed, the reason we need these signals is that third parties must comply with the GDPR’s transparency requirements and, where they are leveraging the consent legal basis, must be able to demonstrate that the user has indeed consented. These things are only possible if there is a signal.

For example, if a publisher lets a third party know that it has not provided transparency into on behalf of a third party, and has not obtained consent on behalf of a third party (maybe because the publisher doesn’t work with that third party), and that third party starts processing personal data regardless, the publisher is now able to demonstrate that it has duly informed the third party of all relevant facts allowing blame and liability to be established clearly with the third party that has engaged in unlawful processing despite better knowledge.

If anything, publishers are in a better position implementing the Framework than they were pre-GDPR.  This is because thanks to the audit trail it creates in order to convey information up the delivery chain, the Framework will make it possible to detect what parties were acting without the necessary legal basis, so that liability can be correctly apportioned.

Transparency & Consent Framework – Keeping The Ball Rolling

In this Friday’s weekly webinar on IAB Europe’s GDPR Transparency & Consent Framework, we will be discussing the feedback we have received to date from publishers in the public consultation we launched on 8 March. Since the law and the technology to which it applies are complex, some confusion has arisen in relation to what the Framework actually does (and does not do). The webinar should be a good opportunity to respond to what publishers have already told us, and give you the opportunity to ask any other questions you may have “live”.

Here are some examples of the feedback so far:

1.Publishers would like more control over which third parties receive and are able to process the data, including personal data, of their audiences, or what those third parties are able to do with the data

The Framework currently provides publishers with full control over which third parties – whether technology vendors or other data controllers – are disclosed on their websites, and which third parties the publishers solicit user consent for. The Framework also allows publishers (and their users) to prescribe the purposes for which the approved third parties may process data.  While in Version 1.0 the Framework is limited to controlling whether a given purpose is toggled on or off for all approved vendors, we are actively exploring technical solutions that would enable purpose-by-vendor controls for publishers and users.

2. Publishers are concerned about legal liability in the event of non-compliance by vendors

The Framework does not change rules on liability, which are defined by the law, including the GDPR, and contractual arrangements.  The Framework increases accountability by allowing a publisher to signal relevant information to technology vendors.  These signals create an audit trail that provides readily available evidence for identifying non-compliance and responsibility.

3. Publishers want user consent to be specific.

The version of the Framework put out for consultation foresees four different data processing purposes that websites would disclose – and could offer granular control for – accessing a device (ePrivacy Directive); advertising personalisation; analytics; and content personalisation. The proposed approach is a good-faith attempt to balance the conflicting imperatives of transparency and comprehensibility to the consumer, on the one hand, and ease of use for both publisher and user, on the other.

The Framework does not impose on users a take-it-or-leave it choice to accept or reject all third parties disclosed by the publisher, though some publishers may opt to present users with a take-it-or-leave-it choice.  Version 1.0 of the Framework will allow users to consent to some, all, or none of the data processing purposes disclosed, and to data processing (for those purposes) by some, all, or none of the third parties disclosed.  Moreover, publishers have complete control as to which third parties and which data processing purposes they solicit user consent for.

4. Publishers want to leverage the privileged relationship they have with their audiences

The Framework depends on publishers leveraging their direct relationships with their users to provide transparency and control over the data processing that occurs on their services. Publishers have complete freedom to define the user interfaces on their sites; they may create their own CMPs, or enlist a commercial CMP.  The Framework is deliberately not prescriptive in relation to the look and feel and ownership of the user experience.

The Framework empowers publishers to be more transparent and to offer more controls over the data processing undertaken by various technology providers for various purposes when users access a publisher’s content services, but entrusts publishers with deciding how best to leverage its possibilities.

No publisher-user relationship, whether privileged or otherwise, can exist if the production of content cannot be financed in a way that enables the creation of a compelling proposition for users.  The Framework has been created to enable publishers and the suppliers of other online services to continue to be able to choose how they finance their activities, and to enable users to choose how they access them.

We’ll keep surfacing the most recurrent queries and any misconceptions over the next few weeks.  Above all, we are looking forward to further input from all stakeholders, and an outcome that everyone can converge on as from May.

Legitimate Interest And Consent – Can Both Legal States Be Declared In The Framework?

In our last blog ‘To be or not be’ we presented the duality of the ‘processor’ and ‘controller’ and how the Global Vendor & CMP List (List) could best serve them. Concluding that the primary value of the List is for companies, irrespective of their controller or processor status, to provide transparency into a legal ground for processing personal data and obtain consent in accordance with their own assessment of when that is needed.

This brings us to a second important state of duality that the Framework is tackling – the declaration of the two allowable legal states, under GDPR, of consent and legitimate interest against a purpose.

Participation in the Framework requires that the consent manager provider (CMP) or publisher acting as a CMP must disclose every vendor they wish to work with alongside the purpose and the legal basis of their data processing – they must not signal that consent has been obtained for a vendor and purpose that has not been disclosed to the user. This is not optional but a hard requirement under the policies as well as the law. Publishers who refuse to make disclosures on behalf of a vendor will not be able to work with that vendor under the Framework.

Currently the Framework also supports the disclosure of legitimate interest as a legal basis by a vendor who processes data toward a specific purpose. The publisher or CMP must not attempt to obtain consent for that vendor and purpose combination or make it appear as though a vendor is operating on the basis of consent for that purpose.

When a vendor declares consent as their legal basis against a purpose the publisher or CMP must provide transparency and obtain consent on behalf of the vendor. Therefore, when consent is the legal basis a publisher must pass information about consent (or the lack thereof) to its vendors.

When a vendor declares legitimate interest as their legal basis, it only needs the publisher to provide transparency. Since legitimate interests are claimed, rather than given, no signal about the existence of the legitimate interest is necessary.

BUT currently it is not possible for a publisher or CMP to pass onto a vendor, information that they have provided transparency to the end user that legitimate interest and vendor and purpose is the claimed state for personal data processing. They can only pass to the vendor that they have requested and obtained consent. The only way for a vendor to know that transparency has been provided is when receiving a positive consent signal. If no consent is ‘signalled’ this means that consent has not been given – in the dual world of legitimate interest and consent this could mean that the publisher or CMP have either disclosed a legitimate interest, attempted but failed to obtain consent, or chosen not to work with a vendor. The vendor has no way of knowing which of these cases is causing this transmission and would therefore be conflicted by the signal. However, since under the ePrivacy Directive consent is generally required for storing and/or accessing information on a device, Vendors can rely on their consent status for ePrivacy Directive purposes to infer the remainder of their disclosure status.

However, in future the recently announced Pubvendors.JSON extension to the Framework, which is currently subject to public consultation will address this information transmission conflict by giving publishers a mechanism by which they can inform vendors of the disclosures they have provided on their behalf. As a result, Pubvendors.JSON will allow vendors to declare consent or legitimate interest against purposes provided that they adhere to the Pubvendors.JSON implementation.

Public comment concludes on June 1, 2018. IAB Tech Lab and IAB Europe participants will evaluate and incorporate feedback received and release a final version of each of these specifications. If the dual challenge of legitimate interest and consent resonates with your company then you can adopt the pubvendors.json technology as a beta implementation now, even before the specifications are finalized.

We welcome your feedback  – technical feedback can be sent to and general feedback can be sent to

We look forward to hearing from you.

To Be Or Not To Be

As the adoption of the IAB Europe Transparency & Consent Framework gains momentum we are seeing increasing and exciting levels of engagement from the industry.  Our Friday Webinar series on the Framework is attracting over 300 participants each week – sign-up for the next one here.

After each webinar we have received numerous questions about what was covered during the session. They ranged from detailed technical questions about how the Framework works, to queries about the registration process, cookies, consent policy, legal liability, and the user interface.

One of the common questions is the declaration dilemma of processor and controller and the place for each in the Framework.  Our List of registered vendors does not differentiate between controller and processor namely because for different processing activities vendors may be controllers and/or processors in the same transaction, or between different transactions. Being on the list doesn’t make a representation about a company’s legal status as a controller/processor in a given situation under the GDPR. The primary value of the List is for companies, irrespective of their controller or processor status, to provide transparency and obtain consent in accordance with their own assessment of when that is needed.

As a controller under GDPR companies are responsible to ensure that transparency is provided and a legal basis established where personal data is processed, which makes the value of the List apparent for controllers.

However, even if you are a processor who may not need to provide transparency into a legal ground for processing personal data, because you are acting on the instruction of and under the legal basis of a controller, you may still need to obtain consent for information storage or access under the ePrivacy Directive and therefore can leverage the Framework exclusively to that end.

Therefore: If you are a vendor and consider that you are a processor that does not need to provide transparency as a legal ground for processing personal data, but still like to obtain consent for the placement of cookies, then the declaration of one of five purposes the Framework enables “information storage and access” (described as ‘the storage of information, or access to information that is already stored, on your device such as advertising identifiers, device identifiers, cookies, and similar technologies’) would be the minimum you should consider.

With this thought in mind do not delay in signing up to the Global Vendor List here and join the growing number of vendors (over 130 at the last count) that to date have joined the Framework. This will ensure that you can continue to maintain and work closely with the publishers that you support now and in the future.

Transparency & Consent Framework Specification Launches Global As Industry Participation Increases

We are very pleased to announce the release of the technical specifications for IAB Europe’s Transparency & Consent Framework. This exciting cross-industry initiative will be a critical tool in helping publishers, technology vendors, agencies and advertisers meet the transparency and user choice requirements of the EU’s new General Data Protection Regulation (GDPR) which comes into effect on 25th May 2018.

The Framework will ensure that online services give consumers full visibility and control over who is allowed to process their data in connection with advertising, and for what purposes.

The official release version of this open-source standard reflects extensive feedback from publishers, advertisers, and other important stakeholders who all participated in the final working group review of the following technical specifications:

To support the technical specifications, there is a series of implementation guides for publishers, buyers (DSPs and agencies), CMPs and DMPs:

The technical specifications of the Framework will be maintained by an IAB Tech Lab working group. We will be working continuously with them to update the technical specifications to accommodate any changes in policy as well as feedback from the market. We look forward to hearing from you at

Sign up now

This release swiftly follows our recent announcement that the registration process is now open for both Vendors and Consent Management Providers (CMPs) to apply for approved status in the context of IAB Europe’s Transparency & Consent Framework. Since the announcement, we are seeing an increasing number of Vendors and CMPs registering and gaining approval. For more information about the Framework, including a link to the registration portal for vendors wishing to participate, visit

Join our next Webinar

On Friday 20th April, we had a very successful Webinar with a panel of CMPs demonstrating their consent solution to over 300 participants. You can watch a recording of it here. We will repeat this webinar on Friday 27 April at  8am PDT / 11am EDT / 4pm BST/ 5pm CEST. If you are interested please check for details or register here.