TigerGate can push scan results, quality-gate failures, critical findings, and compliance and runtime events to the tools your team already uses. Notification channels are configured per organization, and delivery is retried automatically on failure. Configure them under Integrations → Notifications & Destinations. The page has four tabs: Notification Channels, Event Destinations, Ticket Rules and Issue Tracker.

Notification channels

On the Notification Channels tab, choose Add Channel, pick a type, give it a name, and enter its configuration. Each configured channel has Edit, Test, and remove actions.
ChannelConfiguration
SlackIncoming webhook URL, plus an optional bot token
Microsoft TeamsIncoming webhook URL
EmailRecipient list, plus optional SMTP host / port / username / password (leave the SMTP fields blank to use the platform default server)
PagerDutyAPI key, plus an optional Events API v2 routing key (used for critical incident paging)
Custom WebhookEndpoint URL, plus an optional signing secret
If you set a signing secret on a Custom Webhook, TigerGate adds an X-TigerGate-Signature header to each request so you can confirm the payload came from TigerGate.

Issue tracker

The Issue Tracker tab connects a ticketing system so your team can create tickets directly from security findings.
ProviderConfiguration
JiraConnect to Jira authorizes the TigerGate app on your Atlassian site (OAuth), then you choose the site, project and default issue type
GitHub IssuesPersonal access token (or the connected GitHub App installation), repository, default issue type
LinearAPI key, team ID, optional default issue type
ServiceNowInstance URL, an integration user or an OAuth client, the table, and optional assignment group, category and severity mapping
Secrets are write-only. They are stored encrypted and never shown again; leave a secret field blank on save to keep the stored value. Only owners and admins can change the configuration. Test connection checks the saved configuration against the tracker. A finding’s Create Ticket action files the ticket and links it to the finding. For Jira and ServiceNow, the finding’s panel also shows the ticket’s live status, assignee and priority. That is read-only in both directions: closing the ticket does not close the finding.

ServiceNow

ServiceNow tickets are records created through the Table API on your instance. The default table is incident.
SettingWhat it does
Instance URLhttps://<instance>.service-now.com. HTTPS only. Enter just the instance name and .service-now.com is added for you. The host must resolve to a public address.
AuthenticationIntegration user (basic auth with a username and password) or OAuth client credentials (the client ID and secret of an Application Registry entry that allows the client credentials grant). TigerGate fetches a fresh OAuth token for each operation and never stores it.
TableThe table tickets are filed in: incident, or another task table such as sn_si_incident for Security Incident Response. The user or OAuth client must be able to read and create records in it. On incident, the itil role covers this.
Assignment groupOptional. A group name, which TigerGate looks up in sys_user_group when it files a ticket, or the group’s sys_id.
CategoryOptional. The category’s stored value, for example security, not its display label.
Severity mappingThe impact and urgency each finding severity is filed with. ServiceNow derives the priority from the two.
The default severity mapping follows ServiceNow’s standard priority matrix:
Finding severityImpactUrgencyResulting priority
Critical1 - High1 - High1 - Critical
High1 - High2 - Medium2 - High
Medium2 - Medium2 - Medium3 - Moderate
Low3 - Low2 - Medium4 - Low
Info3 - Low3 - Low5 - Planning
Test connection reads one record from the table (GET /api/now/table/incident?sysparm_limit=1) and confirms that the assignment group exists. Each ticket gets a short description (the finding title, up to 160 characters), a description with the finding’s details (and a link back to the finding when it is filed from the console), and a correlation_id that identifies the finding. The record’s number (for example INC0010023) and its link appear on the finding. TigerGate makes HTTPS calls only to the instance URL you configured, and never follows redirects.

Event destinations and ticket rules

The Event Destinations tab streams Data Security (DSPM) and Runtime Security events to a SIEM, XDR, SSE or workflow tool: a signed webhook, Splunk HEC, Microsoft Sentinel, syslog or CEF over TLS, or a notification channel. The Ticket Rules tab opens a ticket in the connected tracker for every new or reopened Data Security Finding that matches a rule. Both are described in Data Security integrations.

Events

Once at least one channel is configured, TigerGate delivers alerts for:
EventWhen
Scan resultsA scan finishes
Quality-gate failuresA scan trips a configured quality gate
Critical findingsA new critical finding is detected
Compliance reportA scheduled compliance report is generated
Compliance violationA control moves into a failing / violation state
Control status changeA control’s pass/fail status changes
Agent statusA runtime agent goes online or offline
Users can independently opt in or out of email and Slack delivery for compliance reports, violations, control status changes, and agent status.

Message formatting

Slack and Teams messages are formatted (Slack uses Block Kit sections) and color-coded by severity. Email uses HTML templates. Webhook deliveries POST a JSON payload describing the event.

Delivery and retries

Failed deliveries are retried automatically up to three times with exponential backoff — starting at roughly one second, doubling each attempt, and capped at 30 seconds, with jitter. A background sweep also re-attempts recently failed sends.

Test a channel

Every configured channel has a Test button that sends a connection test to the destination, so you can confirm the webhook is reachable, the credentials are valid, or the email passes your filters before real alerts start flowing.