Governance and Compliance in Microsoft Fabric: A Practitioner's Reference

Enterprise data platforms live or die on trust: trust that the right people see the right data, that sensitive content stays protected when it moves between systems, and that teams can locate and evaluate assets without tribal knowledge. Microsoft Fabric addresses this through a governance model that is built in rather than bolted on, centralizing controls in a single surface and propagating them automatically across every workload.

This article is a practitioner's reference to that governance model. It covers every verified aspect of the system — the structural hierarchy, the protection controls, the discovery surfaces, and the compliance posture — so you can design, implement, and audit governance for a production Fabric platform with confidence.

The Four Functional Areas of Fabric Governance#

Fabric organizes its entire governance surface into four distinct functional areas ^[S1]:

1. Managing the data estate — the admin portal, domains, workspaces, capacities, and metadata scanning APIs that give administrators structural control and visibility.
2. Securing and protecting data — sensitivity labels from Microsoft Purview Information Protection, Data Loss Prevention (DLP) policies, and unified audit logging.
3. Encouraging discovery and trust — the OneLake catalog, endorsement levels, tags, and item lineage that help data consumers find and evaluate assets.
4. Monitoring activity — the monitoring hub, capacity metrics app, and admin monitoring workspace that surface operational health and usage patterns.

These four areas are not independent modules; they share a common identity and permissions fabric. Permissions, sensitivity labels, and auditing are applied automatically and inherited across Fabric items, and the controls remain enforced even when data is shared across tenant boundaries ^[S2].

The Three-Tier Settings Hierarchy#

Every configurable governance setting in Fabric resolves through a three-tier hierarchy ^[S1]:

• Tenant level — Fabric admins set platform-wide defaults in the admin portal. These apply to all domains and workspaces unless a lower tier overrides them.
• Domain level — for settings that have been explicitly delegated by a tenant admin, domain admins can apply domain-specific values. This is the mechanism by which different business units govern their own data estates without requiring full tenant admin rights.
• Workspace level — workspace owners apply the most granular controls, tuning behavior for individual projects or datasets within the boundaries permitted by the domain above them.

Inference: The cascade means that organizations should treat tenant-level settings as the risk ceiling, not the operational default. Locking sensitive settings at the tenant level prevents domain or workspace admins from inadvertently opening gaps, while delegating safe settings to the domain tier keeps governance distributed and scalable.

Domains: Organizing by Business Area#

Domains let organizations logically group Fabric content by business area or department ^[S1]. A domain is not just a label — it is a governance scope. Each department can apply its own governance settings within a domain, provided those settings have been delegated from the tenant level. Domains can contain subdomains, giving large organizations a two-level organizational hierarchy below the tenant. Workspace content filtered by domain is surfaced directly in the OneLake catalog, so data consumers can browse assets within a specific business area without needing to know which workspace holds the underlying data ^[S1].

Domains also map naturally onto a data-mesh operating model, where domain teams own and govern their data products. Inference: Assigning domain admin rights to data product owners — while retaining sensitive security controls at the tenant level — is a practical way to balance autonomy with enterprise control.

Capacities as Isolation Boundaries#

Capacities serve dual purposes in the governance model: they are compute isolation boundaries and chargeback units ^[S1]. The recommended practice is to split capacities by environment stage — development, test, acceptance, and production — to achieve workload isolation and enable accurate cost attribution per environment ^[S1]. A misbehaving workload in development cannot consume capacity reserved for production, and finance teams can attribute spend to each environment's dedicated capacity without complex allocation models.

Sensitivity Labels and Data Protection#

Sensitivity labels from Microsoft Purview Information Protection can be applied to Fabric items through several mechanisms ^[S1]:

• Manually by the item owner or authorized users
• Default labeling, which applies a configured label automatically when an item is created
• Label inheritance, which propagates a label from a source item to downstream items
• Programmatic labeling, applied via API for automated pipelines

