> ## Documentation Index
> Fetch the complete documentation index at: https://docs.incident.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Wiz

> Resolve Wiz Issues from incident.io, and choose which system owns the lifecycle

The Wiz integration lets incident.io act on your Wiz tenant, rather than only receiving
from it. Today it does one thing: when someone resolves a Wiz alert in incident.io, we can
close the underlying Issue in Wiz and leave a comment on it.

It is optional. The [Wiz alert source](/alerts/wiz) works on its own, and you only need
this integration if you want incident.io to update Wiz.

## What you need

A Wiz service account, with permission to read Issues and to update the status of, and
comment on, both issues and threats. Wiz's API uses OAuth2 client credentials, so a
service account is the only way to authenticate.

See [Wiz's documentation](https://docs.wiz.io) for creating one and for the scopes it
offers. Note that Wiz shows the client secret only once, when the account is created.

## Connecting Wiz

Go to **Settings → Integrations** in incident.io, find **Wiz**, and click **Connect**. You
need three values from your service account:

* **Client ID**
* **Client secret**
* **Region**, which Wiz calls your **Tenant Data Center**. It looks like `us17` or `eu2`,
  and Wiz shows it under Tenant Info in your portal.

## Choosing what resolving does

Once connected, the integration's settings let you choose how resolving an alert in
incident.io affects Wiz. You set this separately for two groups, because Wiz treats them
differently:

* **Posture issues**, covering toxic combinations and cloud configuration findings
* **Threats**, from Wiz Defend

For each group you can choose:

| Setting                                                              | What happens                                                                                                                                      |
| -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Wiz alerts will resolve only when the issue is resolved in Wiz**   | The default. Wiz owns the lifecycle. The Resolve button is disabled in incident.io, and the alert clears when Wiz tells us the Issue is resolved. |
| **Resolve the issue in Wiz when resolving the alert in incident.io** | We close the Wiz Issue with a resolution reason you choose, and leave a comment naming whoever resolved it.                                       |
| **Resolve in incident.io only**                                      | The alert resolves here and the Wiz Issue is left untouched.                                                                                      |

When incident.io resolves a Wiz Issue, Wiz requires a reason, so you choose which one we
send. The options differ by group:

* **Posture issues**: False positive, Exception, Won't fix
* **Threats**: Malicious threat, Not malicious, Security test, Planned action,
  Inconclusive

<Note>
  If incident.io resolves an alert while the Wiz Issue is still open, Wiz can reopen the alert on its next update, so
  the two systems drift apart. Leaving Wiz as the source of truth keeps them in step.
</Note>

## Detections

Detections are always resolved in incident.io only, whatever you choose above. They are
point-in-time events rather than Issues, so there is nothing in Wiz to close and no
setting for them.

## If something goes wrong

If Wiz rejects the credentials, we mark the integration as needing reconnection and stop
trying. Reconnect it with a fresh client secret from **Settings → Integrations**.

If your service account is missing a permission we need, resolving an alert shows an error
saying so rather than silently doing nothing. Grant it in Wiz and try again.