Secure Data Collaboration

Overview

Two organisations often need an answer that spans both their datasets without either handing over the raw records. This is an exploration of that problem: what a privacy-first collaboration boundary looks like in practice, and which parts of it are tractable with current tooling.

It is research rather than a product. The work exists to establish whether the approach is sound before anything is built on top of it.

Why it exists

Joint analysis between organisations usually means one of them copying personal or commercially sensitive data to the other. That creates a second copy to secure, a second place to breach and a governance question that is easier to defer than to answer.

The organisations this would serve are ones with a genuine reason to collaborate and a genuine reason not to pool raw data — which, once privacy regulation is taken seriously, is most of them.

Engineering approach

The guiding idea is collaboration without unnecessary sharing: answer the question that spans both datasets without either party taking custody of the other's raw records.

Processing is intended to be controlled and transient rather than accumulating a new long-lived dataset, and every step auditable so participants can see what was run against their data.

This is architectural intent. None of it describes deployed infrastructure, and the distinction matters enough to state plainly.

Design priorities

What the project is being built to do well. These describe intent, not delivered features.

• Collaboration without pooling

  Answering a shared question without either party taking custody of the other's raw personal data.

• Controlled, transient processing

  Processing scoped to the question asked, rather than creating a new permanent dataset as a side effect.

• Ownership and governance

  Each participant keeps ownership of their own data and a say in what may be done with it.

• Auditability

  A participant should be able to see what was run against their data, and when.