• This document lays out the Policies applicable to participants in the IAB Europe Transparency & Consent Framework.
• Participants may include publishers, advertisers, vendors, and/or CMPs. Each category of participant has specific obligations and requirements which are included in these Policies.
• Participants must adhere to these Policies to maintain their participation in the Framework.
• Participants must not amend, supplement, or modify their implementation of the Framework unless expressly provided for in the Policies or Specifications.
• Participants must follow applicable privacy and data protection laws. In the event of a conflict between applicable law and the Policies, the law prevails.

1. “Transparency and Consent Framework” (the “Framework”, or the “TCF”) means the Framework comprising the various parts defined under these Policies. It has the objective to help all parties in the digital environment to comply with the EU’s General Data Protection Regulation (“GDPR”) and ePrivacy Directive (“ePD”) when processing personal data and/or accessing and/or storing information on a user’s device.

2. “Interactive Advertising Bureau Europe aisbl” (“IAB Europe”, the “Managing Organization”, or the “MO”) means the entity that manages and governs the Framework, including the Policies, Specifications, and the GVL. IAB Europe may update these Policies from time to time as it reasonably determines is necessary to ensure the ongoing success of the Framework.

3. “Framework Policies” (the “Policies”) means this or any other official policy documentation disseminated by IAB Europe and updated from time to time, that defines the requirements for compliant participation in, and use of, the Framework, including, but not limited to, Appendix A and Appendix B of these Policies, and any associated policy guidance, or publicly communicated, enforcement actions.

4. “Framework Specifications” (the “Specifications”) means any official technical documentation disseminated by IAB Europe in concert with IAB Tech Lab or future designated technical body, and updated from time to time, that defines the technical implementation of the Framework, including, but not limited to, the Transparency and Consent String with Global Vendor List Format specification, the Consent Management Platform API specification, and any associated implementation guidance.

5. “Global Vendor List” (the “GVL”, or the “Vendor List”) means the list of Vendors who have registered with IAB Europe for participating in the Framework. The list is managed and maintained by IAB Europe, and is referenced by CMPs, Publishers and individual Vendors. Its structure and content shall be defined by the Specifications.

6. “Transparency and Consent Management Platform” (“Consent Management Platform”, or “CMP”) means the company or organisation that centralises and manages transparency for, and consent and objections of the end user. The CMP can read and update the Legal Basis status of Vendors on the GVL, and acts as an intermediary between a Publisher, an end user, and Vendors to provide transparency, help Vendors and Publishers establish Legal Bases for processing, acquire user consent as needed and manage user objections, and communicate Legal Basis, consent or and/or objection status to the ecosystem. A CMP may be the party that surfaces, usually on behalf of the publisher, the UI to a user, though that may also be another party. CMPs may be private or commercial. A private CMP means a Publisher that implements its own CMP for its own purposes. A commercial CMP offers CMP services to other parties. Unless specifically noted otherwise, these policies apply to both private and commercial CMPs.

7. “Vendor” means a company that participates in the delivery of digital advertising or other online activities within a Publisher’s website, app, or other digital content, to the extent that company is not acting as a Publisher or CMP, and that either accesses an end user’s device or processes personal data about end users visiting the Publisher’s content and adheres to the Policies. A Vendor may be considered under the GDPR to be a Controller, a Processor, or both, depending on specific circumstances.

8. “Publisher” means an operator of a Digital Property and who is primarily responsible for ensuring the Framework UI is presented to users and that Legal Bases, including consent, are established with respect to Vendors that may process personal data based on users’ visits to the Publisher’s content.

9. “Digital Property” means a website, app, or other content or service delivery mechanism where digital ads and/or content are displayed, or information is collected and/or used for any Purpose or Special Purpose.

10. “Framework UI” (“UI”) means the user interface or user experience defined by the Specifications for presentation to a user in order to establish Legal Bases for GVL Vendors as part of their compliance with European privacy and data protection laws. The Policies and Specifications define requirements for the UI along with aspects that are configurable by Publishers.

11. “Initial Layer” refers to information that must be made visible to the user in the UI prior to the user being able to give his or her consent. For the avoidance of doubt, the use of the term “visible” should not be understood as excluding other forms of information presentation used, for example, for assisted internet access, or on devices with non-visual user interfaces.

12. “Purpose” means one of the defined purposes for processing of data, including users’ personal data, by participants in the Framework that are defined in the Policies or the Specifications for which Vendors declare a Legal Basis in the GVL and for which the user is given choice, i.e. to consent or to object depending on the Legal Basis for the processing, by a CMP.

13. “Special Purpose” means one of the defined purposes for processing of data, including users’ personal data, by participants in the Framework that are defined in the Policies or the Specifications for which Vendors declare a Legal Basis in the GVL and for which the user is not given choice by a CMP.

14. “Feature” means one of the features of processing personal data used by participants in the Framework that are defined in the Policies or the Specifications used in pursuit of one or several Purposes for which the user is not given choice separately to the choice afforded regarding the Purposes for which they are used.

15. “Special Feature” means one of the features of processing personal data used by participants in the Framework that are defined in the Policies or the Specifications used in pursuit of one or several Purposes for which the user is given the choice to opt-in separately from the choice afforded regarding the Purposes which they support.

16. “Stack” means one of the combinations of Purposes and/or Special Features of processing personal data used by participants in the Framework that may be used to substitute or supplement more granular Purpose and/or Special Feature descriptions in the Initial Layer of a UI.

17. “Category of data” means one of the categories of data collected and processed by Framework participants in pursuit of one or several Purposes and that are defined in the Policies or the Specifications.

18. “Signal” means any signal defined by the Policies or Specifications sent by a CMP, usually on behalf of a Publisher, to Vendors that includes, amongst others, information about the transparency, consent, and/or objection status of a Vendor and/or Purpose, the opt-in status of a Special Feature, and Publisher restrictions.

19. “Precise Geolocation Data” means information about a user’s geographic location accurate to up to 500 metres and/or latitude and longitude data beyond two decimal points.

20. “Legal Basis” means a lawful ground for processing defined in Article 6 GDPR and supported by the Framework, which are consent in accordance with Article 6(1)(a) GDPR and legitimate interests in accordance with Article 6(1)(f) GDPR. Legal Bases in the Framework can be established with

(a) Service-specific scope, which means a Legal Basis is applicable only on the service, for example a Publisher website or app, on which the Legal Basis is obtained and managed;