Labels use the same taxonomy already used across Microsoft 365 — levels such as General, Confidential, and Highly Confidential, or custom labels an organization defines — and can be applied manually, by default, or through a mandatory labeling policy ^{[S3] [S4]}. A label's protection travels with the underlying data: when labeled Fabric or Power BI content is exported to Excel, PowerPoint, PDF, or .pbix, encryption is enforced so only authorized users can open the exported file ^[S3]. This means a report or dataset extracted from Fabric and opened elsewhere carries the same classification — and the same access restriction — that was applied inside Fabric.

Beyond classification, protection policies tie directly to a specific sensitivity label and restrict access to any item carrying that label to a named set of users and groups, blocking everyone else. This is supported for native Fabric items and Power BI semantic models ^[S3].

A label's protection travels with the data itself, not with the tool you happen to open it in.

Best Practice: Use Label Inheritance for End-to-End Coverage#

Applying a label to a source lakehouse or warehouse and relying on inheritance to propagate it to semantic models and reports reduces the labeling surface area a team must manage manually. Reserve explicit per-item labeling for exceptions where a downstream item requires a stricter classification than its source.

# Before: manual labeling at every downstream item (error-prone, drifts over time)
Lakehouse (Confidential)         -> label applied manually
Semantic Model (unlabeled)       -> forgotten during a rebuild
Report (unlabeled)                -> exported to Excel with no protection

# After: label the source, inherit downstream
Lakehouse (Confidential)         -> label applied manually, marked as source
Semantic Model (Confidential)    -> inherited automatically
Report (Confidential)             -> inherited automatically
Excel export                      -> encrypted, opens only for authorized users  <sup id="cite-3"><a href="#src-3" class="cite">[S3]</a></sup>

Sensitivity Labels for AI Agents#

Fabric data agent scenarios raise the stakes on labeling discipline. Sensitivity labels are exposed through public APIs, which enables programmatic access by agents and automated workflows ^[S4] — but that same exposure means an agent built on unlabeled or under-labeled sources has no classification signal to reason about. Purview DLP and access-restriction policies apply directly to data agent queries, and can block a query from running or strip sensitive results from an agent's response even when the agent is technically permitted to read the source ^[S5]. In other words, labeling and DLP are not bypassed just because the consumer is an AI agent rather than a human in a report — the same governed path applies.

Data Loss Prevention (DLP) Policies#

Purview DLP policies scoped to Fabric and Power BI workspaces automatically scan DLP-supported item types on upload to detect sensitive information types and labels — including semantic models and OneLake structured items such as lakehouses, SQL databases, mirrored databases, and KQL databases ^{[S1] [S3]}. When sensitive information is detected, the policy generates an audit log entry for every detection and can surface a configurable alert message to the data owner so they can take remedial action before the data propagates further ^[S1].

A practical rollout pattern: DLP policies can be run first in simulation mode to tune detection accuracy before enforcement, which avoids false-positive alert fatigue when a policy first goes live ^[S3].

DLP has historically operated as a passive scan at ingest time rather than a blocking control during query execution, generating alerts rather than preventing access outright. Inference: The new restrict-access preview action changes that calculus — once it reaches general availability, DLP moves from detect-and-alert toward detect-and-enforce, which is a meaningful shift for teams that previously treated DLP as advisory only.

Tenant-wide visibility: the Protect, secure, and comply report#

A Protect, secure, and comply report inside the OneLake Catalog's Govern tab shows tenant-wide sensitivity-label coverage, and audit logs separately track label activity and DLP detections for ongoing visibility ^[S3]. This is one of the surfaces that moved out of the retired Purview Hub — see the navigation section below.

Data Security Posture Management (DSPM) for AI#

As organizations connect Fabric data to AI agents and Copilot experiences, a new governance question emerges: is sensitive data leaking into prompts or model responses that were never designed to be access-controlled the same way a report is? Microsoft Purview Data Security Posture Management (DSPM) for Fabric addresses this directly. It discovers data risks such as sensitive data appearing in AI prompts and responses, and runs Data Risk Assessments that identify overshared, unprotected, or sensitive Fabric assets so admins can target remediation — applying labels or policies to the specific assets the assessment flags ^[S3].

