ActualitésMacroLa conformité en cybersécurité exige des preuves continues et vérifiables

La conformité en cybersécurité exige des preuves continues et vérifiables

Auteur: Blocktelegraph·

Points clés

  • •Les professionnels de la cybersécurité recommandent d'associer chaque contrôle à des preuves générées par machine, telles que des journaux, des résultats d'analyse et des enregistrements de correctifs horodatés, car les auditeurs accordent plus de poids aux preuves en direct qu'aux documents de politique.
  • •Les experts recommandent de collecter les preuves d'audit en continu dans le cadre des opérations de sécurité courantes, car attendre la demande d'un audit oblige les équipes à passer plus de temps à reconstituer les enregistrements.
  • •Une équipe de néobanque a obtenu la certification SOC 2 en 2025 en divisant son backend en microservices à périmètres de données étroits, en transmettant les données d'identité directement aux fournisseurs KYC et en utilisant une infrastructure en tant que code versionnée pour la configuration cloud.
  • •L'attribution de responsables nommés et d'échéances aux constats de remédiation, avec la priorité donnée aux problèmes urgents comme les permissions et le chiffrement, a aidé une organisation à transformer un arriéré de risques en programme auditable pour un audit SOC 2 Type II.
  • •Les tests de résience opérationnelle par exercices de sauvegarde, mises en situation et analyses brutes de dépôts ont produit des preuves d'audit crédibles ; un échec de restauration documenté a renforcé la confiance de l'auditeur car il prouvait qu'un test réel avait eu lieu.
La conformité en cybersécurité exige des preuves continues et vérifiables

La conformité en cybersécurité ne s'obtient pas par les seules politiques. Elle exige des preuves vérifiables, une responsabilité claire et des contrôles qui fonctionnent dans le cadre du travail quotidien d'une organisation. Les professionnels de la cybersécurité et de la conformité décrivent des approches incluant la collecte continue des enregistrements d'audit, l'attribution de responsables à la remédiation, la restriction de l'accès aux données, l'automatisation des contrôles de conformité et le test de la résilience opérationnelle avant que les régulateurs ou les auditeurs ne demandent des preuves.

Prioriser des défenses vérifiables après une faille

Après la faille de St. Paul, Edith Forestal a préparé un dossier de conformité pour les régulateurs municipaux, fondé sur les actions à court terme décrites dans son analyse. Ce dossier documentait l'application de l'authentification multifacteur (MFA) résistante au hameçonnage pour la messagerie, le VPN et les rôles d'administrateur ; un inventaire minimal des actifs et des identités ; et la segmentation des services critiques, notamment les finances et les opérations d'urgence.

Il comprenait également des preuves de sauvegardes hors ligne immuables et un test de restauration réussi pour un système critique pour la mission. Des journaux centralisés ont été transmis à un système de gestion des informations et des événements de sécurité (SIEM) avec des déte du vol d'identifiants et des comportements administrateur inhabituels.

Forestal a indiqué que l'approche donnait la priorité aux contrôles à la fois à fort impact et vérifiables. Des référentiels de configuration, des résultats de tests et des sorties de journalisation ont été présentés pour répondre aux exigences de l'auditeur.

— Edith Forestal, CISSP, CISM, CEH, fondatrice et spécialiste en cybersécurité, Forestal Security

Collecter les preuves de revue dans le cadre des opérations courantes

Udaya Bhaskar Vemuri a déclaré que les preuves d'audit devraient être créées via les processus de sécurité habituels plutôt qu'assemblées juste avant un audit. Son approche comprenait la tenue d'enregistrements des revues de sécurité, des résultats d'analyses, des tickets de remédiation, des décisions d'acceptation des risques et des preuves que les problèmes étaient suivis jusqu'à leur clôture.

Ces enregistrements ont aidé à démontrer que les contrôles n'étaient pas seulement documentés mais réellement utilisés en pratique. Lors d'un audit, a précisé Vemuri, la réponse doit rester simple : expliquer le contrôle, présenter les preuves à l'appui et identifier toute exception ou tout point non résolu.

Sa principale leçon était que la préparation est plus facile lorsque les preuves sont collectées en continu. Si les équipes attendent qu'un auditeur demande des enregistrements spécifiques, elles passent généralement plus de temps à reconstituer ce qui s'est passé. Vemuri a souligné que ses commentaires reflétaient ses opinions professionnelles personnelles et non celles de son employeur.

— Udaya Bhaskar Vemuri, analyste principal en sécurité applicative

