nLPD : registre des traitements et registre des incidents, deux obligations à ne pas confondre

Deux registres, deux régimes juridiques distincts

Une fiduciaire de 35 collaborateurs à Lausanne traite des données fiscales, salariales et médicales. Elle n'a constitué ni registre des activités de traitement, ni procédure documentée pour journaliser ses incidents de sécurité. Lors d'un contrôle ou d'une violation de données, cette absence coûte non pas une amende institutionnelle à la société, mais une poursuite pénale personnelle contre le responsable du traitement — jusqu'à CHF 250 000 d'amende selon l'art. 60 nLPD.

La loi fédérale sur la protection des données révisée (nLPD), entrée en vigueur le 01.09.2023, introduit deux obligations documentaires fondamentales qui répondent à des finalités différentes : le registre des activités de traitement (art. 12 nLPD) et le registre des violations de données — soit ce que les praticiens appellent couramment le registre des incidents. Comprendre leur périmètre, leur architecture et leur interdépendance est un prérequis opérationnel pour tout RSSI ou DSI de PME romande.

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

Qui est concerné ?

L'art. 12 nLPD oblige le responsable du traitement à tenir un registre des activités de traitement. Une exception PME existe : les entreprises de moins de 250 collaborateurs peuvent s'en dispenser à condition que le traitement ne présente qu'un risque limité d'atteinte à la personnalité des personnes concernées. En pratique, cette exemption tombe dès que la PME traite des données sensibles au sens de l'art. 5 let. c nLPD — données de santé, données biométriques, données sur les poursuites pénales, convictions religieuses — ou réalise un profilage à risque élevé. Une fiduciaire, un cabinet médical, un bureau RH externalisé ou un MSP hébergeant des données clients : aucun ne bénéficie de l'exemption de fait.

Contenu minimal du registre

L'ordonnance sur la protection des données (OPDo) précise les champs obligatoires :

• Identité du responsable du traitement et, le cas échéant, du sous-traitant (nom, coordonnées)
• Finalité du traitement
• Catégories de personnes concernées et de données traitées
• Catégories de destinataires (y compris pays tiers ou organisations internationales)
• Durée de conservation ou critères permettant de la déterminer
• Mesures de sécurité techniques et organisationnelles (TOM) — description générale

Il n'existe pas de format imposé : tableur, CMDB annotée, outil GRC ou simple document Word sont acceptables, pourvu que le registre soit tenu à jour et accessible sur demande au Préposé fédéral à la protection des données et à la transparence (PFPDT).

Architecture recommandée pour 20-150 endpoints

Pour une PME romande de 30 à 80 collaborateurs, une structure en trois niveaux est efficace :

1. Niveau 1 — Inventaire des systèmes : liste des applications (ERP, CRM, messagerie, cloud), bases de données et flux d'intégration. Inclure l'URL d'administration, la version déployée, le responsable applicatif.
2. Niveau 2 — Fiche de traitement : une fiche par activité de traitement (ex. : gestion de la paie, facturation clients, accès VPN). Chaque fiche documente les champs OPDo plus la base légale (consentement, contrat, intérêt légitime).
3. Niveau 3 — Matrice des flux transfrontaliers : si des données partent hors de Suisse ou hors de l'EEE, documenter le mécanisme de transfert (clauses contractuelles types, adéquation reconnue par le CF, garanties appropriées art. 16 nLPD).

Un traitement non documenté dans le registre ne bénéficie d'aucune présomption de conformité en cas de contrôle ou d'incident.

Le registre des violations de données (incidents)

Base légale et champ d'application

L'art. 24 nLPD impose au responsable du traitement de notifier au PFPDT toute violation de la sécurité des données susceptible d'entraîner un risque élevé pour la personnalité ou les droits fondamentaux des personnes concernées, dans les meilleurs délais. L'OPDo (art. 15) précise que cette notification doit intervenir aussitôt que possible — sans délai maximal fixé en jours dans la loi, contrairement au RGPD européen qui impose 72 heures. Le PFPDT recommande toutefois d'agir dans un délai comparable. Lorsque le risque est réalisé, les personnes concernées doivent également être informées (art. 24 al. 4 nLPD).

Parallèlement, toute violation doit être consignée dans un registre interne, qu'elle dépasse ou non le seuil de notification. Ce registre d'incidents est l'outil qui permet au PFPDT, lors d'un audit, de vérifier la maturité du programme de gestion des risques.

Contenu du registre des incidents

Chaque entrée doit documenter a minima :

• Date et heure de détection, date et heure supposées de l'incident
• Nature de la violation : confidentialité (accès non autorisé), intégrité (altération), disponibilité (destruction, perte)
• Catégories et volume approximatif de données et de personnes concernées
• Conséquences probables et gravité du risque (faible / moyen / élevé)
• Mesures prises ou envisagées pour remédier à la violation et en atténuer les effets
• Décision de notification au PFPDT (oui/non) avec justification documentée
• Décision de communication aux personnes concernées (oui/non) avec justification
• Références aux preuves : logs, tickets ITSM, rapports forensiques

