Compliance, audit and data residency

Dataverse auditing

Dataverse can audit data changes — record create/update/delete and field-level before/after values — but it is enabled per environment and then per table and per column. Turning on environment auditing does nothing until tables/columns are also flagged. This is separate from the Purview activity log (who launched an app, who edited a flow); Dataverse auditing is about the data itself.

Retention

• Dataverse long-term retention can move old rows to a cheaper retained store under a policy, keeping them queryable without bloating the live database.
• Audit-log retention for the change history is time-bounded and can be configured/extended; leaving it short loses the compliance trail.
• Purview activity-log retention depends on licensing — the who-did-what history has its own clock.

Data residency

An environment has a region, chosen at creation, and its Dataverse data physically resides there. For a multinational, the region is the data-residency control — an app built in the wrong-region environment stores regulated data in the wrong geography, and an environment's region generally cannot be changed after creation. Tenants also have a home geo; environments can sometimes be in other supported geos.

Failure modes

• Auditing 'on' but no tables selected. The environment flag is set, everyone assumes changes are audited, and nothing is actually recorded.
• Retention too short for the obligation. A 90-day audit window against a multi-year regulatory requirement is a silent gap.
• Wrong-region environments. Regulated data created in an environment in the wrong geography — usually the ungoverned default env, provisioned wherever the tenant defaulted.
• Capacity blowback from auditing. Verbose auditing consumes Dataverse log capacity; left unbounded it can exhaust the entitlement.

What to watch (proofs)

• Environment region / residency: Get-AdminPowerAppEnvironment returns each environment's location — regulated data in the wrong geo is the finding.
• Dataverse auditing state: the environment audit setting and which tables/ columns are audit-enabled (admin center → environment → Auditing, or the Dataverse settings) — 'on but empty' is the trap.
• Retention configuration: audit and long-term retention policies vs the compliance obligation — short windows are the gap.
• Change history exists: the Dataverse audit summary / Search-UnifiedAuditLog for platform activity — proof the trail is actually being written.