10.2 — Governance Layers, Sensitivity Labels & Data Lineage in Microsoft Fabric

Governance is where Microsoft Fabric either becomes a strategic enterprise platform or just another analytics tool. This section looks at how Fabric combines governance layers, sensitivity labels, and data lineage into a single, enforceable model that spans all workloads and OneLake.

Governance Layers in Microsoft Fabric

Fabric governance is not one feature. It is a stack of complementary layers, each responsible for a different scope:

Layer	Scope	Primary Responsibility
Workspace governance	Workspaces & tenants	Who can create, access, share, and administer solution containers
Item governance	Individual Fabric items	Permissions, lifecycle, and policies for reports, Lakehouses, Warehouses, etc.
Data governance (Purview)	Data estate across services	Catalog, classification, lineage, and policy for data assets
Security governance (RBAC/RLS/OLS)	Row, object, and column-level access	Who can see which objects and which rows/columns of data
Deployment governance	Dev/Test/Prod environments	How changes move between environments in a controlled, auditable way

Workspace Governance

Workspaces are the primary security and collaboration boundary in Fabric. They group items (Lakehouses, Warehouses, semantic models, reports, notebooks, pipelines) and control who can work with them.

Key workspace governance elements:

• Roles and membership: Admin, Member, Contributor, Viewer — each with defined capabilities such as publishing content, managing permissions, or only viewing.
• Workspace types: Default, Pro, and capacity-backed (Fabric capacity or Power BI Premium) workspaces determine performance, scale, and some governance options.
• Creation policies: Tenant-level controls decide who can create workspaces and under what conditions, often restricted to specific security groups.
• Isolation boundaries: Workspaces separate teams, projects, and environments (Dev, Test, Prod) to avoid accidental cross-impact.
• Backup and lifecycle: Options such as deployment pipelines, export, and retention policies connect workspace content to broader lifecycle management.

In most enterprises, workspace design is the first and most visible governance decision: how many, for whom, and mapped to which business domains and environments.

Item Governance

Item governance focuses on the individual objects that live inside workspaces. Each Fabric item has its own permissions, lifecycle rules, and policies.

Typical controls at the item level include:

• Item permissions: Granular access control for a specific Lakehouse, Warehouse, report, semantic model, or pipeline, which can diverge from the workspace default.
• Sharing and endorsement: Controls for publishing to apps, sharing with individuals or groups, and endorsing content as Promoted or Certified.
• Sensitivity labels: Classification and protection that travel with the item and its data (discussed later).
• Usage and quality signals: View metrics, refresh history, and data reliability indicators feed into governance decisions (e.g., deprecating unused items).
• Lifecycle states: Naming, versioning, and deprecation practices that make it clear which items are experimental vs. production-grade.

Item governance lets central teams define standards (naming, tagging, labeling) while still allowing business units to own and iterate on their own solutions.

Data Governance (Microsoft Purview)

Microsoft Purview provides the data governance backbone for Fabric. It is responsible for understanding what data exists, where it lives, how it is classified, and how it flows.

• Unified catalog: Purview scans Fabric items to register tables, files, schemas, and business-friendly metadata.
• Business glossary: Enterprise terms (Customer, Invoice, Order) are linked to technical assets, enabling consistent interpretation.
• Classification: Automatic and manual classification rules identify PII, financial, health, and other regulated data.
• Policies: Data access, masking, and sharing policies can be defined centrally and applied consistently across workloads.
• Lineage: End-to-end data flow is captured automatically, enabling impact analysis, troubleshooting, and compliance evidence.

In Fabric, Purview is not a separate, optional add-on. It is tightly integrated into OneLake and the Fabric experiences, which means governance is present from ingestion through visualization.

Security Governance (RBAC, RLS, OLS)

Security governance describes who can see which data and at what granularity. Fabric combines multiple mechanisms:

• RBAC (Role-Based Access Control)
  • Controls access to workspaces, items, and datasets at the object level.
  • Implemented via Azure AD (Entra ID) groups, workspace roles, and item-level permissions.
• RLS (Row-Level Security)
  • Filters rows in semantic models or Warehouse/Lakehouse tables based on the identity of the user.
  • Common patterns: region-based access, business unit isolation, or customer tenancy.
• OLS (Object-Level Security)
  • Controls which tables or columns users can see in a semantic model or dataset.
  • Useful for hiding highly sensitive measures or technical tables that should not be exposed.

These security features work alongside sensitivity labels and Purview policies. A user may technically have access to an item, but labels and policies can still restrict what they can do with the data (e.g., exporting or sharing).

