Data Clean Rooms Guide: Controls and Privacy Limits

A data clean room lets two or more organisations analyse their combined data without handing raw records to each other, but its privacy protection is only as good as the rules someone configures. Clean rooms are now common in advertising measurement, retail media, financial services partnerships and healthcare research, and they are sold as a privacy answer. The US Federal Trade Commission has warned that the name is misleading: a clean room combines data from different companies and exports results, and its constraints are not automatic. This guide explains how clean rooms work, the controls that matter (analysis rules, aggregation thresholds, differential privacy, query approval, encryption), the residual risks, and how to deploy and monitor one. It is for privacy engineers, data platform teams and security reviewers. For the wider set of techniques, see the Privacy-Enhancing Technologies Guide.

Key takeaways

A clean room is a rules engine, not a vault. The FTC describes clean rooms as cloud data processing services that let companies exchange and analyse data restrained by rules that limit data use; the rules are the whole of the protection.
Defaults can be permissive. The FTC notes clean room services often default to giving both parties full access to all data, so every constraint must be deliberately configured and tested.
Aggregation thresholds alone do not stop inference. Repeated, overlapping queries can single out individuals; differential privacy with a finite privacy budget, or pre-approved query templates, close that gap.
Using a clean room does not change the law. The FTC states that unlawful data practices remain unlawful with or without a clean room, so purpose, consent and contracts still decide what may be matched.
The clean room is a new attack surface. It concentrates identifiable data from several organisations behind cloud accounts and service credentials, so identity controls and logging matter as much as privacy rules.

How a data clean room works

Every clean room has the same basic parts, though products name them differently:

Collaboration: the shared space and its membership. In AWS Clean Rooms a collaboration creator invites AWS accounts as members; in Snowflake Data Clean Rooms an owner creates the clean room and assigns roles.
Roles: data providers contribute data, an analysis runner (or "member who can query") runs analyses, and a results receiver gets the output. Snowflake's documentation separates the owner, data provider and analysis runner; the runner bears the cost of analysis. AWS lets the creator designate which member pays for compute.
Data offerings or configured tables: a controlled view of each party's data. AWS reads data from its original location rather than copying it into another provider; Snowflake describes a data offering as a live view of the source data, not a snapshot, with a specification that controls which columns are exposed.
Join keys: the identifiers matched across parties, typically hashed email addresses, customer IDs or identity graph IDs. AWS adds ID mapping tables and entity resolution for this.
Analysis rules or templates: what questions may be asked and what may leave. This is where privacy is won or lost.
Outputs and activation: aggregate reports, or audience lists pushed to a party's account for use in campaigns. Snowflake permits activation only if the data offering, collaboration and template all allow it.

Typical uses are campaign measurement (did people exposed to an ad go on to buy), audience overlap and planning, lookalike modelling (AWS Clean Rooms ML trains a lookalike model on one party's data and generates a segment from another party's seed data), and research collaborations where raw records cannot be shared.

Control types compared

AWS Clean Rooms documents three analysis rule types, which map well to the choices any clean room offers.

Control	What it allows	Built-in protections (AWS documentation)	Residual risk
Aggregation rule	Aggregate statistics such as COUNT, SUM and AVG by permitted dimensions, using INNER JOIN, no subqueries	Blind match, aggregation required, minimum aggregation threshold of at least 2, predefined query structure	Differencing attacks across many queries; small thresholds
List rule	Row-level lists of the overlap between tables	Blind match, overlap required, predefined query structure	Output is row level by design: the overlap list itself is personal data
Custom rule with analysis templates	Most SQL constructs, but only for templates (or providers) each data owner has approved	Template review, minimum aggregation thresholds, comparison controls, disallowed output columns, optional differential privacy	Only as safe as the review of each template
Differential privacy	Aggregate queries with calibrated noise, limited by a privacy budget	Noise per query, finite shared budget expressed as epsilon	Budget set too high, or monthly refresh on repeatedly queried rows
Encrypted computation	Queries over data kept encrypted (AWS Cryptographic Computing for Clean Rooms, C3R)	Data stays encrypted during processing	Restricts which operations are possible; key handling becomes critical

