
How do we integrate Wiz with Jira or ServiceNow so findings auto-create tickets, assign owners, and track remediation SLAs?
Most security teams don’t struggle to find risks—they struggle to turn those risks into owned, trackable work that actually gets fixed. Integrating Wiz with Jira or ServiceNow is how you turn Wiz findings into auto-created tickets, clear ownership, and enforceable remediation SLAs, without a spreadsheet in sight.
Quick Answer: You connect Wiz to Jira or ServiceNow using built-in integrations, define routing rules based on Wiz context (resource, repo, tag, environment, severity), and let Wiz automatically open, update, and close tickets as findings change—giving you end-to-end visibility into who owns each issue and whether it’s being remediated on time.
The Quick Overview
- What It Is: A native integration between Wiz and Jira/ServiceNow that turns Wiz findings into structured tickets, keeps them in sync, and supports SLA-driven remediation tracking.
- Who It Is For: Security, cloud, and product teams that want to replace manual export/triage workflows with a consistent “exposure → ticket → code fix” pipeline.
- Core Problem Solved: Eliminates the gap between detection and remediation by automatically assigning the right owner, creating tickets with full context, and tracking closure against SLAs.
How It Works
At a high level, Wiz becomes your “source of truth” for cloud risk and Jira/ServiceNow becomes the system of record for remediation. The integration connects the two so any prioritized Wiz finding can automatically generate, update, and close a ticket in your existing workflows.
Under the hood, Wiz uses its Security Graph to understand which team, service, or repo owns a risk, and then pushes that context into Jira or ServiceNow with enough detail for engineers to self-remediate—often without ever logging into Wiz.
-
Connect & Authenticate:
You configure the Jira or ServiceNow connection in Wiz (URLs, credentials/API tokens, project/instance selection) so Wiz can create and update tickets on your behalf. -
Define Routing & Ownership Rules:
You set policies based on Wiz context—such as cloud account, tag, namespace, repo, or application—so findings automatically route to the right Jira project or ServiceNow group, with the correct assignee and priority. -
Automate Ticket Lifecycle & SLA Tracking:
Wiz opens tickets when new high-priority issues appear, enriches them with graph context and fix guidance, and automatically resolves or updates tickets when the underlying risk is fixed or re-detected. You overlay remediation SLAs in Jira/ServiceNow and monitor performance from both tools.
Features & Benefits Breakdown
| Core Feature | What It Does | Primary Benefit |
|---|---|---|
| Native Jira & ServiceNow integration | Connects Wiz directly to your Jira projects or ServiceNow instance using built-in connectors. | Fast implementation and low overhead—no custom middleware required. |
| Context-aware ticket creation | Pulls Wiz Security Graph context (exposure, identity paths, blast radius, ownership) into each ticket. | Engineers get “indisputable evidence” and clear next steps, reducing back-and-forth with security. |
| Automated routing & updates | Uses rules to auto-assign owners, set priorities, and keep ticket status in sync with Wiz findings. | Removes manual triage, enforces SLAs, and shortens MTTR from days to hours. |
How to Integrate Wiz with Jira
1. Prepare Jira for Wiz Integration
Before you touch Wiz, line up the basics in Jira:
-
Pick the right projects:
Decide whether you’ll send issues to:- A central “Cloud Security” project, or
- Multiple team/service projects (recommended for ownership).
-
Standardize issue types & fields:
- Choose issue types (e.g., “Bug,” “Task,” or a custom “Security Finding”).
- Confirm required fields (priority, component, labels) and how they map from Wiz fields (severity, cloud account, service name).
-
Define assignment model:
- Use components, custom fields, or labels to reflect service or team ownership.
- Align with how you already track services (e.g., “payments-api,” “identity-service”).
2. Configure the Jira Connection in Wiz
In Wiz (exact UI labels may vary slightly by version):
- Navigate to Integrations in the Wiz console.
- Select Jira as an integration type.
- Provide:
- Jira URL (Cloud or Server/DC URL).
- Authentication (API token or OAuth/app credentials).
- Default project (used when routing rules don’t specify a different project).
- Test the connection to confirm Wiz can:
- Create an issue,
- Read issue status,
- Update issues.
This step is agentless and low-overhead—no deployment on your infrastructure.
3. Build Ownership-Based Routing Rules
This is where the magic happens: you map Wiz context to Jira projects and assignees so tickets land on the right desk by default.
Common routing patterns:
- By cloud account or subscription:
- Rule example:
- If
cloud_account = prod-aws-core→ send to Jira projectCLOUD-SECand componentcore-platform.
- If
- Rule example:
- By tags/labels (e.g.,
owner,team,service):- If resource has tag
team = payments→ send to Jira projectPAYMENTSand assign to team lead.
- If resource has tag
- By application/service name:
- If Wiz finding is linked to repo/service
checkout-service→ map to componentcheckoutin Jira.
- If Wiz finding is linked to repo/service
- By environment:
- Prod vs. non-prod can drive different priorities and SLAs:
env = prod→ higher priority & tighter SLA.env != prod→ lower priority, tracked separately.
- Prod vs. non-prod can drive different priorities and SLAs:
In Wiz, you define these as policies or routing rules that look at:
- Cloud metadata (account, project, subscription).
- Resource tags/labels.
- Security Graph ownership mapping (repo/service relationships).
- Finding severity and category (e.g., internet-exposed critical vulns vs. internal misconfigurations).
4. Define Ticket Templates & Fields
Configure how Wiz populates Jira issues so each ticket is “ready to work”:
- Summary: Concise, actionable titles, e.g.,
Critical: Publicly exposed VM with exploitable vuln CVE-XXXX-XXXX - Description: Include:
- What Wiz detected (finding type and severity).
- Why it matters (effective exposure, identity paths, data access chains).
- Affected resources (with links back to Wiz and cloud console).
- Recommended remediation steps or code fix guidance.
- Fields & labels:
Prioritymapped from Wiz severity and blast radius.ComponentorServicemapped from Wiz ownership mapping.Labelsforenvironment,cloud-provider,category(e.g.,CSPM,CNAPP,runtime).
Wiz’s in-code remediation and Green agent can also open PRs directly for certain issues; the Jira ticket then references the PR so teams have a clear from-exposure-to-code-fix trail.
5. Automate Ticket Lifecycle & SLA Tracking
Once the integration is live:
-
Ticket creation:
When a finding matches your routing criteria (e.g.,Critical+internet-exposed), Wiz automatically:- Opens a Jira issue,
- Populates the template,
- Routes it to the correct owner.
-
Status synchronization:
As engineers remediate:- If the underlying issue is fixed and Wiz verifies it (via the next scan), Wiz can:
- Automatically add a comment to the Jira ticket, and/or
- Transition it to a “Resolved/Done” status (if configured).
- If the issue reappears, Wiz can:
- Reopen the existing ticket instead of creating a duplicate.
- If the underlying issue is fixed and Wiz verifies it (via the next scan), Wiz can:
-
SLA and reporting:
- You maintain SLA policies in Jira (e.g., “Critical in prod must be resolved in 7 days”).
- Wiz and Jira together give you:
- Time-to-remediate metrics (Aon, for example, reduced from days to hours),
- SLA performance by team, environment, and risk category,
- Visibility into “0 criticals” goals across environments.
How to Integrate Wiz with ServiceNow
The ServiceNow integration serves the same mission—turn Wiz signals into owned, trackable work—but plugs into your ITSM/enterprise workflow instead of or alongside Jira.
1. Prepare ServiceNow
Align your ServiceNow configuration with how you want to treat Wiz findings:
-
Choose the right record type:
- Incidents for urgent threats,
- Problems for structural vulnerabilities and misconfigurations,
- Custom “Security Finding” table if your SOC already uses one.
-
Define assignment groups:
- Cloud platform,
- Application squads,
- Network/security engineering,
- SRE/operations.
-
Clarify priority mapping:
How Wiz severities (Critical/High/Medium/Low) translate to ServiceNow priorities and SLA timers.
2. Configure ServiceNow Integration in Wiz
In Wiz:
- Go to Integrations.
- Select ServiceNow.
- Provide:
- Instance URL,
- Authentication details (API user/account with permission to create and update records),
- Default table and assignment group, if required.
- Test the connection by creating a sample record.
As with Jira, this is agentless and quick—most teams get it connected in under an hour.
3. Build Routing & Enrichment Policies
Use Wiz context to drive where ServiceNow tickets go and how they’re enriched:
-
Assignment group rules:
cloud_account = azure-prod-data→ groupData Platform Team.tag.owner = “payments-team”→ groupPayments App Team.
-
Priority rules based on real exposure:
- Critical + internet-exposed + active identity path to sensitive data → P1.
- High + internal-only + no viable lateral movement path → P3.
-
Field population:
- Description includes:
- Graph-based attack path narrative (initial access → lateral movement → data access).
- Affected resources and services.
- Recommended remediation and, where applicable, links to in-code fixes or check-in locations.
- Custom fields for:
- Cloud provider (
AWS,Azure,GCP), - Environment (
prod,staging,dev), - Risk category (
Misconfiguration,Vulnerability,Identity,Runtime).
- Cloud provider (
- Description includes:
4. Ticket Lifecycle & SLA Enforcement
Once routing is set:
- Auto-create records:
- Wiz generates incidents/problems when findings cross your thresholds, with all context embedded.
- Auto-update & closure:
- As teams fix issues and Wiz validates with new scans, Wiz updates ServiceNow:
- Status moves to resolved/closed,
- Notes are added with Wiz verification details.
- As teams fix issues and Wiz validates with new scans, Wiz updates ServiceNow:
- SLA and metrics:
- ServiceNow’s SLA engine measures:
- Time to acknowledge,
- Time to resolve.
- You can slice performance by:
- Service,
- Team,
- Environment,
- Risk type—aligned to how Wiz prioritizes based on exploitability and blast radius.
- ServiceNow’s SLA engine measures:
Ideal Use Cases
-
Best for consolidating cloud security into existing engineering workflows:
Because it lets engineers work entirely in Jira or ServiceNow while Wiz handles detection, context, and validation behind the scenes. -
Best for SLA-driven remediation programs:
Because Wiz’s context-driven prioritization feeds directly into Jira/ServiceNow SLAs, letting you commit to—and actually hit—remediation timelines for the issues that matter most.
Limitations & Considerations
-
Initial ownership mapping setup:
You’ll need to invest in mapping tags, repos, and services to teams so routing rules are accurate. The payoff is massive, but plan a phase where security and platform teams define this model together. -
Too-broad automation can cause noise:
If you auto-ticket every finding, you’ll recreate the “3500-row spreadsheet” problem inside Jira/ServiceNow. Start with a focused scope (e.g., internet-exposed criticals in prod) and expand as you see success.
Pricing & Plans
Wiz’s Jira and ServiceNow integrations are part of the broader Wiz platform, which is licensed based on your cloud footprint and module selection (e.g., attack surface scanning, code scanning, runtime detection and response).
Typical patterns:
- Core CNAPP package: Best for organizations needing unified visibility, contextual risk prioritization, and ticket-based remediation into Jira/ServiceNow.
- Advanced Defend/XDR package: Best for teams that also want Wiz Defend’s runtime detection, automated investigations, and threat validation feeding into their ITSM and incident workflows.
For exact pricing and which package includes which integrations, talk to Wiz directly.
Frequently Asked Questions
Can we control which Wiz findings create Jira or ServiceNow tickets?
Short Answer: Yes. You can define granular policies so only the risks that matter trigger tickets.
Details:
You can filter by:
- Severity (e.g., Critical/High only),
- Exposure (internet-exposed, public endpoints),
- Identity paths (reachable from certain roles or attack paths),
- Environment (prod vs. non-prod),
- Category (e.g., limit to vulnerabilities or misconfigurations),
- Tags/ownership (only specific business units or services).
This lets you start with a small, high-value slice—like “Critical, internet-exposed in prod”—and expand over time as engineering capacity and process maturity grow.
Do engineers need to log into Wiz to remediate issues?
Short Answer: No. They can work entirely in Jira or ServiceNow if you configure the integration correctly.
Details:
Many Wiz customers let engineering teams self-remediate using:
- Jira/ServiceNow tickets generated by Wiz, with full finding context,
- Clear remediation guidance or direct references to PRs opened by Wiz’s in-code remediation,
- Ownership mapping that routes tickets to the right service/team.
This is how organizations like Aon cut remediation from days to hours—tech teams treat Wiz-driven tickets like any other work item in their backlog, without needing to learn a new console unless they want deeper context.
Summary
Integrating Wiz with Jira or ServiceNow is how you turn contextual cloud risk insights into predictable, SLA-backed engineering work. Wiz’s Security Graph surfaces what’s truly exploitable, maps it to the right owner, and then uses native integrations to auto-create and maintain tickets with all the context engineers need to fix issues at the source. Instead of exports and manual triage, you get a clean pipeline from exposure to code fix, with measurable MTTR and SLA performance.