1. Executive Summary

Problem : Data governance initiatives consistently stall when accountability is concentrated in the data team while the rest of the organization treats it as someone else's problem.

Recommended approach: Treat governance as a shared operating model — one where business domains own their data assets and the data platform team provides the enabling infrastructure.

Where it fits: Any enterprise running Snowflake as a central data platform, particularly those experiencing trust erosion, repeated audit findings, or poorly adopted self-service analytics.

Key outcomes: Improved data trust, clear ownership trails, defensible audit posture, and analytics workloads that business teams actually rely on.

What the reader can implement: A governance model grounded in role-based access control (RBAC), domain data ownership, metadata-driven discoverability, and operational monitoring — achievable within the Snowflake native feature set for most organizations, with external cataloguing tools (Alation, Collibra, Atlan) warranted where enterprise-scale metadata management or cross-platform lineage is required.

2. Background

Most organizations that have invested in a modern data platform eventually arrive at the same uncomfortable realization: the platform works, but the data does not.

Snowflake is provisioned, pipelines are running, dashboards are populated — and yet business users question the numbers, reports contradict each other, and the data team spends more time firefighting trust issues than building new capability.

The root cause is rarely technical. It is structural. Governance was treated as a project milestone — a checklist of policies, permissions, and cataloguing tasks — rather than as an ongoing operating model shared between the data team and the business.

When governance is handed entirely to a central data team, the business retains none of the accountability that makes governance work.

This blog examines why that pattern fails, and how organizations can reframe governance as a business conversation one that uses Snowflake's native capabilities to make shared accountability practical rather than aspirational.

3. Problem

3.1 Symptoms

• Business teams reject data products because they cannot trace where a figure came from or who certified it as reliable.
• The data team is the sole point of contact for access requests, quality complaints, and definition disputes — creating a bottleneck that scales with every new consumer.
• Audit and compliance reviews surface orphaned tables, undefined data owners, and access grants that no one can explain — usually three months before a regulatory deadline.
• Different departments maintain their own spreadsheet extracts because they do not trust the shared platform, defeating the purpose of centralization.
• Data quality issues discovered in production are resolved without a clear process, meaning the same issue often recurs in a different pipeline.

3.2 Impact

The operational consequence is a data team permanently stuck in reactive mode.

Every sprint is interrupted by access requests, pipeline investigations, and definition arbitration. The business consequence is slower, lower-confidence decisions.

When finance and operations are working from different numbers, alignment meetings replace insight discussions.

Over time, trust in the data platform erodes to the point where senior stakeholders commission parallel data efforts — compounding the very problem the platform was meant to solve.

4. Requirements & Assumptions

4.1 Data & SLA

• Data scope: Enterprise-wide — multiple source domains including finance, operations, customer, and product data.
• Freshness model: Mix of daily batch and near-event ingestion, depending on domain criticality.
• Governance model is SLA-aware but not dependent on latency tier.
• Environments: Production, UAT, and development environments with distinct access boundaries enforced through Snowflake account-level or database-level separation.

4.2 Security & Compliance

• Data sensitivity: Likely includes PII and commercially sensitive information; governance model must accommodate column-level masking and row-level security policies.
• Access model: Role-based access control (RBAC) enforced natively in Snowflake, integrated with the organisation's identity provider for SSO.
• Service accounts managed separately from interactive user roles.
• Compliance posture: Designed to support internal audit requirements, GDPR or similar data protection obligations, and any sector-specific regulation the organization faces.

4.3 Organizational Assumption (Critical)