Deployment Governance (Dev/Test/Prod Pipelines)

Deployment governance is about how change happens. Fabric deployment pipelines provide a structured way to move content between development, test, and production environments while preserving governance.

• Environment separation: Each stage (Dev, Test, Prod) maps to a distinct workspace with its own access controls.
• Controlled promotion: Only authorized users can promote changes downstream, ensuring that reviews and approvals occur.
• Configurable connections: Data source connections and parameters can vary by environment (e.g., test databases vs. production databases) while keeping the same logical pipeline.
• Consistency checks: Pipelines help detect drift between environments and ensure that production reflects approved configurations.

Deployment governance ties into audit, security, and lineage: promotions are logged, access is controlled by roles, and lineage reflects which production assets originate from which development sources.

How the Governance Layers Work as a Unified Stack

These layers are additive rather than alternative. For any given analytics solution in Fabric, multiple layers apply simultaneously:

• Workspace defines the broad access boundary and environment (Dev/Test/Prod).
• Item governance refines access and lifecycle for specific assets like a Lakehouse or report.
• Data governance (Purview) ensures the data itself is cataloged, classified, labeled, and tracked.
• Security (RBAC/RLS/OLS) enforces who can see which objects and which slices of the data.
• Deployment governance controls how changes to any of the above move toward production.

When designed intentionally, this stack lets central teams define guardrails while still giving domains and teams autonomy within their workspaces and pipelines.

Sensitivity Labels — Protecting Data Everywhere

What Sensitivity Labels Are and Why They Matter

Sensitivity labels classify data according to its business impact and apply technical protections that travel with the data. In Fabric, labels are built on Microsoft Purview Information Protection, the same platform used for Office documents and emails.

Labels serve three main purposes:

• Classification: Communicate how sensitive a dataset or report is (e.g., Public vs. Highly Confidential).
• Protection: Enforce restrictions such as encryption, export controls, or forced justification for risky actions.
• Awareness: Make end users aware of the data sensitivity directly within the Fabric UI and downstream tools like Excel and Power BI Desktop.

Label Hierarchy

Most enterprises implement a hierarchical label model. A typical example looks like this:

Label	Typical Use	Example Protections
Public	Information intended for anyone	No restrictions; may still carry minimal branding or disclaimers
Internal	Routine business data for employees/partners	Limited sharing outside the organization; basic export monitoring
Confidential	Sensitive business data	Restricted sharing, monitored exports, potential encryption
Highly Confidential	Critical or regulated data (PII, financial, health)	Strict export controls, mandatory encryption, limited audience
Restricted	Exceptionally sensitive data (e.g., M&A, legal, national security)	Strong encryption, heavily constrained access, robust monitoring and justification

Each higher level inherits expectations from the levels below and adds stricter controls. Fabric respects this hierarchy consistently across workloads.

How Labels Are Applied

Labels can be applied in multiple ways, which often coexist in the same tenant:

• Manual labeling
  • Creators or owners choose a label directly in the Fabric experience (e.g., setting a report to Confidential).
  • Typically required for key assets where the owner understands the business impact best.
• Automatic labeling via Purview
  • Purview scans data for sensitive information types (PII, payment data, health identifiers) and applies labels based on centrally configured policies.
  • Policies can be scoped to specific workspaces, domains, or data types.
• Inherited labeling
  • Child assets inherit labels from parent objects when created or refreshed.
  • For example, a semantic model or report built on a Highly Confidential Lakehouse table will inherit the Highly Confidential label by default.

Administrators can combine these approaches to balance automation with human judgment.

Where Labels Apply in Fabric

In Fabric, sensitivity labels apply across both analytics and data engineering workloads. Common label targets include:

• Lakehouses and their Delta tables
• Warehouses (SQL analytics endpoints and objects)
• Power BI reports and semantic models
• Pipelines (especially output datasets and connections)
• Notebooks and dataflows
• Event Streams and streaming sources/sinks
• OneLake files and folders (e.g., CSV, Parquet within Delta Lake structures)

Because labels are built on a common Microsoft Purview Information Protection foundation, their behavior is consistent with Office content where possible.

How Labels Travel with Data

One of the most important aspects of labels is that they are sticky — they follow the data, even outside Fabric, wherever possible.

• Export protection
  • When users export data to Excel, PowerPoint, PDF, or CSV, labels (and associated encryption) are preserved where supported.
  • For example, a Highly Confidential report exported to PowerPoint will produce a labeled, protected deck.
