Overview

Jira is one of Vanta's most powerful and widely used integrations. If your team already lives in Jira, this integration lets you keep working there while Vanta handles the compliance tracking in the background.

Terminology Note: In Jira, work items are called issues (sometimes “tickets”). In Vanta, those Jira issues appear as tasks linked to tests and other workflows. In addition, "projects" has been rebranded to "spaces" in some Atlassian versions.

Vanta reads issue data from your Jira projects to gather compliance evidence and track remediation progress. It can also create Jira issues and post comments to issues directly from the Vanta platform. Once an issue is resolved in Jira, Vanta automatically reflects that so your engineers never need to log into Vanta to close out compliance work.

This integration guide covers Jira Cloud only.

Want the fastest way to get started? Go to the Jira Quickstart!

What you can do with this integration:

Pull security issues into Vanta automatically — Tag Jira issues with the security label (or a custom label you configure), and Vanta will automatically import them. This gives you a centralized view of all tracked security work without manual evidence uploads.
Prove SLA compliance to your auditor – Vanta records when each security issue was created and when it was resolved. This lets your auditor verify that security work was completed within your stated SLA, no spreadsheets or screenshots needed.

Tip: If label-based filtering doesn't fit your workflow, you can use Jira Query Language (JQL) instead. When configuring your task tracking labels, check the Use Jira Query Language (JQL) option to write a custom query for identifying issues. This is available for security, offboarding, incident, and vendor procurement task types.

Create Jira issues directly from Vanta tests — When a compliance test fails, you can generate a Jira issue in a few clicks. Vanta pre-populates it with what's failing, which test it relates to and the associated controls, and step-by-step remediation instructions so the assignee has everything they need without back-and-forth.
Automate issue creation with workflows in Vanta — Set up a workflow so that every time a specific test falls into a Failing state, Vanta automatically creates a Jira issue. Vanta checks for existing open issues before creating a new one. If an open, unresolved issue for that test already exists, it will not create a duplicate.
Track offboarding access issues — When an employee is offboarded, Vanta can track whether an access removal issue exists in Jira and whether it was resolved within your SLA. Vanta links the issue to the departing employee using their email address in the issue title or description.
Track incident management and resolution — Use Jira to manage your incident response workflow and let Vanta automatically pull in those issues as compliance evidence, helping you prove to auditors that incidents are being addressed and resolved per your policy.

Connection details:

Connection type	OAuth — Vanta reads issue data from Jira and can optionally create issues if you grant write access. Choose access level: Read-only: Vanta can read user information, projects, epics, sprints, and issues for compliance evidence and status tracking, but cannot create Jira issues. Read and write: Required if you want to create Jira issues from Vanta or enable automatic task creation workflows. Write access also enables sprint and epic selection when creating issues.
Supported products	Jira Cloud
Who should connect	A Jira user with Browse Projects permission on the projects you want to monitor. If you enable write access, the user also needs Create Issues permission. We recommend using a dedicated service account (e.g., [email protected]) rather than a personal account, since the integration authenticates as this user. If their access is later revoked or their permissions change, the integration will break. A dedicated service account with a real, monitored email inbox protects against this.
Multiple Jira instances	Vanta supports connecting multiple Jira Cloud sites. If your organization uses more than one Jira Cloud instance, you can connect each one separately.
Estimated setup time	10–20 minutes for initial connection; additional time for label and workflow configuration.
Manual sync	If you need to force a resync, reconnect the integration or contact Support.

What Vanta collects and why

This section covers the data fields Vanta reads from Jira and why each is collected. For details on how Vanta uses this data within specific workflows including security task tracking, offboarding, and incident management see the use cases and capabilities section.

Data collected

Scope - What Vanta monitors

Vanta reads from all Jira projects the connecting user has Browse Projects permission for. Note that Vanta connects to projects, not boards — if your team works from a board that aggregates issues across multiple projects, Vanta's data collection is scoped to the underlying projects, not the board.

Project scope note: Vanta can pull in matching issues from any Jira projects the connected Jira user can browse. If you want to limit which projects Vanta can read from, restrict that user's Jira project permissions (recommended), or use JQL-based targeting (advanced).

