Microsoft Fabric Security and Governance Checklist

Security and governance in Microsoft Fabric aren't optional extras - they're the foundation that determines whether your data platform is trustworthy enough for production use. We've seen too many Fabric implementations rush to build pipelines and dashboards while leaving security as a "we'll sort it out later" task. Later never comes, and you end up with a platform where everyone has admin access and nobody knows who can see what.

This post is a practical checklist based on what we configure for every Fabric implementation we deliver. It's not exhaustive (Microsoft's documentation covers every edge case), but it covers the 80% that matters most for mid-market Australian organisations.

Workspace Security

Fabric workspaces are the primary unit of access control. Getting workspace design right is the first step in a secure implementation.

Workspace Design Checklist

• Separate workspaces by environment - At minimum, have separate workspaces for Development, Test, and Production. Never develop directly in the production workspace.

• Separate workspaces by data sensitivity - If you have datasets with different classification levels (e.g., general business data vs. HR/payroll data vs. customer PII), use separate workspaces. This makes it easier to apply different access policies.

• Use a consistent naming convention - We recommend: [Environment]-[Domain]-[Type]. For example: Prod-Finance-Warehouse, Dev-Sales-Lakehouse, Prod-HR-Reports. This makes it obvious what each workspace contains and who should have access.

• Assign workspaces to a Fabric capacity - Every workspace should be assigned to an appropriate capacity. Development workspaces can share a smaller capacity; production workspaces need dedicated capacity with appropriate sizing.

Workspace Role Assignments

Fabric has four workspace roles, and using them correctly matters:

Role	What they can do	Who should have it
Admin	Full control including deleting the workspace	Data platform team lead, 1-2 senior engineers max
Member	Create, edit, and delete content; share items; manage permissions on items they own	Data engineers and developers actively building in this workspace
Contributor	Create and edit content but cannot share or manage permissions	Analysts who create reports but shouldn't control access
Viewer	View content only	Business users consuming reports and dashboards

• Apply least privilege - Most users should be Viewers. Contributors and Members should be limited to people who actively develop content. Admins should be 1-2 people maximum per workspace.

• Use Entra ID security groups - Don't assign workspace roles to individual users. Create security groups in Microsoft Entra ID (e.g., SG-Fabric-Finance-Viewers, SG-Fabric-Finance-Contributors) and assign roles to groups. This scales better and is easier to audit.

• Review workspace membership quarterly - People change roles, leave the company, or no longer need access. Set a calendar reminder to review workspace membership every 90 days.

Data Access and Protection

Workspace-level security controls who can access the workspace, but you also need to control what data users can see within the workspace.

Row-Level Security (RLS)

• Implement RLS for multi-tenant data - If your reports serve multiple business units, regions, or customer segments, configure row-level security so users only see data relevant to their scope. This applies to both Power BI semantic models and Fabric Warehouse views.

• Test RLS with the "View as" feature - After configuring RLS, use Power BI's "View as" capability to verify that each role sees only the correct data. Don't assume it works - validate it.

• Document RLS rules - Write down which roles map to which data filters. This documentation is essential for auditing and for onboarding new team members.

Column-Level Security

• Identify sensitive columns - Salary, personal identification numbers, health records, financial account numbers, and other sensitive fields should be protected.

• Use Object-Level Security (OLS) in Power BI - For sensitive columns in Power BI semantic models, configure OLS to hide columns from users who don't need them.

• Control column access in Fabric Warehouse - Use T-SQL GRANT/DENY on specific columns in the Warehouse when you need database-level column protection.

Data Classification and Sensitivity Labels

• Apply Microsoft Purview sensitivity labels - If your organisation uses Microsoft Purview, apply sensitivity labels (e.g., Confidential, Internal, Public) to Fabric items. This carries the classification through to Power BI reports and exports.

• Configure label inheritance - Set up label inheritance so that downstream items (reports built on a labelled dataset) automatically inherit the sensitivity label from the source data.

• Restrict export for sensitive data - For items labelled Confidential or above, configure policies that prevent users from exporting data to CSV, Excel, or PDF. This prevents sensitive data from leaving the governed environment.

Data Encryption

• Verify encryption at rest - Fabric encrypts data at rest by default using Microsoft-managed keys. If your organisation requires customer-managed keys (CMK) for compliance reasons, verify that Fabric supports this for your specific workloads.

• Verify encryption in transit - All data movement within Fabric and between Fabric and client applications uses TLS encryption by default. Confirm this meets your compliance requirements.

• Check data residency - For Australian organisations with data sovereignty requirements, verify that your Fabric capacity is deployed in the Australia East or Australia Southeast region. OneLake data should reside in the same region as your capacity.

Identity and Authentication

Entra ID Configuration

• Enforce multi-factor authentication (MFA) - All users accessing Fabric should have MFA enabled through Entra ID conditional access policies. No exceptions.

• Configure conditional access policies - Beyond MFA, consider policies that restrict Fabric access to managed devices, specific IP ranges (office network and approved VPN), or specific geographic locations.

• Disable personal Microsoft account access - Ensure that only organisational Entra ID accounts can access your Fabric tenant. Personal Microsoft accounts should be blocked.

• Review Entra ID sign-in logs - Regularly check sign-in logs for unusual patterns - logins from unexpected locations, failed authentication attempts, or sign-ins outside business hours.

Service Principal and API Access

• Use service principals for automated access - If you have applications or scripts that access Fabric programmatically, use Entra ID service principals with specific scopes rather than user accounts.

• Rotate service principal secrets - Set a schedule (90 days maximum) for rotating service principal client secrets. Use Azure Key Vault to store secrets.