Associer les contrôles à des preuves générées par machine

Ace Zhuo a déclaré que les auditeurs accordent plus de poids aux journaux et autres preuves en direct qu'aux longs documents de politique. Lors d'une revue informatique d'un client courtier exploitant MT5 sur l'infrastructure TradingFXVPS, l'équipe a fait parcourir à l'auditeur les preuves en direct plutôt que d'expliquer un manuel de politiques détaillé.

Les preuves comprenaient des journaux d'accès immuables pour toutes les connexions administrateur au serveur de trading, l'application du MFA sur chaque compte et des enregistrements de correctifs horodatés montrant que toutes les mises à jour critiques avaient été publiées en 72 heures. Les historiques de modifications des règles de pare-feu ont été exportés et associés aux numéros de tickets correspondants.

L'équipe a également présenté les résultats de son dernier exercice de sauvegarde, dont une restauration qui avait échoué et les mesures prises pour la corriger. Zhuo a indiqué que cet échec avait renforcé la confiance de l'auditeur car il démontrait qu'un test réel, et non un simple exercice simulé, avait eu lieu.

Sa méthode de préparation aux audits consistait à associer chaque contrôle à des preuves générées par machine le plus tôt possible. Il a également recommandé de considérer un contrôle comme échoué si ses preuves ne pouvaient être récupérées en moins de cinq minutes à la demande d'un auditeur.

— Ace Zhuo, PDG ; ventes et marketing, expert en technologie et finance, TradingFXVPS

Attribuer des responsables et des échéances à la remédiation

En préparation d'un audit SOC 2 Type II, Ankit Sarawagi a dirigé un effort visant à transformer un arriéré de constats de risques en un programme de remédiation auditable. Chaque constat a reçu un responsable nommé et une échéance. Les problèmes urgents, notamment les et le chiffrement, ont été priorisés, tandis que les corrections moins prioritaires étaient planifiées dans des sprints mensuels.

Ce processus a permis à l'organisation de montrer aux auditeurs qui avait agi, ce qui avait été modifié et le statut de chaque constat. Il a également réduit la préparation de dernière minute et permis à l'équipe de démontrer une progression constante pendant l'audit.

— Ankit Sarawagi, conservateur, CFO Matrix

Tracer l'accès et l'utilisation des informations par les outils d'IA

Shubham Paikrao a déclaré que l'une de ses leçons de conformité les plus importantes provenait de l'évaluation de la question de savoir si un assistant IA utilisé pour trier les tickets pouvait compromettre la conformité en accédant à des données réglementées de manière imprévue. La documentation existante avait été rédigée pour des humains prenant des décisions, et non pour un modèle notant des informations et suggérant des actions en arrière-plan.

Plutôt que de traiter l'outil comme une application ordinaire et de rassembler des preuves standard de sa sécurité, l'équipe l'a évalué comme un nouveau prestataire avec son propre profil de risque, à l'instar d'une interface de programmation d'applications (API) tierce récupérant des données clients.

Paikrao a examiné des journaux montrant exactement quelles informations l'outil ingérait, ce qu'il pouvait consulter sans agir, et comment ces activités correspondaient à la politique de classification des données de l'organisation. Il a également créé un court diagramme de flux de données pour l'auditeur. Les pratiques de réentraînement impliquant des données envoyées au modèle ont été signalées, et l'équipe a soulevé ses préoccupations en se référant aux termes du contrat.

La question pour les organisations utilisant l'IA, a précisé Paikrao, n'est pas seulement de savoir si leurs contrôles fonctionnent. Elles doivent aussi pouvoir prouver ce que leurs outils d'IA ont fait des données qu'elles ont traitées et comprendre leurs propres opérations d'IA. Les auditeurs ne s'attendent pas nécessairement à des réponses parfaites, a-t-il ajouté, mais ils attendent des organisations qu'elles connaissent leur visibilité sur les contrôles et les outils utilisés au quotidien.

— Shubham Paikrao, analyste en sécurité de l'information

Utiliser des périmètres de données étroits pour SOC 2

En 2025, l'équipe d'Evgeny Leonov a obtenu la certification SOC 2 pour une application de néobanque servant le marché américain. L'organisation a traité la revue comme un problème d'architecture et exigé que chaque contrôle laisse des preuves qu'un auditeur pouvait suivre depuis l'exigence jusqu'au système en fonctionnement.

