Dernière mise à jour : [EFFECTIVE_DATE]

Modèle en cours de validation juridique. Ce document est un projet destiné à être vérifié et adapté par un conseil juridique qualifié dans chaque pays concerné avant toute publication. Il ne constitue pas un avis juridique.

Politique de gestion des violations de données

La présente politique définit la manière dont [LEGAL_ENTITY] détecte, évalue, notifie et corrige les violations de données personnelles affectant [TRADING_NAME]. Elle complète la Politique de sécurité de l'information et la Politique de protection des données.

1. Qu'est-ce qu'une violation de données ?

Une violation de données personnelles est une atteinte à la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l'altération, la divulgation ou l'accès non autorisé à des données personnelles. Sont notamment concernés : l'accès d'un tiers non autorisé, la fuite ou l'exposition de données, la perte d'un appareil, une compromission de compte, ou une erreur exposant les données d'un locataire à un autre.

2. Comment signaler une violation

En interne : tout collaborateur ou prestataire qui soupçonne ou constate une violation doit la signaler immédiatement à [SECURITY_EMAIL], sans tenter de la dissimuler ni d'enquêter seul.

En externe : un client, un utilisateur ou un chercheur en sécurité peut signaler un incident présumé à [SECURITY_EMAIL] (voir aussi la divulgation responsable dans la Politique de sécurité).

3. Cycle de réponse

Détecter : identifier et enregistrer l'incident dès sa survenance ou son signalement.
Contenir : limiter la propagation (révocation d'accès, isolement des systèmes, rotation des secrets).
Évaluer le risque : déterminer la nature des données, le nombre de personnes concernées et la gravité du risque pour leurs droits et libertés.
Notifier : informer les autorités, les responsables de traitement et/ou les personnes concernées selon les obligations applicables (section 4).
Remédier : corriger la cause, restaurer les services et renforcer les mesures.
Réexaminer : mener une analyse post-incident et documenter les enseignements.

4. Obligations et délais de notification

Les délais varient selon la loi applicable. À titre indicatif :

le RGPD impose au responsable de traitement de notifier l'autorité compétente dans les 72 heures après en avoir pris connaissance, lorsque la violation est susceptible d'engendrer un risque ;
plusieurs lois africaines — par exemple le NDPA nigérian, la loi kényane de 2019 et la loi POPIA sud-africaine — imposent de notifier le régulateur et les personnes concernées dès que raisonnablement possible / sans retard injustifié.

Cadre	Qui notifier	Délai
RGPD (UE/RU)	Autorité de contrôle ; personnes concernées si risque élevé	72 heures (autorité) ; sans retard injustifié (personnes)
NDPA (Nigéria)	NDPC ; personnes concernées	Dès que raisonnablement possible
Loi 2019 (Kenya)	ODPC ; personnes concernées	Sans retard injustifié
POPIA (Afrique du Sud)	Régulateur ; personnes concernées	Dès que raisonnablement possible

5. Responsable ou sous-traitant : qui notifie qui ?

Lorsque nous agissons en tant que responsable de traitement (comptes d'administrateurs, facturation, prospects, support), il nous appartient de notifier l'autorité et, le cas échéant, les personnes concernées.

Lorsque nous agissons en tant que sous-traitant des données métier d'un abonné, nous notifions le client responsable de traitement sans retard injustifié afin qu'il puisse remplir ses propres obligations ; nous ne notifions pas l'autorité à sa place. Voir l'Accord de traitement des données.

6. Communication aux personnes concernées

Lorsque la violation est susceptible d'engendrer un risque élevé pour les personnes, celles-ci sont informées en termes clairs : nature de la violation, conséquences probables, mesures prises et recommandations pour se protéger.

7. Registre des violations

Toutes les violations, y compris celles ne donnant pas lieu à notification, sont consignées dans un registre interne (faits, effets, mesures correctives) au titre du principe de responsabilité.

8. Analyse post-incident

Après chaque incident significatif, une revue est menée pour identifier la cause racine et améliorer les contrôles, la détection et la présente procédure.

9. Nous contacter

Signalement d'incident : [SECURITY_EMAIL].

Last updated: [EFFECTIVE_DATE]

Draft pending legal review. This document is a working draft to be verified and localised by qualified legal counsel in each country of operation before publication. It is not legal advice.

Data Breach Response Policy

This policy sets out how [LEGAL_ENTITY] detects, assesses, notifies and remediates personal-data breaches affecting [TRADING_NAME]. It complements the Information Security Policy and the Data Protection Policy.

1. What is a personal-data breach?

A personal-data breach is a security incident leading to the accidental or unlawful destruction, loss, alteration, disclosure of, or unauthorised access to personal data. Examples include: unauthorised third-party access, a data leak or exposure, a lost device, an account compromise, or an error exposing one tenant's data to another.

2. How to report a breach

Internally: any staff member or contractor who suspects or discovers a breach must report it immediately to [SECURITY_EMAIL], without attempting to conceal it or investigate alone.

Externally: a customer, user or security researcher may report a suspected incident to [SECURITY_EMAIL] (see also responsible disclosure in the Security Policy).

3. Response lifecycle

Detect: identify and record the incident as soon as it occurs or is reported.
Contain: limit the spread (revoke access, isolate systems, rotate secrets).
Assess risk: determine the nature of the data, the number of people affected, and the severity of risk to their rights and freedoms.
Notify: inform regulators, controllers and/or affected persons per the applicable obligations (section 4).
Remediate: fix the cause, restore services and strengthen controls.
Review: run a post-incident review and document lessons learned.

4. Notification obligations and timelines

Timelines vary by applicable law. By way of indication:

the GDPR requires a controller to notify the competent authority within 72 hours of becoming aware, where the breach is likely to result in a risk;
several African laws — for example Nigeria's NDPA, Kenya's 2019 Act and South Africa's POPIA — require notifying the regulator and affected persons as soon as reasonably practicable / without undue delay.

Framework	Who to notify	Timeline
GDPR (EU/UK)	Supervisory authority; affected persons if high risk	72 hours (authority); without undue delay (persons)
NDPA (Nigeria)	NDPC; affected persons	As soon as reasonably practicable
2019 Act (Kenya)	ODPC; affected persons	Without undue delay
POPIA (South Africa)	Regulator; affected persons	As soon as reasonably practicable

5. Controller vs processor: who notifies whom?

When we act as a controller (administrator accounts, billing, prospects, support), it is our duty to notify the authority and, where required, the affected persons.

When we act as a processor for a subscriber's business data, we notify the controller-customer without undue delay so they can meet their own duties; we do not notify the authority on their behalf. See the Data Processing Agreement.

6. Communication to affected data subjects

Where a breach is likely to result in a high risk to individuals, they are informed in plain terms: the nature of the breach, the likely consequences, the measures taken, and recommendations to protect themselves.

7. Record-keeping of breaches

All breaches, including those that do not trigger notification, are recorded in an internal register (facts, effects, remedial actions) under the accountability principle.

8. Post-incident review

After each significant incident, a review is conducted to identify the root cause and improve controls, detection and this procedure.

9. Contact us

Incident reporting: [SECURITY_EMAIL].