Two behaviours from the AWS documentation are worth designing around. When a query touches several configured tables, the most restrictive control from any of them applies: if one partner sets a threshold of 100 distinct identifiers per output row and another sets 150, rows need at least 150. And rows that fail the threshold are removed without the output indicating anything was removed, which analysts must understand when reading results. Without any analysis rule, an AWS configured table can be associated with a collaboration but cannot be queried.

Thresholds vary by platform. Google's Ads Data Hub, for example, documents approximate aggregation thresholds of about 50 users per row with legacy difference checks, about 20 with noise injection (its recommended mode) and about 10 for click and conversion-only queries, plus static checks that block queries exporting user identifiers.

Differential privacy and the privacy budget

Aggregation thresholds stop a single query from returning a tiny group, but a determined analyst can run two overlapping queries and subtract the results. Differential privacy addresses this by adding calibrated noise and limiting total queries. In AWS Clean Rooms it is turned on through a custom analysis rule and governed by a collaboration-level differential privacy policy with two settings:

Privacy budget: quantified in epsilon, a single finite resource shared by all differentially protected tables in the collaboration and consumed by every query. It can be increased at any time but not decreased once querying has started.
Noise added per query: expressed as the number of users whose contributions are obscured. More noise depletes the budget more slowly but gives less accurate results.

AWS also offers a monthly budget refresh for collaborations with regularly new data, and warns that it can allow arbitrary information about rows to be revealed if the same rows are queried repeatedly across refreshes. AWS documents that the results receiver cannot use differential privacy on its own tables, and that the querying member cannot join tables from two data providers who both have differential privacy turned on. For the theory and parameter choices, see the Differential Privacy Guide.

Choosing a clean room design

Need	Recommended control	Why
Recurring campaign measurement with fixed reports	Pre-approved analysis templates, aggregation threshold, disallowed output columns	Questions are known in advance, so each can be reviewed once
Exploratory analysis by a partner's data scientists	Differential privacy with a conservative budget	Open-ended queries need a mathematical limit on what can be learned
Audience activation	List or activation output only to the party with a lawful basis to use it, with strict column controls	Output is personal data; treat it as a data transfer
Highly sensitive data (health, financial)	Encrypted computation or confidential computing, plus templates, plus legal review	Reduces exposure of raw data to the operator as well as the partner
Small partnership, low volume	One platform both parties already use, templates only	Lower complexity and fewer credentials to manage

Smaller organisations usually join a clean room hosted by a larger partner. Their main job is reviewing the partner's proposed templates and confirming what leaves. Larger organisations operating many collaborations need a central review function, standard rule sets per data class, and an inventory of every collaboration, its members and its outputs. See the Confidential Computing Guide for hardware-backed options.

Legal and privacy considerations

The FTC's 2024 article is blunt: a clean room does not prevent impermissible disclosure or use of data and does not shield a company from FTC Act liability if the same disclosure would violate the Act by other means. It also notes clean rooms can make it easier to buy selectively the data that augments profiles, increasing tracking across the web and the physical world. Practical consequences:

Purpose and basis first: decide whether each party may lawfully use its data for the matching purpose before configuring anything. In the EU and UK, matching hashed identifiers is still processing of personal data; hashing is pseudonymisation, not anonymisation. See the Pseudonymisation Techniques Guide.
Roles and contracts: agree who is controller and who is processor (or whether parties are joint controllers) and put the analysis rules, permitted outputs and deletion terms into the contract.
Impact assessment: large-scale matching for profiling or advertising will often need a DPIA. See the DPIA Guide.
Consistency with notices: what consumers were told must match what the clean room does, including activation.

This section summarises regulator commentary and is not legal advice.

Implementation: a phased rollout