Inference: DSPM effectively closes the loop between classification (labels) and enforcement (DLP) by adding a discovery layer that proactively surfaces where those controls are missing, rather than waiting for a DLP scan to catch a violation after the fact.

Data-Level Security: Row, Column, and Table Controls#

Workspace roles provide coarse-grained access — a user either has access to a workspace or they do not. For finer grain, Fabric supports row-level security (RLS), column-level security (CLS), and table-level security (TLS) on specific item types ^[S1]. As of the verified claims in this knowledge base, these granular controls are supported on:

• SQL analytics endpoints
• Warehouses
• Direct Lake semantic models
• KQL Database items

The diagram below traces how a permission or sensitivity-label decision actually resolves at open/query time — walking from tenant defaults down through domain delegation and workspace boundaries to the specific item, and separately tracing how a label is sourced (manual, inherited, default, or programmatic) before it converges on an enforced state.

Inference: Lakehouses accessed via the SQL analytics endpoint can therefore enforce row and column filters without modifying the underlying Delta tables. Direct Lake models inherit security from the underlying SQL endpoint, making this a practical pattern for multi-audience reporting.

Endorsement: Signaling Trustworthiness#

Endorsement gives item creators and organizations a structured way to communicate asset quality without requiring consumers to investigate each item themselves ^[S1]. There are two levels:

• Promoted — item owners self-apply this status to indicate an asset is ready for general use.
• Certified — organizations apply this to items that meet defined quality standards; certification authority is typically restricted to a designated group.

Endorsed items receive priority placement in certain search results and catalog views ^[S1], so higher-trust assets naturally rise to the top of discovery surfaces without requiring consumers to filter manually.

Best Practice: Define Certification Criteria Before You Enable Certification#

Certification is only meaningful if it signals consistent quality. Before enabling the certified endorsement, document what a Certified item means in your organization — schema stability, documentation completeness, test coverage, SLA — and gate the certification workflow on those criteria. An uncritical flood of self-certified assets degrades the signal for all consumers.

The OneLake Catalog: Explore, Govern, and Secure#

The OneLake catalog provides a single searchable surface for all Fabric items a user has access to ^[S1]. Since the January 2026 Purview Hub retirement, the catalog is organized into three distinct tabs, each with a different governance job ^[S6]:

Because the Explore tab only shows items the current user already has access to, getting a full-estate discovery view requires either Fabric Admin rights, or domain owners being granted read access across all workspaces in their domain ^[S6]. This is a meaningful planning point for anyone building a central data-catalog view: the OneLake catalog by itself will show a different picture to every viewer unless that viewer has broad read access.

Users can reach relevant content without needing prior knowledge of which workspace or system holds the data ^[S1]. Governance in Fabric is centralized in the OneLake Catalog and powered by built-in Purview, meaning permissions and controls flow from this surface rather than being configured separately per workload ^[S2].

Purview Data Map Integration and Lineage#

For organizations that need enterprise-grade lineage and metadata cataloging beyond what the OneLake catalog provides natively, Fabric integrates with Microsoft Purview Data Map ^[S1]:

• Purview Data Map can scan Fabric items to extract item-level metadata and lineage.
• Scanned metadata is exposed via Atlas APIs, making it accessible to any external tool or system that speaks the Atlas open standard.
• A live view lets data consumers browse all Fabric workspaces they have viewer access to directly within the Purview portal, without waiting for a scan.
• Manual scanning for full item-level metadata is available at the enterprise tier of Purview.

This lineage tracking is not limited to Fabric-native data. Because Fabric integrates with Purview, data lineage can be tracked end-to-end from an external source — such as Snowflake — through to the AI model that ultimately consumes the data ^[S8]. That is a meaningfully broader lineage story than "lineage within Fabric": it follows data across a multi-cloud boundary and through to AI consumption.

