How do I configure Wiz to ignore findings from our pen-test team's activity?

Welcome! You're on the right track with both ideas - using service accounts and resource tags are the most common ways to handle this.

Tagging the specific resources (like the VMs or storage buckets) your pen-test team uses is often the cleanest method, as it's directly scoped to the infrastructure. Creating an exclusion rule based on those tags will suppress findings from those assets. Just make sure your tagging schema is consistent and the team remembers to apply them.

One caveat - you might also consider creating a separate "Project" in Wiz for pen-test activities if that fits your workflow. It can help keep that data accessible for their reports while keeping it out of the main production dashboards.

Totally feel your pain on the alert noise. Tagging the resources is solid, but I've found you need to pair it with an exclusion rule on the service account too, just to catch any strays. The pen-test VMs might get tagged, but what about the temporary storage they spin up that inherits the service account?

One gotcha: make your exclusions time-bound if Wiz allows it. Your team's test account shouldn't have a permanent "ignore" rule. Schedule it to match their quarterly or weekly scan windows.

Also, double-check the rule logic. Excluding by IP range alone got me burned once because a real attacker used a compromised internal machine. So maybe combine the tag AND the service account for a safer filter.

You've got the right instincts. Tagging the resources and using the service account for exclusions is a solid approach, but you need to layer them to avoid the risk you mentioned.

For a precise rule, I'd combine the resource tag with the pen-test service account AND the specific finding type, like "Excessive permissions detected." This way, you're only suppressing that exact scenario from that specific, authorized source. It's a bit more setup but prevents the filter from being too wide.

Also, before you make it active, use the preview function in the rule builder to see exactly what findings would be suppressed. It'll give you confidence you're not silencing a real issue.

Tagging and service account exclusions are the foundation, but you're missing a critical architectural layer: identity federation. Your pen-test team should operate under a distinct OIDC identity provider or SAML assertion that's separate from your standard corporate SSO. Wiz can ingest these context attributes and you can build exclusions around the federated identity's issuer URL or specific claim. This creates an immutable boundary that's harder to bypass than a resource tag, which can be missed or applied incorrectly.

Combine that federated identity with a separate cloud tenant or at least a dedicated subscription/project. Don't just tag resources within your production environment; isolate the testbed entirely. Then, in Wiz, you can scope an entire exclusion to that cloud project hierarchy. This reduces rule complexity and eliminates the risk of a stray untagged resource causing noise.

The preview function is your friend, but it's a point-in-time check. Establish a validation workflow where a subset of suppressed findings from the last pen-test cycle are manually reviewed by a separate security engineer before the exclusion rule goes fully live. This adds a control to prevent the filter from masking a genuine compromise of the pen-test team's own infrastructure.

You're right to be cautious about making the exclusion too broad; that's the core challenge. Tagging and service accounts are good, but they're administrative controls that can drift.

The most reliable method I've seen anchors the exclusion to the *financial construct* behind the resources. If your pen-test team has its own cloud billing account, subscription, or project, that's a hard boundary. Configure Wiz to scope an exclusion directly to that Cloud Account ID or Project Number. This aligns with the immutable billing lineage and can't be accidentally removed like a tag. Combine this with a time-bound rule for their active scan periods.

Always run the exclusion preview against at least a week of historical findings *before* activating it. You'll quickly see if you're silencing anything from your production financial units.

You're overthinking this. Don't build a complex filter that could hide real issues.

Tag the pen-test resources, sure. But the main fix is simpler: use Wiz's built-in suppression for *authorized scanning* via the Activity tab. Mark their specific activities as approved. This logs the justification and quiets the alert without creating a permanent rule that could drift and cause a blind spot.

The replies about separate billing accounts are theoretically sound but ignore setup time. Start with the tagging and activity suppression. If noise persists, then explore the heavier isolation methods.

Yeah, the time-bound exclusions are a lifesaver. We set ours to auto-disable after their monthly testing sprint ends. Forces a review and keeps the rule from becoming stale.

> temporary storage they spin up that inherits the service account

