Dataverse Security & Governance: the platform guardrails explained

The four-layer Dataverse security stack

Dataverse security is not one control but a stack of four layers, each evaluated before data is returned. At the bottom, Microsoft Entra ID (the renamed Azure Active Directory) authenticates the user and applies conditional-access policy. Above that, the environment acts as a hard security boundary: roles, data, and policies in one environment are invisible to users who only have access to another. Within the environment, role-based security decides which tables and records the user can reach. At the top, column-level security narrows access field by field for the most sensitive data.

Microsoft's [Security concepts in Microsoft Dataverse](https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds) whitepaper is blunt about how the layers combine: a user's effective access to any record is the accumulation of all their security roles, the business unit they belong to, the teams they are a member of, and the records that have been shared with them. There is no 'deny' override in the core model. The single rule that governs the whole stack is that all privilege grants are accumulative, with the greatest amount of access prevailing — so a broad Organization-level read granted anywhere cannot be narrowed back down by a tighter role elsewhere.

For a compliance-minded team, this changes the order of operations. You do not 'add security' at the end by tightening individual records; you design the role and business-unit structure up front so that least privilege is the default state, and you treat any Organization-level grant as an explicit, reviewed exception. The rest of this guide walks each layer — environments, identity, roles, business units, row-level teams, column-level security, DLP, and managed environments — in the order a governance lead would configure them. If you need the underlying platform context first, our [Dataverse foundations guide](/learn/dataverse-guide) covers the data model, tables, relationships, and capacity planning this article builds on.

• →Four stacked layers: Entra ID authentication → environment boundary → role/record security → column-level security
• →The governing rule: all privilege grants are accumulative, greatest access always prevails — there is no deny override in the core model
• →A security role is only active in environments that actually have a Dataverse database provisioned
• →Least privilege must be designed up front; you cannot narrow an over-granted Organization-level privilege later by hiding records
• →Every layer is tenant-configurable in the Power Platform admin center, not in the individual apps

Environments are the primary governance boundary

An environment is a container that holds apps, flows, connections, and — if provisioned — a single Dataverse database. Microsoft treats the environment as the first real security boundary: security roles, data, and DLP policies do not cross environment lines. A user who is a System Administrator in a sandbox environment has no inherent access to the production environment next to it, and a record created in one environment is invisible to apps running in another. This isolation is what makes a clean separation of production, development, and test possible without separate tenants.

Power Platform offers several environment types, each with a different governance posture. Production environments are backed by paid capacity and are where live business data belongs. Sandbox environments are for development and testing, with reduced storage costs and the ability to be reset. Developer environments are tied to an individual's Power Apps Developer Plan and are explicitly not licensed for managed-environment features when users run assets. The Default environment is created automatically for every tenant and shared by all licensed users — which is exactly why most governance failures start there, because every maker can build against it by default. Dataverse for Teams (the Teams environment type) provides a lightweight Dataverse database inside Microsoft Teams for a lower-privilege, lower-cost footprint.

The compliance implication is that environment strategy is security strategy. Running every app and every maker in the single Default environment means one person's custom connector or over-shared canvas app is everyone's problem. A defensible posture is to ring-fence the Default environment (or route it via default-environment routing), stand up dedicated Production environments for each major solution, and use Sandbox environments for build and test with pipelines between them. Environment choice also fixes data residency: each environment is created in a specific Azure region, which matters directly for GDPR, PIPEDA, and sectoral residency rules. The platform-level treatment of why access control matters across the whole ERP — not just Dataverse — is covered in our [ERP security for SMEs](/learn/erp-security) guide.

Default environment routing is a Managed Environments capability that steers new makers out of the shared Default environment and into a personal developer environment when they first open Power Apps or Power Automate. Microsoft documents it as part of the Managed Environments suite: instead of hoping makers stay out of Default, you redirect them so production-bound assets never start there. Pair routing with a tenant-wide DLP policy and a security group on each Production environment so only licensed, in-scope users can enter. An environment security group is optional but powerful — users outside the group do not appear as active users for that environment (with the usual exception that Power Platform Administrators still surface for admin work). Licensed users still need at least one Dataverse security role in that environment; without a role they get a data access denied error even if the security group lets them in.

