Terminology and concepts

Kaseya MDR uses an alert‑centric security model. Understanding the concepts in this article will help you interpret alerts correctly, understand investigations, and make informed response decisions.

This article explains concepts only. It does not describe configuration steps or click‑by‑click workflows.

Summary: Core concepts that prevent wrong assumptions

• Events are raw security data; alerts are actionable findings

• Alerts drive investigations; investigations inform responses

• Kaseya MDR is alert‑centric, not event‑centric

• Detection and correlation determine when alerts are created

• Severity helps prioritize work, but does not replace investigation

• Defaults define baselines; overrides define intentional exceptions

• Automation accelerates response but does not replace human judgment

Telemetry, events, and alerts

Telemetry

Telemetry is a general term for security‑relevant data collected from systems and services. Telemetry may include logs, metrics, signals, or activity records, and is ingested from multiple sources to provide visibility across an environment.

Event

An event is a single piece of security telemetry collected from a data source (for example: authentication activity, process execution, network connections, or configuration changes). Events are raw signals and do not necessarily indicate malicious activity. In Kaseya MDR, events are inputs, not the primary interface.

Alert

An alert represents a security‑relevant condition identified after evaluating and correlating one or more events. Alerts are designed to be actionable and context‑rich, and Kaseya MDR intentionally generates fewer alerts than events to reduce noise and focus attention on activity that requires investigation or response. Alerts are the primary unit of attention in the interface.

IMPORTANT  Events are data. Alerts are the platform signaling “this deserves attention.”

Alert‑centric vs. event‑centric security

Event‑centric model

In an event‑centric model, users focus on raw activity. Large volumes of events must be reviewed to find meaningful issues and context is built manually.

This approach becomes difficult to scale in larger environments.

Alert‑centric model

Kaseya MDR uses an alert‑centric model. Alerts surface what requires attention, correlation reduces noise, and investigations start from actionable findings. This design helps teams prioritize, investigate, and respond more efficiently.

Agent

The Kaseya MDR agent is a lightweight endpoint component that collects security‑relevant telemetry and executes response actions when instructed by the platform, subject to availability and connectivity.

The agent is shared across Kaseya MDR and Kaseya SIEM and is the continued evolution of the RocketCyber agent. Because the same agent is used across products, documentation generally refers to it as the agent, rather than defining separate RocketCyber, MDR, or SIEM agents. Product behavior and available capabilities are determined by the platform, not by deploying different agents.

The agent does not independently determine severity, confirm incidents, or decide responses. Detection, correlation, investigation, and decision‑making occur at the platform level. The agent acts as a sensor and execution point, not an autonomous security decision‑maker.

This distinction helps clarify how alerts, investigations, and response actions are coordinated without assuming local enforcement or continuous connectivity.

Detection and correlation

Detection

A detection defines the logic used to evaluate events and determine whether an alert should be generated. Detections may consider event types, time windows, thresholds/frequency, and correlated activity across sources. Some alerts are detection‑only and are intended to prompt investigation or awareness rather than immediate action.

Correlation

Correlation is the process of connecting related events across time, devices, users, or data sources to form a single alert or investigation. Correlation reduces duplicate alerts, identifies broader patterns, and provides context that individual events cannot.

Detection logic vs. response capability

Detection logic and response capability are related but independent concepts in Kaseya MDR.

A detection defines when security activity is elevated into an alert. Whether an alert supports response actions depends on the alert type, data source, and configuration.

• Some alerts are detection‑only and are intended to prompt investigation or awareness.

• Other alerts may support manual or automated response actions.

• The presence or absence of a response option does not reflect the quality or importance of the detection itself.

This distinction helps explain why some alerts can trigger response actions while others are informational but still security‑relevant.

Investigation vs. Response

Investigation

An investigation is the collection of related activity associated with an alert. Investigations provide context, related events, a timeline of activity, and supporting details used to assess risk and impact.

In Kaseya MDR, investigations:

• Combine related activity into a single view

• Provide context across users, devices, and assets

• Help determine scope and impact

Investigations typically occur before taking response actions. Investigation answers the question: What happened, and how serious is it?

For more detail on how investigations work in practice, see Using the Analysis page for unified investigations.

Response action

A response action is an action taken to contain, mitigate, or resolve a security issue. Response actions may be automated, initiated by the SOC, or triggered manually by a user. Not all alerts support response actions; availability depends on the alert type and configuration.

Response actions may include:

• Isolating a device

• Restoring a device

• Taking other containment steps

IMPORTANT  Investigation helps you understand the issue. Response is what you do about it.

Response answers the question: What should we do about it? For more information about available response actions, see Response actions.

Incident

An incident is a confirmed security event that requires active response.

In Kaseya MDR, the term incident is intentionally reserved for situations where investigation has confirmed malicious activity or compromise that requires containment, remediation, or coordinated response.

Not every alert represents an incident.

