top of page
Search

When an Employee Changes Roles, SaaS Access Should Too

Writer: Martin Snyder
Martin Snyder
Nov 9
5 min read

In brief: A role change should trigger a SaaS access review that compares the employee's new responsibilities with existing accounts, groups, grants and privileged workflows. Verify removal of obsolete access and transfer any ownership duties. Joining a new team does not itself establish that old SaaS permissions disappeared, especially where local accounts or independently authorized integrations remain.


Monday: the move is effective

In a hypothetical company, a finance analyst moves into sales operations. HR updates the department. New access is requested. Nobody asks whether the employee still needs the old reporting workspace, finance exports or a local SaaS administrator role. The mover process succeeds as provisioning and fails as a complete access transition.

Treat the role change as a review event with a known effective date, old role and new role. Ask the previous and receiving managers to identify the business responsibilities that end, continue or begin. The point is not to remove every old account blindly. It is to explain why each relevant entitlement remains or changes.


Tuesday: compare duties before comparing application names

Build a short responsibility map. Which information and operations are required in the new role? Which old responsibilities need a handoff? An application can remain useful while an administrative role inside it becomes unnecessary. Review entitlement scope, not merely whether the vendor appears on an approved list.

Microsoft's Lifecycle Workflow deployment guidance describes lifecycle planning in its environment. Use the current supported capabilities where appropriate, but verify which applications and tasks your deployment actually covers. A workflow completion status cannot establish that every local SaaS account or integration outside its scope was reviewed.


Wednesday: reconcile known and discovered access

Start with identity-provider assignments, application-admin records and the existing inventory. Add discovered associations that require investigation. Mark confirmed accounts separately from historical or unverified signals. An old account-related message should prompt a check; it should not be presented as proof that the employee can still reach sensitive data.

For each confirmed account, record tenant, role, resource scope and authorization path. Include privileged roles, shared workspaces and identified OAuth grants where relevant. Microsoft's permissions and consent overview helps distinguish application authorization models. App-only workflows require their own ownership review rather than being treated as personal entitlements that vanish with a department change.


Thursday: choose the disposition

Existing relationship

Possible outcome

Verification needed

Old-role read access

Remove or narrow

Scoped effective-state check

Continuing business duty

Retain with rationale

Manager and resource-owner confirmation

Workspace ownership

Transfer

Accepted ownership and continuity check

Privileged role

Reassess necessity

Relevant role and restriction evidence

Integration responsibility

Transfer or retire

Application identity and dependency review

These are candidate outcomes, not automatic rules. The new manager may know the employee's duties but not the resource's sensitivity. The application owner may know the permissions but not whether the business responsibility continues. A useful review obtains both perspectives and records who accepted the resulting decision.

The temporary overlap that needs an end date

A handover may require limited access to both old and new environments. Record the purpose, permitted scope and expiry date. Assign an owner to verify removal at the end. Avoid letting a reasonable transition period become indefinite access simply because the initial mover ticket was closed.


Friday: verify the change, then close the handoff

Have the authorized administrator implement each decision. Record the post-change state for the relevant account or permission. Where an approved test is useful, keep it bounded and use non-sensitive information. Do not report complete removal based only on the request's approval or the fact that one group membership changed.

NIST SP 800-53 provides broader account-management context. The practical completion record should name the subject, entitlement, action, evidence and any residual limitation. If a local account still needs follow-up, preserve an open subtask rather than forcing the entire transition into a green status.

Use Waldo's employee offboarding context to examine removal paths, adapting it for employees who remain with the organization. The platform overview provides related application and identity discovery context. Verification still belongs with the authoritative systems and responsible administrators.


After the first week: learn from the gaps

Review which entitlements were missed by the standard mover workflow and why. A local SaaS role may need a new application-owner task. An ownership transfer may need an earlier manager notification. An ambiguous discovery finding may need better identifiers. Improve the process based on confirmed gaps, not a blanket assumption that all unintegrated tools are unauthorized.

Measure obsolete access with verified removal, continuing access with accepted rationale and temporary overlap with an expiry. These outcomes tell the organization whether roles and permissions are staying aligned. Counting completed HR updates or new access requests alone does not answer that question.

The employee should finish the transition with the access needed for the new job and a clear handoff for old duties. The governance record should explain retained access, show completed changes and keep remaining work visible. That is a more useful result than an automated “mover complete” label with no account-level evidence.


Ask the receiving manager to confirm the handoff

The receiving manager should see retained old-role access and any temporary overlap, not only the new provisioning request. Ask for a business rationale within the person's responsibilities, while the relevant resource owner confirms the permission scope. Those perspectives can reveal a continuing duty that needs a formal transfer rather than indefinite access under the employee's new role.

At the end of the transition period, verify the agreed removal and record whether the handoff completed. If the work still depends on the employee, reopen the ownership decision and define a new scoped arrangement. Avoid leaving the original temporary note untouched. A role-change process becomes dependable when it follows responsibility through to an accepted new owner and checks the resulting access, instead of stopping at the department update.


Frequently asked questions

Should every old SaaS account be removed?

Review the business need and entitlement scope. Some accounts remain useful, while old privileged roles may not. Record the rationale and responsible owner instead of applying a blanket vendor-level removal rule.

Does an HR department update remove permissions?

It may trigger workflows configured for that attribute, but does not establish coverage of every SaaS account. Verify the deployment's actual tasks and review local or independently managed access separately.

Who approves temporary overlap?

Use the organization's authority model and relevant resource owners. Record the purpose, scope, expiry and verification owner. A handover need should not become indefinite retained access by default.

What happens to applications the employee configured?

Review the application identity, business purpose and ownership separately. Transfer responsibility or retire the workflow as appropriate. The employee's role change does not prove app-only credentials or permissions changed.

How do we close the mover review?

Record decisions for relevant entitlements, verify implemented changes and expose outstanding tasks. Retained access needs a rationale; temporary access needs an expiry. A provisioning completion alone is insufficient evidence.


Key takeaways

  • Compare duties and entitlement scope.

  • Review local accounts and application ownership separately.

  • Verify changes and expire temporary overlap.

Next step: Explore identity context on the platform. Start with the evidence gap that affects your current workflow and assign its verification to an accountable owner.


Sources and further reading

Comments

bottom of page