CNDP cookie banner — real compliance
Nine out of ten cookie banners observed on the Moroccan web are trompe-l'œil: they display consent, they do not obtain it. This is precisely what a CNDP inspection detects fastest.
The cookie banner is the compliance topic where the gap between perception and reality is the widest. A management team that sees a beautiful banner displayed on the home page of its site easily convinces itself that compliance is taken care of. The auditor who opens the page in a browser in investigation mode generally discovers the opposite: third-party scripts that have already fired, tracking cookies dropped before any click, no useful categorisation, no archived proof of consent. This is, statistically, the most widespread point of non-compliance on the Moroccan web.
What the doctrine requires, plainly
The legal foundation combines Law 09-08 on the protection of personal data and the principles of the European ePrivacy directive (article 5(3)) which the CNDP applies in practice in its graduated doctrine. Four requirements stand out:
Explicit consent is required for any cookie or tracker that is not strictly necessary for the functioning of the service. A technical session, a shopping basket, a language preference: these cookies can operate without prior consent. Everything else — audience measurement, marketing, personalisation, social networks — requires a clear positive action from the user.
This act must be informed by accessible prior information. Not a vague mention "we use cookies to improve your experience", but precise information on the categories of cookies dropped, their purposes, the recipients, the retention period. The "manage my cookies" page must be accessible without friction from anywhere on the site.
Consent must be specific by purpose. Not a global consent that authorises everything in one click. Per-category granularity is the standard norm: at least two categories (necessary + non-necessary), ideally four or five for useful granularity.
And it must be as simple to withdraw as to give. This means that at any time, the user must be able to revisit their choices with the same number of clicks it took to express them. A prominent "accept all" button on the home page and a withdrawal hidden in the cookie policy three clicks deep is an unfair pattern — typical of cosmetic banners.
The technical test in thirty seconds
Here is how to quickly check whether a cookie banner is genuinely compliant or merely cosmetic. The test literally takes thirty seconds per site.
Open the site in a private browsing window (to neutralise existing cookies). Open the developer tools, network tab. Reload the page. Before clicking anything in the banner, look at the outgoing requests. If a single request goes out to a tracking domain — google-analytics.com, googletagmanager.com, facebook.net, linkedin.com/insights, hotjar.com, clarity.ms — the site is non-compliant. It is that simple.
The second test: click "reject" in the banner, then check the browser's "storage" tab. No tracking cookies should be present. If any are found, the banner has a cosmetic but not operational effect.
The third: navigate to three other pages, then come back and check the storage. Consent must be persistent across pages — the user should not have to reconfirm their choice on every page.
The majority of Moroccan professional sites fails at least one of the three tests. Not because teams are incompetent, but because the "plug and play" solutions they have installed do not actually do the work. They display; they do not block.
Runtime blocking — what separates compliance from façade
Blocking a tracker before consent is not a secondary technical option. It is the central issue. The difference between a banner that "informs that cookies are being dropped" (and effectively drops them) and a banner that "obtains consent before dropping anything" is a difference of nature, not of degree.
Technically, two approaches exist.
The runtime interception approach consists of preventing the browser from executing third-party scripts as long as consent has not been given. An intermediate layer — generally a CMP (Consent Management Platform) — intercepts script loading and holds it back. When the user consents to a category, the corresponding scripts are released. When the user withdraws consent, the scripts are no longer executed on the next load. This approach is technically more complex, but it is the only one that produces real compliance.
The conditional loading approach consists of only injecting third-party scripts after reading the stored consent. Simpler to implement, it requires all tracking scripts to be loaded through a mechanism controlled by the organisation's code. It suits a modern site built on a JavaScript framework, less so a WordPress site with twenty plugins that inject their own scripts.
The pseudo-blocking approach — which displays a banner but lets everything load in the background — is not an approach, it is a breach. Yet, this is what dominates the market.
The pitfall of the non-compliant compliance provider
Here is a situation we encounter regularly in audits. An organisation has invested in a consent management solution, usually Cookiebot, OneTrust, or an equivalent. It thinks the topic is handled. It pays a monthly subscription on that basis.
However, the main market solutions are American SaaS. Their use implies a transfer of personal data (at minimum, browser fingerprints and consent choices) to the United States or other jurisdictions outside the EU/Morocco. This transfer must be authorised under F118 or framed by standard contractual clauses adopted explicitly. Many Moroccan organisations have deployed Cookiebot or OneTrust without addressing this dimension. The result: the solution meant to solve a compliance problem has created a new one, sometimes more visible.
The pragmatic alternative is to use self-hosted solutions in the EU — there are several good open-source ones (Klaro, Tarteaucitron, Orejime) — or to develop a minimal CMP integrated into the site when the scope is limited. Less glamorous than a SaaS solution, but aligned with the sovereignty logic that the doctrine encourages.
The "cookie policy" page — what it must contain
Beyond the banner, the dedicated page must exist, be easily accessible, and contain at minimum:
The exhaustive list of cookies dropped, organised by category. For each cookie: technical name, concrete purpose, retention period, type (first-party or third-party). This list is supposed to reflect what actually happens on the site — not a theoretical projection. When auditing it, the content of the page is compared with the actual technical inventory.
An explanation of the choices offered to the user. What they can do to modify, withdraw, delete. With a direct link to the management interface, not just to the browser settings.
The identity of the data controller for these cookies, with a contact channel to exercise rights. Logically, this is the DPO or the general contact channel provided in the privacy policy.
The CNDP doctrine does not set a single format for this page, but the recommendations of the CNIL for the French context provide a highly operational reference, which can be transposed by enriching it with Moroccan specifics.
The trajectory of a successful compliance rollout
On an existing site starting from scratch on the cookie side, here is the trajectory that works:
Week 1: full technical inventory. Which cookies are dropped. By which scripts. For which purposes. Without this inventory, any subsequent action is disorganised.
Weeks 2 to 3: classification of cookies by category and trade-offs. Which are strictly necessary (really, not for convenience)? Which fall under audience measurement? Which are marketing? Which are third-party trackers that could be eliminated?
Weeks 3 to 5: implementation of the CMP with effective runtime blocking. Tests in a pre-production environment. Validation that blocking works before deployment.
Week 6: switch to production with attentive monitoring. Checking consent rates, adjustments to the banner wording if necessary.
Weeks 7 to 8: drafting of the cookie policy page aligned with the post-deployment technical reality. Updating the privacy policy with an explicit reference to the cookie page.
Week 9: final audit by an external eye. This is the step most often skipped and yet the one that reveals the details that went unnoticed.
Resources
- CNIL — cookies and trackers
- EDPB — consent guidelines
- Klaro — self-hostable open-source CMP
- Official CNDP site
- Pillar guide — CNDP compliance in Morocco 2026
- F118 and international transfers
- Service — Compliance rollout support
In the Moroccan business press (Médias24, L'Économiste), cookie topics regularly feature in tech sections for three or four years now. The market has globally absorbed the principle, without having absorbed the practice. The gap between the two is precisely what a serious audit brings to light, and that is what gives value to structured support. The banner that makes the eye smile and the auditor wince has become a cliché of the market — and one of the few defects that fixes well.
Mehdi A. — data protection expert, DataSouv contributor. Article reviewed and validated by Amine Rais, founder.
Frequently asked questions
Does the absence of a response count as consent?
No. Silence, continued browsing, or page scrolling do not amount to consent. This position is aligned with ePrivacy doctrine and European recommendations, and the CNDP applies it in practice. A banner that drops tracking cookies before an explicit click is in breach, even if a banner is shown.
Should trackers be blocked before consent?
Yes, and this is where the difference between real compliance and façade compliance plays out. The banner must prevent the execution of third-party scripts — Google Analytics, Meta Pixel, LinkedIn Insight, etc. — before the user gives explicit consent. Many solutions show a banner but block nothing in the background. The test: a curl on the home page before any click should reveal no connection to a third-party tracking domain.
How many consent categories should be offered?
At least two: necessary (which do not require consent) and non-necessary. Ideally four to five for useful granularity: necessary, audience measurement, marketing, personalisation, social networks. A single 'global' consent is not compliant because it does not respect the required specificity of consent.
Should proof of consent be kept?
Yes. Date, time, accepted categories, version of the banner at the time of consent. This traceability is what makes it possible to respond to an inspection. Without proof, the position becomes indefensible: the organisation claims to have obtained consent it cannot demonstrate. Storage can be local (consent cookie) or server-side (recommended for high-traffic sites).
Are Cookiebot and OneTrust compliant solutions?
Technically, these solutions can be compliant if properly configured. Politically, they raise a specific issue in Morocco: they are SaaS hosted outside the EU/Morocco that themselves process personal data to provide the service. Their use triggers an international transfer that must be authorised under F118 or covered by standard contractual clauses. Many Moroccan organisations use these tools without having addressed their own compliance — a classic case of a provider supposed to bring compliance while creating a new breach.