What you will be able to do
- Explain how Snowflake encryption protects regulated data at rest, in transit and in customer-managed stages
- Describe how masking policies and access controls limit who sees sensitive values, and how policy use is recorded
- Use Access History and column lineage as evidence for GDPR and CCPA audits
- Identify which edition and shared-responsibility documents apply to PHI, cardholder data and HITRUST
Key concept
Shared responsibility for compliance — Snowflake's certifications cover the controls Snowflake runs. The customer still has to configure and evidence its own controls, such as masking, access grants and auditing, before a workload is compliant.
1.Encryption: the baseline every regulation assumes
GDPR, HIPAA, CCPA and PCI DSS all expect regulated data to be unreadable to anyone who intercepts it or gets at the storage underneath it. Snowflake handles this without any configuration: all customer data at rest is encrypted, and all traffic to and from the service is encrypted with TLS. Snowflake describes this as end-to-end encryption (E2EE), which it defines as a method that stops third parties from reading data while it is at rest or in transit.
One gap needs a design decision from you: files in an external stage, meaning a cloud storage location you own. Files uploaded to an internal stage are encrypted by the Snowflake client before they leave the user's machine. Files in an external stage are only protected if you protect them. Snowflake recommends client-side encryption for data files in external stages. With client-side encryption, the client encrypts each file with a random key and encrypts that key with the customer's master key. As a result, the cloud provider and any ISP never see the data in the clear. This matters when an auditor asks whether cardholder data or PHI was ever stored unencrypted in a bucket.
To load client-side-encrypted files, you create a named stage that carries the master key. The key must be a 128-bit or 256-bit AES key encoded in Base64. The named stage also acts as an access control: you can grant the stage to other users without giving them the cloud credentials or the encryption key.
Checkpoint 1 of 5· Fill the gap
Which parameter inside ENCRYPTION supplies the customer's client-side master key for this external stage?
create stage encrypted_customer_stage
url='s3://customer-bucket/data/'
credentials=(AWS_KEY_ID='ABCDEFGH' AWS_SECRET_KEY='12345678')
encryption=( ? ='eSxX...=');Snowflake loads client-side-encrypted data from a named stage created with the MASTER_KEY parameter, which takes a Base64-encoded 128-bit or 256-bit AES key.
Source: docs.snowflake.comSources1
2.Masking policies and access controls: limiting who sees what
Encryption protects data from outsiders. Regulations also limit which insiders may see personal data. For example, a support analyst may need a customer record without needing the full card number. In Snowflake, Column-level Security covers this with two features. Dynamic Data Masking uses masking policies to selectively mask plain-text data in table and view columns at query time. External Tokenization replaces sensitive values with tokens before the data is loaded, then detokenizes them at query runtime through masking policies that call external functions.
The underlying data never changes. Instead, the masking policy's conditions decide at query time whether a user sees the full value, a partially masked value, an obfuscated value or a token. For compliance, this means you can meet data-minimisation expectations without keeping a separate redacted copy of the table.
Masking works together with access control. Row access policies restrict which rows a role can see. Grants restrict which objects a role can use. Snowflake's Access History guidance gives the order of work: after you trace where sensitive data has moved, apply masking and row access policies, tighten access control on the stage and table, and tag the sensitive columns so they can be tracked. Policies also leave evidence behind. When a query touches a protected object, Snowflake records the policy information in the policies_referenced column of ACCESS_HISTORY. Separately, DDL that attaches a policy or sets a tag is recorded in object_modified_by_ddl.
Checkpoint 2 of 5· Check yourself
An auditor asks for proof that queries on a masked column were actually governed by the masking policy. Where is that recorded?
When a query references a column protected by a masking policy or an object protected by a row access policy, ACCESS_HISTORY records the policy in policies_referenced.
“Snowflake records the policy information in the policies_referenced column”Source: docs.snowflake.com
3.Auditing: answering GDPR and CCPA questions with Access History
Controls only count for compliance if you can prove they worked. Snowflake's main evidence source is the ACCESS_HISTORY view in the ACCOUNT_USAGE and ORGANIZATION_USAGE schemas. It holds one record per SQL statement. Each record links the user, the query, the objects and columns read, and the objects written. The documentation states this purpose directly: the records facilitate regulatory compliance auditing. One of the benefits it lists is identifying who wrote to a table or stage, and when, to meet regulations such as GDPR and CCPA.
| Column | What it records | Compliance use |
|---|---|---|
| user_name | The user who ran the statement | Attribute access to a named person |
| base_objects_accessed | The original source tables and columns | Show which underlying personal data was read |
| objects_modified | Tables, columns and stages written | Prove who wrote regulated data, and when |
| object_modified_by_ddl | DDL, including policy and tag changes | Show when a masking or row access policy was attached |
| policies_referenced | Masking and row access policies in effect | Show that protected data was read under a policy |
Column lineage extends this to data that has been copied. Snowflake follows data from a source column through INSERT, MERGE and CTAS into every derived table, as long as no object in the chain has been dropped. Two benefits matter for privacy regulation. First, data stewards can tag sensitive source columns once, without extra work each time someone creates a derived object. Second, privacy officers can count how many tables and views now hold a copy of a sensitive column. That count is how data privacy officers can prove how they satisfy regulatory compliance standards, for example under GDPR.
Checkpoint 3 of 5· Match them up
Match each compliance need to the Access History capability that meets it
Tap a term, then the definition that fits it.
Access History names GDPR and CCPA as the goal of auditing write operations. Column lineage gives copy counts, and policies_referenced records which policies were in effect.
“when the write operation occurred to meet compliance regulations, such as GDPR and CCPA”Source: docs.snowflake.com
Sources3
4.PHI, cardholder data and the shared-responsibility documents
Some regulations also affect which edition you buy. Business Critical Edition, formerly called Enterprise for Sensitive Data (ESD), offers higher levels of data protection for organisations with extremely sensitive data, particularly PHI data that must comply with HIPAA. If a scenario mentions protected health information, look for Business Critical first.
For PCI DSS, Snowflake is a Level 1 Service Provider compliant under PCI DSS version 3.2.1. A Qualified Security Assessor (QSA) assesses Snowflake every year. This lets customers store, process or transmit cardholder data in Snowflake. However, Snowflake's own compliance does not make the customer compliant. The Attestation of Compliance (AoC) is available on request. Customers can also request the Snowflake PCI Shared Responsibility Matrix, which lists the requirements the customer still owns.
Healthcare follows a similar pattern through HITRUST CSF. That framework combines controls drawn from US federal law, such as HIPAA and HITECH, with other standards. Through the HITRUST Shared Responsibility and Inheritance Program, customers can inherit Snowflake's certification, but only if they apply the controls the matrix assigns to them.
Checkpoint 4 of 5· Check yourself
A retailer moves cardholder data into Snowflake and says that Snowflake's PCI DSS compliance covers its own audit. What is accurate?
Snowflake's compliance allows cardholder data in the service, but some PCI responsibilities fall to the customer. The Shared Responsibility Matrix sets out which ones.
“there are PCI compliance responsibilities that fall to customers outside of those managed by Snowflake”Source: docs.snowflake.com
Checkpoint 5 of 5· Exam question
A hospital analytics team must load protected health information (PHI) into a new Snowflake account under a HIPAA business associate agreement. The account was created as Standard edition. What must the security engineer do before PHI is loaded?
Correct answer: A — Move the account to Business Critical edition and sign a business associate agreement with Snowflake before PHI is loaded
- A. Correct. Snowflake supports PHI under HIPAA and HITRUST only on Business Critical (and higher) editions, and a BAA must be in place before regulated data is loaded.
- B. Incorrect. Tri-Secret Secure is not available on Standard edition, and a customer-managed key does not by itself make an account eligible for PHI.
- C. Incorrect. Masking policies are a column-level control and cannot change the edition-level support boundary; masking does not place a Standard account in HIPAA scope.
- D. Incorrect. Periodic rekeying is an Enterprise feature, but the minimum edition for PHI support is Business Critical, not Enterprise.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Applying a masking policy replaces the sensitive values stored in the table, so the originals can no longer be recovered.Why is that wrong?
Dynamic Data Masking is evaluated at query time. The stored data stays the same, and the policy decides what each user sees.
Covered in Masking policies and access controls: limiting who sees what
2.Because Snowflake holds a certification such as HITRUST CSF, every customer workload automatically inherits it.Why is that wrong?
Customers can inherit Snowflake's HITRUST certification only if they apply the controls assigned to them in the Shared Responsibility Matrix.
Covered in PHI, cardholder data and the shared-responsibility documents
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“all customer data at rest is encrypted and encrypted with TLS in transit to/from the Snowflake service”
↩︎ Encryption: the baseline every regulation assumes“We recommend client-side encryption for data files in external stages”
↩︎ Encryption: the baseline every regulation assumes“The MASTER_KEY parameter requires either a 128-bit or 256-bit Advanced Encryption Standard (AES) key encoded in Base64.”
↩︎ Encryption: the baseline every regulation assumes“they can be granted to other users within a Snowflake account without revealing access credentials or client-side encryption keys to those users”
↩︎ Encryption: the baseline every regulation assumes - 2.
“uses masking policies to selectively mask plain-text data in table and view columns at query time”
↩︎ Masking policies and access controls: limiting who sees what“External Tokenization makes use of masking policies with external functions.”
↩︎ Masking policies and access controls: limiting who sees what“sensitive data in Snowflake is not modified in an existing table (i.e. no static masking)”
↩︎ Exam trap 1“sensitive data in Snowflake is not modified in an existing table (i.e. no static masking)”
↩︎ Prediction - 3.
“apply policies (masking and row access) to protect data, update access control settings to further regulate access to the stage and table”
↩︎ Masking policies and access controls: limiting who sees what“The records in these views facilitate regulatory compliance auditing”
↩︎ Auditing: answering GDPR and CCPA questions with Access History“data privacy officers can prove how they satisfy regulatory compliance standards”
↩︎ Auditing: answering GDPR and CCPA questions with Access History“Data stewards can easily tag sensitive source columns without having to do additional work after creating derived objects (e.g. CTAS).”
↩︎ Auditing: answering GDPR and CCPA questions with Access History“Snowflake records the policy information in the policies_referenced column”
↩︎ Checkpoint“when the write operation occurred to meet compliance regulations, such as GDPR and CCPA”
↩︎ Checkpoint - 4.
“particularly PHI data that must comply with HIPAA”
↩︎ PHI, cardholder data and the shared-responsibility documents - 5.
“Snowflake is a Level 1 Service Provider compliant under PCI DSS version 3.2.1”
↩︎ PHI, cardholder data and the shared-responsibility documents“customers can request the Snowflake PCI Shared Responsibility Matrix”
↩︎ PHI, cardholder data and the shared-responsibility documents“there are PCI compliance responsibilities that fall to customers outside of those managed by Snowflake”
↩︎ Key concept“there are PCI compliance responsibilities that fall to customers outside of those managed by Snowflake”
↩︎ Checkpoint - 6.
“unify security controls based on aspects of US federal law (such as HIPAA and HITECH)”
↩︎ PHI, cardholder data and the shared-responsibility documents“customers can now inherit Snowflake’s HITRUST CSF certification provided that customers apply the controls detailed in the HITRUST Alliance website”
↩︎ Exam trap 2