Two companies want to answer a joint question, did this campaign drive those sales, do our fraud victims overlap, how many patients appear in both registries, without either side handing its customer table to the other. A data clean room is the architecture for that. Vendors often sell it as a compliance checkbox; it is not one. This guide covers what makes a clean room actually defensible under GDPR: the legal roles, the DPIA, and the technical controls that prevent re-identification.
What is a data clean room and what problem does it solve?
A data clean room is a controlled environment where two or more organizations run joint analysis over combined datasets without any party seeing another party's raw records. Inputs stay isolated or encrypted, queries are restricted to aggregates, and only approved outputs leave. It exists for cases where sharing raw personal data is illegal, contractually barred, or commercially unacceptable.
The pattern shows up wherever two datasets are worth more joined than apart:
- ▸Advertising measurement: an advertiser's conversions joined with a publisher's or retailer's exposure logs, now that third-party cookies are unreliable.
- ▸Fraud and risk: two banks measuring mule-account overlap without exchanging customer lists.
- ▸Healthcare research: hospitals computing cohort statistics across sites they cannot pool.
- ▸Supply chain: a manufacturer and a retailer reconciling demand signals.
The common mechanic: each party keeps control of its own data, computation happens in a neutral and audited environment, and everything that exits passes a privacy gate.
Is the data inside a clean room anonymous under GDPR?
Usually not. Hashed emails and matched identifiers are pseudonymous, not anonymous, so GDPR applies in full to the inputs and to the matching step. Only aggregated outputs may qualify as anonymous, and only when they defeat singling out, linkability, and inference. Design the clean room as personal-data processing, because that is what it is.
The three-criteria test comes from the Article 29 Working Party opinion on anonymisation and still anchors EDPB thinking; check the EDPB's more recent guidance on anonymisation and pseudonymisation for the current position before relying on it. Two practical consequences:
- ▸Hashing is not anonymisation. An unsalted SHA-256 of an email address is reversible with a dictionary of known addresses in minutes.
- ▸You still need a legal basis for contributing data, typically legitimate interest for measurement analytics, or consent where the underlying collection falls under ePrivacy rules, plus honest coverage in your privacy notice.
Recent EU case law has moved toward assessing identifiability relative to the party actually holding the data, which can strengthen the argument for output datasets. Treat that as a position to document with counsel, not a loophole to lean on.
Which architecture should you pick: vendor platform, TEE, or build your own?
Start with a managed clean room, AWS Clean Rooms, Snowflake or Databricks Clean Rooms, or Google Ads Data Hub for ad measurement, because query restriction, aggregation thresholds, and audit logging come built in. Choose a confidential-computing design on AMD SEV-SNP or Intel TDX when parties refuse to trust any operator. Build custom only when data cannot leave your infrastructure.
- ▸Managed platforms let each party keep data in its own account while the service enforces analysis rules per table, AWS Clean Rooms, for example, distinguishes list, aggregation, and custom rules, and can layer differential privacy on results. Pin EU regions and review the sub-processor chain; the residency questions are the same ones covered in EU Data Residency: Why Where Your Data Lives Matters in 2026.
- ▸TEE-based designs run the join inside an attested confidential VM or enclave, so even the platform operator cannot read inputs. This is the same hardware story as Confidential AI Inference on GPUs: Running LLMs with NVIDIA TEE and Encrypted VRAM; remote attestation verification becomes part of partner onboarding.
- ▸Custom builds on multi-party computation or private set intersection libraries give the strongest trust story but typically cost months of specialist engineering. They are justified in inter-bank and healthcare settings, rarely in marketing.
How do you allocate GDPR roles and write the collaboration agreement?
In most collaborations the participating companies are joint controllers under Article 26 for the matching and analysis they jointly define, and the platform vendor is a processor under Article 28. Write the Article 26 arrangement early: it must allocate transparency and data-subject-rights duties between the parties, and its essence must be made available to data subjects.
The CJEU has read joint controllership broadly, so assume it applies once you jointly decide purposes and means, and document the split instead of arguing you are independent controllers. The collaboration agreement should fix, at minimum:
- ▸Enumerated purposes and a change process, purpose creep is the most common compliance failure in running clean rooms.
- ▸Permitted query templates and minimum aggregation thresholds, written as an annex that engineers can implement literally.
- ▸Output handling: who may receive results, retention periods, and an explicit ban on re-identification attempts.
- ▸Transfers: SCCs or an adequacy basis if any participant or sub-processor sits outside the EEA.
- ▸Audit and exit: mutual log-access rights and verified deletion on termination.
If you already run a GDPR program, this slots into the machinery described in GDPR Compliance for SaaS Startups: A Practical 2026 Guide.
What goes into the DPIA for a clean room?
A clean-room DPIA under Article 35 documents the joint purposes, the data flows into the matching step, a concrete re-identification threat model, and the residual risk after controls. Large-scale matching or combining of datasets appears on most supervisory authorities' DPIA-required lists, so write it before the first record is onboarded, not after launch.
The threat model is the part generic DPIA templates miss. Enumerate at least:
- ▸Differencing attacks: two overlapping aggregate queries subtracted to isolate one person.
- ▸Narrow cohorts: filter combinations that shrink a segment below any safe size.
- ▸Repeat-query averaging: re-running a noised query until the noise cancels out.
- ▸Insider probing: an analyst at either partner deliberately crafting queries.
- ▸Platform compromise: what an attacker inside the vendor's environment could reach.
Map each attack to a named control, involve both DPOs, and treat the document as living, a new query template or purpose reopens it. Check your national authority's list of DPIA-mandatory operations rather than assuming your case is exempt.
Which technical controls actually prevent re-identification?
Four control families do the real work: minimum aggregation thresholds (k typically between 25 and 100 for ad measurement), noise injection or formal differential privacy on outputs, restriction to pre-approved query templates, and differencing protection across overlapping result sets. A clean room without at least thresholds and query restriction is a shared database with extra steps.
- ▸Aggregation thresholds: suppress any output row describing fewer than k people; large ad platforms commonly sit around 50.
- ▸Noise or differential privacy: either platform-style row noise, or a formal epsilon budget using libraries like OpenDP or Tumult Analytics. Seed the noise per query definition so identical re-runs return identical results instead of fresh samples an attacker can average.
- ▸Query templates over free SQL: free-form SQL makes differencing trivial. Approved, parameterised templates reviewed by a privacy gate close most of that surface.
- ▸No row-level egress, ever: exports limited to aggregate tables, with a human review queue for anything anomalous.
- ▸Rate limits and result caching as backstops against automated probing.
How do you match identities without exchanging raw identifiers?
Never swap plaintext or naively hashed emails. Use a private set intersection protocol, a TEE that ingests identifiers encrypted to the enclave, or a neutral match partner that returns pairwise pseudonymous IDs to each side. Expect email-based consumer match rates of roughly 30 to 70 percent, and keep the matched table short-lived.
- ▸Private set intersection: ECDH-style PSI protocols (Google's Private Join and Compute is an open-source reference) reveal only the intersection, or just its size, and nothing about non-matching records.
- ▸TEE ingestion: each party encrypts identifiers to an attested enclave key, so matching happens where no operator can watch.
- ▸Match partners: identity vendors returning pairwise pseudonymous IDs are processors in your chain; diligence them like any other processor, sub-processors included.
- ▸Store the resulting crosswalk separately from analytical tables, with retention typically in the 30-to-90-day range and automatic deletion.
What operational guardrails keep the clean room compliant over time?
Compliance decays without operations. Log every query with the analyst identity behind it, gate new query templates through privacy review, reopen the DPIA when purposes change, and delete matched tables on schedule. Assign a named owner on each side, unattended clean rooms drift into being ordinary data shares with better branding.
- ▸Keep an immutable query log and review it, it is your primary evidence if a regulator or partner asks what actually ran.
- ▸Run quarterly access reviews on both analyst accounts and service credentials.
- ▸Meter utility: a legitimate-interest basis needs the processing to keep earning its risk, so track whether the collaboration still answers real questions.
- ▸Define the incident path for a leaked or over-precise output before it happens.
- ▸Fold ownership and cataloguing into the practices from Data Governance Engineers Will Actually Use.
How TuniCyberLabs helps
We design and build clean-room deployments for EU and North African clients: platform selection, Terraform-provisioned AWS Clean Rooms or Snowflake setups, TEE-based matching where the trust model demands it, differential-privacy output layers, and the DPIA and Article 26 drafting alongside your counsel. If you have a partner waiting on a data collaboration and a legal team waiting on answers, talk to our engineers and we will scope the smallest defensible build that ships.