Questions d'entretien Governance, Risk & Compliance

Non. Le cloud repose sur un modèle de responsabilité partagée : le fournisseur sécurise l'infrastructure sous-jacente (« sécurité du cloud »), mais vous restez responsable de vos données, de la gestion des identités et des accès, de la configuration et — en IaaS — du système d'exploitation et des correctifs (« sécurité dans le cloud »). La grande majorité des fuites cloud sont des erreurs de configuration côté client, comme des buckets publics et un IAM trop permissif, et non des défaillances du fournisseur. Croire que le fournisseur sécurise vos données est précisément ainsi que ces fuites surviennent.

Non. Un VPN chiffre le trafic jusqu'au serveur VPN et masque votre IP à la destination, mais le fournisseur peut voir et journaliser votre activité, et les connexions, cookies et l'empreinte du navigateur vous identifient toujours. Cela déplace la confiance de votre réseau local/FAI vers l'opérateur du VPN — c'est de la confidentialité vis-à-vis du réseau local, pas de l'anonymat. Tor et une discipline opérationnelle stricte sont d'autres outils pour un autre objectif.

Un modèle tiers est une dépendance de chaîne d'approvisionnement : vérifiez qu'il provient d'une source de confiance avec des sommes de contrôle/signatures correspondantes, que sa licence autorise votre usage, et que le format de fichier n'exécute pas de code arbitraire au chargement (préférez une sérialisation sûre aux formats de type pickle). « Il se charge » et « la vitesse de téléchargement » ne disent rien de la confiance, et supposer que les modèles publics sont sûrs ignore les risques réels d'empoisonnement et de désérialisation.

Envoyer des données personnelles de clients à une API externe les expose au traitement et à la conservation d'un tiers et peut enfreindre des obligations de confidentialité. Minimisez et anonymisez ce qui est envoyé, confirmez les conditions d'usage/conservation du fournisseur et un accord de traitement des données (ou des garanties de non-entraînement), ou passez à un déploiement privé pour les données sensibles. La longueur de la clé n'a aucune importance, et envoyer plus de données personnelles augmente l'exposition.

L'intégrité probante repose sur le hachage de l'image lors de l'acquisition (par exemple SHA-256) et la vérification ultérieure du hachage pour prouver qu'elle est inaltérée, le maintien d'une chaîne de possession documentée, et l'analyse d'une copie de travail pour que l'original reste intact. Renommer le fichier ne fait rien pour l'intégrité, et le compresser pour gagner de l'espace ne prouve pas l'intégrité ni n'aide la recevabilité. Toucher à l'original risque une destruction de preuves qui peut faire écarter la preuve. Hachez, documentez la possession et travaillez sur une copie vérifiée.

Les auditeurs vérifient des preuves, pas des intentions : présentez la politique de revue d'accès, des relevés datés de chaque revue avec la validation d'un approbateur, et la confirmation que les accès signalés ont bien été révoqués et vérifiés. Une confirmation verbale ne prouve rien de reproductible, une promesse de commencer le trimestre prochain montre que le contrôle ne fonctionnait pas pendant la période auditée, et un organigramme décrit des liens hiérarchiques, pas des décisions d'accès. Seuls les artefacts datés et attribuables démontrent que le contrôle a fonctionné comme prévu sur toute la période.

Les sauvegardes sont nécessaires mais non suffisantes : la reprise d'activité et la continuité d'activité sont la capacité testée à restaurer l'activité dans les objectifs convenus de temps et de point de reprise (RTO/RPO), ce qui exige un plan documenté, des dépendances cartographiées, des runbooks et des restaurations validées — pas seulement l'existence de fichiers de sauvegarde. Affirmer qu'elles sont identiques confond une copie de données avec une capacité opérationnelle. Le PRA ne se résume pas à souscrire une assurance, qui transfère la perte financière mais ne restaure pas les systèmes. Et les sauvegardes ne rendent pas un PRA inutile — des sauvegardes non testées échouent régulièrement le moment venu. La clarification : le PRA doit être exercé, pas présumé.

Les référentiels fixent une barre minimale et peuvent être pleinement satisfaits alors qu'un risque réel subsiste ; une check-list réussie ne signifie donc pas sécurisé : signalez la faille, évaluez son risque et pilotez son traitement, quel que soit le statut de conformité. Conclure que c'est sécurisé parce que la conformité est validée est un amalgame dangereux entre deux choses différentes. Retirer la faille du rapport est une falsification, voire une fraude. Attendre le prochain cycle d'audit laisse sciemment une exposition réelle ouverte. La posture mature traite la conformité comme la preuve d'un plancher, pas d'un plafond, et agit sur le risque que l'on peut réellement voir.

Un traitement incohérent traduit généralement l'absence de définition partagée de la sensibilité ; le contrôle fondamental est donc un schéma de classification des données (par ex. public/interne/confidentiel/restreint) avec des exigences définies de traitement, de stockage et de partage par niveau, permettant aux équipes d'appliquer des contrôles proportionnés. Ne rien chiffrer « pour faire simple » ou traiter toutes les données comme publiques retire la protection aux données qui en ont besoin. Supprimer toutes les données de plus d'un jour détruit des enregistrements dont l'entreprise et la loi ont besoin. Seul un schéma de classification aligne la force des contrôles sur la sensibilité réelle des données.

Le risque au départ, c'est l'accès résiduel ; le contrôle à vérifier est donc le déprovisionnement rapide de chaque voie d'accès — comptes d'annuaire, SSO, VPN, identifiants privilégiés et de service, et SaaS tiers — rapproché du processus arrivée/mobilité/départ (JML). Supposer que les RH gèrent tout sans vérification laisse des failles que personne ne possède. Garder le compte actif « au cas où il reviendrait » est un risque permanent et non surveillé. Désactiver seulement l'e-mail ignore les nombreux autres systèmes que la personne pourrait encore atteindre. L'enjeu est de vérifier que l'accès est réellement et totalement retiré, pas de présumer qu'il l'a été.

Le périmètre PCI DSS couvre les systèmes qui stockent, traitent ou transmettent les données de titulaires de cartes, plus tout système qui leur est connecté ou peut les affecter ; une segmentation réseau efficace isole donc l'environnement des données de cartes (CDE) et exclut du périmètre les systèmes sans rapport, réduisant coût, effort et risque. Chiffrer tous les serveurs ne définit aucune frontière et les systèmes connectés restent dans le périmètre ; ajouter des pare-feu partout sans cible n'est pas de la segmentation si cela ne restreint ni ne valide les flux de données ; et cesser de lire les numéros de carte à voix haute relève de l'hygiène, pas d'un contrôle de périmètre. La réponse systémique est de maîtriser où vivent les données de cartes et ce qui peut les atteindre.

La gouvernance, c'est capturer et gérer le risque, pas le traiter de façon informelle : inscrivez-le au registre des risques avec une probabilité et un impact évalués, désignez un propriétaire responsable, décidez et documentez le traitement (atténuer, transférer, accepter ou éviter), et fixez une date de revue. Le corriger vous-même sur-le-champ contourne la responsabilité, la priorisation et le suivi, et ce n'est peut-être même pas à vous de le faire. L'ignorer jusqu'à ce qu'il devienne un incident est une négligence, et l'envoyer par e-mail à tout le monde crée du bruit mais aucune responsabilité ni suivi. Le registre transforme une observation ponctuelle en une décision suivie, attribuée et réexaminée.