Le backend a été divisé en microservices avec des bases de données séparées et des périmètres de données étroits. L'équipe de support ne pouvait pas consulter les informations financières, tandis que le service de transactions recevait les détails de paiement sans le contexte personnel complet de l'utilisateur. L'entreprise ne conservait pas d'images de passeport ni d'autres données d'identité sur ses propres serveurs ; ces informations étaient transmises directement au fournisseur KYC et à la banque.

Les développeurs devaient vérifier leur identité et demander l'accès aux services auprès du DevOps. L'accès en production restait entre les mains DevOps et des responsables d'équipe. Les sauvegardes et la réplication Cloud SQL assuraient la récupération.

L'entreprise a également réduit la quantité d'infrastructure personnalisée dans le périmètre d'audit. Bond gérait les fonctions bancaires, Persona et Sardine les vérifications d'identité et de fraude, et Auth0 l'authentification. Chaque prestataire avait une responsabilité définie, ce qui facilitait la démonstration de la propriété.

Pour la configuration cloud, l'équipe a utilisé Terraform et Terragrunt. Leonov a indiqué qu'un historique des modifications versionné et révisé constituait une preuve plus solide qu'un environnement configuré manuellement. Les services gérés certifiés peuvent également réduire le temps de préparation des revues SOC 2, HIPAA et RGPD lorsque leurs preuves de contrôle correspondent aux exigences du système.

L'équipe a réussi sa certification SOC 2, la banque devant toutefois compléter une certification distincte, avec son propre ensemble de contrôles et ses responsabilités. Leonov a résumé l'approche ainsi : versionner l'infrastructure, minimiser la garde des données, définir les responsables des accès et expliciter le périmètre de conformité de chaque prestataire.

— Evgeny Leonov, directeur technique, Ronas IT | Software Development Company

Automatiser les enregistrements de conformité continue

Mark Sternig a déclaré que la conformité doit pouvoir être démontrée un jour ordinaire plutôt qu'assemblée durant la semaine précédant une revue. Son principe directeur est simple : tout ce qui est fait en interne doit refléter ce qu'un réviseur externe examinerait, de sorte que démontrer la conformité devient une visite guidée d'un système existant plutôt qu'un effort pour construire un récit.

Les contrôles doivent se documenter eux-mêmes. Plutôt que de compter sur des employés pour capturer des captures d'écran avant une revue, les systèmes doivent rendre compte en continu et horodaté, de sorte qu'une dérive de configuration soit détectée le jour où elle survient, et non la veille de l'examen d'un auditeur.

Sternig a indiqué que son organisation avait auparavant besoin de plusieurs jours pour collecter les journaux de différents systèmes, reconstituer les incidents et rédiger des comptes rendus. Après avoir appliqué l'IA à ce processus, un travail qui prenait des jours a été réduit à environ 30 minutes, avec des résultats cohérents et documentés.

Selon lui, l'objectif n'était pas de supprimer le jugement humain, mais d'automatiser la collecte de preuves et la surveillance tout en confiant les décisions aux personnes. Les réviseurs vérifient plus facilement des preuves visibles et reproductibles qu'une explication ponctuelle.

— Mark Sternig, directeur technique, Focus

Appliquer l'authentification des e-mails en temps réel

Al Iverson a déclaré que les organisations démontrant leur conformité en matière de sécurité des e-mails devraient montrer que les politiques d'authentification sont appliquées en temps réel plutôt que de se limiter à des enregistrements DNS statiques. Montrer que chaque expéditeur autorisé est pris en compte et que les messages non autorisés sont activement bloqués sous des politiques DMARC appliquées fournit une preuve directe que le contrôle fonctionne.

L'usurpation d'e-mail et le spoofing de domaine sont des points de contrôle d' importants dans les secteurs réglementés comme les services financiers et la santé. Les régulateurs veulent vérifier que les protections couvrent tous les domaines d'entreprise et les services d'envoi tiers.

Chez Valimail, a précisé Iverson, l'entreprise automatise la gestion hébergée de DMARC, SPF et DKIM. L'objectif est d'offrir une protection continue des domaines et une visibilité sur les flux de messagerie autorisés sans obliger les équipes à mener des audits manuels.

— Al Iverson, responsable de la recherche sectorielle et de l'engagement communautaire, ValiMail

Démontrer l'assurance opérationnelle lors d'un examen

Yousuf Rizvi a indiqué que son cabinet conseille des entreprises fintech et crypto sur les contrôles financiers et la préparation réglementaire. À titre d'exemple, le cabinet a préparé un client à un examen de transmetteur de fonds d'État dans lequel les questions de cybersécurité et de sécurité de l'information étaient aussi détaillées que celles portant sur le bilan.

