What this template is for
Offboarding is the IT workflow with the highest compliance risk and the lowest organisational attention. The leaver is gone, the team moves on, and three months later an access review finds a still-active GitHub account or an AWS key that should have been rotated.
This template makes offboarding a single tracked ticket with explicit sub-tasks for every system to be revoked, every device to be recovered, and every ownership to be transferred. The ticket is the audit trail.
When to use it
Use this template for:
- Every employee or contractor departure (voluntary or involuntary)
- Long-term leave (parental, sabbatical, medical) where access should be suspended
- End-of-contract for fixed-term contractors
The Termination Type field drives the timing of access revocation - immediate for involuntary, end-of-day for voluntary.
Sub-task breakdown
STM Issue Templates is particularly valuable on offboarding because the cost of forgetting a sub-task is high (dormant credentials, lost devices, compliance findings) and the sub-task list is long. Auto-creating the full checklist means offboarding consistency does not depend on which IT engineer happens to pick up the ticket. Pair this with the standard role bundles from Employee Onboarding (IT) so the revocation list mirrors the original grants exactly.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | IT offboarding - @leaver (last day 2026-06-30) | Yes |
Leaver Name (custom) | Priya Patel | Yes |
Last Working Day | 2026-06-30 | Yes |
Termination Type (custom) | Resignation / End of contract / Termination / Retirement | Yes |
Manager | @line-manager | Yes |
Successor / Owner Transfers To (custom) | @new-owner (per system) | Yes |
Hardware to Recover (custom) | MacBook Pro (asset MBP-0481), Cisco headset | Yes |
Access Revocation List (custom) | SSO, GitHub org, AWS SSO, production DBs, 1Password vaults | Yes |
Data Retention (custom) | Mailbox suspended 90 days then deleted; Drive transferred to manager | No |
Recovery Address (custom) | Office mailroom / prepaid return label | No |
Exit Confirmed By | @it-offboarding | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Disable identity-provider account at end of last working day
- Revoke production access immediately if termination is involuntary
- Revoke SaaS, source-control, and infrastructure access via SSO group removal
- Transfer ownership of files, repos, dashboards, and on-call rotations to successor
- Recover hardware (laptop, phone, peripherals, security keys)
- Confirm hardware received, wipe, and update asset register
- Suspend mailbox per data-retention policy; schedule deletion
- Close ticket with checklist signed off
Common questions
What is an IT offboarding ticket in Jira used for?
It is the ticketed flow that ensures a leaver's IT footprint is fully closed - identity disabled, access revoked, hardware recovered, ownership transferred, data retained per policy. Without it, the most common failures are dormant credentials that show up in the next access review and laptops nobody ever asked back for. The ticket is also the auditable record that everything was done.
How quickly should access be revoked on offboarding?
For voluntary departures, at the end of the last working day. For involuntary terminations, before the conversation with the leaver - revocation happens first, then the manager has the conversation. The Termination Type field on the ticket drives the timing. Production access in particular should be revoked the moment a termination is decided, regardless of the official last day.
What happens to a leaver's data?
Per the company data-retention policy, but the offboarding ticket captures the specifics. Typically: mailbox suspended for 90 days to receive bouncebacks, then deleted; Drive contents transferred to manager; chat history retained per policy; personal-use data is not transferred. The data-retention field on the ticket records the actual disposition so audit can trace it.
Should offboarding sub-tasks be auto-created?
Yes - it is the single highest-value automation in IT operations. [STM Issue Templates](/stm/) lays down the identity-disable / access-revoke / ownership-transfer / hardware-recovery / data-retention sub-tasks on every offboarding ticket. The risk of missing one (a dormant account, an unrevoked production grant) is exactly what compliance frameworks audit, and automating the checklist is the cheapest defence.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →