Ticketing Integration

Connect TATER to Jira or ServiceNow to automatically create tickets for failing compliance controls and remediation tasks — so security findings flow directly into your team's existing workflow without manual copy-paste.

Why Use Ticketing Integration?

Compliance findings that live only in TATER rarely get fixed. The people who need to remediate a failing control — system administrators, IT engineers, developers — live in ticketing systems: Jira boards, ServiceNow queues, sprint planners. Without a direct connection between the compliance finding and the work queue, findings get lost, progress is tracked in two places (or neither), and remediation timelines slip.

TATER's ticketing integration eliminates this gap. When a control fails, you can create a fully populated ticket in your ITSM platform with a single click. The ticket includes the control description, the specific audit finding, the remediation steps, and a link back to TATER — everything an engineer needs to understand what to fix and how to fix it. The ticket ID is stored in TATER so you can track resolution progress without leaving the compliance view.

Jira Integration

Prerequisites

Before configuring the Jira integration, you will need:

• A Jira Cloud account with a project where tickets will be created. Jira Data Center (self-hosted) is also supported if it is accessible via HTTPS from the internet.
• A Jira API token. Generate one at id.atlassian.com/manage-profile/security/api-tokens. Tokens are scoped to the account that creates them.
• The email address associated with the Atlassian account used to generate the token.
• OrgAdmin or higher role in TATER to configure the integration.

Configuring the Jira Integration

1. In TATER, navigate to Settings > Integrations
2. Locate the Jira section and click Configure
3. Complete the configuration form with the following fields:

Field	Description	Example
Jira Base URL	Your Jira instance URL. For Jira Cloud, this is your Atlassian domain. Do not include a trailing slash.	https://yourcompany.atlassian.net
Project Key	The short code for the Jira project where tickets will be created. Found in the project settings or in any existing issue key (e.g., the "SEC" in "SEC-142").	SEC
Issue Type	The Jira issue type for created tickets. Use whatever type your team tracks remediation work under. Common values: Task, Bug, Story, Improvement.	Task
Username / Email	The email address of the Atlassian account associated with the API token. Used for Basic authentication.	security@yourcompany.com
API Token	The Jira API token generated from your Atlassian account settings. Stored encrypted at rest using AES-256-GCM. Never displayed after saving.	(paste token here)
Default Assignee	Optional. The Jira account ID of the user to assign new tickets to by default. If left blank, tickets are created unassigned. You can find a user's account ID in Jira's user management settings.	5c7f3a2b...
Labels	Optional. A comma-separated list of labels applied to all TATER-created tickets. Useful for filtering in Jira. TATER automatically adds the label tater-compliance regardless of this setting.	security, compliance, cis

4. Click Test Connection to verify that TATER can authenticate to Jira with the provided credentials. The test creates a minimal API request (fetching the project metadata) without creating any issues.
5. If the test succeeds, click Save. If it fails, see the Troubleshooting section.

What Jira Tickets Look Like

When TATER creates a Jira ticket for a failing control, it populates the following fields:

Jira Field	Value
Summary	[TATER] {ControlId}: {ControlTitle} Example: [TATER] ENT_047: Conditional Access Policy for All Users
Description	Full control description, the specific audit finding, the audit procedure (how to verify), remediation steps from the catalog, the scan date when the failure was recorded, risk level, framework mapping, and a direct link back to the TATER control detail page.
Issue Type	The type configured in Settings (e.g., Task, Bug)
Priority	Mapped from TATER risk level: Critical → Highest, High → High, Medium → Medium, Low → Low (see Priority Mapping)
Labels	tater-compliance plus any labels configured in Settings
Assignee	The default assignee configured in Settings (if any)

After the ticket is created, TATER stores the Jira issue key (e.g., SEC-142) in the control record. This key is displayed in the control detail panel so your team can navigate directly to the Jira issue, and it is included in compliance reports that reference the ticket status.

ServiceNow Integration

Prerequisites

Before configuring the ServiceNow integration, you will need:

