How We Managed Snowflake Data Access Control for Clients with Multiple Teams

Quick Summary

Introduction

Snowflake began as a cloud data warehouse, a single place to store and query data without managing servers. It has since grown into a unified platform or a data engineering tool, and that is what pulled so many teams onto it. In the early days, only the analytics team used it.

Today, engineers, data scientists, app developers, and business users all work in the same account, and each of them needs access to different data.

We have worked with clients in healthcare, banking, finance, and insurance, and most of them come to us with the same Snowflake access control problem. Many of these clients already share one account, but access was never structured for that many people. Admin roles are spread too widely, permissions were granted to individuals instead of roles, and no one can say for certain who can see what.

The rest of this article explains the most common mistakes organizations make managing Snowflake data access control across multiple teams, the ideal architecture to follow, and the best practices to keep that structure in place as the organization grows.

Top 6 Mistakes We See Teams Making With Snowflake Data Access Control

Here are the six major mistakes we have seen most teams make when they work with Snowflake accounts across multiple teams or roles.

1. Relying on ACCOUNTADMIN and Other High-Privilege Roles

The most common issue we see is that too many people hold ACCOUNTADMIN or SYSADMIN or similar high-privilege access roles. It happens for a few reasons: there is no role structure early on, a top-level role is easier to grant than the right one, and service accounts are set up with full access to avoid permission errors.

But the trouble is that these roles can read, modify, and grant access to everything in the account. A single mistake or one compromised login then exposes the entire environment, not just one team’s data.

We implement data governance on Snowflake by first establishing the right role hierarchy, which sets the foundation for managing access across the environment. Masking, row access policies, and access reviews all rely on this structure, so we get the hierarchy right before putting these controls in place.

2. Granting Access to Individuals Instead of Roles

With many of our insurance clients, we find accounts where privileges were assigned directly to individual users on demand rather than to roles. The problem appears when those individuals change teams, move to a new project, or leave the company.

Since the access is tied to the person and not to a role, each grant has to be tracked down and removed manually. Across a number of users, no one can say for sure who can read the customer data, and every audit turns into a manual search.

3. Creating a Separate Role for Every Person (Role Sprawl)

Some teams create a separate role for each employee rather than for each job function. Because the roles map to people, their number grows with headcount, and most differ only slightly from one another.

When a new employee joins, the team duplicates an existing role to give them similar access, adding another near-duplicate. The account soon holds a large number of overlapping roles, and it becomes difficult to determine what access any single role provides.

4. Forgetting to Set Up Future Grants

In Snowflake, access is usually granted at the schema level, so a team can read every table in an area with a single grant instead of one table at a time. The catch is that this only covers the tables that exist at that moment. Any table added to the schema later is left out unless future grants are set up first.

Many teams miss this step. New tables then arrive with no access, and whoever needs them has to request it each time. To avoid the delay, someone opens the new tables to a broad role, and data that should have stayed restricted becomes visible to more people than intended.

5. Never Revoking Access Timely

Most organizations openly grant access well but fail to reclaim it on time. When someone leaves the company or moves to a new team, their old access often stays active, which creates exposure risk.

With our banking and insurance clients, this becomes a real problem, since regulators expect access to be removed the moment it is no longer needed. The result is a growing list of users and service accounts that still have access no one uses.

6. Leaving Sensitive Data Unmasked

On a shared Snowflake account, sensitive columns are often left unmasked, which means anyone who can query the table can read them. That includes fields such as names, account numbers, and health records.

We have seen this with our healthcare clients: an analyst running a normal report can end up seeing protected health information they have no reason to access, and the same applies to account and policy details in banking and insurance.

The Two Pillars of Snowflake Data Access Control: RBAC and DAC

Snowflake controls data access through two models. One decides how access is assigned, the other decides who can hand it out. Most problems we fix come from teams using one well and ignoring the other.

Role-Based Access Control (RBAC)

In Snowflake, privileges are never given to people directly. They are given to roles, roles are assigned to users, and a role can also be granted to another role, so access builds up in layers. What a person can do depends entirely on the roles they hold.

When our Snowflake developers implement RBAC in Snowflake for our clients, they build the roles in two layers. One set holds the access to data, such as read access to the finance schema. The other maps to a job, such as for a data analyst or data engineer, and inherits that access. Users get only the job roles, so access is defined once and inherited everywhere instead of rebuilt role by role.

Discretionary Access Control (DAC)

Every object in Snowflake, whether a database, schema, or table, has an owner. That owner decides, at its own discretion, which other roles can access it.

When we set up access for a client, we assign object ownership to a dedicated role. That role owns the databases, schemas, and tables, and no personal or admin account holds ownership. On schemas with sensitive data, we apply managed access schemas, which give only the owner the right to grant access to the tables inside.

How the Two Fit Together

