Security & Governance

The Security & Governance pillar focuses on building a secure and compliant Snowflake environment by implementing the principles of the Confidentiality, Integrity, and Availability (CIA) triad. The recommendations provided within this framework are based on the Shared Responsibility Model and focus on the security controls that are the customer's responsibility. The goal is to minimize security risks by securing the Snowflake perimeter, using the principle of least privilege for data access, responsibly deploying AI, and preparing for security incidents.

Principles

Secure the perimeter

A strong security perimeter is built using network, identity, and policy constructs. You should assess network traffic to and from your Snowflake accounts to ensure network and endpoint security are in place for all connections. For identities, leverage modern authentication and authorization flows and enforce conditional access policies for Snowflake accounts.

Governance

Governance in the security pillar is about enforcing, monitoring, and auditing data access, privacy, and compliance controls. This ensures that auditors can prove who can see what, and under what conditions. Broader governance concepts like data quality and lineage are addressed in other pillars.

Responsible AI

The rapid adoption of AI capabilities brings security concerns, particularly regarding the protection of sensitive data. It's crucial to use AI responsibly and ensure that AI deployments are secure within your Snowflake environment.

Assume Breach

You must prepare for security events by having established Cyber Security Incident Response Plans (CSIRP) specifically for your Snowflake accounts. This includes creating playbooks with actionable tasks for different incident scenarios and conducting regular training and tabletop exercises. Continuous monitoring of Snowflake accounts for anomalous behavior is also vital.

The following key recommendations are covered within each principle of Security & Governance:

Shared Responsibility Model

Reliability and security are shared responsibilities between the cloud provider, Snowflake, and the customer. The Shared Responsibility Model outlines this division of responsibilities and is the foundation for all security recommendations. It is essential for customers to understand, document, and operationalize these specific responsibilities to prevent gaps in security ownership. You can find more information about this model in the Snowflake documentation: https://www.snowflake.com/en/resources/report/snowflake-shared-responsibility-model/.

Network Security 

You can build a strong security perimeter by using network policies to control network traffic to your Snowflake account. Network policies are a crucial first step in securing your environment by allowing or denying user access based on their IP address. It is a best practice to define a clear set of network policies that restrict access to only trusted IP addresses or IP ranges. For more advanced network control, consider using features like Snowflake's Private Connectivity options.

Authentication & Authorization

Authentication and authorization are fundamental to securing your Snowflake environment. You should use Role-Based Access Control (RBAC) to manage user permissions and ensure that each user has the minimum level of access required to perform their job duties, a principle known as least privilege. Modern authentication methods like federated authentication with SSO (Single Sign-On) should be used whenever possible to simplify user management and improve security.

Data Protection 

Data protection involves implementing controls to protect sensitive data at rest and in transit. Snowflake provides native features like Default Encryption at Rest and Client-Side Encryption. You can enhance this with Customer-Managed Keys (CMK) using Snowflake's integration with cloud provider key management services. Additionally, features such as Time Travel and Fail-safe provide data protection and recovery from logical errors by allowing you to restore data to a previous state. For more details, see the documentation on Time Travel.

Data Governance

Data governance ensures that data access, privacy, and compliance controls are enforced, auditable, and monitored. This includes the use of Dynamic Data Masking and Row Access Policies to control who can see what data under what conditions. Classification and Object Tracking are also critical for identifying and protecting sensitive data and maintaining data lineage.

Incident Response 

Having a well-defined Cyber Security Incident Response Plan (CSIRP) is vital for preparing for security events. The plan should include playbooks with actionable tasks and should be regularly tested through tabletop exercises to ensure effectiveness. Regular monitoring for anomalous behavior in your Snowflake accounts is key to early detection and rapid response to potential incidents.

Overview

Securing the perimeter of a Snowflake environment is crucial for protecting data and maintaining business continuity. A well-architected framework for this involves a multi-layered approach that addresses network policies, identity and credential management, and authentication hardening. By implementing these controls, you can ensure that access to your data platform is strictly controlled, external threats are proactively blocked, and your organization is resilient against potential security breaches.

