Conformité nLPD : registre des traitements et registre des incidents

Deux registres, deux obligations distinctes

Depuis le 01.09.2023, la nouvelle loi fédérale sur la protection des données (nLPD) est en vigueur. Elle introduit deux obligations documentaires souvent confondues dans la pratique : le registre des activités de traitement (art. 12 nLPD) et le registre des violations de données — appelé ici registre des incidents — que l'art. 24 nLPD impose d'instruire avant toute décision de notification au Préposé fédéral à la protection des données et à la transparence (PFPDT). Ces deux registres ont des périmètres, des contenus et des cycles de vie radicalement différents. Ne pas les distinguer, c'est soit surcharger inutilement le registre de traitement, soit sous-documenter les incidents et s'exposer à une notification tardive.

Registre des activités de traitement : cadre légal et architecture

Qui est concerné ?

L'art. 12 nLPD exige la tenue d'un registre des activités de traitement de tout responsable du traitement et de tout sous-traitant. La loi prévoit une exception pour les entreprises de moins de 250 employés dont le traitement ne présente qu'un risque limité pour la personnalité des personnes concernées. En pratique, cette exception est étroite : dès qu'une PME traite des données sensibles (données de santé, profils de solvabilité, données biométriques, opinions syndicales ou religieuses), ou qu'elle effectue un profilage à grande échelle, elle doit tenir le registre quel que soit l'effectif. Une fiduciaire de 15 personnes gérant des données fiscales de milliers de clients n'est pas exemptée.

Contenu minimum du registre (art. 12 al. 2 nLPD)

Pour chaque activité de traitement, le registre doit documenter :