RBAC and DAC need to be set up together. In most accounts we review, the roles are reasonably organized, but ownership was never planned. Each object belongs to whatever role happened to create it, which means people can grant access from roles no one is watching. We assign ownership on purpose while we build the roles, so access and ownership match.

Best Practices for Snowflake Data Access Control Recommended by Bacancy

Here are the eight best practices we, at Bacancy, recommend to our clients for keeping Snowflake data access control secure and manageable as their teams grow.

1. Establish a Strict System Role Hierarchy

Connect every custom role to Snowflake’s built-in system roles so none are left unmanaged. Grant every functional role to SYSADMIN, keep ACCOUNTADMIN for account-level work only, and use USERADMIN for day-to-day provisioning.

For many of our banking clients, we have seen them connect their custom roles straight to ACCOUNTADMIN. We restructured the hierarchy under SYSADMIN and reserved ACCOUNTADMIN for account-level tasks.

2. Give Each Team Its Own Database or Schema

Give every team a dedicated database or schema to work in. This keeps one team’s tables and pipelines from spilling into another’s, and it makes access easy to reason about, since a team’s own space has clear boundaries.

For a banking client running analytics and data engineering on one shared account, we split the two into separate databases with their own functional roles, and the teams stopped overwriting each other’s tables.

3. Turn On Future Grants for New Objects

Set future grants at the schema level so any table or view created later inherits the right access on its own. Without this, every new object either lands with no access or gets opened to everyone to save time.

For a healthcare client, their pipelines created new tables every day, and analysts often found tables they were unable to query. After we set future grants on those schemas, new tables were assigned to the right roles automatically.

4. Tag and Classify Sensitive Data

Tag sensitive columns, such as PII, financial, or health fields, so governance can be applied from the tag rather than table by table. Once a column is tagged, a masking policy attached to that tag applies everywhere the tag appears.

With our insurance clients, we usually tag policyholder PII once and attach masking to that tag, so any new table that carries those fields is protected automatically.

5. Protect Data at the Column and Row Level

When several teams share the same tables, it is better to control what each one sees instead of copying the data. We usually recommend dynamic masking to hide sensitive columns from roles that should not read them, and row access policies limit which rows a role can see.

With our healthcare clients, analysts often need to work with patient data without seeing who the patients are. We mask fields such as name and medical record number, and add row access policies so each clinic sees only its own records.

6. Review and Revoke Access on a Schedule

Access should be reviewed on a fixed schedule, not only when something goes wrong. On a set cadence, each team lead confirms who still needs the access their roles carry, and anything unused is removed.

With our fintech clients, we set up a quarterly review, and the first round alone clears out a big list of access permissions left behind by people who had changed teams.

7. Monitor Access with Access History and Lineage

Track who reads which data using Snowflake’s access history, and use lineage to see where sensitive data flows across tables and views. Set alerts on the most sensitive schemas so unusual reads surface early.

For our clients preparing for an audit, their access history lets us show exactly who had read the sensitive tables, turning a stressful request into a quick report.

8. Automate Provisioning and Manage Access as Code

Connect Snowflake to an identity provider such as Okta or Azure AD using SCIM, so that when someone joins, changes teams, or leaves, their Snowflake roles update automatically. Keep your databases, roles, and grants defined in Terraform as well, so every change to access is recorded and reviewed before it goes live.

We usually set this up for clients in regulated industries, where auditors expect every access change to be traceable. Their roles and grants live in Terraform, so each change goes through a pull request and leaves a record of who changed what and when.

Conclusion

Frequently Asked Questions (FAQs)

How should you structure Snowflake roles across multiple teams?

In Snowflake, build custom roles in two layers rather than granting everything from SYSADMIN. Access roles hold the object privileges, such as SELECT on a schema, following a pattern like FINANCE_READ. Functional roles map to a job, such as FINANCE_ANALYST, and inherit the access roles they need. Assign users only the functional roles, so moving someone between teams is a single role change.

How do you protect sensitive data when several teams share the same Snowflake tables?

Use Snowflake’s column and row-level controls instead of copying the data. Dynamic data masking hides sensitive columns, such as PII, from roles that should not read them, so the same table returns real values to some users and masked values to others. Row access policies restrict which rows a role sees, so a regional team reads only its own region’s records.

How do you make sure new Snowflake tables get the right access automatically?

Set future grants at the schema level. A standard grant in Snowflake covers only the tables that exist when it runs, so tables created later have no access until someone grants it by hand. With future grants in place, every new table or view is assigned to the correct access role as soon as it is created, which matters most for teams running frequent pipelines.

How do you see who has access to what in Snowflake?

Use Snowflake’s ACCESS_HISTORY to track which users read which objects, and review role grants on a schedule to confirm access is still needed. Set alerts on sensitive schemas so unusual reads surface early. In the Horizon Catalog, this monitoring sits alongside tagging and masking, giving a current view of access and the evidence auditors ask for.