or

(b) Group-specific scope, which means a Legal Basis is applicable only on a pre-defined group of services, for example a number of Digital Properties of one or more Publishers that implement CMPs with their group’s scope, each of which allows users to manage their choices regarding Legal Bases established for the group across all the services of the group.

21. “Device” means electronic equipment, such as a computer, tablet, phone, TV, watch, that is capable of accessing the internet, including any software run on the electronic equipment to connect to the internet, such as a browser or app.

1. CMPs must apply to IAB Europe for participation in the Framework. IAB Europe shall take reasonable steps to vet and approve a CMP’s application according to procedures adopted, and updated from time to time, by the MO.

2. CMPs must provide all information requested by IAB Europe that is required to fulfil IAB Europe’s CMP application and approval procedures.

3. IAB Europe shall not approve a CMP’s application unless or until IAB Europe can verify to its satisfaction the identity of the party or parties controlling the CMP, as well as the CMP’s ability to maintain its service and adhere to the Policies and Specifications.

1. A CMP must adhere to all Policies applicable to CMPs that are disseminated by the MO in the Policies or in documentation that implements the Policies, such as in operating policies and procedures, guidance, and enforcement decisions.

2. A CMP must make a public attestation of compliance with the Policies in a prominent disclosure, such as in a privacy policy. This attestation must at minimum include: (i) an affirmation of the CMP’s participation in the IAB Europe Transparency & Consent Framework; (ii) an affirmation of its compliance with the Policies and Specifications of the Transparency & Consent Framework; (ii) the IAB Europe-assigned ID of the CMP. Example:

<Organisation> participates in the IAB Europe Transparency & Consent Framework and complies with its Specifications and Policies. <Organisation> operates Consent Management Platform with the identification number <CMP ID>.

1. In addition to implementing the Framework according to the Specifications, a CMP must support the full Specifications, unless the Specifications expressly state that a feature is optional, in which case a CMP may choose to implement the optional feature but need not to do so.

2. A private CMP need only implement the Specifications to the extent necessary to support the needs of the Vendors, Purposes, and Special Features selected by its Publisher owner.

3. A CMP must disclose Vendors’ GVL information, including Legal Bases, as declared, and update Vendors’ GVL information, including Legal Bases status in the Framework, wherever stored, according to the Specifications, without extension, modification, or supplementation, except as expressly allowed for in the Specifications.

4. A CMP must not read, write, or communicate any Vendor’s Legal Bases except according to and as provided for under the Specifications.

1. A CMP will remind the user of their right to withdraw consent and/or right to object to processing with respect to any Vendor or Purpose in accordance with the requirements laid down by the relevant Authorities.

2. A CMP must resolve conflicts in Signals or merge Signals before transmitting it in accordance with the Policies and Specifications.

3. A CMP must only generate a positive consent Signal on the basis of a clear affirmative action taken by a user that unambiguously signifies that user’s agreement on the basis of appropriate information in accordance with the law.

4. A CMP must only generate a positive legitimate interest Signal on the basis of the provision of transparency by the CMP about processing on the basis of a legitimate interest and must always generate a negative legitimate interest Signal if the user has indicated an objection to such processing on the basis of a legitimate interest.

5. A CMP must only generate a positive opt-in Signal for Special Features on the basis of a clear affirmative action taken by a user that unambiguously signifies that user’s agreement on the basis of appropriate information.

6. A CMP will establish Legal Bases only in accordance with the declarations made by Vendors in the GVL and using the definitions of the Purposes and/or their translations found in the GVL, without extension, modification, or supplementation, except as expressly allowed for in the Policies.

7. A CMP must resurface the Framework UI if the MO indicates, in accordance with the Policies and Specifications, that changes to the Policies are of such a nature as to require re-establishing Legal Bases.

8. A CMP may be instructed by its Publisher which Purposes, Special Features, and/or Vendors to disclose. If a Publisher instructs a CMP not to disclose a Purpose, Special Feature, and/or a Vendor, the Signals the CMP generates must appropriately reflect in the Signal that no Legal Bases and/or opt-ins have been established for the respective Purposes, Special Features, and/or Vendors. For the avoidance of doubt: Special Purposes, and Features must always be disclosed if at least one of the Vendors disclosed has declared itself using them.

9. A CMP must implement any Publisher restrictions, such as a restriction of Purposes per Vendors, by making appropriate changes in the User Interface to reflect such restrictions, and by creating the appropriate Signals containing the Publisher restrictions in accordance with the Policies and Specifications.

11. A CMP may be instructed by its Publisher to establish, record and transmit information about Legal Bases applicable to data processing performed by the Publisher, including Legal Bases for purposes that are not standardised by the Framework.

1. If a CMP works with Vendors who are not participating in the Framework and published on the GVL, the CMP must make it possible for users to distinguish between those Vendors who are participating in the Framework, on the one hand, and those who are not, on the other. CMPs must not misrepresent Vendors who are not registered with IAB Europe as participating in the Framework and published on the GVL.

2. If a Publisher or Vendor operates a CMP, the Policies for CMPs shall apply only to the extent of that party’s CMP operation. For example, if a Publisher operates a CMP, the prohibition against a CMP discriminating against Vendors shall apply to the Publisher’s CMP only, while the Publisher remains free to make choices with respect to Vendors appearing on its sites or apps.

3. In any interaction with the Framework, a CMP may not exclude, discriminate against, or give preferential treatment to a Vendor except pursuant to explicit instructions from the Publisher involved in that interaction and in accordance with the Specifications and the Policies. A commercial CMP shall allow the Publisher using its CMP to make choices with respect to each Vendor appearing on its sites or apps and may not impose a list of Vendors. Additionally, it should inform the Publisher of the legal risk described in Chapter IV (20)(1). For the avoidance of doubt, nothing in this paragraph prevents a private CMP from fully implementing instructions from its Publisher owner.

4. If a Vendor also operates a CMP, it may require a Publisher to whom it provides the CMP service to work with its Vendor-owner and Vendor-partners as part of the terms and conditions of using the CMP. Such a requirement shall not constitute preferential treatment in the meaning of Policy 6(3).

5. If a CMP reasonably believes that a Vendor is not in compliance with the Specifications and/or the Policies, it must promptly notify IAB Europe according to MO procedures and may, as provided for by MO procedures, pause working with the Vendor while the matter is addressed.

1. A CMP shall only work with Publishers within the Framework that are in full compliance with the Policies, including but not limited to the requirement to make an attestation of compliance in a prominent location, such as a privacy policy.

2. A CMP is responsible for ensuring that its UIs and Signals comply with the Policies and Specifications. Where a commercial CMP is not able to ensure such compliance, for example because it offers Publishers the option to customise aspects that may impact compliance, the Publisher using such customisation options must assume responsibility for compliance with the Policies for CMPs, register a private CMP within the Framework, and use the commercial CMPs offering in association with the Publisher’s assigned private CMP ID.

3. If a CMP reasonably believes that a Publisher using its CMP is not in compliance with the Specifications and/or the Policies, it must promptly notify IAB Europe according to MO procedures and may, as provided for by MO procedures, pause working with the Publisher while the matter is addressed. For the avoidance of doubt, where a commercial CMP receives an instruction from a Publisher that is in violation of these Policies, the CMP shall not act on the instruction.

4. The MO may prevent a Publisher from participation in the Framework for violations of Framework Policies that are willful and/or severe according to MO procedures. The MO may enact a suspension or block of a Publisher by notifying CMPs that the Publisher is not in full compliance.

1. IAB Europe shall take reasonable steps to periodically review and verify a CMP’s compliance with the Policies and/or the Specifications according to procedures adopted, and updated from time to time, by the MO. A CMP will provide, without undue delay, any information reasonably requested by IAB Europe to verify compliance (which, for the avoidance of doubt, does not include information that might be related to users).

2. IAB Europe may suspend a CMP from participation in the Framework for any failure to comply with the Policies and/or the Specifications until the CMP comes into full compliance and demonstrates its intention and ability to remain so to the MO’s satisfaction. The MO may expel a CMP from participation in the Framework for violations of Policies that are willful and/or severe.

3. Additionally, IAB Europe may, at its discretion and according to MO procedures, take additional actions in response to a CMP’s non-compliance, including publicly communicating the CMP’s non-compliance and reporting the non-compliance to data protection authorities.

1. Vendors must apply to IAB Europe for participation in the Framework. IAB Europe shall take reasonable steps to vet and approve a Vendor’s application according to procedures adopted, and updated from time to time, by the MO.

2. Vendors must provide all information requested by the MO that is reasonably required to fulfil the MO’s application and approval procedures.

3. Vendors must have all legally-required disclosures in a prominent, public-facing privacy policy on their websites.

4. The MO will not approve a Vendor’s application unless or until the MO can verify to its satisfaction the identity of the party or parties controlling the Vendor, as well as the Vendor’s ability to maintain its service and adhere to the Framework policies.

5. A Vendor will provide to the MO, and maintain as complete and accurate, all information required for inclusion in the GVL, according to the GVL Specifications. This includes the Purposes and Special Purposes for which it collects and processes personal data, the Legal Bases it relies on for processing personal data for each Purpose and Special Purpose and, where applicable, a link to an explanation of its legitimate interest(s) at stake, the retention period of data processed for each Purpose and Special Purpose, the Features and Special Features it relies on in pursuit of such Purposes and Special Purposes, the categories of data it collects and processes in pursuit of the Purposes and Special Purposes it has declared, and its requirements regarding storing and/or accessing information on users’ devices. It will ensure its Purposes, Legal Bases, and access to a user’s device, are completely and accurately included in the GVL. It will notify the MO of any changes in a timely manner.

1. A Vendor must adhere to all policies applicable to Vendors that are disseminated by the MO in this document or in documentation that implements the Policies, such as in operating policies and procedures, guidance, and enforcement decisions. See Accountability below regarding enforcement.

2. A Vendor must make a public attestation of compliance with the Policies in a prominent disclosure, such as in a privacy policy. This language must at a minimum include: (i) participation in the IAB Europe Transparency & Consent Framework; (ii) compliance with the Policies and Specifications with the Transparency & Consent Framework; (ii) the IAB Europe assigned ID that the Vendor uses. Example:

<Organisation> participates in the IAB Europe Transparency & Consent Framework and complies with its Specifications and Policies. <Organisation>’s identification number within the framework is <Vendor ID>.

1. In addition to implementing the Framework only according to the Specifications, a Vendor must support the full Specifications, including being able to retrieve and/or pass on Signals in the technical formats required by the Specifications and in accordance with Policies, when available.

1. A Vendor shall work with a CMP within the Framework only if the CMP is in full compliance with the Policies, including but not limited to the requirements to register with IAB Europe, and to make a public attestation of compliance.

2. If a Vendor reasonably believes that a CMP is not in compliance with the Specifications and/or the Policies, it must promptly notify IAB Europe according to MO procedures and may, as provided for by MO procedures, pause working with the CMP while the matter is addressed.

3. A Vendor must respect Signals communicated by a CMP or received from a Vendor who forwarded the Signal originating from a CMP in accordance with the Specifications and Policies, and act accordingly. A Vendor must respect Signals on an individual basis in real-time and must not rely on a stored version of a previously received Signal to store and/or access information on a device, or to process personal data for any Purpose and/or use any Special Feature where a more recent Signal has been received by that Vendor.

4. If a Vendor is unable to read or process the contents of a received Signal, the Vendor must assume that it does not have permission to store and/or access information on a device, or to process personal data for any Purpose and/or Special Purpose.

5. If a Vendor is unable to act in accordance with the contents of a received Signal, the Vendor must not store and/or access information on a device, or process personal data for any Purpose and/or Special Purpose.

6. A Vendor must not create Signals where no CMP has communicated a Signal, and shall only transmit Signals communicated by a CMP or received from a Vendor who forwarded a Signal originating from a CMP without extension, modification, or supplementation, except as expressly allowed for in the Policies and/or Specifications.

7. A Vendor must not obtain a Signal from a CMP except according to and as provided for under the Specifications and, where applicable, using the API provided by a CMP according to the Specifications. For the avoidance of doubt, this shall not preclude receiving a Signal that has been properly obtained using the API provided by a CMP in accordance with the Specifications.

1. A Vendor shall work with a Publisher within the Framework only if the Publisher is in full compliance with the Policies, including but not limited to the requirement to make a public attestation of compliance.

2. If a Vendor reasonably believes that a Publisher is not in compliance with the Specifications and/or the Policies, it must promptly notify IAB Europe according to MO procedures and may, as provided for by MO procedures, pause working with the Publisher while the matter is addressed.