Le client disposait déjà d'une politique de sécurité de l'information, d'une politique de contrôle d'accès et d'un plan de réponse aux incidents. Ce qui lui manquait, c'était la preuve que ces politiques fonctionnaient. L'équipe a donc construit une piste de preuves avant que l'examinateur ne la demande.

Chaque politique a été associée à un responsable du contrôle, un calendrier de tests et un enregistrement montrant que le contrôle avait fonctionné. Les revues d'accès documentaient qui avait examiné quel accès et quand. Le MFA était étayé par des captures de configuration démontrant son application, et non par une simple déclaration d'existence. Le plan de réponse aux incidents était associé à un exercice sur table et à une analyse post-mortem d'un véritable incident mineur.

À l'arrivée de l'examinateur, l'entreprise a présenté un dossier de preuves organisé par contrôle et expliqué comment chacun avait été testé. Les questions qui prolongent habituellement un examen pendant des semaines ont été traitées dès la première séance, les preuves ayant déjà été assemblées.

Rizvi a souligné que les régulateurs veulent savoir si un contrôle a fonctionné, qui en est responsable et comment l'organisation saurait s'il échouait. Répondre à ces trois questions avec des documents plutôt qu'avec des explications transforme l'examen en revue plutôt qu'en enquête.

— Yousuf Rizvi, CPA, associé, Ridgeway Financial Services

Tester le consentement des sites web avant une inspection

Taha Farhane, anciennement auditeur principal en technologie, processus et confidentialité des données, a déclaré que les organisations qui réussissent facilement les revues tendent à présenter des preuves plutôt que des politiques. Une politique peut affirmer que le consentement est obtenu, mais les preuves doivent montrer ce qu'un visiteur donné a vu, le choix qu'il a fait et quelles balises se sont déclenchées ensuite.

Farhane a indiqué que les audits étaient plus courts lorsque les équipes pouient produire ces enregistrements pour un échantillon choisi par l'auditeur. Les revues duraient souvent plus longtemps et aboutissaient à des constats lorsque les entreprises ne fournissaient qu'un PDF de politique et une capture d'écran d'un bandeau de consentement.

En développant un logiciel de consentement pour des entreprises du Golfe soumises à la loi saoudienne sur la protection des données, Farhane a commencé à tester les sites web en direct de l'extérieur, comme le ferait un régulateur. Le processus consistait à charger une page d'accueil dans un navigateur vierge et à vérifier ce qui se déclenchait avant tout clic du visiteur.

Le test a été mené sur 1 556 boutiques en ligne saoudiennes. Selon Farhane, 60 % exécutaient des traceurs sans afficher de bandeau de consentement, tandis que 68 % chargeaient le traçage avant que les visiteurs ne fassent un choix. Il a précisé que le test prenait 30 secondes et recommandé aux organisations de tester leurs propres sites, de conserver les enregistrements de consentement et d'utiliser ces enregistrements pour appuyer un audit fondé sur l'échantillonnage plutôt que sur la dispute.

— Taha FARHANE, PDG, Arqam360

Fournir les résultats bruts d'analyse des dépôts

Timur Rakhmatullin a décrit un audit de sécurité interne chez Softline, qui gère une plateforme de données GCP pour plus de 1 500 comptes clients. L'auditeur demandait la preuve que chaque dépôt disposait de nomenclatures logicielles (SBOM) appropriées, d'aucun CVE connu dans les dépendances et de chaînes de licences propres. La revue couvrait plus de 30 dépôts.

Rakhmatullin avait créé un outil open source npm nommé ai-project-audit pour analyser la conformité des licences, les vulnérabilités de sécurité et l'exhaustivité des SBOM. Il a exécuté l'outil sur tous les dépôts en une nuit et disposait de rapports structurés dès le lendemain matin. Les rapports contenaient des horodatages, des arbres de dépendances et des identifiants de vulnérabilités.

Il a déclaré que les auditeurs devraient recevoir des journaux bruts plutôt qu'un résumé indiquant que tout semblait satisfaisant. Le dossier fourni à l'auditeur comprenait des identifiants CVE avec dates, des versions de dépendances, des résultats d'analyse JSON bruts, une SBOM générée et une liste de problèmes signalés pour chaque dépôt. Plusieurs dépendances transitives obsolètes ont été identifiées et corrigées avant l'audit.

