nLPD : registre des traitements et registre des incidents en pratique

Deux registres, deux logiques, une même obligation de résultat

Depuis l'entrée en vigueur de la loi fédérale sur la protection des données révisée (nLPD) le 01.09.2023, les responsables du traitement basés en Suisse — y compris les PME — doivent tenir deux instruments documentaires distincts : le registre des activités de traitement (art. 12 nLPD) et le registre des violations de données (art. 24 nLPD). Le premier est un inventaire permanent ; le second est un journal d'incidents actif. Les confondre dans un même tableur mal structuré, ou ne tenir que l'un des deux, constitue un manquement directement opposable par le Préposé fédéral à la protection des données et à la transparence (PFPDT).

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

Qui est obligé ?

L'art. 12 al. 5 nLPD prévoit une exemption pour les entreprises de moins de 250 employés dont les traitements présentent un risque limité pour la personnalité des personnes concernées. En pratique, cette exemption est plus étroite qu'il n'y paraît : dès qu'une PME traite des données sensibles (santé, opinions politiques, données biométriques, profils de risque financier), gère des données pour des tiers (prestataire RH, fiduciaire, MSP), ou réalise du profilage, l'obligation s'applique pleinement. Une fiduciaire de 18 collaborateurs qui traite les salaires de 60 clients PME entre clairement dans le champ.

Contenu minimal requis

L'ordonnance sur la protection des données (OPDo) précise les champs obligatoires pour chaque activité de traitement :

• Identité du responsable et du représentant en Suisse si applicable.
• Finalité du traitement : libellé précis, pas une formule générique comme « gestion administrative ».
• Catégories de personnes concernées : employés, clients, visiteurs, prospects, mineurs.
• Catégories de données : coordonnées, données financières, données sensibles au sens de l'art. 5 let. c nLPD.
• Destinataires ou catégories de destinataires, y compris les sous-traitants et les transferts hors Suisse.
• Durée de conservation ou critères pour la déterminer.
• Mesures de sécurité techniques et organisationnelles (TOM) : au moins une description de niveau.

Le registre n'a pas de format imposé — tableur, outil GRC, fichier JSON structuré — mais il doit être disponible sur demande du PFPDT dans un délai raisonnable (pratique : 5 jours ouvrables est un seuil SLA défendable). Une colonne supplémentaire indiquant la base légale du traitement (consentement, intérêt légitime, exécution du contrat) facilite les éventuels contrôles et la mise à jour de la politique de confidentialité.

Mise à jour et gouvernance

Le registre n'est pas un document statique. Chaque nouveau traitement, chaque changement de sous-traitant ou de pays de stockage déclenche une mise à jour. En PME, une revue semestrielle formalisée (responsable désigné, date de validation, historique des versions) est le minimum crédible. Sans historique, impossible de démontrer la continuité de la conformité.

Registre des violations de données et obligation de notification (art. 24 nLPD)

Définition d'une violation et seuil de notification

Une violation de données personnelles est tout incident entraînant accidentellement ou illicitement la destruction, la perte, la modification, la divulgation non autorisée ou l'accès non autorisé à des données personnelles. Le seuil de notification au PFPDT est défini à l'art. 24 al. 1 nLPD : notification obligatoire dès que la violation est susceptible d'entraîner un risque élevé pour la personnalité ou les droits fondamentaux de la personne concernée. Le délai est « dans les meilleurs délais » — la pratique européenne (72 heures RGPD) sert de référence implicite ; le PFPDT n'a pas fixé de délai chiffré à ce jour, mais toute notification au-delà de 72 à 96 heures doit être justifiée.

Contenu du registre des incidents

Indépendamment de l'obligation de notification, tout incident doit être consigné dans un registre interne, même s'il ne dépasse pas le seuil de notification. Ce registre doit contenir :

