Article 23 of Law 09-08: mandatory security

Article 23 of Law No. 09-08 fits in a single sentence. The data controller must take all useful precautions, having regard to the nature of the data and the risks presented by the processing, to preserve the security of the data and to prevent its alteration, loss, or access by unauthorised third parties. That is all. No list of measures, no numeric thresholds, no imposed methodology. The sobriety of the text conceals the depth of the obligation.

This editorial openness has a twofold practical effect. On one hand, it allows the organisation to calibrate its security measures against its own risks — no single mandatory specification. On the other, it shifts the burden of proof: it is up to the organisation to demonstrate that the measures chosen were adapted to the state of the art at the time the incident occurred. And the state of the art is moving fast.

What the state of the art says in 2026

To make ourselves understood, here is the technical baseline that should be demonstrable on any site collecting the slightest piece of personal data in Morocco in 2026. This is not a theoretical ideal, it is what an ordinary auditor checks first — and what will be held against you in case of breach.

TLS encryption across the entire site, version 1.2 at minimum, version 1.3 recommended. No exceptions, including public information pages. The myth that "the home page does not need HTTPS" disappeared about a decade ago in the technical community. Yet it remains the default configuration in a non-negligible fraction of Moroccan hosting setups.

HSTS (HTTP Strict Transport Security) with subdomain inclusion and preload. This is the instruction given to the browser to refuse any downgrade to HTTP, including on the first contact. Without HSTS, an SSL stripping attack remains theoretically possible — rarely used in practice, but its absence is a signal of lax configuration.

A strict Content-Security-Policy. At minimum default-src 'self', ideally enriched with directives by resource type. CSP is the most effective defensive measure against script injection attacks (XSS). It requires an initial configuration effort, but it is a one-off investment that pays off throughout the site's lifetime.

The full set of HTTP security headers: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy disabling unused APIs (camera, microphone, geolocation, sensors). None of these headers takes more than five minutes to configure; their absence is the most immediate marker of a default configuration left as is.

Access management on the principle of least privilege, with strong authentication (MFA) for administrator accounts. No shared accounts, no default authentication, no passwords written in plain text in an internal wiki. Inactive accounts must be deactivated within reasonable timeframes — typically ninety days for employee accounts after departure.

Logging of access to sensitive data, retained for a duration useful for post-incident investigation — generally six to twelve months, longer for regulated sectors. Without logs, the organisation is blind; in case of an incident, it can neither reconstruct the attack, nor notify accurately, nor demonstrate what was not affected.

Backups regular, encrypted, and — this is the part that gets neglected — tested. A backup that has never been restored is a technical fiction. The restoration test, at least annually, should be a governance ritual. Without it, you learn in a crisis situation that the backup is not usable, usually at the worst possible moment.

Email anti-spoofing via SPF, DKIM and DMARC with a policy at least in quarantine, ideally in reject. A domain without DMARC in 2026 is a domain that anyone can impersonate to send emails in your name. This is not a peripheral topic: the majority of major data incidents start with phishing exploiting an unprotected domain identity.

All of this is measurable, objectively scored, and public. The Mozilla Observatory gives a letter grade that summarises a good part of these points. OWASP provides the methodological framework to go further (ASVS for applications with authentication, MASVS for mobile). The CNIL publishes practical security guides that remain a useful reference, even outside the strict GDPR framework.

The bridge with administrative compliance

Where management often underestimates the scope of Article 23 is in its articulation with CNDP formalities. An F211 or F112 declaration that describes security measures does not become a truth by its mere existence. It becomes an enforceable commitment. If you declare that your backups are encrypted and tested every month, and an inspection reveals that they are not, you have two problems: the security failure and the declarative inaccuracy. The second aggravates the first.

This observation changes the work of building CNDP files. What appears under the "security measures" section must reflect reality, not an optimistic projection. If reality lags behind what you would like to describe, it is better to describe what exists and add a dated improvement plan, rather than ticking boxes that lie. The CNDP prefers documented truth to polished fiction — this is consistent with its graduation doctrine.

Incident notification — the area that will shift

For now, Law 09-08 does not impose an explicit obligation to notify the Commission of a data breach, unlike Article 33 of the GDPR which sets a seventy-two hour timeframe. The reform expected for several years should introduce an equivalent provision, aligned with the European standard. In the meantime, the recommended practice — which the CNDP encourages in its public deliberations and which the EDPB documents in its guidelines — is to notify in case of a significant incident, out of diligence.

In concrete terms, this means having prepared in advance a notification procedure: who makes the decision, within what timeframe, through which channel (CNDP in parallel, where applicable, with European authorities in case of GDPR exposure), with which template, what communication to the data subjects if necessary. Building this procedure calmly takes a day; building it during an incident takes three or four, with errors.

In the Moroccan economic press (Médias24, TelQuel), the published data incidents almost invariably show the same pattern. An avoidable technical incident. A late discovery. Poorly calibrated communication. A CNDP that must reconstruct the facts from contradictory fragments. A reputation that pays the final cost. All of this is largely preventable, and that is precisely what Article 23 targets through its open formulation.

The audit as a ritual, not an event

The most common positioning error consists in treating security as a one-off event — an audit done two years ago, fixes deployed since, no further follow-up. This is unsuited to the rhythm of the Web. A site secured in 2024 may be vulnerable in 2026 simply because standards have moved on and the technical stack has accumulated obsolete dependencies.

The defensible rhythm is an annual audit in full, supplemented by an automated monthly scan of headers and dependencies. The majority of degradations can be detected by passive observation. The annual audit serves to dig into topics that do not appear in the scan: code quality, management of internal permissions, configuration of third-party services, relevance of retained logs.

For applications that expose authentication, payment, or APIs, we add a pentest every two to three years. Not every year if the perimeter has not changed substantially — that would be theatrical. But not every five years either. The two-to-three-year window corresponds to the typical lifetime of a non-trivial application architecture.

Our own posture, enforceable

At DataSouv we apply to ourselves what we recommend — that is the public commitment recorded on the /securite page. Mozilla Observatory score target A+, full HTTP headers published in plain sight, processing register displayed publicly, security.txt in place, no third-party trackers, European hosting. If we say it is feasible and useful, we show it.

The objective is not exhibition. It is consistency. An organisation that sells security and compliance without applying them to itself sends the most damaging signal there is. The Moroccan market has seen this contradiction too often. It is one of the simple arguments that distinguish serious actors from opportunistic ones — and it is, at near-zero cost, one of the most effective differentiation levers.

Resources

• Mozilla Observatory — objective scoring of HTTP headers
• OWASP ASVS — application verification levels
• CNIL — security guides — comparative European doctrine
• EDPB — incident guidelines — notification best practices
• Official CNDP website
• Pillar guide — CNDP Compliance in Morocco 2026
• Our public security posture
• Service — Technical security audit

Article 23 is short; what it covers is not. The best defence against its ambiguity is documentation. Documenting the measures, documenting the reviews, documenting the fixes, documenting the exceptions and their justifications. An organisation that can produce a complete security file in two clicks shows, independently of the audit result, that it takes its obligations seriously. This is what the CNDP doctrine values. It is also what transforms compliance spending into a governance asset.

Salma O. — application security specialist, DataSouv contributor. Article reviewed and validated by Amine Rais, founder.