Granting access to an application often takes more than one step. That's true for modelling systems, and just as true for the systems we rely on every day: loan application systems, fraud management platforms, claims workbenches and pricing engines.
Removing access should take the same number of steps. It often doesn’t, and this creates risk.
We've written before about deprovisioning user access. This is one specific gap worth checking even where a deprovisioning process already exists.
If an onboarding step is missed, the user can't do their job, and they'll follow it up.
Offboarding doesn't have that same pressure. Unless offboarding is automated (well), removal is often at one of the layers, not everything that was done to grant access. So someone might remove access inside the app; the rest remains, unnoticed, because it’s not immediately affecting anyone.
Some systems require an application to be installed before a user can access it. This could be through a company portal. Getting a new starter working then takes more than one action: provision the app through the portal, then grant them access inside it.
When the user leaves or changes roles, we need to remove both the access within the app, and access to the app in the portal.
Many modern systems use single sign-on (SSO). Access is enabled by adding the user to a network group, separate to access within the app itself. If the app only allows SSO, there’s no access without this step.
Again, when the user leaves or changes roles, we need to remove both the access within the app, and the network group membership.
I see each of these often (probably too often) when reviewing access controls:
Mature organisations don't reissue a leaver's ID to a different person, and that's the right control. But rehires and re-engaged contractors can get their old identity back. Any previously leftover access may then be re-activated. This can happen without a new approval, and without anyone realising it was there.
Regular reviews of system access are hard enough. When the list is filled with these orphaned records that don’t map to current users, it’s easy to ignore them because there’s no immediate risk. We have other priorities.
Bith risks matter more here than for ordinary office tools, because these systems decide things about customers. Someone with leftover access to a lending system might see or touch applications they no longer have any business reason to.
If we don’t have automated cross-system deprovisioning, we should map provisioning properly: list every system and layer touched when someone gets access, not just the main request. Then:
Disclaimer: The info in this article is not legal advice. It may not be relevant to your circumstances. It was written for specific contexts within banks and insurers, may not apply to other contexts, and may not be relevant to other types of organisations.