They should assess who the recipient is, what other data they hold, whether the recipient can reasonably re-identify people, and whether the share can be justified and documented. If the answer depends on hidden assumptions about the recipient’s environment, the share is not ready for approval. Governance should be tied to the actual recipient, not the label on the dataset.
How to decide whether pseudonymized data can be shared
Pseudonymization reduces direct identifiability, but it does not make a dataset automatically safe to disclose. The decision has to be recipient-specific: who they are, what else they already know, what they can combine it with, and whether the receiving environment makes re-identification reasonably possible. If those facts are unclear, treat the share as unapproved until the assumptions are made explicit and recorded.
That is why governance should focus on the actual recipient and the exact disclosure context, not on the label attached to the dataset. A “pseudonymized” description can hide material variation in risk if the recipient has linking data, privileged access, or a legitimate way to reverse the protection.
What makes a recipient-specific assessment necessary?
The key question is not whether the data has been pseudonymized in the abstract, but whether the proposed recipient can still identify people when the dataset is combined with other information they hold or can access. That means the same file can be acceptable for one third party and inappropriate for another, depending on their data holdings, business role, technical controls, and contractual limits.
This is a practical privacy and security boundary, not just a legal formality. Recipients with rich auxiliary datasets, broad internal access, or repeated exposure to the same subjects can often infer identities from patterns, timestamps, location, rare attributes, or small joins that look harmless in isolation.
When the share depends on assumptions about the recipient’s environment, those assumptions need to be tested, not guessed. If you cannot explain how the recipient is prevented from linking the data back to individuals, you do not yet have a defensible sharing decision.
What should the approval decision look at?
Start with the recipient’s identity and purpose, then examine the minimum facts needed to judge re-identification risk. The most useful checks are whether the recipient already holds complementary data, whether they have a legitimate operational need to combine datasets, whether the pseudonymous values are stable over time, and whether the transfer is limited to a purpose that is documented and auditable.
In practice, this often means applying the same discipline you would use for a sensitive third-party access decision. NHIMG’s Third-Party, B2B and Contractor Access Guide is a useful companion because the real question is who the recipient is and what access they can actually exercise, not what label sits on the package.
Approval should also consider whether sharing is reversible. If the recipient can retain the data indefinitely, merge it with other sources, or reuse it for a different purpose later, the original assessment may no longer hold. That is why retention limits, purpose limits, and offboarding expectations matter as much as the initial transfer decision.
Risk and Threat Considerations
pseudonymized data can still become personal data again when a recipient has enough auxiliary information to re-identify people, either directly or by inference. The main risk is not the pseudonymization step itself, but the combination risk created by the recipient’s environment, data holdings, and downstream use.
Failure mechanism: A third party joins pseudonymized records with internal systems, reference datasets, device logs, customer records, or other attributes that make individuals distinguishable, allowing re-identification or sensitive inference even without an obvious direct identifier.
Impact: The share can expose individuals, expand the controller’s liability, and undermine the assumptions behind the privacy control, especially if the recipient can keep, reuse, or redistribute the data beyond the original purpose.
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 ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AR-4 — Privacy Notice | Pseudonymized-data sharing still needs purpose and recipient disclosure governance. |
| AC-4 — Information Flow Enforcement | Sharing depends on controlling where data may flow and with whom. | |
| Recommendation — Document recipient-specific sharing terms and verify they match the approved purpose. Restrict transfers to approved recipients and use policy controls for downstream use. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Third-party sharing requires supplier-style risk assessment and control over recipient handling. |
| A.5.34 — Privacy and protection of PII | Pseudonymized data sharing still requires privacy protection and re-identification risk review. | |
| Recommendation — Assess the third party’s handling controls before approving the disclosure. Review whether the recipient can re-identify the data before authorising transfer. | ||
| SOC 2 (AICPA) | CC3.2 — Risk Assessment | Recipient-specific pseudonymized sharing is a risk-assessment decision tied to exposure and misuse. |
| Recommendation — Assess re-identification and downstream-use risk before approving the share. | ||
Practitioner Guidance
What to verify: Confirm the recipient’s other data holdings, the intended use, the technical and contractual limits on combination, and whether the pseudonymous identifiers are stable enough to support linkage beyond the approved purpose. If any of those points are unknown, the share is not ready.
Decision rule: If the recipient can reasonably re-identify people with data they already have or can lawfully obtain, treat the transfer as higher risk and require stronger controls, tighter scope, or a different disclosure method. If you cannot explain the boundary in plain language, do not approve the share.
Practitioner takeaway: The right test is not whether data is “pseudonymized”, but whether this specific recipient can still turn it back into identifiable information in practice.
Related resources from NHI Mgmt Group
- What should organisations do when a customer asks them not to sell or share personal data with third parties?
- What happens when organisations share data with third parties without APRA-level due diligence?
- How should organisations design digital credential systems so they can share only the minimum data needed with third parties?
- How should organisations assess whether pseudonymized data is still personal data under GDPR?