Offboarding ends a person’s organizational access and requires account removal, asset return, and confirmation of continuing obligations; a role transfer keeps the person employed or engaged but requires their access, approvals, and responsibilities to be recalculated for the new role. An offboarding vs role transfer security checklist should therefore use different end states: “disable and close” for separation, and “remove, grant, and re-certify” for a transfer. Under ISO 27001 control 6.5, both workflows must also define, enforce, and communicate information security duties that survive termination or a change of employment.
What is the difference in an offboarding vs role transfer security checklist?
What is offboarding?
Offboarding is the controlled separation of an employee, contractor, temporary worker, or other external party from the organization. The security objective is to end access at the correct time, preserve business records and evidence, recover organizational assets, and remind the departing person of obligations that remain in force. Those obligations commonly include confidentiality, protection of intellectual property, non-disclosure commitments, and requirements to return or securely destroy organizational information held outside approved systems.
For example, consider NorthBridge Clinical Systems, a 620-person healthcare technology vendor that operates a SaaS patient-engagement platform. When a senior implementation consultant leaves, HR records the termination in Workday with an effective time of 5:00 p.m. The offboarding workflow sends a ServiceNow request to disable the consultant’s Okta account, revoke active sessions, remove Microsoft 365 access, and deprovision Salesforce, Jira, Confluence, GitHub Enterprise, and the customer-support platform. The consultant’s laptop is returned through the endpoint-management process, while the security team verifies that their SSH keys, API tokens, shared-mailbox permissions, and privileged support access are removed. Their continuing confidentiality obligation is communicated and acknowledged as part of the separation package.
An offboarding checklist is not complete merely because the person can no longer sign in. The organization must be able to show who authorized the separation, when access was revoked, what systems were in scope, whether any exceptions existed, and how continuing security obligations were communicated.
What is a role transfer?
A role transfer occurs when a person remains with the organization but changes job function, department, reporting line, level of authority, project assignment, or contractual scope. The security objective is not to remove the person’s identity; it is to ensure the new access profile matches the new duties and that access tied to the prior role is removed promptly. This is often more difficult than offboarding because the user must remain productive while old access, inherited permissions, approval rights, and elevated roles are identified and eliminated.
At NorthBridge Clinical Systems, an implementation consultant may transfer into product management. Their Okta account, Microsoft 365 mailbox, and device remain active, but customer implementation project access should end. The transfer security review removes the user from the Salesforce Professional Services group, Jira customer-delivery projects, production support rotation, customer VPN policy, and the Azure subscription role used to troubleshoot deployments. It may grant access to Productboard, the product roadmap workspace, and a limited Jira product-development project. The manager must also confirm whether the employee still needs access to customer data, whether their prior approval authority remains valid, and whether their new role creates a separation-of-duties concern.
How do offboarding and role transfers compare?
| Security decision | Offboarding | Role transfer | Audit evidence to retain |
|---|---|---|---|
| Identity status | Disable or delete the workforce identity at the approved separation time. | Keep the identity active, but update department, manager, role, and access profile. | Workday event, ServiceNow ticket, Okta System Log, and completion timestamp. |
| Okta and Microsoft 365 | Deactivate Okta, revoke sessions, remove MFA factors, and block Microsoft 365 sign-in. | Remove old Okta groups and Microsoft 365 groups; retain only groups justified by the new role. | Before-and-after group membership export and reviewer approval. |
| Privileged access | Remove Azure roles, VPN access, PAM vault access, SSH keys, API tokens, and emergency accounts. | Revalidate each privilege against the new duties; remove prior elevated roles unless explicitly reapproved. | Azure Activity Log, PAM session records, role-review attestation, and exception approval. |
| Business records and ownership | Transfer mailbox, customer cases, repositories, contracts, and workflow ownership to a named successor. | Transfer only records and approvals tied to the former job; preserve access required for the new job. | Named successor, mailbox delegation record, and workflow reassignment report. |
| Physical and managed assets | Recover badge, laptop, security key, mobile device, and any paper records. | Reissue or reconfigure assets if the new role changes location, customer-site access, or device requirements. | Asset inventory record, badge deactivation report, and endpoint-management status. |
| Continuing responsibilities | Communicate obligations that continue after separation, including confidentiality and information return requirements. | Communicate revised responsibilities, including duties that remain from the prior role and duties added by the new role. | Signed acknowledgement, policy notice, or documented HR communication. |
Where do organizations confuse these workflows under ISO 27001 control 6.5?
The most common mistake is treating a role transfer as a partial offboarding event: the organization grants new access but does not systematically remove access from the prior role. This creates accumulated privilege. A developer who becomes an engineering manager may retain production deployment rights; a customer-success employee who moves to finance may retain customer export permissions; or a contractor converted to an internal employee may inherit both vendor and employee access paths. None of these outcomes is automatically wrong, but each requires a documented business justification and approval.
The reverse confusion is also risky: treating offboarding as only an access-management task. ISO 27001:2022 control 6.5, Responsibilities After Termination or Change of Employment, requires that information security responsibilities and duties remaining valid after termination or a change of employment be defined, enforced, and communicated to relevant personnel and other interested parties.[1] An assessor will therefore look beyond a screenshot showing an inactive account. They will want to understand how the organization identifies surviving obligations, who communicates them, and how it records that communication.
For an IT manager preparing for certification, the practical distinction is in the trigger and the evidence trail. A separation trigger should initiate termination-specific activities: disable access, recover assets, transfer ownership, preserve records, and issue the continuing-obligations notice. A transfer trigger should initiate a role-based access review: remove old groups first or concurrently with new grants, reassess privileged access, update approvers, and communicate changed responsibilities. The same HR system may trigger both workflows, but the required tasks and completion criteria should not be identical.
Assessors commonly test this through sampling. They may select a recent departure and ask for the Workday separation event, ServiceNow ticket, Okta deactivation log, endpoint return record, and acknowledgement of post-employment confidentiality duties. They may then select a recent transfer and compare the user’s access before and after the role change. If the employee moved from customer operations to engineering, the assessor may ask why the employee still belongs to a customer-data group, retains a Salesforce export permission, or can approve the same change they now implement.
What should a defensible transfer review show?
A role-transfer checklist should show that access was reviewed against the destination role rather than simply copied from the source role. At a 180-person medical-device software provider, for example, a quality analyst transferred to a release-engineering role. The review removed the analyst’s approval authority in the electronic quality management system, retained read-only access needed for release evidence, and added a tightly scoped GitHub Enterprise team membership. The change record documented that the employee could prepare release artifacts but could not independently approve the quality record governing the same release. That evidence supports both access control and the organization’s separation-of-duties design.
For this reason, assign accountability clearly. HR should own the employment-event accuracy and timing; the receiving and departing managers should confirm job duties and ownership transfers; IT should execute standard deprovisioning and provisioning; application owners should validate high-risk entitlements; and information security should define the control requirements, monitor exceptions, and retain evidence. A manager’s verbal confirmation that “they still need access” is not a substitute for an approved role-based decision.
What is the bottom-line verdict?
Offboarding and role transfer are related lifecycle controls, but they are not interchangeable: offboarding closes the access relationship, while a role transfer redesigns it and must actively remove no-longer-needed privileges. Your offboarding and role-transfer checklists should share evidence, ownership, and continuing-obligation requirements under ISO 27001 control 6.5, but they need separate completion criteria so that neither orphaned accounts nor accumulated privilege pass unnoticed.
Before your certification audit, sample three separations and three role changes and verify that each record proves both the technical access decision and the communication of continuing security responsibilities.
