Snowflake data clean rooms

Define the trust boundary

Treat each participant as the owner of its data. Record what the other participant can join, filter, aggregate, or project. Limit outputs to what the approved use needs. Hashing an identifier can reduce exposure, but it does not make linkage risk disappear. Permitted questions: The analyses each party may run, in plain language. Join keys: The columns on which records may be matched. Projected columns: The fields that may appear in results. Aggregation threshold: The smallest group a result may describe. Output shape: Row-level results forbidden; aggregates only. Retention: How long inputs, results, and logs persist. Review owner: Who approves a new question, dataset, or template. Write the boundary so a reviewer who is not an engineer can test a proposed analysis against it. If the agreement permits campaign overlap reporting and a proposed template joins purchase history to location traces, the boundary should reject it before any query runs. Snowflake clean rooms enforce policies inside the collaboration rather than in the underlying account. A provider can attach join, projection, and aggregation policies to shared tables, and the consumer runs analysis templates against them. Warehouse-level controls such as roles and row access policies still protect the provider's own estate, but they do not substitute for clean-room policy design. Snowflake clean-room policies can control join columns and projected columns for analysis templates. Snowflake also warns that policy behavior depends on the template and configuration. Test the complete template with representative data and adversarial queries.

Build approved templates

A template should expose a narrow analytical operation. Avoid general SQL access. Validate inputs, constrain joins, apply output thresholds, and reject unsupported dimensions. Version the template and record who approved it. Constrain parameters as narrowly as the analysis allows. Prefer enumerated values over free text, date ranges with maximum spans over open ranges, and validated identifiers over raw strings. A template that accepts arbitrary SQL fragments is a query endpoint with extra steps. Treat template changes as releases. A new version needs a reviewer, a recorded approval, and a regression run against the adversarial test set described below. Keep old versions retrievable so a disputed result can be traced to the exact logic that produced it. For each template, document:

Business purpose and owner
Permitted datasets and columns
Join and output policy
Minimum aggregation threshold
Expected query volume and cost owner
Evidence captured for each run
Expiry and review date

Test leakage and misuse

Test small groups, repeated queries, differencing attacks, unusual filters, null values, and attempts to project restricted columns. Review whether multiple allowed outputs can be combined to reveal a person or small group. Include operational administrators in the threat model. Work through a differencing attack on paper before testing it in the platform. Suppose an approved template returns audience counts. A query for the full segment returns 12,400. A second query adds one exclusion and returns 12,399. The difference isolates one record, and any attribute known about that record is now disclosed. The defense combines minimum group sizes, limits on query overlap, rate limits, and review of repeated similar queries. Cover the recurring attack classes:

Differencing: two permitted queries whose results isolate a small group.
Composition: several allowed outputs combined to infer a restricted value.
Small-cell probing: filters tuned to sit just above the aggregation threshold.
Identifier probing: joins used to test whether a known person is present.
Timing and repetition: stable populations queried over many windows.

Operate the collaboration

Monitor template changes, policy changes, participant access, query activity, rejected requests, output size, and cost. Define an incident path and a way to suspend the collaboration. Recheck the permitted purpose when a dataset, participant, regulation, or commercial agreement changes. Give each participant a named technical and business owner. The technical owner manages datasets, policies, templates, and evidence. The business owner confirms that the analysis still serves the agreed purpose. Record how a participant leaves, how its data is removed, and how completed-query evidence is retained. Define the evidence pack for each run: template version, policy version, parameters, result shape, group counts, approval reference, and timestamps. Store it where both parties' auditors can reach it under the agreement. Evidence that lives only in one party's account cannot settle a dispute. Set a cost boundary for providers and consumers. A permitted query can still create an unexpected workload. Monitor warehouse use, query frequency, rejected requests, and repeated analyses. Rate limits and scheduled analysis windows may be useful when the operating agreement requires them.

Separate identity matching from analysis

Identity matching can create the highest-risk part of a clean-room design. Define the permitted identifiers, preparation method, match rule, false-match handling, and minimum population. A shared hash can remain linkable when the underlying identifier has a small or predictable domain. Understand what hashing does and does not do. An email address or phone number has a small, enumerable domain. Any party that holds the same hash function can test candidate identifiers against the match set. Hashing hides values from casual inspection; it does not prevent dictionary attacks. Record this limit in the design, and use provider-side matching services or tokenization where the agreement requires stronger protection. Use the minimum identifiers needed for the approved join. Keep raw identity material outside the analysis surface where the design permits it. Test duplicates, household identifiers, reused contact details, missing identifiers, and participants with different normalization rules. Normalization rules decide match quality before any algorithm runs. Document case folding, whitespace and punctuation handling, international phone formats such as E.164, transliteration, and how each party treats missing or placeholder values. Two parties that normalize differently will undercount matches, and the gap will look like a business result. Measure match coverage without exposing unmatched records. A low match rate may indicate a preparation problem. It does not justify widening the identity set without a new review.

Review output disclosure risk

An aggregation threshold is one control. It does not prevent every disclosure path. Repeated queries can isolate a small group by changing one filter at a time. Several permitted outputs can be combined to infer a restricted value. Rare dimensions can identify a person even when a row does not contain a direct identifier. Create adversarial tests for these paths. Review exact-threshold groups, overlapping cohorts, complementary queries, date slices, rare categories, and queries that return a stable population over time. Decide when a result is suppressed, rounded, delayed, or sent to review. Group well above threshold: Return the result. Group at or near threshold: Suppress or route to review. Repeated overlapping queries: Rate-limit and flag for review. Rare or identifying dimension: Generalize the category or remove it. Result needed for audit: Store with restricted access, outside the analytics path. Rounding and noise trade accuracy for protection. Rounding counts to a fixed interval or adding calibrated noise makes differencing harder, and it also makes results harder to explain to a business user. Choose the mechanism per template, document it, and test that legitimate analysis still works at the chosen precision. Record the output fields, threshold, policy version, template version, participant, and execution time with each accepted result. The evidence should show why an output was allowed without copying the underlying restricted data into the log. Snowflake is moving its legacy provider and consumer clean-room interfaces toward the Collaboration API. Confirm the supported interface and migration dates in current product documentation before implementation.

Rehearse suspension and exit

Test how the team disables a participant, template, dataset, or analysis when a contract changes or an incident occurs. Confirm that scheduled workloads stop, credentials are removed, shared objects are no longer reachable, and alerts reach the right owners. At the end of the collaboration, remove access and temporary data according to the agreed retention rule. Preserve only the evidence required for audit, support, or dispute resolution. Record the final state and the owner who confirmed it. Rehearse on a schedule, not only after a scare. A suspension drill should prove that queries stop, access is revoked, scheduled jobs halt, and both parties' owners receive the same notification. An exit drill should prove that data, results, and derived objects are removed or returned as the agreement specifies, and that only the agreed evidence remains.

Release checklist

Name the permitted question and legal basis. Minimize the shared fields. Approve join, filter, and output behavior. Test disclosure risk and unsupported queries. Review identity matching for linkability and normalization. Capture access and query evidence. Set cost, retention, expiry, and incident owners. Rehearse suspension and exit with both parties. Review current Snowflake lifecycle notices before release. A clean room is a governed analytical product. Its quality depends on ownership, template design, validation, monitoring, and evidence as much as platform configuration.

Primary sources

Official references for the tools and services covered in this guide.