• Date et heure de détection, date et heure estimée du début de l'incident.
• Nature de la violation (accès non autorisé, exfiltration, ransomware, erreur d'envoi, perte de support physique…).
• Catégories et volume approximatif de données concernées (ex. : 340 dossiers clients incluant IBAN et adresses).
• Catégories et nombre approximatif de personnes concernées.
• Conséquences probables pour les personnes concernées.
• Mesures prises ou envisagées pour remédier à la violation.
• Décision motivée de notifier ou non le PFPDT, signée par le responsable du traitement ou le RSSI.
• Si notification : date d'envoi, numéro de dossier PFPDT, contenu transmis.

Procédure de notification au PFPDT

Le PFPDT met à disposition un formulaire de notification en ligne. La procédure recommandée est la suivante :

1. Détection et confinement (H+0 à H+4) — DSI ou SOC isole les systèmes compromis, sécurise les logs. Ouverture du ticket d'incident avec horodatage.
2. Qualification juridique (H+4 à H+24) — RSSI et juriste évaluent : données sensibles impliquées ? Nombre de personnes ? Risque élevé au sens de l'art. 24 nLPD ? Décision documentée, signée.
3. Notification initiale au PFPDT (avant H+72 si risque élevé) — Via le formulaire de notification du PFPDT. La notification initiale peut être partielle si l'enquête est incomplète ; une notification complémentaire suit.
4. Information des personnes concernées (si risque élevé) — Art. 24 al. 4 nLPD : le responsable doit informer les personnes si c'est nécessaire pour leur protection. Délai et contenu à documenter.
5. Rapport post-incident (J+5 à J+14) — Chronologie complète, cause racine, mesures correctives, mise à jour du registre des incidents. Notification complémentaire au PFPDT si des éléments nouveaux sont apparus.
6. Clôture et archivage — Entrée définitive dans le registre des violations, avec statut « clôturé » et date. Conservation minimale recommandée : 5 ans (cohérent avec les délais de prescription civile).

Articulation avec les autres obligations nLPD et les normes de référence

Analyse d'impact (AIPD) et registre

L'art. 22 nLPD impose une analyse d'impact relative à la protection des données (AIPD) pour les traitements à risque élevé. L'AIPD n'est pas une entrée du registre des traitements, mais elle s'y articule : chaque traitement qualifié « risque élevé » dans le registre doit pointer vers l'AIPD correspondante (référence documentaire, date, version). Cette traçabilité est vérifiée en priorité lors d'un contrôle PFPDT.

Alignement CIS et ISO 27001

Les CIS Benchmarks (contrôle CIS v8 #3 — Data Protection, #17 — Incident Response Management) et la norme ISO 27001:2022 (annexe A, contrôle 5.24 et 6.8) couvrent des exigences proches. Une PME certifiée ISO 27001 ou alignée CIS dispose en général d'un registre d'actifs et d'une procédure d'incident response ; il suffit d'adapter ces outils au vocabulaire nLPD pour satisfaire les deux cadres sans doublon documentaire. Le registre des incidents de sécurité (ISO 27001 §6.8) et le registre des violations nLPD peuvent être le même document si les champs requis par les deux référentiels sont couverts.

Spécificités sectorielles

Les entités régulées par la FINMA (banques, assurances, gestionnaires de fortune) ont des obligations de notification parallèles (circulaire FINMA 2023/1 sur les risques opérationnels). La notification PFPDT et la notification FINMA sont deux canaux distincts, avec des délais potentiellement différents. Le registre des incidents doit tracer les deux flux séparément.

Cas pratique : fiduciaire vaudoise de 22 collaborateurs

Contexte : Fiduciaire à Lausanne, 22 collaborateurs, 85 clients PME. Traite des données salariales, fiscales et comptables pour le compte de ses clients (sous-traitant au sens nLPD vis-à-vis de ses clients, responsable du traitement pour ses propres données RH internes). Parc : 28 endpoints Windows 11 23H2, 4 MacBook (macOS 14.5), 1 NAS Synology en local, stockage cloud chez un fournisseur helvétique.

Incident survenu le 14.03.2024, 07h42 : Un collaborateur reçoit un e-mail de phishing, clique sur un lien, saisit ses identifiants Microsoft 365. L'attaquant exfiltre depuis la boîte mail du collaborateur 1 240 e-mails contenant des bulletins de salaire et des déclarations fiscales de 34 clients, soit environ 680 personnes physiques concernées (employés des clients). Détection par une alerte MFA anormale à 08h15.

Procédure appliquée :

1. 08h15 — Confinement : Le DSI révoque la session active, réinitialise le mot de passe, active le MFA forcé sur le compte. Snapshot des logs d'audit Microsoft 365 exporté (format .csv, 48 h d'historique). Ticket d'incident ouvert dans le système de ticketing (horodatage : 08h22).
2. 09h00 — Qualification : RSSI (rôle tenu par le DSI dans cette structure) et l'associé responsable évaluent : données sensibles ? Oui — bulletins de salaire = données financières, numéros AVS présents dans 12 % des documents. Nombre de personnes : ~680. Risque élevé : oui (usurpation d'identité, fraude fiscale possibles). Décision : notification PFPDT obligatoire.
3. 11h30 (H+3h15) — Notification initiale au PFPDT : Formulaire en ligne soumis avec les informations disponibles. Mention explicite que l'enquête est en cours ; notification complémentaire promise sous 5 jours. Numéro de dossier PFPDT reçu automatiquement.
4. 14h00 — Information des clients : Les 34 clients PME dont les données ont été exfiltrées sont contactés par téléphone, puis par e-mail avec description de l'incident, des données concernées, et des mesures recommandées pour leurs propres employés. La fiduciaire est ici sous-traitant ; elle informe ses clients (responsables du traitement) qui décident eux-mêmes d'informer leurs employés.
5. 19.03.2024 — Notification complémentaire : Rapport complet transmis au PFPDT : liste précise des 1 240 e-mails exfiltrés, analyse forensique succincte (aucun accès aux systèmes internes, exfiltration limitée à la boîte mail), mesures correctives (déploiement MFA sur tous les comptes, formation anti-phishing, révision de la politique de partage de documents).
6. Entrée registre des incidents : Violation #2024-001, statut clôturé le 22.03.2024. Coût estimé : 3 200 CHF (temps DSI + conseil juridique externe 2 h à 350 CHF/h + communication clients).