3. For the avoidance of doubt, contractual obligations that a Vendor is subject to with respect to the use of data override more permissive Signals for that Vendor about permissions to that data.

4. A Vendor must update its software for use by its Publisher- and Vendor-partners, such as scripts and tags that result in personal data processing or the storing and/or accessing of information on user devices, to ensure compliance with the Specifications, and/or the Policies. In particular, the requirement to not process personal data prior to verifiably establishing a Legal Basis for processing personal data as communicated by the appropriate Signal in accordance with the Policies and Specifications, and not storing and/or accessing information on a user’s device that is not exempted from the obligation to obtain consent, prior to verifiably having obtained consent as communicated by the appropriate Signal in accord with the Policies and Specifications.

5. A Vendor shall update software provided by its Vendor-partners present on its services, such as scripts and tags that result in personal data processing or the storing and/or accessing of information on user devices, if the Vendor-partner has provided updated software for the purpose of complying with the Specifications and/or the Policies.

6. Where applicable, a Vendor must forward the Signal communicated by a CMP or received from a Vendor who forwarded a Signal originating from a CMP, in accordance with the Specifications and Policies to its Vendor-partners present on its services.

1. A Vendor must not store information or access information on a user’s device without consent, unless the law exempts such storage of information or accessing of information on a user’s device from an obligation to obtain consent.

2. A Vendor shall indicate on the global vendor list if it seeks consent for storing information or accessing information on a user’s device where such consent is necessary. A Vendor must not store information or access information on a user’s device without consent where such consent is necessary.

2bis. A Vendor shall indicate on the GVL the maximum duration of information stored on a user’s device, including whether such duration may be refreshed. A Vendor must, in addition, provide more detailed and purpose-specific storage and access information in accordance with the Specifications.

3. A Vendor must not process personal data relating to a user without a Legal Basis to do so.

4. A Vendor shall indicate on the Global Vendor List:

(a) that it seeks to establish one of the Legal Bases available under the Framework for processing toward a Purpose;

(b) the Legal Basis or Legal Bases it seeks to establish for processing toward a Purpose, specifically whether it wishes to rely on:

i. consent as its sole legal base
ii. legitimate interest as its sole legal base
iii. consent or legitimate interest as its Legal Bases, selected in accordance with the Policy and Specifications

(c) the default Legal Basis to be used by CMPs where the Vendor declares two possible Legal Bases under Policy 4(b)(iii).

5. A Vendor shall indicate on the Global Vendor List that it seeks to establish a legitimate interest for processing for a Special Purpose.

6. A Vendor shall indicate on the Global Vendor List the Features it relies on in support of one or more Purposes and/or Special Purposes.

7. A Vendor shall indicate on the Global Vendor List the Special Features it relies on in support of one or more Purposes and/or Special Purposes.

8. Where a situation falls within the Framework, in addition to complying with relevant data protection laws, a Vendor wishing to rely on the user’s consent for the processing of his or her personal data will only do so if it can verify by way of the appropriate Signal in accord with the Specifications and Policies that the user has given his or her appropriate consent for the storing and/or accessing of information on a user’s device and/or processing of his or her personal data before any information is stored and/or accessed on the user’s device or any personal data is processed.

9. Where a situation falls within the Framework, in addition to complying with relevant data protection laws, a Vendor wishing to rely on its legitimate interest for the processing of personal data will only do so if:

(a) it can verify by way of the appropriate Signal in accordance with the Specifications and Policies that the appropriate information has been provided to the user at the time that the processing of his or her personal data starts.

(b) the user has not exercised his or her right to object to such processing as indicated in the appropriate Signal in accord with the Policies and the Specifications.

10. Where a situation falls within the Framework, in addition to complying with relevant data protection laws, a Vendor wishing to make use of a Feature will only do so if it has indicated on the Global Vendor List its use of the Features it wishes to rely on in support of one or more Purposes and/or Special Purposes.

11. By way of derogation of Policy 14(10), a Vendor may identify devices based on information transmitted automatically without having indicated on the Global Vendor List its use of the Feature to identify devices based on information transmitted automatically to:

(a) process the identifiers based on information transmitted automatically for the Special Purpose of ensuring security, preventing and detecting fraud, and fixing errors provided that

(i) the Vendor complies with relevant data protection law;
(ii) the Vendor has conducted a data protection impact assessment for the processing of identifiers based on information transmitted automatically collected and/or processed under this derogation;
(iii) the Vendor actively minimises collection and/or processing of identifiers based on information transmitted automatically collected and/or processed under this derogation;
(iv) the Vendor puts in place reasonable retention periods for the identifiers based on information transmitted automatically collected and/or processed under this derogation;
(v) the Vendor only retains the identifiers based on information transmitted automatically collected and/or processed under this derogation in an identifiable state for as long as is necessary to fulfil the Special Purpose of ensuring security, preventing and detecting fraud, and fixing errors;
(vi) the Vendor erases the data associated with identifiers based on information transmitted automatically collected and/or processed under this derogation as soon as possible; and
(vii) the data associated with identifiers based on information transmitted automatically collected and/or processed under this derogation is never used for any other Purposes and/or Special Purposes. The prohibition of change of purpose of the processing of data associated with identifiers based on information transmitted automatically under this derogation does not preclude a Vendor from indicating on the Global Vendor List its use of the Feature to identify devices based on information transmitted automatically at a later time and associating data with such identifiers for other Purposes and/or Special Purposes after having made the indication. However, the prohibition does not permit using any data associated with the identifier for the Special Purpose of ensuring security, preventing and detecting fraud, and fixing errors that has occurred under this derogation for any other Purposes and/or Special Purposes and, for example, also precludes changing Purpose with the explicit consent of the user.

12. Where a situation falls within the Framework, in addition to complying with relevant data protection laws, a Vendor wishing to make use of a Special Feature will only do so with the opt-in of the user and if it can verify by way of the appropriate Signal in accord with the Specifications and Policies that the user has given his or her opt-in for the use of the Special Feature before any Special Feature is used by the Vendor, unless expressly provided for by, and subject to, the Policies and/or Specifications.

13. By way of derogation of Policy 14(12), a Vendor may process Precise Geolocation Data without the opt-in of the user to the Special Feature of using Precise Geolocation Data to:

(b) immediately render the Precise Geolocation Data into a non-precise state, for example by truncating decimals of latitude and longitude data, without processing the Precise Geolocation Data in its precise state in any other way;
(c) process the Precise Geolocation Data for the Special Purpose of ensuring security, preventing and detecting fraud, and fixing errors, provided that

