Data-subject and deletion requests

When one of your people — or a customer, or a regulator acting for them — asks “What do you hold about me?” or “Delete what you hold about me,” you need to be able to answer with confidence, completely, and on a timeline. Under GDPR these are data-subject access requests (DSARs) and erasure requests (“the right to be forgotten”); equivalent rights exist under CCPA/CPRA and most modern privacy laws.

This page explains how SUPERWISE Chat is built to make those requests straightforward: where each kind of data lives, how you find it, how you delete it, what is intentionally kept (and why), and how the system proves to an auditor that you did what you said you did. It is written so that you — the tenant administrator — can run a request end to end and stand behind the result.

The shape of the problem

A person’s data in Chat is not one big blob. It lives in a handful of distinct places, each with its own lifecycle. Understanding that map is most of the job — once you can name where data lives, fulfilling a request is mechanical.

Everything below is scoped to your tenant. Every record carries the tenant it belongs to, and every read, write, and audit query is filtered to that tenant. One customer’s request can never reach across into another’s data. (For the full explanation of how that isolation works, see Tenant isolation.)

Where a person’s data lives

Data	What it is	Tied to the user?
Conversations & messages	The chats they sent and received	Yes — owned by the user
Memory	Facts the assistant remembered about or for them	Yes — owned, scoped
Knowledge & notes	Documents and notes they created or promoted	Yes — authored
Shares & share links	Conversations they shared with others	Yes — created by them
Consent records	Their choices about optional processing	Yes — per user
Usage & traces	Operational records of their activity	Linked, short-lived
Audit log	The immutable record that actions happened	References them; kept

The first five are the person’s content — the substance of a DSAR and the target of an erasure request. The last two are operational and compliance records, and they behave differently on purpose, which we cover under What is kept, and why.

Handling an access request (DSAR)

An access request asks you to produce a copy of the personal data you hold. In Chat, that means gathering the person’s content across the categories above. Work through them in order.

1. Identify the subject. You need the user’s identity in your tenant — their email or user ID as it appears in your identity provider. Because Chat authenticates against your SSO, the user ID in Chat is the same identity your IdP issued. (See Identity & SSO.)
2. Gather conversations and messages. Their conversations and the messages within them are the largest category. These are listed and read through the conversations surface; an administrator with the right role can retrieve them on the subject’s behalf.
3. Gather memory. The assistant’s stored memories about the user are user-owned and scoped. Retrieve the user’s memory entries so the export reflects what the assistant “remembers.”
4. Gather knowledge, notes, and shares. Include documents and notes the user authored or promoted, plus any conversations they shared or share links they created.
5. Gather consent records. Include the user’s current consent state and their consent history — the full record of what they granted or revoked and when.
6. Compile and deliver. Assemble the categories into a single export and deliver it to the requester through your normal secure channel, within the deadline your regulator sets (one month under GDPR; you may extend once for complex requests).

Note

A DSAR is read-only. Producing a copy never changes the data. Keep the request, your verification of the requester’s identity, and the date you fulfilled it in your own records — these are evidence that you responded on time.

Handling an erasure (deletion) request

Erasure removes the person’s content. Chat is designed so that deletion is decisive but recoverable in the moment — most content is soft-deleted first (marked deleted and removed from view) before it is permanently purged, which protects you from an accidental, irreversible mistake during a high-stakes operation.

Work through the same map, deleting instead of reading.

1. Confirm the request and the subject. Verify the requester’s identity and that the request is genuinely an erasure (not, say, a closed account that should be retained for a contractual reason).
2. Delete conversations and messages. Remove the user’s conversations and the individual messages within them. Deletion is scoped to your tenant and gated by role, so only an authorized administrator can perform it.
3. Delete memory. Remove the user’s memory entries. Memory is soft-deleted first, then purged — so the assistant stops “remembering” the person immediately, and the underlying rows are cleared.
4. Delete knowledge, notes, and shares. Remove documents and notes the user authored, and revoke any shares and share links they created so nothing they shared remains reachable. A revoked share link returns “gone” to anyone who tries to open it.
5. Handle consent. Erasure does not require deleting the consent history — that history is itself a compliance record proving the person’s choices were honored. Where your policy calls for it, record that the account was erased.
6. Confirm completion. Once the categories are cleared, the person’s content is gone from the product. The audit log entry that the deletion occurred remains (see below) — that is the proof you acted, not retained content.

Caution

Erasure is not instant-and-silent across every store. Content is removed from the product on deletion. Short-lived operational records (traces, request logs) that reference the user age out on their own schedule rather than being individually hand-deleted — they are not part of the person’s content and they expire automatically. State this honestly if a requester asks: their content is deleted; operational telemetry referencing them expires on a fixed, short window.

Retention windows

Different categories of data are kept for different lengths of time. Knowing these windows lets you tell a requester exactly when something referencing them will be gone even without manual action, and lets you set policy that matches your obligations.

