The components of a BI governance framework — certified content standards, publishing governance, metric definitions, access control, and change management — and how to implement governance that scales with a growing analytics programme without killing the speed teams need to work.
Most BI governance frameworks fail for the same reason most governance frameworks fail: they start with process, not with the problem governance is supposed to solve. The problem is specific: in growing organisations, the analytics environment degrades over time. Metric definitions diverge across teams. Certified dashboards get quietly modified. New workbooks get published without review and trusted without verification. Users lose confidence in the numbers. The data team spends increasing time investigating "the data is wrong" complaints that turn out to be definition disagreements.
Governance exists to prevent this degradation and restore confidence when it occurs. A governance framework that solves this problem at an acceptable cost to team speed is effective. One that creates bureaucratic overhead without preventing the underlying failure modes is not.
The Components of BI Governance
### Certified Content Standards
Certification is the cornerstone of BI governance. A certified workbook or data source carries an explicit signal: this content is reviewed, validated, meets quality standards, and is maintained by a named owner. Uncertified content is exploratory or provisional.
The certification standard defines what a workbook or data source must satisfy to be promoted:
- **Data source:** Connects to a certified, documented data source (not a direct database connection or personal data file)
- **Calculations:** Business logic is documented with field descriptions; complex calculations have explanations
- **Design:** Meets the organisation's visual and UX standards (branding, colour, tooltip standards)
- **Performance:** Loads within defined response time thresholds
- **Testing:** Outputs have been verified against known baselines or source systems
- **Owner:** A named owner is responsible for maintaining the content and responding to quality issues
The certification process is a review workflow — typically a senior analytics engineer or BI lead reviews against the checklist before promoting content to the certified tier.
Without certification, governance has no teeth. Any workbook can be published, any number can appear correct, and users have no signal for what to trust. With certification, users know what the certified tier means and what the standard tier means.
### Publishing Governance
Publishing governance controls who can publish what, and where. In Tableau, this means project-level permissions: who can publish to the Certified project, who can publish to the Standard project, who can publish to personal projects.
The typical model:
- **Certified project:** Analytics engineers and BI leads only. New content requires the certification checklist to pass.
- **Standard project:** All analytics team members can publish. No certification required, but content is labelled as standard (not certified).
- **Sandbox/personal projects:** Individual analysts can publish freely for exploration and prototyping.
Publishing governance prevents the failure mode where every analyst publishes directly to the production project, where Certified content is indistinguishable from a quick one-off made yesterday.
The governance should not eliminate analyst ability to create and share content — it should create a clear tiering system that preserves agility while protecting the certified tier's integrity.
### Metric Definition Governance
Metric definition governance is where most organisations struggle. The problem: different teams define the same metric differently. Sales defines "revenue" as contract value. Finance defines it as recognised revenue. Marketing defines it as pipeline value. All three call it "revenue" in their dashboards. Users see three different numbers for "revenue" and stop trusting any of them.
The solution is a business glossary — a documented register of canonical metric definitions, who owns each definition, and where the authoritative calculation lives. The canonical definition is implemented once, in the data transformation layer (dbt models, certified data sources), and all downstream content references the canonical definition rather than re-deriving it.
The governance process for metric definitions:
1. New metric request goes through a definition review (what exactly is this measuring? who are the stakeholders? are there existing similar metrics?)
2. If approved, the metric is implemented in the transformation layer with full documentation
3. The definition is registered in the business glossary
4. Content that references the metric uses the certified data source rather than a custom calculation
This requires a change management process for definition changes: if the definition of "Active Customer" changes, all downstream content using that definition needs to be reviewed and the change communicated to users before it takes effect.
### Access Control and User Management
Access governance ensures that users see only the data they are authorised to see, that access is granted based on documented business need rather than informal request, and that access is reviewed and revoked when roles change.
Access governance has two layers in Tableau:
**Content access:** Who can see which workbooks and projects. Managed through Tableau groups and project permissions. The governance process defines which groups have access to which projects, how group membership is managed (ideally via SSO/SAML group sync to avoid manual management), and how new access requests are processed and approved.
**Data access:** Whether the underlying data source enforces row-level security (RLS). Certified data sources serving sensitive data should use RLS to restrict which rows a given user can query — not just which workbooks they can open. Row-level security is implemented at the data source level, not the workbook level, ensuring it applies regardless of how the data source is accessed.
The quarterly access review is the operational governance process: review which users have access to what, identify accounts of former employees, identify over-provisioned access that no longer reflects current roles, and produce an audit trail.
### Change Management
Change management governance covers two types of change:
**Planned changes to certified content:** When a certified workbook needs to be updated (new business requirement, underlying data model change), the change goes through a review process. For minor changes (adding a filter, fixing a calculation label), a lightweight self-review against the certification checklist may be sufficient. For significant changes (restructuring the data model, changing a metric definition), peer review is required before publishing to the certified project.
**Upstream changes with downstream impact:** When a data model change (dbt model update, source system schema change) affects certified content, all downstream content needs to be identified, tested against the change, and updated before the upstream change is deployed. Impact analysis — using Tableau's lineage features or the Metadata API — identifies what content is affected. The change process ensures affected content is updated and validated before deployment.
Without change management, upstream changes silently break certified dashboards. Users see wrong numbers, the data team investigates, and the root cause turns out to be an upstream model change that was deployed without checking downstream impact.
Governance That Scales
The failure mode of governance at scale is bureaucratic overhead that teams circumvent. If the certification process takes three weeks, analysts will publish directly to the production project rather than wait. If the metric definition process requires six approvals, teams will define the metric themselves and never register it in the glossary.
Governance that scales is:
**Automated where possible:** Use dbt tests to enforce data quality standards automatically. Use CI/CD pipelines to block deployments that fail tests. Automate the access review using the Tableau REST API rather than manually exporting user lists. Automated enforcement at lower cost than manual review.
**Proportional to risk:** Certified content serving C-suite dashboards needs rigorous review. Exploratory content in a sandbox project needs none. Apply governance effort proportionally to the stakes.
**Fast for low-risk changes:** A certification process that takes two business days for a minor change is a process teams will use. One that takes two weeks is a process teams will work around.
**Visible to stakeholders:** Monthly or quarterly governance health metrics — certification rate, access review completion, open quality incidents, metric definition coverage — give leadership visibility into governance programme health and demonstrate the programme's value.
Starting a Governance Programme
Most organisations attempting BI governance from scratch make the mistake of trying to govern everything at once. The right approach:
1. **Identify the highest-risk content first.** What are the five dashboards that senior leadership and financial reporting depend on? Start governance there.
2. **Define the certified standard.** What does a workbook have to satisfy to be certified? Write the checklist. It does not need to be perfect on day one.
3. **Certify the existing high-risk content.** Review each of the five critical dashboards against the checklist. Fix what fails. Certify what passes.
4. **Establish the publishing workflow.** Set up the Certified project with restricted publishing permissions. Train the team on the tiers.
5. **Add metric governance for the most contested metrics.** Pick the three metrics that cause the most definition disputes and document canonical definitions. Implement them in the transformation layer.
6. **Expand incrementally.** Add more content to the certification programme, add more metrics to the glossary, extend access governance — but incrementally, at a pace the team can maintain.
Our managed BI services include BI governance framework design and implementation — contact us to discuss governance for your analytics environment.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →