Managing alert severity and detection tuning

Kaseya MDR allows you to customize alert severity so that alerts reflect what actually matters in your environment. Proper severity tuning helps reduce unnecessary noise, prevents alert fatigue, and ensures that investigation and response effort is focused on meaningful security activity.

This article explains what can be configured from Settings > Customize Alert Severity tab, when each option should be used, and how these settings relate to investigation, suppression, and Respond rules.

This article explains how to configure and manage alert severity and detection tuning. It does not help you decide whether tuning, suppression, or Respond rules are appropriate. If you are deciding how alert behavior should change after investigation, start with Managing noise and signal or 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

What alert severity means in Kaseya MDR

Alert severity indicates the priority of an alert, not whether an alert represents a confirmed incident or requires response. Severity is used to:

  • Prioritize which alerts are reviewed first

  • Control which alerts generate notifications or PSA tickets (depending on configuration)

  • Help distinguish high‑confidence signals from informational activity

By default, Kaseya MDR assigns severity based on detection logic and correlation. Over time, you may find that some alert types are consistently lower value or more informational in your environment. Severity tuning allows you to adjust how those alerts are prioritized before considering suppression or automation.

When to tune alert severity

Consider adjusting alert severity when investigation shows that an alert type is:

  • High‑frequency but expected

  • Informational rather than actionable

  • Useful for audit or historical context, but not for immediate escalation

  • Generating unnecessary notifications or tickets

Severity tuning should always follow investigation. Do not adjust severity based on alert volume alone.

Before tuning severity, confirm that you have:

  • Reviewed representative alerts

  • Investigated related activity using the Analysis page

  • Confirmed the behavior is understood and acceptable in context

Severity tuning compared to other options

Alert severity tuning is one of several ways to manage alert behavior. Choosing the correct option avoids hiding meaningful activity.

  • Severity tuning: Changes how alert types are prioritized globally going forward. Best for alerts that are consistently low urgency across the environment

  • Alert suppression: Prevents specific alerts from surfacing under defined conditions: Prevents alerts from surfacing under specific, well‑defined conditions. Best for scoped exceptions, not global behavior changes

  • Respond rules: Correlate multiple signals into higher‑confidence alerts or automate response. Best when individual alerts are insufficient on their own

In general:

  • Prefer severity tuning for globally low‑value alert types

  • Use suppression for narrow, well‑defined exceptions

  • Use Respond rules when combined behavior is meaningful

NOTE  This article implements severity tuning only. Decision‑making guidance lives in Managing noise and signal and Managing repeated alerts.

Understanding the Customize Alert Severity tab

The Customize Alert Severity tab controls how alerts are prioritized and finalized before they appear for review. All settings on this page apply globally and affect future alerts only.

This tab includes three types of controls: alert‑level severity overrides, default severity mode, and latent time handling.

Custom alert severity overrides

Each alert type listed on the Customize Alert Severity tab has a Default Severity, shown in the Default Severity column. This value represents the system’s baseline prioritization for that alert type before any customization is applied.

You can override this behavior by selecting a different value from the Custom Severity drop-down menu for a specific alert type. This allows you to adjust how that alert is prioritized when investigation shows it is consistently higher or lower value in your environment.

Custom severity overrides:

  • Apply globally to all future alerts of that alert type

  • Do not suppress data collection or detection

  • Preserve alert visibility for investigation and audit

  • Are typically preferred over suppression for alert types that are consistently low value across the environment

Existing alerts retain their original severity. Severity overrides affect future alerts only.

To help manage changes over time, the Customized only filter shows only alert types where the Custom Severity differs from the platform default. This view makes it easier to review, validate, and maintain severity adjustments without scanning the full alert catalog.

Default severity mode

The Mode setting controls the baseline severity model applied across the alert library.

  • Quiet mode applies conservative default severities designed to reduce noise and unnecessary escalation. This mode is recommended for most environments, especially during onboarding or early tuning

  • Expert mode applies more aggressive default severities intended for environments that require higher sensitivity and faster escalation

Changing the mode does not override existing custom severity settings.

The current mode and latent time configuration are displayed at the top of the page for visibility.

Quiet mode defines the default baseline severities applied across the alert library. For details on how default severities differ when Quiet mode is enabled, see Quiet mode.

Latent time period

Some data sources deliver events after a delay due to batching, processing, or vendor behavior. The Latent time period setting allows Kaseya MDR to account for this delay before finalizing alert behavior.

The latent time period:

  • Allows late‑arriving data to be considered during correlation

  • Helps alerts reflect more complete activity context

  • Reduces escalation based on partial or out‑of‑order data

This setting is especially important in environments with SaaS integrations or asynchronous data sources.

Using Analysis to validate severity changes

The Analysis page is the recommended way to validate severity tuning decisions.

Before changing severity:

  • Use Analysis to review alert volume over a 1–2 week period

  • Filter by Medium and Critical alerts to see which alerts would have generated escalation

  • Identify alert types that dominate volume without changing investigation outcomes

After changing severity:

  • Use Analysis again to confirm that alert volume is reduced as expected

  • Verify that important activity still surfaces with sufficient priority

  • Confirm that visibility for investigation and audit purposes is preserved

Severity tuning should reduce unnecessary escalation without hiding meaningful security signals.

Best practices for alert severity tuning

  • Start conservatively. Lower severity gradually rather than making large changes

  • Tune based on evidence from investigation, not assumptions

  • Re‑evaluate severity periodically as your environment and integrations evolve

  • Avoid using severity tuning to hide activity that may still be relevant for investigation

  • Document why severity changes were made to preserve decision context

How this fits into the MDR workflow

Alert severity tuning is part of detection governance, not day‑to‑day alert review.

A typical workflow looks like:

  1. Review alerts and decide what requires investigation

  2. Investigate activity using the Analysis page

  3. Identify patterns that are consistently low value or high noise

  4. Tune alert severity where appropriate

  5. Use suppression or Respond rules only when severity tuning is insufficient

Related articles

  • Working with alerts: Learn how to review alerts in Events, understand what they represent, and decide whether deeper investigation is required before taking any action

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

  • Managing noise and signal: Decide whether alert behavior should change after investigation, and choose the least disruptive approach—severity tuning, suppression, or automation—based on evidence

  • Managing repeated alerts: Apply investigation‑first decision‑making to alerts that recur frequently, and determine when severity tuning, suppression, or no action is appropriate