Employee offboarding transfer

Purpose

Build a traceable departure workplan that preserves business continuity while respecting access, privacy, retention, and asset rules. The plan identifies what the departing person owns, who receives it, which evidence is needed, and which dependencies remain unresolved.

Scope

Cover the employee or contractor record, last-working date, manager, team, role, projects, customer relationships, recurring duties, repositories, credentials and groups, devices, keys, contracts, open approvals, documents, and successor or interim owner. Include transfer priorities and evidence of handover readiness. Excluded: disabling accounts, collecting devices, contacting the person, approving termination, or making employment-law determinations.

Data basis

• HRIS or people table: worker ID, employment type, manager, team, role, location, status, and departure date.
• Identity and access inventory: account, application, group, privilege, owner, last-used date, and deprovisioning rule.
• Asset register: asset ID, type, custodian, condition, return status, and location.
• Project, CRM, ticket, contract, calendar, repository, and recurring-work records.
• Handover policy, retention schedule, access matrix, and the optional departure_context input.

Result

Produce an offboarding transfer sheet with one row per access, asset, responsibility, relationship, or open item, plus a handover brief. Each row includes outgoing owner, receiving owner, due point, evidence, risk, disposition, and unresolved dependency; the brief summarizes continuity-critical work and retention constraints.

Quality criteria

• The worker and departure date are reconciled across HRIS and the run context.
• Every privileged access, assigned asset, active project, recurring duty, and customer relationship is represented or cited as unavailable.
• No successor is invented; unassigned work is explicitly escalated as a gap.
• Access and retention dispositions follow the supplied policy and retain the reason and source.
• Handover readiness is based on evidence such as a link, owner record, status field, or dated note.

Instructions

Separate immediate continuity risks from routine administrative items. Use the last-working date only as a planning anchor; do not infer an account disablement time unless policy states it. Flag shared credentials, personal data, regulated records, customer commitments, and undocumented recurring work for the defined escalation role. Preserve the outgoing owner’s source record and distinguish “transfer planned” from “transfer evidenced.” Treat internal transfer as a change of owner and entitlement scope, not as a full exit, when the employment status and policy say so.

Adapt before use

• Map HRIS, identity, asset, project, CRM, ticket, repository, and contract identifiers.
• Add the offboarding, retention, access-review, and asset-return policies to the scope.
• Define continuity-risk levels, receiving-owner roles, evidence requirements, and date conventions.