diff --git a/config/_default/menus/main.en.yaml b/config/_default/menus/main.en.yaml
index b2107587a79a6..2ed1b4168fffe 100644
--- a/config/_default/menus/main.en.yaml
+++ b/config/_default/menus/main.en.yaml
@@ -6080,6 +6080,11 @@ menu:
       parent: cloud_siem
       identifier: siem_guides
       weight: 11
+    - name: Data Security
+      url: data_security/cloud_siem/
+      parent: cloud_siem
+      identifier: siem_data_security
+      weight: 12
     - name: Cloud Security
       url: security/cloud_security_management
       parent: security_platform_heading
@@ -8009,51 +8014,56 @@ menu:
       url: data_security/agent/
       parent: data_security
       weight: 1
-    - name: Tracing
-      identifier: data_security_tracing
-      url: /tracing/configure_data_security/
+    - name: Cloud SIEM
+      identifier: data_security_cloud_siem
+      url: data_security/cloud_siem/
       parent: data_security
       weight: 2
-    - name: Log Management
-      identifier: data_security_log_management
-      url: data_security/logs/
-      parent: data_security
-      weight: 3
     - name: Kubernetes
       identifier: data_security_kubernetes
       url: data_security/kubernetes
       parent: data_security
       weight: 4
-    - name: Synthetic Monitoring
-      identifier: data_security_synthetic_monitoring
-      url: data_security/synthetics/
+    - name: Log Management
+      identifier: data_security_log_management
+      url: data_security/logs/
       parent: data_security
-      weight: 5
+      weight: 4
     - name: Real User Monitoring
       identifier: data_security_real_user_monitoring
       url: data_security/real_user_monitoring/
       parent: data_security
+      weight: 5
+    - name: Synthetic Monitoring
+      identifier: data_security_synthetic_monitoring
+      url: data_security/synthetics/
+      parent: data_security
       weight: 6
+    - name: Tracing
+      identifier: data_security_tracing
+      url: /tracing/configure_data_security/
+      parent: data_security
+      weight: 7
     - name: PCI Compliance
       identifier: data_security_pci_compliance
       url: data_security/pci_compliance/
       parent: data_security
-      weight: 7
+      weight: 8
     - name: HIPAA Compliance
       identifier: data_security_hipaa_compliance
       url: data_security/hipaa_compliance/
       parent: data_security
-      weight: 8
+      weight: 9
     - name: Data Retention Periods
       identifier: data_retention_periods
       url: data_security/data_retention_periods/
       parent: data_security
-      weight: 9
+      weight: 10
     - name: Guides
       identifier: data_security_guide
       url: data_security/guide/
       parent: data_security
-      weight: 9
+      weight: 11
     - name: Help
       url: help/
       pre: info-fill
