Transcription

• Speaker #0

  Mais qui est responsable de tes photos de vacances ? Toi ou Apple ? Ou Google Photos ? Ou OneDrive ? Si tu hésites, tu ne fais probablement pas la différence entre un data owner et un data custodienne. Et pourtant, cette confusion est présente dans énormément d'entreprises, et elle est à l'origine de beaucoup de problèmes de gouvernance. Bienvenue dans Compliance without coma, le podcast qui parle de cybersécurité, de gouvernance et d'ISO 27001. Sans te plonger dans le coma, je suis Fabrice De paepe et depuis plus de 20 ans, j'accompagne des organisations à mettre en place des systèmes de management qui fonctionnent vraiment. Et aujourd'hui, on va répondre à une question qui paraît simple, mais qui change complètement la manière dont on gère l'information. Imaginons que je prenne des photos de mes vacances. Qui décide quelles photos je garde ? Moi, qui décide avec qui je les partage ? Moi, qui décide de les supprimer ? Moi, qui décide si elles sont importantes ou non ? Encore moi. Je suis donc le data owner. Le data owner est celui qui décide de l'utilisation de la donnée. Il connaît sa valeur, il connaît son importance, et il décide ce qu'on peut en faire. Par contre, ces photos sont stockées sur iCloud, qui sauvegarde les disques. Apple. Qui protège les serveurs ? Apple. Qui chiffre les data centers ? Apple. Bon, dit comme ça, c'est un peu raccourci, mais garde l'idée en tête. Qui remplace un disque défectueux ? Apple. Qui surveille les infrastructures ? Apple. Apple est alors le data custodian. Le custodian n'est pas propriétaire des données. Il les protège, il les héberge, il les sauvegarde, il les restaure si nécessaire, mais il ne décide jamais de leur utilisation, enfin en principe. Et attention, être data owner ne signifie pas que tu possèdes les données. Cela signifie que tu es responsable des décisions concernant ces données. Tu décides de leur classification, donc leur confidentialité éventuellement, la disponibilité, l'intégrité. Tu décides combien de temps elles doivent être conservées, qui peut y accéder, et lorsqu'un risque doit être accepté, c'est généralement toi qui devras prendre cette décision. Je te prends un exemple en entreprise. Un dossier d'employé. Qui décide combien de temps il doit être conservé ? On va dire les ressources humaines et le DPO. Qui décide qui peut consulter les évaluations ? Les ressources humaines. Qui décide si certains documents sont confidentiels ? Les ressources humaines. Donc les RH sont donc le Data Owner. L'IT, lui, sauvegarde, restaure, protège, chiffre. Oui, parce qu'on dit chiffré et pas crypté. Gère les serveurs et applique les droits décidés par les RH. L'IT est donc le data custodienne. Un autre exemple, le CRM de ton entreprise. Les données des clients. Est-ce que l'IT décide si un commercial peut consulter tous les clients ? Eh bien non. Est-ce que l'IT décide combien de temps un prospect doit être conservé ? Non. Est-ce que l'IT décide qu'une donnée doit être supprimée parce qu'un client exerce son droit ? à l'effacement. Et encore non. Toutes ces décisions appartiennent au métier. L'IT met simplement en œuvre ce qui a été décidé. Et alors, spoiler alert, pavé dans la mare, combien de fois j'ai entendu et j'entends encore, l'IT est propriétaire des données. Non, l'IT est rarement propriétaire des données. L'IT, on est le gardien. Et ça change tout. Parce qu'un data custodian ne peut pas protéger correctement une donnée Merci. Si le data owner ne lui a jamais expliqué ce qu'il fallait protéger ? Comment veux-tu choisir le bon niveau de protection ? Si personne ne t'a expliqué la valeur de la donnée ? Par défaut, tu risques de mettre une protection standard, alors que certaines données mériteraient beaucoup plus, et d'autres beaucoup moins. Ça, c'est un problème de gouvernance. D'ailleurs, quand mes équipes réalisent des audits ISO 27001, on ne commence presque jamais par l'IT. Nous allons voir les RH, les achats, marketing, départements juridiques, les opérations. Les processus métiers en fin de compte. Pourquoi ? Parce que ce sont eux qui connaissent la valeur des données. L'IT connaît les serveurs, le métier connaît les infos. Et les deux doivent travailler ensemble. Alors pourquoi est-ce si important ? Parce que sinon, qui décide du temps de conservation ? Qui décide si une donnée peut être supprimée ? Qui décide qui a accès ? Qui décide du niveau de classification ? Qui accepte le risque ? Très souvent en personne, ou pire. Tout le monde pense que c'est quelqu'un d'autre. D'ailleurs, fais un petit test pour voir la maturité de ton entreprise. Demande autour de toi qui est le data owner des données RH. Puis pose la même question à 5 personnes différentes, pas au sein des RH. Si tu obtiens 5 réponses différentes, tu viens probablement de découvrir un problème de gouvernance. Mais RH, en général, c'est assez clair. Prends plutôt le département commercial. qui normalement par essence est plus compliqué car c'est ce qui est censé faire entrer de l'argent, avec un time to market treccert et des modèles qui s'adaptent au fil des mois. C'est pas si facile que ça. Alors retiens simplement ceci, le data owner répond à une question. Pourquoi cette donnée existe-t-elle ? Le data custodian répond à une autre. Comment avais-je la protégée ? Le premier connaît la valeur de la donnée, le second connaît les moyens de la protéger. Les deux sont indispensables et surtout, les deux doivent se parler. Good luck. Parce qu'une bonne donnée protégée commence toujours par une responsabilité clairement définie. Et si dans ton quotidien tu te retrouves face à une question de responsabilité, qui est le data owner, qui est le data custodian, qui décide, qui exécute, qui accepte le risque ? Ou tout simplement, tu ne sais même plus qui doit prendre la décision, c'est exactement pour ça que j'ai créé Compliance without coma un solo, tu peux me soumettre ton cas concret, une matrice racine, une architecture, une classification de l'info, une analyse de risque, ou simplement... Une décision qui te fait hésiter. L'objectif n'est pas que je décide à ta place, l'objectif est de t'aider à clarifier les rôles, à poser les bonnes responsabilités au bon endroit et à construire une gouvernance qui fonctionne réellement. Parce qu'au fond, la plupart des problèmes de sécu ne viennent pas d'un manque de techno, ils viennent d'un manque de clarté sur qui décide de quoi. Et avec l'académie, on va encore plus loin. Tu apprends à raisonner comme un consultant ou comme un ciseau, tu comprends pourquoi les rôles sont aussi importants que les contrôles. Tu apprends à distinguer la responsabilité de l'exécution et de la redevabilité. Tu développes ton jugement, plutôt que d'appliquer des modèles sans les comprendre. Et tu progresses grâce à des cas réels, ceux que je rencontre sur le terrain depuis plus de 20 ans. Parce qu'au final, une certification valide des connaissances, mais c'est ta capacité à attribuer les bonnes responsabilités aux bonnes personnes qui fera toute la différence. Le jour où quelqu'un te demandera, mais qui décide ? Et si cet épisode t'a plu, eh bien... partage-le avec un collègue qui pense encore que l'IT est propriétaire de toutes les données ou avec quelqu'un qui confond encore Data Owner et Data Custodian. Là, je viens de te t'expliquer en fait un slide. Un slide du 6ème. Un seul slide. T'imagines ? Sûr que t'en connais à la machine à café des gens qui confondent. Et si tu veux vraiment soutenir le podcast, prends 30 secondes, laisse 5 étoiles sur Spotify ou Apple Podcast s'il te plaît et va jeter un oeil à la version YouTube. La narration y est différente. Si tu le vois passer aussi sur ton fil d'actualité LinkedIn, n'hésite pas à le repartager, ça me fait toujours autant plaisir. Merci d'être toujours plus nombreux à rejoindre les Coma. On se retrouve vendredi prochain, déjà, pour un nouvel épisode de Compliance without coma. D'ici là, n'oublie jamais, la sécurité ne commence pas par une techno, elle commence par savoir qui est responsable de quoi. Prends soin de toi, Coma.