OPINION Traditionally, security incident records have a singular, crucial purpose: documenting what the organization observed, decided, and did. Security teams treat these records, including closure notes, rule text, false-positive dispositions, and the reasons alerts were dropped, as part of the ticket queue. Security automation has been around for quite some time.
When incident records are ingested into a security AI system with permission to capture data for model development or validation, this evidence can become valuable data for the vendor.
Related: What We Missed: Knicks Phishing Test Goes Out of Bounds A single closure is relatively safe. ## Copilot Options: 9 Cybersecurity Tips That Match Today's Threat Landscape Each setting's default varies based on how the workspace was provisioned. Customers who enabled a setting have made an intentional choice, but those who haven't viewed the settings page might not be aware of which default applies.
A vendor breach would expose the records outside the customer's network, whereas a legal demand could expose them without the customer's control. The retention rules and access controls were designed for the organization's archive, but they were not built to handle a second copy located elsewhere. A vendor's use of customer security records for a service does not inherently authorize their use for model improvement, and evidence retention and model development require separate permissions.
