Jira Offboarding Template: 26 Tasks by Department
TL;DR: 26 offboarding tasks across IT, HR, Legal, Security, and the manager's team, ordered by timing from the last day. Two hard rules before everything else: issue the litigation hold before deactivating the account, and export the Jira Audit Log before deleting it. Everything else is timing and assignment.
A Jira offboarding template is the full list of tasks that IT, HR, Legal, Security, and the manager's team need to complete when someone leaves — organized by department, timed from the last day, and tracked inside Jira. This guide gives you those 26 tasks with Jira-specific notes, plus the sequencing rules that determine whether the offboarding closes cleanly or leaves access gaps.
The template assumes one offboarding Epic per employee with IT, HR, Legal, Security, and Manager as Jira Components. That structure lets each department filter to their own tasks without scrolling through the full list.
The complete Jira offboarding template
26 tasks organized by department and timing from the last day.
| # | Timing | Dept | Task | Jira-specific note |
|---|---|---|---|---|
| 1 | Week before | Legal | Issue litigation hold notice (if applicable) | If there is any active or anticipated litigation involving the departing employee, legal must issue a hold before account deactivation. Deactivation can trigger email purges or auto-archive workflows. Legal completes this task; IT deactivates only after legal has cleared it. |
| 2 | Week before | IT | Audit Jira Automation rules owned by this user | Automation rules owned by the departing employee continue to run after account deactivation. HTTP request actions using their stored credentials fail silently — no error appears in the Automation log visible to other admins. Go to Automation → filter by Owner: [User] → reassign each rule before the last day. |
| 3 | Week before | IT | Fix Component default assignee | If the employee was the default assignee for any Jira Component, deactivating them silently routes new issues to Unassigned with no notification. Go to Project Settings → Components → update the default assignee for each affected Component before the last day. |
| 4 | Week before | HR | Export PTO and leave balance | Export the balance before deactivating the account. Some leave-tracking tools lose history when the user is removed from the IdP. Record the final balance in the offboarding Epic before triggering account deactivation. |
| 5 | Week before | HR | Schedule exit interview | Schedule before the last day, not on it. People on their last day are occupied with logistics handoffs. Create a sub-task with a due date 5 business days before the last day to keep the interview from slipping. |
| 6 | Week before | Manager | Bulk reassign open Jira issues | Use Jira's bulk edit: Board or Backlog → select issues → Bulk Change → Edit Fields → Assignee. Do this before the last day while the employee can still clarify context on open work. Issues assigned to a deactivated user remain in Jira but are excluded from most default sprint board filters. |
| 7 | Week before | Manager | Document knowledge transfer in Confluence | Create a Confluence page linked to the offboarding Epic. The employee writes it; the manager reviews it before sign-off. Minimum sections: current project status, active blockers, key contacts, and any team account credentials not stored in a password manager. |
| 8 | Last day | Security | Remove from Jira Admin group before deactivating | Jira users with Site Admin access retain that access even after account deactivation until explicitly removed from the admin group. Go to Atlassian Admin → Groups → site-admins → remove the user. Complete this before triggering deactivation. |
| 9 | Last day | Security | Export Jira Audit Log for this user | Go to Jira Admin → System → Audit log. Filter by the user and export the last 90 days. Look for bulk issue exports, permission changes, and project configuration edits. Export before deactivation — some audit records are attached to the user object and may not be accessible after the account is removed. |
| 10 | Last day | IT | Disable IdP/SSO account | Disable in Okta, Azure AD, or Google Workspace first. Jira respects SSO deactivation on the next session refresh, but the Atlassian account remains active until you also deactivate it in Atlassian Admin. Both steps are required; one alone leaves a gap. |
| 11 | Last day | IT | Deactivate Jira account (do not delete) | Deactivating preserves all issue attribution and audit history. Deleting removes the user from every Reporter and Assignee field site-wide — the board shows anonymous attributions for all work that person did. Deactivate only. Go to Atlassian Admin → Users → [User] → Deactivate. |
| 12 | Last day | IT | Revoke Jira personal API tokens | Jira does not auto-revoke personal API tokens when an account is deactivated. Active tokens continue to authenticate API requests until they expire or are manually revoked. Go to Atlassian Admin → Users → [User] → API tokens → revoke all. |
| 13 | Last day | Security | Revoke SSH keys on all servers and deploy keys | Check authorized_keys on every production and staging server individually. Also check GitHub and Bitbucket for repository-level deploy keys the employee may have added — these are not removed when the organization account is deprovisioned. |
| 14 | Last day | Security | Revoke PATs across all developer tools | GitHub, GitLab, CircleCI, Datadog, Sentry, and similar tools each maintain separate token stores. Deprovisioning from the IdP does not revoke these tokens. Create a sub-task per integration and track revocation for each one individually. |
| 15 | Last day | IT | Collect hardware and initiate MDM wipe if needed | Log the hardware return in the Jira task with the device serial number. If MDM (Jamf, Kandji) is in use, trigger a remote wipe command from this task before returning the device to inventory. Set the due date to the agreed return date. |
| 16 | Last day | Legal | Confirm NDA and confidentiality obligations | Send the employee a written reminder of active NDAs and confidentiality obligations on or before the last day. The Jira task completion timestamp serves as documentation that the reminder was delivered and acknowledged. |
| 17 | Last day | Legal | Confirm IP assignment for work in progress | Verify the IP assignment agreement covers any work-in-progress at the time of departure. Engineering should list any pending patents or unreleased inventions in a sub-task for legal review before the account is deactivated. |
| 18 | Last day | HR | Issue separation letter and collect signed paperwork | If severance is involved, confirm the release agreement is signed before the last day. Track document status in the Jira task using a label or status sequence: Drafted → Sent → Signed → Filed. |
| 19 | Last day | Manager | Transfer Confluence space ownership | If the employee owned a Confluence space, the space becomes unmanaged when the account is deactivated. Go to Space Settings → Overview → Edit → Owner and transfer ownership before deactivating the account. |
| 20 | +5 days | HR | Update HRIS and employee directory | Mark the termination date and type (voluntary or involuntary). If your HRIS syncs to Jira via SCIM or a directory integration, verify the sync removed the user from Jira groups. Some SCIM configurations add users on provisioning but do not remove them on deactivation. |
| 21 | +5 days | HR | Send COBRA notification | Employers have 30 days to notify their group health plan administrator, who then has 14 days to send COBRA election paperwork to the employee. The 30-day clock starts on the last day of coverage. Set a Jira due date to the termination date + 29 days to avoid missing this deadline. |
| 22 | +5 days | HR | Process final payroll | Final pay deadlines vary by state. California requires same-day payment for involuntary terminations; most other states allow the next regular pay cycle. Log the applicable state deadline in the Jira task with a due date that matches the law, not the next default payroll run. |
| 23 | +5 days | IT | Rotate shared credentials the employee held | Shared service account passwords, integration API tokens tied to team accounts, and any webhook secrets the employee knew. List each credential in a sub-task and rotate one at a time to avoid breaking live integrations during the rotation. |
| 24 | +14 days | Legal | Process equity and stock paperwork | RSU vesting dates, option exercise windows, and ESPP elections each have different post-termination deadlines. ISO stock options typically have a 90-day exercise window after the last day of employment. Create a Jira task with a due date set to last day + 89 days so this does not slip. |
| 25 | +14 days | Legal | Apply data retention policy to employee files | Email archives, Confluence pages, and Jira history fall under your data retention schedule. Configure the retention policy before deleting the Atlassian account — deleting the account also removes Jira issue history attributed to that user. |
| 26 | +14 days | Manager | Update runbooks and process docs with new owner names | Any runbook listing the employee as an escalation contact is now stale. Run a Confluence search for the employee's name. Update all pages before closing the offboarding Epic. Assign this as a Jira sub-task with a due date 14 days after the last day. |
Sequencing: two tasks that must come before deactivation
Most offboarding tasks can run in parallel. IT can collect hardware on the last day while HR prepares the separation letter. Two tasks have a hard ordering constraint:
1. Litigation hold before account deactivation. If there is any active litigation or a reasonable expectation of it involving the departing employee, legal must issue a hold notice before IT deactivates the account. Deactivation can trigger email purges, auto-archive workflows, and cloud storage sync deletions. Once the data is gone, a hold notice cannot recover it. Legal clears task 1 in the table; IT runs task 10 after.
2. Jira Audit Log export before account removal. The audit log filtered by user is accessible while the account exists. Some audit records are tied to the user object and may not survive account deletion. Export the log on the last day, before any deactivation step. This is task 9 in the table, ordered above the deactivation tasks for this reason.
Three ways to run this template in Jira
Jira does not have a native offboarding mode. These are the three practical approaches, ordered from lowest setup cost to highest automation:
- Jira Automation rule — Create a rule triggered by a custom field change (for example, "Employment Status" set to "Terminated") that automatically creates the offboarding Epic and sub-tasks. Requires Jira Admin access and Automation Premium tier. The rule needs maintenance as task lists evolve, but it removes manual Epic creation for each departure.
- Confluence template + manual Jira tasks — Write the 26 tasks as a Confluence page template. For each offboarding, duplicate the page and create Jira sub-tasks from it manually. More effort per departure, but no automation configuration required.
- TeamOps — Creates the per-employee offboarding Epic, the IT/HR/Legal/Security Component split, and the 26 tasks with due dates calculated from the last day — IT tasks default to "last day," HR tasks to "+5 days," legal tasks to "+14 days." Free for up to 10 users.
Frequently asked questions
- How do I offboard someone in Jira?
- Create an offboarding Epic named "Offboarding – [Name]" with the last day as the start date. Add IT, HR, Legal, Security, and Manager as Jira Components. Create sub-tasks for each department. The 26-task template above covers a complete offboarding with Jira-specific notes for each task.
- What is the difference between deactivating and deleting a Jira user?
- Deactivating prevents login and removes the user from project member lists but preserves all issue history. Every ticket they created or were assigned to keeps their name. Deleting removes them from all issue history site-wide, replacing their name with anonymous references. Always deactivate; never delete a former employee's account.
- Does deactivating a Jira user revoke their API tokens?
- No. Personal API tokens are not automatically revoked on account deactivation. Active tokens continue to authenticate API requests until they expire or are manually revoked. After deactivating the account, go to Atlassian Admin → Users → [User] → API tokens and revoke each token.
- Should offboarding tasks go in the team's main Jira project or a separate HR project?
- A dedicated HR or People Ops project keeps offboarding history separate from sprint work. Offboarding tasks span IT, HR, Legal, and Security — they do not belong in a single team's backlog. A dedicated project lets you use Components for department filtering and a clean 3-status workflow: To Do, In Progress, Done.
TeamOps runs this inside Jira. Free for up to 10 users.