I have watched three governance programs die the same way: a 60-page policy, a council that met twice, a tool nobody had time to populate. Governance in a mid-size company has to be sized for the team that will actually run it, which is usually one or two people with other jobs. The program below is what I have seen survive: four controls that run automatically and one meeting that takes an hour a month.
What governance is for
The DAMA Data Management Body of Knowledge frames governance as the function that gives an organization control over its data so it can get value from it, spanning quality, security, metadata and the other data-management disciplines [1]. For a mid-size company that translates into three questions anyone should be able to answer about any number on any report: who is allowed to see it, where it came from, and whether it is right. Everything below serves one of those three.
Control 1: dynamic row-level security
Row-level security in Power BI restricts data for users with the Viewer role through DAX filter rules defined on roles in the semantic model; workspace admins, members and contributors are not filtered, and membership is managed in the service [2]. Static roles (one per region) do not scale. The pattern that does is a security table mapped to the user’s identity:
-- SecurityRegionMap: one row per (UserEmail, RegionKey)
-- Role "Regional" filter on SecurityRegionMap:
[UserEmail] = USERPRINCIPALNAME()
-- Relationship: SecurityRegionMap[RegionKey] -> DimRegion[RegionKey]
-- with "Apply security filter in both directions" so the fact is filtered through DimRegion.
Three rules. Keep the mapping table in the warehouse, loaded from the HR or CRM system, so access changes with the org chart rather than with a ticket. Test as a specific viewer, not as yourself; Microsoft notes that “Test as role” does not reproduce every identity scenario, such as B2B guests [2]. And remember that workspace members bypass RLS: the viewer role is the only place it applies, so keep the workspace membership list short and reviewed.
Add object-level security for columns that should never appear for some audiences (cost, salary, a document fee), so the column is absent rather than blank. Both RLS and OLS belong in the model’s source-controlled definition, not in a report.
Control 2: lineage you can show in a meeting
“Where does this number come from” should have an answer in under a minute. Three sources of lineage already exist in most Microsoft estates and need only to be used: the Power BI lineage view in the service, which shows data sources, semantic models and reports in a workspace; the model DAG that dbt generates if you transform with dbt [3]; and the audit table your pipelines write (see pipelines that survive change). Fabric’s governance features add discovery and endorsement (promoted, certified) so users can tell a governed model from a personal one [4]. The governance act is simply to certify the models that pass the tests below and to publish the rule that reports should be built on certified models only.
Control 3: quality tests that run on every load
Quality is not a quarterly audit; it is an assertion that runs every time data moves. The minimum set, per gold table:
| Test | What it catches | Example |
|---|---|---|
| Uniqueness at the grain | Duplicated loads, bad joins | order_id + line_no is unique in fct_order_line |
| Not-null foreign keys | Orphaned facts, late-arriving dimensions | customer_key is never null |
| Referential integrity | Keys with no dimension row | every customer_key exists in dim_customer |
| Accepted values | New codes the model does not handle | status in (open, invoiced, cancelled) |
| Reconciliation | Everything else | sum(revenue) in gold equals the GL control total within tolerance |
| Freshness | Silent stale data | max(load_date) within 26 hours |
dbt expresses the first four as one line each in YAML [3]; a stored procedure or a notebook does the same in T-SQL or Python if you are not using dbt. The important property is that a failing test stops the load from reaching gold and notifies someone, rather than writing a log line nobody reads.
Control 4: the data dictionary that writes itself
Separate wikis go stale. Put the description on the object: a description on every table, column and measure in the semantic model (TMDL makes this reviewable text [5]) and in the dbt YAML, then generate the catalog from those sources. The same descriptions are what Copilot and data agents read to answer questions, so this control pays twice (see what generative AI changes in BI).
The monthly hour
One meeting, one hour, one page. The data owner and one business sponsor review:
- Access: who was added to or removed from workspace roles and the security mapping table this month; any member who should be a viewer.
- Quality: test failures by table, with the fix and the root cause (source change, pipeline bug, business rule gap).
- Definitions: any measure added or changed, with its description; any two reports that disagreed.
- Freshness and reliability: loads that failed or ran late, and what the business saw.
- One decision: the single governance change for next month. Not five.
The page is produced by the audit tables and the test results; nobody writes it by hand. That is the difference between a governance program that lasts and one that becomes a document.
Security beyond the model
RLS protects what the report shows; it does not protect the data at rest or the credentials that move it. The controls that come from running production data platforms through incidents are unglamorous: least-privilege service accounts for pipelines, secrets in a vault rather than in connection strings, encryption for backups, tested restores, and an inventory of every place the data is copied (exports, shared drives, personal workspaces). A governance program that cannot say where the data is cannot say who can see it.
Starting next week
- Pick the one semantic model that matters most. Add dynamic RLS from a mapping table and test it as a viewer.
- Add the six tests above to its gold tables and make a failure stop the load.
- Describe every visible measure. Certify the model.
- Put the first monthly hour on the calendar with a sponsor who will attend.
Four controls, one hour a month, sized for the team you have. That is governance a mid-size company can keep.
References
- DAMA International, “DAMA Data Management Body of Knowledge (DAMA-DMBOK),” dama.org/cpages/body-of-knowledge (accessed 9 Oct 2026).
- Microsoft Learn, “Row-level security (RLS) with Power BI,” learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security (accessed 9 Oct 2026).
- dbt Labs, “Add data tests to your DAG,” docs.getdbt.com/docs/build/data-tests (accessed 9 Oct 2026).
- Microsoft Learn, “Governance and compliance in Microsoft Fabric,” learn.microsoft.com/en-us/fabric/governance/governance-compliance-overview (accessed 9 Oct 2026).
- Microsoft Learn, “Tabular Model Definition Language (TMDL),” learn.microsoft.com/en-us/analysis-services/tmdl/tmdl-overview (accessed 9 Oct 2026).