Un rapport SOC 2 ne vous rassure que si vous le lisez vraiment : confirmez le bon type (le Type II teste l'efficacité opérationnelle dans la durée, le Type I seulement la conception à un instant donné), vérifiez le périmètre et les critères des services de confiance couverts, que la période est récente et sans trou, l'opinion rendue par l'auditeur (sans réserve ou avec réserve), et examinez les exceptions relevées ainsi que les contrôles complémentaires de l'entité utilisatrice (CUEC) qui vous incombent. Se contenter de constater que le rapport existe — ou le juger à son logo de couverture ou à son nombre de pages — ne dit rien de l'efficacité réelle des contrôles du fournisseur ni de vos obligations résiduelles.

Le code transitif s'exécute dans votre application, donc une CVE critique est votre risque. Évaluez si le chemin de code vulnérable est réellement atteignable, puis remédiez en montant ou en surchargeant la version (ou en atténuant) et vérifiez en production. L'ignorer parce qu'elle est transitive laisse un trou connu qu'un attaquant peut exploiter. Supprimer l'avertissement ne fait que masquer le signal. Réinstaller node_modules ramène la même version vulnérable. Suivez-la via le SCA, ne la faites pas taire.

Équilibrez utilisabilité et risque : imposez un accès conditionnel lié à la posture de l'appareil et isolez les données d'entreprise dans un conteneur géré (MAM/MDM) afin de les contrôler et de les effacer sélectivement sans prendre la main sur tout l'appareil personnel. Un accès illimité risque la fuite sur des terminaux non gérés, possiblement compromis. Une interdiction pure et simple pousse aux contournements non sûrs comme le transfert vers une messagerie personnelle. Et envoyer les données en pièces jointes les disperse de façon incontrôlable sur des appareils que vous ne récupérerez jamais.

Aucun produit unique n'arrête toutes les attaques ; une sécurité mature superpose des contrôles indépendants — la défense en profondeur — pour que la défaillance de l'un ne signifie pas la compromission. Cartographiez la dépense proposée par rapport aux véritables lacunes en identité, réseau, poste de travail, données et détection, et conservez les contrôles complémentaires qui fonctionnent déjà. Tout miser sur un seul outil crée un point unique de défaillance, et arracher les contrôles existants pour les remplacer réduit la couverture. Ne rien dépenser du tout ignore de vraies lacunes.

Le chiffrement au repos ne défend qu'une seule menace — le vol physique ou de disque — et n'apporte rien contre une application compromise, des identifiants volés ou un trafic intercepté, car la base déchiffre de façon transparente pour toute requête autorisée. Une conception saine exige aussi du TLS en transit, une authentification et une autorisation fortes, et une gestion des clés avec séparation des tâches. Doubler le chiffrement au repos ajoute du coût sans changer le modèle de menace, et ne chiffrer que les sauvegardes laisse les données en production et leurs chemins d'accès exposés.

La modélisation des menaces est la moins coûteuse et la plus efficace à la conception, avant que le code ne fige les décisions : parcourez les flux de données, énumérez les menaces avec un cadre comme STRIDE, intégrez les mesures, puis révisez à mesure que la conception évolue. La faire seulement après un incident ou au pentest annuel révèle les problèmes une fois qu'ils sont coûteux à corriger et déjà exposés. Et se fier à des « développeurs prudents » est un espoir, non un contrôle reproductible et auditable.

Transmettre des données personnelles à un tiers étend votre périmètre de confiance ; menez donc d'abord une évaluation de sécurité du fournisseur — traitement des données, chiffrement, contrôles d'accès, certifications comme SOC 2 / ISO 27001, sous-traitants, modalités de notification de violation — et signez un accord de traitement des données (DPA) avant tout transfert. Un contrat de prix ou la parole verbale d'un commercial n'est pas une diligence raisonnable. Et un « site web soigné » ne dit rien sur la façon dont le fournisseur protège réellement les données ; vous en restez responsable.

« Sécurisé » n'est pas binaire ; un RSSI communique dans le langage du risque métier : les risques les plus importants, la manière dont les contrôles actuels les réduisent par rapport à l'appétit pour le risque du conseil, les investissements prévus et le risque résiduel accepté. Un « oui » absolu est une fausse assurance qui s'effondre dès le premier incident. « Non, nous ne serons jamais sécurisés » est techniquement vrai mais inutile et trahit un manque de maîtrise. Une liste d'achats de pare-feu et d'outils traduit une dépense, pas un risque ni un résultat que le conseil puisse gouverner.

La gestion d'une violation est encadrée par la loi et le contrat : travailler avec le juridique pour respecter les délais de notification obligatoires (comme les 72 heures du RGPD vers l'autorité de contrôle) et informer les personnes concernées avec exactitude. La dissimulation expose à des amendes bien plus lourdes, à des sanctions et à une atteinte à la réputation lorsqu'elle est découverte. Diffuser prématurément des détails techniques bruts et non vérifiés peut induire les clients en erreur et aider les attaquants. Désigner publiquement un employé comme bouc émissaire n'est ni exact, ni légal, ni une gestion de crise efficace.

Les métriques de niveau conseil doivent se rattacher au risque et aux résultats : temps de détection et de réponse (MTTD/MTTR), respect des SLA de correctifs sur les systèmes critiques, couverture des contrôles et évolution du risque résiduel par rapport à l'appétit. Le nombre d'attaques bloquées par le pare-feu, le compte des signatures antivirus et le total des courriels reçus sont des chiffres vaniteux — ils impressionnent mais ne disent rien sur la baisse du risque. Le conseil gouverne le risque, les métriques doivent donc lui montrer la tendance et lui permettre de décider.

Un taux de clic de 30 % est un point de référence à améliorer, pas une liste de personnes à punir : associer une formation ciblée par rôle et un bouton de signalement sans friction à des défenses techniques (MFA, filtrage de courrier, moindre privilège) pour qu'un seul clic ne mène pas à une compromission, et suivre la tendance dans le temps. Humilier publiquement les employés étouffe le signalement dont vous dépendez. Déclarer le personnel irrécupérable supprime un contrôle à renforcer. Un nouveau courriel anxiogène à tous n'est pas une intervention mesurable et ne change pas le comportement.

Les dépenses de sécurité doivent suivre le risque, pas l'effet de mode : utiliser une analyse de risque pour orienter l'argent là où l'impact métier et la probabilité sont les plus élevés et où la couverture des contrôles actuels est la plus faible, puis mesurer la réduction obtenue. Acheter ce que vend le fournisseur à la mode ignore votre profil de menace réel et finance souvent des outils inutilisés. Répartir le budget également sous-finance les rares domaines qui comptent le plus. Copier les concurrents suppose que leur profil de risque égale le vôtre, ce qui est rarement le cas.

Les simulations répètent le côté humain et décisionnel de la RI — qui a l'autorité de déclarer un incident, comment circule la communication juridique/RP/direction, et où le manuel se brise — afin que la première fois où vous prenez ces décisions ne soit pas en pleine crise réelle. Il est bien moins coûteux de trouver les failles lors d'un exercice qu'en pleine violation. Ce n'est pas une case de conformité vide, ce n'est pas pour attribuer des blâmes sur des incidents passés, et c'est transverse, pas réservé au SOC — la direction doit s'entraîner aux décisions qu'elle seule peut prendre.

Quand on ne peut pas remédier, on gère le risque : réduire l'exposition par des contrôles compensatoires (segmentation réseau, restriction des accès, surveillance renforcée), quantifier le risque résiduel et faire accepter formellement ce risque par le propriétaire métier responsable, avec une date de revue définie. Un arrêt unilatéral outrepasse l'autorité du RSSI et nuit à l'entreprise. L'ignorer parce qu'il est non corrigeable est une négligence. L'omettre du registre des risques masque la responsabilité, rompt la piste d'audit et signifie que personne n'assume officiellement la décision.

Une violation chez un fournisseur est aussi votre incident : déclencher la réponse à incident pour cadrer quelles données et intégrations ont été exposées, faire tourner tous les secrets partagés, clés API et relations de confiance SSO, évaluer vos propres obligations de notification réglementaire et tenir le fournisseur à sa divulgation. Attendre passivement le fournisseur vous fait perdre le contrôle de votre propre calendrier et de vos obligations. Une résiliation publique du contrat est un effet de manche prématuré avant même de connaître votre exposition. Supposer que vous n'êtes pas touché saute précisément l'évaluation qu'attendent les régulateurs et vos clients.

Le changement manuel dans la console est une dérive de configuration : le prochain terraform apply peut annuler silencieusement le correctif, et le changement a aussi contourné la revue et l'audit. Réconciliez-le en codifiant le changement dans Terraform, en lançant plan/apply pour que le code et la réalité concordent, et en ajoutant des garde-fous contre les modifications ad hoc dans la console (accès console au moindre privilège, SCP, détection de dérive). Ne rien faire laisse une mine pour le prochain apply. Supprimer l'état Terraform est destructeur et peut orpheliner ou dupliquer des ressources. Abandonner Terraform sacrifie reproductibilité, revue et pistes d'audit.

Les règles d'engagement excluent généralement le déni de service en production, et un plantage non planifié cause un dommage réel à l'activité et peut annuler la mission. Vérifiez d'abord le périmètre ; si une preuve de concept destructrice n'est pas autorisée, prouvez la vulnérabilité par des moyens plus sûrs et documentez clairement l'impact probable. Lancer l'exploit pour une capture d'écran est imprudent. Le lancer à répétition pour des « métriques de fiabilité » multiplie la panne. Le passer sous silence cache au client un risque sérieux et exploitable.

