An employee leaves the company. What's the GRC-relevant control to verify?
Short answer
Leaver risk is lingering access, so the control to verify is timely deprovisioning of every access path — directory accounts, SSO, VPN, privileged and service credentials, and third-party SaaS — reconciled against the joiner/mover/leaver (JML) process. Assuming HR handles it all without verification leaves gaps no one owns. Keeping the account active 'in case they come back' is standing, unmonitored risk. Disabling only email ignores the many other systems the person could still reach. The point is to verify access is actually and fully removed, not to trust that it was.
When someone leaves, the risk isn't the departure — it's the access that lingers after it. A former employee (or an attacker who finds the abandoned account) with live credentials to email, VPN, cloud consoles, or a privileged system is a textbook breach vector. The GRC control is to verify that all of that access is removed promptly, and to verify it against a defined process rather than assume it happened.
What "all access" actually covers
Deprovisioning is not a single switch. A complete leaver process revokes directory accounts (Active Directory / Entra ID), SSO sessions and federated logins, VPN and remote-access credentials, privileged and service/admin accounts, and crucially third-party SaaS apps — many of which are provisioned outside central IT and survive an SSO disable. All of this should be reconciled against the joiner/mover/leaver (JML) process, so there's a defined, auditable workflow that says what gets removed, by when, and who confirmed it.
Why the wrong answers fail
"HR handles all of it" is the assumption that creates orphaned accounts: HR owns the employment event, but technical access removal needs an owner and verification — trust without checking leaves gaps. Keeping the account active "in case they come back" is standing, unmonitored risk; a dormant valid credential is exactly what attackers hunt for. Disabling only email addresses the most visible system and ignores VPN, cloud, SaaS, and privileged access the person can still use — a partial fix that feels done but isn't.
The judgment being probed
The interviewer wants to hear that you think in terms of the full identity lifecycle, that you'd verify rather than assume, and that you understand the long tail of SaaS and shadow accounts that escape SSO. A strong answer mentions reconciling against the JML process, handling shared and service credentials (rotate, don't just disable), and being able to evidence timely deprovisioning to an auditor — closing the loop between the HR event and the actual, confirmed removal of every access path.
Likely follow-ups
- How do you catch SaaS or 'shadow IT' accounts that aren't behind SSO?
- What's the right way to handle shared or service accounts the leaver used?
- How would you evidence timely deprovisioning to an auditor?