Suppressing alerts from Events (investigation‑based suppression)

Suppressing alerts from Events helps you reduce repeated alert noise without losing investigative visibility. Use this approach when you have confirmed that an alert is generally valid, but becomes noise only within a specific, expected context (for example, a specific user, device, IP range, or time window).

This type of suppression affects future alerting behavior only. The underlying activity continues to be collected and remains available for investigation and historical context.

For general guidance on what alert suppression is and how suppression rules behave, see Alert suppression. This article focuses specifically on scenario‑based suppression that starts from a real alert or investigation, not on creating suppression rules in advance. This workflow is most useful when suppressing alerts reactively from investigation context rather than creating rules proactively.

How alert behavior decisions fit together

Use the articles in this section together as a deliberate decision ladder:

  1. Start with the alert

    Review the alert and understand what it represents before taking action.

    See Working with alerts

  2. Investigate before changing behavior

    Use the Analysis page to validate context, scope, and impact.

    See Investigating activity using the Analysis page

  3. Decide how (or whether) alert behavior should change

    Determine whether tuning, suppression, or no action is appropriate based on investigation results.

    See Managing noise and signal; Managing repeated alerts

  4. Apply the selected change in the correct place

    Severity or detection tuning > global prioritization changes.

    See: Managing alert severity and detection tuning

    Suppression rules > scoped exceptions for specific conditions.

    See Suppressing alerts from Events; Alert suppression

Each article in this set is intentionally scoped to one step in this process.

Avoid skipping steps. Changing alert behavior without investigation can hide meaningful security activity and reduce confidence in response decisions

How investigation‑based alert suppression starts

Investigation‑based alert suppression starts from an alert.

It is used when reviewing a live alert in Events and deciding whether repeated future alerts should be suppressed under specific, validated conditions.

This workflow assumes that you are responding to a real alert and validating behavior through investigation, rather than creating suppression rules proactively.

When to use investigation‑based alert suppression

Use investigation‑based alert suppression only after all of the following are true:

  • You have reviewed the alert in Events and determined it does not require immediate response.

  • You have investigated at least one representative example using the Analysis page.

  • You have confirmed the behavior is expected and low risk in a clearly defined context.

  • You can precisely define when suppression should apply and when it should not.

If an alert is consistently low urgency across your entire environment, adjust alert severity first (see Managing noise and signal). Reserve advanced alert suppression for scoped, rule‑level exceptions.

Step 1: Review the alert in Events

Before creating a suppression rule:

  1. Open Events from the side navigation menu.

  2. Review the alert details and severity.

  3. Decide whether the alert requires immediate action or escalation.

  4. Do not suppress alerts at this stage unless the behavior is fully understood.

Step 2: Validate the pattern in Analysis

After reviewing the alert in Events, validate the behavior:

  1. Open Analysis.

  2. Scope the view to the relevant organization and primary subject (user, device, or IP address).

  3. Review correlated activity, timelines, and related entities.

  4. Confirm the behavior is consistent, expected, and low risk.

This step ensures suppression is based on a representative example and prevents overly broad suppression rules.

Step 3: Initiate suppression for the validated pattern

Once the behavior has been validated, initiate alert suppression for the specific pattern you want to suppress. Suppression can be initiated from investigation results. Some alert views also expose suppression controls directly, providing a shortcut to the same workflow. The availability of suppression controls varies by alert type and product.

Option A: Start suppression from investigation results (common workflow)

If suppression controls are available in the results table:

  • Run an investigation in Analysis that includes the alert or activity.

  • Locate the suppression icon (bell with a slash).

  • Select it to open the Create event suppression rule panel.

NOTE  In some cases, suppression controls may be visible but not available. When suppression cannot be applied, the activity remains logged and visible for investigation and historical reference.

Option B: Start suppression from the alert

If your UI allows suppression directly from alert views, use this option only after validating the pattern in Analysis.

Step 4: Scope the suppression rule narrowly

Define the smallest safe scope for the suppression rule. Common options include:

  • A specific user or account

  • A specific device or host

  • A specific organization

  • A specific IP address or location pattern

  • A specific time window (temporary exception)

Best practice: start narrow.

  • Avoid suppressing an alert type globally unless you have confirmed it is low value in all contexts.

  • Avoid suppressing an alert type by name alone unless additional conditions are applied.

Step 5: Define suppression criteria

Depending on the alert, available criteria may include:

  • IP address

  • Geographic location (city, region, country)

  • Other event‑specific attributes

You can combine multiple criteria so suppression applies only when all conditions are met.

Example: Suppress an alert for a specific user only when activity originates from an approved IP range during a planned change window.

Step 6: Set a duration (recommended)

Choose whether the suppression is:

  • Temporary, using a defined date range (recommended), or

  • Indefinite, when the behavior is permanently expected.

Temporary suppressions are preferred whenever possible.

Step 7: Enter a reason (required)

Provide a clear explanation for why the suppression exists. Include:

  • Business or operational justification

  • A change request or support ticket reference, if applicable

  • Clear documentation supports audits, troubleshooting, and future review.

Step 8: Choose what to suppress

Select which downstream actions should be skipped when suppression applies:

  • Skip IOC notifications

  • Skip Respond rules

  • Skip ticketing and notifications

  • Analysis visibility can remain enabled, allowing continued investigation and historical review.

  • Suppression does not delete event data.

Step 9: Validate suppression behavior

After creating the rule:

  • Return to Analysis.

  • Review results including suppressed activity (if available).

Confirm the following:

  • Repeated notifications have stopped for the suppressed pattern.

  • The underlying activity remains visible for investigation.

  • Alerts still trigger when the suppression conditions are not met.

This validation loop ensures noise reduction without loss of detection coverage.

If alerts stop appearing outside the intended suppression conditions, revise or remove the rule immediately.

Reviewing suppressed activity

Use Analysis to review suppressed activity when:

  • An investigation requires historical context

  • You need to confirm the suppression is still appropriate

  • The environment has changed and the suppression may no longer apply

Suppressing alerts is not the same as disabling detection.

What not to do

  • Do not suppress alerts before investigating a representative example.

  • Do not create broad suppressions that hide large classes of alerts.

  • Do not use suppression to compensate for unknown or unresolved risk.

  • Do not treat suppression as permanent by default.

Related articles

  • Managing noise and signal: Decide whether alert behavior should change after investigation, and choose the least disruptive noise‑reduction approach before introducing suppression or automation

  • Alert suppression: Explains how alert suppression rules work in Kaseya MDR and how to configure them to reduce alert noise without stopping event collection

  • Investigating activity using the Analysis page: Validate alert context, scope, and impact by reviewing correlated activity, timelines, and related entities before making tuning, suppression, or response decisions

  • Creating high‑confidence alerts with Respond rules: Design Respond rules that correlate multiple signals into higher‑confidence alerts when single alerts are valid but insufficient to represent meaningful risk