How should organisations decide between input privacy and output privacy when designing PET-based data collaboration?

Use input privacy when parties must contribute sensitive data to a joint computation without exposing the raw inputs to each other. Use output privacy when the main risk is inferring individual records from released results. In practice, many deployments need both, because protecting inputs alone does not stop leakage through repeated or overly granular outputs.

How to choose the privacy boundary you actually need

The decision starts with the collaboration model, not the technology. If the parties must share sensitive records to compute a shared result, the core concern is usually whether the inputs stay hidden from collaborators, operators, and the platform. If the main exposure is what can be inferred from the published or returned results, the boundary shifts to output privacy, especially when the same dataset can be queried repeatedly or at high granularity.

Input privacy is the better fit when the business question depends on combining data from multiple holders without revealing each holder’s raw records. That is common in cross-organisation analytics, federated computation, and joint model training where contributors need assurance that their source data cannot be reconstructed by other participants. Output privacy is better when a result can be individually sensitive even if no one sees the raw inputs, such as aggregate counts, rankings, or scores that can still leak membership or attribute information.

Most PET-based collaborations should treat the two as complementary rather than competing goals. A strong input privacy design can still leak information through repeated queries, overly precise outputs, or small cohorts, while a strong output privacy design does not protect raw inputs if the computation or operator can inspect them. The practical question is which side of the trust boundary carries the highest likelihood and cost of misuse, then whether the same deployment also needs a second layer to close the remaining leak path.

Where the leakage risk actually sits

Think in terms of attack surface and inference path. Input privacy reduces exposure during collection, processing, and joint computation, which matters when collaborators do not fully trust one another or the compute environment. Output privacy reduces exposure at release time, which matters when the result itself can be used to infer whether a person was present, how a subgroup behaves, or how an individual compares to peers.

That distinction becomes sharper as the collaboration scales. Small participant sets, rare attributes, and repeated runs can turn an otherwise safe result into a disclosure channel. In those cases, output privacy is not just a reporting concern, it becomes a control on inference risk. EU General Data Protection Regulation (GDPR) is a useful reference point here because data protection by design and security of processing both push teams to consider whether leakage occurs before, during, or after the computation.

Input privacy and output privacy also fail differently. Input privacy usually fails when raw data is visible to the wrong party, when encryption or enclave assumptions are broken, or when a trusted processor can still extract more than intended. Output privacy usually fails when results are too detailed, too frequent, or too easily cross-correlated with outside information. The right design choice is therefore not just about confidentiality in general, but about which stage of the workflow is most likely to expose identifiable information.

Designing for both without overengineering

Many collaboration patterns need both layers because each protects a different leakage path. That does not mean applying every privacy mechanism everywhere. It means mapping the data flow first: who contributes, who computes, who can see intermediate state, who can see the final output, and what can be inferred from repeated use. When that map is clear, input privacy controls can be placed around the computation boundary and output privacy controls around the release boundary.

For governance and design review, the useful question is whether the result can be safely reused. If a release is meant to support ongoing analysis, benchmarking, or API-style access, output privacy needs explicit limits on granularity, frequency, and cohort size. If the collaboration is a one-time joint computation with highly sensitive source records, input privacy should be the first priority because the raw data itself is the highest-value secret. NIST Privacy Framework is a good fit for structuring that review because it frames privacy as a risk-management problem, not just a cryptographic one.

Where the privacy boundary spans systems and organisations, the control choice should also match the trust model. If the platform operator is not fully trusted, input privacy mechanisms need to reduce what the operator can observe. If the operator is trusted but recipients are not, output privacy needs to reduce what the recipients can learn. In mature deployments, the boundary is often split so each party gets only the minimum visibility required for its role.

Risk and Threat Considerations

Privacy failures in PET-based collaboration usually come from inference, not direct exposure. A design that protects raw inputs can still leak sensitive facts through repeated queries, small-group outputs, linkage attacks, or overly precise aggregates, while a design that only hides outputs can still expose source records to insiders, operators, or compromised infrastructure.

Failure mechanism: Input privacy fails when the computation, host, or intermediary can inspect raw records or intermediate state; output privacy fails when repeated or granular releases let an observer reconstruct individual information.

Impact: The result can be re-identification, membership disclosure, competitor intelligence leakage, or loss of participant trust, which can make the collaboration unusable even if the underlying PET is technically sound.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while GDPR defines the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	Art.25 — Data protection by design and by default	PET design choices directly affect privacy-by-design obligations.
	Art.32 — Security of processing	Input and output privacy are both controls for protecting processing against disclosure.
Recommendation — Bake input and output privacy into the collaboration design from the start. Apply security measures that reduce disclosure across computation and release.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Privacy boundaries should minimize who can see raw inputs or detailed outputs.
	SC-28 — Protection of Information at Rest	Sensitive source data in PET workflows still needs protection while stored or staged.
	AU-13 — Monitoring for Information Disclosure	Repeated or granular outputs can create inference leakage that monitoring should detect.
Recommendation — Restrict access to the minimum data needed for each collaboration role. Protect staged collaboration data with strong storage controls and encryption. Monitor releases for disclosure patterns that increase inference risk.

Practitioner Guidance

What to prioritise: Start by classifying the highest-value exposure point in the workflow. If collaborators must never see each other’s raw records, prioritise input privacy first; if the main danger is what the result reveals, prioritise output privacy first.

What to verify: Confirm whether the output can be queried, combined, or repeated in ways that materially increase inference risk. If yes, treat output privacy controls as mandatory rather than optional, even when input privacy is already strong.

Decision rule: If a single mechanism cannot protect both the source data and the release channel, design for layered privacy and accept the added complexity. Practitioner takeaway: the right PET design is the one that closes the dominant inference path, not the one that sounds strongest in isolation.