Recommendations

Hardening the Perimeter and Network Access

Implementing Network Policies is a critical first step to securing your Snowflake environment. These policies, such as Network ACLs, should be used to restrict connections to your data platform from only approved and trusted IP ranges. Proactively mitigating data exfiltration pathways is also essential; this involves securing external stages, restricting outbound connectivity, and actively monitoring for high-volume data egress. You can significantly reduce your attack surface by utilizing a combination of user-level and account-level network policies. Account-level policies prevent the use of stolen credentials from exploited IP addresses and ensure all users access the platform from known IPs. User-level policies can be used to prevent end-users from using service accounts and allow for enforced exceptions to account-level policies. For further information, see the Snowflake documentation on network policies.

Identity and Credential Management

A robust security posture requires the elimination of static credentials across your organization. Instead, you should mandate the adoption of modern authentication flows like SAML, Key Pair, and OAuth for all identities, including human users, service accounts, and machine-to-machine processes. This approach minimizes the risk of credentials being compromised. It's also vital to establish a Privileged Access Management (PAM) program to govern, monitor, and strictly control access for administrative and high-privilege roles. This process helps to mitigate the risk of misuse of administrative access. A formal process should exist for granting, reviewing, and revoking high-privilege access, ideally with a tool to manage and monitor these administrative sessions.

Hardening Authentication

Enforcing Multi-Factor Authentication (MFA) is a key recommendation for hardening your Snowflake environment. Snowflake supports various MFA methods, including TOTP (Time-based One-Time Password) authenticator apps like Microsoft and Google Authenticator, as well as Passkeys and DUO, the only method with a "Push" notification option. It's recommended to avoid SMS as a fallback to prevent SIM swapping attacks by selecting the "Tablet" option in DUO instead of "Phone". Additionally, you should implement Workload Identity Federation (WIF), allows for service-to-service authentication method that lets workloads, such as applications, services, or containers, authenticate with Snowflake using their cloud provider’s native identity system, such as AWS Identity and Access Management (AWS IAM) roles, Microsoft Entra ID (Managed Principles), and Google Cloud service accounts to get an attestation that Snowflake can use and validate.

Overview

The Governance principle defines how sensitive data is accessed, protected, and proven compliant. In Snowflake, this means translating business rules into enforceable controls: masking and row policies, projection constraints, role hierarchies, and auditable evidence, so that teams can state with confidence who can see what, under what conditions, and how that access is monitored. Governance is most effective when it is automated and observable: tags drive policy attachment, Access History substantiates usage, and dashboards highlight drift and exceptions. The broader disciplines of lineage, quality, and continuous improvement are addressed across other pillars, but their outcomes are strengthened by a sound governance baseline here.

Desired outcome

A well‑architected governance posture lets organizations demonstrate that sensitive data is consistently classified and protected across environments, access is role‑based and least‑privilege, row‑level and projection rules limit exposure to the minimal necessary surface, AI/LLM interactions are scoped and logged, and regulatory obligations are mapped to Snowflake‑native controls with reproducible evidence. When governance operates in this manner, audit readiness becomes routine and does not hinder delivery.

Common anti-patterns

Weak governance often shows up as direct user‑to‑role grants without federation, unmasked PII in widely used datasets, manual access reviews that miss drift, agentic/LLM activity that is neither logged nor constrained, and uncontrolled role/object growth that accumulates technical debt. These patterns increase the likelihood of over‑exposure and complicate audits.

Benefits

A cohesive approach reduces breach and compliance risk, accelerates onboarding and offboarding through automated RBAC, improves trust in analytics and AI and shortens audit cycles by turning control checks into repeatable queries and evidence packs. Teams gain faster access to the right data because policies are pre‑bound and self‑enforcing.

Risks