(i) the Vendor complies with relevant data protection law;
(ii) the Vendor has conducted a data protection impact assessment for the processing of Precise Geolocation Data collected and/or processed under this derogation;
(iii) the Vendor actively minimises collection and/or processing of Precise Geolocation Data collected and/or processed under this derogation;
(iv) the Vendor puts in place reasonable retention periods for the Precise Geolocation Data collected and/or processed under this derogation;
(v) only retains the Precise Geolocation Data collected and/or processed under this derogation in an identifiable and/or precise state for as long as is necessary to fulfil the Special Purpose of ensuring security, preventing and detecting fraud, and fixing errors;
(ivi) erases the Precise Geolocation Data collected and/or processed under this derogation as soon as possible; and
(vii) the Precise Geolocation Data collected and/or processed under this derogation is never used for any other Purposes and/or Special Purposes. The prohibition of change of purpose of the processing of Precise Geolocation Data collected under this derogation is absolute, and, for example, also precludes changing Purpose with the explicit consent of the user.

14. By way of derogation of Policy 14(12), a Vendor may actively scan device characteristics for identification without the opt-in of the user to the Special Feature of actively scanning device characteristics for identification to:

(a) process the identifiers obtained through actively scanning device characteristics for identification for the Special Purpose of ensuring security, preventing and detecting fraud, and fixing errors provided that

(i) the Vendor complies with relevant data protection law;
(ii) the Vendor has conducted a data protection impact assessment for the processing of identifiers obtained through actively scanning device characteristics for identification collected and/or processed under this derogation;
(iii) the Vendor actively minimises collection and/or processing of identifiers obtained through actively scanning device characteristics for identification collected and/or processed under this derogation;
(iv) the Vendor puts in place reasonable retention periods for the identifiers obtained through actively scanning device characteristics for identification collected and/or processed under this derogation;
(v) only retains the identifiers obtained through actively scanning device characteristics for identification collected and/or processed under this derogation in an identifiable state for as long as is necessary to fulfil the Special Purpose of ensuring security, preventing and detecting fraud, and fixing errors;
(vi) the Vendor erases the data associated with identifiers obtained through actively scanning device characteristics for identification collected and/or processed under this derogation as soon as possible;
(vii) the Vendor identifiers obtained through actively scanning device characteristics for identification collected and/or processed and any data associated with this identifier under this derogation are never used for any other Purposes and/or Special Purposes. The prohibition of change of purpose of the processing of identifiers obtained through actively scanning device characteristics for identification and data associated with this identifier under this derogation does not preclude obtaining an opt-in for actively scanning device characteristics for identification at a later time and associating data with such identifiers for other Purposes and/or Special Purposes after having obtained such an opt-in. However, the prohibition does not permit using any data associated with the identifier for the Special Purpose of ensuring security, preventing and detecting fraud, and fixing errors that has occurred under this derogation for any other Purposes and/or Special Purposes and, for example, also precludes changing purpose with the explicit consent of the user.

15. A Vendor must not transmit personal data to another Vendor unless the Framework’s Signals show that the receiving Vendor has a Legal Basis for the processing of the personal data. For the avoidance of doubt, a Vendor may in addition choose not to transmit any data to another Vendor for any reason.

16. A Vendor must not transmit a user’s personal data to an entity outside of the Framework unless it has a justified basis for relying on that entity’s having a Legal Basis for processing the personal data in question.

17. If a Vendor receives a user’s personal data without having a Legal Basis for the processing of that data, the Vendor must quickly cease processing the personal data and must not further transmit the personal data to any other party, even if that party has a Legal Basis for processing the personal data in question.

18. If a Vendor is unable to receive and respect Signals in real-time, it must put in place reasonable measures to regularly verify the validity of the Signal it relies upon and put in place a limited retention period to mechanically cease processing of user’s personal data when the Signal cannot be verified.

1. The MO may adopt procedures for periodically reviewing and verifying a Vendor’s compliance with the Policies. A Vendor will provide, without undue delay, any information reasonably requested by the MO to verify compliance (which, for the avoidance of doubt, does not include information that might be related to users).

2. The MO may suspend a Vendor from participation in the Framework for its failure to comply with the Policies until the Vendor comes into full compliance and demonstrates its intention and ability to remain so. The MO may expel a Vendor from participation in the Framework for violations of the Policies that are willful and/or severe.

3. Additionally, the MO may, at its discretion and according to MO procedures, take additional actions in response to a Vendor’s non-compliance, including publicly communicating the Vendor’s non-compliance and reporting the non-compliance to data protection authorities.

1. A Publisher may adopt and use the Framework in association with its content as long as it adheres to the Policies and the Specifications.

2. Publishers must have and maintain all legally-required disclosures in a public-facing privacy policy prominently linked to from the content in association with which they are using the Framework.

1. In addition to implementing the Framework only according to the Specifications, a Publisher must adhere to all policies applicable to Publishers that are disseminated by the MO in this document or in documentation that implements the Policies, such as in operating policies and procedures, guidance, and enforcement decisions. See Accountability below regarding enforcement.

2. A Publisher must make a public attestation of compliance with the Policies in a prominent disclosure, such as in a privacy policy. This language must at a minimum include: (i) an affirmation of its participation in the IAB Europe Transparency & Consent Framework; (ii) an affirmation of its compliance with the Policies and Specifications with the Transparency & Consent Framework; (ii) the IAB Europe assigned ID of the CMP that the publisher uses. Example:

<Organisation> participates in the IAB Europe Transparency & Consent Framework and complies with its Specifications and Policies. <Organisation> [operates|uses] the Consent Management Platform with the identification number <CMP ID>.

1. A Publisher must support and adhere to the full Specifications, without extension, modification, or supplementation except as expressly allowed for in the Specifications.

1. A Publisher will work with a CMP within the Framework only if the CMP is in full compliance with the Policies and the Specifications, including but not limited to the requirement for the CMP to register with the MO.

2. If a Publisher reasonably believes that a CMP is not in compliance with the Specifications and/or the Policies, it must promptly notify the MO according to MO procedures and may, as provided for by MO procedures, pause working with the CMP while the matter is addressed.

3. A Publisher may operate a private CMP. A Publisher’s private CMP is subject to the Policies for CMPs just as a commercial CMP is, unless expressly stated otherwise in the Framework Policies or the Specifications.

