Skip to main content
Our services

CNDP compliance & sensitive data

Your personal-data processing brought into compliance — and your platforms designed to stay that way.

Audit RBAC Audit logging Encryption
Request a quote

We bring personal data processing into line with law 09-08 and the requirements of the CNDP, then modify the software so it stays that way: an audit of your processing activities, the declaration or authorisation file, fine-grained role management, access logging and retention periods actually enforced. Budget of 40,000 to 180,000 MAD depending on the number of processing activities and the state of the system. We are an engineering team, not a law firm — and that is precisely the half of the work that is usually missing.

Why this is surfacing now

The CNDP has stepped up its controls, and the sectors it names as priorities include healthcare providers, the pharmaceutical industry, hospitality, online retail and higher education. Many companies have been processing personal data for years without a prior declaration, often without realising it: a customer file, payroll software, a badge system, video surveillance and a contact form are already five distinct processing activities.

What directors discover late

The exposure is not only institutional. For sensitive data — health data in particular — the law provides for financial penalties and a liability that can reach the director personally. This is not a subject you delegate to an IT provider after the fact, and it is not one you close with a document.

Declaration or authorisation: the decision that shapes the file

This is the first question, and the one most companies answer backwards. The regime depends on the nature of the data and the purpose of the processing, not on the size of the company:

  • Declaration — the ordinary regime: you notify the processing to the CNDP before putting it into effect.
  • Prior authorisation — required for the most sensitive processing, foremost health data, along with certain transfers abroad and certain interconnections of files. Here you do not notify: you wait for a decision.

The practical consequence is a schedule, not a formality. Processing subject to authorisation cannot start because the file has been submitted — which, on a software project, has to be built into the delivery plan at scoping rather than discovered in launch week.

The forms

The file is not a single document but the form matching your situation. The three we meet most often:

FormUse
F211Standard prior declaration of a processing activity
F214Simplified prior declaration
F112Application for prior authorisation — standard
F113Application for prior authorisation — simplified

Special case: F115 belongs to neither regime. It declares the identity of the controller of a public register, not an ordinary declaration or authorisation.

The choice of form follows from the mapping, not the other way round. That is why we always start by inventorying the processing activities: a file submitted under the wrong regime comes back, and the time lost is project time.

The deadlines to know

  • 24 hours — the period within which the CNDP issues the receipt for a declaration. It is an acknowledgement, not a decision: a receipt does not attest that the processing is compliant.
  • 8 days — the window in which the CNDP may notify you that it is moving your processing to the prior-authorisation regime, if it judges that the activity presents manifest risks to privacy. It is a power the Commission holds, not a deadline imposed on you.
  • Two months, extendable once only — the period within which the CNDP gives and notifies its decision on an authorisation request. Plan it as a project milestone: four months in the worst case.

One decisive point, and a commonly omitted one: if the file is incomplete, none of these periods start running until the CNDP has received the information or documents it asked for. Filing quickly but incompletely gains nothing.

These deadlines are why compliance is handled at scoping. A healthcare platform that discovers prior authorisation three weeks before delivery has a scheduling problem that neither the lawyer nor the developer can solve.

What we actually do

  • Mapping of processing activities — what data, collected where, stored how long, accessible by whom, shared with whom. It is an inventory, and it almost always surfaces activities nobody had counted.
  • Gap analysis — what is missing against law 09-08: legal basis, informing data subjects, security, control of sub-processors.
  • Regime qualification — declaration or authorisation, activity by activity, and the matching form.
  • The file — preparing the forms and supporting documents, and following through to the decision.
  • Technical remediation — fine-grained roles, access logging, encryption, automatic purge at the end of the retention period, export and deletion on a data subject’s request.
  • Audit documentation — enough to answer a control without reconstructing history under pressure.
  • Consent — collection, proof and withdrawal, including on existing web and mobile journeys.

Your sub-processors are your responsibility

This is the most common blind spot. Your host, your backup provider, your emailing tool, your payroll software vendor and your development agency all process personal data on your behalf. You remain the controller; they are sub-processors. That requires three verifiable things: a written commitment on purpose and security, knowledge of where the data is stored, and a prohibition on onward sub-processing without your agreement.

The question that settles it during a control: where is your data physically, and who else has access to it? Many companies cannot answer for half their tools.

Transfers outside Morocco

Hosting with a foreign provider, using an American emailing service or an audience analytics tool constitutes a transfer of data outside Morocco. It is not prohibited, but it is not neutral: such transfers fall under their own regime and must appear in the file. Discovering them after submission means an amendment — form F112.

Retention periods: the point that fails in practice

Almost every system we audit keeps everything, indefinitely, because nothing was ever programmed to delete. But a retention period is not a policy written in a document: it is an automatic process that runs. Three examples of what that means concretely:

  • An application file that must disappear at its term has to disappear from exports and backups too, after their own retention cycle.
  • A deleted user account cannot leave a name in clear text in access logs kept longer than the account itself.
  • Data needed for accounting does not expire on the same clock as prospecting data — so you need a period per category, not one global period.

This is exactly the kind of work a compliance report cannot do for you.

What a control asks for

Being prepared means being able to produce, without delay: the list of your processing activities and their legal basis, the declaration receipt or authorisation decision, the retention policy as enforced, the notices shown to data subjects, proof of consent where that is the basis relied on, the list of sub-processors and their commitments, the access rights matrix, and the access logs for sensitive data.

Our deliverable is built to answer that list. It is also why we refuse to separate the audit from the technical remediation: half of that evidence only exists if the software produces it.

Why us, and not a law firm

A legal opinion describes what ought to be true. Compliance is settled in the software: who can see which file, what is recorded when someone reads a data item, what happens at the end of the retention period, what remains in backups after a deletion. A compliance report resting on a system that cannot answer those questions protects nobody on the day of a control.

We do both halves of the work — the analysis and the modification of the system. And we do not do the half that is not ours: we give no legal advice, and we work readily with your counsel, who will remain better than us at qualifying an edge case.

The special case of health data

The strictest regime, and our main territory: clinics, laboratories, health funds. A healthcare platform accumulates constraints that cannot be handled separately — prior authorisation, role separation between practitioner, front desk and administration, traceability of access to records, a retention period specific to each category of data. See healthcare platforms and insurance and health funds.

We apply this to ourselves

Our own processing follows the same logic: data minimisation, a preference for business contact details, defined retention periods. We can show you our approach before recommending it to you.

Where do you stand?

If you do not know, start with our CNDP self-assessment: eight questions on your processing activities, an immediate result, free, no sign-up and nothing recorded. It does not replace an audit — it tells you whether you need one.

Going further: what a Moroccan company actually has to do, or tell us about your situation. Ranges on our pricing page.

Ready to start your project?

Let's talk about your operation: we scope the roles and integrations first, then we price it.

Chat on WhatsApp