Absent these practices, unauthorized access to sensitive data becomes more likely, regulatory obligations become hard to prove and model or agent outputs may inadvertently reveal protected information. Over time, unmanaged roles and objects increase operational drag and obscure ownership.

Recommendations

Start by defining a policy model in business terms: what constitutes sensitive information, who requires access, and what contextual factors must be considered (role, location, purpose). Express those rules as tags and policies in Snowflake. Classify sensitive columns, apply masking and row access policies that reference tags, and route consumption through curated views with explicit projection constraints. Integrate with an Identity Provider so users receive privileges via roles, not direct grants. Enable Access History and utilize Account Usage to create governance dashboards. Schedule drift detection to flag untagged columns, unused or over‑privileged roles, and detached policies. Finally, connect obligations (GDPR, HIPAA, PCI, SOX) to the specific Snowflake controls and the queries that produce evidence.

Recommendation checklist

1. Define RBAC hierarchy
2. Classify/tag sensitive datasets, bind masking & RAP policies
3. Enable Access History and build audit dashboards
4. Automate drift detection (orphan roles, untagged columns, policy detachment)
5. Configure Cortex AI governance (prompt logging, redaction, agent scope)
6. Build control-to-query library for regulatory evidence
7. Review governance scorecard quarterly (coverage, exceptions, audit readiness)

Overview

The Governance principle defines how sensitive data is accessed, protected, and proven compliant. In Snowflake, this means translating business rules into enforceable controls: masking and row policies, projection constraints, role hierarchies, and auditable evidence, so that teams can state with confidence who can see what, under what conditions, and how that access is monitored. Governance is most effective when it is automated and observable: tags drive policy attachment, Access History substantiates usage, and dashboards highlight drift and exceptions. The broader disciplines of lineage, quality, and continuous improvement are addressed across other pillars, but their outcomes are strengthened by a sound governance baseline here.

Desired outcome

A well‑architected governance posture lets organizations demonstrate that sensitive data is consistently classified and protected across environments, access is role‑based and least‑privilege, row‑level and projection rules limit exposure to the minimal necessary surface, AI/LLM interactions are scoped and logged, and regulatory obligations are mapped to Snowflake‑native controls with reproducible evidence. When governance operates in this manner, audit readiness becomes routine and does not hinder delivery.

Common anti-patterns

Weak governance often shows up as direct user‑to‑role grants without federation, unmasked PII in widely used datasets, manual access reviews that miss drift, agentic/LLM activity that is neither logged nor constrained, and uncontrolled role/object growth that accumulates technical debt. These patterns increase the likelihood of over‑exposure and complicate audits.

Benefits

A cohesive approach reduces breach and compliance risk, accelerates onboarding and offboarding through automated RBAC, improves trust in analytics and AI and shortens audit cycles by turning control checks into repeatable queries and evidence packs. Teams gain faster access to the right data because policies are pre‑bound and self‑enforcing.

Risks

Absent these practices, unauthorized access to sensitive data becomes more likely, regulatory obligations become hard to prove and model or agent outputs may inadvertently reveal protected information. Over time, unmanaged roles and objects increase operational drag and obscure ownership.

Recommendations

Start by defining a policy model in business terms: what constitutes sensitive information, who requires access, and what contextual factors must be considered (role, location, purpose). Express those rules as tags and policies in Snowflake. Classify sensitive columns, apply masking and row access policies that reference tags, and route consumption through curated views with explicit projection constraints. Integrate with an Identity Provider so users receive privileges via roles, not direct grants. Enable Access History and utilize Account Usage to create governance dashboards. Schedule drift detection to flag untagged columns, unused or over‑privileged roles, and detached policies. Finally, connect obligations (GDPR, HIPAA, PCI, SOX) to the specific Snowflake controls and the queries that produce evidence.

Recommendation checklist