1. A Publisher may choose the Vendors for which it wishes to provide transparency and help establish Legal Bases within the Framework. A Publisher may further specify the individual Purposes for which it wishes to help establish Legal Bases for each Vendor. The Publisher communicates, or instructs its CMP to communicate, its preferences to Vendors in accordance with the Specifications and Policies

WARNING: Publishers should consider the number of Vendors they work with, and put in place a selection process (Publishers may use the Additional Vendor Information List to facilitate such selection). Providing transparency and helping to establish Legal Bases within the Framework for an unjustifiably large number of Vendors may impact users’ ability to make informed choices and increase Publisher and Vendor legal risk.

2. A Publisher will, in accordance with the Specifications and Policies, and considering and respecting each Vendor’s declarations on the GVL, signal, or instruct to Vendors which Legal Basis it has established on behalf of each Vendor.

3. For the avoidance of doubt, contractual obligations that a Publisher is subject to with respect to the permissions of a Vendor to use of data must be reflected by Signals to align with those contractual obligations.

4. A Publisher may work with Vendors that are not in the GVL but must be careful not to confuse or mislead users as to which Vendors are operating within the Policies

5. For the avoidance of doubt, contractual obligations that a Vendor is subject to with respect to the use of data override more permissive Signals for that Vendor about permissions to that data.

6. If a Publisher reasonably believes that a Vendor is not in compliance with the Specifications and/or the Policies, it must promptly notify the MO according to MO procedures and may, as provided for by those procedures, pause working with the Vendor while the matter is addressed.

7. A Publisher will undertake to update software present on its services of its Vendor-partners, such as scripts and tags that result in personal data processing or the storing and/or accessing of information on user devices, if the Vendor has provided updated software for the purpose of complying with the Specifications and/or the Policies.

8. Where applicable, a Publisher must forward the Signal communicated by a CMP in accordance with the Specifications and Policies to its Vendor-partners present on its services.

1. The Framework does not dictate how Publishers respond to a user’s acceptance or rejection of Purposes, Special Features, and/or Vendors.

2. A Publisher using the Framework is required to help establish transparency, Legal Bases and/or opt-ins for the specific Purposes, Special Purposes, Features, and Special Features that Vendors claim, in accord with the Policies and Specifications.

3. A Publisher may choose which Purposes, Special Features, and/or Vendors to disclose. If a Publisher chooses not to disclose a Purpose, Special Feature, and/or a Vendor, the Signals must appropriately reflect in the Signal that no Legal Bases and/or opt-ins have been established for the respective Purposes, Special Features, and/or Vendors. For the avoidance of doubt: Special Purposes, and Features must always be disclosed if at least one of the Vendors disclosed has declared to be using them.

4. A Publisher may restrict certain Purposes for specific Vendors, these restrictions must be implemented by the CMP, which shall reflect Publisher restrictions in both the User Interface and the Signals in accordance with the Policies and Specifications.

5. A Publisher must not modify, or instruct its CMP to modify the Purpose, Special Purpose, Feature, or Special Feature names, definitions and/or their translations, or Stack names or their translations.

6. A Publisher must not modify, or instruct its CMP to modify, Stack descriptions and/or their translations unless:

(a) the Publisher has registered a private CMP with the Framework, or its commercial CMP is using a CMP ID assigned to the Publisher for use with a private CMP;
(b) the modified Stack descriptions cover the substance of standard Stack descriptions, such as accurately and fully covering all Purposes that form part of the Stack;
(c) Vendors are alerted to the fact of a Publisher using custom Stack descriptions through the appropriate Signal in accordance with the Specification.

7. A publisher must not modify or supplement, or instruct its CMP to modify or supplement, standard illustrations and/or their translations unless:

(a) the Publisher follows any guidance that may be disseminated or updated by the MO so that the modified or additional illustrations provide accurate examples of data processing operations performed by Vendors under the Purposes;
(b) the Publisher can modify only one of the two standard illustrations presented for each Purpose. Modifying the standard illustrations for Special Purposes and Purpose 1 (store and/or access information on a device) is not permitted;
(c) Vendors are alerted to the fact of a Publisher using custom illustrations through the appropriate Signal in accordance with the Specification.

WARNING: Publishers should consider carefully the consequences of modifying and/or supplementing stacks descriptions or standard illustrations, even when permitted. Unfaithful, inaccurate or incomplete representations of data processing activities carried out by Vendors may impact users' ability to make informed choices and increase Publisher and Vendor legal risk. It may therefore result in Vendors refusing to work with Publishers using the permissions described in Chapter IV (21)(6) and Chapter IV (21)(7).

8. If a Vendor that was not included in a prior use of the Framework UI is added by the Publisher, the Publisher must resurface or instruct its CMP to resurface the Framework UI to establish that Vendor’s Legal Bases before signalling that the Vendor’s Legal Bases have been established. It also means resurfacing the UI, for example, when a previously surfaced Vendor claims a previously undisclosed Purpose or changes its declared Legal Basis for a previously disclosed Purpose before signalling that the Vendor’s Legal Bases have been established.

9. Publishers should remind users, or instruct their CMPs to do so, of their right to object to processing or withdraw consent, as applicable, in accordance with the requirements laid down by relevant authorities.

10. A Publisher will not be required to resurface the Framework UI, or instruct its CMP to do so, if it has established a Vendor’s Purposes and Legal Bases in accordance with the Policies prior to a Vendor joining the GVL.

11. A Publisher must resurface the Framework UI, or instruct its CMP to do so, if the MO notifies participants that changes to the Framework are of such a nature as to require re-establishing Legal Bases.

12. A Publisher may use the Specification to manage and store, or instruct its CMP to do so, its own Legal Bases in conjunction with its own processing or for processing conducted on its behalf by a Vendor who is acting as its processor under the law, including Legal Bases for purposes that are not standardised by the Framework.

1. The MO may adopt procedures for periodically reviewing and verifying a Publisher’s compliance with Framework Policies. A Publisher will provide, without undue delay, any information reasonably requested by the MO to verify compliance (which, for the avoidance of doubt, does not include information that might be related to users).

2. The MO may suspend a Publisher from participation in the Framework for its failure to comply with Framework Policies until the Publisher comes into full compliance and demonstrates its intention and ability to remain so. The MO may block a Publisher from participation in the Framework for violations of Framework Policies that are wilful and/or severe. The MO may enact a suspension or block of a Publisher by notifying CMPs that the Publisher is not in full compliance.