diff --git a/content/en/data_security/cloud_siem.md b/content/en/data_security/cloud_siem.md
new file mode 100644
index 0000000000000..cf739e60869e9
--- /dev/null
+++ b/content/en/data_security/cloud_siem.md
@@ -0,0 +1,62 @@
+---
+title: Cloud SIEM Data Security
+disable_toc: false
+further_reading:
+- link: "/data_security/"
+  tag: "Documentation"
+  text: "Review the main categories of data submitted to Datadog"
+- link: "/data_security/pci_compliance/"
+  tag: "Documentation"
+  text: "Set up a PCI-compliant Datadog organization"
+---
+
+<div class="alert alert-info">This page is about the security of data sent to Datadog. If you're looking for cloud and application security products and features, see the <a href="/security/" target="_blank">Security</a> section.</div>
+
+## Overview
+
+Datadog generates a security signal when at least one case defined in a detection rule is matched over a given period of time. You can customize detection rules to provide notification messages that contain specific information about the signal (for example, user ID, IP addresses, and so on) and the triggering group-by values of the signal. Security rules can also use webhooks to send notifications to third-party services.
+
+Because data sent to Datadog may contain sensitive information, this document goes over those notification features and what to do if you do not want your users to have access to these features.
+
+## Security rules can use message template variables
+
+When you create a detection rule you can customize the notification message with [notification variables][1], which adds specific information related to the signal. For example, if the following JSON object is associated with a security signal:
+
+```
+{
+  "network": {
+    "client": {
+      "ip": "1.2.3.4"
+    }
+  },
+  "user": {
+    "id": "user@domain.com"
+  },
+  "used_mfa": "false"
+}
+```
+Using `{{@network.client.ip}}` in the notification message would display the IP address associated with the signal.
+
+Contact [support][2] if you want to prevent users from adding template variables to notification messages.
+
+## Security rules can include triggering group-by values in the notification title
+
+In the **Describe your playbook** sections for [log detection rules][3] and [signal correlation rules][4], you can add group-by values in the notification title. For example, if you are grouping by `service`, the service name shows in the title. Uncheck **Include triggering group-by values in notification title** to prevent group-by values from appearing in the title.
+
+Contact [support][2] if you want to remove the **Include triggering group-by values in notification title** option.
+
+## Security rules can use webhooks
+
+<div class="alert alert-warning">If your organization had HIPAA enabled in 2024 or earlier, reach out to <a href = "https://docs.datadoghq.com/help/">Datadog support</a> to enable webhooks for security rules.</a></div>
+
+Security notifications can be sent to [integrations][5], such as Jira, PagerDuty, and [webhooks][6]. Contact [support][2] to prevent users from sending notifications to third-party services using webhooks.
+
+## Further reading
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /security/notifications/variables/?tab=cloudsiem#template-variables
+[2]: /help/
+[3]: /security/cloud_siem/log_detection_rules/?tab=threshold#describe-your-playbook
+[4]: /security/cloud_siem/signal_correlation_rules#describe-your-playbook
+[5]: /security/notifications/#integrations
+[6]: /integrations/webhooks/
\ No newline at end of file
diff --git a/content/en/security/cloud_siem/detection_rules/_index.md b/content/en/security/cloud_siem/detection_rules/_index.md
index 3e49c5e9064b9..84487ac9917b5 100644
--- a/content/en/security/cloud_siem/detection_rules/_index.md
+++ b/content/en/security/cloud_siem/detection_rules/_index.md
@@ -386,7 +386,7 @@ One way to decrease signal noise is to prioritize production environment signals
 
 The severity decrement is applied to signals with an environment tag starting with `staging`, `test`, or `dev`.
 
-## Say what's happening
+## Describe your playbook
 
 {{% security-rule-say-whats-happening %}}
 
@@ -394,6 +394,8 @@ Use the **Tag resulting signals** dropdown menu to add tags to your signals. For
 
 **Note**: the tag `security` is special. This tag is used to classify the security signal. The recommended options are: `attack`, `threat-intel`, `compliance`, `anomaly`, and `data-leak`.
 
+See [Cloud SIEM Data Security][7] for more information on securely using message template variables, group-by values in the notification title, and webhooks.
+
 ## Suppression rules
 
 Optionally, add a suppression rule to prevent a signal from getting generated. For example, if a user `john.doe` is triggering a signal, but their actions are benign and you do not want signals triggered from this user, add the following query into the **Add a suppression query** field: `@user.username:john.doe`.
@@ -441,3 +443,4 @@ The rule deprecation process is as follows:
 [4]: https://app.datadoghq.com/security/rules
 [5]: /security/cloud_siem/historical_jobs/
 [6]: /security/default_rules/?category=cat-cloud-siem-log-detection#all
+[7]: /data_security/cloud_siem/
diff --git a/content/en/security/cloud_siem/detection_rules/signal_correlation_rules.md b/content/en/security/cloud_siem/detection_rules/signal_correlation_rules.md
index 724924728d96a..8ff7f04ccc250 100644
--- a/content/en/security/cloud_siem/detection_rules/signal_correlation_rules.md
+++ b/content/en/security/cloud_siem/detection_rules/signal_correlation_rules.md
@@ -62,7 +62,7 @@ Click **Add Case** to add additional cases.
 
 **Note**: The `evaluation window` must be less than or equal to the `keep alive` and `maximum signal duration`.
 
-### Say what's happening
+### Describe your playbook
 
 {{% security-rule-say-whats-happening %}}
 
@@ -70,8 +70,11 @@ Use the **Tag resulting signals** dropdown menu to add tags to your signals. For
 
 **Note**: the tag `security` is special. This tag is used to classify the security signal. The recommended options are: `attack`, `threat-intel`, `compliance`, `anomaly`, and `data-leak`.
 
+See [Cloud SIEM Data Security][2] for more information on securely using message template variables, group-by values in the notification title, and webhooks.
+
 ## Further reading
 
 {{< partial name="whats-next/whats-next.html" >}}
 
 [1]: https://app.datadoghq.com/security/configuration/rules?product=siem
+[2]: /data_security/cloud_siem/