This rule detects deletion of AWS Backup recovery points via CloudTrail management events. It targets DeleteRecoveryPoint events from backup.amazonaws.com that succeed and are not generated by AWS service principals (filters out aws.cloudtrail.user_identity.type: AWSService). A recovery point is a restorable backup for resources such as EBS, RDS, DynamoDB, EFS, S3, and others; deleting recovery points removes restore capability and is a common anti-recovery technique used in ransomware and data-destruction campaigns. Routine expirations are handled by AWS Backup itself, so non-service principal deletions are high-signal, especially when multiple recovery points or vaults are deleted in a short window. The rule is implemented as a Kuery query against the aws.cloudtrail dataset and integrates with the Elastic CloudTrail setup. It aligns with MITRE ATT&CK Inhibit System Recovery (T1490) under the Impact tactic. Triage involves identifying the actor (aws.cloudtrail.user_identity.arn and type), source origin, and the affected recovery point and vault (aws.cloudtrail.request_parameters); assess whether several points or vaults were impacted; and correlate with other destructive or evasion activities by the same principal. False positives include legitimate retention cleanup, migrations, or decommissioning; confirm intent and exclude known administration roles. Response guidance recommends treating unauthorized deletions as potential precursors to destructive activity: preserve remaining backups, enable Vault Lock where possible, rotate credentials, and restrict backup:DeleteRecoveryPoint to a trusted admin set. References include the AWS DeleteRecoveryPoint API and Vault Lock docs.