AI security monitoring: a privacy checklist for buyers

Evaluate AI security monitoring by asking what it collects, who can read it and how each copy is deleted. Begin with the minimum event data needed for a defined security purpose. Require separate justification and controls for any retained prompt, response, file or screenshot.

A security platform becomes another data-processing system when it observes employee activity. Its own telemetry can expose customer information, confidential work and personal details. Procurement therefore needs a review of the monitoring service alongside the AI services it protects.

Start with a field-level collection record

Ask the vendor to demonstrate a normal event and an alert using fictional test data. List every field stored locally, transmitted to the service, shown to administrators and exported to other systems.

For each field, record its purpose, sensitivity, readers, storage region and retention period. A policy identifier, outcome and timestamp may be enough for one investigation question. Another question may need account attribution. The required evidence should follow the question being answered.

The NIST Privacy Framework treats logging, generation, disclosure and disposal as data-processing activities. Its CT.DM-P8 outcome explicitly incorporates data minimisation into audit and log records. This is voluntary guidance, with useful questions for a procurement review.

Ask what the vendor means by metadata. A destination, document title, persistent user identifier or detailed event sequence may still reveal sensitive information. Obtain the actual schema and a representative export.

Separate routine monitoring from incident access

Write down which routine decisions the platform must support: identifying an unapproved service, counting blocked actions or investigating a failed policy decision. Then test whether those jobs can be completed with content-minimised evidence.

Where an investigation genuinely needs content, define a case-specific access path. Identify the trigger, authorised investigator, approver, scope and end time. Require a record of viewing and export activity. Keep a documented route for urgent incidents, with subsequent review.

Demonstrate the roles separately. A tenant administrator, security analyst, auditor and vendor support engineer can have different operational needs. Ask whether support impersonation, troubleshooting bundles or a product-feedback feature creates another way to retrieve content.

The OAIC's guidance on commercially available AI products recommends checking terms and settings, including developer and third-party access to input and generated data. Apply that due diligence to any AI component within the monitoring product too.

Give each copy a retention clock

A single answer such as “we retain logs for 30 days” leaves several questions open. Ask for separate periods and deletion behaviour for ordinary events, alerts, investigation records, exports, backups and support tickets.

Use a fictional event identifier to trace one record through the proposed deployment. Follow it into the vendor console, search index, SIEM export and any support workflow. Record which organisation controls deletion at each destination.

For covered Australian entities, APP 11 guidance explains reasonable steps to destroy or de-identify personal information that is no longer needed, subject to applicable exceptions. It addresses archived copies, backups and verification when a third party holds the data.

Ask how a legal hold changes the normal schedule, who authorises it and how it ends. An export to a customer-controlled system needs its own retention owner. Deleting the original console entry leaves those downstream responsibilities to be checked.

Make deletion part of the pilot

Agree a small deletion exercise before signing. Create a clearly fictional event, confirm where it appears, request its removal through the documented process and check the result after the stated interval.

Use these acceptance questions:

1. Can an authorised user still retrieve the event by identifier or search?
2. Do exports and derived records follow documented deletion rules?
3. What evidence supports the vendor's backup-expiry claim?
4. Does restoring a backup reintroduce a deleted record, and how is that handled?
5. What happens to retained material when the contract ends?

Some answers require contractual evidence or an independent assurance report. A buyer usually cannot inspect every storage layer directly. Record that limitation and the evidence supplied. Avoid treating a successful console deletion as proof about all copies.

The exercise should also show that routine security work remains usable. Ask an analyst to explain the policy outcome and affected route after the sensitive test content has expired.

Review workforce obligations with the right owners

Involve Privacy, Legal and People teams before collecting employee activity. Explain the purpose, collected fields, access and retention to the people affected. Keep security monitoring purposes explicit and review proposed secondary uses separately.

Australia's employee-records exemption applies only in specified circumstances. OAIC guidance explains that contractors handling another employer's records generally cannot rely on that exemption. State and territory surveillance rules also require jurisdiction-specific advice.

This checklist supplies procurement questions and a proposed pilot, without asserting that one configuration satisfies every legal obligation. No vendor was independently tested for this guide.

Use the broader AI DLP comparison guide to identify relevant control points, then make collection, access and deletion evidence part of the purchasing decision.

Review your AI data-handling requirements with Promptective.