Gesetz Nr. 2008-12: CDP-Konformität ab der Rahmensetzung eines SAP- oder Salesforce-Projekts.

Halten wir gleich fest, was dieser Text nicht ist: eine Rechtsberatung. Wir sind ein Beratungs- und Technologieunternehmen. Was wir hier beschreiben, ist die Art und Weise, wie sich das Gesetz in einem SAP- oder Salesforce-Projekt niederschlägt, und was wann zu entscheiden ist, um es nicht zu spät zu entdecken. Die genauen Formalitäten obliegen Ihrer Rechtsberatung und der Commission de protection des données personnelles selbst.

Was das Gesetz abdeckt

Das Gesetz Nr. 2008-12 vom 25. Januar 2008 regelt die Verarbeitung personenbezogener Daten im Senegal, also jeder Information, die eine Person unmittelbar oder mittelbar identifizierbar macht. Es benennt einen Verantwortlichen, das Unternehmen, das über Zwecke und Mittel entscheidet, und legt ihm Pflichten auf: einen bestimmten und rechtmäßigen Zweck, diesem Zweck angemessene Daten, eine begrenzte Aufbewahrungsdauer, Sicherheit und Vertraulichkeit sowie die Information der betroffenen Personen. Es erkennt diesen Personen Rechte zu: informiert zu werden, auf ihre Daten zuzugreifen, sie berichtigen zu lassen, bestimmten Verarbeitungen zu widersprechen.

Es richtet eine Aufsichtsbehörde ein, die CDP, bei der Verarbeitungen vorab anzuzeigen sind. Je nach Art der Daten und der Verarbeitung handelt es sich um eine Anzeige oder um einen Genehmigungsantrag, wobei bestimmte, als sensibel geltende Datenkategorien einer strengeren Regelung unterliegen. Schließlich regelt das Gesetz die Übermittlung von Daten aus dem Senegal heraus, was jedes im Ausland betriebene oder von einem internationalen Konzern geführte Projekt unmittelbar betrifft.

Warum das Thema zu spät kommt

Drei Gründe, die wir überall wiederfinden. Der erste ist organisatorisch: Das Projekt wird von der Finanzabteilung, der Personalabteilung oder dem Vertrieb getragen, und niemand im Projektteam fühlt sich für die Konformität verantwortlich. Der zweite ist kulturell: Man meint, das Gesetz ziele auf große Plattformen oder Banken, nicht auf ein Industrie- oder Dienstleistungsunternehmen. Der dritte ist technisch: Anbieter und Integratoren sprechen von Sicherheit, Sicherung und Zugriffsrechten, und das Team schließt daraus, die Konformität sei abgedeckt. Sie ist es nicht. Sicherheit schützt die Daten; Konformität rechtfertigt, dass man sie verarbeitet.

Die Kosten der Verspätung sind konkret. Ein Feld „Gesundheitszustand“, das einer Personalakte ohne erklärten Zweck hinzugefügt wurde. Eine Kundenbasis, die mit Interessentendaten migriert wurde, die ohne Information erhoben worden waren. Ein Betriebsort außerhalb des Landes, gewählt, ohne dass die Übermittlungsfrage gestellt wurde. Jede dieser Entscheidungen lässt sich in der Konzeption in einer Sitzung korrigieren. Nach der Produktivsetzung braucht es dafür eine Datenübernahme, einen Vertragsnachtrag oder eine neue Formalität.

Sicherheit schützt die Daten. Konformität rechtfertigt, dass man sie verarbeitet. Ein Projekt, das beides verwechselt, entdeckt die zweite nach der Produktivsetzung.

Was sich in einem ERP ändert

In SAP S/4HANA, SAP SuccessFactors oder Odoo sind die sensibelsten Daten die aus Personalwesen und Lohnabrechnung. Das Projekt muss entscheiden, welche Daten tatsächlich nötig sind: Personenstand und Bankverbindung sind es, um zu bezahlen; Gewerkschaftszugehörigkeit, Religion oder Gesundheitsdaten unterliegen einer besonderen Regelung und haben nur dann ihren Platz, wenn ein genauer Zweck das rechtfertigt. Es muss die Aufbewahrungsdauern festlegen, unter Beachtung der handels- und sozialrechtlichen Aufbewahrungspflichten, und sie anschließend im System umsetzen: Archivierung, Sperrung, Löschung. Es muss die Zugriffsrechte je Rolle ordnen, mit Nachvollziehbarkeit der Zugriffe auf sensible Daten. Und es muss vorsehen, wie eine Mitarbeiterin ihr Auskunftsrecht ausübt, ohne dass dies über einen improvisierten manuellen Auszug läuft.

Lieferanten und Kunden, die natürliche Personen sind, sind ebenfalls betroffen. Ein Subunternehmer im Handwerk oder eine Privatkundin ist eine Person im Sinne des Gesetzes. Der Einkaufs- und der Vertriebsbereich verarbeiten also personenbezogene Daten, mit denselben Fragen nach Zweck, Dauer und Zugriff.

Was sich in einem CRM ändert