• Audit API access - Monitor which service principals access Fabric and what operations they perform. Unusual API activity can indicate compromised credentials.

Tenant-Level Governance

Fabric Admin Portal Settings

The Fabric admin portal has dozens of tenant-level settings that control what users can do. Here are the ones we always review:

• Restrict workspace creation - By default, anyone in your tenant can create Fabric workspaces. Restrict this to specific security groups to prevent workspace sprawl.

• Control export and sharing - Decide whether users can export data from Power BI reports (to Excel, CSV, PDF) and share content externally. For most organisations, we recommend restricting external sharing and allowing exports only for non-sensitive data.

• Manage embed codes - Control whether users can publish reports publicly via embed codes. For most mid-market companies, this should be restricted or disabled.

• Control Copilot access - If your organisation uses Fabric Copilot features, review which workspaces and users have access. Copilot generates queries based on your data, so ensure users accessing Copilot have appropriate data clearance.

• Enable audit logging - Ensure that the unified audit log is enabled for Fabric. This captures who did what, when, across all Fabric workloads. Essential for compliance and incident investigation.

• Set up usage metrics - Enable usage metrics so you can track which reports and datasets are actively used. This helps with both governance (identifying stale content) and capacity planning.

Domain and Endorsement

• Configure domains - If your organisation has multiple business units using Fabric, set up domains to group related workspaces. This provides logical separation and allows domain-specific governance policies.

• Use endorsement labels - Fabric supports "Promoted" and "Certified" endorsement labels for data items. Use these to help users identify trusted, production-quality data sources. Only data stewards should be able to certify items.

Data Lineage and Cataloguing

• Enable and review data lineage - Fabric tracks lineage from source through transformation to report automatically. Review lineage regularly to ensure data flows are as expected and there are no unexpected connections.

• Maintain a data dictionary - Document what each table, column, and metric means. Fabric doesn't do this automatically - you need to maintain descriptions in your semantic models and warehouse tables.

• Integrate with Microsoft Purview - If your organisation uses Microsoft Purview for broader data governance, connect it to Fabric. This gives you a unified view of data assets across Fabric and other data sources.

• Tag data owners - Every dataset and workspace should have a clearly identified data owner who is responsible for data quality, access decisions, and compliance.

Compliance Considerations for Australian Organisations

Privacy Act and APPs

• Identify personal information - Audit your Fabric data assets for personal information as defined under the Australian Privacy Act. This includes names, addresses, email addresses, phone numbers, financial information, and health information.

• Implement access controls on PI - Personal information should be accessible only to users with a legitimate business need. Use workspace separation, RLS, and column-level security as appropriate.

• Configure data retention - The Privacy Act requires that personal information not be retained longer than necessary. Implement retention policies on Fabric items containing personal data.

• Plan for access requests - Under the APPs, individuals can request access to their personal information. Ensure you can locate and extract an individual's data from your Fabric environment if requested.

Industry-Specific Compliance

• Financial services (APRA CPS 234) - If you're in financial services, ensure your Fabric implementation aligns with APRA's Information Security standard. This includes specific requirements around access controls, incident management, and testing.

• Healthcare (My Health Records Act) - If you handle health records, additional restrictions apply to data access, storage, and sharing.

• Government (ISM/PSPF) - Government organisations should align Fabric security controls with the Information Security Manual and Protective Security Policy Framework.

Monitoring and Incident Response

• Set up capacity alerts - Configure alerts for when Fabric capacity utilisation exceeds 80%. This gives you time to investigate and scale before users are affected by throttling.

• Monitor unusual data access - Use audit logs to identify unusual patterns - users accessing data they don't normally access, large data exports, or access at unusual times.

• Create an incident response plan - Document what to do if you discover a data breach, unauthorised access, or compliance violation in your Fabric environment. Include escalation contacts, containment steps, and notification requirements.

• Test your security regularly - At least annually, conduct a security review of your Fabric environment. Check that access controls are working as expected, review audit logs, and validate that governance policies are being followed.

• Keep up with Fabric security updates - Microsoft releases new security features and changes regularly. Assign someone to track the Fabric roadmap and evaluate new security capabilities as they become available.

A Prioritised Implementation Order

If you're setting up governance for a new Fabric environment, here's the order we recommend:

1. Week 1: Workspace design, role assignments with Entra ID groups, MFA enforcement
2. Week 2: Tenant admin settings (restrict workspace creation, control exports, enable auditing)
3. Week 3: Data protection (sensitivity labels, RLS for key datasets, column-level security for sensitive fields)
4. Week 4: Monitoring setup (capacity alerts, audit log review process, usage metrics)
5. Ongoing: Data cataloguing, lineage reviews, quarterly access reviews, compliance validation

Don't try to do everything at once. Get the foundational controls in place first, then layer on more advanced governance over time.

How Team 400 Helps with Fabric Governance

Security and governance are built into every Microsoft Fabric engagement we deliver. We don't treat it as a separate workstream - it's part of the platform foundation we set up in the first week.

For organisations that need a dedicated governance effort, we also run standalone security and governance assessments where we:

• Audit your existing Fabric environment against this checklist
• Identify gaps and risks
• Prioritise remediation based on business impact
• Implement the highest-priority controls
• Document the governance model for ongoing maintenance

We often combine this with Power BI governance work, since the two are closely connected, and broader AI governance for organisations building AI capabilities on top of Fabric data.

If your Fabric environment needs a security health check or you're planning a new implementation and want to get governance right from the start, contact our team. We'll help you build a platform your security and compliance teams can trust.

Learn more about our services or explore how we approach data platform architecture with security built in.