IT Admin Data Architect Platform Owner Data Steward — This section defines the Fabric governance operating model: domains, ownership, catalog responsibilities, endorsement, information protection, lifecycle, and delegated administration.
Use this page for the governance operating model and maturity assessment. Use Catalog & Governance for OneLake Catalog and Purview implementation, and Security for detailed access, data protection, and audit controls.
Governance
Establishing data governance, cataloging, quality, and trust across your Fabric environment.
Governance Framework
Effective governance assigns decisions to the right level. Fabric administrators establish tenant-wide guardrails, domain administrators adapt delegated settings for business areas, workspace owners manage delivery boundaries, and item owners and data stewards maintain trustworthy content.
1. Organize
Use domains, subdomains, capacities, and workspaces to make ownership and lifecycle boundaries visible.
2. Describe & Endorse
Maintain useful names, descriptions, owners, lineage, sensitivity labels, and trust signals in the OneLake Catalog.
3. Protect
Apply workspace and item permissions, OneLake Security, labels, DLP, and audit controls according to risk.
4. Review & Improve
Use the Catalog Govern and Secure experiences, access reviews, operational monitoring, and certification reviews to address governance debt.
Fabric Governance Surfaces
OneLake Catalog is the daily Fabric experience for discovery, governance insights, and centralized security administration. Fabric domains provide organization and delegated administration. Microsoft Purview supplies supporting information-protection, DLP, audit, compliance, and cross-estate capabilities where your organization uses them.
Use Catalog & Governance for Explore, Govern, Secure, and Catalog API guidance. Use Security for access enforcement and OneLake policies. This page defines ownership, delegated decision rights, and the operating process that connects them.
Data Domains & Ownership
Organize Fabric workspaces into logical domains and subdomains that align with durable business accountability rather than temporary projects. Domain assignment improves organization, discoverability, and delegated governance; it does not grant access to workspace items or their data.
- Assign domain admins to manage the domain description, contributors, workspace assignments, and delegated settings
- Use domain contributors when workspace admins should be able to associate their own workspaces with a domain
- Delegate only the tenant settings that business units genuinely need to customize, such as domain certification or default-label settings
- Establish data stewards who maintain descriptions, ownership, endorsement evidence, and quality expectations
- Review domain and workspace assignments as organizational ownership changes
Endorsement
Fabric provides three endorsement badges to signal trust in items:
Promoted
Workspace members can promote artifacts to indicate they're ready for broader use. A lightweight signal that says "this is reliable."
Certified
Only designated reviewers can certify artifacts. It means the artifact meets organizational quality and governance standards.
Master data
Marks an item as the authoritative, single source of truth for a core business entity (customer, product, employee). Applied by designated reviewers, like certification.
Establish an evidence-based certification process: define eligible item types, required ownership and documentation, quality and freshness expectations, security review, reviewer responsibilities, and expiration or recertification rules. Certify items because they meet the standard—not simply because they are in a Gold layer or production workspace.
Sensitivity Labels
Microsoft Information Protection sensitivity labels classify Fabric items and can participate in downstream inheritance, export protection, DLP evaluation, and label-based protection policies. Behavior depends on the item type, tenant configuration, label permissions, and how the label was applied.
- Automatically inherited labels do not overwrite manually applied labels, and less restrictive labels do not replace more restrictive labels
- Downstream propagation can require user consent or operate automatically, depending on tenant settings and the supported relationship
- Supported export paths can carry the label and its protection outside Fabric
- Purview protection policies can restrict access to supported labeled Fabric items; review their scope and limitations before rollout
Data Quality Accountability
Keep quality ownership close to the domain and data product teams that understand the data. Use Fabric engineering controls to prevent, record, and communicate quality failures, while the catalog supplies ownership, lineage, endorsement, and discovery context.
- Implement data quality rules in notebooks (Great Expectations, custom Spark checks)
- Use Delta Lake constraints (NOT NULL, CHECK) for schema-level enforcement
- Set up monitoring and alerting for data freshness, completeness, and accuracy
- Publish quality status, freshness expectations, known limitations, and owner contacts with critical data assets
- Make quality and operational evidence part of promotion, certification, and recertification decisions
Governance and Security Handoff
Turning governance decisions into enforceable Fabric access, protection, and monitoring controls.
Governance defines who owns data, who may approve access, what trust and classification mean, and how often controls are reviewed. The Security implementation applies those decisions through identity, workspace and item permissions, OneLake Security, information protection, network controls, and auditing.
🔐 Identity & Workspace
Use Entra groups, least-privilege workspace roles, workload identities, and periodic access reviews.
🛡️ Item & Data Policies
Use item permissions and the appropriate OneLake, SQL, semantic-model, or engine-specific object-, row-, and column-level controls.
🏷️ Information Protection
Use sensitivity labels, protection policies, DLP, supported export protection, and compliance workflows.
📊 Review & Evidence
Use OneLake Catalog Secure, audit logs, access reviews, and operational evidence to verify that decisions remain effective.
Explore the full layered security model with interactive diagrams, code examples, decision matrices, and a hardening checklist → Security Deep Dive →
Governance-First Assessment
Assess your organization's governance maturity across domains, development process, security, and workspace design — then get tailored recommendations grounded in Microsoft's official best practices.
Answer 12 questions across 4 categories. You'll receive a governance maturity score with per-category breakdowns and actionable recommendations for building a governance-first Fabric environment.
1. How are business domains defined in your organization?
2. Do domain owners have accountability for data quality and access?
3. How do teams discover and request access to data from other domains?
4. How do you manage changes to Fabric artifacts (notebooks, pipelines, reports)?
5. Do you have separate environments (Dev / Test / Prod)?
6. How are deployments promoted across environments?
7. How are workspace roles assigned?
8. Do you enforce data-level security at the correct layer?
9. Is information protection governed as an operating process?
10. How is your workspace structure organized?
11. How do you manage capacity assignment for workspaces?
12. Do you use Fabric domains to logically group workspaces?
Building a Governance-First Fabric Environment
A practical blueprint for designing your Fabric estate with governance, security, and access control from day one — based on official Microsoft best practices.
Don't retrofit governance after deployment. Design your Fabric environment with domains, security, workspace structure, and development lifecycle defined upfront. This avoids the costly cycle of organic sprawl → audit failures → forced refactoring.
🏛️ Domain Strategy & Ownership
Organize your Fabric estate around business domains — not technical teams or projects. Each domain should have clear ownership and delegated governance authority. Note that domains are an organizational and discoverability construct with delegated settings; assigning a workspace to a domain does not by itself change item visibility or access.
Define Domains & Subdomains
Map domains to major business units (Finance, Sales, HR, Marketing). Use subdomains to keep categories manageable (e.g., Sales → Domestic, International). Assign a domain admin with delegated control over domain policies.
Data Stewardship Model
Appoint data stewards per domain responsible for quality, access requests, and metadata curation. Stewards work with the domain admin but focus on hands-on data governance — ensuring datasets are documented, endorsed, and accurate.
Discovery via OneLake Catalog
Use Explore for discovery, Govern for posture insights and recommended actions, and Secure for centralized workspace and OneLake-role administration. Use endorsement (Promoted / Certified / Master data) to communicate trust.
📐 Workspace Topology
Workspaces are both a security boundary and an operational boundary in Fabric. Design them intentionally before creating any content.
Environment Separation
Create Dev / Test / Prod workspaces per domain or data product. Example: Finance-Dev, Finance-Test, Finance-Prod. Never develop directly in production workspaces.
Naming Conventions
Enforce a consistent naming standard: [Domain]-[Product]-[Env]. Examples: Sales-Analytics-Prod, HR-DataLake-Dev. This enables at-a-glance identification and automated governance policies.
Capacity Assignment
Assign workspaces to capacities based on criticality. Production workloads on Fabric/Premium capacities for SLA guarantees. Development/test on smaller or trial capacities. Monitor utilization via the admin monitoring workspace.
🔐 Security Layering
Fabric implements defense-in-depth with five security layers. A governance-first environment configures all layers before exposing data to users.
| Layer | Mechanism | Governance-First Action |
|---|---|---|
| 1. Identity | Entra ID, Conditional Access | Enforce MFA, restrict access by location/device via conditional access policies |
| 2. Workspace | Workspace Roles (Admin/Member/Contributor/Viewer) | Assign via Entra ID security groups, default to Viewer, elevate only with justification |
| 3. Item | Item-level permissions, sharing | Grant per-item read/reshare only for cross-domain sharing scenarios |
| 4. Data | OneLake Security, SQL security, semantic-model security, engine controls | Map every access path to the correct object-, row-, and column-level policy; validate behavior across the engines users actually query |
| 5. Network | Private endpoints, managed VNets, trusted workspace access | Enable private endpoints for sensitive workloads; use managed VNets for Spark outbound traffic control |
□ Enable Entra Conditional Access | □ Create security groups per workspace role | □ Define data policies for each query path | □ Configure sensitivity labels and inheritance settings | □ Enable audit logs | □ Set an access-review cadence
📚 Official Docs
Security Overview ↗ OneLake Data Access Roles ↗ Permission Model ↗ Secure Your Data ↗🚀 Development Lifecycle
A governed development lifecycle ensures changes are tracked, reviewed, tested, and promoted safely — not edited directly in production.
Git Integration
Connect all workspaces to Azure DevOps or GitHub repositories. Use branch policies requiring pull requests and at least one reviewer. Map branches to environments: feature/* → Dev, main → Prod.
Deployment Pipelines
Use Fabric's native deployment pipelines to promote artifacts across Dev → Test → Prod stages. Configure approval gates so production deployments require sign-off from domain owners or data stewards.
Environment Configuration
Use variable libraries to manage environment-specific settings (connection strings, capacity, parameters) without manual changes. Automate deployment orchestration via GitHub Actions or Azure Pipelines.
Microsoft offers two CI/CD patterns: Git-centric (each environment maps to a branch; deploy by merging) and Pipeline-centric (single branch linked to Dev; deploy via Fabric deployment pipelines). Choose based on your team's maturity. Pipeline-centric is simpler to start; Git-centric offers more flexibility for large teams.