Salesforce Sales Cloud, Service Cloud und Marketing Cloud sind darauf ausgelegt, Kontaktdaten zu erheben, anzureichern und zu nutzen. Das ist ihr Daseinszweck, und genau das verlangt besondere Wachsamkeit. Drei Themen überwiegen. Das erste ist die Erhebung: Woher stammen die Kontakte, wurden sie informiert, ist eine gekaufte oder aus einem Altsystem importierte Datei verwendbar? Das zweite sind Scoring und Segmentierung: Personen nach Wert oder Verhalten einzuordnen ist eine eigenständige Verarbeitung, die anzuzeigen und zu erklären ist und deren Wirkungen die Betroffenen bestreiten können. Das dritte ist die Kampagne: Der automatisierte Versand von Nachrichten per SMS, E-Mail oder WhatsApp setzt eine Rechtsgrundlage voraus, eine einfache Widerspruchsmöglichkeit und die Beachtung dieses Widerspruchs auf allen Kanälen.

Ein gut entworfenes CRM trägt diese Regeln in seinen Daten: die Quelle des Kontakts, Datum und Art seiner Information, seine Kommunikationswünsche Kanal für Kanal und das Datum, ab dem er zu archivieren ist. Das ist kein Konformitätsmodul. Das ist ein Datenmodell, das ab der Rahmensetzung durchdacht wurde.

Übermittlung und Betriebsort

Die Frage des Betriebsorts wird oft aus Kosten- oder Leistungsgründen entschieden, ohne dass die Datenübermittlung geprüft wird. Dabei sind ein CRM in der öffentlichen Cloud, ein von einem Konzern außerhalb des Senegals betriebenes ERP, ein Shared-Service-Center in einem anderen Land oder ein Support-Dienstleister mit Fernzugriff auf die Produktivdatenbank allesamt Situationen, die eine Übermittlung darstellen können. Das Projekt muss sie erfassen, mit seiner Rechtsberatung besprechen und die nötigen Klauseln vor der Unterschrift in die Verträge mit Anbietern und Dienstleistern aufnehmen. Wir behandeln diese Dimension in unserem Angebot Cloud, wo die Lokalisierung der Daten ebenso ein Auswahlkriterium ist wie Latenz und Kosten in Devisen.

Checkliste je Projektphase

• Rahmensetzung. Eine für Konformität verantwortliche Person im Projektteam benennen. Die Verarbeitungen, die das künftige System tragen wird, und ihre Zwecke erfassen. Sensible Daten identifizieren. Die Frage nach Betriebsort und Übermittlungen stellen. Die Rechtsberatung zu den bei der CDP einzuleitenden Formalitäten und zu deren Zeitplan hinzuziehen.
• Konzeption. Die Felder auf die notwendigen Daten begrenzen. Aufbewahrungsdauern und Archivierungsregeln festlegen. Rollen und Berechtigungen entwerfen. Im Datenmodell Quelle, Information und Wünsche der Personen vorsehen. Beschreiben, wie Auskunfts-, Berichtigungs- und Widerspruchsrechte bearbeitet werden.
• Realisierung. Berechtigungen und Nachvollziehbarkeit einrichten. Sensible Daten in den Testumgebungen verschlüsseln oder maskieren. Prüfen, dass die Schnittstellen, insbesondere zwischen SAP und Salesforce, keine Daten ohne Notwendigkeit vervielfachen.
• Datenübernahme. Vor der Migration aussortieren. Ein Datum, dessen Zweck oder Herkunft sich nicht begründen lässt, darf nicht ins neue System gelangen. Es ist die seltene Gelegenheit, aufzuräumen.
• Produktivsetzung. Sicherstellen, dass die Formalitäten erledigt oder eingeleitet sind. Die betroffenen Personen, Mitarbeitende wie Kundschaft, über die neue Verarbeitung informieren. Die Nutzenden in den Zugriffsregeln und im Umgang mit Anfragen der Betroffenen schulen.
• Betrieb. Berechtigungen regelmäßig überprüfen. Die vorgesehenen Löschungen durchführen. Das Verzeichnis der Verarbeitungen bei jeder fachlichen Änderung aktualisieren. Diese Überprüfungen in den Vertrag für Support & Application Management aufnehmen.

Der Fall der UEMOA-Konzerne

Ein in mehreren Staaten der Union tätiger Konzern teilt eine Währung und ein harmonisiertes Wirtschaftsrecht. Er teilt keine Datenschutzbehörde. Jedes Land hat sein Gesetz und seine Behörde, mit abweichenden Formalitäten, Fristen und Anforderungen. Ein regionales CRM oder ein Konzern-ERP muss deshalb so entworfen sein, dass jede Tochtergesellschaft für ihre Verarbeitungen verantwortlich bleibt, mit nach Ländern getrennten Daten, wo das lokale Recht es verlangt, und einem Konformitätsdossier je Staat. Die Versuchung einer einzigen Datenbasis nach der Regel eines einzigen Landes ist groß. Sie trägt nicht.

Konformität ist keine Bremse für Projekte. Sie ist eine Konzeptionsanforderung wie Leistung oder Sicherheit, die man in der Rahmensetzung bezahlt und im Betrieb zurückbekommt. Unser Angebot IT-Sicherheit & Risiken bindet sie ab dem ersten Workshop in unsere SAP- und Salesforce-Programme ein.