I've reproduced both the contents of the blog and the comments section (which is probably more interesting than the article) below. Enjoy!
Identity Management technology can be tricky. But in most instances, it's not the technology that trips up an implementation. It's the policy development (or lack thereof) that causes the heartache.
Deprovisioning Policy is typically more complex than a simple policy that states that when HR says a person is terminated, the identity system terminates the user's access to all systems. Here are a few things to consider when developing your Deprovisioning Policy.
1. Deprovisioning Policy (Technical View)
The technical view of a deprovisioning policy is concerned with what the identity system should do once we know that the user should be deprovisioned for each target system.
- Should the user's account be hard deleted or just disabled?
- If disabled, how is that done? (Move the AD account to a disabled users OU, place the row into an archive table, etc.)
- How long should disabled users be kept in the system?
- What should happen to the person's shares, mailbox, etc.?
2. Deprovisioning Policy (Business Process View)
The business process view of a deprovisioning policy addresses the states that should trigger a deprovisioning action. Here are a few questions to ask your policy team:
- How do we calculate the actual last day a person should have access? Is there an effective date that can be used? Is HR using that field properly?
- How should 'leaves of absence' be handled?
- What should happen if a person wants to use his/her vacation days directly before retirement? What if the person may still provide off-site help during this time period and therefore needs access?
- How should sabbaticals be handled?
- Should a user's current access be terminated in a department transfer? What if they still need their old access for some time?
- How should unused sick days be taken into consideration?
3. Take Compliance Policy into Consideration
Besides the business process view of the policy, sometimes existing regulatory compliance rules may have an adverse impact on an otherwise sensible policy. For example, definitions of 'termination', 'employee job role change' and 'leave of absence' will directly impact the overall policy and should be taken into consideration.By thinking through these issues, an effective Deprovisioning Policy can be put together prior to implementing an IAM solution.
Hi Ash, my suggestion (as always with IAM related decisions) is to start from the business view and try to stay out from the temptation to start analyzing the event from a technical standpoint.
Using business as starting point can be very helpful for example in fragmented, complex or very dynamic environments where could be very hard to find a common agreement on the right behavior to follow and where, probably, it can give you also a longer-term solution.
What do you think?