diff --git a/content/en/security_platform/cloud_siem/log_detection_rules.md b/content/en/security_platform/cloud_siem/log_detection_rules.md
index cf89ca419786a..9b06420b3a203 100644
--- a/content/en/security_platform/cloud_siem/log_detection_rules.md
+++ b/content/en/security_platform/cloud_siem/log_detection_rules.md
@@ -49,6 +49,14 @@ Anomaly detection is currently in
+Impossible travel is currently in public beta.
+
+
+Impossible travel detects access from different locations whose distance is greater than the distance a human can travel in the time between the two access events.
+
## Define a search query
{{< tabs >}}
@@ -126,6 +134,37 @@ Anomaly detection inspects how the `group by` attribute has behaved in the past.
**Note**: The query applies to all Datadog events and ingested logs that do not require indexing.
+{{% /tab %}}
+
+{{% tab "Impossible Travel" %}}
+
+### Search query
+
+Construct a search query using the same logic as a [log explorer search][1]. All logs matching this query are analyzed for a potential impossible travel. You can use the `preview` section to see which logs are matched by the current query.
+
+#### User attribute
+
+For the `user attribute`, select the field in the analyzed log that contains the user ID. This can be an identifier like an email address, user name, or account identifier.
+
+#### Location attribute
+
+The `location attribute` specifies which field holds the geographic information for a log. The only supported value is `@network.client.geoip`, which is enriched by the [GeoIP parser][2] to give a log location information based on the client's IP address.
+
+#### Baseline user locations
+
+Click the checkbox if you'd like Datadog to learn regular access locations before triggering a signal.
+
+When selected, signals are suppressed for the first 24 hours. In that time, Datadog learns the user's regular access locations. This can be helpful to reduce noise and infer VPN usage or credentialed API access.
+
+Do not click the checkbox if you want Datadog to detect all impossible travel behavior.
+
+#### Advanced options
+
+Click the **Advanced** option to add queries that will **Only trigger a signal when:** a value is met, or **Never trigger a signal when:** a value is met. For example, if a user is triggering a signal, but their actions are benign and you no longer want signals triggered from this user, create a logs query that excludes `@user.username: john.doe` under the **Never trigger a signal when:** option.
+
+[1]: /logs/search_syntax/
+[2]: /logs/log_configuration/processors#geoip-parser
+
{{% /tab %}}
{{< /tabs >}}
@@ -206,6 +245,26 @@ Once a signal is generated, the signal will remain "open" if the data remains an
A signal will "close" regardless of whether or not the anomaly is still anomalous once the time exceeds the maximum signal duration. This time is calculated from the first seen timestamp.
+[1]: /monitors/notify/?tab=is_alert#integrations
+{{% /tab %}}
+
+{{% tab "Impossible Travel" %}}
+
+The impossible travel detection method does not require setting a rule case.
+
+### Severity and notification
+
+Select an appropriate severity level for the security signal (`INFO`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`).
+
+In the “Notify” section, configure zero or more [notification targets][1].
+
+### Time windows
+
+An `evaluation window` is specified to match when at least one of the cases is true. This is a sliding window and evaluates in real-time.
+
+Once a signal is generated, the signal remains “open” if a case is matched at least once within the `keep alive` window. Each time a new event matches any of the cases, the *last updated* timestamp is updated for the signal.
+
+A signal closes regardless of the query being matched once the time exceeds the `maximum signal duration`. This time is calculated from the first seen timestamp.
[1]: /monitors/notify/?tab=is_alert#integrations
{{% /tab %}}