What it does

Handling a DSR in Dataverse means running six actions across every environment that might hold the individual's data: discover, access, rectify, restrict, delete and export. Microsoft is the processor; finding the data and acting on it is the controller's job, and there's no single button for it.

Key facts

• There are two distinct populations to handle. Users — your own staff, whose identity data syncs from Entra into the systemuser table — and data subjects in your business data, sitting in Account, Contact, Lead and every custom table you built.
• Standard user personal data is maintained in the Microsoft 365 admin centre and synced into systemuser in every environment. You can't edit it directly in Dataverse while the user is active.
• Deleting a user from Microsoft 365 does not remove their row from Dataverse. The user is set to Disabled and an admin has to remove the personal data or permanently delete the user, per environment.
• Permanently deleting a user replaces their name with No Name everywhere they appear as creator, last-modified-by, or in audit logs.
• Custom attributes added to systemuser are entirely your responsibility — nothing syncs or cleans them up.
• Audit history holds personal data for every audited table the individual touched. Removing it is a separate act using Delete Change History, which needs the Delete Audit Record Change History privilege.
• Microsoft is explicit that it doesn't offer correction of system-generated logs, because those are a factual historical record.
• Export tooling is thin. The documented routes are Export to Excel from the user list, table export to CSV, and — for audit history and search results — taking a screenshot.
• Environments can be configured so a table's rows can't be deleted. Where that applies you have to blank the personal data in the row instead of removing the row.
• Long-term retention makes retained data read-only and it can never return to the live state, which changes how you satisfy an erasure request against it.

When to use / skip

This isn't optional and it isn't a technical exercise. The whole thing hinges on the client having an inventory of which tables in which environments hold personal data — Microsoft says so directly, and without one you're running Dataverse search across production and hoping. Build that inventory during the data model design, not when the first request arrives with a statutory clock running. The consultant's realistic contribution is the inventory, a documented runbook, and the search configuration that makes discovery possible; the actual requests belong to the client's privacy function.

Configuration decisions

• What the personal data inventory looks like, where it lives, and who keeps it current as new tables are added.
• Which tables and columns are configured as searchable so that discovery actually finds things.
• Whether erasure means deleting the row or blanking the personal columns, decided per table — and how downstream reporting copes with either.
• Whether audit history is in scope for erasure, and who holds the privilege to delete change history.
• Whether personal data can be retained long-term at all, given retained rows are immutable.

Gotchas

• Every environment is a separate exercise. Dev, test, sandbox copies and any environment restored from a backup all hold their own copy of the individual's data, and the DSR covers all of them.
• Dataverse search only finds what's configured as searchable. An unindexed custom table holding personal data is invisible to discovery and nobody will notice until an audit.
• Audit history survives deletion of the row it describes. Deleting the contact doesn't remove the audit trail of what the contact's data used to be.
• Permanently deleting a user turning every historical reference into No Name is often unexpected by the business, and it's irreversible.
• Export by screenshot is genuinely what the documentation recommends for audit history. Plan for a real export path via the Web API if the client has any volume of requests.
• Retained data being immutable means erasure against it needs a different answer. Work that out with legal before you enable retention on tables holding personal data.

Consultant notes

• Deliver the personal data inventory as a project artefact with a named owner. It's the single thing that turns DSR handling from a panic into a process, and clients almost never have one.
• Be precise about the controller/processor split when the client asks what Microsoft does for them. Microsoft provides the tools; identifying and acting on the data is theirs.
• Warn that sandbox refreshes reintroduce deleted personal data. A DSR completed in production and then undone by next month's copy is a real incident, and the fix is a refresh runbook step.
• Point at the Trust Centre and Service Trust Portal for the contractual and regulatory framing rather than paraphrasing it. Your job is where the data is, not what the law says about it.

---

Worth revisiting if Dataverse gains proper DSR export tooling, or if erasure against long-term retained data becomes possible.