• Alerts indicate that activity met detection criteria

• Investigations provide context to assess scope, intent, and impact

• Incidents represent confirmed events that require response

This distinction exists to prevent premature escalation and unnecessary disruption.

Important for RocketCyber customers

In RocketCyber, the term incident was used more broadly to describe high‑priority detections. In Kaseya MDR, those detections are now surfaced as alerts and investigations. They may become incidents after investigation, but they are not treated as incidents by default.

This change reflects a more precise security model:

Detection does not assume impact

Investigation determines severity and scope

Incident classification is deliberate and evidence‑based

Understanding this distinction helps ensure that response actions and SOC involvement are reserved for confirmed security events.

Automation

Automation refers to predefined actions that occur automatically when certain alert conditions are met. Automation is designed to speed up response, reduce manual effort, and support consistent handling of common scenarios. It is intended to augment human decision‑making, not replace it.

Manual vs. automated response actions

Manual response actions

They are initiated by a user or analyst, allow human judgment before action, and are useful for complex or high‑impact situations

Automated response actions

They trigger automatically when defined conditions are met, reduce response time, and are suited for repeatable, high‑confidence scenarios.

Both manual and automated responses use the same underlying response capabilities.

Alert severity

Kaseya MDR assigns severity to help teams prioritize investigation and response. Severity supports consistent communication and reduces alert fatigue, but it does not replace investigation or context. Severity is an indicator—not a verdict.

Severity reflects prioritization, not certainty. Confidence is established through investigation, correlation, and context provided by the alert and related activity. An alert with high severity still requires investigation to confirm scope, intent, and impact.

Alert validity vs. response execution

An alert represents a security‑relevant condition that has already been detected and correlated. Whether a response action executes successfully does not determine whether the alert is valid.

If a response action cannot execute (for example, due to reachability at execution time), the alert or investigation may show a failed or pending response status. That outcome reflects execution conditions, not alert validity or whether monitoring stopped.

Coverage vs. visibility

Kaseya MDR is designed to reduce noise by surfacing actionable security conditions rather than exposing every raw event. As a result, seeing fewer alerts does not automatically mean reduced monitoring or reduced coverage. The platform intentionally generates fewer alerts than events to focus attention on what requires investigation or response.

Coverage vs. enforcement

Coverage refers to Kaseya MDR’s ability to detect and evaluate security‑relevant activity across supported data sources.

Enforcement refers to the ability to take response actions to contain or mitigate an issue.

Detection coverage does not imply enforcement in every case:

• Activity may be detected and alerted even if no response action is available.

• Some alerts support investigation only, while others may support response actions under specific conditions.

• Response execution may also depend on reachability, permissions, and timing.

Understanding this distinction helps prevent assumptions that detection always results in automatic containment or remediation.

Defaults vs. overrides

Defaults

Kaseya MDR includes default detections and behavior designed to provide effective coverage out of the box. They are baseline settings defined at the provider or MSP level.

They represent the standard security configuration, apply automatically unless overridden, and help maintain consistency across environments.

Overrides

Organization overrides are settings that differ from global defaults for a specific organization. They allow you to adjust behavior for specific environments, reduce noise where appropriate, and align detection/response with operational needs. Understanding the difference helps prevent unintended gaps in coverage.

They are used to:

• Accommodate unique customer requirements

• Handle exceptions without changing the baseline

• Maintain visibility into configuration differences

IMPORTANT  Global defaults define the standard. Overrides define intentional exceptions.

For related configuration concepts, see Global defaults and organization overrides.

AI‑assisted investigation (emerging concept)

Kaseya MDR is introducing AI‑assisted capabilities intended to support investigation by helping with telemetry interrogation, anomaly detection, and guided investigation. AI‑assisted investigation is designed to augment analysts, not replace human judgment or SOC involvement. Availability and scope of AI‑assisted features may vary by release.

How these concepts apply across products

Many of these concepts are shared across Kaseya security products that use an alert‑centric model. Understanding them here helps you interpret alerts, investigations, correlation, and response consistently across products that share this foundation.

While data sources and capabilities may differ by product, the underlying concepts remain consistent.

Why these distinctions matter

These concepts map directly to how Kaseya MDR behaves in practice. Misunderstanding them can lead to assumptions such as expecting every event to appear as an alert, assuming fewer alerts means reduced coverage, or treating automation as fully autonomous response. This terminology exists to help you interpret what the platform is showing—and not showing—accurately.

Related articles

• Detection and correlation model: Explains how raw telemetry is evaluated, combined, and elevated into alerts, and why correlation reduces noise without reducing coverage

• Detect > Investigate > Respond flow: Describes how alerts progress through investigation and, when appropriate, response, clarifying where automation applies and where human judgment is required.

• Using Kaseya MDR: Applies the concepts defined here to common workflows, helping you navigate alerts, investigations, and response actions in day‑to‑day use