Alert suppression

Alert suppression in Kaseya SIEM allows you to reduce alert noise by preventing specific events from escalating into alerts, notifications, tickets, or automated responses, without stopping data ingestion.

Suppression rules are intended for known, expected, or low‑risk activity that would otherwise generate repetitive alerts under well‑defined conditions, such as a specific event type, product, location, user, or time window.

Suppression rules are managed from Events > Suppression Rules and apply after events are ingested and evaluated, not at the integration or data source level.

This article explains how alert suppression works and how suppression rules are configured and managed. It does not help you decide whether suppression is appropriate. If you are encountering the same alert repeatedly and are deciding whether suppression or tuning is the right action, start with Managing repeated alerts.

Use this article when:

  • You are ready to configure alert suppression rules after investigating and validating the activity.

  • You need procedural guidance on creating, editing, or reviewing suppression rules.

  • You are making scoped, auditable alert‑noise decisions as part of SIEM administration.

For investigation‑first decision‑making, see Managing repeated alerts.

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.

Understanding alert suppression in Kaseya SIEM

In Kaseya SIEM, suppression operates as part of the alerting and rule-evaluation pipeline:

  • Events are still collected from integrations and data sources.

  • Detection and rule logic evaluates incoming events.

  • Suppression rules determine whether matching events:

    • Trigger automated response actions

    • Create PSA tickets or email notifications

    • Escalate through downstream notification workflows

  • Suppressed events are not deleted and, unless explicitly hidden, remain visible in the Analysis page for investigation and audit purposes.

IMPORTANT  Suppression does not disable integrations, stop event ingestion, or remove data from the platform.

When to use alert suppression

Use alert suppression when all of the following are true:

  • You have reviewed the activity and confirmed it is expected or acceptable.

  • The alert is valid in other scenarios and should not be disabled globally.

  • The behavior can be clearly identified using specific conditions.

  • The goal is to reduce noise, not hide unknown or risky activity.

Examples:

  • A known API key rotation event that generates repeated alerts

  • Login activity from an approved geographic location during planned work

  • Expected administrative actions during a maintenance window

If an alert is consistently low value across your entire environment, adjust alert severity or detection tuning instead of creating suppression rules (see Managing alert severity and detection tuning). Before creating suppression rules, investigate at least one representative alert in Analysis to confirm the behavior is expected and low risk. For scenario‑driven workflows that start from a specific alert or investigation context, see Suppressing alerts from Events (investigation‑based suppression).

Creating a suppression rule

Creating a suppression rule is a two‑step process:

  1. Define the conditions that identify the activity

  2. Define what actions should be skipped when those conditions are met

Defining the conditions

Step 1: Open Suppression Rules

  1. From the side navigation menu, select Events.

  2. Select Suppression Rules.

  3. Click + New Suppression.

Step 2: Define suppression conditions

Suppression conditions determine which events the rule applies to.

  • Applies to: Select the scope where the suppression applies (for example, partner or tenant).

  • Product: Choose the product that generates the event (for example, Datto EDR).

  • Event type: Select the specific event type to suppress (for example, API Key Created, External Integration Created, Mailbox Permission Added).

Optional condition fields

Depending on the selected product and event type, you may also define:

  • Additional description text

  • User agent string

  • Device or identity mapping status

  • IP address

  • Country or location

  • Custom fields (up to 10)

Best practice: Use the smallest possible set of conditions that uniquely identifies the expected behavior. Overly broad conditions increase the risk of hiding important alerts.

NOTE  The available device.unifyStatus values reflect different unification outcomes for devices and users. Use this field only when you understand the context in which a specific status appears and have validated representative events in Analysis.

Configuring suppression behavior

After defining conditions, configure how the suppression behaves.

Date‑based suppression

  • Enable date‑based suppression to create temporary or planned exceptions

  • Specify a start and end date

  • Leave date‑based suppression disabled for indefinite rules

