Jira Cloud Integration

This page covers the Jira Cloud integration (regscale jira) only. For on-prem Jira Server / Data Center, see the separate Jira Data Center page.

The regscale jira command group performs bulk processing and ticket assignment between RegScale and Jira Cloud (*.atlassian.net). It cross-links RegScale and Jira IDs, syncs attachments both ways, and is designed for automated, scheduled assignment of RegScale issues/tasks to Jira and vice versa. Authentication uses an Atlassian account email + API token.

Commands

Command	Description
`regscale jira issues`	Bidirectionally sync issues between RegScale and Jira.
`regscale jira tasks`	Bidirectionally sync tasks between RegScale and Jira (Jira issue type is fixed to `Task`).

`regscale jira issues` options

Option	Alias	Type	Required	Default	Description
`--regscale_id`		int	yes		ID of the RegScale record the issues belong to.
`--regscale_module`		str	yes		RegScale module of that record (e.g. `securityplans`). See RegScale Modules.
`--jira_project`	`-j`	str	yes	(prompted)	Jira project key/name to sync against.
`--jira_issue_type`	`-i`	str	yes	(prompted)	Jira issue type to use when creating new issues. Case sensitive. See Jira issue types.
`--sync_attachments`		bool	no	`True`	Sync attachments in both directions, de-duplicating so files match in both systems.
`--token_auth`	`-t`	flag	no	`False`	Use token (Bearer) authentication instead of basic auth.
`--jql`		str	no		Custom JQL query to select Jira issues. Overrides the project/issue-type query.
`--poams`	`-p`	flag	no	`False`	Create/update the incoming Jira issues as POA&Ms in RegScale.
`--dry_run`		flag	no	`False`	Print the count of items that would sync (as JSON) without writing anything.
`--offset`		int	no		Skip this many Jira items from the start.
`--limit`		int	no		Process at most this many Jira items.

`regscale jira tasks` options

Same as issues, except there is no --jira_issue_type (it is hardcoded to Task) and no --poams.

Jira issue types

--jira_issue_type takes the name of an issue type as it exists in your Jira Cloud project. Issue types are defined per-project in Jira, not by RegScale — the CLI passes your string through and validates it against the project's available types before syncing, aborting with a clear message if it is not found.

Two rules govern what you can pass:

Case sensitive — the value must match Jira exactly. Bug works; bug does not.
It must exist in the target project — the authoritative list is in Jira → Project settings → Issue types for that specific project (or via the Jira createmeta REST endpoint).

Default Jira Cloud issue types by project type

The defaults depend on how the Jira project was created:

Project type	Default issue types
Software (company-managed)	`Epic`, `Story`, `Task`, `Bug`, `Subtask`
Software (team-managed)	`Epic`, `Story`, `Task`, `Bug`, `Subtask` (fully customizable)
Business / Work Management (company-managed)	`Task`, `Subtask` — templates may add `Epic`, `Story`, etc.
Service Management (JSM)	`[System] Incident`, `[System] Service request`, `[System] Service request with approvals`, `[System] Change`, `[System] Problem`

Notes on specific types

Type	Notes
`Task`	Generic work item. This is the value the `jira tasks` command uses automatically.
`Bug`	Standard software defect.
`Story`	Agile user story.
`Epic`	Large body of work containing stories.
`Subtask` / `Sub-task`	A child issue type. Jira cannot create these standalone, so they are not usable for issue/task sync.
`[System] Incident`	Default JSM incident type — the `[System]` prefix is literal and must be typed exactly.
`[System] Service request` / `[System] Change` / `[System] Problem`	Other default JSM types, prefix included.

Your instance may rename these defaults or define custom issue types. Always confirm the exact names in your project's settings and pass them verbatim. If RegScale reports the type is invalid, it is not present in the target project.

Priority → RegScale severity mapping

When a Jira issue is imported, its priority is mapped to a RegScale IssueSeverity:

