nLPD : registre des traitements et registre des incidents, deux obligations distinctes

Deux registres, une même inspection

Le 01.09.2023, la nouvelle loi fédérale sur la protection des données (nLPD) est entrée en vigueur. Parmi les nouvelles exigences formelles, deux registres sont souvent traités comme un seul document dans les PME romandes : le registre des activités de traitement (art. 12 nLPD) et ce que les praticiens appellent le registre des incidents — soit la traçabilité des violations de données ouvrant ou non une obligation de notification au Préposé fédéral à la protection des données et à la transparence (PFPDT). Ces deux documents ont des périmètres, des responsables et des cycles de mise à jour différents. Les confondre expose l'organisation à une incapacité à répondre efficacement lors d'un contrôle ou d'un incident.

Le registre des activités de traitement : cadre légal et contenu minimum

Qui est obligé ?

L'art. 12 nLPD prévoit une exemption pour les entreprises de moins de 250 employés à condition que le traitement présente un faible risque de violation des droits des personnes concernées. En pratique, cette exemption disparaît dès qu'un traitement implique des données sensibles (données de santé, données biométriques, profils de la personnalité, données relatives aux poursuites ou sanctions pénales) ou un profilage à risque élevé. Une PME de 40 personnes gérant des dossiers RH complets, des données médicales pour une assurance complémentaire, ou des journaux d'accès biométrique dépasse ce seuil sans discussion. La règle pratique : si vous traitez des données sensibles au sens de l'art. 5 let. c nLPD, tenez le registre sans chercher l'exemption.

Contenu obligatoire côté responsable du traitement

L'ordonnance sur la protection des données (OPDo, art. 24–25) précise les rubriques minimales :

• Identité du responsable et, le cas échéant, du représentant en Suisse ou du sous-traitant.
• Finalités du traitement : soyez spécifiques (facturation clients ≠ scoring crédit interne).
• Catégories de personnes concernées : employés, clients B2C, prospects, visiteurs du site web.
• Catégories de données traitées : coordonnées, données financières, données de santé, logs système.
• Catégories de destinataires, y compris les pays tiers si les données franchissent les frontières.
• Durée de conservation ou critères pour la fixer (ex. : 10 ans pour les documents comptables selon le CO art. 958f).
• Mesures de sécurité générales : référence aux contrôles techniques et organisationnels appliqués.

Le registre n'est pas un document public, mais il doit être communiqué au PFPDT sur demande. Un tableur partagé non versionné sur un OneDrive sans contrôle d'accès n'est pas un registre conforme : la traçabilité des modifications (qui, quand, quelle version) est implicitement attendue.

Cycle de mise à jour

La nLPD n'impose pas de fréquence de révision explicite, mais la doctrine retient une revue annuelle formelle plus une mise à jour déclenchée par tout changement de système, de finalité ou de sous-traitant. Un projet d'intégration d'un nouveau SaaS RH, un changement de prestataire de cloud ou l'activation d'un module d'analyse comportementale sur les postes de travail sont autant de déclencheurs immédiats.

Le registre des incidents : obligations de notification et traçabilité interne

Cadre légal de la notification

L'art. 24 nLPD oblige le responsable du traitement à notifier le PFPDT dans les meilleurs délais une violation de la sécurité susceptible d'entraîner un risque élevé pour les droits des personnes concernées. La page dédiée aux nouvelles dispositions du PFPDT précise que la notification doit contenir a minima : la nature de la violation, les catégories et le volume de données concernées, les conséquences probables, les mesures prises ou envisagées. Si le risque est élevé pour les personnes elles-mêmes, celles-ci doivent également être informées directement.

La nLPD ne fixe pas de délai chiffré en heures contrairement au RGPD (72 h). L'expression "meilleurs délais" est interprétée par le PFPDT comme quelques jours ouvrés dans la pratique, avec une tolérance réduite si la violation est massive ou implique des données sensibles.

Contenu du registre des incidents

Il n'existe pas de formulaire légal standardisé, mais le Centre national pour la cybersécurité (NCSC) recommande une traçabilité structurée de chaque incident. En pratique, chaque entrée du registre devrait documenter :

