---
title: Detection rule concepts
description: Understand key concepts that apply to all detection rules, including data sources, authorization, exceptions, and notifications.
url: https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/detection-rule-concepts
products:
  - Elastic Cloud Serverless
  - Elastic Security
applies_to:
  - Serverless Security projects: Generally available
  - Elastic Stack: Generally available
---

# Detection rule concepts
Before creating detection rules, familiarize yourself with the foundational concepts that apply across all rule types. Understanding these concepts helps you design effective rules and troubleshoot issues when they arise.

## How detection rules work

At a high level, a detection rule can be broken down into three parts:

| Part         | Purpose                                                                                                                                                                                                                                                                                                               |
|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Query        | Specifies the threat behavior or pattern to detect. The query searches your [data sources](#data-sources-concept) using syntax that varies by [rule type](https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/choose-the-right-rule-type) (for example, ES|QL, KQL, or EQL).    |
| Schedule     | Controls how often the rule runs and how far back it searches. The interval you set determines both. For example, a rule with a 5-minute interval runs every 5 minutes and searches the last 5 minutes of data each time. An optional look-back setting extends the search window to help catch late-arriving events. |
| Rule actions | Specifies what happens when the rule detects a match. You can [send notifications](#notifications-concept), create tickets, or trigger actions on external systems.                                                                                                                                                   |

These three parts work together when a rule runs:
1. At each scheduled interval, the rule runs its query against your data sources.
2. The rule creates alerts for events that match the query (unless [exceptions](#exceptions-concept) apply).
3. Configured rule actions notify your team or trigger actions on external systems.

Behind the scenes, rules execute using the [authorization](#rule-authorization-concept) of the user who last edited them.

## Data sources

A rule's query runs against the data sources you configure. When you create a rule (except for machine learning rules, which use anomaly jobs), you specify either:
- **Index patterns**: Wildcards like `logs-*` or `filebeat-*` that match one or more indices.
- **Data views**: Named references to index patterns that can include [runtime fields](https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/get-started/create-runtime-fields-in-elastic-security) for computed values at query time.

Data views are useful when you need consistent field definitions across multiple rules or want to add fields without reindexing data. ES|QL rules do not support data views—specify source indices directly in the query's `FROM` command, using index patterns or [aliases](https://www.elastic.co/elastic/docs-builder/docs/3028/manage-data/data-store/aliases).
For guidance on configuring rule data sources, refer to [Set rule data sources](https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/set-rule-data-sources).
<note>
  To use data views in Elastic Stack, you must have the [required permissions](/elastic/docs-builder/docs/3028/explore-analyze/find-and-organize/data-views#data-views-read-only-access). In Serverless, you must have the appropriate [predefined Security user role](/elastic/docs-builder/docs/3028/deploy-manage/users-roles/cloud-organization/user-roles#general-assign-user-roles) or a [custom role](https://www.elastic.co/elastic/docs-builder/docs/3028/deploy-manage/users-roles/cloud-organization/user-roles) with the right privileges.
</note>

<important>
  System indices, such as the alert indices, contain important configuration and internal data. Do not change their mappings. Changes can lead to rule execution and alert indexing failures. Use [runtime fields](https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/get-started/create-runtime-fields-in-elastic-security) instead to add fields to existing alert and event documents.
</important>


## Exceptions

Exceptions refine a rule's query by excluding specific conditions from generating alerts—even when the query criteria are met. Use exceptions to:
- Exclude trusted processes, IP addresses, or user accounts
- Filter out known-benign activity specific to your environment
- Reduce alert noise without modifying the rule's query logic

Exceptions can be scoped to a [single rule](https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/add-manage-exceptions) or shared across multiple rules using [shared exception lists](https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/create-manage-shared-exception-lists). You can add exceptions to all rule types.

## Rule actions and notifications

Rule actions are automated responses that a rule triggers when it generates alerts. You can configure rule actions to run for every alert, at scheduled intervals, or only when alerts meet specific conditions (such as high severity). Rule actions are configured in the **Actions** tab of the rule settings. For details, refer to [Rule actions](/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/common-rule-settings#rule-notifications).
Rule actions fall into two categories: external and system actions.

### External actions

External actions use connectors to:
- Send notifications (Slack messages, emails, PagerDuty alerts) to inform your team in real time
- Create tickets in Jira or ServiceNow for tracking and triage
- Trigger webhooks or custom integrations


### System actions

System actions operate within Kibana to:
- Create or update cases automatically
- Add entries to indices for tracking or enrichment
- Trigger [workflows](https://www.elastic.co/elastic/docs-builder/docs/3028/explore-analyze/workflows) for more complex automation


## Rule authorization

<applies-to>
  - Elastic Cloud Serverless: Generally available
  - Elastic Stack: Generally available
</applies-to>

Rules run in the background using the privileges of the user who last edited them. When you create or modify a rule, Elastic Security generates an [API key](https://www.elastic.co/elastic/docs-builder/docs/3028/deploy-manage/api-keys/elasticsearch-api-keys) that captures a snapshot of your current privileges. The rule uses this API key to:
- Execute detection queries against the configured data sources
- Write alerts to the alerts index
- Execute actions (send notifications)

This means rules continue running with their editor's privileges, even when that user is not logged in.
<important>
  Ensure that only users with the [appropriate access](https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/detections-privileges) edit rules.If a user without the required privileges (such as index read access) updates a rule, the rule can stop functioning correctly and no longer generate alerts. To fix this, a user with the required privileges (such as access to manage rules) must do one of the following:
  - **Edit and save the rule**: This regenerates the API key with the current user's privileges. Refer to [Manage detection rules > Edit rule settings](/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/manage-detection-rules#edit-rules-settings) to learn more.
  - **Update the API key directly**: This allows the rule configuration to remain unchanged. Refer to [Cross-cluster search and detection rules > Update a rule’s API key](/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/cross-cluster-search-detection-rules#update-api-key) to learn more.
  Either action rebinds the rule to a user who has the necessary access.
</important>


## Key terms quick reference

<definitions>
  <definition term="Rule actions">
    Automated responses a rule triggers when it generates alerts. Rule actions can send data to external services using connectors, or perform operations within Kibana such as creating cases or triggering workflows.
  </definition>
  <definition term="Alerts">
    Records created when a rule's query finds matching events. Each alert represents a potential threat for analysts to investigate.
  </definition>
  <definition term="API key">
    A credential that captures the privileges of the user who last edited a rule. Rules use API keys to execute queries and write alerts.
  </definition>
  <definition term="Connectors">
    Integrations that connect actions to external services like Slack, Jira, or PagerDuty.
  </definition>
  <definition term="Data sources">
    The Elasticsearch indices or data views that a rule's query searches. Configured using index patterns or data views.
  </definition>
  <definition term="Data views">
    Named references to index patterns that can include runtime fields. Useful for consistent field definitions across rules.
  </definition>
  <definition term="Exceptions">
    Conditions that prevent a rule from generating alerts, even when query criteria are met. Used to exclude trusted activity.
  </definition>
  <definition term="Index patterns">
    Wildcards (like `logs-*`) that match one or more Elasticsearch indices.
  </definition>
  <definition term="Notifications">
    A type of action that signals something needs attention (Slack messages, emails, PagerDuty alerts).
  </definition>
  <definition term="Query">
    The logic that defines what threat behavior or pattern a rule detects. Syntax varies by rule type.
  </definition>
  <definition term="Rule authorization">
    The privilege model that determines what a rule can access. Rules execute using an API key tied to the user who last edited them.
  </definition>
  <definition term="Rule type">
    The detection method a rule uses (custom query, EQL, threshold, indicator match, new terms, ES|QL, or machine learning).
  </definition>
  <definition term="Schedule">
    How often a rule runs and how far back it looks for matching events.
  </definition>
</definitions>


## Related resources

- [Common rule settings](https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/common-rule-settings): Full reference for all rule configuration options
- [Select the right rule type](https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/choose-the-right-rule-type): Compare rule types and find the best fit for your use case
- [Detections privileges](https://www.elastic.co/elastic/docs-builder/docs/3028/solutions/security/detect-and-alert/detections-privileges): Required permissions for creating and managing rules