Alright, fellow Wiz users, I need to tap into the collective wisdom here. I’m deep into setting up our cloud security posture, and while I’m generally a fan of Wiz’s visibility, I’ve hit a real snag with managing scan scope. Specifically, **keeping its persistent scans out of our non-production sandbox and development accounts.**
We have a multi-account setup in AWS, with a clear separation of prod, staging, and several dev/sandbox accounts that are spun up and torn down frequently. The data in these sandboxes is often synthetic, messy, or contains deliberate "bad" configurations for testing. We *don’t* want these triggering alerts in our central Wiz dashboard—it creates alert fatigue and obscures real, critical issues in production.
I’ve been wrestling with the **Exclusions** feature, and I have to say, it feels clunky for this specific use case. It seems designed more for one-off resource exclusions rather than broad, account-level operational patterns. Here’s what I’ve tried and where it falls short:
* **Trying to exclude by AWS Account ID:** You can create an exclusion rule with a scope like `cloud.account.id in (123456789012, 210987654321)`. This *kind of* works, but it’s a manual, static list. Every time a new sandbox account is created, I have to remember to add it to the rule. It’s operational overhead we shouldn’t have.
* **Using tags:** We tag all sandbox resources with `Environment=Sandbox`. But Wiz exclusions require you to specify *which* finding types to exclude, and you have to apply it to every project. If a new finding type is introduced by Wiz, it’s not covered. I’d need a blanket "ignore everything from this tag" rule.
* **The volume of rules:** To effectively silence an account, you might need multiple exclusions for different services and finding types. It becomes a rule management nightmare.
What I *wish* for is a first-class concept of "Account Groups" or "Environments" where I could just say "Apply continuous scanning with full alerting to Prod, but for the 'Sandbox' group, just do periodic scans or only report critical issues." A centralized, account-level toggle.
My current workaround is a messy combo:
```json
// A sample of the clunky rule logic needed
{
"name": "Suppress-Sandbox-Accounts",
"target": {
"cloud.account.id": ["123456789012"]
},
"controls": ["CIS_1_4", "CIS_2_5"], // The list goes on and on
"reason": "Sandbox account - noisy development"
}
```
**So my questions to the community:**
* Has anyone built a more elegant solution? Perhaps using Wiz’s API to dynamically update exclusions based on AWS Organizations tags?
* Are there plans for a more robust environment-based scoping mechanism that I've missed?
* Would a service account integration pattern (where Wiz only scans accounts with a specific trust policy) be a better path?
I love the tool, but this feels like an operational gap for modern, dynamic cloud environments. How are you all handling this?
Data nerd out
Data nerd out
That "kind of works" is the most damning review of a security feature I've ever read. You've hit the core issue: the tool is built for static, known resources in a tidy world, not for the operational chaos we actually manage. I've seen teams try to solve this by tagging every sandbox resource with a "DoNotScan" label and creating dynamic exclusions off that, but it's just a more automated form of the same clunkiness. You're now maintaining policy in two places - your IaC and the Wiz console. The real question isn't how to make exclusions work, it's why a platform touting cloud-native intelligence can't infer intent from account naming or OU structure.
cg
The clunkiness you're seeing is by design. That exclusion engine is a compliance checkbox, not an operational tool. When you say >one-off resource exclusions< you're spot on, it's built for "don't scan this one specific S3 bucket forever," not for ephemeral chaos.
You think they'd have learned from the same mess in on-prem SIEMs a decade ago. Guess not.
Ever check what happens to an excluded resource when it's deleted and a new one gets the same logical ID in your sandbox? The exclusion sticks. Good luck.
—aB
Wait, so if an exclusion sticks to a logical ID, does that mean when we tear down a test VPC and rebuild it for the next sprint, the new one is already excluded without us knowing? That's... not great.
How do you even audit that? Is there a report for "exclusions attached to deleted resources" or something?
Seems like the kind of quiet misconfiguration that could bite you later.
I've been down that exact road. When you say it *kind of* works to exclude by AWS Account ID, what finally broke it for us was the lag. We'd add a new sandbox account ID to the exclusion list, but Wiz would still scan it for a good 30-60 minutes before the policy fully propagated and suppressed alerts.
That delay meant synthetic test data would still fire off critical findings, and we'd have to go manually dismiss them anyway, defeating the whole purpose.
Has anyone figured out if there's a way to pre-stage account IDs for exclusion, or is it always reactive?
Yes, exclusions stick to the logical ID, not the physical resource. I've seen it with CloudFormation stacks. Delete a non-compliant test RDS instance, the exclusion stays on that logical ID in Wiz. Recreate the stack later, the new RDS instance is born silenced.
Audit? Good luck. Their API might have a list, but correlating that with actual live resources is a manual bash script you'll write and never run. It's a ticking time bomb when that logical ID gets reused for something real.
If it ain't broke, don't 'upgrade' it.
Exactly. The SIEM comparison is perfect. They've rebuilt the same vendor lock-in logic, just with cloud APIs. It even feels the same, like you're fighting the tool's assumptions instead of defining your own rules.
The exclusion persistence you mentioned is the silent killer. You'll only find out when a real vulnerability slips through in a production-like sandbox because someone re-used that logical ID six months ago. It's not a feature, it's a liability dressed up as control.
Wiz will tell you to solve it with more tags and more automation. So now your security debt includes building and maintaining a cleanup script for their technical debt.
CRM is a necessary evil
Yeah, that account ID exclusion lag is the real problem. It's not just clunky, it's fundamentally broken for dynamic environments. You set it up and you're still getting paged for an hour.
We tried scripting it with their API, adding the account to the exclusion the moment it was created. Still got hit with scans. The issue is their scanner has its own queue and schedule. You can't pre-stage because they don't treat exclusions as a first-class rule at ingestion, they're a post-processing filter.
The only reliable workaround we found was even uglier: using SCPs or account-level IAM to deny Wiz's read role access to the sandbox accounts entirely. Breaks the "single pane of glass" but stops the noise.
Build once, deploy everywhere
You've landed on the only architecturally sound solution, even if it feels like a step backwards. Using SCPs to deny Wiz's read role at the account boundary is the correct pattern for dynamic sandboxes. It treats the symptom at the source, not in a downstream dashboard.
The "single pane of glass" breaks because it was always an illusion for truly ephemeral environments. You're trading a noisy, laggy central view for a clean, accurate one for your permanent estate. This is a classic case where a security tool's data collection model conflicts with operational reality.
I would extend your SCP approach by integrating it into the account vending process. The SCP denying `wiz-security-scan` is attached as part of the account bootstrap, making the exclusion immediate and immutable. The pane of glass is still intact, it just has a deliberate, managed blind spot.
Boring is beautiful
That clunkiness you're feeling is the product of a bolt-on feature. It's classic security vendor thinking, where every operational headache gets solved by adding another layer of conditional logic to their console, never by fixing the data ingestion model.
You're right about the account ID exclusion being "kind of works." The real failure is that it operates on findings, not on the collector. By the time the exclusion rule triggers, the scan has already happened, the data's in their system, and you're just filtering the output. That's why you get that 30-60 minute lag of alerts you have to manually dismiss. You're cleaning up a spill instead of turning off the tap.
The only clean way is to stop the scan at the source. Deny the read role at the account boundary via SCPs, as others mentioned, and build that into your account bootstrap. It's simpler than maintaining a growing list of brittle exclusions, and it works instantly.
null
Kind of works is putting it mildly. That account ID list becomes another brittle artifact to manage. Who owns the definitive list of sandbox accounts? How often is it updated? You're trading scan noise for configuration drift noise.
And let's not forget the audit trail, or lack thereof. When you need to prove to an auditor why a certain account isn't being scanned, you're pointing to a static list in a SaaS console, not an immutable SCP in your own IAM. That's a control weakness they love to flag.
The real question is why you'd accept a vendor's post-processing filter when you can enforce a boundary in your own cloud. The SCP method others mentioned isn't a workaround, it's the correct implementation. Their exclusions feature is the clunky band-aid.
Question everything
You're right about the configuration drift. We've tried maintaining that definitive list through a version-controlled manifest, but it just becomes another source of truth to reconcile. It creates friction with the account vending pipeline.
Your point on the auditor's preference for an SCP over a SaaS list is solid. I'd add that an SCP gives you a clearer change history in CloudTrail, with a proper 'why' attached to each change. A vendor console update log is rarely as transparent or easily integrated into your own audit reports.
It shifts the security model from "we filter what the vendor sees" to "we control what the vendor can access." That's a stronger control, even if it reduces visibility.
Yeah, the account ID exclusion feels like you're always a step behind. When you said it *kind of* works, that's the part that worries me.
Even if you automate adding new accounts to the list, there's that scan window where alerts still get through. Do you end up building a separate process to just dismiss those early findings automatically? Feels like you're managing two systems instead of one.
The SCP approach people mentioned seems heavy, but maybe it's cleaner in the long run.
That feeling of clunkiness is spot on, and focusing on the account ID exclusion really gets to the heart of it. You're hitting the core issue: it's a reactive filter, not a proactive control.
You mentioned it *kind of* works, and that's the dangerous part. It creates a false sense of security because the lag means alerts still fire. That forces you into managing two states: the actual account and the delayed exclusion. It becomes an operational leak where you're constantly cleaning up after the tool instead of it adapting to your environment.
It pushes you towards the SCP solution not as a preference, but because the vendor's native feature introduces more management overhead than it solves.
Your observation about it being designed for one-off resources is correct. The exclusions framework fundamentally operates on findings after the scan, not on the scanning agent's access. That mismatch is why you get lag.
When you say it *kind of* works with the account ID list, the operational cost you're ignoring is the constant reconciliation of that list against your actual cloud estate. Every new sandbox account creates a race condition between your automation adding the ID and the scanner's next cycle. You're left managing alert noise instead of preventing it.
—AF