Govern Microsoft Fabric by assigning accountable data owners, controlling every access path, classifying sensitive information and retaining evidence of changes and reviews. Catalogs, lineage and labels support that operating model; they do not independently prove that a dataset is correct, authorized for every user or compliant with a particular obligation.

Key takeaways

• Separate ownership, discovery, authorization and protection responsibilities.
• Test permissions through the actual SQL, notebook, reporting and sharing paths.
• Verify label and policy behavior for supported items and export routes.
• Keep audit evidence tied to an owner, decision and review date.

Define governance outcomes before configuring tools

Start with concrete questions: who can approve use of this dataset, what business definition does it implement, who can read it and how can an incident be investigated? A governance design should answer those questions for a new dataset and for a dataset whose owner has left the organization.

Microsoft’s Fabric and Purview guidance positions the OneLake catalog as the Fabric governance experience, including discovery, domains, endorsement and lineage. Purview adds information protection, monitoring and broader risk or compliance capabilities. Review the licensing and support required for each selected feature rather than assuming one purchase enables every control.

Use a small operating contract for each published data product: purpose, owner, source, intended consumers, quality checks, freshness target, access rules, retention decision and support route. Keep it readable enough that the consuming team can use it during an incident.

A responsibility matrix for data products

This is an illustrative allocation, not a prescription for every organization. One person may hold multiple roles, but the decision still needs an explicit accountable owner. A shared mailbox without a decision process is not ownership.

Build an access model around real execution paths

Inventory workspace roles, item permissions, data-path permissions, SQL policies, semantic-model rules and service identities. Then document the effective caller at each boundary. Broad development permissions can make a test pass while hiding restrictions that affect a normal consumer.

The SQL endpoint security guide distinguishes user-identity and delegated-identity modes. The selected mode changes where data rules are enforced and which identity reaches OneLake. Verify the configured mode rather than assuming that SQL access and direct data access share an identical policy path.

Row-level security is scoped to its implementation

A model-level row rule does not automatically constrain every other route to the underlying data. Identify which layer owns the rule and test each permitted interface. Where a centralized policy is selected, verify support and behavior for the specific engine and item. Avoid an untested claim of universal enforcement.

Run these checks after meaningful role, connection or sharing changes. Preserve the identity type and interface in the evidence so a later reviewer knows what was actually tested.

Sensitivity labels, policies and supported exports

Microsoft’s information protection documentation distinguishes sensitivity classification from policy-based access and protection behavior. Supported tenant policies, protected files and export paths matter. Do not assume that attaching a label alone enforces every desired restriction or that every export format retains protection.

Define a classification scheme with clear examples and an escalation route for ambiguous data. Publish policies to the intended users and groups, verify licensing and test supported scenarios. Inspect what happens when an item changes source or receives inherited classification, rather than assuming a one-time label is permanently correct.

• Identify the information types and intended uses.
• Assign an owner for label and policy decisions.
• Test ordinary access and supported export behavior.
• Record unsupported paths and the controls that address them.
• Review coverage after new sources or consumers are introduced.

Classification coverage is useful, but it is not the same as proof of effective authorization. Report both coverage and observed policy behavior so the governance dashboard does not collapse distinct controls into one percentage.

Use lineage to support decisions, not to certify correctness

Lineage helps identify upstream sources and downstream impact. Use it when reviewing schema changes, retiring datasets or investigating an incorrect report. Confirm coverage for the actual tools and external steps used; a custom process may need additional documentation.

Before a change, identify affected consumers, notify their owners and define compatibility checks. After release, confirm that critical reports and jobs still use the intended version. A visible lineage connection proves a dependency exists; it does not prove the transformation is semantically correct.

Endorsement needs an acceptance process

Define what a promoted or certified dataset means in your organization. Require a documented grain, business definitions, quality checks and owner approval. Review that status after material changes. An endorsement that outlives its supporting evidence can mislead consumers.

An audit-evidence checklist

Retain evidence according to organizational policy and applicable obligations. This checklist is an operational starting point, not a certification or legal conclusion.

• Dataset purpose, accountable owner and review date.
• Source and transformation references, with release revision.
• Data-quality checks and documented exceptions.
• Access request, approval and effective-permission evidence.
• Service-identity and connection ownership records.
• Classification and policy configuration with tested scenarios.
• Sharing and export decisions for the relevant paths.
• Change history, incident records and completed remediation.
• Retention and recovery responsibilities.

Make the evidence searchable by item or data-product identifier. Keep sensitive query contents and personal information out of broad-access logs unless collection is necessary and authorized. Auditability should not create a second uncontrolled copy of the data being governed.

Use the Fabric CI/CD guide to connect releases with governance checks. Use the shortcut guide for producer and consumer identity boundaries.

Common questions

Make governance part of everyday delivery

Start with one important data product and prove its ownership, access and evidence model. Plan your Microsoft Fabric implementation with controls that teams can operate and reviewers can verify.