Cookie policy and consent-banner configuration

Scanning must cover multiple pages and scenarios: before and after login, checkout, forms, video, maps and integrations. Some scripts set identifiers through local storage, pixels or similar technologies, even if the traditional cookie list appears short.

For each technology, the provider, purpose, duration, domain, data and transfer are identified. Classification as “necessary” depends on the function requested by the user, not its commercial usefulness to the operator.

The interface and technical mechanism must be tested together. A “Reject” button that hides the banner but leaves analytics active does not respect the user’s choice.

• Initial display: essential information and easily understood choices.
• Rejection: accessible without disproportionate steps or manipulative design.
• Categories: sufficiently granular for different purposes.
• Default state: non-essential trackers disabled before agreement.
• Withdrawal: as simple as giving consent, with a genuine technical effect.
• Evidence: the banner version and choice, without excessive data collection.

The policy must describe categories, purposes, durations and third parties in accessible language. Automatically generated lists must be checked because a cookie’s technical name does not explain its purpose and may become outdated after an update.

If the tracker transfers data outside the EEA, the privacy policy and transfer analysis must align. Consent to accessing the terminal does not automatically resolve all GDPR obligations relating to subsequent processing.

Plugins, the tag manager and campaigns introduce new trackers. Periodic scanning and approval of scripts before launch prevent discrepancies between the published policy and actual configuration.

Testing must be repeated across browsers and devices for acceptance, rejection, partial preferences and withdrawal. Logs and policy versions must be retained for as long as justified to demonstrate compliance.