Create Jira and ServiceNow Tickets for Security Incidents

Tasks

Create one Jira Cloud issue or ServiceNow record for a security incident, with its plain-English title, why it matters, the recommended action, MITRE techniques, severity and a link back to the incident.

Before you start

• You need the admin role to configure destinations and to create tickets.
• For Jira Cloud, create an API token for a service account that can create issues in the project. You need the site URL, the account email and the project key.
• For ServiceNow, create an integration user, or an OAuth application registry entry for the client credentials flow, with write access to the table you use (incident, or sn_si_incident for Security Incident Response).
• Set ui.publicURL if you want each ticket to link back to the incident.
• The base URL must have no path and use HTTPS (HTTP only for a loopback address) and cannot contain a query string, fragment or user info. Cloud metadata and link-local addresses are refused.
• Know what a ticket contains. It never contains evidence content, prompts, responses, the triage note or credentials. Finding summaries are added only to a destination where you turn on Include finding summaries; credentials and personal data are redacted first, and everything else in a summary is sent as is.

Configure the destinations

1. Go to Integrations → Security tickets and select Add destination. You can add up to 10, each with its own filters.
2. Enter a unique Name and choose the System, then enter the Base URL, such as https://your-site.atlassian.net.
3. For Jira Cloud, enter the account email, API token and project key. Optionally set the issue type (Task when empty), custom fields (a field ID such as customfield_10010 and a text value), a Jira priority name for each severity (Highest, High, Medium and Low when empty) and extra labels. Every issue also gets the aicontrols label.
4. For ServiceNow, choose Username and password or OAuth client credentials and enter the credentials. Optionally set the table (incident when empty), an assignment group (its 32-character sys_id), and urgency, impact and priority for each severity. Urgency and impact default to 1/1 for critical, 1/2 for high, 2/2 for medium and 3/3 for low; priority is left to your instance unless you set it.
5. The Severity filter and optional Event types decide which incidents this destination receives from Create ticket for all destinations and from automatic creation.
6. Choose Automatic creation. The default is Off. When you turn it on without a severity filter, only critical incidents get a ticket.
7. Optionally turn on Redact actors to leave user, agent and assignee identities out of the ticket, or Include finding summaries. Both are off by default.
8. Turn the integration on, select Send Test, then Save. The test proves the credentials with a read-only request and creates no ticket. The credentials are hidden after you save; leave them as shown to keep them.

Create a ticket

1. Go to Security → Activity → Correlated findings and open an incident.
2. Choose All matching destinations or one destination, then select Create ticket. The drawer shows each destination's ticket as a link, with when and by whom it was created. A viewer sees the links but not the button.

An incident has at most one ticket per destination. Selecting Create ticket again links the existing ticket and does not call Jira or ServiceNow. A destination you choose by name ignores its filters. If one destination fails, the others still get their tickets and the drawer names the one that failed; try again once the cause is fixed.

A ticket is not updated when you acknowledge, assign or resolve the incident. The ticket link is carried on later OCSF exports of the incident, in tickets.

Create tickets automatically

With Automatic creation on, every few minutes the product creates a ticket for each open incident seen in the last 24 hours that is at or above the destination's severity (critical when no filter is set) and matches its event types, if it has no ticket there. Each incident is claimed once per destination across all replicas. A failed attempt is retried after about 10 minutes, until the incident leaves the 24-hour window.

Check what was created

Every attempt is recorded in Security → Activity → Configuration as security_incident.ticket_created, with the actor (system for automatic creation), the trigger, the destination name and host, the ticket key and link, the attempt count, and whether it succeeded. A failure records a short reason such as http_403, never the response from the ticket system. Scrape aicontrols_security_ticket_total to alert on failures. See Security Incident Tickets for the settings and the API.

Troubleshooting

Reason	Cause
http_401 or http_403	The credentials are wrong or lack permission. Send a test.
http_400	The ticket system rejected a field. For Jira, check the project key, issue type, priority names and custom fields. For ServiceNow, check the table, assignment group and priority values.
http_404	The base URL, project or table does not exist.
network_error or timeout	The ticket system is unreachable from AIControls. After a timeout the ticket may exist; check the ticket system before you try again.
Reference not recorded	A ticket may have been created but its record is missing (after a timeout or a 5xx, or a failed save). Nothing is created again for 34 days; find the ticket in Jira or ServiceNow.