Review software access when a person changes role or leaves
Check business permissions, active sessions and connected services with a named owner for every account.
Inventory more than the login
List the systems the person uses and how each grants access: direct account, central sign-in, shared group or connected service. Include administrator consoles, shared documents, API clients and devices under your control. Record an owner for each action and the intended completion time. In this fictional small distributor, a salesperson also owns a reporting connector. Removing only the CRM login leaves that connector unreviewed.
Describe permissions as business actions
Build a matrix of roles and actions rather than relying on labels such as 'standard user'. A salesperson needs to update assigned contacts, a finance operator needs to issue billing records, and an administrator needs to manage access. Review viewing, editing, exporting and deleting separately. OWASP recommends least privilege, denial by default and authorisation checks on each request. A menu hidden from a user does not establish that the underlying action is denied.
Check a role change before closing the old role
For an internal move, agree the new responsibilities and remove permissions that no longer belong to the role. Use a test account to confirm that the new role can complete required work and cannot reach restricted records through direct links or exports. Keep the access decision and reviewer recorded. Do not leave both old and new administrator rights enabled indefinitely simply to avoid resolving one missing permission.
Review sessions and delegated access
Use each product's documented controls to disable the account, revoke sessions and remove connected application grants. Check whether a password change alone affects existing sessions or API credentials; do not assume it does. Remove individual tokens that belong to the departing person under the organisation's process. Where a shared credential was known to them, arrange controlled rotation and update authorised integrations without placing the secret in the ticket.
Transfer ownership of ongoing work
Reassign quotes, scheduled reports, integration jobs and recovery responsibilities before removing the old owner's operational role. Service accounts need their own purpose, access boundary and accountable owner; they must not survive as unexplained personal accounts. Preserve records according to the agreed business and retention rules. Disabling access and deleting business history are different actions and need separate decisions.
Verify closure
Keep a completion record with the system, action, operator, time and verification result. Confirm that the former role cannot log in, that old sessions behave as documented, and that required automated work still runs under the intended service identity. Record unresolved external access explicitly and assign follow-up. End with a repeatable checklist for the next departure, then schedule access reviews around real role changes and your operational review cycle.