Temporary suppressions are strongly recommended whenever possible to reduce long‑term blind spots by ensuring exceptions expire when planned activity ends.

When date‑based suppression is disabled, the suppression remains active indefinitely until it is manually removed.

Name / reason (required)

Provide a clear explanation for why the suppression exists, including:

  • Business or operational justification

  • Change‑management or support ticket references

  • Context for future review

This information is visible to other administrators and is important for audits and ongoing review.

Selecting suppressed actions

You can control which downstream actions are skipped when the suppression conditions are met:

  • Skip IOC: Prevents indicator‑of‑compromise escalation for matching events

  • Skip Respond: Prevents automated response actions from triggering

  • Skip PSA & email ticketing: Prevents PSA tickets or email notifications from being generated

  • Skip outside approved location: Suppresses alerts that would normally trigger based on activity outside approved geographic locations

  • Hide from Analysis: Removes suppressed events from the Analysis view

IMPORTANT  If Hide from Analysis is not enabled, suppressed events remain searchable and visible for investigation and historical reference. Enable Hide from Analysis only when you fully understand the investigation and compliance impact. Otherwise, leave Analysis visibility enabled.

Saving the suppression rule

  1. Review the configured conditions and actions.

  2. Click Create Suppression.

  3. A confirmation message appears when the rule is successfully created.

The rule becomes active immediately or at the configured start time.

Viewing and managing suppression rules

View active and future rules

Open Events > Suppression Rules. Active and scheduled rules are listed by default.

View expired rules

Enable Show expired to view rules that have reached their end date.

Expired rules are retained for visibility and auditing.

Review suppressed events

Click the eye icon to view events affected by a suppression rule.

This opens the Analysis page filtered to show only events that matched the rule during its active period. This view shows the underlying events associated with the suppression rule.

Editing a suppression rule

You can edit an existing suppression rule on the Edit Event Suppression Rule by clicking the pencil icon.

Then, click Update Suppression to save your changes.

You will see a confirmation message that your rule has been successfully updated.

NOTE  Although suppression rules can be fully edited, changing the scope or intent of an existing rule can make historical decisions harder to track. When the behavior being suppressed changes significantly, consider creating a new suppression rule instead of modifying an existing one.

Deleting a suppression rule

To delete a suppression rule, click the trash can icon and confirm removal.

Deleted rules are permanently removed and do not appear under expired rules.

Best practices for alert suppression

Use the following best practices to reduce noise without obscuring meaningful security signals:

  • Prefer tuning before suppression: Use severity or detection tuning for globally low‑value alerts before applying suppression.

  • Scope rules narrowly: Limit suppressions to specific products, event types, users, locations, or time windows.

  • Validate before suppressing: Review representative activity in Analysis to confirm behavior is expected.

  • Use temporary suppressions whenever possible: Especially for maintenance, onboarding, or planned changes.

  • Document clearly: Always include a reason and relevant context for audits and future review. Clear documentation helps preserve decision context for audits, reviews, and future investigators who may revisit the suppression.

  • Avoid hiding events from Analysis unless necessary: Retaining visibility supports investigation and compliance.

  • Review suppressions regularly: Remove rules that are no longer required.

  • Confirm alerts still trigger outside the scope: Verify suppression does not unintentionally block unrelated alerts.

Examples of effective alert suppression rules

The following examples are illustrative patterns, not exhaustive or guaranteed alert scenarios. Actual alert behavior depends on detections, integrations, and investigation context. Suppression in SIEM represents an operational risk decision and should be applied only when the behavior is well understood.

Example 1: API key rotation generating repeated alerts

Scenario: Automated API key rotation triggers repeated alerts.

Approach:

  • Scope to the specific event type and product

  • Apply suppression only during the rotation window

  • Skip alerting and ticketing, retain Analysis visibility

Why it works: Targets predictable, low‑risk activity while preserving audit context.

Example 2: Login activity from an approved geographic location

Scenario: Admin logins from a known location during scheduled work generate alerts.

