Guide: Integrating Wiz findings into our existing PagerDuty escalation policy.

So your security team dumped Wiz on you and now you need to pipe those "critical cloud misconfigurations" into PagerDuty. Good luck. Everyone thinks this is a simple webhook until they see the payload.

The trick is filtering the noise. Wiz will alert on everything. You need to map their `Severity` and `Entity Type` to PagerDuty urgency. Don't just forward "High" to PagerDuty. Their "High" might be your team's "Medium." Build a lookup table. We do it in a staging table before the service kicks off the PagerDuty API call.

Here's the core of our transform. It lives in a dbt model that ingests the raw Wiz webhook JSON.

```sql
WITH normalized_alerts AS (
SELECT
data:issue -> 'id' AS wiz_alert_id,
data:issue -> 'severity' AS wiz_severity,
data:issue -> 'entitySnapshot' -> 'type' AS entity_type,
data:issue -> 'control' -> 'name' AS control_name
FROM {{ source('wiz_webhook', 'raw_alerts') }}
WHERE data:issue IS NOT NULL
),

pagerduty_mapping AS (
SELECT
wiz_alert_id,
CASE
WHEN wiz_severity = 'CRITICAL' AND entity_type IN ('VIRTUAL_MACHINE', 'CONTAINER_IMAGE') THEN 'critical'
WHEN wiz_severity = 'HIGH' AND entity_type IN ('CLOUD_ACCOUNT', 'USER') THEN 'warning'
ELSE 'info'
END AS pd_severity
FROM normalized_alerts
)
SELECT * FROM pagerduty_mapping
WHERE pd_severity IN ('critical', 'warning')
```

This gets materialized as a table. A simple Airflow DAG picks up new rows and POSTs them to the PagerDuty Events API v2. The real work is in that CASE statement. Tune it aggressively or your on-call will revolt.