Security+ — Gouvernance, risques et conformité : 45 questions d'entraînement

Step 1: Identifier et inventorier les actifs critiques — La gestion des risques débute par un inventaire des actifs (données, systèmes, personnes, processus). Cela permet de déterminer ce qui a de la valeur pour l'organisation et quels sont les points d'impact potentiel (confidentialité, intégrité, disponibilité).

Step 2: Évaluer les risques associés à ces actifs — Une fois les actifs identifiés, on réalise des analyses qualitatives ou quantitatives pour déterminer les menaces, vulnérabilités et l'impact potentiel sur l'organisation. Cette étape donne la base pour prioriser les risques.

Step 3: Définir et appliquer des traitements de risque — Après avoir priorisé, on choisit des réponses appropriées (accepter, transférer, atténuer, éviter) et on implémente des contrôles puis on surveille leur efficacité. Le suivi garantit que la stratégie reste adaptée. Trap: une idée reçue fréquente est de commencer par des mesures techniques visibles (pare-feu, IDS) ou par la surveillance continue sans d'abord définir le périmètre et les actifs. Sans inventaire précis, ces efforts risquent d'être mal ciblés et inefficaces. Why each wrong answer fails: - Mettre en place des contrôles techniques compensatoires : C'est une étape de traitement (atténuation) qui vient après l'identification et l'évaluation. Poser des contrôles sans connaître les actifs critiques peut conduire à surinvestir sur des éléments de faible valeur et laisser des lacunes ailleurs. - Calculer le coût potentiel des sauvegardes : C'est une activité tactique liée à la disponibilité et à la continuité, utile une fois les actifs et les risques identifiés. Elle ne peut remplacer l'inventaire initial. - Surveiller en continu les journaux d'événements : La surveillance est essentielle mais doit être basée sur un périmètre et des priorités définis. Sans inventaire, la surveillance risque d'être trop vaste, bruyante et coûteuse. Contexte réaliste : dans une entreprise multisite, débuter par un inventaire centralisé des actifs (applications critiques, bases de données PII, environnements cloud) permet d'aligner budget et efforts sur la réduction des risques les plus impactants.

Step 1: Vérifier le niveau de risque par rapport à la tolérance et au seuil d'appétit — Une fois les contrôles appliqués, il faut mesurer le risque résiduel et le comparer aux politiques de gouvernance du risque établies par l'organisation.

Step 2: Décision formelle — Si le risque résiduel est inférieur au seuil de tolérance, la décision la plus rationnelle est de l'accepter, mais cette acceptation doit être formalisée (approbation par le propriétaire du risque, enregistrement dans le registre des risques) et assortie d'un plan de surveillance pour détecter toute évolution.

Step 3: Surveillance et revue — Même accepté, le risque doit être revu périodiquement et la situation réévaluée si des changements d'environnement, de menace ou de conformité surviennent. Trap: penser qu'accepter un risque signifie l'ignorer est une erreur fréquente. L'acceptation est une décision contrôlée et documentée, pas de la négligence. Why each wrong answer fails: - Imposer des contrôles supplémentaires immédiats, quel qu'en soit le coût : Cela peut être inefficace et gaspiller des ressources. Les contrôles doivent être proportionnés aux risques et alignés sur les priorités business. Si le risque est déjà en-dessous du seuil, des dépenses additionnelles peuvent réduire le retour sur investissement sans bénéfice matériel. - Transférer automatiquement le risque à un fournisseur externe sans nouvelles analyses : Le transfert (assurance, sous-traitance) est une option valide mais doit être évalué (coût, limites de couverture, clauses contractuelles). Le transfert aveugle peut laisser des lacunes et n'élimine pas la responsabilité légale ou réglementaire de l'entreprise. - Ignorer toute documentation et continuer les opérations normales : L'absence de documentation compromet la traçabilité, la gouvernance et la capacité d'auditer la décision. En cas d'incident futur, cela peut exposer l'entreprise à des sanctions ou à une perte de confiance. Contexte réaliste : dans une banque, diminuer la probabilité d'une faille de 0,2% après contrôles et constater un risque résiduel inférieur au seuil de tolérance opérationnel justifie une acceptation formelle, mais avec monitoring renforcé des indicateurs clés.