Seuil de notification : évaluer le risque

La notion de "risque élevé" n'est pas définie numériquement dans la nLPD. Les critères opérationnels à évaluer sont : sensibilité de la catégorie de données (données de santé = risque plus élevé que coordonnées publiques), volume (100 dossiers patients vs. 5), probabilité d'exploitation malveillante, vulnérabilité des personnes (mineurs, patients, salariés précaires), et réversibilité du préjudice. Documenter ce raisonnement dans le registre est essentiel — une décision de non-notification non justifiée peut constituer une infraction à l'art. 60 nLPD.

Pour signaler un incident au PFPDT, la procédure passe par le formulaire de notification des violations de données du PFPDT. Pour les incidents à caractère cyber (ransomware, phishing ciblé, intrusion sur infrastructure), un signalement parallèle au Centre national pour la cybersécurité (NCSC) est vivement recommandé — ces deux notifications sont indépendantes et non substituables.

Interdépendance des deux registres et gouvernance

Lien structurel

Les deux registres se complètent : un incident sur un traitement non documenté dans le registre des activités est presque impossible à qualifier correctement. Sans fiche de traitement, on ne connaît pas les catégories de données exposées, les destinataires habituels, ni les durées de rétention — autant d'éléments nécessaires à l'évaluation du risque de l'incident. Tenir le registre des activités à jour est donc un prérequis opérationnel au registre des incidents.

Acteurs et responsabilités

La nLPD n'impose pas la désignation d'un délégué à la protection des données (DPO) pour les entreprises privées suisses, contrairement au RGPD. Mais un point de contact interne identifié (DSI, juriste ou RSSI) est indispensable pour coordonner les décisions de notification sous pression temporelle.

Durée de conservation des registres

La nLPD ne fixe pas de durée minimale explicite pour la conservation des registres eux-mêmes. Par analogie avec le droit commercial suisse (art. 958f CO — 10 ans) et les recommandations du PFPDT, une durée de 5 à 10 ans est recommandée pour le registre des incidents. Pour le registre des traitements, il doit être maintenu tant que le traitement est actif, plus une période raisonnable après cessation.

Cas pratique : bureau d'études d'ingénierie à Sion, 45 collaborateurs

Contexte

Un bureau d'études en ingénierie civile basé à Sion emploie 45 personnes. Le parc informatique comprend 38 postes Windows 11 23H2, 7 MacBook Pro sous macOS 14 Sonoma, et des accès VPN site-à-site vers deux sous-traitants en Suisse alémanique. Les données traitées incluent : données RH et salaires (données personnelles ordinaires et sensibles), dossiers de soumission publique avec informations confidentielles de tiers, et un accès en lecture à un système cantonal de données géotechniques. Aucun registre de traitement n'était formalisé avant le 01.09.2023.

Phase 1 : constitution du registre des activités (durée estimée : 3 semaines)

1. Inventaire des systèmes (J1-J5) : Le DSI dresse la liste de tous les systèmes hébergeant des données personnelles : ERP (Abacus, version 2024.1), messagerie Microsoft 365 tenant CH, serveur de fichiers NAS Synology DS923+, logiciel de gestion de projet (Asana cloud, datacenter UE), accès VPN Fortinet FortiGate 60F. Résultat : 12 systèmes identifiés, dont 3 avec transfert potentiel hors Suisse.
2. Ateliers métier (J6-J10) : Le DSI rencontre les responsables RH, comptabilité, direction de projet. Pour chaque département, il cartographie les traitements : qui collecte quoi, pour quelle finalité, qui a accès, combien de temps est-ce conservé. Résultat : 9 fiches de traitement rédigées.
3. Qualification des données sensibles (J11-J12) : Les fiches RH et médecine du travail (visites médicales obligatoires pour certains chantiers) sont classées "données sensibles" au sens de l'art. 5 let. c nLPD. L'exception PME ne s'applique pas.
4. Matrice des flux transfrontaliers (J13-J15) : Asana héberge des données de projet dans l'UE. Le bureau vérifie la liste des pays reconnus adéquats par le Conseil fédéral — l'UE y figure. Le flux est documenté avec référence à la décision d'adéquation.
5. Validation juridique (J16-J18) : Un juriste externe valide les bases légales retenues (contrat pour la paie, intérêt légitime pour la gestion de projet, obligation légale pour la médecine du travail). Coût estimé : CHF 1 500 à CHF 2 500 selon le cabinet.
6. Archivage et accès (J19-J21) : Le registre est stocké dans un dossier SharePoint à accès restreint (DSI + direction). Une revue annuelle est planifiée chaque mois de janvier.

Phase 2 : incident survenu 4 mois après (simulation)

En janvier 2025, un collaborateur clique sur un lien de phishing. Les identifiants Microsoft 365 sont compromis. L'attaquant accède à la boîte mail pendant environ 18 heures avant détection par une alerte MFA anormale. La boîte contenait des échanges RH incluant des arrêts maladie de 3 collaborateurs.

