VPN access request template

Remote work made VPN access a routine ask in most IT teams, and a risky one when it travels by email or chat. A VPN access request template turns that ask into a structured Jira Service Management ticket that records who wants access, to which network, why, for how long, and who signed off. Copy the template above straight into a Jira issue, or read on for what each field captures, a strong-versus-weak example, and how to turn the structure into a reusable template with Process Templates for Jira.

What this template captures and why

The hard part is never opening the ticket, it is making sure the ticket carries everything IT and your auditors need before anyone touches the firewall. This template front-loads that: identity, target system, justification, expiry, and approver, all in one issue.

Standardizing the intake does three things. It removes the back-and-forth where IT has to chase the requester for missing details. It keeps an access record inside Jira instead of a mailbox, so the request, the approval, and the eventual revocation all live on one issue with a full history. And it makes the expiry explicit, which is how you avoid the slow accumulation of standing access that no one remembers granting.

Field-by-field breakdown

• Summary: a one-line title that reads cleanly in a queue. A smart value like VPN access request - {{requester.name}} - {{system}} fills it in automatically when the issue is created, so every ticket is named consistently.
• Requester contact information: name, work email, and a phone number. Phone matters here because VPN provisioning often needs a second channel to deliver credentials or confirm identity.
• System to access: a dropdown of the networks you actually run, for example Production VPN, Staging VPN, or a customer-network VPN. A fixed list stops free-text guesses and keeps reporting clean.
• Description: the plain-language reason for the request, the resources that need to be reached, and the access duration required.
• Justification: the business reason, separated from the description so an approver can scan it in one line.
• Expiration date: the date access should be revoked. Treat this as required, not optional.
• Manager approval: the name of the approving manager, captured on the issue so the approval is part of the record rather than a verbal yes.
• Additional information: anything that does not fit elsewhere, such as a linked change ticket, a security exception reference, or device constraints.

You can expose the variable fields (text, dropdown, date) at create time so the agent or requester fills them in a short wizard. See creating variables in templates for how that works, and smart values for auto-filling the summary and other fields.

Best practices

• Always set an expiration date. Open-ended VPN access is how shadow access piles up. If access genuinely needs to be permanent, that is a different, heavier decision than a standard request and should be flagged as such.
• Keep the system list as a dropdown. Free text invites typos like “prod vpn”, “Production”, and “PROD-VPN” that fragment your reporting. A managed list keeps every ticket queryable.
• Make justification its own field. Approvers should not have to dig through a paragraph to find the reason. One clear line speeds the decision and improves the access record.
• Record the approver on the issue. A verbal or chat approval leaves no trail. Capturing the manager’s name, and ideally routing the approval through a workflow transition, keeps the audit trail and the approval in the same place.
• Link related work. If the request comes from an onboarding or a change, link it so the access has visible context. Preserving the links between issues explains how template links carry across.

Strong example vs weak example

A weak request looks like this:

Summary: vpn pls Description: need vpn for work

There is no named system, no justification an approver can act on, no end date, and no approver. IT has to reply and ask for all of it, which adds a day before anything happens.

A strong request from this template looks like this:

Summary: VPN access request - Jane Doe - Production VPN Requester: Jane Doe, jane.doe@acme.com, +32 2 555 01 22 System to access: Production VPN Justification: Added to the payments on-call rotation; needs production VPN to reach monitoring and the incident jump host. Expiration date: 2026-12-31 Manager approval: Priya Nair (team lead)

The second ticket can be approved and provisioned without a single clarifying reply, and six months later anyone can see exactly why the access exists and when it lapses.

How to use this template in Jira

1. Build the request once with these fields in your Service Management project, then save it as a template. The walkthrough in how to create templates covers this end to end.
2. Mark the changing fields as variables so the requester, system, justification, expiration, and approver are asked at create time. See creating issues from templates.
3. Pin the template for staff to raise on a dashboard gadget so they raise a correctly structured VPN request in two clicks.
4. Route approval with automation so a Jira rule sends the ticket to the requester’s manager, then to IT once approved. The automation integration guide shows the hooks. This keeps the approval and the access record together on one issue.

Frequently asked questions

What is a VPN access request in Jira? A VPN access request is a Jira Service Management ticket where an employee asks for remote access to a company network. The ticket records who wants access, to which VPN, the justification, an expiration date and the approving manager, so the request, the approval and the eventual revocation all live on one issue.

What should a VPN access request template include? It should capture the requester’s contact information, the specific system to access, a plain-language description, a one-line justification, an expiration date, the approving manager and any additional notes such as a linked onboarding or change ticket.

Why set an expiration date on VPN access? Open-ended VPN access is how standing access quietly accumulates until no one remembers granting it. A required expiration date makes every grant time-boxed, which is the single most effective control on this form and keeps access reviews honest.

How do I create a reusable VPN access request template in Jira? Install Process Templates for Jira, build one Service Request with the fields on this page, save it as a template, then mark the requester, system, justification, expiration and approver as variables so staff fill only the blanks at create time.

Related templates

Pair this with the rest of your access and IT intake forms: the Admin access request template, the Request for new software template, and the IT support request template. Or browse the full template library for matching formats across software, ITSM and support work. Process Templates for Jira is free for up to 10 users, so you can standardize VPN intake across the team before deciding on a paid plan.