1. Every change in position will be regarded as an event of deletion
Start from the HR record of the system. After the change takes place, generate a task for the outgoing and incoming manager where there will be only one question for the manager to answer — what will the individual no longer need? Provide them with the access list and 10 minutes to answer the question. All the access the individual had created during this period needs to have an owner. If you only do one of these three, do this one.
2. Each permission must have its own unique owner and expiration date
Permissions or access to the project folders, special permissions or access to the production system must expire on a particular date, which could be either the date the project expires or, by default, three months after its issuance, unless renewed by the owner, who must be a named person, not an e-mail address. I think of the account, the owner and the applications it accesses as a graph, because if there is any change in accounts, then with one query, it can determine what he/she owns and his/her dependencies. Renewal must be a one-click option, but in the event of that person’s no longer being available, it should be done through his/her manager so that it does not get lost in the cracks. It is a default setting. In the current scenario, if you do nothing, it is your permission; hence, laziness is the dangerous path. Do not make the default action renewing the permission.
3. Present last-used information on all reviews, and allow people to act on it
Pull last login and last activity timestamps from your identity provider and application logs and present them along with each entitlement. Order the list such that the least used access appears at the top, select it for removal and ask the reviewer to explain why they need to keep it. From experience, I have found that people are happy to confirm when “this entitlement hasn’t been used in seven months” shows up on the screen. Then allow them to take action based on what they think is best. If attestation takes place using one tool and rotation/vaulting takes place using another tool, then you would find people confirming the question and skipping the action. That’s why I’ve started to keep attestation, rotation, vaulting and retirement of access in one process. Remember, however, there are limitations to this approach. Not all applications maintain usage logs, and sometimes there is legitimate access that is rarely used. Take the case of quarterly close accounts and break glass accounts, for example. They should be assigned an owner and a note.