Step 1: Contenir la propagation — L’isolation immédiate des systèmes compromis (déconnecter du réseau, couper accès aux partages, suspendre comptes infectés) est critique pour empêcher l’extension du chiffrement et la compromission de sauvegardes ou d'autres environnements. C’est l’action de confinement primaire dans les procédures d’intervention.

Step 2: Activer la continuité et restaurer depuis sauvegardes validées — Après confinement, l’organisation doit activer son plan BCP/DR, prioriser les services critiques et restaurer les systèmes à partir de sauvegardes connues propres et validées. Les restaurations doivent suivre des procédures testées pour éviter la réinfection (vérification d’intégrité, restauration en isolation, patching préalable).

Step 3: Enquêter, communiquer et renforcer — Conserver les preuves et lancer une analyse forensique pour comprendre vecteur, scope et responsabilités ; notifier les parties prenantes et autorités si requis ; renforcer contrôles (segmentations, MFA, durcissement) pour prévenir récidive. Trap: Penser que le paiement de la rançon est la voie rapide et sans risque. Payer ne garantit pas récupération, encourage les attaquants, et peut être contraire aux conseils légaux et d’assurance. De plus, restaurer sans analyse peut réintroduire l'attaquant. Why each wrong answer fails: - Payer la rançon : Le paiement n’assure pas la récupération complète des données ni l’absence de porte dérobée. Il alimente l’économie du crime, peut être illégal dans certains cas (si le destinataire est sanctionné) et n’est pas une garantie technique de reprise sécurisée. - Effacer les journaux et reprendre les opérations sans analyse forensique : Supprimer les journaux détruit des preuves essentielles pour identifier l'origine, l'étendue et les indicateurs de compromission ; cela compromet la capacité à corriger les causes profondes et à prévenir de futurs incidents. C’est également problématique pour la conformité et les obligations de notification. Conclusion : les priorités opérationnelles sont confinement + restauration contrôlée via sauvegardes validées et activation BCP/DR. Les autres actions, comme l’analyse forensique et la communication réglementaire, suivent rapidement et doivent être menées selon la politique d’incident.

Step 1: Définir les obligations contractuelles minimales — Un contrat robuste doit énoncer clairement les responsabilités du fournisseur (sécurité, notification des incidents, protection des données, audits, sous-traitance éventuelle) et les niveaux de service attendus pour disponibilité et récupération.

Step 2: Inclure des clauses d'indemnisation et de conformité — Les clauses d'indemnisation protègent le client contre les coûts résultant d'une faute du fournisseur (fuites de données, non-respect réglementaire). Les exigences de conformité obligent le fournisseur à respecter des normes (RGPD, HIPAA, ISO) et permettent des vérifications ou audits.

Step 3: Prévoir des mécanismes d'escalade et des sanctions (SLA) — Les SLA définissent les pénalités, obligations de remédiation et processus de résolution en cas de non-respect, réduisant ainsi l'incertitude juridique et financière. Trap: penser qu'une simple acceptation rapide des CGV ou une foi aveugle aux attestations du fournisseur suffit est une erreur courante. Sans protections contractuelles explicites, l'organisation cliente peut se retrouver sans recours en cas d'incident. Why each wrong answer fails: - Accepter les conditions générales du fournisseur sans négociation pour accélérer le déploiement : Cela laisse souvent l'entreprise cliente exposée, avec des responsabilités non couvertes et peu de recours en cas de non-conformité ou d'incident. - Se fier uniquement aux attestations auto-déclarées du fournisseur (self-assessment) : Les auto-attestations peuvent être utiles mais sont insuffisantes comme unique preuve. Elles ne remplacent pas les droits contractuels d'audit, les preuves techniques et les obligations légales. - Éviter toute clause de confidentialité pour simplifier les litiges potentiels : Supprimer des protections contractuelles accroît le risque juridique ; la confidentialité est au contraire une composante essentielle pour limiter la responsabilité et définir les actions en cas de violation. Contexte réaliste : une entreprise de services financiers qui migre vers le cloud devrait exiger des clauses de responsabilité financière, des obligations de notification de violation sous 72 heures, et le droit de procéder à des audits ou d'exiger des rapports SOC/ISO afin de réduire le risque légal associé aux fournisseurs.