Inference: Teams that already operate Purview as their enterprise catalog of record can extend that catalog to cover Fabric without standing up a parallel governance tool. The Atlas API exposure means downstream governance automation — automated classification, lineage-aware impact analysis — can consume Fabric metadata alongside metadata from other data systems.

Metadata Scanning APIs#

For organizations that do not use Purview Data Map but still need programmatic access to platform metadata, Fabric provides admin REST APIs known as the scanner APIs ^[S1]. External cataloging tools can call these to retrieve item-level metadata across all Fabric items, including:

• Item name and ID
• Sensitivity label status
• Endorsement status

This API surface is the integration point for custom governance dashboards, data-catalog imports, and automated compliance reporting pipelines ^[S1]. Inference: A common pattern is to schedule scanner API calls as a nightly batch, push results to a central governance store, and build compliance dashboards on top — enabling audit-ready visibility without requiring Purview licensing for the full data map.

Compliance Certifications#

Microsoft Fabric holds multiple recognized compliance certifications ^[S1]:

• HIPAA BAA
• ISO/IEC 27001
• ISO/IEC 27017
• ISO/IEC 27018
• ISO/IEC 27701

These certifications cover the platform itself; workloads built on Fabric must independently satisfy their own regulatory requirements.

Licensing Considerations#

Some advanced governance capabilities require licenses beyond the base Fabric license ^[S1]:

• Purview Information Protection (sensitivity labels beyond basic)
• Purview DLP for Fabric
• Cross-organization Purview governance

Inference: Organizations evaluating Fabric's governance model for regulated workloads — healthcare, financial services, public sector — should map required capabilities to their specific licensing tier before committing to a governance design. Features that appear native may require separate Purview licensing to activate at the policy level.

Best Practices Summary#

The verified pattern claims in this knowledge base support the following recommendations:

1. Structure the settings hierarchy intentionally. Lock sensitive or high-risk governance settings at the tenant level. Delegate safe, domain-specific settings to domain admins. Reserve workspace-level controls for operational fine-tuning ^[S1].

2. Split capacities by environment stage. Use separate capacities for development, test, acceptance, and production to achieve workload isolation and clean cost attribution per environment ^[S1].

3. Adopt label inheritance for coverage at scale. Apply sensitivity labels at the source and inherit downstream rather than labeling every downstream item manually ^{[S1] [S3]}.

4. Run DLP in simulation mode before enforcing it. Tune detection accuracy against real traffic before turning on alerts or the preview restrict-access action, to avoid false-positive fatigue ^[S3].

5. Define certification standards before enabling certified endorsement. Governance signals are only valuable when they are consistent and trusted ^[S1].

6. Layer governance by medallion stage. Inference, drawing on a tier-6 practitioner pattern: bronze restricted to engineering workspace roles with sensitivity labels applied at ingestion; silver adding schema validation and item-level consumer permissions; gold requiring catalog certification, domain-owner endorsement, tested row-level security, and a completed DLP scan before the item is marked discoverable ^[S6]. Treat this as one practitioner's layering scheme to adapt, not a Microsoft-documented reference architecture.

# Medallion governance pattern (inference, tier-6 sourced — adapt, don't copy verbatim)
Bronze  -> engineering-only workspace roles + sensitivity label at ingestion
Silver  -> + schema validation + item-level consumer permissions + OneSecurity row filters
Gold    -> + catalog certification + domain-owner endorsement
           + tested row-level security + completed DLP scan
           => only then marked discoverable in the OneLake catalog

What Goes Wrong#