Les missions professionnelles se terminent par un nettoyage complet et un inventaire des artefacts, pour ne pas laisser de nouvelle surface d'attaque ni brouiller l'environnement du client. Laisser des shells ou des comptes au client à trouver est négligent et dangereux — un vrai attaquant pourrait les réutiliser. Conserver une porte dérobée « pour la prochaine fois » est contraire à l'éthique et probablement illégal. Supprimer vos propres journaux d'activité détruit la piste d'audit dont le client a besoin pour valider le test et reconstituer ce que vous avez fait.

Découvrir une intrusion active est une urgence hors bande : les règles d'engagement doivent définir une procédure d'escalade, alors déclenchez-la immédiatement, préservez les preuves et évitez de contaminer un incident en cours. Continuer à tester peut interférer avec le vrai attaquant ou détruire les preuves mêmes dont les intervenants ont besoin. Tenter d'expulser l'attaquant vous-même est hors périmètre, risqué et peut l'alerter. Attendre le rapport final pourrait signifier des jours de violation continue et de perte de données.

Les tests d'ingénierie sociale doivent rester dans des prétextes convenus et éthiques : assez réalistes pour être utiles, mais sans coercition, sans usurper une autorité ni exploiter des situations personnelles ou médicales. Une réinitialisation générique de mot de passe IT convenue dans les règles d'engagement est acceptable. Se faire passer pour l'enfant malade d'un vrai employé ou menacer quelqu'un de licenciement cause un véritable préjudice psychologique. Se faire passer pour les forces de l'ordre usurpe une autorité et est souvent illégal, même avec une mission signée.

Prouvez la vulnérabilité sans nuire au client ni accumuler ses données : montrez que vous pouvez lire des données arbitraires via la version de la base, le schéma ou un seul échantillon anonymisé, puis arrêtez-vous. Extraire l'intégralité des données personnelles crée une responsabilité de notification de violation et de traitement pour les deux parties. Supprimer une table est destructeur et dépasse de loin la preuve de concept. Chiffrer la base et exiger une prime, c'est de l'extorsion, pas un test : c'est un délit, pas un constat.

L'autorisation définit la mission : tester hors du périmètre convenu est potentiellement illégal et viole les règles d'engagement, aussi tentante que soit la cible. Documentez ce que vous avez vu, arrêtez-vous et obtenez l'accord écrit du client avant d'aller plus loin. Exploiter pour « plus de constats » ne justifie jamais un accès non autorisé. L'exploiter discrètement en pensant ne pas être pris est à la fois contraire à l'éthique et un délit, et étendre le périmètre vous-même prive le client de son consentement éclairé.

Un rapport utile pousse à la remédiation : classez par risque métier (probabilité × impact), mettez en avant les chaînes d'exploitation qui mènent à une compromission critique et donnez des correctifs actionnables pour chaque constat. Le classement alphabétique enterre l'essentiel sous ce qui commence par « A ». Le plus long écrit d'abord récompense le verbiage plutôt que la gravité. Supprimer les constats faibles cache un risque réel et les motifs dont le client a besoin pour la défense en profondeur, le laissant avec une image faussement rassurante.