Approach:

  • Add location‑based and time‑based conditions

  • Suppress alerts only when conditions are met

Why it works: Alerts still trigger for off‑schedule or unusual locations.

Example 3: Expected administrative actions during maintenance

Scenario: Planned maintenance causes temporary alert spikes.

Approach:

  • Create a time‑bound suppression

  • Document the maintenance window

  • Allow the rule to expire automatically

Why it works: Reduces noise without creating long‑term blind spots.

Example 4: Repeated low‑risk events from a known service account

Scenario: A service account performs routine operations that trigger alerts.

Approach:

  • Scope suppression to the specific account and event type

  • Retain Analysis visibility

Why it works: Prevents noise without suppressing similar activity from other users.

Example 5: Integration validation and expected telemetry churn

Scenario: A newly enabled integration (for example, a SaaS application, cloud service, or security tool) generates elevated alerts during initial validation, synchronization, or first‑time baseline evaluation. The activity is expected while the integration stabilizes.

Approach:

  • Scope suppression to the specific integration product and event types involved in the initial sync or validation phase.

  • Use a temporary, date‑based suppression aligned to the known validation or burn‑in period.

  • Document the integration name and onboarding context in the suppression reason for audit clarity.

  • Review and remove the suppression once the integration reaches steady state.

Why it works: It reduces short‑term alert noise tied to expected integration behavior without masking alerts once the environment stabilizes or if similar activity appears outside the defined onboarding window.

Example 6: Shared jump host / bastion access generating repeat alerts

Scenario: Technicians routinely access customer environments through a shared jump host (bastion). This produces recurring alerts for predictable login patterns or access events.

Approach:

  • Scope the suppression to the specific product + event type that is generating the noise.

  • Add time‑based conditions (for example, business hours or a planned support window) rather than suppressing broadly.

  • Add location/IP conditions where appropriate to constrain to the known jump‑host network.

  • Prefer temporary suppressions during onboarding or migration periods; review once steady state is reached.

Why it works: It reduces predictable technician‑access noise while keeping the same alert type active for unexpected users, locations, or time windows.

Example 7: Shared admin tooling account used across tenants

Scenario: An MSP uses a shared admin tooling account (or automation identity) to run known maintenance tasks across multiple organizations. The activity is legitimate but triggers repetitive alerts.

Approach:

  • Scope suppression to the specific identity/account and event type.

  • Add a time window that matches the scheduled automation run.

  • Keep investigation visibility enabled unless there is a specific reason to exclude it.

Why it works: It reduces noise from a known operational identity without suppressing similar events from other accounts (which could indicate compromise).

Example 8: Onboarding burst from RMM deployment / scripted rollout

Scenario: During initial rollout, an MSP deploys agents, scripts, or integrations at scale. This creates a short‑term spike of expected alerts.

Approach:

  • Use date‑based (temporary) suppression for the rollout window.

  • Scope by product, event type, and (where possible) the specific organization(s) being onboarded.

  • Document the rollout/change reference in the suppression reason for auditability.

Why it works: It reduces onboarding noise without creating long‑term blind spots, because the suppression automatically expires and can be reviewed after the onboarding period.

Example 9: Advanced (optional) Shared device mappings during early Unify normalization

Scenario: During early deployment or environment changes, SIEM may generate repeated alerts related to device‑to‑user association states. This can occur in environments with shared devices, reused endpoints, or incomplete device mapping, where device and user relationships are still being normalized.

Approach:

  • Scope suppression to the specific event type(s) that become noisy during early device‑mapping or normalization activity.

  • When available, add a condition using device.unifyStatus to limit suppression to known transitional mapping states.

  • Use a temporary, date‑based suppression and review behavior once device and user associations stabilize.

Why it works: It limits alert noise only during known transitional mapping phases while preserving visibility and alerting once device‑to‑user relationships are fully established or if similar activity appears outside the defined scope.

Related articles