Risk Management
As with any multi-party data system, organisations should first implement applicable baseline data protection, cybersecurity, and governance practices. In FA deployments, these baseline measures should be complemented by controls over who may submit queries, what analytical scope is permitted, how outputs are checked before release, and how activity is logged and monitored.
4.1 Key Risk Concerns
Section titled “4.1 Key Risk Concerns”The following risks are relevant in FA deployments.
| Risk | Description | Typical safeguards |
|---|---|---|
| Small-cell disclosure from aggregated outputs | Analytical results may reveal sensitive information if outputs relate to very small populations or contain minimal counts. Even where raw data remains local, the release of highly granular outputs may still enable inference about individuals or small groups. | Apply aggregation thresholds, suppress or generalise small cells, and restrict release of outputs that do not meet defined disclosure controls. |
| Query chaining and reconstruction | Users may submit multiple related queries and compare outputs to infer sensitive information about specific individuals, groups, or participating datasets. | Restrict permitted query types, impose parameter bounds, monitor query patterns, and apply governance review for repeated or highly granular queries. |
| Data heterogeneity across participants | Differences in data definitions, coding standards, schema structures, or collection practices may produce misleading or non-comparable outputs across organisations. | Establish common data definitions, harmonised schemas, agreed analytical scope, and validation checks before combining results. |
| Participant collusion or misuse of outputs | Participants or authorised users may combine outputs outside the system, or use results in ways that go beyond the intended analytical purpose. | Establish governance agreements, define acceptable use and release conditions, and restrict access to approved outputs and authorised users. |
| Unauthorised query submission or result access | If access controls are weak, unauthorised users may submit queries or gain access to intermediate or final outputs. | Enforce strong authentication, role-based access control, approval workflows, and audit logging. |
4.2 Privacy-Enhancing Technologies (PETs)
Section titled “4.2 Privacy-Enhancing Technologies (PETs)”Where baseline governance and disclosure controls are insufficient, organisations may integrate additional privacy-enhancing technologies (PETs) to strengthen protection. In practice, these PETs are used for different purposes and may be combined.
| PET | How it can be used in FA | Commentary / trade-offs |
|---|---|---|
| Differential Privacy (DP) | DP adds calibrated noise to data or results so that the contribution of any single individual has a limited effect on the released output. In FA, it is most naturally applied at the point of result release, for example by perturbing counts, rates, or summary statistics in dashboards or reports. This can help reduce small-cell disclosure risks and limit the information gain from repeated querying over the same population. | Best suited where the main concern is the safe release of aggregated outputs, rather than protection of the aggregation process itself. The trade-off is reduced precision, especially for small populations or highly granular analyses. |
| Secure Multi-Party Computation (SMPC) | SMPC allows multiple parties to jointly compute a result without revealing their individual inputs to one another. In FA, this can support secure computation of cross-party totals, averages, or intermediate statistics where participants want the final aggregate but do not want any central coordinator, or other participants, to see each party’s contribution. | Best suited where no single coordinator is fully trusted. It provides strong protection over intermediate values, but introduces more coordination and communication overhead, especially as the number of participants or complexity of the computation increases. |
| Homomorphic Encryption (HE) | HE allows certain computations to be performed directly on encrypted data. In FA, this can be used in a secure centralised architecture, where participants send encrypted intermediate values to a coordinator that performs aggregation without seeing the plaintext inputs. This is often most practical for relatively simple aggregation tasks such as sums or other bounded operations on local outputs. | Best suited where central orchestration is still desirable, but stronger confidentiality is needed during aggregation. The trade-off is substantial computational overhead and limits on the range of practical operations. |
| Trusted Execution Environments (TEEs) | TEEs provide a hardware-protected environment in which sensitive computation can be executed in isolation from the surrounding system. In FA, they can be used to run an aggregation service inside a protected enclave, reducing the extent to which the coordinator or infrastructure operator can observe intermediate results. | Best suited where a central operating model is preferred, but participants want stronger protection at the infrastructure layer. The trade-offs include hardware dependence, memory constraints, and additional engineering effort for setup, attestation, and debugging. |