Data	Kept while active	Purged after	How it is enforced
Conversations	Indefinitely	24 months inactive	Tenant-configurable; deletion is manual / soft-delete
Memory entries	Indefinitely	On explicit delete	Soft-delete first, then purge
Pending memory proposals	30 days	60 days	Auto-rejected and cleaned up
Execution traces	90 days	180 days	Automatic scheduled cleanup
Request logs	90 days	—	Automatic daily purge
Session tokens	24 hours	Auto-expire	Expire on their own

A few of these matter especially for deletion requests:

• Conversations are kept indefinitely while in use, and the 24-month window applies to inactivity. For an erasure request you delete them directly rather than waiting for the window. The active-retention window is tenant-configurable, so you can set a shorter default that matches your data-minimization policy.
• Traces and request logs are short-lived and self-purging. This is why an erasure request does not require hunting them down — they age out automatically within months and are operational, not content.
• Memory is soft-deleted first. That means a delete takes effect immediately for the user’s experience and gives you a brief safety margin before the rows are permanently cleared.

Note

Retention durations are policy values that can evolve. Treat the figures above as the current defaults and confirm any contractual commitment to a requester against your agreement rather than restating a number from memory.

Consent records

Consent is a first-class, auditable record in Chat — both because optional processing requires a lawful basis and because being able to prove a person’s consent choices is itself part of compliance.

Chat publishes a catalog of processing activities with the legal basis for each, so a person can see exactly what happens to their data and choose where they have a choice:

Activity	Why it happens	Can the user turn it off?
Answering your messages	Needed to deliver the service	No — it is what the product does
Remembering useful facts (memory)	Improves your experience	Yes
Indexing documents you add to knowledge	Lets the assistant use your documents	Yes
Usage analytics	Helps run and improve the service	Yes
AI safety review	Legal/safety obligation	No — required for safe operation

The two essential activities — actually answering messages and the AI safety review — cannot be switched off, because the product cannot function or operate safely without them; an attempt to revoke them is refused. The three optional activities can be granted or revoked by the user at any time, and tenant administrators can set the tenant-wide defaults for new users.

Every consent change — grant, revoke, or a change to the tenant default — is written to a consent history that is retained and queryable per user. When you fulfill a DSAR, that history is part of what you produce; when you fulfill an erasure, that history is the kind of compliance record you generally keep, not delete, because it proves the person’s choices were respected.

For the customer-facing view of these choices, see Privacy & your data choices.

What is kept, and why

The single most common worry with erasure is “if I delete everything, can I still prove what happened?” Chat answers that worry by drawing a clear line between content (deletable) and the audit record (retained, immutable).

• The audit log is immutable. Records of administrative actions — who assigned a role, who changed a setting, what the safety framework decided, and the fact that a deletion was performed — are written so that they cannot be edited or deleted by any tenant administrator. Settings changes in particular are strictly append-only: entries can be added but never altered or removed, by anyone. This is deliberate. An audit trail you could quietly change would be worthless to an auditor — and to you.
• Why keeping it is correct under privacy law. The right to erasure covers the person’s personal data, not the lawful, minimal record that an action took place. Retaining “deletion of user X’s data was performed on date Y by administrator Z” is a legitimate processing record, not retained content. It is what lets you prove the erasure happened.
• Consent history is kept for the same reason. A revocation is itself evidence that you honored the person’s wishes; deleting that evidence would defeat its purpose.

So a complete erasure leaves behind no conversations, no memory, no knowledge, no notes, no live shares — and an immutable, minimal trail showing the erasure was carried out. That is exactly the posture a regulator expects.

Note

How long the audit trail is kept. Audit and governance records follow a defined retention policy — kept active for one year and permanently removed after three. The integrity guarantee holds throughout: while a record exists, it cannot be edited or deleted by any administrator. Operational logs (traces, request logs) purge on their own short schedule, as in the retention table above.

Running it cleanly: a short checklist

• Verify identity first. Confirm the requester is who they claim to be before you read or delete anything. The wrong response to the wrong person is itself a breach.
• Scope to the subject. Everything you do is already tenant-scoped; make sure you are acting on the right user within it.
• Soft-delete is your friend. Because most content is soft-deleted before purge, a mistake during a delete is recoverable in the moment — but do not rely on it as a long-term undo.
• Keep your own paperwork. The request, your identity check, and the completion date are evidence you responded within the deadline. Pair them with the system’s immutable audit entry and you have a defensible record.
• Mind the deadline. GDPR gives you one month, extendable once for genuinely complex requests. Other regimes differ — work to the shortest deadline that applies.

Related pages

• Tenant isolation — why one tenant’s data can never reach another’s, the foundation that makes scoped deletion safe.
• Security statement — the overall security and compliance posture, including audit integrity and access controls.
• Privacy & data choices — how data flows and what the consent catalog discloses to users.
• Users & roles — the roles that authorize an administrator to read or delete another user’s data on their behalf.