La période de préparation est passée d'environ deux semaines à trois jours. L'essentiel du temps restant a été consacré à la correction des problèmes signalés plutôt qu'à leur recherche.

— Timur Rakhmatullin, ingénieur logiciel senior, Softline Solutions

Utiliser les exercices sur table pour démontrer la résilience

Lors d'une revue de conformité, la préparation de la réponse aux incidents a été démontrée par les preuves produites par un exercice sur table plutôt que par une présentation soignée. Le dossier comprenait le scénario, les rôles des participants, le journal des décisions, les brouillons de communication, les leçons apprises et les tickets de suivi.

Sherif Koussa a mis l'accent sur les changements apportés après l'exercice, notamment des seuils d'escalade clarifiés et une meilleure collecte des journaux applicatifs. Les auditeurs voient souvent des plans qui se lisent bien mais n'ont jamais été testés dans l'incertitude. Un exercice mené à bien montré si les équipes techniques, juridiques et d'ingénierie pouvaient prendre des décisions coordonnées avec des informations incomplètes.

L'exercice a également démontré l'amélioration continue, ce qui, selon Koussa, peut être plus significatif qu'une affirmation de perfection. Les meilleures preuves d'audit rendent la résilience visible par un comportement reproductible, un apprentissage documenté et des changements opérationnels mesurables.

— Sherif Koussa, PDG, Software Secured

Concevoir les protections avant le déploiement

Oscar Moncada a déclaré que son entreprise a conçu pour la conformité avant d'écrire le code de sa plateforme de coûts et de sécurité cloud. Comme l'entreprise prévoyait de viser SOC 2, elle a appliqué les bonnes pratiques de sécurité dès le départ. Au début de l'audit, l'organisation documentait des contrôles déjà intégrés à son infrastructure plutôt que de les ajouter après coup.

L'entreprise a également préparé ses politiques de sécurité bien avant l'audit, évitant une précipitation pour produire la documentation. Pour les organisations disposant déjà d'un produit, Moncada a recommandé d'appliquer les pratiques de sécurité à chaque nouvelle fonctionnalité et composant d'infrastructure plutôt que de tout changer d'un coup. Il a également recommandé d'utiliser un outil identifiant en continu les lacunes de sécurité et de conformité inconnues dans les environnements cloud.

Pour les clients de Stratus10, la partie la plus difficile de SOC 2 est souvent la remédiation des lacunes cachées dans l'infrastructure AWS existante : rôles IAM largement accordés et jamais revus, journalisation non centralisée et chiffrement incohérent entre les services. Identifier ces lacunes tôt permet d'éviter des semaines de remédiation en cours d'audit.

— Oscar Moncada, cofondateur et PDG, Stratus10

Lier les exigences aux revues régulières

Au cours de son processus d'enregistrement FCA, Michael Foote a déclaré avoir appris que la documentation était essentielle pour démontrer la conformité. Les régulateurs voulaient des preuves de la protection des données clients plutôt que des promesses de pratiques futures.

Son organisation a constitué une bibliothèque de conformité associant chaque contrôle de sécurité à l'exigence réglementaire spécifique qu'il couvrait. L'entreprise a également mené des audits internes trimestriels et consigné chaque incident de sécurité, y compris les plus mineurs.

Lorsqu'un auditeur a examiné les systèmes, l'entreprise a pu présenter un historique d'amélioration continue plutôt que de tenter de démontrer sa conformité à la dernière minute. Foote a indiqué que cette approche a réduit le travail de préparation et démontré l'attention portée à la protection des données dans la gestion de l'argent des clients.

— Michael Foote, fondateur, Quotegoat

Traiter la cybersécurité comme des opérations quotidiennes

Dean Rotchin a déclaré que BLACKJET a construit son cadre de cybersécurité autour des audits de certification Part 135 et traite la sécurité des données de la même manière systématique que la maintenance des aéronefs. Selon son expérience, les régulateurs attachent plus d'importance aux processus reproductibles qu'à la technologie spécifique.

L'entreprise a documenté les contrôles d'accès, les procédures de réponse aux incidents et les évaluations des prestataires tiers. Lors son audit le plus récent, elle a présenté ses systèmes de réservation chiffrés aux auditeurs et expliqué comment les données de paiement des clients étaient séparées des données d'exploitation des vols.

Rotchin a souligné que la cybersécurité doit être présentée comme une discipline opérationnelle intégrée aux flux de travail quotidiens et non comme une responsabilité strictement informatique. L'entreprise tient des journaux détaillés et mène des audits internes trimestriels. Il a également insisté sur la construction de la documentation en même temps que des systèmes et la formation de chaque membre de l'équipe, car tout employé peut devenir une source de vulnérabilité.

— Dean Rotchin, PDG de BLACKJET, BlackJet

Établir des protections défendables dès le départ

Roman Vasilenko a déclaré que l'exploitation d'une plateforme fintech dans le secteur de la formation crypto a obligé l'entreprise à traiter la sécurité dès le début, la confiance des utilisateurs étant fondamentale et le secteur faisant l'objet d'une surveillance réglementaire.

Son approche privilégiait des preuves concrètes. L'entreprise a tenu des enregistrements détaillés des pratiques de traitement des données, des protocoles de chiffrement, des contrôles d'accès et des procédures de réponse aux incidents. Elle a également poursuivi la conformité SOC 2 avant qu'elle ne soit obligatoire pour l'activité, utilisant l'audit pour formaliser les pratiques et identifier les lacunes.

La conformité a été intégrée au processus de développement par des revues de sécurité régulières, des mises à jour des dépendances et la formation des employés. Lorsque les auditeurs ont demandé comment l'entreprise restait à jour, elle a pu montrer un processus en cours plutôt qu'une évaluation ponctuelle.

Vasilenko a également déclaré que l'entreprise a été transparente sur les situations où elle a privilégié la rapidité à la perfection théorique, en expliquant pourquoi ces compromis avaient du sens pour une startup autofinancée. Il a décrit la conformité non pas comme la réussite d'un audit, mais comme la construction de systèmes que l'organisation serait prête à défendre publiquement.

— Roman Vasilenko, responsable de la publicité display, Vasilenko AdOps

Intégrer les politiques dans le code d'infrastructure

Sudhanshu Dubey a déclaré que les organisations peuvent améliorer leur préparation réglementaire en passant d'une préparation réactive à une architecture continue et automatisée de conformité en tant que code. Dans son travail sur des plateformes financières complexes, la collecte manuelle de journaux et de captures d'écran a été remplacée par des politiques de conformité intégrées directement aux modèles d'infrastructure en tant que code.

En utilisant le NIST Cybersecurity Framework (NIST CSF) et SOC 2 comme référentiels, l'équipe ne s'est plus appuyée sur des vérifications manuelles lorsque les auditeurs demandaient la vérification des politiques de gestion des identités et des accès ou de chiffrement. Elle a plutôt présenté l'historique versionné du dépôt et des moteurs automatisés d'application des politiques qui bloquaient en temps réel le provisionnement de ressources non conformes.

Un tableau de bord de télémétrie en direct a fourni la preuve de l'état de l'environnement au-delà de la date de l'évaluation. Dubey a indiqué que traiter la conformité comme un exercice de documentation ponctuel expose les organisations à la dérive de configuration entre les cycles d'audit. L'intégration des règles dans les pipelines de livraison logicielle rend la posture de sécurité vérifiable et capable de corriger automatiquement certains problèmes.

— Sudhanshu Dubey, delivery manager et architecte de solutions d'entreprise, Errna

Bâtir la confiance par la préparation et la transparence des équipes

Corina Tham a déclaré que, lorsqu'elle travaillait avec un cabinet d'audit potentiel pour la revue de sécurité et de conformité de CheapForexVPS par un partenaire de paiement, elle expliquait d'abord comment les données clients circulaient dans l'entreprise et qui pouvait y accéder. Elle expliquait également la perte commerciale potentielle en cas de fuite de ces données. Cela donnait aux contrôles décrits dans le rapport d'audit une justification opérationnelle claire.

Tham a également préparé le personnel de première ligne et le support. Les auditeurs peuvent tester les employés qui répondent aux tickets 24h/24 pour déterminer s'ils savent comment traiter une demande de connexion suspecte. Une réponse assurée et cohérente d'un employé junior constitue une preuve plus forte de la culture de sécurité de l'organisation que de nombreux documents de politiques et procédures.

Lorsque des contrôles présentaient des lacunes, Tham documentait la remédiation requise, identifiait qui la réaliserait et fixait une échéance. Elle a également confirmé que la finance avait approuvé un budget pour les travaux nécessaires.

Son objectif était de faire de la conformité une relation transparente avec l'entreprise plutôt qu'un test à réussir. Cette approche a rendu le processus plus serein, plus rapide et plus collaboratif.

— Corina Tham, directrice des ventes, du marketing et du développement commercial, CheapForexVPS

L'article source est disponible sur BlockTelegraph.