• A ServiceNow instance (any tier: Developer, Express, or Enterprise). The instance must be accessible via HTTPS from the internet.
• A ServiceNow user account with sufficient permissions to create records in the target table (typically incident or change_request). A dedicated integration service account is recommended.
• The username and password for that service account.
• OrgAdmin or higher role in TATER to configure the integration.

Configuring the ServiceNow Integration

1. Navigate to Settings > Integrations
2. Locate the ServiceNow section and click Configure
3. Complete the configuration form:

Field	Description	Example
Instance URL	Your ServiceNow instance URL. Do not include a trailing slash or /api/ path.	https://dev12345.service-now.com
Username	The ServiceNow username of the integration service account.	tater-integration
Password	The service account password. Stored encrypted at rest. Never displayed after saving.	(service account password)
Table Name	The ServiceNow table where records are created. Use incident for incidents or change_request for change management tickets. Custom tables are supported if they exist in your instance.	incident
Assignment Group	Optional. The ServiceNow group name to assign new records to. Must match the group name exactly as it appears in ServiceNow.	Security Operations
Category	Optional. The category field value for created records (typically mapped to your IT service catalog).	Security
Subcategory	Optional. Subcategory for further classification within the category.	Compliance

4. Click Test Connection to verify authentication and table access.
5. Click Save if the test succeeds.

What ServiceNow Records Look Like

TATER maps compliance control data to ServiceNow fields as follows:

ServiceNow Field	Value
Short Description	[TATER] {ControlId}: {ControlTitle}
Description	Full control description, finding note, audit procedure, remediation steps, scan date, TATER deep link
Urgency	Mapped from TATER risk level: Critical → 1 (High), High → 2 (Medium), Medium → 3 (Low), Low → 3 (Low)
Category	Value from the Category field in Settings, or Security if not configured
Subcategory	Value from the Subcategory field in Settings
Assignment Group	Value from the Assignment Group field in Settings
Work Notes	Framework mappings, CIS level, authority, and compliance zone for the control

After creating a record, TATER stores the ServiceNow record number (e.g., INC0010142) in the control record for reference.

Creating Tickets From Controls

Single Control Ticket

To create a ticket for a single failing control:

1. Open any scan result, the Controls page, or the dashboard failing controls list
2. Click the control name to open the detail panel
3. In the detail panel, click Create Ticket
4. A confirmation dialog shows you the ticket title, the destination (Jira or ServiceNow), the project or table, and the assignee
5. Click Confirm to create the ticket
6. The Jira issue key or ServiceNow record number is immediately displayed and stored in the control record

If a ticket already exists for this control (from a previous creation), TATER shows a warning and asks whether you want to create a duplicate or open the existing ticket instead.

Bulk Ticket Creation

To create tickets for multiple failing controls at once:

1. Open a scan result and switch to the Failing Controls view
2. Use the checkboxes on the left side of the control list to select the controls you want to ticket. A "Select All" checkbox at the top selects the entire filtered view.
3. With one or more controls selected, the Bulk Actions toolbar appears at the bottom of the screen
4. Click Create Tickets from the bulk actions menu
5. A summary dialog shows the number of tickets to create, the destination platform, and any controls that already have tickets (which will be skipped by default)
6. Click Create N Tickets to confirm

Bulk ticket creation runs sequentially to avoid overloading the target system's API rate limits. Progress is shown in real time. If any individual ticket creation fails, the error is displayed and the remaining tickets continue to be created.

Mapping TATER Severity to Ticketing Priority

TATER assigns a risk level to each compliance control based on the framework's severity classification. When creating tickets, this risk level is mapped to the target platform's priority field:

TATER Risk Level	Jira Priority	ServiceNow Urgency
Critical	Highest	1 — High
High	High	2 — Medium
Medium	Medium	3 — Low
Low	Low	3 — Low
(unrated)	Medium	3 — Low

These defaults reflect a conservative mapping: Critical compliance failures are the most urgent, but even Low risk findings map to a defined priority level rather than being created with no priority. Your team can always adjust the priority on individual tickets in Jira or ServiceNow after creation if the mapping does not fit your team's conventions.