This is exactly why we also built a rule around the IAM role ARN they use, not just the account ID. It catches those ephemeral resources the tags miss.

Good call on the IAM role ARN. That's often the only constant on ephemeral junk. Tags get lost, service accounts can be shared, but that role ARN is usually locked.

One pitfall: if your pen-testers are using something like Terraform with dynamic provider credentials, the role might not be what you think. Watch for the `sts:AssumeRole` chain. You might need to exclude the *root* role that gets assumed, not the intermediate one.

Time-bound is still key though, otherwise you're just building a permanent backdoor.

Ah, the classic "how do we ignore the people we paid to attack us" problem. Everyone's dancing around the obvious: you shouldn't ignore this activity at all.

> I'm worried about making the exclusion too broad and accidentally ignoring a real threat.

You should be. All this talk of tags, service accounts, and separate billing projects is just building a beautifully documented blind spot. If your pen-testers are finding "excessive permissions," that's a real finding. The fact that it's them doing it is irrelevant. The misconfiguration exists.

Instead of filtering out the noise, use it. Route those "critical findings" from known pen-test activity into a separate ticketing queue for remediation. The vulnerability was just demonstrated to be exploitable. Treat it as a high-priority fix, not an alert to silence.

If you absolutely must suppress, do it for the alerting channel only, never for the finding itself. Let the finding land in a dedicated dashboard for the security team to review as proof of test execution.

Identity federation adds complexity that most shops won't stomach. It's a great way to sell more consulting hours for your IDP vendor, though.

Your separate tenant/subscription idea is sound in theory, but have you priced that out? That's another cost center, another set of guardrails to build. Most teams will just balk at the extra cloud bill and stick with tags.

And a "validation workflow" for suppressed findings? That's just recreating the alert noise problem with extra steps. Now you've got two queues to manage.

You're fundamentally asking the wrong question, which is why you're lost in the portal. The noise *is* the signal.

> "Excessive permissions detected" or "Sensitive data access from unusual IP."

These are not false positives. Your pen-test team is demonstrating exploitable conditions. If you build an exclusion filter, you are architecting a permanent blind spot for that exact attack path. The service account and tag approach is brittle and will miss ephemeral resources, as others have noted.

Instead, use Wiz's workflow to create a dedicated project or policy for findings originating from the authorized pen-test infrastructure. Route them automatically to a high-priority remediation queue. The finding is valid, the actor is authorized, but the vulnerability is now proven. Treat it as such.

The noise *is* the issue, but not the one you think. You've got a bill for a fancy cloud security tool, and now you need to spend more engineering time teaching it to ignore the security work you're already paying for.

> I'm worried about making the exclusion too broad

You should be. Every "best practice" exclusion layer they're suggesting (tags, service accounts, separate billing) introduces a new cost center or management overhead. It's vendor lock-in with extra steps.

Instead of trying to filter out your pen-testers, filter your dashboard view. Let the findings flow, but create a separate view that strips out the known testing IPs and service accounts. That way you're not building a permanent, decaying suppression rule that Finance will refuse to pay to maintain next quarter. The misconfigurations they find are real; hiding them just means you paid twice to discover and then ignore a problem.

> filter your dashboard view

This only solves the problem for *you*, not for the automation or the on-call engineer who gets paged at 3am. The point of a suppression rule is to stop the alert, not just to hide it from a particular report.

You're right about decaying rules being a cost center. That's why you anchor them to something immutable like a Cloud Account ID and make them time-bound. It's a small, defined maintenance overhead that prevents a much larger operational one: alert fatigue and ignored tickets.

You've nailed the key tension here. Suppressing the alert stops the 3am page, but hiding it in a dashboard just moves the noise. Neither feels perfect.

What's worked for us is treating the suppression rule *itself* as a ticket. When we anchor it to the pentest Cloud Account ID, we set the expiry date to match the SOW's end date. That creates a calendar reminder to review and close the rule, turning it from decaying tech debt into a managed process.

It's not zero-effort, but it's less effort than sifting through hundreds of noise alerts. Sometimes the pragmatic middle ground is just documenting a temporary fix.