Une RCE non authentifiée sur un serveur exposé sur Internet relève de l'urgence : réduisez la fenêtre d'exposition par un déploiement testé, en staging ou progressif, et ajoutez des contrôles compensatoires (restreindre l'accès, règles WAF) en attendant. Attendre la fenêtre trimestrielle laisse un trou exploitable comme un ver ouvert des semaines. Patcher à l'aveugle en production en heures ouvrées sans test risque une panne et un rollback raté. Se fier au pare-feu périmétrique ne sert à rien — le service est déjà exposé et l'exploit n'a besoin d'aucun identifiant.

Les dirigeants sont précisément les comptes que veulent les attaquants (BEC, fraude au virement), donc les exempter inverse le modèle de risque. Résolvez la friction, pas le contrôle : déployez des passkeys/FIDO2 résistants au phishing, plus rapides que les codes. Céder à la dérogation détruit la crédibilité du programme et laisse vos comptes de plus grande valeur sans protection. Abandonner le projet MFA, c'est renoncer à un contrôle de premier ordre. L'activer en douce dans leur dos détruit la confiance et la responsabilité.

Les données sensibles ne devraient jamais atteindre les journaux : masquez ou caviardez à la source d'abord pour arrêter l'hémorragie, puis remédiez aux journaux existants et resserrez les accès. PCI DSS interdit de stocker ainsi des PAN complets et des CVV, et les mots de passe ne devraient jamais être journalisés. Des journaux « internes » restent une cible de choix. Chiffrer ou restreindre l'accès au stockage laisse quand même des secrets en clair dans les journaux, accessibles à quiconque a un droit de lecture — sauvegardes, pipelines SIEM et administrateurs les voient tous.

Le NIST AI Risk Management Framework (AI RMF 1.0) est un cadre volontaire et fondé sur le risque pour gouverner une IA digne de confiance tout au long de son cycle de vie. Son cœur est constitué de quatre fonctions : Govern (culture, politique, responsabilité — et elle traverse les autres), Map (contexte et identification des risques), Measure (évaluer et suivre les risques) et Manage (prioriser et répondre). Il définit aussi des caractéristiques de fiabilité — valide et fiable, sûr, sécurisé et résilient, responsable et transparent, explicable, respectueux de la vie privée et équitable. Il complète des listes techniques comme l'OWASP LLM Top 10 au niveau du programme.

Les contrôles se classent de deux façons. Par type : administratif (politiques, formation, procédures), technique/logique (pare-feu, MFA, chiffrement) et physique (serrures, badges, caméras). Par fonction : préventif (empêcher un événement — MFA, contrôle d'accès), détectif (repérer un événement — SIEM, IDS, journaux d'audit), correctif (réparer après — restauration de sauvegarde, correctif), dissuasif (décourager — bannières d'avertissement) et compensatoire (une alternative quand le contrôle principal n'est pas faisable). La défense en profondeur superpose ces contrôles pour qu'aucune défaillance isolée ne mène à une compromission.

L'article 5 du GDPR pose sept principes : licéité/loyauté/transparence, limitation des finalités, minimisation des données, exactitude, limitation de la conservation, intégrité et confidentialité, et responsabilité. En cas de violation de données personnelles, le responsable du traitement doit notifier l'autorité de contrôle compétente sans retard injustifié et, si possible, dans les 72 heures après en avoir pris connaissance (article 33). Si la violation est susceptible d'engendrer un risque élevé pour les personnes, le responsable doit aussi notifier les personnes concernées sans retard injustifié (article 34).

La gouvernance est la façon dont la direction fixe le cap, définit la responsabilité et aligne la sécurité sur les objectifs métier — les politiques, les rôles et la supervision qui disent à quoi ressemble « le bon niveau ». La gestion des risques est le processus d'identification, d'évaluation, de traitement et de surveillance des menaces pesant sur ces objectifs. La conformité consiste à démontrer le respect des obligations — lois, règlements, contrats et politiques internes. La gouvernance pilote les décisions de risque ; le risque détermine les contrôles nécessaires ; la conformité prouve que ces contrôles répondent aux normes exigées. La conformité est un résultat d'une bonne GRC, pas un substitut à la sécurité.

HIPAA (la loi américaine Health Insurance Portability and Accountability Act) protège les Protected Health Information (PHI). La Privacy Rule encadre l'utilisation et la divulgation des PHI ; la Security Rule s'applique aux PHI électroniques (ePHI) et exige trois catégories de garanties — administratives, physiques et techniques. Elle s'applique aux covered entities (prestataires, régimes de santé, chambres de compensation) et aux business associates qui traitent des PHI pour leur compte, liés par des Business Associate Agreements. La Breach Notification Rule fixe les obligations de notifier les personnes, le HHS et parfois les médias.

ISO/IEC 27001 spécifie les exigences d'un Information Security Management System (ISMS) : un cadre descendant et fondé sur le risque, fait de politiques, de processus, de rôles et d'amélioration continue (Plan-Do-Check-Act) qui régit la manière dont une organisation gère la sécurité de l'information. L'Annexe A est un catalogue de contrôles de référence. On ne les applique pas tous aveuglément — on mène une analyse des risques, on décide quels contrôles sont nécessaires, et on documente les décisions d'inclusion/exclusion avec justification dans une Statement of Applicability (SoA).

Le NIST Cybersecurity Framework organise les résultats de cybersécurité en fonctions principales. Dans le CSF 2.0, il y en a six : Govern (la nouvelle fonction faîtière pour la stratégie, les rôles, les décisions de risque et la supervision), Identify (comprendre les actifs et les risques), Protect (garanties pour limiter l'impact), Detect (repérer les événements), Respond (agir sur les incidents) et Recover (restaurer les capacités). Elles ne sont pas strictement séquentielles — elles fonctionnent en continu et décrivent ensemble un cycle de vie complet de gestion du cyber-risque.

PCI DSS (Payment Card Industry Data Security Standard) est une norme de sécurité maintenue par le PCI Security Standards Council qui s'applique à toute organisation qui stocke, traite ou transmet des données de titulaires de cartes. Elle s'organise autour d'objectifs de contrôle couvrant un réseau sécurisé, la protection des données stockées, la gestion des vulnérabilités, un contrôle d'accès fort, la surveillance/les tests et une politique de sécurité de l'information. Le périmètre est tout ce qui se trouve dans le cardholder data environment (CDE) — donc la segmentation, la tokenisation et le fait de ne pas stocker de données inutiles sont les principaux moyens de le réduire.

Traitez la sensibilisation comme un changement de comportement, pas comme une case à cocher annuelle. Rendez-la basée sur les rôles (un développeur a besoin d'un contenu différent de celui de la finance), continue plutôt qu'un diaporama une fois par an, et ancrée dans des risques réels comme le phishing, l'ingénierie sociale et la manipulation des données. Renforcez-la avec des simulations de phishing, des rappels au bon moment et des canaux de signalement clairs. Mesurez les résultats — taux de signalement de phishing, taux de clic, temps de signalement — pas seulement les pourcentages d'achèvement. Bâtissez une culture où les gens signalent leurs erreurs sans crainte, car la crainte étouffe le signalement.

Un KPI (Key Performance Indicator) mesure la performance d'une activité de sécurité par rapport à son objectif — par exemple le délai moyen de détection, le respect du SLA de correctifs, ou le pourcentage de systèmes avec MFA. Un KRI (Key Risk Indicator) est un signal prospectif indiquant que l'exposition au risque augmente vers un niveau inacceptable, avec un seuil censé déclencher une action — par exemple le nombre de correctifs critiques en retard, le compte d'appareils non gérés, ou les revues d'accès échouées en hausse. Les KPI vous disent comment vous vous en sortez ; les KRI vous avertissent de la direction que vous prenez.

Un rapport SOC 2 Type I évalue si les contrôles d'une organisation de services sont conçus de façon adéquate à un instant unique. Un rapport Type II va plus loin : il teste si ces contrôles ont fonctionné efficacement sur une période d'examen, généralement de 3 à 12 mois. Les deux reposent sur les Trust Services Criteria de l'AICPA — la Sécurité (les critères communs obligatoires), plus en option la Disponibilité, l'Intégrité du traitement, la Confidentialité et la Vie privée.

Traitez le risque fournisseur comme un cycle de vie, pas comme un questionnaire ponctuel. Inventoriez vos tiers et classez-les par criticité et sensibilité des données. Menez une due diligence proportionnelle au niveau — examinez les rapports SOC 2 / ISO 27001, les questionnaires de sécurité, les synthèses de pentest, ainsi que les données et accès concernés. Inscrivez les contrôles dans le contrat (exigences de sécurité, droit d'audit, notification de violation, traitement des données, sous-traitants). Surveillez ensuite en continu, pas seulement à l'onboarding, et prévoyez un processus d'offboarding propre pour révoquer les accès et récupérer ou détruire les données. Le risque de quatrième partie (sous-traitant) compte aussi.

Les revues d'accès (recertification) sont des vérifications périodiques où un propriétaire responsable confirme que l'accès de chaque personne reste justifié, et révoque ce qui ne l'est pas. Elles constituent le filet de sécurité qui détecte la dérive de privilèges, les comptes orphelins et les droits accordés pour un projet terminé. Le contrôle ne fonctionne que si un propriétaire compétent — généralement le manager ou le propriétaire de la ressource — examine réellement l'accès au lieu de le valider machinalement, et si les révocations sont appliquées.