• Downstream inheritance
  • If a semantic model is labeled Highly Confidential, reports built on top inherit the label by default.
  • If a Lakehouse table is labeled Confidential, derived assets created within Fabric generally inherit that label.
• Cross-application consistency
  • Labels applied in Fabric are visible in Office apps and vice versa, provided policies and scopes are aligned.

This behavior ensures that protection does not stop at the workspace boundary; it continues all the way to the end user’s desktop.

Label Enforcement: Blocking, Justification, Encryption

Labels are not just metadata; they trigger enforcement policies defined by security and compliance teams. Common enforcement actions include:

• Blocking high-risk actions
  • Preventing export of Restricted or Highly Confidential data to unsupported formats.
  • Blocking sharing of sensitive content with external users or domains.
• Requiring user justification
  • Allowing an action (like downgrading a label or exporting confidential data) only if the user provides a reason.
  • Justifications are recorded in audit logs for later review.
• Applying encryption
  • Encrypting exported files (Office documents in particular) so that content remains protected even after leaving Fabric.
  • Binding access to identities and groups in Entra ID.

From an end user perspective, this might look like grayed-out export options, warning dialogs requiring justification, or prompts to confirm label changes.

Real-World Example: Highly Confidential Lakehouse to Semantic Model

Consider a customer analytics solution:

• A Lakehouse table contains detailed customer data, including PII and transaction history.
• The data governance team classifies it as Highly Confidential and applies the corresponding sensitivity label.
• A semantic model is built on top of the Lakehouse to drive executive dashboards.
• Reports are published to a workspace used by the sales leadership team.

With properly configured policies:

• The semantic model and reports inherit the Highly Confidential label from the Lakehouse table.
• When a user opens the report in the service or Power BI Desktop, the label is displayed in the UI.
• If a user attempts to export the report data to Excel, the system may either:
  • Block the export entirely, or
  • Require justification and apply encryption to the exported file.
• Any exported Excel file carries the Highly Confidential label and associated protections into the Office environment.

This is the core value of labels in Fabric: they move governance from policy documents into enforceable, user-visible behavior.

Data Lineage — The Backbone of Enterprise Governance

What Data Lineage Is and Why It Matters

Data lineage describes how data moves and transforms from its original source to its final consumption point. In Fabric, lineage is a first-class capability provided by Purview.

Lineage matters because it enables:

• Trust: Users can see where data came from and what transformations occurred.
• Impact analysis: Engineers can understand what will break if a source schema or pipeline changes.
• Compliance: Auditors can verify how regulated data flows and where it is stored.
• Operational efficiency: Support teams can troubleshoot issues faster by following data paths.

How Purview Lineage Works in Fabric

In Fabric, lineage is captured automatically as you build solutions; there is no need for manual lineage diagrams or custom tagging.

• Automatic capture
  • When you create a pipeline that ingests from a source into a Lakehouse, Purview records the source → Lakehouse relationship.
  • When a semantic model or report connects to a Lakehouse or Warehouse, that dependency is also recorded.
• No-code and code-first parity
  • Both dataflows/pipelines and notebook-based transformations can contribute to lineage when they use supported connectors and operations.
• Continuous updates
  • Lineage is refreshed as new assets are created or existing assets are modified, keeping the graph more accurate over time.

What Lineage Tracks

Purview lineage in Fabric connects a broad set of asset types in a single graph. Typical lineage chains include:

• Sources: On-premises databases, SaaS applications, cloud storage, streaming feeds.
• Pipelines and dataflows: Ingestion and transformation logic.
• Notebooks: Spark-based transformations, feature engineering, and advanced processing.
• Lakehouses and Warehouses: Curated, queryable storage layers.
• Semantic models: Business-friendly models exposed to analysts and report authors.
• Dashboards and reports: Final consumption artifacts in Power BI.

The result is an end-to-end view that covers engineering, analytics, and visualization in a single lineage graph.

Lineage Use Cases

With automatic lineage in place, several high-value scenarios become possible:

• Impact analysis
  • Before changing a Delta table schema, you can check which downstream semantic models and reports depend on it.
  • This avoids breaking critical business reports unexpectedly.
• Debugging data issues
  • If a dashboard shows unexpected values, lineage helps trace back to the specific pipeline or source that introduced the anomaly.
• Compliance audits
  • Auditors can follow regulated data from the system of record to every place it is stored, transformed, or visualized.
• Change management
  • Release managers can assess which owners and teams must be notified when a shared dataset or table changes.

The Lineage Graph in Purview

