Law No. 2008-12: building CDP compliance into the scoping of an SAP or Salesforce project.

Let us state from the outset what this text is not: legal advice. We are a consulting and technology firm. What we describe here is how the law translates into an SAP or Salesforce project, and what has to be decided, and when, so as not to discover it too late. The precise formalities are a matter for your legal counsel and for the Commission de protection des données personnelles itself.

What the law covers

Law No. 2008-12 of 25 January 2008 governs the processing of personal data in Senegal, that is, any information that makes it possible to identify a person, directly or otherwise. It designates a data controller, the company that decides on the purposes and means, and imposes obligations on it: a specified and legitimate purpose, data proportionate to that purpose, a limited retention period, security and confidentiality, and information of the persons concerned. It grants those persons rights: to be informed, to access their data, to have it rectified, to object to certain processing operations.

It establishes a supervisory authority, the CDP, with which processing operations are subject to prior formalities. Depending on the nature of the data and the processing, this is a declaration or a request for authorisation, with certain categories of data, known as sensitive, calling for a stricter regime. Finally, the law governs transfers of data outside Senegal, which directly concerns any project hosted abroad or operated by an international group.

Why the subject comes up too late

Three reasons, which we find everywhere. The first is organisational: the project is sponsored by finance, HR or sales, and nobody on the project team feels responsible for compliance. The second is cultural: people think the law targets large platforms or banks, not an industrial company or a services firm. The third is technical: vendors and integrators talk about security, backups and access rights, and the team concludes that compliance is covered. It is not. Security protects the data; compliance justifies processing it.

The cost of the delay is concrete. A “health status” field added to an employee record with no declared purpose. A customer base migrated with prospect data collected without notice. Hosting chosen outside the country without the transfer question having been raised. Each of these decisions is corrected at design stage in one meeting. After go-live, it is corrected through a data migration, a contract amendment or a new formality.

Security protects the data. Compliance justifies processing it. A project that confuses the two discovers the second after go-live.

What it changes in an ERP

In SAP S/4HANA, SAP SuccessFactors or Odoo, the most sensitive data is that of human resources and payroll. The project must decide which data is really necessary: civil status and bank account are, in order to pay; union membership, religion or health data fall under a special regime and have a place only if a precise purpose justifies it. It must set retention periods, taking into account accounting and social record-keeping obligations, then implement them in the system: archiving, blocking, deletion. It must organise access rights by role, with a trace of who consults sensitive data. And it must plan how an employee exercises their right of access, without that going through an improvised manual extract.

Suppliers and customers who are natural persons are also concerned. A self-employed subcontractor or a private customer is a person within the meaning of the law. The purchasing module and the sales module therefore process personal data, with the same questions of purpose, retention and access.

What it changes in a CRM

Salesforce Sales Cloud, Service Cloud and Marketing Cloud are designed to collect, enrich and exploit contact data. That is their reason for being, and it is what calls for particular vigilance. Three subjects dominate. The first is collection: where do the contacts come from, were they informed, is a purchased file or one imported from an old tool usable? The second is scoring and segmentation: classifying people according to their value or behaviour is a processing operation in its own right, which must be declared and explained, and whose effects the persons concerned can contest. The third is the campaign: automated sending of messages by SMS, e-mail or WhatsApp requires a legal basis, a simple way to opt out and respect for that opt-out across all channels.

A well-designed CRM carries these rules in its data: the source of the contact, the date and method of their information, their communication choices, channel by channel, and the date beyond which they must be archived. That is not a compliance module. It is a data model thought through at scoping.

Transfers and hosting

The hosting question is often settled for reasons of cost or performance, without the data transfer being examined. Yet a CRM in public cloud, an ERP hosted by a group outside Senegal, a shared services centre in another country, or a support provider accessing the production database remotely are all situations that may constitute a transfer. The project must inventory them, discuss them with its legal counsel, and include the necessary clauses in contracts with vendors and providers, before signing. We address this dimension in our cloud offering, where data location is a selection criterion on a par with latency and cost in foreign currency.

Checklist by project phase

• Scoping. Name a compliance owner on the project team. Inventory the processing operations the future system will carry and their purposes. Identify sensitive data. Raise the question of hosting and transfers. Consult legal counsel on the formalities to initiate with the CDP and on their timeline.
• Design. Limit fields to necessary data. Define retention periods and archiving rules. Design roles and authorisations. Provide in the data model for the source, the information given and the choices of the persons concerned. Describe how rights of access, rectification and objection will be handled.
• Build. Configure authorisations and traceability. Encrypt or mask sensitive data in test environments. Check that interfaces, notably between SAP and Salesforce, do not duplicate data unnecessarily.
• Data migration. Sort before migrating. Data whose purpose or origin cannot be justified must not enter the new system. It is a rare opportunity to purge.
• Go-live. Make sure the formalities are completed or under way. Inform the persons concerned, employees and customers, of the new processing. Train users in access rules and in handling requests from individuals.
• Operations. Review authorisations regularly. Apply the planned purges. Keep the inventory of processing operations up to date with every functional change. Include these reviews in the support and application management contract.

The case of UEMOA groups

A group present in several States of the union shares a currency and a harmonised business law. It does not share a data protection authority. Each country has its own law and its own authority, with formalities, timelines and requirements that differ. A regional CRM or a group ERP must therefore be designed so that each subsidiary remains responsible for its own processing, with data partitioned by country where local law requires it, and a compliance file per State. The temptation of a single database, governed by the rules of one country, is strong. It does not hold.

Compliance is not a brake on projects. It is a design requirement, like performance or security, that is paid for at scoping and pays off in operations. Our IT security & risk offering builds it into our SAP and Salesforce programs, from the very first workshop.