Identity, Entra ID, and the admin-vs-data distinction

Authentication in Dataverse is handled entirely by Microsoft Entra ID. There are no Dataverse-local passwords to manage, rotate, or leak: every user is an Entra principal, and every sign-in inherits the conditional-access, multifactor-authentication, and risk policies already configured at the tenant level. This is a significant governance advantage over platforms that ship a parallel identity store, because the same Entra controls that protect email and Microsoft 365 protect the CRM and ERP data sitting in Dataverse. Service-to-service access uses Entra-backed application registrations and managed identities rather than shared API keys.

A subtle but critical distinction catches teams off guard: tenant-level admin roles — Power Platform Administrator, Dynamics 365 Administrator, Global Administrator — grant administrative access across environments, but they do not automatically grant Dataverse data access. Microsoft's [role-based security](https://learn.microsoft.com/en-us/power-platform/admin/database-security) documentation states plainly that to work with data in a Dataverse environment, a tenant admin must also be assigned the System Administrator Dataverse security role in that specific environment. In other words, the person who can create environments is not, by default, the person who can read customer records — which is the correct separation for a compliance audit, even though it frustrates a first-time admin.

Identity also drives the most efficient way to manage Dataverse roles at scale: group teams. You create a Microsoft Entra security group for each business function, create a Dataverse group team mapped to that Entra group, and assign the appropriate security role to the group team. Joiner-mover-leaver then happens in Entra, not in Dataverse — when HR removes someone from the group, their Dataverse access is revoked automatically. Conditional access can further scope which apps a user opens and from which network, and on managed environments you can apply conditional-access policy to individual apps rather than the whole environment.

Security roles, eight privileges, four access levels

Role-based security is the core of the Dataverse model. A security role is a named bundle of privileges, assigned to a user, a team, or (via group teams) an Entra security group. Microsoft's [security roles and privileges](https://learn.microsoft.com/en-us/power-platform/admin/security-roles-privileges) reference is explicit that a user can hold multiple roles and that the privileges are cumulative — every privilege available in any assigned role is available to the user, with no subtraction. This is why the predefined roles shipped with the platform are deliberately built on the principle of minimum required access: the least access to the minimum business data a user needs to do their job.

Each security role grants table privileges across eight operations: Create, Read, Write, Delete, Append, Append To, Assign, and Share. Append means attaching another record (an activity or note) to the current record; Append To means being the target that other records attach to. Assign transfers ownership; Share grants access to a specific record without transferring ownership. In addition to these eight table privileges, a role carries miscellaneous task-based privileges (publish articles, activate business rules) and privacy-related privileges (export to Excel, print) that gate data leaving Dataverse.