3. Additionally, the MO may, at its discretion and according to MO procedures, take additional actions in response to a Publisher’s non-compliance, including publicly communicating the Publisher’s non-compliance and reporting the non-compliance to data protection authorities.

• Purpose 1: Store and/or access information on a device
• Special Feature 1: Use precise geolocation data
• Stack 3: Personalised advertising
  • Purpose 2: Use limited data to select advertising
  • Purpose 3: Create profiles for personalised advertising
  • Purpose 4: Use profiles to select personalised advertising
• Stack 11: Personalised content
  • Purpose 5: Create a personalised content profile
  • Purpose 6: Use profiles to select personalised content
• Stack 17: Advertising and content measurement, and audience research
  • Purpose 7: Measure advertising performance
  • Purpose 8: Measure content performance
  • Purpose 9: Understand audiences through statistics or combinations of data from different sources
  • Purpose 10: Develop and improve services

• Purpose 1: Store and/or access information on a device
• Special Feature 1: Use precise geolocation data
• Stack 8: Personalised advertising and advertising measurement
• Purpose 2: Use limited data to select advertising
• Purpose 3: Create profiles for personalised advertising
• Purpose 4: Use profiles to select personalised advertising
• Purpose 7: Measure advertising performance

• Stack 14: Personalised content, and content measurement
• Purpose 5: Create profiles to personalise content
• Purpose 6: Use profiles to select personalised content
• Purpose 8: Measure content performance
• Purpose 9: Understand audiences through statistics or combinations of data from different sources
• Purpose 10: Develop and improve services

• Purpose 1: Store and/or access information on a device
• Special Feature 1: Use precise geolocation data
• Stack 3: Personalised advertising
  • Purpose 2: Use limited data to select advertising
  • Purpose 3: Create profiles for personalised advertising
  • Purpose 4: Use profiles to select personalised advertising

• Stack 19: Advertising measurement and audience research
  • Purpose 7: Measure advertising performance
  • Purpose 9: Understand audiences through statistics or combinations of data from different sources
  • Purpose 10: Develop and improve services

• Purpose 1: Store and/or access information on a device
• Special Feature 1: Use precise geolocation data
• Stack 2: Advertising based on limited data and advertising measurement
  • Purpose 2
  • Purpose 7
• Stack 3: Personalised advertising
  
  • Purpose 3: Create profiles for personalised advertising
  • Purpose 4: Use profiles to select personalised advertising
•  Stack 15: Advertising measurement and audience research
  • • Purpose 5
    • Purpose 6
    • Purpose 8
    • Purpose 9
    • Purpose 11
• Purpose 10: Develop and improve services

a. When providing transparency about Purposes, Features and Vendors in connection with requesting a user’s consent for the same, the Framework UI’s must be displayed prominently and separately from other information, such as the general terms and conditions or the privacy policy, in a modal or banner that covers all or substantially all of the content of the website or app.

b. When making use of a so-called layered approach, the Initial Layer of the Framework UI providing transparency and requesting a user’s consent:

I. Must include information about the fact that information is stored on and/or accessed from the user’s device (e.g. use of cookies, device identifiers, or other device data);

II. Must include information about the fact that personal data is processed, and the nature of the personal data processed (e.g. unique identifiers, browsing data);

III. Must include information about the fact that third party Vendors will be storing and/or accessing information from the user’s device and processing their personal data, the number of third party Vendors (which may also include Vendors not participating in the Framework); and a link to the list of named third parties;

IV. Must include the list of the distinct and separate Purposes for which the Vendors are processing data, using at least the standardised names and/or Stack names as defined in Appendix A;

V. Must include information about the Special Features used by the Vendors when processing data;

VI. Should include information about the consequences (if any) of consenting or not consenting (including withdrawing consent);

VII. Must include information about the scope of the consent choice, i.e. service-specific consent, or group-specific consent. If group-specific consent, a link with information about the group;

VIII. Must include information about the fact that the user can withdraw their consent at any time, and how to resurface the Framework UI in order to do so;

IX. Should include information about the fact that some Vendors (if any) are not requesting consent, but processing the user’s data on the basis of their legitimate interest; the fact that the user has a right to object to such processing; and a link to the relevant layer of the Framework UI dealing with processing on the basis of legitimate interests where more information can be found;

X. Must include a call to action for the user to express their consent (for example “Accept”, “Okay”, “Approve”, etc.);

XI. Must include a call to action for the user to customise their choices (for example “Advanced Settings”, “Customise Choices”, etc.).

c. When making use of a so-called layered approach, a secondary layer must be provided that allows the user to: 

I. Review:

• • • the list of named Vendors and a link to each Vendor’s privacy policy,
    • their Purposes, Special Purposes, associated Legal Bases and corresponding retention period,
    • their Features and Special Features and
    • the categories of data collected and processed

II. Review the list of Purposes, Special Purposes, Features, and Special Features including their standard name, their full standard user-friendly text and where applicable their illustrations, as defined in Appendix A, the number of Vendors seeking consent for each of the Purposes (which may also include Vendors not participating in the Framework), and have a way to see those Vendors ;

III. Make granular and specific consent choices with respect to each Vendor, and, separately, each Purpose for which the Publisher chooses to obtain consent on behalf of or more Vendors;

IV. Make granular and specific opt-in choices with respect to each Special Feature for which the Publisher chooses to obtain opt-ins on behalf of one or more Vendors;

V. Where applicable and not disclosed in a 1st layer, view information about the fact that some Vendors (if any) are not requesting consent, but processing the user’s data on the basis of their legitimate interest; the fact that the user has a right to object to such processing; and a link to the relevant layer of the Framework UI dealing with processing on the basis of legitimate interests where more information could be found and the right to object exercised;

VI. Where not disclosed in a 1st layer, view information about the consequences (if any) of consenting or not consenting (including withdrawing consent);

VII. Where applicable, review Vendors’ maximum device storage duration and whether Vendors refresh such duration (by stating, for example, that “duration may expire [n] months/days from your last interaction with the property”, where [n] represents the maximum duration for which the Vendor considers the user consent as valid) as well as, where applicable, review any additional purpose specific storage and access information provided by a Vendor in accordance with the Specifications.

d. When a user accesses a layer, which will be a secondary layer when using a layered approach, allowing them to make granular and specific consent choices with respect to each Purpose, under Policy C(c)(III), and/or to make granular and specific opt-in choices with respect to each Special Feature under Policy C(c)(IV) the default choice must be “no consent”, “no opt-in” or “off”.