1. Define RBAC hierarchy
2. Classify/tag sensitive datasets, bind masking & RAP policies
3. Enable Access History and build audit dashboards
4. Automate drift detection (orphan roles, untagged columns, policy detachment)
5. Configure Cortex AI governance (prompt logging, redaction, agent scope)
6. Build control-to-query library for regulatory evidence
7. Review governance scorecard quarterly (coverage, exceptions, audit readiness)

CLS (column‑level security)

Column‑level security protects sensitive attributes with masking policies that adapt to context. In practice, tags like SENSITIVITY and REGULATORY_SCOPE travel with columns and trigger masking automatically, while session attributes such as role, network location, or declared purpose inform whether data is shown in the clear or redacted. Deterministic masking can preserve joinability where required, and clear‑text access can be logged via secure UDF patterns when justified. In regulated scenarios, tokenization may be necessary; it should be paired with strict stewardship and evidence of necessity.

Design approach

Keep base tables secured and expose consumers to policy‑protected views. Separate administrative personas from analytical personas to avoid privilege creep and ensure least privilege.

Assessment prompts

Which roles can view clear PII, and under what context? How are exceptions time‑boxed, tracked, and reviewed?

RAP (row access policies)

Row access policies constrain visibility at the record level based on attributes like geography or line of business. Centralizing rules in secure UDFs and driving entitlements from reference tables makes policies explainable and maintainable. Performance should be validated against real workloads, and pruning/clustering strategies used where helpful.

Design Approach

Adopt a hub‑and‑spoke model: one policy per domain, so all child tables and views inherit the same semantics through tags.

Assessment Prompts

Are RAP rules managed from a single source of truth rather than embedded in views? What are the policy evaluation latency and cache hit rates under load?

Projection policy

Projection controls define which columns (or combinations of columns) may be selected together, preventing risky joins (e.g., date of birth with ZIP and gender). Express these rules in curated secure views and verify them in CI so prohibited projections never reach production. Pair projection constraints with masking and row access for layered protection.

Design Approach

Publish approved column bundles per persona and provide redaction views for common but risky analytics patterns.

Assessment Prompts

Which disallowed column combinations are blocked today? How are projection constraints tested and reported in CI pipelines?

CLS (column‑level security)

Column‑level security protects sensitive attributes with masking policies that adapt to context. In practice, tags like SENSITIVITY and REGULATORY_SCOPE travel with columns and trigger masking automatically, while session attributes such as role, network location, or declared purpose inform whether data is shown in the clear or redacted. Deterministic masking can preserve joinability where required, and clear‑text access can be logged via secure UDF patterns when justified. In regulated scenarios, tokenization may be necessary; it should be paired with strict stewardship and evidence of necessity.

Design approach

Keep base tables secured and expose consumers to policy‑protected views. Separate administrative personas from analytical personas to avoid privilege creep and ensure least privilege.

Assessment prompts

Which roles can view clear PII, and under what context? How are exceptions time‑boxed, tracked, and reviewed?

RAP (row access policies)

Row access policies constrain visibility at the record level based on attributes like geography or line of business. Centralizing rules in secure UDFs and driving entitlements from reference tables makes policies explainable and maintainable. Performance should be validated against real workloads, and pruning/clustering strategies used where helpful.

Design Approach

Adopt a hub‑and‑spoke model: one policy per domain, so all child tables and views inherit the same semantics through tags.

Assessment Prompts

Are RAP rules managed from a single source of truth rather than embedded in views? What are the policy evaluation latency and cache hit rates under load?

Projection policy

Projection controls define which columns (or combinations of columns) may be selected together, preventing risky joins (e.g., date of birth with ZIP and gender). Express these rules in curated secure views and verify them in CI so prohibited projections never reach production. Pair projection constraints with masking and row access for layered protection.

Design Approach

Publish approved column bundles per persona and provide redaction views for common but risky analytics patterns.

Assessment Prompts

Which disallowed column combinations are blocked today? How are projection constraints tested and reported in CI pipelines?