• Assumed tooling: Snowflake as the central platform; dbt or equivalent for transformation; a metadata catalogue (Alation, Collibra, or Snowflake's native object tagging); an orchestration layer such as Airflow or Prefect.
• Key constraints: Governance processes must not impose meaningful latency on existing pipelines.
• The model should be adoptable by business domain teams without requiring SQL expertise.
• Cataloguing must not depend on manual curation alone.

5. Recommended Architecture

5.1 High-Level Flow

The architecture is best understood as a layered responsibility model, not just a data pipeline.

Each layer has a designated owner — and that ownership is as much a governance artefact as the data itself.

The key architectural principle is that governance controls — access policies, quality rules, metadata tags — are applied at the governed data products layer, not at the consumption layer.

This means that regardless of how data is accessed (BI tool, notebook, application), the same rules are enforced.

Consumers cannot bypass policy by choosing a different access mechanism.

5.2 Architecture Diagram

5.3 Options

• Option A — Centralized governance, federated ownership: A central governance council sets policy; individual business domains appoint data stewards who are accountable for their domain's assets. Best for organizations with a mature central data function.
• Option B — Federated governance, shared platform: Each business domain manages its own data products with agreed-upon standards, publishing to a shared consumption layer. Best for organizations with strong domain autonomy and limited central data resources.
• Selection guide: Most enterprises begin with Option A to establish baseline standards, then progressively shift towards Option B as domain capability matures. The Snowflake architecture is identical for both; what changes is the organizational ownership model layered on top.

5.4 Tooling Choice: Native Snowflake, Snowflake Horizon, or Third-Party Catalogue?

Snowflake Horizon is Snowflake’s native governance layer, introduced to consolidate capabilities that previously required separate tooling or manual configuration.

It surfaces classification, data quality, lineage, access intelligence, and privacy controls through a unified interface within the Snowflake platform.

For organizations that are Snowflake-centric and do not have cross-platform data assets requiring a single governance pane, Horizon represents a materially stronger native option than object tagging and ACCESS_HISTORY alone, and should be evaluated before defaulting to a third-party catalogue purchase.

The decision between Horizon and a specialist tool such as Alation, Collibra, or Atlan comes down to three questions: (1) Does your data estate extend beyond Snowflake to databases, SaaS sources, or cloud object stores that also need governed cataloguing?

If yes, a third-party tool with broader connectors is warranted.

(2) Do your business stakeholders need a non-SQL, consumer-grade catalogue experience with business glossary, stewardship workflows, and social curation features?

Horizon’s interface is platform-native and technically oriented; enterprise catalogue tools are built for a broader stakeholder audience.

(3) Do you have existing catalogue investments or contractual commitments?

If so, evaluate Horizon’s API and connector surface before displacing existing tooling.

For most greenfield Snowflake deployments, the recommended starting position is: use Horizon for governance enforcement (classification, masking, lineage, access intelligence) and assess third-party cataloguing needs at the six-month mark once actual consumption patterns are understood.

6. Implementation

Implementation of a shared governance model has four dimensions: structural (who owns what), technical (how access and quality are enforced), operational (how stewardship is practised day-to-day), and cultural (how the organization learns to treat data as a shared asset).

This section covers the structural and technical dimensions at a pattern level.

6.1 Setup

Snowflake Objects

• Database and schema structure should reflect business domains, not technical pipeline stages. A customer domain database with raw, conformed, and product schemas is more governable than a single monolithic warehouse with no domain boundaries.
• Warehouses should be separated by workload type — ingestion, transformation, and consumption — to enable cost attribution and access control at the compute level.
• Roles should be designed in a hierarchy: SYSADMIN > domain-level functional roles > user roles. Every role should have a documented owner. Critically, governance objects — masking policies, row access policies, and object tags — must be owned by a dedicated POLICY_ADMIN role that sits outside the SYSADMIN hierarchy.
• Allowing SYSADMIN to own policy objects is a common design error that creates privilege escalation risk and fails Snowflake security reviews; the separation ensures that compute administrators cannot unilaterally alter data access controls.

External Objects

Secrets and credentials for external sources should be managed in a secrets manager (e.g., AWS Secrets Manager, Azure Key Vault) and referenced by pipeline tooling, not stored in Snowflake directly.

If external stages (S3, ADLS) are used for data landing, storage integration objects in Snowflake should be created per environment, not shared across prod and non-prod.

6.2 Core Build Steps

1. Define domain ownership map: Before any technical work, document which business team owns each data domain. This map becomes the source of truth for role assignment and steward accountability.
2. Implement RBAC aligned to domains: Create functional roles (e.g., FINANCE_READ, CUSTOMER_WRITE) that correspond to business access patterns rather than individual user names. User-to-role assignment is managed through the identity provider.
3. Apply object tagging for classification: Use Snowflake object tags to mark tables and columns with sensitivity level (e.g., PII, INTERNAL, PUBLIC) and data owner. These tags drive dynamic masking policies and feed cataloguing tools.
4. Define data quality contracts at the domain boundary: Each data product should have documented expectations — acceptable null rates, referential integrity rules, freshness thresholds. These are enforced as automated checks in the transformation layer.
5. Publish governed data products to a discoverable catalogue: Whether using Snowflake's native object search, a connected cataloguing tool, or a simple internal wiki, consumers need to be able to find certified assets without raising a ticket.
6. Establish a governance council with business representation: A monthly or bi-monthly forum attended by domain stewards, the data platform lead, and a compliance representative. This is where policy decisions are made and ownership disputes are resolved.

6.3 Configuration Defaults

• Access provisioning: Role requests should follow a documented approval flow; avoid granting broad roles temporarily as they rarely get revoked.
• Tagging strategy: Start with two classification axes — sensitivity and domain. Add further dimensions only when they serve a concrete governance need.
• Masking policies: Implement dynamic data masking at the column level for PII fields; the same masking policy can reference the calling role, eliminating the need for separate physical copies of data for different access tiers.
• Data sharing: Use Snowflake Secure Data Sharing for cross-account or cross-business-unit consumption; this avoids data duplication and preserves a single governance boundary.

6.4 Deployment: Governance Objects as Code

Governance objects deployed manually in production are a significant operational risk.

Masking policy and row access policy changes take effect immediately with no built-in rollback mechanism; an incorrectly applied policy can either expose sensitive data or silently break business-critical queries.

All governance objects — masking policies, row access policies, object tags, resource monitors, and role grants — should be version-controlled and deployed through a CI/CD pipeline, subject to the same review and approval process as application code.

Recommended tooling pattern: Use Terraform (with the Snowflake provider) or SchemaChange to manage Snowflake objects declaratively.

Store policy definitions in source control alongside the dbt models they protect.

Promotion gates between dev, UAT, and production environments should require a pull request approval from both the platform team and the domain data steward for any change to a policy governing PII or regulated data.

Before any masking policy change is deployed to production, run a validation query against a non-production environment confirming that the intended roles receive masked output and that permitted roles receive clear data.

6.5 Schema Evolution and the Governed Layer

Source schema changes are one of the most common causes of production incidents in governed data platforms.

When an upstream system adds, renames, or removes a column, the impact cascades through the governed layer: masking policies referencing the affected column become unbound, dbt models referencing the column fail at compile time, and row access policies dependent on the column’s values may silently return incorrect results.

Recommended patterns: Configure dbt with on_schema_change: ‘warn’ or ‘fail’ at the model level so that unexpected upstream column changes surface as pipeline failures rather than silent data drift.

Note: Snowflake Streams do not detect DDL changes — they track DML row-level changes (INSERT, UPDATE, DELETE) only.

To detect schema drift, use one of three proven mechanisms: (1) poll INFORMATION_SCHEMA.COLUMNS on a scheduled Snowflake Task and compare against a baseline snapshot, alerting on any column additions, removals, or type changes;

(2) instrument dbt source freshness tests with dbt-expectations column-level assertions that fail the run when unexpected columns appear;

or (3) configure a Snowflake Alert on QUERY_HISTORY filtering for DDL event_type = ‘ALTER_TABLE’ against monitored source tables, routing the notification to the data engineering Slack channel.

For PII-classified columns specifically, any schema change — including a rename — must go through the governance change request process, since the masking policy association is name-bound and will detach silently on rename without triggering a pipeline error.

7. Validation & Testing

7.1 Data Validation

• Row count consistency: Compare ingested row counts against source system records on a scheduled basis. Unexplained discrepancies should trigger an alert, not a manual investigation.
• Duplicate detection: Primary key uniqueness checks at the conformed layer surface upstream ingestion issues before they reach business consumers.
• Freshness verification: Each governed table should expose a last-updated timestamp. Monitoring systems should alert when a table has not been refreshed within its expected SLA window.
• Referential integrity: Where foreign key relationships exist across domains, periodic reconciliation checks confirm that joins return expected cardinalities.

7.2 Reconciliation

For financially material data, a periodic reconciliation against the authoritative source system should be built into the governance process — not left to the business team to discover at month-end.

The data steward for the relevant domain is accountable for investigating and resolving discrepancies within a defined timeframe.

Reconciliation findings should be logged to a governance tracking artefact so they inform future quality improvement priorities.

7.3 Lineage Pattern: Tracing a Dashboard Metric to Source

The most common governance question from a business buyer is: “If a number on this dashboard is wrong, how quickly can you show me exactly where it came from?”

The answer requires two complementary layers: dbt lineage (compile-time model dependencies) and Snowflake’s OBJECT_DEPENDENCIES view (runtime object-level lineage).

Together they produce a full chain from a BI metric to the raw source table.

The pattern below traces a revenue metric in a Tableau workbook back to its source system.

Step 1 — dbt lineage (compile-time): The dbt manifest.json records model dependencies at build time.

The lineage chain for a revenue metric is visible in the dbt docs UI, or queryable via the compiled manifest:

Tableau workbook (revenue_dashboard)
└─ FINANCE_PROD.reporting.fct_revenue        [dbt model, certified]
   └─ FINANCE_PROD.conformed.int_orders_enriched [dbt model]
      └─ FINANCE_PROD.raw.stg_erp_orders          [source, owner: Finance BU]

Step 2 — OBJECT_DEPENDENCIES (runtime): Snowflake’s OBJECT_DEPENDENCIES view in ACCOUNT_USAGE captures runtime object references, including views and dynamic tables that dbt does not model.

Use this SQL to walk the dependency graph upstream from any governed object:

SELECT referenced_object_name,
referenced_object_domain,
referencing_object_name,
referencing_object_domain
FROM SNOWFLAKE.ACCOUNT_USAGE.OBJECT_DEPENDENCIES
WHERE referencing_object_name = ‘FCT_REVENUE’

This query returns every object that FCT_REVENUE directly references. Walk it recursively — joining back on referenced_object_name — to traverse the full upstream chain to raw source tables.

The resulting lineage map, combined with the object tag on each node showing domain owner and sensitivity classification, gives a business stakeholder or auditor a complete, queryable chain of custody for any metric in under five minutes.

When dbt lineage and OBJECT_DEPENDENCIES are both in place, the answer to “where did this number come from?” is a SQL query, not a meeting.

8. Security & Access

Key controls and separation of duties:

• Required permissions model: Separate roles for read, write, and ownership at the schema level. No user should have ACCOUNTADMIN for day-to-day work. Service accounts used by pipelines should have the minimum privilege needed to write to their target schema.
• Secret management: Pipeline credentials should be rotated on a defined schedule and stored outside Snowflake. Snowflake's external tokenisation or secrets integration can be used where applicable.
• Separation of duties: The role that creates Snowflake objects should not be the same role used to query production data. The data engineering team provisions infrastructure; business roles are granted by the domain steward in coordination with the platform team.
• Auditability: ACCESS_HISTORY provides a column-level audit trail. Organisations with regulatory obligations should establish a process for periodic review — at minimum, a quarterly review of privileged role membership and an annual review of all access grants.

8.2 Emergency Access Path

The standard access provisioning process — domain steward approval, change request, governance council review — operates on a cycle that is incompatible with genuine production emergencies.

A month-end close blocked by a missing role grant, or an urgent regulatory data pull needed within hours, cannot wait for the next council meeting.

Every governance model needs a documented emergency access path that is equally rigorous without being slow.

The pattern that works in practice is a break-glass role: a pre-defined, time-limited role with the minimum scope needed to address the most common emergency scenarios (e.g., FINANCE_EMERGENCY_READ scoped to the reporting schema only).

Granting the break-glass role requires two-person authorisation — the on-call data platform lead and the domain data steward — documented via a Jira ticket or equivalent tracking system created before the grant is executed.

The role is granted with a hard expiry enforced at the Snowflake level using a session policy or, for short windows, a scheduled Task that executes REVOKE after a defined interval (typically 4–8 hours).

Every use of the break-glass role triggers an automatic ACCESS_HISTORY export to the compliance inbox.

The governance council reviews all break-glass activations at its next scheduled meeting; repeated use of the same emergency path is a signal that a permanent role gap exists and should be addressed in the RBAC model, not normalised as an operational workaround.

9. Performance & Cost

9.1 Performance Considerations

• Governance mechanisms — masking policies, row access policies, object tagging — add acceptable query overhead when implemented correctly.

However, row access policies that use subqueries against mapping tables can cause significant performance degradation on large fact tables in production; this is one of the most common causes of post-go-live performance incidents on governed Snowflake deployments.

Masking policies chained across multiple joined columns compound this effect.

All governance policies should be load-tested against representative query patterns before promotion to production, and query profiles should be reviewed for unexpected policy evaluation costs.

The performance risk arises when policies are applied inconsistently or when large numbers of policy evaluations are chained across joins.

• Warehouse sizing for governance workloads (metadata queries, audit reviews, quality checks) should be kept separate from analytical workloads to avoid contention.
• Clustering on large governed tables should be considered where the primary access pattern is known and stable; this reduces the scan cost of data quality checks run on large datasets.

9.2 Cost Drivers

• Compute: Governance-related workloads (quality checks, audit queries, catalogue sync jobs) should run on a dedicated small warehouse that auto-suspends aggressively.
• Storage: Object tagging and metadata storage carry negligible cost. Time Travel settings should be calibrated per domain — financially critical data may warrant 90-day retention; transient staging data does not.
• Data sharing: Snowflake Secure Data Sharing does not incur egress costs within the same cloud region. Cross-region or cross-cloud data sharing involves compute and transfer costs that should be accounted for in the platform cost model.

9.2 Cost Drivers

• Auto-suspend all warehouses, including governance-dedicated ones. A warehouse left running for a metadata query is a common and avoidable cost leak.
• Use resource monitors with notifications at defined credit thresholds. Alerts should go to a platform owner, not just an on-call engineer.
• Batch quality checks and audit queries into scheduled windows rather than running them on-demand; this improves warehouse cache utilisation and reduces credit consumption.

10. Operations & Monitoring

10.2 Alerting

• Pipeline failures should trigger immediate alerts to the data engineering on-call channel. Alerts should include the pipeline name, affected table, and the last successful run timestamp — not just an error code.
• Freshness SLA breaches should alert the domain data steward directly, not only the data team. The steward is accountable for escalating if the data is needed for a time-sensitive business process.
• Quality check failures should be routed to a shared data quality tracker. Each open issue should have an assigned owner and a target resolution date, preventing quality backlogs from accumulating invisibly.
• Cost alerts should fire at 80% of the monthly resource monitor threshold to allow corrective action before the limit is hit.

11. Runbook: Top Issues

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.COPY_HISTORY 
WHERE TABLE_NAME = '<table_name>' 
  AND LAST_LOAD_TIME > DATEADD(hour, -24, CURRENT_TIMESTAMP()) 
ORDER BY LAST_LOAD_TIME DESC;

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.TASK_HISTORY 
WHERE NAME = '<task_name>' 
  AND STATE != 'SUCCEEDED' 
ORDER BY SCHEDULED_TIME DESC 
LIMIT 10;

SELECT USER_NAME, ROLE_NAME, QUERY_START_TIME, OBJECTS_ACCESSED 
FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY 
WHERE QUERY_START_TIME BETWEEN '<window_start>' AND '<window_end>'
  AND ARRAY_SIZE(OBJECTS_ACCESSED) > 0;

12. Common Pitfalls

• Treating the data catalogue as a finished project : A catalogue is only as useful as its currency. If updating metadata depends on manual effort by the data team alone, it will drift. Governance tooling should be connected to pipeline completion events and dbt documentation so that metadata updates are automated wherever possible.
• Assigning data ownership without accountability mechanisms : Naming a data steward in a spreadsheet is not governance. Stewards need to receive alerts, attend review forums, and have a defined process for handling issues in their domain. Ownership without obligation is decoration.
• Building an RBAC model that mirrors the org chart : Org charts change. Roles built around individual names or team names instead of access patterns become unmanageable within a year. Design roles around the data they access and the actions they perform.
• Applying governance only at the consumption layer : If masking and access policies are applied only to BI tool connections but not to the underlying Snowflake objects, a user with direct SQL access bypasses all controls. Governance must be enforced at the data platform layer.
• Launching governance as a one-time initiative : Governance degrades without maintenance. Source systems change, teams restructure, regulations evolve. The governance model needs a review cadence — at minimum, a quarterly check of role assignments and a semi-annual review of policies and standards.

13. Variations & Use Cases

14. Next Steps

If the patterns described here resonate with challenges your organisation is facing, the practical starting point is a governance readiness assessment — an honest audit of where ownership currently sits, what controls exist, and where the most urgent gaps are.

• Start with a domain ownership map: Identify the five to eight data domains most critical to business decisions and assign a named steward to each before any technical work begins.
• Audit your current RBAC model: Review how many roles exist in your Snowflake account, what privileges they carry, and whether each role has a documented owner. Roles without owners should be reviewed for revocation.
• Run a governance gap review with your SI: A two-to-three day structured assessment with your Snowflake system integrator can identify the delta between your current state and a production-ready governance model, with a prioritised remediation plan.
• Review Boolean's related content: See our companion blog on Snowflake RBAC design patterns, and our guide to data quality monitoring using dbt and Snowflake tasks.
• Request a governance workshop: Boolean offers a half-day facilitated session with your data and business leadership to define governance principles, assign domain ownership, and produce a 90-day implementation roadmap.

14. Appendix

A. Governance Responsibility Matrix (RACI — Summary)

RACI key: Accountable = single owner who answers for the outcome and has final decision authority. Responsible = party who performs the work. Consulted = subject matter input required before action. Informed = notified of outcome but not involved in execution. Each activity must have exactly one Accountable party; multiple Responsible parties are permitted.

B. Glossary

• RBAC (Role-Based Access Control): A method of restricting system access to authorised users based on their assigned role, rather than their identity directly. In Snowflake, roles are granted privileges on objects.
• Dynamic Data Masking: A Snowflake feature that substitutes sensitive column values with masked or tokenised values at query time, based on the role of the querying user. The underlying data is unchanged.
• Data Steward: A business-side individual accountable for the quality, meaning, and appropriate use of data within a specific domain. Not a technical role — a business accountability.
• Data Product: A curated, governed, and documented dataset or set of datasets designed to be consumed by business users or downstream systems. Distinguished from a raw or intermediate dataset by its certified status and documented ownership.
• ELT (Extract, Load, Transform): A data processing pattern where raw data is loaded into the destination platform first, then transformed within it. Contrasts with ETL, where transformation happens before loading. Snowflake's compute model makes ELT the preferred pattern.
• Object Tagging: The application of key-value metadata labels to Snowflake database objects. Tags can be used to drive masking policies, classify data sensitivity, and feed external cataloguing tools.
• Data Lineage: The documented path that data takes from its source system through ingestion, transformation, and consumption. Lineage enables root cause analysis of data quality issues and supports regulatory traceability requirements.
• Governance Council: A cross-functional forum with representation from data platform, business domains, and compliance. Responsible for ratifying governance policies, resolving ownership disputes, and reviewing the health of the governance model on a recurring cadence.