Data point	What Vanta collects	Why it’s collected
Title	Issue's summary field	Identifies the security issue or task being tracked
Assignee	User assigned to the issue	Surfaces ownership of remediation work in Vanta
Status	Current Jira workflow status	Determines whether the task is open, in progress, or complete
Priority	Jira's default priority values (Highest, High, Medium, Low, Lowest) OR P0/P1/P2/P3 labels if applied	Maps to Vanta's priority tiers for SLA tracking and test reporting
Tags/labels	All labels applied to the issue	Used to identify which issues Vanta should track (based on your label configuration)
Description	Issue description/body	Collected but not prominently displayed in the Vanta UI. Used primarily for specific workflows such as offboarding issue matching.
Created at	Issue creation timestamp	Establishes when the work began on an issue
Resolution date	The date the issue was resolved in Jira	Used to determine whether the issue was resolved within your policy's SLA
Last updated	Timestamp of the most recent change to the issue	Used for incremental sync–Vanta only re-fetches recently changed issues
Project	The Jira project the issue belongs to	Used to scope data collection and organize tasks in Vanta

Note: Vanta reads issue data from any Jira project the connecting user has access to, subject to your label and project configuration. Data from projects the connecting user cannot access will not appear in Vanta.

What Vanta does not collect or sync

To avoid confusion, the following are explicitly not included in the Vanta and Jira sync:

Not supported	Notes
Issue comments	Vanta doesn’t import Jira comments into Vanta. For Jira attachment-based evidence upload, Vanta may add confirmation comments on the Jira issue.
Attachments	Not synced (except via the dedicated evidence upload Preview feature)
Due dates	Not collected
Sprint assignments	Not read from Jira during sync. However, when creating a new Jira issue from Vanta (with write access enabled), you can assign the issue to a sprint.
Epic links	Not read from Jira during sync. However, when creating a new Jira issue from Vanta (with write access enabled), you can assign the issue to an epic.
Story points	Not collected
Board or backlog configuration	Not collected
Jira user license or billing data	Not collected
Custom Jira statuses	Vanta maps by status category, not status name. Any status in Jira's Done category will be treated as resolved in Vanta, regardless of what you've named it. Statuses in any other category (To Do, In Progress) are treated as not resolved.
Custom required fields beyond the supported set	Vanta will prompt for many required custom fields. If Jira requires a field type Vanta can’t collect, issue creation may still fail. Use a simpler Jira project or adjust Jira field requirements.

Prerequisites and readiness checklist

Before connecting Jira to Vanta, complete every item in this checklist. Skipping these steps is the leading cause of connection failures and permission errors.

Who should connect: A Vanta admin, using a Jira user that has access to the projects you want Vanta to read. An Atlassian Organization Admin may need to enable User Installed Apps first, but the connecting Jira user only needs project-level permissions, not Jira admin access.

Create a service account (strongly recommended)
- Create a dedicated service user for the Jira connection (e.g., [email protected]) and grant it the permissions above.
- This is a recommended practice, not a hard requirement. Using a dedicated service user protects the integration if the connecting person leaves the company or has their Jira access changed. Use a real, monitored email inbox for the service account.
Enable User Installed Apps in Atlassian Organization Settings
- In admin.atlassian.com:
  - Select your organization
  - Expand Apps → Sites, then select your site
  - Click Connected apps → Settings
  - Set User Installed Apps to Allowed
  - Save
- Why this matters: If User Installed Apps is not enabled, the Accept button during the OAuth flow will be greyed out and the connection cannot be completed. This setting requires Atlassian Organization Admin access.
- Note: Navigation options may vary depending on your Atlassian version. The goal is to locate Connected Apps → Settings under your organization's site. For example, if you’re on Atlassian’s improved user management experience, go to Products → Select your site → Connected apps → Settings instead.
Grant Jira permissions - connecting user
- Permissions vary by project type. To identify your project type, check the Type column on the Projects page in Jira.
  Note: Terminology has evolved at Atlassian and these may be referred to as "Spaces" in some versions.

Company-managed projects