• Date et heure de détection, de qualification et de notification (si applicable).
• Nature de la violation : accès non autorisé, exfiltration, perte de support, divulgation accidentelle, ransomware chiffrant des données personnelles.
• Systèmes et données impliqués : référence croisée au registre des traitements (identifiant du traitement concerné).
• Nombre estimé de personnes concernées et catégories de données exposées.
• Décision de notifier ou non le PFPDT, avec justification documentée si la décision est de ne pas notifier.
• Actions de remédiation et résultats des mesures correctives.
• Responsable de l'entrée et validateur (RSSI, juriste, DPO si nommé).

Ce registre a une valeur probatoire directe : en cas de litige ou de plainte auprès du PFPDT, l'absence de trace d'analyse de risque interne avant une décision de non-notification aggrave la position de l'organisation.

Incidents sans obligation de notification

Tous les incidents ne déclenchent pas une notification. La perte d'un laptop chiffré avec BitLocker (AES-256, clé de récupération en Entra ID, accès conditionnel actif) sans exfiltration confirmée ne présente pas de risque élevé si les mesures de sécurité fonctionnent. L'important est de documenter le raisonnement : pourquoi le risque est évalué comme faible, quelles preuves techniques étayent cette conclusion (logs MDM, état du chiffrement au moment de la perte). Cette documentation reste dans le registre même si aucune notification n'est envoyée.

Architecture documentaire : lier les deux registres

Référencement croisé

Un incident n'a de sens que rapporté à un traitement spécifique. Si votre registre des traitements attribue un identifiant unique à chaque activité (ex. : RH-003 pour la gestion de la paie, CLI-007 pour la base clients CRM), le registre des incidents peut référencer directement cet identifiant. Lors d'une inspection, le PFPDT peut ainsi tracer en quelques minutes la chaîne : traitement → données concernées → mesures de sécurité annoncées → incident survenu → réponse apportée. Un registre des incidents sans référence croisée oblige à reconstituer cette chaîne sous pression, avec le risque de contradiction.

Outillage minimal

Un tableur versionné (Git ou SharePoint avec historique activé) suffit pour une PME de moins de 100 endpoints, à condition que l'accès soit restreint (groupe AD ou Entra ID dédié, logs d'accès conservés). Les outils GRC (Gouvernance, Risques, Conformité) apportent la traçabilité des modifications, les workflows de validation et l'export structuré, mais impliquent un coût annuel de CHF 3 000 à CHF 15 000 pour les offres adaptées aux PME. Le choix doit refléter le volume d'incidents historiques et la fréquence de mise à jour du registre des traitements.

Sanctions et contrôles : ce que risque concrètement une PME

L'art. 60 nLPD prévoit des amendes pénales jusqu'à CHF 250 000 à l'encontre des personnes physiques responsables (pas de l'entreprise comme entité), en cas de violation intentionnelle des obligations d'information, de notification ou de coopération avec le PFPDT. L'absence de registre des traitements ou d'un registre des incidents documenté peut être qualifiée d'entrave à l'exercice des droits des personnes concernées ou de non-coopération. Le PFPDT dispose du pouvoir d'ouvrir des enquêtes d'office, d'émettre des recommandations contraignantes et de saisir le Tribunal administratif fédéral en cas de refus d'exécution. Les secteurs régulés (banques, assurances) cumulent les exigences nLPD avec celles de la FINMA, notamment la circulaire 2023/1 sur les risques opérationnels, qui impose des délais de notification d'incidents cyber à la FINMA elle-même.

Cas pratique : fiduciaire romande, 35 employés, 120 clients actifs

Contexte

Fiduciaire établie à Morges (VD), 35 employés, environ 120 mandats actifs incluant PME locales et indépendants. Parc informatique : 38 postes Windows 11 23H2, 12 MacBook Pro sous macOS 14, 8 iPhones gérés via MDM. Pas de DSI à plein temps, un responsable IT externalisé (MSP local). Données traitées : comptabilité clients, données salariales, données fiscales, documents d'identité pour les mandats de constitution de sociétés.

Qualification des obligations

35 employés → seuil des 250 non atteint. Mais la fiduciaire traite des données de santé (employés clients pour les déclarations sociales) et des profils financiers détaillés. L'exemption PME ne s'applique pas. Le registre des traitements est obligatoire.

Procédure de mise en conformité (12 semaines)

1. Semaines 1-2 — Inventaire des systèmes : Le MSP liste les applications en production (ERP fiduciaire, portail clients, messagerie, SharePoint, outil de signature électronique). Identification de 9 activités de traitement distinctes.
2. Semaines 3-4 — Rédaction du registre des traitements : Un juriste externe (demi-journée, environ CHF 600) valide les finalités et les bases légales. Le registre est structuré dans un tableur Excel versionné sur SharePoint, accès restreint à 3 personnes (associé responsable, MSP, juriste).
3. Semaine 5 — Durées de conservation : Recoupement avec les obligations légales (CO art. 958f : 10 ans pour pièces comptables, LAVS : 5 ans pour données salariales). Mise à jour du registre et instruction au MSP pour configurer les politiques de rétention sur Microsoft 365 (Exchange Online, SharePoint).
4. Semaines 6-7 — Registre des incidents : Création d'un second onglet (ou fichier séparé avec référence croisée) pour les incidents. Template avec les champs décrits ci-dessus. Formation de l'associé responsable sur les critères de déclenchement d'une notification PFPDT (30 min, checklist imprimée).
5. Semaines 8-10 — Test sur un incident fictif : Simulation d'un ransomware chiffrant le serveur de partage (scénario : 800 dossiers clients potentiellement exposés). Exercice de qualification du risque, rédaction de la notification fictive au PFPDT, calcul du délai de réponse. Résultat : 14 h pour produire une notification complète, objectif fixé à 8 h pour la prochaine simulation.
6. Semaines 11-12 — Revue annuelle planifiée : Entrée dans le calendrier de gestion (Q1 de chaque année) pour révision du registre des traitements et bilan des incidents de l'année écoulée. Coût total de la mise en conformité initiale : environ CHF 4 800 (juriste, temps MSP, formation).

Incident réel survenu 4 mois après

Un collaborateur reçoit un e-mail de phishing et clique sur un lien. Le MDM détecte une connexion depuis une IP roumaine sur le compte Microsoft 365 du collaborateur à 23h17. L'accès conditionnel bloque la session (politique MFA + localisation). Aucune donnée n'est exfiltrée selon les logs Microsoft Purview. Le registre des incidents est ouvert le lendemain matin : risque qualifié de faible (accès bloqué, pas d'exfiltration détectée, chiffrement actif sur tous les postes). Décision documentée : pas de notification PFPDT. Mesure corrective : révocation des tokens actifs, reset du mot de passe, formation anti-phishing pour le collaborateur. Entrée dans le registre complétée en 2 h 30.

Récapitulatif opérationnel

• Vérifiez l'exemption PME : si vous traitez des données sensibles (santé, finances détaillées, biométrie), le registre des traitements est obligatoire quelle que soit votre taille.
• Donnez un identifiant unique à chaque activité dans le registre des traitements pour permettre le référencement croisé avec les incidents.
• Créez le registre des incidents dès maintenant, même vide : l'absence de registre lors d'un premier incident oblige à reconstituer la chronologie sous pression.
• Documentez chaque décision de ne pas notifier le PFPDT : la justification technique et juridique a autant de valeur probatoire que la notification elle-même.
• Fixez un délai interne de notification inférieur à celui attendu par le PFPDT : viser 48 h pour qualifier un incident et 72 h pour envoyer une notification si le risque est élevé.
• Planifiez une revue annuelle formelle du registre des traitements avec un juriste ou un DPO externe (demi-journée suffit pour une PME de moins de 100 personnes).
• Simulez un incident une fois par an : chronométrez le temps de production d'une notification PFPDT complète et réduisez cet écart à chaque exercice.
• Vérifiez les flux transfrontaliers : tout SaaS hébergé hors de Suisse ou de l'EEE doit figurer dans le registre des traitements avec la base légale du transfert (décision d'adéquation, clauses contractuelles types).
• Conservez les deux registres au moins 10 ans (alignement sur les délais comptables du CO) : une plainte tardive peut porter sur des faits anciens.

SynGuard accompagne les PME romandes dans l'alignement de leur gestion d'endpoints avec les exigences documentaires de la nLPD, notamment la traçabilité des accès et la gestion des incidents sur les postes managés.

Sources

• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nLPD entrée en vigueur le 01.09.2023, base légale des obligations de registre et de notification.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de surveillance, guides pratiques et procédure de notification des violations de données.
• Centre national pour la cybersécurité (NCSC) — Recommandations sur la gestion des incidents cyber et signalement volontaire pour les entreprises suisses.
• FINMA — Autorité fédérale de surveillance des marchés financiers — Circulaire 2023/1 sur les risques opérationnels et obligations de notification d'incidents pour les établissements régulés.