Category: TCF and Vendors
Disclosed Vendors
Also known as: Disclosed Vendors segment, disclosedVendors
Simply put
Disclosed Vendors is a part of the consent signal used in the IAB Europe Transparency & Consent Framework (TCF) that records which third-party companies (vendors) were shown to a user during the consent process. It lets those vendors check whether they were actually presented to the user, which matters when they rely on so-called Special Purposes that do not require explicit consent. It does not, by itself, indicate what a user consented to; it indicates disclosure.
Formal definition
Within the IAB Europe TCF, 'Disclosed Vendors' is a mandatory segment of the Transparency and Consent (TC) string. According to the evidence, it functions as a binary signal per vendor (1 = disclosed, 0 = not disclosed), allowing a vendor to determine whether it was disclosed to the end user, which is relevant for processing under TCF Special Purposes and Features. The IAB Europe TCF Policies note that Special Purposes and Features must always be disclosed where at least one disclosed vendor has declared its use of them. Per the transition guidance, from 28 February 2026 vendors affected by prior signalling ambiguity must recognise and act on the disclosedVendors segment appropriately. Note the scope limits of this definition: the segment concerns disclosure signalling within the TCF only and does not, in itself, evidence valid consent under the GDPR, nor does its presence guarantee compliance with the ePrivacy Directive's rules on storing or accessing information on a user's device. This entry describes the segment's role at a conceptual level based on the cited sources and does not specify the low-level encoding of the segment, which is defined in the TCF technical specification and is out of scope here.
Why it matters
The Disclosed Vendors segment addresses a specific gap in the TCF consent signal: it records whether a given vendor was actually presented to the user during the consent flow, as distinct from what the user consented to. This distinction matters most for vendors relying on TCF Special Purposes and Features, which do not require explicit consent but do require disclosure. A vendor operating under a Special Purpose needs a reliable way to confirm it was disclosed; the Disclosed Vendors segment provides that binary signal (1 = disclosed, 0 = not disclosed) on a per-vendor basis.
Who it's relevant to
Vendors relying on Special Purposes and Features
Third-party companies that process data under TCF Special Purposes or Features, rather than under explicit consent, depend on this segment to confirm they were disclosed to the user. Because such processing turns on disclosure rather than consent, reading the Disclosed Vendors segment correctly is central to determining whether the vendor may proceed under the framework.
Consent management platform (CMP) implementers
CMPs generate the TC string and are responsible for populating the Disclosed Vendors segment accurately. Since the segment is mandatory in the current TCF version, omitting it produces an invalid string. Implementers should also account for the transition guidance requiring affected vendors to recognise and act on the disclosedVendors segment from 28 February 2026.
Privacy officers and compliance teams
Teams overseeing TCF participation should understand that disclosure signalling is distinct from consent. The Disclosed Vendors segment evidences that a vendor was presented to the user; it does not, on its own, demonstrate valid GDPR consent or ePrivacy compliance. Legal adequacy of the overall consent flow requires separate assessment and depends on facts beyond the TC string.
Web developers and adtech integration engineers
Engineers integrating TCF signals into ad delivery, analytics, or downstream vendor calls need to parse the Disclosed Vendors segment reliably and treat its absence as an invalid-string condition rather than a permitted default state. The exact encoding is specified in the TCF technical specification, which should be consulted for implementation detail.
Inside Disclosed Vendors
Disclosed Vendors segment (DisclosedVendors)
An optional-in-earlier-versions but, since TCF v2.3, mandatory segment of the IAB Transparency and Consent Framework (TCF) TC string. It records which vendors were disclosed to the user in the consent interface, and its absence renders a TC string invalid under the current specification.
Encoded vendor IDs only
The segment encodes only the numeric IDs of the vendors that were disclosed to the user. It does not store vendor names, controller/processor roles, processing purposes, data categories, or retention periods; those details reside in the Global Vendor List (GVL) and other documentation, not in this segment.
OptimizedIntRange encoding
Vendor IDs in the segment are represented using an OptimizedIntRange structure, a bit-efficient encoding that expresses the disclosed set as a combination of individual IDs and ID ranges to keep the string compact.
Purpose within the TCF
The segment supports transparency and auditability by signalling the set of vendors surfaced to the user, which is distinct from the vendors for whom consent or legitimate interest was actually established (recorded elsewhere in the core TC string).
Relationship to the Global Vendor List
The IDs in the segment are meaningful only by reference to the GVL, which is the authoritative source for a vendor's identity, declared purposes, and legal bases. The segment itself is a pointer to those entries, not a copy of them.
Common questions
Answers to the questions practitioners most commonly ask about Disclosed Vendors.
Does the Disclosed Vendors segment store vendor details like names, roles, purposes, and retention periods?
No. The Disclosed Vendors segment does not store descriptive vendor information such as names, controller/processor roles, processing purposes, data categories, or retention periods. Under the IAB TCF specification, the segment encodes only the numeric IDs of the vendors that were disclosed to the user, using an optimized integer range encoding. The descriptive attributes you may associate with each vendor live in the Global Vendor List (GVL), which is maintained separately and referenced by vendor ID rather than embedded in the TC string. When you need vendor names, purposes, or legal roles, you should resolve the disclosed vendor IDs against the GVL rather than expecting to read those attributes from the segment itself.
Is the Disclosed Vendors segment an optional part of the TC string that can safely be absent?
No, not under current versions of the framework. Since TCF v2.3 (introduced in April 2025), the Disclosed Vendors segment is mandatory, and a TC string that omits it is invalid. This is a change from earlier expectations, so guidance or older documentation describing the segment as optional or treating its absence as a valid state should be considered out of date. If you are working with strings generated under the current specification, you should treat the presence of this segment as a validity requirement rather than a nice-to-have. Note that the precise version behavior depends on which TCF version a given CMP or integration implements, so confirm the version in use when auditing existing strings.
How do I read the vendors that were disclosed to a user from a TC string?
Decode the TC string, locate the Disclosed Vendors segment, and extract the set of vendor IDs it encodes through the optimized integer range representation. Those IDs identify which vendors were disclosed to the user in the CMP interface. To turn the IDs into meaningful information, resolve each against the Global Vendor List to obtain the vendor name, declared purposes, and legal bases. Most established TCF-aware libraries and the IAB's own tooling handle the segment decoding for you, so in practice you would call the decoder and read the resulting list rather than parsing the bitfield manually.
How should our CMP populate the Disclosed Vendors segment?
The segment should reflect the vendors that were actually presented to the user during the disclosure step, based on the vendors your CMP configuration surfaces from the Global Vendor List. As a practical matter this is handled by the CMP's encoding logic rather than by hand. Because the segment is mandatory in the current specification, verify that your CMP produces it in every string it generates. If you operate a custom or heavily modified CMP, confirm with your vendor or engineering team that disclosure logic and encoding stay aligned with the framework version you are certifying against.
How can we validate that the Disclosed Vendors segment in our TC strings is correct?
Run generated strings through a TCF-compliant decoder or the IAB's validation tooling and confirm that the segment is present, decodes without error, and yields the expected set of vendor IDs. Because a missing segment renders the string invalid under the current specification, absence should be treated as a validation failure. Beyond structural validity, check that the disclosed IDs match the vendors your interface actually showed the user, since a well-formed segment that misrepresents what was disclosed is a substantive problem even when it passes a syntax check. Validation confirms format and consistency; it does not by itself establish that your overall consent collection meets applicable legal requirements.
What is the difference between the Disclosed Vendors segment and the vendor consent and legitimate interest sections of the core string?
The Disclosed Vendors segment records which vendors were shown to the user, while the vendor consent and legitimate interest fields in the core string record the user's actual choices for each vendor. In other words, disclosure and permission are tracked separately: a vendor can be disclosed without the user having granted consent or legitimate interest for it. When assessing whether a given vendor may process data, you should read the consent and legitimate interest signals, and use the Disclosed Vendors segment to establish what was communicated to the user. Whether that disclosure and those signals are sufficient for lawful processing depends on the applicable legal regime and facts outside the string itself.
Common misconceptions
The Disclosed Vendors segment stores rich vendor metadata such as names, controller/processor roles, purposes, data categories, and retention periods.
The segment encodes only vendor IDs via an OptimizedIntRange. Descriptive attributes about each vendor are held in the Global Vendor List, not within the segment. Treating the segment as a self-contained vendor record is inaccurate.
The Disclosed Vendors segment is optional, so its absence is a valid state.
Since TCF v2.3 (introduced in 2025) the segment is mandatory, and a TC string that omits it is invalid under the current specification. Guidance written for earlier TCF versions that described the segment as optional should be treated as outdated.
Vendors listed in the Disclosed Vendors segment are the vendors that received consent.
Disclosure and consent are distinct. The segment indicates which vendors were shown to the user, while consent and legitimate-interest signals for specific vendors are carried in other parts of the TC string. A vendor can be disclosed without having obtained consent.
Best practices
Populate the Disclosed Vendors segment in every TC string you generate, since it is mandatory under TCF v2.3 and its omission makes the string invalid.
Encode the disclosed vendor set using the OptimizedIntRange structure defined by the specification, and validate the output against the current TCF technical documentation.
Resolve vendor IDs against the current Global Vendor List rather than assuming the segment carries names, roles, purposes, or retention details, which it does not.
Keep the disclosed vendor set consistent with what your consent interface actually presents to users, and treat disclosure as separate from recorded consent or legitimate interest.
Update any tooling, templates, or documentation that still describe the segment as optional, as this reflects pre-v2.3 behaviour and can mislead implementers.
Retain your consent records and configuration alongside legal review, remembering that correct segment encoding supports but does not by itself establish compliance with the GDPR or ePrivacy rules.