e. If a UI displays Vendors who are not registered with IAB Europe for participation in the Framework, the UI must make it possible for users to distinguish between Vendors registered with the Framework, and those who are not. The UI must not mislead others as to the Framework participation of any of the Vendors who are not registered with the MO.

f. A user must be able to resurface the Framework UI from an easily accessible link or call to action, such as a floating icon or a footer link available on each webpage of the Publisher’s website, or from the top-level settings of the Publisher’s app as to allow them to withdraw their consent as easily as it was to give it. If a call to action for the user to express their consent for all Purposes and Vendors was provided in the Initial Layer of the Framework UIs used to request the user’s consent (for example “Consent to all”), an equivalent call to action for the user to withdraw their consent for all Purposes and Vendors must be provided in the Framework UI that the user resurfaces (for example “Withdraw consent to all”).

g. Calls to action in a Framework UI must not be invisible, illegible, or appear disabled. While calls to action do not need to be identical, to ensure they are clearly visible, they must have matching text treatment (font, font size, font style) and, for the text of each, a minimum contrast ratio of 5 to 1. To the extent that an Initial Layer has more than two calls to action, this policy only applies to the two primary calls to action.

h. By way of derogation from Appendix B, Policies C(c)(iii) and (iv) and C(d), a Publisher shall not be required to allow a user to make granular and specific consent or opt-in choices if the Publisher implements a way for the user to access its content without consenting through other means, for example by offering paid access that does not require consenting to any Purposes. For the avoidance of doubt, all other Policies remain applicable.

a. When providing transparency about Purposes, Special Purposes, Features, Special Features, and Vendors in connection with a legitimate interest for the same, transparency must be provided at least through an easily accessible link to the relevant layer of the Framework UI dealing with processing on the basis of legitimate interests.

b. When providing transparency about Purposes, Special Purposes, Features, Special Features, and Vendors in connection with both requesting a user’s consent for the same and a legitimate interest, Policy C(a) applies, and the easily accessible link to the relevant layer of the Framework UI dealing with processing on the basis of legitimate interests required under Policy D(a) must be included in the Initial Layer of the Framework UI presented in line with Policy C(a).

c. When providing transparency about Purposes, Special Purposes, Features, Special Features and Vendors in connection with a legitimate interest for the same, a single secondary layer must be provided that allows the user to:

I. see information about the fact that personal data is processed, and the nature of the personal data processed (e.g. unique identifiers, browsing data);

II. see information about the scope of the legitimate interest processing and scope of any objection to such processing, i.e. service-specific scope, or group-specific scope. If group-specific scope, a link with information about the group.

III. access controls within the Framework UI to object to processing of their personal data on the basis of a legitimate interest;

IV. review the list of Purposes and Special Purposes including their standard name and their full standard user-friendly text and where applicable their illustrations, as defined in Appendix A, the number of Vendors processing their data for each of the Purposes on the basis of legitimate interest (which may also include Vendors not participating in the Framework), and have a way to see those Vendors. V. exercise their right to object with respect to processing under a legitimate interest for each Vendor, and, separately, each Purpose for which the Publisher chooses to help establish Vendors transparency;

VI. review:

• the list of named Vendors and a link to each Vendor’s privacy policy,
• their Purposes, Special Purposes, associated Legal Bases (and a link to each Vendor’s explanation of its legitimate interest(s) at stake) and corresponding retention period,
• their Features, Special Features and
• the categories of data collected and processed.

VII. review where applicable the storage and access information relating to the CMP’s recording of Signals, including the maximum device storage duration.

• Version 2018-04-10.1 – Initial Framework Policies.
• Version 2018-04-25.2 – Added Purpose and Feature Definitions to Appendix A, and UI/UX Guidelines and Requirements to Appendix B.
• Version 2018-10-02.2a – Removed a provision stating CMPs must only work with Vendors registered with the MO. Clarified conditions for providing services to Vendors not registered with the MO.
• Version 2019-08-21.3 – Framework Policies for Version 2.0. Major changes have been made to the Policies, including Appendix A, and Appendix B.
• Version 2020-04-06.3a – Added Stacks 38-42. Removed requirement to disclose Special Purposes and Feature in initial UI layer.
• Version 2020-06-30.3.1 – Added CTA prominence requirement in Appendix B, Policy C and storage duration disclosure requirements in Policy 16(2bis) and Appendix B, Policy C(c)(I).
• Version 2020-08-24.3.2 – Removed non-essential 1st layer requirements and updated 2nd layer requirements in Appendix B, Policy C. Added Appendix B, Policy C(h) introducing a derogation from Appendix B, Policy C(c)(iii), (iv) and (d) on not providing granular choices in certain situations.
• Version 2020-11-18.3.2a – Updated Vendor guidance for Purpose 1 to clarify it must be declared in conjunction with another Purpose, Feature, Special Purpose and/or Special Feature except where processors register for Purpose 1. Added new policy 13(7) to clarify that Vendors should verify signals have been obtained using API.
• Version 2021-02-17.3.2b – Updated Preamble point (ii) to clarify that the Framework is applicable for UK GDPR and PECR.
• Version 2021-04-19.3.3 – Removed prohibition for Vendors to refresh maximum storage duration (Policy 16(2bis)). Updated UI duration disclosure requirements (new Appendix B, Policy C(c)(vii).
• Version 2021-06-22.3.4 – Removed global scope policies, added policies on forwarding TCF signals to URL-based services (new Policies 14(6) and 22(8)).
• Version 2022-06-20.3.5 – Update to indicate the mandatory nature of the provision of a devicestorage.json file by vendors (Chapter III: Policies for Vendors / Policy 16 2bis; Appendix B: User Interface Requirements / C(c)(vii))
• Version 2023-05-15.4.0 – Framework Policies for Version 2.2. Major changes have been made to the Policies, including Appendix A, and Appendix B.
• Version 2024-01-15.4.0.a – Clarified conditions for using Stacks and added Stacks 44 and 45. Added example of stack combination. Improvement of user-friendly text for Purpose 6.
• Version 2024-06-3.5.0 - Introduction of Special Purpose 3 to Appendix A that covers the processing of users’ privacy choices. Added 2nd layer requirement in Appendix B, Policy D for CMP to disclose how and for how long users’ privacy choices are stored on their devices.