1. L'identité du responsable du traitement (raison sociale, adresse, représentant en Suisse si siège à l'étranger).
2. La finalité du traitement (exemple : «gestion des salaires et déclarations AVS», «CRM prospection commerciale»).
3. Les catégories de personnes concernées (employés, clients, fournisseurs, prospects).
4. Les catégories de données traitées, en distinguant données ordinaires et données sensibles au sens de l'art. 5 let. c nLPD.
5. Les catégories de destinataires, y compris les transferts hors de Suisse et la base légale applicable (art. 16-17 nLPD, listes d'États adéquats publiées par le Conseil fédéral).
6. La durée de conservation ou les critères permettant de la déterminer.
7. Les mesures de sécurité techniques et organisationnelles (TOM) de nature générale.

L'ordonnance sur la protection des données (OPDo) précise ces éléments et les exigences relatives aux sous-traitants (art. 24-25 OPDo). Le registre n'a pas de format imposé — tableur Excel, outil GRC, module dédié — à condition qu'il reste à jour et consultable en cas de contrôle du PFPDT.

Granularité : une ligne par application ou une ligne par finalité ?

La pratique recommande de structurer par finalité métier plutôt que par application technique. Un ERP peut supporter cinq finalités distinctes (paie, comptabilité, gestion des commandes, suivi des incidents SAV, reporting direction). Chaque finalité aura potentiellement des durées de conservation, des destinataires et des mesures de sécurité différentes. Mélanger les deux niveaux produit un registre ingérable lors des mises à jour.

Registre des incidents (violations de données) : périmètre et mécanique

Obligation de documentation vs obligation de notification

L'art. 24 nLPD impose deux niveaux distincts :

• Documentation systématique de toute violation de données constatée, même si elle ne génère pas de risque élevé. Pas de seuil minimum : une erreur d'envoi d'un e-mail contenant des données personnelles à un mauvais destinataire doit être consignée.
• Notification au PFPDT uniquement si la violation est «susceptible d'entraîner un risque élevé pour la personnalité ou les droits fondamentaux de la personne concernée». Ce seuil est apprécié au cas par cas. La notification doit intervenir dans les meilleurs délais (la loi ne fixe pas le délai de 72 h du RGPD, mais la pratique du PFPDT et le guide du Centre national de cybersécurité (NCSC) orientent vers 72 à 96 heures pour les incidents significatifs).

Contenu du registre des incidents

Pour chaque violation documentée, le registre doit capturer :

1. Date et heure de détection (et, si connue, de survenance).
2. Nature de la violation : confidentialité (accès non autorisé), intégrité (modification), disponibilité (destruction/perte).
3. Catégories et volume approximatif de données concernées (ex. : 340 dossiers clients incluant numéro AVS).
4. Catégories de personnes concernées.
5. Conséquences probables de la violation.
6. Mesures prises ou envisagées pour remédier à la violation et atténuer ses effets.
7. Décision motivée de notifier ou non le PFPDT, avec le raisonnement sur le niveau de risque.
8. Si notification : date d'envoi, référence du dossier PFPDT, contenu de la notification.
9. Si information des personnes concernées : canal, date, contenu.

Ce registre est un document juridique : il constitue la preuve que le responsable du traitement a évalué le risque de manière documentée. Un registre vide ou lacunaire à la date d'un contrôle est interprété comme une absence de process, pas comme une absence d'incidents.

Articulation avec la réponse à incident IT

La majorité des PME romandes pilotent les incidents de sécurité dans un ticketing IT (ServiceNow, Jira, Zendesk, ou même un tableur). Le registre nLPD n'est pas un doublon : c'est la couche juridico-documentaire alimentée par le ticket IT une fois la qualification «violation de données» posée. Le processus recommandé :

1. Détection → ticket IT ouvert, priorité selon gravité.
2. Triage initial (DSI ou RSSI, sous 4 h) : l'incident implique-t-il des données personnelles ? Si oui, passage en mode «gestion de violation de données».
3. Qualification du risque (RSSI + juriste, sous 24 h) : risque faible / modéré / élevé. Critères : nature des données, volume, identification des personnes, probabilité d'usage malveillant.
4. Si risque élevé : notification PFPDT via le formulaire de signalement du PFPDT, copie dans le registre des incidents.
5. Clôture du ticket IT ET mise à jour du registre incidents (mesures prises, leçons tirées).

Sanctions et risques en cas de défaut

La nLPD introduit une responsabilité pénale personnelle : ce sont les personnes physiques — dirigeant, DSI, RSSI selon les responsabilités attribuées — qui peuvent être condamnées, et non l'entreprise. Les sanctions pénales (art. 60-63 nLPD) atteignent jusqu'à CHF 250 000 d'amende pour :

• Violation de l'obligation de renseigner, de notifier ou de collaborer avec le PFPDT (art. 60).
• Violation des exigences minimales de sécurité entraînant une atteinte grave à la personnalité (art. 61).
• Non-respect des obligations de diligence dans la communication de données à des tiers (art. 62).

L'absence de registre des activités de traitement n'est pas directement sanctionnée pénalement par un article dédié, mais elle constitue une preuve d'absence de conformité qui aggrave considérablement la position du responsable lors d'un contrôle ou d'un litige. Le PFPDT dispose du pouvoir d'ouvrir des procédures administratives et de rendre des décisions contraignantes (art. 49 ss nLPD). Les CIS Benchmarks et les cadres de sécurité tels que le NIST Cybersecurity Framework recommandent d'ailleurs d'intégrer les obligations de documentation légale directement dans les contrôles de gouvernance des données.

Cas pratique : fiduciaire vaudoise de 38 employés

Contexte

Fiduciaire basée à Lausanne, 38 collaborateurs, environ 420 dossiers clients actifs (PME, indépendants, personnes physiques). Le parc comprend 42 postes Windows 11 23H2, 12 MacBook (macOS 14 Sonoma) et 8 téléphones mobiles sous iOS 17 gérés via MDM. Les données traitées incluent : données fiscales, données salariales (AVS, salaires, coordonnées bancaires), données comptables. La fiduciaire utilise un ERP spécialisé (hébergé en Suisse), une suite bureautique cloud et un outil de messagerie chiffrée.

Structuration du registre des activités de traitement

L'audit initial identifie 11 finalités de traitement distinctes. Les 5 principales :

• Gestion des mandats fiscaux — données sensibles (revenus, fortune, dettes fiscales) — conservation 10 ans (délai de prescription fiscale) — destinataires : AFC cantonale, AFC fédérale.
• Traitement des salaires — données sensibles (AVS, salaires bruts/nets, données bancaires) — conservation 5 ans minimum (CO) — destinataires : caisses AVS, assureurs LAA/LPP, SUVA.
• CRM et prospection — données ordinaires (coordonnées, profil entreprise) — conservation 3 ans post-clôture — destinataires : aucun tiers.
• Gestion du personnel interne — données sensibles (salaires, dossiers médicaux pour absences longue durée) — conservation 5 ans — destinataires : caisse de pension, assureur collectif.
• Archivage numérique des pièces comptables — données ordinaires et sensibles — conservation 10 ans (CO art. 958f) — destinataires : réviseurs externes.

Temps de construction du registre initial (avec un consultant externe) : 3 jours. Mise à jour semestrielle estimée : 4 heures. Le registre est maintenu dans un tableur sécurisé sur le serveur interne, accès restreint au directeur associé et à la personne responsable de la protection des données (pas d'obligation de DPO formel sous la nLPD pour les entités privées, mais nomination recommandée).

Simulation d'incident : envoi erroné d'une annexe de bulletin de salaire

Le 14.03.2024, un collaborateur envoie par e-mail un fichier PDF contenant les bulletins de salaire de mars de 12 employés au mauvais destinataire (adresse e-mail d'un client, au lieu d'une adresse interne). Le fichier contient : noms complets, salaires bruts, numéros AVS, coordonnées bancaires.

Procédure appliquée :

1. Détection (J+0, 09h14) : le collaborateur signale l'erreur au DSI dans les 20 minutes. Ticket IT ouvert.
2. Confinement (J+0, 09h40) : le DSI contacte le client destinataire, demande suppression et confirmation écrite. Tentative de recall e-mail (partielle, client sur Gmail externe). Résultat : confirmation de suppression reçue à 11h20.
3. Qualification nLPD (J+0, après-midi) : données personnelles impliquées ? Oui. Données sensibles ? Oui (données salariales, AVS, bancaires). Volume : 12 personnes concernées. Probabilité d'usage malveillant : faible (client connu, bonne foi confirmée). Risque résiduel : modéré.
4. Décision de notification (J+0, 16h00) : le directeur associé, après consultation juridique, conclut que le risque pour la personnalité des 12 personnes concernées est probable mais non élevé compte tenu de la confirmation de suppression. Décision : pas de notification PFPDT, mais documentation intégrale dans le registre des incidents et information des 12 employés concernés.
5. Information des personnes concernées (J+1, matin) : les 12 employés reçoivent un e-mail du directeur associé expliquant l'incident, les mesures prises et le risque résiduel estimé.
6. Clôture et mesures correctives (J+5) : mise en place d'une règle DLP sur le serveur de messagerie bloquant les envois externes de fichiers contenant des patterns de numéros AVS (format 756.XXXX.XXXX.XX). Formation ciblée du collaborateur concerné. Mise à jour du registre incidents.

Coût de l'incident : environ 8 h de travail interne (DSI, direction) + 2 h de conseil juridique externe, soit approximativement CHF 2 400 à 3 200 selon les taux horaires. Zéro notification PFPDT, zéro sanction, mais un registre incidents qui démontre une gestion diligente.

Un outil MDM couvrant l'ensemble des 62 endpoints de la fiduciaire — comme celui proposé par SynGuard — aurait permis d'activer la règle DLP de manière centralisée sur les postes Windows et macOS sans intervention manuelle poste par poste.

Récapitulatif opérationnel

• Vérifier l'applicabilité de l'exception PME : moins de 250 employés ne suffit pas. Si traitement de données sensibles ou profilage → registre obligatoire.
• Structurer le registre par finalité métier, pas par application technique. Prévoir une colonne «dernière mise à jour» et un responsable nommé pour chaque ligne.
• Séparer physiquement les deux registres : registre des traitements (gouvernance, stable) ≠ registre des incidents (opérationnel, dynamique). Ne pas mélanger les deux dans le même document.
• Définir un seuil de déclenchement du registre incidents : tout événement impliquant des données personnelles, quelle que soit la gravité apparente. La qualification du risque intervient après, pas avant.
• Documenter la décision de ne pas notifier avec le même soin que la notification elle-même. La motivation écrite protège le responsable du traitement.
• Viser 72 à 96 heures pour la notification au PFPDT en cas de risque élevé, même si la nLPD dit «dans les meilleurs délais». Aligner le SLA interne sur cette fenêtre.
• Réviser le registre des traitements a minima annuellement et à chaque changement significatif (nouveau logiciel SaaS, nouveau sous-traitant, nouveau pays de destination des données).
• Intégrer les TOM dans le registre des traitements à un niveau de granularité suffisant : chiffrement au repos (AES-256), chiffrement en transit (TLS 1.2+), contrôle d'accès (RBAC, MFA), sauvegarde (RTO/RPO). Ces mentions seront demandées en cas de contrôle.
• Nommer un interlocuteur identifié pour chaque registre. Pas obligatoirement un DPO, mais une personne dont la responsabilité est formalisée par écrit (fiche de poste ou lettre de mission).
• Tester la procédure incident une fois par an : simuler un scénario (ex. perte d'un ordinateur portable non chiffré) et chronométrer le temps de qualification, de décision et de rédaction de la notification fictive.

Sources

• Loi fédérale sur la protection des données (nLPD), RS 235.1 — Texte consolidé en vigueur depuis le 01.09.2023.
• Ordonnance sur la protection des données (OPDo), RS 235.11 — Précisions réglementaires sur les registres, les mesures de sécurité et les transferts transfrontaliers.
• PFPDT — Signalement des violations de données — Procédure et formulaire de notification officiel du Préposé fédéral.
• Centre national de cybersécurité (NCSC) — Conseils pour les PME, signalement d'incidents de cybersécurité, ressources de réponse à incident.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de surveillance, guides pratiques nLPD, décisions et recommandations.