For each table privilege, the role sets an access level that controls how far the right extends. There are four access levels — User (only the user's own records), Business Unit (records owned within the user's BU), Parent:Child Business Units (the user's BU plus its child BUs), and Organization (every record in the environment). The access levels that actually appear depend on the table's ownership type, but for user/team-owned tables all four tiers are in play. The combination matrix is large — eight privileges times four access levels per table — which is why copying a known-good predefined role and trimming it is almost always safer than building one from a blank grid.

• →A security role bundles eight table privileges plus miscellaneous and privacy-related privileges
• →Four access levels scope each privilege: User, Business Unit, Parent:Child BUs, Organization
• →Privileges are cumulative across all assigned roles — there is no deny override
• →Predefined roles are built on minimum-required-access; copy and trim rather than build from blank
• →Every role also carries privacy-related privileges (export, print) that gate data leaving the environment

Business units and the two ownership types

Business units work alongside security roles to decide what a user can actually see. Microsoft defines the business unit as a security-modeling building block that defines a security boundary. Every Dataverse database has exactly one root business unit, which is fixed at the top and cannot be removed; beneath it you create child business units to segment users and data. When a user is associated with an environment, they belong to one business unit, and that association determines which business unit owns the records they create — which in turn determines the scope a Business Unit access level grants them.

There are two ways to structure the relationship between users and business units. The classic tree hierarchy compartmentalizes users and data so that a user in Division A can see Division A's records but not Division B's. The modernized matrix structure (Record ownership across business units) lets a single user own and access records across multiple business units by holding a role from each, without the rigid either/or of the tree model. This is enabled through a feature switch and the Owning Business Unit column, which defaults to the creator's business unit but can be set explicitly once the feature is on. For matrix access, Microsoft recommends mapping each business unit to a Microsoft Entra security group so that joiners and leavers are handled in identity rather than in Dataverse.

Underneath both structures sits a decision fixed at table creation time that cannot be changed later: ownership type. A table is either Organization-owned or User/Team-owned. For Organization-owned tables, the only access-level choice is binary — the user can do the operation or cannot — so the four-tier access levels collapse. For User/Team-owned tables, the full four access levels apply. This is why choosing ownership type is a one-way architectural decision: it permanently shapes what the security model can express, and getting it wrong at table design time is expensive to work around. The platform-neutral principles behind this — least privilege, separation of duties, reviewed role assignments — are the same ones our [Dynamics 365 services](/solutions/microsoft-dynamics-365) engagements harden against during implementation.

Hierarchy security: manager and position models

Role and business-unit security alone force an uncomfortable choice in many sales and service orgs: either grant managers Organization-level read (too broad) or build a forest of business units and custom roles (expensive to maintain). Hierarchy security is Microsoft's answer — an extension on top of business units, roles, teams, and sharing that grants managers or higher positions access to subordinates' data without rewriting every role.

There are two models, and you pick one. Manager hierarchy follows the Manager field on the system user table (the reporting chain). A manager gets Read, Write, Append, and Append To on direct reports' data, and read-only access further down the chain, limited by a Depth setting. By default the manager must sit in the same business unit as the report or in the parent business unit; if you enable record ownership across business units, you can relax that with the ManagersMustBeInSameOrParentBusinessUnitAsReports environment database setting. Position hierarchy is job-structure based: you define positions, nest them, tag users, and higher positions see lower positions on the direct ancestor path — useful when access should follow function ("service lead sees cases") rather than people-manager lines, and it can cross business units more freely.

Critical constraints from Microsoft's hierarchy security documentation keep this from becoming a silent over-grant. Hierarchy security is off by default. Managers and higher positions still need at least User-level Read on a table to see subordinates' records of that table — hierarchy does not invent privileges the role lacks. Depth should keep the effective population under a manager or position at roughly 50 users or fewer for performance; deeper trees are fine, but Depth is how you bound read-only span. You can exclude individual tables from hierarchy table management so HR or payroll tables never ride the management chain. And if a direct report has broader security than their manager (for example Business Unit read while the manager only has User read), the manager does not automatically inherit everything the report can see — hierarchy grants access to the report's owned and shared records, not a clone of the report's entire role.

• →Hierarchy security extends roles/BUs/teams/sharing — it does not replace them
• →Off by default; requires System Administrator (and Change Hierarchy Security Settings) to enable
• →Managers still need at least User-level Read on each table they should see
• →Use Depth and table exclusions to stop hierarchy from becoming Organization-level by another name
• →Prefer hierarchy over multiplying business units when the real need is manager visibility

How record access is determined: teams and sharing

Record-level access is where the accumulative rule bites hardest in practice. For any given user, access to a specific record is the combination of every security role they hold, the business unit they sit in, every team they belong to (and the records those teams own), and every record that has been explicitly shared with them. Microsoft is explicit that all of this is accumulative within the scope of a single Dataverse database — there is no negative grant to subtract an over-broad entitlement. The practical consequence is that a quarterly access review must look at the union of all these vectors, not just the role column on the user record.

Teams are the primary mechanism for managing access at the row level without micromanaging individual users. Dataverse ships two team types. Owning teams can own records, and any member of the team gets direct access to the records the team owns; because a user can belong to multiple owning teams, this is an efficient way to grant broad, role-like access by group membership. Every business unit has a default team whose membership is managed automatically by the system — it always contains every user in that business unit, and you cannot add or remove members manually.

The second team type, the access team, is built for exception-based access rather than ownership. An access team does not own records and cannot be assigned security roles; instead, records are shared with the team via an access team template that defines which permissions members receive. This is more performant than ad-hoc sharing because the access is computed through template membership rather than tracked as individual share records. Individual record sharing remains available as a last resort, but Microsoft flags it as less performant and harder to troubleshoot precisely because it sits outside the consistent role-and-business-unit model — it should be an exception, never the primary access mechanism.

Choose the team type deliberately. Owning teams are the right default for department-level record ownership and least-privilege group access. Access teams (with templates) are the right tool for deal rooms, case collaboration, or temporary project access that should not transfer ownership. Group teams are the right tool for joiner-mover-leaver automation via Entra. Ad-hoc record sharing is the escape hatch for one-off exceptions — track it in access reviews because shares accumulate silently and are hard to reverse at scale.

Column-level security for the most sensitive fields

When row-level control is not granular enough — a salary column on a record a manager is otherwise entitled to read, a national-insurance number, a contract value — Dataverse provides column-level security. Microsoft's [column-level security](https://learn.microsoft.com/en-us/power-platform/admin/field-level-security) documentation describes it as organization-wide configuration that applies to all data-access requests, not a per-form or per-view setting. The mechanism is a three-step process: enable column security on the specific columns of a table, optionally attach a masking rule, and then associate one or more column security profiles that grant Read, Read unmasked, Update, and Create permissions to specific users or teams.

A column security profile controls four discrete permissions. Read determines whether the value is visible at all; Read unmasked controls whether a developer's code can retrieve the true value when a masking rule is applied (the default is Not Allowed, so masked data stays masked through the API); Update controls whether the value can be changed; Create controls whether the value can be set on a new record. Crucially, a user must already have record-level access for the column profile to grant anything — column security narrows access, it does not create it. And unless at least one column security profile is assigned to a secured column, only users with the System Administrator role can read it; everyone else sees asterisks.

There are guardrails worth knowing before you enable it broadly. Column-level security does not apply to users who hold the System Administrator role — data is never hidden from a system administrator, so you must test the configuration with a non-admin account. Not every column can be secured: lookup columns, formula columns, virtual-table columns, primary name columns, and system columns like createdon and modifiedon cannot be protected this way. File and image data types can be secured but not masked. Finally, a calculated column that references a secured column can leak the underlying value, so review calculated and rollup columns that derive from secured fields before relying on masking for compliance.

• →Column-level security is organization-wide configuration, applied to all data-access requests
• →Column security profiles grant Read, Read unmasked, Update, and Create per column
• →System Administrator bypasses column security entirely — always test with a non-admin account
• →Lookup, formula, virtual-table, primary-name, and system columns cannot be secured
• →Calculated columns referencing a secured column can leak the underlying value

Application users and service principals for integrations

Human security roles are only half of a production Dataverse estate. Integrations, Power Automate service-principal-owned flows, custom APIs, and ISV connectors should not run as a named employee — that pattern creates orphaned access when the person leaves, breaks MFA policies, and attributes system changes to the wrong identity. The correct pattern is an Entra application registration (service principal) mapped to a Dataverse application user with a least-privilege security role.

Microsoft documents application users as non-interactive identities created in the Power Platform admin center (Users + permissions → Application users) or via API. Application users are not counted against the classic seven non-interactive user account limit, and there is no documented cap on how many application users you can create per environment. You assign ordinary Dataverse security roles to the application user — Create, Read, Write, Delete, Append, Append To, Assign, Share with the correct access levels for only the tables the integration touches. System Administrator on an application user is acceptable only in a locked-down development sandbox; in Production it is an over-grant that every security review will flag.

Two failure modes dominate real projects. First, creating the Entra app registration without the Dataverse application user (or the reverse) produces 401s that look like "auth is broken" when the missing half is simply the identity link. Second, granting dynamics.user_impersonation or bloated application permissions in Entra and then stacking System Administrator in Dataverse doubles the blast radius. Prefer certificate or federated credentials over long-lived client secrets, rotate secrets on a calendar, store them in Azure Key Vault, and review application-user roles in the same quarterly cadence as human privileged roles. For Power Automate, service-principal-owned flows keep ownership stable when makers leave and are subject to non-licensed user API request limits — plan capacity accordingly rather than silently binding flows to a departing admin.

• →Entra app registration + Dataverse application user + least-privilege role — all three, not one
• →Application users are non-interactive and not limited like classic non-interactive user slots
• →Never use System Administrator for production automation identities
• →Prefer certificates/federated credentials and Key Vault over long-lived secrets in flow connections
• →Include application users in privileged access reviews alongside human System Administrators

DLP policies and the three data groups

Data loss prevention in Power Platform is enforced through data policies (DLP policies) that classify connectors into groups and forbid data from flowing between groups. Microsoft's [manage data policies](https://learn.microsoft.com/en-us/power-platform/admin/prevent-data-loss) documentation frames the goal plainly: an organization's data must be available for decision-making but protected from being shared with unauthorized audiences. A DLP policy lets an administrator declare, for example, that SharePoint and Salesforce (carrying business data) can share data with each other, but cannot be combined in the same app or flow with Facebook or Twitter, and that certain connectors are blocked outright.

Every policy sorts connectors into three data groups. The Business data group holds connectors for sensitive data. The Non-Business (Default) group holds connectors for non-sensitive data, and this is where every unassigned connector lands automatically. The Blocked group lists connectors that cannot be used anywhere the policy applies. The rule is strict and bidirectional: connectors in the Business group cannot share data with connectors in any other group, and the same isolation applies to Non-Business. The connector matrix is what an administrator works through when building the policy — a five-by-five grid of allowed-or-denied combinations that makes the data-flow rules concrete and auditable.

Scope is where compliance teams must pay attention. DLP policies exist at two levels: tenant-wide and environment-level. A tenant-wide policy can include or exclude specific environments and is the right tool for organization-wide guardrails; an environment-level policy applies to a single environment. The hierarchy is one-directional and important: an environment-level data policy cannot override a tenant-wide data policy. So the tenant-wide policy sets the floor, and environment policies can only add restrictions on top. Custom connectors are classified separately, and a default-group setting controls where any connector Microsoft adds in the future automatically lands — Microsoft recommends keeping that default as Non-Business so new connectors cannot quietly enter the Business group. Creating or editing a policy requires Environment Admin or Power Platform Administrator permissions.

Managed Environments: the governance feature suite

Managed Environments is the premium capability suite that lets administrators govern Power Platform at scale with more control, less effort, and more insight. Microsoft's [managed environments overview](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-overview) describes it as a layer you enable on any environment type; once an environment is managed, it unlocks a broad set of features that an unmanaged environment does not have. For a compliance-minded team, Managed Environments is where most of the advanced guardrails live, because the standard environment gives you only the baseline role-and-policy controls described above.

The feature list reads like a governance checklist. Limit sharing caps how widely a single app can be shared, countering the most common low-code sprawl problem. Solution checker enforcement runs validation against solutions before they are imported, blocking known-bad patterns. IP Firewall and IP cookie binding restrict access by network origin and block cookie-replay attacks. Weekly usage insights surface what makers are actually building. Pipelines provide governed application-lifecycle-management paths between environments. Conditional access can be applied to individual apps rather than only the whole environment, and you can control exactly which apps are allowed to run in the environment at all. Masking rules — the same ones column-level security uses — are configured here. Data policies (DLP) and extended backup retention are also governed through the suite.

Two Managed Environments features matter most for regulated industries. Customer Managed Key (CMK) lets you self-manage the encryption key for the environment's data-at-rest from your own Azure Key Vault, which means you can revoke Microsoft's access to the data on demand — a requirement for some data-residency and sovereignty commitments. Customer Lockbox adds an approval workflow so that Microsoft support cannot access your data without an explicit, customer-approved access request. Both are entitlements of the standalone Power Apps, Power Automate, Copilot Studio, Power Pages, and Dynamics 365 licenses; the Developer Plan is explicitly excluded when users run assets, which is another reason not to host production data in a Developer environment.

The licensing trap is the most common production surprise. Managed Environments are an entitlement of standalone Power Apps Premium, Power Automate Premium, Microsoft Copilot Studio, Power Pages, and Dynamics 365 Premium/Enterprise/Team Members (and related) licenses, plus qualifying pay-as-you-go meters — not of the Power Apps Developer Plan when users run assets. When you flip an environment to managed, every user who actively runs apps or cloud flows in that environment needs a qualifying premium (or Dynamics 365) license — even if the app only uses standard connectors. Microsoft's Managed Environments licensing documentation states that either Power Apps Premium or Power Automate Premium satisfies the requirement for a user who both runs apps and runs flows; you do not need both. Licensing compliance notifications ramped in 2026: administrators receive advance notice through the Microsoft 365 Message center and Power Platform admin center (from March 2026), and end users who open Power Apps without an appropriate license see escalating in-app notifications starting June 2026. Before enabling Managed Environments on a widely used Production or Default-adjacent environment, run the "Users requiring licenses in managed environments" report under Licensing → Power Apps in the admin center and assign licenses (or use an auto-claim policy) so governance features do not become a licensing incident.

Encryption, customer-managed keys, and compliance posture

All customer data stored in Power Platform is encrypted at rest with strong Microsoft-managed encryption keys by default. Microsoft stores and manages the database encryption key, so a team that does nothing still gets at-rest protection — a stolen database copy cannot be restored elsewhere without the key. For organizations that need more than the default, the [customer-managed encryption key](https://learn.microsoft.com/en-us/power-platform/admin/customer-managed-key) capability lets you bring your own RSA-HSM key from Azure Key Vault and apply it to the Dataverse environment. With CMK you can rotate or swap the key on demand, and — critically for sovereignty commitments — you can revoke key access to prevent Microsoft's services from reading the data at any time.

CMK coverage is broad but not universal, and the exclusions matter for an honest compliance posture. The capability encrypts Dataverse data, Dynamics 365 first-party apps (Sales, Customer Service, Field Service, Finance, Supply Chain Management, Project Operations), Power Automate, Chat for Dynamics 365, Dynamics 365 Customer Insights, and Copilot Studio. It does not encrypt connector connection settings, Power Platform environment settings, Power Apps display names and descriptions, solution-checker download results, or maker welcome content — those remain on a Microsoft-managed key. Reverting to a Microsoft-managed key is supported, and changing keys is done by creating a new enterprise policy and reapplying. Environments with finance-and-operations apps must have Power Platform integration enabled to be CMK-eligible.

Underneath the configuration choices sits a compliance posture Microsoft maintains continuously. Dataverse and the Power Platform inherit the Azure compliance framework, which includes ISO 27001, SOC 1 and SOC 2, HIPAA, and FedRAMP attestations across the relevant cloud offerings (commercial and sovereign clouds such as GCC High). These attestations mean the platform itself is auditable, but they do not make your configuration compliant — a poorly scoped security role or a permissive DLP policy is your exposure, not Microsoft's. The discipline is to map each regulatory requirement (GDPR data-subject access, HIPAA minimum-necessary, SOX segregation of duties) to a specific Dataverse control and then verify it with a non-admin test account.

Audit logging, retention, and access reviews

Auditing is the control that turns security configuration into evidence. Dataverse has a built-in audit log that captures create, update, delete, and access events at the table and column level when auditing is enabled — and auditing is off by default, which is a common and easily missed gap. The audit log feeds the Dataverse audit history shown in model-driven apps and is also available to administrators for investigation. Microsoft also integrates with Microsoft Purview for unified data-audit visibility and with Azure Application Insights (exported from Managed Environments) for telemetry on app and plug-in behavior, giving compliance teams a single place to correlate Dataverse events with the rest of the Microsoft 365 audit trail.

Retention is the operational question that follows. Audit data accumulates in the Log storage pool tracked separately from database and file storage, so unreviewed audit logs are not just a governance gap but a capacity cost. The platform provides retention and deletion controls so that audit data is kept for the period a regulation requires (for example, the standard six-year window some frameworks expect) and pruned thereafter. A mature practice is to export long-term audit data to a dedicated store rather than let it age inside the environment's Log pool, both to manage capacity and to produce an immutable record an auditor can be handed.

Configuration without review is theatre. The accumulative nature of Dataverse privileges means that an access review must examine the effective access of each user — the union of their roles, business-unit membership, team memberships, and shared records — not just the role name on their record. A reasonable cadence for an SME is quarterly for privileged roles (System Administrator, System Customizer, any role granting Organization-level write or delete) and semi-annual for the rest, plus an event-driven review whenever someone changes role or leaves. Microsoft's predefined roles are built on minimum required access; the drift that defeats them is almost always the manual exception — the manager granted System Administrator 'just to unblock' a task and never demoted.

When a user reports "I cannot open the environment" or "I get privilege errors on one table," start with Run diagnostics in the Power Platform admin center rather than guessing at roles. Path: environment → Settings → Users + permissions → Users → select the user → Run diagnostics. The tool surfaces license state, security-role assignments, environment security-group membership, and related blockers, and it forces a sync of Entra user information into the environment's Dataverse database — often clearing stale membership after a group change. Pair diagnostics with the accumulative-access review: a clean diagnostics result only proves the user can enter; it does not prove least privilege. For privileged roles, still examine Organization-level Write/Delete, team memberships, and lingering shares.

• →Dataverse auditing is off by default — enabling it is a baseline compliance requirement, not an enhancement
• →Audit data lives in the Log storage pool, tracked separately from database and file pools
• →Integrations with Microsoft Purview and Azure Application Insights unify Dataverse events with M365 telemetry
• →Export long-term audit data to an immutable store rather than aging it inside the environment
• →Access reviews must examine effective access (roles + BU + teams + shares), not just the role name on the user
• →Use Run diagnostics in the Power Platform admin center before rebuilding roles from scratch — it syncs Entra and lists license/role/group blockers

A Dataverse security hardening checklist

The layers compound: get any one wrong and the ones above and below it lose value. The checklist below orders the work the way a governance lead should approach it — environment and identity first, because they are the boundaries; then roles and business units, because they are the model; then field, DLP, and managed-environment controls, because they are the refinements; then auditing, because without evidence none of the rest is provable. None of these steps require third-party tooling; every one is native to the Power Platform admin center and the makers' tools, which is the strongest argument for configuring them deliberately rather than treating them as optional.

Two principles run through the whole list. First, because privileges are accumulative and greatest-access prevails, design every role from minimum-required-access upward and treat any Organization-level grant as a documented exception. Second, because System Administrator bypasses column-level security and tenant-admin roles do not automatically grant Dataverse data access, always validate your configuration with a non-admin test account that mirrors a real business user. A configuration that looks correct in the admin center and fails in the hands of an actual user is the most common — and most preventable — compliance finding.

SME and mid-market teams do not need the same depth on day one. A 40-person services firm can start with two Production environments (or one Production plus Sandbox), Entra group teams for three job functions, a single tenant DLP floor, auditing on, and Managed Environments only where premium licensing is already in place. A multi-entity mid-market group with field service and finance data usually needs modernized business units or hierarchy security, column security on PII, CMK/Lockbox if contracts demand it, pipelines between Sandbox and Production, and quarterly privileged-role reviews with diagnostics evidence. The decision is not "more features = more secure"; it is "which controls match the data classification and the license estate you already pay for."

Frequently asked questions