Step 1: Classifier le risque et déterminer le profil d'acceptabilité — Dans un contexte réglementé, un risque à fort impact est rarement acceptable sans action. L’organisation doit d’abord quantifier l’impact financier, opérationnel et réglementaire (amendes, interruption de service, atteinte à la vie privée) pour savoir ce qui est requis par la conformité.

Step 2: Appliquer des traitements de risque appropriés — La mitigation (mettre en place contrôles techniques et procédures : redondance, segmentation réseau, sauvegardes, tests de reprise, contrôles d'accès robustes, surveillance et alerting) permet de réduire la probabilité et/ou l'impact. Le transfert (assurance cyber, clauses contractuelles avec fournisseurs, SLA) répartit l'exposition financière et opérationnelle. Utiliser les deux en combinaison est courant pour risques à fort impact : réduire la cause première puis transférer la partie résiduelle.

Step 3: Documenter, surveiller et réévaluer — Toute décision doit être consignée dans le registre des risques avec justification, indicateurs (KRI) et plan d'action. Mettre en place des contrôles de vérification (tests, audits) et revoir périodiquement l'efficacité des mesures. Trap: Une erreur fréquente est de confondre 'faible probabilité' avec 'faible priorité'. Un faible taux d'occurrence n'atténue pas l'obligation de traiter un impact majeur, surtout sous réglementation stricte. Why each wrong answer fails: - Accepter le risque sans action supplémentaire : Dans un environnement réglementé, accepter un risque à très fort impact sans justificatif solide expose l’entreprise à des sanctions, pertes majeures et réputationnelles. L'acceptation n'est appropriée que si l'analyse coût-bénéfice montre que les contrôles sont disproportionnés ou si le risque résiduel est dans le seuil d'appétit de risque documenté. - Retirer complètement l'activité ou le service : L'évitement (stopper l'activité) est efficace mais souvent impraticable pour des services critiques car il peut entraîner des pertes commerciales ou violer des obligations contractuelles/réglementaires. C'est une option de dernier recours et rarement viable pour les services essentiels. En résumé, pour un risque à fort impact dans un cadre réglementé, la combinaison mitigation + transfert est la réponse pragmatique : réduire l'exposition technique et opérationnelle puis répartir le risque financier ou contractuel, tout en documentant et surveillant les mesures mises en place.

Step 1: Principes juridiques du RGPD sur les transferts — Le RGPD encadre strictement les transferts de données personnelles vers des pays tiers. Les mécanismes légaux acceptés incluent une décision d'adéquation (la Commission européenne reconnaît qu'un pays assure un niveau de protection adéquat), les Clauses Contractuelles Types (SCC/CCT) approuvées, et les Règles d'Entreprise Contraignantes (BCR) pour les groupes d'entreprises. Ces mécanismes garantissent des obligations contractuelles et de protection au-delà des frontières.

Step 2: Rôle des mesures techniques comme le chiffrement — Le chiffrement est une mesure de sécurité importante et peut réduire le risque lors d'un transfert, mais il n'abroge pas la nécessité de disposer d'un fondement juridique pour le transfert. Par exemple, si le responsable du traitement ou le sous-traitant conserve la capacité de déchiffrement ou si l'accès aux clés est possible depuis le pays tiers sans garanties supplémentaires, le simple chiffrement n'est pas suffisant juridiquement.