• Enabling OneSecurity on a lakehouse that backs a Direct Lake model. Reported to cause silent fallback to DirectQuery, losing the performance benefit Direct Lake exists to provide ^[S6] — hedge: tier-6 source, verify in your tenant.
• Leaving all settings at tenant default and relying on workspace-level ad hoc controls, which creates inconsistency and audit gaps. (Inference from the structural claims.)
• Applying sensitivity labels only at the item level without configuring inheritance, resulting in unlabeled downstream exports. (Inference.)
• Enabling certified endorsement without written criteria, causing certification inflation that erodes consumer trust. (Inference.)
• Treating compliance certification (ISO, HIPAA) as a substitute for workload-level controls, when the certifications cover the platform, not the data or pipelines built on it. (Inference.)
• Checking the Govern tab for a permission change that just happened. Because Govern-tab data refreshes roughly daily, a change made minutes ago will not show up there yet — check the Secure tab instead ^[S6].

Items marked (Inference) are drawn from structural claims rather than independently verified antipattern claims in this knowledge base.

Internals#

Architecture & design#

Coming soon — this depth isn't in the knowledge base yet. It needs an L4/L5 source such as a Microsoft engineering blog or architecture deep-dive on how the Purview policy/label service, the OneLake catalog's Govern-tab data pipeline, and Fabric's admin monitoring workspace are wired together as distinct backend components. Tracked in content/queue.md.

How it works internally#

Coming soon — this depth isn't in the knowledge base yet. It needs an L4/L5 source such as a Microsoft engineering blog on Purview policy-evaluation internals in Fabric (how a DLP scan or label-inheritance rule is actually evaluated against an item at write time) or lineage-scanning internals (how the Data Map scanner walks Fabric's metadata graph to build the Atlas lineage graph). Tracked in content/queue.md.

Performance characteristics#

Coming soon — this depth isn't in the knowledge base yet. It needs an L4/L5 source publishing measured numbers — DLP scan latency at upload time, Govern-tab refresh-pipeline throughput, or Data Map scan duration by workspace size — rather than the qualitative "roughly daily" cadence currently verified. Tracked in content/queue.md.

Worked Example: Rolling Out Governance for a New Domain#

Consider a Finance domain being stood up for the first time. A practical, claims-grounded sequence:

1. Tenant admin delegates safe settings to the domain. Sensitive settings (e.g., cross-tenant sharing) stay locked at tenant level; domain-scoped settings (e.g., workspace naming, default sensitivity label) are delegated to the Finance domain admin ^[S1].
2. Domain admin creates the domain and assigns workspaces underneath it, following the functional-alignment guidance rather than mirroring the org chart, and keeping workspace count within a manageable range per domain ^[S6].
3. A default sensitivity label is configured on the domain's lakehouses so every new item inherits a baseline classification without relying on manual tagging ^{[S1] [S3]}.
4. DLP policies are scoped to the domain's workspaces and run in simulation mode for an initial period to observe what would be flagged, before switching on alerts ^[S3].
5. Certification criteria are documented before any gold-layer asset in the domain is allowed to carry the Certified endorsement ^[S1].
6. The team checks the OneLake catalog's Govern tab weekly for label/endorsement coverage gaps, and the Secure tab whenever a live permission question comes up — not the Govern tab, since it lags by roughly a day ^[S6].

# Rollout order (claims-grounded)
1. Tenant: lock sensitive settings, delegate the rest            <sup id="cite-1"><a href="#src-1" class="cite">[S1]</a></sup>
2. Domain: create Finance domain, assign workspaces              <sup id="cite-6"><a href="#src-6" class="cite">[S6]</a></sup>
3. Default label on domain lakehouses                             <sup id="cite-1"><a href="#src-1" class="cite">[S1]</a></sup> <sup id="cite-3"><a href="#src-3" class="cite">[S3]</a></sup>
4. DLP policy in simulation mode -> tune -> enforce                <sup id="cite-3"><a href="#src-3" class="cite">[S3]</a></sup>
5. Certification criteria documented before Gold assets certify   <sup id="cite-1"><a href="#src-1" class="cite">[S1]</a></sup>
6. Govern tab weekly, Secure tab for live permission checks        <sup id="cite-6"><a href="#src-6" class="cite">[S6]</a></sup>

Inference: this sequencing is a synthesis of the individual verified claims above, not itself a single verified end-to-end procedure from one source.