Registre des traitements mis à jour : L'incident a révélé que le traitement « archivage e-mails clients » n'était pas décrit dans le registre. Entrée créée le 19.03.2024 avec durée de conservation (7 ans, cohérent avec CO art. 958f), mesures de sécurité (MFA, chiffrement au repos), et base légale (exécution du contrat de mandat).

Récapitulatif opérationnel

• Vérifier le périmètre d'obligation : même sous 250 employés, l'exemption art. 12 al. 5 nLPD ne s'applique pas si vous traitez des données sensibles ou agissez comme sous-traitant.
• Structurer deux registres distincts : registre des activités (inventaire statique mis à jour) et registre des violations (journal d'incidents actif). Un seul tableur peut suffire à condition d'onglets et de champs distincts.
• Couvrir les 7 champs obligatoires du registre des traitements (finalité, catégories de personnes, catégories de données, destinataires, durée, TOM, base légale).
• Définir un seuil interne de qualification : toute violation impliquant des données sensibles ou plus de 100 personnes passe automatiquement en revue juriste + RSSI dans les 4 heures.
• Cibler H+72 pour la notification PFPDT en cas de risque élevé. Une notification initiale partielle vaut mieux qu'une notification tardive complète.
• Documenter la décision de ne pas notifier : pour les incidents sous le seuil, une décision motivée signée dans le registre protège en cas de contrôle ultérieur.
• Aligner registre des incidents et procédure ISO 27001 §6.8 / CIS v8 #17 pour éviter la double documentation.
• Prévoir une revue semestrielle du registre des traitements : responsable nommé, date de validation, historique des versions conservé 5 ans minimum.
• Former les collaborateurs à la détection et au signalement interne : le délai H+72 commence à la détection ; un incident non signalé en interne pendant 48 h laisse moins de 24 h pour notifier.
• Vérifier les clauses sous-traitant dans vos contrats clients : l'art. 9 nLPD impose des clauses contractuelles avec vos sous-traitants ; en cas d'incident chez un sous-traitant, c'est vous le responsable du traitement vis-à-vis du PFPDT.

SynGuard propose des modèles de registres conformes nLPD et des procédures d'incident response adaptées aux PME romandes de 20 à 150 endpoints, intégrables dans les outils de gestion existants.

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 — Détail des champs requis pour le registre des activités et les mesures de sécurité.
• Notification d'une violation de données — PFPDT — Formulaire officiel et instructions de notification au Préposé fédéral.
• CIS Benchmarks — Center for Internet Security — Référentiel de contrôles techniques incluant Data Protection (CIS v8 #3) et Incident Response (#17).
• ISO/IEC 27001:2022 — Organisation internationale de normalisation — Norme de management de la sécurité de l'information, annexe A contrôles 5.24 et 6.8.