Define the use case precisely. Write down the questions to answer, the outputs needed, who receives them and the retention period. Anything not listed is out of scope.
Complete legal and privacy review. Lawful basis, roles, contract terms, DPIA where needed, and consumer notice alignment.
Minimise the data offered. Expose only the join key and the columns the use case needs; mark identifiers as disallowed output columns.
Choose and configure the rules. Prefer templates or aggregation rules with a high threshold; use differential privacy for open-ended analysis. Do not rely on platform defaults.
Test before real data. Run the agreed queries on synthetic or test data, then attempt deliberate misuse (small groups, differencing, exporting identifiers) and confirm the rules block it. Record the results.
Harden access. Enforce MFA and least privilege for every human who can create, approve or run analyses, and scope service credentials narrowly.
Go live with logging on. Enable analysis logs and cloud audit logs, and review the first weeks closely.
Close down. At the end of the collaboration remove data offerings, leave or delete the collaboration, revoke credentials and confirm deletion of outputs. Rollback during operation means disassociating a table or revoking template approval, which stops further queries.

Where identity fits

A clean room is reached through cloud accounts, roles and service credentials, and those are now a path to several organisations' customer data at once. The FTC gives the example of a service that does not require two-factor authentication being exposed by phishing or credential stuffing. The Snowflake breach showed what happens when data platform accounts rely on static passwords without MFA: infostealer credentials were enough to log in to customer accounts. For clean rooms, require MFA for all human users, give the service roles that read source data the narrowest possible scope (for example a single table or view), store any connector secrets (AWS documents using Secrets Manager for Snowflake access) in a secrets manager with rotation, and review who holds approval rights over templates. See the Service Accounts in Snowflake Guide.

Detection and measurement

Query and job logs: AWS Clean Rooms analysis logs record queries and jobs for audit; review who ran what, against which tables, and how often.
Cloud audit events: changes to analysis rules, template approvals, membership and privacy budget settings should alert the data owner.
Budget consumption: track privacy budget use against plan; a sudden drain suggests probing.
Suppressed rows: a high share of rows removed by thresholds can indicate attempts to query small groups. Because AWS removes such rows silently, this figure has to be estimated, for example by comparing expected and returned row counts in test runs.
Output transfers: every activation or export of results to a partner account should be logged and matched against the approved recipients for that collaboration.

Metrics that show the programme is working:

Percentage of collaborations with a completed legal review and DPIA decision before go-live.
Percentage of collaborations using templates or differential privacy rather than open aggregation.
Number of configuration changes to rules or budgets made without a recorded approval (target zero).
Percentage of clean room users and service roles covered by MFA and least-privilege review in the last quarter.
Number of collaborations past their end date still active (target zero).

Common failure patterns

Trusting the label: treating "clean room" as compliance in itself. Regulators have said it is not.
Low or default thresholds: leaving minimum aggregation near the platform minimum, so outputs describe very small groups.
Approving templates without reading them: a custom template can return far more than the use case needs.
Row-level activation by default: pushing audience lists to a partner when an aggregate report would have answered the question.
Weak access to the platform: shared logins, missing MFA or broad service roles over source tables, as in the Snowflake customer account compromises.
Collaborations that never end: data offerings remain live views long after the campaign.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev 5	PT-2 Authority to Process PII; PT-3 PII Processing Purposes	Lawful basis and purpose limitation for matching
NIST SP 800-53 Rev 5	AC-21 Information Sharing; SA-9 External System Services	Sharing decisions and use of the clean room operator
NIST SP 800-53 Rev 5	AU-2 Event Logging; SC-28 Protection of Information at Rest	Query logging and protection of offered data
NIST CSF 2.0	ID.AM-07; GV.SC-05; PR.DS-01	Data inventory, supply chain requirements for partners, data protection
ISO/IEC 27001:2022 Annex A	5.34 Privacy and protection of PII; 5.14 Information transfer	Privacy controls and transfer rules for outputs

Practitioner checklist

Document each collaboration's questions, outputs, recipients and end date.
Complete legal review, roles and DPIA decision before any data is offered.
Offer only the join key and required columns; block identifier columns from output.
Use templates or differential privacy; never rely on default rules.
Set aggregation thresholds deliberately and document why.
Test misuse attempts on test data and keep the evidence.
Enforce MFA and least privilege for users and service roles, and rotate connector secrets.
Enable and review analysis logs and alerts on rule or budget changes.
Decommission collaborations and confirm output deletion at the end date.

Data Clean Rooms Guide: Controls, Privacy Limits and Secure Configuration