Procédure d'enregistrement de l'incident :

1. Détection et containment (H+0 à H+2) : Le DSI révoque la session, réinitialise le mot de passe, active une MFA renforcée sur le compte. Il ouvre un ticket ITSM avec horodatage.
2. Qualification (H+2 à H+6) : Le DSI consulte les logs Microsoft 365 Purview Audit (rétention 90 jours sur licence E3). Il identifie 3 messages contenant des certificats médicaux. Catégorie de données : données de santé (sensibles). Personnes concernées : 3 employés. Volume faible, risque d'exploitation probable (phishing sophistiqué).
3. Évaluation du risque (H+6 à H+12) : Données de santé + accès malveillant confirmé + personnes identifiables = risque élevé au sens de l'art. 24 nLPD. Décision : notification au PFPDT requise. Notification aux 3 personnes concernées également requise.
4. Notification PFPDT (H+12 à H+24) : Le DSI et le juriste complètent le formulaire officiel du PFPDT. Nature : violation de confidentialité. Mesures prises : révocation de session, réinitialisation, audit des règles de transfert mail (absence de règle de redirection suspecte confirmée).
5. Signalement NCSC (H+12 à H+24) : Signalement parallèle au NCSC via le formulaire en ligne, en tant qu'incident de phishing ayant abouti. Le NCSC peut émettre des avertissements sectoriels sans divulguer l'identité du déclarant.
6. Communication aux salariés (H+24 à H+48) : Les 3 collaborateurs concernés sont informés par écrit (email + entretien RH) : nature de l'incident, données exposées, mesures prises, droits d'accès et de rectification.
7. Entrée au registre des incidents : L'incident est enregistré avec tous les champs requis, référence ticket ITSM, copies des notifications envoyées, et clôture avec les mesures correctives (formation anti-phishing, déploiement de Microsoft Defender for Identity sur les 45 comptes, révision de la politique MFA).

Coût total de gestion de l'incident : environ CHF 3 000 à CHF 6 000 (DSI interne + juriste externe + communication). Sans registre des activités préalable, la qualification des données exposées aurait pris 2 à 3 jours supplémentaires, augmentant le délai de notification et le risque d'infraction.

Récapitulatif opérationnel

• Vérifier l'exemption PME : Si votre PME traite des données sensibles (santé, convictions, biométrie, poursuites pénales) ou réalise du profilage à risque élevé, l'exemption de l'art. 12 al. 5 nLPD ne s'applique pas — registre des activités obligatoire quelle que soit la taille.
• Structurer le registre des traitements en 3 niveaux : inventaire des systèmes → fiches de traitement → matrice des flux transfrontaliers. Révision à chaque nouveau traitement ou changement majeur, plus une revue annuelle planifiée.
• Créer le registre des incidents dès maintenant : ne pas attendre le premier incident. Un modèle de fiche avec les 8 champs obligatoires suffit pour commencer. Le registre peut être un simple fichier Excel sécurisé avec contrôle de version.
• Définir le seuil de notification interne : rédiger une procédure en 1 page qui indique qui décide de notifier le PFPDT, selon quels critères, dans quel délai, et qui prévient les personnes concernées. Tester ce workflow au moins une fois par an en simulation.
• Identifier le point de contact officiel : nommer un responsable interne (DSI, RSSI ou juriste) comme interlocuteur du PFPDT et du NCSC. Documenter ses coordonnées dans les deux registres.
• Relier les deux registres : chaque fiche d'incident doit référencer la ou les fiches de traitement du registre des activités concernées. Sans ce lien, la qualification du risque est incomplète et la décision de notification indéfendable.
• Conserver les preuves de notification : accusés de réception du formulaire PFPDT, emails aux personnes concernées, tickets ITSM — conserver au minimum 5 ans.
• Auditer les sous-traitants : si un sous-traitant traite des données pour votre compte, vérifier que le contrat contient les clauses art. 9 nLPD (obligation de sécurité, notification des incidents dans un délai défini contractuellement, retour ou destruction des données en fin de contrat).
• Former les collaborateurs : la plupart des violations commencent par une erreur humaine (phishing, mauvais destinataire, clé USB perdue). Une formation annuelle de 45 minutes réduit significativement la fréquence des incidents à documenter.

Des outils de gestion de flotte et de conformité endpoints — comme ceux proposés par SynGuard — peuvent automatiser la collecte de certaines données nécessaires aux fiches de traitement (inventaire des assets, versions OS, état de chiffrement), réduisant le coût de maintenance des deux registres.

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, incluant les art. 12 (registre des activités), 24 (violations) et 60 (sanctions pénales).
• Ordonnance sur la protection des données (OPDo), RS 235.11 — Fedlex — précisions sur les champs du registre des activités et la procédure de notification.
• Violations de données — PFPDT (Préposé fédéral à la protection des données et à la transparence) — page officielle de procédure et formulaire de notification au PFPDT.
• Signalement d'incidents — Centre national pour la cybersécurité (NCSC) — formulaire de signalement des incidents cyber, indépendant de la notification PFPDT.