Step 3: Pratique de mise en conformité opérationnelle — Avant tout transfert, réalisez une évaluation des risques du pays destinataire, choisissez le mécanisme juridique approprié (décision d'adéquation, SCC, BCR), documentez la logique et conservez les preuves. Assurez-vous que les clauses contractuelles couvrent les droits des personnes, les obligations de sécurité, les mécanismes d'accès et de coopération avec les autorités. Maintenez la traçabilité, les politiques de clé et, si applicable, mesures techniques complémentaires (pseudonymisation, chiffrement avec gestion sûre des clés). Trap: Croire que des mesures techniques seules (par ex. chiffrement) permettent d'éviter les obligations contractuelles ou de registre — les autorités de contrôle exigent des garanties juridiques et contractuelles en plus des protections techniques. Why each wrong answer fails: 1) (Correct) — Recense et combine les mécanismes légaux reconnus par le RGPD et rappelle la limitation du chiffrement seul. 2) — Incorrect : Le chiffrement seul n'exonère pas des obligations de transfert ; il faut un mécanisme juridique approprié. Par ailleurs, la gestion des clés et l'accès potentiel peuvent annuler l'efficacité juridique du seul chiffrement. 3) — Incorrect : Un accord verbal n'a aucune valeur juridique suffisante pour garantir la conformité au RGPD ; il faut des documents écrits, datés et souvent standardisés (SCC) ou des décisions formelles (adéquation). 4) — Incorrect : Les accords locaux internes ne remplacent pas les obligations contractuelles standardisées lorsque les données quittent l'UE ; les autorités exigent des garanties conformes au RGPD (SCC, BCR, ou autre base légale clairement établie). En résumé, pour les transferts internationaux depuis l'UE, sélectionnez et documentez le mécanisme juridique approprié (décision d'adéquation, SCC/CCT, BCR) et utilisez des mesures techniques comme le chiffrement en complément, mais pas comme substitution aux obligations légales.

Step 1: Valider l'identité et le besoin du fournisseur — Avant toute élévation de droits, vérifier l'identité du fournisseur, la justification métier, la durée nécessaire et s'assurer qu'un DPA et/ou contrat couvre la protection des données et responsabilités.

Step 2: Appliquer le principe du moindre privilège techniquement — Créer un compte temporaire avec les permissions minimum requises pour résoudre le problème, limiter sa durée (time-bound), forcer l'authentification forte (MFA), segmenter l'accès au périmètre nécessaire et activer la journalisation et la surveillance en temps réel pour enregistrer toutes les actions.

Step 3: Documenter et contrôler l'accès — Archiver les logs, obtenir approbation formelle du responsable métier et de la sécurité, exiger des preuves post-action (rapport, captures d'écran si approprié), et révoquer immédiatement l'accès à la fin de la mission. Mettre en place des revues périodiques et intégrer la preuve dans les audits. Trap: un piège courant est de privilégier la rapidité opérationnelle (donner accès permanent ou via comptes internes) au détriment de la sécurité et de la conformité; cela fait disparaître la séparation des responsabilités et complique toute traçabilité en cas d'incident futur. Why each wrong answer fails: - Fournir un compte administratif permanent (option 2) : Cela viole le principe du moindre privilège et augmente la surface d'attaque ; c'est non conforme aux contrôles d'accès, rend difficile la traçabilité et crée des risques d'abus et de non-conformité contractuelle. - Permettre l'accès via le compte d'un employé interne (option 3) : Partager des comptes ou utiliser le compte d'un employé entrave la responsabilisation, complique les audits et viole souvent les politiques internes ; en cas de mauvaise action il est impossible d'identifier l'acteur réel. - Donner un accès VPN complet sans journalisation (option 4) : L'absence de journalisation empêche toute vérification post-mortem et est incompatible avec les exigences de conformité ; un VPN large augmente aussi le périmètre exposé et n'applique pas le moindre privilège. En résumé, l'approche sécurisée et conforme est de mettre en place un accès temporaire et limité, contractuellement encadré, fortement authentifié et intégré à une stratégie de journalisation et d'audit.

