How should organisations handle deletion requests across cloud, SaaS, and AI systems?

Why This Matters for Security Teams

Deletion requests are not only a privacy obligation. They are also a control problem, a data discovery problem, and, increasingly, an AI governance problem. If a request is handled only in the application where it was received, copies often remain in backups, SaaS exports, analytics stores, support tooling, and model training datasets. That creates exposure under privacy law, retention policy, and incident response review.

Security teams need to treat deletion as a verified workflow with ownership, evidence, and exception handling. The practical question is not whether a record was “deleted” in one interface, but whether the organisation can show where the data lived, what was removed, what had to be retained, and why. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties privacy handling to auditable control execution rather than ad hoc cleanup.

In practice, many security teams discover deletion gaps only after a subject access or erasure request has already exposed inconsistent retention across cloud services, SaaS tenants, and downstream AI pipelines.

How It Works in Practice

Operationally, deletion should start with data mapping. Organisations need to know which systems hold the data, which ones merely reference it, and which ones generate derived artifacts from it. That includes primary databases, object storage, document repositories, SaaS collaboration platforms, support ticketing systems, logs, caches, search indexes, feature stores, vector databases, and model training or fine-tuning datasets. Where systems support machine-readable erasure requests, automation should trigger the workflow across connected services and record each completion status.

The implementation pattern usually has four stages:

• Identity and request validation, so the organisation removes the right data for the right person or account.
• Data discovery and scoping, including structured records, unstructured content, and AI-derived copies.
• Execution and propagation, with API-based deletion, tombstoning, or redaction where full removal is not immediately possible.
• Verification and evidence, so legal, privacy, and security teams can prove what was removed and what remains under lawful retention.

For cloud and SaaS environments, retention settings, backup schedules, and tenant-level export options matter as much as the delete button. For AI systems, current guidance suggests organisations distinguish between raw training inputs, cached prompts, retrieval stores, logs, and model weights. Not every AI artifact can be selectively erased in a precise way, so best practice is evolving around source-data removal, retraining triggers, and documented residual risk. The NIST AI Risk Management Framework and NIST AI RMF Playbook are helpful for structuring accountability around those decisions.

Deletion workflows also need exception logic. Some records must be retained for fraud prevention, regulatory evidence, billing, or security logging, but those exceptions should be narrow, approved, and time-bound. The key is to separate legal retention from operational convenience. These controls tend to break down when data lives in unmanaged SaaS exports and shadow AI tooling because the organisation loses visibility into where copies were created.

Common Variations and Edge Cases

Tighter deletion controls often increase operational overhead, requiring organisations to balance user privacy rights against backup integrity, auditability, and recovery objectives. That tradeoff is especially visible in environments with long retention windows, immutable storage, or heavy use of third-party SaaS integrations.

There is no universal standard for exact erasure behavior across all cloud and AI platforms. Some services support hard deletion, others only logical deletion, and some preserve data in backups until the next expiry cycle. For AI systems, deletion requests may also affect prompts, RAG indexes, embeddings, or fine-tuning corpora in ways that are not fully reversible without model updates. Organisations should document where true deletion is possible, where delayed expiry is the only option, and where residual risk must be accepted by policy.

Edge cases also include shared records, multi-tenant SaaS, legal holds, and federated identity data. If a deletion request targets an account linked to shared collaboration spaces or delegated admin functions, the organisation may need to remove personal identifiers while preserving operational artifacts. The most defensible approach is to keep a deletion ledger that records request date, systems contacted, method used, exceptions applied, and confirmation of completion. For broader digital identity governance, ISO 29100 Privacy Framework and privacy authority guidance on personal data security remain useful reference points.

Related resources from NHI Mgmt Group

• How should security teams inventory identities across cloud, SaaS, and AI systems?
• How should organisations handle privileged access when workloads and AI systems are part of the model?
• How should security teams govern federated access across cloud and SaaS systems?
• How should security teams inventory AI agents across SaaS, cloud, and low-code platforms?