Troubleshooting

Authentication Failures

If the Test Connection button shows an authentication error:

• Jira: Verify that the email address matches the Atlassian account that owns the API token. The email and token must belong to the same account. Also confirm the base URL is correct — for Jira Cloud it must include .atlassian.net. API tokens from one Atlassian account cannot be used with a different account's email address.
• ServiceNow: Confirm that the username and password are correct for the ServiceNow instance, and that the instance URL does not have a trailing slash. If your ServiceNow instance uses SSO for user logins, the service account may need to be configured specifically for Basic authentication (check your ServiceNow admin settings under User Administration > Users and ensure Web service access only is not checked if it restricts the account's access to table APIs).

SSL Certificate Errors

TATER validates the SSL certificate of the target system. This is a security requirement to prevent credential exposure. If your Jira or ServiceNow instance uses a self-signed certificate or a private CA, the integration will fail with an SSL error. To resolve:

• For Jira Cloud instances (atlassian.net), this should not occur as Atlassian uses publicly trusted certificates.
• For Jira Data Center or ServiceNow instances using private certificates, contact TATER support to discuss certificate authority configuration options for your deployment.

Field Mapping Errors

Some Jira projects have required fields beyond the standard summary and description. If your project requires fields like "Epic Link", "Sprint", "Story Points", or custom fields marked as required, ticket creation will fail with a field validation error from the Jira API.

To resolve field mapping errors in Jira:

1. In Jira, navigate to your project settings and review the issue creation screen (the screen shown when creating a new issue of the configured type)
2. Identify any fields marked as required that TATER does not populate
3. Consider removing the required constraint from those fields for the TATER integration use case, or configure default values for required fields at the project level (Jira allows per-field default values in project settings)

Rate Limits

Both Jira Cloud and ServiceNow enforce API rate limits. Bulk ticket creation for large numbers of controls may be slowed by these limits. TATER automatically detects HTTP 429 (Too Many Requests) responses and applies an exponential backoff delay before retrying. This means bulk operations on large scan results may take several minutes to complete — this is expected and does not indicate an error.

If your Jira or ServiceNow administrator has configured unusually strict rate limits, consider breaking large bulk operations into smaller batches by using the severity filter to ticket one severity level at a time.

Tickets Created But Not Visible in TATER

If a ticket was created successfully in Jira or ServiceNow but the ticket reference is not showing in the TATER control record, the most common cause is a browser refresh that interrupted the response. Navigate to the control detail panel, click the refresh button, and check whether the ticket reference now appears. If it does not, check your Jira or ServiceNow instance to confirm whether the ticket was actually created before attempting to create it again.

Rotating Credentials

When you rotate your Jira API token or ServiceNow password:

1. Generate the new credential in Jira or ServiceNow first
2. Navigate to Settings > Integrations in TATER
3. Click Configure on the relevant integration
4. Enter the new token or password in the credential field
5. Click Test Connection to confirm it works
6. Click Save

Existing ticket references stored in TATER (Jira issue keys, ServiceNow record numbers) are not affected by credential rotation.

Credential Security

TATER takes several measures to protect your ticketing credentials:

• Encryption at rest: API tokens and passwords are encrypted using AES-256-GCM before storage in Cosmos DB. The encryption key is configured separately on the API server and is never stored alongside the encrypted data.
• No plaintext in responses: Credential fields are never returned to the browser. Once saved, credentials are write-only from the browser's perspective.
• SSRF protection: The Jira base URL and ServiceNow instance URL are validated to prevent Server-Side Request Forgery attacks. Only public HTTPS URLs are accepted; private IP ranges, loopback addresses, and non-HTTPS URLs are rejected.
• Credential isolation: Credentials are scoped to the organization that configured them. Members of one organization cannot access another organization's ticketing credentials, even if they are a member of both organizations.
• Role restriction: Only OrgAdmin and above can view or modify integration settings. Viewer and Auditor roles can see that integrations are configured (e.g., that a ticket exists for a control) but cannot read credentials or reconfigure the integration.