Step 1: Définir les concepts — due diligence (diligence raisonnable) signifie évaluer et comprendre les risques (audits, évaluations, analyses) ; due care (soin dû) implique d'agir de manière responsable pour protéger les actifs (contrôles, formation, surveillance). Les juristes et assureurs s'attendent à des preuves tangibles de ces deux dimensions.

Step 2: Actions correspondant aux concepts — réaliser des évaluations régulières des risques (p. ex. BIA, évaluations de vulnérabilités, évaluations de conformité) démontre que l'organisation identifie et priorise les risques (due diligence). Former les employés régulièrement, mesurer la rétention des connaissances via tests et appliquer des mesures correctives/disciplinaires si nécessaire montre que l'organisation met en œuvre des protections opérationnelles et s'assure qu'elles sont suivies (due care).

Step 3: Documenter, mesurer et s'améliorer en continu — combiner ces activités avec des enregistrements formels, indicateurs (KRI/KPI) et preuves d'amélioration continue crée une posture défendable en cas d'incident ou d'audit. Les évaluations informent les priorités de formation et les contrôles techniques. Trap: Une idée fausse courante est que l'assurance seule ou la simple documentation suffit. L'assurance gère l'aspect financier post-incident mais ne remplace pas l'obligation de mettre en place des contrôles effectifs ; la documentation sans contrôle opérationnel est insuffisante pour démontrer la mise en œuvre réelle. Pourquoi chaque mauvaise réponse échoue : - Acheter une assurance cyber et considérer le risque comme transféré (option 2) : l'assurance transfère une partie du risque financier mais n'élimine pas l'obligation de sécuriser les systèmes ; les régulateurs et tribunaux exigent souvent des preuves que des mesures de sécurité adéquates existaient avant l'incident. - Documenter des politiques sans vérifier l'application (option 4) : les politiques non mises en œuvre ou non contrôlées ne prouvent ni la due diligence ni la due care ; les audits et contrôles opérationnels sont nécessaires pour démontrer l'application effective. En synthèse, les évaluations de risques régulières (due diligence) combinées à des programmes de formation et d'application des contrôles (due care) forment la base d'une gouvernance de sécurité responsable et défendable.

Step 1: Activer la préservation (legal hold) et stopper les processus automatiques — Dès que le service juridique impose un legal hold, l'équipe IT doit désactiver toute suppression automatique et mécanismes de rétention qui expireraient les données concernées, et s'assurer que les éléments e-mail sont marqués comme préservés.

Step 2: Préserver les données et métadonnées intactes — Il est crucial de conserver non seulement le contenu des e-mails mais aussi les métadonnées (horodatages, en-têtes, informations sur les pièces jointes, identifiants de message) et les journaux d'accès qui permettent de reconstruire l'origine, le parcours et l'intégrité des preuves. Tout processus de collecte doit documenter les étapes et garantir l'intégrité (hachage, empreinte) des éléments extraits.