Grant the following at Project’s (Space's) Settings → Permissions:

Permission	Required for
Browse projects	Reading issue data (required)
Create issues	Creating issues from Vanta (required for write features)
Assign issues	Assigning issues from Vanta (required for write features)
Assignable user	Appearing as an assignee option in Vanta (required for write features)
Modify reporter	Selecting a reporter when creating issues from Vanta (optional — if the connecting user lacks this permission, the Reporter field will not appear in the issue creation modal)

Team-managed projects

Add the connecting user to the project with the appropriate role in Project’s (Space's) settings → Access:

Role	What Vanta can do
Member	Read data and create/assign issues (recommended)
Viewer	Read data only Vanta cannot create issues

Note: Vanta can connect with Browse Projects permission alone. Create Issues, Assign Issues, and Assignable User are only required if you want to create and assign issues from Vanta's test pages.

Readiness Checklist - quick reference

You have Vanta administrator access.
User Installed Apps is set to Allowed in Atlassian admin.
The connecting Jira user has Browse Projects permission on all projects Vanta should monitor.
(If using write features) The connecting Jira user Create Issues, Assign Issues, and Assignable User permissions.
(Optional) A dedicated service account has been created and granted the required permissions.
You know which project type(s) you are connecting (company-managed vs. team-managed).

Setup Guide

Here are the steps to get connected.

Step 1: Connect Jira in Vanta

In Vanta, navigate to Integrations.
Search for Jira in the Available tab.
Click View details.
Click Connect.
A Connected Jira Credentials modal will appear. Click Add Jira Credentials.
In the Link Jira modal, you can determine if you want to grant Vanta read and write access, or read access only.

Which access level should you choose?

Read and write (recommended): Lets you create Jira issues directly from Vanta tests. Choose this unless your security policy requires read-only.
Read only: Vanta monitors existing Jira issues but cannot create new ones from Vanta.

Then you must provide your Atlassian site URL.

How to find your Atlassian site URL:

Note: You may have a different version of Atlassian which may cause variation in the following setup steps or website screenshots.

Click on the 4-square icon in Atlassian.
Expand Jira.
Select the organization you want to connect.
That brings you to Jira. The URL there contains the site URL needed for the Link Jira modal in Vanta.
Click Connect Jira.

Step 2: Authorize the connection

Once you have completed the steps above (added the Atlassian URL and clicked Connect Jira), it will bring you to the following steps and screen.
Be sure the right organization is selected in the dropdown for Use app on.
Review the requested permissions.
Click Accept.
You should see: a redirect back to Vanta with Jira showing as Connected.

Notes:

If the Accept button is greyed out: Make sure you’ve enabled User Installed Apps in Atlassian Organization Settings, then retry.
If you manage multiple Atlassian sites: Make sure you are authorizing the correct site. Vanta connects to whichever site is active during the OAuth flow.

Step 3: Label your security issues in Jira

Vanta tracks any Jira issue labeled security (lowercase) or Security (capitalized) by default.

Add this label to any issue you want Vanta to pick up as compliance evidence.

Open an issue in Jira.
In the Labels field, select security or Security from the dropdown.
Repeat for any other issues you want Vanta to track.

Tip: You can add the security label to issues in bulk using Jira's bulk edit feature. You can also add it to new issues going forward as part of your team's workflow.

Using a different label? You can change the default in Vanta → Integrations → Jira → Manage → Task Tracking Labels.

Labels vs. JQL

Most teams should start with labels: add a label like security to the Jira issues you want Vanta to track, and configure that same label in Vanta.

If you need more control (for example, to filter by issue type or custom fields within your selected project), you can use a JQL rule instead of labels.

Example JQLs:

Only Bugs: issuetype = Bug
Bugs with a label: issuetype = Bug AND labels = security
By priority: priority = High AND labels = security

Step 4: Verify tasks are appearing in Vanta

In Vanta, navigate to Tests and filter the All resource monitoring tab by integration.
Select Jira as the integration filter.
Then click on any security-related test that appears (e.g. a test that tracks whether security issues are resolved within your SLA).
You’ll land on the results tab by default.
If Jira issues with your configured label are being pulled in, you’ll see them listed under a header like “{18} issues need remediation."

Don't see anything yet? Sync is not instant. Most issues appear within 1-2 hours of connecting, though it can take longer for very large Jira instances.

Notes:

Vanta pulls matching issues across any Jira projects the connected user can browse. To limit scope, restrict that user’s Jira project permissions or use JQL targeting.
If a project you expect is missing: Either the connecting user does not have Browse Projects permission for that project, or it was added to Jira after the connection was established. Reconnecting the integration will refresh the project list.
If no data appears after the initial sync window: Confirm the connecting user has Browse Projects permission for the expected projects and that those projects contain issues with your configured labels. See the t roubleshooting section for a full diagnostic guide.

Verification and validation

After setup, confirm the following to verify and validate that the integration is connected.

Note: allow time for the initial sync before checking. The first sync may take several minutes depending on the number of Jira issues.

Integration is active — In Vanta, go to your Integrations page and confirm Jira shows a Connected status. If the status shows as Disconnected, verify that the connecting user's Jira access has not been revoked and that User Installed Apps is still enabled in Atlassian admin.
Security tasks are pulling in — Open a security test in Vanta and go to the Tasks tab. Jira issues with your configured label should appear as linked tasks.
Issue creation works (requires write access) — From any failing test, go to the Tasks tab and create a Jira issue. Confirm it appears in your target Jira project with the test name in the summary and remediation instructions in the description. If you see a prompt to enable write access instead, the integration was connected in read-only mode — reconnect with write access enabled.
Status syncs back — Resolve an issue in Jira (move it to a status in the Done category). After the next sync cycle (typically within 30–60 minutes), confirm its status has updated to resolved in Vanta.
Automation is active (if configured) — Tests with active workflows show an Automated workflow button (with a bolt icon) in the test detail page header, under the Task automation metadata label. If automatic issue creation fails, Vanta displays a warning: "There was an error creating a Jira task. Contact support for help." This can happen if the connecting user's permissions have changed, the target project was deleted, or required fields were added after the workflow was configured.

Use cases and capabilities

This section covers each Jira integration use case: what it does, how it works, and how to configure it. Shared behaviors (how Vanta reads status, determines resolution, and maps priority) are defined once in the quick reference section below and apply across all use cases.

Quick reference

Use case	What it does	Key requirement
Security task tracking	Pulls labeled Jira issues into Vanta as compliance evidence	Issues must carry your configured label (default: security)
Manual issue creation	Create Jira issues from failing tests with pre-populated context	Write access enabled on the Jira connection
Automatic issue creation	Auto-creates a Jira issue when tests fail	Write access + workflow configured per test
Offboarding access tracking	Tracks whether access removal issues exist and are resolved within SLA	Departing employee’s email in issue title or description
Incident management tracking	Tracks incident management and resolution issues as compliance evidence	Issues must carry your configured incident labels

Reference: How Vanta reads Jira data

These behaviors apply to all use cases. They are defined here once and referenced throughout.

How Vanta determines an issue is resolved

Vanta marks an issue as resolved if either of the following is true:

The issue has a Resolution Date set in Jira, or
The issue's status category is Done

Either condition is sufficient. A custom status like Verified and Closed will be treated as resolved as long as its category is set to Done in your Jira workflow configuration.

How Vanta maps Jira status

Vanta reads the status category assigned to your Jira issue (not the custom status name) and maps it to one of these display statuses:

Jira status category	Examples	Vanta task status
To Do	Open, Backlog, To Do	Open
In Progress	In Progress, In Review, In Development	In progress
Done	Done, Closed, Resolved (or issue has a Resolution Date)	Completed

Why this matters: Jira lets you create unlimited custom workflow statuses, but every status must belong to one of three categories: To Do, In Progress, or Done. Vanta maps from the category, not the name. This way, a custom status like "Awaiting QA" maps to "In progress" as long as it's assigned to the In Progress category in your Jira workflow settings.

Note: The "In progress" status in Vanta only appears for Jira-linked tasks. Native Vanta tasks show only Open or Completed.

If a custom status isn't mapping correctly, go to Jira → Project Settings → Workflow and confirm the category assignment for that status.

Universal status behaviors for all use cases

Regardless of which use case you're using, the following behaviors apply:

Status reflects automatically. When an issue is resolved in Jira, Vanta picks this up on the next sync cycle and marks the associated task as completed, no action needed in Vanta.
Regression is handled. If a resolved issue regresses and the test fails again, Vanta surfaces it. If you have automatic issue creation configured, a new Jira issue is created automatically.
No duplicates. Vanta will never create a new issue if an open, unresolved linked issue for that test already exists at the test level.

How Vanta determines priority

Vanta checks for priority in the following order:

Jira’s default priority field: if a standard Jira priority value is present, Vanta uses this fixed mapping (see chart below).
P0–P3 labels: if no default Jira priority value is present, Vanta checks for a P0, P1, P2, or P3 label in the issue's Labels field as a fallback. Note: P4 is only available through the default priority field mapping; the label-based fallback supports P0 through P3 only.
Unrecognized priority names — custom priority names (e.g., "P1 - Critical" or "Urgent") are not recognized and will return null, even if the Jira priority field appears filled. To fix:
1. Option 1: Rename your Jira priority values to match the default names above
2. Option 2: Use a Jira Automation rule to automatically add a P0–P3 label when a custom priority is assigned (e.g., "If Priority = Critical, then add label p0")

Jira priority	Vanta priority
Highest	P0
High	P1
Medium	P2
Low	P3
Lowest	P4

The mapping is fixed and cannot be customized in Vanta.

How SLA is calculated

Vanta measures SLA compliance using two timestamps pulled directly from Jira:

Created At — when the issue was created in Jira
Resolution Date — when the issue was resolved

The elapsed time between these two timestamps is compared against the SLA timeframe defined in your Vanta SLA settings.

Important: Vanta evaluates whether the issue was resolved within the SLA window — not whether active work happened during that time. An issue created on day 1 but not worked on until day 28 of a 30-day SLA will still show as SLA-compliant if resolved by day 30. Conversely, an issue that remains open on day 31 will show as SLA-breached regardless of how much work was done.

Security task tracking

Vanta monitors your Jira projects for issues carrying a specific label and surfaces them as security tasks within your test results. This is the core compliance use case for the Jira integration.

How Vanta identifies security tasks:

By default, Vanta tracks Jira issues with the security label. You can configure a custom label or multiple labels in Vanta's Task Tracking Labels settings. Vanta only tracks issues that carry a recognized label — issues without a matching label are ignored regardless of project or content.

To change your configured label:

Go to the Integrations page in Vanta
Search for Jira and click View Details.
Then click Manage.
Then click Task Tracking labels.
In the modal, enter all labels you want Vanta to use to track security issues.
Click Save.

Where tasks appear in Vanta:

Security tasks linked to Jira issues appear in the Tasks tab on the relevant test page.

Manual issue creation from tests

When you create a Jira issue from a Vanta test page, Vanta pre-populates it with the context needed for the assignee to act immediately.

What Vanta populates at creation:

Summary: the name of the failing test
Description: what's failing, remediation instructions, and up to 10 failing resources
A link back to the Vanta test
Assignee (if selected)
Project (based on your selection)

Creation options:

One issue for the entire test
Individual issues per failing item within a test

How to create an issue from Vanta:

Navigate to the test detail page for the failing test and open the Tasks tab.
Click the Create task button. A modal will open.
Select your Jira connection (if you have multiple Jira credentials connected).
Choose the Project where the issue should be created.
Choose the Issue Type (e.g. Bug, Task, Story).
Optionally set an Assignee, Reporter, Due Date, and (if available for your Jira project) Epic and Sprint.
The summary and description are pre-populated by Vanta based on the failing test details.
Click Create. Vanta creates the issue in Jira and links it back to the test in Vanta.
On success, a confirmation toast appears. The new issue will appear in the Tasks tab with a link to the Jira issue.

Note: If your organization has Jira Software access, Epic and Sprint fields will be available during issue creation. If not, a banner explains that those fields require Jira Software permissions.

Fields not currently supported in Vanta’s Jira task creation:

Story points
Any Jira fields that are required in your Jira project but not supported in Vanta’s creation form (in those cases, Jira may block creation)

Reporter note: By default, Jira sets the reporter to the Jira user that connected the integration. If you want to choose a different reporter, the connected Jira user needs the MODIFY_REPORTER permission in the relevant Jira projects. If the connecting user lacks this permission on a given project, the Reporter field will not appear in the creation modal.

Automatic issue creation

Vanta can create Jira issues automatically when tests fail with no manual action required after initial configuration.

How to set up automatic issue creation

Navigate to the test you want to automate in Vanta.
Select the Tasks tab within the test.
Click the automated setup button.
Configure the following fields: project, issue type, assignee, and optionally epic and sprint (if available, these require Jira Software and may not appear for all project types).
Save the workflow.

Trigger condition

An issue is created automatically when all of the following are true:

The test is in a Failing state (automation does not trigger on Needs Attention tests).
No open, unresolved Jira issue linked to that test already exists at the test level.

If an open linked issue exists at the test level, Vanta does not create a duplicate. It waits until the existing issue is resolved or deleted before creating a new one if the test fails again.

Entity-level vs test-level: If open issues exist but are all linked to individual failing resources within the test (not to the test itself), Vanta will still create a new issue at the test level.

A new issue is also created if a previously linked issue is deleted in Jira, not just resolved.

How to identify auto-created issues

Tests with active workflows show an Automated workflow button (with a bolt icon) in the test detail page header, under the Task automation metadata label.

Reopened issue behavior

If a previously resolved Jira issue is moved back to an open or in-progress status:

Vanta detects the status change on the next sync cycle
The task returns to an open state in Vanta
A new automated issue will not be created because an open linked issue now exists at the test level

Note: If the automation setup button appears disabled after filling all visible fields, ensure your Jira project doesn't have standard fields (like Reporter or Priority) set as required without defaults.

Offboarding access tracking

Vanta tracks whether a Jira access removal issue exists for each offboarded employee and whether it was resolved within your SLA.

How Vanta links a Jira issue to a departing employee

Vanta looks for the departing employee's email address in one of two places:

Anywhere in the issue's title
Anywhere in the issue's description, using the format: Access task for: EMAIL_ADDRESS

At least one of these must be present for Vanta to associate the issue with the correct employee. If neither is present, the issue will not be linked and the offboarding check will show as incomplete.

In addition to label-based tracking, JQL queries can be used to define more custom targeting rules (for example, pulling issues from a specific Jira project regardless of label).

How Vanta determines the issue is resolved

Same as the shared reference above: Vanta marks it resolved if either a Resolution Date is set or the status category is Done.

SLA tracking

Vanta uses the Created At and Resolution Date timestamps to calculate whether the access removal issue was resolved within your policy's defined SLA window.

Tests powered by offboarding tracking

Ensure offboarded users have an associated access issue
Ensure access issues are resolved within the stated SLA

Offboarding a Jira user account

When the Jira integration is connected, all Jira user accounts are tracked on Vanta's Access page. To trigger offboarding for a Jira account in Vanta, you must remove the account from Jira, not suspend it.

Suspending a Jira account does not trigger offboarding in Vanta. Suspended accounts can be reactivated, which means access has not been fully removed. There is no workaround. Removal is required.

How to remove a Jira user account:

Go to admin.atlassian.com and select your organization.
Select Directory from the top-level menu.
You should be taken to a page listing your users — if not, select Users from the left-hand menu.
Find the user you wish to offboard and click their avatar or click ... → Show Details.
On the details page, click ... again and select Remove user.
You should see: The account removed from your Jira instance. Vanta will reflect the offboarding on the Access page after the next sync cycle.

Shared or service accounts: If an account should not be fully removed (e.g., a shared service account), an administrator can mark it as Not a Person in Vanta. When an actual person begins using the account again, an administrator can re-assign it.

Incident management tracking

Vanta tracks Jira issues used to manage and resolve security incidents, recording when each was opened and closed.

Vanta supports two distinct task types for incidents, each with its own configurable label:

Incident Management: tracks issues related to the incident response process
Incident Resolution: tracks issues related to the final fix or remediation

How Vanta identifies incident issues

You configure which issues Vanta should track using labels or JQL queries in Vanta's Task Tracking Labels settings (the same place you configure security labels). Vanta only pulls in issues that match your configured criteria.

How Vanta determines an incident is resolved

Same as the shared reference above: Resolution Date or status category Done.

Tests powered by incident tracking

Incident Resolution Tasks Completed
Incident Management Tasks Completed

Why this matters for auditors: Auditors expect incidents to occur. What they need to see is that when an incident was identified, it was managed and resolved according to your documented incident response policy. The timestamp data Vanta collects from Jira provides this evidence automatically.

Limitations and edge cases

The following are known constraints of Vanta's Jira integration that may affect automated issue creation and user offboarding workflows.

Limitation	Detail	Workaround
One issue per test (automated)	Automated issue creation creates one issue per failing test — not one per individual failing resource. The issue description includes details for up to 10 failing resources, but all are grouped into a single issue.	Create individual issues manually from the test page, which supports per-item issue creation.
Automated issue description is truncated	When an automated issue is created, the description includes a maximum of 10 failing resources. If the test has more than 10 failures, the remaining items are not listed in the Jira issue.	Review the full list of failures on the test detail page in Vanta.
Automation only triggers on Failing tests	Automated issue creation does not trigger on Needs Attention tests — only on Failing tests.	Monitor Needs Attention tests manually and create issues from the test page if needed.
Jira account must be deactivated or removed for offboarding recognition	Vanta checks the Jira account’s active status to determine whether access has been removed for terminated personnel. Accounts must be deactivated or deleted in Jira for Vanta to recognize them as deprovisioned. If a terminated user's Jira account remains active, the "Jira accounts deprovisioned when personnel leave" test will fail.	Deactivate or delete the user’s Jira account. Vanta will recognize the change on its next sync.

Permissions

For step-by-step instructions on granting these permissions, see prerequisites and readiness section.

Vanta permissions

Permission	Required for
Vanta Admin	Connecting, reconnecting, and managing the Jira integration

Jira permissions: company-managed projects

Permission	Required or optional	What happens without it
Browse Projects	Required	No data from this project appears in Vanta. No error is shown — the project is silently skipped.
Create Issues	Required for write features	Issue creation from Vanta fails with an error when attempting to create in that project.
Assign Issues	Required for write features	Issues are created without an assignee
Assignable User	Required for write features	The connecting user cannot be selected as an assignee option in Vanta
MODIFY_REPORTER	Optional	The Reporter field does not appear in the issue creation modal. All Vanta-created issues default the reporter to the connecting user.

Jira permissions: team-managed projects

Role	What Vanta can do	What’s limited
Member	Read data, create issues, assign issues	(full access)
Viewer	Read data only	Cannot create or assign issues. No error is shown, the option is simply unavailable.

Key behaviors:

Permissions are tied to the connecting user. Vanta can only access what that user can access in Jira. If their permissions change, the integration is affected immediately — no restart or reconnect is needed for the change to take effect.
To reconnect or update the connecting user without losing existing data and configurations: go to Integrations → Jira → Manage, then follow the reconnection flow.

Troubleshooting and FAQs

Common questions and issues you may encounter when setting up or using Vanta's Jira integration, along with recommended solutions.

Before contacting Support: To reduce resolution time, collect the following before reaching out:

The connecting user’s email address
Your Atlassian site URL
The affected project name or key
A screenshot of any error message

Archived projects

Q: If a project is archived, does Vanta continue displaying previously synced issues?

A: Jira's API does not return issues from archived projects. Previously synced issues remain in Vanta's database as historical data, but they will not be updated on subsequent sync cycles. They should continue to appear in historical task records but will become stale.

Deleted issues

Q: What happens to a deleted Jira issue in Vanta?

When a Jira issue is deleted in Jira, Vanta can no longer retrieve it from the Jira API. On the next sync cycle, the task will show as Not found in Vanta.

Q: If a deleted issue was linked to a passing compliance test, does the test revert to failing?

No. Test results in Vanta are determined entirely by the test's own evaluation logic (e.g., whether the required evidence or configuration is in place) — they are not affected by the status of linked tasks. Deleting an issue only impacts whether Vanta considers the failure as having an active remediation task — not whether the test passes or fails.

Historical sync on first connection

Q: Does Vanta pull all historical issues?

A: Yes — on first sync, Vanta pulls all matching issues regardless of creation date. Subsequent syncs are incremental and only fetch recently updated issues

Q: If an issue was created, resolved, and closed before the integration was connected, will Vanta recognize it as completed historical evidence?

A: Yes. A resolved issue fetched during the initial sync will have its resolution date present, and Vanta will recognize it as completed historical evidence.

Renamed or moved projects

Q: If a project is renamed or its key changes, does the connection break?

A: No. Jira project IDs are stable across renames and key changes. The connection continues working without any action.

Connection and setup

Q: The Accept button is greyed out during OAuth

Go to admin.atlassian.com → your site → Connected apps → Settings
- Improved user management experience: Products → select your site → Connected apps → Settings
Set User Installed Apps to Allowed
Return to Vanta and retry the connection

Escalate if: User Installed Apps is already set to Allowed and the button is still greyed out.

Q: Error: "No resources for fetch where we require at least one resource" or "OAuth grant has no accessible resources"

Cause: The wrong Atlassian account was used during authorization, or a cached session is connecting to the wrong site.
- Disconnect the Jira integration in Vanta
- Open an incognito or private browser window
- Reconnect via Integrations → Jira → Manage → Edit → Connect Jira
- Sign in as the correct connecting user and confirm you're authorizing the correct Atlassian site

Escalate if: The error persists after retrying in incognito with the correct account.

Q: The Jira integration disconnected unexpectedly

Cause: The connecting user's password, MFA, or Jira access changed.
Reconnect via Integrations → Jira → Manage → Edit → Connect Jira.
- Prevent recurrence: Use a dedicated service account to connect the integration so personal account changes don't affect it.

Escalate if: The integration reconnects but disconnects again with 24 hours.

Issue creation

Q: Issue creation fails with a required fields error

Vanta automatically detects required custom fields for your target Jira project and surfaces them in the creation modal. Fill them in and click Create.
If a field type is not supported by Vanta:
- Option 1: Make the field optional in Jira → Project Settings → Fields
- Option 2: Use a dedicated Jira project with no custom required fields as your Vanta destination, then use a Jira Automation rule to route or enrich issues after creation

Escalate if: The field cannot be made optional and the field type is unsupported.

Q: The reporter on Vanta-created issues can't be changed

Cause: The connecting user needs the MODIFY_REPORTER permission on the target project. You may also need to reconnect the integration for the change to take effect.
- Grant MODIFY_REPORTER in Jira → Project Settings → Permissions
- Reconnect the integration: Integrations → Jira → Manage → Edit → Connect Jira
- Note: MODIFY_REPORTER must be granted in every Jira project you intend to create issues in, not just one.

Sync and status

Q: Security tasks are not appearing in Vanta. Work through these steps in order before escalating:

Step 1: Check the label. The issue must have the security label (or your configured custom label) in Jira's Labels field, not in a comment, description, or custom field.
Step 2: Check Browse Projects permission. The connecting user needs Browse Projects permission on every project you want Vanta to monitor. Go to Jira → Project Settings → Permissions to verify.
Step 3: Check for an Issue Security Scheme. Go to Jira → Project Settings → Issue Security. If a scheme is active, the connecting user must have explicit access within the scheme. Browse Projects alone is not sufficient for restricted issues. This is the most commonly missed step.
Step 4: Confirm projects, not boards. Vanta connects to Jira projects, not boards. If you're expecting issues from a board that spans multiple projects, confirm the connecting user has Browse Projects permission on every underlying project.
Step 5: Reconnect in incognito. If all steps above check out, try reconnecting in an incognito or private browser window to rule out cached session data.
Escalate if: All steps check out and tasks still aren’t appearing after 60 minutes.

Offboarding

Q: An offboarded employee isn't being linked to their access issue or still showing as active.

This issue has two distinct causes. Work through them in the following order:

Cause 1: The account was not deactivated or removed

Accounts must be deactivated or deleted in Jira for Vanta to recognize them as deprovisioned. If the account is still active, the "Jira accounts deprovisioned when personnel leave" test will fail.
Fix: Deactivate or remove the account from Jira entirely via admin.atlassian.com → Directory → Users → find user → Deactivate or Remove user. See Offboarding a Jira User Account in the Use Cases section for the full step-by-step.

Cause 2: The access issue isn’t linked to the employee

Vanta links issues to employees using their email address. Confirm it appears in one of these two places:
- Anywhere in the issue title — e.g., Offboard access for [email protected]
- Anywhere in the issue description — using the format: Access task for: [email protected] (note: Vanta looks for a valid email address anywhere in the title or description. The recommended format is Access task for: EMAIL_ADDRESS.)
The link will register on the next sync cycle after the email is added.

If neither fix resolves it – sync delay

Offboarding changes may take longer than standard sync cycles to appear in Vanta due to rate limits and organization size. Wait a few hours before escalating.

Escalate if: More than a few hours have passed and the account still shows as active. Contact Vanta Support and include a screenshot confirming the account no longer exists in your Jira instance.

Jira: Integration Guide