nLPD : registre des traitements et registre des incidents, ce que la loi exige vraiment

Deux registres, deux obligations distinctes que beaucoup de PME confondent

Depuis l'entrée en vigueur de la nouvelle loi fédérale sur la protection des données (nLPD) le 01.09.2023, les entreprises suisses doivent tenir un registre des activités de traitement et documenter tout incident impliquant des données personnelles. Ces deux instruments répondent à des finalités différentes : l'un est un outil de gouvernance permanente, l'autre une trace chronologique d'événements à risque. Les confondre, ou pire, n'en tenir qu'un seul, expose à des mesures correctives du Préposé fédéral à la protection des données et à la transparence (PFPDT) et, en cas de violation grave, à des sanctions pénales pouvant atteindre CHF 250 000.

Cadre légal : ce que la nLPD impose précisément

Le registre des activités de traitement (art. 12 nLPD)

L'article 12 de la nLPD oblige le responsable du traitement à tenir un registre de ses activités de traitement. L'ordonnance sur la protection des données (OPDo) précise le contenu minimal à l'art. 24 OPDo. Ce registre doit documenter, pour chaque activité :

• L'identité du responsable du traitement et, le cas échéant, du sous-traitant.
• La finalité du traitement (RH, comptabilité, CRM, surveillance réseau, etc.).
• Les catégories de personnes concernées et de données traitées.
• Les catégories de destinataires, y compris les pays tiers.
• La durée de conservation ou les critères qui la déterminent.
• Les mesures de sécurité techniques et organisationnelles (référence possible aux CIS Benchmarks ou à l'ISO 27001).

Exception PME : les entreprises de moins de 250 collaborateurs bénéficient d'une exemption partielle si leurs traitements ne comportent pas de données sensibles, ne sont pas à grande échelle et ne présentent pas de risque élevé pour les personnes concernées (art. 24 al. 4 OPDo). En pratique, dès qu'une PME gère des données de santé, des informations sur les poursuites, ou des profils comportementaux, l'exemption tombe. Une fiduciaire de 30 collaborateurs traitant les salaires de ses clients — avec fiches de paie, numéros AVS, informations sur des saisies — ne peut pas invoquer cette exception.

Le registre des incidents (art. 24 nLPD — violation de données)

L'art. 24 nLPD introduit l'obligation de notifier au PFPDT toute violation de données susceptible d'entraîner un risque élevé pour les personnes concernées, dans les meilleurs délais. Mais avant toute notification externe, la loi implique une capacité de détection et de documentation interne. Sans registre des incidents structuré, l'entreprise ne peut pas :

• Démontrer qu'elle a bien évalué la gravité d'un incident.
• Prouver le délai entre la détection et la notification (critère apprécié par le PFPDT).
• Alimenter une analyse de tendances pour améliorer sa posture de sécurité.

Ce registre des incidents est distinct du registre des traitements. Il s'agit d'un journal d'événements horodatés, avec champ de gravité, données concernées, cause probable, mesures prises et décision de notification ou non. L'absence de ce registre lors d'un audit ou d'une enquête du PFPDT constitue un signal fort de défaillance organisationnelle.

Architecture des deux registres : contenu et format

Registre des traitements : structure recommandée

Un fichier Excel ou un outil GRC suffit pour une PME de moins de 100 endpoints, à condition que le document soit versionné, daté et accessible au PFPDT sur demande. Chaque ligne correspond à une activité de traitement. Les colonnes minimales :

1. ID unique de l'activité (RT-001, RT-002…).
2. Nom de l'activité (ex. : « Gestion des salaires clients », « Surveillance des accès réseau »).
3. Responsable interne (DSI, DRH, direction).
4. Base légale (exécution d'un contrat, obligation légale, intérêt légitime, consentement).
5. Catégories de données (données ordinaires / sensibles — préciser lesquelles).
6. Catégories de personnes (employés, clients, prospects, fournisseurs).
7. Destinataires / sous-traitants (nom, pays, contrat de sous-traitance signé : oui/non).
8. Transfert hors Suisse (pays, garanties : CCT, décision d'adéquation).
9. Durée de conservation (ex. : 10 ans pour documents comptables selon CO art. 958f).
10. Mesures de sécurité (chiffrement, MFA, segmentation réseau, MDM).
11. Date de création / dernière révision.

Registre des incidents : structure recommandée

Ce registre doit être tenu séquentiellement. Chaque entrée correspond à un événement détecté, même s'il s'avère finalement sans risque significatif. La décision de ne pas notifier doit être documentée autant que la décision de notifier.

1. ID incident (INC-2024-001…).
2. Date et heure de détection (format DD.MM.YYYY HH:MM).
3. Date et heure de survenance estimée (si différente).
4. Description factuelle (type de violation : confidentialité, intégrité, disponibilité).
5. Données concernées (nature, volume estimé — ex. : 340 enregistrements clients avec e-mail et date de naissance).
6. Catégories de personnes affectées.
7. Cause probable (ransomware, accès non autorisé, erreur humaine, perte de support).
8. Mesures correctives prises (isolation du système, révocation des accès, patch déployé).
9. Évaluation du risque (faible / moyen / élevé — critères : probabilité + gravité des conséquences).
10. Décision de notification PFPDT (oui/non, date si oui, référence du dossier).
11. Décision d'information aux personnes concernées (oui/non, motif).
12. Responsable de l'entrée + visa du RSSI ou de la direction.

Procédure de notification au PFPDT : étape par étape

Lorsque l'évaluation interne conclut à un risque élevé pour les personnes concernées, la notification au PFPDT s'impose sans délai injustifié. Voici la séquence opérationnelle :

1. Détection (Heure 0) — SOC, sysadmin ou utilisateur signale l'anomalie. Ouverture immédiate d'une entrée dans le registre des incidents.
2. Confinement (H+1 à H+4) — DSI isole les systèmes concernés, préserve les logs. Aucune donnée compromise ne doit être effacée avant analyse forensique.
3. Qualification (H+4 à H+24) — RSSI et juriste évaluent : nature des données, volume, risque de préjudice (usurpation d'identité, discrimination, perte financière). Décision documentée dans le registre.
4. Notification PFPDT (dès que possible, idéalement sous 72 h — recommandation de bonne pratique calquée sur le RGPD, la nLPD dit « dans les meilleurs délais ») — Utilisation du formulaire disponible sur le site du PFPDT. Les informations minimales : nature de la violation, données et personnes concernées, conséquences probables, mesures prises.
5. Information aux personnes concernées (si risque élevé pour elles) — Rédaction d'un message factuel, sans minimisation. Conseil pratique : faire valider par le juriste avant envoi.
6. Post-incident (J+7 à J+30) — Analyse des causes racines, plan de remédiation, mise à jour du registre des traitements si une activité était mal documentée ou mal sécurisée.

Le NCSC offre également un guichet de signalement pour les incidents cyber affectant des infrastructures suisses, distinct de la notification PFPDT mais complémentaire pour les incidents à composante technique (ransomware, DDoS, intrusion).

Cas pratique : fiduciaire vaudoise de 35 collaborateurs

Contexte

Fiduciaire basée à Lausanne, 35 collaborateurs, environ 180 clients PME. Parc informatique : 40 postes Windows 11 (22H2), 8 MacBook Pro sous macOS 14, serveur de fichiers on-premise, accès à deux solutions SaaS (logiciel fiduciaire cloud, outil de signature électronique). Données traitées : fiches de salaire avec numéros AVS, bilans comptables, informations sur des procédures de poursuites pour certains clients. Pas de RSSI interne — un MSP mandaté pour l'infogérance.

État avant mise en conformité (31.08.2023)

• Aucun registre des traitements formalisé. Un document Word « liste des logiciels » existait, sans mention des finalités ni des sous-traitants.
• Les incidents passés (une perte de laptop en 2022, un ransomware stoppé en 2021) n'étaient documentés que par des e-mails internes non archivés de manière structurée.
• Aucun contrat de sous-traitance signé avec le MSP pour la protection des données.

Démarche de mise en conformité (sept. – déc. 2023)

1. Inventaire des traitements (2 jours, DSI + direction) — Identification de 14 activités de traitement distinctes : gestion des salaires clients, comptabilité clients, recrutement interne, surveillance des accès IT, etc. Constat : 6 activités impliquent des données sensibles (numéros AVS = données sur la situation économique, poursuites). L'exemption PME ne s'applique pas.
2. Rédaction du registre des traitements (1 semaine) — Tableur structuré selon les 11 colonnes décrites plus haut. Chaque traitement validé par le responsable de département concerné. Durées de conservation alignées sur les obligations légales (10 ans pour pièces comptables, 5 ans pour dossiers RH après départ).
3. Signature du contrat de sous-traitance avec le MSP — Clauses : obligation de confidentialité, notification d'incident dans les 24 h, droit d'audit, liste des sous-sous-traitants (hébergeur du SaaS fiduciaire = serveurs en Allemagne, couvert par la décision d'adéquation CH-UE).
4. Création du registre des incidents — Fichier dédié, accès restreint à la direction et au MSP-RSSI. Reconstitution a posteriori des deux incidents passés (entrées INC-2021-001 et INC-2022-001) avec les informations disponibles.
5. Formation du personnel (2 h) — Procédure de signalement interne : tout collaborateur détectant une anomalie (e-mail suspect, laptop manquant, accès refusé inhabituel) doit alerter le MSP via un ticket prioritaire dans les 2 h.

Incident réel survenu en février 2024

Un collaborateur signale l'envoi accidentel d'un fichier Excel contenant 87 fiches de salaire (nom, prénom, numéro AVS, salaire brut, informations sur une saisie sur salaire pour 3 personnes) à un mauvais destinataire client. Délai de détection-signalement interne : 3 h. Procédure déclenchée :

• Ouverture INC-2024-003, horodatée 14.02.2024 à 09h47.
• Confirmation de suppression du fichier par le destinataire (e-mail + appel téléphonique enregistré dans le registre).
• Évaluation du risque : élevé pour les 3 personnes avec information sur saisie (donnée sur la situation économique = donnée sensible au sens de la nLPD).
• Notification au PFPDT effectuée le 16.02.2024 (J+2). Information directe aux 3 personnes concernées par la donnée sensible, le 16.02.2024.
• Mesure corrective : configuration d'une règle DLP sur l'outil de messagerie pour bloquer l'envoi de fichiers contenant des patterns de numéro AVS (756.XXXX.XXXX.XX) vers des domaines externes non autorisés.

Coût total de l'incident (temps interne + MSP + juriste) : environ CHF 4 800. Aucune sanction du PFPDT — la procédure documentée et la réactivité ont joué en faveur de la fiduciaire.

Récapitulatif opérationnel

• Vérifier l'applicabilité de l'exemption PME : dès qu'un traitement porte sur des données sensibles (santé, AVS, poursuites, opinions politiques) ou est à grande échelle, l'obligation de tenir le registre des traitements s'applique intégralement, quelle que soit la taille de l'entreprise.
• Créer deux registres séparés : un registre des traitements (gouvernance permanente, mis à jour à chaque nouveau traitement ou changement significatif) et un registre des incidents (journal chronologique de tous les événements détectés, même sans notification).
• Formaliser les contrats de sous-traitance avant tout traitement externalisé : MSP, SaaS, hébergeur cloud. Vérifier la localisation des serveurs et les garanties pour les transferts hors Suisse.
• Documenter les décisions de non-notification autant que les notifications : le PFPDT peut demander à voir pourquoi un incident n'a pas été signalé.
• Établir une procédure interne de signalement avec un délai maximal entre la détection et l'ouverture d'une entrée dans le registre des incidents (recommandation : 2 à 4 heures pour les incidents potentiellement graves).
• Réviser le registre des traitements au minimum une fois par an et à chaque changement de système, d'outil SaaS ou de périmètre métier.
• Tester la procédure de notification par un exercice tabletop annuel (scénario : ransomware chiffrant un serveur RH) : qui appelle qui, dans quel délai, avec quels éléments pour remplir la notification PFPDT.
• Conserver les registres de manière sécurisée : accès restreint, versionné, avec logs d'accès. Un registre d'incidents accessible à tous les collaborateurs est une violation en soi.
• Aligner les durées de conservation documentées dans le registre des traitements avec les obligations légales effectives (CO, droit du travail, droit fiscal cantonal si applicable) plutôt que des durées arbitraires.
• Former au moins une personne en interne (ou mandate explicitement le RSSI externe) comme point de contact unique pour la gestion des incidents et les échanges avec le PFPDT.

SynGuard accompagne des PME romandes dans la mise en place de ces registres et des contrôles techniques associés (MDM, DLP, gestion des accès) sans alourdir la charge administrative des équipes IT.

Sources

• Loi fédérale sur la protection des données (nLPD), RS 235.1 — Fedlex — Texte consolidé de la nLPD en vigueur depuis le 01.09.2023.
• Ordonnance sur la protection des données (OPDo), RS 235.11 — Fedlex — Précisions réglementaires sur le registre des traitements (art. 24 OPDo) et les mesures de sécurité.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de contrôle compétente pour les notifications de violations et les recommandations de mise en conformité.
• Centre national pour la cybersécurité (NCSC) — Guichet de signalement des incidents cyber et ressources pour les PME suisses.
• CIS Benchmarks — Center for Internet Security — Référentiels de configuration sécurisée pour Windows, macOS et systèmes cloud, utilisables comme référence pour documenter les mesures de sécurité dans le registre des traitements.