Step 3: Documenter la chaîne de custody et contrôler l'accès — Toute extraction, transfert, analyse ou copie d'éléments soumis au legal hold doit être enregistrée : qui a accédé, pourquoi, comment et où les éléments sont stockés. Appliquer des contrôles d'accès stricts, des logs d'audit et conserver les preuves dans un stockage immuable quand possible. Trap: un piège fréquent est de confondre restauration à partir de sauvegardes ou suppression pour gain d'espace avec une vraie préservation juridique ; modifier, restaurer sans documentation ou supprimer des éléments peut être considéré comme spoliation et entraîner des sanctions lourdes. Why each wrong answer fails: - Supprimer immédiatement les messages en double (option 2) : La suppression de duplicatas sans validation peut altérer la preuve et enlever des informations contextuelles. Même si l'espace est une contrainte, toute suppression doit être approuvée par le service juridique et documentée ; fournir un échantillon sans préservation complète peut être insuffisant pour la découverte légale. - Chiffrer les boîtes mail et supprimer les journaux d'accès (option 3) : Chiffrer peut être acceptable pour protéger la confidentialité mais la suppression des journaux d'accès détruit des métadonnées essentielles et prive le processus juridique d'éléments probants ; cela ressemble à de la destruction volontaire d'informations pertinentes. - Restaurer des sauvegardes antérieures sans documentation (option 4) : Restaurer des backups peut altérer les originaux et, sans documentation rigoureuse de la méthode, compromet la validité des preuves. La manipulation non documentée des preuves numériques nuit à leur recevabilité. En résumé, la procédure conforme est d'activer le legal hold, préserver intégralement les e-mails et leurs métadonnées, documenter chaque action et maintenir une chaîne de custody pour garantir l'intégrité et l'acceptabilité des preuves en contexte légal.

Step 1: Comprendre la nature des deux documents — ISO 27001 est une norme internationale publiée par l'ISO qui définit les exigences pour établir, mettre en œuvre, maintenir et améliorer un Système de Management de la Sécurité de l'Information (SMSI). Elle contient des exigences auditable et certifiables par des organismes accrédités. Le NIST CSF (Framework for Improving Critical Infrastructure Cybersecurity) est un cadre de bonnes pratiques développé par le NIST qui fournit des fonctions, catégories et sous-catégories pour aider les organisations à gérer le risque cyber, mais il n'est pas conçu comme une norme certifiable.

Step 2: Considérer l'usage en entreprise — Dans un contexte d'audit, ISO 27001 permet à une entreprise de démontrer officiellement, via un certificat, que son SMSI respecte des exigences définies et qu'il y a une gouvernance formelle (politiques, revue de direction, traitement des non-conformités). Le NIST CSF est précieux pour effectuer des évaluations de maturité, cartographier des contrôles ou aligner des pratiques techniques sur des objectifs de sécurité, mais il ne remplace pas une certification formelle.

Step 3: Intégration pratique — Les organisations utilisent souvent les deux : ISO 27001 pour la gouvernance auditable du SMSI et NIST CSF pour détailler les capacités opérationnelles, la gestion des incidents et l'amélioration continue. Il existe des mappings publics entre les deux pour aider à traduire les exigences ISO en contrôles opérationnels NIST. Trap: Une erreur commune est de considérer que le NIST CSF est certifiable ou qu'ISO 27001 ne nécessite pas de preuves de gouvernance; en réalité c'est l'inverse : ISO 27001 est certifiable et exige de la documentation et des preuves de mise en œuvre effectives. Why each wrong answer fails: 1) (Correct) — correspond à la réalité fonctionnelle et juridique des deux cadres. 2) — Incorrect : Le NIST CSF n'est pas une norme certifiable internationale; il s'agit d'un cadre volontaire (principalement adopté aux États-Unis mais largement utilisé globalement) pour guider la gestion des risques. ISO 27001, au contraire, est une norme internationale certifiable. 3) — Incorrect : ISO 27001 ne se limite pas aux contrôles techniques ; elle couvre la gouvernance, les processus, la gestion des actifs, la continuité, la conformité légale, la formation, etc. De même, le NIST CSF ne se limite pas à la sécurité physique ; il couvre identification, protection, détection, réponse et récupération. 4) — Incorrect : Les deux ne sont pas strictement interchangeables ; ISO 27001 a un statut de norme certifiable tandis que le NIST CSF fournit un référentiel de bonnes pratiques. Les exigences légales et la reconnaissance peuvent varier selon les juridictions (ex : certifications ISO acceptées internationalement, NIST souvent utilisé dans le secteur public/critique aux États-Unis). Cette distinction impacte la préparation à un audit : pour démontrer une conformité « audit-ready », implémentez un SMSI basé sur ISO 27001 pour obtenir des preuves formelles et utilisez le NIST CSF pour renforcer et mesurer la maturité opérationnelle des contrôles techniques.

