Data deletion and subject rights requests

What it does

Customer Insights - Data holds copies of personal data that originated somewhere else, so it has no delete button for a customer. Erasure is done at the source and then propagated by refreshing the affected data sources and everything downstream of them. Portability requests for customer data go through Microsoft rather than through the product.

Key facts

There is no in-product delete for a customer profile. You delete the record in the originating system, then refresh that data source in Customer Insights - Data and let the downstream chain rerun.
The propagation is not automatic on its own — you refresh the affected sources under Data > Data sources, watch the status through to completion, then run the downstream refreshes so unification, segments, measures and exports all reflect the deletion.
Static segments are not refreshed. They keep the profiles they captured, so a static segment has to be recreated against the refreshed data or it remains a live copy of deleted personal data.
Inactive segments are not refreshed either. Either reactivate and rerun them, or delete them.
Deleting an application user is different and is done in-product: Settings > Permissions > Users, select the user, Remove, confirm.
Export requests for a customer's data are handled by Microsoft. The tenant admin emails [email protected] with the customer's email address, confirms via a follow-up email, and the export comes back to the tenant admin's address. The same route covers export of a user's data.
Retention behaviour: inactive data partitions and snapshots are removed after 30 or more days of inactivity. The most recent active data is retained and is not aged out.
Audit logs are kept separately from customer data and are not covered by the customer data deletion path.
Deleting the environment does not delete data held in your own Azure Data Lake Storage account. Resetting the environment does not remove source data or your own lake data either — that stays your problem.
Anything already exported to a third party is outside the product's reach entirely. Removing the connection stops future flow; it does not retract what has gone.

When to use / skip

Not optional if the client processes personal data of people in the UK or EU, which for this product is essentially all of them. What is optional is how formal you make it. A small client with two data sources can run this as a documented manual procedure. A client with a dedicated privacy function will want it written into their DSR runbook alongside the source systems, with named owners and an SLA — and that is the version worth building, because the thirty-day statutory clock does not care that your refresh runs weekly.

Where consultants underinvest is the segment sweep. The refresh chain handles the mainstream case competently; static and inactive segments are the part that silently retains data, and nobody discovers that until an audit does.

Configuration decisions

Which system is the authoritative place to delete for each entity — the answer differs per source and has to be written down before the first request arrives.
Whether the deletion refresh is triggered on demand or ride on the next scheduled system refresh, given the response deadline.
A policy on static segments: allowed with a mandatory rebuild step in the DSR procedure, or discouraged outright.
What happens to inactive segments — a periodic cull, or reactivate-and-rerun as part of each request.
Who holds tenant admin and can raise the export request with Microsoft, and what their cover is when they are away.
Whether audit and diagnostic logs forwarded to Azure Monitor fall inside the client's own retention policy, since that destination is theirs to manage.

Gotchas

Refreshing only the obvious data source is the common miss. If the individual appears in several sources, every one of them needs deleting at origin and refreshing.
Static segments are the trap. They look like segments, they are not recalculated, and they will still contain the deleted person after a clean refresh.
Exports that have already run cannot be recalled. If an export fired between the deletion request and the refresh, the third party needs telling separately.
The export-request route depends on a tenant admin's mailbox and a confirmation email. If that person has left or the mail is filtered, the request stalls with no visible error anywhere in the product.
Your own data lake is not cleaned up by resetting or deleting the environment. On a bring-your-own-storage deployment the client owns that lifecycle and usually has not planned for it.
Retention of inactive snapshots is measured in days of inactivity, not a fixed calendar window, so "when will it be gone" has no single answer you can quote to a privacy officer.

Consultant notes

Write the DSR procedure during delivery, not after. It takes an hour and it is the artefact the client's privacy team will actually ask for.
Rehearse one deletion end to end in the sandbox with a test identity, including the static segment rebuild, and hand the client the screenshots.
Be explicit that the product is a downstream copy — every deletion conversation goes better once the client accepts that source systems are where erasure happens.
Flag the bring-your-own-lake retention gap to whoever owns the Azure subscription, because the Customer Insights admin cannot fix it.
Before go-live, confirm the tenant admin address for export requests is a monitored mailbox and not one person's inbox.

Worth revisiting if in-product profile deletion ever ships, or if the snapshot retention window is given a firm number.