Data protection for Moroccan businesses: what actually has to change

For most businesses, data protection is framed as a legal topic and therefore postponed. In practice it is a technical and operational topic: data protection rules mostly ask where personal information lives, who can access it, why you hold it, and how long you keep it. Those are questions your systems either answer or do not.

This article is written from an engineering perspective, not a legal one. It describes what tends to change inside a system — a qualified adviser and the relevant authority's guidance remain the sources for your specific obligations.

Which rules actually apply to you

• Moroccan law on the protection of personal data (Law 09-08), which governs the processing of personal data in Morocco and is overseen by the national data protection authority, the CNDP.
• Formal steps around processing — many categories of processing require a prior declaration or authorisation before they begin.
• Rights for the people whose data you hold — access, correction, and objection — which are practical capabilities your systems must be able to support.
• European data protection rules (GDPR) when you process data of people in the EU, for example by selling to European customers or providing services to European clients who impose this contractually.
• Sector-specific obligations, which often carry stricter rules than general data protection law — finance, health, and employment data being common examples.

What compliance changes in practice

• You stop collecting data you cannot justify. Convenience is not a purpose.
• Systems gain a retention rule: records are deleted or anonymised when the purpose ends, rather than kept indefinitely.
• Access becomes intentional — permissions per role, reviewed, with a record of who saw what.
• The people behind the data can exercise their rights without a developer intervention every time.
• Vendors are assessed before they receive personal data, not after.
• Export and deletion become designed features rather than emergency manual tasks.

Four questions to answer for every system

• What personal data does this system hold, and why does each field exist?
• Who can see it, from inside and outside the business, and is that access still justified?
• How long should it be kept, and what actually happens when that period ends?
• Where does it travel — hosting location, backup location, third-party services, exports, and emails?

If those four answers cannot be given for a system, that is not a paperwork problem. It is a design gap, and it usually indicates that the same system would fare badly if it were ever compromised.

Common gaps we see

• Personal data copied into spreadsheets and shared by email, outside any system with access control.
• Test or demo environments containing real customer data.
• Backups retained indefinitely, long after the records they contain should have been deleted.
• Marketing lists that were collected for one purpose and are used for another.
• Exports created for a report and never deleted from someone's laptop.
• Third-party tools receiving customer data with no review of where it is stored or how long it is kept.

Starting without a big programme

Begin with an inventory: list the systems that hold personal data, what each one contains, and who has access. In most small and mid-sized businesses this takes a week and immediately reveals the gaps worth closing. From there, add retention rules and access reviews to the highest-risk system first, then repeat. Compliance built this way stays current because it is part of how the systems are operated, not a document revisited in a panic.

Good data protection looks a lot like good housekeeping: hold less, know where it is, and let go of it on purpose.

Compliance as a by-product of good design

When a system is designed with clear data ownership, role-based access, and defined retention, compliance becomes a matter of describing what already exists. The expensive path is retrofitting those properties onto a system that was never built with them — which is why the cheapest moment to address data protection is before the next system is built.