The Purview lineage graph shows assets as nodes and data flows as edges. Within the Fabric experiences, you can usually open a lineage view directly from an asset.

• What it shows
  • Upstream sources feeding the selected asset.
  • Downstream assets that depend on it.
  • Intermediate transformations such as pipelines, dataflows, or notebooks.
• How to navigate
  • Click to expand upstream or downstream chains.
  • Filter by asset type (e.g., show only Lakehouses and semantic models).
  • Drill into specific nodes to see properties, classifications, and labels.

For large estates, the lineage graph becomes the primary way architects and data stewards understand how everything connects.

Cross-Workload Lineage in Fabric

Because Fabric unifies data engineering, data science, real-time analytics, and BI, lineage naturally crosses workload boundaries:

• Streaming Event Streams feeding into Lakehouses.
• Batch Pipelines loading raw data into Bronze tables, then curated Silver/Gold tables.
• Warehouses consuming curated Lakehouse data for SQL-centric analytics.
• Semantic models referencing Lakehouses or Warehouses.
• Power BI reports and dashboards consuming semantic models.

All of these relationships are captured in a single lineage fabric, giving a coherent view of the entire analytics platform.

Real-World Scenario: Schema Change in a Delta Table

Imagine a data engineer needs to modify a Delta table used across the organization:

• The engineer plans to rename a column and add a new column in a Lakehouse Delta table.
• Before making the change, they open lineage for the table in Purview.
• The lineage graph shows that the table feeds:
  • Two semantic models used by finance and sales.
  • Several reports, including an executive KPI dashboard.
  • A Warehouse that powers ad-hoc SQL queries.
• Armed with this view, the engineer coordinates with affected owners, updates semantic models and reports, and schedules the change during a maintenance window.

After the change, lineage automatically updates to reflect the modified schema and any downstream adjustments. There is no need for manual diagram maintenance.

Audit Logs & Automatic Data Classification

Purview Audit Logs in Fabric

Audit logs capture who did what, when, and to which assets. In Fabric, Purview audit logs integrate with the broader Microsoft 365 and Azure auditing ecosystem.

At a high level, audit logs help you:

• Reconstruct events after an incident or suspected data leak.
• Demonstrate control during compliance assessments.
• Detect anomalies such as unusual export patterns or label downgrades.

What Gets Logged

While the precise schema depends on your tenant configuration, typical audit events in a Fabric context include:

• Access events
  • Users viewing or querying sensitive datasets, reports, or tables.
  • Sign-ins and role changes for workspaces and items.
• Label changes
  • Applying, changing, or removing sensitivity labels on items.
  • Downgrading a label (e.g., Highly Confidential to Internal) with optional justification.
• Export attempts
  • Exporting data to Excel, CSV, PowerPoint, or other formats.
  • Blocked exports due to policy and any user justifications.
• Policy violations
  • Attempts to share labeled content with unauthorized users or domains.
  • Actions that trigger DLP (Data Loss Prevention) or conditional access policies.

These logs can be integrated into centralized SIEM and monitoring systems for real-time alerting and long-term analysis.

Automatic Data Classification

Automatic classification uses predefined and custom rules to detect sensitive data patterns in your Fabric assets. It reduces reliance on manual tagging and ensures consistent treatment of regulated data.

• PII detection
  • Patterns like names, email addresses, phone numbers, national IDs, and other personal identifiers.
• Financial data classification
  • Credit card numbers, bank account details, transaction identifiers.
• Regulated content tagging
  • Health information (PHI), government identifiers, or other industry-specific data types.

Classification results are visible in Purview and can drive both operational decisions (who can use which data) and compliance processes (which assets require special handling).

How Classification Feeds Labels and Policy Enforcement

Automatic classification and sensitivity labels are tightly coupled:

• Label suggestions
  • When Purview detects PII or financial data, it can suggest appropriate labels (e.g., Confidential or Highly Confidential) to asset owners.
  • Owners can accept, refine, or override suggestions based on business context.
• Auto-labeling policies
  • Administrators can create policies that automatically apply labels when certain classification conditions are met.
  • For example, any dataset containing credit card numbers is automatically labeled Highly Confidential.
• Policy enforcement
  • Once labels are applied, DLP and access policies use them to enforce controls: blocking exports, restricting sharing, or requiring justification.
  • Audit logs record when these policies are triggered and how users responded.

The result is a feedback loop: classification detects sensitive content, labels apply protection, policies enforce behavior, and audit logs provide evidence. Together with governance layers and lineage, this forms a comprehensive governance model for Microsoft Fabric.