Usercentrics Consent Management Platform
& Cookie Banner

It is important to store the visitor’s consent on the server’s side, as well as on the customer’s side.

This results from the documentation obligation and the obligation to provide evidence regarding the consent. If possible, the consent data is stored on servers in the EU. The CMP should also be able to offer on-site provision of consent data.

The user should first be given the option of both consent and refusal. A cookie banner that gives the user no choice but to agree does not meet the requirements for voluntarily given consent and is therefore not GDPR-compliant.

It should be possible to load the technologies requiring consent only after a valid opt-in.

After opt-out, the technologies should not be loaded, not even the opt-out itself. Sending the user to an external third-party website to opt-out is not useful and is not a simple opt-out.

The CMP should also recognize and cover piggyback constellations.

These are cookies that automatically transfer data to other linked cookies that are not on the website itself. These are, for example, affiliate cookies that are partially reloaded.

The CMP should offer to be able to customize the user interface. After all, this is the only way to ensure that website visitors do not feel irritated and annoyed by cookie popups and banners. This could lead to the elaborately designed CI and UI/UX efforts being thwarted.

The consent requirement should apply not only to cookies, but also to other web technologies such as plug-ins and integrated content (e.g. embedded YouTube videos, Google Fonts).

The obligation to obtain consent may arise from factors that result, for example, in data being transferred to a third country such as the USA. In any case, they are subject to the duty to inform according to Art. 13 GDPR.

To prevent the CMP from becoming the next “data octopus”, customer data should be stored separately during processing.

This can be done by not tracking or linking the user’s data. That is, if the identical user gives consent on one website, by default the CMP should not be able to use that consent as consent for another website.

This profiling requires consent in its turn, according to Art. 21 GDPR.

The “iab Transparency” and “Consent Framework” is the first possibility to transfer a consent globally.

The selected CMP should support the iab standard, because in the future personalized advertising will only be controlled with ConsentID in the offer request.

The CMP software should be developed agnostically. This means that it is compatible with any cookie management and website system. 

Since the responsible party must comply with the duty to inform, it makes sense to be able to (automatically) integrate the legally relevant texts of the web technologies into the general privacy policy, e.g., by means of an iFrame.

It is very important to be able to control and change cookie loading policies. In some cases, a company may want to adopt a “soft” setting – for example, to load certain technologies such as web analytics-only cookies without consent.

However, if a ruling by a data authority prohibits this, it must be possible to quickly switch to a zero-cookieload setting.

The sole business purpose of the service provider should be to obtain the respective consent so that the use of the CMP can be based on Art. 6c GDPR.

If a provider pursues further business purposes in addition, it can be assumed that the consent data will likewise be used for these business purposes. Therefore, either in-house development with a separate neutral company or an external provider with privacy-by-design is recommended.

The principle of concreteness can be interpreted as a requirement for granular consent to specific technologies used on the website. Furthermore, out of the principle of minimalism, consent should only be obtained for technology that is actually used on the website.

Consent to a full list of over 350 vendors, as required by the iab solution, is difficult to justify.