Step 1: Identifier et documenter les baselines — Pour rester audit-ready, il faut d’abord définir des baselines (configurations de référence) pour chaque catégorie de système (OS, base de données, applicatifs). Ces baselines servent de point de comparaison lors d'audits et permettent de détecter des dérives ou configurations non autorisées.

Step 2: Contrôler les changements — Un processus formel de gestion des changements (RFC, approbation, tests, fenêtres de déploiement, plan de retour arrière) doit être lié aux baselines. Chaque modification doit être enregistrée, justifiée et traçable.

Step 3: Versionner et rapporter — Les baselines et les enregistrements des changements doivent être versionnés et conservés avec des métadonnées (qui, quand, pourquoi). Ces artefacts constituent la preuve qu'un contrôle continu est en place et facilitent les revues d'audit. Trap: la croyance que « avoir des logs suffit » est une erreur fréquente; sans baselines et preuves d'approbation, les logs ne prouvent pas que les configurations étaient conformes ou que les changements ont été validés. Pourquoi chaque mauvaise réponse échoue: Réponse 2 (Conserver indéfiniment les logs) : Bien que la conservation des journaux soit importante, l'archivage seul ne prouve pas que les systèmes étaient correctement configurés ni que les changements ont été approuvés; de plus, conserver tout indéfiniment crée des coûts et des risques de confidentialité. Réponse 3 (Formation annuelle) : La formation est nécessaire pour la sensibilisation, mais n'apporte pas de traçabilité opérationnelle ni de preuve de conformité des configurations. Réponse 4 (Déployer un pare-feu NG) : Un pare-feu moderne aide la sécurité réseau, mais ne remplace pas la documentation des configurations, la gestion des changements et les baselines applicables à l'ensemble des systèmes. En synthèse, la combinaison baselines + gestion des changements versionnée répond directement aux exigences d'audit en produisant la preuve documentaire et technique de l'état et de l'évolution des systèmes.

Step 1: Rappel du principe réglementaire — Le RGPD impose une obligation de notification des violations de données personnelles à l'autorité de contrôle compétente «sans délai indu, et si possible, dans les 72 heures» après en avoir pris connaissance, lorsque la violation est susceptible d'engendrer un risque pour les droits et libertés des personnes physiques.

Step 2: Appliquer la procédure d'incident — À la découverte d'une violation, activer le plan d'intervention, évaluer l'étendue et les risques, documenter l'incident et, si l'analyse révèle un risque, préparer la notification incluant la nature de la violation, les catégories et le nombre approximatif de personnes affectées, les mesures prises et les contacts pour plus d'informations. Cela doit être fait dans le délai maximal de 72 heures; si la notification est retardée, il faut fournir une justification motivée.

Step 3: Notification aux personnes concernées et suivi — Si la violation est susceptible d'engendrer un risque élevé pour les droits et libertés, informer également les personnes concernées sans retard injustifié. Mettre en œuvre des mesures correctives et renforcer les contrôles pour éviter récidive. Trap: penser que 24 heures est la norme stricte est une erreur courante — le RGPD prévoit 72 heures comme délai maximal raisonnable, non 24. Pourquoi chaque mauvaise réponse échoue: 1) 24 heures est trop court et n'est pas la norme fixée par le RGPD; bien que la réactivité soit importante, l'autorité prévoit 72 heures pour permettre l'évaluation initiale. 3) 7 jours dépasse le délai légal maximal; notifier après 7 jours sans justification expose l'organisation à des sanctions. 4) 30 jours est manifestement trop long et non conforme à l'exigence de notification rapide; une telle latence peut aggraver les risques pour les personnes et entraîner des pénalités. En résumé, l'exigence RGPD est d'aviser l'autorité compétente dans les 72 heures après prise de connaissance si le critère de risque est rempli, tout en documentant l'évaluation et les motifs de tout retard.