Skip to content
Notifications
Clear all

Anyone using Wiz for SOC2 audit evidence collection?

4 Posts
4 Users
0 Reactions
1 Views
(@integration_maven)
Estimable Member
Joined: 4 months ago
Posts: 130
Topic starter   [#8107]

Having recently completed the evidence-gathering phase for our own SOC 2 Type II audit, I wanted to share our team's experience leveraging the Wiz platform as a primary data source. The promise is compelling: a single, cloud-native platform with deep visibility into cloud security posture, vulnerability management, and compliance. The reality, however, involves significant integration and transformation work to mold Wiz outputs into auditor-acceptable evidence packages.

Our approach centered on using the Wiz GraphQL API to programmatically extract data, which we then normalized and presented in a structured format. The key evidence categories we targeted included:

* **User Access Reviews:** Pulling `User` and `Role` objects, then mapping them to cloud resources to demonstrate periodic review of access controls.
* **Vulnerability Management:** Using `VulnerabilityFinding` nodes with temporal filters to prove regular scanning and remediation workflows over the audit period.
* **Configuration Compliance:** Exporting results from Wiz Security Graph queries related to specific CIS Benchmark controls (e.g., "Ensure Cloud Storage is encrypted") as snapshots in time.
* **Alert & Incident Response:** Querying `Issue` and `Alert` objects to demonstrate monitoring and ticketing system integration.

The primary challenge was not data collection, but curation. Raw API payloads are too voluminous and lack the narrative context auditors require. We built a middleware layer (Node.js) to orchestrate these calls, filter to the relevant timeframes, and generate summary reports. A simplified example of fetching critical vulnerabilities for a specific period:

```graphql
query SOC2EvidenceVulnerabilities($first: Int, $filter: VulnerabilityFindingFilters) {
vulnerabilityFindings(first: $first, filter: $filter) {
nodes {
id
name
severity
status
createdAt
updatedAt
resource {
id
name
cloudPlatform
}
}
}
}
```

Variables:
```json
{
"first": 500,
"filter": {
"severity": ["CRITICAL", "HIGH"],
"updatedAt": {
"after": "2024-01-01T00:00:00Z",
"before": "2024-06-30T23:59:59Z"
}
}
}
```

We then transformed this data into a CSV timeline linked to our internal ticketing system (via Zapier webhooks) to show the lifecycle of each finding.

**Pitfalls to Consider:**
* **Control Mapping Gap:** Wiz's built-in compliance frameworks (CIS, etc.) don't map 1:1 to SOC 2 Trust Services Criteria. You must manually align the evidence.
* **Data Locality:** Ensure your API calls and data processing adhere to the same geographic compliance requirements as your audit.
* **Evidence Integrity:** Auditors often require immutable logs. We had to supplement API data with exported, timestamped PDFs from the Wiz UI to serve as "unalterable" snapshots.

Ultimately, Wiz served as a powerful *source* of truth, but not a *presentation* of truth for audit purposes. The effort to build the integration was justified by the automation and scale it provided across multiple cloud accounts. I'm keen to hear if others have taken a different approach, perhaps using Wiz's newer reporting features or integrating directly with GRC platforms.

API first.


IntegrationWizard


   
Quote
(@chrisg)
Estimable Member
Joined: 6 days ago
Posts: 75
 

Yeah, we went down that path too. The GraphQL API is solid, but the transformation layer is a hidden cost.

We ended up writing custom Python scripts to query, then dumping everything into structured CSV reports with timestamps. Had to add a lot of metadata - auditor context, control mapping, evidence owner - that Wiz doesn't provide out of the box.

Did you also have to supplement with manual evidence for processes Wiz doesn't cover? We still pulled logs from our IDP and CI/CD for certain controls.


YAML all the things.


   
ReplyQuote
(@julier)
Eminent Member
Joined: 1 week ago
Posts: 20
 

Yeah, the metadata gap is real. We had to tag everything with our internal control IDs and ownership manually. It ate so much time.

Do you think any of that custom script work could be reused for an ISO 27001 audit later, or is it too specific to SOC2 controls? I'm already dreading the next cycle.



   
ReplyQuote
(@benchmark_bob_42)
Reputable Member
Joined: 3 months ago
Posts: 151
 

The reusability question is a good one. A lot of the core script logic for pulling and normalizing data from the Wiz API is absolutely transferable to ISO 27001. The core mechanics of authentication, querying the GraphQL endpoint, and handling pagination don't care about the compliance framework.

Where you'll hit another specificity wall is in the mapping and filtering layer. You'll need to rebuild that logic to align Wiz asset and vulnerability data with ISO 27001 Annex A controls instead of SOC2 trust services criteria. For example, the evidence for A.12.4 (logging and monitoring) might pull from similar Wiz datasets as CC6.1, but the auditor's expected presentation and the specific metadata fields will differ.

Our approach was to separate the engine (the data fetcher) from the control mapping definitions. That let us swap out a YAML file mapping SOC2 controls to Wiz query filters for one mapping ISO 27001 controls, without rewriting the scripts from scratch. The time sink moves from coding to crafting those new mapping definitions.


-- bb42


   
ReplyQuote