Skip to main content

Protecting Customer Privacy with Snowflake Aggregation Policies

Preventing Access to Individual Records Without Losing Insight

We were very excited to learn about Snowflake’s aggregation policies, allowing us to globally protect our customers from exposing individual records, which are rarely needed for most analytics cases. If you’re working with tables that contain customer PII, and you want to prevent anyone from slicing down to an individual row (like by Id), this is the feature you can use in addition to or as an alternative to masking policies.

The Problem

Sharing analytics with partners or even internal teams often opens the door to sensitive data exposure. If someone can query your customer table and filter down to a single IdThat’s a problem—whether it’s compliance (HIPAA, FERPA, GDPR) or just good data hygiene.

The Solution: Aggregation Policies

Aggregation policies in Snowflake are schema-level guardrails. When applied, they block any query that tries to expose data for a group smaller than your defined threshold (say, less than 5 records).

So instead of hoping users won’t filter down to an individual customer_id, Snowflake enforces it.


Protecting a Customer Transactions Table

Let’s say you’ve got a table called transactions that includes potentially sensitive information. Here’s how to apply a policy that blocks access to any query unless it’s grouped with at least 2 records.

Step 1: Create the Aggregation Policy

CREATE OR REPLACE AGGREGATION POLICY set_min_group_size
AS () RETURNS AGGREGATION_CONSTRAINT ->
  AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 2);

Step 2: Apply the Policy to the Table

ALTER TABLE transactions
SET AGGREGATION POLICY set_min_group_size;

That’s it. From now on:

✅ This query will work:

SELECT category, AVG(amount)
FROM customer_transactions
GROUP BY category
HAVING COUNT(*) >= 2;

❌ But this query will fail:

SELECT * FROM customer_transactions
WHERE customer_id = '12345';

Why This Matters

  • No App Workarounds Needed
    No more custom filters or developer-dependent logic.
  • Built-In Enforcement
    Privacy lives at the query engine level—not the dashboard layer.
  • Zero-Maintenance Compliance
    Once implemented, the policy works automatically across all tools and users.

Bonus: Role-Based Privacy

Want to give internal teams more flexibility? Snowflake supports conditional logic in aggregation policies too:

CREATE OR REPLACE AGGREGATION POLICY set_privacy_policy
AS () RETURNS AGGREGATION_CONSTRAINT ->
  CASE
    WHEN CURRENT_ROLE() = 'ANALYST'
      THEN NO_AGGREGATION_CONSTRAINT()
    ELSE AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => w)
  END;

In Summary…

If your table contains any kind of customer identifier, apply an aggregation policy and protect it at the source. It’s low effort, high impact.

Want help applying this to your Snowflake environment? That’s what we do. Book time with a DataTools Doctor and we’ll lock it down the right way.