What this template is for
SaaS procurement is the discipline that decays fastest in growing companies. A laptop costs $4,000 once; a SaaS tool costs $5,000 a year forever, and nobody is tracking the forever part. This template makes the forever explicit: every license has a renewal date, a renewal owner, and a 60-day review sub-task that fires before auto-renewal.
The security review field is the other piece teams skip and regret. Every SaaS holds at least some data; the review captures who, what, and under what terms.
When to use it
Use this template for:
- New SaaS subscription (any plan tier)
- Seat-count increase on an existing subscription (treat as a mini-renewal review)
- Plan upgrade (Starter to Business, etc.)
- Vendor change for the same use case
Trial / proof-of-concept usage with no contract does not need a full ticket, but the moment a contract is signed the workflow starts.
How to set it up in Jira
Create a Software License Request issue type with the fields above and the security-review sub-task as a hard gate before approval. Use STM Issue Templates to lay down the justification / security-review / approval / procurement / provisioning / renewal-schedule sub-tasks. Link the Vendor Evaluation Ticket field to a vendor-evaluation ticket if a bake-off was run.
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 | Figma Organization plan - 12 seats for design team | Yes |
Requester | @design-lead | Yes |
Vendor (custom) | Figma | Yes |
Product / Plan (custom) | Figma Organization | Yes |
Seat Count (custom) | 12 | Yes |
Business Justification (custom) | Replacing Sketch; needed for cross-team design files | Yes |
Annual Cost (custom) | $5,400 | Yes |
Budget Code (custom) | DESIGN-2026-OPEX | Yes |
Security Review (custom) | SOC 2 Type II on file; SSO enforced; DPA signed | Yes |
Renewal Date (custom) | 2027-06-01 | No |
Renewal Owner | @design-lead | No |
Vendor Evaluation Ticket | PROJ-1500 (optional - if a bake-off was run) | 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.
- Confirm business justification and that no existing tool covers the use case
- Run or reference security review (SOC 2, DPA, SSO, data residency)
- Get manager and budget-owner approval
- Execute contract through procurement
- Provision SSO group and provisioning rules (SCIM where supported)
- Assign seats to named users; document the seat-allocation owner
- Schedule renewal review 60 days before Renewal Date
Common questions
What is a software license request in Jira?
It is the ticket that captures a new SaaS or software purchase - the vendor, plan, seat count, justification, security review, budget code, and renewal owner. The ticket is the procurement audit trail, the security-review record, and the renewal calendar entry in one place. Without it, SaaS purchases scatter across expense reports and renewals come as a surprise.
How do you avoid SaaS sprawl?
Two practices. First, require the request to confirm no existing tool covers the use case before procurement begins - this catches the third Figma-like license a team has accidentally bought. Second, track renewal owners and review dates on the ticket itself, with a 60-day renewal review sub-task that surfaces in the queue before auto-renewal.
Should every SaaS purchase have a security review?
Every SaaS that holds company or customer data, yes. Security review at minimum captures: independent attestation (SOC 2 / ISO 27001), data processing agreement, SSO support, data residency, and a contact for security incidents. For trivial tools that hold no sensitive data, a lightweight review is fine, but it must still be on the ticket.
How do you keep SaaS renewal dates from sneaking up on you?
Schedule the renewal review as a sub-task on the procurement ticket itself. [STM Issue Templates](/stm/) can auto-create the renewal-review sub-task with a target date 60 days before Renewal Date, surfacing it in the queue before auto-renewal kicks in. This is how SaaS programmes stay deliberate rather than reactive.
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 →