Un employé quitte l'entreprise. Quel est le contrôle pertinent côté GRC à vérifier ?

Lorsqu'une personne part, le risque n'est pas le départ — c'est l'accès qui subsiste après. Un ancien employé (ou un attaquant qui trouve le compte abandonné) disposant d'identifiants actifs vers l'e-mail, le VPN, les consoles cloud ou un système privilégié est un vecteur de compromission classique. Le contrôle GRC consiste à vérifier que tous ces accès sont retirés rapidement, et à le vérifier contre un processus défini plutôt qu'à présumer que cela a été fait.

Ce que « tous les accès » recouvre réellement

Le déprovisionnement n'est pas un simple interrupteur. Un processus de départ complet révoque les comptes d'annuaire (Active Directory / Entra ID), les sessions SSO et les connexions fédérées, les identifiants VPN et d'accès distant, les comptes privilégiés et de service/admin et, surtout, les applications SaaS tierces — dont beaucoup sont provisionnées hors de l'IT centrale et survivent à une désactivation du SSO. Tout cela doit être rapproché du processus arrivée/mobilité/départ (JML), afin qu'un flux défini et auditable précise ce qui est retiré, sous quel délai et qui l'a confirmé.

Pourquoi les mauvaises réponses échouent

« Les RH gèrent tout » est l'hypothèse qui crée des comptes orphelins : les RH possèdent l'événement d'emploi, mais le retrait technique des accès a besoin d'un propriétaire et d'une vérification — faire confiance sans contrôler laisse des failles. Garder le compte actif « au cas où » est un risque permanent et non surveillé ; un identifiant valide dormant est exactement ce que recherchent les attaquants. Désactiver seulement l'e-mail traite le système le plus visible et ignore le VPN, le cloud, le SaaS et les accès privilégiés que la personne peut encore utiliser — un correctif partiel qui paraît terminé mais ne l'est pas.

Le jugement évalué

L'intervieweur veut vous entendre raisonner en termes de cycle de vie complet de l'identité, vous voir vérifier plutôt que présumer, et comprendre la longue traîne des comptes SaaS et shadow qui échappent au SSO. Une bonne réponse évoque le rapprochement avec le processus JML, la gestion des identifiants partagés et de service (les renouveler, pas seulement les désactiver) et la capacité à prouver un déprovisionnement rapide à un auditeur — en bouclant la boucle entre l'événement RH et le retrait réel et confirmé de chaque voie d'accès.