--- title: Finding Rules description: >- Create and manage the backend rules that evaluate your runtime security posture and generate Workload Protection findings. breadcrumbs: >- Docs > Datadog Security > Workload Protection > Detect and Monitor > Detection and Finding Rules > Finding Rules --- > For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt). # Finding Rules Finding rules describe the backend logic used to evaluate your runtime security posture by analyzing [Agent events](https://docs.datadoghq.com/security/workload_protection/investigate_and_triage/agent_events.md). When a finding rule matches, Workload Protection generates a [finding](https://docs.datadoghq.com/security/workload_protection/investigate_and_triage/security_findings.md) for the affected resource. Unlike [detection rules](https://docs.datadoghq.com/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md), which surface real runtime security threats, finding rules track ongoing bad practices and misconfigurations. A finding represents a resource (a host or container) that is actively failing a security policy, not a single suspicious activity. Finding rules use existing Agent events to surface practical security recommendations such as package manager usage in containers, IMDS access patterns, or unnecessary privilege configurations. This helps you address real-world risks that are not direct threats but represent risky practices in production environments. ## OOTB finding rules{% #ootb-finding-rules %} Workload Protection includes out-of-the-box (OOTB) finding rules maintained by Datadog. These rules continuously surface bad practices and risky configurations in production workloads. Datadog develops new default rules on an ongoing basis, and new rules are automatically imported into your account. For the full list, see [OOTB rules list](https://docs.datadoghq.com/security/default_rules.md#workload-activity). Browse and review finding rules deployed to your organization in the Workload Protection [finding rules](https://app.datadoghq.com/security/workload-protection/finding-rules) list in Datadog. Each rule includes a description of the security risk, the resource types it applies to, and remediation guidance. To reduce noise for expected configurations, use a findings automation to mute a rule without disabling it. See [Findings automation](https://docs.datadoghq.com/security/automation_pipelines/mute.md). ## Create a custom finding rule{% #create-a-custom-finding-rule %} Custom finding rules follow the same creation process as [detection rules](https://docs.datadoghq.com/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md), with one key difference: they target a specific resource type—host or container—rather than detecting a point-in-time event. To create a custom finding rule, go to the Workload Protection [finding rules](https://app.datadoghq.com/security/workload-protection/finding-rules) page and click New Rule. The rule editor walks you through five steps. ### Step 1: Select a resource type and define search query{% #step-1-select-a-resource-type-and-define-search-query %} Select the type of resource the finding rule evaluates: - Host: The rule applies to hosts. Workload Protection automatically prepends `-@container.id:*` to your query to exclude container events. - Container: The rule applies to containers. Workload Protection automatically prepends `@container.id:*` to your query to include only container events. {% image source="https://docs.dd-static.net/images/security/workload_protection/detect_and_monitor/finding_rules_editor.8694396c5921b26afe9bc3fb6d74a23e.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/workload_protection/detect_and_monitor/finding_rules_editor.8694396c5921b26afe9bc3fb6d74a23e.png?auto=format&fit=max&w=850&dpr=2 2x" alt="Finding rule editor showing the Host and Container resource type selector and search query preview" /%} Define the query that selects which [Agent events](https://docs.datadoghq.com/security/workload_protection/investigate_and_triage/agent_events.md) the rule evaluates. The search query determines which events are considered when deciding whether a resource is failing the rule. You can: - Filter on **specific fields** in Agent events to refine the query and make the finding more precise. For example, filter on `@process.executable.path`, `@file.path`, or `@agent.rule_id`. Similar to [detection rules](https://docs.datadoghq.com/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md), finding rules can query any field from the backend event schema, which includes all Agent event fields plus additional enrichment such as infrastructure context, process ancestry, and threat intelligence. See [Linux backend syntax](https://docs.datadoghq.com/security/workload_protection/backend_linux.md) and [Windows backend syntax](https://docs.datadoghq.com/security/workload_protection/backend_windows.md) for the full set of available fields. - Combine multiple conditions to scope the rule to a subset of your infrastructure or workloads. Use the [Agent Events Explorer](https://app.datadoghq.com/security/agent-events) to test your query and validate which events match before you publish the rule. ### Step 2: Define finding severity{% #step-2-define-finding-severity %} Define the severity a finding has when the rule is triggered. ### Step 3: Describe the finding{% #step-3-describe-the-finding %} Configure the **name**, **description**, and **remediation guidance** that appear when a finding is generated. 1. Enter a Rule name. The name appears in the finding rules list and becomes the title of the generated finding. 1. In the Rule message section, use Markdown to describe what the finding means and how to address it. Include a `## Remediation` header in the message body—Workload Protection uses this section to surface remediation steps directly in the finding side panel. 1. Use the Tag resulting findings dropdown to add tags to generated findings. For example, `security:posture` or `compliance:pci`. **Note**: The `## Remediation` header is required for remediation steps to display correctly in the finding side panel.