Teams should assess more than disclosure in a privacy notice. The proposed test looks at reasonable expectations, transparency, data minimisation, genuine choice, proportionality, and impacts on individuals. Privacy, legal, and product teams should map each use to its purpose, data categories, systems, and downstream disclosures, then test whether a less privacy invasive approach would achieve the same outcome.
How the proposed test goes beyond a privacy notice
The proposed Australian reforms move secondary use assessment away from a narrow disclosure exercise. A privacy notice still matters, but it is only one input. Privacy teams need to ask whether the person would reasonably expect the use, whether the purpose is clear, whether the use is proportionate to the original context, and whether the same outcome could be achieved with less data or a less intrusive design. That shifts the analysis from “was it mentioned?” to “would this use still feel fair in context?”
This matters because secondary use often starts with a lawful collection purpose and then expands through product change, analytics, vendor integrations, or internal reuse. The legal risk is not just surprise, it is mismatch between the original relationship and the later use. Teams should therefore assess the use on its own facts, not on the existence of broad privacy boilerplate. In practice, the most common failure is treating a notice as permission for almost anything the business later wants to do.
How to assess fairness and reasonableness in practice
A workable assessment starts by mapping the full use case. Privacy, legal, product, and security teams should identify the specific data elements involved, the system or workflow where the reuse occurs, who receives the data, and what downstream disclosures or transfers follow. That inventory should then be tested against the original collection context, the sensitivity of the data, and the benefit the secondary use is meant to create.
- Purpose fit, does the reuse align with the original reason the data was collected?
- Expectation fit, would an ordinary person expect this reuse in the circumstances?
- Necessity fit, is each data category actually needed for the new use?
- Impact fit, does the reuse create undue surprise, risk, or disadvantage?
- Design fit, can the outcome be achieved with aggregation, de-identification, shorter retention, or narrower access?
Reasonableness also depends on process quality. Teams should be able to show how the decision was made, not just the final conclusion. That means documenting the purpose, the data fields reviewed, the human review involved, and any constraints or alternatives considered. If the use depends on a vendor, model, or analytics pipeline, the assessment should include who can see the data, where it is stored, and whether the downstream use is compatible with the original purpose.
A strong practical test is whether the use would still feel proportionate if explained plainly to the affected person, without relying on legal phrasing. These assessments break down when product teams treat broad analytics or product improvement language as a universal justification for reuse across unrelated contexts.
Common edge cases and where teams get it wrong
Tighter secondary-use controls often increase review effort, so organisations need to balance speed against the risk of normalising vague reuse. The hardest cases are not obvious misuse cases, but uses that are technically related and still feel excessive to the individual.
One edge case is internal reuse across business units. A dataset collected for one service may be attractive for fraud, personalisation, or model training elsewhere, but the fairness test still applies separately to each use. Another is where the data is already visible to the organisation in a technical sense, which does not automatically make the later use fair. Access and purpose are different questions.
Another common problem is over-reliance on consent wording or broad terms in a privacy policy. Current guidance suggests that notice quality helps, but it does not by itself resolve a weak purpose match or an unnecessarily invasive design. Teams should also be careful with sensitive information, cross-context profiling, and uses that may affect vulnerable individuals more sharply than the average user.
The better the secondary use is documented as a concrete, bounded purpose, the easier it is to defend. The more it depends on open-ended future reuse, the harder it is to justify as fair and reasonable.
Risk and Threat Considerations
Secondary use creates privacy risk when organisations reuse personal information in ways people would not reasonably expect, or when a broad internal purpose begins to cover multiple downstream uses that were never clearly bounded. The exposure is not just legal non-compliance, it is loss of trust, increased complaint risk, and the possibility that a technically valid use is still judged unfair because it is disproportionate.
Failure mechanism: Risk materialises when teams rely on generic notice language, fail to test data minimisation, or expand a dataset into new systems and vendors without reassessing purpose, sensitivity, and impact. The problem is usually cumulative, a use starts as acceptable, then becomes harder to justify as more categories, recipients, and contexts are added.
Impact: The likely consequences are over-collection, excessive disclosure, avoidable privacy harm, remediation work, and a weaker position if a regulator or complainant asks why the reuse was reasonable in context. Once the reuse becomes difficult to explain in plain language, the fairness case is often already weak.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-02 — Legal and Regulatory Requirements | Secondary-use fairness depends on privacy risk governance and legal obligations. |
| Recommendation — Embed secondary-use reviews in governance decisions before any reuse goes live. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Identity and data-use decisions often depend on trustworthy user-context handling. |
| Recommendation — Apply privacy-preserving identity practices when secondary use depends on user context. | ||
| NIST SP 800-53 Rev 5 | Security and Privacy Controls | Privacy and access controls support limiting reuse, disclosure, and retention. |
| Recommendation — Use privacy and access controls to constrain reuse to approved purposes. | ||
Practitioner Guidance
What to prioritise: Test the reuse against the original collection context before you worry about whether the notice mentioned it. The first question is whether the later use changes the relationship with the individual in a way that would reasonably surprise them.
What to verify: Confirm that each secondary use has a named purpose, a documented data-minimisation rationale, and a clear view of downstream access or disclosure. If the team cannot explain why a specific field is needed, that field should usually be removed from the use case.
Decision rule: If the same outcome can be achieved with less personal information, narrower access, or lower downstream sharing, treat the broader design as the higher-risk option and require a stronger justification.
Practitioner takeaway: Fairness assessments work best when they are treated as a design control, not a wording check; the real test is whether the secondary use still makes sense after the data, audience, and impact are made explicit.
Related resources from NHI Mgmt Group
- How should privacy teams assess whether Alabama’s APDPA applies to them?
- How should organisations assess whether pseudonymized data is still personal data under GDPR?
- Which teams should own privacy evidence when automated decisions use personal data?
- How should security teams assess whether a generative AI model is safe enough for business use?