Jira priority	RegScale severity
`Blocker`, `Critical`	Critical (`0 - Critical - Must be Fixed`)
`Highest`, `High`	High (`I - High - Significant Deficiency`)
`Major`, `Medium`, `Moderate`	Moderate (`II - Moderate - Reportable Condition`)
`Low`, `Lowest`, `Minor`, `Trivial`	Low (`III - Low - Other Weakness`)
(none/unrecognized)	Low

Outbound (RegScale → Jira) severity is sent as the simple labels Critical / High / Medium / Low.

Status mapping

Jira status Done closes the RegScale record (sets status Closed and the completion date). For tasks: To Do → Backlog, In Progress → Open, Done/Closed → Closed, Cancelled/Canceled → Cancelled; anything else defaults to Open.

Issue processing workflow

Log into RegScale via the CLI (regscale login) to set the 24-hour access token, or use a service account. See the CLI Login docs.
Run the command with the flags above.
The CLI retrieves all existing RegScale issues for the given regscale_id / regscale_module.
The CLI retrieves all matching Jira issues (paging 100 at a time until all are retrieved, via /rest/api/3/search/jql with nextPageToken pagination).
For each Jira issue:
- If it has no matching RegScale issue → a RegScale issue is created and linked.
- If RegScale has issues not yet in Jira → a Jira ticket is created and the RegScale issue is updated with the new Jira ID.
- If the issue exists in both → the records are compared and updated.
- When --sync_attachments is true → attachments are compared and synced both ways to prevent duplication.

Detailed logging is emitted throughout for progress and troubleshooting.

Init.yaml configuration

Key	Required	Default	Description
`jiraUrl`	yes		Base URL of your Jira Cloud instance, e.g. `https://team-99999999.atlassian.net`.
`jiraUserName`	yes		Atlassian account username (email).
`jiraApiToken`	yes		API token generated for that user (sensitive).
`jiraDefaultIssueType`	no	`Task`	Default issue type.
`jiraDefaultPriority`	no	`Medium`	Default priority.
`maxThreads`	no	`1000`	Max threads for bulk processing. Tuning can help or hurt performance.
`jiraCustomFields`	no	`{}`	Map of Jira custom field IDs → RegScale Issue attribute names.

Creating an API token: In Jira, click the Settings icon → Atlassian Account Settings → Security tab → Create or Manage API Token → Create API Token. Copy it into init.yaml.

The issues.jira block in init.yaml controls remediation SLAs (days until due) and the default status for newly created issues:

issues:
  jira:
    highest: 7
    high: 30
    medium: 90
    low: 180
    lowest: 365
    status: Open

Example `init.yaml`

domain: https://mycompany.regscale.com
token: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVC...
maxThreads: 1000
userId: c9f579e2-a8c9-4c02-8e91-ce122a1aa518
jiraUrl: https://team-99999999.atlassian.net
jiraUserName: [email protected]
jiraApiToken: 99rtYi34trydt345ynb

Examples

regscale login

Sync issues for a System Security Plan:

regscale jira issues --regscale_id=5 --regscale_module="securityplans" --jira_project="AT" --jira_issue_type="[System] Incident"

Sync tasks:

regscale jira tasks --regscale_id=5 --regscale_module="securityplans" --jira_project="AT" --sync_attachments True

Create incoming Jira issues as POA&Ms in RegScale:

regscale jira issues --regscale_id=5 --regscale_module="securityplans" --jira_project="AT" --jira_issue_type="Bug" --poams

Bash script example

#!/bin/sh
regscale login
regscale jira issues --regscale_id=5 --regscale_module="securityplans" --jira_project="AT" --jira_issue_type="Bug"

Run with . regscaleScheduler.sh. Chain any sequence of CLI commands to run them in order.

Custom filtering with JQL

issues and tasks accept a --jql option using full Jira Query Language:

regscale jira issues --regscale_id=1 --regscale_module=securityplans --jira_issue_type=Bug --jira_project=project1 --jql="project=project1 AND priority=High AND status=Backlog"

Important: When --jql is supplied, the integration does not implicitly scope to --jira_project. If you do not name a project in the JQL, it searches all projects. Include project=<key> in your JQL to scope it.