Detection and correlation model

Before you adjust alert severity, question alert volume, or try to “tune down noise,” it’s important to understand how Kaseya MDR decides that something is worth your attention.

Kaseya MDR uses a detection‑first, correlation‑driven model to evaluate large volumes of security telemetry and turn them into actionable alerts. Instead of generating alerts for every individual event, the platform looks for patterns, relationships, and behaviors that indicate meaningful security conditions.

This article explains how that process works—from raw telemetry, to detections, to alerts, to investigations—and why the results may look different from traditional, event‑centric security tools. Understanding this model will help you trust alert behavior, interpret investigations correctly, and avoid over‑tuning detections in ways that unintentionally reduce coverage.

This model underpins how alerts and investigations are presented throughout Kaseya MDR, even when individual events or signals are not directly visible.

This article is conceptual. It explains why alerts appear the way they do, not how to configure rules step by step.

Who should read this article

This article is especially important if you:

  • Review alert volume and question whether coverage is sufficient

  • Customize alert severity, suppression, or response behavior

  • Investigate incidents and need to understand how activity was grouped

  • Are responsible for tuning Kaseya MDR for multiple organizations

  • Need to explain why certain activity generated (or did not generate) an alert

If you primarily review alerts at a high level, you may not need every detail here. However, understanding this model will help you avoid common assumptions, such as expecting every security event to surface as an alert.

Why this understanding matters

Most alert fatigue (and most mistrust of security platforms) comes from misunderstanding how detection works.

Common misconceptions include:

  • Expecting every event to generate an alert

  • Assuming fewer alerts means reduced monitoring

  • Treating alerts as single events instead of summarized activity

Kaseya MDR is intentionally designed to avoid these patterns. The detection and correlation model exists to reduce noise while preserving investigative context, not to hide activity. The concepts in this article explain how that balance is achieved.

From telemetry to detection

Kaseya MDR continuously collects security telemetry from supported data sources, such as endpoints, infrastructure, network devices, and integrations.

This telemetry is evaluated by detections, which define the conditions under which activity becomes security‑relevant. Detections do not simply look at individual events in isolation. They may evaluate:

  • Event types and attributes

  • Frequency or repetition over time

  • Behavior across users, devices, or assets

  • Relationships between otherwise independent signals

Most telemetry is expected, benign, or informational. Detection exists to identify meaningful security conditions, not to surface every raw signal as an alert.

In practice, only activity that meets detection criteria is surfaced as alerts or included in investigations; most telemetry remains in the background unless it contributes to a security‑relevant condition.

Alert‑only vs. action‑capable detections

Detections in Kaseya MDR fall into two broad categories.

Alert‑only detections

Alert‑only detections identify activity that should be reviewed but does not automatically support response actions.

They are typically used to:

  • Surface suspicious or unusual behavior

  • Provide visibility without disruption

  • Support investigation and trend analysis

These alerts are designed to inform investigation, not to trigger immediate containment.

Action‑capable detections

Action‑capable detections identify activity that may warrant containment or remediation, depending on context.

These detections may support:

  • Automated response actions

  • SOC‑initiated actions

  • Manual response by users

Whether a detection is alert‑only or action‑capable depends on the detection logic and the type of activity involved. Not all alerts are designed, or intended, to result in action.

This distinction explains why some alerts in Kaseya MDR support response actions, while others are investigation‑focused and do not present response options.

Correlation is central to alert quality

Correlation is the process of connecting related activity into a single alert or investigation.

Instead of generating separate alerts for individual events, Kaseya MDR correlates:

  • Events over time

  • Activity across multiple devices or users

  • Signals from different data sources

This allows the platform to:

  • Reduce duplicate or redundant alerts

  • Identify broader attack patterns

  • Preserve context that individual events cannot convey

As a result, a single alert may represent:

  • Multiple underlying events

  • Activity spanning several minutes or hours

  • Behavior observed across different systems

This is expected behavior. Alerts are summaries of security conditions, not raw logs.

When reviewing an alert in Kaseya MDR, it is expected that the alert summarizes related activity rather than representing a single event. Investigation views preserve the underlying context that informed the alert.

Why you may not see every event as an alert

Kaseya MDR is intentionally not event‑centric.

You may notice that:

  • Some events appear only within an investigation.

  • Not every security signal generates a standalone alert.

  • Alerts often summarize patterns rather than individual actions.

This does not mean activity is missing or ignored. It means the platform is prioritizing attention and clarity over volume, while preserving access to supporting telemetry when deeper context is required.

Correlation across products and sources

Kaseya MDR is designed to correlate activity across multiple supported sources within its scope.

Correlation may include:

  • Endpoint activity combined with network behavior

  • Repeated actions by the same user or device

  • Related signals occurring within defined time windows

This approach helps identify activity that may appear harmless in isolation but becomes significant when viewed together.

Correlation occurs within the scope of data available to Kaseya MDR and does not imply cross‑domain SIEM correlation unless additional products are in use.

Detection outcomes and investigations

When detection and correlation criteria are met, Kaseya MDR generates an alert and associates it with an investigation.

The investigation:

  • Groups related activity

  • Preserves timelines and relationships

  • Provides the context needed to assess risk and impact

Detections do not operate in isolation. They feed into investigations that support informed decision‑making within Kaseya MDR, rather than prompting immediate or isolated responses to individual events.

What this model is optimized for

The detection and correlation model in Kaseya MDR is optimized to:

  • Reduce alert noise

  • Highlight actionable security conditions

  • Preserve investigative context

  • Support consistent response workflows

It is not designed to function as a raw log viewer or replace forensic tooling.

How this understanding helps in practice

Understanding the detection and correlation model helps you:

  • Trust alerts even when volumes are lower than expected

  • Avoid over‑tuning detections prematurely

  • Interpret investigations more accurately

  • Make informed decisions about response and automation

This model underpins how Kaseya MDR behaves throughout the platform.

With this model in mind, alert behavior should feel more predictable, investigations more coherent, and tuning decisions easier to reason about.

Related articles

To continue building on this model, see:

  • Detect > Investigate > Respond flow: Explains how alerts move through investigation and, when appropriate, response, clarifying how automation and human decision‑making fit into the lifecycle after detection

  • Agent architecture and security model: Describes how platform and agent design support detection, correlation, and response execution, including trust boundaries and architectural constraints

  • Using Kaseya MDR: Shows how detections, alerts, and investigations appear in day‑to‑day use, applying the concepts in this article to common workflows without focusing on configuration