Everyone’s talking about Wiz’s agentic this and AI-powered that, but let’s get real: the real test is whether the project structure actually works for developers or just creates another silo.
We’re moving from a more traditional ticketing system. Devs own their services end-to-end. How do you map that to Wiz’s concepts? Do you create a project per service? Per team? How do you handle cross-cutting platform issues without creating a permissions nightmare?
I’m particularly suspicious of any setup that requires a dedicated “Wiz admin” to manage it all. That’s just shifting the burden, not creating efficiency. What’s actually working in practice?
—EB
I'm a lead security engineer at a mid-sized fintech (~400 devs, full AWS/GCP/Kubernetes stack), and we've been running Wiz in production for over a year now to handle cloud security posture and vulnerability management across all our service teams.
* **Project-per-Team, Not Per-Service**: The most maintainable pattern we found is a Wiz Project for each developer team (8-15 people). We tried a project-per-microservice initially, and managing the 200+ projects created was a full-time job. Per-team mapping keeps the admin overhead reasonable and aligns with who actually owns triage and remediation. Each team project gets an AWS account or a couple of GCP projects scoped to it.
* **Permission Strategy via IdP Groups**: We avoid manual Wiz user management entirely. We sync Azure AD groups (one per dev team) to corresponding Wiz Projects as "Project Admins." This means when a developer switches teams internally, their access updates automatically. It took about two weeks to script the initial sync, but now it's mostly set-and-forget. The critical detail is ensuring your cloud resource tags (like `team: product-infra`) are consistent and reliably applied so the Wiz inventory scans can map resources correctly.
* **Handling Platform Issues with a Central Project**: We have one dedicated "Platform Security" project owned by our infra security team. It uses global cloud-account-level scanning rules to catch cross-cutting issues (like public S3 buckets, IAM drift, or org-wide container registry vulns). Findings here are automatically shared into the relevant team projects via Wiz's "Issue Sharing" feature. This avoids permission nightmares because the platform team owns the rule set, but the dev teams see and act on the issues in their own space.
* **Real Admin Burden Estimate**: You will need a fractional admin - not a dedicated headcount, but about half a day per week from someone who understands your cloud layout and IdP. The main tasks are adjusting project scopes after major refactors and tuning the noise ratio for new service types. At our scale, that's me spending 3-4 hours weekly. It's less than our old ticketing system's queue management, but it's not zero.
My pick is the team-aligned project structure. It's the best balance of ownership and scalability for a dev-centric org. To know if it'll work for you, we'd need to know how stable your team boundaries are and whether your cloud resource tagging is already mature (at least 80% coverage). If teams constantly reorganize or tagging is a mess, the maintenance cost goes way up.
buyer beware, but buy smart
You've hit on the core tension. Moving from a ticketing system to an ownership model in Wiz is less about technical mapping and more about accountability.
We also use a project-per-team structure, but we layered on a tagging convention for services. Each resource is tagged with `service:` and `team:`. Our team projects are scoped by the `team` tag. This gives devs a single view of their team's entire portfolio, while still allowing us to run organization-wide queries on a specific service if needed.
The real efficiency gain was forcing us to define our team boundaries and cloud account strategy *before* implementing Wiz. If that's ambiguous, any tool will create a permissions nightmare.
Measure twice, buy once.