What this template is for
Access management is where ITSM tickets earn their compliance keep. Every grant of permission needs a justification, an approver, and a review date - otherwise access accumulates silently until the next audit finds five years of stale grants.
This template encodes least-privilege defaults into the ticket. Required fields for Access Level, Justification, Duration, and dual approvers (manager + system owner) make the right thing the default thing. The audit trail is automatic because the ticket is the artefact.
When to use it
Use this template for any non-default permission grant:
- Production system access (databases, infrastructure consoles, deploy keys)
- Sensitive data access (PII, financial, source code on protected repos)
- Elevated roles inside SaaS tools (Jira admin, GitHub org owner, AWS root)
- Time-limited project access for contractors or partners
Routine onboarding access (standard email, base SaaS tools) lives on the employee-onboarding-it ticket instead.
How to set it up in Jira
Create an Access Request issue type with the fields above on its Create Issue screen. Make Access Level, Justification, Duration, and both approver fields required. Use STM Issue Templates to lay down the standard sub-task checklist. For repeat patterns (joining a rotation, joining a project team), consider Custom Fields configured per project so reporting on access by team is straightforward.
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 | Grant @priya.patel read access to payments-prod database | Yes |
Requester | @priya.patel | Yes |
System / Resource (custom) | payments-prod (RDS) - read only | Yes |
Access Level (custom) | Read / Write / Admin | Yes |
Justification (custom) | Joining on-call rotation; needs read for incident triage | Yes |
Duration (custom) | 90 days (auto-revoke 2026-08-21) | Yes |
Approver (Manager) (custom) | @line-manager | Yes |
Approver (System Owner) (custom) | @payments-tl | Yes |
Mechanism (custom) | AWS SSO permission set / Okta group / IAM role | No |
Linked Onboarding/Project Ticket | PROJ-1480 (optional) | No |
Status | Pending approval / Approved / Granted / Revoked | 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.
- Capture business justification and confirm least-privilege scope
- Get line-manager approval
- Get system-owner approval
- Provision the access through the standard mechanism (SSO group, IAM role)
- Confirm requester can access the resource and close the ticket
- Schedule auto-revoke or review at the duration boundary
Common questions
What is an access request in a Jira ITSM workflow?
It is the ticketed flow for granting a person permission to a system or resource. The ticket captures who is asking, what they are asking for, why, who approved it, and when it should be reviewed or revoked. Storing access decisions in Jira creates the audit trail compliance frameworks (SOC 2, ISO 27001) require and lets you query 'who has access to X' in one place.
Should access requests be time-bound?
Wherever possible, yes. Time-bound access is the cheapest defence against permission creep - the cleanup is on the calendar, not on the security team's wish list. For permanent role-based access, the time-bound review still applies (e.g. annual recertification); the duration field becomes the review date rather than a revocation date.
How do you enforce least privilege in an access request?
Three habits. Require explicit Access Level (read/write/admin) rather than 'access to X'. Require business Justification that explains why this level is needed. Make the system owner the second approver - they are the only person with context to push back on over-broad requests. The line-manager approval covers headcount; the system-owner approval covers scope.
How do you automate access-request sub-tasks?
Use [STM Issue Templates](/stm/) to lay down the justify / manager-approve / owner-approve / provision / confirm / schedule-revoke sub-tasks on every access ticket. The schedule-revoke sub-task is the one that quietly disappears in ad-hoc workflows; automating it is how access programs stay compliant without heroics.
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 →